sendrawtransaction wire protocol? | Bitcointalksearch.org

gmaxwell

staff

Activity: 4284

Merit: 8808

Quote from: achow101 on February 24, 2016, 12:05:47 PM

Actually, if node b rejects your message, it will respond to you with a 'reject' message which will include an error code for the reason of the rejection.

Might. Rejects can be useful for software diagnostics but you shouldn't count on them for much.

You should always INV first. While handing nodes loose transactions currently works, it may not work forever. (and in some configurations, like nodes without relay set, may get you instabanned). It's also better for privacy, generally, since sending a loose transaction pretty much guarantees you are the source of the transaction.

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

Quote from: jl777 on February 24, 2016, 10:52:59 AM

Quote from: achow101 on February 24, 2016, 10:21:18 AM

The are two ways to send a transaction. The node can send an 'inv' message with the txid of the transaction. Then the peers respond with a 'getdata' message for that transaction and your node responds with a 'tx' message which contains the transaction. Alternatively the node can simply send 'tx' messages to its peers. Both methods require sending unsolicited messages to the peers.

makes sense.

So with 3 nodes, A, B and C. A can simply send a tx message to B and then I wait to see if B sends it to C. If it does, that indicates B was happy with the tx, if not, then rummage through the debug log to see why it rejected it.

And this will work even if A is a non-relaying node? Of course B has to be a relaying node.

James

Actually, if node b rejects your message, it will respond to you with a 'reject' message which will include an error code for the reason of the rejection.

jl777

legendary

Activity: 1176

Merit: 1134

Quote from: achow101 on February 24, 2016, 10:21:18 AM

The are two ways to send a transaction. The node can send an 'inv' message with the txid of the transaction. Then the peers respond with a 'getdata' message for that transaction and your node responds with a 'tx' message which contains the transaction. Alternatively the node can simply send 'tx' messages to its peers. Both methods require sending unsolicited messages to the peers.

makes sense.

So with 3 nodes, A, B and C. A can simply send a tx message to B and then I wait to see if B sends it to C. If it does, that indicates B was happy with the tx, if not, then rummage through the debug log to see why it rejected it.

And this will work even if A is a non-relaying node? Of course B has to be a relaying node.

James

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

The are two ways to send a transaction. The node can send an 'inv' message with the txid of the transaction. Then the peers respond with a 'getdata' message for that transaction and your node responds with a 'tx' message which contains the transaction. Alternatively the node can simply send 'tx' messages to its peers. Both methods require sending unsolicited messages to the peers.

jl777

legendary

Activity: 1176

Merit: 1134

The bitcoin rpc has sendrawtransaction, but at the wire protocol level, there is the "INV", "getdata" and "data" messages.

I couldnt find much documentation on the proper way for a node that doesnt have the networkservices bit set to push a transaction to the network.

From what I am seeing if network services bit is set, then just by sending INV message with the txid, the other nodes will do a getdata message and the transaction can be sent back with the data message.

I am not seeing consistent behavior for a node that is not a relaying node. Is there something special that needs to be done or maybe some detailed docs on how best to do a sendrawtransaction.

James

P.S. I am writing a full node from scratch, so I cant rely on any local or external bitcoind

Topic: sendrawtransaction wire protocol? (Read 734 times)