Why Nostr? What is Njump?
2023-06-09 13:04:51
in reply to

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
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l