[Bitcoin-development] Feedback requested: "reject" p2p message

Mike Hearn mike at plan99.net
Thu Oct 31 12:01:37 UTC 2013


On Wed, Oct 30, 2013 at 6:13 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:

> If a node is using priority queued rate limiting for its relaying then
> it might "accept" a transaction from you, but have it fall out of its
> memory pool (due to higher priority txn arriving, or getting
> restarted, etc.) before it ever gets a chance to send it on to any
> other peers.
>

That's a good point, however, I would hope that this fairly trivial race
condition can be resolved. There's no requirement that a transaction be
placed into a buffer from which it can be removed before relaying. After
relaying - sure. But the gap of a few seconds between that shouldn't cause
any issues to eliminate.

I believe Gavin's smartfees branch adds mempool persistence to disk, so
restarting nodes won't clear the mempool in future. Or at least that's a
part of the longer term plan once mempool limiting is done.


> Finding out that it rejected is still useful information, but even
> assuming all nodes are honest and well behaved I don't think you could
> count on its absence to be sure of forwarding.
>

I think measuring propagation will be a part of bitcoin wallets for the
forseeable future, although if all nodes reject that allows for a more
responsive and more helpful UI than just waiting for some arbitrary timeout
to elapse.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131031/61485d73/attachment.html>


More information about the bitcoin-dev mailing list