Mike Hearn [ARCHIVE] on Nostr: 📅 Original date posted:2013-10-31 📝 Original message:On Wed, Oct 30, 2013 at ...
📅 Original date posted:2013-10-31
📝 Original message: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>;
📝 Original message: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>;