Good evening Jim,
> I don't agree that quantum resistance should be a blocker to deployment of > scriptless scripts on lightning > I don't mean to speak narrowly about quantum cryptanalysis, but more generally about the need for backups to every primitive we use. DL is no exception, but for DL signatures, we do have lattices. > because 1) it is a layer-2 solution > If this becomes global financial infrastructure, then layer 2 security will matter enough to merit some cryptographic conservatism. What if lightning succeeds fabulously? I think, it might. > and 2) it already critically depends on the security of DL. > Does it? In specific form, sure - but in a pinch, could lattice-based algorithms not be swapped on relatively short notice, without changing the conceptual architecture? Perhaps I'm overlooking something, but I think probably, yes. > There are arguments against making certain protocol changes to the base > Bitcoin blockchain for the reason that they may not be quantum resistant. > The most notable is Confidential Transactions. There reason is that the > worst case attack is much worse: an attacker could print money freely and > without detection. > Yes, that risk is entirely unacceptable, I agree - even at a mere $150 billion market cap, and much more so if this one day surpasses USD M3. Of course, if one knew the attack, it would be tempting to advocate for the weakness. I'm not making such an accusation here of course, I'm just saying that cryptographic conservatism helps demonstrate and maintain alignment of interests, and to demonstrate such alignment also to skeptical observers. > In Bitcoin today, a DL break would compromise funds in any addresses for > which the pubkey has been revealed and it's not even clear what to do about > the remaining funds on chain. Compromising the fundamental security of the > blockchain is a valid cause for concern. > Yes, bitcoin is wise to at least hash the pub key until use. Granted, lightning (necessarily?) risks public key exposure, but in a pinch there are other signature algorithms for lightning to move to. > In the case of Lightning, the attack scenario on scriptless scripts is > that a peer is going to use a quantum computer to steal all live payments > routed through them from their senders before they get to the recipient. > This would be bad, but not catastrophic, and once it is recognized that the > attack is possible, insecure channels could be closed. > All channels would become insecure, the very premise of lightning would thus break, which is only a problem if the world came to depend on it. But then why try a thing, unless you plan to maybe succeed? Also, we don't know that a quantum computer is necessary. SHA-1 was secure, until it wasn't, no quantum computer was needed to break it. > But furthermore, an attacker with a quantum computer could just steal the > multisig funding output directly instead of attacking scriptless scripts. > Absolutely, and today there is no redundant signature of different algorithm, in the code. (That would be better.) But even so, how hard would it be to swap one signature algorithm for another? Then users "just" move their funds to multisig addresses under the new algorithm. > So additional protocol changes relying on the DL assumption don't bother > me in the least. > I don't follow the logic. If today we would have a frantic scramble in event of sudden DL weakness, as indeed seems probable, it does not then follow that we might as well design DL weakness to become a fundamentally unsurvivable problem. DL signatures bother me less because lattice cryptography can serve as backup. Scriptless scripts worry me because I just don't know what the backup is, when (not if) DL falls. Perhaps scriptless scripts can be done with lattices(?), in which case I am simply unaware - but some such backup should be identified, at least at a conceptual level, prior to use. If this is just a toy, then never mind. If we don't expect the world to ever depend on this for anything important, then there is no need to fret over the finite lifespan of primitives. Or maybe we can just hope, that this time will be unlike all the others in the history of cryptography. Otherwise, consider for example the history of DES, or SHA-1. Those are scenarios where we saw the problems coming far enough in advance to transition. Sure, it would be better if we had redundant primitives for every function in the actual code itself - just in case of either a sudden, or else a secret, break. In fact, we should aim to one day get there. But for now, let's at least have functionally equivalent backups for every function, even if only on paper. When exciting new functionality is invented but based on a mathematically unproven assumption, then let's wait to build on it until after at least one or two mathematically dissimilar assumptions have been found as alternative backup foundation. The global economy deserves such careful hands, I think, or else we do not deserve it. Thanks, Benjamin Mord
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev