How to calculate signature #1
Comments
|
closing as sticky |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
{{ message }}
|
closing as sticky |
This is to help you
This project is cryptocurrency-agnostic (BTC, BSV, BCH, DASH, DOGE, etc).
Although this module was written for Dash, the examples come from https://bitcointalk.org/index.php?topic=651344.0.
Table of Contents
Basic Anatomy of a Transaction
In short, every transaction for wallet payments looks like this:
VERSION#of InputsINPUTs(note: these vary wildly between Tx types)
#of OutputsOUTPUTsLOCKTIMESIGHASH_TYPETypes of Types
VarInt0x01000000is 1ASN.1ASN.1BigInts0x00if the first byte is >=0x80, unless the number is negativeOP_codesByte by Byte
Here's a look at each representation of a TX, byte by byte:
"Raw" Tx
Overview
0xffffffff)Example
Decoded
"Hashable" Tx
0xffffffff)"Signed" (Ready-to-Broadcast) Tx
106 to 109, varies due to BigInt padding
0xffffffff)Amalgam (all 3 types together)
0xffffffff)Types of Transactions (in Bytes)
There are 3 different byte structures for the same basic transaction:
This is just inputs (tx ids and indexes from previous outputs) and outputs.
It's pretty much useless. I have no idea why you'd ever want this.
There is one "Ready-to-Hash" Tx (Signable Tx) for each input (even if from the same address)
These are generated in order to creating unique Tx Hashes and verify signatures
These contain enough information to lookup what is needed to reconstruct the Tx Hashes from the info that exists in the blockchain indexes. These have a Tx ID.
Raw Tx (Useless)
There's nothing interesting you can do with these other than pass unit tests.
This format cannot be used to sign or broadcast. It lacks the necessary information to construct either of the useful Tx types.
That said..., here's what a Raw TX looks like, in bytes:
If we break that down cleanly into 4 sections:
Signable Tx
As stated above, a Raw Tx is useless. It's like an idiot-savant's version of JSON.
The signable TX is similar (example forthcoming), but:
sigScript(and its size) is replaced by the previous transaction's output's lock Script (rather than being 0-length, as in the raw)0x01) must be appended as a 32-bit LittleEndianNote: this example was added in haste and may not be perfectly correct. TODO make it perfect!
A Signed Tx
The signed transaction will look like this:
Which can be broken down like this:
# version (int32) 01 00 00 00 # number of outputs as inputs (varint) 01 # output at index 0 # byte-reversed txid of input's previous output a2bda7b7e967346fcf189cee2563b0846d7bec06bb6db6119054add1875bd377 # index of input's previous output 00 00 00 00 # prev vout index # size of signature script (106 decimal) - 00 + 6a + # size of signature + sighashtype (71 in decimal) + 47 + # ASN.1 Sequence + Size + 30 44 + # ASN.1 Bytes + Len + 02 20 + # Signature R value + 528e92bc890b362efcab0ab1af0f9427d501909be59fe22dbdb4c26eac174181 + # ASN.1 Bytes + Len + 02 20 + # Signature S Value + 6eb9c83360ad46c9f17be32ea15a08d2765a934e08ce6f2578b3379bbfa03afd + # SigHashType + 01 + # Varint PubKey Len (33) + 21 + # Full Public Key (first byte is quadrant) + 02 4451fc7d9e271fab77265bd0292fc274ee231e7ecc076bf6269999c0cbbf9f90 # sequence of this input ffffffff # number of outputs 01 # output at index 0 # satoshis (reverse byte order) 20 f1 61 0b 00 00 00 00 # varint size of this output's pubkeyhash script 19 # some op codes 76 a9 # decimal 20, the size of the pubkeyhash 14 # the pubkeyhash (no magic byte or checksum) f93af105187d21ed6adfa5d71bfada7d7324e53c # more op codes 88 ac # locktime 00000000The text was updated successfully, but these errors were encountered: