path: root/dc/6d42f5bef777b27f622f5b718b948c1f82fefe

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