{"type":"rich","version":"1.0","author_name":"npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l","author_url":"https://nostr.ae/npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2021-12-16\n📝 Original message:\nGood morning William,\n\n\n\u003e Has anyone coded up a 'Poor man's rendez-vous' demo yet? How hard would\n\u003e it be, could it be done with a clightning plugin perhaps?\n\nProbably 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.\nMaybe call such a command `signfakeinvoice`.\n\nHowever, 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\".\n\nSo to generate the invoice:\n\n* Arrange the payees in some agreed fixed order.\n* Last payee generates a normal invoice.\n* From last payee to second, each one:\n  * Passes its invoice to the previous payee.\n  * 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.\n  * The previous payee plugin stores the next-payee invoice and the details of its own invoice to db, such as by `datastore` command.\n* The first payee sends the sender the invoice.\n\nOn payment:\n\n* The sender sends the payment to the first hop.\n* From first payee to second-to-last:\n  * Triggers `htlc_accepted` hook, and plugin checks if the incoming payment has a hash that is in this scheme stored in the database.\n  * The plugin gathers `htlc_accepted` hook invocations until they sum up to the expected amount (this handles multipath between payees).\n  * 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).\n  * 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)\n    * If the outgoing payment exists and is pending, wait for it to resolve to either success or failure.\n    * If the outgoing payment exists and succeeded, resolve all the gathered `htlc_accepted` hooks.\n    * If the outgoing payment exists and failed, fail all the gathered `htlc_accepted` hooks.\n    * Otherwise, perform a `pay`, giving `maxfeepercent` and `maxdelay` based on its fee budget and delay budget.\n      When the `pay` succeeds or fails, propagate it to the gathered `htlc_accepted` hooks.\n* The last payee just receives a normal payment using the normal invoice-receive scheme.\n\nRegards,\nZmnSCPxj"}