[Lightning-dev] Maintenance service for Lightning Network

Rusty Russell rusty at rustcorp.com.au
Mon Apr 4 02:19:32 UTC 2016

Kumaigorodskiy Anton <anton.kumaigorodskiy at outlook.com> writes:
> Hi everyone,

Hi Anton!

        Sorry for the delay in response: these are great questions and
deserve a thought-through response.

> I think LN is a great idea and would like to add it to my Bitcoin wallet. I've been thinking for some time now about how LN could work for an end users (ideally dealing with it should be less frustrating than dealing with Bitcoin itself).

This is definitely worth thinking about.

> As far as I understand a payment sender needs to obtain at least three "core" pieces of data before he can start interacting with LN (plus maybe some metadata):
> 1. Required hash of R-value.
> 2. Required list of "full node" URL's where receiver currently has
> open channels.
> 3. Required list of receiver ID's for each "full node" (so "full node"
> will know whom to ask for R-value).
> 4. Optional but sometimes desirable metadata like name, picture,
> address etc.

It's slightly more general.  You need the R-hash, and one (or more)
routes.  In particular, you need the fee information for the route.

My current thinking is:
0) Nodes have an ID, which is a bitcoin-style pubkey.
1) Nodes publish their public routes by proving they own the anchor
   transactions for their channels.
2) Nodes occasionally update their fees for their channels.
3) Every 24 hours(?) a new set of (10?) landmarks are selected using the
   bitcoin block hash.
4) Every node keeps information on routes to and from the landmarks.

This means a step in a route can be represented as a block number and a
transaction number, making them quite compact.  To accept a payment you
would give:

1) A unique hash of R-value.
2) An amount.
3) Route information from a landmark to you.  Maybe more than one.

It also means that the receiving node doesn't know where the sending
node is.

> And further requirements:
> - "Lightning address" and QR-code approach won't work as R-value should be unique. Ideally no piece of "core" data should be easily accessible as text or QR to avoid confusion.

If you want you can do donation-style send by having the sender encode
the R-value inside the routing information.  But you'll still need
fairly recent routing information.

> - "core" data sould come directly from receiver's device, either via internet or locally wia bluetooth, WiFiP2P, NFC, etc.
> - Sender needs a way to verify that receiver is who he says he is which means resistance to MITM and identity theft plus some kind of "name authority" to validate metadata.
> Taking all the above into account it seems to me that:
> 1. LN users should be able to generate stable identites on their
> devices. EC25519 keys seem a good fit to me because of their small
> size and applicability for both encryption and signing.

We've chosen to use the bitcoin curve, since we rely on it anyway.

> 2. There has to be a service parallel to LN that can transfer "core"
> data in encrypted form (easy because identities are pubKeys), perhaps
> store requests for some time if receiver's device is offline,
> optionally act as third-party watcher for broadcasted commitment
> transactions and, finally, act as "name authority" for users who
> supplied some metadata along with their public keys.

Since we need to store and send route information, adding other
information should be fairly easy.

Offline receive is much harder, and I'm not planning on supporting it in
a 1.0 spec.  Either the receiver needs to trust someone to collect the
payment, or pay extra for all the funds they will tie up in the network
waiting for the receiver to come online.

Hope that clarifies my thinking (and I'm sure others will add their
thoughts too!).


More information about the Lightning-dev mailing list