Re: [bitcoin-dev] [Lightning-dev] RBF Pinning with Counterparties and Competing Interest

[Matt Corallo via bitcoin-dev]

Great summary, a few notes inline.

> On Apr 22, 2020, at 21:50, ZmnSCPxj  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.

> * 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.

> * 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.

> * 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.

> Is that a fair summary?

Yep!

> --
> 
> 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.

> 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.

> 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

Re: [bitcoin-dev] [Lightning-dev] RBF Pinning with Counterparties and Competing Interest

[ZmnSCPxj via bitcoin-dev]

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?

--

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).

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.
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".

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.

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 r

Re: [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest

[Jeremy via bitcoin-dev]

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


--
@JeremyRubin 
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest

[Matt Corallo via bitcoin-dev]

On 4/22/20 7:27 PM, Olaoluwa Osuntokun wrote:
> 
>> 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.

> 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 :).

>> 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.

> -- Laolung
> 
> 
> On Wed, Apr 22, 2020 at 4:20 PM Matt Corallo  > wrote:
> 
> 
> 
>> On Apr 22, 2020, at 16:13, Olaoluwa Osuntokun > > 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 > > 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
>> 

Re: [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest

[Olaoluwa Osuntokun via bitcoin-dev]

> 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?

> 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 
wrote:

>
>
> On Apr 22, 2020, at 16:13, Olaoluwa Osuntokun  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 
> 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.
>>
>> Becaus

Re: [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest

[Matt Corallo via bitcoin-dev]

> On Apr 22, 2020, at 16:13, Olaoluwa Osuntokun  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  
>> 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
>> partiall

Re: [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest

[Olaoluwa Osuntokun via bitcoin-dev]

> 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].

> 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 
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 mem

Re: [bitcoin-dev] [Lightning-dev] RBF Pinning with Counterparties and Competing Interest

[Olaoluwa Osuntokun via 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 
wrote:

> 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  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, 

Re: [bitcoin-dev] [Lightning-dev] RBF Pinning with Counterparties and Competing Interest

[Olaoluwa Osuntokun via bitcoin-dev]

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  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

Re: [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest

[Matt Corallo via bitcoin-dev]

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


> 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.
> 
> -Dave

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest

[David A. Harding via bitcoin-dev]

On Wed, Apr 22, 2020 at 03:03:29PM -0400, Antoine Riard wrote:
> > 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


signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest

[Antoine Riard via bitcoin-dev]

> 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 :

> 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
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Fwd: (Semi)Traceless 2-party coinjoin off-chain protocol using schnorr signatures

[German Luna via bitcoin-dev]

Hello All,

## Objective
* Make atomic swaps within the same chain possible in a traceless way
* Achieving traceless same-chain atomic-swaps effectively turns an entire
chain into a  (P2PKH) mixer by default

## Proposed solution
Similar to the way that atomic swaps would work with schnorr signatures
(i.e. leveraging adaptor signatures), the proposed solution is to use - in
place of the secret 't' - a suitably chosen schnorr signature. The end
result being that when one counterparty claims their side of the funds, the
party can obtain the signature they're missing to claim the funds in the
(schnorr) multisig that pays them.
On-chain, this would appear like two independent transactions, even though
effectively the two parties have “exchanged” the history attached to the
UTXOs. Unlike a mixing service, in which all of the histories get merged,
with this protocol histories can be pairwise swapped without anybody’s
knowledge.

## Protocol description
* Alice and Bob, holding funds at UTXO1 (controlled by Alice) and UTXO2
(controlled by Bob) wish to swap them.
* Alice provides Bob with a single public key P_A
* Bob provides Alice two pubkeys P_B1, P_B2.
* Bob and Alice construct the P2PKH addresses Addr1 = Hash(P_A+P_B1) [where
the UTXO1 funds will be sent to eventually] and Addr2  = Hash(P_A+P_B2)
[where the UTXO2 funds will be sent to eventually]
* Bob and Alice exchange time-locked refund transactions for the funding
transactions sending the funds to Addr1 and Addr2.
* Bob and Alice submit the funding transactions (Alice pays to Addr1 from
UTXO1; Bob pays to Addr2 from UTXO2)
* Alice sends Bob an adaptor signature: r1 + H(r1 | m)*x_a + r2 + H( r2 |
m')*x_a
* Bob verifies the adaptor signature Alice sent contains a valid signature
for spending from Addr1 AND another valid signature for spending from
Addr2. Both signatures from Alice. Bob cannot separate out the two
signatures and hence cannot claim any of the funds, provided H( r1 | m) !=
H( r2 | m') in the signature commitment.
* Bob now sends Alice the valid signature: r2 + H( r2 | m' )*x_b2
* Alice can now add her signature to Bob's and get: r2 + H( r2| m'
)*(x_b2 + x_a) which is a valid signature to spend the funding transaction
sent to Addr2.
* Finally, Bob sees Alice claims the fund sent to Addr2 and uses that
signature to subtract his own: r2 + H( r2 | m' )*(x_b2 + x_a) - (r2 + H( r2
| m' )*x_b2) = H( r2 | m ')*x_a
* Bob takes the original adaptor signature and subtracts the known quantity
r2+ H( r2 | m' )*x_a, to get a valid signature: r1 + H( r1 | m )*x_a
* Bob can now add to that valid signature, his own signature and retrieve
the funds.
## Notes
* It is possible for the counterparty to store copies of the signatures as
proof that such a join has taken place. But plausible deniability is
available upon discarding signatures since the joint private keys (x_a +
x_b*) are unavailable.

I'm interested in hearing feedback on this idea if possible, and deemed
interesting enough.

Best regards,
-- 
Germán
Mathematician
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest

[David A. Harding via bitcoin-dev]

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


signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Lightning-dev] RBF Pinning with Counterparties and Competing Interest

[Matt Corallo via bitcoin-dev]

On 4/22/20 12:12 AM, ZmnSCPxj 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.

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.

> 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.

> 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.

> 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.

> 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

Re: [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest

[Matt Corallo via bitcoin-dev]

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 broadcas

Re: [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest

[David A. Harding via bitcoin-dev]

On Tue, Apr 21, 2020 at 09:13:34PM -0700, Olaoluwa Osuntokun wrote:
> 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]

> 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.


signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Academic research regarding BIP0002

[nopara73 via bitcoin-dev]

Just a tip: if you'd like to get feedback on your work, then share your
work as well, since not many people are willing to commit to helping unless
they know how large the work is.

On Tue, Apr 21, 2020 at 10:51 PM Shiva Jairam via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi all,
>
>
>
> I am doing a project trying to map out BIP002 (
> https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki) into a
> bussiness process model using BPMN2.0.
>
> This is a project regarding an academic research for my studies.
>
> I am by no means an expert in Blockchain nor Bitcoin and have just
> recently began looking into the technologies.
>
>
>
> Is someone willing to review or discuss my model?
>
> If this is not the right place to discuss such a topic, pointing in the
> right direction is much appreciated.
>
>
>
>
>
> Kind regards,
>
> Shiva Jairam
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>


-- 
Best,
Ádám
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Lightning-dev] RBF Pinning with Counterparties and Competing Interest

[Bastien TEINTURIER via 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
> 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  a
écrit :

> 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, Alic

Re: [bitcoin-dev] [Lightning-dev] RBF Pinning with Counterparties and Competing Interest

[Antoine Riard via bitcoin-dev]

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