Bitcoin Forum
May 05, 2024, 11:05:41 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Bitcoin Scripts for dummies  (Read 323 times)
Husires (OP)
Legendary
*
Offline Offline

Activity: 1596
Merit: 1285



View Profile WWW
July 14, 2020, 03:54:45 PM
Merited by LoyceV (8), dbshck (8), AB de Royse777 (5), joniboini (4), Symmetrick (3), Halab (2), DdmrDdmr (2), JayJuanGee (1), Daniel91 (1), ABCbits (1), witcher_sense (1)
 #1


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.....


Introduction


Let'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 Outputs


Script 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:

Code:
scriptPubKey: <expiry time> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>

Unspendable/Prunable Outputs:

Code:
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.

Code:
scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>

raw scriptPubKey:

Code:
  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 P2SH

Pay-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.)

Code:
scriptPubKey: <pubKey> OP_CHECKSIG
scriptSig: <sig>

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:

Code:
ScriptPubKey= OP_DUP OP_HASH160 <Public KeyHash> OP_EQUAL OP_CHECKSIG
ScriptSig= <Signature> <Public Key>

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 <multiply by 2> <4> <check if equal> the following SHA-256 hash:

e145fe9ed5c23aa71fdb443de00c7d9b4a69f8a27a2e4fbb1fe1d0dbfb6583f1

P2SH output is:

Code:
OP_HASH160 <redeemScript hash> 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:

Code:
<signature> <public key>

scriptSig:
Empty

scriptPubKey:

Code:
<OP_0> <public key hash>

How does nodes that receives the transaction what to do?  based on the length of <public key hash> 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.....








.BEST..CHANGE.███████████████
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
███████████████
..BUY/ SELL CRYPTO..
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
BrewMaster
Legendary
*
Offline Offline

Activity: 2114
Merit: 1292


There is trouble abrewing


View Profile
July 14, 2020, 05:08:12 PM
 #2

Quote
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.)
there is no addresses defined for P2PK scripts. and as for their security it is pretty much the same as everything else and if ECDSA were to be broken one day, nothing would be safe anymore.

Quote
lower the transaction fees (for the sender): Fees are commensurate with transaction sizes.
the size is too small to be considered an advantage for sender (2 bytes).
and receiver ends up paying higher fee because there is an additional push of the redeem script which takes up more space.

Quote
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.
it is a big deal for them because they have no way of verifying the transactions so if anybody spends anybody else's SegWit transactions they will not be able to verify which one is correct.

There is a FOMO brewing...
Husires (OP)
Legendary
*
Offline Offline

Activity: 1596
Merit: 1285



View Profile WWW
July 14, 2020, 06:36:35 PM
 #3

there is no addresses defined for P2PK scripts. and as for their security it is pretty much the same as everything else and if ECDSA were to be broken one day, nothing would be safe anymore.

I mean IP addresses.
No, Pay-to-Pubkey-Hash (P2PKH) is more secure because we see part a public key hash and not the whole key, in fact the addresses are considered safe Because our public key is not known until we spend the funds even ECDSA were to be broken.

the size is too small to be considered an advantage for sender (2 bytes).
and receiver ends up paying higher fee because there is an additional push of the redeem script which takes up more space.
Can you tell me how you did the calculation? I used to think that when we talk about P2SH, we have a weight units which is lower than P2PKH.

it is a big deal for them because they have no way of verifying the transactions so if anybody spends anybody else's SegWit transactions they will not be able to verify which one is correct.
correct so it is backward-compatible soft fork.

.BEST..CHANGE.███████████████
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
███████████████
..BUY/ SELL CRYPTO..
Husires (OP)
Legendary
*
Offline Offline

Activity: 1596
Merit: 1285



View Profile WWW
July 29, 2020, 08:39:32 PM
 #4

UP

.BEST..CHANGE.███████████████
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
███████████████
..BUY/ SELL CRYPTO..
Husires (OP)
Legendary
*
Offline Offline

Activity: 1596
Merit: 1285



View Profile WWW
July 30, 2020, 12:55:23 PM
 #5

P2PKH is more secure because the public key is hashed, not part of the public key.
Correct. The wording of the phrase was incorrect. I will adjust it. Thank you.

You're confused between regular P2SH and P2SH-P2WPKH (aka SegWit P2SH), only P2SH-P2WPKH have lower weight units size.
No, I compared P2SH & P2PKH transaction fess. will talk about P2SH-P2WPKH later.

.BEST..CHANGE.███████████████
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
██
███████████████
..BUY/ SELL CRYPTO..
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!