Re: [bitcoindev] Weak Quantum Bounty Ceremony

[Garlo Nicon <garlonicon@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5182 bytes --]

I think I saw a similar topic on Delving:
https://delvingbitcoin.org/t/qcap-a-bitcoin-native-quantum-canary-alert/2498

> and intentionally limited to 160 bits of entropy

If you need 160-bit keys, then I think you can use secp160k1. As I said,
there are four curves with similar properties: secp160k1, secp192k1,
secp224k1, and secp256k1. Also, because the half of the generator in
secp224k1 and secp256k1 is identical, it could make them easier to connect.

> After the transcript is finalized, participants destroy their secret
shares and temporary randomness.

Well, we have some existing puzzle, where it was not done, but other than
that, it looks exactly like you described. Also, the missing part here is
proving, that private keys are in a given range:
https://mempool.space/tx/08389f34c98c606322740c0be6a7125d9860bb8d5cb182c02f98461e5fa6cd15

I guess your puzzle would be similar to that, but would also contain some
proofs, that private keys are really placed in a proper range.

> whether there are cleaner constructions

I wonder, if grinding some bits of x-value on secp256k1 has a similar
difficulty, as finding the N-bit private key. Because in that case, it
could be checked by OP_SIZE instead. And for that cases, we already have
some puzzle:
https://mempool.space/tx/aba3c2ae442aa20150996ee68f9aa4da83b57a4312891078be0c2e68c50b2801

Then, if OP_CHECKSIG would be completely broken, we would see 9-byte DER
signatures. But if only secp256k1 would be, without breaking SHA-256, then
we would have one-byte r-value, and then grinded s-value, which would mean
40-byte or smaller DER signatures.

sob., 30 maj 2026 o 21:30 Erik Aronesty <erik@q32.com> napisał(a):

> >  If the network is not updated to be post-quantum, the attackers can
> just go for the funds elsewhere
>
> .This assumes that quantum computing speedup for classical computing is
> feasible and finite-energy for classically interprable results, which has
> not been proven or demonstrated
>
> > The counterargument is that a discovery can be made by a lab that’s not
> interested in stealing.
>
> Yes, and this bounty would not be stealing, so labs can freely do this
> legally.
>
> >  The bounty is already there, it’s the network itself, pre- or
> post-quantum.
>
> This is a canary bounty with a weaker key, presumably it will be unlocked
> at least a few months in advance of any needed emergency upgrades, should
> they ever prove necessary.
>
>
> On Sat, May 30, 2026 at 12:18 PM Nikita Karetnikov <nikita@karetnikov.org>
> wrote:
>
>> Dear Erik,
>>
>> The bounty idea has been discussed recently in “What if we let Quantum
>> Hunters get Bitcoin rewards ?”
>> I’ve also seen it mentioned elsewhere.
>>
>> Before going into the implementation, let’s discuss the concept.
>> I don’t understand what problem is being solved by the bounty.
>> To me it serves no purpose.
>>
>> If the network is not updated to be post-quantum, the attackers can just
>> go for the funds elsewhere.
>> The counterargument is that a discovery can be made by a lab that’s not
>> interested in stealing.
>> What is the bounty for in that case?
>> The researchers are primarily motivated by producing novel results.
>> They already receive salary and the companies working on this have
>> funding.
>> This also assumes that the lab would be allowed to publish this result
>> publicly.
>> They would have other means to demonstrate their discovery as well.
>> Why would you optimize for this very specific use case?
>>
>> And if the network is updated to be post-quantum, the PQ bounty has no
>> purpose.
>>
>> The bounty is already there, it’s the network itself, pre- or
>> post-quantum.
>>
>> Thanks,
>> Nikita
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Bitcoin Development Mailing List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to bitcoindev+unsubscribe@googlegroups.com.
>> To view this discussion visit
>> https://groups.google.com/d/msgid/bitcoindev/28eeaa8b-dc19-463f-882f-1ed69c4c9037%40app.fastmail.com
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/CAJowKgJZk%3Dc17stAtWxa%3Dh1fAhZL4YfvbbAY%2Bgo32wmDKffNzQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/bitcoindev/CAJowKgJZk%3Dc17stAtWxa%3Dh1fAhZL4YfvbbAY%2Bgo32wmDKffNzQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAN7kyNggyHQ6SNmrDqdZg9R8FgP6-5ia0eQhPbAaQCte6PzXUA%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 6703 bytes --]