{"type":"rich","version":"1.0","author_name":"npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0s","author_url":"https://nostr.ae/npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0s","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2020-04-22\n📝 Original message:\nHi Antoine and list,\n\nThanks for raising this. There's one step I'd like to understand further:\n\n* Mallory can broadcast its Pinning Preimage Tx on offered HTLC #2 output\n\u003e on Alice's transaction,\n\u003e feerate is maliciously chosen to get in network mempools but never to\n\u003e confirm. Absolute fee must\n\u003e be higher than HTLC-timeout #2, a fact known to Mallory. There is no p2p\n\u003e race.\n\u003e\n\nCan you detail how the \"absolute fee\" is computed here?\nDoesn't that mean that if this had a higher fee than the htlc-timeout, and\nthe htlc-timeout fee was\nchosen to confirm quickly (that's why we have an annoying `update_fee`),\nthe htlc-success will confirm\nquickly (which makes the problem disappear)?\nBecause once the commit tx is confirmed, the \"package\" consists of only the\nhtlc-success, doesn't it?\n\nI think the devil will be in the details here, so it's worth expanding on\nthe fee calculation imho.\n\nThanks!\nBastien\n\nLe mer. 22 avr. 2020 à 10:01, Antoine Riard \u003cantoine.riard at gmail.com\u003e a\nécrit :\n\n\u003e Personally, I would have wait a bit before to go public on this, like\n\u003e letting some implementations\n\u003e increasing their CLTV deltas, but anyway, it's here now.\n\u003e\n\u003e Mempool-pinning attacks were already discussed on this list [0], but what\n\u003e we found is you\n\u003e can _reverse_ the scenario, where it's not the malicious party delaying\n\u003e confirmation of honest\n\u003e party transactions but malicious deliberately stucking its own\n\u003e transactions in the mempool to avoid\n\u003e confirmation of timeout. And therefore gaming inter-link timelock to\n\u003e provoke an unbalanced\n\u003e settlement for the victim (\"aka you pay forward, but don't get pay\n\u003e backward\").\n\u003e\n\u003e How much attacks are practical is based on how you can leverage mempool\n\u003e rules to pin your own\n\u003e transaction. What you're looking for is a  _mempool-obstruction_ trick,\n\u003e i.e a way to get honest party\n\u003e transaction being bounce off due to your transaction being already there.\n\u003e\n\u003e Beyond disabling RBF on your transaction (with current protocol, not\n\u003e anchor proposal), there is\n\u003e two likely candidates:\n\u003e * BIP 125 rule 3: \"The replacement transaction pays an absolute fee of at\n\u003e least the sum paid by the original transactions.\"\n\u003e * BIP 125 rule 5: \"The number of original transactions to be replaced and\n\u003e their descendant transactions which will be evicted from the mempool must\n\u003e not exceed a total of 100 transactions.\"\n\u003e\n\u003e Let's go through whole scenario:\n\u003e * Mallory and Eve are colluding\n\u003e * Eve and Mallory are opening channels with Alice, Mallory do a bit of\n\u003e rebalancing\n\u003e to get full incoming capacity, like receiving funds on an onchain address\n\u003e through another Alice\n\u003e link\n\u003e * Eve send a HTLC #1 to Mallory through Alice expirying at block 100\n\u003e * Eve send a second HTLC #2 to Mallory through Alice, expirying at block\n\u003e 110 on outgoing link\n\u003e (A\u003c-\u003eM), 120 on incoming link (E\u003c-\u003eA)\n\u003e * Before block 100, without cancellation from Mallory, Alice will\n\u003e force-close channel and broadcast\n\u003e her local commitment and HTLC-timeout to get back HTLC #1\n\u003e * Alice can't broadcast HTLC-timeout for HTLC #2 as it's only expires at\n\u003e 110\n\u003e * Mallory can broadcast its Pinning Preimage Tx on offered HTLC #2 output\n\u003e on Alice's transaction,\n\u003e feerate is maliciously chosen to get in network mempools but never to\n\u003e confirm. Absolute fee must\n\u003e be higher than HTLC-timeout #2, a fact known to Mallory. There is no p2p\n\u003e race.\n\u003e * As Alice doesn't watch the mempool, she is never going to learn the\n\u003e preimage to redeeem incoming\n\u003e HTLC #2\n\u003e * At block 110, Alice is going to broadcast HTLC-timeout #2, feerate may\n\u003e be higher but as absolute\n\u003e fee is lower, it's going to be rejected from network mempools as\n\u003e replacement for Pinning Preimage\n\u003e Tx (BIP 125 rule 3)\n\u003e * At block 120, Eve closes channel and HTLC-timeout HTLC #2\n\u003e * Mallory can RBF its Pinning Preimage Tx by a high-feerate one and get it\n\u003e confirmed\n\u003e\n\u003e New anchor_output proposal, by disabling RBF, forces attacker to bid on\n\u003e the absolute fee. It may\n\u003e be now a risk to loose the fee if Pinning Tx is confirming. You may extend\n\u003e your \"pinning\n\u003e lease\" by ejecting your malicious tx, like conflicting or trimming out of\n\u003e the mempool one of its\n\u003e parents. And then reannounce your preimage tx with a\n\u003e lower-feerate-but-still-high-fee before a\n\u003e new block and a honest HTLC-timeout rebroadcast.\n\u003e\n\u003e AFAICT, even with anchor_output deployed, even assuming empty mempools,\n\u003e success rate and economic\n\u003e rationality of attacks is finding such cheap, reliable \"pinning lease\n\u003e extension\" trick.\n\u003e\n\u003e I think any mempool watching mitigation is at best a cat-and-mouse hack.\n\u003e Contrary to node\n\u003e advancing towards a global blockchain view thanks to PoW, network mempools\n\u003e don't have a convergence\n\u003e guarantee. This means,  in a distributed system like bitcoin, node don't\n\u003e see events in the same\n\u003e order, Alice may observe tx X, tx Y, tx Z and Bob may observe tx Z, tx X,\n\u003e tx Y. And order of events\n\u003e affects if a future event is going to be rejected or not, like if tx Z\n\u003e disable-RBF and tx X try to\n\u003e replace Z, Alice accepts X and Bob rejects it. And this divergence may\n\u003e perserve until a new block.\n\u003e\n\u003e Practically, it means an attacker can provoke a local conflict to bounce\n\u003e off HTLC preimage tx out\n\u003e of your mempool while broadcasting preimage tx without conflict to the\n\u003e rest of the network by\n\u003e tweaking tx-relay protocol and so easily manipulating order of events for\n\u003e every node. A local\n\u003e conflict is easy to provoke, just make tx A double-spent by both\n\u003e HTLC-preimage-tx and non-RBF-tx-B.\n\u003e Announce txA+txB to mempool victim and txA+HTLC-preimage-tx to rest of\n\u003e network. When rest of\n\u003e network announce HTLC-preimage-tx, it's going to rejected by your mempool.\n\u003e\n\u003e Provoking local conflict assumes of course _interlayer_ mapping by an\n\u003e attacker, i.e mapping your LN\n\u003e node to your full-node(s). Last time, we check, there was 982 match by IP\n\u003e for 4,500 LN/52,000\n\u003e full-node. Mapping heuristics is an ongoing research subject and sadly\n\u003e seems affordable.\n\u003e\n\u003e Yes a) you can enable full-RBF on your local node but blinding conflicting\n\u003e may still be with higher\n\u003e feerate as everything is attacker malleable b) you may want to catch tx\n\u003e and extract preimage\n\u003e on the p2p wire, but processing raw transaction would be such a DoS\n\u003e vector...\n\u003e\n\u003e Overall, I think we all agree on the long term direction to get a\n\u003e Contracting-Protocols-Enhanced\n\u003e mempool with a multiparty-safe-API, bundled with package relay deployment.\n\u003e Even if there is current\n\u003e move toward this direction, this may take longer than expected as with any\n\u003e critical-safety\n\u003e component in Core.\n\u003e\n\u003e A temporary fix could be to resuscitate old work to ensure peering through\n\u003e a full-RBF propagation path,\n\u003e but p2p implications are hard to gauge, like wouldn't guarantee p2p\n\u003e censorship resistance of this...\n\u003e\n\u003e It's quite a tangled issue, with a good deal of both bitcoin and lightning\n\u003e knowledge so feel free\n\u003e to verify and double-check more than usual\n\u003e\n\u003e Cheers\n\u003e\n\u003e [0]\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/002240.html\n\u003e\n\u003e Le mer. 22 avr. 2020 à 02:08, ZmnSCPxj via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e a écrit :\n\u003e\n\u003e\u003e Good morning Laolu, Matt, and list,\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e \u003e \u003e  * With `SIGHASH_NOINPUT` we can make the C-side signature\n\u003e\u003e \u003e \u003e  `SIGHASH_NOINPUT|SIGHASH_SINGLE` and allow B to re-sign the B-side\n\u003e\u003e \u003e \u003e  signature for a higher-fee version of HTLC-Timeout (assuming my\n\u003e\u003e cached\n\u003e\u003e \u003e \u003e  understanding of `SIGHASH_NOINPUT` still holds).\n\u003e\u003e \u003e\n\u003e\u003e \u003e no_input isn't needed. With simply single+anyone can pay, then B can\n\u003e\u003e attach\n\u003e\u003e \u003e a new input+output pair to increase the fees on their HTLC redemption\n\u003e\u003e \u003e transaction. As you mention, they now enter into a race against this\n\u003e\u003e \u003e malicious ndoe to bump up their fees in order to win over the other\n\u003e\u003e party.\n\u003e\u003e\n\u003e\u003e Right, right, that works as well.\n\u003e\u003e\n\u003e\u003e \u003e\n\u003e\u003e \u003e If the malicious node uses a non-RBF signalled transaction to sweep\n\u003e\u003e their\n\u003e\u003e \u003e HTLC, then we enter into another level of race, but this time on the\n\u003e\u003e mempool\n\u003e\u003e \u003e propagation level. However, if there exists a relay path to a miner\n\u003e\u003e running\n\u003e\u003e \u003e full RBF, then B's higher fee rate spend will win over.\n\u003e\u003e\n\u003e\u003e Hmm.\n\u003e\u003e\n\u003e\u003e So basically:\n\u003e\u003e\n\u003e\u003e * B has no mempool, because it wants to reduce its costs and etc.\n\u003e\u003e * C broadcasts a non-RBF claim tx with low fee before A-\u003eB locktime (L+1).\n\u003e\u003e * B does not notice this tx because:\n\u003e\u003e   1.  The tx is too low fee to be put in a block.\n\u003e\u003e   2.  B has no mempool so it cannot see the tx being propagated over the\n\u003e\u003e P2P network.\n\u003e\u003e * B tries to broadcast higher-fee HTLC-timeout, but fails because it\n\u003e\u003e cannot replace a non-RBF tx.\n\u003e\u003e * After L+1, C contacts the miners off-band and offers fee payment by\n\u003e\u003e other means.\n\u003e\u003e\n\u003e\u003e It seems to me that, if my cached understanding that `\u003c0\u003e\n\u003e\u003e OP_CHECKSEQUENCEVERIFY` is sufficient to require RBF-flagging, then adding\n\u003e\u003e that to the hashlock branch (2 witness bytes, 0.5 weight) would be a pretty\n\u003e\u003e low-weight mitigation against this attack.\n\u003e\u003e\n\u003e\u003e So I think the combination below gives us good size:\n\u003e\u003e\n\u003e\u003e * The HTLC-Timeout signature from C is flagged with\n\u003e\u003e `OP_SINGLE|OP_ANYONECANPAY`.\n\u003e\u003e   * Normally, the HTLC-Timeout still deducts the fee from the value of\n\u003e\u003e the UTXO being spent.\n\u003e\u003e   * However, if B notices that the L+1 timeout is approaching, it can\n\u003e\u003e fee-bump HTLC-Timeout with some onchain funds, recreating its own signature\n\u003e\u003e but reusing the (still valid) C signature.\n\u003e\u003e * The hashlock branch in this case includes `\u003c0\u003e OP_CHECKSEQUENCEVERIFY`,\n\u003e\u003e preventing C from broadcasting a low-fee claim tx.\n\u003e\u003e\n\u003e\u003e This has the advantages:\n\u003e\u003e\n\u003e\u003e * B does not need a mempool still and can run in `blocksonly`.\n\u003e\u003e * The normal path is still the same as current behavior, we \"only\" add a\n\u003e\u003e new path where if the L+1 timeout is approaching we fee-bump the\n\u003e\u003e HTLC-Timeout.\n\u003e\u003e * Costs are pretty low:\n\u003e\u003e   * No need for extra RBF carve-out txo.\n\u003e\u003e   * Just two additional witness bytes in the hashlock branch.\n\u003e\u003e * No mempool rule changes needed, can be done with the P2P network of\n\u003e\u003e today.\n\u003e\u003e   * Probably still resilient even with future changes in mempool rules,\n\u003e\u003e as long as typical RBF behaviors still remain.\n\u003e\u003e\n\u003e\u003e Is my understanding correct?\n\u003e\u003e\n\u003e\u003e Regards,\n\u003e\u003e ZmnSCPxj\n\u003e\u003e\n\u003e\u003e \u003e\n\u003e\u003e \u003e -- Laolu\n\u003e\u003e \u003e\n\u003e\u003e \u003e On Tue, Apr 21, 2020 at 9:13 PM ZmnSCPxj via bitcoin-dev \u003c\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e \u003e\n\u003e\u003e \u003e \u003e Good morning Matt, and list,\n\u003e\u003e \u003e \u003e\n\u003e\u003e \u003e \u003e \u003e     RBF Pinning HTLC Transactions (aka \"Oh, wait, I can steal\n\u003e\u003e funds, how, now?\")\n\u003e\u003e \u003e \u003e \u003e     =============================\n\u003e\u003e \u003e \u003e \u003e\n\u003e\u003e \u003e \u003e \u003e     You'll note that in the discussion of RBF pinning we were\n\u003e\u003e pretty broad, and that that discussion seems to in fact cover\n\u003e\u003e \u003e \u003e \u003e     our HTLC outputs, at least when spent via (3) or (4). It does,\n\u003e\u003e and in fact this is a pretty severe issue in today's\n\u003e\u003e \u003e \u003e \u003e     lightning protocol [2]. A lightning counterparty (C, who\n\u003e\u003e received the HTLC from B, who received it from A) today could,\n\u003e\u003e \u003e \u003e \u003e     if B broadcasts the commitment transaction, spend an HTLC using\n\u003e\u003e the preimage with a low-fee, RBF-disabled transaction.\n\u003e\u003e \u003e \u003e \u003e     After a few blocks, A could claim the HTLC from B via the\n\u003e\u003e timeout mechanism, and then after a few days, C could get the\n\u003e\u003e \u003e \u003e \u003e     HTLC-claiming transaction mined via some out-of-band agreement\n\u003e\u003e with a small miner. This leaves B short the HTLC value.\n\u003e\u003e \u003e \u003e\n\u003e\u003e \u003e \u003e My (cached) understanding is that, since RBF is signalled using\n\u003e\u003e `nSequence`, any `OP_CHECKSEQUENCEVERIFY` also automatically imposes the\n\u003e\u003e requirement \"must be RBF-enabled\", including `\u003c0\u003e OP_CHECKSEQUENCEVERIFY`.\n\u003e\u003e \u003e \u003e Adding that clause (2 bytes in witness if my math is correct) to the\n\u003e\u003e hashlock branch may be sufficient to prevent C from making an RBF-disabled\n\u003e\u003e transaction.\n\u003e\u003e \u003e \u003e\n\u003e\u003e \u003e \u003e But then you mention out-of-band agreements with miners, which\n\u003e\u003e basically means the transaction might not be in the mempool at all, in\n\u003e\u003e which case the vulnerability is not really about RBF or relay, but sheer\n\u003e\u003e economics.\n\u003e\u003e \u003e \u003e\n\u003e\u003e \u003e \u003e The payment is A-\u003eB-\u003eC, and the HTLC A-\u003eB must have a larger timeout\n\u003e\u003e (L + 1) than the HTLC B-\u003eC (L), in abstract non-block units.\n\u003e\u003e \u003e \u003e The vulnerability you are describing means that the current time must\n\u003e\u003e now be L + 1 or greater (\"A could claim the HTLC from B via the timeout\n\u003e\u003e mechanism\", meaning the A-\u003eB HTLC has timed out already).\n\u003e\u003e \u003e \u003e\n\u003e\u003e \u003e \u003e If so, then the B-\u003eC transaction has already timed out in the past\n\u003e\u003e and can be claimed in two ways, either via B timeout branch or C hashlock\n\u003e\u003e branch.\n\u003e\u003e \u003e \u003e This sets up a game where B and C bid to miners to get their version\n\u003e\u003e of reality committed onchain.\n\u003e\u003e \u003e \u003e (We can neglect out-of-band agreements here; miners have the\n\u003e\u003e incentive to publicly leak such agreements so that other potential bidders\n\u003e\u003e can offer even higher fees for their versions of that transaction.)\n\u003e\u003e \u003e \u003e\n\u003e\u003e \u003e \u003e Before L+1, C has no incentive to bid, since placing any bid at all\n\u003e\u003e will leak the preimage, which B can then turn around and use to spend from\n\u003e\u003e A, and A and C cannot steal from B.\n\u003e\u003e \u003e \u003e\n\u003e\u003e \u003e \u003e Thus, B should ensure that *before* L+1, the HTLC-Timeout has been\n\u003e\u003e committed onchain, which outright prevents this bidding war from even\n\u003e\u003e starting.\n\u003e\u003e \u003e \u003e\n\u003e\u003e \u003e \u003e The issue then is that B is using a pre-signed HTLC-timeout, which is\n\u003e\u003e needed since it is its commitment tx that was broadcast.\n\u003e\u003e \u003e \u003e This prevents B from RBF-ing the HTLC-Timeout transaction.\n\u003e\u003e \u003e \u003e\n\u003e\u003e \u003e \u003e So what is needed is to allow B to add fees to HTLC-Timeout:\n\u003e\u003e \u003e \u003e\n\u003e\u003e \u003e \u003e * We can add an RBF carve-out output to HTLC-Timeout, at the cost of\n\u003e\u003e more blockspace.\n\u003e\u003e \u003e \u003e * With `SIGHASH_NOINPUT` we can make the C-side signature\n\u003e\u003e `SIGHASH_NOINPUT|SIGHASH_SINGLE` and allow B to re-sign the B-side\n\u003e\u003e signature for a higher-fee version of HTLC-Timeout (assuming my cached\n\u003e\u003e understanding of `SIGHASH_NOINPUT` still holds).\n\u003e\u003e \u003e \u003e\n\u003e\u003e \u003e \u003e With this, B can exponentially increase the fee as L+1 approaches.\n\u003e\u003e \u003e \u003e If B can get HTLC-Timeout confirmed before L+1, then C cannot steal\n\u003e\u003e the HTLC value at all, since the UTXO it could steal from has already been\n\u003e\u003e spent.\n\u003e\u003e \u003e \u003e\n\u003e\u003e \u003e \u003e In particular, it does not seem to me that it is necessary to change\n\u003e\u003e the hashlock-branch transaction of C at all, since this mechanism is enough\n\u003e\u003e to sidestep the issue (as I understand it).\n\u003e\u003e \u003e \u003e But it does point to a need to make HTLC-Timeout (and possibly\n\u003e\u003e symmetrically, HTLC-Success) also fee-bumpable.\n\u003e\u003e \u003e \u003e\n\u003e\u003e \u003e \u003e Note as well that this does not require a mempool: B can run in\n\u003e\u003e `blocksonly` mode and as each block comes in from L to L+1, if HTLC-Timeout\n\u003e\u003e is not confirmed, feebump HTLC-Timeout.\n\u003e\u003e \u003e \u003e In particular, HTLC-Timeout comes into play only if B broadcast its\n\u003e\u003e own commitment transaction, and B *should* be aware that it did so ---\n\u003e\u003e there is still no need for mempool monitoring here.\n\u003e\u003e \u003e \u003e\n\u003e\u003e \u003e \u003e Now, of course this only delays the war.\n\u003e\u003e \u003e \u003e Let us now consider what C can do to ensure that the bidding war will\n\u003e\u003e happen eventually.\n\u003e\u003e \u003e \u003e\n\u003e\u003e \u003e \u003e * C can bribe a miner to prevent HTLC-Timeout from confirming between\n\u003e\u003e L and L+1.\n\u003e\u003e \u003e \u003e   * Or in other words, this is a censorship attack.\n\u003e\u003e \u003e \u003e     * The Bitcoin censorship-resistance model is that censored\n\u003e\u003e transactions can be fee-bumped, which attracts non-censoring miners to try\n\u003e\u003e their luck at mining and evict the censoring miner.\n\u003e\u003e \u003e \u003e       * Thus, letting B bump the fee on HTLC-Timeout is precisely the\n\u003e\u003e mechanism we need.\n\u003e\u003e \u003e \u003e       * This sets up a bidding war between C requesting miners to\n\u003e\u003e censor, vs. B requesting miners to confirm, but that only sets the stage\n\u003e\u003e for a second bidding war later between C and B, thus C is at a\n\u003e\u003e disadvantage: it has to bribe miners to censor continuously from L to L+1\n\u003e\u003e *and* additional bribe miners to confirm its transaction after L+1, whereas\n\u003e\u003e B can offer its bribe as being something that miners can claim now without\n\u003e\u003e waiting after L+1.\n\u003e\u003e \u003e \u003e\n\u003e\u003e \u003e \u003e The issue of course is the additional output that bloats the UTXO set\n\u003e\u003e and requires another transaction to claim later.\n\u003e\u003e \u003e \u003e And if we have `SIGHASH_NOINPUT`, it seems to me that\n\u003e\u003e Decker-Russell-Osuntokun sidesteps this issue as well, as any timed-out\n\u003e\u003e HTLC can be claimed with a fee-bumpable transaction directly without\n\u003e\u003e RBF-carve-out.\n\u003e\u003e \u003e \u003e (As well, it seems to me that, if both nodes support doing so, a\n\u003e\u003e Poon-Dryja channel can be upgraded, without onchain activity, to a\n\u003e\u003e Decker-Russell-Osuntokun channel: sign a transaction spending the funding\n\u003e\u003e tx to a txo that has been set up as Decker-Russell-Osuntokun, do not\n\u003e\u003e broadcast that transaction, then revoke the latest Poon-Dryja commitment\n\u003e\u003e transactions, then switch the mechanism over to Decker-Russell-Osuntokun;\n\u003e\u003e you still need to monitor for previous Poon-Dryja commitment transactions,\n\u003e\u003e but HTLCs now sidestep the issue under discussion here.)\n\u003e\u003e \u003e \u003e\n\u003e\u003e \u003e \u003e Regards,\n\u003e\u003e \u003e \u003e ZmnSCPxj\n\u003e\u003e \u003e \u003e _______________________________________________\n\u003e\u003e \u003e \u003e bitcoin-dev mailing list\n\u003e\u003e \u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e \u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200422/cdacdb19/attachment-0001.html\u003e"}