we use BIP-459 full aggregation for P2MR or P2TRH, we can recover one of the EC keys of a CISA group, solving its equation for that EC key. This saves 32 bytes per group. If a group is small

merged into BIP360 which amends the spec to change depth-zero trees to be anyone-can-spend. Kudos to Ethan Heilman for this excellent suggestion in response to my OP. P2MR is now much

p2mr-bip-360/2603 > [4]: https://groups.google.com/g/bitcoindev/c/8O857bRSVV8/m/8nr6I5NIAwAJ > [5]: https://groups.google.com/g/bitcoindev/c/p8AVEmAtWdA

worse than BIP360: - It doesn't offer any flexibility with respect to gradual migration. The complete absence of usable EC spending paths would ensure absolutely nobody will

-read BIP360 (it has changed a lot) and look at SHRINCS. > > 1. BIP360 does not introduce any new PQ algos. All it does is add a new > Taproot address that disables the (implied

proponents of BIP-360, which is a literal copypasta of Taproot with the key-path spend hacked out of it. be well, Louise On Thursday, May 21, 2026 at 12:17:56 PM UTC-6 conduition wrote

extends to BIP-352 (Silent Payments) > > Yup, as shown in my latest post, we can batch aggregate multiple claims into a > > single proof. If this were to be deployed at some

we suppose BIP-360 is a prerequisite to my proposal. Which means that all new addresses would be quantum-resistant. Each old-address holder is responsible to migrate to a new quantum

PQC is BIP360 and many invalidly assume its >> disabling of key spend path means "deactivating Schnorr". That's NOT what >> the BIP does: >> >

defense of BIP 360. I think their approach of keeping Taproot's Merkle > tree of BIP 342 Scripts is a fine design, but my argument applies to an output > type that enables a hash

> Using BIP 360, we could have a leaf script for CHECKSIG_DSA1 and a leaf script for CHECKSIG_DSA2. > > > > > > Leaf1: DSA1_PUBKEY, CHECKSIG_DSA1 > > >

Hi List, With the progress of BIP360's P2MR address format, and Ethan's recent thread [1] about cryptographic agility, now seems a good time to

(eg BIP 360). But I'm > unsure if should fail for those, return empty, or use the second final > witness script and hope that convention survives into the future... > >

Taproot or BIP360. And since we will need quantum upgrade at some >>> point, this upgrade is kind of (in my personal interpretation) doubling >>> down to the part

signature opcode BIP following BIP360. > > > > > > https://blog.cloudflare.com/nist-post-quantum-surprise/#floating-points-falcons-achilles > >

. Between BIP360 and something like TXHASH, it's possible to make quantum safe scripts and multi-step commit-reveal vaults that don't relay solely on signatures at all.

that enables BIP-32-like functionality. It achieves this by getting rid of a public key compression step in the OG algorithm that results in a loss of homomorphic properties. There

noticed that BIP360 doesn't appear to specify the exact hash function to be used in SPHINCS BIP360 specifies a new witness version and address format: P2TSH (effectively taproot

this "BIP" would maintain Bitcoin's value as a distributed system. It more-or-less sounds like you're suggesting to vest the power of quantum-recovery using

post-BIP-360 + 2 years) assumes smooth consensus and implementation. Given Bitcoin's history, this could easily stretch to 7-10 years, most likely pushing implementation

parallel: BIP360 and other post-quantum debates which > will eventually lead to the addition of at least one new signature > algorithm to consensus. By the time P256 is standardized

I remember what i was talking about a few weeks back. I was envisioning that all the pubkeys would be merged together across all inputs, but this would

. This BIP deliberately excludes non-NIST submissions like SQISign, which fails to meet basic security requirements upon examination. While ML-DSA (CRYSTALS-Dilithium) shows

context of BIP360: > https://delvingbitcoin.org/t/changes-to-bip-360-pay-to-quantum-resistant-hash-p2qrh/1811/11 > . > > Therefore, our starting position

I misread BIP 173 and bech32 does drop the OP_PUSH32. This answers my question. As an outcome of this conversation BIP 360 no longer uses Witness version 3 but Witness version 2. https

changes to BIP-360 (Pay to Quantum Resistant Hash) PR : - P2QRH (Pay to Quantum Resistant Hash) is now taproot (P2TR) but with the quantum vulnerable key-spend path removed. - PQ signatures

> of BIP-360. SLH-DSA is concering, in that 7/8 arbitrary data would make it >> about on par with the de facto witness discount. I don't want to sacrifice >> SLH-

according to BIP-360 Falcon is cheaper than edDSA per signature verification. EdDSA Cycles to verify: 130000 FALCON-512 Cycles to verify: 81036 This is one of the reasons I am very

that this BIP will become a mistake in Bitcoin in 15 years or > less. > > It adds orders of magnitude to public keys sizes and/or signature sizes; > and verification computation

the existing BIP-360 (Pay to Quantum Resistant Hash) proposal. Both of these proposals aim to protect Bitcoin from potential quantum computing threats, but they approach the problem