Disclaimer: The information's contained in this explanation is the result of my understanding of Bitcoin Scripts and may contain some errors. Search and confirm about it.
Table of contents 1.
Introduction 2.
Bitcoin stack, Opcodes, Locktime, and Unspendable/Prunable Outputs 3.
P2PK, P2PKH, and P2SH 4.
why SegWit is a backward-compatible soft fork? 5.
coming soon.....IntroductionLet's imagine the following: The wallet is a private key that enables the user to spend money, Blockchain is a long belt of bags that anyone can look at and know their value, but only those who have the key can spend it.
When you want to send the money, you opens your bag, perform a new scan that indicates the old (which is then destroyed) and closes that bag, so the recipient can open it to spend and repeat the process.
By assuming the above, we can rename it as follows: private key (scriptSig) locker (scriptPubKey)
The outcome of combining the two gives us a tiny program, which each node check it.
A transaction is considered valid if the embedded script does not have anything to fail and the top stack item is True (non-zero).
Byte vectors are not allowed to be more than 520 bytes long, Opcodes be no more than 4 bytes long, except addition/subtraction (overflow a 5 byte.)
Script is a list of instructions recorded with each transaction, those instructions describe how the next person who wants to spend the transferred bitcoin can access it. it is simple, stack-based, processed from left to right, and not Turing-complete, with no loops. so is what governs the locking/unlocking mechanism.
Through it, a set of conditions can be set, such as providing multiple keys, there are no keys at all, adding a secret, a specific time and others.
Bitcoin stack, Opcodes, Locktime, and Unspendable/Prunable OutputsScript is what’s known as a stack-based language, but what is the stack?
Think you have a vertical column, you stack the data (signatures, hashes, ...etc) down and add new data to the top, we have instructions (opcodes) that tell us to do something, we work on one or more elements starting from the top.
Opcodes is a list of all Script words, new opcodes can be added by executed softfork using OP_NOP1-OP_NOP10.
False is zero or negative zero (using any number of bytes) or an empty array, and True is anything else.
Locktime:
scriptPubKey:
OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG
scriptSig: Unspendable/Prunable Outputs:
scriptPubKey: OP_RETURN {zero or more ops}
Script examples:
Data to be pushed to the stack (enclosed in angle brackets), data push commands are omitted, Non-bracketed words are opcodes.
Non-standard scripts are accepted if they are in a block, but nodes will not relay them.
scriptPubKey: OP_DUP OP_HASH160
OP_EQUALVERIFY OP_CHECKSIG
scriptSig: raw scriptPubKey:
76 A9 14
OP_DUP OP_HASH160 Bytes to push
89 AB CD EF AB BA AB BA AB BA AB BA AB BA AB BA AB BA AB BA 88 AC
Data to push OP_EQUALVERIFY OP_CHECKSIG
how each word is processed:
P2PK, P2PKH, and P2SHPay-to-Pubkey (P2PK):From the name you can deduce that it is paying (locking funds) to a particular public key (without first hashing the public key.) in this case you need to provide your public key.
Cons: longer payment addresses, and less protection (break in the ECDSA signature algorithm with the whole public key may enable the hacker to know the key to using quantum computers.)
scriptPubKey:
OP_CHECKSIG
scriptSig: Process:
Pay-to-Pubkey-Hash (P2PKH):Pay-to-Pubkey-Hash (P2PKH) is now the most common type of transaction.
The ScriptPubKey and ScriptSig for a transaction is shown below:
ScriptPubKey= OP_DUP OP_HASH160
OP_EQUAL OP_CHECKSIG
ScriptSig= OP_DUP:
Pops the first element, duplicates it, and adds both back to the stack.
The result will be: Perform an iterative operation without affecting the original
OP_HASH160:
Pops the first element, hashes it twice and add the result to the output.
First hash: with the SHA-256 algorithm.
Second hash: The SHA-256 output is hashed with the RIPEMD-160 algorithm.
OP_EQUALVERIFY:
Combines two other operators OP_EQUAL and OP_VERIFY.
OP_EQUAL: pops two elements and checks if they’re identical. Yes: adds a 1 to the stack. No: adds a 0 to the stack.
OP_VERIFY:
Pops the top element and checks. True (i.e., non-zero) is valid. else the transaction fails.
The public key is not disclosed when the recipient decides to transfer funds.
Pay-to-Script Hash(P2SH):lock funds to the hash of a script without knowing anything about the details of how to set up security. Then the recipient may need the signatures of many people to spend this bitcoin, or a password may be needed, or any requirements that may be completely unique.
Addresses:
BIP 13 specifies the address format. P2SH bitcoin address formats begin with the number 3 because we have a version byte prefix of 0x05 (3 after base58check encoding,) instead of the 0x00 prefix (1 after base58check encoding) in P2PKH addresses.
locking script is replaced with a redeem script hash,hash derives from a redeem script. when a transaction attempting to spend the UTXO input must contain the PubKey Script (that contains the redeem script hash) and the unlocking script.
scriptSig is <2>, scriptPubKey
<4> the following SHA-256 hash:
e145fe9ed5c23aa71fdb443de00c7d9b4a69f8a27a2e4fbb1fe1d0dbfb6583f1
P2SH output is:
OP_HASH160 OP_EQUAL
redeemScript hash: From the name you can deduce how it works, hash of the script we need to provide to redeem the funds.
Changing redeemScript == scriptSig change.
redeemScript treated as an element But at some point, it’ll be interpreted as instructions (you can make it anything.)
P2SH Advantages:
- fund/pay any arbitrary redeem script without knowing conditions: It seems logical, you as a sender do not need to know how the future will spend the money in the future.
- lower the transaction fees (for the sender): Fees are commensurate with transaction sizes.
- SegWit compatibility: SegWit is a soft fork as we said, you don't need to know the terms so it doesn't matter if clients include them.
why SegWit is a backward-compatible soft fork?
We have a scriptSig, a scriptPubKey, and a new field called the witness which represents scriptSig so scriptSig is empty.
witness data:
scriptSig:
Empty
scriptPubKey:
How does nodes that receives the transaction what to do? based on the length of they calculate it and understand it as P2PKH transaction.
How do nodes that did not upgrade deal? They read an empty scriptSig and some data so They don't know anything, but that doesn't matter as long as the transaction is valid.
coming soon.....
