Lightning Network Interoperability via Submarine Swaps

If the Bitcoin Lightning Network starts getting significant adoption, Grin may have difficulty competing, even with its privacy and scaling advantages.

Grin is missing a few primitives needed for an efficient lightning network implementation, specifically per-transaction relative timelocks.

But, directly supporting a grin-denominated lightning network may not be critical. Submarine swaps[0][1] are a proposed technique to atomically bridge an on-chain bitcoin payments into off-chain lightning payments or channel openings, or vice versa.

Grin supports adapter signatures–as already used by Jasper to perform BTC/grin and ETH/grin atomic swaps–which are all that are necessary for submarine swaps. The following transaction types are possible:

  1. On-chain grin → bitcoin lightning network payment: pay a BTC-denominated lightning network invoice with on-chain grin
  2. Bitcoin lightning network payment → on-chain grin: Create a LN-invoice that credits you, via an atomic swap, with on-chain Grin
  3. On-chain grin → bitcoin lightning network channel open: open a BTC-denominated lightning network channel with on-chain grin
  4. Bitcoin lightning network channel close → on-chain grin: Close out a BTC lightning network channel and receive on-chain grin

I think that #3 and #4 are probably the most interesting, since #1 and #2 bridge an on-chain transaction and an off-chain transaction, which burdens what would otherwise be a speedy, low-fee off-chain transaction with fees and delays from the on-chain component. Channel opens and closes are themselves on-chain transactions, so adding an additional cross-chain on-chain component isn’t a significant extra burden.

Just wanted to throw this out there, since others might find it interesting.



Interesting post. Thanks

I’m interested to see if grins small data footprint, make it possible to never need to stake coins to a 2nd layer protocol. In that, if there is a lightning network type thing for grin, that it arises soley out of the utility of payment channels, rater than arising as a ‘solution’ to some problem.

On a side note, I never really saw lightning as a scaling solution even though it is. To me it’s a 2nd layer payment protocol, and always has been.

Thanks for the post, it got me thinking that’s for sure.