pull down to refresh

**Lightning in a Jar: where it stands, and looking for LND operators**
1517 sats \ 1 comment \ @modulo 16 Oct bitcoin privacy lightning

Lightning in a Jar (LiJ) is a Lightning and on-chain bitcoin wallet that opens in your browser. It runs on LDK compiled to WASM, under the MIT licence. There's no app store and no account.

What works today, on mainnet:

  • Your 12 words are the wallet, in any wallet. When a channel closes, your share pays to a plain address from your own seed. Sparrow, BlueWallet or any standard wallet finds it with the same 12 words.
  • Black start. If your phone, your backup and your provider are all gone, the 12 words still recover everything at lightninginajar.xyz/recover. An encrypted Black start kit is held by every participating LIJOX provider and by  various public Nostr relays.
  • Payments wait for you. If your phone is off, your provider holds incoming payment messages for hours.
  • Silent payments, send and receive.
  • Multi-recipients
  • South African shop QR codes (Pick n Pay and others) paid through MoneyBadger.
  • Delegate payments. Fund an errand runner who has no wallet. The provider holds the chit's sats until they are spent.
  • Coinjoin pools built on the public joinstr code. The first mainnet pool went through on Oct 13 with three wallets. LiJ-private and public Nostr pools are online—I call it Tatara (Forge).

LIJOX is the open list of providers. Any operator signs an entry and wallets choose among them, with no approval and no lock-in. The provider software is an MIT adapter that runs beside LND, with an operator console.

I run two lsp nodes right now to get it off the ground.

I'm looking for:

  • LND node operators willing to run a LIJOX provider. The adapter runs on stock LND. To give LiJ wallets instant channels that the 12 words can recover, LND needs a small change: instant (zero-conf) channels without anchors. LND already accepts that channel type when LDK opens one; the change lets LND open it too. I will propose it to LND, and in the meantime I can supply a patched build.
  • Someone to review the LDK patch set, documented in docs/ldk-patches.md.

Try it: https://lightninginajar.xyz

Code: github.com/dav1dpgit/lightninginajar · github.com/dav1dpgit/LIJOX · github.com/dav1dpgit/lijox-lnd-adapter

Contact: dp@modulo.network

write
compose
related posts
8 sats \ 0 replies \ @satoshi_research 18 Oct -22 sats

For LND operators weighing this, LND's own zero-conf doc sets out today's constraints:

  • Both sides need protocol.option-scid-alias and protocol.zero-conf set, or zero-conf channels won't work.
  • When LND opens a zero-conf channel, it must use the anchors channel type. That's the limit you're describing.
  • As the receiving side, LND can already accept a zero-conf channel from a non-LND funder such as LDK, but only through a ChannelAcceptor, and the scid-alias feature must be negotiated. Without a ChannelAcceptor, LND fails every incoming open request.

Source: https://github.com/lightningnetwork/lnd/blob/master/docs/zero_conf_channels.md