Re: [Lightning-dev] Mandatory "d" or "h" UX issues
Francis Pouliot writes: > Here is how I picture the ux issues taking place. > >1. User goes on my app to buy Bitcoin with fiat, and opts to be paid out >via LN rather than on-chain BTC. >2. My app will tell him: "make an invoice with the following: msatoshi, >description. >3. He will go in his wallet and type msatoshi, description. >4. It's likey he won't pay too much attention, make a typo in >description, leave it blank, write his own description, etc. >5. When my app tries to pay, we of course have to decode his bolt11 >first. >6. We have to have some logic that will compare the "h" or "d" that we >instructed him to create and the "h" or "d" that we got from the decoded >bolt 11 (which is an extra hassle for devs) >7. In the cases there they are not the same, we need to instruct the >user to create a new bolt 11 invoice because the one he created was not >correct. Yes, there's a missing "give me an invoice" API for this kind of push payment. yalls.org has the same problem: there's a clumsy API where you give them an invoice and it pays it if you have that much. lninv: URL? Description, min and max amounts, submission URL? Ideally the browser would reach out to the wallet to get an invoice and do the submission itself (preserving sessions, cookies, etc) but I'm not sure how that part of the stack works? There was talk of something similar in Adelaide, but I hadn't appreciated the concrete problem at the time :( Cheers, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Unification of feature bits?
Hi all, I have a concrete proposal for feature bits. 1. Rename 'local features' to 'peer features'. 2. Rename 'global features' to 'routing features'. 3. Have them share a number space (ie. peer and routing features don't overlap). 4. Put both in `features` in node announcements, but never use even bits for peer features. This means we can both use node_announcement as "connect to a peer which supports feature X" and "can I route through this node?". Similarly, (future) DNS seed filtering might support filtering only by pairs of bits (ie. give me peers which support X, even or odd). Cheers, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Lightning and the semantic web
Hi All I work on the solid project [1] and am very interested in the lightning network. In particular, I am looking at trying to create an integration between lightning (layer 2) and solid (layer 3? web layer?). The first step towards integration would be to port some of the lightning concepts to the semantic web. This is done by creating an ontology. Does anyone know of any existing work in this area. Alternatively, does anyone have an interest to collaborate on an ontology? Best Melvin [1] https://solid.mit.edu/ ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Quick analysis of channel_update data
Additional info on channel_update traffic: Comparing daily backups of routing tables over the last 2 weeks shows that nearly all channels get at least a new update every day. This means that channel_update traffic is not primarily cause by nodes publishing new updates when channel are about to become stale: otherwise we would see 1/14th of our channels getting a new update on the first day, then another 1/14th on the second day and so on.This is confirmed by comparing routing table backups over a single day: nearly all channels were updated, one average once, with an update that almost always does not include new information. It could be caused by "flapping" channels, probably because the hosts that are hosting them are not reliable (as in is often offline). Heuristics can be used to improve traffic but it's orhtogonal to the problem of improving our current sync protocol. Also, these heuristics would probaly be used to close channels to unreliable nodes instead of filtering/delaying publishing updates for them. Finally, this is not just obsessing over bandwidth (though bandwidth is a real issue for most mobile users). I'm also over obsessing over startup time and payment UX :), because they do matter a lot for mobile users, and would like to push the current gossip design as far as it can go. I also think that we'll face the same issue when designing inventory messages for channel_update messages. Cheers, Fabrice On Wed, 9 Jan 2019 at 00:44, Rusty Russell wrote: > > Fabrice Drouin writes: > > I think there may even be a simpler case where not replacing updates > > will result in nodes not knowing that a channel has been re-enabled: > > suppose you got 3 updates U1, U2, U3 for the same channel, U2 disables > > it, U3 enables it again and is the same as U1. If you discard it and > > just keep U1, and your peer has U2, how will you tell them that the > > channel has been enabled again ? Unless "discard" here means keep the > > update but don't broadcast it ? > > This can only happen if you happen to lose connection to the peer(s) > which sent U2 before it sends U3. > > Again, this corner case penalizes flapping channels. If we also > ratelimit our own enables to 1 per 120 seconds, you won't hit this case? > > > But then there's a risk that nodes would discard channels as stale > > because they don't get new updates when they reconnect. > > You need to accept redundant updates after 1 week, I think. > > Cheers, > Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
