{"type":"rich","version":"1.0","author_name":"npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","author_url":"https://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2013-10-31\n📝 Original message:On Wed, Oct 30, 2013 at 6:13 PM, Gregory Maxwell \u003cgmaxwell at gmail.com\u003e wrote:\n\n\u003e If a node is using priority queued rate limiting for its relaying then\n\u003e it might \"accept\" a transaction from you, but have it fall out of its\n\u003e memory pool (due to higher priority txn arriving, or getting\n\u003e restarted, etc.) before it ever gets a chance to send it on to any\n\u003e other peers.\n\u003e\n\nThat's a good point, however, I would hope that this fairly trivial race\ncondition can be resolved. There's no requirement that a transaction be\nplaced into a buffer from which it can be removed before relaying. After\nrelaying - sure. But the gap of a few seconds between that shouldn't cause\nany issues to eliminate.\n\nI believe Gavin's smartfees branch adds mempool persistence to disk, so\nrestarting nodes won't clear the mempool in future. Or at least that's a\npart of the longer term plan once mempool limiting is done.\n\n\n\u003e Finding out that it rejected is still useful information, but even\n\u003e assuming all nodes are honest and well behaved I don't think you could\n\u003e count on its absence to be sure of forwarding.\n\u003e\n\nI think measuring propagation will be a part of bitcoin wallets for the\nforseeable future, although if all nodes reject that allows for a more\nresponsive and more helpful UI than just waiting for some arbitrary timeout\nto elapse.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131031/61485d73/attachment.html\u003e"}