Author: Matt Corallo 2019-01-07 15:18:52
Published on: 2019-01-07T15:18:52+00:00
The email exchange between Rusty Russell and Matt Corallo discusses the issue of RBF-pinning, which allows a transactor to mark their transactions as "likely-to-be-RBF'ed" to prevent attacks. In order to ensure that such attacks are not possible to pull off consistently, children of such transactions would be rejected unless the resulting package would be "near the top of the mempool." However, this proposal is less convincing due to the difficulty of defining a "near the top of the mempool" criteria. Lightning's requirements differ from the original problem, as they need certainty that the transaction in question confirms by some deadline rather than a high probability that it will confirm soon. As for package relay, there might be a simpler solution for this specific case, but it depends on the scope of that design. The proposal seems like a hack, but it is a hack at the boundary condition where packages meet local anti-DoS rules in violation of the "incentive compatible" goal anyway. This proposal is very different and isn't incentive compatible if blocks come in a bit fast for an hour or two, as all of a sudden that "near the top of the mempool" criteria makes no sense and you should have accepted the new transaction(s). Regarding the reduction of the problem that the current lightning proposal adds to the UTXO set with two anyone-can-spend txs for 1000 satoshis, Rusty suggests allowing a simple single P2WSH(OP_TRUE) output, or, with IsStandard changed, a literal OP_TRUE. Meanwhile, the proposal clearly relies on some form of package relay, which comes with its own challenges. Nonetheless, Rusty believes that this could be done client-side by doing a quick check if the transaction is above 250 satoshi per kweight but below minrelayfee, putting it in a side-cache with a 60-second timeout sweep. If something comes in which depends on it, which is above minrelayfee, then process them as a pair.
Updated on: 2023-05-20T18:28:42.619741+00:00