From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id C79D3DD4 for ; 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 ; 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: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrkedtgdduheejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepufhjohhr shcurfhrohhvohhoshhtuceoshhjohhrshesshhprhhovhhoohhsthdrnhhlqeenucffoh hmrghinhepghhithhhuhgsrdgtohhmpdhlihhnuhigfhhouhhnuggrthhiohhnrdhorhhg necukfhppeekgedruddthedriedurdduheenucfrrghrrghmpehmrghilhhfrhhomhepsh hjohhrshesshhprhhovhhoohhsthdrnhhlnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: 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 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: <201905062017.11396.luke@dashjr.org> To: Pieter Wuille , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 = 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