[Lightning-dev] Maintenance service for Lightning Network
anton.kumaigorodskiy at outlook.com
Tue Apr 5 17:47:34 UTC 2016
Thanks for clarifying how routing data is supposed to work. Still I don't quite understand how one can make an initial payment request. What I mean is say I run a Lightning node on my phone and someone knows my bitcoin-pubkey-style ID only, how can our devices connect for me to provide all the info upon request?
One way I can think of is both our devices should establish a socket connections to current landmark nodes and continue communication through one of them but this can be overwhelming both for a phone (10? websocket connections at once) and for landmark nodes (possibly billions of socket connections).
Or perhaps there could be some deterministic method that, given a user's ID and overall network topology, would determine to what exact node should that exact ID connect? This could at least distribute the load across the network.
And then there are DDoS attacks, as far as I understand it could be fairly easy for someone to spam a Lightning device with millions of payment requests. This perhaps could be mitigated with requests rationing via blind signatures but I have no idea how to enforce that on a distributed network.
> From: rusty at rustcorp.com.au
> To: anton.kumaigorodskiy at outlook.com; lightning-dev at lists.linuxfoundation.org
> Subject: Re: [Lightning-dev] Maintenance service for Lightning Network
> Date: Mon, 4 Apr 2016 11:49:32 +0930
> Kumaigorodskiy Anton 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!).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Lightning-dev