Add option to sign commitments at various feerates (FEAT 32/33) #1036
Conversation
When using `option_anchors`, nodes must keep a pool of utxos available to set the fees of commitment and HTLC transactions at broadcast time. This is a complex task that requires sophisticated utxo management to efficiently protect against malicious peers. The `option_alternative_feerates` feature reduces that complexity, by making it possible for nodes to have versions of HTLC transactions at various feerates, which may remove the need to add external inputs in most cases and keep them for exceptional occasions, at the expense of slightly more latency, bandwidth and storage usage.
|
How does this help with the HTLC txs? You still need to bring your own utxo - or are you assuming using the old
Yes, please. :) It would be great to be able to avoid reserving utxos... |
|
If we're gonna do this I really think we have to go to broadcaster-pays. Doing this for HTLCs is also really complicated because we probably don't want to go back from the zero fee htlcs world for several reasons. Maybe instead as a step one have an option to increase the anchor value on your side of the channel (for your own commitment transactions, not your counterpartys). It's kinda shitty cause the anchor amount can always be stolen, but at least you have one block to claim it for yourself? Or we could allow the anchor amount to be just a p2pk with this option. |
No you won't need to, sorry if that was unclear, but the HTLC txs from
Can you detail what reasons? On the contrary, I want this mostly for the HTLC txs (more than for the commit tx), because that's where we potentially get a big multiplier on the number of on-chain txs we have to confirm. For those HTLC txs, it is effectively broadcaster-pays (since the feerate is paid from the HTLC input). It is slightly cumbersome for the commit tx, because you need to apply different trimming thresholds for each feerate, but it's not new complexity we didn't have before. I agree it would make a lot of sense for those alternative commit txs to take the fee from the broadcaster's main output: this part would be new complexity, where you won't be able to reach the desired feerate if your peer's main output doesn't have enough value, but it doesn't feel overwhelmingly complex (especially in light of the benefits of sparing your utxos and the increased safety that comes with it - even though you still need some utxo management logic for the case where the pre-signed feerates are still not good enough). Also, there may be added complexity on HTLC relaying/acceptance logic. If your peer adds HTLC but the feerates it signs for aren't satisfying enough for you, your safest bet is to fail those HTLCs instead of relaying them (unless you're quite confident there won't be a force-close with that specific state, which you can't fully predict). Estimating the right thresholds at which you do that will probably be a bit ugly 😐 I know it is definitely not a very satisfying solution 😅, but I don't see how else we can get that extra-safety in the short term, and I think such extra-safety is quite desirable... |
| - If `option_alternative_feerates` was negotiated: | ||
| - MUST send one `alternative_commitment_signed` for each feerate listed | ||
| in the corresponding `commitment_signed.alternative_feerates`. | ||
| - MUST use `SIGHASH_ALL` for the `htlc_signature`s. |
There was a problem hiding this comment.
How does this help with the HTLC txs? You still need to bring your own utxo
No you won't need to, sorry if that was unclear, but the HTLC txs from
alternative_commitment_signeduseSIGHASH_ALL, notSIGHASH_SINGLE | SIGHASH_ANYONECANPAY, and they do pay the feerate announced.
I see. The fee part was not clear to me from the text. I guess I could have deduced it from the using sighash_all requirement. I think it would be better to explicitly mention this, e.g.:
| - MUST use `SIGHASH_ALL` for the `htlc_signature`s. | |
| - MUST use `SIGHASH_ALL` for the `htlc_signature`s, and apply `feerate_per_kw` for each HTLC transaction even if `option_anchors_zero_fee_htlc_tx` applies to the channel. |
(to counterbalance bolt-03 being very specific about the contrary)
There was a problem hiding this comment.
Yes definitely, if there is generally a good feeling about the proposal, I'll make that PR much more detailed, since there are quite a few subtleties that are currently hard to grasp.
| A sending node: | ||
| - If `option_alternative_feerates` was negotiated: | ||
| - MUST send one `alternative_commitment_signed` for each feerate listed | ||
| in the corresponding `commitment_signed.alternative_feerates`. |
There was a problem hiding this comment.
Note that HTLC-timeout transactions are CLTV locked (with independent CLTVs between htlcs). A CLTV might be hundreds of blocks into the future. Broadcasting a commitment tx at alternative_feerate1 locks in that same feerate for all HTLCs too. (because the sighash in the htlc tx's input commits to the txid of the parent commit tx)
Unless we make it quadratic and pre-sign htlc txs at each alternative_feerate for commit txs at each alternative_feerate. That would mean creating num_htlcs * len(alternative_feerates)**2 signatures at every committed channel state update.
There was a problem hiding this comment.
This is a very good remark. I went back and forth on that, the other option I had in mind that doesn't have this issue is to only sign alternative HTLC txs and not the commit tx. We keep a single commit tx (the one signed in commitment_signed, which will likely need some CPFP using the anchor) and sign alternative HTLC txs for each pending HTLC (and all these alternatives would spend the same output of the commit tx).
That means we need to handle the case where an HTLC tx doesn't make sense to be signed at some feerates (because its value goes entirely to fees): there are different ways of doing that (either skip them entirely or provide a dummy signature like 0x00...00), it's not necessarily hard but is a bit messy.
Another option is to double the number of signatures (instead of quadratically increasing them), by providing for each alternative_commitment one HTLC signature with sighash_all at the given feerate and one with sighash_single | sighash_anyonecanpay. But I'm not a big fan...
| - If `option_anchors` and `option_alternative_feerates` were negotiated: | ||
| - MUST send `alternative_feerates` containing other feerates for which it | ||
| will send signatures. | ||
| - MUST send one `alternative_commitment_signed` for each of those feerates. |
There was a problem hiding this comment.
I find it weird that Alice decides what feerates will be available to Bob in Bob's commitment tx, and vice-versa. Ideally it would be Alice who can decide for herself that she wants feerates [3,10,30,100,300] (sat/vbyte). What if Alice sends some nice rates to Bob but Bob does not give any alternatives to Alice (alternative_feerates=[])? Is Alice supposed to force-close because of not having enough feerate options?
There was a problem hiding this comment.
I agree, that's one of the decisions I wanted to have on this PR, thanks for raising it 😉. What we do here depends on whether we do "broadcaster pays" or not and whether we re-sign commitment transactions or not.
One issue with Alice deciding what feerates Bob should sign for her commit transaction is that she ask Bob to pay a feerate so high that HTLCs all go to dust, and then she could broadcast the corresponding commitment once it's revoked and Bob won't be able to claim anything. Similarly to what we have with update_fee, Bob shouldn't sign feerates that it feels are absurdly high. But we can probably find a good middle ground that works well enough in practice.
Sorry that was unclear, I was thinking about all the dust concerns, which I think creep back in here - what do you do about your counterparty broadcasting and using your HTLC funds to spend on fee. Don't we need to reintroduce all the dust complexity in #919 that we were able to basically get rid of? |
I agree, that would be very annoying, but we don't necessarily have to, the design space is quite open here, it's a matter of what we want to do. A very simple solution is to decide that those I'm sorry if this is still quite hand-wavy, I didn't open this PR with a finalized idea of all the details, on the contrary I wanted to gather feedback to help decide what trade-offs seem best. |
Hmm, thinking more its not a full issue as before, but its still a minor concern - if the concern is your counterparty can burn your HTLC funds to dust, they can still do it by just broadcasting an unnecessarily high fee version of the HTLC tx, even if the output is still in the commitment transaction. This now only works on revoked commitment transactions, though, so the attacker may burn your balance to dust but you should still be able to get the reserve value out of them. One higher-level question, actually, however, is I'm not sure I understand why this is useful at all. Focusing on the HTLC transactions seems the wrong place to look - once the commitment transaction is on-chain you have your (at least reserve) balance lying there to use as anchor input value on HTLC transactions. This goes double post-anchor when HTLC outputs are 1 CSV. The bigger question is how to ensure you can get the commitment transaction confirmed with lower anchor usage consideration, which is a bit more of a quagmire, but maybe we could come up with something like (a) commitment tx fee up to min-fee is paid by the channel initiator, (b) at higher feerates, commitment txn alternatives are signed, with the extra fee taken from the broadcaster, as long as they have enough pre-reserve funds available for it.
Totally, I'm trying to keep questions high-level, I admit I only skimmed the actual BOLT text here :) |
|
Joining Matt's concern here, I think we're re-introducing all the risk aleas of dusty HTLCs either burnable by your counterparty as a straight damage or collectable by your counterparty if it behaves in collusion with a miner (an assumption lowered with the deployment of Stratum v2 in fact, where the block template can be selected at the endpoint). HTLC transactions can be both ways, as such even if you have the LSP always acting as a funder with the fee responsibility, you might give something like counterparty's I don't think the solution of relying on your reserve balance (from channel A) as a anchor input value on HTLC transactions (from channel B) is a viable solution either, as you cannot be certain in the worst-case scenario all your channels might go on-chain as the same time. The idea of alternative pre-signed feerates commitment transaction where the extra fee is taken from the broadcaster sounds more plausible. Though still you have to consider issue like withheld HTLC resolution from your counterparty to push you to broadcast your own version of the commitment. And if your fee-estimation is delegated to a third-party or external API, combining both for the highest fee altnerative to be broadcast. Appears that, it might be good. |
I don't think that really works though, unless you have a very long At every block, you'd need to double-spend your previous batched transaction to include one more HTLC, and that requires increasing fees as well to follow RBF rules. It would be interesting to run the numbers and see how much extra fees you'd end up paying to "save" those utxos. The alternative is to make a tree of unconfirmed transactions where you use the change output of the HTLC tx with expiry N+1 to fund the HTLC tx with expiry N+2, and repeat that for each HTLC, but that also ends up being an RBF nightmare: if the fees of the first HTLC tx are too low, RBF-ing it will be incredibly expensive because of the chain of unconfirmed descendants, so your only option is to use CPFP at the bottom of the tree, which means setting a high feerate for all the HTLC txs in the tree, whereas some of them still have some time before expiry. That also ends up greatly overpaying fees, which is a painful griefing attack, isn't it? Those scenarios are why I'm focusing on HTLC txs, because getting commitment txs included is easier in my opinion since it doesn't have the transaction multiplier effect that HTLCs have, so you're probably ok always targeting a quick confirmation window which then frees another utxo to fee-bump another channel.
I agree that this is non-trivial: the signer cannot sign for feerates that are too high, because they otherwise potentially lose too much money to miners if a revoked commit is broadcast. The signer would need to choose the feerates it uses to sign to ensure that the amount burnt to fees never exceeds the channel reserve. I'll run some numbers to see if that could be reasonable or not. |
|
Closing this PR, there doesn't seem to be general interest in that feature in the short term. We can re-open later if we feel this is necessary. |
When using
option_anchors, nodes must keep a pool of utxos available to set the fees of commitment and HTLC transactions at broadcast time. This is a complex task that requires sophisticated utxo management to efficiently protect against malicious peers (even more so when HTLC txs pay 0 fees by default).The
option_alternative_feeratesfeature reduces that complexity, by making it possible for nodes to have versions of HTLC transactions at various feerates, which may remove the need to add external inputs in most cases and keep them for exceptional occasions, at the expense of slightly more latency, bandwidth and storage usage.Disclaimer: this is a very low tech and unsatisfying mitigation for the issues discussed in #845, but it's trivial to implement and may provide good guarantees against attackers in practice. I'm merely chasing concept ACKs at that point and need to prototype it to fill potential gaps in the requirements. It can be especially useful for mobile wallets that don't want to manage on-chain fee-bumping reserves.
TODO: