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
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
