Skip to content

Commit 79209bf

Browse files
jrakibijrakibi
authored
Merge pull request #54 from jrakibi/transaction-weight-topic
add tx wieght topic
2 parents c8446f5 + 4f92892 commit 79209bf

File tree

8 files changed

+409
-2
lines changed

8 files changed

+409
-2
lines changed

‎decoding/fee-calculation.mdx

Lines changed: 158 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,163 @@ layout: TopicBanner
88
order: 6
99
icon: "FaClipboardList"
1010
images: ["/bitcoin-topics/static/images/topics/thumbnails/musig-thumbnail.webp"]
11-
children: ["weight-vsize", "fee-rate", "rbf"]
11+
children: ["transaction-weight", "blocksize-vs-blockweight", "fee-rate", "rbf"]
1212
---
1313

14-
(coming soon)
14+
## Topics:
15+
16+
<div className="grid grid-cols-2 gap-4">
17+
<div>
18+
1. Transaction Fees
19+
2. Weight-vsize
20+
3. Fee Rate
21+
</div>
22+
<div>
23+
4. Fee Bumping (RBF, CPFP)
24+
5. Security Budget Problem
25+
</div>
26+
</div>
27+
28+
---
29+
30+
Fees in Bitcoin are calculated as the difference between inputs and outputs amounts.
31+
32+
<div className="text-center my-4 text-orange-500">
33+
$$\mathbf{Fee = \sum{Inputs} - \sum{Outputs}}$$
34+
</div>
35+
36+
Let's calculate the fee for the following <a href="https://mempool.space/tx/c27c4d2236fce2a7542e024408d7f89b95e50e42a2c3d10be499c3102ccb45ef" target="_blank" rel="noopener noreferrer">transaction</a>:
37+
38+
<div className="dark:hidden w-full rounded-xl overflow-hidden">
39+
<SvgDisplay
40+
src="/bitcoin-topics/static/images/topics/transactions/fees/fees_0_temp.png"
41+
width="100%"
42+
height="auto"
43+
/>
44+
</div>
45+
<div className="hidden dark:block w-full rounded-xl overflow-hidden">
46+
<SvgDisplay
47+
src="/bitcoin-topics/static/images/topics/transactions/fees/fees_0_temp.png"
48+
width="100%"
49+
height="auto"
50+
/>
51+
</div>
52+
53+
54+
**Fee = Input - (Output1 + Output2)**
55+
= 299.99430000 - (0.00140000 + 299.99240000)
56+
= 0.00050000 BTC (50,000 sats)
57+
58+
**Remember:** Sum(Inputs) should always be greater than Sum(Outputs)
59+
60+
---
61+
62+
## Why Do We Need Fees?
63+
64+
The purpose of fees is to incentivize miners to include transactions in the block.
65+
Without fees, miners would have no reason to include transactions in their blocks.
66+
67+
- But how exactly do miners decide which transactions to include ?
68+
69+
---
70+
71+
### How Miners Select Transactions ?
72+
73+
Miners receive two types of rewards for securing the network:
74+
75+
1. **Block Reward**
76+
2. **Transaction Fees**
77+
78+
<div className="dark:hidden w-full rounded-lg">
79+
<SvgDisplay
80+
src="/bitcoin-topics/static/images/topics/transactions/fees/fees_1.svg"
81+
width="100%"
82+
height="auto"
83+
/>
84+
</div>
85+
<div className="hidden dark:block w-full rounded-lg">
86+
<SvgDisplay
87+
src="/bitcoin-topics/static/images/topics/transactions/fees/fees_1.svg"
88+
width="100%"
89+
height="auto"
90+
/>
91+
</div>
92+
93+
A miner who mines a block will have revenue as:
94+
95+
<div className="text-orange-500 text-sm">
96+
$$Revenue = Tx\ Fees + Block\ Subsidy$$
97+
</div>
98+
99+
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.
100+
101+
For now, understand that:
102+
103+
- Transactions paying **higher fees** get priority for inclusion (fast confirmation)
104+
- Transactions paying **lower fees** may wait longer in the mempool (or even fail)
105+
106+
<div className="dark:hidden w-full rounded-lg">
107+
<SvgDisplay
108+
src="/bitcoin-topics/static/images/topics/transactions/fees/fees_2.svg"
109+
width="100%"
110+
height="auto"
111+
/>
112+
</div>
113+
<div className="hidden dark:block w-full rounded-lg">
114+
<SvgDisplay
115+
src="/bitcoin-topics/static/images/topics/transactions/fees/fees_2.svg"
116+
width="100%"
117+
height="auto"
118+
/>
119+
</div>
120+
121+
---
122+
123+
### Minimum Relay Fee
124+
125+
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.
126+
127+
This is called the **minimum relay fee**.
128+
129+
- It's the minimum fee required for nodes to relay and accept a transaction
130+
- Default is typically 1 sat/vbyte (we'll explain this unit sat/vbyte in the next topic)
131+
- Transactions below this threshold will be rejected by nodes
132+
- Helps prevent spam and DoS attacks on the network
133+
134+
<ExpandableAlert title="NOTE" type="info">
135+
💡 Even if you pay the minimum relay fee, your transaction might still take
136+
a long time to confirm if network activity is high. The minimum relay fee is
137+
just the baseline for transaction acceptance.
138+
</ExpandableAlert>
139+
140+
This brings us to an important question: What happens when you submit a transaction with fees that are above the minimum relay fee but still too low for current network conditions?
141+
142+
---
143+
144+
### Fee Adjustment Methods
145+
146+
When network activity increases, transactions with lower fees might get stuck in the mempool. This can happen even if you paid above the minimum relay fee, as miners will prioritize transactions offering higher fees.
147+
148+
Let's say you have a transaction that's been sitting in the mempool for hours because you set the fee too low during a period of high network activity.
149+
150+
<div className="dark:hidden w-full rounded-lg">
151+
<SvgDisplay
152+
src="/bitcoin-topics/static/images/topics/transactions/fees/fees_3.svg"
153+
width="80%"
154+
height="auto"
155+
/>
156+
</div>
157+
<div className="hidden dark:block w-full rounded-lg">
158+
<SvgDisplay
159+
src="/bitcoin-topics/static/images/topics/transactions/fees/fees_3.svg"
160+
width="80%"
161+
height="auto"
162+
/>
163+
</div>
164+
165+
You have two main solutions to "unstick" it:
166+
167+
1. **RBF (Replace-by-Fee)**
168+
2. **CPFP (Child Pays for Parent)**
169+
170+
We will cover both these fee adjustment methods in detail in upcoming sections.

‎decoding/transaction-weight.mdx

Lines changed: 87 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,87 @@
1+
---
2+
title: "Transaction Weight"
3+
date: 2024-01-25T15:32:14Z
4+
lastmod: "2024-07-26"
5+
draft: false
6+
category: Transactions
7+
layout: TopicBanner
8+
order: 6
9+
icon: "FaClipboardList"
10+
images: ["/bitcoin-topics/static/images/topics/thumbnails/musig-thumbnail.webp"]
11+
parent: "fee-calculation"
12+
---
13+
14+
When sending Bitcoin transactions, we need to pay fees. But how does the network determine how much we should pay?
15+
16+
It all comes down to space - specifically, how much space our transaction takes up in a block.
17+
18+
## Transaction Size (Legacy)
19+
20+
Originally, measuring transaction size was straightforward:
21+
22+
<div className="text-center my-4 text-orange-500">
23+
$$\mathbf{Transaction\ Size = Bytes\ of\ serialized\ transaction}$$
24+
</div>
25+
26+
This simple measurement worked because:
27+
- Each transaction was just a series of bytes
28+
- Fees were calculated based on these bytes
29+
30+
31+
32+
## Enter SegWit Transactions
33+
34+
The legacy system was simple, but it had a problem: transaction signatures.
35+
36+
Every Bitcoin transaction needs signatures to prove ownership, similar to signing a check. These signatures:
37+
- Take up a lot of space (often 65% of the transaction)
38+
- Were part of the main transaction data
39+
- Could be slightly modified without invalidating them (transaction malleability)
40+
41+
This is where SegWit (Segregated Witness) comes in. "Segregated" means separated, and "Witness" refers to the signature.
42+
43+
So SegWit simply means:
44+
"Let's store the signatures separately from the main transaction data!"
45+
46+
47+
48+
<div className="dark:hidden w-full rounded-lg">
49+
<SvgDisplay
50+
src="/bitcoin-topics/static/images/topics/transactions/fees/fees_5.svg"
51+
width="100%"
52+
height="auto"
53+
/>
54+
</div>
55+
<div className="hidden dark:block w-full rounded-lg">
56+
<SvgDisplay
57+
src="/bitcoin-topics/static/images/topics/transactions/fees/fees_5.svg"
58+
width="100%"
59+
height="auto"
60+
/>
61+
</div>
62+
63+
SegWit splits each transaction into two parts:
64+
- **Base data**: The essential information (addresses, amounts) - the "what"
65+
- **Witness data**: The signatures - the "proof"
66+
67+
68+
#### Transaction Weight
69+
70+
But splitting the data created a new challenge: how do we measure transaction size now?
71+
The solution was a new measurement called "transaction weight", calculated as:
72+
73+
<div className="text-center my-4 text-orange-500">
74+
$$\mathbf{Transaction\ Weight = (Base\ Size × 4) + Witness\ Size}$$
75+
</div>
76+
77+
For example, if you have a transaction with base data of 200 bytes and witness data of 100 bytes, the weight would be: (200 × 4) + 100 = 900 weight units
78+
79+
This formula means:
80+
- Base data counts heavily (4× weight)
81+
- Witness data counts lightly (1× weight)
82+
83+
<ExpandableAlert title="NOTE" type="info">
84+
💡 For legacy (non-SegWit) transactions, the entire transaction is considered base data,
85+
so weight = size × 4
86+
</ExpandableAlert>
87+

‎static/images/topics/transactions/fees/fees_0_temp.png

93.6 KB
Loading

0 commit comments

Comments
 (0)