From: Anthony Towns <aj@erisian•com.au>
To: Gregory Maxwell <greg@xiph•org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting
Date: Tue, 23 Jan 2018 16:44:19 +1000 [thread overview]
Message-ID: <20180123064419.GA1296@erisian.com.au> (raw)
In-Reply-To: <CAAS2fgTXg5kk6TyUM9dS=tf5N0_Z-GKVmzMLwTW1HxUgrqdo+Q@mail.gmail.com>
On Tue, Jan 23, 2018 at 12:30:06AM +0000, Gregory Maxwell via bitcoin-dev wrote:
> One point that comes up while talking about merkelized scripts is can
> we go about making fancier contract use cases as indistinguishable as
> possible from the most common and boring payments.
> Now we tweak C to produce P which is the key we'll publish: P = C + H(C||S)G.
> (This is the attack hardened pay-to-contract construction described in [2])
> Then we pay to a scriptPubKey of [Taproot supporting version] [EC point P].
Is this really intended as paying directly to a pubkey, instead of a
pubkey hash?
If so, isn't that a step backwards with regard to resistance to quantum
attacks against ECC?
Paying direct to pubkey doesn't seem quite enough to make pay-to-taproot
cheaper than p2wpkh: the extra 12 bytes in the scriptPubKey would need
you to reduce the witness by 48 bytes to maintain the weight, but I think
you'd only be saving 33 bytes by not having to reveal the pubkey, and
another 6-7 bytes by having a tighter signature encoding than DER. Still,
that's pretty close with a difference of only a couple of vbytes per
input by my count.
If it were "pay-to-taproot-hash", then presuming taproot hashes were 256
bit, then p2wpkh would be a full 12 vbytes cheaper due to the shorter
hash. That might make it hard to maximise the anonymity set. I suppose
a small penalty/discount could be added to align the economic incentives
though.
I wonder how this interacts with segwit versioning. I think you'd want
to have taproot be versioned overall so that you could cope with moving
to a new signing method (different curve, or something non-ECC based)
eventually, and segwit versioning will handle that already; but maybe
it would also be a good idea to also have "S" include a version, that
could be bumped to add new features to script, but left hidden within
the hash so that the fact you're using new (or old) features is only
revealed when it has to be.
Those nits aside, this seems great.
Cheers,
aj
next prev parent reply other threads:[~2018-01-23 7:26 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-23 0:30 Gregory Maxwell
2018-01-23 1:55 ` Chris Belcher
2018-01-23 2:51 ` Matt Corallo
2018-01-23 14:39 ` Mark Friedenbach
2018-01-23 21:23 ` Matt Corallo
2018-01-23 21:38 ` Gregory Maxwell
2018-01-23 6:44 ` Anthony Towns [this message]
2018-01-23 13:15 ` Gregory Maxwell
2018-01-23 22:22 ` Anthony Towns
2018-01-23 22:45 ` Gregory Maxwell
2018-01-24 1:52 ` Andrew Poelstra
2018-01-24 9:28 ` Tim Ruffing
2018-01-24 12:51 ` Natanael
2018-01-24 15:38 ` Tim Ruffing
2018-01-24 18:51 ` Natanael
2018-01-24 23:22 ` Tim Ruffing
2018-01-25 0:09 ` Natanael
2018-01-26 13:14 ` [bitcoin-dev] Recovery of old UTXOs in a post-quantum world Tim Ruffing
2018-01-27 17:07 ` [bitcoin-dev] Taproot: Privacy preserving switchable scripting Russell O'Connor
2018-01-27 17:23 ` Matt Corallo
2018-01-23 15:43 ` Greg Sanders
2018-01-26 21:34 ` Gregory Maxwell
2018-07-13 1:51 ` [bitcoin-dev] Generalised taproot Anthony Towns
2018-10-24 2:22 ` Pieter Wuille
2018-02-05 9:27 ` [bitcoin-dev] Taproot: Privacy preserving switchable scripting 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=20180123064419.GA1296@erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=greg@xiph$(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