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>
Subject: Re: [bitcoin-dev] Taproot proposal
Precedence: list

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