During off-channel discussion, Suhas made a great point that even with fullrbf, you can get stuck by bip125 rule#5 pinning if an adversary controls a number of inputs(4 with default mempool settings).
Implication being, while we can mitigate rule#3 damage potentially with fullrbf, we cannot actually make promises about mempool entry beyond quite small transaction sizes. Adversary has to make 100 transactions, 4 chains of 25, but it achieves the original pin. On Thu, Oct 27, 2022 at 1:44 PM Greg Sanders <gsander...@gmail.com> wrote: > > For instance, the double-spend could be low-feerate and large, and > effectively pin any attempt to replace it. > > Yes, this is the biggest hole left. You *could* replace it with RBF when > before you simply could not, so perhaps the pinning door is slightly > smaller in scenarios where going feerates are significantly higher than min. > > > Or it could be higher feerate and confirm and B/C have to start all over. > > Coinjoins have "blame rounds" exactly for this. Ruling out the above hole > where you don't want to pay the 100kvb rule#3 penalty, you can kick the > griefer out. Without replacement, you likely can not. > > > Or, A could stall things in the signing phase and B/C have to figure out > when to give up on the channel with A. > > Again, blame rounds solve this. > > So to recap, it makes it *possible* to over-bid your griefer, vs simply > not able to and have funds tied up for weeks(or guess you're being pinned > and double-spend your input, which again looks blame-worthy). > > Properly replacing rule#3 would give these protocols higher assurances, > but this is where we're at now. > > On Thu, Oct 27, 2022 at 1:35 PM Suhas Daftuar via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> I have more to say on this broader topic, but since you've brought up >> this particular example I think it's worth commenting: >> >> On Thu, Oct 27, 2022 at 1:23 PM Anthony Towns via bitcoin-dev < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> >>> Is that true? Antoine claims [1] that opt-in RBF isn't enough to avoid >>> a DoS issue when utxos are jointly funded by untrusting partners, and, >>> aiui, that's the main motivation for addressing this now. >>> >>> [1] >>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html >>> >>> The scenario he describes is: A, B, C create a tx: >>> >>> inputs: A1, B1, C1 [opts in to RBF] >>> fees: normal >>> outputs: >>> [lightning channel, DLC, etc, who knows] >>> >>> they all analyse the tx, and agree it looks great; however just before >>> publishing it, A spams the network with an alternative tx, double >>> spending her input: >>> >>> inputs: A1 [does not opt in to RBF] >>> fees: low >>> outputs: A >>> >>> If A gets the timing right, that's bad for B and C because they've >>> populated their mempool with the 1st transaction, while everyone else >>> sees the 2nd one instead; and neither tx will replace the other. B and >>> C can't know that they should just cancel their transaction, eg: >>> >>> inputs: B1, C1 [opts in to RBF] >>> fees: 50% above normal >>> outputs: >>> [smaller channel, refund, whatever] >>> >>> and might instead waste time trying to fee bump the tx to get it mined, >>> or similar. >>> >>> What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to >>> solve that problem if they have only opt-in RBF available? >>> >> >> I think this is not a real example of a DoS vector that is available >> because we support non-rbf signaling transactions. Even in a world where >> all transactions are replaceable, person A could double-spend their input >> in a way that is annoying for B and C. For instance, the double-spend >> could be low-feerate and large, and effectively pin any attempt to replace >> it. Or it could be higher feerate and confirm and B/C have to start all >> over. Or, A could stall things in the signing phase and B/C have to figure >> out when to give up on the channel with A. >> >> So I find this example to be unconvincing. Are there any other examples >> where having a non-replacement policy for some transactions causes problems >> for protocols people are trying to build? >> >> Thanks, >> Suhas >> _______________________________________________ >> 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
