Matt Corallo <lf-li...@mattcorallo.com> writes: > Ultimately, defining a "near the top of the mempool" criteria is fraught > with issues. While it's probably OK for the original problem (large > batched transactions where you don't want a single counterparty to > prevent confirmation), lightning's requirements are very different. > Instead is wanting a high probability that the transaction in question > confirms "soon", we need certainty that it will confirm by some deadline.
I don't think it's different, in practice. > Thus, even if you imagine a steady-state mempool growth, unless the > "near the top of the mempool" criteria is "near the top of the next > block" (which is obviously *not* incentive-compatible) I was defining "top of mempool" as "in the first 4 MSipa", ie. next block, and assumed you'd only allow RBF if the old package wasn't in the top and the replacement would be. That seems incentive compatible; more than the current scheme? The attack against this is to make a 100k package which would just get into this "top", then push it out with a separate tx at slightly higher fee, then repeat. Of course, timing makes that hard to get right, and you're paying real fees for it too. Sure, an attacker can make you pay next-block high fees, but it's still better than our current "*always* overpay and hope!", and you can always decide at the time based on whether the expiring HTLC(s) are worth it. But I think whatever's simplest to implement should win, and I'm not in a position to judge that accurately. Thanks, Rusty. _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
