Bitcoin Forum
September 24, 2018, 06:25:27 PM *
News: ♦♦ New info! Bitcoin Core users absolutely must upgrade to previously-announced 0.16.3 [Torrent]. All Bitcoin users should temporarily trust confirmations slightly less. More info.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Does anyone know why 0.12.x nodes relay transactions faster than later versions?  (Read 550 times)
piotr_n
Legendary
*
Offline Offline

Activity: 1932
Merit: 1018


aka tonikt


View Profile WWW
August 04, 2017, 03:59:38 PM
 #1

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.

Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.
PGP fingerprint: AB9E A551 E262 A87A 13BB  9059 1BE7 B545 CDF3 FD0E
1537813527
Hero Member
*
Offline Offline

Posts: 1537813527

View Profile Personal Message (Offline)

Ignore
1537813527
Reply with quote  #2

1537813527
Report to moderator
1537813527
Hero Member
*
Offline Offline

Posts: 1537813527

View Profile Personal Message (Offline)

Ignore
1537813527
Reply with quote  #2

1537813527
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1537813527
Hero Member
*
Offline Offline

Posts: 1537813527

View Profile Personal Message (Offline)

Ignore
1537813527
Reply with quote  #2

1537813527
Report to moderator
1537813527
Hero Member
*
Offline Offline

Posts: 1537813527

View Profile Personal Message (Offline)

Ignore
1537813527
Reply with quote  #2

1537813527
Report to moderator
1537813527
Hero Member
*
Offline Offline

Posts: 1537813527

View Profile Personal Message (Offline)

Ignore
1537813527
Reply with quote  #2

1537813527
Report to moderator
piotr_n
Legendary
*
Offline Offline

Activity: 1932
Merit: 1018


aka tonikt


View Profile WWW
August 04, 2017, 06:04:51 PM
 #2

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.

Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.
PGP fingerprint: AB9E A551 E262 A87A 13BB  9059 1BE7 B545 CDF3 FD0E
achow101
Moderator
Legendary
*
expert
Offline Offline

Activity: 1526
Merit: 1654


3F1Y9yquzvY6RWvKbw2n2zeo9V5mvBhADU


View Profile WWW
August 04, 2017, 07:11:13 PM
 #3

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?

piotr_n
Legendary
*
Offline Offline

Activity: 1932
Merit: 1018


aka tonikt


View Profile WWW
August 04, 2017, 07:51:13 PM
 #4

Could you show us the numbers you are getting for relay time and the methodology you used to get those numbers?
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.

Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.
PGP fingerprint: AB9E A551 E262 A87A 13BB  9059 1BE7 B545 CDF3 FD0E
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2506
Merit: 1505



View Profile
August 05, 2017, 01:48:50 AM
 #5

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.
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)

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

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.

Quote
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?
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. Smiley

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.

Bitcoin will not be compromised
piotr_n
Legendary
*
Offline Offline

Activity: 1932
Merit: 1018


aka tonikt


View Profile WWW
August 05, 2017, 07:12:40 AM
 #6

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.

Quote
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?
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. Smiley

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.

That explains everything. Thanks.

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

Quote
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.
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:


Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.
PGP fingerprint: AB9E A551 E262 A87A 13BB  9059 1BE7 B545 CDF3 FD0E
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!