[bitcoindev] P2QRH / BIP-360 Update

[bitcoindev] P2QRH / BIP-360 Update

[Hunter Beast]

[-- Attachment #1.1: Type: text/plain, Size: 7749 bytes --]



Dear Bitcoin Dev Community,

A bit over six months after introducing the P2QRH proposal (now BIP-360), 
I'm writing to share significant developments and request additional 
feedback on our post-quantum roadmap, and I'd also like to mention a 
potential P2TRH post-quantum mitigation strategy.

First, now that there's a BIP number assigned, you can find the update BIP 
here:

https://github.com/cryptoquick/bips/blob/p2qrh/bip-0360.mediawiki

The revised BIP-360 draft reflects substantial changes since initial 
publication, particularly regarding algorithm selection. While we 
originally considered SQIsign, it has 15,000x slower verification compared 
to ECC [1]. If it takes 1 second to verify a fully ECC block, it would take 
4 hours to validate a block filled with SQIsign transactions. This has 
obvious and concerning DDoS implications.

While it would take a long time to sign many thousands of SQIsign 
transactions as well, the increased time needed to sign the transactions 
likely won’t affect the practicality of DDoS attacks-- another concern 
which has been brought to my attention. As such, I've decided to deprecate 
SQIsign from the BIP.

It's worth mentioning because it was brought up in the PR, there's a new 
class of algorithms that support signature aggregation, but they generally 
result in signatures that are still quite large. Chipmunk and RACCOON are 
good examples [2], [3]. I do expect that to improve with time. It might be 
worthwhile to shorten the list by making signature aggregation a 
requirement, so as not to regress too far from Schnorr signatures. That 
said, I think those capabilities should be introduced in a separate BIP 
once they're more mature and worthwhile.

Our current shortlist prioritizes FALCON for its signature aggregation 
potential, with SPHINCS+ and CRYSTALS-Dilithium as secondary candidates. 
However, major technical challenges remain, particularly BIP-32 
compatibility issues affecting xpub generation in watch-only wallets, as 
detailed by conduition in another mailing list discussion [4], and also, 
how we should handle multisig wallets.

Additionally, I think it's worthwhile to restrict BIP-360 to NIST-approved 
algorithms to maintain FIPS compliance. That's because HSMs such as those 
provided by Securosys already have support for all three algorithms [5], 
which is essential for secure deployment of federated L2 treasuries.

Presently, for multisigs, we have a merkle tree configuration defined for 
encumbering the output with multiple keys. While that's efficient, it's a 
novel construction. I'm not certain we should proceed with the merkle tree 
commitment scheme-- it needs more scrutiny. We could use a sort of P2SH 
approach, just modifying the semantics of OP_CHECKMULTISIG in a witness 
script to alias to public keys in the attestation. But that could introduce 
additional overhead in a signature scheme that already uses a lot more 
space. Without this, however, we do not yet have a way specified to 
indicate thresholds or a locking script for the attestation, as it is 
designed to be purposely limited, so as specified it is only capable of n/n 
multisig. I consider m/n multisigs to be the single largest obvious 
omission in the spec right now. It definitely needs more thought and I'm 
open to suggestions. Perhaps two additional bytes at the top level of the 
SegWit v3 output hash could be provided to indicate PQC signature threshold 
and total, and those would be hashed and committed to in the output, then 
provided in a field in the attestation once spent.

While finalizing PQC selections, I've also drafted P2TRH as an interim 
solution to secure Taproot keypath spends without disabling them, as 
Matthew Corallo proposes in the aforementioned mailing list thread [4]. The 
P2TRH approach hashes public keys rather than exposing them directly, 
particularly benefiting:

- MuSig2 Lightning channel implementations

- FROST-based MPC vaults

- High-value transactions using private pools that don't reveal the block 
template

For those interested, take a look at the draft BIP for P2TRH here: 
https://github.com/cryptoquick/bips/blob/p2trh/bip-p2trh.mediawiki

I have my hands full with P2QRH advocacy and development and would prefer 
to focus on that, but I wanted to introduce P2TRH in case that is 
attractive as the community's preferred solution-- at least for Taproot 
quantum security. The tradeoff is that it adds 8.25 vB of overhead per 
input, and key tweaking might have slightly less utility for some 
applications, and it also doesn't protect against short exposure quantum 
attacks as defined in BIP-360.

Returning to P2QRH and what's needed to push it across the finish line...

I still need to finish the test vectors. I'm implementing these using a 
fork of rust-bitcoin and modeling them after Steven Roose's work on 
BIP-346. I've been told that's not a blocker for merging the draft, but if 
it isn't merged by the time I'm finished, hopefully that will provide some 
additional impetus behind it.

One concern Murch brought up is that introducing four new algorithms into 
the network was too many-- adding too much complexity to the network and to 
wallets and other applications-- and I agree. 

Hopefully this is addressed to some degree by removing SQIsign (especially 
in its current state lacking implementation maturity), and will help push 
the BIP below a certain complexity threshold, making it somewhat easier to 
review.

 

I think it's still important to include multiple signature algorithm 
options for users to select their desired level of security. It's not 100% 
certain that all of these algorithms will remain quantum resistant for all 
time, so redundancy here is… key.

Another concern is that NIST level V is overkill. I have less conviction on 
this since secp256k1 technically has 128 bits of security due to Pollard's 
rho attacks. But if the intention was for 256 bits of security, should 
level V security be the default? It's difficult for me to say. Perhaps both 
level V and level I implementations could be included, but this would be a 
deviation from the BIP as presently specified, which defaults to level V 
security. The disadvantage of including level I support for each algorithm 
is that it essentially doubles the complexity of libbitcoinpqc.

Ultimately, I hope the default of NIST V and selection of 3 mature 
NIST-approved algorithms demonstrate a focused, polished, and conservative 
proposal.

At this point, the major call to action I would like to highlight is simply 
the need for more feedback from the community. Please review and provide 
feedback here: https://github.com/bitcoin/bips/pull/1670

I look forward to feedback and opinions on P2QRH and P2TRH.

P.S. I'll be advocating for BIP-360 at OP_NEXT in VA, btc++ in Austin, 
Consensus in Toronto, and BTC 25 in Las Vegas, and later this year, TABConf 
in Atlanta.


[1] https://pqshield.github.io/nist-sigs-zoo

[2] https://eprint.iacr.org/2023/1820.pdf

[3] https://eprint.iacr.org/2024/1291.pdf

[4] https://groups.google.com/g/bitcoindev/c/8O857bRSVV8/m/7uu4dZNgAwAJ

[5] 
https://docs.securosys.com/tsb/Tutorials/Post-Quantum-Cryptography/pqc-release-overview

-- 
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/8797807d-e017-44e2-b419-803291779007n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 22793 bytes --]

Re: [bitcoindev] P2QRH / BIP-360 Update

[Dustin Ray]

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

Thanks for your work on this, it's exciting to watch it move along.

One item I have not yet addressed yet that is worth discussing is the
hierarchical deterministic seed characteristic of private keys for any of
the post quantum schemes you have mentioned so far. At present, if FALCON
is shortlisted, how do you propose to backup private keys? Must a new
wallet backup be made for each new public key that is generated?

Per your comment on security levels, I agree that your previous proposal
was absolutely overkill. My personal thought is that we will be just fine
by matching the current security levels provided by ecdsa, many years of
scrutiny has shown that this is sufficient.


On Wed, Feb 19, 2025 at 7:57 AM Hunter Beast <hunter@surmount.systems>
wrote:

> Dear Bitcoin Dev Community,
>
> A bit over six months after introducing the P2QRH proposal (now BIP-360),
> I'm writing to share significant developments and request additional
> feedback on our post-quantum roadmap, and I'd also like to mention a
> potential P2TRH post-quantum mitigation strategy.
>
> First, now that there's a BIP number assigned, you can find the update BIP
> here:
>
> https://github.com/cryptoquick/bips/blob/p2qrh/bip-0360.mediawiki
>
> The revised BIP-360 draft reflects substantial changes since initial
> publication, particularly regarding algorithm selection. While we
> originally considered SQIsign, it has 15,000x slower verification compared
> to ECC [1]. If it takes 1 second to verify a fully ECC block, it would take
> 4 hours to validate a block filled with SQIsign transactions. This has
> obvious and concerning DDoS implications.
>
> While it would take a long time to sign many thousands of SQIsign
> transactions as well, the increased time needed to sign the transactions
> likely won’t affect the practicality of DDoS attacks-- another concern
> which has been brought to my attention. As such, I've decided to deprecate
> SQIsign from the BIP.
>
> It's worth mentioning because it was brought up in the PR, there's a new
> class of algorithms that support signature aggregation, but they generally
> result in signatures that are still quite large. Chipmunk and RACCOON are
> good examples [2], [3]. I do expect that to improve with time. It might be
> worthwhile to shorten the list by making signature aggregation a
> requirement, so as not to regress too far from Schnorr signatures. That
> said, I think those capabilities should be introduced in a separate BIP
> once they're more mature and worthwhile.
>
> Our current shortlist prioritizes FALCON for its signature aggregation
> potential, with SPHINCS+ and CRYSTALS-Dilithium as secondary candidates.
> However, major technical challenges remain, particularly BIP-32
> compatibility issues affecting xpub generation in watch-only wallets, as
> detailed by conduition in another mailing list discussion [4], and also,
> how we should handle multisig wallets.
>
> Additionally, I think it's worthwhile to restrict BIP-360 to NIST-approved
> algorithms to maintain FIPS compliance. That's because HSMs such as those
> provided by Securosys already have support for all three algorithms [5],
> which is essential for secure deployment of federated L2 treasuries.
>
> Presently, for multisigs, we have a merkle tree configuration defined for
> encumbering the output with multiple keys. While that's efficient, it's a
> novel construction. I'm not certain we should proceed with the merkle tree
> commitment scheme-- it needs more scrutiny. We could use a sort of P2SH
> approach, just modifying the semantics of OP_CHECKMULTISIG in a witness
> script to alias to public keys in the attestation. But that could introduce
> additional overhead in a signature scheme that already uses a lot more
> space. Without this, however, we do not yet have a way specified to
> indicate thresholds or a locking script for the attestation, as it is
> designed to be purposely limited, so as specified it is only capable of n/n
> multisig. I consider m/n multisigs to be the single largest obvious
> omission in the spec right now. It definitely needs more thought and I'm
> open to suggestions. Perhaps two additional bytes at the top level of the
> SegWit v3 output hash could be provided to indicate PQC signature threshold
> and total, and those would be hashed and committed to in the output, then
> provided in a field in the attestation once spent.
>
> While finalizing PQC selections, I've also drafted P2TRH as an interim
> solution to secure Taproot keypath spends without disabling them, as
> Matthew Corallo proposes in the aforementioned mailing list thread [4]. The
> P2TRH approach hashes public keys rather than exposing them directly,
> particularly benefiting:
>
> - MuSig2 Lightning channel implementations
>
> - FROST-based MPC vaults
>
> - High-value transactions using private pools that don't reveal the block
> template
>
> For those interested, take a look at the draft BIP for P2TRH here:
> https://github.com/cryptoquick/bips/blob/p2trh/bip-p2trh.mediawiki
>
> I have my hands full with P2QRH advocacy and development and would prefer
> to focus on that, but I wanted to introduce P2TRH in case that is
> attractive as the community's preferred solution-- at least for Taproot
> quantum security. The tradeoff is that it adds 8.25 vB of overhead per
> input, and key tweaking might have slightly less utility for some
> applications, and it also doesn't protect against short exposure quantum
> attacks as defined in BIP-360.
>
> Returning to P2QRH and what's needed to push it across the finish line...
>
> I still need to finish the test vectors. I'm implementing these using a
> fork of rust-bitcoin and modeling them after Steven Roose's work on
> BIP-346. I've been told that's not a blocker for merging the draft, but if
> it isn't merged by the time I'm finished, hopefully that will provide some
> additional impetus behind it.
>
> One concern Murch brought up is that introducing four new algorithms into
> the network was too many-- adding too much complexity to the network and to
> wallets and other applications-- and I agree.
>
> Hopefully this is addressed to some degree by removing SQIsign (especially
> in its current state lacking implementation maturity), and will help push
> the BIP below a certain complexity threshold, making it somewhat easier to
> review.
>
>
>
> I think it's still important to include multiple signature algorithm
> options for users to select their desired level of security. It's not 100%
> certain that all of these algorithms will remain quantum resistant for all
> time, so redundancy here is… key.
>
> Another concern is that NIST level V is overkill. I have less conviction
> on this since secp256k1 technically has 128 bits of security due to
> Pollard's rho attacks. But if the intention was for 256 bits of security,
> should level V security be the default? It's difficult for me to say.
> Perhaps both level V and level I implementations could be included, but
> this would be a deviation from the BIP as presently specified, which
> defaults to level V security. The disadvantage of including level I support
> for each algorithm is that it essentially doubles the complexity of
> libbitcoinpqc.
>
> Ultimately, I hope the default of NIST V and selection of 3 mature
> NIST-approved algorithms demonstrate a focused, polished, and conservative
> proposal.
>
> At this point, the major call to action I would like to highlight is
> simply the need for more feedback from the community. Please review and
> provide feedback here: https://github.com/bitcoin/bips/pull/1670
>
> I look forward to feedback and opinions on P2QRH and P2TRH.
>
> P.S. I'll be advocating for BIP-360 at OP_NEXT in VA, btc++ in Austin,
> Consensus in Toronto, and BTC 25 in Las Vegas, and later this year, TABConf
> in Atlanta.
>
>
> [1] https://pqshield.github.io/nist-sigs-zoo
>
> [2] https://eprint.iacr.org/2023/1820.pdf
>
> [3] https://eprint.iacr.org/2024/1291.pdf
>
> [4] https://groups.google.com/g/bitcoindev/c/8O857bRSVV8/m/7uu4dZNgAwAJ
>
> [5]
> https://docs.securosys.com/tsb/Tutorials/Post-Quantum-Cryptography/pqc-release-overview
>
> --
> 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/8797807d-e017-44e2-b419-803291779007n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/8797807d-e017-44e2-b419-803291779007n%40googlegroups.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/CAC3UE4KkpxCO%2B%2Bhuw%3Dkw6YRayEvnhWtngzPkngiAvk16v3Kfew%40mail.gmail.com.

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

Re: [bitcoindev] P2QRH / BIP-360 Update

[Hunter Beast]

[-- Attachment #1.1: Type: text/plain, Size: 10103 bytes --]

> HD wallets

libbitcoinpqc will require key entropy to be provided, so it should 
maintain compatibility with that feature of HD wallets, so that's not a 
concern. The larger problem is for full BIP-32 support, I'm not really sure 
how xpubs or watch-only wallets will work.

> Security levels

You're not the first person to say that NIST V is overkill... I'll update 
the spec for NIST I. If more security is desired, they can use all three 
algorithms, plus Schnorr.

On Wednesday, February 19, 2025 at 11:47:04 AM UTC-7 Dustin Ray wrote:

> Thanks for your work on this, it's exciting to watch it move along.
>
> One item I have not yet addressed yet that is worth discussing is the 
> hierarchical deterministic seed characteristic of private keys for any of 
> the post quantum schemes you have mentioned so far. At present, if FALCON 
> is shortlisted, how do you propose to backup private keys? Must a new 
> wallet backup be made for each new public key that is generated?
>
> Per your comment on security levels, I agree that your previous proposal 
> was absolutely overkill. My personal thought is that we will be just fine 
> by matching the current security levels provided by ecdsa, many years of 
> scrutiny has shown that this is sufficient.
>
>
> On Wed, Feb 19, 2025 at 7:57 AM Hunter Beast <hun...@surmount.systems> 
> wrote:
>
>> Dear Bitcoin Dev Community,
>>
>> A bit over six months after introducing the P2QRH proposal (now BIP-360), 
>> I'm writing to share significant developments and request additional 
>> feedback on our post-quantum roadmap, and I'd also like to mention a 
>> potential P2TRH post-quantum mitigation strategy.
>>
>> First, now that there's a BIP number assigned, you can find the update 
>> BIP here:
>>
>> https://github.com/cryptoquick/bips/blob/p2qrh/bip-0360.mediawiki
>>
>> The revised BIP-360 draft reflects substantial changes since initial 
>> publication, particularly regarding algorithm selection. While we 
>> originally considered SQIsign, it has 15,000x slower verification compared 
>> to ECC [1]. If it takes 1 second to verify a fully ECC block, it would take 
>> 4 hours to validate a block filled with SQIsign transactions. This has 
>> obvious and concerning DDoS implications.
>>
>> While it would take a long time to sign many thousands of SQIsign 
>> transactions as well, the increased time needed to sign the transactions 
>> likely won’t affect the practicality of DDoS attacks-- another concern 
>> which has been brought to my attention. As such, I've decided to deprecate 
>> SQIsign from the BIP.
>>
>> It's worth mentioning because it was brought up in the PR, there's a new 
>> class of algorithms that support signature aggregation, but they generally 
>> result in signatures that are still quite large. Chipmunk and RACCOON are 
>> good examples [2], [3]. I do expect that to improve with time. It might be 
>> worthwhile to shorten the list by making signature aggregation a 
>> requirement, so as not to regress too far from Schnorr signatures. That 
>> said, I think those capabilities should be introduced in a separate BIP 
>> once they're more mature and worthwhile.
>>
>> Our current shortlist prioritizes FALCON for its signature aggregation 
>> potential, with SPHINCS+ and CRYSTALS-Dilithium as secondary candidates. 
>> However, major technical challenges remain, particularly BIP-32 
>> compatibility issues affecting xpub generation in watch-only wallets, as 
>> detailed by conduition in another mailing list discussion [4], and also, 
>> how we should handle multisig wallets.
>>
>> Additionally, I think it's worthwhile to restrict BIP-360 to 
>> NIST-approved algorithms to maintain FIPS compliance. That's because HSMs 
>> such as those provided by Securosys already have support for all three 
>> algorithms [5], which is essential for secure deployment of federated L2 
>> treasuries.
>>
>> Presently, for multisigs, we have a merkle tree configuration defined for 
>> encumbering the output with multiple keys. While that's efficient, it's a 
>> novel construction. I'm not certain we should proceed with the merkle tree 
>> commitment scheme-- it needs more scrutiny. We could use a sort of P2SH 
>> approach, just modifying the semantics of OP_CHECKMULTISIG in a witness 
>> script to alias to public keys in the attestation. But that could introduce 
>> additional overhead in a signature scheme that already uses a lot more 
>> space. Without this, however, we do not yet have a way specified to 
>> indicate thresholds or a locking script for the attestation, as it is 
>> designed to be purposely limited, so as specified it is only capable of n/n 
>> multisig. I consider m/n multisigs to be the single largest obvious 
>> omission in the spec right now. It definitely needs more thought and I'm 
>> open to suggestions. Perhaps two additional bytes at the top level of the 
>> SegWit v3 output hash could be provided to indicate PQC signature threshold 
>> and total, and those would be hashed and committed to in the output, then 
>> provided in a field in the attestation once spent.
>>
>> While finalizing PQC selections, I've also drafted P2TRH as an interim 
>> solution to secure Taproot keypath spends without disabling them, as 
>> Matthew Corallo proposes in the aforementioned mailing list thread [4]. The 
>> P2TRH approach hashes public keys rather than exposing them directly, 
>> particularly benefiting:
>>
>> - MuSig2 Lightning channel implementations
>>
>> - FROST-based MPC vaults
>>
>> - High-value transactions using private pools that don't reveal the block 
>> template
>>
>> For those interested, take a look at the draft BIP for P2TRH here: 
>> https://github.com/cryptoquick/bips/blob/p2trh/bip-p2trh.mediawiki
>>
>> I have my hands full with P2QRH advocacy and development and would prefer 
>> to focus on that, but I wanted to introduce P2TRH in case that is 
>> attractive as the community's preferred solution-- at least for Taproot 
>> quantum security. The tradeoff is that it adds 8.25 vB of overhead per 
>> input, and key tweaking might have slightly less utility for some 
>> applications, and it also doesn't protect against short exposure quantum 
>> attacks as defined in BIP-360.
>>
>> Returning to P2QRH and what's needed to push it across the finish line...
>>
>> I still need to finish the test vectors. I'm implementing these using a 
>> fork of rust-bitcoin and modeling them after Steven Roose's work on 
>> BIP-346. I've been told that's not a blocker for merging the draft, but if 
>> it isn't merged by the time I'm finished, hopefully that will provide some 
>> additional impetus behind it.
>>
>> One concern Murch brought up is that introducing four new algorithms into 
>> the network was too many-- adding too much complexity to the network and to 
>> wallets and other applications-- and I agree. 
>>
>> Hopefully this is addressed to some degree by removing SQIsign 
>> (especially in its current state lacking implementation maturity), and will 
>> help push the BIP below a certain complexity threshold, making it somewhat 
>> easier to review.
>>
>>  
>>
>> I think it's still important to include multiple signature algorithm 
>> options for users to select their desired level of security. It's not 100% 
>> certain that all of these algorithms will remain quantum resistant for all 
>> time, so redundancy here is… key.
>>
>> Another concern is that NIST level V is overkill. I have less conviction 
>> on this since secp256k1 technically has 128 bits of security due to 
>> Pollard's rho attacks. But if the intention was for 256 bits of security, 
>> should level V security be the default? It's difficult for me to say. 
>> Perhaps both level V and level I implementations could be included, but 
>> this would be a deviation from the BIP as presently specified, which 
>> defaults to level V security. The disadvantage of including level I support 
>> for each algorithm is that it essentially doubles the complexity of 
>> libbitcoinpqc.
>>
>> Ultimately, I hope the default of NIST V and selection of 3 mature 
>> NIST-approved algorithms demonstrate a focused, polished, and conservative 
>> proposal.
>>
>> At this point, the major call to action I would like to highlight is 
>> simply the need for more feedback from the community. Please review and 
>> provide feedback here: https://github.com/bitcoin/bips/pull/1670
>>
>> I look forward to feedback and opinions on P2QRH and P2TRH.
>>
>> P.S. I'll be advocating for BIP-360 at OP_NEXT in VA, btc++ in Austin, 
>> Consensus in Toronto, and BTC 25 in Las Vegas, and later this year, TABConf 
>> in Atlanta.
>>
>>
>> [1] https://pqshield.github.io/nist-sigs-zoo
>>
>> [2] https://eprint.iacr.org/2023/1820.pdf
>>
>> [3] https://eprint.iacr.org/2024/1291.pdf
>>
>> [4] https://groups.google.com/g/bitcoindev/c/8O857bRSVV8/m/7uu4dZNgAwAJ
>>
>> [5] 
>> https://docs.securosys.com/tsb/Tutorials/Post-Quantum-Cryptography/pqc-release-overview
>>
>> -- 
>> 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+...@googlegroups.com.
>> To view this discussion visit 
>> https://groups.google.com/d/msgid/bitcoindev/8797807d-e017-44e2-b419-803291779007n%40googlegroups.com 
>> <https://groups.google.com/d/msgid/bitcoindev/8797807d-e017-44e2-b419-803291779007n%40googlegroups.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/aa62f885-2807-41af-a672-5b1ff4c0b6b6n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 26301 bytes --]

Re: [bitcoindev] P2QRH / BIP-360 Update

[Matt Corallo]

If we want to do something like this in the short to medium term, IMO we should strip out all the 
signature schemes that are anything more than quite straightforward in their security assumptions 
(i.e. only keep hash-based signatures, maybe just SPHINCS+), only embed them in a taproot leaf, and 
call it a day.

BIP 32 compatibility isn't a really huge deal if we're talking about an "emergency break glass" 
kinda setup - most wallets are set up with a root key and can just embed the same PQ pubkey in all 
of their outputs. The privacy cost is only realized in a break glass case, and long before then 
hopefully whatever we do today is replaced with something better, with the knowledge that we'll gain 
on the way to "then". We'd still want to do it in an opcode so that we can do multisig, though.

Matt

On 2/19/25 10:40 AM, Hunter Beast wrote:
> Dear Bitcoin Dev Community,
> 
> 
> A bit over six months after introducing the P2QRH proposal (now BIP-360), I'm writing to share 
> significant developments and request additional feedback on our post-quantum roadmap, and I'd also 
> like to mention a potential P2TRH post-quantum mitigation strategy.
> 
> 
> First, now that there's a BIP number assigned, you can find the update BIP here:
> 
> https://github.com/cryptoquick/bips/blob/p2qrh/bip-0360.mediawiki <https://github.com/cryptoquick/ 
> bips/blob/p2qrh/bip-0360.mediawiki>
> 
> 
> The revised BIP-360 draft reflects substantial changes since initial publication, particularly 
> regarding algorithm selection. While we originally considered SQIsign, it has 15,000x slower 
> verification compared to ECC [1]. If it takes 1 second to verify a fully ECC block, it would take 4 
> hours to validate a block filled with SQIsign transactions. This has obvious and concerning DDoS 
> implications.
> 
> 
> While it would take a long time to signmany thousands of SQIsign transactions as well, the increased 
> time needed to sign the transactions likely won’t affect the practicality of DDoS attacks-- another 
> concern which has been brought to my attention. As such, I've decided to deprecate SQIsign from the BIP.
> 
> 
> It's worth mentioning because it was brought up in the PR, there's a new class of algorithms that 
> support signature aggregation, but they generally result in signatures that are still quite large. 
> Chipmunk and RACCOON are good examples [2], [3]. I do expect that to improve with time. It might be 
> worthwhile to shorten the list by making signature aggregation a requirement, so as not to regress 
> too far from Schnorr signatures. That said, I think those capabilities should be introduced in a 
> separate BIP once they're more mature and worthwhile.
> 
> 
> Our current shortlist prioritizes FALCON for its signature aggregation potential, with SPHINCS+ and 
> CRYSTALS-Dilithium as secondary candidates. However, major technical challenges remain, particularly 
> BIP-32 compatibility issues affecting xpub generation in watch-only wallets, as detailed by 
> conduition in another mailing list discussion [4], and also, how we should handle multisig wallets.
> 
> 
> Additionally, I think it's worthwhile to restrict BIP-360 to NIST-approved algorithms to maintain 
> FIPS compliance. That's because HSMs such as those provided by Securosys already have support for 
> all three algorithms [5], which is essential for secure deployment of federated L2 treasuries.
> 
> 
> Presently, for multisigs, we have a merkle tree configuration defined for encumbering the output 
> with multiple keys. While that's efficient, it's a novel construction. I'm not certain we should 
> proceed with the merkle tree commitment scheme-- it needs more scrutiny. We could use a sort of P2SH 
> approach, just modifying the semantics of OP_CHECKMULTISIG in a witness script to alias to public 
> keys in the attestation. But that could introduce additional overhead in a signature scheme that 
> already uses a lot more space. Without this, however, we do not yet have a way specified to indicate 
> thresholds or a locking script for the attestation, as it is designed to be purposely limited, so as 
> specified it is only capable of n/n multisig. I consider m/n multisigs to be the single largest 
> obvious omission in the spec right now. It definitely needs more thought and I'm open to 
> suggestions. Perhaps two additional bytes at the top level of the SegWit v3 output hash could be 
> provided to indicate PQC signature threshold and total, and those would be hashed and committed to 
> in the output, then provided in a field in the attestation once spent.
> 
> 
> While finalizing PQC selections, I've also drafted P2TRH as an interim solution to secure Taproot 
> keypath spends without disabling them, as Matthew Corallo proposes in the aforementioned mailing 
> list thread [4]. The P2TRH approach hashes public keys rather than exposing them directly, 
> particularly benefiting:
> 
> 
> - MuSig2 Lightning channel implementations
> 
> - FROST-based MPC vaults
> 
> - High-value transactions using private pools that don't reveal the block template
> 
> 
> For those interested, take a look at the draft BIP for P2TRH here: https://github.com/cryptoquick/ 
> bips/blob/p2trh/bip-p2trh.mediawiki <https://github.com/cryptoquick/bips/blob/p2trh/bip-p2trh.mediawiki>
> 
> 
> I have my hands full with P2QRH advocacy and development and would prefer to focus on that, but I 
> wanted to introduce P2TRH in case that is attractive as the community's preferred solution-- at 
> least for Taproot quantum security. The tradeoff is that it adds 8.25 vB of overhead per input, and 
> key tweaking might have slightly less utility for some applications, and it also doesn't protect 
> against short exposure quantum attacks as defined in BIP-360.
> 
> 
> Returning to P2QRH and what's needed to push it across the finish line...
> 
> 
> I still need to finish the test vectors. I'm implementing these using a fork of rust-bitcoin and 
> modeling them after Steven Roose's work on BIP-346. I've been told that's not a blocker for merging 
> the draft, but if it isn't merged by the time I'm finished, hopefully that will provide some 
> additional impetus behind it.
> 
> 
> One concern Murch brought up is that introducing four new algorithms into the network was too many-- 
> adding too much complexity to the network and to wallets and other applications-- and I agree.
> 
> 
> Hopefully this is addressed to some degree by removing SQIsign (especially in its current state 
> lacking implementation maturity), and will help push the BIP below a certain complexity threshold, 
> making it somewhat easier to review.
> 
> I think it's still important to include multiple signature algorithm options for users to select 
> their desired level of security. It's not 100% certain that all of these algorithms will remain 
> quantum resistant for all time, so redundancy here is… key.
> 
> 
> Another concern is that NIST level V is overkill. I have less conviction on this since secp256k1 
> technically has 128 bits of security due to Pollard's rho attacks. But if the intention was for 256 
> bits of security, should level V security be the default? It's difficult for me to say. Perhaps both 
> level V and level I implementations could be included, but this would be a deviation from the BIP as 
> presently specified, which defaults to level V security. The disadvantage of including level I 
> support for each algorithm is that it essentially doubles the complexity of libbitcoinpqc.
> 
> 
> Ultimately, I hope the default of NIST V and selection of 3 mature NIST-approved algorithms 
> demonstrate a focused, polished, and conservative proposal.
> 
> 
> At this point, the major call to action I would like to highlight is simply the need for more 
> feedback from the community. Please review and provide feedback here: https://github.com/bitcoin/ 
> bips/pull/1670 <https://github.com/bitcoin/bips/pull/1670>
> 
> 
> I look forward to feedback and opinions on P2QRH and P2TRH.
> 
> 
> P.S. I'll be advocating for BIP-360 at OP_NEXT in VA, btc++ in Austin, Consensus in Toronto, and BTC 
> 25 in Las Vegas, and later this year, TABConf in Atlanta.
> 
> 
> 
> [1] https://pqshield.github.io/nist-sigs-zoo
> 
> [2] https://eprint.iacr.org/2023/1820.pdf
> 
> [3] https://eprint.iacr.org/2024/1291.pdf
> 
> [4] https://groups.google.com/g/bitcoindev/c/8O857bRSVV8/m/7uu4dZNgAwAJ
> 
> [5] https://docs.securosys.com/tsb/Tutorials/Post-Quantum-Cryptography/pqc-release-overview
> 
> 
> -- 
> 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 <mailto:bitcoindev+unsubscribe@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/8797807d-e017-44e2- 
> b419-803291779007n%40googlegroups.com <https://groups.google.com/d/msgid/bitcoindev/8797807d- 
> e017-44e2-b419-803291779007n%40googlegroups.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/737fe7bb-4195-439f-87a9-b6fabd14eeea%40mattcorallo.com.

Re: [bitcoindev] P2QRH / BIP-360 Update

[Jonas Nick]

Hi Hunter,

Thanks for your work on BIP 360. I think now is a good time to develop and
discuss concrete PQ proposals. I have a few questions and comments regarding
some aspects of the proposal:

Selective disclosure
---

From, the output contains a root of a Merkle tree of public key hashes and
spending from this output requires revealing the public keys and their
corresponding valid signatures. More concretely, if the user creates root

R = MerkleRoot([hash(public_key_falcon_1024), hash(public_key_secp256k1)]),

they can spend from R by revealing both public keys and corresponding signatures.

The BIP also mentions that the public keys can be selectively disclosed:

 > When spending, if a public key hash is provided in the attestation with an
 > empty signature, that hash will be used directly in the merkle tree computation
 > rather than hashing the full public key.

What prevents an quantum adversary, upon observing a spend from R, from breaking
public_key_secp256k1 and then spending from R by providing

[
   hash(public_key_falcon_1024),
   empty string,
   public_key_secp256k1,
   a secp256k1 signature forgery
]?


Attestation structure
---

The BIP proposes to an attestation structure alongside the witness which is
supposed to contain BIP 360 public keys and signatures (instead having them in
the witness). The purpose of this structure is to assign a higher weight
discount than the witness. The "Rationale" and "Output Mechanics" sections the
BIP describe that, since the attestation structure only contains public keys and
signatures, storage of arbitrary data ("inscriptions") is prevented.

Leaving aside that there may be creative ways to embed arbitrary data in public
keys and signatures as well, selective disclosure of the Merkle tree appears to
allow embedding arbitrary data. For instance, a user can create root

R = MerkleRoot(data, hash(public_key_secp256k1)]),

where data is an arbitrary 256-bit string. What prevents the user from
pretending that data is the hash of a public key and providing

[
   data,
   empty string,
   public_key_secp256k1,
   a secp256k1 signature forgery
]

in the attestation structure to spend from R?


Multi-signature 256-bit security
---

The BIP briefly discusses multi-signature scenarios in the script validation
section, but the details seem incomplete. From what I can infer, the current
specification fails to achieve the claimed 256-bit security.

The potential attack would work as follows:
1. The victim provides their public key pk to the adversary.
2. The adversary finds two public keys pk' and pk'' such that
    MerkleRoot(MultiSig[pk, pk']) = MerkleRoot([pk''])
3. The adversary convinces the victim to send coins to MerkleRoot(MultiSig[pk,
    pk']) and then steals the coins by opening the Merkle tree root to [pk''] and
    providing a signature for pk''.

Since the Merkle root is the 256-bit output of SHA256, the adversary can find
this collision with about 2^128 operations.

If I remember correctly, this attack was discussed on the mailing list in the
context of segwit and it's the reason why P2WSH (unlike P2PKH) requires 256-bit
hashes.


General comments
---

I think one of the main questions that the BIP does not currently address is how
it affects the worst-case validation cost of a block.

Regarding your question:
 > But if the intention was for 256 bits of security, should level V security be
 > the default?

I don't know what Satoshi's intentions were, but the secp256k1 specification
clearly indicates 128-bit "strength" ([0], Table 1). I believe that's fairly
well known in the technical Bitcoin space.

I am not quite convinced that adding three PQ schemes to the Bitcoin consensus
protocol is a great solution to the problem of not being sure which exact scheme
to pick. Offloading this decision to users does not really solve this problem.
Moreover, this adds massive complexity and new cryptographic assumptions to the
protocol. Remember that one of the main motivations behind libsecp256k1, was
that general purpose cryptographic libraries are not well suited for consensus
systems. So all new cryptographic schemes added to the consensus protocol need
to be exceptionally well specified and implemented. That said, it makes a lot of
sense to design a hybrid scheme that also provides security against a classic
attacker through an established signature scheme (as BIP 360 proposes).

Lastly, I agree that non-interactive aggregation of PQ schemes might be
promising, as it could mitigate about signature size and verification cost if
aggregation is applied on the transaction level. Recently, there has been
progress on the security of aggregating hash-based signatures [1] and Falcon
[2].

[0] https://www.secg.org/sec2-v2.pdf
[1] https://eprint.iacr.org/2025/055
[2] https://eprint.iacr.org/2024/311 (Unfortunately, this only beats trivial
     aggregation (concatenation of signatures) when the number of signatures is
     greater than about 110)

Jonas

-- 
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/5667eb21-cd56-411d-a29f-81604752b7c4%40gmail.com.

Re: [bitcoindev] P2QRH / BIP-360 Update

[Hunter Beast]

[-- Attachment #1.1: Type: text/plain, Size: 11054 bytes --]

Hi Matt,

The only problem with that approach is that SLH-DSA signatures are quite 
large. NIST has also approved ML-DSA and FN-DSA, which, while both are 
based on lattice cryptography, they're not only standardized, but becoming 
widely supported. One consideration is hardware acceleration, and I believe 
those three algorithms will have the best chance of having hardware 
implementations as PQC extensions are added to CPUs and SoCs.

As for gating P2TR, the problem with that approach is that keypath spends 
would need to be disabled and that has a confiscatory effect that I'm 
seeking to avoid in this BIP.

An additional opcode should not be necessary if multisig capability is 
built into the attestation.

I agree with your statement on full BIP-32 compatibility. BIP-360 is just a 
starting point, and maybe you're right, it's best thought of as a "break 
glass" implementation. It's not ideal, it's full of compromises, not 
everyone is 100% happy with it, and that's probably okay, because bitcoin 
isn't perfect-- but it doesn't have to be in order to work.

Thank you for your thoughts.

Hunter

On Friday, February 21, 2025 at 3:18:21 AM UTC-7 Matt Corallo wrote:

If we want to do something like this in the short to medium term, IMO we 
should strip out all the 
signature schemes that are anything more than quite straightforward in 
their security assumptions 
(i.e. only keep hash-based signatures, maybe just SPHINCS+), only embed 
them in a taproot leaf, and 
call it a day. 

BIP 32 compatibility isn't a really huge deal if we're talking about an 
"emergency break glass" 
kinda setup - most wallets are set up with a root key and can just embed 
the same PQ pubkey in all 
of their outputs. The privacy cost is only realized in a break glass case, 
and long before then 
hopefully whatever we do today is replaced with something better, with the 
knowledge that we'll gain 
on the way to "then". We'd still want to do it in an opcode so that we can 
do multisig, though. 

Matt 

On 2/19/25 10:40 AM, Hunter Beast wrote: 
> Dear Bitcoin Dev Community, 
> 
> 
> A bit over six months after introducing the P2QRH proposal (now BIP-360), 
I'm writing to share 
> significant developments and request additional feedback on our 
post-quantum roadmap, and I'd also 
> like to mention a potential P2TRH post-quantum mitigation strategy. 
> 
> 
> First, now that there's a BIP number assigned, you can find the update 
BIP here: 
> 
> https://github.com/cryptoquick/bips/blob/p2qrh/bip-0360.mediawiki <
https://github.com/cryptoquick/ 
> bips/blob/p2qrh/bip-0360.mediawiki> 
> 
> 
> The revised BIP-360 draft reflects substantial changes since initial 
publication, particularly 
> regarding algorithm selection. While we originally considered SQIsign, it 
has 15,000x slower 
> verification compared to ECC [1]. If it takes 1 second to verify a fully 
ECC block, it would take 4 
> hours to validate a block filled with SQIsign transactions. This has 
obvious and concerning DDoS 
> implications. 
> 
> 
> While it would take a long time to signmany thousands of SQIsign 
transactions as well, the increased 
> time needed to sign the transactions likely won’t affect the practicality 
of DDoS attacks-- another 
> concern which has been brought to my attention. As such, I've decided to 
deprecate SQIsign from the BIP. 
> 
> 
> It's worth mentioning because it was brought up in the PR, there's a new 
class of algorithms that 
> support signature aggregation, but they generally result in signatures 
that are still quite large. 
> Chipmunk and RACCOON are good examples [2], [3]. I do expect that to 
improve with time. It might be 
> worthwhile to shorten the list by making signature aggregation a 
requirement, so as not to regress 
> too far from Schnorr signatures. That said, I think those capabilities 
should be introduced in a 
> separate BIP once they're more mature and worthwhile. 
> 
> 
> Our current shortlist prioritizes FALCON for its signature aggregation 
potential, with SPHINCS+ and 
> CRYSTALS-Dilithium as secondary candidates. However, major technical 
challenges remain, particularly 
> BIP-32 compatibility issues affecting xpub generation in watch-only 
wallets, as detailed by 
> conduition in another mailing list discussion [4], and also, how we 
should handle multisig wallets. 
> 
> 
> Additionally, I think it's worthwhile to restrict BIP-360 to 
NIST-approved algorithms to maintain 
> FIPS compliance. That's because HSMs such as those provided by Securosys 
already have support for 
> all three algorithms [5], which is essential for secure deployment of 
federated L2 treasuries. 
> 
> 
> Presently, for multisigs, we have a merkle tree configuration defined for 
encumbering the output 
> with multiple keys. While that's efficient, it's a novel construction. 
I'm not certain we should 
> proceed with the merkle tree commitment scheme-- it needs more scrutiny. 
We could use a sort of P2SH 
> approach, just modifying the semantics of OP_CHECKMULTISIG in a witness 
script to alias to public 
> keys in the attestation. But that could introduce additional overhead in 
a signature scheme that 
> already uses a lot more space. Without this, however, we do not yet have 
a way specified to indicate 
> thresholds or a locking script for the attestation, as it is designed to 
be purposely limited, so as 
> specified it is only capable of n/n multisig. I consider m/n multisigs to 
be the single largest 
> obvious omission in the spec right now. It definitely needs more thought 
and I'm open to 
> suggestions. Perhaps two additional bytes at the top level of the SegWit 
v3 output hash could be 
> provided to indicate PQC signature threshold and total, and those would 
be hashed and committed to 
> in the output, then provided in a field in the attestation once spent. 
> 
> 
> While finalizing PQC selections, I've also drafted P2TRH as an interim 
solution to secure Taproot 
> keypath spends without disabling them, as Matthew Corallo proposes in the 
aforementioned mailing 
> list thread [4]. The P2TRH approach hashes public keys rather than 
exposing them directly, 
> particularly benefiting: 
> 
> 
> - MuSig2 Lightning channel implementations 
> 
> - FROST-based MPC vaults 
> 
> - High-value transactions using private pools that don't reveal the block 
template 
> 
> 
> For those interested, take a look at the draft BIP for P2TRH here: 
https://github.com/cryptoquick/ 
> bips/blob/p2trh/bip-p2trh.mediawiki <
https://github.com/cryptoquick/bips/blob/p2trh/bip-p2trh.mediawiki> 
> 
> 
> I have my hands full with P2QRH advocacy and development and would prefer 
to focus on that, but I 
> wanted to introduce P2TRH in case that is attractive as the community's 
preferred solution-- at 
> least for Taproot quantum security. The tradeoff is that it adds 8.25 vB 
of overhead per input, and 
> key tweaking might have slightly less utility for some applications, and 
it also doesn't protect 
> against short exposure quantum attacks as defined in BIP-360. 
> 
> 
> Returning to P2QRH and what's needed to push it across the finish line... 
> 
> 
> I still need to finish the test vectors. I'm implementing these using a 
fork of rust-bitcoin and 
> modeling them after Steven Roose's work on BIP-346. I've been told that's 
not a blocker for merging 
> the draft, but if it isn't merged by the time I'm finished, hopefully 
that will provide some 
> additional impetus behind it. 
> 
> 
> One concern Murch brought up is that introducing four new algorithms into 
the network was too many-- 
> adding too much complexity to the network and to wallets and other 
applications-- and I agree. 
> 
> 
> Hopefully this is addressed to some degree by removing SQIsign 
(especially in its current state 
> lacking implementation maturity), and will help push the BIP below a 
certain complexity threshold, 
> making it somewhat easier to review. 
> 
> I think it's still important to include multiple signature algorithm 
options for users to select 
> their desired level of security. It's not 100% certain that all of these 
algorithms will remain 
> quantum resistant for all time, so redundancy here is… key. 
> 
> 
> Another concern is that NIST level V is overkill. I have less conviction 
on this since secp256k1 
> technically has 128 bits of security due to Pollard's rho attacks. But if 
the intention was for 256 
> bits of security, should level V security be the default? It's difficult 
for me to say. Perhaps both 
> level V and level I implementations could be included, but this would be 
a deviation from the BIP as 
> presently specified, which defaults to level V security. The disadvantage 
of including level I 
> support for each algorithm is that it essentially doubles the complexity 
of libbitcoinpqc. 
> 
> 
> Ultimately, I hope the default of NIST V and selection of 3 mature 
NIST-approved algorithms 
> demonstrate a focused, polished, and conservative proposal. 
> 
> 
> At this point, the major call to action I would like to highlight is 
simply the need for more 
> feedback from the community. Please review and provide feedback here: 
https://github.com/bitcoin/ 
> bips/pull/1670 <https://github.com/bitcoin/bips/pull/1670> 
> 
> 
> I look forward to feedback and opinions on P2QRH and P2TRH. 
> 
> 
> P.S. I'll be advocating for BIP-360 at OP_NEXT in VA, btc++ in Austin, 
Consensus in Toronto, and BTC 
> 25 in Las Vegas, and later this year, TABConf in Atlanta. 
> 
> 
> 
> [1] https://pqshield.github.io/nist-sigs-zoo 
> 
> [2] https://eprint.iacr.org/2023/1820.pdf 
> 
> [3] https://eprint.iacr.org/2024/1291.pdf 
> 
> [4] https://groups.google.com/g/bitcoindev/c/8O857bRSVV8/m/7uu4dZNgAwAJ 
> 
> [5] 
https://docs.securosys.com/tsb/Tutorials/Post-Quantum-Cryptography/pqc-release-overview 
> 
> 
> -- 
> 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+...@googlegroups.com <mailto:bitcoindev+...@googlegroups.com>. 
> To view this discussion visit 
https://groups.google.com/d/msgid/bitcoindev/8797807d-e017-44e2- 
> b419-803291779007n%40googlegroups.com <
https://groups.google.com/d/msgid/bitcoindev/8797807d- 
> e017-44e2-b419-803291779007n%
40googlegroups.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/866ee206-4a4e-4cd6-9de3-fa2fa35e2230n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 14359 bytes --]

Re: [bitcoindev] P2QRH / BIP-360 Update

[Hunter Beast]

[-- Attachment #1.1: Type: text/plain, Size: 8496 bytes --]

Hi Jonas,

On Selective Disclosure,

I think we're going to need to add simple multisig semantics to the 
attestation due to its lack of script capability. Would that help? Separate 
multisig semantics like quorum and total would be needed for each class of 
key, so that even if Schnorr signatures can be broken (or one or two of the 
other PQC signatures even), they don't count towards the quorum of the 
other signature types.

On Attestation structure,

What prevents arbitrary data being hashed and then included in the 
attestation is, each signature public key pair must be able to verify the 
transaction message in order to be considered a valid transaction. In other 
words, each public key and signature pair is validated against the 
transaction message upon transaction verification.

On Multisignature 256-bit security,

To be honest, I've read this a couple of times and I will admit I don't 
understand this attack. Can you provide more details on how it works, and 
how it might be possible to mitigate?

On General comments,

I agree with the worst-case transaction verification concern. I'll need to 
put some work into detailing NIST I variants and their signature 
verification times, and then computing worst-case scenarios for different 
discount constants.

On 128-bit security... Yes, I'm coming to realize that too. It's been a 
common point of feedback.

On adding three schemes, there are a couple of advantages of this. First, 
wallets can automatically decide how many signatures to add based on the 
amount being spent. This then acts as a sort of MEV opportunity for miners, 
because the higher the value of the transaction, the more signatures might 
be included, which increases fee revenue. Also, it addresses Matt's concern 
about security assumptions. There's a strong desire for SLH-DSA support, 
even though it's so large. However, from a practicality standpoint 
(thinking of plebs), it will make sense to include the smaller ML-DSA and 
FN-DSA also. While it does increase complexity, I believe that a 
libbitcoinpqc library, as mentioned in the BIP, will serve as a useful 
analogue to libsecp256k1. It's also worth noting that in my position at 
Anduro, I have resources to put into building such a library. Hopefully 
this can help meet the expectation of a well specified and implemented 
consensus level library.

On signature aggregation, yes, I'm excited to see those developments in 
FN-DSA, and maybe we can see that filter into SLH-DSA as well. Hopefully 
those improvements will be ready once the time comes to activate.



On Friday, February 21, 2025 at 3:18:35 AM UTC-7 Jonas Nick wrote:

> Hi Hunter,
>
> Thanks for your work on BIP 360. I think now is a good time to develop and
> discuss concrete PQ proposals. I have a few questions and comments 
> regarding
> some aspects of the proposal:
>
> Selective disclosure
> ---
>
> From, the output contains a root of a Merkle tree of public key hashes and
> spending from this output requires revealing the public keys and their
> corresponding valid signatures. More concretely, if the user creates root
>
> R = MerkleRoot([hash(public_key_falcon_1024), hash(public_key_secp256k1)]),
>
> they can spend from R by revealing both public keys and corresponding 
> signatures.
>
> The BIP also mentions that the public keys can be selectively disclosed:
>
> > When spending, if a public key hash is provided in the attestation with 
> an
> > empty signature, that hash will be used directly in the merkle tree 
> computation
> > rather than hashing the full public key.
>
> What prevents an quantum adversary, upon observing a spend from R, from 
> breaking
> public_key_secp256k1 and then spending from R by providing
>
> [
> hash(public_key_falcon_1024),
> empty string,
> public_key_secp256k1,
> a secp256k1 signature forgery
> ]?
>
>
> Attestation structure
> ---
>
> The BIP proposes to an attestation structure alongside the witness which is
> supposed to contain BIP 360 public keys and signatures (instead having 
> them in
> the witness). The purpose of this structure is to assign a higher weight
> discount than the witness. The "Rationale" and "Output Mechanics" sections 
> the
> BIP describe that, since the attestation structure only contains public 
> keys and
> signatures, storage of arbitrary data ("inscriptions") is prevented.
>
> Leaving aside that there may be creative ways to embed arbitrary data in 
> public
> keys and signatures as well, selective disclosure of the Merkle tree 
> appears to
> allow embedding arbitrary data. For instance, a user can create root
>
> R = MerkleRoot(data, hash(public_key_secp256k1)]),
>
> where data is an arbitrary 256-bit string. What prevents the user from
> pretending that data is the hash of a public key and providing
>
> [
> data,
> empty string,
> public_key_secp256k1,
> a secp256k1 signature forgery
> ]
>
> in the attestation structure to spend from R?
>
>
> Multi-signature 256-bit security
> ---
>
> The BIP briefly discusses multi-signature scenarios in the script 
> validation
> section, but the details seem incomplete. From what I can infer, the 
> current
> specification fails to achieve the claimed 256-bit security.
>
> The potential attack would work as follows:
> 1. The victim provides their public key pk to the adversary.
> 2. The adversary finds two public keys pk' and pk'' such that
> MerkleRoot(MultiSig[pk, pk']) = MerkleRoot([pk''])
> 3. The adversary convinces the victim to send coins to 
> MerkleRoot(MultiSig[pk,
> pk']) and then steals the coins by opening the Merkle tree root to [pk''] 
> and
> providing a signature for pk''.
>
> Since the Merkle root is the 256-bit output of SHA256, the adversary can 
> find
> this collision with about 2^128 operations.
>
> If I remember correctly, this attack was discussed on the mailing list in 
> the
> context of segwit and it's the reason why P2WSH (unlike P2PKH) requires 
> 256-bit
> hashes.
>
>
> General comments
> ---
>
> I think one of the main questions that the BIP does not currently address 
> is how
> it affects the worst-case validation cost of a block.
>
> Regarding your question:
> > But if the intention was for 256 bits of security, should level V 
> security be
> > the default?
>
> I don't know what Satoshi's intentions were, but the secp256k1 
> specification
> clearly indicates 128-bit "strength" ([0], Table 1). I believe that's 
> fairly
> well known in the technical Bitcoin space.
>
> I am not quite convinced that adding three PQ schemes to the Bitcoin 
> consensus
> protocol is a great solution to the problem of not being sure which exact 
> scheme
> to pick. Offloading this decision to users does not really solve this 
> problem.
> Moreover, this adds massive complexity and new cryptographic assumptions 
> to the
> protocol. Remember that one of the main motivations behind libsecp256k1, 
> was
> that general purpose cryptographic libraries are not well suited for 
> consensus
> systems. So all new cryptographic schemes added to the consensus protocol 
> need
> to be exceptionally well specified and implemented. That said, it makes a 
> lot of
> sense to design a hybrid scheme that also provides security against a 
> classic
> attacker through an established signature scheme (as BIP 360 proposes).
>
> Lastly, I agree that non-interactive aggregation of PQ schemes might be
> promising, as it could mitigate about signature size and verification cost 
> if
> aggregation is applied on the transaction level. Recently, there has been
> progress on the security of aggregating hash-based signatures [1] and 
> Falcon
> [2].
>
> [0] https://www.secg.org/sec2-v2.pdf
> [1] https://eprint.iacr.org/2025/055
> [2] https://eprint.iacr.org/2024/311 (Unfortunately, this only beats 
> trivial
> aggregation (concatenation of signatures) when the number of signatures is
> greater than about 110)
>
> Jonas
>
>

-- 
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/16d7adca-a01e-40c5-9570-31967ee339ecn%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 10276 bytes --]

Re: [bitcoindev] P2QRH / BIP-360 Update

[Jonas Nick]

 > What prevents arbitrary data being hashed and then included in the attestation
 > is, each signature public key pair must be able to verify the transaction
 > message in order to be considered a valid transaction.

This appears to contradict the selective disclosure mechanism described in the
BIP and this sentence in the "Script Validation" section:

 > Public keys that are not needed can be excluded by including their hash in the
 > attestation accompanied with an empty signature

Even if the selective disclosure vulnerability is fixed by committing to the
multisig semantics in the P2QRH output, any unopened public key commitment could
still be "abused" for arbitrary data storage. Similar to the scenario in my
previous post, if the root R is MerkleRoot([leafhash1, leafhash2]) and the
multisig policy is "1-of-2", then we can set

leafhash1 := data
leafhash2 := hash(public_key_secp256k1)

and post the data to the chain by spending the output using an attestation
structure that includes leafhash1, an empty signature, public_key_secp256k1 and
the corresponding signature.

 > I will admit I don't understand this attack. Can you provide more details on
 > how it works, and how it might be possible to mitigate?

To give more context, this attack is intended as a concrete demonstration of how
breaking the collision resistance of the hash function used in the Merkle tree
can enable an adversary to steal coins. Here's a different explanation for
essentially the same attack in the context of P2SH vs. P2WSH:
https://bitcoin.stackexchange.com/a/54847/35586

The attack against the BIP's proposed signature scheme (where the Merkle tree is
constructed from public keys and then an ordinary signature scheme is applied to
one or more of the committed public keys) can be mitigated by using a hash
function with a larger output space (e.g., SHA-512).

However, I'm not suggesting to do this. My point is that while the BIP aims for
256 bits of security by using NIST strength level V parameters, it does not
actually achieve that security level (when the adversary can affect any of the
leaves as in multisignatures, for example).

The Bitcoin protocol relies heavily on collision-resistance of SHA-256, which is
pretty much the definition of NIST strength level II [0].

[0] https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cryptography-standardization/evaluation-criteria/security-(evaluation-criteria)

-- 
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/5550807e-0655-4895-bc66-1b67bfde8c3e%40gmail.com.

Re: [bitcoindev] P2QRH / BIP-360 Update

[Ian Quantum]

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

FALCON+ is more likely to get NIST approval. They struggled to get the
algorithm over "80 bits of security" even with a significant set of
improvements. I don't know if this affects the aggregation features, it
would take significant research. The dramatic security improvements of
FALCON+ only cost 5% and 0 bytes additional overhead.
https://eprint.iacr.org/2024/1769.pdf

SECP256k1 had significant reductions to it's security over the last 16
years but none of the attacks detailed by Bernstein directly impact the
security as implemented into Bitcoin. (Mitigations and non-interactive
signing, salt and hash were excellent design choices.)

I would suggest delaying FALCON or FALCON+ until standardized. There are
significant weaknesses but no full break. The brittleness of the random
numbers, exposure to inverse function and a lot "weaker than expected"
parameters would suggest caution. Once standardized I would suggest rapid
implementation but not until then.

NTRU Prime is a favored alternate candidate of mine, as communicated
previously. Cryptographers suspect that NIST has again inserted PQC
backdoors following the last 3 public key standards being standardized with
very suspicious parameters. (P224, P256, P384)

I hope we can get some momentum around protecting Bitcoin. 1-6 million
(depending on estimate) BTC have known public keys and while most could
transfer to p2pkh the creation of quantum safe addresses is a strong
signal. The implementation of post quantum cryptography is also required by
many government agencies around the world, including the White House.
Ian Smith
Migrate to Quantum Safety before 2027

On Mon, Feb 24, 2025, 12:53 AM Hunter Beast <hunter@surmount.systems> wrote:

> Hi Jonas,
>
> On Selective Disclosure,
>
> I think we're going to need to add simple multisig semantics to the
> attestation due to its lack of script capability. Would that help? Separate
> multisig semantics like quorum and total would be needed for each class of
> key, so that even if Schnorr signatures can be broken (or one or two of the
> other PQC signatures even), they don't count towards the quorum of the
> other signature types.
>
> On Attestation structure,
>
> What prevents arbitrary data being hashed and then included in the
> attestation is, each signature public key pair must be able to verify the
> transaction message in order to be considered a valid transaction. In other
> words, each public key and signature pair is validated against the
> transaction message upon transaction verification.
>
> On Multisignature 256-bit security,
>
> To be honest, I've read this a couple of times and I will admit I don't
> understand this attack. Can you provide more details on how it works, and
> how it might be possible to mitigate?
>
> On General comments,
>
> I agree with the worst-case transaction verification concern. I'll need to
> put some work into detailing NIST I variants and their signature
> verification times, and then computing worst-case scenarios for different
> discount constants.
>
> On 128-bit security... Yes, I'm coming to realize that too. It's been a
> common point of feedback.
>
> On adding three schemes, there are a couple of advantages of this. First,
> wallets can automatically decide how many signatures to add based on the
> amount being spent. This then acts as a sort of MEV opportunity for miners,
> because the higher the value of the transaction, the more signatures might
> be included, which increases fee revenue. Also, it addresses Matt's concern
> about security assumptions. There's a strong desire for SLH-DSA support,
> even though it's so large. However, from a practicality standpoint
> (thinking of plebs), it will make sense to include the smaller ML-DSA and
> FN-DSA also. While it does increase complexity, I believe that a
> libbitcoinpqc library, as mentioned in the BIP, will serve as a useful
> analogue to libsecp256k1. It's also worth noting that in my position at
> Anduro, I have resources to put into building such a library. Hopefully
> this can help meet the expectation of a well specified and implemented
> consensus level library.
>
> On signature aggregation, yes, I'm excited to see those developments in
> FN-DSA, and maybe we can see that filter into SLH-DSA as well. Hopefully
> those improvements will be ready once the time comes to activate.
>
>
>
> On Friday, February 21, 2025 at 3:18:35 AM UTC-7 Jonas Nick wrote:
>
>> Hi Hunter,
>>
>> Thanks for your work on BIP 360. I think now is a good time to develop
>> and
>> discuss concrete PQ proposals. I have a few questions and comments
>> regarding
>> some aspects of the proposal:
>>
>> Selective disclosure
>> ---
>>
>> From, the output contains a root of a Merkle tree of public key hashes
>> and
>> spending from this output requires revealing the public keys and their
>> corresponding valid signatures. More concretely, if the user creates root
>>
>> R = MerkleRoot([hash(public_key_falcon_1024),
>> hash(public_key_secp256k1)]),
>>
>> they can spend from R by revealing both public keys and corresponding
>> signatures.
>>
>> The BIP also mentions that the public keys can be selectively disclosed:
>>
>> > When spending, if a public key hash is provided in the attestation with
>> an
>> > empty signature, that hash will be used directly in the merkle tree
>> computation
>> > rather than hashing the full public key.
>>
>> What prevents an quantum adversary, upon observing a spend from R, from
>> breaking
>> public_key_secp256k1 and then spending from R by providing
>>
>> [
>> hash(public_key_falcon_1024),
>> empty string,
>> public_key_secp256k1,
>> a secp256k1 signature forgery
>> ]?
>>
>>
>> Attestation structure
>> ---
>>
>> The BIP proposes to an attestation structure alongside the witness which
>> is
>> supposed to contain BIP 360 public keys and signatures (instead having
>> them in
>> the witness). The purpose of this structure is to assign a higher weight
>> discount than the witness. The "Rationale" and "Output Mechanics"
>> sections the
>> BIP describe that, since the attestation structure only contains public
>> keys and
>> signatures, storage of arbitrary data ("inscriptions") is prevented.
>>
>> Leaving aside that there may be creative ways to embed arbitrary data in
>> public
>> keys and signatures as well, selective disclosure of the Merkle tree
>> appears to
>> allow embedding arbitrary data. For instance, a user can create root
>>
>> R = MerkleRoot(data, hash(public_key_secp256k1)]),
>>
>> where data is an arbitrary 256-bit string. What prevents the user from
>> pretending that data is the hash of a public key and providing
>>
>> [
>> data,
>> empty string,
>> public_key_secp256k1,
>> a secp256k1 signature forgery
>> ]
>>
>> in the attestation structure to spend from R?
>>
>>
>> Multi-signature 256-bit security
>> ---
>>
>> The BIP briefly discusses multi-signature scenarios in the script
>> validation
>> section, but the details seem incomplete. From what I can infer, the
>> current
>> specification fails to achieve the claimed 256-bit security.
>>
>> The potential attack would work as follows:
>> 1. The victim provides their public key pk to the adversary.
>> 2. The adversary finds two public keys pk' and pk'' such that
>> MerkleRoot(MultiSig[pk, pk']) = MerkleRoot([pk''])
>> 3. The adversary convinces the victim to send coins to
>> MerkleRoot(MultiSig[pk,
>> pk']) and then steals the coins by opening the Merkle tree root to [pk'']
>> and
>> providing a signature for pk''.
>>
>> Since the Merkle root is the 256-bit output of SHA256, the adversary can
>> find
>> this collision with about 2^128 operations.
>>
>> If I remember correctly, this attack was discussed on the mailing list in
>> the
>> context of segwit and it's the reason why P2WSH (unlike P2PKH) requires
>> 256-bit
>> hashes.
>>
>>
>> General comments
>> ---
>>
>> I think one of the main questions that the BIP does not currently address
>> is how
>> it affects the worst-case validation cost of a block.
>>
>> Regarding your question:
>> > But if the intention was for 256 bits of security, should level V
>> security be
>> > the default?
>>
>> I don't know what Satoshi's intentions were, but the secp256k1
>> specification
>> clearly indicates 128-bit "strength" ([0], Table 1). I believe that's
>> fairly
>> well known in the technical Bitcoin space.
>>
>> I am not quite convinced that adding three PQ schemes to the Bitcoin
>> consensus
>> protocol is a great solution to the problem of not being sure which exact
>> scheme
>> to pick. Offloading this decision to users does not really solve this
>> problem.
>> Moreover, this adds massive complexity and new cryptographic assumptions
>> to the
>> protocol. Remember that one of the main motivations behind libsecp256k1,
>> was
>> that general purpose cryptographic libraries are not well suited for
>> consensus
>> systems. So all new cryptographic schemes added to the consensus protocol
>> need
>> to be exceptionally well specified and implemented. That said, it makes a
>> lot of
>> sense to design a hybrid scheme that also provides security against a
>> classic
>> attacker through an established signature scheme (as BIP 360 proposes).
>>
>> Lastly, I agree that non-interactive aggregation of PQ schemes might be
>> promising, as it could mitigate about signature size and verification
>> cost if
>> aggregation is applied on the transaction level. Recently, there has been
>> progress on the security of aggregating hash-based signatures [1] and
>> Falcon
>> [2].
>>
>> [0] https://www.secg.org/sec2-v2.pdf
>> [1] https://eprint.iacr.org/2025/055
>> [2] https://eprint.iacr.org/2024/311 (Unfortunately, this only beats
>> trivial
>> aggregation (concatenation of signatures) when the number of signatures
>> is
>> greater than about 110)
>>
>> Jonas
>>
>> --
> 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/16d7adca-a01e-40c5-9570-31967ee339ecn%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/16d7adca-a01e-40c5-9570-31967ee339ecn%40googlegroups.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/CA%2B7C%2BcYY_97y_QsSON5U3y7v4a0usGaGmcD%2Br%3D8Y05p5Cwmp5w%40mail.gmail.com.

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

Re: [bitcoindev] P2QRH / BIP-360 Update

[Hunter Beast]

[-- Attachment #1.1: Type: text/plain, Size: 10250 bytes --]

Hi Tim,

Your spreadsheet makes sense, I think. Does this include an attestation 
discount?

I've also done some similar calculations here:

https://x.com/cryptoquick/status/1866986505434264047

On Monday, February 24, 2025 at 8:27:37 AM UTC-7 Tim Bratton wrote:

> I did some quick estimates of the proposals in terms of TPS (Comparison 
> chart attached).
>
> There are tradeoffs to be made for sure.
>
> Is this in line with what everyone else is thinking too?
>
>
>
>
>
> On Sun, Feb 23, 2025 at 3:53 PM Hunter Beast <hun...@surmount.systems> 
> wrote:
>
>> Hi Jonas,
>>
>> On Selective Disclosure,
>>
>> I think we're going to need to add simple multisig semantics to the 
>> attestation due to its lack of script capability. Would that help? Separate 
>> multisig semantics like quorum and total would be needed for each class of 
>> key, so that even if Schnorr signatures can be broken (or one or two of the 
>> other PQC signatures even), they don't count towards the quorum of the 
>> other signature types.
>>
>> On Attestation structure,
>>
>> What prevents arbitrary data being hashed and then included in the 
>> attestation is, each signature public key pair must be able to verify the 
>> transaction message in order to be considered a valid transaction. In other 
>> words, each public key and signature pair is validated against the 
>> transaction message upon transaction verification.
>>
>> On Multisignature 256-bit security,
>>
>> To be honest, I've read this a couple of times and I will admit I don't 
>> understand this attack. Can you provide more details on how it works, and 
>> how it might be possible to mitigate?
>>
>> On General comments,
>>
>> I agree with the worst-case transaction verification concern. I'll need 
>> to put some work into detailing NIST I variants and their signature 
>> verification times, and then computing worst-case scenarios for different 
>> discount constants.
>>
>> On 128-bit security... Yes, I'm coming to realize that too. It's been a 
>> common point of feedback.
>>
>> On adding three schemes, there are a couple of advantages of this. First, 
>> wallets can automatically decide how many signatures to add based on the 
>> amount being spent. This then acts as a sort of MEV opportunity for miners, 
>> because the higher the value of the transaction, the more signatures might 
>> be included, which increases fee revenue. Also, it addresses Matt's concern 
>> about security assumptions. There's a strong desire for SLH-DSA support, 
>> even though it's so large. However, from a practicality standpoint 
>> (thinking of plebs), it will make sense to include the smaller ML-DSA and 
>> FN-DSA also. While it does increase complexity, I believe that a 
>> libbitcoinpqc library, as mentioned in the BIP, will serve as a useful 
>> analogue to libsecp256k1. It's also worth noting that in my position at 
>> Anduro, I have resources to put into building such a library. Hopefully 
>> this can help meet the expectation of a well specified and implemented 
>> consensus level library.
>>
>> On signature aggregation, yes, I'm excited to see those developments in 
>> FN-DSA, and maybe we can see that filter into SLH-DSA as well. Hopefully 
>> those improvements will be ready once the time comes to activate.
>>
>>
>>
>> On Friday, February 21, 2025 at 3:18:35 AM UTC-7 Jonas Nick wrote:
>>
>>> Hi Hunter, 
>>>
>>> Thanks for your work on BIP 360. I think now is a good time to develop 
>>> and 
>>> discuss concrete PQ proposals. I have a few questions and comments 
>>> regarding 
>>> some aspects of the proposal: 
>>>
>>> Selective disclosure 
>>> --- 
>>>
>>> From, the output contains a root of a Merkle tree of public key hashes 
>>> and 
>>> spending from this output requires revealing the public keys and their 
>>> corresponding valid signatures. More concretely, if the user creates 
>>> root 
>>>
>>> R = MerkleRoot([hash(public_key_falcon_1024), 
>>> hash(public_key_secp256k1)]), 
>>>
>>> they can spend from R by revealing both public keys and corresponding 
>>> signatures. 
>>>
>>> The BIP also mentions that the public keys can be selectively disclosed: 
>>>
>>> > When spending, if a public key hash is provided in the attestation 
>>> with an 
>>> > empty signature, that hash will be used directly in the merkle tree 
>>> computation 
>>> > rather than hashing the full public key. 
>>>
>>> What prevents an quantum adversary, upon observing a spend from R, from 
>>> breaking 
>>> public_key_secp256k1 and then spending from R by providing 
>>>
>>> [ 
>>> hash(public_key_falcon_1024), 
>>> empty string, 
>>> public_key_secp256k1, 
>>> a secp256k1 signature forgery 
>>> ]? 
>>>
>>>
>>> Attestation structure 
>>> --- 
>>>
>>> The BIP proposes to an attestation structure alongside the witness which 
>>> is 
>>> supposed to contain BIP 360 public keys and signatures (instead having 
>>> them in 
>>> the witness). The purpose of this structure is to assign a higher weight 
>>> discount than the witness. The "Rationale" and "Output Mechanics" 
>>> sections the 
>>> BIP describe that, since the attestation structure only contains public 
>>> keys and 
>>> signatures, storage of arbitrary data ("inscriptions") is prevented. 
>>>
>>> Leaving aside that there may be creative ways to embed arbitrary data in 
>>> public 
>>> keys and signatures as well, selective disclosure of the Merkle tree 
>>> appears to 
>>> allow embedding arbitrary data. For instance, a user can create root 
>>>
>>> R = MerkleRoot(data, hash(public_key_secp256k1)]), 
>>>
>>> where data is an arbitrary 256-bit string. What prevents the user from 
>>> pretending that data is the hash of a public key and providing 
>>>
>>> [ 
>>> data, 
>>> empty string, 
>>> public_key_secp256k1, 
>>> a secp256k1 signature forgery 
>>> ] 
>>>
>>> in the attestation structure to spend from R? 
>>>
>>>
>>> Multi-signature 256-bit security 
>>> --- 
>>>
>>> The BIP briefly discusses multi-signature scenarios in the script 
>>> validation 
>>> section, but the details seem incomplete. From what I can infer, the 
>>> current 
>>> specification fails to achieve the claimed 256-bit security. 
>>>
>>> The potential attack would work as follows: 
>>> 1. The victim provides their public key pk to the adversary. 
>>> 2. The adversary finds two public keys pk' and pk'' such that 
>>> MerkleRoot(MultiSig[pk, pk']) = MerkleRoot([pk'']) 
>>> 3. The adversary convinces the victim to send coins to 
>>> MerkleRoot(MultiSig[pk, 
>>> pk']) and then steals the coins by opening the Merkle tree root to 
>>> [pk''] and 
>>> providing a signature for pk''. 
>>>
>>> Since the Merkle root is the 256-bit output of SHA256, the adversary can 
>>> find 
>>> this collision with about 2^128 operations. 
>>>
>>> If I remember correctly, this attack was discussed on the mailing list 
>>> in the 
>>> context of segwit and it's the reason why P2WSH (unlike P2PKH) requires 
>>> 256-bit 
>>> hashes. 
>>>
>>>
>>> General comments 
>>> --- 
>>>
>>> I think one of the main questions that the BIP does not currently 
>>> address is how 
>>> it affects the worst-case validation cost of a block. 
>>>
>>> Regarding your question: 
>>> > But if the intention was for 256 bits of security, should level V 
>>> security be 
>>> > the default? 
>>>
>>> I don't know what Satoshi's intentions were, but the secp256k1 
>>> specification 
>>> clearly indicates 128-bit "strength" ([0], Table 1). I believe that's 
>>> fairly 
>>> well known in the technical Bitcoin space. 
>>>
>>> I am not quite convinced that adding three PQ schemes to the Bitcoin 
>>> consensus 
>>> protocol is a great solution to the problem of not being sure which 
>>> exact scheme 
>>> to pick. Offloading this decision to users does not really solve this 
>>> problem. 
>>> Moreover, this adds massive complexity and new cryptographic assumptions 
>>> to the 
>>> protocol. Remember that one of the main motivations behind libsecp256k1, 
>>> was 
>>> that general purpose cryptographic libraries are not well suited for 
>>> consensus 
>>> systems. So all new cryptographic schemes added to the consensus 
>>> protocol need 
>>> to be exceptionally well specified and implemented. That said, it makes 
>>> a lot of 
>>> sense to design a hybrid scheme that also provides security against a 
>>> classic 
>>> attacker through an established signature scheme (as BIP 360 proposes). 
>>>
>>> Lastly, I agree that non-interactive aggregation of PQ schemes might be 
>>> promising, as it could mitigate about signature size and verification 
>>> cost if 
>>> aggregation is applied on the transaction level. Recently, there has 
>>> been 
>>> progress on the security of aggregating hash-based signatures [1] and 
>>> Falcon 
>>> [2]. 
>>>
>>> [0] https://www.secg.org/sec2-v2.pdf 
>>> [1] https://eprint.iacr.org/2025/055 
>>> [2] https://eprint.iacr.org/2024/311 (Unfortunately, this only beats 
>>> trivial 
>>> aggregation (concatenation of signatures) when the number of signatures 
>>> is 
>>> greater than about 110) 
>>>
>>> Jonas 
>>>
>>> -- 
>> 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+...@googlegroups.com.
>> To view this discussion visit 
>> https://groups.google.com/d/msgid/bitcoindev/16d7adca-a01e-40c5-9570-31967ee339ecn%40googlegroups.com 
>> <https://groups.google.com/d/msgid/bitcoindev/16d7adca-a01e-40c5-9570-31967ee339ecn%40googlegroups.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/9d6f01ca-9fab-4638-b59b-64db6301c2dbn%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 12719 bytes --]

Re: [bitcoindev] P2QRH / BIP-360 Update

[Hunter Beast]

[-- Attachment #1.1: Type: text/plain, Size: 3999 bytes --]

Hi Jonas,

I think I understand what you're getting at with your first point. The 
thing is, to be able to include arbitrary data in the hashes provided to 
resolve the Merkle tree, it would require an extraordinary amount of 
computation to wind up with enough to store arbitrary data. And remember, 
this is competing with just storing that data in the witness, so it has to 
be 4x more economical. Consider a 1/1024 multisig, and the key being spent 
is at the furthest depth in the tree. This means that they would need to 
grind generating an elliptic curve public key in the hopes of getting a 
hash collision just to include 11 hashes, or 352 bytes of arbitrary data. 
This would also have to be a valid public key and signature pair. I don't 
see this approach as being practical.

As for your second point, a 256 bit hash provides 128 bits of security, 
correct? If so, I think that's still fine. Others in this thread have 
commented that 256 bits is overkill.

Hunter

On Monday, February 24, 2025 at 8:27:53 AM UTC-7 Jonas Nick wrote:

> What prevents arbitrary data being hashed and then included in the 
attestation 
> is, each signature public key pair must be able to verify the transaction 
> message in order to be considered a valid transaction. 

This appears to contradict the selective disclosure mechanism described in 
the 
BIP and this sentence in the "Script Validation" section: 

> Public keys that are not needed can be excluded by including their hash 
in the 
> attestation accompanied with an empty signature 

Even if the selective disclosure vulnerability is fixed by committing to 
the 
multisig semantics in the P2QRH output, any unopened public key commitment 
could 
still be "abused" for arbitrary data storage. Similar to the scenario in my 
previous post, if the root R is MerkleRoot([leafhash1, leafhash2]) and the 
multisig policy is "1-of-2", then we can set 

leafhash1 := data 
leafhash2 := hash(public_key_secp256k1) 

and post the data to the chain by spending the output using an attestation 
structure that includes leafhash1, an empty signature, public_key_secp256k1 
and 
the corresponding signature. 

> I will admit I don't understand this attack. Can you provide more details 
on 
> how it works, and how it might be possible to mitigate? 

To give more context, this attack is intended as a concrete demonstration 
of how 
breaking the collision resistance of the hash function used in the Merkle 
tree 
can enable an adversary to steal coins. Here's a different explanation for 
essentially the same attack in the context of P2SH vs. P2WSH: 
https://bitcoin.stackexchange.com/a/54847/35586 

The attack against the BIP's proposed signature scheme (where the Merkle 
tree is 
constructed from public keys and then an ordinary signature scheme is 
applied to 
one or more of the committed public keys) can be mitigated by using a hash 
function with a larger output space (e.g., SHA-512). 

However, I'm not suggesting to do this. My point is that while the BIP aims 
for 
256 bits of security by using NIST strength level V parameters, it does not 
actually achieve that security level (when the adversary can affect any of 
the 
leaves as in multisignatures, for example). 

The Bitcoin protocol relies heavily on collision-resistance of SHA-256, 
which is 
pretty much the definition of NIST strength level II [0]. 

[0] 
https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cryptography-standardization/evaluation-criteria/security-(evaluation-criteria) 

-- 
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/8e1cf1b5-27d1-4510-afec-52fb28959189n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 4998 bytes --]

Re: [bitcoindev] P2QRH / BIP-360 Update

[Tim Bratton]

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

*Hi Hunter,*

Thanks for sharing your detailed calculations. Your breakdown aligns
closely with what I’ve modeled, and I appreciate the depth you went into on
the chain growth rates and hardware implications.

Yes, it *does include an attestation discount*. I considered the three
primary scenarios you outlined in your analysis:

   1.

   *QuBit16 (16x Attestation Discount):*
   - *~10MB blocks*
      - *~3,000 transactions per block*
      - *~5.6 TPS* (3,000 tx/block ÷ 600 seconds per block)
      - *~500GB annual chain growth*
   2.

   *QuBit64 (64x Attestation Discount):*
   - *~17MB blocks*
      - *~5,000 transactions per block*
      - *~8.3 TPS*
      - *~900GB annual chain growth*
   3.

   *QuBitWit (No Attestation Discount):*
   - *~3.5MB blocks*
      - *~1,000 transactions per block*
      - *~1.7 TPS*
      - *~185GB annual chain growth*


   - The *QuBit64 scenario* offers the *highest TPS (~8.3)* but comes
with *significant
   chain growth (~900GB/year)*, which could present hardware challenges for
   personal node operators.
   - The *QuBit16 scenario* is a *balanced approach* with *moderate TPS
   (~5.6)* and *more manageable chain growth (~500GB/year)*.
   - Without an attestation discount (*QuBitWit*), the TPS drops
   dramatically to *~1.7*, although this would keep storage growth more
   manageable.


   - Given Bitcoin’s current TPS is around *7* (with SegWit and Taproot
   improvements), the *QuBit64 scenario* would provide a *comparable
   throughput* with the added benefit of quantum resistance.
   - However, the *hardware demands* (with nearly *1TB of chain growth per
   year*) could limit *decentralization* if smaller node operators struggle
   to keep up.
   - The *QuBit16 approach* feels like a *sweet spot*, offering *decent TPS*
   and a *storage growth rate* that aligns better with current node
   capabilities.


   - *Consensus Preference:* Exchanges and miners, having the most at
   stake, would likely favor *higher TPS (QuBit64)* for operational
   efficiency.
   - *Node Decentralization:* From a decentralization perspective, *QuBit16*
   might be more appealing due to lower storage demands.
   - *Future Hardware Improvements:* As *8TB+ NVMe drives* become more
   accessible and affordable, the higher chain growth rates may become less
   concerning.

Would love to hear if others in the community lean toward maximizing TPS (
*QuBit64*) or maintaining lower storage requirements (*QuBit16*). Also, how
much would decentralization concerns influence the final consensus here?




On Tue, Feb 25, 2025 at 12:25 PM Ian Quantum <ianquantum2027@gmail.com>
wrote:

> FALCON+ is more likely to get NIST approval. They struggled to get the
> algorithm over "80 bits of security" even with a significant set of
> improvements. I don't know if this affects the aggregation features, it
> would take significant research. The dramatic security improvements of
> FALCON+ only cost 5% and 0 bytes additional overhead.
> https://eprint.iacr.org/2024/1769.pdf
>
> SECP256k1 had significant reductions to it's security over the last 16
> years but none of the attacks detailed by Bernstein directly impact the
> security as implemented into Bitcoin. (Mitigations and non-interactive
> signing, salt and hash were excellent design choices.)
>
> I would suggest delaying FALCON or FALCON+ until standardized. There are
> significant weaknesses but no full break. The brittleness of the random
> numbers, exposure to inverse function and a lot "weaker than expected"
> parameters would suggest caution. Once standardized I would suggest rapid
> implementation but not until then.
>
> NTRU Prime is a favored alternate candidate of mine, as communicated
> previously. Cryptographers suspect that NIST has again inserted PQC
> backdoors following the last 3 public key standards being standardized with
> very suspicious parameters. (P224, P256, P384)
>
> I hope we can get some momentum around protecting Bitcoin. 1-6 million
> (depending on estimate) BTC have known public keys and while most could
> transfer to p2pkh the creation of quantum safe addresses is a strong
> signal. The implementation of post quantum cryptography is also required by
> many government agencies around the world, including the White House.
> Ian Smith
> Migrate to Quantum Safety before 2027
>
> On Mon, Feb 24, 2025, 12:53 AM Hunter Beast <hunter@surmount.systems>
> wrote:
>
>> Hi Jonas,
>>
>> On Selective Disclosure,
>>
>> I think we're going to need to add simple multisig semantics to the
>> attestation due to its lack of script capability. Would that help? Separate
>> multisig semantics like quorum and total would be needed for each class of
>> key, so that even if Schnorr signatures can be broken (or one or two of the
>> other PQC signatures even), they don't count towards the quorum of the
>> other signature types.
>>
>> On Attestation structure,
>>
>> What prevents arbitrary data being hashed and then included in the
>> attestation is, each signature public key pair must be able to verify the
>> transaction message in order to be considered a valid transaction. In other
>> words, each public key and signature pair is validated against the
>> transaction message upon transaction verification.
>>
>> On Multisignature 256-bit security,
>>
>> To be honest, I've read this a couple of times and I will admit I don't
>> understand this attack. Can you provide more details on how it works, and
>> how it might be possible to mitigate?
>>
>> On General comments,
>>
>> I agree with the worst-case transaction verification concern. I'll need
>> to put some work into detailing NIST I variants and their signature
>> verification times, and then computing worst-case scenarios for different
>> discount constants.
>>
>> On 128-bit security... Yes, I'm coming to realize that too. It's been a
>> common point of feedback.
>>
>> On adding three schemes, there are a couple of advantages of this. First,
>> wallets can automatically decide how many signatures to add based on the
>> amount being spent. This then acts as a sort of MEV opportunity for miners,
>> because the higher the value of the transaction, the more signatures might
>> be included, which increases fee revenue. Also, it addresses Matt's concern
>> about security assumptions. There's a strong desire for SLH-DSA support,
>> even though it's so large. However, from a practicality standpoint
>> (thinking of plebs), it will make sense to include the smaller ML-DSA and
>> FN-DSA also. While it does increase complexity, I believe that a
>> libbitcoinpqc library, as mentioned in the BIP, will serve as a useful
>> analogue to libsecp256k1. It's also worth noting that in my position at
>> Anduro, I have resources to put into building such a library. Hopefully
>> this can help meet the expectation of a well specified and implemented
>> consensus level library.
>>
>> On signature aggregation, yes, I'm excited to see those developments in
>> FN-DSA, and maybe we can see that filter into SLH-DSA as well. Hopefully
>> those improvements will be ready once the time comes to activate.
>>
>>
>>
>> On Friday, February 21, 2025 at 3:18:35 AM UTC-7 Jonas Nick wrote:
>>
>>> Hi Hunter,
>>>
>>> Thanks for your work on BIP 360. I think now is a good time to develop
>>> and
>>> discuss concrete PQ proposals. I have a few questions and comments
>>> regarding
>>> some aspects of the proposal:
>>>
>>> Selective disclosure
>>> ---
>>>
>>> From, the output contains a root of a Merkle tree of public key hashes
>>> and
>>> spending from this output requires revealing the public keys and their
>>> corresponding valid signatures. More concretely, if the user creates
>>> root
>>>
>>> R = MerkleRoot([hash(public_key_falcon_1024),
>>> hash(public_key_secp256k1)]),
>>>
>>> they can spend from R by revealing both public keys and corresponding
>>> signatures.
>>>
>>> The BIP also mentions that the public keys can be selectively disclosed:
>>>
>>> > When spending, if a public key hash is provided in the attestation
>>> with an
>>> > empty signature, that hash will be used directly in the merkle tree
>>> computation
>>> > rather than hashing the full public key.
>>>
>>> What prevents an quantum adversary, upon observing a spend from R, from
>>> breaking
>>> public_key_secp256k1 and then spending from R by providing
>>>
>>> [
>>> hash(public_key_falcon_1024),
>>> empty string,
>>> public_key_secp256k1,
>>> a secp256k1 signature forgery
>>> ]?
>>>
>>>
>>> Attestation structure
>>> ---
>>>
>>> The BIP proposes to an attestation structure alongside the witness which
>>> is
>>> supposed to contain BIP 360 public keys and signatures (instead having
>>> them in
>>> the witness). The purpose of this structure is to assign a higher weight
>>> discount than the witness. The "Rationale" and "Output Mechanics"
>>> sections the
>>> BIP describe that, since the attestation structure only contains public
>>> keys and
>>> signatures, storage of arbitrary data ("inscriptions") is prevented.
>>>
>>> Leaving aside that there may be creative ways to embed arbitrary data in
>>> public
>>> keys and signatures as well, selective disclosure of the Merkle tree
>>> appears to
>>> allow embedding arbitrary data. For instance, a user can create root
>>>
>>> R = MerkleRoot(data, hash(public_key_secp256k1)]),
>>>
>>> where data is an arbitrary 256-bit string. What prevents the user from
>>> pretending that data is the hash of a public key and providing
>>>
>>> [
>>> data,
>>> empty string,
>>> public_key_secp256k1,
>>> a secp256k1 signature forgery
>>> ]
>>>
>>> in the attestation structure to spend from R?
>>>
>>>
>>> Multi-signature 256-bit security
>>> ---
>>>
>>> The BIP briefly discusses multi-signature scenarios in the script
>>> validation
>>> section, but the details seem incomplete. From what I can infer, the
>>> current
>>> specification fails to achieve the claimed 256-bit security.
>>>
>>> The potential attack would work as follows:
>>> 1. The victim provides their public key pk to the adversary.
>>> 2. The adversary finds two public keys pk' and pk'' such that
>>> MerkleRoot(MultiSig[pk, pk']) = MerkleRoot([pk''])
>>> 3. The adversary convinces the victim to send coins to
>>> MerkleRoot(MultiSig[pk,
>>> pk']) and then steals the coins by opening the Merkle tree root to
>>> [pk''] and
>>> providing a signature for pk''.
>>>
>>> Since the Merkle root is the 256-bit output of SHA256, the adversary can
>>> find
>>> this collision with about 2^128 operations.
>>>
>>> If I remember correctly, this attack was discussed on the mailing list
>>> in the
>>> context of segwit and it's the reason why P2WSH (unlike P2PKH) requires
>>> 256-bit
>>> hashes.
>>>
>>>
>>> General comments
>>> ---
>>>
>>> I think one of the main questions that the BIP does not currently
>>> address is how
>>> it affects the worst-case validation cost of a block.
>>>
>>> Regarding your question:
>>> > But if the intention was for 256 bits of security, should level V
>>> security be
>>> > the default?
>>>
>>> I don't know what Satoshi's intentions were, but the secp256k1
>>> specification
>>> clearly indicates 128-bit "strength" ([0], Table 1). I believe that's
>>> fairly
>>> well known in the technical Bitcoin space.
>>>
>>> I am not quite convinced that adding three PQ schemes to the Bitcoin
>>> consensus
>>> protocol is a great solution to the problem of not being sure which
>>> exact scheme
>>> to pick. Offloading this decision to users does not really solve this
>>> problem.
>>> Moreover, this adds massive complexity and new cryptographic assumptions
>>> to the
>>> protocol. Remember that one of the main motivations behind libsecp256k1,
>>> was
>>> that general purpose cryptographic libraries are not well suited for
>>> consensus
>>> systems. So all new cryptographic schemes added to the consensus
>>> protocol need
>>> to be exceptionally well specified and implemented. That said, it makes
>>> a lot of
>>> sense to design a hybrid scheme that also provides security against a
>>> classic
>>> attacker through an established signature scheme (as BIP 360 proposes).
>>>
>>> Lastly, I agree that non-interactive aggregation of PQ schemes might be
>>> promising, as it could mitigate about signature size and verification
>>> cost if
>>> aggregation is applied on the transaction level. Recently, there has
>>> been
>>> progress on the security of aggregating hash-based signatures [1] and
>>> Falcon
>>> [2].
>>>
>>> [0] https://www.secg.org/sec2-v2.pdf
>>> [1] https://eprint.iacr.org/2025/055
>>> [2] https://eprint.iacr.org/2024/311 (Unfortunately, this only beats
>>> trivial
>>> aggregation (concatenation of signatures) when the number of signatures
>>> is
>>> greater than about 110)
>>>
>>> Jonas
>>>
>>> --
>> 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/16d7adca-a01e-40c5-9570-31967ee339ecn%40googlegroups.com
>> <https://groups.google.com/d/msgid/bitcoindev/16d7adca-a01e-40c5-9570-31967ee339ecn%40googlegroups.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/CA%2B7C%2BcYY_97y_QsSON5U3y7v4a0usGaGmcD%2Br%3D8Y05p5Cwmp5w%40mail.gmail.com
> <https://groups.google.com/d/msgid/bitcoindev/CA%2B7C%2BcYY_97y_QsSON5U3y7v4a0usGaGmcD%2Br%3D8Y05p5Cwmp5w%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/CABfMNdL9XDBCM4fw9wpGDj8e9yJh%2B-6F6%3DQA8i5MUS%3Dbj1Pcrw%40mail.gmail.com.

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

Re: [bitcoindev] P2QRH / BIP-360 Update

[Jonas Nick]

 > it would require an extraordinary amount of computation to wind up with enough
 > to store arbitrary data.

I have no idea why this would require extraordinary amount of computation. In
the example I provided, arbitrary data can be included in the attestation
structure with zero additional computational cost, no elliptic curve grinding or
hash collisions required.

-- 
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/69ab395f-acba-4d11-87ee-9da6327509c6%40gmail.com.

Re: [bitcoindev] P2QRH / BIP-360 Update

[Matt Corallo]

I think you're approaching this from the wrong stance.

If our goal is to "make bitcoin Quantum-secure", its gonna take a decade for the state of PQ 
research to build something that's ready for us to "just switch to". I don't buy that there's a 
world where we get serious about adding something lattice-based to Bitcoin for a longggg time (I'm 
not sure I've ever heard a serious cryptographer suggest that lattice-based systems are a good idea, 
rather than "a good thing to layer on top of a traditional non-PQC scheme").

In the short-term, the only (remotely-practical) thing we can do is add something that we have high 
confidence will still be secure in two decades (which basically is only hash-based schemes) and get 
wallets to include it in their taproot outputs. That gives wallets created today the possibility of 
being robust in a QC world, but, indeed, it would require tough decisions in the future.

If your view is that Bitcoin would simply be fine if we didn't confiscate any coins in response to a 
practical QC stealing 5% of total supply, I'm not really convinced, but we can also make it a 
version-2 segwit output ("taproot but a future softfork can freely freeze the keypath spends") if 
you really feel strongly.

TBH the whole "would we confiscate if the time comes" question I think simply cannot be answered 
today because it depends very, very much on specific details (eg lets say we did the above proposal 
and its been around for 30 years and ~all wallets support it, that's a very very different world 
from, for example, deploying some PQC scheme under threat where a QC could realistically steal coins 
in five years). The only thing we can really do today is create the option in the future, we cannot 
decide for the future what to do.

Matt

On 2/23/25 3:33 PM, Hunter Beast wrote:
> Hi Matt,
> 
> The only problem with that approach is that SLH-DSA signatures are quite large. NIST has also 
> approved ML-DSA and FN-DSA, which, while both are based on lattice cryptography, they're not only 
> standardized, but becoming widely supported. One consideration is hardware acceleration, and I 
> believe those three algorithms will have the best chance of having hardware implementations as PQC 
> extensions are added to CPUs and SoCs.
> 
> As for gating P2TR, the problem with that approach is that keypath spends would need to be disabled 
> and that has a confiscatory effect that I'm seeking to avoid in this BIP.
> 
> An additional opcode should not be necessary if multisig capability is built into the attestation.
> 
> I agree with your statement on full BIP-32 compatibility. BIP-360 is just a starting point, and 
> maybe you're right, it's best thought of as a "break glass" implementation. It's not ideal, it's 
> full of compromises, not everyone is 100% happy with it, and that's probably okay, because bitcoin 
> isn't perfect-- but it doesn't have to be in order to work.
> 
> Thank you for your thoughts.
> 
> Hunter
> 
> On Friday, February 21, 2025 at 3:18:21 AM UTC-7 Matt Corallo wrote:
> 
>     If we want to do something like this in the short to medium term, IMO we should strip out all the
>     signature schemes that are anything more than quite straightforward in their security assumptions
>     (i.e. only keep hash-based signatures, maybe just SPHINCS+), only embed them in a taproot leaf, and
>     call it a day.
> 
>     BIP 32 compatibility isn't a really huge deal if we're talking about an "emergency break glass"
>     kinda setup - most wallets are set up with a root key and can just embed the same PQ pubkey in all
>     of their outputs. The privacy cost is only realized in a break glass case, and long before then
>     hopefully whatever we do today is replaced with something better, with the knowledge that we'll
>     gain
>     on the way to "then". We'd still want to do it in an opcode so that we can do multisig, though.
> 
>     Matt
> 
>     On 2/19/25 10:40 AM, Hunter Beast wrote:
>      > Dear Bitcoin Dev Community,
>      >
>      >
>      > A bit over six months after introducing the P2QRH proposal (now BIP-360), I'm writing to share
>      > significant developments and request additional feedback on our post-quantum roadmap, and I'd
>     also
>      > like to mention a potential P2TRH post-quantum mitigation strategy.
>      >
>      >
>      > First, now that there's a BIP number assigned, you can find the update BIP here:
>      >
>      > https://github.com/cryptoquick/bips/blob/p2qrh/bip-0360.mediawiki <https://github.com/
>     cryptoquick/bips/blob/p2qrh/bip-0360.mediawiki> <https://github.com/cryptoquick/ <https://
>     github.com/cryptoquick/>
>      > bips/blob/p2qrh/bip-0360.mediawiki>
>      >
>      >
>      > The revised BIP-360 draft reflects substantial changes since initial publication, particularly
>      > regarding algorithm selection. While we originally considered SQIsign, it has 15,000x slower
>      > verification compared to ECC [1]. If it takes 1 second to verify a fully ECC block, it would
>     take 4
>      > hours to validate a block filled with SQIsign transactions. This has obvious and concerning DDoS
>      > implications.
>      >
>      >
>      > While it would take a long time to signmany thousands of SQIsign transactions as well, the
>     increased
>      > time needed to sign the transactions likely won’t affect the practicality of DDoS attacks--
>     another
>      > concern which has been brought to my attention. As such, I've decided to deprecate SQIsign
>     from the BIP.
>      >
>      >
>      > It's worth mentioning because it was brought up in the PR, there's a new class of algorithms
>     that
>      > support signature aggregation, but they generally result in signatures that are still quite
>     large.
>      > Chipmunk and RACCOON are good examples [2], [3]. I do expect that to improve with time. It
>     might be
>      > worthwhile to shorten the list by making signature aggregation a requirement, so as not to
>     regress
>      > too far from Schnorr signatures. That said, I think those capabilities should be introduced in a
>      > separate BIP once they're more mature and worthwhile.
>      >
>      >
>      > Our current shortlist prioritizes FALCON for its signature aggregation potential, with
>     SPHINCS+ and
>      > CRYSTALS-Dilithium as secondary candidates. However, major technical challenges remain,
>     particularly
>      > BIP-32 compatibility issues affecting xpub generation in watch-only wallets, as detailed by
>      > conduition in another mailing list discussion [4], and also, how we should handle multisig
>     wallets.
>      >
>      >
>      > Additionally, I think it's worthwhile to restrict BIP-360 to NIST-approved algorithms to
>     maintain
>      > FIPS compliance. That's because HSMs such as those provided by Securosys already have support
>     for
>      > all three algorithms [5], which is essential for secure deployment of federated L2 treasuries.
>      >
>      >
>      > Presently, for multisigs, we have a merkle tree configuration defined for encumbering the output
>      > with multiple keys. While that's efficient, it's a novel construction. I'm not certain we should
>      > proceed with the merkle tree commitment scheme-- it needs more scrutiny. We could use a sort
>     of P2SH
>      > approach, just modifying the semantics of OP_CHECKMULTISIG in a witness script to alias to
>     public
>      > keys in the attestation. But that could introduce additional overhead in a signature scheme that
>      > already uses a lot more space. Without this, however, we do not yet have a way specified to
>     indicate
>      > thresholds or a locking script for the attestation, as it is designed to be purposely
>     limited, so as
>      > specified it is only capable of n/n multisig. I consider m/n multisigs to be the single largest
>      > obvious omission in the spec right now. It definitely needs more thought and I'm open to
>      > suggestions. Perhaps two additional bytes at the top level of the SegWit v3 output hash could be
>      > provided to indicate PQC signature threshold and total, and those would be hashed and
>     committed to
>      > in the output, then provided in a field in the attestation once spent.
>      >
>      >
>      > While finalizing PQC selections, I've also drafted P2TRH as an interim solution to secure
>     Taproot
>      > keypath spends without disabling them, as Matthew Corallo proposes in the aforementioned mailing
>      > list thread [4]. The P2TRH approach hashes public keys rather than exposing them directly,
>      > particularly benefiting:
>      >
>      >
>      > - MuSig2 Lightning channel implementations
>      >
>      > - FROST-based MPC vaults
>      >
>      > - High-value transactions using private pools that don't reveal the block template
>      >
>      >
>      > For those interested, take a look at the draft BIP for P2TRH here: https://github.com/
>     cryptoquick/ <https://github.com/cryptoquick/>
>      > bips/blob/p2trh/bip-p2trh.mediawiki <https://github.com/cryptoquick/bips/blob/p2trh/bip-
>     p2trh.mediawiki <https://github.com/cryptoquick/bips/blob/p2trh/bip-p2trh.mediawiki>>
>      >
>      >
>      > I have my hands full with P2QRH advocacy and development and would prefer to focus on that,
>     but I
>      > wanted to introduce P2TRH in case that is attractive as the community's preferred solution-- at
>      > least for Taproot quantum security. The tradeoff is that it adds 8.25 vB of overhead per
>     input, and
>      > key tweaking might have slightly less utility for some applications, and it also doesn't protect
>      > against short exposure quantum attacks as defined in BIP-360.
>      >
>      >
>      > Returning to P2QRH and what's needed to push it across the finish line...
>      >
>      >
>      > I still need to finish the test vectors. I'm implementing these using a fork of rust-bitcoin and
>      > modeling them after Steven Roose's work on BIP-346. I've been told that's not a blocker for
>     merging
>      > the draft, but if it isn't merged by the time I'm finished, hopefully that will provide some
>      > additional impetus behind it.
>      >
>      >
>      > One concern Murch brought up is that introducing four new algorithms into the network was too
>     many--
>      > adding too much complexity to the network and to wallets and other applications-- and I agree.
>      >
>      >
>      > Hopefully this is addressed to some degree by removing SQIsign (especially in its current state
>      > lacking implementation maturity), and will help push the BIP below a certain complexity
>     threshold,
>      > making it somewhat easier to review.
>      >
>      > I think it's still important to include multiple signature algorithm options for users to select
>      > their desired level of security. It's not 100% certain that all of these algorithms will remain
>      > quantum resistant for all time, so redundancy here is… key.
>      >
>      >
>      > Another concern is that NIST level V is overkill. I have less conviction on this since secp256k1
>      > technically has 128 bits of security due to Pollard's rho attacks. But if the intention was
>     for 256
>      > bits of security, should level V security be the default? It's difficult for me to say.
>     Perhaps both
>      > level V and level I implementations could be included, but this would be a deviation from the
>     BIP as
>      > presently specified, which defaults to level V security. The disadvantage of including level I
>      > support for each algorithm is that it essentially doubles the complexity of libbitcoinpqc.
>      >
>      >
>      > Ultimately, I hope the default of NIST V and selection of 3 mature NIST-approved algorithms
>      > demonstrate a focused, polished, and conservative proposal.
>      >
>      >
>      > At this point, the major call to action I would like to highlight is simply the need for more
>      > feedback from the community. Please review and provide feedback here: https://github.com/
>     bitcoin/ <https://github.com/bitcoin/>
>      > bips/pull/1670 <https://github.com/bitcoin/bips/pull/1670 <https://github.com/bitcoin/bips/
>     pull/1670>>
>      >
>      >
>      > I look forward to feedback and opinions on P2QRH and P2TRH.
>      >
>      >
>      > P.S. I'll be advocating for BIP-360 at OP_NEXT in VA, btc++ in Austin, Consensus in Toronto,
>     and BTC
>      > 25 in Las Vegas, and later this year, TABConf in Atlanta.
>      >
>      >
>      >
>      > [1] https://pqshield.github.io/nist-sigs-zoo <https://pqshield.github.io/nist-sigs-zoo>
>      >
>      > [2] https://eprint.iacr.org/2023/1820.pdf <https://eprint.iacr.org/2023/1820.pdf>
>      >
>      > [3] https://eprint.iacr.org/2024/1291.pdf <https://eprint.iacr.org/2024/1291.pdf>
>      >
>      > [4] https://groups.google.com/g/bitcoindev/c/8O857bRSVV8/m/7uu4dZNgAwAJ <https://
>     groups.google.com/g/bitcoindev/c/8O857bRSVV8/m/7uu4dZNgAwAJ>
>      >
>      > [5] https://docs.securosys.com/tsb/Tutorials/Post-Quantum-Cryptography/pqc-release-overview
>     <https://docs.securosys.com/tsb/Tutorials/Post-Quantum-Cryptography/pqc-release-overview>
>      >
>      >
>      > --
>      > 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+...@googlegroups.com <mailto:bitcoindev+...@googlegroups.com>.
>      > To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/8797807d-
>     e017-44e2- <https://groups.google.com/d/msgid/bitcoindev/8797807d-e017-44e2->
>      > b419-803291779007n%40googlegroups.com <http://40googlegroups.com> <https://groups.google.com/
>     d/msgid/bitcoindev/8797807d- <https://groups.google.com/d/msgid/bitcoindev/8797807d->
>      > e017-44e2-b419-803291779007n%40googlegroups.com?utm_medium=email&utm_source=footer
>     <http://40googlegroups.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 <mailto:bitcoindev+unsubscribe@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/866ee206-4a4e-4cd6-9de3- 
> fa2fa35e2230n%40googlegroups.com <https://groups.google.com/d/msgid/ 
> bitcoindev/866ee206-4a4e-4cd6-9de3-fa2fa35e2230n%40googlegroups.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/2e0fc337-3603-4a22-8056-59cf7e21aa43%40mattcorallo.com.

Re: [bitcoindev] P2QRH / BIP-360 Update

[Dustin Ray]

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

Matt, you make a potent and salient point. I think that when we survey the
current state of existing pqc solutions and try to apply them to bitcoin,
we keep coming up with either a massive chain, massive key sizes, extremely
degraded performance, confiscation, or some combination of those.

I think laying the groundwork for this inevitable task now is important,
but if I understand your points correctly, I would agree that existing
solutions do not seem equipped to carry bitcoin into the post quantum
landscape.

On Thu, Feb 27, 2025 at 6:41 PM Matt Corallo <lf-lists@mattcorallo.com>
wrote:

> I think you're approaching this from the wrong stance.
>
> If our goal is to "make bitcoin Quantum-secure", its gonna take a decade
> for the state of PQ
> research to build something that's ready for us to "just switch to". I
> don't buy that there's a
> world where we get serious about adding something lattice-based to Bitcoin
> for a longggg time (I'm
> not sure I've ever heard a serious cryptographer suggest that
> lattice-based systems are a good idea,
> rather than "a good thing to layer on top of a traditional non-PQC
> scheme").
>
> In the short-term, the only (remotely-practical) thing we can do is add
> something that we have high
> confidence will still be secure in two decades (which basically is only
> hash-based schemes) and get
> wallets to include it in their taproot outputs. That gives wallets created
> today the possibility of
> being robust in a QC world, but, indeed, it would require tough decisions
> in the future.
>
> If your view is that Bitcoin would simply be fine if we didn't confiscate
> any coins in response to a
> practical QC stealing 5% of total supply, I'm not really convinced, but we
> can also make it a
> version-2 segwit output ("taproot but a future softfork can freely freeze
> the keypath spends") if
> you really feel strongly.
>
> TBH the whole "would we confiscate if the time comes" question I think
> simply cannot be answered
> today because it depends very, very much on specific details (eg lets say
> we did the above proposal
> and its been around for 30 years and ~all wallets support it, that's a
> very very different world
> from, for example, deploying some PQC scheme under threat where a QC could
> realistically steal coins
> in five years). The only thing we can really do today is create the option
> in the future, we cannot
> decide for the future what to do.
>
> Matt
>
> On 2/23/25 3:33 PM, Hunter Beast wrote:
> > Hi Matt,
> >
> > The only problem with that approach is that SLH-DSA signatures are quite
> large. NIST has also
> > approved ML-DSA and FN-DSA, which, while both are based on lattice
> cryptography, they're not only
> > standardized, but becoming widely supported. One consideration is
> hardware acceleration, and I
> > believe those three algorithms will have the best chance of having
> hardware implementations as PQC
> > extensions are added to CPUs and SoCs.
> >
> > As for gating P2TR, the problem with that approach is that keypath
> spends would need to be disabled
> > and that has a confiscatory effect that I'm seeking to avoid in this BIP.
> >
> > An additional opcode should not be necessary if multisig capability is
> built into the attestation.
> >
> > I agree with your statement on full BIP-32 compatibility. BIP-360 is
> just a starting point, and
> > maybe you're right, it's best thought of as a "break glass"
> implementation. It's not ideal, it's
> > full of compromises, not everyone is 100% happy with it, and that's
> probably okay, because bitcoin
> > isn't perfect-- but it doesn't have to be in order to work.
> >
> > Thank you for your thoughts.
> >
> > Hunter
> >
> > On Friday, February 21, 2025 at 3:18:21 AM UTC-7 Matt Corallo wrote:
> >
> >     If we want to do something like this in the short to medium term,
> IMO we should strip out all the
> >     signature schemes that are anything more than quite straightforward
> in their security assumptions
> >     (i.e. only keep hash-based signatures, maybe just SPHINCS+), only
> embed them in a taproot leaf, and
> >     call it a day.
> >
> >     BIP 32 compatibility isn't a really huge deal if we're talking about
> an "emergency break glass"
> >     kinda setup - most wallets are set up with a root key and can just
> embed the same PQ pubkey in all
> >     of their outputs. The privacy cost is only realized in a break glass
> case, and long before then
> >     hopefully whatever we do today is replaced with something better,
> with the knowledge that we'll
> >     gain
> >     on the way to "then". We'd still want to do it in an opcode so that
> we can do multisig, though.
> >
> >     Matt
> >
> >     On 2/19/25 10:40 AM, Hunter Beast wrote:
> >      > Dear Bitcoin Dev Community,
> >      >
> >      >
> >      > A bit over six months after introducing the P2QRH proposal (now
> BIP-360), I'm writing to share
> >      > significant developments and request additional feedback on our
> post-quantum roadmap, and I'd
> >     also
> >      > like to mention a potential P2TRH post-quantum mitigation
> strategy.
> >      >
> >      >
> >      > First, now that there's a BIP number assigned, you can find the
> update BIP here:
> >      >
> >      > https://github.com/cryptoquick/bips/blob/p2qrh/bip-0360.mediawiki
> <https://github.com/
> >     cryptoquick/bips/blob/p2qrh/bip-0360.mediawiki> <
> https://github.com/cryptoquick/ <https://
> >     github.com/cryptoquick/>
> >      > bips/blob/p2qrh/bip-0360.mediawiki>
> >      >
> >      >
> >      > The revised BIP-360 draft reflects substantial changes since
> initial publication, particularly
> >      > regarding algorithm selection. While we originally considered
> SQIsign, it has 15,000x slower
> >      > verification compared to ECC [1]. If it takes 1 second to verify
> a fully ECC block, it would
> >     take 4
> >      > hours to validate a block filled with SQIsign transactions. This
> has obvious and concerning DDoS
> >      > implications.
> >      >
> >      >
> >      > While it would take a long time to signmany thousands of SQIsign
> transactions as well, the
> >     increased
> >      > time needed to sign the transactions likely won’t affect the
> practicality of DDoS attacks--
> >     another
> >      > concern which has been brought to my attention. As such, I've
> decided to deprecate SQIsign
> >     from the BIP.
> >      >
> >      >
> >      > It's worth mentioning because it was brought up in the PR,
> there's a new class of algorithms
> >     that
> >      > support signature aggregation, but they generally result in
> signatures that are still quite
> >     large.
> >      > Chipmunk and RACCOON are good examples [2], [3]. I do expect that
> to improve with time. It
> >     might be
> >      > worthwhile to shorten the list by making signature aggregation a
> requirement, so as not to
> >     regress
> >      > too far from Schnorr signatures. That said, I think those
> capabilities should be introduced in a
> >      > separate BIP once they're more mature and worthwhile.
> >      >
> >      >
> >      > Our current shortlist prioritizes FALCON for its signature
> aggregation potential, with
> >     SPHINCS+ and
> >      > CRYSTALS-Dilithium as secondary candidates. However, major
> technical challenges remain,
> >     particularly
> >      > BIP-32 compatibility issues affecting xpub generation in
> watch-only wallets, as detailed by
> >      > conduition in another mailing list discussion [4], and also, how
> we should handle multisig
> >     wallets.
> >      >
> >      >
> >      > Additionally, I think it's worthwhile to restrict BIP-360 to
> NIST-approved algorithms to
> >     maintain
> >      > FIPS compliance. That's because HSMs such as those provided by
> Securosys already have support
> >     for
> >      > all three algorithms [5], which is essential for secure
> deployment of federated L2 treasuries.
> >      >
> >      >
> >      > Presently, for multisigs, we have a merkle tree configuration
> defined for encumbering the output
> >      > with multiple keys. While that's efficient, it's a novel
> construction. I'm not certain we should
> >      > proceed with the merkle tree commitment scheme-- it needs more
> scrutiny. We could use a sort
> >     of P2SH
> >      > approach, just modifying the semantics of OP_CHECKMULTISIG in a
> witness script to alias to
> >     public
> >      > keys in the attestation. But that could introduce additional
> overhead in a signature scheme that
> >      > already uses a lot more space. Without this, however, we do not
> yet have a way specified to
> >     indicate
> >      > thresholds or a locking script for the attestation, as it is
> designed to be purposely
> >     limited, so as
> >      > specified it is only capable of n/n multisig. I consider m/n
> multisigs to be the single largest
> >      > obvious omission in the spec right now. It definitely needs more
> thought and I'm open to
> >      > suggestions. Perhaps two additional bytes at the top level of the
> SegWit v3 output hash could be
> >      > provided to indicate PQC signature threshold and total, and those
> would be hashed and
> >     committed to
> >      > in the output, then provided in a field in the attestation once
> spent.
> >      >
> >      >
> >      > While finalizing PQC selections, I've also drafted P2TRH as an
> interim solution to secure
> >     Taproot
> >      > keypath spends without disabling them, as Matthew Corallo
> proposes in the aforementioned mailing
> >      > list thread [4]. The P2TRH approach hashes public keys rather
> than exposing them directly,
> >      > particularly benefiting:
> >      >
> >      >
> >      > - MuSig2 Lightning channel implementations
> >      >
> >      > - FROST-based MPC vaults
> >      >
> >      > - High-value transactions using private pools that don't reveal
> the block template
> >      >
> >      >
> >      > For those interested, take a look at the draft BIP for P2TRH
> here: https://github.com/
> >     cryptoquick/ <https://github.com/cryptoquick/>
> >      > bips/blob/p2trh/bip-p2trh.mediawiki <
> https://github.com/cryptoquick/bips/blob/p2trh/bip-
> >     p2trh.mediawiki <
> https://github.com/cryptoquick/bips/blob/p2trh/bip-p2trh.mediawiki>>
> >      >
> >      >
> >      > I have my hands full with P2QRH advocacy and development and
> would prefer to focus on that,
> >     but I
> >      > wanted to introduce P2TRH in case that is attractive as the
> community's preferred solution-- at
> >      > least for Taproot quantum security. The tradeoff is that it adds
> 8.25 vB of overhead per
> >     input, and
> >      > key tweaking might have slightly less utility for some
> applications, and it also doesn't protect
> >      > against short exposure quantum attacks as defined in BIP-360.
> >      >
> >      >
> >      > Returning to P2QRH and what's needed to push it across the finish
> line...
> >      >
> >      >
> >      > I still need to finish the test vectors. I'm implementing these
> using a fork of rust-bitcoin and
> >      > modeling them after Steven Roose's work on BIP-346. I've been
> told that's not a blocker for
> >     merging
> >      > the draft, but if it isn't merged by the time I'm finished,
> hopefully that will provide some
> >      > additional impetus behind it.
> >      >
> >      >
> >      > One concern Murch brought up is that introducing four new
> algorithms into the network was too
> >     many--
> >      > adding too much complexity to the network and to wallets and
> other applications-- and I agree.
> >      >
> >      >
> >      > Hopefully this is addressed to some degree by removing SQIsign
> (especially in its current state
> >      > lacking implementation maturity), and will help push the BIP
> below a certain complexity
> >     threshold,
> >      > making it somewhat easier to review.
> >      >
> >      > I think it's still important to include multiple signature
> algorithm options for users to select
> >      > their desired level of security. It's not 100% certain that all
> of these algorithms will remain
> >      > quantum resistant for all time, so redundancy here is… key.
> >      >
> >      >
> >      > Another concern is that NIST level V is overkill. I have less
> conviction on this since secp256k1
> >      > technically has 128 bits of security due to Pollard's rho
> attacks. But if the intention was
> >     for 256
> >      > bits of security, should level V security be the default? It's
> difficult for me to say.
> >     Perhaps both
> >      > level V and level I implementations could be included, but this
> would be a deviation from the
> >     BIP as
> >      > presently specified, which defaults to level V security. The
> disadvantage of including level I
> >      > support for each algorithm is that it essentially doubles the
> complexity of libbitcoinpqc.
> >      >
> >      >
> >      > Ultimately, I hope the default of NIST V and selection of 3
> mature NIST-approved algorithms
> >      > demonstrate a focused, polished, and conservative proposal.
> >      >
> >      >
> >      > At this point, the major call to action I would like to highlight
> is simply the need for more
> >      > feedback from the community. Please review and provide feedback
> here: https://github.com/
> >     bitcoin/ <https://github.com/bitcoin/>
> >      > bips/pull/1670 <https://github.com/bitcoin/bips/pull/1670 <
> https://github.com/bitcoin/bips/
> >     pull/1670>>
> >      >
> >      >
> >      > I look forward to feedback and opinions on P2QRH and P2TRH.
> >      >
> >      >
> >      > P.S. I'll be advocating for BIP-360 at OP_NEXT in VA, btc++ in
> Austin, Consensus in Toronto,
> >     and BTC
> >      > 25 in Las Vegas, and later this year, TABConf in Atlanta.
> >      >
> >      >
> >      >
> >      > [1] https://pqshield.github.io/nist-sigs-zoo <
> https://pqshield.github.io/nist-sigs-zoo>
> >      >
> >      > [2] https://eprint.iacr.org/2023/1820.pdf <
> https://eprint.iacr.org/2023/1820.pdf>
> >      >
> >      > [3] https://eprint.iacr.org/2024/1291.pdf <
> https://eprint.iacr.org/2024/1291.pdf>
> >      >
> >      > [4]
> https://groups.google.com/g/bitcoindev/c/8O857bRSVV8/m/7uu4dZNgAwAJ
> <https://
> >     groups.google.com/g/bitcoindev/c/8O857bRSVV8/m/7uu4dZNgAwAJ>
> >      >
> >      > [5]
> https://docs.securosys.com/tsb/Tutorials/Post-Quantum-Cryptography/pqc-release-overview
> >     <
> https://docs.securosys.com/tsb/Tutorials/Post-Quantum-Cryptography/pqc-release-overview
> >
> >      >
> >      >
> >      > --
> >      > 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+...@googlegroups.com <mailto:
> bitcoindev+...@googlegroups.com>.
> >      > To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/8797807d-
> >     e017-44e2- <
> https://groups.google.com/d/msgid/bitcoindev/8797807d-e017-44e2->
> >      > b419-803291779007n%40googlegroups.com <http://40googlegroups.com>
> <https://groups.google.com/
> >     d/msgid/bitcoindev/8797807d- <
> https://groups.google.com/d/msgid/bitcoindev/8797807d->
> >      > e017-44e2-b419-803291779007n%
> 40googlegroups.com?utm_medium=email&utm_source=footer
> >     <http://40googlegroups.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 <mailto:
> bitcoindev+unsubscribe@googlegroups.com>.
> > To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/866ee206-4a4e-4cd6-9de3-
> > fa2fa35e2230n%40googlegroups.com <https://groups.google.com/d/msgid/
> > bitcoindev/866ee206-4a4e-4cd6-9de3-fa2fa35e2230n%
> 40googlegroups.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/2e0fc337-3603-4a22-8056-59cf7e21aa43%40mattcorallo.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/CAC3UE4K1mLaj2AHUcK5S3QB0wtJ40qA-y%2BuEROb3BqxC2_G%2BXA%40mail.gmail.com.

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