📅 Original date posted:2022-01-31
📝 Original message:On Mon, Jan 31, 2022 at 04:57:52PM +0100, Bastien TEINTURIER via bitcoin-dev wrote:
> I'd like to propose a different way of looking at descendants that makes
> it easier to design the new rules. The way I understand it, limiting the
> impact on descendant transactions is only important for DoS protection,
> not for incentive compatibility. I would argue that after evictions,
> descendant transactions will be submitted again (because they represent
> transactions that people actually want to make),
I think that's backwards: we're trying to discourage people from wasting
the network's bandwidth, which they would do by publishing transactions
that will never get confirmed -- if they were to eventually get confirmed
it wouldn't be a waste of bandwith, after all. But if the original
descendent txs were that sort of spam, then they may well not be
submitted again if the ancestor tx reaches a fee rate that's actually
likely to confirm.
I wonder sometimes if it could be sufficient to just have a relay rate
limit and prioritise by ancestor feerate though. Maybe something like:
- instead of adding txs to each peers setInventoryTxToSend immediately,
set a mempool flag "relayed=false"
- on a time delay, add the top N (by fee rate) "relayed=false" txs to
each peer's setInventoryTxToSend and mark them as "relayed=true";
calculate how much kB those txs were, and do this again after
SIZE/RATELIMIT seconds
- don't include "relayed=false" txs when building blocks?
- keep high-feerate evicted txs around for a while in case they get
mined by someone else to improve compact block relay, a la the
orphan pool?
That way if the network is busy, any attempt to do low fee rate tx spam
will just cause those txs to sit as relayed=false until they're replaced
or the network becomes less busy and they're worth relaying. And your
actual mempool accept policy can just be "is this tx a higher fee rate
than the txs it replaces"...
> Even if bitcoin core releases a new version with updated RBF rules, as a
> wallet you'll need to keep using the old rules for a long time if you
> want to be safe.
All you need is for there to be *a* path that follows the new relay rules
and gets from your node/wallet to perhaps 10% of hashpower, which seems
like something wallet providers could construct relatively quickly?
Cheers,
aj
Anthony Towns [ARCHIVE] /
npub17r…x9l2h
2023-06-07 23:03:10
in reply to nevent1q…83lr
Author Public Key
npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2hPublished at
2023-06-07 23:03:10Event JSON
{
"id": "92a0feb9205b0f719ed8b7395b904736e00db02e78c2f8dd67c3bd4f43778479",
"pubkey": "f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab",
"created_at": 1686178990,
"kind": 1,
"tags": [
[
"e",
"71aa4103a9ee18292e86ffa3579e1f8f9dd5d48d8a9656c877d724e3219f53f4",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2022-01-31\n📝 Original message:On Mon, Jan 31, 2022 at 04:57:52PM +0100, Bastien TEINTURIER via bitcoin-dev wrote:\n\u003e I'd like to propose a different way of looking at descendants that makes\n\u003e it easier to design the new rules. The way I understand it, limiting the\n\u003e impact on descendant transactions is only important for DoS protection,\n\u003e not for incentive compatibility. I would argue that after evictions,\n\u003e descendant transactions will be submitted again (because they represent\n\u003e transactions that people actually want to make),\n\nI think that's backwards: we're trying to discourage people from wasting\nthe network's bandwidth, which they would do by publishing transactions\nthat will never get confirmed -- if they were to eventually get confirmed\nit wouldn't be a waste of bandwith, after all. But if the original\ndescendent txs were that sort of spam, then they may well not be\nsubmitted again if the ancestor tx reaches a fee rate that's actually\nlikely to confirm.\n\nI wonder sometimes if it could be sufficient to just have a relay rate\nlimit and prioritise by ancestor feerate though. Maybe something like:\n\n - instead of adding txs to each peers setInventoryTxToSend immediately,\n set a mempool flag \"relayed=false\"\n\n - on a time delay, add the top N (by fee rate) \"relayed=false\" txs to\n each peer's setInventoryTxToSend and mark them as \"relayed=true\";\n calculate how much kB those txs were, and do this again after\n SIZE/RATELIMIT seconds\n\n - don't include \"relayed=false\" txs when building blocks?\n\n - keep high-feerate evicted txs around for a while in case they get\n mined by someone else to improve compact block relay, a la the\n orphan pool?\n\nThat way if the network is busy, any attempt to do low fee rate tx spam\nwill just cause those txs to sit as relayed=false until they're replaced\nor the network becomes less busy and they're worth relaying. And your\nactual mempool accept policy can just be \"is this tx a higher fee rate\nthan the txs it replaces\"...\n\n\u003e Even if bitcoin core releases a new version with updated RBF rules, as a\n\u003e wallet you'll need to keep using the old rules for a long time if you\n\u003e want to be safe.\n\nAll you need is for there to be *a* path that follows the new relay rules\nand gets from your node/wallet to perhaps 10% of hashpower, which seems\nlike something wallet providers could construct relatively quickly?\n\nCheers,\naj",
"sig": "f59834db0f0779f704cd4876de64d14d079189a393e901936f018e4bc862ceb9d3ed2f5b82fe233795331443b7b473288314803c710b8a9cb8113713b16a91fb"
}