Tom Harding [ARCHIVE] on Nostr: 📅 Original date posted:2015-06-11 📝 Original message:On 6/11/2015 6:10 AM, ...
📅 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).
📝 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).