rich1.0npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lhttps://nostr.ae/npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lnjumphttps://nostr.ae📅 Original date posted:2021-12-16 📝 Original message: 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