Wasteless transaction propagation?

[HCLivess]

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.

[1714985336]

1714985336

[1714985336]

1714985336

[1714985336]

1714985336

[franky1]

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

[HCLivess]

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]

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]

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

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]

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]

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.

[HCLivess]

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]

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