When using the context menu to copy a transaction ID, the subtransaction index is added for no apparent reason.
We don't show the subtransaction index in the details window, so I see no reason why a user would want it appended to their transaction ID from the context menu.
Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/168573fe20aaae7fb0bccd1175047e538cde05d1 for binaries and test log. This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.
Did you check that TransactionRecord::getTxID() is ONLY used for copying the TxID (to clipboard)?
This loses information for received transactions. Maybe it should be shown in the details?
Not sure that I agree with this. Only when the subtransaction (output) id is added, the identifier uniquely identifies a transaction record. If you change this, only change the "copy" and not the other functionality such as CSV export.
The inability to get a vout at all on blockchain.info was seriously screwing with me earlier. Why would we want to exclude the vout index here?
Ok, consensus seems to be not to merge this as-is, so I'm closing this. Adding the subtransaction to the details window is still a good idea though.
Is appending a hyphen and the subtransaction ID considered the "standard format"? If so, why doesn't getrawtransaction support it?
$ bitcoind getrawtransaction a642029ef09d7780c9e13fea3ad8706098f919cb4174870b6284e27353ab1aa7-000 1 error: {"code":-8,"message":"parameter 1 must be hexadecimal string (not 'a642029ef09d7780c9e13fea3ad8706098f919cb4174870b6284e27353ab1aa7-000')"}
Because all the bitcoind RPC functions work on whole transactions, not sub-transactions. Only the GUI has that distinction. Getrawtransaction on one output would mean nothing.
Right, that's my point. Everything that refers to the transaction ID specifically does not include the subtransaction index. I believe we are going to confuse users by muddling the term transaction ID to sometimes mean the entire transaction and other times mean the transaction ID with the subtransaction index appended.
I think the txid-vout format is pretty clear. It specifies a hierarchical subdivision with -, and the user can delete the part after - easily if he doesn't need it. As there is not a standard format, I think it will do as well as any other.
In the details window I could call it TxID-vout instead of just TxID, but in the context menu there is no space for further elaboration.
Simply dropping the vout index loses information that is needed to drill down to that specific subtransaction [From user viewpoint, the subtransaction is the transaction]. And indeed the RPC does not accept TxID-vout format, but that's mainly because the need has never arisen to point at specific subtransactions (AFAIK) so one should remove the subtransaction before submitting it through RPC (which is just deleting the last 4 characters).
I'm really not convinced that there is a problem (apart from lack of documentation/explanation) here. Unless you have a much better proposal I'd like to keep it this way.
Createrawtransaction and signrawtransaction take a vout, though they take them as separate vout arguments.
Having the vout is essential to authoring transactions. It's also important when handling payments in order to prevent duplicate keys on the txid when you're paid multiple times in a single transaction.
When I write them together I normally use txid:vout, I'm not sure where this form comes from. It's a little annoying that the raw transaction api breaks out the vout, but oh well.