Joseph Poon [ARCHIVE] on Nostr: 📅 Original date posted:2015-07-02 📝 Original message: Hi Rusty and Stephen, On ...

📅 Original date posted:2015-07-02
📝 Original message:
Hi Rusty and Stephen,

On Tue, Jun 30, 2015 at 05:33:00PM +0930, Rusty Russell wrote:
> Joseph's solution is that E can route a conditional refund back to A
> with a larger timeout (say 3 days) via some other route: this pays
> back the amount to A if they present the preimage for the initial
> stalled payment and another preimage A only has. This serves as a
> guarantee that E will not reveal the preimage required to take the
> stalled payment.

To clarify, this is only necessary if there is a routing failure when a
signed transaction has been sent but not acknowledged or cancellation is
refused.

For example, presume the prior route A->B->C->E. If C acknowledges B's
attempt to route but does not actually route after the signature has
been sent by B to C, then A and B are unsure whether C's computer has
gone offline or is acting maliciously. In that case, it's necessary for
E to send a "conditional refund" back to A. The reason A requires an
additional preimage/hash when doing the "conditional refund" is in case
the conditional refund itself fails.

However, the most likely case is the routing fails cleanly. If B is
unable to send to C because C has been offline or B otherwise refuses to
route to C, B can undo the HTLC by cancelling the HTLC entirely
(replacement with a new Commitment transaction state with A). This
cancellation can cascade back to the sender to free up the money. In the
event that the cancellation doesn't end up cascading back to the sender
(should be fairly rare), then A can get E to do the same E->D->A with
the same hash described in the previous example. Most routing failures
should end up being rollbacks.

> This raises other questions, such as who would pay E (and any other
> intermediate nodes) for locking up their money for such a time. Could
> A provide evidence that the route really had timed out? How many
> times can A claim "payment failed"? etc.

I'm assuming that the payment from A to E is split into many small
payments. If the payment is too small to be split up, then it's probably
cheap enough to not matter anyway (in most cases, waiting for expiration
is no big deal). Resolving incomplete payments should be deferred until
after the payment is sufficiently complete; E can have as a policy to
only send "conditional refunds" when she has received sufficient funds
from A (and A has paid for the time-value/fee of the refund). Since the
payment is likely source-routed, it is the responsibility for the sender
to pay for payment failure. The incentives are largely in favor of
receiver being online and accepting -- the recipient, is after all,
increasing the amount of bitcoin they own.

--
Joseph Poon