📅 Original date posted:2015-06-11
📝 Original message:On 6/11/2015 6:10 AM, Peter Todd wrote:
> On Wed, Jun 10, 2015 at 02:18:30PM -0700, Aaron Voisine wrote:
>> The other complication is that this will tend to be a lagging indicator
>> based on network congestion from the last time you connected. If we assume
>> that transactions are being dropped in an unpredictable way when blocks are
>> full, knowing the network congestion *right now* is critical, and even then
>> you just have to hope that someone who wants that space more than you do
>> doesn't show up after you disconnect.
> Hence the need for ways to increase fees on transactions after initial
> broadcast like replace-by-fee and child-pays-for-parent.
>
> Re: "dropped in an unpredictable way" - transactions would be dropped
> lowest fee/KB first, a completely predictable way.
Quite agreed. Also, transactions with unconfirmed inputs should be
among the first to get dropped, as discussed in the "Dropped-transaction
spam" thread. Like all policy rules, either of these works in
proportion to its deployment.
Be advised that pull request #6068 emphasizes the view that the network
will never have consistent mempool/relay policies, and on the contrary
needs a framework that supports and encourages pluggable, generally
parameterized policies that could (some might say should) conflict
wildly with each other.
It probably doesn't matter that much. Deploying a new policy still
wouldn't be much easier than deploying a patched version. I mean,
nobody has proposed a policy rule engine yet (oops).
Tom Harding [ARCHIVE] /
npub1ms…pmwjy
2023-06-07 15:37:20
in reply to nevent1q…4gcj
Author Public Key
npub1msef5qkfwz4t7qacwxz775wgdtlytph78g2g2z903x90874u263sypmwjyPublished at
2023-06-07 15:37:20Event JSON
{
"id": "1a0d3cdaee524e7ba35947febc92089656d589dc98b343880d485d11794d9565",
"pubkey": "dc329a02c970aabf03b87185ef51c86afe4586fe3a148508af898af3fabc56a3",
"created_at": 1686152240,
"kind": 1,
"tags": [
[
"e",
"e5c5b327043fce5d06c04d5d47b9e1bc42816638599cdc94c838afd2a20dc49c",
"",
"root"
],
[
"e",
"3981542ecf780e32eb14e01188dd6efa6193680c916dbd3ab7c6b5f7390b2d39",
"",
"reply"
],
[
"p",
"ddea23b6169366c61b6830c8077177c91a1fa9b4106e13c8abbe23284f300f5e"
]
],
"content": "📅 Original date posted:2015-06-11\n📝 Original message:On 6/11/2015 6:10 AM, Peter Todd wrote:\n\u003e On Wed, Jun 10, 2015 at 02:18:30PM -0700, Aaron Voisine wrote:\n\u003e\u003e The other complication is that this will tend to be a lagging indicator\n\u003e\u003e based on network congestion from the last time you connected. If we assume\n\u003e\u003e that transactions are being dropped in an unpredictable way when blocks are\n\u003e\u003e full, knowing the network congestion *right now* is critical, and even then\n\u003e\u003e you just have to hope that someone who wants that space more than you do\n\u003e\u003e doesn't show up after you disconnect.\n\u003e Hence the need for ways to increase fees on transactions after initial\n\u003e broadcast like replace-by-fee and child-pays-for-parent.\n\u003e\n\u003e Re: \"dropped in an unpredictable way\" - transactions would be dropped\n\u003e lowest fee/KB first, a completely predictable way.\n\nQuite agreed. Also, transactions with unconfirmed inputs should be \namong the first to get dropped, as discussed in the \"Dropped-transaction \nspam\" thread. Like all policy rules, either of these works in \nproportion to its deployment.\n\nBe advised that pull request #6068 emphasizes the view that the network \nwill never have consistent mempool/relay policies, and on the contrary \nneeds a framework that supports and encourages pluggable, generally \nparameterized policies that could (some might say should) conflict \nwildly with each other.\n\nIt probably doesn't matter that much. Deploying a new policy still \nwouldn't be much easier than deploying a patched version. I mean, \nnobody has proposed a policy rule engine yet (oops).",
"sig": "3dbd77df59c22db584d66eea9517a19ee55261ba6d66393238b919c71e100e64a1706c0f697861e5c404bd8b63bdcfe27622974f83e49a1c3a929b29500e6b39"
}