On Tue, Dec 22, 2015 at 05:31:19PM -0800, Peter Todd via bitcoin-dev wrote: > # Summary
Updates from IRC discussion: 1) There was some debate about what exactly should be required from the current block to calculate the previous block posession proof. For instance, requiring the coinbase outputs potentially restricts some mining setups; requiring a commitment to the current block's (non-coinbase) transaction outputs restricts tx selection outsourcing schemes. However, it appears that we can allow the nonce to be picked arbitrarily. Equally, if the nonce is arbitrary, then a future soft-fork can be add commitments to current block contents. Thus the previous block proof can be simple H(<nonce> + <prev-block-contents>) 2) Pieter Wuille brought up fraud proofs in relation to previous block content proofs - specifically how the simplest H(<nonce> + <prev-block-contents>) construction requires a large fraud proof to prove incorrect. This followed a bunch of debate over what exactly fraud proofs would be - a proof that some data is fraudulent, or a unmet challenge that some data is correct? Regardless, if the posession proof is structured as a merkle tree, then fraud can be easily proven with a merkle path. In that model we'd take the previous block contents and rehash it in its entirety with the nonce. The fraud proof then becomes two merkle paths - one in the original block with the original hash, and the second with the same data, and same structure, but with the nonce mixed into the hashing algorithm. Todo: writeup the difference between the fraud proof model, and the validity challenge model, to provide background to making this decision. Incidentally, based the positive response to fixing this issue w/ segregated witnesses - my main objection to the plan - I've signed the Bitcoin Core capacity increases statement: https://github.com/bitcoin-dot-org/bitcoin.org/pull/1165#issuecomment-168263005 -- 'peter'[:-1]@petertodd.org 000000000000000006808135a221edd19be6b5b966c4621c41004d3d719d18b7
signature.asc
Description: Digital signature
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
