[Bitcoin-development] Coinbase reallocation to discourage Finney attacks

Jorge Timón jtimon at monetize.io
Thu Apr 24 11:22:24 UTC 2014


On 4/23/14, Mike Hearn <mike at plan99.net> wrote:
>> I guess word "honest" might have different meanings, that can be a source
>> of confusing.
>> 1. Honest -- not trying to destroy bitcoin
>> 2. Honest -- following rules which are not required by the protocol
>>
>
> I'm using it in the same sense Satoshi used it. Honest miners work to
> prevent double spends. That's the entire justification for their existence.

I thought the mechanism they used to prevent double-spends was proof of work.
Therefore dishonest miners where only those who mine on top of a block
which is not the longest valid chain they've seen.
To distinguish this definition from your own "honest miners are those
who decide on double-spends by mining the transaction they saw first"
definition I propose to give another new name to the later, instead of
changing the definition of the former.
So inside the group of honest miners we have some that decide on
transactions based on reception times and others that simply maximize
their revenue while respecting the protocol rules.
I suggest "stupid miners" and "smart miners" respectively as more
clear terms for what we're talking about here.

> Miners that are deliberately trying to double spend are worse than useless.

I completely disagree.
Miner's proof of work makes transactions irreversible. Even if zero
confirmation transactions weren't possible in a replace-by-fee
environment, that's very useful.
Even if you always had to wait for transactions to be confirmed with
some irreversible proof of work (as described in Satoshi's
whitepaper), it doesn't follow that "automatically resolves the
Bitcoin experiment as a failure". I don't understand how can you
conclude that.

But in fact 0 conf txs are possible *precisely* using replace-by-fee,
as described in the "
0 confirmation txs using replace-by-fee and game theory" thread. So
that conclusion is definitely wrong.

On your concrete proposal, it seems to me that you're trying to
prevent double-spending without relying on proof of work, which I
think it impossible in the context of a truly p2p system.
I don't think your current proposal is secure and I fear that at best
you will end up with an "invite only" transaction processing network
like Ripple.com has with their consensus algorithm and Unique Node
Lists: that's not really p2p.

-- 
Jorge Timón

http://freico.in/




More information about the bitcoin-dev mailing list