"Interesting" problem. Why is this tx not being relayed by peers?

[DeathAndTaxes]

https://blockchain.info/tx/7945140310e5e22e2d38f41eba3422e11e92719aad527e6e4a4d7b660ac5cda7?show_adv=true

The tx is large (17K) but it includes >0.1mBTC per KB in fees, it has no double spent or unconfirmed inputs, and it has no dust outputs.  The interesting thing is that the tx was sent from Bitcoin Core (v0.91).  That node does not have direct connectivity to blockchain.info so it must have been relayed by at least one peer.  The recipient node is also using Bitcoin Core v0.91 but the tx is not in the memory pool and my assumption is that the recipients peers are dropping it.  The question is why?  Possibly a difference in relaying rules on older nodes (and the recipient is unlucky enough to have all older nodes as peers?  As of the time of the post it hasn't been included in a block but I am more concerned with what would keep it from being seen as an unconfirmed tx by the recipient node.

On edit: ok it was just included in a block and the recipient node instantly recognized and reported the confirmed tx but why wasn't it relayed prior to being confirmed.

[1713462091]

1713462091

[1713462091]

1713462091

[1713462091]

1713462091

[1713462091]

1713462091

[1713462091]

1713462091

[MaxwellsDemon]

it has no dust outputs.

There's one under 5430:

1KM4q73ta9Wt4FHEr8f2pR8JtryuAo2CKV (0.00000745 BTC - Output)

[DeathAndTaxes]

Thanks but that is an input. There is no prohibition on the value of inputs only on the value of outputs (the goal is to prevent creating new dust, not preventing the "spending" of existing dust).  The tx only has a single output and it is above the dust limit.

Here is the raw transaction decoded: <Nope can't post it forum has a max limit of 64K char per post>

[MaxwellsDemon]

Thanks but that is an input. There is no prohibition on the value of inputs only on the value of outputs (the goal is to prevent creating new dust, not preventing the "spending" of existing dust).  

Hmm... For some reason I thought that 5430 rule applied for inputs too, but now that I think about it, that really wouldn't make a lot of sense.

[DannyHamilton]

I've found that if my Bitcoin Core is not connected to peers when they first receive a transaction, they don't relay that transaction to my Bitcoin Core when it eventually connects to them.

In that case, my Bitcoin Core doesn't show the transaction at all until it is in a block.

Apparently late comers to the party don't get to hear all the gossip that occurred before they arrived (so to speak).

Any chance that your receiver started up their Bitcoin Core after you had already sent the transaction?

I've also noticed if my Bitcoin Core has been off for a while, and someone sends me a transaction after I start it up (but while it's still syncing) if that transaction spends an output that was confirmed in a block that my Bitcoin Core doesn't have yet, my Bitcoin Core won't seem to recognize the transaction (I assume because the UTXO being spent appears invalid to my client).  Then a few minutes later, once my Bitcoin Core has finished syncing, it's back in that situation where no peers are relaying the transaction that they already know about, so my Bitcoin Core doesn't get to know about it until it is confirmed in a block.

Any chance that your receiver's Bitcoin Core was still syncing when you sent the transaction?

[DeathAndTaxes]

It is possible Bitcoin Core was offline or syncing when the tx was sent.  I assumed it was due to peer propagation but it could have been a client side "bug".  The fact that it instantly was reported by the receiver's wallet once the block was received is good.  Still not the best to have to explain to a new customer how their funds have been sent even though they can't see it.  Even more fun that it was some miners excluded it so it took longer before the block showed up.  This despite being near the top of the memory pool when ranked by fee per KB.

If it is a timing issue it would be nice feature if the client supported a query option.  Provide a tx id and the client will ask all its peers if they are aware of the tx.

[Coinsera]

https://blockchain.info/tx/7945140310e5e22e2d38f41eba3422e11e92719aad527e6e4a4d7b660ac5cda7?show_adv=true

The tx is large (17K) but it includes >0.1mBTC per KB in fees, it has no double spent or unconfirmed inputs, and it has no dust outputs.  The interesting thing is that the tx was sent from Bitcoin Core (v0.91).  That node does not have direct connectivity to blockchain.info so it must have been relayed by at least one peer.  The recipient node is also using Bitcoin Core v0.91 but the tx is not in the memory pool and my assumption is that the recipients peers are dropping it.  The question is why?  Possibly a difference in relaying rules on older nodes (and the recipient is unlucky enough to have all older nodes as peers?  As of the time of the post it hasn't been included in a block but I am more concerned with what would keep it from being seen as an unconfirmed tx by the recipient node.

On edit: ok it was just included in a block and the recipient node instantly recognized and reported the confirmed tx but why wasn't it relayed prior to being confirmed.

In my understanding Input and Output rule should not be different, and same will definitely work.

Thanks