RBF Pinning with Counterparties and Competing Interest
39 messages, 21 Apr to 24 Jun 2020. Started by Matt Corallo.
Matt Corallo (9), ZmnSCPxj (8), David A. Harding (7), Olaoluwa Osuntokun (6), Bastien TEINTURIER (5), Antoine Riard (2), Jeremy Rubin, Rusty Russell
[Hi bitcoin-dev, in lightning-land we recently discovered some quite frustrating issues which I thought may merit broader discussion]
While reviewing the new anchor outputs spec [1] last week, I discovered it introduced a rather nasty ability for a user to use RBF Pinning to steal in-flight HTLCs which are being enforced on-chain. Sadly, Antoine pointed out that this is an issue in today's light as well, though see [2] for qualifications. After some back-and-forth with a few other lightning folks, it seems clear that there is no easy+sane fix (and the practicality of exploitation today seems incredibly low), so soliciting ideas publicly may be the best step forward.
I've included lots of background for those who aren't super comfortable with lightning's current design, but if you already know it well, you can skip at least background 1 & 2.
Background - Lightning's Transactions (you can skip this) =====================================
As many of you likely know, lightning today does all its update mechanics through: a) a 2-of-2 multisig output, locking in the channel, b) a "commitment transaction", which spends that output: i) back to its owners, ii) to "HTLC outputs", c) HTLC transactions which spend the relevant commitment transaction HTLC outputs.
This somewhat awkward third layer of transactions is required to allow HTLC timeouts to be significantly lower than the time window during which a counterparty may be punished for broadcasting a revoked state. That is to say, you want to "lock-in" the resolution of an HTLC output (ie by providing the hash lock preimage on-chain) by a fixed block height (likely a few hours from the HTLC creation), but the punishment mechanism needs to occur based on a sequence height (possibly a day or more after transaction broadcast).
As Bitcoin has no covanents, this must occur using pre-signed transactions - namely "HTLC-Success" and "HTLC-Timeout" transactions, which finalize the resolution of an HTLC, but have a sequence-lock for some time during which the funds may be taken if they had previously been revoked. To avoid needless delays, if the counterparty which did *not* broadcast the commitment transaction wishes to claim the HTLC value, they may do so immediately (as there is no reason to punish the non-broadcaster for having *not* broadcasted a revoked state). Thus, we have four possible HTLC resolutions depending on the combination of which side broadcast the HTLC and which side sent the HTLC (ie who can claim it vs who can claim it after time-out):
1) pre-signed HTLC-Success transaction, providing the preimage in the witness and sent to an output which is sequence-
locked for some time to provide the non-broadcasting side the opportunity to take the funds,
2) pre-signed HTLC-Timeout transaction, time-locked to N, providing no preimage, but with a similar sequence lock and
output as above,
3) non-pre-signed HTLC claim, providing the preimage in the witness and unencumbered by the broadcaster's signature,
4) non-pre-signed HTLC timeout, OP_CLTV to N, and similarly unencumbered.
Background 2 - RBF Pinning (you can skip this) ==========================
Bitcoin Core's general policy on RBF transactions is that if a counterparty (either to the transaction, eg in lightning, or not, eg a P2P node which sees the transaction early) can modify a transaction, especially if they can add an input or output, they can prevent it from confirming in a world where there exists a mempool (ie in a world where Bitcoin works). While this is somewhat unintuitive, there are any number of good anti-DoS reasons for this, eg: * (ok, this is a bad reason, but) a child transaction could be marked 'non-RBF', which would mean allowing the parent be RBF'd would violate the assumptions those who look at the RBF opt-in marking make, * a parent may be very large, but low feerate - this requires the RBF attempt to "pay for its own relay" and include a large absolute fee just to get into the mempool, * one of the various package size limits is at its maximum, and depending on the structure of the package the computational complexity of calculation evictions may be more than we want to do for a given transaction.
Background 3 - "The RBF Carve-Out" (you can skip this) ==================================
In today's lightning, we have a negotiation of what we expect the future feerate to be when one party goes to close the channel. All the pre-signed transactions above are constructed with this fee-rate in mind, and, given they are all pre-signed, adding additional fee to them is not generally an option. This is obviously a very maddening prediction game, especially when the security consequences for negotiating a value which is wrong may allow your counterparty to broadcast and time out HTLCs which you otherwise have the preimage for. To remove this quirk, we came up with an idea a year or two back now called "anchor outputs" (aka the RBF carve-out for those in Bitcoin-land) - a neat trick to allow both counterparties to add fees to a transaction which is being broadcast without getting into the quagmire that is RBF pinning. Specifically, we added a rule to Bitcoin Core which allows for transactions which have a narrow structure to be CPFP'd trivially by either counterparty, irrespective of what the other counterparty does! In order to meet this structure, the commitment transaction (b) must have two (potentially-)additional outputs, each which only one side can spend, and every other output must have a CSV lock associated with it. This is great and there is (finally) movement to deploy this.
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.
You'll note that B would be just fine if they had a way to safely monitor the global mempool, and while this seems like a prudent mitigation for lightning implementations to deploy today, it is itself a quagmire of complexity, especially when you consider differences in relay policy during an upgrade cycle and how those may effect propagation through the P2P network. Further, this is a really obnoxious assumption to hoist onto lightning nodes - having an active full node with an in-sync mempool is a lot more CPU, bandwidth, and complexity than most lightning users were expecting to face.
It seems highly likely we could come up with some kind of variant of of the RBF Carve-Out to solve this problem, though probably much more specific to this particular transaction structure - imagine a rule which allowed B to RBF C's low-fee HTLC claim transaction, without ever seeing it. This could be accomplished by locking down the transaction types in (3) and (4) by pre-signing them (just, like (1) and (2)) and then using some kind of policy rule to allow only the addition of additional confirmed inputs and one (small) output. This would mean that B knows that either C's transaction has high fee, or B's reasonably-higher-fee transaction will meet the RBF rules and replace C's maliciousness.
While the original RBF Carve-Out was a little awkward, its structure was sufficiently generic that other off-chain protocols could reasonably (need to) take advantage of it, however a rule to address this issue seems like it would need to be highly tailored to lightning, which doesn't seem acceptable (there appears to be a way to shoehorn the existing carve-out, but it results in a ton of extra on-chain volume).
Strategies involving full-RBF for transactions not at the top of the mempool, (slow-)full-mempool-sync allowing mempool-total-fee decreases and relaxations of the RBF rules would be welcome, but without a ton of legwork to include things like package relay I'm not convinced they would suffice. This of course doesn't even account for the possibility of similar issues given rely policy differences.
PS For Lightning-Dev Folks (aka "An Alternative Anchor Proposal") ==========================
Given the anchor outputs proposal seeks to expand lightning's security in a world where Bitcoin is running at steady-state and the mempool reliably has transactions in it, not fixing this issue seems to render the whole exercise somewhat useless (not to mention that the current design makes this attack more obvious and provides several alternative paths to exploitation).
An alternative, albeit not ideal anchor outputs proposal is as follows:
* Instead of making the HTLC output spending more free-form with SIGHASH_ANYONECAN_PAY|SIGHASH_SINGLE, we clearly need to go the other direction - all HTLC output spends need to be pre-signed. * Sadly, and this really hurts from an on-chain-tx-size perspective, we have to include anchor outputs in the HTLC transactions (intuitively I think all of them, but at least HTLC-fulfilling transactions definitely). * Our poor B, being exploited, above, will attempt to spend their anchor output with a CPFP even if they aren't sure C has broadcast the HTLC-Success transaction! This is fine as B already knows the txid, and just wants to learn whats in the witness (assuming there is one).
For those from bitcoin-dev still reading who are thinking "blah, you clearly don't need anything else, you have a solution!" we're talking about extra outputs out the wazoo for hopefully-unnecessary edge cases involving transactions entering the mempool which a user wants to avoid confirming! This severely cuts into the lowest-value HTLCs which can be sent "safely" and adds a significant social cost of extra low-value, possibly-uneconomical outputs in the chain.
Still, lacking a better idea, and with a strong desire to make lightning's security more practical in a world where Bitcoin miners are paid to operate, we should probably start considering moving forward with this.
Thanks for reading, Matt
[1] https://github.com/lightningnetwork/lightning-rfc/pull/688
[2] I'll note that while it is a "severe issue", given the general issues with fee-prediction described in background 3, its pretty hard to argue its really in the scope of the security model of lightning today. If there were an easy fix to it, we'd have deployed it by now in response to private discussion, but, sadly, there is not.
Good morning Matt, and list,
Quoted text (9 lines)
> 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
Hi Matt,
Quoted text (2 lines)
> While this is somewhat unintuitive, there are any number of good anti-DoS > reasons for this, eg:
None of these really strikes me as "good" reasons for this limitation, which is at the root of this issue, and will also plague any more complex Bitcoin contracts which rely on nested trees of transaction to confirm (CTV, Duplex, channel factories, etc). Regarding the various (seemingly arbitrary) package limits it's likely the case that any issues w.r.t computational complexity that may arise when trying to calculate evictions can be ameliorated with better choice of internal data structures.
In the end, the simplest heuristic (accept the higher fee rate package) side steps all these issues and is also the most economically rationale from a miner's perspective. Why would one prefer a higher absolute fee package (which could be very large) over another package with a higher total _fee rate_?
Quoted text (1 line)
> You'll note that B would be just fine if they had a way to safely monitor
the
Quoted text (3 lines)
> global mempool, and while this seems like a prudent mitigation for > lightning implementations to deploy today, it is itself a quagmire of > complexity
Is it really all that complex? Assuming we're talking about just watching for a certain script template (the HTLC scipt) in the mempool to be able to pull a pre-image as soon as possible. Early versions of lnd used the mempool for commitment broadcast detection (which turned out to be a bad idea so we removed it), but at a glance I don't see why watching the mempool is so complex.
Quoted text (4 lines)
> Further, this is a really obnoxious assumption to hoist onto lightning > nodes - having an active full node with an in-sync mempool is a lot more > CPU, bandwidth, and complexity than most lightning users were expecting to > face.
This would only be a requirement for Lightning nodes that seek to be a part of the public routing network with a desire to _forward_ HTLCs. This isn't doesn't affect laptops or mobile phones which likely mostly have private channels and don't participate in HTLC forwarding. I think it's pretty reasonable to expect a "proper" routing node on the network to be backed by a full-node. The bandwidth concern is valid, but we'd need concrete numbers that compare the bandwidth over head of mempool awareness (assuming the latest and greatest mempool syncing) compared with the overhead of the channel update gossip and gossip queries over head which LN nodes face today as is to see how much worse off they really would be.
As detailed a bit below, if nodes watch the mempool, then this class of attack assuming the anchor output format as described in the open lightning-rfc PR is mitigated. At a glance, watching the mempool seems like a far less involved process compared to modifying the state machine as its defined today. By watching the mempool and implementing the changes in #lightning-rfc/688, then this issue can be mitigated _today_. lnd 0.10 doesn't yet watch the mempool (but does include anchors [1]), but unless I'm missing something it should be pretty straight forward to add which mor or less resolves this issue all together.
Quoted text (1 line)
> not fixing this issue seems to render the whole exercise somewhat useless
Depends on if one considers watching the mempool a fix. But even with that a base version of anchors still resolves a number of issues including: eliminating the commitment fee guessing game, allowing users to pay less on force close, being able to coalesce 2nd level HTLC transactions with the same CLTV expiry, and actually being able to reliably enforce multi-hop HTLC resolution.
Quoted text (3 lines)
> Instead of making the HTLC output spending more free-form with > SIGHASH_ANYONECAN_PAY|SIGHASH_SINGLE, we clearly need to go the other > direction - all HTLC output spends need to be pre-signed.
I'm not sure this is actually immediately workable (need to think about it more). To see why, remember that the commit_sig message includes HTLC signatures for the _remote_ party's commitment transaction, so they can spend the HTLCs if they broadcast their version of the commitment (force close). If we don't somehow also _gain_ signatures (our new HTLC signatures) allowing us to spend HTLCs on _their_ version of the commitment, then if they broadcast that commitment (without revoking), then we're unable to redeem any of those HTLCs at all, possibly losing money.
In an attempt to counteract this, we might say ok, the revoke message also now includes HTLC signatures for their new commitment allowing us to spend our HTLCs. This resolves things in a weaker security model, but doesn't address the issue generally, as after they receive the commit_sig, they can broadcast immediately, again leaving us without a way to redeem our HTLCs.
I'd need to think about it more, but it seems that following this path would require an overhaul in the channel state machine to make presenting a new commitment actually take at least _two phases_ (at least a full round trip). The first phase would tender the commitment, but render them unable to broadcast it. The second phase would then <insert something something scriptless scripts here> enter a new sub-protocol which upon conclusion, gives the commitment proposer valid HTLC signatures, and gives the responder what they need to be able to broadcast their commitment and claim their HTCLs in an atomic manner.
-- Laolu
Quoted text (1 line)
> So what is needed is to allow B to add fees to HTLC-Timeout:
Indeed, anchors as defined in #lightning-rfc/688 allows this.
Quoted text (4 lines)
> * 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@lists•linuxfoundation•org> wrote:
Quoted text (130 lines)
> 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@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>Good morning Laolu, Matt, and list,
Quoted text (9 lines)
> > * 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.
Right, right, that works as well.
Quoted text (5 lines)
> > 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.
Hmm.
So basically:
* B has no mempool, because it wants to reduce its costs and etc. * C broadcasts a non-RBF claim tx with low fee before A->B locktime (L+1). * B does not notice this tx because: 1. The tx is too low fee to be put in a block. 2. B has no mempool so it cannot see the tx being propagated over the P2P network. * B tries to broadcast higher-fee HTLC-timeout, but fails because it cannot replace a non-RBF tx. * After L+1, C contacts the miners off-band and offers fee payment by other means.
It seems to me that, if my cached understanding that `<0> OP_CHECKSEQUENCEVERIFY` is sufficient to require RBF-flagging, then adding that to the hashlock branch (2 witness bytes, 0.5 weight) would be a pretty low-weight mitigation against this attack.
So I think the combination below gives us good size:
* The HTLC-Timeout signature from C is flagged with `OP_SINGLE|OP_ANYONECANPAY`. * Normally, the HTLC-Timeout still deducts the fee from the value of the UTXO being spent. * However, if B notices that the L+1 timeout is approaching, it can fee-bump HTLC-Timeout with some onchain funds, recreating its own signature but reusing the (still valid) C signature. * The hashlock branch in this case includes `<0> OP_CHECKSEQUENCEVERIFY`, preventing C from broadcasting a low-fee claim tx.
This has the advantages:
* B does not need a mempool still and can run in `blocksonly`. * The normal path is still the same as current behavior, we "only" add a new path where if the L+1 timeout is approaching we fee-bump the HTLC-Timeout. * Costs are pretty low: * No need for extra RBF carve-out txo. * Just two additional witness bytes in the hashlock branch. * No mempool rule changes needed, can be done with the P2P network of today. * Probably still resilient even with future changes in mempool rules, as long as typical RBF behaviors still remain.
Is my understanding correct?
Regards, ZmnSCPxj
Quoted text (69 lines)
>
> -- Laolu
>
> On Tue, Apr 21, 2020 at 9:13 PM ZmnSCPxj via bitcoin-dev <bitcoin-dev@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@lists•linuxfoundation•org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-devPersonally, I would have wait a bit before to go public on this, like letting some implementations increasing their CLTV deltas, but anyway, it's here now.
Mempool-pinning attacks were already discussed on this list [0], but what we found is you can _reverse_ the scenario, where it's not the malicious party delaying confirmation of honest party transactions but malicious deliberately stucking its own transactions in the mempool to avoid confirmation of timeout. And therefore gaming inter-link timelock to provoke an unbalanced settlement for the victim ("aka you pay forward, but don't get pay backward").
How much attacks are practical is based on how you can leverage mempool rules to pin your own transaction. What you're looking for is a _mempool-obstruction_ trick, i.e a way to get honest party transaction being bounce off due to your transaction being already there.
Beyond disabling RBF on your transaction (with current protocol, not anchor proposal), there is two likely candidates: * BIP 125 rule 3: "The replacement transaction pays an absolute fee of at least the sum paid by the original transactions." * BIP 125 rule 5: "The number of original transactions to be replaced and their descendant transactions which will be evicted from the mempool must not exceed a total of 100 transactions."
Let's go through whole scenario: * Mallory and Eve are colluding * Eve and Mallory are opening channels with Alice, Mallory do a bit of rebalancing to get full incoming capacity, like receiving funds on an onchain address through another Alice link * Eve send a HTLC #1 to Mallory through Alice expirying at block 100 * Eve send a second HTLC #2 to Mallory through Alice, expirying at block 110 on outgoing link (A<->M), 120 on incoming link (E<->A) * Before block 100, without cancellation from Mallory, Alice will force-close channel and broadcast her local commitment and HTLC-timeout to get back HTLC #1 * Alice can't broadcast HTLC-timeout for HTLC #2 as it's only expires at 110 * Mallory can broadcast its Pinning Preimage Tx on offered HTLC #2 output on Alice's transaction, feerate is maliciously chosen to get in network mempools but never to confirm. Absolute fee must be higher than HTLC-timeout #2, a fact known to Mallory. There is no p2p race. * As Alice doesn't watch the mempool, she is never going to learn the preimage to redeeem incoming HTLC #2 * At block 110, Alice is going to broadcast HTLC-timeout #2, feerate may be higher but as absolute fee is lower, it's going to be rejected from network mempools as replacement for Pinning Preimage Tx (BIP 125 rule 3) * At block 120, Eve closes channel and HTLC-timeout HTLC #2 * Mallory can RBF its Pinning Preimage Tx by a high-feerate one and get it confirmed
New anchor_output proposal, by disabling RBF, forces attacker to bid on the absolute fee. It may be now a risk to loose the fee if Pinning Tx is confirming. You may extend your "pinning lease" by ejecting your malicious tx, like conflicting or trimming out of the mempool one of its parents. And then reannounce your preimage tx with a lower-feerate-but-still-high-fee before a new block and a honest HTLC-timeout rebroadcast.
AFAICT, even with anchor_output deployed, even assuming empty mempools, success rate and economic rationality of attacks is finding such cheap, reliable "pinning lease extension" trick.
I think any mempool watching mitigation is at best a cat-and-mouse hack. Contrary to node advancing towards a global blockchain view thanks to PoW, network mempools don't have a convergence guarantee. This means, in a distributed system like bitcoin, node don't see events in the same order, Alice may observe tx X, tx Y, tx Z and Bob may observe tx Z, tx X, tx Y. And order of events affects if a future event is going to be rejected or not, like if tx Z disable-RBF and tx X try to replace Z, Alice accepts X and Bob rejects it. And this divergence may perserve until a new block.
Practically, it means an attacker can provoke a local conflict to bounce off HTLC preimage tx out of your mempool while broadcasting preimage tx without conflict to the rest of the network by tweaking tx-relay protocol and so easily manipulating order of events for every node. A local conflict is easy to provoke, just make tx A double-spent by both HTLC-preimage-tx and non-RBF-tx-B. Announce txA+txB to mempool victim and txA+HTLC-preimage-tx to rest of network. When rest of network announce HTLC-preimage-tx, it's going to rejected by your mempool.
Provoking local conflict assumes of course _interlayer_ mapping by an attacker, i.e mapping your LN node to your full-node(s). Last time, we check, there was 982 match by IP for 4,500 LN/52,000 full-node. Mapping heuristics is an ongoing research subject and sadly seems affordable.
Yes a) you can enable full-RBF on your local node but blinding conflicting may still be with higher feerate as everything is attacker malleable b) you may want to catch tx and extract preimage on the p2p wire, but processing raw transaction would be such a DoS vector...
Overall, I think we all agree on the long term direction to get a Contracting-Protocols-Enhanced mempool with a multiparty-safe-API, bundled with package relay deployment. Even if there is current move toward this direction, this may take longer than expected as with any critical-safety component in Core.
A temporary fix could be to resuscitate old work to ensure peering through a full-RBF propagation path, but p2p implications are hard to gauge, like wouldn't guarantee p2p censorship resistance of this...
It's quite a tangled issue, with a good deal of both bitcoin and lightning knowledge so feel free to verify and double-check more than usual
Cheers
[0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/002240.html
Le mer. 22 avr. 2020 à 02:08, ZmnSCPxj via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> a écrit :
Quoted text (215 lines)
> Good morning Laolu, Matt, and list,
>
>
> > > * 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.
>
> Right, right, that works as well.
>
> >
> > 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.
>
> Hmm.
>
> So basically:
>
> * B has no mempool, because it wants to reduce its costs and etc.
> * C broadcasts a non-RBF claim tx with low fee before A->B locktime (L+1).
> * B does not notice this tx because:
> 1. The tx is too low fee to be put in a block.
> 2. B has no mempool so it cannot see the tx being propagated over the
> P2P network.
> * B tries to broadcast higher-fee HTLC-timeout, but fails because it
> cannot replace a non-RBF tx.
> * After L+1, C contacts the miners off-band and offers fee payment by
> other means.
>
> It seems to me that, if my cached understanding that `<0>
> OP_CHECKSEQUENCEVERIFY` is sufficient to require RBF-flagging, then adding
> that to the hashlock branch (2 witness bytes, 0.5 weight) would be a pretty
> low-weight mitigation against this attack.
>
> So I think the combination below gives us good size:
>
> * The HTLC-Timeout signature from C is flagged with
> `OP_SINGLE|OP_ANYONECANPAY`.
> * Normally, the HTLC-Timeout still deducts the fee from the value of the
> UTXO being spent.
> * However, if B notices that the L+1 timeout is approaching, it can
> fee-bump HTLC-Timeout with some onchain funds, recreating its own signature
> but reusing the (still valid) C signature.
> * The hashlock branch in this case includes `<0> OP_CHECKSEQUENCEVERIFY`,
> preventing C from broadcasting a low-fee claim tx.
>
> This has the advantages:
>
> * B does not need a mempool still and can run in `blocksonly`.
> * The normal path is still the same as current behavior, we "only" add a
> new path where if the L+1 timeout is approaching we fee-bump the
> HTLC-Timeout.
> * Costs are pretty low:
> * No need for extra RBF carve-out txo.
> * Just two additional witness bytes in the hashlock branch.
> * No mempool rule changes needed, can be done with the P2P network of
> today.
> * Probably still resilient even with future changes in mempool rules, as
> long as typical RBF behaviors still remain.
>
> Is my understanding correct?
>
> Regards,
> ZmnSCPxj
>
> >
> > -- Laolu
> >
> > On Tue, Apr 21, 2020 at 9:13 PM ZmnSCPxj via bitcoin-dev <
> bitcoin-dev@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@lists•linuxfoundation•org
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>Hi Antoine and list,
Thanks for raising this. There's one step I'd like to understand further:
* Mallory can broadcast its Pinning Preimage Tx on offered HTLC #2 output
Quoted text (6 lines)
> on Alice's transaction, > feerate is maliciously chosen to get in network mempools but never to > confirm. Absolute fee must > be higher than HTLC-timeout #2, a fact known to Mallory. There is no p2p > race. >
Can you detail how the "absolute fee" is computed here? Doesn't that mean that if this had a higher fee than the htlc-timeout, and the htlc-timeout fee was chosen to confirm quickly (that's why we have an annoying `update_fee`), the htlc-success will confirm quickly (which makes the problem disappear)? Because once the commit tx is confirmed, the "package" consists of only the htlc-success, doesn't it?
I think the devil will be in the details here, so it's worth expanding on the fee calculation imho.
Thanks! Bastien
Le mer. 22 avr. 2020 à 10:01, Antoine Riard <antoine.riard@gmail•com> a écrit :
Quoted text (365 lines)
> Personally, I would have wait a bit before to go public on this, like
> letting some implementations
> increasing their CLTV deltas, but anyway, it's here now.
>
> Mempool-pinning attacks were already discussed on this list [0], but what
> we found is you
> can _reverse_ the scenario, where it's not the malicious party delaying
> confirmation of honest
> party transactions but malicious deliberately stucking its own
> transactions in the mempool to avoid
> confirmation of timeout. And therefore gaming inter-link timelock to
> provoke an unbalanced
> settlement for the victim ("aka you pay forward, but don't get pay
> backward").
>
> How much attacks are practical is based on how you can leverage mempool
> rules to pin your own
> transaction. What you're looking for is a _mempool-obstruction_ trick,
> i.e a way to get honest party
> transaction being bounce off due to your transaction being already there.
>
> Beyond disabling RBF on your transaction (with current protocol, not
> anchor proposal), there is
> two likely candidates:
> * BIP 125 rule 3: "The replacement transaction pays an absolute fee of at
> least the sum paid by the original transactions."
> * BIP 125 rule 5: "The number of original transactions to be replaced and
> their descendant transactions which will be evicted from the mempool must
> not exceed a total of 100 transactions."
>
> Let's go through whole scenario:
> * Mallory and Eve are colluding
> * Eve and Mallory are opening channels with Alice, Mallory do a bit of
> rebalancing
> to get full incoming capacity, like receiving funds on an onchain address
> through another Alice
> link
> * Eve send a HTLC #1 to Mallory through Alice expirying at block 100
> * Eve send a second HTLC #2 to Mallory through Alice, expirying at block
> 110 on outgoing link
> (A<->M), 120 on incoming link (E<->A)
> * Before block 100, without cancellation from Mallory, Alice will
> force-close channel and broadcast
> her local commitment and HTLC-timeout to get back HTLC #1
> * Alice can't broadcast HTLC-timeout for HTLC #2 as it's only expires at
> 110
> * Mallory can broadcast its Pinning Preimage Tx on offered HTLC #2 output
> on Alice's transaction,
> feerate is maliciously chosen to get in network mempools but never to
> confirm. Absolute fee must
> be higher than HTLC-timeout #2, a fact known to Mallory. There is no p2p
> race.
> * As Alice doesn't watch the mempool, she is never going to learn the
> preimage to redeeem incoming
> HTLC #2
> * At block 110, Alice is going to broadcast HTLC-timeout #2, feerate may
> be higher but as absolute
> fee is lower, it's going to be rejected from network mempools as
> replacement for Pinning Preimage
> Tx (BIP 125 rule 3)
> * At block 120, Eve closes channel and HTLC-timeout HTLC #2
> * Mallory can RBF its Pinning Preimage Tx by a high-feerate one and get it
> confirmed
>
> New anchor_output proposal, by disabling RBF, forces attacker to bid on
> the absolute fee. It may
> be now a risk to loose the fee if Pinning Tx is confirming. You may extend
> your "pinning
> lease" by ejecting your malicious tx, like conflicting or trimming out of
> the mempool one of its
> parents. And then reannounce your preimage tx with a
> lower-feerate-but-still-high-fee before a
> new block and a honest HTLC-timeout rebroadcast.
>
> AFAICT, even with anchor_output deployed, even assuming empty mempools,
> success rate and economic
> rationality of attacks is finding such cheap, reliable "pinning lease
> extension" trick.
>
> I think any mempool watching mitigation is at best a cat-and-mouse hack.
> Contrary to node
> advancing towards a global blockchain view thanks to PoW, network mempools
> don't have a convergence
> guarantee. This means, in a distributed system like bitcoin, node don't
> see events in the same
> order, Alice may observe tx X, tx Y, tx Z and Bob may observe tx Z, tx X,
> tx Y. And order of events
> affects if a future event is going to be rejected or not, like if tx Z
> disable-RBF and tx X try to
> replace Z, Alice accepts X and Bob rejects it. And this divergence may
> perserve until a new block.
>
> Practically, it means an attacker can provoke a local conflict to bounce
> off HTLC preimage tx out
> of your mempool while broadcasting preimage tx without conflict to the
> rest of the network by
> tweaking tx-relay protocol and so easily manipulating order of events for
> every node. A local
> conflict is easy to provoke, just make tx A double-spent by both
> HTLC-preimage-tx and non-RBF-tx-B.
> Announce txA+txB to mempool victim and txA+HTLC-preimage-tx to rest of
> network. When rest of
> network announce HTLC-preimage-tx, it's going to rejected by your mempool.
>
> Provoking local conflict assumes of course _interlayer_ mapping by an
> attacker, i.e mapping your LN
> node to your full-node(s). Last time, we check, there was 982 match by IP
> for 4,500 LN/52,000
> full-node. Mapping heuristics is an ongoing research subject and sadly
> seems affordable.
>
> Yes a) you can enable full-RBF on your local node but blinding conflicting
> may still be with higher
> feerate as everything is attacker malleable b) you may want to catch tx
> and extract preimage
> on the p2p wire, but processing raw transaction would be such a DoS
> vector...
>
> Overall, I think we all agree on the long term direction to get a
> Contracting-Protocols-Enhanced
> mempool with a multiparty-safe-API, bundled with package relay deployment.
> Even if there is current
> move toward this direction, this may take longer than expected as with any
> critical-safety
> component in Core.
>
> A temporary fix could be to resuscitate old work to ensure peering through
> a full-RBF propagation path,
> but p2p implications are hard to gauge, like wouldn't guarantee p2p
> censorship resistance of this...
>
> It's quite a tangled issue, with a good deal of both bitcoin and lightning
> knowledge so feel free
> to verify and double-check more than usual
>
> Cheers
>
> [0]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/002240.html
>
> Le mer. 22 avr. 2020 à 02:08, ZmnSCPxj via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation•org> a écrit :
>
>> Good morning Laolu, Matt, and list,
>>
>>
>> > > * 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.
>>
>> Right, right, that works as well.
>>
>> >
>> > 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.
>>
>> Hmm.
>>
>> So basically:
>>
>> * B has no mempool, because it wants to reduce its costs and etc.
>> * C broadcasts a non-RBF claim tx with low fee before A->B locktime (L+1).
>> * B does not notice this tx because:
>> 1. The tx is too low fee to be put in a block.
>> 2. B has no mempool so it cannot see the tx being propagated over the
>> P2P network.
>> * B tries to broadcast higher-fee HTLC-timeout, but fails because it
>> cannot replace a non-RBF tx.
>> * After L+1, C contacts the miners off-band and offers fee payment by
>> other means.
>>
>> It seems to me that, if my cached understanding that `<0>
>> OP_CHECKSEQUENCEVERIFY` is sufficient to require RBF-flagging, then adding
>> that to the hashlock branch (2 witness bytes, 0.5 weight) would be a pretty
>> low-weight mitigation against this attack.
>>
>> So I think the combination below gives us good size:
>>
>> * The HTLC-Timeout signature from C is flagged with
>> `OP_SINGLE|OP_ANYONECANPAY`.
>> * Normally, the HTLC-Timeout still deducts the fee from the value of
>> the UTXO being spent.
>> * However, if B notices that the L+1 timeout is approaching, it can
>> fee-bump HTLC-Timeout with some onchain funds, recreating its own signature
>> but reusing the (still valid) C signature.
>> * The hashlock branch in this case includes `<0> OP_CHECKSEQUENCEVERIFY`,
>> preventing C from broadcasting a low-fee claim tx.
>>
>> This has the advantages:
>>
>> * B does not need a mempool still and can run in `blocksonly`.
>> * The normal path is still the same as current behavior, we "only" add a
>> new path where if the L+1 timeout is approaching we fee-bump the
>> HTLC-Timeout.
>> * Costs are pretty low:
>> * No need for extra RBF carve-out txo.
>> * Just two additional witness bytes in the hashlock branch.
>> * No mempool rule changes needed, can be done with the P2P network of
>> today.
>> * Probably still resilient even with future changes in mempool rules,
>> as long as typical RBF behaviors still remain.
>>
>> Is my understanding correct?
>>
>> Regards,
>> ZmnSCPxj
>>
>> >
>> > -- Laolu
>> >
>> > On Tue, Apr 21, 2020 at 9:13 PM ZmnSCPxj via bitcoin-dev <
>> bitcoin-dev@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@lists•linuxfoundation•org
>> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation•org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>On Tue, Apr 21, 2020 at 09:13:34PM -0700, Olaoluwa Osuntokun wrote:
Quoted text (9 lines)
> On Mon, Apr 20, 2020 at 10:43:14PM -0400, Matt Corallo via Lightning-dev wrote: > > While this is somewhat unintuitive, there are any number of good anti-DoS > > reasons for this, eg: > > None of these really strikes me as "good" reasons for this limitation > [...] > In the end, the simplest heuristic (accept the higher fee rate > package) side steps all these issues and is also the most economically > rationale from a miner's perspective.
I think it's important to remember than mempool behavior affects not just miners but also relay nodes. Miner costs, such as bandwidth usage, can be directly offset by their earned block rewards, so miners can be much more tolerant of wasted bandwidth than relay nodes who receive no direct financial compensation for the processing and relay of unconfirmed transactions.[1]
Quoted text (2 lines)
> Why would one prefer a higher absolute fee package (which could be > very large) over another package with a higher total _fee rate_?
To avoid the excessive wasting of bandwidth. Bitcoin Core's defaults require each replacement pay a feerate of 10 nBTC/vbyte over an existing transaction or package, and the defaults also allow transactions or packages up to 100,000 vbytes in size (~400,000 bytes). So, without enforcement of BIP125 rule 3, an attacker starting at the minimum default relay fee also of 10 nBTC/vbyte could do the following:
- Create a ~400,000 bytes tx with feerate of 10 nBTC/vbyte (1 mBTC total fee)
- Replace that transaction with 400,000 new bytes at a feerate of 20 nBTC/vbyte (2 mBTC total fee)
- Perform 998 additional replacements, each increasing the feerate by 10 nBTC/vbyte and the total fee by 1 mBTC, using a total of 400 megabytes (including the original transaction and first replacement) to ultimately produce a transaction with a feerate of 10,000 nBTC/vbyte (1 BTC total fee)
- Perform one final replacement of the latest 400,000 byte transaction with a ~200-byte (~150 vbyte) 1-in, 1-out P2WPKH transaction that pays a feerate of 10,010 nBTC/vbyte (1.5 mBTC total fee)
Assuming 50,000 active relay nodes and today's BTC price of ~$7,000 USD/BTC, the above scenario would allow an attacker to waste a collective 20 terabytes of network bandwidth for a total fee cost of $10.50. And, of course, the attacker could run multiple attacks of this sort in parallel, quickly swamping the network.
To use the above concrete example to repeat the point made at the beginning of this email: miners might be willing to accept the waste of 400 MB of bandwidth in order to gain a $10.50 fee, but I think very few relay nodes could function for long under an onslaught of such behavior.
-Dave
[1] The reward to relay nodes of maintaining the public relay network is
that it helps protect against miner centralization. If there was no
public relay network, users would need to submit transactions
directly to miners or via a privately-controlled relay network.
Users desiring timely confirmation (and operators of private relay
networks) would have a large incentive to get transactions to the
largest miners but only a small incentive to get the transaction to
the smaller miners, increasing the economies of scale in mining and
furthering centralization.
Although users of Bitcoin benefit by reducing mining centralization
pressure, I don't think we can expect most users to be willing to
bear large costs in defense of benefits which are largely intangible
(until they're gone), so we must try to keep the cost of operating a
relay node within a reasonable margin of the cost of operating a
minimal-bandwidth blocks-only node.A few replies inline.
On 4/22/20 12:13 AM, Olaoluwa Osuntokun wrote:
Quoted text (19 lines)
> Hi Matt, > > >> While this is somewhat unintuitive, there are any number of good anti-DoS >> reasons for this, eg: > > None of these really strikes me as "good" reasons for this limitation, which > is at the root of this issue, and will also plague any more complex Bitcoin > contracts which rely on nested trees of transaction to confirm (CTV, Duplex, > channel factories, etc). Regarding the various (seemingly arbitrary) package > limits it's likely the case that any issues w.r.t computational complexity > that may arise when trying to calculate evictions can be ameliorated with > better choice of internal data structures. > > In the end, the simplest heuristic (accept the higher fee rate package) side > steps all these issues and is also the most economically rationale from a > miner's perspective. Why would one prefer a higher absolute fee package > (which could be very large) over another package with a higher total _fee > rate_?
This seems like a somewhat unnecessary drive-by insult of a project you don't contribute to, but feel free to start with a concrete suggestion here :).
Quoted text (11 lines)
>> You'll note that B would be just fine if they had a way to safely monitor the >> global mempool, and while this seems like a prudent mitigation for >> lightning implementations to deploy today, it is itself a quagmire of >> complexity > > Is it really all that complex? Assuming we're talking about just watching > for a certain script template (the HTLC scipt) in the mempool to be able to > pull a pre-image as soon as possible. Early versions of lnd used the mempool > for commitment broadcast detection (which turned out to be a bad idea so we > removed it), but at a glance I don't see why watching the mempool is so > complex.
Because watching your own mempool is not guaranteed to work, and during upgrade cycles that include changes to the policy rules an attacker could exploit your upgraded/non-upgraded status to perform the same attack.
Quoted text (15 lines)
>> Further, this is a really obnoxious assumption to hoist onto lightning >> nodes - having an active full node with an in-sync mempool is a lot more >> CPU, bandwidth, and complexity than most lightning users were expecting to >> face. > > This would only be a requirement for Lightning nodes that seek to be a part > of the public routing network with a desire to _forward_ HTLCs. This isn't > doesn't affect laptops or mobile phones which likely mostly have private > channels and don't participate in HTLC forwarding. I think it's pretty > reasonable to expect a "proper" routing node on the network to be backed by > a full-node. The bandwidth concern is valid, but we'd need concrete numbers > that compare the bandwidth over head of mempool awareness (assuming the > latest and greatest mempool syncing) compared with the overhead of the > channel update gossip and gossip queries over head which LN nodes face today > as is to see how much worse off they really would be.
If mempool-watching were practical, maybe, though there are a number of folks who are talking about designing partially-offline local lightning hubs which would be rendered impractical.
Quoted text (31 lines)
> As detailed a bit below, if nodes watch the mempool, then this class of > attack assuming the anchor output format as described in the open > lightning-rfc PR is mitigated. At a glance, watching the mempool seems like > a far less involved process compared to modifying the state machine as its > defined today. By watching the mempool and implementing the changes in > #lightning-rfc/688, then this issue can be mitigated _today_. lnd 0.10 > doesn't yet watch the mempool (but does include anchors [1]), but unless I'm > missing something it should be pretty straight forward to add which mor or less > resolves this issue all together. > >> not fixing this issue seems to render the whole exercise somewhat useless > > Depends on if one considers watching the mempool a fix. But even with that a > base version of anchors still resolves a number of issues including: > eliminating the commitment fee guessing game, allowing users to pay less on > force close, being able to coalesce 2nd level HTLC transactions with the > same CLTV expiry, and actually being able to reliably enforce multi-hop HTLC > resolution. > >> Instead of making the HTLC output spending more free-form with >> SIGHASH_ANYONECAN_PAY|SIGHASH_SINGLE, we clearly need to go the other >> direction - all HTLC output spends need to be pre-signed. > > I'm not sure this is actually immediately workable (need to think about it > more). To see why, remember that the commit_sig message includes HTLC > signatures for the _remote_ party's commitment transaction, so they can > spend the HTLCs if they broadcast their version of the commitment (force > close). If we don't somehow also _gain_ signatures (our new HTLC signatures) > allowing us to spend HTLCs on _their_ version of the commitment, then if > they broadcast that commitment (without revoking), then we're unable to > redeem any of those HTLCs at all, possibly losing money.
Hmm, maybe the proposal wasn't clear. The idea isn't to add signatures to braodcasted transactions, but instead to CPFP a maybe-broadcasted transaction by sending a transaction which spends it and seeing if it is accepted. You only need to know the transaction's exact format (ie txid, which we do, since we sent a signature for it long ago) to do this, you don't have to actually *have* the fully-signed transaction (and you don't).
Quoted text (19 lines)
> In an attempt to counteract this, we might say ok, the revoke message also > now includes HTLC signatures for their new commitment allowing us to spend > our HTLCs. This resolves things in a weaker security model, but doesn't > address the issue generally, as after they receive the commit_sig, they can > broadcast immediately, again leaving us without a way to redeem our HTLCs. > > I'd need to think about it more, but it seems that following this path would > require an overhaul in the channel state machine to make presenting a new > commitment actually take at least _two phases_ (at least a full round trip). > The first phase would tender the commitment, but render them unable to > broadcast it. The second phase would then <insert something something > scriptless scripts here> enter a new sub-protocol which upon conclusion, > gives the commitment proposer valid HTLC signatures, and gives the responder > what they need to be able to broadcast their commitment and claim their > HTCLs in an atomic manner. > > -- Laolu > > [1]: https://github.com/lightningnetwork/lnd/pull/3821
On 4/22/20 12:12 AM, ZmnSCPxj wrote:
Quoted text (16 lines)
> 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.
Hmm, indeed, though note that (IIRC) you can break this by adding children or parents which are *not* RBF-enabled and then the package may lose the ability to be RBF'd.
Quoted text (1 line)
> 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.
No. The whole point of this attack is that you keep a transaction in the mempool but unconfirmed via RBF pinning, which prevents an *alternative* transaction from being confirmed. You then have plenty of time to go get it confirmed later.
Quoted text (6 lines)
> 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.)Right, I think I didn't explain clearly enough. The point is that, here, B tries to broadcast the timeout transaction but cannot because there is an in-mempool conflict.
Quoted text (11 lines)
> 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).
This does not solve the issue because you can add as many fees as you want, as long as the transaction is RBF-pinned, there is not much you can do in an automated fashion.
Quoted text (28 lines)
> 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 >
On Mon, Apr 20, 2020 at 10:43:14PM -0400, Matt Corallo via Lightning-dev wrote:
Quoted text (7 lines)
> 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.
IIUC, the main problem is honest Bob will broadcast a transaction without realizing it conflicts with a pinned transaction that's already in most node's mempools. If Bob knew about the pinned transaction and could get a copy of it, he'd be fine.
In that case, would it be worth re-implementing something like a BIP61 reject message but with an extension that returns the txids of any conflicts? For example, when Bob connects to a bunch of Bitcoin nodes and sends his conflicting transaction, the nodes would reply with something like "rejected: code 123: conflicts with txid 0123...cdef". Bob could then reply with a a getdata('tx', '0123...cdef') to get the pinned transaction, parse out its preimage, and resolve the HTLC.
This approach isn't perfect (if it even makes sense at all---I could be misunderstanding the problem) because one of the problems that caused BIP61 to be disabled in Bitcoin Core was its unreliability, but I think if Bob had at least one honest peer that had the pinned transaction in its mempool and which implemented reject-with-conflicting-txid, Bob might be ok.
-Dave
Quoted text (1 line)
> In that case, would it be worth re-implementing something like a BIP61
reject message but with an extension that returns the txids of any conflicts?
That's an interesting idea, but an attacker can create a local conflict in your mempool and then send the preimage tx to make hit recentRejects until next tip so when the rejection code with conflict is received transaction isn't going to be fetched. Of course you can make an exception for this, but seems a DoS vector...
And also if you have a private full-node and connect only to 8 outbounds, an attacker can do a bit of tx-relay topology discovery and blind your tx-relay peers too...
I think p2p/mempool hardening measures will only make attack harder but not erase it, we should avoid tie too much the security model of Lightning on a given p2p topology. If you don't do manual peering (whitelist,addnode), this one may change without visibility (like stale tip).
Le mer. 22 avr. 2020 à 14:25, David A. Harding via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> a écrit :
Quoted text (36 lines)
> On Mon, Apr 20, 2020 at 10:43:14PM -0400, Matt Corallo via Lightning-dev
> wrote:
> > 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.
>
> IIUC, the main problem is honest Bob will broadcast a transaction
> without realizing it conflicts with a pinned transaction that's already
> in most node's mempools. If Bob knew about the pinned transaction and
> could get a copy of it, he'd be fine.
>
> In that case, would it be worth re-implementing something like a BIP61
> reject message but with an extension that returns the txids of any
> conflicts? For example, when Bob connects to a bunch of Bitcoin nodes
> and sends his conflicting transaction, the nodes would reply with
> something like "rejected: code 123: conflicts with txid 0123...cdef".
> Bob could then reply with a a getdata('tx', '0123...cdef') to get the
> pinned transaction, parse out its preimage, and resolve the HTLC.
>
> This approach isn't perfect (if it even makes sense at all---I could be
> misunderstanding the problem) because one of the problems that caused
> BIP61 to be disabled in Bitcoin Core was its unreliability, but I think
> if Bob had at least one honest peer that had the pinned transaction in
> its mempool and which implemented reject-with-conflicting-txid, Bob
> might be ok.
>
> -Dave
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>On Wed, Apr 22, 2020 at 03:03:29PM -0400, Antoine Riard wrote:
Quoted text (6 lines)
> > In that case, would it be worth re-implementing something like a BIP61 > reject message but with an extension that returns the txids of any > conflicts? > > That's an interesting idea, but an attacker can create a local conflict in > your mempool
You don't need a mempool to send a transaction. You can just open connections to random Bitcoin nodes directly and try sending your transaction. That's what a lite client is going to do anyway. If the pinned transaction is in the mempools of a significant number of Bitcoin nodes, then it should take just a few random connections to find one of those nodes, learn about the conflict, and download the pinned transaction.
If that's not acceptable, you could find some other way to poll a significant number of people with mempools, e.g. BIP35 mempool messages or reusing the payment hash in a bunch of 1 msat probes to LN nodes who opt-in to scanning their bitcoind's mempools for a corresponding preimage.
-Dave
Hmm, that's an interesting suggestion, it definitely raises the bar for attack execution rather significantly. Because lightning (and other second-layer systems) already relies heavily on uncensored access to blockchain data, its reasonable to extend the "if you don't have enough blocks, aggressively query various sources to find new blocks, or, really just do it always" solution to "also send relevant transactions while we're at it".
Sadly, unlike for block data, there is no consensus mechanism for nodes to ensure the transactions in their mempools are the same as others. Thus, if you focus on sending the pinning transaction to miner nodes directly (which isn't trivial, but also not nearly as hard as it sounds), you could still pull off the attack. However, to do it now, you'd need to wait for your counterparty to broadcast the corresponding timeout transaction (once it is confirmable, and can thus get into mempools), turning the whole thing into a mempool-acceptance race. Luckily there isn’t much cost to *trying*, though it’s less likely you’ll succeed.
There are also practical design issues - if you’re claiming multiple HTLC output in a single transaction the node would need to provide reject messages for each input which is conflicted, something which we’d need to think hard about the DoS implications of.
In any case, while it’s definitely better than nothing, it’s unclear if it’s really the kind of thing I’d want to rely on for my own funds.
Matt
Quoted text (31 lines)
> On 4/22/20 2:24 PM, David A. Harding wrote:
>> On Mon, Apr 20, 2020 at 10:43:14PM -0400, Matt Corallo via Lightning-dev wrote:
>> 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.
>
> IIUC, the main problem is honest Bob will broadcast a transaction
> without realizing it conflicts with a pinned transaction that's already
> in most node's mempools. If Bob knew about the pinned transaction and
> could get a copy of it, he'd be fine.
>
> In that case, would it be worth re-implementing something like a BIP61
> reject message but with an extension that returns the txids of any
> conflicts? For example, when Bob connects to a bunch of Bitcoin nodes
> and sends his conflicting transaction, the nodes would reply with
> something like "rejected: code 123: conflicts with txid 0123...cdef".
> Bob could then reply with a a getdata('tx', '0123...cdef') to get the
> pinned transaction, parse out its preimage, and resolve the HTLC.
>
> This approach isn't perfect (if it even makes sense at all---I could be
> misunderstanding the problem) because one of the problems that caused
> BIP61 to be disabled in Bitcoin Core was its unreliability, but I think
> if Bob had at least one honest peer that had the pinned transaction in
> its mempool and which implemented reject-with-conflicting-txid, Bob
> might be ok.
>
> -DaveHi Z,
Quoted text (3 lines)
> It seems to me that, if my cached understanding that `<0> > OP_CHECKSEQUENCEVERIFY` is sufficient to require RBF-flagging, then adding > that to the hashlock branch (2 witness bytes, 0.5 weight) would be a
pretty
Quoted text (1 line)
> low-weight mitigation against this attack.
I think this works...so they're forced to spend the output with a non-final sequence number, meaning it *must* signal RBF. In this case, now it's the timeout-er vs the success-er racing based on fee rate. If the honest party (the one trying to time out the HTLC) bids a fee rate higher (need to also account for the whole absolute fee replacement thing), then things should generally work out in their favor.
-- Laolu
On Tue, Apr 21, 2020 at 11:08 PM ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote:
Quoted text (211 lines)
> Good morning Laolu, Matt, and list,
>
>
> > > * 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.
>
> Right, right, that works as well.
>
> >
> > 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.
>
> Hmm.
>
> So basically:
>
> * B has no mempool, because it wants to reduce its costs and etc.
> * C broadcasts a non-RBF claim tx with low fee before A->B locktime (L+1).
> * B does not notice this tx because:
> 1. The tx is too low fee to be put in a block.
> 2. B has no mempool so it cannot see the tx being propagated over the
> P2P network.
> * B tries to broadcast higher-fee HTLC-timeout, but fails because it
> cannot replace a non-RBF tx.
> * After L+1, C contacts the miners off-band and offers fee payment by
> other means.
>
> It seems to me that, if my cached understanding that `<0>
> OP_CHECKSEQUENCEVERIFY` is sufficient to require RBF-flagging, then adding
> that to the hashlock branch (2 witness bytes, 0.5 weight) would be a pretty
> low-weight mitigation against this attack.
>
> So I think the combination below gives us good size:
>
> * The HTLC-Timeout signature from C is flagged with
> `OP_SINGLE|OP_ANYONECANPAY`.
> * Normally, the HTLC-Timeout still deducts the fee from the value of the
> UTXO being spent.
> * However, if B notices that the L+1 timeout is approaching, it can
> fee-bump HTLC-Timeout with some onchain funds, recreating its own signature
> but reusing the (still valid) C signature.
> * The hashlock branch in this case includes `<0> OP_CHECKSEQUENCEVERIFY`,
> preventing C from broadcasting a low-fee claim tx.
>
> This has the advantages:
>
> * B does not need a mempool still and can run in `blocksonly`.
> * The normal path is still the same as current behavior, we "only" add a
> new path where if the L+1 timeout is approaching we fee-bump the
> HTLC-Timeout.
> * Costs are pretty low:
> * No need for extra RBF carve-out txo.
> * Just two additional witness bytes in the hashlock branch.
> * No mempool rule changes needed, can be done with the P2P network of
> today.
> * Probably still resilient even with future changes in mempool rules, as
> long as typical RBF behaviors still remain.
>
> Is my understanding correct?
>
> Regards,
> ZmnSCPxj
>
> >
> > -- Laolu
> >
> > On Tue, Apr 21, 2020 at 9:13 PM ZmnSCPxj via bitcoin-dev <
> bitcoin-dev@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@lists•linuxfoundation•org
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>Hi z,
Actually, the current anchors proposal already does this, since it enforces a CSV of 1 block before the HTLCs can be spent (the block after confirmation). So I think we already do this, meaning the malicious node is already forced to use an RBF-replaceable transaction.
-- Laolu
On Wed, Apr 22, 2020 at 4:05 PM Olaoluwa Osuntokun <laolu32@gmail•com> wrote:
Quoted text (236 lines)
> Hi Z,
>
> > It seems to me that, if my cached understanding that `<0>
> > OP_CHECKSEQUENCEVERIFY` is sufficient to require RBF-flagging, then
> adding
> > that to the hashlock branch (2 witness bytes, 0.5 weight) would be a
> pretty
> > low-weight mitigation against this attack.
>
> I think this works...so they're forced to spend the output with a non-final
> sequence number, meaning it *must* signal RBF. In this case, now it's the
> timeout-er vs the success-er racing based on fee rate. If the honest party
> (the
> one trying to time out the HTLC) bids a fee rate higher (need to also
> account
> for the whole absolute fee replacement thing), then things should generally
> work out in their favor.
>
> -- Laolu
>
>
> On Tue, Apr 21, 2020 at 11:08 PM ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote:
>
>> Good morning Laolu, Matt, and list,
>>
>>
>> > > * 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.
>>
>> Right, right, that works as well.
>>
>> >
>> > 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.
>>
>> Hmm.
>>
>> So basically:
>>
>> * B has no mempool, because it wants to reduce its costs and etc.
>> * C broadcasts a non-RBF claim tx with low fee before A->B locktime (L+1).
>> * B does not notice this tx because:
>> 1. The tx is too low fee to be put in a block.
>> 2. B has no mempool so it cannot see the tx being propagated over the
>> P2P network.
>> * B tries to broadcast higher-fee HTLC-timeout, but fails because it
>> cannot replace a non-RBF tx.
>> * After L+1, C contacts the miners off-band and offers fee payment by
>> other means.
>>
>> It seems to me that, if my cached understanding that `<0>
>> OP_CHECKSEQUENCEVERIFY` is sufficient to require RBF-flagging, then adding
>> that to the hashlock branch (2 witness bytes, 0.5 weight) would be a pretty
>> low-weight mitigation against this attack.
>>
>> So I think the combination below gives us good size:
>>
>> * The HTLC-Timeout signature from C is flagged with
>> `OP_SINGLE|OP_ANYONECANPAY`.
>> * Normally, the HTLC-Timeout still deducts the fee from the value of
>> the UTXO being spent.
>> * However, if B notices that the L+1 timeout is approaching, it can
>> fee-bump HTLC-Timeout with some onchain funds, recreating its own signature
>> but reusing the (still valid) C signature.
>> * The hashlock branch in this case includes `<0> OP_CHECKSEQUENCEVERIFY`,
>> preventing C from broadcasting a low-fee claim tx.
>>
>> This has the advantages:
>>
>> * B does not need a mempool still and can run in `blocksonly`.
>> * The normal path is still the same as current behavior, we "only" add a
>> new path where if the L+1 timeout is approaching we fee-bump the
>> HTLC-Timeout.
>> * Costs are pretty low:
>> * No need for extra RBF carve-out txo.
>> * Just two additional witness bytes in the hashlock branch.
>> * No mempool rule changes needed, can be done with the P2P network of
>> today.
>> * Probably still resilient even with future changes in mempool rules,
>> as long as typical RBF behaviors still remain.
>>
>> Is my understanding correct?
>>
>> Regards,
>> ZmnSCPxj
>>
>> >
>> > -- Laolu
>> >
>> > On Tue, Apr 21, 2020 at 9:13 PM ZmnSCPxj via bitcoin-dev <
>> bitcoin-dev@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@lists•linuxfoundation•org
>> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>>Quoted text (3 lines)
> This seems like a somewhat unnecessary drive-by insult of a project you > don't contribute to, but feel free to start with a concrete suggestion > here :).
This wasn't intended as an insult at all. I'm simply saying if there's concern about worst case eviction/replacement, optimizations likely exist. Other developers that are interested in more complex multi-transaction contracts have realized this as well, and there're various open PRs that attempt to propose such optimizations [1].
Quoted text (4 lines)
> Hmm, maybe the proposal wasn't clear. The idea isn't to add signatures to > braodcasted transactions, but instead to CPFP a maybe-broadcasted > transaction by sending a transaction which spends it and seeing if it is > accepted
Sorry I still don't follow. By "we clearly need to go the other direction - all HTLC output spends need to be pre-signed.", you don't mean that the HTLC spends of the non-broadcaster also need to be an off-chain 2-of-2 multi-sig covenant? If the other party isn't restricted w.r.t _how_ they can spend the output (non-rbf'd, ect), then I don't see how that addresses anything.
Also see my mail elsewhere in the thread that the other party is actually forced to spend their HTLC output using an RBF-replaceable transaction. With that, I think we're all good here? In the end both sides have the ability to raise the fee rate of their spending transactions with the highest winning. As long as one of them confirms within the CLTV-delta, then everyone is made whole.
[1]: https://github.com/bitcoin/bitcoin/pull/18191
On Wed, Apr 22, 2020 at 9:50 AM Matt Corallo <lf-lists@mattcorallo•com> wrote:
Quoted text (158 lines)
> A few replies inline. > > On 4/22/20 12:13 AM, Olaoluwa Osuntokun wrote: > > Hi Matt, > > > > > >> While this is somewhat unintuitive, there are any number of good > anti-DoS > >> reasons for this, eg: > > > > None of these really strikes me as "good" reasons for this limitation, > which > > is at the root of this issue, and will also plague any more complex > Bitcoin > > contracts which rely on nested trees of transaction to confirm (CTV, > Duplex, > > channel factories, etc). Regarding the various (seemingly arbitrary) > package > > limits it's likely the case that any issues w.r.t computational > complexity > > that may arise when trying to calculate evictions can be ameliorated with > > better choice of internal data structures. > > > > In the end, the simplest heuristic (accept the higher fee rate package) > side > > steps all these issues and is also the most economically rationale from a > > miner's perspective. Why would one prefer a higher absolute fee package > > (which could be very large) over another package with a higher total _fee > > rate_? > > This seems like a somewhat unnecessary drive-by insult of a project you > don't contribute to, but feel free to start with > a concrete suggestion here :). > > >> You'll note that B would be just fine if they had a way to safely > monitor the > >> global mempool, and while this seems like a prudent mitigation for > >> lightning implementations to deploy today, it is itself a quagmire of > >> complexity > > > > Is it really all that complex? Assuming we're talking about just watching > > for a certain script template (the HTLC scipt) in the mempool to be able > to > > pull a pre-image as soon as possible. Early versions of lnd used the > mempool > > for commitment broadcast detection (which turned out to be a bad idea so > we > > removed it), but at a glance I don't see why watching the mempool is so > > complex. > > Because watching your own mempool is not guaranteed to work, and during > upgrade cycles that include changes to the > policy rules an attacker could exploit your upgraded/non-upgraded status > to perform the same attack. > > >> Further, this is a really obnoxious assumption to hoist onto lightning > >> nodes - having an active full node with an in-sync mempool is a lot more > >> CPU, bandwidth, and complexity than most lightning users were expecting > to > >> face. > > > > This would only be a requirement for Lightning nodes that seek to be a > part > > of the public routing network with a desire to _forward_ HTLCs. This > isn't > > doesn't affect laptops or mobile phones which likely mostly have private > > channels and don't participate in HTLC forwarding. I think it's pretty > > reasonable to expect a "proper" routing node on the network to be backed > by > > a full-node. The bandwidth concern is valid, but we'd need concrete > numbers > > that compare the bandwidth over head of mempool awareness (assuming the > > latest and greatest mempool syncing) compared with the overhead of the > > channel update gossip and gossip queries over head which LN nodes face > today > > as is to see how much worse off they really would be. > > If mempool-watching were practical, maybe, though there are a number of > folks who are talking about designing > partially-offline local lightning hubs which would be rendered impractical. > > > As detailed a bit below, if nodes watch the mempool, then this class of > > attack assuming the anchor output format as described in the open > > lightning-rfc PR is mitigated. At a glance, watching the mempool seems > like > > a far less involved process compared to modifying the state machine as > its > > defined today. By watching the mempool and implementing the changes in > > #lightning-rfc/688, then this issue can be mitigated _today_. lnd 0.10 > > doesn't yet watch the mempool (but does include anchors [1]), but unless > I'm > > missing something it should be pretty straight forward to add which mor > or less > > resolves this issue all together. > > > >> not fixing this issue seems to render the whole exercise somewhat > useless > > > > Depends on if one considers watching the mempool a fix. But even with > that a > > base version of anchors still resolves a number of issues including: > > eliminating the commitment fee guessing game, allowing users to pay less > on > > force close, being able to coalesce 2nd level HTLC transactions with the > > same CLTV expiry, and actually being able to reliably enforce multi-hop > HTLC > > resolution. > > > >> Instead of making the HTLC output spending more free-form with > >> SIGHASH_ANYONECAN_PAY|SIGHASH_SINGLE, we clearly need to go the other > >> direction - all HTLC output spends need to be pre-signed. > > > > I'm not sure this is actually immediately workable (need to think about > it > > more). To see why, remember that the commit_sig message includes HTLC > > signatures for the _remote_ party's commitment transaction, so they can > > spend the HTLCs if they broadcast their version of the commitment (force > > close). If we don't somehow also _gain_ signatures (our new HTLC > signatures) > > allowing us to spend HTLCs on _their_ version of the commitment, then if > > they broadcast that commitment (without revoking), then we're unable to > > redeem any of those HTLCs at all, possibly losing money. > > Hmm, maybe the proposal wasn't clear. The idea isn't to add signatures to > braodcasted transactions, but instead to CPFP > a maybe-broadcasted transaction by sending a transaction which spends it > and seeing if it is accepted. You only need to > know the transaction's exact format (ie txid, which we do, since we sent a > signature for it long ago) to do this, you > don't have to actually *have* the fully-signed transaction (and you don't). > > > In an attempt to counteract this, we might say ok, the revoke message > also > > now includes HTLC signatures for their new commitment allowing us to > spend > > our HTLCs. This resolves things in a weaker security model, but doesn't > > address the issue generally, as after they receive the commit_sig, they > can > > broadcast immediately, again leaving us without a way to redeem our > HTLCs. > > > > I'd need to think about it more, but it seems that following this path > would > > require an overhaul in the channel state machine to make presenting a new > > commitment actually take at least _two phases_ (at least a full round > trip). > > The first phase would tender the commitment, but render them unable to > > broadcast it. The second phase would then <insert something something > > scriptless scripts here> enter a new sub-protocol which upon conclusion, > > gives the commitment proposer valid HTLC signatures, and gives the > responder > > what they need to be able to broadcast their commitment and claim their > > HTCLs in an atomic manner. > > > > -- Laolu > > > > [1]: https://github.com/lightningnetwork/lnd/pull/3821 >
Quoted text (12 lines)
> On Apr 22, 2020, at 16:13, Olaoluwa Osuntokun <laolu32@gmail•com> wrote: > > > Hmm, maybe the proposal wasn't clear. The idea isn't to add signatures to > > braodcasted transactions, but instead to CPFP a maybe-broadcasted > > transaction by sending a transaction which spends it and seeing if it is > > accepted > > Sorry I still don't follow. By "we clearly need to go the other direction - > all HTLC output spends need to be pre-signed.", you don't mean that the HTLC > spends of the non-broadcaster also need to be an off-chain 2-of-2 multi-sig > covenant? If the other party isn't restricted w.r.t _how_ they can spend the > output (non-rbf'd, ect), then I don't see how that addresses anything.
Indeed, that is what I’m suggesting. Anchor output and all. One thing we could think about is only turning it on over a certain threshold, and having a separate “only-kinda-enforceable-on-chain-HTLC-in-flight” limit.
Quoted text (6 lines)
> Also see my mail elsewhere in the thread that the other party is actually > forced to spend their HTLC output using an RBF-replaceable transaction. With > that, I think we're all good here? In the end both sides have the ability to > raise the fee rate of their spending transactions with the highest winning. > As long as one of them confirms within the CLTV-delta, then everyone is > made whole.
It does seem like my cached recollection of RBF opt-in was incorrect but please re-read the intro email. There are a bunch of ways of doing pinning - just opting into RBF isn’t even close to enough.
Quoted text (120 lines)
> [1]: https://github.com/bitcoin/bitcoin/pull/18191 > > >> On Wed, Apr 22, 2020 at 9:50 AM Matt Corallo <lf-lists@mattcorallo•com> wrote: >> A few replies inline. >> >> On 4/22/20 12:13 AM, Olaoluwa Osuntokun wrote: >> > Hi Matt, >> > >> > >> >> While this is somewhat unintuitive, there are any number of good anti-DoS >> >> reasons for this, eg: >> > >> > None of these really strikes me as "good" reasons for this limitation, which >> > is at the root of this issue, and will also plague any more complex Bitcoin >> > contracts which rely on nested trees of transaction to confirm (CTV, Duplex, >> > channel factories, etc). Regarding the various (seemingly arbitrary) package >> > limits it's likely the case that any issues w.r.t computational complexity >> > that may arise when trying to calculate evictions can be ameliorated with >> > better choice of internal data structures. >> > >> > In the end, the simplest heuristic (accept the higher fee rate package) side >> > steps all these issues and is also the most economically rationale from a >> > miner's perspective. Why would one prefer a higher absolute fee package >> > (which could be very large) over another package with a higher total _fee >> > rate_? >> >> This seems like a somewhat unnecessary drive-by insult of a project you don't contribute to, but feel free to start with >> a concrete suggestion here :). >> >> >> You'll note that B would be just fine if they had a way to safely monitor the >> >> global mempool, and while this seems like a prudent mitigation for >> >> lightning implementations to deploy today, it is itself a quagmire of >> >> complexity >> > >> > Is it really all that complex? Assuming we're talking about just watching >> > for a certain script template (the HTLC scipt) in the mempool to be able to >> > pull a pre-image as soon as possible. Early versions of lnd used the mempool >> > for commitment broadcast detection (which turned out to be a bad idea so we >> > removed it), but at a glance I don't see why watching the mempool is so >> > complex. >> >> Because watching your own mempool is not guaranteed to work, and during upgrade cycles that include changes to the >> policy rules an attacker could exploit your upgraded/non-upgraded status to perform the same attack. >> >> >> Further, this is a really obnoxious assumption to hoist onto lightning >> >> nodes - having an active full node with an in-sync mempool is a lot more >> >> CPU, bandwidth, and complexity than most lightning users were expecting to >> >> face. >> > >> > This would only be a requirement for Lightning nodes that seek to be a part >> > of the public routing network with a desire to _forward_ HTLCs. This isn't >> > doesn't affect laptops or mobile phones which likely mostly have private >> > channels and don't participate in HTLC forwarding. I think it's pretty >> > reasonable to expect a "proper" routing node on the network to be backed by >> > a full-node. The bandwidth concern is valid, but we'd need concrete numbers >> > that compare the bandwidth over head of mempool awareness (assuming the >> > latest and greatest mempool syncing) compared with the overhead of the >> > channel update gossip and gossip queries over head which LN nodes face today >> > as is to see how much worse off they really would be. >> >> If mempool-watching were practical, maybe, though there are a number of folks who are talking about designing >> partially-offline local lightning hubs which would be rendered impractical. >> >> > As detailed a bit below, if nodes watch the mempool, then this class of >> > attack assuming the anchor output format as described in the open >> > lightning-rfc PR is mitigated. At a glance, watching the mempool seems like >> > a far less involved process compared to modifying the state machine as its >> > defined today. By watching the mempool and implementing the changes in >> > #lightning-rfc/688, then this issue can be mitigated _today_. lnd 0.10 >> > doesn't yet watch the mempool (but does include anchors [1]), but unless I'm >> > missing something it should be pretty straight forward to add which mor or less >> > resolves this issue all together. >> > >> >> not fixing this issue seems to render the whole exercise somewhat useless >> > >> > Depends on if one considers watching the mempool a fix. But even with that a >> > base version of anchors still resolves a number of issues including: >> > eliminating the commitment fee guessing game, allowing users to pay less on >> > force close, being able to coalesce 2nd level HTLC transactions with the >> > same CLTV expiry, and actually being able to reliably enforce multi-hop HTLC >> > resolution. >> > >> >> Instead of making the HTLC output spending more free-form with >> >> SIGHASH_ANYONECAN_PAY|SIGHASH_SINGLE, we clearly need to go the other >> >> direction - all HTLC output spends need to be pre-signed. >> > >> > I'm not sure this is actually immediately workable (need to think about it >> > more). To see why, remember that the commit_sig message includes HTLC >> > signatures for the _remote_ party's commitment transaction, so they can >> > spend the HTLCs if they broadcast their version of the commitment (force >> > close). If we don't somehow also _gain_ signatures (our new HTLC signatures) >> > allowing us to spend HTLCs on _their_ version of the commitment, then if >> > they broadcast that commitment (without revoking), then we're unable to >> > redeem any of those HTLCs at all, possibly losing money. >> >> Hmm, maybe the proposal wasn't clear. The idea isn't to add signatures to braodcasted transactions, but instead to CPFP >> a maybe-broadcasted transaction by sending a transaction which spends it and seeing if it is accepted. You only need to >> know the transaction's exact format (ie txid, which we do, since we sent a signature for it long ago) to do this, you >> don't have to actually *have* the fully-signed transaction (and you don't). >> >> > In an attempt to counteract this, we might say ok, the revoke message also >> > now includes HTLC signatures for their new commitment allowing us to spend >> > our HTLCs. This resolves things in a weaker security model, but doesn't >> > address the issue generally, as after they receive the commit_sig, they can >> > broadcast immediately, again leaving us without a way to redeem our HTLCs. >> > >> > I'd need to think about it more, but it seems that following this path would >> > require an overhaul in the channel state machine to make presenting a new >> > commitment actually take at least _two phases_ (at least a full round trip). >> > The first phase would tender the commitment, but render them unable to >> > broadcast it. The second phase would then <insert something something >> > scriptless scripts here> enter a new sub-protocol which upon conclusion, >> > gives the commitment proposer valid HTLC signatures, and gives the responder >> > what they need to be able to broadcast their commitment and claim their >> > HTCLs in an atomic manner. >> > >> > -- Laolu >> > >> > [1]: https://github.com/lightningnetwork/lnd/pull/3821
Quoted text (1 line)
> Indeed, that is what I’m suggesting
Gotcha, if this is indeed what you're suggesting (all HTLC spends are now 2-of-2 multi-sig), then I think the modifications to the state machine I sketched out in an earlier email are required. An exact construction which achieves the requirements of "you can't broadcast until you have a secret which I can obtain from the htlc sig for your commitment transaction, and my secret is revealed with another swap", appears to be an open problem, atm.
Even if they're restricted in this fashion (must be a 1-in-1 out, sighashall, fees are pre agreed upon), they can still spend that with a CPFP (while still unconfirmed in the mempool) and create another heavy tree, which puts us right back at the same bidding war scenario?
Quoted text (2 lines)
> There are a bunch of ways of doing pinning - just opting into RBF isn’t > even close to enough.
Mhmm, there're other ways of doing pinning. But with anchors as is defined in that spec PR, they're forced to spend with an RBF-replaceable transaction, which means the party wishing to time things out can enter into a bidding war. If the party trying to impeded things participates in this progressive absolute fee increase, it's likely that the war terminates with _one_ of them getting into the block, which seems to resolve everything?
-- Laolu
On Wed, Apr 22, 2020 at 4:20 PM Matt Corallo <lf-lists@mattcorallo•com> wrote:
Quoted text (210 lines)
> > > On Apr 22, 2020, at 16:13, Olaoluwa Osuntokun <laolu32@gmail•com> wrote: > > > > Hmm, maybe the proposal wasn't clear. The idea isn't to add signatures to > > braodcasted transactions, but instead to CPFP a maybe-broadcasted > > transaction by sending a transaction which spends it and seeing if it is > > accepted > > Sorry I still don't follow. By "we clearly need to go the other direction - > all HTLC output spends need to be pre-signed.", you don't mean that the > HTLC > spends of the non-broadcaster also need to be an off-chain 2-of-2 multi-sig > covenant? If the other party isn't restricted w.r.t _how_ they can spend > the > output (non-rbf'd, ect), then I don't see how that addresses anything. > > > Indeed, that is what I’m suggesting. Anchor output and all. One thing we > could think about is only turning it on over a certain threshold, and > having a separate “only-kinda-enforceable-on-chain-HTLC-in-flight” limit. > > Also see my mail elsewhere in the thread that the other party is actually > forced to spend their HTLC output using an RBF-replaceable transaction. > With > that, I think we're all good here? In the end both sides have the ability > to > raise the fee rate of their spending transactions with the highest winning. > As long as one of them confirms within the CLTV-delta, then everyone is > made whole. > > > It does seem like my cached recollection of RBF opt-in was incorrect but > please re-read the intro email. There are a bunch of ways of doing pinning > - just opting into RBF isn’t even close to enough. > > [1]: https://github.com/bitcoin/bitcoin/pull/18191 > > > On Wed, Apr 22, 2020 at 9:50 AM Matt Corallo <lf-lists@mattcorallo•com> > wrote: > >> A few replies inline. >> >> On 4/22/20 12:13 AM, Olaoluwa Osuntokun wrote: >> > Hi Matt, >> > >> > >> >> While this is somewhat unintuitive, there are any number of good >> anti-DoS >> >> reasons for this, eg: >> > >> > None of these really strikes me as "good" reasons for this limitation, >> which >> > is at the root of this issue, and will also plague any more complex >> Bitcoin >> > contracts which rely on nested trees of transaction to confirm (CTV, >> Duplex, >> > channel factories, etc). Regarding the various (seemingly arbitrary) >> package >> > limits it's likely the case that any issues w.r.t computational >> complexity >> > that may arise when trying to calculate evictions can be ameliorated >> with >> > better choice of internal data structures. >> > >> > In the end, the simplest heuristic (accept the higher fee rate package) >> side >> > steps all these issues and is also the most economically rationale from >> a >> > miner's perspective. Why would one prefer a higher absolute fee package >> > (which could be very large) over another package with a higher total >> _fee >> > rate_? >> >> This seems like a somewhat unnecessary drive-by insult of a project you >> don't contribute to, but feel free to start with >> a concrete suggestion here :). >> >> >> You'll note that B would be just fine if they had a way to safely >> monitor the >> >> global mempool, and while this seems like a prudent mitigation for >> >> lightning implementations to deploy today, it is itself a quagmire of >> >> complexity >> > >> > Is it really all that complex? Assuming we're talking about just >> watching >> > for a certain script template (the HTLC scipt) in the mempool to be >> able to >> > pull a pre-image as soon as possible. Early versions of lnd used the >> mempool >> > for commitment broadcast detection (which turned out to be a bad idea >> so we >> > removed it), but at a glance I don't see why watching the mempool is so >> > complex. >> >> Because watching your own mempool is not guaranteed to work, and during >> upgrade cycles that include changes to the >> policy rules an attacker could exploit your upgraded/non-upgraded status >> to perform the same attack. >> >> >> Further, this is a really obnoxious assumption to hoist onto lightning >> >> nodes - having an active full node with an in-sync mempool is a lot >> more >> >> CPU, bandwidth, and complexity than most lightning users were >> expecting to >> >> face. >> > >> > This would only be a requirement for Lightning nodes that seek to be a >> part >> > of the public routing network with a desire to _forward_ HTLCs. This >> isn't >> > doesn't affect laptops or mobile phones which likely mostly have private >> > channels and don't participate in HTLC forwarding. I think it's pretty >> > reasonable to expect a "proper" routing node on the network to be >> backed by >> > a full-node. The bandwidth concern is valid, but we'd need concrete >> numbers >> > that compare the bandwidth over head of mempool awareness (assuming the >> > latest and greatest mempool syncing) compared with the overhead of the >> > channel update gossip and gossip queries over head which LN nodes face >> today >> > as is to see how much worse off they really would be. >> >> If mempool-watching were practical, maybe, though there are a number of >> folks who are talking about designing >> partially-offline local lightning hubs which would be rendered >> impractical. >> >> > As detailed a bit below, if nodes watch the mempool, then this class of >> > attack assuming the anchor output format as described in the open >> > lightning-rfc PR is mitigated. At a glance, watching the mempool seems >> like >> > a far less involved process compared to modifying the state machine as >> its >> > defined today. By watching the mempool and implementing the changes in >> > #lightning-rfc/688, then this issue can be mitigated _today_. lnd 0.10 >> > doesn't yet watch the mempool (but does include anchors [1]), but >> unless I'm >> > missing something it should be pretty straight forward to add which mor >> or less >> > resolves this issue all together. >> > >> >> not fixing this issue seems to render the whole exercise somewhat >> useless >> > >> > Depends on if one considers watching the mempool a fix. But even with >> that a >> > base version of anchors still resolves a number of issues including: >> > eliminating the commitment fee guessing game, allowing users to pay >> less on >> > force close, being able to coalesce 2nd level HTLC transactions with the >> > same CLTV expiry, and actually being able to reliably enforce multi-hop >> HTLC >> > resolution. >> > >> >> Instead of making the HTLC output spending more free-form with >> >> SIGHASH_ANYONECAN_PAY|SIGHASH_SINGLE, we clearly need to go the other >> >> direction - all HTLC output spends need to be pre-signed. >> > >> > I'm not sure this is actually immediately workable (need to think about >> it >> > more). To see why, remember that the commit_sig message includes HTLC >> > signatures for the _remote_ party's commitment transaction, so they can >> > spend the HTLCs if they broadcast their version of the commitment (force >> > close). If we don't somehow also _gain_ signatures (our new HTLC >> signatures) >> > allowing us to spend HTLCs on _their_ version of the commitment, then if >> > they broadcast that commitment (without revoking), then we're unable to >> > redeem any of those HTLCs at all, possibly losing money. >> >> Hmm, maybe the proposal wasn't clear. The idea isn't to add signatures to >> braodcasted transactions, but instead to CPFP >> a maybe-broadcasted transaction by sending a transaction which spends it >> and seeing if it is accepted. You only need to >> know the transaction's exact format (ie txid, which we do, since we sent >> a signature for it long ago) to do this, you >> don't have to actually *have* the fully-signed transaction (and you >> don't). >> >> > In an attempt to counteract this, we might say ok, the revoke message >> also >> > now includes HTLC signatures for their new commitment allowing us to >> spend >> > our HTLCs. This resolves things in a weaker security model, but doesn't >> > address the issue generally, as after they receive the commit_sig, they >> can >> > broadcast immediately, again leaving us without a way to redeem our >> HTLCs. >> > >> > I'd need to think about it more, but it seems that following this path >> would >> > require an overhaul in the channel state machine to make presenting a >> new >> > commitment actually take at least _two phases_ (at least a full round >> trip). >> > The first phase would tender the commitment, but render them unable to >> > broadcast it. The second phase would then <insert something something >> > scriptless scripts here> enter a new sub-protocol which upon conclusion, >> > gives the commitment proposer valid HTLC signatures, and gives the >> responder >> > what they need to be able to broadcast their commitment and claim their >> > HTCLs in an atomic manner. >> > >> > -- Laolu >> > >> > [1]: https://github.com/lightningnetwork/lnd/pull/3821 >> >
On 4/22/20 7:27 PM, Olaoluwa Osuntokun wrote:
Quoted text (9 lines)
> >> Indeed, that is what I’m suggesting > > Gotcha, if this is indeed what you're suggesting (all HTLC spends are now > 2-of-2 multi-sig), then I think the modifications to the state machine I > sketched out in an earlier email are required. An exact construction which > achieves the requirements of "you can't broadcast until you have a secret > which I can obtain from the htlc sig for your commitment transaction, and my > secret is revealed with another swap", appears to be an open problem, atm.
Hmm, indeed, it does seem to require a change to the state machine, but I don't think a very interesting one. Because B providing A an HTLC signature spending a commitment transaction B will broadcast does not allow A to actually broadcast said HTLC transaction, B can be rather liberal with it. Indeed, however, it would require that B provide such a signature before A can send the commitment_signed that exists today.
Quoted text (4 lines)
> Even if they're restricted in this fashion (must be a 1-in-1 out, > sighashall, fees are pre agreed upon), they can still spend that with a CPFP > (while still unconfirmed in the mempool) and create another heavy tree, > which puts us right back at the same bidding war scenario?
Right, you'd have to use anchor outputs just like we do on the commitment transaction :).
Quoted text (10 lines)
>> There are a bunch of ways of doing pinning - just opting into RBF isn’t >> even close to enough. > > Mhmm, there're other ways of doing pinning. But with anchors as is defined > in that spec PR, they're forced to spend with an RBF-replaceable > transaction, which means the party wishing to time things out can enter into > a bidding war. If the party trying to impeded things participates in this > progressive absolute fee increase, it's likely that the war terminates > with _one_ of them getting into the block, which seems to resolve > everything?
No? Even if we assume there are no tricks that you can play with, eg, the package limits duri eviction, which I'd be surprised about, the "absolute fee/feerate" thing still screws you. The attacker here gets to hold something at the bottom of the mempool and the poor honest party is going to have to pay an absurd (likely more than the HTLC value) fee just to get it unstuck, whereas the attacker never would have had to pay said fee.
Quoted text (159 lines)
> -- Laolung > > > On Wed, Apr 22, 2020 at 4:20 PM Matt Corallo <lf-lists@mattcorallo•com <mailto:lf-lists@mattcorallo.com>> wrote: > > > >> On Apr 22, 2020, at 16:13, Olaoluwa Osuntokun <laolu32@gmail•com <mailto:laolu32@gmail.com>> wrote: >> >> > Hmm, maybe the proposal wasn't clear. The idea isn't to add signatures to >> > braodcasted transactions, but instead to CPFP a maybe-broadcasted >> > transaction by sending a transaction which spends it and seeing if it is >> > accepted >> >> Sorry I still don't follow. By "we clearly need to go the other direction - >> all HTLC output spends need to be pre-signed.", you don't mean that the HTLC >> spends of the non-broadcaster also need to be an off-chain 2-of-2 multi-sig >> covenant? If the other party isn't restricted w.r.t _how_ they can spend the >> output (non-rbf'd, ect), then I don't see how that addresses anything. > > Indeed, that is what I’m suggesting. Anchor output and all. One thing we could think about is only turning it on > over a certain threshold, and having a separate “only-kinda-enforceable-on-chain-HTLC-in-flight” limit. > >> Also see my mail elsewhere in the thread that the other party is actually >> forced to spend their HTLC output using an RBF-replaceable transaction. With >> that, I think we're all good here? In the end both sides have the ability to >> raise the fee rate of their spending transactions with the highest winning. >> As long as one of them confirms within the CLTV-delta, then everyone is >> made whole. > > It does seem like my cached recollection of RBF opt-in was incorrect but please re-read the intro email. There are a > bunch of ways of doing pinning - just opting into RBF isn’t even close to enough. > >> [1]: https://github.com/bitcoin/bitcoin/pull/18191 >> >> >> On Wed, Apr 22, 2020 at 9:50 AM Matt Corallo <lf-lists@mattcorallo•com <mailto:lf-lists@mattcorallo.com>> wrote: >> >> A few replies inline. >> >> On 4/22/20 12:13 AM, Olaoluwa Osuntokun wrote: >> > Hi Matt, >> > >> > >> >> While this is somewhat unintuitive, there are any number of good anti-DoS >> >> reasons for this, eg: >> > >> > None of these really strikes me as "good" reasons for this limitation, which >> > is at the root of this issue, and will also plague any more complex Bitcoin >> > contracts which rely on nested trees of transaction to confirm (CTV, Duplex, >> > channel factories, etc). Regarding the various (seemingly arbitrary) package >> > limits it's likely the case that any issues w.r.t computational complexity >> > that may arise when trying to calculate evictions can be ameliorated with >> > better choice of internal data structures. >> > >> > In the end, the simplest heuristic (accept the higher fee rate package) side >> > steps all these issues and is also the most economically rationale from a >> > miner's perspective. Why would one prefer a higher absolute fee package >> > (which could be very large) over another package with a higher total _fee >> > rate_? >> >> This seems like a somewhat unnecessary drive-by insult of a project you don't contribute to, but feel free to >> start with >> a concrete suggestion here :). >> >> >> You'll note that B would be just fine if they had a way to safely monitor the >> >> global mempool, and while this seems like a prudent mitigation for >> >> lightning implementations to deploy today, it is itself a quagmire of >> >> complexity >> > >> > Is it really all that complex? Assuming we're talking about just watching >> > for a certain script template (the HTLC scipt) in the mempool to be able to >> > pull a pre-image as soon as possible. Early versions of lnd used the mempool >> > for commitment broadcast detection (which turned out to be a bad idea so we >> > removed it), but at a glance I don't see why watching the mempool is so >> > complex. >> >> Because watching your own mempool is not guaranteed to work, and during upgrade cycles that include changes to the >> policy rules an attacker could exploit your upgraded/non-upgraded status to perform the same attack. >> >> >> Further, this is a really obnoxious assumption to hoist onto lightning >> >> nodes - having an active full node with an in-sync mempool is a lot more >> >> CPU, bandwidth, and complexity than most lightning users were expecting to >> >> face. >> > >> > This would only be a requirement for Lightning nodes that seek to be a part >> > of the public routing network with a desire to _forward_ HTLCs. This isn't >> > doesn't affect laptops or mobile phones which likely mostly have private >> > channels and don't participate in HTLC forwarding. I think it's pretty >> > reasonable to expect a "proper" routing node on the network to be backed by >> > a full-node. The bandwidth concern is valid, but we'd need concrete numbers >> > that compare the bandwidth over head of mempool awareness (assuming the >> > latest and greatest mempool syncing) compared with the overhead of the >> > channel update gossip and gossip queries over head which LN nodes face today >> > as is to see how much worse off they really would be. >> >> If mempool-watching were practical, maybe, though there are a number of folks who are talking about designing >> partially-offline local lightning hubs which would be rendered impractical. >> >> > As detailed a bit below, if nodes watch the mempool, then this class of >> > attack assuming the anchor output format as described in the open >> > lightning-rfc PR is mitigated. At a glance, watching the mempool seems like >> > a far less involved process compared to modifying the state machine as its >> > defined today. By watching the mempool and implementing the changes in >> > #lightning-rfc/688, then this issue can be mitigated _today_. lnd 0.10 >> > doesn't yet watch the mempool (but does include anchors [1]), but unless I'm >> > missing something it should be pretty straight forward to add which mor or less >> > resolves this issue all together. >> > >> >> not fixing this issue seems to render the whole exercise somewhat useless >> > >> > Depends on if one considers watching the mempool a fix. But even with that a >> > base version of anchors still resolves a number of issues including: >> > eliminating the commitment fee guessing game, allowing users to pay less on >> > force close, being able to coalesce 2nd level HTLC transactions with the >> > same CLTV expiry, and actually being able to reliably enforce multi-hop HTLC >> > resolution. >> > >> >> Instead of making the HTLC output spending more free-form with >> >> SIGHASH_ANYONECAN_PAY|SIGHASH_SINGLE, we clearly need to go the other >> >> direction - all HTLC output spends need to be pre-signed. >> > >> > I'm not sure this is actually immediately workable (need to think about it >> > more). To see why, remember that the commit_sig message includes HTLC >> > signatures for the _remote_ party's commitment transaction, so they can >> > spend the HTLCs if they broadcast their version of the commitment (force >> > close). If we don't somehow also _gain_ signatures (our new HTLC signatures) >> > allowing us to spend HTLCs on _their_ version of the commitment, then if >> > they broadcast that commitment (without revoking), then we're unable to >> > redeem any of those HTLCs at all, possibly losing money. >> >> Hmm, maybe the proposal wasn't clear. The idea isn't to add signatures to braodcasted transactions, but >> instead to CPFP >> a maybe-broadcasted transaction by sending a transaction which spends it and seeing if it is accepted. You >> only need to >> know the transaction's exact format (ie txid, which we do, since we sent a signature for it long ago) to do >> this, you >> don't have to actually *have* the fully-signed transaction (and you don't). >> >> > In an attempt to counteract this, we might say ok, the revoke message also >> > now includes HTLC signatures for their new commitment allowing us to spend >> > our HTLCs. This resolves things in a weaker security model, but doesn't >> > address the issue generally, as after they receive the commit_sig, they can >> > broadcast immediately, again leaving us without a way to redeem our HTLCs. >> > >> > I'd need to think about it more, but it seems that following this path would >> > require an overhaul in the channel state machine to make presenting a new >> > commitment actually take at least _two phases_ (at least a full round trip). >> > The first phase would tender the commitment, but render them unable to >> > broadcast it. The second phase would then <insert something something >> > scriptless scripts here> enter a new sub-protocol which upon conclusion, >> > gives the commitment proposer valid HTLC signatures, and gives the responder >> > what they need to be able to broadcast their commitment and claim their >> > HTCLs in an atomic manner. >> > >> > -- Laolu >> > >> > [1]: https://github.com/lightningnetwork/lnd/pull/3821 >>
Hi everyone,
Sorry to just be getting to a response here. Hadn't noticed it till now.
*(Plug: If anyone or their organizations would like to assist in funding the work described below for a group of developers, I've been working to put resources together for funding the above for a few months now, and I think it would be high leverage towards seeing this through. There are a lot of unsexy tasks to do that aren't coming up with a solution (e.g.,writing a myriad of Mempool stress test scenarios) that can be a well defined full-time job for someone to do.)*
I've been working on exactly this problem in the mempool for months now. I'm deeply familiar with the issues here and the types of pinning possible. I think everyone can recognize that with my work on OP_CTV I want nothing more than the mempool to be able to accept whatever long chains we can throw at it, but I'm pretty well steeped at this point in the obstacles to doing that.
I don't think that we should be entertaining further carve outs at the moment, unless it is really trivial. Every new carve out rule added to the way that the mempool operates is removing complexity invariants we aim to preserve in the mempool in order to keep nodes operational. Many of these invariants are well documented, some are not. I'm happy to go off list for a more thorough discussion with anyone qualified to have it; this isn't the best venue for that discussion.
From my point of view the path forward here is to dedicate more development resources towards finishing the mempool project I began. You can see the outstanding work here: https://github.com/bitcoin/bitcoin/projects/14, contributing review towards moving those PRs forward will greatly improve our ability to consider a stopgap carve out measure.
The current focus of this work is primarily on:
1) Testing Construction to better test & catch regressions or vulnerabilities introduced or extant in mempool 2) Refactoring algorithms in mempool to reduce constant factors & asymptotics 3) Package Relay
None of these fix the exact problem at hand though, but here's part of how they can help us:
If we finish up the algorithmic refactors I've been working on it seems plausible to do a one-off increase of descendants limits to say, 100 descendants with no restriction. However, we could use the opportunity to use the 75 descendant increase exclusively for a new carve out, and apply some new stricter rules in that extra space. There are a few anti-pinning countermeasures that you can apply in that space that you would not generally want in the mempool. An example of one is that any new transaction must pay more feerate and absolute fee than every child in that space. Or that only the highest fee paying branch of the excess transactions are mineable, no others. Another would be disabling RBF past that watermark. In all likelihood, different subsystems interacting with the mempool will require a different set of restrictions each with the current architecture, I don't think there's a magic bullet.
Package relay is a promising approach for a future pinning solution as there are opportunities to attach to packages compact proofs of improved fee efficiency for pinned transactions. But the ground work for package relay needs to come first. This is theoretically possible with our current architecture of the mempool and can probably address much of the pinning concerns by replacing pinning with more rational eviction policies.
Longer term I've been working on plans and designs to completely re-do the mempool's architecture to make it behave for arbitrary cases. It's possible to one day lift all preemptively enforced (e.g., before acceptance) descendants limits, which can solve this problem for good. There is more than one potentially good solution here, and a conjunction of them can be used as they affect independent sub systems. But this work will probably take years to complete to the point where restrictions can realistically be lifted.
If developers would like to coordinate resources around completing this work and making more regular progress on it I'm happy to help point people to specific tasks that need to be done in order to accelerate this and help serialize the work so that we can not get into rebase hell.
Originally I had the plug at the top as a closing note, but I figured people might miss it.
Best,
Jeremy
Good morning lists et al,
Let me try to summarize things a little:
* Suppose we have a forwarding payment A->B->C.
* Suppose B does not want to maintain a mempool and is running in `blocksonly` mode to reduce operational costs.
* C triggers B somehow dropping the B<->C channel, such as by sending an `error` message, which will usually cause the other side to drop the channel onchain using its commitment transaction.
* The dropped B<->C channel has an HTLC (that was set up during the A->B->C forwarding).
* The HTLC, being used in a Poon-Dryja channel, actually has the following contract text:
* The fund may be claimed by either of these clauses:
* C can claim, if C shows the preimage of some hash H (hashlock branch).
* B and C must agree, and claim after time L (timelock branch).
* B holds a signature from C that can claim the timelock branch of the HTLC, for a transaction that spends to an output with an `OP_CHECKSEQUENCEVERIFY`.
* The signature is `SIGHASH_ALL`, so the transaction has a fixed feerate.
* C can "pin" the HTLC output by spending using the hashlock branch, and creating a large fee, low fee-rate (tree of) transactions.
* As it is a low fee-rate, miners have no incentive to put this in a block, especially if unrelated higher-fee-rate transactions exist that would earn them more money.
* Even in a full RBF universe, because of the anti-DoS mempool rules, B cannot evict this pinned transaction by just bidding up the feerate.
* A replacing transaction cannot evict alternatives unless its absolute fee is greater than the absolute fee of the alternative.
* The pinning transaction has a high fee, but is blockspace-wasteful, so it is:
* Undesirable to mine (low feerate).
* Difficult to evict (high fee).
* Thus, B is unable to get its timelock-branch transaction in the mempools of miners.
* C waits until the A->B HTLC times out, then:
* C directly contacts miners with an out-of-band proposal to replace its transaction with an alternative that is much smaller and has a low fee, but much better feerate.
* Miners, being economically rational, accept this proposal and include this in a block.
The proposal by Matt is then:
* The hashlock branch should instead be:
* B and C must agree, and show the preimage of some hash H (hashlock branch).
* Then B and C agree that B provides a signature spending the hashlock branch, to a transaction with the outputs:
* Normal payment to C.
* Hook output to B, which B can use to CPFP this transaction.
* Hook output to C, which C can use to CPFP this transaction.
* B can still (somehow) not maintain a mempool, by:
* B broadcasts its timelock transaction.
* B tries to CPFP the above hashlock transaction.
* If CPFP succeeds, it means the above hashlock transaction exists and B queries the peer for this transaction, extracting the preimage and claiming the A->B HTLC.
Is that a fair summary?
Great summary, a few notes inline.
Quoted text (8 lines)
> On Apr 22, 2020, at 21:50, ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote: > > Good morning lists et al, > > Let me try to summarize things a little: > > * Suppose we have a forwarding payment A->B->C. > * Suppose B does not want to maintain a mempool and is running in `blocksonly` mode to reduce operational costs.
Quick point of clarification, due to the mempool lacking a consensus system (that’s the whole point, after all :p), there are several reasons to that just running a full node/having a mempool isn’t sufficient.
Quoted text (9 lines)
> * C triggers B somehow dropping the B<->C channel, such as by sending an `error` message, which will usually cause the other side to drop the channel onchain using its commitment transaction. > * The dropped B<->C channel has an HTLC (that was set up during the A->B->C forwarding). > * The HTLC, being used in a Poon-Dryja channel, actually has the following contract text: > * The fund may be claimed by either of these clauses: > * C can claim, if C shows the preimage of some hash H (hashlock branch). > * B and C must agree, and claim after time L (timelock branch). > * B holds a signature from C that can claim the timelock branch of the HTLC, for a transaction that spends to an output with an `OP_CHECKSEQUENCEVERIFY`. > * The signature is `SIGHASH_ALL`, so the transaction has a fixed feerate. > * C can "pin" the HTLC output by spending using the hashlock branch, and creating a large fee, low fee-rate (tree of) transactions.
Another: this is the simplest example. There are also games around the package size limits if I recall correctly.
Quoted text (9 lines)
> * As it is a low fee-rate, miners have no incentive to put this in a block, especially if unrelated higher-fee-rate transactions exist that would earn them more money. > * Even in a full RBF universe, because of the anti-DoS mempool rules, B cannot evict this pinned transaction by just bidding up the feerate. > * A replacing transaction cannot evict alternatives unless its absolute fee is greater than the absolute fee of the alternative. > * The pinning transaction has a high fee, but is blockspace-wasteful, so it is: > * Undesirable to mine (low feerate). > * Difficult to evict (high fee). > * Thus, B is unable to get its timelock-branch transaction in the mempools of miners. > * C waits until the A->B HTLC times out, then: > * C directly contacts miners with an out-of-band proposal to replace its transaction with an alternative that is much smaller and has a low fee, but much better feerate.
Or they can just wait. For example in today’s mempool it would not be strange for a transaction at 1 sat/vbyte to wait a day but eventually confirm.
Quoted text (14 lines)
> * Miners, being economically rational, accept this proposal and include this in a block. > > The proposal by Matt is then: > > * The hashlock branch should instead be: > * B and C must agree, and show the preimage of some hash H (hashlock branch). > * Then B and C agree that B provides a signature spending the hashlock branch, to a transaction with the outputs: > * Normal payment to C. > * Hook output to B, which B can use to CPFP this transaction. > * Hook output to C, which C can use to CPFP this transaction. > * B can still (somehow) not maintain a mempool, by: > * B broadcasts its timelock transaction. > * B tries to CPFP the above hashlock transaction. > * If CPFP succeeds, it means the above hashlock transaction exists and B queries the peer for this transaction, extracting the preimage and claiming the A->B HTLC.
Note that no query is required. The problem has been solved and the preimage-containing transaction should now confirm just fine.
Quoted text (1 line)
> Is that a fair summary?
Yep!
Quoted text (6 lines)
> -- > > Naively, and remembering I am completely ignorant of the exact details of the mempool rules, it seems to me quite strange that we are allowing an undesirable transaction (tree) into the mempool: > > * Undesirable to mine (low fee-rate). > * Difficult to evict (high fee).
As noted, such transactions today are profit in 10 hours. Just because they’re big doesn’t mean they don’t pay.
Quoted text (7 lines)
> Miners are not interested in low fee-rate transactions, as long as higher fee-rate transactions exist. > And being difficult to evict means miners cannot get alternatives that are more lucrative for them. > > The reason (as I understand it) eviction is purposely made difficult here is to prevent certain DoS attacks on Bitcoin nodes, specifically: > > 1. Attacker sends a low fee-rate tx as a "root" transaction. > 2 Attacker sends thousands of low fee-rate tx that build off the above root.
I believe the limit is 25, though the point stands, mostly from a total-size perspective.
Quoted text (5 lines)
> 3. Attacker sends a slightly higher fee-rate alternative to the root, evicting the above tree of txes. > 4. Attacker sends thousands of low fee-rate tx that build off the latest root. > 5. GOTO 3. > > However, it seems to me, naively, that "an ounce of prevention is worth a pound of cure".
Sadly, it’s very very easy for this to be a huge amount of CPU + bandwidth.
Quoted text (3 lines)
> As I understand it, the mempool is organized already into "packages" of transactions, and adding a transaction into the mempool involves extending and merging packages. > Perhaps the size of a package with low fee-rate (relative to the other packages in the mempool) can be limited, so that mempools drop incoming txes that extend a low-fee-rate tree of transactions. > This means an attacker cannot send thousands of low fee-rate tx that build off some low fee-rate root tx in the first place, so it can still be evicted easily later without much impact.
There have been several proposals before around considering a transactions position in the mempool for various similar criteria. The extreme version being simply heavily rate-limiting transaction relay at low feerates and allowing much more liberal replacement of such packages. It isn’t quite perfect for this issue, though, as it may be easy for the attacker to just fill that rate-limit bucket.
Quoted text (6 lines)
> Naively, it seems to me to prevent the DoS attack as well, as at step 2 it would be prevented from sending thousands of low fee-rate tx building off the root. > > As well, as I understand it, this merely tightens the mempool acceptance rules, preventing low fee-rate packages from growing (analogous to a consensus-layer softfork). > The "cannot evict high absolute fee" rule can be retained, as the low-fee-rate package is prevented from reaching a large size. > > Would that be workable as a general solution to solve (what I think is) the root cause of this problem?
It’s not clear to me that tightening the acceptance rules wouldn’t break other existing uses. Historically the 25 package size limit has proven to be an issue for users doing (somewhat naïve) centralized wallet withdraws. Sadly many users want that “payment pending” notification instantly, even if we know it to be somewhat lacking in security. Wallets which have over-compacted their UTXOs are thus stuck making long chains.
To revive an old discussion, on the original thread proposing the CPFP Carve-Out, I said this:
Quoted text (1 line)
> As an alternative proposal, at various points there have been discussions around solving the "RBF-pinning" problem by allowing transactors to mark their transactions as "likely-to-be-RBF'ed", which could enable a relay policy where children of such transactions would be rejected unless the resulting package would be "near the top of the mempool". This would theoretically imply such attacks are not possible to pull off consistently, as any "transaction-delaying" channel participant will have to place the package containing A at an effective feerate which makes confirmation to occur soon with some likelihood. It is, however, possible to pull off this attack with low probability in case of feerate spikes right after broadcast.
To which Rusty responded (and I may be paraphrasing here): “Fuck Yea”. I’m still not much of a fan of this idea as it introduces too many constants (what is “the top of the mempool”, anyway?), and it’s unclear to me what you do as the mempool prevailing feerate changes, but it seems more along the lines or what you’re looking for here.
On Wed, Apr 22, 2020 at 03:53:37PM -0700, Matt Corallo wrote:
Quoted text (3 lines)
> if you focus on sending the pinning transaction to miner nodes > directly (which isn't trivial, but also not nearly as hard as it > sounds), you could still pull off the attack.
If the problem is that miners might have information not available to the network in general, you could just bribe them for that knowledge. E.g. as Bob's refund deadline approaches and he begins to suspect that mempool shenanigans are preventing his refund transaction from confirming, he takes a confirmed P2WPKH UTXO he's been saving for use in CPFP fee bumps and spends part of its value (say 1 mBTC) to the following scriptPubKey[1],
OP_SHA256 <hash_whose_preimage_bob_wants> OP_EQUAL
Assuming the feerate and the bribe amount are reasonable, any miner who knows the preimage is incentivized to include Bob's transaction and a child transation spending from it in their next block. That child transaction will include the preimage, which Bob will see when he processes the block.
If any non-miner knows the preimage, they can also create that child transaction. The non-miner probably can't profit from this---miners can just rewrite the child transaction to pay themselves since there's no key-based security---but the non-miner can at least pat themselves on the back for being a good Summaritan. Again Bob will learn the preimage once the child transaction is included in a block, or earlier if his wallet is monitoring for relays of spends from his parent transaction.
Moreover, Bob can first create a bribe via LN and, in that case, things are even better. As Bob's deadline approaches, he uses one of his still-working channels to send a bunch of max-length (20 hops?) probes that reuse the earlier HTLC's <hash>. If any hop along the path knows the preimage, they can immediately claim the probe amount (and any routing fees that were allocated to subsequent hops). This not only gives smaller miners with LN nodes an equal chance of claiming the probe-bribe as larger miners, but it also allows non-miners to profit from learning the preimage from miners.
That last part is useful because even if, as in your example, the adversary is able to send one version of the transaction just to miners (with the preimage) and another conflicting version to all relay nodes (without the preimage), miners will naturally attempt to relay the preimage version of the transaction to other users; if some of those users run modified nodes that write all 32-byte witness data blobs to a database---even if the transaction is ultimately rejected as a conflict---then targetted relay to miners may not be effective at preventing Bob from learning the preimage.
Obviously all of the above requires people run additional software to keep track of potential preimages[2] and then compare them to hash candidates, plus it requires additional complexity in LN clients, so I can easily understand why it might be less desirable than the protocol changes under discussion in other parts of this thread. Still, with lots of effort already being put into watchtowers and other enforcement-assistance services, I wonder if this problem can be largely addressed in the same general way.
-Dave
[1] Requires a change to standard relay and mining policy. [2] Pretty easy, e.g.
bitcoin-cli getrawmempool \
| jq -r .[] \
| while read txid ; do
bitcoin-cli getrawtransaction $txid true | jq .vout[].scriptPubKey.asm
done \
| grep -o '\<[0-9a-f]\{64\}\>'Good morning Matt,
Quoted text (3 lines)
> > - C directly contacts miners with an out-of-band proposal to replace its transaction with an alternative that is much smaller and has a low fee, but much better feerate. > > Or they can just wait. For example in today’s mempool it would not be strange for a transaction at 1 sat/vbyte to wait a day but eventually confirm.
That introduces the possibility that the entire tree (with high total fee, remember) gets confirmed, so it would be better for C to replace it with an alternative to a different address C still controls, with a slightly better fee rate but smaller (no child transactions) and lower total fee, so an economically-rational C will make that effort (and if there are still other transactions in the mempool, an economically-rational miner will accept this proposal).
But in any case this is a minor detail and the attack will work either way.
Quoted text (17 lines)
> > > - Miners, being economically rational, accept this proposal and include this in a block. > > > > The proposal by Matt is then: > > > > - The hashlock branch should instead be: > > - B and C must agree, and show the preimage of some hash H (hashlock branch). > > - Then B and C agree that B provides a signature spending the hashlock branch, to a transaction with the outputs: > > - Normal payment to C. > > - Hook output to B, which B can use to CPFP this transaction. > > - Hook output to C, which C can use to CPFP this transaction. > > - B can still (somehow) not maintain a mempool, by: > > - B broadcasts its timelock transaction. > > - B tries to CPFP the above hashlock transaction. > > - If CPFP succeeds, it means the above hashlock transaction exists and B queries the peer for this transaction, extracting the preimage and claiming the A->B HTLC. > > Note that no query is required. The problem has been solved and the preimage-containing transaction should now confirm just fine.
Ah, right, so it gets confirmed and the `blocksonly` B sees it in a block.
Even if C hooks a tree of low-fee transactions on its hook output or normal payment, miners will still be willing to confirm this and the B hook CPFP transaction without, right?
Regards, ZmnSCPxj
Good morning David,
Unfortunately this technique does not look like it is compatible to payment points rather than hashes, and we would really like to upgrade to payment points sooner rather than later. Nobody but B can recognize the signature as revealing the scalar behind a particular point (the main privacy advantage of using points). Even variations on this are not useable with payment points.
Regards, ZmnSCPxj
Quoted text (74 lines)
> On Wed, Apr 22, 2020 at 03:53:37PM -0700, Matt Corallo wrote:
>
> > if you focus on sending the pinning transaction to miner nodes
> > directly (which isn't trivial, but also not nearly as hard as it
> > sounds), you could still pull off the attack.
>
> If the problem is that miners might have information not available to
> the network in general, you could just bribe them for that knowledge.
> E.g. as Bob's refund deadline approaches and he begins to suspect that
> mempool shenanigans are preventing his refund transaction from
> confirming, he takes a confirmed P2WPKH UTXO he's been saving for use in
> CPFP fee bumps and spends part of its value (say 1 mBTC) to the
> following scriptPubKey[1],
>
> OP_SHA256 <hash_whose_preimage_bob_wants> OP_EQUAL
>
> Assuming the feerate and the bribe amount are reasonable, any miner who
> knows the preimage is incentivized to include Bob's transaction and a
> child transation spending from it in their next block. That child
> transaction will include the preimage, which Bob will see when he
> processes the block.
>
> If any non-miner knows the preimage, they can also create that child
> transaction. The non-miner probably can't profit from this---miners can
> just rewrite the child transaction to pay themselves since there's no
> key-based security---but the non-miner can at least pat themselves on
> the back for being a good Summaritan. Again Bob will learn the preimage
> once the child transaction is included in a block, or earlier if his
> wallet is monitoring for relays of spends from his parent transaction.
>
> Moreover, Bob can first create a bribe via LN and, in that case, things
> are even better. As Bob's deadline approaches, he uses one of his
> still-working channels to send a bunch of max-length (20 hops?) probes
> that reuse the earlier HTLC's <hash>. If any hop along the path knows
> the preimage, they can immediately claim the probe amount (and any
> routing fees that were allocated to subsequent hops). This not only
> gives smaller miners with LN nodes an equal chance of claiming the
> probe-bribe as larger miners, but it also allows non-miners to profit
> from learning the preimage from miners.
>
> That last part is useful because even if, as in your example, the
> adversary is able to send one version of the transaction just to miners
> (with the preimage) and another conflicting version to all relay nodes
> (without the preimage), miners will naturally attempt to relay the
> preimage version of the transaction to other users; if some of those
> users run modified nodes that write all 32-byte witness data blobs to a
> database---even if the transaction is ultimately rejected as a
> conflict---then targetted relay to miners may not be effective at
> preventing Bob from learning the preimage.
>
> Obviously all of the above requires people run additional software to
> keep track of potential preimages[2] and then compare them to hash
> candidates, plus it requires additional complexity in LN clients, so I
> can easily understand why it might be less desirable than the protocol
> changes under discussion in other parts of this thread. Still, with
> lots of effort already being put into watchtowers and other
> enforcement-assistance services, I wonder if this problem can be largely
> addressed in the same general way.
>
> -Dave
>
> [1] Requires a change to standard relay and mining policy.
> [2] Pretty easy, e.g.
>
> bitcoin-cli getrawmempool \
> | jq -r .[] \
> | while read txid ; do
> bitcoin-cli getrawtransaction $txid true | jq .vout[].scriptPubKey.asm
> done \
> | grep -o '\<[0-9a-f]\{64\}\>'
>
> Lightning-dev mailing list
> Lightning-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-devOn 4/23/20 8:46 AM, ZmnSCPxj wrote:
Quoted text (20 lines)
>>> - Miners, being economically rational, accept this proposal and include this in a block. >>> >>> The proposal by Matt is then: >>> >>> - The hashlock branch should instead be: >>> - B and C must agree, and show the preimage of some hash H (hashlock branch). >>> - Then B and C agree that B provides a signature spending the hashlock branch, to a transaction with the outputs: >>> - Normal payment to C. >>> - Hook output to B, which B can use to CPFP this transaction. >>> - Hook output to C, which C can use to CPFP this transaction. >>> - B can still (somehow) not maintain a mempool, by: >>> - B broadcasts its timelock transaction. >>> - B tries to CPFP the above hashlock transaction. >>> - If CPFP succeeds, it means the above hashlock transaction exists and B queries the peer for this transaction, extracting the preimage and claiming the A->B HTLC. >> >> Note that no query is required. The problem has been solved and the preimage-containing transaction should now confirm just fine. > > Ah, right, so it gets confirmed and the `blocksonly` B sees it in a block. > > Even if C hooks a tree of low-fee transactions on its hook output or normal payment, miners will still be willing to confirm this and the B hook CPFP transaction without, right?
Correct, once it makes it into the mempool we can CPFP it and all the regular sub-package CPFP calculation will pick it and its descendants up. Of course this relies on it not spending any other unconfirmed inputs.
"David A. Harding via bitcoin-dev" <bitcoin-dev@lists•linuxfoundation•org> writes:
Quoted text (22 lines)
> To avoid the excessive wasting of bandwidth. Bitcoin Core's defaults > require each replacement pay a feerate of 10 nBTC/vbyte over an existing > transaction or package, and the defaults also allow transactions or > packages up to 100,000 vbytes in size (~400,000 bytes). So, without > enforcement of BIP125 rule 3, an attacker starting at the minimum > default relay fee also of 10 nBTC/vbyte could do the following: > > - Create a ~400,000 bytes tx with feerate of 10 nBTC/vbyte (1 mBTC total > fee) > > - Replace that transaction with 400,000 new bytes at a feerate of 20 > nBTC/vbyte (2 mBTC total fee) > > - Perform 998 additional replacements, each increasing the feerate by 10 > nBTC/vbyte and the total fee by 1 mBTC, using a total of 400 megabytes > (including the original transaction and first replacement) to > ultimately produce a transaction with a feerate of 10,000 nBTC/vbyte > (1 BTC total fee) > > - Perform one final replacement of the latest 400,000 byte transaction > with a ~200-byte (~150 vbyte) 1-in, 1-out P2WPKH transaction that pays > a feerate of 10,010 nBTC/vbyte (1.5 mBTC total fee)
To be fair, if the feerate you want is 100x the minimum permitted, you can always use 100x as much bandwidth as necessary without extra cost. If everyone (or some major tx producers) were to do that, it would suck.
To fix this properly, you really need to agressively delay processing (thus propagation) of transactions which aren't likely to be in the next (few?) blocks. This is a more miner incentive compatible scheme.
However, I realize this is a complete rewrite of bitcoind's logic, and I'm not volunteering to do it!
Cheers, Rusty,
Good morning list,
Sorry for being (very) late to the party on that subject, but better late than never.
A lot of ideas have been thrown at the problem and are scattered across emails, IRC discussions, and github issues. I've spent some time putting it all together in one gist, hoping that it will help stir the discussion forward as well as give newcomers all the background they need to ramp up on this issue and join the discussion, bringing new ideas to the table.
The gist is here, and I'd appreciate your feedback if I have wrongly interpreted some of the ideas: https://gist.github.com/t-bast/22320336e0816ca5578fdca4ad824d12
Readers of this list can probably directly skip to the "Future work" section. I believe my "alternative proposal" should loosely reflect Matt's proposal from the very first mail of this thread; note that I included anchors and new txs only in some places, as I think they aren't necessary everywhere.
My current state-of-mind (subject to change as I discover more potential attacks) is that:
* The proposal to add more anchors and pre-signed txs adds non-negligible complexity and hurts small HTLCs, so it would be better if we didn't need it * The blind CPFP carve-out trick is a one shot, so you'll likely need to pay a lot of fees for it to work which still makes you lose money in case an attacker targets you (but the money goes to miners, not to the attacker - unless he is the miner). It's potentially hard to estimate what fee you should put into that blind CPFP carve-out because you have no idea what the current fee of the pinned success transaction package is, so it's unsure if that solution will really work in practice * If we take a step back, the only attack we need to protect against is an attacker pinning a preimage transaction while preventing us from learning that preimage for at least `N` blocks (see the gist for the complete explanation). Please correct me if that claim is incorrect as it will invalidate my conclusion! Thus if we have: * a high enough `cltv_expiry_delta` * [off-chain preimage broadcast]( https://github.com/lightningnetwork/lightning-rfc/issues/783) (or David's proposal to do it by sending txs that can be redeemed via only the preimage) * LN hubs (or any party commercially investing in running a lightning node) participating in various mining pools to help discover preimages * decent mitigations for eclipse attacks * then the official anchor outputs proposal should be safe enough and is much simpler?
Thank you for reading, I hope the work I put into this gist will be useful for some of you.
Bastien
Le ven. 24 avr. 2020 à 00:47, Matt Corallo via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> a écrit :
Quoted text (42 lines)
> > > On 4/23/20 8:46 AM, ZmnSCPxj wrote: > >>> - Miners, being economically rational, accept this proposal and > include this in a block. > >>> > >>> The proposal by Matt is then: > >>> > >>> - The hashlock branch should instead be: > >>> - B and C must agree, and show the preimage of some hash H (hashlock > branch). > >>> - Then B and C agree that B provides a signature spending the > hashlock branch, to a transaction with the outputs: > >>> - Normal payment to C. > >>> - Hook output to B, which B can use to CPFP this transaction. > >>> - Hook output to C, which C can use to CPFP this transaction. > >>> - B can still (somehow) not maintain a mempool, by: > >>> - B broadcasts its timelock transaction. > >>> - B tries to CPFP the above hashlock transaction. > >>> - If CPFP succeeds, it means the above hashlock transaction exists > and B queries the peer for this transaction, extracting the preimage and > claiming the A->B HTLC. > >> > >> Note that no query is required. The problem has been solved and the > preimage-containing transaction should now confirm just fine. > > > > Ah, right, so it gets confirmed and the `blocksonly` B sees it in a > block. > > > > Even if C hooks a tree of low-fee transactions on its hook output or > normal payment, miners will still be willing to confirm this and the B hook > CPFP transaction without, right? > > Correct, once it makes it into the mempool we can CPFP it and all the > regular sub-package CPFP calculation will pick it > and its descendants up. Of course this relies on it not spending any other > unconfirmed inputs. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
On Fri, Jun 19, 2020 at 09:44:11AM +0200, Bastien TEINTURIER via Lightning-dev wrote:
Quoted text (3 lines)
> The gist is here, and I'd appreciate your feedback if I have wrongly > interpreted some of the ideas: > https://gist.github.com/t-bast/22320336e0816ca5578fdca4ad824d12
Quoted text below is from the gist:
Quoted text (3 lines)
> The trick to protect against a malicious participant that broadcasts a > low-fee HTLC-success or Remote-HTLC-success transaction is that we can > always blindly do a CPFP carve-out on them; we know their txid
I think you're assuming here that the attacker broadcast a particular state. However, in a channel which potentially had thousands of state changes, you'd have to broadcast a blind child for each previous state (or at least each previous state that pays the attacker more than the latest state). That's potentially thousands of transactions times potentially dozens of peers---not impossible, but it seems messy.
I think there's a way to accomplish the same goal for less bandwidth and zero fees. The only way your Bitcoin peer will relay your blind child is if it already has the parent transaction. If it has the parent, you can just request it using P2P getdata(type='tx', id=$txid).[1] You can batch multiple txid requests together (up to 50,000 IIRC) to minimize overhead, making the average cost per txid a tiny bit over 36 bytes. If you receive one of the transactions you request, you can extract the preimage at no cost to yourself (except bandwidth). If you don't receive a transaction, then sending a blind child is hopeless anyway---your peers won't relay it.
Overall, it's hard for me to guess how effective your proposal would be at defeating the attack. I think the strongman argument for the attack would be that the attacker will be able to perform a targeted relay of their outdated state to just miners---everyone else on the network will receive the counterparty's honest final-state close. Unless the counterparty happens to have a connection to a miner's node, the counterparty will neither be able to CPFP fee bump nor use getdata to retrieve the preimage.
It seems to me it's practical for a motivated attacker to research which IP addresses belong to miners so that they can target them, whereas honest users won't practically be able to do that research (and, even if they could, it would create a centralizing barrier to new miners entering the market if users focused on maintaining connections to previously-known miners).
-Dave
[1] You'd have to be careful to not attempt the getdata too soon after
you think the attacker broadcast their old state, but I think that
only means waiting a single block, which you have to do anyway to
see if the honest final-commitment transaction confirmed. See
https://github.com/bitcoin/bitcoin/pull/18861On Fri, Jun 19, 2020 at 03:58:46PM -0400, David A. Harding via bitcoin-dev wrote:
Quoted text (2 lines)
> I think you're assuming here that the attacker broadcast a particular > state.
Whoops, I managed to confuse myself despite looking at Bastien's excellent explainer. The attacker would be broadcasting the latest state, so the honest counterparty would only need to send one blind child. However, the blind child will only be relayed by a Bitcoin peer if the peer also has the parent transaction (the latest state) and, if it has the parent transaction, you should be able to just getdata('tx', $txid) that transaction from the peer without CPFPing anything. That will give you the preimage and so you can immediately resolve the HTLC with the upstream channel.
Revising my conclusion from the previous post:
I think the strongman argument for the attack would be that the attacker will be able to perform a targeted relay of the low-feerate preimage-containing transaction to just miners---everyone else on the network will receive the honest user's higher-feerate expired-timelock transaction. Unless the honest user happens to have a connection to a miner's node, the user will neither be able to CPFP fee bump nor use getdata to retrieve the preimage.
Sorry for the confusion.
-Dave
Hello Dave and list,
Thanks for your quick answers!
The attacker would be broadcasting the latest
Quoted text (3 lines)
> state, so the honest counterparty would only need to send one blind > child. >
Exactly, if the attacker submits an outdated transaction he would be shooting himself in the foot, as we could claim the revocation paths when seeing the transaction in a block and get all the channel funds (since the attacker's outputs will be CSV-locked).
The only way your Bitcoin peer will relay your blind child
Quoted text (2 lines)
> is if it already has the parent transaction. >
That's an excellent point that I missed in the blind CPFP carve-out trick! I think this makes the blind CPFP carve-out quite hard in practice (even using getdata - thanks for detailing that option)...
In the worst case scenario where most miners' mempools contain the attacker's tx and the rest of the network's mempools contains the honest participant's tx, I think there isn't much we can do. We're simply missing information, so it looks like the only good solution is to avoid being in that situation by having a foot in miners' mempools. Do you think it's unreasonable to expect at least some LN nodes to also invest in running nodes in mining pools, ensuring that they learn about attackers' txs and can potentially share discovered preimages with the network off-chain (by gossiping preimages found in the mempool over LN)? I think that these recent attacks show that we need (at least some) off-chain nodes to be somewhat heavily invested in on-chain operations (layers can't be fully decoupled with the current security assumptions - maybe Eltoo will help change that in the future?).
Thank you for your time! Bastien
Le ven. 19 juin 2020 à 22:53, David A. Harding <dave@dtrt•org> a écrit :
Quoted text (29 lines)
> On Fri, Jun 19, 2020 at 03:58:46PM -0400, David A. Harding via bitcoin-dev
> wrote:
> > I think you're assuming here that the attacker broadcast a particular
> > state.
>
> Whoops, I managed to confuse myself despite looking at Bastien's
> excellent explainer. The attacker would be broadcasting the latest
> state, so the honest counterparty would only need to send one blind
> child. However, the blind child will only be relayed by a Bitcoin peer
> if the peer also has the parent transaction (the latest state) and, if
> it has the parent transaction, you should be able to just getdata('tx',
> $txid) that transaction from the peer without CPFPing anything. That
> will give you the preimage and so you can immediately resolve the HTLC
> with the upstream channel.
>
> Revising my conclusion from the previous post:
>
> I think the strongman argument for the attack would be that the attacker
> will be able to perform a targeted relay of the low-feerate
> preimage-containing transaction to just miners---everyone else on the
> network will receive the honest user's higher-feerate expired-timelock
> transaction. Unless the honest user happens to have a connection to a
> miner's node, the user will neither be able to CPFP fee bump nor use
> getdata to retrieve the preimage.
>
> Sorry for the confusion.
>
> -Dave
>On Sat, Jun 20, 2020 at 10:54:03AM +0200, Bastien TEINTURIER wrote:
Quoted text (3 lines)
> We're simply missing information, so it looks like the only good > solution is to avoid being in that situation by having a foot in > miners' mempools.
The problem I have with that approach is that the incentive is to connect to the highest hashrate pools and ignore the long tail of smaller pools and solo miners. If miners realize people are doing this, they may begin to charge for information about their mempool and the largest miners will likely be able to charge more money per hashrate than smaller miners, creating a centralization force by increasing existing economies of scale.
Worse, information about a node's mempool is partly trusted. A node can easily prove what transactions it has, but it can't prove that it doesn't have a certain transaction. This implies incumbent pools with a long record of trustworthy behavior may be able to charge more per hashrate than a newer pools, creating a reputation-based centralizing force that pushes individual miners towards well-established pools.
This is one reason I suggested using independent pay-to-preimage transactions[1]. Anyone who knows the preimage can mine the transaction, so it doesn't provide reputational advantage or direct economies of scale---pay-to-preimage is incentive equivalent to paying normal onchain transaction fees. There is an indirect economy of scale---attackers are most likely to send the low-feerate preimage-containing transaction to just the largest pools, so small miners are unlikely to learn the preimage and thus unlikely to be able to claim the payment. However, if the defense is effective, the attack should rarely happen and so this should not have a significant effect on mining profitability---unlike monitoring miner mempools which would have to be done continuously and forever.
ZmnSCPxj noted that pay-to-preimage doesn't work with PTLCs.[2] I was hoping one of Bitcoin's several inventive cryptographers would come along and describe how someone with an adaptor signature could use that information to create a pubkey that could be put into a transaction with a second output that OP_RETURN included the serialized adaptor signature. The pubkey would be designed to be spendable by anyone with the final signature in a way that revealed the hidden value to the pubkey's creator, allowing them to resolve the PTLC. But if that's fundamentally not possible, I think we could advocate for making pay-to-revealed-adaptor-signature possible using something like OP_CHECKSIGFROMSTACK.[3]
[1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002664.html [2] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002667.html [3] https://bitcoinops.org/en/topics/op_checksigfromstack/
Quoted text (5 lines)
> Do you think it's unreasonable to expect at least some LN nodes to > also invest in running nodes in mining pools, ensuring that they learn > about attackers' txs and can potentially share discovered preimages > with the network off-chain (by gossiping preimages found in the > mempool over LN)?
Ignoring my concerns about mining centralization and from the perspective of just the Lightning Network, that doesn't sound unreasonable to me. But from the perspective of a single LN node, it might make more sense to get the information and *not* share it, increasing your security and allowing you to charge lower routing fees compared to your competitors. This effect would only be enhanced if miners charged for their mempool contents (indeed, to maximize their revenue, miners might require that their mempool subscribers don't share the information---which they could trivially enforce by occasionally sending subscribers a preimage specific to the subscriber and seeing if it propagated to the public network).
Quoted text (4 lines)
> I think that these recent attacks show that we need (at least some) > off-chain nodes to be somewhat heavily invested in on-chain operations > (layers can't be fully decoupled with the current security assumptions > - maybe Eltoo will help change that in the future?).
I don't see how eltoo helps. Eltoo helps ensure you reach the final channel state, but this problem involves an abuse of that final state.
-Dave
Good morning Dave,
Quoted text (11 lines)
> ZmnSCPxj noted that pay-to-preimage doesn't work with PTLCs.[2] I was > hoping one of Bitcoin's several inventive cryptographers would come > along and describe how someone with an adaptor signature could use that > information to create a pubkey that could be put into a transaction with > a second output that OP_RETURN included the serialized adaptor > signature. The pubkey would be designed to be spendable by anyone with > the final signature in a way that revealed the hidden value to the > pubkey's creator, allowing them to resolve the PTLC. But if that's > fundamentally not possible, I think we could advocate for making > pay-to-revealed-adaptor-signature possible using something like > OP_CHECKSIGFROMSTACK.[3]
Not a cryptographer, I just play one on the Internet, but maybe the pay-for-signature construction could work...?
Assuming a PTLC has a pointlocked branch, which involves signing with MuSig(A, B). A offers to B the amount if B reveals the secret `t` behind `T = t * G`; A knows `T` but not `t`. This is done by B handing over `R[B]` and `s'[B]`:
R = R[A] + R[B] + T
s'[B] = r[B] + h(MuSig(A, B) | R | m) * b
Then A provides its partial signature to B.
s[A] = r[A] + h(MuSig(A, B) | R | m) * a
B has to complete the signature by:
s = s[A] + s'[B] + t
Since A knows both `s[A]` and `s'[B]`, once it knows `s`, it can compute `t`.
Now, we can massage the equation for `s`:
s = r[A] + h(MuSig(A, B) | R | m) * a + r[B] + h(MuSig(A, B) | R | m) * b + t
; multiply both sides by G
s * G = r[A] * G + h(MuSig(A, B) | R | m) * a * G + r[B] * G + h(MuSig(A, B) | R | m) * b * G + t * G
; replace with public points
s * G = R[A] + h(MuSig(A, B) | R | m) * A + R[B] + h(MuSig(A, B) | R | m) * B + T
Note that A can compute `s * G` above, because it generated `R[A]`, was given `R[B]` and `T`, and knows who `A` and `B` are.
So what A needs to do is to offer a fund that can only be claimed by leaking knowledge of `s` behind `s * G`. A can do this by creating a new keypair `A[p4s] = a[p4s] * G` and putting a fund into it.
Then A generates an `R[A][p4s] = r[A][p4s] * G`, and computes:
R[p4s] = R[A][p4s] + s * G
s'[A][p4s] = r[A][p4s] + h(A | R[p4s] | m) * a[p4s]
The signed message could be a signature to `SIGHASH_NONE`, finally an actual use for that flag.
A reveals publicly (in an `OP_RETURN` as you suggest):
* `R[A][p4s]` * `s * G` * `s'[A][p4s]` * `A[p4s]` - Already the Schnorr output pubkey.
In order to complete the above signature, a third party C has to learn `s` from B.
The third party has to scan every onchain 1-of-1 signature for an `s` that matches `s * G`, so there is greater processing (point multiplies are more expensive than hashes, also there are more 1-of-1s). But once learned, the third party can complete the signature and claim the funds. And A then learns `s`, from which it can derive `t`.
The third party learns about which channel (i.e. the UTXO that was spent to create the PTLC in the first place), but never learns `t` or `T`, which is a small but nice privacy bonus.
Regards, ZmnSCPxj
Good morning again,
Quoted text (17 lines)
> Good morning Dave, > > > ZmnSCPxj noted that pay-to-preimage doesn't work with PTLCs.[2] I was > > hoping one of Bitcoin's several inventive cryptographers would come > > along and describe how someone with an adaptor signature could use that > > information to create a pubkey that could be put into a transaction with > > a second output that OP_RETURN included the serialized adaptor > > signature. The pubkey would be designed to be spendable by anyone with > > the final signature in a way that revealed the hidden value to the > > pubkey's creator, allowing them to resolve the PTLC. But if that's > > fundamentally not possible, I think we could advocate for making > > pay-to-revealed-adaptor-signature possible using something like > > OP_CHECKSIGFROMSTACK.[3] > > <snip> > > The signed message could be a signature to `SIGHASH_NONE`, finally an actual use for that flag.
If you are going to embed it in an `OP_RETURN` in the same transaction, you also need `SIGHASH_ANYPREVOUT`, otherwise you cannot embed the adaptor signature for spending from that transaction in the transaction being spent, it also implies `A[p4s] = a[p4s] * G` is a one-time-use keypair.
Regards, ZmnSCPxj
Thanks for the detailed write-up on how it affects incentives and centralization, these are good points. I need to spend more time thinking about them.
This is one reason I suggested using independent pay-to-preimage
Quoted text (2 lines)
> transactions[1] >
While this works as a technical solution, I think it has some incentives issues too. In this attack, I believe the miners that hide the preimage tx in their mempool have to be accomplice with the attacker, otherwise they would share that tx with some of their peers, and some non-miner nodes would get that preimage tx and be able to gossip them off-chain (and even relay them to other mempools).
If they are actively helping the attacker, they wouldn't spend the pay-to-preimage tx, unless they gain more from it than the share the attacker gives them. This becomes a simple bidding war, and the honest user will always be the losing party here (the attacker has nothing to lose). For this reason I'm afraid it wouldn't work out in practice as well as we'd hope...what do you think? And even if the honest user wins the bidding war, the attack still steals money from that user; it just goes into the miner's pocket.
But from the perspective of a single LN node, it
Quoted text (2 lines)
> might make more sense to get the information and *not* share it >
I think it depends. If this attack becomes doable in practice and we see it happening, LN routing nodes and service providers have a very high incentive to thwart these attacks, because otherwise they'd lose their business as people would leave the lightning network.
As long as enough nodes think that way (with "enough" being a very hard to define quantity), this should mitigate the attack. The only risk would be a big "exit scam" scenario, but the coordination cost between all these nodes makes that scenario unlikely (IMHO).
Thanks, Bastien
Le sam. 20 juin 2020 à 12:37, David A. Harding <dave@dtrt•org> a écrit :
Quoted text (79 lines)
> On Sat, Jun 20, 2020 at 10:54:03AM +0200, Bastien TEINTURIER wrote: > > We're simply missing information, so it looks like the only good > > solution is to avoid being in that situation by having a foot in > > miners' mempools. > > The problem I have with that approach is that the incentive is to > connect to the highest hashrate pools and ignore the long tail of > smaller pools and solo miners. If miners realize people are doing this, > they may begin to charge for information about their mempool and the > largest miners will likely be able to charge more money per hashrate > than smaller miners, creating a centralization force by increasing > existing economies of scale. > > Worse, information about a node's mempool is partly trusted. A node can > easily prove what transactions it has, but it can't prove that it > doesn't have a certain transaction. This implies incumbent pools with a > long record of trustworthy behavior may be able to charge more per > hashrate than a newer pools, creating a reputation-based centralizing > force that pushes individual miners towards well-established pools. > > This is one reason I suggested using independent pay-to-preimage > transactions[1]. Anyone who knows the preimage can mine the > transaction, so it doesn't provide reputational advantage or direct > economies of scale---pay-to-preimage is incentive equivalent to paying > normal onchain transaction fees. There is an indirect economy of > scale---attackers are most likely to send the low-feerate > preimage-containing transaction to just the largest pools, so small > miners are unlikely to learn the preimage and thus unlikely to be able > to claim the payment. However, if the defense is effective, the attack > should rarely happen and so this should not have a significant effect on > mining profitability---unlike monitoring miner mempools which would have > to be done continuously and forever. > > ZmnSCPxj noted that pay-to-preimage doesn't work with PTLCs.[2] I was > hoping one of Bitcoin's several inventive cryptographers would come > along and describe how someone with an adaptor signature could use that > information to create a pubkey that could be put into a transaction with > a second output that OP_RETURN included the serialized adaptor > signature. The pubkey would be designed to be spendable by anyone with > the final signature in a way that revealed the hidden value to the > pubkey's creator, allowing them to resolve the PTLC. But if that's > fundamentally not possible, I think we could advocate for making > pay-to-revealed-adaptor-signature possible using something like > OP_CHECKSIGFROMSTACK.[3] > > [1] > https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002664.html > [2] > https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002667.html > [3] https://bitcoinops.org/en/topics/op_checksigfromstack/ > > > Do you think it's unreasonable to expect at least some LN nodes to > > also invest in running nodes in mining pools, ensuring that they learn > > about attackers' txs and can potentially share discovered preimages > > with the network off-chain (by gossiping preimages found in the > > mempool over LN)? > > Ignoring my concerns about mining centralization and from the > perspective of just the Lightning Network, that doesn't sound > unreasonable to me. But from the perspective of a single LN node, it > might make more sense to get the information and *not* share it, > increasing your security and allowing you to charge lower routing fees > compared to your competitors. This effect would only be enhanced if > miners charged for their mempool contents (indeed, to maximize their > revenue, miners might require that their mempool subscribers don't share > the information---which they could trivially enforce by occasionally > sending subscribers a preimage specific to the subscriber and seeing if > it propagated to the public network). > > > I think that these recent attacks show that we need (at least some) > > off-chain nodes to be somewhat heavily invested in on-chain operations > > (layers can't be fully decoupled with the current security assumptions > > - maybe Eltoo will help change that in the future?). > > I don't see how eltoo helps. Eltoo helps ensure you reach the final > channel state, but this problem involves an abuse of that final state. > > -Dave >
Good morning Bastien,
Quoted text (11 lines)
> Thanks for the detailed write-up on how it affects incentives and centralization, > these are good points. I need to spend more time thinking about them. > > > This is one reason I suggested using independent pay-to-preimage > > transactions[1] > > While this works as a technical solution, I think it has some incentives issues too. > In this attack, I believe the miners that hide the preimage tx in their mempool have > to be accomplice with the attacker, otherwise they would share that tx with some of > their peers, and some non-miner nodes would get that preimage tx and be able to > gossip them off-chain (and even relay them to other mempools).
I believe this is technically possible with current mempool rules, without miners cooperating with the attacker.
Basically, the attacker releases two transactions with near-equal fees, so that neither can RBF the other. It releases the preimage tx near miners, and the timelock tx near non-miners.
Nodes at the boundaries between those that receive the preimage tx and the timelock tx will receive both. However, they will receive one or the other first. Which one they receive first will be what they keep, and they will reject the other (and *not* propagate the other), because the difference in fees is not enough to get past the RBF rules (which requires not just a feerate increase, but also an increase in absolute fee, of at least the minimum relay feerate times transaction size).
Because they reject the other tx, they do not propagate the other tx, so the boundary between the two txes is inviolate, neither can get past that boundary, this occurs even if everyone is running 100% unmodified Bitcoin Core code.
I am not a mempool expert and my understanding may be incorrect.
Regards, ZmnSCPxj
Hey ZmnSCPxj,
I agree that in theory this looks possible, but doing it in practice with accurate control of what parts of the network get what tx feels impractical to me (but maybe I'm wrong!).
It feels to me that an attacker who would be able to do this would break *any* off-chain construction that relies on absolute timeouts, so I'm hoping this is insanely hard to achieve without cooperation from a miners subset. Let me know if I'm too optimistic on this!
Cheers, Bastien
Le lun. 22 juin 2020 à 10:15, ZmnSCPxj <ZmnSCPxj@protonmail•com> a écrit :
Quoted text (46 lines)
> Good morning Bastien, > > > Thanks for the detailed write-up on how it affects incentives and > centralization, > > these are good points. I need to spend more time thinking about them. > > > > > This is one reason I suggested using independent pay-to-preimage > > > transactions[1] > > > > While this works as a technical solution, I think it has some incentives > issues too. > > In this attack, I believe the miners that hide the preimage tx in their > mempool have > > to be accomplice with the attacker, otherwise they would share that tx > with some of > > their peers, and some non-miner nodes would get that preimage tx and be > able to > > gossip them off-chain (and even relay them to other mempools). > > I believe this is technically possible with current mempool rules, without > miners cooperating with the attacker. > > Basically, the attacker releases two transactions with near-equal fees, so > that neither can RBF the other. > It releases the preimage tx near miners, and the timelock tx near > non-miners. > > Nodes at the boundaries between those that receive the preimage tx and the > timelock tx will receive both. > However, they will receive one or the other first. > Which one they receive first will be what they keep, and they will reject > the other (and *not* propagate the other), because the difference in fees > is not enough to get past the RBF rules (which requires not just a feerate > increase, but also an increase in absolute fee, of at least the minimum > relay feerate times transaction size). > > Because they reject the other tx, they do not propagate the other tx, so > the boundary between the two txes is inviolate, neither can get past that > boundary, this occurs even if everyone is running 100% unmodified Bitcoin > Core code. > > I am not a mempool expert and my understanding may be incorrect. > > Regards, > ZmnSCPxj >
Given transaction relay delays and a network topology that is rather transparent if you look closely enough, I think this is very real and very practical (double-digit % success rate, at least, with some trial and error probably 50+). That said, we all also probably know most of the people who know enough to go from zero to doing this practically next week. As for motivated folks who have lots of time to read code and dig, this seems like something worth fixing in the medium term.
Your observation is what’s largely led me to conclude there isn’t a lot we can do here without a lot of creativity and fundamental rethinking of our approach. One thing I keep harping on is maybe saving the blind-CPFP approach with a) eltoo, and b) some kind of magic transaction relay metadata that allows you to specify “this spends at least one output on any transaction that spends output X” so that nodes can always apply it properly. But maybe that’s a pipedream of complexity. I know Antoine has other thoughts.
Matt
Quoted text (50 lines)
> On Jun 22, 2020, at 04:04, Bastien TEINTURIER via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote: > > > Hey ZmnSCPxj, > > I agree that in theory this looks possible, but doing it in practice with accurate control > of what parts of the network get what tx feels impractical to me (but maybe I'm wrong!). > > It feels to me that an attacker who would be able to do this would break *any* off-chain > construction that relies on absolute timeouts, so I'm hoping this is insanely hard to > achieve without cooperation from a miners subset. Let me know if I'm too optimistic on > this! > > Cheers, > Bastien > >> Le lun. 22 juin 2020 à 10:15, ZmnSCPxj <ZmnSCPxj@protonmail•com> a écrit : >> Good morning Bastien, >> >> > Thanks for the detailed write-up on how it affects incentives and centralization, >> > these are good points. I need to spend more time thinking about them. >> > >> > > This is one reason I suggested using independent pay-to-preimage >> > > transactions[1] >> > >> > While this works as a technical solution, I think it has some incentives issues too. >> > In this attack, I believe the miners that hide the preimage tx in their mempool have >> > to be accomplice with the attacker, otherwise they would share that tx with some of >> > their peers, and some non-miner nodes would get that preimage tx and be able to >> > gossip them off-chain (and even relay them to other mempools). >> >> I believe this is technically possible with current mempool rules, without miners cooperating with the attacker. >> >> Basically, the attacker releases two transactions with near-equal fees, so that neither can RBF the other. >> It releases the preimage tx near miners, and the timelock tx near non-miners. >> >> Nodes at the boundaries between those that receive the preimage tx and the timelock tx will receive both. >> However, they will receive one or the other first. >> Which one they receive first will be what they keep, and they will reject the other (and *not* propagate the other), because the difference in fees is not enough to get past the RBF rules (which requires not just a feerate increase, but also an increase in absolute fee, of at least the minimum relay feerate times transaction size). >> >> Because they reject the other tx, they do not propagate the other tx, so the boundary between the two txes is inviolate, neither can get past that boundary, this occurs even if everyone is running 100% unmodified Bitcoin Core code. >> >> I am not a mempool expert and my understanding may be incorrect. >> >> Regards, >> ZmnSCPxj > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev