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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
