Matt Corallo <lf-li...@mattcorallo.com> writes: > I think this needs significantly improved motivation/description. A few areas > I'd like to see calculated out: > > 1) wrt rule 3, for this to be > obviously-incentive-compatible-for-the-next-miner, I'd think no evicted > transactions would be allowed to be in the next block range. This would > probably require some significant additional tracking in today's mempool > logic.
This is a good question, which is why I really wanted to look into the implementation details. There are some approximations possible wrt. pre- and post- tx bundle feerate, but they have to be examined closely. > 2) wrt rule 4, I'd like to see a calculation of worst-case free relay. I > think we're already not in a great place, but maybe it's worth it or maybe > there is some other way to reduce this cost (intuitively it looks like this > proposal could make things very, very, very bad). I *think* you can currently create a tx at 1 sat/byte, have it propagate, then RBF it to 2 sat/byte, 3... and do that a few thousand times before your transaction gets mined. If that's true, I don't think this proposal makes it worse. >> 3) wrt rule 5, I'd like to see benchmarks, it's probably a pretty nasty DoS >> attack, but it may also be the case that is (a) not worse than other >> fundamental issues or (b) sufficiently expensive. I thought we still meet rule 5 in practice since bitcoind will never even accept a tree of unconfirmed txs which is > 100 txs? That would still stand, it's just that we'd still consider a replacement. > 4) As I've indicated before, I'm generaly not a fan of such vague > protections for time-critical transactions such as payment channel > punishment transactions. The bitcoin network offers no propagation guarantees; it's all best effort anyway. This makes it no worse, and we can tunnel txs through the lightning network if we have to. > At a high-level, in this context your counterparty's transactions (not to > mention every other transaction in everyone's mempool) are still involved in > the decision about whether to accept an RBF, in contrast to previous > proposals, which makes it much harder to reason about. As a specific example, > if an attacker exploits mempool policy differences they may cause your > concept of "top 4M weight" to be bogus for a subeset of nodes, causing > propogation to be limited. If miners have a conflicting tx in the top 4MSipa, you don't have a problem. So an attacker needs to limit propagation in a way which isolates the miners from either the new tx or the conflicting one, which is much harder. > Obviously there is also a ton more client-side knowledge required and > complexity to RBF decisions here than other previous, more narrowly-targeted > proposals. Define client-side here? I'd say from the lightning side it's as simple as a normal RBF policy until you get within a few blocks of a deadline, then you increase the fees until it's well within reach of the next block. You can even approximate this by looking at fees on the previous block, with some care for outliers. > (I don't think this one use-case being not optimal should prevent such a > proposal, i agree it's quite nice for some other cases). I like that it's conceptually simple and inventive-robust, and doesn't really rely on bitcoind's internal policy mechanics of RBF. I think in the longer term we're going to need other mechanisms for restricting abusive propagation anyway, but that's a bit out-of-scope. Thanks! Rusty. _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
