Bitcoin Forum
September 22, 2020, 03:01:00 AM *
News: Latest Bitcoin Core release: 0.20.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Block and Transaction Propagation times  (Read 160 times)
Picard78
Jr. Member
*
Offline Offline

Activity: 56
Merit: 17


View Profile
September 14, 2020, 06:04:14 AM
Merited by ETFbitcoin (3), Jet Cash (1)
 #1

According to this site http://bitcoinstats.com/network/propagation/ in 2017 it took 1.818 seconds to propagate a newly mined block to 50% of the Nodes.  However, it took 3.792 seconds to propagate a single transaction to 50% of the nodes.  (Scroll down to the bottom of the page to see the above mentioned stats)

I don't understand how a transaction would take more time to propagate than an entire block filled with thousands of transactions?

Thank you

1600743660
Hero Member
*
Offline Offline

Posts: 1600743660

View Profile Personal Message (Offline)

Ignore
1600743660
Reply with quote  #2

1600743660
Report to moderator
1600743660
Hero Member
*
Offline Offline

Posts: 1600743660

View Profile Personal Message (Offline)

Ignore
1600743660
Reply with quote  #2

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

Posts: 1600743660

View Profile Personal Message (Offline)

Ignore
1600743660
Reply with quote  #2

1600743660
Report to moderator
1600743660
Hero Member
*
Offline Offline

Posts: 1600743660

View Profile Personal Message (Offline)

Ignore
1600743660
Reply with quote  #2

1600743660
Report to moderator
1600743660
Hero Member
*
Offline Offline

Posts: 1600743660

View Profile Personal Message (Offline)

Ignore
1600743660
Reply with quote  #2

1600743660
Report to moderator
Carlton Banks
Legendary
*
Offline Offline

Activity: 2842
Merit: 2281



View Profile
September 14, 2020, 07:04:35 AM
Merited by Jet Cash (2), ETFbitcoin (1)
 #2

I don't understand how a transaction would take more time to propagate than an entire block filled with thousands of transactions?

probably compact blocks BIP152 plays an important role

because all blocks are composed of valid UTXOs which are relayed as unconfirmed transactions before inclusion in some subsequent block, most nodes do not need the megabytes of transaction information, as they already have all (or most) of the transactions in a given block in their mempool. Compact blocks propagation is designed to leverage this fact; nodes relay only the block header and hashed transactions to other nodes, instead of the complete block. If a node does not have in its local mempool some small number of the unconfirmed transactions in that block, then they request the full transactions they are missing. Then, the node uses the hashed transactions (now that they have all of them for that block) to reconstruct the complete block.

This reduces block propagation time (and the bandwidth used to propagate blocks) considerably (and has been in use since Bitcoin 0.13.0)

Vires in numeris
ranochigo
Legendary
*
Offline Offline

Activity: 2128
Merit: 1475

@ me if you need my response


View Profile WWW
September 14, 2020, 07:10:42 AM
Merited by ETFbitcoin (1)
 #3

Firstly, I would take the stats with a pinch of salt. I can't seem to find their sampling methodology and it is difficult to evaluate the efficacy of their sampling.

Bitcoin Core has an arbitrary interval to send inv messages to its peers. Bitcoin Core maintains a list of transaction (not the mempool) for the individual nodes connected and that the list of transaction is what your client believe that the specific peer that the list is assigned to doesn't have the transaction. The inv message is broadcasted periodically and with an arbitrary delay.

In addition, each node has their own set of rules and some may refuse to relay certain transactions due to a relay fee below its threshold or a myriad of other criteria. The number of hops that a transaction has to go through due to this has a huge factor to play.

CMIIW, since the newer client (After 0.13.0 or so) implements header synchronization, there isn't any delay when announcing blocks after the validation.

gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 3178
Merit: 4301



View Profile
September 15, 2020, 08:32:52 AM
Merited by ETFbitcoin (1)
 #4

Transaction relay is batched and relayed at random intervals because doing so greatly reduces bandwidth usage for relay (due to reducing overheads and due to reducing the number that are advertised both ways on links) and also because its important for privacy as otherwise it's much easier to tell where transactions came from based on when they showed up.  ... and also because there is no particular need for transaction relay to be extremely low latency: blocks are 10 minutes apart on average, after all.


Quote
I don't understand how a transaction would take more time to propagate than an entire block filled with thousands of transactions?
Almost all the data in blocks has already been relayed and validated.  It only takes a 6 or so bytes per transaction on average to relay a block and the only processing needed is a bit of hashing.
Picard78
Jr. Member
*
Offline Offline

Activity: 56
Merit: 17


View Profile
September 16, 2020, 05:32:22 AM
 #5

Thank you for the answers.
Picard78
Jr. Member
*
Offline Offline

Activity: 56
Merit: 17


View Profile
September 18, 2020, 07:27:54 AM
 #6

Quote
nodes relay only the block header and hashed transactions to other nodes, instead of the complete block.

This optimization makes sense.

Quote
It only takes a 6 or so bytes per transaction on average to relay a block and the only processing needed is a bit of hashing.

Where do the 6 Bytes come in?  A transaction ID is a SHA256 hash of the transaction done twice, which is 32 Bytes. 
ETFbitcoin
Legendary
*
Offline Offline

Activity: 2114
Merit: 2510

Use SegWit and enjoy lower fees.


View Profile WWW
September 18, 2020, 11:24:10 AM
Merited by gmaxwell (1)
 #7

Quote
nodes relay only the block header and hashed transactions to other nodes, instead of the complete block.

This optimization makes sense.

Quote
It only takes a 6 or so bytes per transaction on average to relay a block and the only processing needed is a bit of hashing.

Where do the 6 Bytes come in?  A transaction ID is a SHA256 hash of the transaction done twice, which is 32 Bytes. 

IIRC, compact block uses this https://en.bitcoin.it/wiki/Protocol_documentation#Short_transaction_ID

Carlton Banks
Legendary
*
Offline Offline

Activity: 2842
Merit: 2281



View Profile
September 18, 2020, 03:48:22 PM
 #8

Where do the 6 Bytes come in?  A transaction ID is a SHA256 hash of the transaction done twice, which is 32 Bytes. 

compact blocks does not use the txid, it uses a shorter (64 bit) hash, and then apparently drops the 2 most significant bytes (i.e. the first 16 bits, maybe because the hashes are serialized for big endian archs? not sure). Hence, 64 bits - 16 bits = 48 bits (equivalent to 6 bytes per short-tx-id).

follow the link in ETFbitcoin's post above, that page is an invaluable reference.

Vires in numeris
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 3178
Merit: 4301



View Profile
September 18, 2020, 11:05:37 PM
Merited by Carlton Banks (1), aliashraf (1)
 #9

(i.e. the first 16 bits, maybe because the hashes are serialized for big endian archs? not sure)
Siphash's output is 64-bits and we needed fewer based on an analysis of collisions rates.  It didn't matter which bytes of the output got dropped, some just had to be picked.
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!