📅 Original date posted:2021-03-23
📝 Original message:Erik,
> Does anyone think it would it be useful to write up a more official,
and even partly functional plan for Bitcoin to use zero-knowledge
proofs to transition to quantum resistance?
yes, this would be appreciated very much! Andrew Chow's write-up
gives already some high-level idea, but a more detailed exposition
would be essential for further discussion.
thank you,
Martin
On Mon, Mar 22, 2021 at 3:47 PM Erik Aronesty via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> The argument that hashed public addresses provide meaningful quantum
> resistance is flawed *when considered in the context*.of Bitcoin
> itself.
>
> This article by Andrew Chow is easy to read and makes a strong case
> against the quantum utility of hashed public keys:
>
> https://cryptowords.github.io/why-does-hashing-public-keys-not-actually-provide-any-quantum-resistance
>
> And then, of course, one should be mindful of the case against quantum
> computing itself - it is neither inevitable nor "just around the
> corner". Mikhail Dyakonov summarized the arguments well here:
> https://t.co/cgrfrroTTT?amp=1.
>
> My current stance (at my company at least) is that planning for
> quantum computing should be limited to "a provable and written ability
> to upgrade if it becomes clear that it's necessary."
>
> Does anyone think it would it be useful to write up a more official,
> and even partly functional plan for Bitcoin to use zero-knowledge
> proofs to transition to quantum resistance?
>
> - Erik Aronesty
> CTO, Atkama
>
> On Mon, Mar 15, 2021 at 5:48 PM Luke Dashjr via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> 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.
> >
> > Mark Friedenbach explains on his blog:
> > https://freicoin.substack.com/p/why-im-against-taproot
> >
> > In short, Taproot loses an important safety protection against quantum.
> > Note that in all circumstances, Bitcoin is endangered when QC becomes a
> > reality, but pre-Taproot, it is possible for the network to "pause"
> while a
> > full quantum-safe fix is developed, and then resume transacting. With
> Taproot
> > as-is, it could very well become an unrecoverable situation if QC go
> online
> > prior to having a full quantum-safe solution.
> >
> > Also, what I didn't know myself until today, is that we do not actually
> gain
> > anything from this: the features proposed to make use of the raw keys
> being
> > public prior to spending can be implemented with hashed keys as well.
> > It would use significantly more CPU time and bandwidth (between private
> > parties, not on-chain), but there should be no shortage of that for
> anyone
> > running a full node (indeed, CPU time is freed up by Taproot!); at
> worst, it
> > would create an incentive for more people to use their own full node,
> which
> > is a good thing!
> >
> > Despite this, I still don't think it's a reason to NACK Taproot: it
> should be
> > fairly trivial to add a hash on top in an additional softfork and fix
> this.
> >
> > In addition to the points made by Mark, I also want to add two more, in
> > response to Pieter's "you can't claim much security if 37% of the supply
> is
> > at risk" argument. This argument is based in part on the fact that many
> > people reuse Bitcoin invoice addresses.
> >
> > First, so long as we have hash-based addresses as a best practice, we can
> > continue to shrink the percentage of bitcoins affected through social
> efforts
> > discouraging address use. If the standard loses the hash, the situation
> > cannot be improved, and will indeed only get worse.
> >
> > Second, when/if quantum does compromise these coins, so long as they are
> > neglected or abandoned/lost coins (inherent in the current model), it
> can be
> > seen as equivalent to Bitcoin mining. At the end of the day, 37% of
> supply
> > minable by QCs is really no different than 37% minable by ASICs. (We've
> seen
> > far higher %s available for mining obviously.)
> >
> > To conclude, I recommend anyone using Bitcoin to read Mark's article, my
> > thoughts, and any other arguments on the topic; decide if this is a
> concern
> > to you, and make your own post(s) accordingly. Mark has conceded the
> argument
> > (AFAIK he doesn't have an interest in bitcoins anyway), and I do not
> consider
> > it a showstopper - so if anyone else out there does, please make yourself
> > known ASAP since Taproot has already moved on to the activation phase
> and it
> > is likely software will be released within the next month or two as
> things
> > stand.
> >
> > Luke
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210323/d5592b95/attachment-0001.html>;
Martin Schwarz [ARCHIVE] /
npub1c6…fz7ln
2023-06-07 18:30:57
in reply to nevent1q…fjet
Author Public Key
npub1c6ytpr5fshkjp2hptfqrvfxy6qkkcgre9fv9va8qyq7h4fs03ehs4fz7lnPublished at
2023-06-07 18:30:57Event JSON
{
"id": "d7af3a7f1175cd519f184fb63908499baf2dd3426df6ecf241689300204f1e2c",
"pubkey": "c688b08e8985ed20aae15a403624c4d02d6c20792a585674e0203d7aa60f8e6f",
"created_at": 1686162657,
"kind": 1,
"tags": [
[
"e",
"a234deec8deaa4b2f960309b1c4b9227805148596a77c14f96fdcb654e31f3ba",
"",
"root"
],
[
"e",
"dfee7ed0ca0444e8be2a05f892fe671fbb6394ab6f544c994005310854e2cee4",
"",
"reply"
],
[
"p",
"22944ce1e29904e3826d25013a614e4665693ec514003efacc1b7586e8e5d0aa"
]
],
"content": "📅 Original date posted:2021-03-23\n📝 Original message:Erik,\n\n\u003e Does anyone think it would it be useful to write up a more official,\nand even partly functional plan for Bitcoin to use zero-knowledge\nproofs to transition to quantum resistance?\n\nyes, this would be appreciated very much! Andrew Chow's write-up\ngives already some high-level idea, but a more detailed exposition\nwould be essential for further discussion.\n\nthank you,\nMartin\n\nOn Mon, Mar 22, 2021 at 3:47 PM Erik Aronesty via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e The argument that hashed public addresses provide meaningful quantum\n\u003e resistance is flawed *when considered in the context*.of Bitcoin\n\u003e itself.\n\u003e\n\u003e This article by Andrew Chow is easy to read and makes a strong case\n\u003e against the quantum utility of hashed public keys:\n\u003e\n\u003e https://cryptowords.github.io/why-does-hashing-public-keys-not-actually-provide-any-quantum-resistance\n\u003e\n\u003e And then, of course, one should be mindful of the case against quantum\n\u003e computing itself - it is neither inevitable nor \"just around the\n\u003e corner\". Mikhail Dyakonov summarized the arguments well here:\n\u003e https://t.co/cgrfrroTTT?amp=1.\n\u003e\n\u003e My current stance (at my company at least) is that planning for\n\u003e quantum computing should be limited to \"a provable and written ability\n\u003e to upgrade if it becomes clear that it's necessary.\"\n\u003e\n\u003e Does anyone think it would it be useful to write up a more official,\n\u003e and even partly functional plan for Bitcoin to use zero-knowledge\n\u003e proofs to transition to quantum resistance?\n\u003e\n\u003e - Erik Aronesty\n\u003e CTO, Atkama\n\u003e\n\u003e On Mon, Mar 15, 2021 at 5:48 PM Luke Dashjr via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e\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 \u003e\n\u003e \u003e Mark Friedenbach explains on his blog:\n\u003e \u003e https://freicoin.substack.com/p/why-im-against-taproot\n\u003e \u003e\n\u003e \u003e In short, Taproot loses an important safety protection against quantum.\n\u003e \u003e Note that in all circumstances, Bitcoin is endangered when QC becomes a\n\u003e \u003e reality, but pre-Taproot, it is possible for the network to \"pause\"\n\u003e while a\n\u003e \u003e full quantum-safe fix is developed, and then resume transacting. With\n\u003e Taproot\n\u003e \u003e as-is, it could very well become an unrecoverable situation if QC go\n\u003e online\n\u003e \u003e prior to having a full quantum-safe solution.\n\u003e \u003e\n\u003e \u003e Also, what I didn't know myself until today, is that we do not actually\n\u003e gain\n\u003e \u003e anything from this: the features proposed to make use of the raw keys\n\u003e being\n\u003e \u003e public prior to spending can be implemented with hashed keys as well.\n\u003e \u003e It would use significantly more CPU time and bandwidth (between private\n\u003e \u003e parties, not on-chain), but there should be no shortage of that for\n\u003e anyone\n\u003e \u003e running a full node (indeed, CPU time is freed up by Taproot!); at\n\u003e worst, it\n\u003e \u003e would create an incentive for more people to use their own full node,\n\u003e which\n\u003e \u003e is a good thing!\n\u003e \u003e\n\u003e \u003e Despite this, I still don't think it's a reason to NACK Taproot: it\n\u003e should be\n\u003e \u003e fairly trivial to add a hash on top in an additional softfork and fix\n\u003e this.\n\u003e \u003e\n\u003e \u003e In addition to the points made by Mark, I also want to add two more, in\n\u003e \u003e response to Pieter's \"you can't claim much security if 37% of the supply\n\u003e is\n\u003e \u003e at risk\" argument. This argument is based in part on the fact that many\n\u003e \u003e people reuse Bitcoin invoice addresses.\n\u003e \u003e\n\u003e \u003e First, so long as we have hash-based addresses as a best practice, we can\n\u003e \u003e continue to shrink the percentage of bitcoins affected through social\n\u003e efforts\n\u003e \u003e discouraging address use. If the standard loses the hash, the situation\n\u003e \u003e cannot be improved, and will indeed only get worse.\n\u003e \u003e\n\u003e \u003e Second, when/if quantum does compromise these coins, so long as they are\n\u003e \u003e neglected or abandoned/lost coins (inherent in the current model), it\n\u003e can be\n\u003e \u003e seen as equivalent to Bitcoin mining. At the end of the day, 37% of\n\u003e supply\n\u003e \u003e minable by QCs is really no different than 37% minable by ASICs. (We've\n\u003e seen\n\u003e \u003e far higher %s available for mining obviously.)\n\u003e \u003e\n\u003e \u003e To conclude, I recommend anyone using Bitcoin to read Mark's article, my\n\u003e \u003e thoughts, and any other arguments on the topic; decide if this is a\n\u003e concern\n\u003e \u003e to you, and make your own post(s) accordingly. Mark has conceded the\n\u003e argument\n\u003e \u003e (AFAIK he doesn't have an interest in bitcoins anyway), and I do not\n\u003e consider\n\u003e \u003e it a showstopper - so if anyone else out there does, please make yourself\n\u003e \u003e known ASAP since Taproot has already moved on to the activation phase\n\u003e and it\n\u003e \u003e is likely software will be released within the next month or two as\n\u003e things\n\u003e \u003e stand.\n\u003e \u003e\n\u003e \u003e Luke\n\u003e \u003e _______________________________________________\n\u003e \u003e bitcoin-dev mailing list\n\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210323/d5592b95/attachment-0001.html\u003e",
"sig": "ebd1ee61b526ae6bb801da855b9f559d1dfe186bf5b28b80d61a61c0e58b7263817ce5ed36c77fb578b21daee291d423dea9994c4842a676cc4dd9829198edf0"
}