📅 Original date posted:2020-08-07
📝 Original message:When you say that a special relay network might be more "smart about
replacement" in the context of ANYPREVOUT*, do you mean these nodes could
RBF parts of a package like this:
Given:
- Package A = UpdateTx_A(n=1): txin: AnchorTx, txout: SettlementTx_A(n=1)
-> HtlcTxs(n=1)_A -> .chain of transactions that pin UpdateTx_A(n=1) with
high total fee, etc.
And a new package with higher fee rate versions of ANYPREVOUT* transactions
in the package, but otherwise lower total fee:
- Package B = UpdateTx_B(n=1): txin: AnchorTx, txout: SettlementTx_B(n=1)
-> HtlcTxs(n=1)_B -> low total fee package
Relay just the higher up-front fee-rate transactions from package B which
get spent by the high absolute fee child transactions from package A:
- Package A' = UpdateTx_B(n=1): txin: AnchorTx, txout: SettlementTx_B(n=1)
-> HtlcTxs(n=1)_A -> ...chain of up to 25 txs that pin UpdateTx(n=1) with
high total fee, etc.
On Thu, Aug 6, 2020 at 5:59 PM Matt Corallo via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> In general, SIGHASH_NOINPUT makes these issues much, much simpler to
> address, but only if we assume that nodes can
> somehow be "smart" about replacement when they see a SIGHASH_NOINPUT spend
> which can spend an output that something else
> in the mempool already spends (potentially a different input than the
> relaying node thinks the transaction should
> spend). While ideally we'd be able to shove that (significant) complexity
> into the Bitcoin P2P network, that may not be
> feasible, but we could imagine a relay network of lightning nodes doing
> that calculation and then passing the
> transactions to their local full nodes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200807/79ab9202/attachment.html>;
Richard Myers [ARCHIVE] /
npub12j…hfxgj
2023-06-07 18:26:10
in reply to nevent1q…cqft
Author Public Key
npub12jllrss5nmygfhg7j9ztk2te80t96kumx7cllfc29skut6phqh5qfhfxgjPublished at
2023-06-07 18:26:10Event JSON
{
"id": "b835e43f7f7ceccf48ddf7c26786f843dc530c8262c8ededb6a4b880b9c58a24",
"pubkey": "54bff1c2149ec884dd1e9144bb29793bd65d5b9b37b1ffa70a2c2dc5e83705e8",
"created_at": 1686162370,
"kind": 1,
"tags": [
[
"e",
"b580beba13e993f0feaede9804bbc73901ee03ff94bf8b01329f909e32c379c0",
"",
"root"
],
[
"e",
"ffbf79d7ebc410d9007a967139f82508587cf7c874f2466934833bc7471a2c27",
"",
"reply"
],
[
"p",
"cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba"
]
],
"content": "📅 Original date posted:2020-08-07\n📝 Original message:When you say that a special relay network might be more \"smart about\nreplacement\" in the context of ANYPREVOUT*, do you mean these nodes could\nRBF parts of a package like this:\n\n\nGiven:\n - Package A = UpdateTx_A(n=1): txin: AnchorTx, txout: SettlementTx_A(n=1)\n-\u003e HtlcTxs(n=1)_A -\u003e .chain of transactions that pin UpdateTx_A(n=1) with\nhigh total fee, etc.\n\n\nAnd a new package with higher fee rate versions of ANYPREVOUT* transactions\nin the package, but otherwise lower total fee:\n\n - Package B = UpdateTx_B(n=1): txin: AnchorTx, txout: SettlementTx_B(n=1)\n-\u003e HtlcTxs(n=1)_B -\u003e low total fee package\n\n\nRelay just the higher up-front fee-rate transactions from package B which\nget spent by the high absolute fee child transactions from package A:\n\n - Package A' = UpdateTx_B(n=1): txin: AnchorTx, txout: SettlementTx_B(n=1)\n-\u003e HtlcTxs(n=1)_A -\u003e ...chain of up to 25 txs that pin UpdateTx(n=1) with\nhigh total fee, etc.\n\nOn Thu, Aug 6, 2020 at 5:59 PM Matt Corallo via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e In general, SIGHASH_NOINPUT makes these issues much, much simpler to\n\u003e address, but only if we assume that nodes can\n\u003e somehow be \"smart\" about replacement when they see a SIGHASH_NOINPUT spend\n\u003e which can spend an output that something else\n\u003e in the mempool already spends (potentially a different input than the\n\u003e relaying node thinks the transaction should\n\u003e spend). While ideally we'd be able to shove that (significant) complexity\n\u003e into the Bitcoin P2P network, that may not be\n\u003e feasible, but we could imagine a relay network of lightning nodes doing\n\u003e that calculation and then passing the\n\u003e transactions to their local full nodes.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200807/79ab9202/attachment.html\u003e",
"sig": "86a5c44f55058425eca4e7ddfb5b9fb55d2677cab844959c3ccd2d547f0908474a56cf937dfacfc6a745234f6475414b8fd45504b7ffe62d3024f8d28d8c3131"
}