Re: [Lightning-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely
On Mon, Nov 06, 2023 at 06:45:21PM +, Antoine Riard wrote: > > I think you are misunderstanding a key point to my OP_Expire proposal: > because > > the ability to spend the preimage branch of the HTLC goes away when the > refund > > branch becomes available, replacing cycling or any similar technique > becomes > > entirely irrelevant. > > > The situation where Carol prevents Bob from learning about the preimage > in time > > simply can't happen: either Carol collects the HTLC with knowledge of the > > preimage, by spending it in a transaction mined prior to the expiration > time > > and ensuring that Bob learns the preimage from the blockchain itself. Or > the > > HTLC expires and Bob can use the refund branch at his leisure. > > I think I understand the semantic of the OP_Expire proposal overall > correctly, however I'm not sure it prevents replacing cycling or any > similar adversarial technique, as the forwarding node might be the attacker > in some scenario. > Assuming this advanced scenario is correct, I'm not sure the OP_Expire > proposal is substantially fixing all the adversarial replacement cycling > situations. What you are describing here is a completely different problem than what OP_Expire aims to solve. 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. The problem you are describing, as Zmm points out below, doesn't actually exist in Bitcoin right now. But it could exist if we adopted v3 package relay, which as I've pointed out elsewhere, is inferior to using RBF. On Tue, Nov 07, 2023 at 03:44:21PM +, Antoine Riard wrote: > Hi Zeeman, > > > Neither can Bob replace-recycle out the commitment transaction itself, > because the commitment transaction is a single-input transaction, whose > sole input requires a signature from > > Bob and a signature from Carol --- obviously Carol will not cooperate on > an attack on herself. > > The replacement cycling happens on the commitment transaction spend itself, > not the second stage, which is effectively locked until block 100. > > If the commitment transaction is pre-signed with 0 sat / vb and all the > feerate / absolute fee is provided by a CPFP on one of the anchor outputs, > Bob can replace the CPFP itself. After replacement of its child, the > commitment transaction has a package feerate of 0 sat / vb and it will be > trimmed out of the mempool. > > This is actually the scenario tested here on the nversion = 3 new mempool > policy branch (non-deployed yet): > https://github.com/ariard/bitcoin/commits/2023-10-test-mempool-2 > > As of today commitment transactions might not propagate if dynamic mempool > min fee is above pre-signed commitment transaction, which is itself unsafe. > I think this behavior can currently be opportunistically exploited by > attackers. Yes, obviously it can be. For starters, you can easily end up in a situation where the commitment transaction simply can't get mined, an obvious problem. > 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. 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. 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. 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. As SIGHASH_NOINPUT is desirable for LN-Symmetry, a softfork containing both it and OP_Expire could make sense. -- 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] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely
I'm glad the original name (or similar) has been conserved for op_expiry, unlike op_maturity, which ended up being called op_checkLockTimeVerify. Somehow I had hope that this could be eventually accepted, even though I understood that this changed the "once valid, always valid unless replaced" assumption. Not relevant to bitcoin except perhaps for some colored coin implementations, but for multi-asset chains like those created with elements project (or some chain following freimarkets' design), this also allows other interesting use cases, like making p2p trades easier. For example, signing incomplete transactions as "offers" that others can complete and publish if they like the offer. Anyway, it seems the use cases springing more interest is a lightning one. On Tue, Nov 7, 2023 at 1:13 PM ZmnSCPxj via Lightning-dev < lightning-dev@lists.linuxfoundation.org> wrote: > Good morning Antoine, > > > > Once the HTLC is committed on the Bob-Caroll link, Caroll releases the > preimage off-chain to Bob with an `update_fulfill_htlc` message, though Bob > does _not_ send back his signature for the updated channel state. > > > > Some blocks before 100, Caroll goes on-chain to claim the inbound HTLC > output with the preimage. Her commitment transaction propagation in network > mempools is systematically "replaced cycled out" by Bob. > > I think this is impossible? > > In this scenario, there is an HTLC offered by Bob to Carol. > > Prior to block 100, only Carol can actually create an HTLC-success > transaction. > Bob cannot propagate an HTLC-timeout transaction because the HTLC timelock > says "wait till block 100". > > Neither can Bob replace-recycle out the commitment transaction itself, > because the commitment transaction is a single-input transaction, whose > sole input requires a signature from Bob and a signature from Carol --- > obviously Carol will not cooperate on an attack on herself. > > So as long as Carol is able to get the HTLC-success transaction confirmed > before block 100, Bob cannot attack. > Of course, once block 100 is reached, `OP_EXPIRE` will then mean that > Carol cannot claim the fund anymore. > > Regards, > ZmnSCPxj > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely
Hi Zeeman, > Neither can Bob replace-recycle out the commitment transaction itself, because the commitment transaction is a single-input transaction, whose sole input requires a signature from > Bob and a signature from Carol --- obviously Carol will not cooperate on an attack on herself. The replacement cycling happens on the commitment transaction spend itself, not the second stage, which is effectively locked until block 100. If the commitment transaction is pre-signed with 0 sat / vb and all the feerate / absolute fee is provided by a CPFP on one of the anchor outputs, Bob can replace the CPFP itself. After replacement of its child, the commitment transaction has a package feerate of 0 sat / vb and it will be trimmed out of the mempool. This is actually the scenario tested here on the nversion = 3 new mempool policy branch (non-deployed yet): https://github.com/ariard/bitcoin/commits/2023-10-test-mempool-2 As of today commitment transactions might not propagate if dynamic mempool min fee is above pre-signed commitment transaction, which is itself unsafe. I think this behavior can currently be opportunistically exploited by attackers. 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. Best, Antoine Le mar. 7 nov. 2023 à 11:12, ZmnSCPxj a écrit : > Good morning Antoine, > > > > Once the HTLC is committed on the Bob-Caroll link, Caroll releases the > preimage off-chain to Bob with an `update_fulfill_htlc` message, though Bob > does _not_ send back his signature for the updated channel state. > > > > Some blocks before 100, Caroll goes on-chain to claim the inbound HTLC > output with the preimage. Her commitment transaction propagation in network > mempools is systematically "replaced cycled out" by Bob. > > I think this is impossible? > > In this scenario, there is an HTLC offered by Bob to Carol. > > Prior to block 100, only Carol can actually create an HTLC-success > transaction. > Bob cannot propagate an HTLC-timeout transaction because the HTLC timelock > says "wait till block 100". > > Neither can Bob replace-recycle out the commitment transaction itself, > because the commitment transaction is a single-input transaction, whose > sole input requires a signature from Bob and a signature from Carol --- > obviously Carol will not cooperate on an attack on herself. > > So as long as Carol is able to get the HTLC-success transaction confirmed > before block 100, Bob cannot attack. > Of course, once block 100 is reached, `OP_EXPIRE` will then mean that > Carol cannot claim the fund anymore. > > Regards, > ZmnSCPxj > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely
Good morning Antoine, > Once the HTLC is committed on the Bob-Caroll link, Caroll releases the > preimage off-chain to Bob with an `update_fulfill_htlc` message, though Bob > does _not_ send back his signature for the updated channel state. > > Some blocks before 100, Caroll goes on-chain to claim the inbound HTLC output > with the preimage. Her commitment transaction propagation in network mempools > is systematically "replaced cycled out" by Bob. I think this is impossible? In this scenario, there is an HTLC offered by Bob to Carol. Prior to block 100, only Carol can actually create an HTLC-success transaction. Bob cannot propagate an HTLC-timeout transaction because the HTLC timelock says "wait till block 100". Neither can Bob replace-recycle out the commitment transaction itself, because the commitment transaction is a single-input transaction, whose sole input requires a signature from Bob and a signature from Carol --- obviously Carol will not cooperate on an attack on herself. So as long as Carol is able to get the HTLC-success transaction confirmed before block 100, Bob cannot attack. Of course, once block 100 is reached, `OP_EXPIRE` will then mean that Carol cannot claim the fund anymore. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely
> I think you are misunderstanding a key point to my OP_Expire proposal: because > the ability to spend the preimage branch of the HTLC goes away when the refund > branch becomes available, replacing cycling or any similar technique becomes > entirely irrelevant. > The situation where Carol prevents Bob from learning about the preimage in time > simply can't happen: either Carol collects the HTLC with knowledge of the > preimage, by spending it in a transaction mined prior to the expiration time > and ensuring that Bob learns the preimage from the blockchain itself. Or the > HTLC expires and Bob can use the refund branch at his leisure. I think I understand the semantic of the OP_Expire proposal overall correctly, however I'm not sure it prevents replacing cycling or any similar adversarial technique, as the forwarding node might be the attacker in some scenario. Consider the following: you have Alice, Bob, Caroll sharing lightning channels. Alice forwards a HTLC of 1 BTC to Caroll by the intermediary of Bob. On the Bob-Caroll link, the HTLC expires at block 100. According to OP_Expire semantics, Caroll shouldn't be able to claim the htlc-preimage spends on the Bob-Caroll link, after block 100. However, this situation offers the ability to Bob the routing node to steal HTLC payment between Alice and Caroll. Once the HTLC is committed on the Bob-Caroll link, Caroll releases the preimage off-chain to Bob with an `update_fulfill_htlc` message, though Bob does _not_ send back his signature for the updated channel state. Some blocks before 100, Caroll goes on-chain to claim the inbound HTLC output with the preimage. Her commitment transaction propagation in network mempools is systematically "replaced cycled out" by Bob. At block 100, Caroll cannot claim the payment sent to her by Alice. Bob claims the htlc-refund path on the Bob-Caroll link and claims the htlc-preimage path on the Alice-Bob link, as such making a gain of 1 BTC. If Caroll is a lightning mobile client, it is easy for Bob to claim publicly that the lack of success in signature exchange to update channels state is a liveliness mistake of her own. Assuming this advanced scenario is correct, I'm not sure the OP_Expire proposal is substantially fixing all the adversarial replacement cycling situations. Best, Antoine Le sam. 4 nov. 2023 à 07:26, Peter Todd a écrit : > On Fri, Nov 03, 2023 at 05:25:24AM +, Antoine Riard wrote: > > > 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. > > > > I think the distinction is irrelevant here as pre-anchor channel if I > have > > one spendable HTLC output spend and I gain knowledge of my counterparty > > commitment transaction from networks mempools, the spend is malleable and > > can be used as a CPFP. If you assume anchor channels, you have 2 anchor > > outputs as long both parties have balance outputs or pending HTLCs. > > > > Though pre-anchor, legacy channels the counterparty commitment > transaction > > will have to be attached with a fee under min mempool fee for the > > replacement cycling to happen, and let network congestion happen. > > I think you are misunderstanding a key point to my OP_Expire proposal: > because > the ability to spend the preimage branch of the HTLC goes away when the > refund > branch becomes available, replacing cycling or any similar technique > becomes > entirely irrelevant. > > The situation where Carol prevents Bob from learning about the preimage in > time > simply can't happen: either Carol collects the HTLC with knowledge of the > preimage, by spending it in a transaction mined prior to the expiration > time > and ensuring that Bob learns the preimage from the blockchain itself. Or > the > HTLC expires and Bob can use the refund branch at his leisure. > > > I think the more interesting case is a future world with package relay > > deployed at the p2p level and anchor output on the lightning-side. Here > the > > most advanced replacement as illustrated in the test can happen (where > > commitment has an anchor output - see L125). > > Again, with OP_Expire, whether or not package relay or anything similar > exists > is irrelevant. Replacement cycling is totally useless because there is a > defined time window in which the HTLC can be spent with the preimage, after > which only the refund branch can be used. > > Indeed, with OP_Expire Lightning nodes will no longer need to monitor > mempools > for preimages at all. If the preimage is used, it is guaranteed to end up > in > the chain, and the Lightning node is guaranteed to see it provided they > have > access to up-to-date blockchain data. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > ___ Lightning-dev
Re: [Lightning-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely
On Fri, Nov 03, 2023 at 05:25:24AM +, Antoine Riard wrote: > > 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. > > I think the distinction is irrelevant here as pre-anchor channel if I have > one spendable HTLC output spend and I gain knowledge of my counterparty > commitment transaction from networks mempools, the spend is malleable and > can be used as a CPFP. If you assume anchor channels, you have 2 anchor > outputs as long both parties have balance outputs or pending HTLCs. > > Though pre-anchor, legacy channels the counterparty commitment transaction > will have to be attached with a fee under min mempool fee for the > replacement cycling to happen, and let network congestion happen. I think you are misunderstanding a key point to my OP_Expire proposal: because the ability to spend the preimage branch of the HTLC goes away when the refund branch becomes available, replacing cycling or any similar technique becomes entirely irrelevant. The situation where Carol prevents Bob from learning about the preimage in time simply can't happen: either Carol collects the HTLC with knowledge of the preimage, by spending it in a transaction mined prior to the expiration time and ensuring that Bob learns the preimage from the blockchain itself. Or the HTLC expires and Bob can use the refund branch at his leisure. > I think the more interesting case is a future world with package relay > deployed at the p2p level and anchor output on the lightning-side. Here the > most advanced replacement as illustrated in the test can happen (where > commitment has an anchor output - see L125). Again, with OP_Expire, whether or not package relay or anything similar exists is irrelevant. Replacement cycling is totally useless because there is a defined time window in which the HTLC can be spent with the preimage, after which only the refund branch can be used. Indeed, with OP_Expire Lightning nodes will no longer need to monitor mempools for preimages at all. If the preimage is used, it is guaranteed to end up in the chain, and the Lightning node is guaranteed to see it provided they have access to up-to-date blockchain data. -- 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] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely
> 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. I think the distinction is irrelevant here as pre-anchor channel if I have one spendable HTLC output spend and I gain knowledge of my counterparty commitment transaction from networks mempools, the spend is malleable and can be used as a CPFP. If you assume anchor channels, you have 2 anchor outputs as long both parties have balance outputs or pending HTLCs. Though pre-anchor, legacy channels the counterparty commitment transaction will have to be attached with a fee under min mempool fee for the replacement cycling to happen, and let network congestion happen. I think the more interesting case is a future world with package relay deployed at the p2p level and anchor output on the lightning-side. Here the most advanced replacement as illustrated in the test can happen (where commitment has an anchor output - see L125). Best, Antoine Le jeu. 2 nov. 2023 à 06:26, Peter Todd a écrit : > 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. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely
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. -- 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] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely
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. I think this attack scenario is exposed here: https://github.com/ariard/bitcoin/commits/2023-10-test-mempool-2 If this scenario is correct, there is not only a need for a solution that expires the htlc-preimage spending path, but also channel commitment ones. I think you have a difficulty as both channel commitments can be legitimately valid under lightning protocol semantics, where both counterparties cannot trust the other one to broadcast a commitment state in a timely fashion, to subsequently claim time-sensitive HTLCs. Of course, one might come with the observation that the time-sensitive HTLCs might be safeguarded under the new reverse time-lock semantic, though I think you're just switching the security risk from one counterparty to the other one. Now, the forwarding node might receive the preimage off-chain from the payee, and then block any attempt of the payee to broadcast its commitment transaction to claim the inbound HTLC, before the reverse time-lock kicks out. I believe another line of solution could to remove any counterparty malleability in the setting of a package total fees and have fee-bumping reserves pre-committed, though intuitively this sounds to come with the downside of a high-level of total reserve for each channel. Best, Antoine Le sam. 21 oct. 2023 à 01:09, Peter Todd a écrit : > 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,
Re: [Lightning-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely
On Mon, Oct 23, 2023 at 11:10:56AM +, ZmnSCPxj wrote: > Hi all, > > This was discussed partially on the platform formerly known as twitter, but > an alternate design goes like this: > > * Add an `nExpiryTime` field in taproot annex. I would strongly suggest making it nExpiryHeight, and only offering the option of expiration at a given height. Time-based anything is sketchy, as it could give miners incentives to lie about the current time in the nTime field. If anything, the fact that nLockTime can in fact be time-based was a design mistake. > * This indicates that the transaction MUST NOT exist in a block at or above > the height specified. > * Mempool should put txes buckets based on `nExpiryTime`, and if the block > is reached, drop all the buckets with `nExpiryTime` less than that block > height. > * Add an `OP_CHECKEXPIRYTIMEVERIFY` opcode, mostly similar in behavior to > `OP_EXPIRE` proposed by Peter Todd: Note that if we redefine an OP_SuccessX opcode, we do not need _Verify behavior. We can produce a true/false stack element, making either OP_Expire or OP_CheckExpiryTime better names for the opcode. > * Check if `nExpiryTime` exists and has value equal or less than the stack > top. > > The primary difference is simply that while Peter proposes an implicit field > for the value that `OP_EXPIRE` will put in `CTransaction`, I propose an > explicit field for it in the taproot annex. To be clear, I also proposed an explicit field too. But I had a brainfart and forgot that we'd added the taproot annex. So I proposed re-using part of nVersion. > The hope is that "explicit is better than implicit" and that the design will > be better implemented as well by non-Bitcoin-core implementations, as the use > of tx buckets is now explicit in treating the `nExpiryTime` field. Also, having a nExpiryHeight may be useful in cases where a signature covering the field is sufficient. -- 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] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely
Hi all, This was discussed partially on the platform formerly known as twitter, but an alternate design goes like this: * Add an `nExpiryTime` field in taproot annex. * This indicates that the transaction MUST NOT exist in a block at or above the height specified. * Mempool should put txes buckets based on `nExpiryTime`, and if the block is reached, drop all the buckets with `nExpiryTime` less than that block height. * Add an `OP_CHECKEXPIRYTIMEVERIFY` opcode, mostly similar in behavior to `OP_EXPIRE` proposed by Peter Todd: * Check if `nExpiryTime` exists and has value equal or less than the stack top. The primary difference is simply that while Peter proposes an implicit field for the value that `OP_EXPIRE` will put in `CTransaction`, I propose an explicit field for it in the taproot annex. The hope is that "explicit is better than implicit" and that the design will be better implemented as well by non-Bitcoin-core implementations, as the use of tx buckets is now explicit in treating the `nExpiryTime` field. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
