[Bitcoin-development] Coinbase reallocation to discourage Finney attacks

Mike Hearn mike at plan99.net
Wed Apr 23 20:37:20 UTC 2014


On Wed, Apr 23, 2014 at 10:24 PM, Gregory Maxwell <gmaxwell at gmail.com>wrote:

> Right, this works in the Bitcoin network today absent any collusion by
> the miners. You give one miner a transaction and you give every other
> node you can reach another transaction.
>

Yes, but that can be fixed with double spend alerts.


> Someone you ask to not double spend is an entirely separate matter.
> They aren't self-selecting: you select who you trust to not make
> double spends and there is no need for this trust to be globally
> consistent.
>

No? It's not just your decision that matters, the receiver also has to
trust them. They're like a dispute mediator in this regard. You can pick
whoever you want, but that doesn't matter if the receiver doesn't recognise
them or trust them. You have to find an overlap to make an instant trade.

In practice if people have to think about this, evaluate brands etc then
you'd get a very small number of parties because the value of global
agreement is so high. Then it becomes hard to remove ones that have a lot
of momentum.

The censorship resistance of the block chain doesn't matter if your double
spending partners refuse to help you spend your money (because they're
being coerced). The censorship can just happen at a different place.


> To stop GHash.io we would have to take away their hardware or change the
> Bitcoin
> protocol to make their hardware useless
>

..... or, have a majority decide to zero out their coinbase rewards for
blocks that double spent against dice sites. That wouldn't undo the double
spend, but you can't do that with the multisig scheme either. All you can
do is punish the corrupted party post-hoc, either by not using them again,
or by "unpaying" them for the service they did not provide.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/91399fa1/attachment.html>


More information about the bitcoin-dev mailing list