Re: [bitcoindev] Against Allowing Quantum Recovery of Bitcoin

["'Ben Sigman' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>]

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

Considering the information presented by Jameson, it's difficult to see a 
solution to the quantum attack question other than some form of freeze. 

Murch’s idea of a rolling timeout sounds elegant from one perspective, but 
also more difficult to calculate or understand for an average user. The 
quantum doomsday clock is simpler - albeit, there would be a bidding war…

That being said, the first step seems to be that Bitcoin needs a path to 
having post-quantum signatures / addresses as an option. 

I’d advocate that the developer community focus resources on implementing a 
path forward with at least some version of this - either BIP 360 or some 
form of Taproot PQC.

On Monday, March 31, 2025 at 1:41:20 PM UTC-7 Javier Mateos wrote:

> Hi everyone!
>
> Seeing the discussions about transitioning to quantum-resistant 
> signatures, I notice three main concerns:
>
>    - 
>    
>    What should be done with vulnerable funds? Freeze them or leave them 
>    exposed?
>    - 
>    
>    How can the transition be made without affecting Bitcoin’s stability 
>    or dividing the community?
>    - 
>    
>    How can we avoid market chaos if the transition is disorderly?
>    
> Personally, I believe the key is a gradual, well-planned transition based 
> on incentives rather than abrupt changes that create uncertainty.
>
> I can think of a three-phase approach:
>
> 🔹 First, allow users to add optional PQC keys to their Taproot addresses 
> starting now.
> 🔹 Then, before the quantum threat becomes real, introduce a soft fork 
> that disables vulnerable signatures, but with a long migration period (at 
> least four years).
> 🔹 Finally, when the threat is imminent, gradually phase out old 
> signatures instead of forcing a sudden change.
>
> For this to work, adoption should be incentivized—for example, with lower 
> fees for secure transactions and wallet tools that facilitate a smooth 
> transition. Additionally, real-time monitoring of vulnerable addresses 
> would help mitigate risks.
>
> Another key point is to avoid panic. Instead of a sudden "D-Day" where 
> everything changes at once, the deactivation of old UTXOs should be 
> gradual, with clear communication so no one feels forced or disadvantaged.
>
> In summary, this is not about imposing rules or confiscating anything, but 
> about providing options for an orderly transition that doesn’t compromise 
> Bitcoin’s philosophy.
>
> -Javier Mateos
>
> El viernes, 28 de marzo de 2025 a las 21:02:43 UTC-3, Matt Corallo 
> escribió:
>
>>
>>
>> On 3/25/25 4:16 AM, Sjors Provoost wrote: 
>> > Matt Corallo wrote: 
>> > 
>> >>> In that scenario you'd need to use a NUMS point for the key path. Or 
>> maybe that's unsafe, in which case we'd need a new Taproot version without 
>> key path support (or BIP360). That's also not a difficult soft fork, but 
>> now again you have something that only a small set of users will want to 
>> use. 
>> >>>> 
>> >>>> 
>> >> A NUMS point does not suffice unless we explicitly soft-fork out 
>> spending from that NUMS point (which is, of course, doable). 
>> > 
>> > This could be a solution to the sequencing conundrum that I tried to 
>> explain. 
>> > 
>> > Along with the first PCQ scheme for tapscript (script path), we could 
>> have a soft that disables one or more NUMS points. The latter has zero 
>> effect under the current cryptographic assumptions, so it's not 
>> confiscatory. 
>> > 
>> > That way people can start using the scheme without having to worry 
>> about whether the community decides to freeze key path spending in time. 
>> They'll still worry about the market value of their coins, but not about 
>> whether they're going to be the first victim (or the umpteenth victim while 
>> everyone is in denial and blames them for poor key management). 
>>
>>
>> Mmm, yea, fair enough, that seems perfectly reasonable to include. 
>>
>> 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/50193bed-7134-4b4a-9c15-12c5dd559ad7n%40googlegroups.com.

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