Lightning Specification Meeting 2022/01/31

[t-bast]

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

• Anchor output sighash clarification Clarify the sighash types for HTLC Success and Timeout transactions #954
• Route blinding Route Blinding (Feature 24/25) #765
• Onion messages BOLT 7: Onion message support (features 38/39) #759
• Offers Offers #798
• Add dust exposure threshold Add a max_dust_htlc_exposure_msat #919
• Simple turbo channels enablement Explicitly allow funding_locked early, and support alias scids (feat 46/47/50/51) #910
• Dynamic DNS support in gossip messages BOLT 7: add gossip address descriptor type DNS hostname #911

Long Term Updates

• Dual funding interactive-tx: Add dual-funding flow, using the interactive tx protocol (feature 28/29) #851
• Liquidity ads option_will_fund: liquidity ads #878
• Splicing Splice draft (feature 62/63) #863
• Simplified commitment Feature 106/107: option_simplified_update. #867
• Trampoline routing Trampoline Routing (2021 edition) (Feature 56/57) #829 and Trampoline onion format (Feature 56/57) #836
• Upfront payments / DoS protection Hold fees #843
• Peer storage backup Peer backup storage (feature 40/41/42/43) #881
• Anonymous gossip
• Taproot 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.

• lnprototest (https://github.com/rustyrussell/lnprototest)

[arik-so]

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:

• Channel announcements prove inclusion of a public key in a Merkle tree in a zero-knowledge context using a SNARK-friendly hash function, and nodes independently build Merkle trees based on UTXOs using the same hash function to compare the roots.
• Channel announcements additionally include a signature using the private key to prove its knowledge. In order for the signature to be verifiable in a ZKP context, it needs to use a curve other than secp256k1 with a different (larger) base field, so the ZKP also has to include proof of equality between the private keys for their corresponding public keys across the curves.

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

• PLONK
  • Benefit: transparent setup
  • Proof size: 2-3KB
  • Verification time: 0.5-1 seconds, worse case up to 2-3s
• STARKs
  • Benefit: transparent setup
  • Proof size: 20KB best case scenario, but most likely closer to 200KB
  • Verification time: 1-2s
• SNARKs
  • Benefit: constant proof size and verification time
  • Proof size: 300-400 bytes
  • Verification time: 20-25ms

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]

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]

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]

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]

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]

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]

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]

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]

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]

Are there logs available from jitsi and/or irc?

[vincenzopalazzo]

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]

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

[michaelfolkson]

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

[michaelfolkson]

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.)