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

[Matt Corallo]

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

> On Jun 22, 2020, at 04:04, Bastien TEINTURIER via bitcoin-dev <bitcoin-dev at 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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200624/7a0b11e4/attachment.html>