From: Peter Todd <pete@petertodd•org>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Segregated witnesses and validationless mining
Date: Thu, 31 Dec 2015 15:48:48 -0800 [thread overview]
Message-ID: <20151231234847.GB5112@muck> (raw)
In-Reply-To: <20151223013119.GA31113@muck>
[-- Attachment #1: Type: text/plain, Size: 2081 bytes --]
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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
next prev parent reply other threads:[~2015-12-31 23:48 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-23 1:31 Peter Todd
2015-12-23 15:41 ` Peter Todd
2015-12-31 23:48 ` Peter Todd [this message]
[not found] ` <CABm2gDpSnX=_jXdHMyoTd-ktXT_U-6NAVDgGMj_R2kHGYykYyA@mail.gmail.com>
2016-01-02 16:54 ` Bryan Bishop
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151231234847.GB5112@muck \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox