📅 Original date posted:2021-03-15
📝 Original message:On Tue, 16 Mar 2021 at 09:05, Matt Corallo via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> There have been many threads on this before, I'm not sure anything new has
> been brought up here.
>
> Matt
>
> On 3/15/21 17:48, Luke Dashjr via bitcoin-dev wrote:
> > I do not personally see this as a reason to NACK Taproot, but it has
> become
> > clear to me over the past week or so that many others are unaware of this
> > tradeoff, so I am sharing it here to ensure the wider community is aware
> of
> > it and can make their own judgements.
>
> Note that this is most definitely *not* news to this list, eg, Anthony
> brought it up in "Schnorr and taproot (etc)
> upgrade" and there was a whole thread on it in "Taproot: Privacy
> preserving switchable scripting". This issue has been
> beaten to death, I'm not sure why we need to keep hitting the poor horse
> corpse.
>
>
I read through this thread just now. The QC discussion starts roughly here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015620.html
My own (very possibly wrong) interpretation of the situation is:
1. Current addresses are very vulnerable to QC and would require hardfork
to fix (and not fix particularly well).
2. Once a QC resistant spending procedure has been developed it could be
added as a backup spending policy as a new tapleaf version (wallets would
have to opt into it).
3. If QC does get to the point where it can break ECC then we can disable
key-path spends via softfork
4. If everyone has moved their coins to Taproot addresses with a QC
resistant tapleaf backup then we're ok.
5. Since the above is almost certainly not going to happen we can simply
congratulate the new QC owners on the Bitcoin they take from old addresses
(specter of QC encourages moving to taproot which could be thought of as a
good thing).
6. Otherwise we have to hard fork to stop old addresses being spent without
a quantum resistant ZKP (oof!).
7. Once we know what we're up against a new quantum resistant segwit
version can be introduced (if it hasn't already).
8. If QC develop far enough to degrade SHA256 sufficiently (ECC probably
breaks first) then that's a whole other ball game since it affects PoW and
txids and so on and will likely require a hard fork.
The ordering of the above events is not predictable. IMO Mark's post is on
the wildly optimistic side of projected rate of progress from my limited
understanding. Either way it is strictly better to enter a QC world with
Taproot enabled and most people are using it so we can introduce QC
resistant backup spend paths without hardforks before they become
practical. Depending on what happens they may not be needed but it's good
to have the option.
On Tue, 16 Mar 2021 at 10:11, Karl-Johan Alm via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Tue, 16 Mar 2021 at 07:48, Matt Corallo via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > Overall, the tradeoffs here seem ludicrous, given that any QC issues in
> Bitcoin need to be solved in another way, and
> > can't practically be solved by just relying on the existing hash
> indirection.
>
> The important distinction here is that, with hashes, an attacker has
> to race against the spending transaction confirming, whereas with
> naked pubkeys, the attacker doesn't have to wait for a spend to occur,
> drastically increasing the available time to attack.
>
>
First note that I am enthusiastically ignorant of QC technology so please
take the following with a bowl of salt.
The premise of Mark's post is that QC progress is currently exponential
(debatable) and will continue to be (unknowable) so "months" will turn into
days and into minutes in short time period. Since QC progress is
exponential and the speedup that ECC quantum algorithms offer is
exponential you're not dealing with the typical "Moore's law" progress in
terms of time to solve a particular problem; It's like exponential
exponential (math person help me now). You could easily go from ten
thousand years to break ECC to a few seconds within a year with that rate
of progress so I don't think "slow quantum" is an adversary worth
protecting against. I would love to know if I am wrong on this point.
Cheers,
LL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210316/62c7381f/attachment.html>;
Lloyd Fournier [ARCHIVE] /
npub1kh…y05yp
2023-06-07 18:30:53
in reply to nevent1q…ea7z
Author Public Key
npub1khlhcuz0jrjwa0ayznq2q9agg4zvxfvx5x7jljrvwnpfzngrcf0q7y05ypPublished at
2023-06-07 18:30:53Event JSON
{
"id": "4b90ad008656e543b050fe165bef9fa77c34397cbf4c8d0a174e50c5f134dac8",
"pubkey": "b5ff7c704f90e4eebfa414c0a017a84544c32586a1bd2fc86c74c2914d03c25e",
"created_at": 1686162653,
"kind": 1,
"tags": [
[
"e",
"a234deec8deaa4b2f960309b1c4b9227805148596a77c14f96fdcb654e31f3ba",
"",
"root"
],
[
"e",
"d073fce21dbbd1163909fedf0c676f2a61e4a770f0a6baa4b6831dfb405ccde3",
"",
"reply"
],
[
"p",
"cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba"
]
],
"content": "📅 Original date posted:2021-03-15\n📝 Original message:On Tue, 16 Mar 2021 at 09:05, Matt Corallo via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e There have been many threads on this before, I'm not sure anything new has\n\u003e been brought up here.\n\u003e\n\u003e Matt\n\u003e\n\u003e On 3/15/21 17:48, Luke Dashjr via bitcoin-dev wrote:\n\u003e \u003e I do not personally see this as a reason to NACK Taproot, but it has\n\u003e become\n\u003e \u003e clear to me over the past week or so that many others are unaware of this\n\u003e \u003e tradeoff, so I am sharing it here to ensure the wider community is aware\n\u003e of\n\u003e \u003e it and can make their own judgements.\n\u003e\n\u003e Note that this is most definitely *not* news to this list, eg, Anthony\n\u003e brought it up in \"Schnorr and taproot (etc)\n\u003e upgrade\" and there was a whole thread on it in \"Taproot: Privacy\n\u003e preserving switchable scripting\". This issue has been\n\u003e beaten to death, I'm not sure why we need to keep hitting the poor horse\n\u003e corpse.\n\u003e\n\u003e\nI read through this thread just now. The QC discussion starts roughly here:\nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015620.html\n\nMy own (very possibly wrong) interpretation of the situation is:\n\n1. Current addresses are very vulnerable to QC and would require hardfork\nto fix (and not fix particularly well).\n2. Once a QC resistant spending procedure has been developed it could be\nadded as a backup spending policy as a new tapleaf version (wallets would\nhave to opt into it).\n3. If QC does get to the point where it can break ECC then we can disable\nkey-path spends via softfork\n4. If everyone has moved their coins to Taproot addresses with a QC\nresistant tapleaf backup then we're ok.\n5. Since the above is almost certainly not going to happen we can simply\ncongratulate the new QC owners on the Bitcoin they take from old addresses\n(specter of QC encourages moving to taproot which could be thought of as a\ngood thing).\n6. Otherwise we have to hard fork to stop old addresses being spent without\na quantum resistant ZKP (oof!).\n7. Once we know what we're up against a new quantum resistant segwit\nversion can be introduced (if it hasn't already).\n8. If QC develop far enough to degrade SHA256 sufficiently (ECC probably\nbreaks first) then that's a whole other ball game since it affects PoW and\ntxids and so on and will likely require a hard fork.\n\nThe ordering of the above events is not predictable. IMO Mark's post is on\nthe wildly optimistic side of projected rate of progress from my limited\nunderstanding. Either way it is strictly better to enter a QC world with\nTaproot enabled and most people are using it so we can introduce QC\nresistant backup spend paths without hardforks before they become\npractical. Depending on what happens they may not be needed but it's good\nto have the option.\n\nOn Tue, 16 Mar 2021 at 10:11, Karl-Johan Alm via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On Tue, 16 Mar 2021 at 07:48, Matt Corallo via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e\n\u003e \u003e Overall, the tradeoffs here seem ludicrous, given that any QC issues in\n\u003e Bitcoin need to be solved in another way, and\n\u003e \u003e can't practically be solved by just relying on the existing hash\n\u003e indirection.\n\u003e\n\u003e The important distinction here is that, with hashes, an attacker has\n\u003e to race against the spending transaction confirming, whereas with\n\u003e naked pubkeys, the attacker doesn't have to wait for a spend to occur,\n\u003e drastically increasing the available time to attack.\n\u003e\n\u003e\nFirst note that I am enthusiastically ignorant of QC technology so please\ntake the following with a bowl of salt.\nThe premise of Mark's post is that QC progress is currently exponential\n(debatable) and will continue to be (unknowable) so \"months\" will turn into\ndays and into minutes in short time period. Since QC progress is\nexponential and the speedup that ECC quantum algorithms offer is\nexponential you're not dealing with the typical \"Moore's law\" progress in\nterms of time to solve a particular problem; It's like exponential\nexponential (math person help me now). You could easily go from ten\nthousand years to break ECC to a few seconds within a year with that rate\nof progress so I don't think \"slow quantum\" is an adversary worth\nprotecting against. I would love to know if I am wrong on this point.\n\nCheers,\n\nLL\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210316/62c7381f/attachment.html\u003e",
"sig": "5b8965f1233a667adf998ad4b16e1ef720687f303477aeecd48ec003025628e6a6b2818e705c8c4f64f10d8eddbfb3e6ce38f97c19a56d1e2a79ba3dc2cc4027"
}