ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2021-12-16 📝 Original message: Good morning William, > ...
📅 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
Published at
2023-06-09 13:04:51Event JSON
{
"id": "96c50f87ccad9aa704774e8ac6b0736342ce7e2b09938b03d6bf46558fa486b3",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686315891,
"kind": 1,
"tags": [
[
"e",
"8c6278694c01face680b94987df6ea625124b2f1ccfcb1675ab1dc9b1b77fdd4",
"",
"root"
],
[
"e",
"93bd9dd004fe00d81ebf09fcd7be95902c8236c2753017551f36a3ad4d1367bd",
"",
"reply"
],
[
"p",
"6fb2fd1f8df298fef3464d220666d5ae7184dfe89dc5cc7d3a177579986c31cb"
]
],
"content": "📅 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",
"sig": "2b8091ba60413fee7c668b966fb054a428e4ecffe25b2303a81dd21227b65c59f73c557c292fc80c87c881d853e108db7abf8cee587b38c1bec3f7eb0d387b5b"
}