Re: [Lightning-dev] [bitcoin-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely
> 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
Re: [Lightning-dev] [bitcoin-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely
On Mon, Nov 13, 2023 at 02:18:16AM +, 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-rep
Re: [Lightning-dev] [bitcoin-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely
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. > 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. 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 > 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. > 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. > 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. > In existing anchor output transactions, this type of attack wouldn't work as > when broadcasting the transaction, Alice would be spending her anchor output, > which Bob can't double spend. However Bob can double-spend Alice's commitment transaction with his own commitment transaction and a CPFP, as long as it's a better ancestor feerate and absolute fee package, then double-spend his own CPFP. Which is exactly what my test is doing so I don't think your statement of saying this type of advanced replacement cycling attack wouldn't work isn't correct. Best, Antoine Le mer. 8 nov. 2023 à 02:06, Peter Todd a écrit : > On Wed, Nov 08, 2023 at 12:51:31AM +, Peter Todd via bitcoin-dev wrote: > > > In a post-package relay world, I think this is possible. And that > > > replacement cycling attacks are breaking future dynamic fee-bumping of > > > pre-signed transactions concerns me a lot. > > > > Well the answer here is pretty clear: v3 package relay with anchors is > broken. > > BTW a subtlety of this that may not be obvious is that in v3 package relay, > with zero value outputs, the outputs must be spent in the same package. > Thus > _unlike_ existing anchor-using transactions, there would be only one anchor > output on the commitment transaction. > > In existing anchor output transactions, this type of attack wouldn't work > as > when broadcasting the transaction, Alice would be spending her anchor > output, > which Bob can't double spend. But that doesn't work in v3, which intends to > limit UTXO growth by requiring that anchors be spent in the same package. > Thus > unlike existing anchor outputs, an anchor would be truly a OP_1 output > without > a signature, and thus belong to either Alice nor Bob uniquely. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > __
Re: [Lightning-dev] [bitcoin-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely
On Wed, Nov 08, 2023 at 12:51:31AM +, Peter Todd via bitcoin-dev wrote: > > In a post-package relay world, I think this is possible. And that > > replacement cycling attacks are breaking future dynamic fee-bumping of > > pre-signed transactions concerns me a lot. > > Well the answer here is pretty clear: v3 package relay with anchors is broken. BTW a subtlety of this that may not be obvious is that in v3 package relay, with zero value outputs, the outputs must be spent in the same package. Thus _unlike_ existing anchor-using transactions, there would be only one anchor output on the commitment transaction. In existing anchor output transactions, this type of attack wouldn't work as when broadcasting the transaction, Alice would be spending her anchor output, which Bob can't double spend. But that doesn't work in v3, which intends to limit UTXO growth by requiring that anchors be spent in the same package. Thus unlike existing anchor outputs, an anchor would be truly a OP_1 output without a signature, and thus belong to either Alice nor Bob uniquely. -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: PGP signature ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [bitcoin-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely
> The idea with package relay is that commitment transaction fees will > be zero and that fees will always be paid via CPFP on the anchor > output. Yes, even if multiple commitment transactions are pre-signed with a RBF range of more than zero, an attacker can always select the lowest fees pre-signed states and adjust in consequence the CPFP paid, and then evict out the bumping CPFP. Le jeu. 2 nov. 2023 à 17:07, Matt Morehouse a écrit : > On Thu, Nov 2, 2023 at 6:27 AM Peter Todd via bitcoin-dev > wrote: > > > > On Thu, Nov 02, 2023 at 05:24:36AM +, Antoine Riard wrote: > > > Hi Peter, > > > > > > > So, why can't we make the HTLC-preimage path expire? Traditionally, > we've > > > tried > > > > to ensure that transactions - once valid - remain valid forever. We > do > > > this > > > > because we don't want transactions to become impossible to mine in > the > > > event of > > > > a large reorganization. > > > > > > I don't know if reverse time-lock where a lightning spending path > becomes > > > invalid after a block height or epoch point solves the more advanced > > > replacement cycling attacks, where a malicious commitment transaction > > > itself replaces out a honest commitment transaction, and the > > > child-pay-for-parent of this malicious transaction is itself replaced > out > > > by the attacker, leading to the automatic trimming of the malicious > > > commitment transaction. > > > > To be clear, are you talking about anchor channels or non-anchor > channels? > > Because in anchor channels, all outputs other than the anchor outputs > provided > > for fee bumping can't be spent until the commitment transaction is > mined, which > > means RBF/CPFP isn't relevant. > > IIUC, Antoine is talking about a cycling attack of the commitment > transaction itself, not the HTLC transactions. It seems possible for > future (ephemeral) anchor channels in a world with package relay. > > The idea with package relay is that commitment transaction fees will > be zero and that fees will always be paid via CPFP on the anchor > output. > > Consider this scenario: Mallory1 -> Alice -> Mallory2. > Mallory2 claims an HTLC from Alice off chain via the preimage. Alice > attempts to claim the corresponding HTLC from Mallory1, but Mallory1 > refuses to cooperate. So Alice publishes her commitment transaction > along with a CPFP on the anchor output. Mallory1 publishes her > competing commitment transaction with a higher CPFP fee on the anchor > output, thereby replacing Alice's package in the mempool. Mallory1 > then replacement-cycles the anchor output child transaction, causing > her commitment transaction to lose its CPFP and the package feerate to > go to zero, which is below the minimum relay fee. Thus, Mallory1's > commitment transaction is also evicted from the mempool. Mallory1 > repeats this process every time Alice broadcasts her commitment, until > the HTLC timeout expires. At that point the preimage path becomes > unspendable, and Mallory1 can claim the HTLC via timeout at her > leisure. > > > > > > > -- > > https://petertodd.org 'peter'[:-1]@petertodd.org > > ___ > > bitcoin-dev mailing list > > bitcoin-...@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [bitcoin-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely
On Thu, Nov 2, 2023 at 6:27 AM Peter Todd via bitcoin-dev wrote: > > On Thu, Nov 02, 2023 at 05:24:36AM +, Antoine Riard wrote: > > Hi Peter, > > > > > So, why can't we make the HTLC-preimage path expire? Traditionally, we've > > tried > > > to ensure that transactions - once valid - remain valid forever. We do > > this > > > because we don't want transactions to become impossible to mine in the > > event of > > > a large reorganization. > > > > I don't know if reverse time-lock where a lightning spending path becomes > > invalid after a block height or epoch point solves the more advanced > > replacement cycling attacks, where a malicious commitment transaction > > itself replaces out a honest commitment transaction, and the > > child-pay-for-parent of this malicious transaction is itself replaced out > > by the attacker, leading to the automatic trimming of the malicious > > commitment transaction. > > To be clear, are you talking about anchor channels or non-anchor channels? > Because in anchor channels, all outputs other than the anchor outputs provided > for fee bumping can't be spent until the commitment transaction is mined, > which > means RBF/CPFP isn't relevant. IIUC, Antoine is talking about a cycling attack of the commitment transaction itself, not the HTLC transactions. It seems possible for future (ephemeral) anchor channels in a world with package relay. The idea with package relay is that commitment transaction fees will be zero and that fees will always be paid via CPFP on the anchor output. Consider this scenario: Mallory1 -> Alice -> Mallory2. Mallory2 claims an HTLC from Alice off chain via the preimage. Alice attempts to claim the corresponding HTLC from Mallory1, but Mallory1 refuses to cooperate. So Alice publishes her commitment transaction along with a CPFP on the anchor output. Mallory1 publishes her competing commitment transaction with a higher CPFP fee on the anchor output, thereby replacing Alice's package in the mempool. Mallory1 then replacement-cycles the anchor output child transaction, causing her commitment transaction to lose its CPFP and the package feerate to go to zero, which is below the minimum relay fee. Thus, Mallory1's commitment transaction is also evicted from the mempool. Mallory1 repeats this process every time Alice broadcasts her commitment, until the HTLC timeout expires. At that point the preimage path becomes unspendable, and Mallory1 can claim the HTLC via timeout at her leisure. > > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > ___ > bitcoin-dev mailing list > bitcoin-...@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [bitcoin-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely
On Fri, Oct 20, 2023 at 10:58:32PM -1000, David A. Harding wrote: > On 2023-10-20 14:09, Peter Todd via bitcoin-dev wrote: > > The basic problem here is after the HTLC-timeout path becomes spendable, > > the > > HTLC-preimage path remains spendable. That's bad, because in this case > > we want > > spending the HTLC-preimage - if possible - to have an urgency attached > > to it to > > ensure that it happens before the previous HTLC-timeout is mined. > > > > So, why can't we make the HTLC-preimage path expire? > > If the goal is to ensure the HTLC-preimage should be mined before an > upstream HTLC-timeout becomes mineable, then I don't think a consensus > change is required. We can just make the HTLC-preimage claimable by anyone > some time after the HTLC-timeout becomes mineable. > > For example, imagine that Alice offers Bob an HTLC with a timeout at block > t+200. Bob offers Carol an HTLC with a timeout at block t+100. The > Bob-Carol HTLC script looks like this: > > If > # Does someone have the preimage? > Hash EqualVerify > If > # Carol has the preimage at any time > CheckSig > Else > # Anyone else has the preimage after t+150 > CLTV > EndIf > Else > # Bob is allowed a refund after t+100 >CheckSigVerify >CLTV > EndIf > > In English: > > - At any time, Carol can spend the output by releasing the preimage > - After t+100, Bob can spend the output > - After t+150, anyone with the preimage can spend the output This is a clever idea. But it doesn't prevent this attack. Think about it this way: where previously there was one Carol who could perform the replacement cycling attack, with the anyone-can-spend branch the situation eventually transforms into a situation where there is an unlimited set of Carols who can perform the attack and, if they are a miner, benefit from it. Either way Bob is in a position where they might not learn about the preimage in time, and thus fail to redeem the received HTLC output. From Carol's point of view the situation didn't significantly change. Either they manage to succesfully spend the offered HTLC output after the redeemed HTLC output times out. Or they fail. Whether or not that failure happens because Bob got their refund, or someone else spent the offered HTLC output via the anyone-can-spend path is not relevant to Carol. Finally, this solution is inferior to OP_Expire in another important way: the anyone-can-spend branch represents a strict deadline for Bob too. With OP_Expire, once HTLC preimage branch has expired, Bob can spend the offered HTLC output at their leisure, as they are the only party with the ability to do that (assuming of course that we're talking about a valid commitment transaction, not an illegitmate revoked once). > [2] Although miners may want to consider running code that allows them to > rewrite any malleable transactions to pay themselve With full-RBF _anyone_ can run that code on behalf of miners, modulo edge cases where the replacement isn't possible due to the RBF anti-DoS rules. Indeed, people are apparently already doing this to screw over signature-less ordinal transactions. -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: PGP signature ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [bitcoin-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely
> By redefining a bit of the nVersion field, eg the most significant bit, we > can apply coinbase-like txout handling to arbitrary transactions. We already have that in OP_CHECKSEQUENCEVERIFY. You can have a system with no coinbase transactions at all, and use only OP_CHECKSEQUENCEVERIFY on the first transaction, and set sequence numbers to put a relative locktime of 100 blocks. Also, if you think some soft-fork is needed anyway, then I recommend building it around already existing OP_CHECKSEQUENCEVERIFY, than reinvent the wheel. > Redefining an existing OP_Nop opcode, OP_Expire would terminate script > evaluation with an error This one is also already there. We have reserved opcodes, like OP_RESERVED. You can do something like " OP_IF OP_RESERVED OP_ENDIF", and then, if "" is triggered in the Script, the whole transaction is marked as invalid. But if that condition is false, then everything is fine, and you can continue executing next opcodes. Again, the situation is the same as in previous case: build it around OP_RESERVED, that is just "OP_EXPIRE" with a different name than you want, and then the only thing you need, is soft-forking a proper condition on the stack. On 2023-10-21 02:09:55 user Peter Todd via bitcoin-dev wrote: On Mon, Oct 16, 2023 at 05:57:36PM +0100, Antoine Riard via bitcoin-dev wrote: > Here enter a replacement cycling attack. A malicious channel counterparty > can broadcast its HTLC-preimage transaction with a higher absolute fee and > higher feerate than the honest HTLC-timeout of the victim lightning node > and triggers a replacement. Both for legacy and anchor output channels, a > HTLC-preimage on a counterparty commitment transaction is malleable, i.e > additional inputs or outputs can be added. The HTLC-preimage spends an > unconfirmed and unrelated to the channel parent transaction M and conflicts > its child. The basic problem here is after the HTLC-timeout path becomes spendable, the HTLC-preimage path remains spendable. That's bad, because in this case we want spending the HTLC-preimage - if possible - to have an urgency attached to it to ensure that it happens before the previous HTLC-timeout is mined. So, why can't we make the HTLC-preimage path expire? Traditionally, we've tried to ensure that transactions - once valid - remain valid forever. We do this because we don't want transactions to become impossible to mine in the event of a large reorganization. A notable example of this design philosophy is seen in Bitcoin's rules around coinbase outputs: they only become spendable after 100 more blocks have been found; a 100 block reorg is quite unlikely. Enter the OP_Expire and the Coinbase Bit soft-fork upgrade. # Coinbase Bit By redefining a bit of the nVersion field, eg the most significant bit, we can apply coinbase-like txout handling to arbitrary transactions. Such a transaction's outputs would be treated similarly to a coinbase transaction, and would be spendable only after 100 more blocks had been mined. Due to this requirement, these transactions will pose no greater risk to reorg safety than the existing hazard of coinbase transactions themselves becoming invalid. Note how such a transaction is non-standard right now, ensuring compatibility with existing nodes in a soft-fork upgrade. # OP_Expire Redefining an existing OP_Nop opcode, OP_Expire would terminate script evaluation with an error if: 1) the Coinbase Bit was not set; or 2) the stack is empty; or 3) the top item on the stack was >= the block height of the containing block This is conceptually an AntiCheckLockTimeVerify: where CLTV _allows_ a txout to become spendable in a particular way in the future, Expire _prevents_ a txout from being spent in a particular way. Since OP_Expire requires the Coinbase Bit to be set, the reorg security of OP_Expire-using transactions is no worse than transactions spending miner coinbases. # How HTLC's Would Use OP_Expire Whenever revealing the preimage on-chain is necessary to the secure functioning of the HTLC-using protocol, we simply add an appropriate OP_Expire to the pre-image branch of the script along the lines of: If Expire Drop Hash EqualVerify CheckSig ElseIf # HTLC Expiration conditions ... EndIf Now the party receiving the pre-image has a deadline. Either they get a transaction spending the preimage mined, notifying the other party via the blockchain itself, or they fail to get the preimage mined in time, reverting control to the other party who can spend the HTLC output at their leisure, without strict time constraints. Since the HTLC-expired branch does *not* execute OP_Expire, the transaction spending the HTLC-expired branch does *not* need to set the Coinbase Bit. Thus it can be spent in a perfectly normal transaction, without restrictions. # Delta Encoding Expiration Rather than having a specific Coinbase Bit, it may also be feasible to encode the expiration height as a delta against a bloc
Re: [Lightning-dev] [bitcoin-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely
On 2023-10-20 14:09, Peter Todd via bitcoin-dev wrote: The basic problem here is after the HTLC-timeout path becomes spendable, the HTLC-preimage path remains spendable. That's bad, because in this case we want spending the HTLC-preimage - if possible - to have an urgency attached to it to ensure that it happens before the previous HTLC-timeout is mined. So, why can't we make the HTLC-preimage path expire? If the goal is to ensure the HTLC-preimage should be mined before an upstream HTLC-timeout becomes mineable, then I don't think a consensus change is required. We can just make the HTLC-preimage claimable by anyone some time after the HTLC-timeout becomes mineable. For example, imagine that Alice offers Bob an HTLC with a timeout at block t+200. Bob offers Carol an HTLC with a timeout at block t+100. The Bob-Carol HTLC script looks like this: If # Does someone have the preimage? Hash EqualVerify If # Carol has the preimage at any time CheckSig Else # Anyone else has the preimage after t+150 CLTV EndIf Else # Bob is allowed a refund after t+100 CheckSigVerify CLTV EndIf In English: - At any time, Carol can spend the output by releasing the preimage - After t+100, Bob can spend the output - After t+150, anyone with the preimage can spend the output Let's consider this in the wider context of the forwarded payment Alice->Bob->Carol: - If Carol attempts to spend the output by releasing the preimage but pays too low of a feerate to get it confirmed by block t+100, Bob can spend the output in block t+101. He then has 99 blocks to settle (revoke) the Alice-Bob HTLC offchain. - If Carol releases the preimage to the network in general but prevents Bob from using it (e.g. using a replacement cycling attack), anyone who saw the preimage can take Carol's output at t+150 and, by doing so, will put the preimage in the block chain where Bob will learn about it. He'll then have 49 blocks to settle (revoke) the Alice-Bob HTLC offchain. - (All the normal cases when the HTLC is settled offchain, or where onchain operations occur in a timely manner) I think that adequately satisfies the concern about the effect on LN from replacement cycling. Looking at potential complications: - If all miners acted together[1], they are incentivized to not mine Carol's preimage transaction before t+150 because its fees are less than the HTLC value they can receive at t+150. I think this level of miner centralization would result in a general failure for LN given that miners could be any LN user's counterparty (or bribed by a user's counterparty). E.g., stuff like this: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017997.html - To allow anyone with the preimage to spend the output after t+150, they need to know the script. For taproot, that means the t+150 tapleaf script needs to follow a standard (e.g. a BOLT) and that any internal merkle nodes needed to connect it to the taproot commitment need to be shown in Carol's preimage transaction (or inferable from it or other data). - Classic RBF pinning of the t+150 transaction to prevent it from confirming by block t+200 might be an issue. E.g., including it in a 400,000 weight low-feerate transaction. - Full RBF might be required to ensure the t+150 transaction isn't sent with a low feerate and no opt-in signal. Deployment considerations: - No changes are required to full nodes (no consensus change required) - No changes are required to mining Bitcoin nodes[2] - At least one well-connected Bitcoin relay node will need to be updated to store preimages and related data, and to send the preimage claim transactions. Data only needs to be kept for a rolling window of a few thousand blocks for the LN case, bounding storage requirements. No changes are required to other relaying Bitcoin nodes - LN nodes will need to update to new HTLC scripts, but this should be doable without closing/re-opening channels. Both anchor and non-anchor channels can continue to be used Compared to OP_EXPIRE: - OP_EXPIRE requires consensus and policy changes; this does not - OP_EXPIRE does not depend on special software; this depends on at least one person running special software Although this proposal is an alternative to Peter's proposal and is primarily inspired by his idea, it's also a variation on a previous suggestion of mine: https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002664.html -Dave [1] Perhaps under block censorship threat from a mining majority or a sub-majority performing selfish mining. [2] Although miners may want to consider running code that allows them to rewrite any malleable transactions to pay themselve ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
