I’m working on a Post-Quantum State-Channel payment method on Bitcoin, and building it raised a question I think matters beyond my specific case.
You can make every off-chain component of a system post-quantum, signatures, identity, ledger state, proofs. But if settlement ultimately touches Bitcoin L1, you’re still relying on ECDSA/Schnorr over secp256k1. So what does “post-quantum” actually mean here? I don’t think it’s about which algorithms run inside the system, I think it’s about the boundary: what specifically crosses from the off-chain side to L1, and whether that crossing point can be minimized rather than just accepted.
This isn’t specific to my project. Any BitVM-based bridge, Lightning, anything that does real cryptographic work off-chain and settles on a non-PQ L1, the same question applies, whether or not it’s being asked yet.
Where I’ve gotten so far
Peg-out seems more tractable, it can potentially be reduced to a commitment-based claim, with the classical signature only appearing once, at the final moment of withdrawal, rather than being exposed continuously. Peg-in seems fundamentally harder, depositing requires a classical signature to construct the transaction itself, and I don’t currently see a way around that without changing Bitcoin L1’s own signature scheme.
Genuinely interested in whether this framing holds up, whether others have thought about this systematically, or whether I’m missing existing work on it.
It seems to me that systematically, any non-PQ L1 simply cannot host a PQ L2 that is worthy of the name “L2”.
If any entity can derive L1 private keys from L1 public keys that they semantically “should not” control, then they can create an L1 transaction that anchors (pegs in, whatever) any funds controlled by that key into any L2, and then the current entity who “should have” controlled that key would be unable to prevent the loss. It is thus immaterial whether the L2 uses PQ for the purposes of fund security.
Thanks for the reply; after three months, I had given up hope of hearing back from anyone
In principle I agree with you, but on the point that a PQ L2 is useless, no. Actually, the more I think about it, the more the argument turns against itself.
Because the L2 doesn’t add the vulnerability, it inherits it. If a quantum computer can derive the private key from an L1 public key, it can steal those funds directly on-chain, with or without an L2. A peg-in with a classical signature isn’t a flaw of the layer, it’s the cost of spending a UTXO on Bitcoin, full stop. So an L2 like this is as secure as the L1 against the quantum threat: if your reasoning made the L2 useless, it would make Bitcoin itself useless too. Immaterial for fund security, as you say, but fund security isn’t the only thing a payment system has to offer.
Then there’s the role. If the L2 were created to replace the L1, then yes, it would be useless, and on that I agree with you. But the role of a layer like this is to make Bitcoin easier to use for payments (the reason Bitcoin was created), and there the post-quantum properties matter a lot. Privacy, for example: the L1 doesn’t offer it at all. An adversary who intercepts and stores encrypted traffic today will decrypt it tomorrow, once a quantum computer exists. PQ signatures and encryption off-chain protect today’s payments from tomorrow’s attack, and that value doesn’t depend in any way on whether the L1 is PQ.
On custody you’re right, and in my case even more than you say: a custodial channel concentrates many users’ funds under a few keys, a bigger target than average. That’s exactly why the peg-out is designed as a commitment-based claim, with the classical signature reduced to a single moment, the final one. Minimizing the number and the window of exposure is the only engineering answer possible as long as the L1 stays as it is. It doesn’t make it perfect, it makes it as little exposed as possible.
About preparing. When the L1 adopts something like P2QRH (BIP-360), QuBit or Lamport signatures in Script, an off-chain layer that is already PQ can migrate the peg the same day without redesigning anything and without unlocking user’s founds. Today’s work is the prerequisite for tomorrow’s migration.
In the end, the point of my original post was exactly this: what does “post-quantum” actually mean for an L2 when settlement happens on a non-PQ L1? I don’t think the answer is definitive, it depends on the phase we’re in. Right now Bitcoin’s L1 is not yet post-quantum, so a post-quantum L2 has the function, beyond the one it was created for, of reducing as much as possible the sensitive information that can be collected today and decrypted tomorrow. If one day Bitcoin itself becomes PQ resistant, then a PQ L2 will take on a different definition. I don’t claim it’s already perfect, but the fact that it already exists means someone is thinking and acting to face this challenge, instead of doing everything at the last second.
What do you think? Have you worked hands-on on anything in this space, or is this a concern you’ve looked at from the outside?
I will stop you right here and point out that fund security is an absolute requirement for this system, otherwise you might as well just go back to the legacy financial system. A payment system that cannot offer fund security is no different from the legacy financial system and any other features it has is irrelevant.
Absolutely, but no one doubts that safety is the most important point, but it is not the only one. But, leaving this aside, I think the focus of the question of the original topic has been lost for a moment.
My question focussed on the boundaries (peg-in and peg-out/ security exit) between L2 and L1.
Certainly the security of the funds is important and within an L2, guaranteeing a PQ resistant security is possible, the problem is on the border. But that’s not why it’s useless to develop L2, considered PQ resistant, on Bitcoin not yet PQ. That’s why in the end I say that maybe the question doesn’t have a single answer, but it has an answer based on the phases in which L1 is located (Bitcoin in this case)
Interesting topic. Obviously the superficial answer is no, you can’t do that, but I could see scenarios where it might make sense:
For example, people use scripthash addresses on L1. They “peg in” (let’s say by entering a multisig or some script condition) by paying into that address with their own coins. And only then (say a year later) is ECDLP effectively broken, the coins sitting in hashed addresses are “safe” until such time as a new L1 consensus occurs. The funds now in L2, supposed quantum-safe, can still be used for payments within L2. The interesting question becomes, how safe is the L2 as a store of value? It seems wildly difficult to say anything specific. The “value” assigned to bitcoin by the market may well have crashed, which you could argue, yeah, of course, the L2 is using bitcoin so its value is defined by that, so we can set that aside. Withdrawing funds from the L2 has become kinda impossible until a base chain consensus fix at least. But then we get into all this commitment scheme stuff.
Obviously, huge topic, but I just wanted to point out that it isn’t crazy to talk about PQ L2 with L1 exposed, in that particular timeline of events. Unlikely perhaps, but not crazy.
This is just a counter to @ZmnSCPxj 's point I guess: if the base layer is 100% CRQC exposed, then his argument is watertight. But Bitcoin’s base layer is only “mostly” exposed or half-exposed (using hashes in some cases), so the argument isn’t watertight, hence the scenario above is possible.
Thank you very much for taking the time to reply and for finding the topic interesting. IMO, it could open the door to many other discussions.
However, yes, I don’t think it’s pointless to discuss PQ-resistant L2s settling on an L1 that is still quantum-vulnerable, and I agree that this is a much broader topic.
The overall security of a system depends on the security assumptions of all its components and how they interact. An attacker will look for the weakest point that allows them to compromise the system at the lowest cost.
In this scenario, I think the bridge deserves particular attention. Even if the peg-in is PQ-resistant, we still need to ask:
Can the bridge correctly authenticate the deposit and attribute it to the intended user?
Is the proof system itself post-quantum secure? This is particularly important because an attacker who can forge a proof accepted by the verifier could authorize an illegitimate peg-out and potentially drain the bridge.
Personally, I think OTS schemes could be a promising direction to explore. However, simply embedding an OTS in a Bitcoin Script is not enough; the signature verification logic must be carefully designed.
In that direction, yes. I think there can be something to discuss.
So you’re imagining pegging in with ECDL already broken?
I don’t see an obvious way that could work, that’s more what @ZmnSCPxj was saying: acting onchain with authorization from a key which is not secure doesn’t seem possible. The L2 can for sure validate authorization with PQ-secure primitives and they for sure can exist in bitcoin transactions - as you point out, stuff like Witnernitz OTS could work, or some variant suited to this particular task. But that doesn’t seem relevant if the coins are controlled with EC keys; so it’s like, you can say “Alice authorized pegging in 1BTC”, but no 1BTC is locked under the L2’s specified control mechanism; if she publishes a tx, she loses control of it; if she doesn’t, nothing has happened.
No, absolutely. It would be pointless if the coins were still controlled by EC keys.
I was just saying that the bridge is one of the components most exposed to attacks, and that it deserves particular attention when trying to build a PQ resistant L2 on an L1 that is not yet PQ resistant (I could be wrong, of course, and if so, please correct me).
Obviously, if the peg-in itself isn’t PQ resistant, discussing what comes afterward may make less sense. But I don’t think this means we should stop exploring it. On the contrary, it could be an incentive to find solutions for peg-in PQ resistant as well.
Regarding OTS, as I mentioned, the verification logic needs to be carefully designed. More importantly, if the scheme is hash based, revealing a preimage proves knowledge of a secret, not necessarily the right to spend the coins. It could also introduce a front-running problem, which is another issue to address.
Personally, I think it’s worth exploring what can be achieved with the tools we have today, squeezing every possible opportunity out of the existing protocol before resorting to a fork. That’s what I’m trying to do at the moment. I recognize that I still can’t answer many questions because of gaps in my knowledge and because there are mechanisms I still need to study and understand better.
Above all, though, I believe we need to start building on Bitcoin.
Hal_03 · 
ZmnSCPxj jxPCSnmZ · 
user1 · 
Adam Gibson ·