Re: [Lightning-dev] Network probes
This seems like a bad idea as it could create timing attacks to discover if a node is the target for a payment. Matt On 1/18/19 9:06 PM, Olaoluwa Osuntokun wrote: Nodes can and eventually should start using bloom filters to avoid most database lookups for incoming payment hashes. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Mandatory "d" or "h" UX issues
What about this? https://github.com/btcontract/lnurl-rfc/blob/master/spec.md#2-withdrawing-funds-from-a-service On Monday, January 21, 2019, Rusty Russell wrote: > 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 mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Lightning and the semantic web
Dear Melvin, have you looked into the W3C Payment Group? https://www.w3.org/TR/payment-request/ The entire field of semantic web kind of originated from W3C and they are working on a recommendation for browser vendors to enable a low level payment API. Also there is LightningJoule that builds on top of webln. While this is not an otology it goes implicitly in a similar direction (c.f.: https://github.com/wbobeirne/webln and in particular this discussion: https://github.com/wbobeirne/webln/issues/1 in which Will said that in his thoughts webln is different to the W3C Payment Group.) I am looking forward to see your progress with integrating Lightning to the semantic web! with kind regards Rene On Mon, Jan 21, 2019 at 7:17 AM Melvin Carvalho wrote: > 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 > -- https://www.rene-pickhardt.de Skype: rene.pickhardt mobile: +49 (0)176 5762 3618 ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Lightning and the semantic web
On 2019/01/21 08:17, Melvin Carvalho wrote: > 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. How do we do that? Build a list of relevant concepts and create possible attributes and links between? i.e. node pubkey ipaddress numberchannels channel stateactive/stateclosed channel fundingtx localbalance remotebalance closingfee stateopen/stateclosed fundingtx datetime amount fee transaction invoice amount destination validtime channelbreach datetime error result -- regards, Bretton openpgp: http://bretton.hivemind.net/bretton_vine.asc ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Network probes
Hi Laolu, Great idea, effectively with a clever (hierarchical) usage of bloom filters nodes can reduce to the bare minimum the DB lookups. I guess with that considered it's probably redundant to have an explicit probe flag for the sender? Not for technical reasons though (the EOB can easily support that - just need an extra type) but it seems to me that the only benefit can be already torn away by client-side optimizations and it wouldn't improve much to have an explicit probe at this point. Cancellable probes is indeed an attracting idea, if i understood it correctly it is about the sender being able to send out another different type of probe that would tell the intermediate nodes that the previous one wasn't actually a payment - allowing the network to free resources. I agree that introducing probes that can be dropped and/or prioritized by intermediate nodes is a privacy issue and can be abused, it allows them to respond differently thus the probe result can not be trusted entirely, perhaps a node policy where nodes would temporary ban a peer that is adding too many unredeemable HTLCs is enough for the moment. Cheers, Andrea. On Fri, 18 Jan 2019 at 22:07, Olaoluwa Osuntokun wrote: > Hi Andrea, > > > This saves the receiving node from doing a database lookup > > Nodes can and eventually should start using bloom filters to avoid most > database lookups for incoming payment hashes. The false positive rate can > be > set to a very low value as the bloom filter doesn't need to transmitted, > and > can even be stored persistently. As an optimization, nodes may opt to > maintain a series of hierarchical bloom filters, with the highest tier > filter containing only payment hashes for non-expired invoices. Clever > bloom > filter usage by nodes would allow them to avoid almost all database lookups > for incoming unknown payment hashes (probes or not). > > > we can improve it by using the `padding` of the `per_hop` field of the > > onion; > > I recently implemented a type of spontaneous payment [1] that works today > in > the wild (gotta love dat End to End Principle). A requirement for this was > fully functional EOB packing logic at the sender, and multi-packet > unwrapping at the receiver, the modified packet construction/processing can > be found here [2]. Using the terminology of the current draft code, all > that > would need to be done is specify an EOB type for this special probe type of > HTLC. As it doesn't need any additional data, it only consumes a single > pivot hop and doesn't require the route to be extended. > > Have you seen aj's prior post [3] on this front (making probe HTLCs > identifiable to the receiver, and allowing intermediate nodes to drop > them)? > Allowing intermediate nodes to identify probe HTLCs has privacy > implications, as all of a sudden we've created two path-level classes of > HTLCs. On the other hand, this may help with QoS scheduling on the > forwarding plane for nodes, they may want to prioritize actual payments > over > probes, with some nodes opting to not forward probes all together. > > [1]: https://github.com/lightningnetwork/lnd/pull/2455 > [2]: https://github.com/lightningnetwork/lightning-onion/pull/31 > [3]: > https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001554.html > > -- Laolu > > > On Fri, Jan 18, 2019 at 8:47 AM Andrea RASPITZU > wrote: > >> Good morning list, >> >> I know there have been discussion around how (and if) we should probe the >> network to check for the liveliness of a path before sending out the >> payment. Currently we issue a payment with a random payment_hash that is >> not redeemable by anyone, if the destination (and the path) is `lively` it >> will respond Error. Assuming we do want to probe, and it make sense to >> assume so because it can't be prevented, we can improve it by using the >> `padding` of the `per_hop` field of the onion; with a single bit of the >> padding we can tell the final node that this is a probe and not an actual >> payment. This saves the receiving node from doing a database lookup >> (checking if it has the preimage for such a payment_hash) and it does not >> reveal anything to intermediate nodes, we don't want them to change the >> behavior if they know it's a probe and not an actual payment. I believe >> probing can help reducing the error rate of payments (and even detect stale >> channels?) and I'm looking forward to have some feedback, and submit a >> draft. >> >> Cheers, Andrea. >> ___ >> Lightning-dev mailing list >> Lightning-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
