From: Luke Dashjr <luke@dashjr•org>
To: Pieter Wuille <pieter.wuille@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Taproot proposal
Date: Mon, 6 May 2019 20:17:09 +0000 [thread overview]
Message-ID: <201905062017.11396.luke@dashjr.org> (raw)
In-Reply-To: <CAPg+sBg6Gg8b7hPogC==fehY3ZTHHpQReqym2fb4XXWFpMM-pQ@mail.gmail.com>
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,
next prev parent reply other threads:[~2019-05-06 20:17 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-06 17:57 Pieter Wuille
2019-05-06 20:17 ` Luke Dashjr [this message]
2019-05-07 20:42 ` Sjors Provoost
2019-05-08 4:37 ` ZmnSCPxj
2019-05-08 5:16 ` ZmnSCPxj
2019-05-08 23:06 ` Pieter Wuille
2019-05-18 17:51 ` ZmnSCPxj
2019-05-08 3:44 ` ZmnSCPxj
2019-05-09 16:56 ` Johnson Lau
2019-05-10 5:38 ` ZmnSCPxj
2019-05-08 4:49 ` Anthony Towns
2019-05-08 13:10 ` Luke Dashjr
2019-05-21 17:20 ` Russell O'Connor
2019-05-23 2:06 ` Pieter Wuille
2019-05-23 2:32 ` Russell O'Connor
2019-05-22 14:14 ` John Newbery
2019-09-16 16:18 ` Greg Sanders
2019-09-17 4:09 ` ZmnSCPxj
2019-09-18 21:21 ` Pieter Wuille
2019-06-27 0:08 ` Russell O'Connor
2019-06-28 9:49 ` Anthony Towns
2019-06-28 11:16 ` Russell O'Connor
2019-08-09 14:58 Elichai Turkel
2019-08-09 18:29 ` Pieter Wuille
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201905062017.11396.luke@dashjr.org \
--to=luke@dashjr$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=pieter.wuille@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox