lightningdevkit
Batching of HTLC transactions for anchor output channels
HTLC transactions for anchor output channels can be aggregated with SIGHASH_SINGLE|SIGHASH_ANYONECANPAY. However, if I understand correctly, LDK currently performs only limited aggregation: only for HTLC success transactions, and only for preimages provided before force-closure, not afterwards.
In the ideal case, all HTLC transactions can be aggregated per block, and a change output from one block can be used for the next block. This could significantly reduce the number of UTXOs (as opposed to the amount) that need to be reserved for anchor output channels.
Happy to take a look as well!
cc @wpaulino
While we can definitely aggregate more aggressively, we may want to split up packages as HTLCs get close (e.g., 6-12 blocks left) to their deadline and the package they were in remains unconfirmed.
While we can definitely aggregate more aggressively, we may want to split up packages as HTLCs get close (e.g., 6-12 blocks left) to their deadline and the package they were in remains unconfirmed.
Would we want to split up packages due to any transaction pinning concerns or to choose a higher fee rate for those HTLCs? If the latter, there could also be a trade-off to fee bump the entire package with the higher fee rate.
For received HTLCs that haven't expired, the counterparty can't claim them so there's not much to talk about there (but indeed if they're getting close to expiry it may make sense to split them off and start giving them higher fee, though you can of course just assign higher fee to the whole package).
For sent HTLCs (or received HTLCs once they expire or revoked outputs if our counterparty broadcasts a stale state), the counterparty could be able to spend the same output, which introduces pinning questions.
However, its not clear to me that its worth trying to materially change the claiming logic for them - if a counterparty is trying to exploit you by pinning, they're going to just push the maximum possible amount as pending HTLC(s) and then try to pin them. If we assume pinning is 100% reliable at delaying an HTLC claim until it has expired then they will just always succeed and we should address pinning with mempool monitoring and human intervention (eg transaction accelerator services) instead. If, on the other hand, we assign some probability of succeeding at pinning, and we assume trials are uncorrelated (they almost certainly are not), then we should not combine claims too much to at least force the counterparty to do a handful of trials so that we get some successes.
Of course none of that means we should aggregate spends of outputs that we believe are not pin-able (unexpired received HTLCs and revoked counterparty balance, basically, see https://github.com/lightning/bolts/pull/803) with ones that we believe may be pin-able, but it seems like a reasonable policy might be to just claim everything in two buckets - pin-able and not-pin-able outputs.
