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
Topic: Wasteless transaction propagation? (Read 485 times)
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
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
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
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.
This concept of inventory vectors sounds rather interesting, do you know where exactly it is implemented?
in bitcoin network protocolQuote
So each transaction has a 32bit hash, which is sent between nodes?
32 byte, not 32 bitsha256 ( 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 HashSetQuote
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
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?
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 understandnodes 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
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
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
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
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.
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.
Jump to: