Bitcoin Forum
November 23, 2017, 10:24:03 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Pushing Transactions to other Bitcoin Clients  (Read 1572 times)
No_2
Hero Member
*****
Offline Offline

Activity: 805


BTC: the beginning of stake-based public resources


View Profile WWW
February 20, 2015, 01:21:22 PM
 #1

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?

MetaLair: a blockchain and cryptocurrency consultancy
Twitter: @MetaLair | Facebook | Google+
1511432643
Hero Member
*
Offline Offline

Posts: 1511432643

View Profile Personal Message (Offline)

Ignore
1511432643
Reply with quote  #2

1511432643
Report to moderator
1511432643
Hero Member
*
Offline Offline

Posts: 1511432643

View Profile Personal Message (Offline)

Ignore
1511432643
Reply with quote  #2

1511432643
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1511432643
Hero Member
*
Offline Offline

Posts: 1511432643

View Profile Personal Message (Offline)

Ignore
1511432643
Reply with quote  #2

1511432643
Report to moderator
1511432643
Hero Member
*
Offline Offline

Posts: 1511432643

View Profile Personal Message (Offline)

Ignore
1511432643
Reply with quote  #2

1511432643
Report to moderator
TierNolan
Legendary
*
Offline Offline

Activity: 1120


View Profile
February 20, 2015, 01:42:26 PM
 #2

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?

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.

Quote
If so:
  • What triggers the transaction being sent?

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.

Quote
  • Can you specify who the recipient is?

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.

Quote
  • Can you point me to the code which implements this?

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.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
piotr_n
Legendary
*
Offline Offline

Activity: 1778


aka tonikt


View Profile WWW
February 20, 2015, 03:36:56 PM
 #3

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.

Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.
PGP fingerprint: AB9E A551 E262 A87A 13BB  9059 1BE7 B545 CDF3 FD0E
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
February 20, 2015, 03:43:01 PM
 #4

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.

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.
No_2
Hero Member
*****
Offline Offline

Activity: 805


BTC: the beginning of stake-based public resources


View Profile WWW
February 20, 2015, 04:01:08 PM
 #5

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?

MetaLair: a blockchain and cryptocurrency consultancy
Twitter: @MetaLair | Facebook | Google+
StephenMorse
Member
**
Offline Offline

Activity: 88


View Profile
February 20, 2015, 04:46:59 PM
 #6

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?
zvs
Legendary
*
Offline Offline

Activity: 1484


I have some bitcoins. Somewhere.


View Profile WWW
February 20, 2015, 05:16:39 PM
 #7

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.

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.
I thought it was only broadcast to 25% of peers

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

Dacentec, best deals for US dedicated servers. They regularly restock $20-$25 Opterons with 8-16GB RAM & 2x1-2TB HDD's (ofc, usually lots of other good stuff to choose from).  I did a Serverbear benchmark of one of my $20/mo Opteron (June last year), it's here.  Have had about a half dozen different servers with Dacentec, & none have failed to sustain at least 40MB/s (burst higher). My favorite is a 12-month rent-to-own ZT Systems 2XL5520 16GB 2x2TB SATA for $40/month (got lucky with the 'off-brand', haven't seen a RTO 2xL5520 for under $50/mo since -- at least for monthly contracts).  wholesaleinternet.com has some ancient 2-core intel CPUs @ $10/mo sometimes (I got an Intel Core 2 6300 @ 1.86GHz, with a 250GB HDD with 46000 hours on it, LOL. $20 @ Dacentec is much better, if you can grab one). joesdatacenter.com (same location as Wholesale Internet) also occasionally has specials (or if you don't want to wait, it has an AMD Opteron 170 @ $16/mo).
TierNolan
Legendary
*
Offline Offline

Activity: 1120


View Profile
February 20, 2015, 07:30:39 PM
 #8

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?

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.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
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!