sendrawtransaction wire protocol?

[jl777]

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

[achow101]

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]

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]

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.

[gmaxwell]

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.