{"type":"rich","version":"1.0","author_name":"npub17kxcmv2v95tlmhupv768wal5ukzwycqeewc8nq5ghyp6ys7a466qrkudlg","author_url":"https://nostr.ae/npub17kxcmv2v95tlmhupv768wal5ukzwycqeewc8nq5ghyp6ys7a466qrkudlg","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2021-12-17\n📝 Original message:\nHi ZmnSCPxj,\n\nSo, are you saying there needs to be a new command \"signfakeinvoice\" at the\nprotocol level?\n\nIf that was there, how much work/hours would it be to build the poor man's\nrendez-vous at the application level?\n\nIf the above were to be implemented, when the payer pays the invoice, it's\nthen automatically split and sent to two (or more) recipients?\n\nLastly, would it make more sense to have split payments at the protocol\nlevel?\n\nThanks, Ronan\n\nOn Thu, Dec 16, 2021 at 11:44 PM ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e wrote:\n\n\u003e Good morning William,\n\u003e\n\u003e\n\u003e \u003e Has anyone coded up a 'Poor man's rendez-vous' demo yet? How hard would\n\u003e \u003e it be, could it be done with a clightning plugin perhaps?\n\u003e\n\u003e Probably not *yet*; it needs each intermediate payee (i.e. the one that is\n\u003e not the last one) to sign an invoice for which it does not know the\n\u003e preimage.\n\u003e Maybe call such a command `signfakeinvoice`.\n\u003e\n\u003e However, if a command to do the above is implemented (it would have to\n\u003e generate and sign the invoice, but not insert it into the database at all),\n\u003e then intermediate payees can use `htlc_accepted` hook for the \"rendez-vous\".\n\u003e\n\u003e So to generate the invoice:\n\u003e\n\u003e * Arrange the payees in some agreed fixed order.\n\u003e * Last payee generates a normal invoice.\n\u003e * From last payee to second, each one:\n\u003e   * Passes its invoice to the previous payee.\n\u003e   * The previous payee then creates its own signed invoice with\n\u003e `signfakeinvoice` to itself, adding its payout plus a fee budget, as well\n\u003e as adding its own delay budget.\n\u003e   * The previous payee plugin stores the next-payee invoice and the\n\u003e details of its own invoice to db, such as by `datastore` command.\n\u003e * The first payee sends the sender the invoice.\n\u003e\n\u003e On payment:\n\u003e\n\u003e * The sender sends the payment to the first hop.\n\u003e * From first payee to second-to-last:\n\u003e   * Triggers `htlc_accepted` hook, and plugin checks if the incoming\n\u003e payment has a hash that is in this scheme stored in the database.\n\u003e   * The plugin gathers `htlc_accepted` hook invocations until they sum up\n\u003e to the expected amount (this handles multipath between payees).\n\u003e   * The plugin marks that it has gathered all `htlc_accepted` hooks for\n\u003e that hash in durable storage a.k.a. `datastore` (this handles a race\n\u003e condition where the plugin is able to respond to some `htlc_accepted`\n\u003e hooks, but the node is restarted before all of them were able to be\n\u003e recorded by C-Lightning in its own database --- this makes the plugin skip\n\u003e the \"gathering\" step above, once it has already gathered them all before).\n\u003e   * The plugin checks if there is already an outgoing payment for that\n\u003e hash (this handles the case where our node gets restarted in the meantime\n\u003e --- C-Lightning will reissue `htlc_accepted` on startup)\n\u003e     * If the outgoing payment exists and is pending, wait for it to\n\u003e resolve to either success or failure.\n\u003e     * If the outgoing payment exists and succeeded, resolve all the\n\u003e gathered `htlc_accepted` hooks.\n\u003e     * If the outgoing payment exists and failed, fail all the gathered\n\u003e `htlc_accepted` hooks.\n\u003e     * Otherwise, perform a `pay`, giving `maxfeepercent` and `maxdelay`\n\u003e based on its fee budget and delay budget.\n\u003e       When the `pay` succeeds or fails, propagate it to the gathered\n\u003e `htlc_accepted` hooks.\n\u003e * The last payee just receives a normal payment using the normal\n\u003e invoice-receive scheme.\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211217/f105a9e5/attachment.html\u003e"}