{"type":"rich","version":"1.0","author_name":"npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4","author_url":"https://nostr.ae/npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2020-04-22\n📝 Original message:\n\u003e So what is needed is to allow B to add fees to HTLC-Timeout:\n\nIndeed, anchors as defined in #lightning-rfc/688 allows this.\n\n\u003e  * With `SIGHASH_NOINPUT` we can make the C-side signature\n\u003e  `SIGHASH_NOINPUT|SIGHASH_SINGLE` and allow B to re-sign the B-side\n\u003e  signature for a higher-fee version of HTLC-Timeout (assuming my cached\n\u003e  understanding of `SIGHASH_NOINPUT` still holds).\n\nno_input isn't needed. With simply single+anyone can pay, then B can attach\na new input+output pair to increase the fees on their HTLC redemption\ntransaction. As you mention, they now enter into a race against this\nmalicious ndoe to bump up their fees in order to win over the other party.\n\nIf the malicious node uses a non-RBF signalled transaction to sweep their\nHTLC, then we enter into another level of race, but this time on the mempool\npropagation level. However, if there exists a relay path to a miner running\nfull RBF, then B's higher fee rate spend will win over.\n\n-- Laolu\n\nOn Tue, Apr 21, 2020 at 9:13 PM ZmnSCPxj via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Good morning Matt, and list,\n\u003e\n\u003e\n\u003e\n\u003e \u003e     RBF Pinning HTLC Transactions (aka \"Oh, wait, I can steal funds,\n\u003e how, now?\")\n\u003e \u003e     =============================\n\u003e \u003e\n\u003e \u003e     You'll note that in the discussion of RBF pinning we were pretty\n\u003e broad, and that that discussion seems to in fact cover\n\u003e \u003e     our HTLC outputs, at least when spent via (3) or (4). It does, and\n\u003e in fact this is a pretty severe issue in today's\n\u003e \u003e     lightning protocol [2]. A lightning counterparty (C, who received\n\u003e the HTLC from B, who received it from A) today could,\n\u003e \u003e     if B broadcasts the commitment transaction, spend an HTLC using the\n\u003e preimage with a low-fee, RBF-disabled transaction.\n\u003e \u003e     After a few blocks, A could claim the HTLC from B via the timeout\n\u003e mechanism, and then after a few days, C could get the\n\u003e \u003e     HTLC-claiming transaction mined via some out-of-band agreement with\n\u003e a small miner. This leaves B short the HTLC value.\n\u003e\n\u003e My (cached) understanding is that, since RBF is signalled using\n\u003e `nSequence`, any `OP_CHECKSEQUENCEVERIFY` also automatically imposes the\n\u003e requirement \"must be RBF-enabled\", including `\u003c0\u003e OP_CHECKSEQUENCEVERIFY`.\n\u003e Adding that clause (2 bytes in witness if my math is correct) to the\n\u003e hashlock branch may be sufficient to prevent C from making an RBF-disabled\n\u003e transaction.\n\u003e\n\u003e But then you mention out-of-band agreements with miners, which basically\n\u003e means the transaction might not be in the mempool at all, in which case the\n\u003e vulnerability is not really about RBF or relay, but sheer economics.\n\u003e\n\u003e The payment is A-\u003eB-\u003eC, and the HTLC A-\u003eB must have a larger timeout (L +\n\u003e 1) than the HTLC B-\u003eC (L), in abstract non-block units.\n\u003e The vulnerability you are describing means that the current time must now\n\u003e be L + 1 or greater (\"A could claim the HTLC from B via the timeout\n\u003e mechanism\", meaning the A-\u003eB HTLC has timed out already).\n\u003e\n\u003e If so, then the B-\u003eC transaction has already timed out in the past and can\n\u003e be claimed in two ways, either via B timeout branch or C hashlock branch.\n\u003e This sets up a game where B and C bid to miners to get their version of\n\u003e reality committed onchain.\n\u003e (We can neglect out-of-band agreements here; miners have the incentive to\n\u003e publicly leak such agreements so that other potential bidders can offer\n\u003e even higher fees for their versions of that transaction.)\n\u003e\n\u003e Before L+1, C has no incentive to bid, since placing any bid at all will\n\u003e leak the preimage, which B can then turn around and use to spend from A,\n\u003e and A and C cannot steal from B.\n\u003e\n\u003e Thus, B should ensure that *before* L+1, the HTLC-Timeout has been\n\u003e committed onchain, which outright prevents this bidding war from even\n\u003e starting.\n\u003e\n\u003e The issue then is that B is using a pre-signed HTLC-timeout, which is\n\u003e needed since it is its commitment tx that was broadcast.\n\u003e This prevents B from RBF-ing the HTLC-Timeout transaction.\n\u003e\n\u003e So what is needed is to allow B to add fees to HTLC-Timeout:\n\u003e\n\u003e * We can add an RBF carve-out output to HTLC-Timeout, at the cost of more\n\u003e blockspace.\n\u003e * With `SIGHASH_NOINPUT` we can make the C-side signature\n\u003e `SIGHASH_NOINPUT|SIGHASH_SINGLE` and allow B to re-sign the B-side\n\u003e signature for a higher-fee version of HTLC-Timeout (assuming my cached\n\u003e understanding of `SIGHASH_NOINPUT` still holds).\n\u003e\n\u003e With this, B can exponentially increase the fee as L+1 approaches.\n\u003e If B can get HTLC-Timeout confirmed before L+1, then C cannot steal the\n\u003e HTLC value at all, since the UTXO it could steal from has already been\n\u003e spent.\n\u003e\n\u003e In particular, it does not seem to me that it is necessary to change the\n\u003e hashlock-branch transaction of C at all, since this mechanism is enough to\n\u003e sidestep the issue (as I understand it).\n\u003e But it does point to a need to make HTLC-Timeout (and possibly\n\u003e symmetrically, HTLC-Success) also fee-bumpable.\n\u003e\n\u003e Note as well that this does not require a mempool: B can run in\n\u003e `blocksonly` mode and as each block comes in from L to L+1, if HTLC-Timeout\n\u003e is not confirmed, feebump HTLC-Timeout.\n\u003e In particular, HTLC-Timeout comes into play only if B broadcast its own\n\u003e commitment transaction, and B *should* be aware that it did so --- there is\n\u003e still no need for mempool monitoring here.\n\u003e\n\u003e\n\u003e Now, of course this only delays the war.\n\u003e Let us now consider what C can do to ensure that the bidding war will\n\u003e happen eventually.\n\u003e\n\u003e * C can bribe a miner to prevent HTLC-Timeout from confirming between L\n\u003e and L+1.\n\u003e   * Or in other words, this is a censorship attack.\n\u003e     * The Bitcoin censorship-resistance model is that censored\n\u003e transactions can be fee-bumped, which attracts non-censoring miners to try\n\u003e their luck at mining and evict the censoring miner.\n\u003e       * Thus, letting B bump the fee on HTLC-Timeout is precisely the\n\u003e mechanism we need.\n\u003e       * This sets up a bidding war between C requesting miners to censor,\n\u003e vs. B requesting miners to confirm, but that only sets the stage for a\n\u003e second bidding war later between C and B, thus C is at a disadvantage: it\n\u003e has to bribe miners to censor continuously from L to L+1 *and* additional\n\u003e bribe miners to confirm its transaction after L+1, whereas B can offer its\n\u003e bribe as being something that miners can claim now without waiting after\n\u003e L+1.\n\u003e\n\u003e\n\u003e\n\u003e The issue of course is the additional output that bloats the UTXO set and\n\u003e requires another transaction to claim later.\n\u003e And if we have `SIGHASH_NOINPUT`, it seems to me that\n\u003e Decker-Russell-Osuntokun sidesteps this issue as well, as any timed-out\n\u003e HTLC can be claimed with a fee-bumpable transaction directly without\n\u003e RBF-carve-out.\n\u003e (As well, it seems to me that, if both nodes support doing so, a\n\u003e Poon-Dryja channel can be upgraded, without onchain activity, to a\n\u003e Decker-Russell-Osuntokun channel: sign a transaction spending the funding\n\u003e tx to a txo that has been set up as Decker-Russell-Osuntokun, do not\n\u003e broadcast that transaction, then revoke the latest Poon-Dryja commitment\n\u003e transactions, then switch the mechanism over to Decker-Russell-Osuntokun;\n\u003e you still need to monitor for previous Poon-Dryja commitment transactions,\n\u003e but HTLCs now sidestep the issue under discussion here.)\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200421/fd98ca19/attachment-0001.html\u003e"}