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] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"
Hi list, As I received a lot of feedback on the full disclosure of the 16th week of October and the following posts, some accurate, I'm taking time to address a few of them. I think one of the most recurring feedback is the fact that the replacement cycling issue laid out in the initial full disclosure post could have been better explained or presented. Here you have a typical disclosure dilemma encountered by any security researcher, on one hand you wish to explain them as best you can to enlighten the public audience, on the other hand if you come up with a full exploitation rootkit, its manual and a paper with a lot of graphic informing on all the way to exploit, you might expose the public audience funds. As a reminder, at the time of the full disclosure the 16th, some lightning implementations were still adding up mitigations in their codebase and corresponding release has only been tagged last week. Moreover, I think when you're doing a full disclosure as a security researcher, it is wiser to be conservative in the flow of information disclosed, as you might have missed some observations or insights worsening the severity and practicality of exploitation. In my reasonable and modest experience, the amount and clarity of information you're revealing in matters of security disclosure is an art rhythmed by contingencies, not a science. Additionally, there is one "unusual" security risk only affecting Bitcoin second-layers, namely triggering winds of panic among lightning node operators. This group of users started to manually force-close channels and holistically congestion network mempools, opening the door to opportunistic "flood & loot" exploitation, a risk known by lightning experts for years. E.g bare option anchor commitment transactions are 900 WU (bolt3), max block size is 4_000_000 WU, if you have half of the 80k of _public_ channels, you might have a hour and half of full blocks, which might offer the opportunity of stealing payments from payee, based on historical timelocks. This last risk is based on experience from previous security coordination work and I did inform the core security list of this concern in date of the 5 october: " if we see an abnormal rate of network mempools congestion from LN node operators manually force-closing their channels with low-trusted peers, this phenomena has already happened during past Lightning security issues disclosures" as it could have provoked disruptions ecosystem-wide beyond lightning. There have been some voices speaking up on the sudden announcement from my side to step down from lightning development. While there has been complete distorsion of my statement by non-specialized journalists and I've been the first one to complain, howev er it was very deliberate on my side to ring the bell on the very poor state of lightning security and marked the score than this new replacement cycling issue is a far more concerning than other major security risks of lightning known so far. As a friendly reminder, we start to pile up a very serious stack of security risks: pinnings, channel jamming, replacement cycling, time dilation (all those ones could kill lightning if exploited at scale - period) and more minor ones such as dust HTLC exposure, fee or liquidity griefing and other denial-of-service. Hard things about hard things, every new major security risk discovered somehow constrains lightning developers to go back on the whiteboard and check that any mitigation in development for each risk is not broken or the security properties with. Most of the time, we might think in isolation to ease the mitigation of research and development work. Astute adversaries might not give us those flowers. At the end, technical reality advises that lightning security issues are better solved at the base-layer, and this is where expert time is cruelly missing to make lightning more robust on the very long-term. On a more ethical plan, there is no wish on my side to stay accountable on the coordinated handling of security issues in the lightning ecosystem, when I have the inner conviction than replacement cycling issues are practical and critical, that they cannot be solved correctly on the lightning-side, that any serious mitigation on the base-layer might take numerous years and their integration back in the lightning-side might take another couple of years. Once again, I warned the whole community of the nest of issues at the mempool-level for lightning very consistently during the past years. With humility, if those replacement cycling attacks start to be played out at scale by sophisticated attackers during the coming future, I'm not competent to improvise an effective mitigation. And even less competent to coordinate dissemination of such eventual patch of mitigations across an ecosystem of nodes, without losing inter-compatibility between implementations, wallets and releases versions (and here the lack of standardized mechanism like dynamic upgrade bolt pr
