search

lightning / bolts

BOLT: Basis of Lightning Technology (Lightning Network Specifications)
2.08k stars 492 forks source link

Lightning Specification Meeting 2022/01/31 #955

Closed t-bast closed 2 years ago

t-bast commented 2 years ago

The meeting will take place on Monday 2022/01/31 at 7pm UTC (5:30am Adelaide time) on Libera Chat IRC #lightning-dev. It is open to the public.

A video link is available for higher bandwidth communication: https://meet.jit.si/Lightning-Spec-Meeting

Pull Request Review

Long Term Updates

Backlog

The following are topics that we should discuss at some point, so if we have time to discuss them great, otherwise they slip to the next meeting.

arik-so commented 2 years ago

Jeff Czyz, Matt, Rusty and I spent some time looking into making gossip more private by means of ZKPs. The overarching approach being essentially the following:

We compared some proof mechanisms including PLONK, STARKs, and SNARKs, and came up with the following estimates for proof sizes and verification times:

Some additional considerations are, for once, that with Schnorr cooperative channel opens, there is no singular private key either node knows and could therefore prove in the channel announcement message. That means that rather than using a SNARK-optimized curve and proving key equivalence, secp256k1 emulation circuitry might need to be embedded inside the proof. A SNARK-native EC point multiplication requires ~3,500 constraints, whereas a non-native one would require ~100,000, which means that for the two multiplications required for a Schnorr sig verification, the constraint count would grow to ~200,000.

Additionally, assuming the Merkle tree allows for up to a depth of 17, using a SNARK-friendly hash function that takes up 750 constraints, the Merkle proof would add an extra 12,750 constraints, which admittedly is somewhat negligible compared to the non-native EC point multiplication issue.

Lastly, and in our opinion, most striking of all, there really don't appear to be any mature libraries for any of the proof mechanisms. Everything is highly experimental, and even though there technically are a lot of different libraries available, especially for SNARKs, not a single one is production-ready. If there's any motivation in the Lightning community to pursue this further, I think that would likely mean a delay of possibly 6-12 months.

t-bast commented 2 years ago

Thanks for the summary!

Most of these schemes are still in the iteration phase at the academic level, so I believe it's expected that there's no production-ready, mature library. I'm afraid it will likely take years before such libraries are available (so much has changed already since Groth16!).

Unfortunately I think we probably need to rule out SNARKs (because we don't want to go through a trusted setup just for gossip stuff). PLONK looks like it could be a good fit, but is it going to be obsolete in one year once a new paper provides a more efficient iteration (or finds a flaw)? STARKs are somewhat more stable, but I believe most of the good libraries are closed-source (unless StarkWare has something that we can easily use?).

I was hoping we could find something based on less fancy crypto (e.g. ring signatures, which are easy to do with schnorr), but I really haven't given it much thought so it's probably a dead-end.

arik-so commented 2 years ago

Thanks for your response!

Indeed, in our discussions with Rusty, ring sigs did come up, though as far as I understand, the signature size grows approximately proportionally with the number of pubkeys included in the set.

If there were a way to create a ring signature that would hypothetically validate only against a given ordered set of pubkeys, thus allowing nodes to supply a lion's share of the data necessary for verification simply by tracking the UTXO set, things would be much easier.

t-bast commented 2 years ago

the signature size grows approximately proportionally with the number of pubkeys included in the set.

Yes, that's the main issue. That's where we'd need to be smart, and see if we can have most of it be deterministically computed at each block by every node and have that reduce the size of the signature (this is very very hand-wavy, I know!).

Roasbeef commented 2 years ago

the signature size grows approximately proportionally with the number of pubkeys included in the set.

log scaling ring signatures exist, though they're a bit more heavy weight than the borromean ring variant most of us are likely somewhat familiar with.

TheBlueMatt commented 2 years ago

log scaling ring signatures exist, though they're a bit more heavy weight than the borromean ring variant most of us are likely somewhat familiar with.

Yea, sadly that also fails the "mature implementations exist" criteria like basically all ZK proof systems :(

Roasbeef commented 2 years ago

Late addition: what do ppl think about moving https://github.com/cdecker/lightning-integration to the new lightning org? We're interested in reviving it, and start to run automated builds of it alongside our release candidates and major releases.

TheBlueMatt commented 2 years ago

Late addition: what do ppl think about moving https://github.com/cdecker/lightning-integration to the new lightning org? We're interested in reviving it, and start to run automated builds of it alongside our release candidates and major releases.

In principle, yes, how does that compare to https://github.com/rustyrussell/lnprototest/ ?

cdecker commented 2 years ago

Definitely go with lnprototest, the lightning-integration thing was good initially, but too slow due to the n^2 setup, whereas lnprototest is a star-like system where everybody tests against scripted scenarios and checks the behavior.

joostjager commented 2 years ago

Are there logs available from jitsi and/or irc?

vincenzopalazzo commented 2 years ago

Are there logs available from jitsi and/or irc?

Yes, we have the recording meeting, I think that the transcript will be available soon.

michaelfolkson commented 2 years ago

Yeah I'll post it here in the next couple of days. Apologies for the delay.

michaelfolkson commented 2 years ago

Transcript: https://github.com/michaelfolkson/bitcointranscripts/blob/lightning-2022-01-31/lightning-specification/2022-01-31-specification-call.md

michaelfolkson commented 2 years ago

Another consideration that I don't believe has been discussed (at least above) on ZK proofs, ring sigs is replicability. If we want to prevent a commitment to a particular UTXO being used to gossip thousands/millions of channels ideally you'd only be able to use it once. Or a weaker form would be the ZK proof not being malleable so if it was used to gossip multiple channels a network participant would be able to identify that it was being used multiple times.

It sounds like ZK proofs, ring sigs aren't being pursued for the time being for the reasons stated by various participants but just thought I'd post this in case it is revisited in future.

(I added a StackExchange post too.)