rich1.0npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydhttps://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydnjumphttps://nostr.ae📅 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>