Topic: signrawtransaction hex (Read 716 times)
Thanks for the tips, guys. gmaxwell you are right: I though it would be rather convenient if the hex-encoded reply of signrawtransactions wouldn't contain any malleable data (which is not true, as kjj explained) so my program would use this internally as a transaction identifier (as tx id can change) so now I will follow your advice and create a hash based on the tx's outputs' address/amount information for that purpose. I will then use this hash to compare it against the one I create for all txs in a block when one of my outgoing txs gets mutated until I track it down and re-associate it internally with its new tx id.
There has been some talk of making an immutable ID.
An immutable ID is not _generally_ possible— since some forms of mutability are very much intentional (e.g. anyonecanpay), and also isn't generally needed. Presenting an "immutabile ID" which sometimes isn't would seem very dangerous to me. You can track your own transactions by which outputs they pay, or by which inputs they spend (so long as you aren't doublespending yourself), or both.WRT, -1 confirmations, it doesn't strictly mean "never will" since there could be a reorg that takes a transaction from -1 to confirmed, but it does mean that it cannot be confirmed in the current chain without a reorganization.
Doug, you've asked several questions now which are 'down in the weeds' and don't describe what you're trying to accomplish. You can usually get more useful answers if you also tell people what you're trying to do.
I haven't kept current with the recent changes to the client, but I believe that a transaction will go from zero to -1 confirmations when the client sees a conflict in the block chain. The idea is that zero means "not confirmed yet" and -1 means "and never will".
If you use walletnotify, you can examine each transaction and compare the input and output sets to your 0 and -1 transactions, looking for a match. If you see one, you can mark them as equivalent in your own system.
There has been some talk of making an immutable ID. For all I know, it is already done and in the client. The block chain requires that the signature be included in the ID hash, otherwise blocks would be impossible to verify (or at least harder). And it is useful almost all of the time to present that same ID to the user. But a signatureless hash can be useful too.
If you use walletnotify, you can examine each transaction and compare the input and output sets to your 0 and -1 transactions, looking for a match. If you see one, you can mark them as equivalent in your own system.
There has been some talk of making an immutable ID. For all I know, it is already done and in the client. The block chain requires that the signature be included in the ID hash, otherwise blocks would be impossible to verify (or at least harder). And it is useful almost all of the time to present that same ID to the user. But a signatureless hash can be useful too.
Great answer, kjj.
So I suppose I have to create a custom hash over my tx's inputs which will never change no matter how my tx gets mutated.
Let's say I've sent out a tx, it got mutated and my program tries to see the original tx's progress (confirmations etc), it sees the original tx orphaned so it should start looking for its mutated version, how do I do this? Scan all txs in the recent blocks and compare their inputs with my original tx's inputs until I get a perfect match? What is the most efficient way to handle this case?
So I suppose I have to create a custom hash over my tx's inputs which will never change no matter how my tx gets mutated.
Let's say I've sent out a tx, it got mutated and my program tries to see the original tx's progress (confirmations etc), it sees the original tx orphaned so it should start looking for its mutated version, how do I do this? Scan all txs in the recent blocks and compare their inputs with my original tx's inputs until I get a perfect match? What is the most efficient way to handle this case?
Again, your question is confused.
But, I promise you that your string will not change if someone else mutates your transaction. If they re-serialize their version of your transaction, they will get a string different from the string you have, but your string will not have changed. Unless you have a quantum computer, haha.
Note that their transaction and your transaction are not the same transaction. They have the same inputs and the same outputs, but a different ID. This is mostly a matter of philosophy though, because we've defined the transaction ID as the sole identifier of a transaction. If we defined a transaction by their input and output sets, they would be the same.
This, by the way, is the core of the malleability problem. If you track transactions by ID, you can end up having problems if someone manages to get a changed version of your transaction into a block instead of your version. You must track by inputs, and you must be prepared for the ID to change between when you create it and when it is safely frozen into the chain.
But, I promise you that your string will not change if someone else mutates your transaction. If they re-serialize their version of your transaction, they will get a string different from the string you have, but your string will not have changed. Unless you have a quantum computer, haha.
Note that their transaction and your transaction are not the same transaction. They have the same inputs and the same outputs, but a different ID. This is mostly a matter of philosophy though, because we've defined the transaction ID as the sole identifier of a transaction. If we defined a transaction by their input and output sets, they would be the same.
This, by the way, is the core of the malleability problem. If you track transactions by ID, you can end up having problems if someone manages to get a changed version of your transaction into a block instead of your version. You must track by inputs, and you must be prepared for the ID to change between when you create it and when it is safely frozen into the chain.
When calling RPC signrawtransaction it returns a hex-encoded string that contains the raw tx request with its signatures.
Is this string:
Is this string:
- malleable?
- unique?
What do you mean asking "Is this string malleable?"
Transactions (not strings!) are malleable in any representation: in hex, in json or even written in human language.
What do you mean asking "Is this string unique?"
Is the string "Hello world!" unique?
I seriously don't get why you even bothered to reply to my question since you don't really know the answer and just wanna fool around with semantics and waste your time and ours.
The signrawtransaction command returns two variables:
- "hex", which is a hex-encoded string
- "complete", which is a numeric
The hex-encoded string is essentially a snapshot of the raw transaction at the moment when its inputs are being signed, so my question is, will this hex-encoded string change if the transaction gets modified by a malleability attack?
When calling RPC signrawtransaction it returns a hex-encoded string that contains the raw tx request with its signatures.
Is this string:
Is this string:
- malleable?
- unique?
What do you mean asking "Is this string malleable?"
Transactions (not strings!) are malleable in any representation: in hex, in json or even written in human language.
What do you mean asking "Is this string unique?"
Is the string "Hello world!" unique?
When calling RPC signrawtransaction it returns a hex-encoded string that contains the raw tx request with its signatures.
Is this string:
Is this string:
- malleable?
- unique?
Jump to: