Author: Matt Corallo 2019-10-25 17:30:41
Published on: 2019-10-25T17:30:41+00:00
The discussion revolves around the recently released RC for bitcoind 0.19, which includes a carve-out rule to pave the way for more robust CPFP of on-chain contracts (Lightning commitment transactions). Johan Torås Halseth suggests relaxing some of the current limits to avoid adding a 1 CSV to all outputs. Matt Corallo responds that the rule still requires at least one non-CSV output per party. Rusty Russell proposes a simplified RBF where 'you can replace if 1. feerate is higher, 2. new tx is in first 4Msipa of mempool, 3. old tx isn't'. It allows someone 100k of free tx spam. The lightning close algorithm would be:1. Give bitcoind unilateral close.2. Ask bitcoind what current expedited fee is (or survey your mempool).3. Give bitcoind child "push" tx at that total feerate.4. If next block doesn't contain unilateral close tx, go to step 2.In effect, an attacker could exceed the MAX_PACKAGE_VIRTUAL_SIZE limit in some cases, but this seems like a problem with the current mempool acceptance code in bitcoind. There have been several changes to the acceptance code and eviction policy since the limit was first introduced.
Updated on: 2023-05-20T18:30:20.689855+00:00