📅 Original date posted:2018-01-23
📝 Original message: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
Anthony Towns [ARCHIVE] /
npub17r…x9l2h
2023-06-07 18:10:08
in reply to nevent1q…xnxu
Author Public Key
npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2hPublished at
2023-06-07 18:10:08Event JSON
{
"id": "048724c7ae1a711a13415d18cb90cade8ede9f5f74b606196ab1e545b9222857",
"pubkey": "f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab",
"created_at": 1686161408,
"kind": 1,
"tags": [
[
"e",
"3098b6cd22aeee78f0db7c45c94594dc578b6094452b2f8e3129789af2cd6fd4",
"",
"root"
],
[
"e",
"14bfb94ed79e882204b76807dc2bb4ae08d16fefc46bd0f67360e81cdd12b538",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "📅 Original date posted:2018-01-23\n📝 Original message:On Tue, Jan 23, 2018 at 12:30:06AM +0000, Gregory Maxwell via bitcoin-dev wrote:\n\u003e One point that comes up while talking about merkelized scripts is can\n\u003e we go about making fancier contract use cases as indistinguishable as\n\u003e possible from the most common and boring payments.\n\n\u003e Now we tweak C to produce P which is the key we'll publish: P = C + H(C||S)G.\n\u003e (This is the attack hardened pay-to-contract construction described in [2])\n\u003e Then we pay to a scriptPubKey of [Taproot supporting version] [EC point P].\n\nIs this really intended as paying directly to a pubkey, instead of a\npubkey hash?\n\nIf so, isn't that a step backwards with regard to resistance to quantum\nattacks against ECC?\n\nPaying direct to pubkey doesn't seem quite enough to make pay-to-taproot\ncheaper than p2wpkh: the extra 12 bytes in the scriptPubKey would need\nyou to reduce the witness by 48 bytes to maintain the weight, but I think\nyou'd only be saving 33 bytes by not having to reveal the pubkey, and\nanother 6-7 bytes by having a tighter signature encoding than DER. Still,\nthat's pretty close with a difference of only a couple of vbytes per\ninput by my count.\n\nIf it were \"pay-to-taproot-hash\", then presuming taproot hashes were 256\nbit, then p2wpkh would be a full 12 vbytes cheaper due to the shorter\nhash. That might make it hard to maximise the anonymity set. I suppose\na small penalty/discount could be added to align the economic incentives\nthough.\n\nI wonder how this interacts with segwit versioning. I think you'd want\nto have taproot be versioned overall so that you could cope with moving\nto a new signing method (different curve, or something non-ECC based)\neventually, and segwit versioning will handle that already; but maybe\nit would also be a good idea to also have \"S\" include a version, that\ncould be bumped to add new features to script, but left hidden within\nthe hash so that the fact you're using new (or old) features is only\nrevealed when it has to be.\n\nThose nits aside, this seems great.\n\nCheers,\naj",
"sig": "241f6ca10858a3b47724fc20b1f29c468ad0d746a6f30f0d9116cd6cbffb0df895659db9383948cdcb2142fd2420e81a9517b916e47c4aabc6ad42152880b4b2"
}