diff options
| author | Sjors Provoost <sjors@sprovoost.nl> | 2019-05-07 22:42:58 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2019-05-07 20:50:25 +0000 |
| commit | ba16ba61f4f4ac993611c9ec07e436c889f4eed4 (patch) | |
| tree | eab1e03ffd2cfc2ea011d2609eb2338a783d61ef /dc | |
| parent | 7407f0154e48491b8e84da2ca4e3ccb3a5d07140 (diff) | |
| download | pi-bitcoindev-ba16ba61f4f4ac993611c9ec07e436c889f4eed4.tar.gz pi-bitcoindev-ba16ba61f4f4ac993611c9ec07e436c889f4eed4.zip | |
Re: [bitcoin-dev] Taproot proposal
Diffstat (limited to 'dc')
| -rw-r--r-- | dc/6d42f5bef777b27f622f5b718b948c1f82fefe | 268 |
1 files changed, 268 insertions, 0 deletions
diff --git a/dc/6d42f5bef777b27f622f5b718b948c1f82fefe b/dc/6d42f5bef777b27f622f5b718b948c1f82fefe new file mode 100644 index 000000000..d501a7e5b --- /dev/null +++ b/dc/6d42f5bef777b27f622f5b718b948c1f82fefe @@ -0,0 +1,268 @@ +Return-Path: <sjors@sprovoost.nl> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id C79D3DD4 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 7 May 2019 20:50:25 +0000 (UTC) +X-Greylist: delayed 00:07:18 by SQLgrey-1.7.6 +Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com + [64.147.123.19]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 71EE6FD + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 7 May 2019 20:50:21 +0000 (UTC) +Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) + by mailout.west.internal (Postfix) with ESMTP id 1EA5446F; + Tue, 7 May 2019 16:43:02 -0400 (EDT) +Received: from mailfrontend2 ([10.202.2.163]) + by compute1.internal (MEProxy); Tue, 07 May 2019 16:43:02 -0400 +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sprovoost.nl; h= + content-type:mime-version:subject:from:in-reply-to:date:cc + :content-transfer-encoding:message-id:references:to; s=fm2; bh=W + xhZp8VJJ2OJmG+29fC4oxDyE3N7Dgd4td4Id7B6VOs=; b=QIqa0yngDZg6Q8Yfc + SoeBK9cOYBobFtKHAYgMl6wDHbPOiialBmW9ELFmTrenLqdLfcPxTd3kYiBav/nZ + X+YGRIp6ZxbFOKCyH4EIeaCu1i4x0/qXwFQRb9/kLZzWiAiAcg6Iv9Jk1uj5NHCt + lh9B9lcMvR/naLjpwrC7Ag7/r3ynCIDz7KKgT6UqtW8tklxncAZ/2F8tyRBQV35J + MIwncp8XUZOV7JIxSazTqVEnQFXrjNz9BEecLhsvRzxdIMPxMY9pd65b462t3Of4 + DCqY/HbFJ9J0Nqg6If6CFPVd2QpoQMEccFKcCHdJK+CfdVlUuMmkiyzbbYpsVS/H + JaBsg== +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= + messagingengine.com; h=cc:content-transfer-encoding:content-type + :date:from:in-reply-to:message-id:mime-version:references + :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender + :x-sasl-enc; s=fm2; bh=WxhZp8VJJ2OJmG+29fC4oxDyE3N7Dgd4td4Id7B6V + Os=; b=nUwWCIPU8MovYfAIOogT0esGY5nogIDhAn8uXK7Z94F4V2bzn1BAl/LnB + 8beZkCd23auHMJ9axxv6CoyuD3sI+GH9ByIe5iw+qzqzWvhiEhFiS9h0PYAAhq7u + ddfcQ0XDyTAfiyz/4Uu2m4lr4GMGRFqCBQKtawIz2kXHStVJUYd2JWN+N1yf0Slg + jhn7gHgBTbxrHwyDkBzYExISp8mFH9W5ypMhX+gwlmKHzzakch3csKRUP6sINN8z + F6wzga4ctXR3h/OZVLk85zGFH5iJ+VMlFxvTBqR7zPARj96fD4v0V1lmFOVWVBS3 + /nQMO7danJ1JBKpDxumRIrIETS54g== +X-ME-Sender: <xms:1e3RXCh4eUUZTS-JVvHn_4abzfgggB4nRGxBCYEyn_8qYtow1nGAJQ> +X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrkedtgdduheejucetufdoteggodetrfdotf + fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen + uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne + cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepufhjohhr + shcurfhrohhvohhoshhtuceoshhjohhrshesshhprhhovhhoohhsthdrnhhlqeenucffoh + hmrghinhepghhithhhuhgsrdgtohhmpdhlihhnuhigfhhouhhnuggrthhiohhnrdhorhhg + necukfhppeekgedruddthedriedurdduheenucfrrghrrghmpehmrghilhhfrhhomhepsh + hjohhrshesshhprhhovhhoohhsthdrnhhlnecuvehluhhsthgvrhfuihiivgeptd +X-ME-Proxy: <xmx:1e3RXI7Y0Sv5vv78DY9xu_oNRK677MyxrL0tQJOwmitRNBWj54apsg> + <xmx:1e3RXMjomJNMu04hrORjNocYYO0O9UkMVrcRsim670zXfpTGzIAJqQ> + <xmx:1e3RXMaS83p2Ctd84gaucyWAgSXkFQTDrx0oJ-dljqx3hTFq8tlhpQ> + <xmx:1e3RXLYLiFCn6TZ7bNRgQAAUd4VaS3UibY-Q30eUcu9sAKvIRr6Ueg> +Received: from [192.168.178.143] (84-105-61-15.cable.dynamic.v4.ziggo.nl + [84.105.61.15]) + by mail.messagingengine.com (Postfix) with ESMTPA id 8373E103D2; + Tue, 7 May 2019 16:43:00 -0400 (EDT) +Content-Type: text/plain; + charset=us-ascii +Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) +From: Sjors Provoost <sjors@sprovoost.nl> +In-Reply-To: <201905062017.11396.luke@dashjr.org> +Date: Tue, 7 May 2019 22:42:58 +0200 +Content-Transfer-Encoding: quoted-printable +Message-Id: <34827F16-9061-4317-B91F-250734850EE6@sprovoost.nl> +References: <CAPg+sBg6Gg8b7hPogC==fehY3ZTHHpQReqym2fb4XXWFpMM-pQ@mail.gmail.com> + <201905062017.11396.luke@dashjr.org> +To: Pieter Wuille <pieter.wuille@gmail.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +X-Mailer: Apple Mail (2.3445.104.8) +X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +X-Mailman-Approved-At: Tue, 07 May 2019 21:08:09 +0000 +Subject: Re: [bitcoin-dev] Taproot proposal +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Tue, 07 May 2019 20:50:25 -0000 + +Hey Pieter, + +I think this is a reasonable collection of changes that make sense in = +combination. Some initial feedback and questions. + +=46rom the BIP: +> If one or more of the spending conditions consist of just a single key = +(after aggregation), +> he most likely one should be made the internal key. If no such = +condition exists, it may +> be worthwhile adding one that consists of an aggregation of all keys = +participating in all +> scripts combined; effectively adding an "everyone agrees" branch. If = +that is inacceptable, +> pick as internal key a point with unknown discrete logarithm (TODO). + +I assume Luke Dashjr referred to the above when saying: + +> Is there any way to use the Taproot construct here while retaining = +external=20 +> script limitations that the involved party(ies) *cannot* agree to = +override?=20 +> For example, it is conceivable that one might wish to have an = +unconditional=20 +> CLTV enforced in all circumstances. + + +One reason why someone would want to avoid a "everone agrees" branch, is = +duress (or self-discipline, or limiting powers of a trustee). In = +particular with respect to time-locks. + +Can this "unknown discrete logarithm" be made provably unknown, so all = +signers are assured of this property? Bonus points if the outside world = +can't tell. The exact mechanism could be outside the scope of the BIP, = +but knowing that it's possible is useful. + +Perhaps Lightning devs have an opinion on "everyone agrees" with respect = +to hash pre-images. I suspect there is no benefit in guaranteeing that a = +pre-image must be revealed or a timeout must be waited for and there's = +no way around that condition. + + +Regarding usage of Schnorr: do I understand correctly that the "everyone = +agrees" internal key MUST use Schnorr, and that individual branches MAY = +use Schnorr, but only if they're marked as tapscript spend? + +Why is tapscript not mandatory? + + +Misc details: + +In the Design section under "Merkle branches" I suggest adding bullet = +points with short descriptions of "various known mechanisms for = +implementing this". In addition to "space savings" maybe also briefly = +mention a few other pros and cons, like implementation complexity and = +privacy. And then point out which one you picked. + +In the Design section, explicitly point out you're no longer using the = +hash of a public key (can move some explanation up from rationale = +section). This is a significant change, even if you have good reason to = +believe it's perfectly safe. + +Regarding the 64 byte SHA256(tag) || SHA256(tag) 64-byte long = +context-specific constant: maybe add that sha-2 block size is 512 bits + +"Conceptually every Taproot output corresponds to" -> some of this = +conceptual stuff belongs in or before the Specification section. Try = +briefly explaining how tagged hashes and script validation (stack) = +interact, before specifying them in detail. The figure (without the = +pseudo-code) can be helpful for that.=20 + +In the figure with the merkle tree, the description says there's "3 = +script leaves.". So what's going on in leaf D? If it's a way to indicate = +an unused leaf, why is E different (or is also TapLeaf)? Maybe emphasize = +that "TapLeaf" tag is there so prove to all signers there's no secret = +conditions (the CVE-2012-2459 protection you refer to). + +Sjors + + +> Op 6 mei 2019, om 22:17 heeft Luke Dashjr via bitcoin-dev = +<bitcoin-dev@lists.linuxfoundation.org> het volgende geschreven: +>=20 +> There are multiple references to "space savings", but no rationale for=20= + +> treating "space" as something to save or even define. The costs are in = +CPU=20 +> time and I/O (which "space saving" doesn't necessarily reduce) and = +bandwidth=20 +> (which can often be reduced without "space saving" in commitments). = +The=20 +> proposal can apparently be made simpler by ignoring this irrelevant = +"space=20 +> saving" goal. +>=20 +> Tagged hashes put the tagging at the start of the hash input. This = +means=20 +> implementations can pre-cache SHA2 states, but it also means they = +can't reuse=20 +> states to produce data for different contexts. (I'm not sure if there = +is a=20 +> use for doing so... but maybe as part of further hiding MAST = +branches?) +>=20 +> Is there any way to use the Taproot construct here while retaining = +external=20 +> script limitations that the involved party(ies) *cannot* agree to = +override?=20 +> For example, it is conceivable that one might wish to have an = +unconditional=20 +> CLTV enforced in all circumstances. +>=20 +> It may be useful to have a way to add a salt to tap branches. +>=20 +> Some way to sign an additional script (not committed to by the witness=20= + +> program) seems like it could be a trivial addition. +>=20 +>=20 +> On Monday 06 May 2019 17:57:57 Pieter Wuille via bitcoin-dev wrote: +>> Hello everyone, +>>=20 +>> Here are two BIP drafts that specify a proposal for a Taproot +>> softfork. A number of ideas are included: +>>=20 +>> * Taproot to make all outputs and cooperative spends = +indistinguishable +>> from eachother. +>> * Merkle branches to hide the unexecuted branches in scripts. +>> * Schnorr signatures enable wallet software to use key +>> aggregation/thresholds within one input. +>> * Improvements to the signature hashing algorithm (including signing +>> all input amounts). +>> * Replacing OP_CHECKMULTISIG(VERIFY) with OP_CHECKSIGADD, to support +>> batch validation. +>> * Tagged hashing for domain separation (avoiding issues like +>> CVE-2012-2459 in Merkle trees). +>> * Extensibility through leaf versions, OP_SUCCESS opcodes, and +>> upgradable pubkey types. +>>=20 +>> The BIP drafts can be found here: +>> * https://github.com/sipa/bips/blob/bip-schnorr/bip-taproot.mediawiki +>> specifies the transaction input spending rules. +>> * = +https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawiki +>> specifies the changes to Script inside such spends. +>> * https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki +>> is the Schnorr signature proposal that was discussed earlier on this +>> list (See +>> = +https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016203.h= +t +>> ml) +>>=20 +>> An initial reference implementation of the consensus changes, plus +>> preliminary construction/signing tests in the Python framework can be +>> found on https://github.com/sipa/bitcoin/commits/taproot. All +>> together, excluding the Schnorr signature module in libsecp256k1, the +>> consensus changes are around 520 LoC. +>>=20 +>> While many other ideas exist, not everything is incorporated. This +>> includes several ideas that can be implemented separately without = +loss +>> of effectiveness. One such idea is a way to integrate = +SIGHASH_NOINPUT, +>> which we're working on as an independent proposal. +>>=20 +>> The document explains basic wallet operations, such as constructing +>> outputs and signing. However, a wide variety of more complex +>> constructions exist. Standardizing these is useful, but out of scope +>> for now. It is likely also desirable to define extensions to PSBT +>> (BIP174) for interacting with Taproot. That too is not included here. +>>=20 +>> Cheers, +>=20 +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev + + |