{"type":"rich","version":"1.0","author_name":"npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","author_url":"https://nostr.ae/npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2013-10-30\n📝 Original message:On Sun, Oct 27, 2013 at 7:32 AM, Mike Hearn \u003cmike at plan99.net\u003e wrote:\n\u003e I'm really looking forward to this. Currently bitcoinj gets a small but\n\u003e steady stream of bug reports of the form \"my transaction did not propagate\".\n\u003e It's flaky because the library picks one peer to send the transaction to,\n\u003e and then watches it propagate across the network. But if that selected peer\n\u003e refuses the tx for whatever reason, that propagation never comes, and\n\nActually, we'll probably need to explicitly document that a failure to\nreject is by no means a promise to forward.\n\nIf a node is using priority queued rate limiting for its relaying then\nit might \"accept\" a transaction from you, but have it fall out of its\nmemory pool (due to higher priority txn arriving, or getting\nrestarted, etc.) before it ever gets a chance to send it on to any\nother peers.\n\nFinding out that it rejected is still useful information, but even\nassuming all nodes are honest and well behaved I don't think you could\ncount on its absence to be sure of forwarding."}