[Bitcoin-development] Coinbase reallocation to discourage Finney attacks

[Daniel Krawisz]

The memory pool is just talk. There is no expectation that the memory pool
has to satisfy some standard as to what will eventually exist in the block
chain, and there are any number of ways that people could communicate
transactions to one another without putting them in the memory pool. The
memory pool can't be treated like a contract because there is no
cryptography to enforce it--there is no contract until the transactions
appear in the block chain, inherently.

Mike Hearn's proposal is nonsense because it requires miners to develop a
concensus on which blocks in the block chain are dishonest. There is no way
to prove cryptographically that a block is dishonest because the block
chain itself is the concensus system--before there is concensus, there is
no concept of dishonesty, at least as far as double-spending goes. In order
to decide that a block is dishonest and reallocate the coinbase, a prior
consensus mechanism would be required. Of course, such a consensus
mechanism would also be subject to attacks just like the block chain.

Maxwell's proposal is very good. One only trusts the oscar not to double
spend, which is perfectly reasonable if oscar is a well-known service.
Normal everyday wallets for immediate payments would simply require a
little more infrastructure.

Daniel Krawisz


On Wed, Apr 23, 2014 at 2:59 PM, Mike Hearn <mike at plan99.net> wrote:

> What you're talking about is just disagreement about the content of
>>  the memory pool
>>
>
> That's the same thing. Whilst you're mining your double spend tx, it's in
> your mempool but you don't broadcast it as per normal. Then when you find
> the block you broadcast it to override everyone elses mempool. So yours and
> theirs were inconsistent.
>
> The only slight way BitUndo differs is, they provide it as a service, and
> I don't know if they inform you when they found a block (probably not), so
> you have to do the purchase and then hope BitUndo finds the next block.
> Otherwise the purchase clears. But they could certainly add a
> pre-notification before they broadcast to get back to the exact scheme
> originally described, they have everything else in place.
>
>
>> Oscar himself can be implemented as a majority M parties to further
>> increase confidence
>
>
> This just brings us back to square one. Who are these parties and what if
> I pay them to be corrupt? What if they offer to be corrupt as a service?
>
>  Let's say I succeed in finding some parties who are incorruptible no
> matter how large of a percentage I offer them. At this point, why bother
> with miners at all? Why pay for double spend protection twice, once to a
> group of Oscar's who are trustworthy and once to a group of miners who are
> not?
>
> The point of the broadcast network and mining is so there can be lots of
> Oscar's and I don't have to know who they are or sign up with them or put
> any effort into evaluating their reputation.
>
>
>> value retail transactions— the fact that any cheating by oscar is
>> cryptographically provable (just show them the double signatures)
>> maybe be strong enough alone.
>>
>
> But as you point out, cheating my GHash.io did not result in any obvious
> negative consequence to them, despite that preventing double spending is
> their sole task. Why would Oscar be different to GHash.io?
>
> Trying to solve the problem of dishonest miners is effectively trying to
> solve the "automatically find trusted third parties" problem at scale.
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/fdc513e7/attachment.html>