From: "David A. Harding" <dave@dtrt.org>
To: Jeremy <jlrubin@mit.edu>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Taproot (and graftroot) complexity (reflowed)
Date: Fri, 14 Feb 2020 16:36:42 -0600 [thread overview]
Message-ID: <20200214223642.djdvosj7t7e6nrdz@ganymede> (raw)
In-Reply-To: <CAD5xwhh=71XDAcSCJL9AQhZOriWmdGq4C5xT34K5wjR_g7FDfA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2087 bytes --]
On Fri, Feb 14, 2020 at 12:07:15PM -0800, Jeremy via bitcoin-dev wrote:
> Is the same if Schnorr + Merkle Branch without Taproot optimization, unless
> I'm missing something in one of the cases?
That's fair. However, it's only true if everyone constructs their
merkle tree in the same way, with a single `<schnorr_pk> OP_CHECKSIG` as
one of the top leaves. Taproot effectively standardizes the position
of the all-parties-agree condition and so its anonymity set may contain
spends from scripts whose creators buried or excluded the the all-agree
option because they didn't think it was likely to be used.
More importantly, there's no incentive for pure single-sig users to use a
merkle tree, since that would make both the scriptPubKey and the witness
data are larger for them than just continuing to use v0 segwit P2WPKH.
Given that single-sig users represent a majority of transactions at
present (see AJ Towns's previous email in this thread), I think we
really want to make it as convenient as possible for them to participate
in the anonymity set.
(To be fair, taproot scriptPubKeys are also larger than P2WPKH
scriptPubKeys, but its witness data is considerably smaller, giving
receivers an incentive to demand P2TR payments even if spenders don't
like paying the extra 12 vbytes per output.)
Rough sums:
- P2WPKH scriptpubkey (22.00 vbytes): `OP_0 PUSH20 <hash160>`
- P2WPKH witness data (26.75): `size(72) <sig>, size(33) <pubkey>`
- P2TR scriptpubkey (34.00): `OP_1 PUSH32 <pubkey>`
- P2TR witness data (16.25): `size(64) <sig>`
- BIP116 MBV P2WSH scriptpubkey (34.00): `OP_0 PUSH32 <sha256>`
- BIP116 MBV P2WSH witness data (42.00): `size(64) <signature>, size(32)
<pubkey>, size(32) <inclusion_proof>, size(36) <PUSH1 <n> PUSH32
<merkle_root> OP_MBV>`
-Dave
P.S. I think this branch of the thread is just rehashing points that
were originally covered over two years ago and which haven't really
changed since then. E.g.:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015629.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2020-02-14 22:37 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-09 20:19 [bitcoin-dev] Taproot (and graftroot) complexity Bryan Bishop
2020-02-09 20:22 ` [bitcoin-dev] An alternative deployment path for taproot technology (Re: Taproot (and graftroot) complexity) Bryan Bishop
2020-02-09 20:24 ` [bitcoin-dev] Taproot public NUMS optimization " Bryan Bishop
2020-02-14 21:21 ` Jeremy
2020-02-09 20:40 ` [bitcoin-dev] Taproot (and graftroot) complexity Matt Corallo
2020-02-09 22:32 ` Antoine Riard
2020-02-09 20:47 ` [bitcoin-dev] Taproot (and graftroot) complexity (reflowed) Bryan Bishop
2020-02-10 0:15 ` David A. Harding
2020-02-10 16:28 ` Jonas Nick
2020-02-14 20:07 ` Jeremy
2020-02-14 22:36 ` David A. Harding [this message]
2020-02-18 23:29 ` Pieter Wuille
2020-02-10 0:20 ` [bitcoin-dev] Taproot (and graftroot) complexity Anthony Towns
2020-02-10 6:27 ` ZmnSCPxj
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=20200214223642.djdvosj7t7e6nrdz@ganymede \
--to=dave@dtrt.org \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=jlrubin@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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