Subject: Re: [bitcoin-dev] Segregated witnesses and validationless mining

From: Peter Todd <[email-masked]>
Date: Thu, 31 Dec 2015 15:48:48 -0800

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