* [bitcoindev] Weak Quantum Bounty Ceremony
@ 2026-05-30 17:01 Erik Aronesty
2026-05-30 19:11 ` Nikita Karetnikov
2026-05-31 6:22 ` Nagaev Boris
0 siblings, 2 replies; 6+ messages in thread
From: Erik Aronesty @ 2026-05-30 17:01 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 2844 bytes --]
I have been thinking about a way to create publicly verifiable Bitcoin
outputs whose recovery is intentionally tied to breaking a weaker
cryptographic system.
The goal is to create a "quantum bounty." The output would be spendable by
a valid secp256k1 private key, but the key would be generated in a public
ceremony and intentionally limited to 160 bits of entropy. Recovery would
additionally be facilitated by publishing an encryption of the same secret
under a weaker elliptic curve system.
The basic idea is that a group of independent participants runs a
distributed key generation ceremony. Each participant contributes a secret
share. The shares are combined into a single 160-bit scalar x. At no point
is x reconstructed on any machine or revealed to any participant.
From the same distributed shares, participants jointly derive:
1. A Bitcoin public key P = xG on secp256k1.
2. An encryption of x under a separate 160-bit elliptic curve system.
The transcript contains all commitments, public contributions, ciphertext
contributions, and equality-of-discrete-log proofs needed to verify that
both constructions are derived from the same hidden scalar.
The construction does not require SNARKs or any trusted setup. It appears
sufficient to use Pedersen-style commitments, ElGamal-style encryption, and
Chaum-Pedersen proofs showing consistency between participant contributions
across the two groups.
After the transcript is finalized, participants destroy their secret shares
and temporary randomness. Assuming at least one participant behaves
honestly and destroys their material, the scalar x is no longer known to
anyone.
The final artifact consists of:
* A Bitcoin public key P.
* A weak-curve ciphertext C.
* A complete public transcript proving that P and C were derived from the
same hidden scalar.
Bitcoin can then be sent to the address corresponding to P.
Anyone who can recover x from the weak cryptosystem can spend the output.
The effective security of the bounty is therefore determined by the weaker
curve rather than by the full secp256k1 discrete logarithm problem.
The intended purpose is to create a publicly auditable cryptographic canary
target.
One question I have not fully resolved is whether there are cleaner
constructions for the recoverable encryption component than ElGamal-style
encryption, while still preserving simple transcript verification and
avoiding general-purpose zero-knowledge systems.
--
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/CAJowKgJVwmm%3Dh6AsO4zeGTmfdK-RUQiDsMJkMRd6WZSo5FjeZg%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 3840 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoindev] Weak Quantum Bounty Ceremony
2026-05-30 17:01 [bitcoindev] Weak Quantum Bounty Ceremony Erik Aronesty
@ 2026-05-30 19:11 ` Nikita Karetnikov
2026-05-30 19:28 ` Erik Aronesty
2026-05-31 6:22 ` Nagaev Boris
1 sibling, 1 reply; 6+ messages in thread
From: Nikita Karetnikov @ 2026-05-30 19:11 UTC (permalink / raw)
To: bitcoindev
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoindev] Weak Quantum Bounty Ceremony
2026-05-30 19:11 ` Nikita Karetnikov
@ 2026-05-30 19:28 ` Erik Aronesty
2026-05-31 5:03 ` Garlo Nicon
0 siblings, 1 reply; 6+ messages in thread
From: Erik Aronesty @ 2026-05-30 19:28 UTC (permalink / raw)
To: Nikita Karetnikov; +Cc: bitcoindev
[-- Attachment #1: Type: text/plain, Size: 2803 bytes --]
> 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.
[-- Attachment #2: Type: text/html, Size: 3686 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoindev] Weak Quantum Bounty Ceremony
2026-05-30 19:28 ` Erik Aronesty
@ 2026-05-31 5:03 ` Garlo Nicon
0 siblings, 0 replies; 6+ messages in thread
From: Garlo Nicon @ 2026-05-31 5:03 UTC (permalink / raw)
To: Erik Aronesty; +Cc: Nikita Karetnikov, bitcoindev
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoindev] Weak Quantum Bounty Ceremony
2026-05-30 17:01 [bitcoindev] Weak Quantum Bounty Ceremony Erik Aronesty
2026-05-30 19:11 ` Nikita Karetnikov
@ 2026-05-31 6:22 ` Nagaev Boris
2026-06-05 23:46 ` 'conduition' via Bitcoin Development Mailing List
1 sibling, 1 reply; 6+ messages in thread
From: Nagaev Boris @ 2026-05-31 6:22 UTC (permalink / raw)
To: Erik Aronesty; +Cc: Bitcoin Development Mailing List
Hey Erik,
The scheme is interesting! I want to add my two cents.
Those not motivated by funds could publish a zero knowledge proof
instead of moving the funds. This means real funds are not even needed
in this case. Or the whole scheme can be deployed to testnet or signet
not to waste (or burn?) real coins.
Also I would like to propose some properties which the publishing
scheme should have to maximize the effect:
- anonymous for the publisher
- plausible deniable for the publisher
- uncensorable
For the plausible deniability thing, imagine a researcher who has
access to a particular signature made by quantum computer and can
prove it, but then it will be clear who leaked it, because the
signature has a unique nonce. This is where ZK can help. But how to do
ZK onchain to get censorship resistance? Maybe some BitVM construction
may help.
Using mainnet provides better censorship resistance than testnet or
signet - that is actually a good reason to use mainnet unless we come
up with a better approach.
Best,
Boris
On Sat, May 30, 2026 at 12:58 PM Erik Aronesty <erik@q32.com> wrote:
>
> I have been thinking about a way to create publicly verifiable Bitcoin outputs whose recovery is intentionally tied to breaking a weaker cryptographic system.
>
> The goal is to create a "quantum bounty." The output would be spendable by a valid secp256k1 private key, but the key would be generated in a public ceremony and intentionally limited to 160 bits of entropy. Recovery would additionally be facilitated by publishing an encryption of the same secret under a weaker elliptic curve system.
>
> The basic idea is that a group of independent participants runs a distributed key generation ceremony. Each participant contributes a secret share. The shares are combined into a single 160-bit scalar x. At no point is x reconstructed on any machine or revealed to any participant.
>
> From the same distributed shares, participants jointly derive:
>
> 1. A Bitcoin public key P = xG on secp256k1.
> 2. An encryption of x under a separate 160-bit elliptic curve system.
>
> The transcript contains all commitments, public contributions, ciphertext contributions, and equality-of-discrete-log proofs needed to verify that both constructions are derived from the same hidden scalar.
>
> The construction does not require SNARKs or any trusted setup. It appears sufficient to use Pedersen-style commitments, ElGamal-style encryption, and Chaum-Pedersen proofs showing consistency between participant contributions across the two groups.
>
> After the transcript is finalized, participants destroy their secret shares and temporary randomness. Assuming at least one participant behaves honestly and destroys their material, the scalar x is no longer known to anyone.
>
> The final artifact consists of:
>
> * A Bitcoin public key P.
> * A weak-curve ciphertext C.
> * A complete public transcript proving that P and C were derived from the same hidden scalar.
>
> Bitcoin can then be sent to the address corresponding to P.
>
> Anyone who can recover x from the weak cryptosystem can spend the output. The effective security of the bounty is therefore determined by the weaker curve rather than by the full secp256k1 discrete logarithm problem.
>
> The intended purpose is to create a publicly auditable cryptographic canary target.
>
> One question I have not fully resolved is whether there are cleaner constructions for the recoverable encryption component than ElGamal-style encryption, while still preserving simple transcript verification and avoiding general-purpose zero-knowledge systems.
>
> --
> 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/CAJowKgJVwmm%3Dh6AsO4zeGTmfdK-RUQiDsMJkMRd6WZSo5FjeZg%40mail.gmail.com.
--
Best regards,
Boris Nagaev
--
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/CAFC_Vt7DLZEytF72Q0EVPeg6iED3qztMXs7aX6zBNBQ5%2B-ceXA%40mail.gmail.com.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoindev] Weak Quantum Bounty Ceremony
2026-05-31 6:22 ` Nagaev Boris
@ 2026-06-05 23:46 ` 'conduition' via Bitcoin Development Mailing List
0 siblings, 0 replies; 6+ messages in thread
From: 'conduition' via Bitcoin Development Mailing List @ 2026-06-05 23:46 UTC (permalink / raw)
To: Nagaev Boris; +Cc: Erik Aronesty, Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 6388 bytes --]
Hey guys,
> Those not motivated by funds could publish a zero knowledge proof instead of moving the funds. This means real funds are not even needed in this case.
Why stop there? If the quantum adversary is willing to cooperate in convincing people of their capabilities, just ask them to find the discrete log of a NUMS point on some curve. Then we don't even need ZK machinery.
Informally: Given scalar k and preimage x, the verifier checks K = k*G = HashToCurve(x).
As stated this would permit a classical prover who finds a collision over all (x, k) pairs, which would be feasible for a 160-bit curve. To rule out collision attacks, we fix x as a constant as a part of the proof system.
This would all be off-chain, no BIPs or UTXOs needed.
If the quantum adversary demands payment to provide this proof, then one can use ZKCPs [1] [2]. But personally I think this would be an implausible scenario. A self-interested QC would bide their time and steal coins once they can factor secp256k1 keys.
regards,
conduition
[1]: https://en.bitcoin.it/wiki/Zero_Knowledge_Contingent_Payment
[2]: https://conduition.io/bitcoin/zkpreimage/
On Sunday, May 31st, 2026 at 3:40 AM, Nagaev Boris <bnagaev@gmail.com> wrote:
> Hey Erik,
>
> The scheme is interesting! I want to add my two cents.
>
> Those not motivated by funds could publish a zero knowledge proof
> instead of moving the funds. This means real funds are not even needed
> in this case. Or the whole scheme can be deployed to testnet or signet
> not to waste (or burn?) real coins.
>
> Also I would like to propose some properties which the publishing
> scheme should have to maximize the effect:
>
> - anonymous for the publisher
> - plausible deniable for the publisher
> - uncensorable
>
> For the plausible deniability thing, imagine a researcher who has
> access to a particular signature made by quantum computer and can
> prove it, but then it will be clear who leaked it, because the
> signature has a unique nonce. This is where ZK can help. But how to do
> ZK onchain to get censorship resistance? Maybe some BitVM construction
> may help.
>
> Using mainnet provides better censorship resistance than testnet or
> signet - that is actually a good reason to use mainnet unless we come
> up with a better approach.
>
> Best,
> Boris
>
> On Sat, May 30, 2026 at 12:58 PM Erik Aronesty <erik@q32.com> wrote:
> >
> > I have been thinking about a way to create publicly verifiable Bitcoin outputs whose recovery is intentionally tied to breaking a weaker cryptographic system.
> >
> > The goal is to create a "quantum bounty." The output would be spendable by a valid secp256k1 private key, but the key would be generated in a public ceremony and intentionally limited to 160 bits of entropy. Recovery would additionally be facilitated by publishing an encryption of the same secret under a weaker elliptic curve system.
> >
> > The basic idea is that a group of independent participants runs a distributed key generation ceremony. Each participant contributes a secret share. The shares are combined into a single 160-bit scalar x. At no point is x reconstructed on any machine or revealed to any participant.
> >
> > From the same distributed shares, participants jointly derive:
> >
> > 1. A Bitcoin public key P = xG on secp256k1.
> > 2. An encryption of x under a separate 160-bit elliptic curve system.
> >
> > The transcript contains all commitments, public contributions, ciphertext contributions, and equality-of-discrete-log proofs needed to verify that both constructions are derived from the same hidden scalar.
> >
> > The construction does not require SNARKs or any trusted setup. It appears sufficient to use Pedersen-style commitments, ElGamal-style encryption, and Chaum-Pedersen proofs showing consistency between participant contributions across the two groups.
> >
> > After the transcript is finalized, participants destroy their secret shares and temporary randomness. Assuming at least one participant behaves honestly and destroys their material, the scalar x is no longer known to anyone.
> >
> > The final artifact consists of:
> >
> > * A Bitcoin public key P.
> > * A weak-curve ciphertext C.
> > * A complete public transcript proving that P and C were derived from the same hidden scalar.
> >
> > Bitcoin can then be sent to the address corresponding to P.
> >
> > Anyone who can recover x from the weak cryptosystem can spend the output. The effective security of the bounty is therefore determined by the weaker curve rather than by the full secp256k1 discrete logarithm problem.
> >
> > The intended purpose is to create a publicly auditable cryptographic canary target.
> >
> > One question I have not fully resolved is whether there are cleaner constructions for the recoverable encryption component than ElGamal-style encryption, while still preserving simple transcript verification and avoiding general-purpose zero-knowledge systems.
> >
> > --
> > 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/CAJowKgJVwmm%3Dh6AsO4zeGTmfdK-RUQiDsMJkMRd6WZSo5FjeZg%40mail.gmail.com.
>
>
>
> --
> Best regards,
> Boris Nagaev
>
> --
> 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/CAFC_Vt7DLZEytF72Q0EVPeg6iED3qztMXs7aX6zBNBQ5%2B-ceXA%40mail.gmail.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/zG-JBFlHqnB2ZXTgBqIPn75VUiXkjrvBrO1CMN78gccfE4BqP3LmWnxB0cu2FQItr_cLoDcMFzlWaXkv3xeUDTOZrJgEGDRvWbpvADCBAZo%3D%40proton.me.
[-- Attachment #1.2: publickey - conduition@proton.me - 0x474891AD.asc --]
[-- Type: application/pgp-keys, Size: 649 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 343 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-06-05 23:56 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-05-30 17:01 [bitcoindev] Weak Quantum Bounty Ceremony Erik Aronesty
2026-05-30 19:11 ` Nikita Karetnikov
2026-05-30 19:28 ` Erik Aronesty
2026-05-31 5:03 ` Garlo Nicon
2026-05-31 6:22 ` Nagaev Boris
2026-06-05 23:46 ` 'conduition' via Bitcoin Development Mailing List
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox