What is Nostr?
David A. Harding [ARCHIVE] /
npub16dt…4wrd
2023-06-07 18:22:54
in reply to nevent1q…gj4g

David A. Harding [ARCHIVE] on Nostr: 📅 Original date posted:2020-02-14 📝 Original message:On Fri, Feb 14, 2020 at ...

📅 Original date posted:2020-02-14
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200214/bc1102fd/attachment-0001.sig>;
Author Public Key
npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrd