1
0
Here's what I get from Mintcoin client for some transaction. I have decoded output, but how can I decrypt asm in transaction input? I know it's a public key. Here it is:
304502207fc09b1c29548feceb349aa1450874f97e7e9b9c0084e5917380151258236633022100808b8ca131480afcdef328c961131be389489fdc07e5201a807c47a6b94b18f201
1
This is ASN.1 DER encoding. This is NOT the public key, but the ECDSA signature.
30 45 means set of data with 0x45 bytes following
02 20 means big integer with 0x20 bytes (this is big endian value "r")
Skip 0x20 bytes...
02 21 means big integer with 0x21 bytes ("s")
In other words:
r = 0x7fc09b1c29548feceb349aa1450874f97e7e9b9c0084e5917380151258236633,
s = 0x808b8ca131480afcdef328c961131be389489fdc07e5201a807c47a6b94b18f2
The final byte 0x01 means SIGHASH_ALL (default)
This is technically correct. ASM is not "encryption" like the OP writes, as such it can't be decrypted. It is the binary (ones an zeros) of a file that is converted to letters and numbers for humans to read. The main purpose of this ASM is to be read by a computer. – goodguys_activate – 2014-03-09T03:50:15.343
Note: reason "s" takes 0x21 bytes is that leading byte 0x80 has bit 7 set to 1, so an extra leading 0x00 byte is added to indicate positive sign, for interoperability with OpenSSL. – uminatsu – 2014-03-09T03:50:43.400
Is the encoding of s really 21 bytes for the DER encoded signature, or is it variable based on the value of the second-to-last bit? If s is variable, I'd say it fluctuates between 21 and 20 bytes. R should be the same way at least 1 in every 1,000,000 random signatures (in my experience) – goodguys_activate – 2014-03-09T03:58:10.867
Yes it is variable based on the most significant bit. Both r and s can be 0x20 or 0x21 bytes. – uminatsu – 2014-03-09T04:03:08.290
You may be interested in these test cases for the recoverable signature format that may be less than 32 bytes http://bitcoin.stackexchange.com/a/22881/1878
0
I suppose you are talking about the scripts. The scriptPubKey script in the output is indeed more readable because it contains OpCodes like OP_HASH160 and OP_CHECKSIG. However, the input scripts are in their original form as well.
As you can see in the specification of the pay-to-pubkey-hash transactions scripts (the regular scripts to pay to Bitcoin address), the input input script only consists of two data elements, the signature and the public key. So what you see in the input fields "hex" and "asm" are the signature and the public key of the address the input spends funds from. The reason that these two values vary slightly is because they are encoded differently, but that doesn't matter all that much.
Basically, they are not encrypted or so, they just contain little to no relevant information.
I merged your previous question with the almost exact same text into this one. Please edit questions if you want to improve them instead of just asking them again. – Murch – 2014-03-15T15:17:19.420