HCLivess (OP)
Legendary
Offline
Activity: 2114
Merit: 1090
=== NODE IS OK! ==
|
|
September 19, 2016, 07:48:04 AM |
|
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.
|
|
|
|
|
|
|
There are several different types of Bitcoin clients. The most secure are full nodes like Bitcoin Core, but full nodes are more resource-heavy, and they must do a lengthy initial syncing process. As a result, lightweight clients with somewhat less security are commonly used.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
franky1
Legendary
Offline
Activity: 4214
Merit: 4475
|
|
September 19, 2016, 10:56:36 AM |
|
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. Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
|
|
|
HCLivess (OP)
Legendary
Offline
Activity: 2114
Merit: 1090
=== NODE IS OK! ==
|
|
September 19, 2016, 11:10:52 AM |
|
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
|
|
|
|
amaclin
Legendary
Offline
Activity: 1260
Merit: 1019
|
|
September 19, 2016, 11:22:30 AM |
|
|
|
|
|
HCLivess (OP)
Legendary
Offline
Activity: 2114
Merit: 1090
=== NODE IS OK! ==
|
|
September 19, 2016, 01:51:05 PM |
|
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?
|
|
|
|
amaclin
Legendary
Offline
Activity: 1260
Merit: 1019
|
|
September 19, 2016, 02:04:43 PM |
|
This concept of inventory vectors sounds rather interesting, do you know where exactly it is implemented? in bitcoin network protocol So each transaction has a 32bit hash, which is sent between nodes? 32 byte, not 32 bit sha256 ( sha256 ( contents-of-transaction ) ) 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
Activity: 3430
Merit: 3074
|
|
September 19, 2016, 02:18:16 PM |
|
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 (OP)
Legendary
Offline
Activity: 2114
Merit: 1090
=== NODE IS OK! ==
|
|
September 19, 2016, 07:47:57 PM |
|
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
|
|
|
|
HCLivess (OP)
Legendary
Offline
Activity: 2114
Merit: 1090
=== NODE IS OK! ==
|
|
November 22, 2016, 02:31:16 PM |
|
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
|
|
|
|
|