📅 Original date posted:2018-11-25
📝 Original message:
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?[1]
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).
-Dave
[1] 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181125/c4adf28a/attachment.sig>;
David A. Harding [ARCHIVE] /
npub16d…x4wrd
2023-06-09 12:53:03
in reply to nevent1q…lgvk
Author Public Key
npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrdPublished at
2023-06-09 12:53:03Event JSON
{
"id": "fba6dd7d1be8dfdc0c4e4d860f80c06272eb0e2f2623869f2765201607656e32",
"pubkey": "d3574a24208f4e3d0821bb4a69a0c3ae842043d444fa5c4a8c49c369918a6fb2",
"created_at": 1686315183,
"kind": 1,
"tags": [
[
"e",
"61bdb1113c2be407a2b6f72754d78bf88b3bb4d02794bc6282368d740c0e6130",
"",
"root"
],
[
"e",
"9d475db1e90a7986a479bc5ecb56b600118d371100b180bdb1bbd645e9a72315",
"",
"reply"
],
[
"p",
"cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba"
]
],
"content": "📅 Original date posted:2018-11-25\n📝 Original message:\nOn Wed, Nov 21, 2018 at 12:47:17PM +1030, Rusty Russell wrote:\n\u003e I'm also starting to implement this, to see what I missed!\n\u003e \n\u003e - Feerate is fixed at 253 [satoshis per 1,000 weight]\n\nIIUC, this is just over Bitcoin Core's default minimum relay fee of\n0.00001000 BTC/vByte. That works right now, as mempools are nowhere\nnear full, but if they fill up again and the BIP133 feefilters are\nincreased by any amount, nodes will no longer relay transactions with\nminimum feerates.\n\nIn that case, how does the commitment transaction get relayed in order\nfor its `to_*_pushme` outputs to be spent for CPFP fee bumping?[1]\n\nThere's currently some text in the PR about using\nsighash_single|sighash_anyonecanpay for use with RBF, but I don't think\nthat can apply to spending the commitment transaction, as that would\nallow not just adding new inputs and outputs, but also removing all but\nthe 'singled' output (allowing theft of its value).\n\n-Dave\n\n[1] I don't think Bitcoin Core currently relays transaction packages\nconsisting of parents below the relay fee limit and children\nsufficiently above the limit to pay for their parents. This has\ncertainly been discussed, so maybe I'm wrong and it is available or\nmaybe it'll be available in the future.\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 833 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181125/c4adf28a/attachment.sig\u003e",
"sig": "0231d90a3b9b4209487e5c487c9018a2c1af9456b2cf8c3311f6db2ea2bb3f21e4762d277a30f922e53fd509fa2f2f63945e245daa04e75b7a7356f7e7fa5efb"
}