* [bitcoindev] Re: In defense of a PQ output type
2026-04-09 18:58 [bitcoindev] In defense of a PQ output type 'Antoine Poinsot' via Bitcoin Development Mailing List
@ 2026-04-09 20:31 ` Dplusplus
2026-04-09 21:17 ` [bitcoindev] " Olaoluwa Osuntokun
2026-04-09 22:46 ` Matt Corallo
2 siblings, 0 replies; 9+ messages in thread
From: Dplusplus @ 2026-04-09 20:31 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 5236 bytes --]
Antoine,
Yes, +1 on decoupling the PQ signature discussion from the "freeze"
discussion.
As one example of what this could look like, P2Q (
https://github.com/casey/bips/blob/280fb529b27949b42721bfbf5f255e67b9a1103b/bip-p2q.md)
formalizes that decoupling. P2Q is a new SegWit version (v3) with spending
rules identical to Taproot today, but with an explicit roadmap: a future
soft fork could disable key-path spending for v3 outputs only, without
touching existing P2TR UTXOs.
Users who send to a P2Q address are deliberately opting in to that future
possibility. The cryptographic decision and the social decision about
unmigrated coins become cleanly separable. It also preserves Schnorr's
benefits (FROST, MuSig2, Taproot channels, etc.) for everyone who wants to
continue using them in the meantime, while P2MR does not.
The part that feels strange to me is the assumption I keep seeing that
SegWit v1 key-path spending will "simply" be disabled in a future soft
fork. That bakes confiscation into the roadmap without ever asking users to
opt in. Whether "freeze" ultimately wins is a decision for the market to
make on its own timeline.
D++
On Thursday, April 9, 2026 at 12:06:19 PM UTC-7 Antoine Poinsot wrote:
> Many of us appear to be in favour of introducing post-quantum signatures to
> Bitcoin via a new Tapscript operation, conditioning the CRQC resistance on
> a
> future invalidation of Taproot key spends. I would like to offer an
> argument in
> favour of introducing such post-quantum signatures as a new output type
> instead,
> that does not depend on invalidating a spending path on existing outputs.
>
> First of all, it's important to clarify what we are trying to achieve. We
> need
> to accept that, by virtue of being faced with an uncertain existential
> threat to
> the network, there are scenarios, however unlikely, in which the network
> does
> not survive. Not all plausible futures are worth optimizing for. For
> instance,
> one in which PoW ends up broken only a few years after EC crypto, or one
> where
> the entire Bitcoin userbase *must* migrate within a handful of years.
>
> I think there are two futures worth optimizing for primarily:
> - a CRQC never materializes and users can continue benefiting from the
> properties of a Bitcoin network relying on classical cryptographic
> assumptions;
> - a CRQC materializes on a long enough timeframe that PQ signature schemes
> that
> maintain today's properties can be designed, vetted and adopted, and the
> vast
> majority of the userbase migrated.
>
> And because hope is not a strategy, it's important to also have a "break
> glass"
> emergency plan in case a CRQC emerges on a shorter (yet still reasonable)
> timeframe. I think the current proposals for hash-based PQ schemes fit this
> category. If they became the only safe option available, it would
> certainly make
> Bitcoin a lot less attractive. But having them around is good risk
> mitigation
> *regardless* of whether a CRQC emerges.
>
> It's often argued that a freeze will be necessary anyways, therefore we
> might as
> well disable the Taproot keyspend path simultaneously and simply introduce
> the
> PQ scheme today in Tapscript. I personally reject the premise, but more
> importantly i think we should separate the concerns of 1) making a PQ
> scheme
> available and 2) freezing vulnerable coins. Yet introducing a PQ scheme
> inside
> vulnerable Taproot outputs locks us onto the path of eventually freezing
> vulnerable coins, as it will inevitably turn users of the PQ scheme into
> supporters of a freeze.
>
> This approach would tie the availability of a PQ scheme to reaching
> consensus on
> a future freeze. Frankly, i do not believe the latter is achievable, let
> alone
> at this stage with so little evidence that a CRQC will materialize anytime
> soon.
> By contrast, there is a much stronger case for introducing a PQ scheme in
> the
> near term purely as a risk mitigation measure. Coupling the two decisions
> would
> necessarily delay the deployment of a PQ scheme, unnecessarily exacerbating
> risks whether or not CRQCs become a reality.
>
> Another drawback of the PQ output type approach is that it would make those
> outputs distinguishable from Taproot ones, which is suboptimal in the
> event that
> a CRQC never materializes. But i would argue that even in this case, the
> cost is
> minimal. The users most likely to adopt PQ outputs today (those securing
> large
> amounts of BTC with a small set of keys) already have vastly different
> usage
> patterns from Taproot users: they often reuse addresses and use legacy
> output
> types (and show little interest in upgrading).
>
> Best,
> Antoine Poinsot
>
--
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/dbaf0dcf-3a47-4790-b45a-639a22de45b9n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 7896 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoindev] In defense of a PQ output type
2026-04-09 18:58 [bitcoindev] In defense of a PQ output type 'Antoine Poinsot' via Bitcoin Development Mailing List
2026-04-09 20:31 ` [bitcoindev] " Dplusplus
@ 2026-04-09 21:17 ` Olaoluwa Osuntokun
2026-04-09 22:46 ` Matt Corallo
2 siblings, 0 replies; 9+ messages in thread
From: Olaoluwa Osuntokun @ 2026-04-09 21:17 UTC (permalink / raw)
To: Antoine Poinsot; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 7968 bytes --]
Hi Antoine,
TL;DR: "¿Por qué no los dos?"
IMO it isn't really either or re a new PQ output type vs disabling certain
vulnerable spending types with various flavors of a pq secure escape hatch.
Adding a new PQ op codes and/or output types would be a precautionary soft
fork
(ppl to migrate at their leisure), while disabling certain spending paths
w/ an
escape hatch would be an emergency softfork.
Even in the face of the emergency soft fork, PQ safe signature types are
still
needed, otherwise you don't have a "safe" place to sweep those vulnerable
outputs into. Also note that it's possible to create safe escape hatches for
non-Taproot output types as well (assuming a hash function was used to
derive
the private scalar from a seed, commonly BIP-32).
IMO Taproot (in addition to a new type ofc), is still an attractive target
as
there's already so much wallet+signing infrastructure built up around it. So
far the newly proposed output type variants seem to keep much of the bsae of
Taproot which is great, as that'll speed up adoption, but we've already seen
first hand how long it can take a new output type to be adopted.
> I think there are two futures worth optimizing for primarily:
There's also a third future in which there's some _classical_ advancement in
the ECDLP problem, that prompts a move away from EC crypto even without an
actual quantum attacker.
> i think we should separate the concerns of 1) making a PQ scheme available
> and 2) freezing vulnerable coins By contrast, there is a much stronger
case
> for introducing a PQ scheme in the near term purely as a risk mitigation
> measure. Coupling the two decisions would necessarily delay the
deployment
> of a PQ scheme, unnecessarily exacerbating risks whether or not CRQCs
become
> a reality.
I totally agree that a precautionary fork and an emergency for need not be
tied
together. The technical question of which signature scheme(s) to add is much
more straight forward than the politically tinged question of which output
types/utxos to disable spending for.
IMO an important reason to have background development on the "PQ rescue"
fork
details is that invariably there'll be laggards in the adoption of a PQ
output
type even if it was made available _today_.
Consider how many exchanges and custodians rely on variants of HSMs for
secure
signing. If we look at popular offerings like AWS CloudHSM, they now have
support for secp256k1 [1][2], but AFAICT, that was added only around 2019
or so
(can anyone confirm?). Taproot has been active for many years now, but
because
it uses a bespoke signature type (on a relative basis), major providers like
AWS don't have _direct_ support (tho one could prob emulate it with a Nitro
Enclave).
Even if these popular HSM providers had support today (IIRC AWS KMS added
ML-DSA support last year, but not SLH-DSA yet) for the NIST PQ schemes, it
would likely be some time until they added whichever variant(s) (eg:
composite
hash based, hash based with non-standard params for smaller sigs, lattice
based
variants that support BIP-32 hardened derivation) that Bitcoin selects in
the
end.
-- Laolu
[1]:
https://docs.aws.amazon.com/cloudhsm/latest/userguide/pkcs11-key-types.html
[2]:
https://docs.aws.amazon.com/kms/latest/developerguide/symm-asymm-choose-key-spec.html
On Thu, Apr 9, 2026 at 12:06 PM 'Antoine Poinsot' via Bitcoin Development
Mailing List <bitcoindev@googlegroups.com> wrote:
> Many of us appear to be in favour of introducing post-quantum signatures to
> Bitcoin via a new Tapscript operation, conditioning the CRQC resistance on
> a
> future invalidation of Taproot key spends. I would like to offer an
> argument in
> favour of introducing such post-quantum signatures as a new output type
> instead,
> that does not depend on invalidating a spending path on existing outputs.
>
> First of all, it's important to clarify what we are trying to achieve. We
> need
> to accept that, by virtue of being faced with an uncertain existential
> threat to
> the network, there are scenarios, however unlikely, in which the network
> does
> not survive. Not all plausible futures are worth optimizing for. For
> instance,
> one in which PoW ends up broken only a few years after EC crypto, or one
> where
> the entire Bitcoin userbase *must* migrate within a handful of years.
>
> I think there are two futures worth optimizing for primarily:
> - a CRQC never materializes and users can continue benefiting from the
> properties of a Bitcoin network relying on classical cryptographic
> assumptions;
> - a CRQC materializes on a long enough timeframe that PQ signature schemes
> that
> maintain today's properties can be designed, vetted and adopted, and the
> vast
> majority of the userbase migrated.
>
> And because hope is not a strategy, it's important to also have a "break
> glass"
> emergency plan in case a CRQC emerges on a shorter (yet still reasonable)
> timeframe. I think the current proposals for hash-based PQ schemes fit this
> category. If they became the only safe option available, it would
> certainly make
> Bitcoin a lot less attractive. But having them around is good risk
> mitigation
> *regardless* of whether a CRQC emerges.
>
> It's often argued that a freeze will be necessary anyways, therefore we
> might as
> well disable the Taproot keyspend path simultaneously and simply introduce
> the
> PQ scheme today in Tapscript. I personally reject the premise, but more
> importantly i think we should separate the concerns of 1) making a PQ
> scheme
> available and 2) freezing vulnerable coins. Yet introducing a PQ scheme
> inside
> vulnerable Taproot outputs locks us onto the path of eventually freezing
> vulnerable coins, as it will inevitably turn users of the PQ scheme into
> supporters of a freeze.
>
> This approach would tie the availability of a PQ scheme to reaching
> consensus on
> a future freeze. Frankly, i do not believe the latter is achievable, let
> alone
> at this stage with so little evidence that a CRQC will materialize anytime
> soon.
> By contrast, there is a much stronger case for introducing a PQ scheme in
> the
> near term purely as a risk mitigation measure. Coupling the two decisions
> would
> necessarily delay the deployment of a PQ scheme, unnecessarily exacerbating
> risks whether or not CRQCs become a reality.
>
> Another drawback of the PQ output type approach is that it would make those
> outputs distinguishable from Taproot ones, which is suboptimal in the
> event that
> a CRQC never materializes. But i would argue that even in this case, the
> cost is
> minimal. The users most likely to adopt PQ outputs today (those securing
> large
> amounts of BTC with a small set of keys) already have vastly different
> usage
> patterns from Taproot users: they often reuse addresses and use legacy
> output
> types (and show little interest in upgrading).
>
> Best,
> Antoine Poinsot
>
> --
> 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/0vqF88LoOnY4GiUB4vf-MdeZpTAtR70tokS3cLwt2DX0e6_fD1X_wyhPwWEdIdm6R88AULObIU08CWsb5QfeoaM5c4yXPqN5wHyCrqMCtfQ%3D%40protonmail.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/CAO3Pvs8zjQr%2Bn2OnJ1J3M%2B%2BOtx73YNrJW-g9ZCJdOx%3Dq7aixKA%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 9339 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoindev] In defense of a PQ output type
2026-04-09 18:58 [bitcoindev] In defense of a PQ output type 'Antoine Poinsot' via Bitcoin Development Mailing List
2026-04-09 20:31 ` [bitcoindev] " Dplusplus
2026-04-09 21:17 ` [bitcoindev] " Olaoluwa Osuntokun
@ 2026-04-09 22:46 ` Matt Corallo
2026-04-10 17:03 ` 'conduition' via Bitcoin Development Mailing List
2 siblings, 1 reply; 9+ messages in thread
From: Matt Corallo @ 2026-04-09 22:46 UTC (permalink / raw)
To: Antoine Poinsot, Bitcoin Development Mailing List
On 4/9/26 2:58 PM, 'Antoine Poinsot' via Bitcoin Development Mailing List wrote:
> Many of us appear to be in favour of introducing post-quantum signatures to
> Bitcoin via a new Tapscript operation, conditioning the CRQC resistance on a
> future invalidation of Taproot key spends.I would like to offer an argument in
> favour of introducing such post-quantum signatures as a new output type instead,
> that does not depend on invalidating a spending path on existing outputs.
>
> First of all, it's important to clarify what we are trying to achieve. We need
> to accept that, by virtue of being faced with an uncertain existential threat to
> the network, there are scenarios, however unlikely, in which the network does
> not survive. Not all plausible futures are worth optimizing for. For instance,
> one in which PoW ends up broken only a few years after EC crypto, or one where
> the entire Bitcoin userbase *must* migrate within a handful of years.
>
> I think there are two futures worth optimizing for primarily:
> - a CRQC never materializes and users can continue benefiting from the
> properties of a Bitcoin network relying on classical cryptographic
> assumptions;
> - a CRQC materializes on a long enough timeframe that PQ signature schemes that
> maintain today's properties can be designed, vetted and adopted, and the vast
> majority of the userbase migrated.
>
> And because hope is not a strategy, it's important to also have a "break glass"
> emergency plan in case a CRQC emerges on a shorter (yet still reasonable)
> timeframe. I think the current proposals for hash-based PQ schemes fit this
> category. If they became the only safe option available, it would certainly make
> Bitcoin a lot less attractive. But having them around is good risk mitigation
> *regardless* of whether a CRQC emerges.
>
> It's often argued that a freeze will be necessary anyways, therefore we might as
> well disable the Taproot keyspend path simultaneously and simply introduce the
> PQ scheme today in Tapscript. I personally reject the premise, but more
> importantly i think we should separate the concerns of 1) making a PQ scheme
> available and 2) freezing vulnerable coins. Yet introducing a PQ scheme inside
> vulnerable Taproot outputs locks us onto the path of eventually freezing
> vulnerable coins, as it will inevitably turn users of the PQ scheme into
> supporters of a freeze.
You've missed the much-more-important thing that cannot be extricated from disabling insecure spend
paths - the ability to recover from a seedphrase. In any world where a CRQC exists, whether it is
next year or a century from now, there will be a million or two bitcoin in lost-key-wallets and a
nontrivial amount in wallets people haven't touched in ten years but still have keys for. Given a
goal of any migration strategy should be to enable the absolute maximum number of coins to be
retained by their owners (I think this is basically the *only* goal?), enabling seedphrase proof
recovery is pretty critical. Sadly the only way that can be done is through disabling insecure spend
proofs.
But you've also confused unrelated concerns here - whether a hash-based signature is added as a
tapscript opcode or not is not strictly tied to whether a new output type is created. If BIP 360 is
the way bitcoin goes, it *still* needs a new hash-based opcode in tapscript. Maybe more
interestingly, a new taproot "version" could be added which has identical semantics to today's
taproot but signals through an alternative version number (or maybe there's a cleverer way to encode
a bit somewhere that we should prefer) that a PQC pubkey exist in a taproot leaf somewhere so the
insecure spend path should be disabled.
> This approach would tie the availability of a PQ scheme to reaching consensus on
> a future freeze. Frankly, i do not believe the latter is achievable, let alone
> at this stage with so little evidence that a CRQC will materialize anytime soon.
> By contrast, there is a much stronger case for introducing a PQ scheme in the
> near term purely as a risk mitigation measure. Coupling the two decisions would
> necessarily delay the deployment of a PQ scheme, unnecessarily exacerbating
> risks whether or not CRQCs become a reality.
Adding a PQ output type which no one will use (eg one where use of the hash-based signature is
mandatory, which drives fees up hugely and has all the drawbacks you mention) is not a risk
mitigation strategy - it does not materially allow for any migration and doesn't accomplish much of
anything. But as mentioned above I do not see why any addition of hash based signatures to tapscript
should require any kind of community consensus on future disablement of insecure spend paths - not
only is it a likely prerequisite for an alternative output type, but its also (obviously?) not
possible to have any kind of "consensus" on what the future bitcoin community will do. Thus it would
be rather impossible to do *anything* if that were a requirement.
> Another drawback of the PQ output type approach is that it would make those
> outputs distinguishable from Taproot ones, which is suboptimal in the event that
> a CRQC never materializes. But i would argue that even in this case, the cost is
> minimal. The users most likely to adopt PQ outputs today (those securing large
> amounts of BTC with a small set of keys) already have vastly different usage
> patterns from Taproot users: they often reuse addresses and use legacy output
> types (and show little interest in upgrading).
>
> Best,
> Antoine Poinsot
>
--
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/cba894e1-f830-4ad5-9498-09f04faaadf7%40mattcorallo.com.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoindev] In defense of a PQ output type
2026-04-09 22:46 ` Matt Corallo
@ 2026-04-10 17:03 ` 'conduition' via Bitcoin Development Mailing List
2026-04-10 20:33 ` Matt Corallo
0 siblings, 1 reply; 9+ messages in thread
From: 'conduition' via Bitcoin Development Mailing List @ 2026-04-10 17:03 UTC (permalink / raw)
To: Matt Corallo; +Cc: Antoine Poinsot, Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 9759 bytes --]
Hi List,
I second Antoine's position. We can have two distinct fields of R&D proceeding concurrently:
1. Proactive: BIP360/P2MR; PQ signature opcodes; QSB & other scripting tricks
2. Retroactive: Freezing; Hourglass; Rescue protocols like BIP32 STARKs and commit/reveal
The two should be independent, because (1) need not affect inactive holders and legacy coins at all, whereas (2) necessarily does.
In my humble opinion, the proactive field (1) is the much more pressing issue. The sooner we settle on at least one address format and wallet structure for long-term hodling, the sooner PQ-vulnerable UTXOs can start migrating, and the fewer will be stolen or need rescue protocols later.
Though planning ahead for (2) is also important long-term. Laolu's recent development work building and benchmarking concrete BIP32 STARK proofs [1] is a great example. Through this, or a commit/reveal equivalent, maybe combined with an ownership proof used for non-BIP32 hashed addresses, I for one am confident we can catch a majority of exposed bitcoin in a safety net.
> But as mentioned above I do not see why any addition of hash based signatures to tapscript should require any kind of community consensus on future disablement of insecure spend paths
I think Antoine's point here is that if we introduce a PQC opcode to tapscript but choose NOT to deploy P2MR, and then encourage people to use that opcode in P2TR script leaves, then we are locking ourselves into the assumption that the community will later disable P2TR key-path spending - otherwise those addresses will be compromised by a CRQC and the PQC leaf script is useless.
> Adding a PQ output type which no one will use (eg one where use of the hash-based signature is mandatory, which drives fees up hugely and has all the drawbacks you mention) is not a risk mitigation strategy - it does not materially allow for any migration and doesn't accomplish much of anything. But as mentioned above I do not see why any addition of hash based signatures to tapscript
I don't think anyone is suggesting deployment of an output type with mandatory hash-based signatures. That would be borderline unusable for anyone but large companies and wealthy elites.
Every decent proposal I've seen has suggested using PQC in tandem with ECC across multiple tapscript leaves, whether in some bastardized variant of P2TR, or in BIP360's P2MR.
My favorite idea is using hash-based sigs as a fallback escape hatch, because as a highly conservative field of cryptography, hash-based keys can be a fallback not just for ECC but for any future FancySig PQC algorithm we adopt in the future: lattice, isogeny, multivariate, whatevs. I posted an idea recently [2] for how to construct drop-in BIP32 replacement algorithms under this exact context.
regards,
conduition
[1]: https://groups.google.com/g/bitcoindev/c/Q06piCEJhkI
[2]: https://groups.google.com/g/bitcoindev/c/5tLKm8RsrZ0
On Thursday, April 9th, 2026 at 8:34 PM, Matt Corallo <lf-lists@mattcorallo.com> wrote:
>
>
> On 4/9/26 2:58 PM, 'Antoine Poinsot' via Bitcoin Development Mailing List wrote:
> > Many of us appear to be in favour of introducing post-quantum signatures to
> > Bitcoin via a new Tapscript operation, conditioning the CRQC resistance on a
> > future invalidation of Taproot key spends.I would like to offer an argument in
> > favour of introducing such post-quantum signatures as a new output type instead,
> > that does not depend on invalidating a spending path on existing outputs.
> >
> > First of all, it's important to clarify what we are trying to achieve. We need
> > to accept that, by virtue of being faced with an uncertain existential threat to
> > the network, there are scenarios, however unlikely, in which the network does
> > not survive. Not all plausible futures are worth optimizing for. For instance,
> > one in which PoW ends up broken only a few years after EC crypto, or one where
> > the entire Bitcoin userbase *must* migrate within a handful of years.
> >
> > I think there are two futures worth optimizing for primarily:
> > - a CRQC never materializes and users can continue benefiting from the
> > properties of a Bitcoin network relying on classical cryptographic
> > assumptions;
> > - a CRQC materializes on a long enough timeframe that PQ signature schemes that
> > maintain today's properties can be designed, vetted and adopted, and the vast
> > majority of the userbase migrated.
> >
> > And because hope is not a strategy, it's important to also have a "break glass"
> > emergency plan in case a CRQC emerges on a shorter (yet still reasonable)
> > timeframe. I think the current proposals for hash-based PQ schemes fit this
> > category. If they became the only safe option available, it would certainly make
> > Bitcoin a lot less attractive. But having them around is good risk mitigation
> > *regardless* of whether a CRQC emerges.
> >
> > It's often argued that a freeze will be necessary anyways, therefore we might as
> > well disable the Taproot keyspend path simultaneously and simply introduce the
> > PQ scheme today in Tapscript. I personally reject the premise, but more
> > importantly i think we should separate the concerns of 1) making a PQ scheme
> > available and 2) freezing vulnerable coins. Yet introducing a PQ scheme inside
> > vulnerable Taproot outputs locks us onto the path of eventually freezing
> > vulnerable coins, as it will inevitably turn users of the PQ scheme into
> > supporters of a freeze.
>
> You've missed the much-more-important thing that cannot be extricated from disabling insecure spend
> paths - the ability to recover from a seedphrase. In any world where a CRQC exists, whether it is
> next year or a century from now, there will be a million or two bitcoin in lost-key-wallets and a
> nontrivial amount in wallets people haven't touched in ten years but still have keys for. Given a
> goal of any migration strategy should be to enable the absolute maximum number of coins to be
> retained by their owners (I think this is basically the *only* goal?), enabling seedphrase proof
> recovery is pretty critical. Sadly the only way that can be done is through disabling insecure spend
> proofs.
>
> But you've also confused unrelated concerns here - whether a hash-based signature is added as a
> tapscript opcode or not is not strictly tied to whether a new output type is created. If BIP 360 is
> the way bitcoin goes, it *still* needs a new hash-based opcode in tapscript. Maybe more
> interestingly, a new taproot "version" could be added which has identical semantics to today's
> taproot but signals through an alternative version number (or maybe there's a cleverer way to encode
> a bit somewhere that we should prefer) that a PQC pubkey exist in a taproot leaf somewhere so the
> insecure spend path should be disabled.
>
> > This approach would tie the availability of a PQ scheme to reaching consensus on
> > a future freeze. Frankly, i do not believe the latter is achievable, let alone
> > at this stage with so little evidence that a CRQC will materialize anytime soon.
> > By contrast, there is a much stronger case for introducing a PQ scheme in the
> > near term purely as a risk mitigation measure. Coupling the two decisions would
> > necessarily delay the deployment of a PQ scheme, unnecessarily exacerbating
> > risks whether or not CRQCs become a reality.
>
> Adding a PQ output type which no one will use (eg one where use of the hash-based signature is
> mandatory, which drives fees up hugely and has all the drawbacks you mention) is not a risk
> mitigation strategy - it does not materially allow for any migration and doesn't accomplish much of
> anything. But as mentioned above I do not see why any addition of hash based signatures to tapscript
> should require any kind of community consensus on future disablement of insecure spend paths - not
> only is it a likely prerequisite for an alternative output type, but its also (obviously?) not
> possible to have any kind of "consensus" on what the future bitcoin community will do. Thus it would
> be rather impossible to do *anything* if that were a requirement.
>
> > Another drawback of the PQ output type approach is that it would make those
> > outputs distinguishable from Taproot ones, which is suboptimal in the event that
> > a CRQC never materializes. But i would argue that even in this case, the cost is
> > minimal. The users most likely to adopt PQ outputs today (those securing large
> > amounts of BTC with a small set of keys) already have vastly different usage
> > patterns from Taproot users: they often reuse addresses and use legacy output
> > types (and show little interest in upgrading).
> >
> > Best,
> > Antoine Poinsot
> >
>
> --
> 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/cba894e1-f830-4ad5-9498-09f04faaadf7%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/6wBygQ_pK40ZpU_CMXfzIy-6LkthOmEh-xd2g9bwUl-f8w2K6G4rUWJEssE2zeJgxyipGe2GrFH9y_TUUI48asqfh7dhi9A2rl7NpWyFW1o%3D%40proton.me.
[-- Attachment #1.2: publickey - conduition@proton.me - 0x474891AD.asc --]
[-- Type: application/pgp-keys, Size: 649 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 343 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoindev] In defense of a PQ output type
2026-04-10 17:03 ` 'conduition' via Bitcoin Development Mailing List
@ 2026-04-10 20:33 ` Matt Corallo
2026-04-11 0:20 ` Ethan Heilman
0 siblings, 1 reply; 9+ messages in thread
From: Matt Corallo @ 2026-04-10 20:33 UTC (permalink / raw)
To: conduition; +Cc: Antoine Poinsot, Bitcoin Development Mailing List
On 4/10/26 1:03 PM, conduition wrote:
>> But as mentioned above I do not see why any addition of hash based signatures to tapscript should require any kind of community consensus on future disablement of insecure spend paths
>
> I think Antoine's point here is that if we introduce a PQC opcode to tapscript but choose NOT to deploy P2MR, and then encourage people to use that opcode in P2TR script leaves, then we are locking ourselves into the assumption that the community will later disable P2TR key-path spending - otherwise those addresses will be compromised by a CRQC and the PQC leaf script is useless.
Right, but you cut my quote off and appear to be responding to a point I didn't make? The very next
few words that you cut were "not only is it a likely prerequisite for an alternative output type".
Yes, we have to figure out what kind of output type we want, whether P2MR (360), P2TRv2 or just
P2TR. There are strong arguments for each. But none of that has any bearing on whether we add hash
based signatures to tapscript. We have to add hash based signatures to tapscript first no matter
what output type we want!
>> Adding a PQ output type which no one will use (eg one where use of the hash-based signature is mandatory, which drives fees up hugely and has all the drawbacks you mention) is not a risk mitigation strategy - it does not materially allow for any migration and doesn't accomplish much of anything. But as mentioned above I do not see why any addition of hash based signatures to tapscript
>
> I don't think anyone is suggesting deployment of an output type with mandatory hash-based signatures. That would be borderline unusable for anyone but large companies and wealthy elites.
>
> Every decent proposal I've seen has suggested using PQC in tandem with ECC across multiple tapscript leaves, whether in some bastardized variant of P2TR, or in BIP360's P2MR.
IMO even something like P2MR's additional cost will strongly discourage adoption. We have a very
long history with Bitcoin wallets not only refusing to adopt new features but actively making some
of the worst possible design decisions from a Bitcoin PoV. IMO we should very strongly not give them
any excuse, even if that's just fees.
Matt
--
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/765490aa-5df3-4619-86cc-17570b6d3e99%40mattcorallo.com.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoindev] In defense of a PQ output type
2026-04-10 20:33 ` Matt Corallo
@ 2026-04-11 0:20 ` Ethan Heilman
2026-04-11 1:04 ` 'Hayashi' via Bitcoin Development Mailing List
0 siblings, 1 reply; 9+ messages in thread
From: Ethan Heilman @ 2026-04-11 0:20 UTC (permalink / raw)
To: Matt Corallo
Cc: conduition, Antoine Poinsot, Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 4276 bytes --]
> IMO even something like P2MR's additional cost will strongly discourage
adoption.
I don't agree.
Over time as quantum attacks become a bigger and bigger concern for
holders, wallets will want to show that they can offer security against
CRQCs. This is especially true for wallets focused on high value Bitcoin
outputs. Even if someone thinks there is only a 2% chance they lose all
their Bitcoin because of a quantum computer, that 2% chance will keep them
up at night.
P2MR would have 17.25 more vBytes, an 11% overhead.
P2TR 1 input, 2 output - key path spend. 154 vbytes
P2MR 1 input, 2 output - spending a schnorr sig leaf of a P2MR output with
two leafs: 1. PQ sig leaf and 2. Schnorr sig leaf. 171.25 vbytes
I'm stacking the deck against P2MR here. Under some circumstances P2MR has
lower fees than P2TR.
It is hard to imagine someone holding significant quantities of Bitcoin not
wanting to pay 50 sats to ensure their Bitcoin isn't stolen by a quantum
computer.
On Fri, Apr 10, 2026 at 7:10 PM Matt Corallo <lf-lists@mattcorallo.com>
wrote:
>
>
> On 4/10/26 1:03 PM, conduition wrote:
> >> But as mentioned above I do not see why any addition of hash based
> signatures to tapscript should require any kind of community consensus on
> future disablement of insecure spend paths
> >
> > I think Antoine's point here is that if we introduce a PQC opcode to
> tapscript but choose NOT to deploy P2MR, and then encourage people to use
> that opcode in P2TR script leaves, then we are locking ourselves into the
> assumption that the community will later disable P2TR key-path spending -
> otherwise those addresses will be compromised by a CRQC and the PQC leaf
> script is useless.
>
> Right, but you cut my quote off and appear to be responding to a point I
> didn't make? The very next
> few words that you cut were "not only is it a likely prerequisite for an
> alternative output type".
> Yes, we have to figure out what kind of output type we want, whether P2MR
> (360), P2TRv2 or just
> P2TR. There are strong arguments for each. But none of that has any
> bearing on whether we add hash
> based signatures to tapscript. We have to add hash based signatures to
> tapscript first no matter
> what output type we want!
>
> >> Adding a PQ output type which no one will use (eg one where use of the
> hash-based signature is mandatory, which drives fees up hugely and has all
> the drawbacks you mention) is not a risk mitigation strategy - it does not
> materially allow for any migration and doesn't accomplish much of anything.
> But as mentioned above I do not see why any addition of hash based
> signatures to tapscript
> >
> > I don't think anyone is suggesting deployment of an output type with
> mandatory hash-based signatures. That would be borderline unusable for
> anyone but large companies and wealthy elites.
> >
> > Every decent proposal I've seen has suggested using PQC in tandem with
> ECC across multiple tapscript leaves, whether in some bastardized variant
> of P2TR, or in BIP360's P2MR.
>
> IMO even something like P2MR's additional cost will strongly discourage
> adoption. We have a very
> long history with Bitcoin wallets not only refusing to adopt new features
> but actively making some
> of the worst possible design decisions from a Bitcoin PoV. IMO we should
> very strongly not give them
> any excuse, even if that's just fees.
>
> Matt
>
> --
> 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/765490aa-5df3-4619-86cc-17570b6d3e99%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/CAEM%3Dy%2BUYBQoocr95ucutw_9QoTuyRcpGPTf_1wgazzK3nbFyyQ%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 5204 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoindev] In defense of a PQ output type
2026-04-11 0:20 ` Ethan Heilman
@ 2026-04-11 1:04 ` 'Hayashi' via Bitcoin Development Mailing List
2026-04-11 1:25 ` Antoine Riard
0 siblings, 1 reply; 9+ messages in thread
From: 'Hayashi' via Bitcoin Development Mailing List @ 2026-04-11 1:04 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 6011 bytes --]
Hi Conduition, Matt and Ethan
> an ownership proof used for non-BIP32 hashed addresses
I’m concerned that shared xpubs could become an attack vector if we allow
ZKP of hash preimages for unused addresses (excluding P2PK/P2TR). Given
that, are there alternative methods for publishing proof of ownership that
we should consider?
It seems the current default stance is effectively "do not freeze," because
preserving the status quo is the only path if we cannot reach consensus
(and if we do not chose hardfork). However, by formalizing a freezing
plan—either through a new BIP or an amendment to BIP361—I believe we gain
several strategic advantages:
*Clarity on P2MR discussion*: It would clarify the ongoing P2MR and P2TR
discussions by defining how P2TR will be treated (I personally prefer P2MR).
*Incentivized Migration*: Establishing a clear future plan encourages users
to migrate to BIP32-hardened addresses with longer time period which
eventually maximize recovery.
*Advance Planning for CRQCs*: We will not panic on the edge case scenario
that CRQCs arrive earlier than PQ signature scheme adoption or when we find
out we cannot allow enough migration period after PQ signature scheme
adoption (I strongly believe we also have to prepare for this future).
While further R&D is required, we likely have sufficient information to
formalize a framework now. We can also disable or modify the defined
freezing plan if the threat landscape changes significantly.
Hayashi
2026年4月11日土曜日 8:33:54 UTC+8 Ethan Heilman:
> > IMO even something like P2MR's additional cost will strongly discourage
> adoption.
>
> I don't agree.
>
> Over time as quantum attacks become a bigger and bigger concern for
> holders, wallets will want to show that they can offer security against
> CRQCs. This is especially true for wallets focused on high value Bitcoin
> outputs. Even if someone thinks there is only a 2% chance they lose all
> their Bitcoin because of a quantum computer, that 2% chance will keep them
> up at night.
>
> P2MR would have 17.25 more vBytes, an 11% overhead.
>
> P2TR 1 input, 2 output - key path spend. 154 vbytes
> P2MR 1 input, 2 output - spending a schnorr sig leaf of a P2MR output with
> two leafs: 1. PQ sig leaf and 2. Schnorr sig leaf. 171.25 vbytes
>
> I'm stacking the deck against P2MR here. Under some circumstances P2MR has
> lower fees than P2TR.
>
> It is hard to imagine someone holding significant quantities of Bitcoin
> not wanting to pay 50 sats to ensure their Bitcoin isn't stolen by a
> quantum computer.
>
>
> On Fri, Apr 10, 2026 at 7:10 PM Matt Corallo <lf-l...@mattcorallo.com>
> wrote:
>
>>
>>
>> On 4/10/26 1:03 PM, conduition wrote:
>> >> But as mentioned above I do not see why any addition of hash based
>> signatures to tapscript should require any kind of community consensus on
>> future disablement of insecure spend paths
>> >
>> > I think Antoine's point here is that if we introduce a PQC opcode to
>> tapscript but choose NOT to deploy P2MR, and then encourage people to use
>> that opcode in P2TR script leaves, then we are locking ourselves into the
>> assumption that the community will later disable P2TR key-path spending -
>> otherwise those addresses will be compromised by a CRQC and the PQC leaf
>> script is useless.
>>
>> Right, but you cut my quote off and appear to be responding to a point I
>> didn't make? The very next
>> few words that you cut were "not only is it a likely prerequisite for an
>> alternative output type".
>> Yes, we have to figure out what kind of output type we want, whether P2MR
>> (360), P2TRv2 or just
>> P2TR. There are strong arguments for each. But none of that has any
>> bearing on whether we add hash
>> based signatures to tapscript. We have to add hash based signatures to
>> tapscript first no matter
>> what output type we want!
>>
>> >> Adding a PQ output type which no one will use (eg one where use of the
>> hash-based signature is mandatory, which drives fees up hugely and has all
>> the drawbacks you mention) is not a risk mitigation strategy - it does not
>> materially allow for any migration and doesn't accomplish much of anything.
>> But as mentioned above I do not see why any addition of hash based
>> signatures to tapscript
>> >
>> > I don't think anyone is suggesting deployment of an output type with
>> mandatory hash-based signatures. That would be borderline unusable for
>> anyone but large companies and wealthy elites.
>> >
>> > Every decent proposal I've seen has suggested using PQC in tandem with
>> ECC across multiple tapscript leaves, whether in some bastardized variant
>> of P2TR, or in BIP360's P2MR.
>>
>> IMO even something like P2MR's additional cost will strongly discourage
>> adoption. We have a very
>> long history with Bitcoin wallets not only refusing to adopt new features
>> but actively making some
>> of the worst possible design decisions from a Bitcoin PoV. IMO we should
>> very strongly not give them
>> any excuse, even if that's just fees.
>>
>> Matt
>>
>> --
>> 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/765490aa-5df3-4619-86cc-17570b6d3e99%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/e737199f-6a69-4d2a-97b8-d9c4aad5f33bn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 7642 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoindev] In defense of a PQ output type
2026-04-11 1:04 ` 'Hayashi' via Bitcoin Development Mailing List
@ 2026-04-11 1:25 ` Antoine Riard
0 siblings, 0 replies; 9+ messages in thread
From: Antoine Riard @ 2026-04-11 1:25 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 8184 bytes --]
Hi,
Thanks for rolling up the ball forward on this topic.
I'm +1 on disentangling the introduction of a PQ safe scheme from
the more fuzzy idea of freezing coins based on output types.
Even the idea of "freezing" coins, the goal of why is still unclear.
It sounds the motivations are blurred between ensuring coins are
staying in the hands of their legitimate owners, a goal I can share
but I don't see how freezing help here, from the more loose idea of
ensuring there is no crash in the bitcoin price vs fiat in the face
of CQRC-enabled attacks, which sounds to me a pandora box.
Even in this eventuality, if there is a general concern on the network
disruptions that might be induced by CRQC attacks (e.g chain instability
due to reorgs by competing CRQC attackers), I believe there are still
intermediary technical solutions, e.g rate-limiting the number of output
types that can be spent by difficulty periods to minimize the risks of
disruptions, while not technically confiscating anyone coin.
Back to introducing a PQ safe scheme, I don't think in this thread
the question is raised to enable to secure one's coin under double
classic cryptogrraphic assumption and PQ assumption, i.e "hybrid"
security (more for the risk of a cryptanalysis break of any PQ safe
scheme that would be introduced at the consensus-level). It might
more a real engineering burden, though I believe it's giving more
flexibility for technically savy bitcoin users to secure one's stack.
Anyway, I think it's good to have a scheme ready early on given
the development cycle to have stuff available on HW wallets and
HSMs. E.g BIP32 support was added in 2018 on Gemalto's HSM i.e a
mere 6 years after the standard introduction (which is not that
bad given that blockchain were recents actors in the hardware
industry at the time).
Best,
Antoine
OTS hash: 6d7c2f5ab01bcdda4ec27d4c21198a9b13ce1dfd138c4a2e6dfaedee9458f6c0
Le Saturday, April 11, 2026 à 2:06:55 AM UTC+1, Hayashi a écrit :
> Hi Conduition, Matt and Ethan
>
> > an ownership proof used for non-BIP32 hashed addresses
> I’m concerned that shared xpubs could become an attack vector if we allow
> ZKP of hash preimages for unused addresses (excluding P2PK/P2TR). Given
> that, are there alternative methods for publishing proof of ownership that
> we should consider?
>
>
> It seems the current default stance is effectively "do not freeze,"
> because preserving the status quo is the only path if we cannot reach
> consensus (and if we do not chose hardfork). However, by formalizing a
> freezing plan—either through a new BIP or an amendment to BIP361—I believe
> we gain several strategic advantages:
>
> *Clarity on P2MR discussion*: It would clarify the ongoing P2MR and P2TR
> discussions by defining how P2TR will be treated (I personally prefer P2MR).
>
> *Incentivized Migration*: Establishing a clear future plan encourages
> users to migrate to BIP32-hardened addresses with longer time period which
> eventually maximize recovery.
>
> *Advance Planning for CRQCs*: We will not panic on the edge case scenario
> that CRQCs arrive earlier than PQ signature scheme adoption or when we find
> out we cannot allow enough migration period after PQ signature scheme
> adoption (I strongly believe we also have to prepare for this future).
>
> While further R&D is required, we likely have sufficient information to
> formalize a framework now. We can also disable or modify the defined
> freezing plan if the threat landscape changes significantly.
>
> Hayashi
> 2026年4月11日土曜日 8:33:54 UTC+8 Ethan Heilman:
>
>> > IMO even something like P2MR's additional cost will strongly
>> discourage adoption.
>>
>> I don't agree.
>>
>> Over time as quantum attacks become a bigger and bigger concern for
>> holders, wallets will want to show that they can offer security against
>> CRQCs. This is especially true for wallets focused on high value Bitcoin
>> outputs. Even if someone thinks there is only a 2% chance they lose all
>> their Bitcoin because of a quantum computer, that 2% chance will keep them
>> up at night.
>>
>> P2MR would have 17.25 more vBytes, an 11% overhead.
>>
>> P2TR 1 input, 2 output - key path spend. 154 vbytes
>> P2MR 1 input, 2 output - spending a schnorr sig leaf of a P2MR output
>> with two leafs: 1. PQ sig leaf and 2. Schnorr sig leaf. 171.25 vbytes
>>
>> I'm stacking the deck against P2MR here. Under some circumstances P2MR
>> has lower fees than P2TR.
>>
>> It is hard to imagine someone holding significant quantities of Bitcoin
>> not wanting to pay 50 sats to ensure their Bitcoin isn't stolen by a
>> quantum computer.
>>
>>
>> On Fri, Apr 10, 2026 at 7:10 PM Matt Corallo <lf-l...@mattcorallo.com>
>> wrote:
>>
>>>
>>>
>>> On 4/10/26 1:03 PM, conduition wrote:
>>> >> But as mentioned above I do not see why any addition of hash based
>>> signatures to tapscript should require any kind of community consensus on
>>> future disablement of insecure spend paths
>>> >
>>> > I think Antoine's point here is that if we introduce a PQC opcode to
>>> tapscript but choose NOT to deploy P2MR, and then encourage people to use
>>> that opcode in P2TR script leaves, then we are locking ourselves into the
>>> assumption that the community will later disable P2TR key-path spending -
>>> otherwise those addresses will be compromised by a CRQC and the PQC leaf
>>> script is useless.
>>>
>>> Right, but you cut my quote off and appear to be responding to a point I
>>> didn't make? The very next
>>> few words that you cut were "not only is it a likely prerequisite for an
>>> alternative output type".
>>> Yes, we have to figure out what kind of output type we want, whether
>>> P2MR (360), P2TRv2 or just
>>> P2TR. There are strong arguments for each. But none of that has any
>>> bearing on whether we add hash
>>> based signatures to tapscript. We have to add hash based signatures to
>>> tapscript first no matter
>>> what output type we want!
>>>
>>> >> Adding a PQ output type which no one will use (eg one where use of
>>> the hash-based signature is mandatory, which drives fees up hugely and has
>>> all the drawbacks you mention) is not a risk mitigation strategy - it does
>>> not materially allow for any migration and doesn't accomplish much of
>>> anything. But as mentioned above I do not see why any addition of hash
>>> based signatures to tapscript
>>> >
>>> > I don't think anyone is suggesting deployment of an output type with
>>> mandatory hash-based signatures. That would be borderline unusable for
>>> anyone but large companies and wealthy elites.
>>> >
>>> > Every decent proposal I've seen has suggested using PQC in tandem with
>>> ECC across multiple tapscript leaves, whether in some bastardized variant
>>> of P2TR, or in BIP360's P2MR.
>>>
>>> IMO even something like P2MR's additional cost will strongly discourage
>>> adoption. We have a very
>>> long history with Bitcoin wallets not only refusing to adopt new
>>> features but actively making some
>>> of the worst possible design decisions from a Bitcoin PoV. IMO we should
>>> very strongly not give them
>>> any excuse, even if that's just fees.
>>>
>>> Matt
>>>
>>> --
>>> 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/765490aa-5df3-4619-86cc-17570b6d3e99%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/459bd81c-584f-4adf-9112-bb733d381c99n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 9992 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread