BTC

?
In the previous section, we understood the components of a transaction (inputs and outputs). Well, there are two more very important components of a transaction- ScriptSig and ScriptPubKey and would be explained in detail in the next section.

The final Bitcoin transaction that we would be building will look like: -

It majorly constitutes two segments, the input and the output part as we discussed earlier.

The input segment consists of the previous UTXO (a combination of previous transaction hash and output index or Vout). It also consists of a ScriptSig, also known as the unlocking script.
The output segment consists of the value of BTC we want to send and also the ScriptPubKey, which contains the address of the user we want to send the amount to. We actually don\rquote t send the Bitcoins, rather, we lock the amount of BTC to a particular address using the ScriptPubKey which becomes the UTXO of that address. Hence it is also known as locking script.
Building the transaction without ScriptSig
Input Segment -

Input part of the transaction is used to identify the output of the previous transaction (UTXO) that we want to spend. It also contains scriptSig (or unlocking script), which represents the ownership to UTXO being spent.

For this example, we would use the following transaction as a funding transaction and would spend its first yield to create our new transaction: -

Utilizing the above exchange, let\rquote s prepare the input portion of our transaction: -

Number_Of_Inputs contains the total number of UTXOs being spent and is represented in one-byte hex-encoded format. Here we want to consume only one UTXO thereby, Number_Of_Inputs is \01\rdblquote
Previous_Tx_hash contains the hash of a transaction containing our UTXO. Notice hash is represented in reversed hash order as Bitcoin core RPCs accept and return the byte-wise reverse of computed SHA-256 values. Reversing the above displayed Transaction Id would result in \c033c70225a3c0b0c0e309083adc223be489a0176f871eb96990b81ac2362e1b\rdblquote
Previous_Output_Index is an index of the previous output. It is padded to 4 bytes and written in little-endian format. For example, we\rquote ll be using the output at the 0th index. Representing \0\rdblquote in 4-byte padded little-endian format would result in \00000000\rdblquote
Filling out the above-generated data in the transaction would look like: -

Output Segment -

Each output is an address receiving Bitcoin and the number of Bitcoins being sent to that address. Also, the output value being created must be less than the inputs being consumed as the difference is considered as transaction fees. The amount being sent must be represented as hex encoded eight bytes padded little-endian value.

Let us clearly understand it -

Suppose we want to send 30000 Satoshis ( the smallest unit of the Bitcoin cryptocurrency) to mys1o8PBWz4VACbJYaNoPDJsgNPWms5vzw, 30000 in hex is represented as 7530, padded to eight bytes and reversing results (little endian format) will give us 3075000000000000.

ScriptPubKey (or locking script) is used to lock the UTXO to a particular address so that only the private key corresponding to that particular address can spend it for future transactions. We won\rquote t go into the details of scripting now.

Basic Locking Script format:

Hex codes for the four opcodes in this locking script (OP_DUP is 0x76, OP_HASH160 is 0xa9, OP_EQUALVERIFY is 0x88, and OP_CHECKSIG is 0xac).

Using hex codes for above opcodes in locking script results in -

The \14\rdblquote we see is the PUSHDATA that represents a hex encoded number of bytes to be pushed in the stack. Converting hex encoded \14\rdblquote into decimal results in \20\rdblquote , which is the length of the pubkey hash.

PUB-KEY HASH can be obtained by performing a base58 decode on the address we want to send the Satoshis to and converting the result into hex. Thereby, this form of Bitcoin transaction is called P2PKH (Pay to PubKey Hash).

Performing above mentioned operation on mys1o8PBWz4VACbJYaNoPDJsgNPWms5vzw results c93d818d55482ef520438ab69040d4a2e5cbf790.

The final ScriptPubKey becomes:

\ 76a914c93d818d55482ef520438ab69040d4a2e5cbf79088ac\rdblquote

Script_Length is a hex encoded length of corresponding locking script.

Filling out output segment: -

Building the transaction message
Till now we have created a basic transaction template with inputs (except scriptSig) and outputs. ScriptSig (or Unlocking Script) is the most important part of the transaction. It ensures that you are the rightful owner of the UTXO that is being spent. ScriptSig is another Bitcoin script which is used to unlock the locking script present in UTXO. It majorly consists of a digital signature and public key of the spending user.

To produce digital signature, Bitcoin uses ECDSA implementation which requires private key along with a hash of a message to be signed.

This is where it gets a bit confusing, the transaction message consists of ScriptSig (digital signature) and to generate digital signature we require the transaction message.

Hmm\'85 that seems weird, but it isn\rquote t.

Actually, the transaction being signed is different than the transaction that would be sent across the Bitcoin network. In the transaction that is being signed, in place of ScriptSig (which we do not have yet for obvious reasons), we place the ScriptPubKey (or locking script) of the previous output which we want to spend. In short, we retrieve the ScriptPubKey from our funding transaction and add it to our transaction message.

Also, we include an additional field in our transaction message called SigHash Code, it is a type of flag that indicates what parts of our transaction are included in the signature. It is padded to 4 bytes and written in little-endian format.

SIGHASH_ALL (code=1) represents that signature includes all inputs and outputs of the transaction except the scriptSig. Representing \1\in 4-byte hex encoded little-endian format results in \01000000\rdblquote

Now we have the transaction message which is ready to get signed.

Signing the transaction message
To sign the transaction message first, we need to double SHA-256 hash the hex of transaction message which will give us a hashed raw transaction. The easiest way of performing hash is by using python or any online tool. The result is then converted to bytes to get signed.

Python code to double hash transaction message: -

As explained earlier Bitcoin uses ECDSA to generate the digital signature. The signature proves ownership and integrity of the transaction. It permits the Bitcoin verification software to verify that no changes are created to the numerous elements of the transaction since it had been signed.

Using following python script we can obtain ECDSA digital signature for the hashed raw transaction (note that we are using our private key to generate the signature):-

The generated signature consists of DER encoded R and S parts of which can either of 32 or 33 bytes in length. The various elements of our signature:

Putting it all together
Now we have the DER encoded digital signature through which ScriptSig can be generated. Remember ScriptSig is an unlocking script with signature as one of its constituents.

Basic unlocking script format:

PUSHDATA represents a hex encoded number of bytes to be pushed in the stack. It includes the length of signature + 1 byte (for SIGHASH code)
SIGNATURE is ECDSA digital signature that we have already generated
PUBKEY is our public key. The compressed public key is of length 32 bytes with a one-byte prefix of 0x02 or 0x03, which makes it a total of 33 bytes. Uncompressed public keys are of length 64 bytes with a prefix of 0x04
The final ScriptSig in hex:-

\47304402201413e8d3a18e6d5ae88b0dcccf329f68547a725f083abf7a7027a64315d3cb1902201dff0aa70a424699a8b7a336b63ba67bc237fa0ed36f062efacfd2525fc46a5801410418895208dbaac7622be18869a7fb16decc9ac36bd35310af8d3a5c156c04f79138435e1465ac635152354713fee2124abe47bb4ad93128b23e725cb9112fc70f\rdblquote

This ScriptSig can be now placed in our transaction. Our final transaction would look like :-

Finally, after all the hard work we have the transaction which can be serialized and broadcasted to bitcoin network. The serialized transaction would look like this:-

\0100000001c033c70225a3c0b0c0e309083adc223be489a0176f871eb96990b81ac2362e1b000000008a47304402201413e8d3a18e6d5ae88b0dcccf329f68547a725f083abf7a7027a64315d3cb1902201dff0aa70a424699a8b7a336b63ba67bc237fa0ed36f062efacfd2525fc46a5801410418895208dbaac7622be18869a7fb16decc9ac36bd35310af8d3a5c156c04f79138435e1465ac635152354713fee2124abe47bb4ad93128b23e725cb9112fc70fffffffff0130750000000000001976a914c93d818d55482ef520438ab69040d4a2e5cbf79088ac00000000\rdblquote

Before broadcasting transaction hex directly to bitcoin network lets first decode it and verify its constituents. For decoding we can use blockcypher decoder.

Here we can cross-check all the parameters that we calculated to construct our signature. Now we can broadcast this transaction in the Bitcoin blockchain network using blockcypher. If everything is fine, our transaction will be mined and added to the Bitcoin network forever!

Final words
So that pretty much sums it up. First, we had an overview of how Bitcoin works and the underlying technologies like blockchain and cryptography that make it so secure. After that, we understood the creation of a Bitcoin transaction and how it is signed in as much detail as we could. In the end, we successfully broadcasted our transaction in the Bitcoin network to prove that the signed transaction we constructed from scratch was actually a valid Bitcoin transaction.

}

Nie ma plików w tym folderze