lightning-dev
CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning)
Posted on: December 4, 2018 03:33 UTC
Matt Corallo has proposed a new solution to the Replace-by-fee (RBF) problem, which involves allowing transactors to mark their transactions as "likely-to-be-RBF'ed." This proposal would enable a relay policy where any children of such transactions would be rejected unless the resulting package would be "near the top of the mempool." While this theoretically implies that such attacks would not be possible to pull off consistently, it is still possible to do so with low probability in case of feerate spikes right after broadcast.
Corallo believes that this idea is incentive-compatible, assuming blocks are full, miners should always take a higher feerate tx if that tx would be in the current block and the replaced txs would not. Furthermore, it reduces the problem that the current lightning proposal adds to the UTXO set with two anyone-can-spend txs for 1000 satoshis, which might be too small to cleanup later. This rule would allow a simple single P2WSH(OP_TRUE) output, or, with IsStandard changed, a literal OP_TRUE.The proposal clearly relies on some form of package relay, which comes with its own challenges, but Corallo believes client-side implementation could work. In this case, a quick check would be done to see if the transaction fee is above 250 satoshi per kweight but below minrelayfee, then it would be put 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. For Lightning, child-pays-for-grandparent is not cared about.