Hi Dave, > 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. I think the mechanism you're describing is plagued by the following vulnerability: - an attacker mempool-partition all miners by exploiting transaction-relay asymmetries (e.g same feerate, same weight, diff txid) - an attacker broadcast an appealing transaction entering the top of mempool - a weak block up to 4MB is generated for each such miner partitioned and relayed to the rest of the network - the whole block-relay network is wasting 4 MB of block-relay bandwidth multiplied by N, the number of miners affected - the mempool-partitition transaction vector might have paid a sub-minimal feerate just to enter in mempool Bonus point: the attacker has hashrate capabilities to mine the block including the mempool-partition transaction vector rendering a null gain for the DoSed miners whatever the weak block reward mechanism for the "weak block" proposal (unless the reward is exogeneous to the bitcoin blockchain, a type of in-protocol reward one might skeptical relatively to bitcoin security model). I don't think the "weak block" proposal as you're presenting it makes sense, at the very least quantitative evaluations would be necessary to be sure you're not worsening the denial-of-service aspect. In the present layout of the "weak block" proposal, I really think you saying it's a decentralized DoS-resistant mechanism is deeply misleading and inaccurate for the rest of the community. Zooming out, I believe it's an intesresting problem wishing to improve rewarding of miners income if we wish to encourage solo miners, and improve on the initial financial liquidity incentives that are driving miners to gather themselves in pool since the early days of bitcon, though I don't see how "weak block" can be a viable solution. Best, Antoine ots hash: 85636ac4e91bc781bbcdc8c0a24a17ad1c90039c6cabbb4d3ddd334c2c29fc02 Le dimanche 21 juillet 2024 à 19:04:29 UTC+1, David A. Harding a écrit : > 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. > > > 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. > > > 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. > > 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. > > > 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. > > 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 > independent nodes to come to consistent conclusions about the best > revenue set of transactions (~cluster mempool), 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. > > 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. > > If pure RBFR is added and clever protocol developers find ways to > largely fix other free relay attacks, then devs will either need to > significantly restrict mempool policy anyway or will need to restrict or > remove RBFR to make Bitcoin Core safe. Given that, it seems to me like > a very reasonable decision not to add pure RBFR and to wait until better > tools like cluster mempool become available before evaluating > significant changes to RBF policy (like one-shot RBFR). > > Thanks, > > -Dave > > [1] > > https://github.com/bitcoinops/bitcoinops.github.io/pull/1421#discussion_r1415834695 > -- 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/1d64b24e-9ae4-4eac-b93a-c35fdcd26d6en%40googlegroups.com.