📅 Original date posted:2018-01-23
📝 Original message:On Tue, Jan 23, 2018 at 6:44 AM, Anthony Towns <aj at erisian.com.au> wrote:
> 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?
You're reading too much into a description of the idea. It's not a BIP
or a spec; I tried to provide enough details to make the general idea
concrete. I didn't dive into details or optimizations (for example,
you can use this with a "no EC redemption path" by special casing
empty C as the point at infinity, and you'd have an output that was
indistinguishable until spend... yadda yadda).
Considering the considerable level of address reuse -- I recall prior
stats that a majority of circulating funds are on addresses that had
previously been used, on top of the general race limitations-- I am
now dubious to the idea that hashing provides any kind of meaningful
quantum resistance and somewhat regret introducing that meme to the
space in the first place. If we considered quantum resistance a
meaningful concern we should address that specifically. --- so I
don't think that should be a factor that drives a decision here.
When collision resistance is needed (as I think it clearly is for
taproot) you don't get a space savings in the txout from hashing, so
there is an argument to use the public key directly at least... but
it's worth considering. Direct SPK use is also adventitious for being
able to efficiently ZKP over the UTXO set, e.g. for private solvency
proofs, but it isn't absolutely mandatory for that (one can hash
inside the proof, but it's slower).
Gregory Maxwell [ARCHIVE] /
npub1f2…crwet
2023-06-07 18:10:08
in reply to nevent1q…09dn
Author Public Key
npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetPublished at
2023-06-07 18:10:08Event JSON
{
"id": "2f8ec0c772de0284b977c10b97a5836a8824735b8687f7e180f5d2cd5b181547",
"pubkey": "4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73",
"created_at": 1686161408,
"kind": 1,
"tags": [
[
"e",
"3098b6cd22aeee78f0db7c45c94594dc578b6094452b2f8e3129789af2cd6fd4",
"",
"root"
],
[
"e",
"048724c7ae1a711a13415d18cb90cade8ede9f5f74b606196ab1e545b9222857",
"",
"reply"
],
[
"p",
"f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab"
]
],
"content": "📅 Original date posted:2018-01-23\n📝 Original message:On Tue, Jan 23, 2018 at 6:44 AM, Anthony Towns \u003caj at erisian.com.au\u003e wrote:\n\u003e Is this really intended as paying directly to a pubkey, instead of a\n\u003e pubkey hash?\n\u003e\n\u003e If so, isn't that a step backwards with regard to resistance to quantum\n\u003e attacks against ECC?\n\nYou're reading too much into a description of the idea. It's not a BIP\nor a spec; I tried to provide enough details to make the general idea\nconcrete. I didn't dive into details or optimizations (for example,\nyou can use this with a \"no EC redemption path\" by special casing\nempty C as the point at infinity, and you'd have an output that was\nindistinguishable until spend... yadda yadda).\n\nConsidering the considerable level of address reuse -- I recall prior\nstats that a majority of circulating funds are on addresses that had\npreviously been used, on top of the general race limitations-- I am\nnow dubious to the idea that hashing provides any kind of meaningful\nquantum resistance and somewhat regret introducing that meme to the\nspace in the first place. If we considered quantum resistance a\nmeaningful concern we should address that specifically. --- so I\ndon't think that should be a factor that drives a decision here.\n\nWhen collision resistance is needed (as I think it clearly is for\ntaproot) you don't get a space savings in the txout from hashing, so\nthere is an argument to use the public key directly at least... but\nit's worth considering. Direct SPK use is also adventitious for being\nable to efficiently ZKP over the UTXO set, e.g. for private solvency\nproofs, but it isn't absolutely mandatory for that (one can hash\ninside the proof, but it's slower).",
"sig": "a08fb69585c7ad87ea981091d93940832e529ddecd4ba41e728f38b6c4f3282dcaaf329b109de30d5ea62b36e40b72560c08611600c9bf493527a6253a768436"
}