> No, that's not a general underlying issue. You've found two separate issues.
> Furthermore, revoked states are clearly different than HTLCs: they're > fraudulent, and thus in punishment-using protocols they are always associated > with high risks of loss if they do in fact get detected or mined. There's > probably tweaks we can do to improve this security. But the general principle > there is certainly true. I see your point in saying we have two separate issues, one the on-chain inclusion of "expired" off-chain output spend (e.g the HTLC-preimage), the other one the usage of revoked or updated or asymmetric states to jam the confirmation of a valid off-chain state. I do think the second one would bring a solution to the first one, as you will be always sure that your counterparty cannot "replay" an "expired" off-chain output at its advantage. Even for solving the first issue, I'm not sure op_expire is enough, you need to expire the worthiness of an off-chain revealed witness secret too (here the preimage). E.g using short-lived proofs, i.e after a specified period of time, the proof is no longer convincing. I still think op_exire is interesting on its own, beyond solving any security issue. E.g for Discreet Log Contract, one can build a time-bounded sequential claim of the same output fund among a set of counterparties. > For a lightning channel to be economical at all in a general routing > environment, the highest likely fee has to be small enough for it to represent > a small percentage of the total value tied up in the Lightning channel. Tying > up a small percentage of the overall capacity for future fee usage is not a > significant expense. Sure, I still think this introduces the corollary for lightning nodes that any payment under the highest likely fee now has a probabilistic security, where the lightning node should make guesses on the worst-level of mempools feerate that can happen between the timelock duration of said payment. > That attack doesn't make sense. HTLCs go to fees at a certain feerate. In a > normal environment where there is a constant supply of fee paying transactions, > the profit for the miner is not the total HTLC value, but the increase in > feerate compared to the transactions they had to give up to mine the commitment > transaction. The attack makes sense in an environment where the level of HTLC trimmed as fees on the commitment transaction renders the feerates of this transaction more interesting than the marginal known transaction in a miner block template. If there is an environment where you're always guaranteed there is a constant supply of fee paying transactions paying a better feerate than the highest-fee rate that trimmed HTLCs can be a commitment transaction, of course the attack wouldn't be plausible. In a world where you have a dynamic blockspace demand market and asymmetries of information, Lightning routing nodes will be always exposed to such attacks. > Second, it's obvious that the total trimmed HTLCs should be limited to what > would be a reasonable transaction fee. A situation where you have 80% of the > channel value going to fees due to a bunch of small HTLCs is obviously > ridiculous, and to the extent that existing implementations have this issue, > should be fixed. This is the hard thing, the existence of asymmetries of information in what is a reasonable transaction fee and what is the level of mempools fee rates at time of broadcast. One could imagine a consensus change where trimmed HTLCs not worthy at the last X blocks of feerates are automatically aggregated or trimmed (think median-time-past though for median fee rates over X blocks). > Yes, obviously. But as I said above, it just doesn't make sense for channels to > be in a situation where closing them costs a significant % of the channel value > in fees, so we're not changing the status quo much. Evaluation of the significant % of the channel value burned in fees in the worst-case at time of off-chain state commitment is the hard thing. > Do you have a concrete attack? I don't have a concrete attack with sufficient testing to say with a satisfying level of certainty that I have a concrete attack. > No, you are missing the point. RBF replacements can use SIGHASH_NOINPUT to sign > HTLC refund transactions, removing the need for a set of different HTLC refund > transactions for each different feerate of the commitment transaction. See above, I think this solution with RBF replacement is robust on the assumption you cannot use the commitment transaction to jam the HTLC-preimage until your HTLC-refund transaction is valid (under nLocktime). Though my point here was only about the LN-symmetry states, not second-stage transactions on top of them. > I'm making no comment on how to do RBF replacements with LN-Symmetry, which I > consider to be a broken idea in non-trusted situations anyway > Removing justice from Lightning is always going to be hopelessly insecure when you can't at > least somewhat trust your counterparty. If your usage of LN-Symmetry is > sufficiently secure, you probably don't have to worry about them playing fee > games with you either. I agree here that LN-symmetry would be better if you can conserve the punishment ability. See https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-July/002064.html On the lack of worries about playing fees games with you, see concern above if your counterparty is a miner, even one with low-hashrate capability. Here low-hashrate capability can be understood as "do you have a non-null chance to mine a block as long as a HTLC-output is committed on an off-chain state only known among off-chain counterparties e.g". Le mar. 14 nov. 2023 à 19:50, Peter Todd <p...@petertodd.org> a écrit : > On Mon, Nov 13, 2023 at 02:18:16AM +0000, Antoine Riard wrote: > > Your two latest mails. > > > > > The problem that OP_Expire aims to solve is the fact that Carol could > > prevent > > > Bob from learning about the preimage in time, while still getting a > > chance to > > > use the preimage herself. OP_Expire thoroughly solves that problem by > > ensuring > > > that the preimage is either broadcast in the blockchain in a timely > > fashion, or > > > becomes useless. > > > > I respectfully disagree - There is a more general underlying issue for > > outdated states in multi-party off-chain constructions, where any > "revoked" > > or "updated" consensus-valid state can be used to jam the latest > off-chain > > agreed-on, through techniques like replacement cycling or pinning. > > No, that's not a general underlying issue. You've found two separate > issues. > > Furthermore, revoked states are clearly different than HTLCs: they're > fraudulent, and thus in punishment-using protocols they are always > associated > with high risks of loss if they do in fact get detected or mined. There's > probably tweaks we can do to improve this security. But the general > principle > there is certainly true. > > > > My suggestion of pre-signing RBF replacements, without anchor outputs, > > and with > > > all outputs rendered unspendable with 1 CSV, is clearly superior: there > > are > > > zero degrees of freedom to the attacker, other than the possibility of > > > increasing the fee paid or broadcasting a revoked commitment. The > latter > > of > > > course risks the other party punishing the fraud. > > > > Assuming the max RBF replacement is pre-signed at 200 sats / vb, with > > commitment transaction of ~268 vbytes and at least one second-stage HTLC > > transaction of ~175 vbytes including witness size, a channel counterparty > > must keep at worst a fee-bumping reserve of 35 268 sats, whatever payment > > value. > > For a lightning channel to be economical at all in a general routing > environment, the highest likely fee has to be small enough for it to > represent > a small percentage of the total value tied up in the Lightning channel. > Tying > up a small percentage of the overall capacity for future fee usage is not a > significant expense. > > > As of today, any payment under $13 has to become trimmed HTLCs. > > Trimmed HTLCs are coming with their own wormhole of issues, notably > making > > them a target to be stolen by low-hashrate capabilities attackers [0]. > > > > [0] > > > https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-May/002714.html > > That attack doesn't make sense. HTLCs go to fees at a certain feerate. In a > normal environment where there is a constant supply of fee paying > transactions, > the profit for the miner is not the total HTLC value, but the increase in > feerate compared to the transactions they had to give up to mine the > commitment > transaction. > > Second, it's obvious that the total trimmed HTLCs should be limited to what > would be a reasonable transaction fee. A situation where you have 80% of > the > channel value going to fees due to a bunch of small HTLCs is obviously > ridiculous, and to the extent that existing implementations have this > issue, > should be fixed. > > For RBF fee bumping, obviously you can take the increased channel fees > from the > party choosing to broadcast the commitment transaction. > > > > This does have the practical problem that a set of refund transactions > > will > > > also need to be signed for each fee variant. But, eg, signing 10x of > each > > isn't > > > so burdensome. And in the future that problem could be avoided with > > > SIGHASH_NOINPUT, or replacing the pre-signed refund transaction > mechanism > > with > > > a covenant. > > > > I think if you wish to be safe against fees griefing games between > > counterparties, both counterparties have to maintain their own > fee-bumping > > reserves, which make channel usage less capital efficient, rather than > > being drawn from a common reserve. > > Yes, obviously. But as I said above, it just doesn't make sense for > channels to > be in a situation where closing them costs a significant % of the channel > value > in fees, so we're not changing the status quo much. > > > > Using RBF rather than CPFP with package relay also has the advantage of > > being > > > more efficient, as no blockspace needs to be consumed by the anchor > > outputs or > > > transactions spending them. Of course, there are special circumstances > > where > > > BIP125 rules can cause CPFP to be cheaper. But we can easily fix that, > eg > > by > > > reducing the replacement relay fee, or by delta-encoding transaction > > updates. > > > > It is left as an exercise to the reader how to break the RBF approach for > > LN channels as proposed. > > Do you have a concrete attack? > > > > As SIGHASH_NOINPUT is desirable for LN-Symmetry, a softfork containing > > both it > > > and OP_Expire could make sense. > > > > I think there is one obvious issue of pre-signing RBF replacements > combined > > with LN-symmetry, namely every state has to pre-commit to fee values > > attached and such states might spend each other in chain. So now you > would > > need `max-rbf-replacement` * `max-theoretical-number-of-states` of > > fee-bumping reserves unless you can pipe fee value with some covenant > > magic, I think. > > No, you are missing the point. RBF replacements can use SIGHASH_NOINPUT to > sign > HTLC refund transactions, removing the need for a set of different HTLC > refund > transactions for each different feerate of the commitment transaction. > > I'm making no comment on how to do RBF replacements with LN-Symmetry, > which I > consider to be a broken idea in non-trusted situations anyway. Removing > justice > from Lightning is always going to be hopelessly insecure when you can't at > least somewhat trust your counterparty. If your usage of LN-Symmetry is > sufficiently secure, you probably don't have to worry about them playing > fee > games with you either. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
