Bitcoin Forum
October 03, 2022, 04:04:12 AM *
News: Latest Bitcoin Core release: 23.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: signrawtransaction hex  (Read 679 times)
DougPeters (OP)
Newbie
*
Offline Offline

Activity: 15
Merit: 0


View Profile
June 03, 2014, 11:29:40 AM
 #1

When calling RPC signrawtransaction it returns a hex-encoded string that contains the raw tx request with its signatures.

Is this string:

  • malleable?
  • unique?
Bitcoin addresses contain a checksum, so it is very unlikely that mistyping an address will cause you to lose money.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
apxu
Member
**
Offline Offline

Activity: 229
Merit: 13


View Profile
June 03, 2014, 12:13:51 PM
 #2

When calling RPC signrawtransaction it returns a hex-encoded string that contains the raw tx request with its signatures.

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?
DougPeters (OP)
Newbie
*
Offline Offline

Activity: 15
Merit: 0


View Profile
June 03, 2014, 12:30:29 PM
 #3

When calling RPC signrawtransaction it returns a hex-encoded string that contains the raw tx request with its signatures.

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?
kjj
Legendary
*
Offline Offline

Activity: 1302
Merit: 1016



View Profile
June 03, 2014, 12:50:50 PM
 #4

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.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
DougPeters (OP)
Newbie
*
Offline Offline

Activity: 15
Merit: 0


View Profile
June 03, 2014, 01:07:28 PM
 #5

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?
kjj
Legendary
*
Offline Offline

Activity: 1302
Merit: 1016



View Profile
June 03, 2014, 02:18:45 PM
 #6

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.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 3752
Merit: 6875



View Profile
June 03, 2014, 02:51:11 PM
 #7

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.
DougPeters (OP)
Newbie
*
Offline Offline

Activity: 15
Merit: 0


View Profile
June 03, 2014, 09:57:03 PM
 #8

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.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!