ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2021-03-16 📝 Original message:Good morning aj, > On Tue, ...
📅 Original date posted:2021-03-16
📝 Original message:Good morning aj,
> On Tue, Mar 16, 2021 at 08:01:47AM +0900, Karl-Johan Alm via bitcoin-dev wrote:
>
> > It may initially take months to break a single key.
>
> From what I understand, the constraint on using quantum techniques to
> break an ECC key is on the number of bits you can entangle and how long
> you can keep them coherent -- but those are both essentially thresholds:
> you can't use two quantum computers that support a lower number of bits
> when you need a higher number, and you can't reuse the state you reached
> after you collapsed halfway through to make the next run shorter.
>
> I think that means having a break take a longer time means maintaining
> the quantum state for longer, which is harder than having it happen
> quicker...
>
> So I think the only way you get it taking substantial amounts of time to
> break a key is if your quantum attack works quickly but very unreliably:
> maybe it takes a minute to reset, and every attempt only has probability
> p of succeeding (ie, random probability of managing to maintain the
> quantum state until completion of the dlog algorithm), so over t minutes
> you end up with probability 1-(1-p)^t of success.
>
> For 50% odds after 1 month with 1 minute per attempt, you'd need a 0.0016%
> chance per attempt, for 50% odds after 1 day, you'd need 0.048% chance per
> attempt. But those odds assume you've only got one QC making the attempts
> -- if you've got 30, you can make a month's worth of attempts in a day;
> if you scale up to 720, you can make a month's worth of attempts in an
> hour, ie once you've got one, it's a fairly straightforward engineering
> challenge at that point.
>
> So a "slow" attack simply doesn't seem likely to me. YMMV, obviously.
What you describe seems to match mining in its behavior: probabilistic, and scalable by pushing more electricity into more devices.
>From this point-of-view, it seems to me that the amount of energy to mount a "fast" attack may eventually approach the energy required by mining, in which case someone who possesses the ability to mount such an attack may very well find it easier to just 51% the network (since that can be done today without having to pour R&D satoshis into developing practical quantum computers).
Regards,
ZmnSCPxj
Published at
2023-06-07 18:30:53Event JSON
{
"id": "4ed1c1ad0f02264d60cf54609d577c3e522c622c70af5657fafd3167d04972d9",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686162653,
"kind": 1,
"tags": [
[
"e",
"a234deec8deaa4b2f960309b1c4b9227805148596a77c14f96fdcb654e31f3ba",
"",
"root"
],
[
"e",
"fdf98ea71456f33cce689d9436c22a55058782ff8f5948bd8b34aea2d06212ac",
"",
"reply"
],
[
"p",
"f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab"
]
],
"content": "📅 Original date posted:2021-03-16\n📝 Original message:Good morning aj,\n\n\u003e On Tue, Mar 16, 2021 at 08:01:47AM +0900, Karl-Johan Alm via bitcoin-dev wrote:\n\u003e\n\u003e \u003e It may initially take months to break a single key.\n\u003e\n\u003e From what I understand, the constraint on using quantum techniques to\n\u003e break an ECC key is on the number of bits you can entangle and how long\n\u003e you can keep them coherent -- but those are both essentially thresholds:\n\u003e you can't use two quantum computers that support a lower number of bits\n\u003e when you need a higher number, and you can't reuse the state you reached\n\u003e after you collapsed halfway through to make the next run shorter.\n\u003e\n\u003e I think that means having a break take a longer time means maintaining\n\u003e the quantum state for longer, which is harder than having it happen\n\u003e quicker...\n\u003e\n\u003e So I think the only way you get it taking substantial amounts of time to\n\u003e break a key is if your quantum attack works quickly but very unreliably:\n\u003e maybe it takes a minute to reset, and every attempt only has probability\n\u003e p of succeeding (ie, random probability of managing to maintain the\n\u003e quantum state until completion of the dlog algorithm), so over t minutes\n\u003e you end up with probability 1-(1-p)^t of success.\n\u003e\n\u003e For 50% odds after 1 month with 1 minute per attempt, you'd need a 0.0016%\n\u003e chance per attempt, for 50% odds after 1 day, you'd need 0.048% chance per\n\u003e attempt. But those odds assume you've only got one QC making the attempts\n\u003e -- if you've got 30, you can make a month's worth of attempts in a day;\n\u003e if you scale up to 720, you can make a month's worth of attempts in an\n\u003e hour, ie once you've got one, it's a fairly straightforward engineering\n\u003e challenge at that point.\n\u003e\n\u003e So a \"slow\" attack simply doesn't seem likely to me. YMMV, obviously.\n\nWhat you describe seems to match mining in its behavior: probabilistic, and scalable by pushing more electricity into more devices.\n\n\u003eFrom this point-of-view, it seems to me that the amount of energy to mount a \"fast\" attack may eventually approach the energy required by mining, in which case someone who possesses the ability to mount such an attack may very well find it easier to just 51% the network (since that can be done today without having to pour R\u0026D satoshis into developing practical quantum computers).\n\nRegards,\nZmnSCPxj",
"sig": "6d89c0add93f6567d56efa479243436f8183f39c3c453da1e23b09f27ae3a6d895b88a0d09593aa5845b85a9a242ec593d5a17a5bca37415d63e0a3c3177bd23"
}