Mempool Incentive Compatibility

Mempool Incentive Compatibility

Original Postby rustyrussell

Posted on: March 19, 2024 02:18 UTC

In the discussion of transaction protocols, particularly those relevant to lightning networks, there's a consideration for applying restrictions on carve-outs.

However, these restrictions might only be suitable for specific cases and not for general protocols. One key point raised involves the Replace-By-Fee (RBF) mechanism, specifically its second rule which prohibits transactions with other unconfirmed inputs. This rule aims to eliminate the necessity of evaluating entire transaction packages, but it appears that there are workarounds, such as initiating a transaction based on another unconfirmed transaction, effectively bypassing this restriction.

The conversation suggests an alternative approach might involve limiting the RBF bypass rule exclusively to version 3 (v3) transactions, though it's acknowledged that this might not entirely address the underlying issue. Another proposal is to refine Rule 2 by introducing a more complex requirement. This new stipulation would necessitate that any new transaction package seeking to replace an existing one must offer a higher bid. Such a change aims to ensure fairness and efficiency in the transaction process, potentially mitigating the challenges posed by the current implementation of the RBF rules.