Topic: Pushing Transactions to other Bitcoin Clients (Read 1723 times)

In that case all that nodes peers will ask for the transactions.  When they are received, they go into the orphan pool.  That means that they are valid, but at least one input is unknown.

Since they aren't committed to the memory pool, those nodes don't forward them onward.  A node which spams only ends up spamming their direct peers.

I thought it was only broadcast to 25% of peers

isn't that what trickle is for? (*and syncnode)

The process of pushing out inventory messages first makes sense, but what stops a node from broadcasting massive amounts of 'inv' messages (for which there is no actual block/transaction data) and clogging up the network? Will the node that does this get banned by its peers?

Thank you very much. This is very helpful.

I have one other question. Is there a way to trigger the sending of a transaction from the client locally on the machine it is running on or does the client expect this request to come from another Bitcoin client on the network, i.e. is this done over a bind()ed TCP socket? Or can it also be done via something like an RCP API?

I would also add (since it is sometimes a point of confusion) that transactions you create are no different than transactions you receive from a peer in this respect.  When your node learns of "something new" in this case a transaction, your node validates it, adds it to the local memory pool, and notifies peers by sending a INV message.

you just announce the new txid by sending inv message to all your peers.
when they realize they don't know it, they will ask you for the data, using getdata message.

Yes, but they aren't supposed to.

The sequence is that a node sends its peers "inv" (inventory) messages.  This is a list of transaction and/or block hashes that the node has.  

They can contain a single hash.  If the peer doesn't have the transaction, it then sends a "getdata" message to request the transaction(s).  This prevents transactions being sent to nodes that already have them and wasting bandwidth.  Hashes are still 32 bytes per transaction though, so still uses up some bandwidth.

Nodes can simply send transactions ("tx" messages) without being asked for them, but that wastes bandwidth and isn't the recommended way to do it.


When a node commits a transaction to its memory pool, it then notifies all peers that it has the transaction.

Committing a transaction to the memory pool means that the transaction is valid and all inputs are either in blocks or also in the memory pool.

The memory pool is the list of transactions that the node would include in any block it created.


Uh, not sure what you mean here.  Nodes can send transactions to only certain peers if they want.  The default operation is to broadcast the "inv" message.

If Bloom filters are used, then only transactions which match the bloom filters are sent.


This is where new transactions are handled and the memory pool is checked here.  If they are accepted, then there is a call to relay them.

The relay call is in net.cpp.  This calls push inventory.

I understand a Bitcoin client can request a transaction from another client on the network, effectively a pull request. However can a client push a transaction to another client on the network, a push request?

If so:

• What triggers the transaction being sent?
• Can you specify who the recipient is?
• Can you point me to the code which implements this?