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