I wish you were right, that was the whole idea behind Taproot! But we’re five years in, have seen multiple periods of mempool congestion in that time (some taking months), and not even all providers support sending to it, let alone use it as default for new addresses. Adoption is mostly within systems built around newer features or technology stacks, and stupid hype stuff. Not the large-scale migration we’d want to see for PQC security, neither in terms of BTC nor in terms of users.
Realistically, I don’t think we should expect CISA to have a bigger impact than that, I think. That’s not to say it won’t influence behavior at all, but as I said, I think it’s more a long term thing that will affect future software projects/companies when people inevitably migrate anyway, not existing wallets.
To back this up with actual numbers, here are graphs with logscale vsize savings for P2WPH inputs → P2TR key path spends, and then from P2TR key path spends to CISA. Full-agg CISA can improve over P2TR more than P2TR did over P2WPH, but only for sufficiently complex transactions. That’s the point of course: incentivizing those, but adopting workflows that allow such transactions is an even bigger task than adding PQC as it will typically involve adding interactivity (for CoinJoin/PayJoin like constructions):
That sounds more like an argument that people like P2MR for other reasons than its economics. I don’t see how you’d conclude from this that feerates are relevant to them?
Just to make sure we’re talking about the same thing. An extension block, as discussed years ago as a scalability proposal, is something very different and much more invasive than what we’re talking about here. It’s a completely new block area, with its own transactions and separate UTXO set, and mechanisms to move coins in both directions between the two areas. It’s completely incompatible with existing wallet designs; you need transfers between the two blocks to pay to an old address. It can be done as a soft-fork, but it’s probably the most invasive thing you can imagine that still qualifies.
I am just talking about a new witness in transaction serialization, like Segwit did, and the design discussed here is somewhat less invasive than that even (no need for new wtxids or P2P changes beyond the transaction serialization). I don’t want to minimize the impact either, it’s still a big change, much bigger than just adopting a new output type or introducing a new signature opcode, but it is something the ecosystem has done before.
And I think we’ll want this even if the long-term migration plan ends up using something else than hash-based. Because it’s very unlikely it’ll have the same size/verification characteristics as ECC, even if it’s not as extreme as hash-based. And if we’re going to need it anyway, I’d rather have the infrastructure in place beforehand.
See the thread AJ linked to for a concrete idea, but I’d like to give an intuitive description.
Split your block up into 10-byte chunks. Then extend each of those chunks (implicitly, we won’t actually compute/store these) to 256 bytes, by adding 246 error-correction bytes, in such a way that you can recover the whole chunk if you have any 10 bytes of it (and know which positions those bytes are from).
Every node now picks one (or a few) random numbers in range [0,255], and just stores those position bytes of every chunk. So for every number they pick, they store 1/10th of each block. For reconstruction, it suffices to pick peers which together have 10 distinct numbers. So it is indeed not quite the case you can have any 10 peers (or 5 or whatever, depending on the constants chosen), they need to be peers that chose distinct numbers. It’s possible to switch to more complex codes which offer a larger range of numbers (making the probability of collisions in them lower), in exchange for more reconstruction complexity.
The big one is block propagation speed: practically, minimizing the time between a miner finding a block, getting it across the network, up to the point where other miners can start hashing on top of a successor block. So this includes:
- time to relay transactions (if those weren’t already relayed before)
- time to relay the block (which can use compact blocks or FIBRE)
- time to validate it along each hop (compact blocks typically allow relay before full validation, but it still needs reconstruction/PoW checking)
- time to validate it by the miner (which cannot be skipped; only for transactions not yet validated beforehand)
- time to build a new block template on top from mempool (in miner’s nodes)
- time for that block template to make it to hashers (internal to miner setup, protocol changes have little impact here).
It’s really only the first one that is directly impacted by block/transaction size, and it is hard to measure its real-life worst-case impact, because in practice most blocks are primarily filled with transactions that were relayed and validated ahead of time. That said, KIT has a page with block and transaction relay statistics going back many years, which shows the impact of adoption of certain technologies and transaction composition changes.
Ah, of course!
I think aiming for roughly the same signature verificiation as BIP-340 seems like a reasonable rule of thumb. It does sound like a potential for bikeshedding, though.
Cool. I think that’s helpful.
I have one concern here, but it is admittedly a weak one that’s probably addressable with education/communication. If a custodial company CEO hears “a simple change that just adds quantum protection”, they may agree to put resources on implementing it quickly. If they hear “a new output type with several features like key aggregation and PQC”, they may decide “We’ll implement that whenever we need to rewrite that part of our stack anyway”.
Yeah, they would be the obvious parties who would want CISA. But I also expect them to be relatively quick adopters of a PQC output type without CISA? Just by virtue of being users/developers willing to be at the forefront of development. Under “long tail”, I mostly think of many custodial and multi-currency software solutions; they tend to put more effort into supporting more altcoins/tokens than keeping up with (from their perspective, relatively) stable Bitcoin that won’t gain them more customers.
I think that’s fair. CISA adds a fair bit of complexity, but it may well be further ahead than some other aspects we’d also need.
This is where my concern lies mostly.
I feel like P2TRv2 and CISA kind of pull in opposite directions in terms of messaging. The output’s goal is preparing for CRQCs, but then it also adds an optimization that stops working when that actually happens.
Maybe I’m wrong, and there is a good synergy between those parts of the community who would favor it, and I’m happy to support the idea if there is momentum. Still, my belief is that the large class of users we’d want to adopt PQC with a P2TRv2 output type will at scale not really adopt CISA anyway, so that doesn’t help them. And in the other direction, if CRQC-skeptical CISA-fans exist, they may be annoyed at being required to add PQC support to get CISA?