[Lightning-dev] Feedback on LN-to-BTC invoicing tool
Hi folks, Danny (on the TrelisDev email) and I have built out an MVP for an invoicing tool that issues an LN invoice and then pays it out to a merchant's BTC account. A few things I'm looking to get input on right now. Your assistance - or tips on people to talk to - would be greatly appreciated: *1. Lightning to Bitcoin Cash-out* The reason for taking this approach is that it was difficult to find a way to support lightning to lightning payments in a non-custodial way. The options we saw were: 1. Trampoline node (like Phoenix) - requiring management of liquidity for our node, which is a pain (and may or may not be custodial?) 2. LN bits approach - which is custodial. Obviously cashing LN out to BTC isn't ideal (due to LN fees + Boltz 0.5% swap fee + Bitcoin on-chain fee), particularly because of the on-chain fee, but at least we can do it more non-custodially. I am interested in better technical approaches. Ideally, we'd like to non-custodially facilitate lightning invoice generation (without the merchant having to set up a node with a BTC pay server type approach = too complicated for most merchants imo). *3. Bitcoin Price Volatility* Generally, I'm skeptical a tool like this can get a lot of adoption because Bitcoin price right now is too volatile to be useful to customers and merchants. I guess there is a bounty for building contracts for difference (illegal in the US) that would support a dollar-pegged asset in lightning channels, but I'm guessing that's 6-12 months away from being usable. Ideas on approaches for addressing this would be appreciated. Cheers, Ronan ~~~ P.S. I have two less technical things I'm thinking about. I know this is a dev thread, but if anyone has reccs or folks to talk to that would be much appreciated. *a. Regulatory Status* I would like to understand whether merchants making use of Trelis software to build a payments page brings Trelis under regulation, and what options there are for handling this in the case of: a) just for providing the software b) specifically with our current implementation, where the merchant uses our api to have Boltz.exchange create a bitcoin lightning invoice that swaps to a bitcoin payment to the merchant's wallet. *b. Mitigating Fraud* I am concerned both about fraudulent merchants creating payment links *and* about the image/brand of Trelis vis-a-vis the merchants that it serves. Broadly, I see two extremes for the approach Trelis could take: 1) No Verification ~ in which case there is probably an adverse selection problem for the types of merchant that would use Trelis. 2) Use Verification: ~ in which case Trelis needs to make moral judgements around what types of businesses to support. To a degree, we already have a layer of this by requiring login with gmail, and could progressively build on this. ___ 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
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
[Lightning-dev] Split payments within one LN invoice
Hi folks, I'm Ronan - based in Dublin and building Trelis.com (simple payment links to accept Lightning). I'm wondering if there is a way to create an invoice that splits the payment to two lightning addresses? If not, what would be required to develop this? * A protocol change? * Could it be built with the current protocol (I see an app on LN Bits to split but it doesn't seem to work). Many thanks, Ronan Ronan McGovern www.Trelis.com ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
