Proposed change to sendtoaddress API call

I’m proposing one small change to Bitcoin’s JSON-RPC api: return a transaction ID when Bitcoins are successfully sent.

Why? Because I want to keep a complete audit trail for any coins going into or coming out of my application’s wallet; I want to keep track of the particular transactions in the bitcoin network that correspond to actions my application takes. The alternative is to call sendtoaddress and then call listtransactions, but that won’t work properly if two similar transactions (same amount to same address) occur at about the same time.

So I propose doing the simplest thing possible: modify the JSON-RPC sendtoaddress call so it returns the string ‘sent:’ followed by the 256-bit-hexadecimal transactions id.

This could break any applications that look for exactly the string ‘sent’ (which is what sendtoaddress does now). The fix would be to modify the apps to see if the string began with ‘sent’.

Alternatives I thought about but think I don’t like:

• make it a new api call so old apps do not break (sendtoaddress2 ? yuck)
• return just the transaction id on successful send instead of ‘sent:…’
• return an array with more information (maybe [ “tx_id”: ”…”, “fee” : 0.0 ] )

Comments/criticisms?

What happens when we desire to return additional information, beyond tx-id?

For the sake of future compatibility, it seems like the flag should present a choice between returning (a) just the current ‘sent’, or (b) a JSON map containing tx-id, and perhaps other things.

What happens when we desire to return additional information, beyond tx-id?

For the sake of future compatibility, it seems like the flag should present a choice between returning (a) just the current ‘sent’, or (b) a JSON map containing tx-id, and perhaps other things.

A ‘gettransaction tx_id’ API call is on my short list.

What do other folks think; should sendtoaddress … true return just the tx_id, and you have to make another API call to get details if you need them? Or should it return an Array?

Do you need ‘gettransaction’, given the existence of ‘getblock’?

It’s too soon to start junking up the API for backward compatibility at all costs.

Just return "".

Quote from: Jeff Garzik on August 13, 2010, 8:13:30 PM UTC

What happens when we desire to return additional information, beyond tx-id?

For the sake of future compatibility, it seems like the flag should present a choice between returning (a) just the current ‘sent’, or (b) a JSON map containing tx-id, and perhaps other things.

A ‘gettransaction tx_id’ API call is on my short list.

What do other folks think; should sendtoaddress … true return just the tx_id, and you have to make another API call to get details if you need them? Or should it return an Array?

Depends on how fancy you want to be.

If you go beyond a boolean, you could just append flags for any reason or function needed. This would leave it open to more functions rather than stacking a ton of booleans on the function as it’s usefulness grows.

sendtoaddress [comment] [comment-to] -tx_id : returns the tx ID of the receiving bitcoin address -dance : returns dance high scores -moon : return current moon phase

So one would simply put in sendtoaddress -tx-_id [comment] [comment-to] instead of sendtoaddress [comment] [comment-to] true false true true false if a lot of functions were added to it later.

It’s too soon to start junking up the API for backward compatibility at all costs. Just return "".

You’ll never hear me argue with “keep it simple.”

Patch for that is trivial:

diff --git a/rpc.cpp b/rpc.cpp
index 920fe90..35a336f 100644
--- a/rpc.cpp
+++ b/rpc.cpp
@@ -364,7 +364,7 @@ Value sendtoaddress(const Array& params, bool fHelp)
     string strError = SendMoneyToBitcoinAddress(strAddress, nAmount, wtx);
     if (strError != "")
         throw runtime_error(strError);
-    return "sent";
+    return wtx.GetHash().ToString();
 }

I think it was implied to be

 return "<" + wtx.GetHash().ToString() + ">";

?