From: Pieter Wuille <pieter.wuille@gmail•com>
To: "David A. Harding" <dave@dtrt•org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Taproot (and graftroot) complexity (reflowed)
Date: Tue, 18 Feb 2020 15:29:21 -0800 [thread overview]
Message-ID: <CAPg+sBiL-m4AM8NiJP24JxPYoA8i_ZO1RuvB7YL4qmXOUd0z_w@mail.gmail.com> (raw)
In-Reply-To: <20200214223642.djdvosj7t7e6nrdz@ganymede>
On Fri, 14 Feb 2020 at 14:37, David A. Harding via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> 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.
Right, I think we shouldn't just see Taproot as adding a possibility
of a cheap single-key branch to Merkle tree. It is actively choosing
to incentivize protocols and implementations that can use the key
path, making sure that the cheapest way spending of spending is also
the most private one - as we can assume that it indeed will be the
most frequent one. I don't believe having a separate MAST-no-Taproot
spending type (through whatever mechanism) is beneficial to that.
Taproot effectively gives everyone a "key path spend is included in
the price", making it maximally appealing even to those who don't care
about privacy.
I don't think this is an unreasonable angle. There are plenty of other
options that exists if we just want to make verification constructions
cheap but disregard incentives for privacy. For example, why don't we
research account-based state/payments? Being able to avoid change
would make simple payments significantly cheaper (both in terms of
block space and computation). Of course, the reason (or at least one
of them) is that it would result in a discount for those willing to
reduce their privacy (use accounts = reuse address = don't pay for
change), and this hurts everyone (and indirectly the fungibility of
the system as a whole). This is true even when there are use cases
that would legitimately benefit from having this option.
This is of course a much weaker case, but I think it is similar.
Having no-Taproot available would reduce the incentives for those who
don't care about spending policy privacy to put the engineering effort
into building key-path-spendable protocols and implementations - and I
think such protocols, wherever possible, should be the goal. There
probably are some use cases where key path spending is truly not an
option, but I suspect they're rare, or sufficiently high value that 8
vbyte differences don't matter to them. If that turns out to be wrong,
it remains possible to add a new output type/witness version that does
support them. This does mean distinguishable outputs, but only for
things that would be distinguishable at spending time anyway, and
that's a cost we'll have to pay anyway for future structural script
improvements (like cross-input aggregation or graftroot).
Cheers,
--
Pieter
next prev parent reply other threads:[~2020-02-18 23:29 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
2020-02-18 23:29 ` Pieter Wuille [this message]
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=CAPg+sBiL-m4AM8NiJP24JxPYoA8i_ZO1RuvB7YL4qmXOUd0z_w@mail.gmail.com \
--to=pieter.wuille@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=dave@dtrt$(echo .)org \
/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