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). ------------------------------------------------------------------------------ _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development