Bitcoin Forum
December 14, 2017, 11:02:19 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Wasteless transaction propagation?  (Read 427 times)
HCLivess
Legendary
*
Offline Offline

Activity: 1372


[[[],[]],[[],[]]]


View Profile WWW
September 19, 2016, 07:48:04 AM
 #1

Hello, do you please have details on how Bitcoin is handling transaction propagation and what is the most efficient way?
I can't think of a scenario which does not involve a lot of waste - transaction resending back to nodes where they originally came from, being unsure about which node to send to, etc.

Asking about the process which happens before the block is formed.

Bismuth - New Language, Interpretation Engines, Free Set of DAPPs https://bitcointalk.org/index.php?topic=1896497
Bitrated user: HCLivess.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
franky1
Legendary
*
Offline Offline

Activity: 1890



View Profile
September 19, 2016, 10:56:36 AM
 #2

in simple laymans

nodes have a mempool.
when they receive or create a new tx, they put it into their mempool and send it out.

when a node sends a TX to someone else, who sends it to someone else, who sends it to someone else, and so on until one of those people have a connection to any of the original nodes, it doesnt cause the original node to automatically re-transmit the same transaction simply because it received it by someone else.. other wise it would trigger a endless loop.

they notice its already in the mempool and just leave it.

in short if the transaction is not already in the mempool its sent out. if it is in the mempool(already sent) its not re-sent out


I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
Don't take any information given on this forum on face value. Please do your own due diligence & respect what is written here as both opinion & information gleaned from experience. If you wish to seek legal FACTUAL advice, then seek the guidance of a LEGAL specialist.
HCLivess
Legendary
*
Offline Offline

Activity: 1372


[[[],[]],[[],[]]]


View Profile WWW
September 19, 2016, 11:10:52 AM
 #3

in simple laymans

nodes have a mempool.
when they receive or create a new tx, they put it into their mempool and send it out.

when a node sends a TX to someone else, who sends it to someone else, who sends it to someone else, and so on until one of those people have a connection to any of the original nodes, it doesnt cause the original node to automatically re-transmit the same transaction simply because it received it by someone else.. other wise it would trigger a endless loop.

they notice its already in the mempool and just leave it.

in short if the transaction is not already in the mempool its sent out. if it is in the mempool(already sent) its not re-sent out


Thanks, still not sure if I wholly understand

A sends to B
B sends to C
C sends to D
D sends to A, B, C - no way to prevent this except for C

but they ignore the transaction, because it is already in the mempool? I was looking for something cleaner

Bismuth - New Language, Interpretation Engines, Free Set of DAPPs https://bitcointalk.org/index.php?topic=1896497
Bitrated user: HCLivess.
amaclin
Legendary
*
Offline Offline

Activity: 1260


View Profile
September 19, 2016, 11:22:30 AM
 #4

https://webcache.googleusercontent.com/search?q=cache:D-XUhGaL4dgJ:https://en.bitcoin.it/wiki/Protocol_documentation+&cd=1&hl=ru&ct=clnk&gl=ru#inv
HCLivess
Legendary
*
Offline Offline

Activity: 1372


[[[],[]],[[],[]]]


View Profile WWW
September 19, 2016, 01:51:05 PM
 #5


Quote
Inventory Vectors
Inventory vectors are used for notifying other nodes about objects they have or data which is being requested.

Inventory vectors consist of the following data format:

Field Size   Description   Data type   Comments
4   type   uint32_t   Identifies the object type linked to this inventory
32   hash   char[32]   Hash of the object

This concept of inventory vectors sounds rather interesting, do you know where exactly it is implemented?

So each transaction has a 32bit hash, which is sent between nodes? I would like to stick to the non-redundancy part of the topic, and how transactions are serialized in the mempool. Hash, timestamp, address, signature - in each case the pool can be shuffled around so the node has to verify the whole pool in time intervals, correct?

Bismuth - New Language, Interpretation Engines, Free Set of DAPPs https://bitcointalk.org/index.php?topic=1896497
Bitrated user: HCLivess.
amaclin
Legendary
*
Offline Offline

Activity: 1260


View Profile
September 19, 2016, 02:04:43 PM
 #6

This concept of inventory vectors sounds rather interesting, do you know where exactly it is implemented?
in bitcoin network protocol

Quote
So each transaction has a 32bit hash, which is sent between nodes?
32 byte, not 32 bit
sha256 ( sha256 ( contents-of-transaction ) )

Quote
I would like to stick to the non-redundancy part of the topic, and how transactions are serialized in the mempool.
some kind of HashSet
Carlton Banks
Legendary
*
Offline Offline

Activity: 1848



View Profile
September 19, 2016, 02:18:16 PM
 #7

A sends to B
B sends to C
C sends to D
D sends to A, B, C - no way to prevent this except for C

but they ignore the transaction, because it is already in the mempool? I was looking for something cleaner

There is nothing a node can do to prevent a newly connected partner node from relaying transactions it already knows, with the current system. amaclin suggests using some kind of hash data structure to minimise/prevent redundant relaying, and it's possible that is viable (there's a similar concept in action in the new compact blocks relay mechanism to minimise the bandwidth used to propagate blocks). Probably better to err on the side of redundancy though, unless a really reliable/effective solution is produced. There's too much of a danger of something like that being subverted as a DoS vector.

Vires in numeris
HCLivess
Legendary
*
Offline Offline

Activity: 1372


[[[],[]],[[],[]]]


View Profile WWW
September 19, 2016, 07:47:57 PM
 #8

A sends to B
B sends to C
C sends to D
D sends to A, B, C - no way to prevent this except for C

but they ignore the transaction, because it is already in the mempool? I was looking for something cleaner

There is nothing a node can do to prevent a newly connected partner node from relaying transactions it already knows, with the current system. amaclin suggests using some kind of hash data structure to minimise/prevent redundant relaying, and it's possible that is viable (there's a similar concept in action in the new compact blocks relay mechanism to minimise the bandwidth used to propagate blocks). Probably better to err on the side of redundancy though, unless a really reliable/effective solution is produced. There's too much of a danger of something like that being subverted as a DoS vector.

Thank you very much

Bismuth - New Language, Interpretation Engines, Free Set of DAPPs https://bitcointalk.org/index.php?topic=1896497
Bitrated user: HCLivess.
HCLivess
Legendary
*
Offline Offline

Activity: 1372


[[[],[]],[[],[]]]


View Profile WWW
November 22, 2016, 02:31:16 PM
 #9

In the end, I decided to share the entire mempool between every node on each sync occassion. The only improvements I can think of is

a, sending headers first
b, sending whole pool hash first
c, prevent sending back transactions from where they came

not sure how much traffic that would save though

Bismuth - New Language, Interpretation Engines, Free Set of DAPPs https://bitcointalk.org/index.php?topic=1896497
Bitrated user: HCLivess.
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!