bolts
bolts copied to clipboard
lightning
Add option to sign commitments at various feerates (FEAT 32/33)
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_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.
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:
- investigate alternatives, such as signing multiple commit txs with different amounts for the anchor output: you can then use this output to fund HTLC txs from this channel (it lets the reserve come from the channel funds inside of an external wallet). Think about the dependency with the channel reserve.
How does this help with the HTLC txs? You still need to bring your own utxo - or are you assuming using the old option_anchor_outputs instead of option_anchors_zero_fee_htlc_tx? (If so, is the old feature supported by nodes? I thought it was pretty much deprecated in favour of option_anchors_zero_fee_htlc_tx)
It can be especially useful for mobile wallets that don't want to manage on-chain fee-bumping reserves.
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.
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_signed use SIGHASH_ALL, not SIGHASH_SINGLE | SIGHASH_ANYONECANPAY, and they do pay the feerate announced. If one of them has the feerate you want, you just add your local sigs and broadcast it without adding any new input. If none of your transactions have a good feerate, then you use the SIGHASH_SINGLE | SIGHASH_ANYONECANPAY tx from commitment_signed and add your own inputs. One added benefit is a smaller HTLC tx since it has a single input, which is more fee-efficient.
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.
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 :neutral_face:
I know it is definitely not a very satisfying solution :sweat_smile:, 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...
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).
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?
Don't we need to reintroduce all the dust complexity in https://github.com/lightning/bolts/pull/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 alternative_commitment_signed don't apply any trimming and keep the exact same HTLC outputs as the main commitment_signed. Some of those HTLC outputs will be uneconomical to spend on-chain, but they're already uneconomical to spend without those additional signatures, so we're not making things worse?
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.
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 alternative_commitment_signed don't apply any trimming and keep the exact same HTLC outputs as the main commitment_signed. Some of those HTLC outputs will be uneconomical to spend on-chain, but they're already uneconomical to spend without those additional signatures, so we're not making things worse?
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.
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.
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 MAX_ACCEPTED_HTLC * max_feerate_presigned_commitment * average_htlc_transaction of "trusted" fee surface to your counterparty. So assuming 50 (LDK default), 100 sat/vbytes, 200 bytes, that is 0.01 BTC of operational risk by connected spoke for a LSP.
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.
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.
I don't think that really works though, unless you have a very long cltv_expiry_delta or a low enough max-accepted-htlcs...
If you use the default max-accepted-htlcs of 483, an attacker would simply make you send 483 outgoing HTLCs with expiries N+1, N+2, ..., N + 483 so you can't easily use a single utxo to claim them all on time.
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.
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
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.