[Lightning-dev] Scriptless Scripts with ECDSA

Benjamin Mord ben at mord.io
Tue May 8 22:02:46 UTC 2018


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180508/efb40998/attachment-0001.html>


More information about the Lightning-dev mailing list