Re: [Lightning-dev] Split payments within one LN invoice
Good morning Ronan, > If there is a payment to go from party A to be split between parties B & C, > is it possible that only one of B or C would need a plugin? > > If all receiving parties need a plugin that is quite limiting. Thanks, Ronan Given N payees, only N - 1 need the plugin. The last payee in a chain of payees issues a normal invoice (C-Lightning plugin not needed). Then the previous payee takes in that invoice, and emits a new invoice, using the plugin. This goes on until the first payee is reached. The first payee then issues its invoice to the payer. To follow your example, where A pays to both B and C: * C issues a normal invoice (no plugin needed). * C hands its invoice over to B. * B receives the invoice from C and issues a plugin-provided command (`addtoinvoice`?), which creates another invoice * B hands its invoice over to A. * A pays the invoice (no plugin needed). As another example, suppose we have you paying cdecker, jb55, and ZmnSCPxj. Let us sort them in alphabetical order. * ZmnSCPxj issues a normal invoice (no plugin needed). * ZmnSCPxj hands its invoice over to jb55. * jb55 issues a plugin-provided command, giving it the invoice from ZmnSCPxj and getting out a larger invoice. * jb55 hands its invoice over to cdecker. * cdecker issues a plugin-provided command, giving it the invoice from jb55 and getting out a larger invoice. * cdecker hands over its invoice to Ronan. * Ronan pays the invoice (no plugin needed). Regards, ZmnSCPxj > > On Fri, Dec 17, 2021 at 3:06 PM ZmnSCPxj wrote: > > > Good morning cdecker, > > > > > I was looking into the docs [1] and stumbled over `createinvoice` which > > > does almost what you need. However it requires the preimage, and stores > > > the invoice in the database which you don't want. > > > > Indeed, that is precisely the issue, we need a `signfakeinvoice` command, > > as we cannot know at invoice creation time the preimage, and our invoice > > database currently assumes every invoice has a preimage known and recorded > > in the database. > > > > > > > > However if you have access to the `hsm_secret` you could sign in the > > > plugin itself, completely sidestepping `lightningd`. Once you have that > > > it should be a couple of days work to get a PoC plugin for the > > > coordination and testing. From there it depends on how much polish you > > > want to apply and what other systems you want to embed it into. > > > > Well, the point of an `hsmd` is that it might be replaced with a driver to > > an actual hardware signing module (H S M). > > The `lightningd`<->`hsmd` interface includes commands for invoice signing, > > and `signfakeinvoice` would essentially just expose that interface, so an > > HSM has to support that interface. > > So a plugin cannot rely on `hsm_secret` existing, as the signer might not > > be emulated in software (i.e. what we do now) but be an actual hardware > > signer that does not keep the secret keys on the same disk. > > This is the reason why we (well, I) created and exposed `getsharedsecret`, > > in theory a plugin could just read `hsm_secret`, but we want to consider a > > future where the HSM is truly a hardware module. > > > > Regards, > > ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Split payments within one LN invoice
If there is a payment to go from party A to be split between parties B & C, is it possible that only one of B or C would need a plugin? If all receiving parties need a plugin that is quite limiting. Thanks, Ronan On Fri, Dec 17, 2021 at 3:06 PM ZmnSCPxj wrote: > Good morning cdecker, > > > I was looking into the docs [1] and stumbled over `createinvoice` which > does almost what you need. However it requires the preimage, and stores the > invoice in the database which you don't want. > > Indeed, that is precisely the issue, we need a `signfakeinvoice` command, > as we cannot know at invoice creation time the preimage, and our invoice > database currently assumes every invoice has a preimage known and recorded > in the database. > > > > > However if you have access to the `hsm_secret` you could sign in the > plugin itself, completely sidestepping `lightningd`. Once you have that it > should be a couple of days work to get a PoC plugin for the coordination > and testing. From there it depends on how much polish you want to apply and > what other systems you want to embed it into. > > Well, the point of an `hsmd` is that it might be replaced with a driver to > an actual hardware signing module (H S M). > The `lightningd`<->`hsmd` interface includes commands for invoice signing, > and `signfakeinvoice` would essentially just expose that interface, so an > HSM has to support that interface. > So a plugin cannot rely on `hsm_secret` existing, as the signer might not > be emulated in software (i.e. what we do now) but be an actual hardware > signer that does not keep the secret keys on the same disk. > This is the reason why we (well, I) created and exposed `getsharedsecret`, > in theory a plugin could just read `hsm_secret`, but we want to consider a > future where the HSM is truly a hardware module. > > Regards, > ZmnSCPxj > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Split payments within one LN invoice
Good morning cdecker, > I was looking into the docs [1] and stumbled over `createinvoice` which does > almost what you need. However it requires the preimage, and stores the > invoice in the database which you don't want. Indeed, that is precisely the issue, we need a `signfakeinvoice` command, as we cannot know at invoice creation time the preimage, and our invoice database currently assumes every invoice has a preimage known and recorded in the database. > > However if you have access to the `hsm_secret` you could sign in the plugin > itself, completely sidestepping `lightningd`. Once you have that it should be > a couple of days work to get a PoC plugin for the coordination and testing. > From there it depends on how much polish you want to apply and what other > systems you want to embed it into. Well, the point of an `hsmd` is that it might be replaced with a driver to an actual hardware signing module (H S M). The `lightningd`<->`hsmd` interface includes commands for invoice signing, and `signfakeinvoice` would essentially just expose that interface, so an HSM has to support that interface. So a plugin cannot rely on `hsm_secret` existing, as the signer might not be emulated in software (i.e. what we do now) but be an actual hardware signer that does not keep the secret keys on the same disk. This is the reason why we (well, I) created and exposed `getsharedsecret`, in theory a plugin could just read `hsm_secret`, but we want to consider a future where the HSM is truly a hardware module. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Split payments within one LN invoice
I was looking into the docs [1] and stumbled over `createinvoice` which does almost what you need. However it requires the preimage, and stores the invoice in the database which you don't want. However if you have access to the `hsm_secret` you could sign in the plugin itself, completely sidestepping `lightningd`. Once you have that it should be a couple of days work to get a PoC plugin for the coordination and testing. From there it depends on how much polish you want to apply and what other systems you want to embed it into. Each recipient will have to run the plugin otherwise they'd not understand how to handle the payment, and creating an invoice requires a bit more work (each payee needs to coordinate to be part of the Rendez-vous), but from the senders point of view it's all seamless. As for whether this is better suited for the protocol itself: could be, probably not though. We let everybody experiment and then formalize and standardize the best ideas from the community, so it may make its way into the spec, but would need to be implemented, tested and popular enough to warrant everybody having to implement yet another feature. In this case it's more for a bLiP, which are less formal and better match the fact that only a small part of the network needs to implement it (only payees need to coordinate and forward, senders and everybody else doesn't care). Cheers, Christian [1] https://lightning.readthedocs.io/lightning-createinvoice.7.html On Fri, 17 Dec 2021, 11:22 Ronan McGovern, wrote: > Hi ZmnSCPxj, > > So, are you saying there needs to be a new command "signfakeinvoice" at > the protocol level? > > If that was there, how much work/hours would it be to build the poor man's > rendez-vous at the application level? > > If the above were to be implemented, when the payer pays the invoice, it's > then automatically split and sent to two (or more) recipients? > > Lastly, would it make more sense to have split payments at the protocol > level? > > Thanks, Ronan > > On Thu, Dec 16, 2021 at 11:44 PM ZmnSCPxj wrote: > >> Good morning William, >> >> >> > Has anyone coded up a 'Poor man's rendez-vous' demo yet? How hard would >> > it be, could it be done with a clightning plugin perhaps? >> >> Probably not *yet*; it needs each intermediate payee (i.e. the one that >> is not the last one) to sign an invoice for which it does not know the >> preimage. >> Maybe call such a command `signfakeinvoice`. >> >> However, if a command to do the above is implemented (it would have to >> generate and sign the invoice, but not insert it into the database at all), >> then intermediate payees can use `htlc_accepted` hook for the "rendez-vous". >> >> So to generate the invoice: >> >> * Arrange the payees in some agreed fixed order. >> * Last payee generates a normal invoice. >> * From last payee to second, each one: >> * Passes its invoice to the previous payee. >> * The previous payee then creates its own signed invoice with >> `signfakeinvoice` to itself, adding its payout plus a fee budget, as well >> as adding its own delay budget. >> * The previous payee plugin stores the next-payee invoice and the >> details of its own invoice to db, such as by `datastore` command. >> * The first payee sends the sender the invoice. >> >> On payment: >> >> * The sender sends the payment to the first hop. >> * From first payee to second-to-last: >> * Triggers `htlc_accepted` hook, and plugin checks if the incoming >> payment has a hash that is in this scheme stored in the database. >> * The plugin gathers `htlc_accepted` hook invocations until they sum up >> to the expected amount (this handles multipath between payees). >> * The plugin marks that it has gathered all `htlc_accepted` hooks for >> that hash in durable storage a.k.a. `datastore` (this handles a race >> condition where the plugin is able to respond to some `htlc_accepted` >> hooks, but the node is restarted before all of them were able to be >> recorded by C-Lightning in its own database --- this makes the plugin skip >> the "gathering" step above, once it has already gathered them all before). >> * The plugin checks if there is already an outgoing payment for that >> hash (this handles the case where our node gets restarted in the meantime >> --- C-Lightning will reissue `htlc_accepted` on startup) >> * If the outgoing payment exists and is pending, wait for it to >> resolve to either success or failure. >> * If the outgoing payment exists and succeeded, resolve all the >> gathered `htlc_accepted` hooks. >> * If the outgoing payment exists and failed, fail all the gathered >> `htlc_accepted` hooks. >> * Otherwise, perform a `pay`, giving `maxfeepercent` and `maxdelay` >> based on its fee budget and delay budget. >> When the `pay` succeeds or fails, propagate it to the gathered >> `htlc_accepted` hooks. >> * The last payee just receives a normal payment using the normal >> invoice-receive scheme. >> >> Regards, >> ZmnSCPxj >> > __
[Lightning-dev] Payment sender authentication
Hello list, In Lightning we have a great scheme to protect the identity of the sender of a payment. This is awesome, but there are also use cases where opt-in sender authentication is desired. An example of such a use case is chat over lightning. If you receive a text message, you generally want to know whom it originates from. For whatsat [1], I added a custom record containing an ECDSA signature over `sender | recipient | timestamp | msg`. I believe other chat protocols on lightning use a similar construction. For regular payments however, sender authentication can be useful too. A donation for example doesn't always need to be anonymous. A donor may want to reveal themselves. In other cases, sender authentication can add a layer of protection against payments getting lost. It provides the receiver with another field that they can use to retrieve lost payment information. On the receiver side, sender authentication also creates new possibilities. A receiver could for example create an invoice that is locked to a specific source node. Also wanted to note that the sender identity doesn't need to be the actual node identity. It can also be an unrelated key that could for example be specific to the service that is being paid to. For example, one registers the public part of a dedicated key pair with an exchange and the exchange then only accepts deposits authenticated with that key. The reason for bringing this up on the list is that I wanted to see what people think is the best way to do it technically. The whatsat approach with an ECDSA signature doesn't look ideal to me because of the non-repudiation property. Also care needs to be taken that whatever data the sender includes, cannot be reused. Another option that I can think of is to derive a shared secret using ECDH with the sender and receiver node keys and then attach a custom record to the payment containing the sender node key and an HMAC of the payment hash using the shared secret as a key. I am sure there people better versed in cryptography than me who have an opinion on this. Thoughts? Joost [1] https://github.com/joostjager/whatsat ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Split payments within one LN invoice
Hi ZmnSCPxj, So, are you saying there needs to be a new command "signfakeinvoice" at the protocol level? If that was there, how much work/hours would it be to build the poor man's rendez-vous at the application level? If the above were to be implemented, when the payer pays the invoice, it's then automatically split and sent to two (or more) recipients? Lastly, would it make more sense to have split payments at the protocol level? Thanks, Ronan On Thu, Dec 16, 2021 at 11:44 PM ZmnSCPxj wrote: > Good morning William, > > > > Has anyone coded up a 'Poor man's rendez-vous' demo yet? How hard would > > it be, could it be done with a clightning plugin perhaps? > > Probably not *yet*; it needs each intermediate payee (i.e. the one that is > not the last one) to sign an invoice for which it does not know the > preimage. > Maybe call such a command `signfakeinvoice`. > > However, if a command to do the above is implemented (it would have to > generate and sign the invoice, but not insert it into the database at all), > then intermediate payees can use `htlc_accepted` hook for the "rendez-vous". > > So to generate the invoice: > > * Arrange the payees in some agreed fixed order. > * Last payee generates a normal invoice. > * From last payee to second, each one: > * Passes its invoice to the previous payee. > * The previous payee then creates its own signed invoice with > `signfakeinvoice` to itself, adding its payout plus a fee budget, as well > as adding its own delay budget. > * The previous payee plugin stores the next-payee invoice and the > details of its own invoice to db, such as by `datastore` command. > * The first payee sends the sender the invoice. > > On payment: > > * The sender sends the payment to the first hop. > * From first payee to second-to-last: > * Triggers `htlc_accepted` hook, and plugin checks if the incoming > payment has a hash that is in this scheme stored in the database. > * The plugin gathers `htlc_accepted` hook invocations until they sum up > to the expected amount (this handles multipath between payees). > * The plugin marks that it has gathered all `htlc_accepted` hooks for > that hash in durable storage a.k.a. `datastore` (this handles a race > condition where the plugin is able to respond to some `htlc_accepted` > hooks, but the node is restarted before all of them were able to be > recorded by C-Lightning in its own database --- this makes the plugin skip > the "gathering" step above, once it has already gathered them all before). > * The plugin checks if there is already an outgoing payment for that > hash (this handles the case where our node gets restarted in the meantime > --- C-Lightning will reissue `htlc_accepted` on startup) > * If the outgoing payment exists and is pending, wait for it to > resolve to either success or failure. > * If the outgoing payment exists and succeeded, resolve all the > gathered `htlc_accepted` hooks. > * If the outgoing payment exists and failed, fail all the gathered > `htlc_accepted` hooks. > * Otherwise, perform a `pay`, giving `maxfeepercent` and `maxdelay` > based on its fee budget and delay budget. > When the `pay` succeeds or fails, propagate it to the gathered > `htlc_accepted` hooks. > * The last payee just receives a normal payment using the normal > invoice-receive scheme. > > Regards, > ZmnSCPxj > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Route reliability<->fee trade-off control parameter
On Mon, Nov 22, 2021 at 5:11 PM Stefan Richter wrote: > I also don't believe putting a choice of more or less seconds expectation > in the UI makes for a great user experience. IMHO the goal should just be: > give the user an estimate of fees necessary to succeed within a reasonable > time. Maybe give them an option to optimize for fees only if they are > really cheap and don't care at all if the payment succeeds. > In the ideal world, I'd agree to this. But how close to that are we today? Suppose we'd define reasonable time as 3 seconds to complete the payment. And to stay below that, we need to use a short, expensive, high success probability route that amounts to a fee of 1%. Would users be happy with a take it or leave it approach or rather pay 0.1% and wait 30 seconds? I think that for the state of Lightning as it is currently, some kind of control lever is useful to bridge the gap to payments that are always fast and cheap. The checkbox that you propose is also a control lever, but it is pretty minimalistic. Joost ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Route reliability<->fee trade-off control parameter
On Mon, Nov 22, 2021 at 7:53 AM ZmnSCPxj wrote: > Good morning Dave, > > > If LN software speculatively chooses a series of attempts with a similar > > 95%, accounting for things like the probability of a stuck payment (made > > worse by longer CLTV timeouts on some paths), it could present users > > with the same sort of options: > > > > ~1 second, x fee > > ~3 seconds, y fee > > ~10 seconds, z fee > > > > This allows the software to use its reliability scoring efficiently in > > choosing what series of payment attempts to make and presents to the > > user the information they need to make a choice appropriate for their > > situation. As a bonus, it makes it easier for wallet software to move > > towards a world where there is no user-visible difference between > > onchain and offchain payments, e.g.: > > > > ~1 second, w fee > > ~15 seconds, x fee > > ~10 minutes, y fee > > ~60 minutes, z fee > > This may not match ideally, as in the worst case a forwarding might be > struck by literal lightning and dropped off the network while your HTLC is > on that node, only for the relevant channel to be dropped onchain days > later when the timeout comes due. > Providing this "seconds" estimate does not prepare users for the > possibility of such black swan events where a high fee transaction gets > stalled due to an accident on the network. > I like the idea of providing the user with such choices, similar to how for example Uber presents its options. But I also agree with Z that it is probably impossible to get a number of seconds there that comes close to the actual time it would take. For LND, I am currently proposing a fuzzy "time preference" parameter that is vaguely indicative of the time that the payment is expected to take ( https://github.com/lightningnetwork/lnd/pull/6024). On the UI level this can either be surfaced as a slider or the cost for three predefined values for time preference can be shown: Slow: 10 msat Normal: 150 msat Fast: 4000 msat > Why not just ask for a fee budget for a payment, and avoid committing > ourselves to paying within some number of seconds, given that the seconds > estimate may very well vary depending on local CPU load? > Would users really complain overmuch if the number of seconds is not > provided, given that we cannot really estimate this well? > A fee budget indeed expresses the time preference indirectly. But how does the user know what a reasonable value is to set this to? It is depend on network conditions. They may accidentally set it to a value that is too low and get an unexpectedly slow payment. Joost ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
