This is a course that a friend recommend me. We were talking about cryptocurrencies and we noticed I was quite clueless about how bitcoin works. I am not after the economy behind, that I can’t manage to fully understand. And when I see people treating crypto investments like fiat, it doesnt help me. Anyway, I really enjoyed he course, I learned a lot of things about the power of bitcoin, the technology and history. The proof-of-work concept so “simple” and beautiful. Double-spend, decentralization, wallets, key, hashes, forth-like reverse polish notation stack-based execution language, etc.

I am not by all means a BTC dev but I think helps you to understand what is going on under the hoods.

BITCOIN DEV COURSE

1 – INTRO TO BITCOIN

1.1 – What is bitcoin

21 million – 2140 – 4y halves production – each 10 minutes, validate transactions
decentralized peer2peer net
public transaction ledger – blockchain
consensus rules
proof-of-work algo (minig) -> avoid central system, global election every 10 min to get consensus about state of transaction -> avoid double-spend

double-spend problem <- digital signatures

2008 creation

solution to distribution computing problem – byzantine generals: trying to agree on a course of action by exchanging infor over an unreliable and potentially compromised network -> proof of work algo

The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power.

we propose a solution to the double-spending problem using a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions. The system is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes <!!!!!!!!!!!!!!!

electronic coin as a chain of digital signatures.

timestamp server

proof-of-work

1.1.1 -> review all points

1.2 P2P networks (the bitcoin network)

stratum protocol
node functions: routing, full blockchain DB, mining and wallet

bitcoin tcp 8333

$ bitcoin-cli getpeerinfo

1.3 Ledger entries (bitcoin transactions)

wallet -> construct transactions

The fundamental building block of a bitcoin transaction is a transaction output. Transaction outputs are indivisible chunks of bitcoin currency

Bitcoin full nodes track all available and spendable outputs, known as unspent transaction outputs, or UTXO.

very transaction represents a change (state transition) in the UTXO set.

each trans increases the UTXO set size by 1.

outputs are discrete and indivisible units of value, denominated in integer satoshis.

As a result of the indivisible nature of transaction outputs, most bitcoin transactions will have to generate change.

special type of transaction called the coinbase transaction, which is the first transaction in each block. This transaction is placed there by the “winning” miner and creates brand-new bitcoin payable to that miner as a reward for mining. This special coinbase transaction does not consume UTXO; instead, it has a special type of input called the “coinbase”. This is how bitcoin’s money supply is created during the mining process.

Transaction outputs is two parts:

• An amount of bitcoin, denominated in satoshis, the smallest bitcoin unit
• A cryptographic puzzle that determines the conditions required to spend the output = locking script, a witness script, or a scriptPubKey.

satoshi = 0.00000001

Trans input is four elements:

• A transaction ID, referencing the transaction that contains the UTXO being spent
• An output index (vout), identifying which UTXO from that transaction is referenced (first one is zero)
• A scriptSig, which satisfies the conditions placed on the UTXO, unlocking it for spending
• A sequence number

1.4 Intro to consensus

video about double spend – the first miner that solves the puzle advertise it and so that transaction is validated, and the second is ignored.

1.5: Decentralization: consensus algo, blockchain tech and bitcoin

video 1h 24m
sw dev
miners
exchange
wallet
merchants

1.6 Open systems

video

1.7 Exercise: loop up a trans on blockchain explorere

check blockchain viewer

study-guide

components and balance:

developers
miners
wallets
exchanges
users
merchants

exam

a transaction considered “confirmed” – When it has been included in a block

Value is transferred via ledger entries called UTXOs

Node operators decide which transactions are valid and will be propagated throughout the network.
Wallet makers decide which features they will include in their apps.

Bitcoin does not use accounts, but instead uses addresses. A transaction consumes one or more outputs from a previous transaction as input, and creates new outputs

Nodes share, network data, their inventory of blockchain data, and transactions that they have validated

=========================

Unit 2: Cryptographic Algorithms

2.1 Cryptography

btc -> hashing (one-way, create identifiiers, identify data tampering,… used in proof-of-work)
digital signatures: sign transactions. Message is signed with private key. Received using the public key of sender can check if the signature matches the message.
-> prevent forging transaction

2.2 Crypto keys

communications and transaction data are not encrypted

Ownership of bitcoin is established through digital keys, bitcoin addresses, and digital signatures.

digital keys are stored in wallet.

Most bitcoin transactions require a valid digital signature to be included in the blockchain,

The digital signature used to spend funds is also referred to as a witness,

In the payment portion of a bitcoin transaction, the recipient’s public key is represented by its digital fingerprint, called a bitcoin address,

In most cases, a bitcoin address is generated from and corresponds to a public key.

Bitcoin uses elliptic curve multiplication as the basis for its cryptography.

Bitcoin uses elliptic curve multiplication as the basis for its cryptography.

When spending bitcoin, the current bitcoin owner presents her public key and a signature (created with priv key)

k=priv key -> elliptic curve mult -> K=public key -> hashing -> A = btc address

priv key = 256-bit number. randomly.

$ bitcoin-cli getnewaddress
19rxWcjug44Xft1T1Ai11ptDZr94wEdRTz
$ bitcoin-cli dumpprivkey 19rxWcjug44Xft1T1Ai11ptDZr94wEdRTz
xxxx

or

$ bx seed | bx ec-new| bx ec-to-wif

dumpprivkey command shows the private key in a Base58 checksum-encoded format called the Wallet Import Format (WIF)

The public key is calculated from the private key using elliptic curve multiplication, which is irreversible: K=k∗G
, where k is the private key,
G is a constant point called the generator point
K is the resulting public key.

2.3 Basics of hashing

btc uses SHA256 (computing efficient, collision resistant, hide information, look random

2.4 keys and transactions signatures

hashing: hash message (static size) + priv key -> signature
verification: message + signature + public key -> yes/no

2.5 keys and btc addresses

btc addresses generated from public key. public key generated using secp256k1 curve

(x ** 3 + 7 – y**2) % p

Starting with a private key in the form of a randomly generated number k, we multiply it by a predetermined point on the curve called the generator point G
to produce another point somewhere else on the curve, which is the corresponding public key K

The generator point is specified as part of the secp256k1 standard and is always the same for all keys in bitcoin:

K = k * G

K = 1E99423A4ED27608A15A2616A2B0E9E52CED330AC530EDCC32C8FFC6A526AEDD * G

The bitcoin address is what appears most commonly in a transaction as the “recipient” of the funds.

public key + double hash: SHA256 and RIPEMD160 –> btc address

A = RIPEMD160(SHA256(K)) -> 160-bit (20-byte) address

Bitcoin addresses are almost always encoded as “Base58Check” -> uses 58 characters (a Base58 number system)

2.6 exercise

python example for enc/dec

pip3 install pycryptodome

>>> from Crypto.Cipher import PKCS1_OAEP
>>> from Crypto.PublicKey import RSA
>>> from binascii import hexlify
>>> 
>>> message = b'I love cryptography!'
>>> 
>>> private_key = RSA.generate(1024)
>>> 
>>> public_key = private_key.publickey()
>>> 
>>> private_pem = private_key.export_key().decode()
>>> public_pem = public_key.export_key().decode()
>>> 
>>> print(type(private_pem), type(public_pem))
<class 'str'> <class 'str'>
>>> 
>>> with open('private.pem', 'w') as pr:
...     pr.write(private_pem)
... 
886
>>> with open('public.pem', 'w') as pu:
...     pu.write(public_pem)
... 
271
>>> 
>>> print('private.pem:')
private.pem:
>>> with open('private.pem', 'r') as f:
...     print(f.read())
... 
-----BEGIN RSA PRIVATE KEY-----
MIIpDblbblalblalballbalblalb=
-----END RSA PRIVATE KEY-----
>>> 
>>> 
>>> print('public.pem:')
public.pem:
>>> with open('public.pem', 'r') as f:
...         print(f.read())
... 
-----BEGIN PUBLIC KEY-----
Mblballbalblablablalbalbllb
-----END PUBLIC KEY-----
>>> 
>>> 
>>> pr_key = RSA.import_key(open('private.pem', 'r').read())
>>> pu_key = RSA.import_key(open('public.pem', 'r').read())
>>> 
>>> print(type(pr_key), type(pu_key))
<class 'Crypto.PublicKey.RSA.RsaKey'> <class 'Crypto.PublicKey.RSA.RsaKey'>
>>> 
>>> cipher = PKCS1_OAEP.new(key=pu_key)
>>> cipher_text = cipher.encrypt(message)
>>> 
>>> print(cipher_text)
b"\xaaok\x1b/\xab\xe8A\xdf\xc9\xb3\xbb\xc4m\xa0\xe7\xc6\xae2\x87\xc9\xa9\x85?\xa27\xe0V\x85\xd9\xa7\x07h\xcb<\xfejm\x8c{\xcf\x94\xdf\x15f\xb6\xc1+\xa9\x90V\xa1\xb6zS\xe3\xf8n\x8d\x83\x95+\x8b\xee3o\x1d\x1d\xc6n\x05\x89\xf9'E\x1c|\xf3\x9c\x8d\x04\xfa{\xe3\x1b\xe2\xeb'q\xd3\xe1\x81\xd6c\x804\xcd\xf8@+\xfeU\xd5Lf0\xac\x1f\xce\x88\x82\x8b4\x03\x0c\xf2gy\x87\x9fy\x9c2\xb4 uGl"
>>> 
>>> 
>>> decrypt = PKCS1_OAEP.new(key=pr_key)
>>> decrypted_message = decrypt.decrypt(cipher_text)
>>> 
>>> print(decrypted_message)
b'I love cryptography!'
>>> 
>>> quit()

video

squiz

=========================

Unit 3: Signatures and Transactions

3.1: What is a Digital Signature?

Elliptic curve cryptography: there is addtion and multiplication, but there is no substraction and division -> you can get recover the original data (1 way function!)s
-> proof you have the priv key without revealing it

3.2: Exercise: Sign and Validate Data

pip3 install ecdsa

from ecdsa import SigningKey, SECP256k1
sk = SigningKey.generate(curve=SECP256k1)
print(sk)

vk = sk.verifying_key
print(vk)

signature = sk.sign(b”Not your keys, not your coins!”)
print(signature)

assert vk.verify(signature, b”Not your keys, not your coins!”)

print(“If your script runs to this point without an error, congrats, you successfully validated the signature!”)

3.3: Introduction to Bitcoin Transactions

command-line interface (getrawtransaction and decoderawtransaction)

The fundamental building block of a bitcoin transaction is a transaction output

Bitcoin full nodes track all available and spendable outputs, known as unspent transaction outputs, or UTXO

Every transaction represents a change (state transition) in the UTXO set.

A user’s wallet has “received” bitcoin, what we mean is that the wallet has detected on the blockchain an UTXO that can be spent with one of the keys controlled by that wallet.

The concept of a balance is created by the wallet application. The wallet calculates the user’s balance by scanning the blockchain and aggregating the value of any UTXO the wallet can spend with the keys it controls.

Notice how each transaction spends an UTXO that was created in a previous transaction, turning it into a spent transaction output, or STXO.

transactions #2 and #3 both create change outputs to the sender, spending a single UTXO and creating two UTXO (the payment and the change output).

bitcoin can be divided down to eight decimal places as satoshis.

outputs are discrete and indivisible units of value, denominated in integer satoshis. An unspent output can only be consumed in its entirety by a transaction.

If an UTXO is larger than the desired value of a transaction, it must still be consumed in its entirety and change must be generated in the transaction. In other words, if you have an UTXO worth 20 bitcoin and want to pay only 1 bitcoin, your transaction must consume the entire 20-bitcoin UTXO and produce two outputs: one paying 1 bitcoin to your desired recipient and another paying 19 bitcoin in change back to your wallet. As a result of the indivisible nature of transaction outputs, most bitcoin transactions will have to generate change.

special type of transaction called the coinbase transaction, which is the first transaction in each block. This transaction is placed there by the “winning” miner and creates brand-new bitcoin. coinbase transaction does not consume UTXO;

example transaction output:

• the transaction contains two outputs. Each output is defined by a value and a cryptographic puzzle (determines the conditions required to spend the output)

little-endian (least-significant-byte-first)

—

Transaction inputs identify (by reference) which UTXO will be consumed and provide proof of ownership through an unlocking script.

Sometimes one UTXO is enough, other times more than one is needed.

For each UTXO that will be consumed to make this payment, the wallet creates one input pointing to the UTXO and unlocks it with an unlocking script.

Most often, the unlocking script is a digital signature and public key proving ownership of the bitcoin.

output index (vout), identifying which UTXO from that transaction is referenced (first one is zero)

3.4: How Bitcoin Transactions Use Signatures

Elliptic Curve Digital Signature Algorithm, or ECDSA

ECDSA is used by the script functions OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG, and OP_CHECKMULTISIGVERIFY

A digital signature serves three purposes in bitcoin:
1- the signature proves that the owner of the private key, who is by implication the owner of the funds, has authorized the spending of those funds
2- the proof of authorization is undeniable (nonrepudiation)
3- the signature proves that the transaction (or specific parts of the transaction) have not and cannot be modified by anyone after it has been signed.

each transaction input is signed independently.

A digital signature is a mathematical scheme that consists of two parts:
1- an algorithm for creating a signature, using a private key (the signing key), from a message (the transaction).
2- an algorithm that allows anyone to verify the signature, given also the message and a public key.

Sig = Fsig(Fhash(message),priv-key)
Sig = (R, S)

The SIGHASH flag is a single byte that is appended to the signature. Every signature has a SIGHASH flag and the flag can be different from input to input.

There are three SIGHASH flags:
ALL: 0x01 signature applies to all inputs and outputs
NONE: 0x02 signature applies to all inputs, none of outputs (bearer check or blank check)
SINGLE: 0x03 signature applies to all inputs but only the one output with the same index number as the signed input

When ANYONECANPAY is set, only one input is signed, leaving the rest (and their sequence numbers) open for modification

ALL|ANYONECANPAY 0x81 Signature applies to one input and all outputs (crowdfunding)
NONE|ANYONECANPAY 0x82 Signature applies to one input, none of the outputs (dust collector = Users who have tiny UTXO in their wallets can’t spend these because the cost in fees exceeds the value of the dust)
SINGLE|ANYONECANPAY 0x83 Signature applies to one input and the output with the same index number

All SIGHASH types sign the transaction nLocktime field. In addition, the SIGHASH type itself is appended to the transaction before it is signed, so that it can’t be modified once signed.

SIGHASH_ALL flag is the most common signature form

the signature generation algorithm uses a random key k, as the basis for an ephemeral private/public key pair. The value of k is not important, as long as it is random.
The industry-standard algorithm for deterministic initialization of k is defined in RFC 6979

-locking scripts and transactions verification (video)

locking (pub key of the receiver and signature) <- sending funds

unlocking: your pub key and a signature created with private <- use funds

Review – view

locking: send funds
unlocking:

input: using uxto (we dont show the value, of 0.5 to pay 0.4) + unlocking script
output: 0.4 for the merchant + locking script with user public key
0.2 for me as the change + locking script with my public key

quiz

Validating a digital signature requires the original message, the signature, and the public key.
A digital signature is created using a private key and the message to be signed

=========================

Unit 4: Hashing and Mining

4.1: What is a Hash? video

hash -> 256bit (compression), one-way (no-reverse), no-collision, deterministic (same entry, same output)s.

4.2: Hashing Algorithms

Applications:

• verify integrity of messages/files (md5, sha-2, etc)
• signature generation and verification
• password verification: only store the hash digest of each password. To authenticate a user, the password presented by the user is hashed and compared with the stored hash. A password hash requires the use of a large random, non-secret salt value which can be stored with the password hash. The salt randomizes the output of the password hash, making it impossible for an adversary to store tables of passwords and precomputed hash values to which the password hash digest can be compared. The output of a password hash function can also be used as a cryptographic key. Password hashes are therefore also known as password-based key derivation functions (PBKDFs).
• proof-of-work: economic measure to deter DoS attacks. asymmetry: the work must be moderately hard (but feasible) on the requester side but easy to check for the service provider. The sender is required to find a message whose hash value begins with a number of zero bits. The average work that the sender needs to perform in order to find a valid message is exponential in the number of zero bits required in the hash value, while the recipient can verify the validity of the message by executing a single hash function. For instance, in Hashcash, a sender is asked to generate a header whose 160-bit SHA-1 hash value has the first 20 bits as zeros. The sender will, on average, have to try 219 times to find a valid header.
• file or data identifier

Algos:
md5: 128-b broken
sha-1: 160-b broken
ripemd-160: 160-b not broken
whirlpool: 512-b
sha-2: sha-256 and sha-512 (faster in 64b systems)
sha-3: configurable output size
blake2: no standard, faster than sha-3.
blake3: single algo. merkle tree

4.3: Exercise: Hash Something

import hashlib

mystring = 'Python is fun!'
print('Your string is:', mystring)

myhash = hashlib.sha256(mystring.encode())

print('Your SHA256 hash is:', myhash.hexdigest())

print('The length of your hash is:', len(myhash.hexdigest()))

4.4: Hashing and Bitcoin Mining

mining and consensus

Mining is the mechanism that underpins the decentralized clearinghouse, by which transactions are validated and cleared.
Mining is the invention that makes bitcoin special, a decentralized security mechanism that is the basis for P2P digital cash.

Miners validate new transactions and record them on the global ledger. A new block, containing transactions that occurred since the last block, is “mined” every 10 minutes on average, thereby adding those transactions to the blockchain. Transactions that become part of a block and added to the blockchain are considered “confirmed,” which allows the new owners of bitcoin to spend the bitcoin they received in those transactions.

Miners receive two types of rewards in return for the security provided by mining: new coins created with each new block, also known as a block reward or coinbase reward, and transaction fees from all the transactions included in the block. To earn this reward, miners compete to solve a difficult mathematical problem based on a cryptographic hash algorithm. The solution to the problem, called the Proof-of-Work, is included in the new block and acts as proof that the miner expended significant computing effort. The competition to solve the Proof-of-Work algorithm to earn the reward and the right to record transactions on the blockchain is the basis for bitcoin’s security model.

Deflationary Money: (21m max)

decentralized mechanism for emergent consensus (asynchronous)

Independent verification of each transaction, by every full node, based on a comprehensive list of criteria
Independent aggregation of those transactions into new blocks by mining nodes, coupled with demonstrated computation through a Proof-of-Work algorithm
Independent verification of the new blocks by every node and assembly into a chain
Independent selection, by every node, of the chain with the most cumulative computation demonstrated through Proof-of-Work

transacction validation: conditions can be seen in detail in the functions AcceptToMemoryPool, CheckTransaction, and CheckInputs in Bitcoin Core

$ bitcoin-cli getblockhash 277316
xxxx
$ bitcoin-cli getblock xxxx
yyyy

Mining Fees, Block Data, Block Headers, and Proof-of-Work

---

The Coinbase Transaction: The first transaction in any block. The coinbase transaction does not consume (spend) UTXO as inputs. Instead, it has only one input, called the coinbase, which creates bitcoin from nothing. The coinbase transaction has one output, payable to the miner’s own bitcoin address.

Total Fees = Sum(Inputs) – Sum(Outputs)

COIN constant (100,000,000 satoshis).

Miner only gets to spend the reward if the block is accepted by everyone.

block header: version, previous block hash, merkle root, timestamp, target, nonce

mining is the process of hashing the block header repeatedly, changing one parameter, until the resulting hash matches a specific target.

In SHA256 output of a script for generating many hashes by iterating on a nonce, the winning “nonce” is 13 and this result can be confirmed by anyone independently. Anyone can add the number 13 as a suffix to the phrase “I am Satoshi Nakamoto” and compute the hash, verifying that it is less than the target. The successful result is also Proof-of-Work, because it proves we did the work to find that nonce

Proof-of-Work must produce a hash that is equal to or less than the target. A higher target means it is less difficult to find a hash that is equal to or below the target. A lower target means it is more difficult to find a hash equal to or below the target. The target and difficulty are inversely related.

The difficulty of mining a bitcoin block is approximately ’10 minutes of processing’ for the entire network, based on the time it took to mine the previous 2016 blocks, adjusted every 2016 blocks. This is achieved by lowering or raising the target.

he primary influence on the mining market is the price of one kilowatt-hour of electricity in bitcoin, because that determines the profitability of mining and therefore the incentives to enter or exit the mining market.

Bitcoin can scale up, achieve broader adoption, and remain secure without any increase in hashing power from today’s level. The increase in hashing power represents market forces as new miners enter the market to compete for the reward.

https://www.youtube.com/watch?v=sdhb1ppD_aU — Bitcoin Q A How Is the Number of Zeros in the Target Hash Determined

4.5 Exercise: Try a Mining Simulator

https://andersbrownworth.com/blockchain/block

4.6: Merkle Trees

Each block in the bitcoin blockchain contains a summary of all the transactions in the block using a merkle tree = binary hash tree

A merkle tree is constructed by recursively hashing pairs of nodes until there is only one hash, called the root, or merkle root.

double-SHA256.

The merkle tree is constructed bottom-up.

Consecutive pairs of leaf nodes are then summarized in a parent node, by concatenating the two hashes and hashing them together

To prove that a specific transaction is included in a block, a node only needs to produce log~2~(N) 32-byte hashes,
??????????????

Video

use of hashges: sw integrity, digital signatures, password verification, data identifier, proof-of-work (email spam origina concept)

how to check hash L is in a block? you get specific hashes to proof to can get to the root hash

========================

Unit 5: Bitcoin Data

5.1: How Bitcoin Transmits Data on the Network

Peer-to-Peer Network Architecture

bitcoin p2p protocol, stratum protocol (mining and wallets)

Node Types and Roles

functions: net routing (N), DB (B), mining (M), wallet (W)

SPV – simplifief payment verification

Fast Internet Bitcoin Relay Engine or FIBRE – udp relay network: minimize the latency in the transmission of blocks between miners.

Network Discovery: tcp 8333
nversion (bitcoin p2p protocol), nlocalservics, ntime, addryou, addrme, subver (sw version satoshixxx), bestheight (block height)

The Bitcoin Core client contains the names of nine different DNS seeds.

Bitcoin Core, also known as the Satoshi client.

SVP nodes

SPV nodes download only the block headers and do not download the transactions included in each block
SPV nodes verify transactions using a slightly different method that relies on peers to provide partial views of relevant parts of the blockchain on demand.

SPV: denial-of-service attack or for a double-spending attack against SPV nodes
vulnerable to network partitioning attacks or Sybil attacks

For infallible security, however, nothing beats running a full blockchain node.

A full blockchain node verifies a transaction by checking the entire chain of thousands of blocks below it in order to guarantee that the UTXO is not spent, whereas an SPV node checks how deep the block is buried by a handful of blocks above it.

Bloom filters allow SPV nodes to receive a subset of the transactions without revealing precisely which addresses they are interested in, through a filtering mechanism that uses probabilities rather than fixed patterns. A bloom filter is a probabilistic search filter that offers an efficient way to express a search pattern while protecting privacy.

Explanation of how bloom filter works

1 patter
M hash functions: each produce a value between 1 and N
N-bits array.

To test if a pattern is part of a bloom filter, the pattern is hashed by each hash function and the resulting bit pattern is tested against the bit array. If all the bits indexed by the hash functions are set to 1, then the pattern is probably recorded in the bloom filter.

On the contrary, if a pattern is tested against the bloom filter and any one of the bits is set to 0, this proves that the pattern was not recorded in the bloom filter.
A negative result is not a probability, it is a certainty. In simple terms, a negative match on a bloom filter is a “Definitely Not!”

An SPV node will initialize a bloom filter as “empty”; in that state the bloom filter will not match any patterns. The SPV node will then make a list of all the addresses, keys, and hashes that it is interested in. It will do this by extracting the public key hash and script hash and transaction IDs from any UTXO controlled by its wallet. The SPV node then adds each of these to the bloom filter, so that the bloom filter will “match” if these patterns are present in a transaction, without revealing the patterns themselves.

The SPV node will then send a filterload message to the peer, containing the bloom filter to use on the connection. On the peer, bloom filters are checked against each incoming transaction. The full node checks several parts of the transaction against the bloom filter, looking for a match including:

The transaction ID
The data components from the locking scripts of each of the transaction outputs (every key and hash in the script)
Each of the transaction inputs
Each of the input signature data components (or witness scripts)

The network protocol and bloom filter mechanism for SPV nodes is defined in BIP-37 (Peer Services).

As a way to increase the privacy and security of the bitcoin P2P network, there are two solutions that provide encryption of the communications: Tor Transport and P2P Authentication and Encryption with BIP-150/151.

$ bitcoind –daemon –debug=tor

BIP-150 (Peer Authentication) and BIP-151 (Peer-to-Peer Communication Encryption).
As of February 2021, BIP-150 and BIP-151 are not implemented in Bitcoin Core

Almost every node on the bitcoin network maintains a temporary list of unconfirmed transactions called the memory pool, mempool, or transaction pool.

the transaction and orphan pools only contain unconfirmed transactions, while the UTXO pool only contains confirmed outputs.

5.2: Bitcoin Addresses and Keys

https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch04_keys.adoc

WIF = wallet import format

base58

Base58 is Base64 without the 0 (number zero), O (capital o), l (lower L), I (capital i), and the symbols: 123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz

Base58Check is a Base58 encoding format: The checksum is an additional four bytes added to the end of the data that is being encoded

version = differnt values depending on the data/payload

checksum = SHA256(SHA256(version+payload))

base58check = BASE58(version+payload+checksum)

From the resulting 32-byte hash (hash-of-a-hash), we take only the first four bytes. These four bytes serve as the error-checking code, or checksum.

              HEX    Base58

btc address -> 0x00 1
pay2script add -> 0x05 3
btc testnet add 0x6F m/n
priv key WIF 0x80 5/K/L
BIP-38 enc priv k 0x0142 6P
BIP-32 ext pub k 0x0488B21E xpub

priv key: raw (32 bytes) hex (64 hex digits), wif, wif-compressed

$ bx base58check-decode xxx
$ bx base58check-encode xxx –version zzz

compress -> append “01” to xxx

uncompressed public keys have a prefix of 04, compressed public keys start with either a 02 (even) or a 03 (odd) prefix (because y point in ellipti graph can have two values)

public key (x,y) -> 04xy uncompressed -> 02x (y even) or 03x (y odd) ==> uncompressed / compressed produces two different btc addresses!!!

priv key:
wif -> 5xxxx
wif-compress -> K/Lxxx

“Compressed private keys” is a misnomer! They are not compressed; rather, WIF-compressed signifies that the keys should only be used to derive compressed public keys and their corresponding bitcoin addresses. Ironically, a “WIF-compressed” encoded private key is one byte longer because it has the added 01 suffix to distinguish it from an “uncompressed” one.

https://github.com/huntrontrakkr/bitcoinbook/blob/master/key-to-address-ecc-example.py
https://github.com/huntrontrakkr/bitcoinbook/blob/master/ec-math.py

Bitcoin addresses that begin with the number “3” are pay-to-script hash (P2SH) addresses –> “joint account”
traditional “1” bitcoin addresses, also known as a pay-to-public-key-hash (P2PKH)

Vanity addresses are valid bitcoin addresses that contain human-readable messages: 1LoveBPzxxxx
Vanity addresses can be used to enhance and to defeat security measures; they are truly a double-edged sword.

Paper wallets are an OBSOLETE technology and are dangerous for most users.

Data Encoding

With Bitcoin, every byte in a transaction incurs a cost.

PEM or Privacy-Enhanced Mail format was developed for storing public and private keys in files. it uses base64

ASN.1 is a standard for data transmission, cross platform. It is used for the exchange of data between systems and is independent of any particular computer or programming language, it is also both human-readable and machine-readable.

DER or Distinguished Encoding Rules is a binary format. DER is intended for applications in which a unique octet(8-bit byte) string encoding is needed, which is the case with cryptographic signatures.

Endianness “A big-endian system stores the most significant byte of a word at the smallest memory address and the least significant byte at the largest.

In DER encoding data is stored in a Tag-Length-Value format.

5.3: Hex Encoding

base 16

5.4: How Bitcoin Stores Data in the Block Structure

The blockchain data structure is an ordered, back-linked list of blocks of transactions
The Bitcoin Core client stores the blockchain metadata using Google’s LevelDB database.
Blocks are linked “back,” each referring to the previous block in the chain.
first block ever created, known as the genesis block.

structure block: 4B block size, 80B block header, 1-9B trans counter, x trans

block header: 4B version, 32B previous block hash, 32B Merkle Root, 4B timestamp, 4B difficulty target, 4B nonce (proof-of-work)

The primary id of a block = hashing the block header twice through the SHA256 algorithm.
Note that the block hash is not actually included inside the block’s data structure,
The block hash might be stored in a separate database table as part of the block’s metadata, to facilitate indexing and faster retrieval of blocks from disk.

A second way to identify a block is by its position in the blockchain, called the block height.
The block height is also not a part of the block’s data structure;

5.5: Exercise: View Block Data

https://bitcoindev.network/bitcoin-cli-sandbox

Mainnet: This is THE Bitcoin network. Transactions on this network have real value. Testing any applications here is highly risky.

Testnet: This is a separate, much smaller network, designed specifically for testing. Transactions on this network exchange testnet coins. You can acquire testnet bitcoins at a testnet faucet such as https://testnet-faucet.mempool.co/. Testnet coins, by design, have no monetary value. They are simply exchanged between developers who are testing Bitcoin applications.

Regtest: This is an entirely local network. You could create a regtest network in your home for you and your roommates. Or set one up at the office, etc. It does not link to mainnet or testnet in any way. It is your own private Bitcoin network.

./bin/bitcoind -regtest -daemon
./bin/bitcoin-cli -regtest stop

./bin/bitcoin-cli -regtest createwallet "wallet1"
./bin/bitcoin-cli -regtest getwalletinfo
./bin/bitcoin-cli -regtest getnewaddress
./bin/bitcoin-cli -regtest generatetoaddress 101 ADDRESS /// create 101 coins/blocks to the ADDRESS
./bin/bitcoin-cli -regtest getblock BLOCKHASH
./bin/bitcoin-cli -regtest getbalance
./bin/bitcoin-cli -regtest -getinfo
./bin/bitcoin-cli -regtest getblockcount

~/btc/bitcoin-27.0$ ./bin/bitcoind
Bitcoin Core starting
go:system|py:btc|tomas@athens:~/btc/bitcoin-27.0$ lsof -i -P -n
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
cli 1720 tomas 10u IPv4 31050 0t0 TCP 127.0.0.1:54150 (LISTEN)
chrome 88292 tomas 460u IPv4 421797 0t0 UDP 224.0.0.251:5353
chrome 88349 tomas 19u IPv4 437188 0t0 TCP 192.168.0.86:48570->34.117.244.60:443 (ESTABLISHED)
chrome 88349 tomas 40u IPv6 417531 0t0 TCP [2a02:8109:b00a:1200:cb1b:f32a:9f9e:48db]:45718->[2a00:1450:4025:c01::bc]:5228 (ESTABLISHED)
bitcoind 96069 tomas 11u IPv6 443969 0t0 TCP [::1]:18443 (LISTEN)
bitcoind 96069 tomas 12u IPv4 443971 0t0 TCP 127.0.0.1:18443 (LISTEN)
bitcoind 96069 tomas 24u IPv4 437239 0t0 TCP 127.0.0.1:18445 (LISTEN)
bitcoind 96069 tomas 25u IPv6 437240 0t0 TCP *:18444 (LISTEN)
bitcoind 96069 tomas 27u IPv4 437241 0t0 TCP *:18444 (LISTEN)
~/btc/bitcoin-27.0$

https://live.blockcypher.com/btc

5.6: Exercise: Convert Data between Decimal, Base58, and Hex

mybase58 = base58.b58encode(mystring)
base58.b58decode()

$ openssl genrsa -out private.pem
$ openssl rsa -in private.pem -out privkey.der -outform der
xxd -p privkey.der

VIDEO

quiz

=====================

Unit 6: Bitcoin Nodes and Wallets

6.1: What a Node Does

node runs btc protocol to advertise blocks and transaction (it is a verification authority) – verify each transaction and block. node sends bad info is isolated
miners create the blocks but nodes validating

6.2: Who Runs a Node and Why?

nodes have diffenrent roles. you run a node, you improve your privacy and participate in the consensus process and validating transactions.

6.3: Exercise: Set Up a Regtest Node

6.4: The Functions of a Bitcoin Wallet (SUPER LONG!!!!)

wallet controls access to a user’s money, managing keys and addresses, tracking the balance, and creating and signing transactions.

the word “wallet” refers to the data structure used to store and manage a user’s keys.

Bitcoin wallets contain keys, not coins. The coins are stored on the blockchain in the form of transaction outputs (often noted as vout or txout).

nondeterministic wallet: JBOK – “Just a Bunch Of Keys”. is discouraged for anything other than simple tests. They are simply too cumbersome to back up and use.
deterministic wallet: are initialized from a random sequence = English words

HD Wallets (BIP-32/BIP-44): tree structure for generating keys + create a sequence of public keys without having access to the corresponding private keys

Seeds and Mnemonic Codes (BIP-39)

BIP-39 defines the creation of a mnemonic code and seed, which we describe here in nine steps. For clarity, the process is split into two parts: steps 1 through 6 are shown in Generating mnemonic words and steps 7 through 9 are shown in From mnemonic to seed.

1 Create a random sequence (entropy) of 128 to 256 bits.
2 Create a checksum of the random sequence by taking the first (entropy-length/32) bits of its SHA256 hash.
3 Add the checksum to the end of the random sequence.
4 Split the result into 11-bit length segments.
5 Map each 11-bit value to a word from the predefined dictionary of 2048 words.
6 The mnemonic code is the sequence of words.

The mnemonic words represent entropy with a length of 128 to 256 bits. The entropy is then used to derive a longer (512-bit) seed through the use of the key-stretching function PBKDF2. The seed produced is then used to build a deterministic wallet and derive its keys.

7 The first parameter to the PBKDF2 key-stretching function is the mnemonic produced from step 6.
8 The second parameter to the PBKDF2 key-stretching function is a salt. The salt is composed of the string constant “mnemonic” concatenated with an optional user-supplied passphrase string.
9 PBKDF2 stretches the mnemonic and salt parameters using 2048 rounds of hashing with the HMAC-SHA512 algorithm, producing a 512-bit value as its final output. That 512-bit value is the seed.

Providing more than 12 words produces additional entropy which is unnecessary, and this unused entropy is not used for the derivation of the seed in the way that one might intially suspect. From a usability perspective, 12 words is also easier to write down, back up, and store.

There are no “wrong” passphrases in BIP-39. Every passphrase leads to some wallet, which unless previously used will be empty.

While passphrases are very useful, they should only be used in combination with a carefully planned process for backup and recovery, considering the possibility of surviving the owner and allowing his or her family to recover the cryptocurrency estate.

Every key in the HD wallet is deterministically derived from this root seed, which makes it possible to re-create the entire HD wallet from that seed in any compatible HD wallet.

The child key derivation functions are based on a one-way hash function that combines:
A parent private or public key (ECDSA compressed key)
A seed called a chain code (256 bits)
An index number (32 bits)

These three items (parent key, chain code, and index) are combined and hashed to generate children keys, as follows

Child private keys are indistinguishable from nondeterministic (random) keys.

So what can the child private key be used for on its own? It can be used to make a public key and a bitcoin address. Then, it can be used to sign transactions to spend anything paid to that address.

: An extended key consists of a private or public key and chain code. An extended key can create children, generating its own branch in the tree structure. Sharing an extended key gives access to the entire branch.

. The Base58Check coding for extended keys uses a special version number that results in the prefix “xprv” and “xpub” when encoded in Base58 characters to make them easily recognizable

As mentioned previously, a very useful characteristic of HD wallets is the ability to derive public child keys from public parent keys, without having the private keys. This gives us two ways to derive a child public key: either from the child private key, or directly from the parent public key.

A single leaked child private key, together with a parent chain code, reveals all the private keys of all the children -> The hardened derivation function looks almost identical to the normal child private key derivation, except that the parent private key is used as input to the hash function, instead of the parent public key

The index number used in the derivation function is a 32-bit integer.
the index number is less than 2^31, the child is normal, whereas if the index number is equal or above 2^31, the child is hardened.

Each parent extended key can have 4 billion children: 2 billion normal children and 2 billion hardened children. Each of those children can have another 4 billion children, and so on.

BIP-44 specifies the structure as consisting of five predefined tree levels:
m / purpose’ / coin_type’ / account’ / change / address_index

Tip: Gap limits explain the phenomenon whereby the importing of a wallet may show an incorrect or zero balance. The funds are not lost, but rather, the wallet importing function has not traversed enough leaves to fully detect funds. Many wallets allow this default gap limit to be changed,

6.5: Exercise: View Your Node Wallet Data

~/btc/bitcoin-27.0$ ./bin/bitcoin-cli -regtest createrawtransaction '[{"txid": "blablatxid", "vout": 0}]' '[{"addresstosent": 0}]'
blablabla

~/btc/bitcoin-27.0$ ./bin/bitcoin-cli -regtest signrawtransactionwithwallet blablabla
{
"hex": "blablablasigned",
"complete": true
}

~/btc/bitcoin-27.0$ ./bin/bitcoin-cli -regtest sendrawtransaction blablablasigned
error code: -26
error message:
dust

$ bitcoin-cli gettransaction [our transaction ID]

6.6 Video

determinustic wallet: just backup the seed to recover the keys
hierarchical determistic HD wallet: 1 seed -> 1 master key -> x child keys -> each child key generates x granchild keys

BIP-39: mnemonic code words + salt -> 2048 rounds of hmac-sha512 -> 512b seed

BIP-44: derivation path: m / purpose (44) / coin_type (0=btc 2=litcoin) / account’ / change (receiving and change address) / address_index

xpub key:

hot wallet: mobile phone (internet access), cold wallet: usb key (no connection to internet)
custodial (coinbase) vs non-custodial (I keep the keys)

wallet:
generate/store keys,
construct transactions
sign transactions with keys
track tr7.1: What’s in a Transaction?
Wansactions

quiz

Unit 7: Transactions and Scripting

7.1: What’s in a Transaction?

Transactions are the most important part of the bitcoin system.
Everything else in bitcoin is designed to ensure that transactions can be created, propagated on the network, validated, and finally added to the global ledger
Transactions are data structures that encode the transfer of value between participants in the bitcoin system.
Each transaction is a public entry in bitcoin’s blockchain, the global double-entry bookkeeping ledger.

Transaction Fees

Most transactions include transaction fees, which compensate the bitcoin miners for securing the network.
Fees also serve as a security mechanism themselves, by making it economically infeasible for attackers to flood the network with transactions.
Transaction fees are calculated based on the size of the transaction in kilobytes,
Transaction fees are not mandatory
Fee estimation algorithms: https://bitcoinfees.earn.com/ (old not working)
The data structure of transactions does not have a field for fees. Instead, fees are implied as the difference between the sum of inputs and the sum of outputs.
Fees=Sum(Inputs)–Sum(Outputs)

Warning: If you forget to add a change output in a manually constructed transaction, you will be paying the change as a transaction fee. Saying “Keep the change!” to the miner might not be what you really intended

7.2: The Transaction Timeline

video

7.3: Transaction Scripting

When a transaction is validated, the unlocking script in each input is executed alongside the corresponding locking script to see if it satisfies the spending condition.
“programmable money” -> because the Script language

there are no loops or complex flow control capabilities other than conditional flow control -> not Turing Complete -> scripts have limited complexity and predictable execution times

The bitcoin transaction script language is stateless -> all the info needed to execute a script is contained within the script -> A script will predictably execute the same way on any system.

Script Construction (Lock + Unlock)

• A locking script is a spending condition placed on an output: it specifies the conditions that must be met to spend the output in the future (scriptPubKey)
• An unlocking script is a script that “solves,” or satisfies, the conditions placed on an output by a locking script and allows the output to be spent (scriptSig). Unlocking scripts are part of every transaction input.

Every bitcoin validating node will validate transactions by executing the locking and unlocking scripts together. Each input contains an unlocking script and refers to a previously existing UTXO. The validation software will copy the unlocking script, retrieve the UTXO referenced by the input, and copy the locking script from that UTXO. The unlocking and locking script are then executed in sequence. The input is valid if the unlocking script satisfies the locking script conditions

most common type of bitcoin transaction (a payment to a public key hash) = Pay-to-Public-Key-Hash (P2PKH)

(forth-like reverse polish notetion stack-based execution language)
Bitcoin’s scripting language is called a stack-based language – stack = LIFO (last-in, first-out)
Transactions are invalid if the top value on the stack is FALSE (a zero-length empty value, or if script execution is halted explicitly by an operator, such as OP_VERIFY,
OP_RETURN, or a conditional terminator such as OP_ENDIF.
The scripts are executed separately with the stack transferred between the two executions, as described next.

First, the unlocking script is executed, using the stack execution engine. If the unlocking script is executed without errors (e.g., it has no “dangling” pointers left over), the main stack is copied and the locking script is executed. If the result of executing the locking script with the stack data copied from the unlocking script is “TRUE,” the unlocking script has succeeded in resolving the conditions imposed by the locking script and, therefore, the input is a valid authorization to spend the UTXO.

locking script: OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG
unlocking script:

Advanced Transactions and Scripting

Multisignature

N public keys are recorded in the script and at least M of those must provide signatures to unlock the funds.
M-of-N (M<=N) At the moment max N=3. but P2SH has max N=15

code: M … N CHECKMULTISIG

ie: 0 2 3 CHECKMULTISIG
0 ->it is added due to a bug!!!

Pay-to-Script-Hash (P2SH)

P2SH means “pay to a script matching this hash, a script that will be presented later when this output is spent.”

With P2SH payments, the complex locking script is replaced with its digital fingerprint, a cryptographic hash. When a transaction attempting to spend the UTXO is presented later, it must contain the script that matches the hash, in addition to the unlocking script.

Redeem Script 2 PubKey1 PubKey2 PubKey3 PubKey4 PubKey5 5 CHECKMULTISIG
Locking Script HASH160 <20-byte hash of redeem script> EQUAL
Unlocking Script 0 Sig1 Sig2

<2 PK1 PK2 PK3 PK4 PK5 5 CHECKMULTISIG> EQUAL

P2SH scripts can invalidate transactions by way of their unlocking script only.

P2SH addresses (20byte) use the version prefix “5,” which results in Base58Check-encoded addresses that start with a “3”.

P2SH addresses hide all of the complexity, so that the person making a payment does not see the script.

You are not able to put a P2SH inside a P2SH redeem script, because the P2SH specification is not recursive.

IMPORTANT! Note that because the redeem script is not presented to the network until you attempt to spend a P2SH output, if you lock an output with the hash of an invalid redeem script it will be processed regardless. And then you will not be able unlock the funds

RETURN operator allows developers to add 80 bytes of nonpayment data to a transaction output. However, unlike the use of “fake” UTXO, the RETURN operator creates an explicitly provably unspendable output, which does not need to be stored in the UTXO set -> no bloat!

there is no “unlocking script” that corresponds to RETURN that could possibly be used to “spend” a RETURN output.

Timelocks are useful for postdating transactions and locking funds to a date in the future. More importantly, timelocks extend bitcoin scripting into the dimension of time, opening the door for complex multistep smart contracts.

nLocktime=0 -> immediate propagation and execution.
< 500 million. it is interpreted as a block height, meaning the transaction is not valid and is not relayed or included in the blockchain prior to the specified block height. >=500 million, it is interpreted as a Unix Epoch and the transaction is not valid prior to the specified time.
The use of nLocktime is equivalent to postdating a paper check.

nLocktime + double-spending issue -> timelock restriction must be placed on the UTXO itself and be part of the locking script, rather than on the transaction.

Check Lock Time Verify (CLTV) is a per-output timelock, rather than a per-transaction timelock as is the case with nLocktime.
-By adding the CLTV opcode in the redeem script of an output it restricts the output, so that it can only be spent after the specified time has elapsed.
-CLTV doesn’t replace nLocktime, but rather restricts specific UTXO such that they can only be spent in a future transaction with nLocktime set to a greater or equal value.

CHECKLOCKTIMEVERIFY DROP DUP HASH160 EQUALVERIFY CHECKSIG

Relative Timelocks: they allow a chain of two or more interdependent transactions to be held off chain, while imposing a time constraint on one transaction that is dependent on the elapsed time from the confirmation of a previous transaction. In other words, the clock doesn’t start counting until the UTXO is recorded on the blockchain.

• For transactions with nLocktime or CHECKLOCKTIMEVERIFY, the nSequence value must be set to less than 2^31 for the timelock guards to have an effect,
• A transaction can include both timelocked inputs (nSequence < 231) and inputs without a relative timelock (nSequence >= 231).
• The nSequence value is specified in either blocks or seconds
• CHECKSEQUENCEVERIFY (CSV) script opcode for relative timelocks that leverages the nSequence value in scripts
• Relative timelocks with CSV are especially useful when several (chained) transactions are created and signed, but not propagated, when they’re kept “off-chain”. A child transaction cannot be used until the parent transaction has been propagated, mined, and aged by the time specified in the relative timelock.

Median-Time-Past is calculated by taking the timestamps of the last 11 blocks and finding the median. That median time then becomes consensus time and is used for all timelock calculations. By taking the midpoint from approximately two hours in the past, the influence of any one block’s timestamp is reduced. By incorporating 11 blocks, no single miner can influence the timestamps in order to gain fees from transactions with a timelock that hasn’t yet matured.

Fee-sniping is a theoretical attack scenario, where miners attempting to rewrite past blocks “snipe” higher-fee transactions from future blocks to maximize their profitability.
-> Bitcoin Core sets the nLocktime on all new transactions to and sets the nSequence on all the inputs to 0xFFFFFFFE to enable nLocktime.

Complex Scripts

Scripts with Flow Control

opcodes: IF, ELSE, ENDIF, and NOTIF
boolean operators: BOOLAND, BOOLOR, and NOT.
flow control clauses look “backward”: 1 2 ADD, => 1 + 2

VERIFY suffix means that if the condition evaluated is not TRUE, execution of the script terminates immediately and the transaction is deemed invalid.
Opcodes that end in VERIFY do not leave the result on the stack.
ie: A redeem script with an EQUALVERIFY guard clause: HASH160 EQUALVERIFY CHECKSIG

if
script A
else
if
script B
else
scirpt C
endif
endif

-> to execute script B, we need to push to the stack: 1 0 -> 0 will be top of the stack and will fail first if, the next value of the stackc is 1 and it will accept the second if and will execute script B

• If you use CHECKMULTISIG -> must push a 0 first in the stack

Segregated Witness (segwit) = “separate scriptSig”
every locking script is preceded by a script version number,
The witness data doesn’t need to be transmitted to all nodes and does not need to be stored on disk by all nodes.
Signature Verification Optimization = O(n)
egregated Witness is a change to how individual UTXO are spent and therefore is a per-output feature.

When a transaction spends an UTXO, it must provide a witness. In a traditional UTXO, the locking script requires that witness data be provided inline in the input part of the transaction that spends the UTXO. A Segregated Witness UTXO, however, specifies a locking script that can be satisfied with witness data outside of the input (segregated).

P2WPKH should be constructed by the payee (recipient) by converting a compressed public key to a P2WPKH hash. You should never transform a P2PKH script, bitcoin address, or uncompressed public key to a P2WPKH witness script.

Pay-to-Witness-Script-Hash (P2WSH) = SHA256(script) = 32 bytes script hash
Pay-to-Script-Hash (P2SH) = RIPEMD160(SHA256(script) = 20 bytes script hash

Two types of witness programs:
Pay-to-Witness-Public-Key-Hash (P2WPKH) – public key hash is 20 bytes
Pay-to-Witness-Script-Hash (P2WSH) – script hash is 32 bytes

upgrading to Segregated Witness is a two-step process:
1) wallets must create special segwit type outputs
2) these outputs can be spent by wallets that know how to construct Segregated Witness transactions

For P2WPKH and P2WSH payment types, both the sender and the recipient wallets need to be upgraded to be able to use segwit. Furthermore, the sender’s wallet needs to know that the recipient’s wallet is segwit-aware.

Bob’s wallet can construct a P2SH address that contains a segwit script inside it. Alice’s wallet sees this as a “normal” P2SH address and can make payments to it without any knowledge of segwit.

P2WPKH and P2WSH, can be embedded in a P2SH address.

The native segwit address format is defined in BIP-173: BIP-173 addresses use 32 lower-case-only alphanumeric character set, carefully selected to reduce errors from misreading or mistyping

[bc|tb]1[6-90 chars]

With the introduction of Segregated Witness, transactions have two identifiers, txid and wtxid. The traditional transaction ID txid is the double-SHA256 hash of the serialized transaction, without the witness data. A transaction wtxid is the double-SHA256 hash of the new serialization format of the transaction with witness data.

The traditional txid, since a pure segwit transaction, has empty scriptSigs in every input, there is no part of the transaction that can be modified by a third party.

The wtxid is like an “extended” ID, in that the hash also incorporates the witness data.

signature verification for segwit -> BIP-143: O(n) (instead of O(n2)

The most expensive part of a transaction are the newly created outputs, as they are added to the in-memory UTXO set

Segregated Witness has two main effects on the fees paid by bitcoin users:
1) segwit reduces the overall cost of transactions by discounting witness data and increasing the capacity of the bitcoin blockchain.
2) segwit’s discount on witness data partially mitigates a misalignment of incentives that may have inadvertently created more bloat in the UTXO set.

Transactions and Multisig

https://www.youtube.com/watch?v=Zhd107b8DqA&t=2s
Advanced Bitcoin Scripting Part 1 Transactions Multisig

7.4 Exercise: Bitcoin Scripting

Script Simulator: https://siminchen.github.io/bitcoinIDE/build/editor.html
Opcodes: https://en.bitcoin.it/wiki/Script#Opcodes

7.5 Video

quix

Unit 8: Reaching Consensus

8.1: Elements of Valid Transactions

Honest Nodes and Consensus
difficulty: “hash must be a number less than x”
double-spent (unspent db)
consensus: rules what is valid

8.2: The Mining Process

Mining is the process how we prevent “double spends”, how we determine who has what when, and how we decide on the “truth” on the network without any one entity being in charge of the process.

hash functions, proof of work. Consume electricity!

genesis block: first ever block

8.3: Consensus

validating a new block

block data structure is syntactivally valid, block header hash is equal or less than the targe (proof of work),
block timestamp is less than two hours n the future , block size is within limits, first transaction is a coinbase transaction
all transaction within the block are valid using the transactin checklist

assembling and selection chains of blocks

Nodes maintain three sets of blocks:
-connected to the main blockchain
-branches off the main blockchain (secondary chains)
-orphans: blocks that do not have a known parent in the known chains

The “main chain” at any time is whichever valid chain of blocks has the most cumulative Proof-of-Work associated with it. Under most circumstances this is also the chain with the most blocks in it

When a new block is received, a node will try to slot it into the existing blockchain. The node will look at the block’s “previous block hash” field, which is the reference to the block’s parent. Then, the node will attempt to find that parent in the existing blockchain. Most of the time, the parent will be the “tip” of the main chain, meaning this new block extends the main chain.

Sometimes, as we will see in Blockchain Forks, the new block extends a chain that is not the main chain. In that case, the node will attach the new block to the secondary chain it extends and then compare the work of the secondary chain to the main chain. If the secondary chain has more cumulative work than the main chain, the node will reconverge on the secondary chain, meaning it will select the secondary chain as its new main chain, making the old main chain a secondary chain. If the node is a miner, it will now construct a block extending this new, longer, chain.

If a valid block is received and no parent is found in the existing chains, that block is considered an “orphan.” Orphan blocks are saved in the orphan block pool where they will stay until their parent is received. Once the parent is received and linked into the existing chains, the orphan can be pulled out of the orphan pool and linked to the parent, making it part of a chain. Orphan blocks usually occur when two blocks that were mined within a short time of each other are received in reverse order (child before parent).

*** Blockchain Forks: good explanation

Bitcoin’s block interval of 10 minutes is a design compromise between fast confirmation times (settlement of transactions) and the probability of a fork. A faster block time would make transactions clear faster but lead to more frequent blockchain forks, whereas a slower block time would decrease the number of forks but make settlement slower.

Mining and the Hashing Race: ASICs, terahashes/sec (TH/sec)

Use the coinbase transaction as a source of extra nonce values. Because the coinbase script can store between 2 and 100 bytes of data, miners started using that space as extra nonce space, allowing them to explore a much larger range of block header values to find valid blocks.
The coinbase transaction is included in the merkle tree, which means that any change in the coinbase script causes the merkle root to change

Mining pools: proof-of-work easier than the target, so you can proof you are trying.

Pool miners connect to the pool server using a mining protocol such as Stratum (STM) or GetBlockTemplate (GBT). Both the STM and GBT protocols create block templates that contain a template of a candidate block header. The pool server constructs a candidate block by aggregating transactions, adding a coinbase transaction (with extra nonce space), calculating the merkle root, and linking to the previous block hash. The header of the candidate block is then sent to each of the pool miners as a template. Each pool miner then mines using the block template, at a higher (easier) target than the bitcoin network target, and sends any successful results back to the pool server to earn shares.

P2Pool, a peer-to-peer mining pool without a central operator. P2Pool works by decentralizing the functions of the pool server, implementing a parallel blockchain-like system called a share chain.
P2Pool mining is more complex than pool mining because it requires that the pool miners run a dedicated computer with enough disk space, memory, and internet bandwidth to support a full bitcoin node and the P2Pool node software.

The Consensus Process

video about the above

The Consensus Attacks

Bitcoin’s ledger becomes more and more immutable as time passes. While in theory, a fork can be achieved at any depth, in practice, the computing power needed to force a very deep fork is immense, making old blocks practically immutable.

Consensus attacks also do not affect the security of the private keys and signing algorithm (ECDSA). A consensus attack cannot steal bitcoin, spend bitcoin without signatures, redirect bitcoin, or otherwise change past transactions or ownership records. Consensus attacks can only affect the most recent blocks and cause denial-of-service disruptions on the creation of future blocks.

A double-spend attack can happen in two ways: either before a transaction is confirmed, or if the attacker takes advantage of a blockchain fork to undo several blocks. A 51% attack allows attackers to double-spend their own transactions in the new chain, thus undoing the corresponding transaction in the old chain.

The more confirmations elapse, the harder it becomes to invalidate a transaction with a 51% attack.

The other scenario for a consensus attack is to deny service to specific bitcoin participants (specific bitcoin addresses). An attacker with a majority of the mining power can simply ignore specific transactions.

8.4: Updating Consensus

hard fork: part of the network is operating under a different set of consensus rules (bug or change of consensus rules). not forward compatible
hard fork: sw fork -> net fork -> mining fork -> chain fork

fork -> diverging miner capacity -> blocks take more time to be generated.

Only consensus changes that are forward-incompatible cause a hard fork.
If the change is implemented in such a way that a non-upgraded client still sees the transaction or block as valid under the previous rules, the change can happen without a fork = soft fork is a forward-compatible

Soft forks redefining NOP opcodes:
NOP1 through NOP10. Under the consensus rules, the presence of these opcodes in a script is interpreted as a null-potent operator, meaning they have no effect. Execution continues after the NOP opcode as if it wasn’t there. A soft fork therefore can modify the semantics of a NOP code to give it new meaning.

critics:
Because soft forks create transactions with additional consensus constraints, they become irreversible upgrades in practice.

Since soft forks allow non-upgraded clients to continue to operate within consensus, the mechanism for “activating” a soft fork is through miners signaling readiness:

BIP-34 Signaling and Activation: change block version to 2. When 95% (out 1000) new blocks are version 2, version 1 block are rejected. This was good but it was improved with the next

BIP-9 Signaling and Activation: interprets the block version as a bit field instead of an integer. BIP-9 also sets a maximum time for signaling and activation.

It is important to recognize that there is no perfect solution for consensus development. Both hard forks and soft forks involve tradeoffs.

8.5: Exercise: Create a Valid Transaction via Your Testnet Node

8.6

video

measure amount of proof of work: “difficulty” to generate the block – number of zeros needed to get the block
consensus attack: can’t steal bitcoin, can’t break crypto, etc
can double spend !!! DDOS, etc

bip-34: version = integer value
bip-9: version = bit field (better)