Topic: Does anyone know why 0.12.x nodes relay transactions faster than later versions? (Read 661 times)

That explains everything. Thanks.

So the tx relay delay is introduced by design and is to be expected from the new software.

No, I don't think so.
Normally I don't even send fee-filter messages.
And when I do, I'd not increase the peer's tx counter upon received tx with a fee that is too low.

I've just tested it with min-fee set to 50 SPB...
pre 0.13 are still ones to send me the most new txs.
It basically looks like this:

Just to clarify: they are only sent before being completely verified only for opportunistically sent compact blocks to peers who have specifically requested it.  (And they are not completely unverified even then, POW, presence of all the data, etc. is still checked first)


0.14 is "faster" at relaying transactions, much faster in fact, but it has higher _delay_ because the delays are intentional and older versions had a bug that bypassed the original privacy protections for transactions, and also wasted a lot of bandwidth in the process.

Nah.  Ancestor feerate handing is very efficient. It does take a little bit of time, but we have since made the rest of the processing much faster to compensate.  E.g. since 0.12 we eliminated _disk_ accesses which always happened for accepting an unconfirmed transaction to the mempool, as you can imagine that was a pretty big speedup.

Nodes are not supposed to relay transactions as fast as possible, doing so leaks the origin of transactions in the network pretty badly. It also wastes bandwidth from sending single transactions at a time in INV packets and from transactions crossing in flight.  Unfortunately performance enhancements back around maybe 0.8 or so broke the original transaction relay delays.

In recent versions transactions are queued to be advertised to peers, then sorted by dependency (to eliminate orphans) and fee-rate (so most tx most likely to get mined quickly relay faster), any replaced or evicted or remotely advertised transactions are eliminated, and what remains is sent on a random timer (with a 5 or 10 second expected time, which ends up being 100ms scale for the node in aggregate) and rate limited to a couple times the networks nominal total rate.

I expect that as further privacy improvements happen, the average delay will go up somewhat further.  These delays are still negligible in general.

You can read more at https://github.com/bitcoin/bitcoin/pull/7840  and in the release notes.


Also it's likely that the main reason you see more transaction traffic from old nodes is that they don't implement fee-filter so they will relay you a lot of stuff that you just will discard, like low fee spam.

I can't give you numbers, but I can tell the methodology.

Basically you count how many new txs (that ended up in mempool) you received from each host.
To make it more reliable, you count them only in the last X minutes,or just divide total txs by the time connected.
It's always pre 0.13 nodes that end up on top - they send you the biggest number of new txs.

I'm sure you can do this kind of tests yourself, but if you want I'm happy to provide some more data from my env.

It's pretty visible - I'm certain it's the case.
You can see it even better dropping (e.g. each few minutes) a peer that has sent you the least txs during the last period.
Then,  after a couple of hours, you end up with mostly pre 0.13 peers
That's why I think the new ones must be slower. Because there is much more of them on the network.

It's possible that changes to the memory pool itself and how accepting transactions works is slowing it down. Several things have been added to and changed in the AcceptToMemoryPool functions which could impact performance. These include handling CPFP, minrelayfee that adjusts based on the mempool size, etc.

Could you show us the numbers you are getting for relay time and the methodology you used to get those numbers?

I was just thinking, might this lower performance be caused by the memory pool feature, that groups txs so the blocks could be miner for more dosh?

Honestly, I dont know how this grouping is actually implemented, but however I imagine doing something like this, it seems like some heavy stuff. Especially when your memory pool is tens of thousands txs big. It's a lot of sorting and quite often.

What I have seen by monitoring the network is that 0.14.x software has been (so far) the fastest to relay blocks.
Which is understandable as it relays blocks before verifying it.

What is not understandable for me, though...
Why pre 0.13.0 software is faster in relaying transactions?

I know 0.12 got secp256k1, but 0.13 and 0.14 also had it...
So why is 0.12.x faster in relaying txs than any version that came later?

It is actually even more weird: it seems that even 0.10.x and 0.11.x are quicker in relying transactions than 0.13+
And these still used openssl for EC operations.