Hi Jimpo,
You're correct that the introduction of symmetric state now re-introduces the
dependency between the CSV value of the commitment, and the HTLC timeouts. It's
worth nothing that this issue existed in an earlier version of the BOLT spec,
this was pointed out by Mats in the past: [1][2]. The dependency meant that if
we wanted to allow very long CSV time outs (like 1 month +), then this would
have the adverse effect of increasing the total CLTV timeout along the entire
route. As a result, we moved to the 2-stage HTLC scheme which is now
implemented and deployed as a part of BOLT 1.0. It may be the case that in the
mid to near future, most implementations aren't concerned about long time locks
due to the existence of robust and reliable private outsourcers.
As a side effect of the way the symmetric state changes the strategy around
breach attempts, we may see more breach attempts (and therefore update
transactions) on the chain since attempting to cheat w/ vanilla symmetric state
is now "costless" (worst case we just use the latest state, best case I can
commit the state better for me. This is in stark contrast to
punishment/slashing based approaches where a failed breach attempt results in
the cheating party losing all their funds.
However, with a commitment protocol that uses symmetric state. The 2-stage HTLC
scheme doesn't actually apply. Observe that with Lighting's current asymmetric
state commitment protocol, the "clock" starts ticking as soon as the commitment
hits the chain, and we follow the "if an output pays to me, it must be delayed
as I may be attempting a breach". With symmetric state this no longer applies,
the clock instead starts "officially" ticking after the latest update
transaction has hit the chain, and there are no further challenges. As a result
of this, the commitment transaction itself doesn't need to have any CSV delays
within the Script branches of the outputs it creates. Instead, each of those
outputs can be immediately be spent as the challenge period has already elapsed,
and from the PoV of the chain, this is now the "correct" commitment. Due to
this, the HTLC outputs would now be symmetric themselves, and look very much
like an HTLC output that one would use in a vanilla on-chain cross-chain atomic
swap.
OK, I see what you are saying. You are effectively suggesting pipelining the broadcasts of the update transactions. I think this introduces a problem that a node in the circuit that withholds the preimage for too long can force all upstream channels to be closed, at only the expense of their one upstream channel being closed. I believe such an attack could significantly disrupt the network.
Let me elaborate on the way I'm thinking about this:
So say I'm a routing node with an upstream HTLC with CLTV = X. I need to ensure that if I learn the preimage, that I have time to broadcast and confirm an HTLC-success transaction before height X. We'll call this number of blocks D_success. So if I know the preimage, let's say X - D_success is the latest height that I can safely broadcast the HTLC-success transaction, assuming the settlement transaction is already final (ie. the update transaction is confirmed and the CSV delay has passed). So now I also need to know when to close the channel with the update transaction. I'll assume it will take at most D_update blocks from the time I broadcast the update transaction for it to be mined. So unless the downstream HTLC is already failed, I should always close the upstream channel at height X - D_success - CSV_update - D_update.
Now we'll look at the downstream HTLC with CLTV = Y. In order to minimize the safe delta between the upstream and downstream CLTVs, I will want to broadcast and confirm an HTLC-timeout transaction as soon after height Y as possible. So assuming that the downstream settlement transaction is final at height Y and it takes at most D_timeout blocks for the HTLC timeout transaction to confirm once it is final assuming no double spends, then Y + D_timeout is very latest I might learn the payment preimage from the downstream channel on-chain. So I should be safe as long as X - D_success > Y + D_timeout. This assumes that the update transaction for the downstream channel is already mined and the CSV has passed. However, we know from above that I had to close the upstream channel at time X - D_success - CSV_update - D_update, which may very well be before Y. So if the downstream hop waits until just before Y to publish the preimage, they can force me to close my upstream channel. This applies transitively for further upstream hops, assuming a large enough CSV value.
Granted, upstream hops can watch the blockchain for preimage reveals in other closings transaction and perhaps fulfill off-chain if there is sufficient time. This would not be possible with payment decorrelation through scriptless scripts or the like.
Does that logic sound right to you?
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev