[Lightning-dev] [PATCH] First draft of option_simplfied_commitment
lf-lists at mattcorallo.com
Sun Nov 25 19:02:55 UTC 2018
Indeed, this change assumes (a) the change in relay policy around CPFP
that is discussed on this thread, and (b) some kind of (at least very
basic) package relay in Bitcoin Core. (a) requires some discussion, but
people seem at least not entirely against it when I've discussed it with
people, and should be easy to implement, (b) requires a bunch more work,
but has been a longstanding goal for a while.
On 11/25/18 6:47 PM, David A. Harding wrote:
> On Wed, Nov 21, 2018 at 12:47:17PM +1030, Rusty Russell wrote:
>> I'm also starting to implement this, to see what I missed!
>> - Feerate is fixed at 253 [satoshis per 1,000 weight]
> IIUC, this is just over Bitcoin Core's default minimum relay fee of
> 0.00001000 BTC/vByte. That works right now, as mempools are nowhere
> near full, but if they fill up again and the BIP133 feefilters are
> increased by any amount, nodes will no longer relay transactions with
> minimum feerates.
> In that case, how does the commitment transaction get relayed in order
> for its `to_*_pushme` outputs to be spent for CPFP fee bumping?
> There's currently some text in the PR about using
> sighash_single|sighash_anyonecanpay for use with RBF, but I don't think
> that can apply to spending the commitment transaction, as that would
> allow not just adding new inputs and outputs, but also removing all but
> the 'singled' output (allowing theft of its value).
>  I don't think Bitcoin Core currently relays transaction packages
> consisting of parents below the relay fee limit and children
> sufficiently above the limit to pay for their parents. This has
> certainly been discussed, so maybe I'm wrong and it is available or
> maybe it'll be available in the future.
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
More information about the Lightning-dev