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 > 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.