From: Peter Todd <pete@petertodd•org>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Segregated witnesses and validationless mining
Date: Wed, 23 Dec 2015 07:41:43 -0800 [thread overview]
Message-ID: <20151223154143.GA2295@muck> (raw)
In-Reply-To: <20151223013119.GA31113@muck>
[-- Attachment #1: Type: text/plain, Size: 2397 bytes --]
On Tue, Dec 22, 2015 at 05:31:19PM -0800, Peter Todd via bitcoin-dev wrote:
> # Easy solution: previous witness data proof
>
> To return segregated witnesses to the status quo, we need to at least
> make having the previous block's witness data be a precondition to
> creating a block with transactions; ideally we would make it a
> precondition to making any valid block, although going this far may
> receive pushback from miners who are currently using validationless
> mining techniques.
>
> We can require blocks to include the previous witness data, hashed with
> a different hash function that the commitment in the previous block.
> With witness data W, and H(W) the witness commitment in the previous
> block, require the current block to include H'(W)
>
> A possible concrete implementation would be to compute the hash of the
> current block's coinbase txouts (unique per miner for obvious reasons!)
> as well as the previous block hash. Then recompute the previous block's
> witness data merkle tree (and optionally, transaction data merkle tree)
> with that hash prepended to the serialized data for each witness.
>
> This calculation can only be done by a trusted entity with access to all
> witness data from the previous block, forcing miners to both publish
> their witness data promptly, as well as at least obtain witness data
> from other miners. (if not actually validate it!) This returns us to at
> least the status quo, if not slightly better.
>
> This solution is a soft-fork. As the calculation is only done once per
> block, it is *not* a change to the PoW algorithm and is thus compatible
> with existing miner/hasher setups. (modulo validationless mining
> optimizations, which are no longer possible)
Note that this fix can be designed to retain the possibility of
validationless mining, by allowing empty blocks to be created if the
previous witness data proof is omitted. This would achieve the same goal
as Gregory Maxwell's blockchain verification flag(1) but with
significantly less ability/reason to lie about the status of that flag.
1) [bitcoin-dev] Blockchain verification flag (BIP draft),
Gregory Maxwell, Dec 4th 2015,
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011853.html
--
'peter'[:-1]@petertodd.org
000000000000000002c7cfc8455339de54444ac9798cad32cbfbcda77e0f2b09
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
next prev parent reply other threads:[~2015-12-23 15:41 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 [this message]
2015-12-31 23:48 ` Peter Todd
[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=20151223154143.GA2295@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