📅 Original date posted:2013-10-30
📝 Original message:On Sun, Oct 27, 2013 at 7:32 AM, Mike Hearn <mike at plan99.net> wrote:
> I'm really looking forward to this. Currently bitcoinj gets a small but
> steady stream of bug reports of the form "my transaction did not propagate".
> It's flaky because the library picks one peer to send the transaction to,
> and then watches it propagate across the network. But if that selected peer
> refuses the tx for whatever reason, that propagation never comes, and
Actually, we'll probably need to explicitly document that a failure to
reject is by no means a promise to forward.
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.
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.
Gregory Maxwell [ARCHIVE] /
npub1f2…crwet
2023-06-07 15:08:10
in reply to nevent1q…tsyy
Author Public Key
npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetPublished at
2023-06-07 15:08:10Event JSON
{
"id": "c7643facebe4090f092fdef109250ef7bcd137da3cafaed553e44f30aff49efc",
"pubkey": "4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73",
"created_at": 1686150490,
"kind": 1,
"tags": [
[
"e",
"3817326e0aa3f4776a8ff8e7526de3607739981db781c73ec645db4eafebe42c",
"",
"root"
],
[
"e",
"119040a36312b9f8d61ead562bed8ac21678347df61e21c6056a9b093333decf",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 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.",
"sig": "cce35469ef5315d35ac8784fd7e3c3031ed6ddc95c2e194410f3edcf8d72759d61b8af808bdf9faeb626b7a34806bc2108379fc5b6fbaae09fe722c24ec553fd"
}