Hi all!
Finally catching up. I prefer the simplicity of the timestamp
mechanism, with a more ambitious mechanism TBA.
Deployment suggestions:
1. This should be a feature bit pair. As usual, even == 'support this or
disconnect', and odd == 'ok even if you don't understand'.
2. This
Technically you can do it with c-lightning today, if you create a
circular route manually and then use the `sendpay` JSON-RPC command to
send funds along that route it'll do just that. It's as simple as that.
We don't have built-in support yet, I don't know if we ever will, since
it is trivially i
Yeah, that is true, it would only give you the atomicity, not the
decorrelation. I don’t see how you could get all the same properties using only
one hash though. I guess the sender has no incentive to claim any of the
payments before all of them have arrived, but you get no guarantee that parti
If using two hashes to deliver the payment while still getting a proof, I'm
not sure what that provides above just sending regular lightning payments
over multiple routes with one hash. Firstly, if there is a second hash, it
would presumably be the same for all routes, making them linkable again,
w
An obvious way to make this compatible with proof-of-payment would be to
require two hashes to claim the HTLC: the presage from the invoice payment
hash (as today) + the new hash introduced here. This would give the sender
a receipt after only one of the HTLCs was claimed. Would require changes
