Hey Pieter, I think this is a reasonable collection of changes that make sense in combination. Some initial feedback and questions.
>From 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 > script limitations that the involved party(ies) *cannot* agree to override? > For example, it is conceivable that one might wish to have an unconditional > 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. 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: > > There are multiple references to "space savings", but no rationale for > treating "space" as something to save or even define. The costs are in CPU > time and I/O (which "space saving" doesn't necessarily reduce) and bandwidth > (which can often be reduced without "space saving" in commitments). The > proposal can apparently be made simpler by ignoring this irrelevant "space > saving" goal. > > Tagged hashes put the tagging at the start of the hash input. This means > implementations can pre-cache SHA2 states, but it also means they can't reuse > states to produce data for different contexts. (I'm not sure if there is a > use for doing so... but maybe as part of further hiding MAST branches?) > > Is there any way to use the Taproot construct here while retaining external > script limitations that the involved party(ies) *cannot* agree to override? > For example, it is conceivable that one might wish to have an unconditional > CLTV enforced in all circumstances. > > It may be useful to have a way to add a salt to tap branches. > > Some way to sign an additional script (not committed to by the witness > program) seems like it could be a trivial addition. > > > On Monday 06 May 2019 17:57:57 Pieter Wuille via bitcoin-dev wrote: >> Hello everyone, >> >> Here are two BIP drafts that specify a proposal for a Taproot >> softfork. A number of ideas are included: >> >> * 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. >> >> 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.ht >> ml) >> >> 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. >> >> 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. >> >> 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. >> >> Cheers, > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
