On Sun, Jul 21, 2024 at 05:35:31AM -1000, David A. Harding wrote: > On 2024-07-20 05:03, Peter Todd wrote: > > What other "free" relay attacks can you think of that were fixed? > > The two you mention were the two I had in mind. Right. So in the entire history of Core, we have two quite ridiculous free relay attacks that got fixed, and we *added* a significant free-relay vulnerability by adding mempool expiration. We also added a free-relay vulnerability, and a fill-and-dump vulnerability, with the mempool size limit. That's not evidence that Core actually cares much about "free" relay. > > Did you actually read my One-Shot RBFR proposal? > > Yes. It didn't provide any examples of RBFr free relay and I wanted to > see whether a basic RBFr free relay attack would use significantly more, > significantly less, or about the same amount of bandwidth per dollar > spent as other free relay attacks. My conclusion is that it's about the > same. Good. So you basically agree with me that RBFR does _not_ significantly change the status quo. I'll respond to the specifics of your RBFR analysis separately; it does *not* apply to one-shot RBFR. > > Weak blocks are not a solution to any of the "free" relay attacks I've > > disclosed and your source does not claim that they are a "free" relay > > solution. > > It does not explicitly say that, but it does say: "bonus use-cases: > “Forcible insertion” of transactions that are incentive-compatible but > violate anti-DoS rules". > > For example, in some of the scenarios you describe, the attacker sends > an appealing transaction to miners and then sends less appealing > versions of that transaction to relay nodes. If the appealing > transaction enters the top mempool and gets included in a weak block, > relay nodes will stop relaying less appealing variations minutes to > hours before they otherwise would. Yes, "minutes to hours". Transactions relay on the order of seconds to tens of seconds. Weak blocks simply aren't relevant. Also, the attacks I've described are ones that can be pulled off by having a tiny minority of hash power mine a double spend. Weak blocks don't help you there, as that tiny minority isn't likely to even find a weak block. > Weak blocks also provide a decentralized DoS-resistant mechanism for > voluntarily communicating all sorts of information from miners to other > miners and relay nodes. That makes them an excellent tool for resolving > any attack that depends on miners and relay nodes having a divergent set > of transactions. For weak blocks to be a solution, you at minimum need to take away the ability of miners to choose what transactions they mine. For example, consider the scenario where you do a "free" relay attack by broadcasting transactions that OCEAN rejects, and then double-spending them via OCEAN _after_ the transactions have been broadcast. Equally, you'd need to take away the ability of RBFR miners to do the revenue maximizing thing: mining RBFR replacements. I'll also second Antoine Riard's objections to this class of idea in general: you're really proposing a secondary pseudo-consensus mechanism to solve the problems in your first pseud-consensus mechanism. > > 1) Have you've read my One Shot RBFR proposal? In particular, my > > analysis of DoS attacks *including* existing DoS attacks like > > simultaneous broadcast. > > > > 2) Do you agree or disagree with me that these existing DoS attacks > > are real? > > Yes, I've read your proposal, and I agree those attacks are plausible. > In my mind, the major difference between those free relay attacks > and RBFR free relay attacks is how solvable they are. > > I think it's easy to sketch a significant mitigation to all free relay > attacks (including RBFR): > > - Reduce the maximum size of both relayable transactions and in-mempool > packages, e.g. from 100,000 vbytes to 1,000 vbytes. > > - Reduce the maximum size of the mempool, e.g. from 300 MB to 10 MB. > > - Increase the default mempool feerate floor, e.g. from e.g. from 1 > sat/vb to 100 sat/vb. > > That would break relay of many existing presigned transactions, > potentially leading to money loss, and would break other existing > usecases, not to mention introduce other problems. However, I think > it's sufficient to prove that a mitigation to free relay is possible > without rendering the network unusable. The irony here is you've almost described a _good_ mitigation to "free" relay attacks: just reduce the size of the default mempool. A big reason why we have "free" relay attacks right now is because we allow transactions to be broadcast that are uneconomical to mine; if you limit transaction broadcast to transactions that are economical to mine in the near future, relay is more expensive. For miners, you can make a decent argument that they want to have on-hand a big backlog of transactions in case mempools empty out; in my conversations with miners almost all of them claim they run with much larger than default mempools (eg >1GB). I've even discussed mempool emptying attacks and RBFR in this context with miners: they didn't think they were an issue as replacing their mempools was absurdly expensive. Fee estimation of course can make use of knowing what backlog of transactions exist. But I'm sure only a small minority of nodes do fee estimation. A variant of this solution would be to just pick the minimum relay fee to be some number N blocks worth of transactions "back" from the highest fee-rate tip of the mempool. Obviously, this will be easier to implement with a cluster mempool, and requires package relay for the CPFP case. > Of course, an ideal solution wouldn't require placing any additional > constraints on mempool policy. For the case of free relay due to > divergent mempool policies, maybe it's something that could be done with > transaction set reconciliation (~erlay), functions for allowing Erlay (and transaction set reconciliation in general) does not help you reconcile conflicting transactions. It simply lets you efficiently learn about the total set of known transactions. Notice how the Erlay is based on WTXIDs, and the BIP doesn't even talk about dealing with conflicts. > independent nodes to come to consistent conclusions about the best > revenue set of transactions (~cluster mempool), That's quite irrelevant as RBFR _is_ the highest revenue policy in lots of situations. That's one reason why in my discussions with miners/pools, they're interested in implementing it (mining pools have very low profit margins, so every cent counts, and RBFR replacements are reasonably common already). Mining pools implemented full-RBF against the wishes of Core for the same reason: full-RBF earns you more revenue, and I made it easy to implement. Implementing one-shot RBFR is probably going to be quite a bit cleaner with cluster mempools, as it'll provide a nice way to rapidly determine what the minimum economic fee-rate is to get into the next (N) blocks. (though you can do this in a less clean way by just periodically assembling a trial block and recording the value, or using the fee estimation code) Finally, why are clusters even relevant to "free" relay? Most "free" relay attacks don't even need transaction packages. The really boring and unsolvable "free" relay attack of simply broadcasting large transactions that conflict with small ones is done with single transaction packages. > P2P relay of non-obvious > cluster linearizations[1], and miners voluntarily committing to their > mempool contents in candidate blocks and P2P relaying those commitments > in weak blocks. As I explained above, weak blocks is not a "free" relay solution. > Innovations like that don't work for RBFR. If mempool policy is kept > the same, free relay attacks with RBFR remain equally effective no > matter what mechanisms we implement to improve preconsensus consistency. I could also argue that magic ponies will solve "free" relay. We have to weight that hope with the likelyhood it will happen; none of the technical advancements you have mentioned even come close. Anyway, I'll reply to the rest of your other email separately. -- https://petertodd.org 'peter'[:-1]@petertodd.org -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/Zp1utYduhnWf4oA4%40petertodd.org.