bitcoin_devs

bitcoin

Segwit Address Explained (Bech32)

It generally help detect typos/errors in an address but does not verify whether the address is actually in use or belongs to anyone. If you generate a valid Bitcoin address but never use it, BTC sent to that address will be lost forever

Find the complete tutorial series of bitcoin technical concepts at https://bitcoindevs.xyz/decoding/welcome

---
### HASHERS AREN'T MINERS.

Mining Process:
1. Running a Node
2. Begin construction of a new block template
3. Select Transactions: From the pool of unconfirmed transactions
4. Create coinbase Tx
5. Constructing Merkle Trees
6. Hashing for the Block Solution
7.1. If success, submit the block

Hashing Process:
1. Only Hash

![](https://m.stacker.news/78175)

Hashing IS NOT Mining

Thanks, glad to hear that! 
We're actively improving the [website](https://bitcoindevs.xyz/decoding) with new resources and tools. If there's a tool you'd like to see or wish existed and want us to build, lmk

*Find the complete tutorial series of bitcoin technical concepts at https://bitcoindevs.xyz/decoding/roadmap*

---

SegWit (Segregated Witness) addresses use **Bech32** encoding (not the older Base58Check). 

A typical Bech32 address might look like:

`bc1qeaqk7vume5vmrdgx5eyveh5sch4ncg56jdmlkj`

![](https://m.stacker.news/77916)

---

## Decoding a Bech32 Address

Let’s decode this bech32 address to extract version, witness program and other data

![](https://m.stacker.news/77917)

### Step 1: Extract the Version
After the `bc1` prefix, the next character encodes the **witness version**.

### Step 2: Extract the Witness Program
The remaining characters (after the version) form the **witness program**.
![](https://m.stacker.news/77920)

### Step 3: Extract the Checksum
1. The final part of the data includes the **checksum**.
2. The checksum confirms the address has no typos or errors.

### Step 4: Verify the Checksum
A valid checksum means the address is properly formatted.


### Step 5: Convert the witness program (base32) into **binary**.

![](https://m.stacker.news/77922)



### Final Step: Convert Binary to Witness Program**  
Use the binary to derive the **Public Key Hash** (WPKH) or other script data.

![](https://m.stacker.news/77923)

---

## Why Bech32?
- **Lower Fees**: SegWit reduces the size of transactions, lowering fees.
- **Error Detection**: The Bech32 format has built-in error correction.
- **Future Compatibility**: Supports newer SegWit versions.

---
Feel free to share these illustrations and notes to help others understand how to decode and verify a SegWit (Bech32) address!

https://bitcoindevs.xyz/decoding/roadmap

1- How to Sign a Segwit Transaction

we will post the whole series in future posts.
As Satsie said, you can check the whole series at this link for now: https://bitcoindevs.xyz/decoding/transaction-signing

In this tutorial series, we'll break down the process of signing a Bitcoin transaction into 7 detailed posts. We'll work with a real example from [BIP143's test vectors](https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#native-p2wpkh) to explain each step of the signing process.

You can find the complete tutorial series on our website at [bitcoindevs.xyz/decoding/transaction-signing](https://bitcoindevs.xyz/decoding/transaction-signing).


---

The transaction we'll be working with has two inputs, but we'll focus specifically on signing the second input which is a P2WPKH (native SegWit) input.  

The first input is a legacy P2PK input which uses a different signing method that we won't cover now.

![](https://m.stacker.news/75814)




Our goal is to create and sign this transaction:

```text
 Unsigned Raw Transaction:
  ----------------------
  0100000002fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f
  0000000000eeffffffef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57
  b90ec68a0100000000ffffffff02202cb206000000001976a9148280b37df378db99f66f85
  c95a783a76ac7a6d5988ac9093510d000000001976a9143bde42dbee7e4dbe6a21b2d50ce2
  f0167faa815988ac11000000
  
  
  Transaction Breakdown:
  ----------------------
  nVersion:  01000000
  txin:      02 fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f 00000000 00 eeffffff
                ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a 01000000 00 ffffffff
  txout:     02 202cb20600000000 1976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac
                9093510d00000000 1976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac
  nLockTime: 11000000`}
```


Below is the complete transaction data. You can refer back to this whenever you need to check any details during the following steps:

### Inputs
| Input | Type | Previous Tx ID | Output Index | Amount |
|-------|------|---------------|--------------|--------|
| #0 | P2PK | 9f96ade4b41d5433f4eda31e1738ec2b36f6e7d1420d94a6af99801a88f7f7ff | 0 | 6.25 BTC |
| #1 | P2WPKH | 8ac60eb9575db5b2d987e29f301b5b819ea83a5c6579d282d189cc04b8e151ef | 1 | 6 BTC |



### Outputs
| Output | Amount | ScriptPubKey |
|--------|------------------------------|--------------------------------------------|
| #0 | 1.1234 BTC (112,340,000 satoshis) | 1976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac |
| #1 | 2.2345 BTC (223,450,000 satoshis) | 1976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac |


## Steps We'll Follow

1. Create Basic Transaction Structure

2. Add Inputs & Outputs

3. Generate ScriptCode

4. Calculate Transaction Digest

5. Calculate Preimage & Sighash

4. Generate Signature

5. Build Witness Data

6. Assemble Final Transaction

Each step will be explained in detail in the following sections, with code examples and tests using this exact transaction data.

[bitcoindevs.xyz/decoding/transaction-signing](https://bitcoindevs.xyz/decoding/transaction-signing)

❓How Bitcoin Stores/Read Data (Endianness)

why we use little endian? that's your question ?

# Creating a Bitcoin Transaction: A Step-by-Step Guide

Alice wants to pay 5 BTC to Bob for a digital item.  
To make this payment, she needs to create a Bitcoin transaction using the unspent outputs (UTXOs) in her wallet.

![](https://m.stacker.news/74083)

---

### 1. Inputs: Where the Money Comes From
To create a transaction, Alice needs to specify which UTXOs she wants to use as inputs:

![](https://m.stacker.news/74085)

- **UTXO #1**: 4 BTC (from Transaction 1, Output Index 1)
- **UTXO #2**: 2 BTC (from Transaction 2, Output Index 0)

Together, these UTXOs provide enough funds (4 BTC + 2 BTC = 6 BTC) for the payment and any transaction fees.


Each input must include:
1. The Transaction ID
2. The Output Index
3. A placeholder for the Signature (which will be added when Alice signs the transaction)

![](https://m.stacker.news/74086)

---

### 2. Outputs: Where the Money Goes
For this transaction, Alice creates two outputs:
- **5 BTC to Bob** (the payment amount)
- **0.99 BTC back to Alice** (as change, assuming 0.01 BTC transaction fee)

![](https://m.stacker.news/74087)

[Continue reading the full guide on Bitcoin Dev Project ➜](https://bitcoindevs.xyz/decoding/transaction-creation)

---

Learn more about:
- Transaction Fees
- Signing Process
- Change Outputs
- And more...


Creating a Bitcoin Transaction: A Step-by-Step Guide

# Endianness

Endianness refers to the order in which bytes are stored and read in a computer's memory.  

To understand it, imagine reading directions in different languages: while English text flows from left to right, Arabic Hex flows from right to left.

Similarly, computers have two ways to store data:
1. **Big-endian (BE):** Most significant byte first
2. **Little-endian (LE):** Least significant byte first

![](https://m.stacker.news/73969)

---

## 1. Big-Endian

Big-endian stores the **most significant byte** first. This is similar to how humans read numbers and Hex in most cases: starting with the most important information.


Example: Storing the number **12345678** (hexadecimal: `0x00BC614E`) in memory:
- **Big-endian order:** `00 BC 61 4E`
- **Most significant byte** (`00`) is at the lowest memory address.
- **Least significant byte** (`4E`) is at the highest address.

![](https://m.stacker.news/73970)

Big-endian is considered more "human-readable" because the data is stored in the order we naturally read it.

---

## 2. Little-Endian

Little-endian stores the **least significant byte** first. While counterintuitive to humans, it's more efficient for modern processors.

Example: Storing the number **12345678** (`0x00BC614E`) in memory:
- **Little-endian order:** `4E 61 BC 00`
- **Least significant byte** (`4E`) is at the lowest memory address.
- **Most significant byte** (`00`) is at the highest address.

![](https://m.stacker.news/73971)

This "reversal" is common in Bitcoin's internal data representation.

---

## 3. Endianness in Bitcoin

Bitcoin primarily uses **little-endian** for storing data like ...

[-> Continue Reading](https://bitcoindevs.xyz/decoding/endianness)

# Transaction Weight

When sending Bitcoin transactions, we need to pay fees based on how much block space our transaction occupies.  

There are three main ways to measure a transaction's size:

-   **Transaction Size**: The raw byte count of the transaction
-   **Transaction Weight**: A weighted measure that counts witness data differently
-   **Virtual Bytes (vBytes)**: Used for fee calculations (covered in the next topic on fee rates)

## 1- Transaction Size

The most straightforward measurement is the raw byte count of a transaction:

`-> Transaction Size = Bytes of serialized transaction`

For example, here's a raw transaction in hexadecimal:

![](https://m.stacker.news/73812)

This transaction is 225 bytes long - we simply count the number of characters
and divide by 2 (since each byte is represented by 2 hex characters).

## 2- Transaction Weight

With the introduction of SegWit, a new measurement called "transaction weight" was created:

`-> Transaction Weight = (Base Size × 4) + Witness Size`

Where:

-   **Base Size** = Size of transaction data without witness data (signatures)
-   **Witness Size** = Size of witness data (signatures) only

![](https://m.stacker.news/73813)

> 💡 **NOTE**: For legacy (non-SegWit) transactions, all data is considered base size and witness size is zero.

## Why Use Weight? Enter SegWit

check the answer here -> https://bitcoindevs.xyz/decoding/transaction-weight

![](https://m.stacker.news/73814)

Transaction Size vs Weight

Transaction Weight vs Size !

# Understanding Transaction Input Counts 
---

![](https://m.stacker.news/73101)

Visit [decoding bitocoin](https://bitcoindevs.xyz/decoding/inputs-inputcount) to read more about  bitcoin transactions:

- Transaction-structure
- Version
- Marker & Flag
- Prev Txid
- ...

---
# Inputs: Input Count

The number of inputs is stored as a variable-length integer (varint).  
Let's examine this real transaction:

![](https://m.stacker.news/73100)

Breaking this down:

-   `01000000`: Version (4 bytes)
-   `01`: Input count (1 byte, highlighted in the image below)
-   `14e68f...`: First input begins

As shown in the highlighted section of the transaction hex above, this transaction has an input count of 1 (`0x01`).  
This single byte tells us that we should expect exactly one input in this transaction.

The encoding format depends on the value range:

| Decimal Range | Hex Range                         | Bytes used | Format                                    |
| ------------- | --------------------------------- | ---------- | ----------------------------------------- |
| 0 to 252      | 0x00 to 0xfc                      | 1          | uint8_t                                   |
| 253 to 2¹⁶-1  | 0xfd to 0xffff                    | 3          | `0xfd` followed by the number as uint16_t |
| 2¹⁶ to 2³²-1  | 0x10000 to 0xffffffff             | 5          | `0xfe` followed by the number as uint32_t |
| 2³² to 2⁶⁴-1  | 0x100000000 to 0xffffffffffffffff | 9          | `0xff` followed by the number as uint64_t |

For example:

-   The number 100 is encoded directly as `0x64`
-   The number 1000 is encoded as `0xfd 0xe8 0x03`
-   The number 100000 is encoded as `0xfe 0xa0 0x86 0x01 0x00`

> **ℹ️ Note:** In our example transaction, the input count is 1 (`0x01`), so it uses the simplest encoding format of a single byte.

## Implementation

Here's a Python implementation for reading and writing varints:

```pyhon

def read_varint(s):
    '''Reads a variable integer from a stream
    
    The first byte determines the format:
    - If < 0xfd: directly contains the number
    - If 0xfd: next 2 bytes contain number
    - If 0xfe: next 4 bytes contain number 
    - If 0xff: next 8 bytes contain number
    '''
    i = s.read(1)[0]
    if i == 0xfd:
        return int.from_bytes(s.read(2), 'little')
    elif i == 0xfe:
        return int.from_bytes(s.read(4), 'little')
    elif i == 0xff:
        return int.from_bytes(s.read(8), 'little')
    else:
        return i

def encode_varint(i):
'''Encodes an integer as a varint

    - Numbers < 0xfd: 1 byte
    - Numbers < 0x10000: 3 bytes (0xfd + 2 bytes)
    - Numbers < 0x100000000: 5 bytes (0xfe + 4 bytes)
    - Numbers < 0x10000000000000000: 9 bytes (0xff + 8 bytes)
    '''
    if i < 0xfd:
        return bytes([i])
    elif i < 0x10000:
        return b'\\xfd' + i.to_bytes(2, 'little')
    elif i < 0x100000000:
        return b'\\xfe' + i.to_bytes(4, 'little')
    elif i < 0x10000000000000000:
        return b'\\xff' + i.to_bytes(8, 'little')
    else:
        raise ValueError(f'integer too large: {i}')
```

---

Visit [decoding bitocoin](https://bitcoindevs.xyz/decoding/inputs-inputcount) to read more about  bitcoin transactions

Understanding Transaction Input Counts

# Transaction Weight

Upcoming Topics:

- Fee Rate
- Fee Bumping (RBF, CPFP)
- Security Budget Problem.

[Check the list of all topics on decoding-bitcoin →](https://bitcoindevs.xyz/decoding/transaction-weight)

---

When sending Bitcoin transactions, we need to pay fees based on how much block space our transaction occupies. There are three main ways to measure a transaction's size:

- **Transaction Size**: The raw byte count of the transaction
- **Transaction Weight**: A weighted measure that counts witness data differently
- **Virtual Bytes (vBytes)**: Used for fee calculations (covered in the next topic on fee rates)

## 1- Transaction Size

The most straightforward measurement is the raw byte count of a transaction:

`Transaction Size = Bytes of serialized transaction`

For example, here's a raw transaction in hexadecimal:

![](https://m.stacker.news/72923)

This transaction is 225 bytes long - we simply count the number of characters and divide by 2 (since each byte is represented by 2 hex characters).

---

## 2- Transaction Weight

With the introduction of SegWit, a new measurement called "transaction weight" was created:

`Transaction Weight = (Base Size × 4) + Witness Size`

Where:
- **Base Size** = Size of transaction data without witness data (signatures)
- **Witness Size** = Size of witness data (signatures) only

![](https://m.stacker.news/72924)

> 💡 For legacy (non-SegWit) transactions, all data is considered base size and witness size is zero.

---

Read more about fee calculation →]https://bitcoindevs.xyz/decoding/fee-calculation)

Fee calculation in bitcoin

Thanks for the feedback @lightcoin 
You're right, there’s a typo in the last graphic, I’ll update it

I planned to cover fee rates in a separate post to keep this one concise but will add a quick clarification to avoid confusion

# Fee Calculation

#### Upcoming Topics:
- Transaction Fees
- Weight-vsize
- Fee Rate
- Fee Bumping (RBF, CPFP)
- Security Budget Problem. 


[Check the list of all topics on decoding-bitcoin →](https://bitcoindevs.xyz/decoding/transaction-lifecycle)

---

Fees in Bitcoin are calculated as the difference between inputs and outputs amounts.

`Fee = Sum of Inputs - Sum of Outputs`

Let's calculate the fee for the following transaction:

![](https://m.stacker.news/72752)

**Fee = Input - (Output1 + Output2)**
= 299.99430000 - (0.00140000 + 299.99240000)
= 0.00050000 BTC (50,000 sats)

**Remember:** Sum(Inputs) should always be greater than Sum(Outputs)

---

## Why Do We Need Fees?

The purpose of fees is to incentivize miners to include transactions in the block.  
Without fees, miners would have no reason to include transactions in their blocks.

-   But how exactly do miners decide which transactions to include?

---

### How Miners Select Transactions?

Miners receive two types of rewards for securing the network:

1. **Block Reward**
2. **Transaction Fees**

![](https://m.stacker.news/72753)

A miner who mines a block will have revenue as:
`Revenue = Transaction Fees + Block Subsidy`

To maximize their revenue, miners prioritize transactions that pay higher fees. The way they determine which transactions pay more will be covered in the next topic when we discuss fee rates.

For now, understand that:

-   Transactions paying **higher fees** get priority for inclusion (fast confirmation)
-   Transactions paying **lower fees** may wait longer in the mempool (or even fail)

![](https://m.stacker.news/72754)

---

### Minimum Relay Fee

While miners can choose which transactions to include based on fees, there's actually a minimum threshold that transactions must meet just to be relayed through the network.

Continue reading https://bitcoindevs.xyz/decoding/fee-calculation


UTXO vs Account Models

here's a good overview on why UTXO scales differently compared to account-based models

https://x.com/MarvinDefi/status/1872746208198049990

![](https://m.stacker.news/71973)

Tracking user balances in decentralized networks relies on two models:

1. **Account Model** (Ethereum): Tracks balances like a bank ledger (simple and intuitive).
2. **UTXO Model** (Bitcoin): Tracks specific unspent outputs from transactions (complex but powerful).

---

### 1. Account Model (Like Your Bank Account)

The account model is similar to a simple bank statement:

**Example:**

-   Alice has 100 ETH.
-   Alice sends 30 ETH to Bob.
-   Result: Alice now has 70 ETH, and Bob has 30 ETH.

| **Pros**                        | **Cons**                            |
| ------------------------------- | ----------------------------------- |
| Simple to understand            | Less private                        |
| Works well with smart contracts | Can be vulnerable to replay attacks |

---

### 2. UTXO Model (Bitcoin's Approach)

The UTXO model is like managing individual bills in your wallet:

**Example:**

Continue reading https://bitcoindevs.xyz/decoding/utxo

Learn step by step how P2PKH script exercution works

***Check the full animation here => https://bitcoindevs.xyz/decoding/p2pkh***

---

![](https://m.stacker.news/71787)

How P2PKH Works ?


# Nonce Reuse Attack

***- If you prefer reading on the website, check 👉 https://bitcoindevs.xyz/decoding/nonce-reuse-attack***

 ---

Nonce is a random, unique value used in the signing process.

In Schnorr signatures, each signature requires a fresh nonce. Reusing the same nonce is a dangerous mistake that allows an attacker to calculate your private key.

Let's start by breaking down the Schnorr signature equation to see how this happens.

![](https://m.stacker.news/69887)

If the nonce **k** remains the same across different transactions, an attacker can isolate the private key **d** by comparing two signatures.

Imagine you want to sign two separate transactions but mistakenly use the same nonce for both. Here's how it plays out:

![](https://m.stacker.news/69888)

$$S1 = k - h(R, P, tx1) \cdot d$$  
$$S2 = k - h(R, P, tx2) \cdot d$$  

Here’s where things go wrong when the nonce is reused!

Since the only variable difference between **S1** and **S2** is the hash of the transactions, an attacker can calculate **k** and subsequently derive your private key **d**. This exposes your Bitcoin funds to theft.


### How to Prevent Nonce Reuse Attacks ?

The solution is straightforward:

Never reuse a nonce!  
Never reuse a nonce!  
Never reuse a nonce!  
Never reuse a nonce!  
Never reuse a nonce!  
Never reuse a nonce!  
Never reuse a nonce!  
Never reuse a nonce!

Always ensure that your cryptographic library generates a unique, random nonce for each signature.

---

### 6. Calculating the Private Key from Reused Nonces

![](https://m.stacker.news/69890)

Check  👉 https://bitcoindevs.xyz/decoding/nonce-reuse-attack for the explanation 