Merge pull request #51 from jrakibi/utxo-account-model-update

jrakibi · web-flow · commit 904e29a250bf · 2025-01-08T18:49:08.000+05:30
add taproot module and update utxo topic
diff --git a/decoding/inputs.mdx b/decoding/inputs.mdx
@@ -11,4 +11,13 @@ images: ["/bitcoin-topics/static/images/topics/thumbnails/musig-thumbnail.webp"]
 parent: "transaction-structure"
 ---
 
-(coming soon)
+<TransactionCreation
+    enabledFields={[
+        "input_count",
+        "txid",
+        "vout",
+        "scriptsig_size",
+        "scriptsig",
+        "sequence"
+    ]}
+/>
diff --git a/decoding/introduction-taproot.mdx b/decoding/introduction-taproot.mdx
@@ -0,0 +1,13 @@
+---
+title: "Introduction to Taproot"
+date: 2024-01-25T15:32:14Z
+lastmod: "2024-07-26"
+draft: false
+category: Taproot
+layout: TopicBanner
+order: 7
+icon: "FaHashtag"
+images: ["/bitcoin-topics/static/images/topics/thumbnails/musig-thumbnail.webp"]
+---
+
+(coming soon)
diff --git a/decoding/marker-flag.mdx b/decoding/marker-flag.mdx
@@ -16,14 +16,13 @@ parent: "transaction-structure"
 
 <TransactionCreation enabledFields={["marker", "flag"]} />
 
-The marker and flag are optional fields introduced with **SegWit**.
+The marker and flag are **optional** fields introduced with **SegWit**.
 
-They indicate that a transaction uses the segregated witness structure defined in **BIP144**.  
-Witness data is required for inputs locked by **P2WPKH**, **P2WSH**, or **P2TR**.
+They indicate that a transaction uses the segregated witness structure defined in **BIP144** (Witness data is required for inputs locked by **P2WPKH**, **P2WSH**, or **P2TR**).
 
 ## Marker
 
-Marker indicates that the transaction uses the extended format.
+Marker indicates that the transaction uses the SegWit transaction format (also known as the extended format).
 
 -   Marker is **1 byte**.
 -   Must always be `0x00` to signal a SegWit transaction.
@@ -46,9 +45,4 @@ Marker indicates that the transaction uses the extended format.
 
 How do old nodes treat marker and flag for SegWit transactions?
 
-<a
-    href="https://chat.bitcoinsearch.xyz/?author=holocat&question=How%2520do%2520old%2520nodes%2520treat%2520marker%2520and%2520flag%2520for%2520SegWit%2520transactions%253F"
-    target="_blank"
->
-    Answer here
-</a>
+-> <a href="https://chat.bitcoinsearch.xyz/?author=holocat&question=How%2520do%2520old%2520nodes%2520treat%2520marker%2520and%2520flag%2520for%2520SegWit%2520transactions%253F" target="_blank" rel="noopener noreferrer">Answer here</a>
diff --git a/decoding/musig.mdx b/decoding/musig.mdx
@@ -3,12 +3,11 @@ title: "MuSig"
 date: 2024-01-25T15:32:14Z
 lastmod: "2024-07-26"
 draft: false
-category: Scripts
+category: Taproot
 layout: TopicBanner
-order: 7
-icon: "FaUsers"
+order: 5
+icon: "FaHashtag"
 images: ["/bitcoin-topics/static/images/topics/thumbnails/musig-thumbnail.webp"]
-parent: taproot
 ---
 
 By the end of this article, we want Alice, Bob, and Carol to sign a transaction using MuSig.
diff --git a/decoding/nonce-reuse-attack.mdx b/decoding/nonce-reuse-attack.mdx
@@ -3,14 +3,14 @@ title: "Nonce Reuse Attack"
 date: 2024-01-25T15:32:14Z
 lastmod: "2024-07-26"
 draft: false
-category: Scripts
+category: Taproot
 layout: TopicBanner
-order: 3
+order: 4
+icon: "FaHashtag"
 images:
     [
         "/bitcoin-topics/static/images/topics/thumbnails/nonce-reuse-attack-thumbnail.webp"
     ]
-parent: taproot
 ---
 
 ### What is a Nonce in Digital Signatures?
diff --git a/decoding/schnorr-signature.mdx b/decoding/schnorr-signature.mdx
@@ -3,11 +3,10 @@ title: "Schnorr Signature"
 date: 2024-01-25T15:32:14Z
 lastmod: "2024-07-26"
 draft: false
-category: Scripts
+category: Taproot
 layout: TopicBanner
-order: 2
-icon: "FaUsers"
-parent: taproot
+order: 3
+icon: "FaHashtag"
 images:
     [
         "/bitcoin-topics/static/images/topics/thumbnails/schnorr-signature-thumbnail.png"
diff --git a/decoding/tagged-hashes.mdx b/decoding/tagged-hashes.mdx
@@ -3,15 +3,14 @@ title: "Tagged Hashes"
 date: 2024-01-25T15:32:14Z
 lastmod: "2024-07-26"
 draft: false
-category: Scripts
+category: Taproot
 layout: TopicBanner
-order: 1
-icon: "FaUsers"
+order: 2
+icon: "FaHashtag"
 images:
     [
         "/bitcoin-topics/static/images/topics/thumbnails/tagged-hashes-thumbnail.jpg"
     ]
-parent: taproot
 ---
 
 Tagged hashes are used throughout the Taproot/Schnorr specification.
diff --git a/decoding/taproot-roadmap.mdx b/decoding/taproot-roadmap.mdx
@@ -0,0 +1,31 @@
+---
+title: "Taproot Roadmap"
+date: 2024-01-25T15:32:14Z
+lastmod: "2024-07-26"
+draft: false
+category: Taproot
+layout: TopicBanner
+order: 1
+icon: "FaHashtag"
+images:
+    [
+        "/bitcoin-topics/static/images/topics/thumbnails/taproot-roadmap-thumbnail.webp"
+    ]
+---
+
+<div className="full-width">
+    <div className="w-full">
+        <div className="dark:hidden w-full rounded-lg">
+            <SvgDisplay
+                src="/bitcoin-topics/static/images/topics/taproot/taproot-roadmap.svg"
+                height="auto"
+            />
+        </div>
+        <div className="hidden dark:block w-full rounded-lg">
+            <SvgDisplay
+                src="/bitcoin-topics/static/images/topics/taproot/taproot-roadmap.svg"
+                height="auto"
+            />
+        </div>
+    </div>
+</div>
diff --git a/decoding/taproot.mdx b/decoding/taproot.mdx
diff --git a/decoding/transaction-structure.mdx b/decoding/transaction-structure.mdx
@@ -40,6 +40,11 @@ To get the raw transaction data, run:
 
 The output will be the serialized transaction format (A long hexadecimal string representing all transaction data).
 
+<CodeSnippet
+    code="010000000114e68f759adcfe66c6aa77d38dc0816cbecf3e9e12d76794f3f9e34c9b1a6e5e000000006b483045022100b18dd5124cf2fcd31af3747a55ed941867f781c340007d9d86dae9e04fa8933f02200bdf817b2e6122ba97b8de40541728ead3988df7462241d6ce70e0f6788e126c012102cd3dfbe89ebca9ee2cfeb5d36234c7d33bce1c329f8a0a318271a48fb9d259d2ffffffff0132aa3200000000002251205805e61a8cc830846e039fa137e791c65b489c9083d14d05a26caebb10d9bf7600000000"
+    language="text"
+    showLineNumbers={false}
+/>
 <ExpandableAlert title="What is Serialization?" type="info" expandable={false}>
     Serialization is the process of converting structured data into a compact
     format (in this case, a hex string) that can be easily stored and
diff --git a/decoding/utxo.mdx b/decoding/utxo.mdx
@@ -28,56 +28,58 @@ images:
     />
 </div>
 
-Tracking user balances in decentralized blockchains like Bitcoin and Ethereum relies on two models:
+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.
 
 ---
 
-### How Transactions Work ?
+### 1. Account Model (Like Your Bank Account)
 
-Every blockchain transaction includes:
+Think of this like a simple bank statement:
 
--   **Amount**: Value transferred.
--   **Payer & Payee**: Sender and recipient.
--   **Authorization**: Digital signature ensuring security.
+**Example:**
 
-Transactions update balances by changing the system’s state.  
-**Example**: Alice sends Bob 5 BTC, decreasing her balance by 5 BTC and increasing Bob's by 5 BTC.
+-   Alice has 100 ETH
+-   Alice sends 30 ETH to Bob
+-   Result: Alice now has 70 ETH, Bob has 30 ETH
 
-## 1- Account Model (Simple and Familiar)
+| **Pros**                        | **Cons**                            |
+| ------------------------------- | ----------------------------------- |
+| Simple to understand            | Less private                        |
+| Works well with smart contracts | Can be vulnerable to replay attacks |
 
-The account model is like a bank ledger, recording total balances without detailing individual inputs or outputs.
+### 2. UTXO Model (Bitcoin's Approach)
 
-**Example**:  
-Alice: 60 ETH → Bob sends 5 ETH → Alice: 65 ETH, Bob: 15 ETH.
+Think of UTXOs like individual bills in your wallet:
 
-| **Pros**                     | **Cons**                     |
-| ---------------------------- | ---------------------------- |
-| Easy to understand           | Vulnerable to replay attacks |
-| Flexible for smart contracts | Limited privacy              |
+**Example:**
+Bob has three "bills" (UTXOs):
 
-|
+-   One 5 BTC UTXO
+-   One 3 BTC UTXO
+-   One 2 BTC UTXO
 
-## 2- UTXO Model (Detailed and Secure)
+To spend 7 BTC, Bob must:
 
-The UTXO model tracks specific outputs from past transactions.
+1. Use the 5 BTC UTXO
+2. Use the 3 BTC UTXO
+3. Get 1 BTC back as "change" (new UTXO)
 
-**Example**:
+Key Points:
 
--   Bob receives UTXOs worth 2 BTC, 3 BTC, and 5 BTC.
--   Spending 6 BTC uses the 5 BTC UTXO and part of the 3 BTC UTXO, creating a new "change" UTXO.
+-   UTXOs can only be spent once (like using a paper bill)
+-   Each transaction creates new UTXOs
+-   Your balance is the sum of all your unspent UTXOs
 
-| **Pros**                            | **Cons**                             |
-| ----------------------------------- | ------------------------------------ |
-| High privacy (new addresses per tx) | More complex and less intuitive      |
-| Prevents double-spending            | Harder to design for state-heavy use |
-|                                     | Requires management of UTXOs         |
+| **Pros**                        | **Cons**                        |
+| ------------------------------- | ------------------------------- |
+| Better privacy                  | More complex to understand      |
+| Prevents double-spending        | Harder for complex applications |
+| Parallel transaction processing | Requires UTXO management        |
 
-|
-
-## Comparing Models
+## 3. Comparing Models
 
 | **Feature**     | **Account Model**            | **UTXO Model**                          |
 | --------------- | ---------------------------- | --------------------------------------- |
diff --git a/decoding/version.mdx b/decoding/version.mdx
@@ -18,8 +18,6 @@ Just like software updates labeled as v1.0, v2.0, v3.0, Bitcoin transactions use
 
 <TransactionCreation enabledFields={["version"]} />
 
-Bitcoin transaction versions and their features:
-
 1. **Version 1:** The original transaction format that follows basic Bitcoin transaction rules.
 
 2. **Version 2:** Introduced in BIP68, BIP112, and BIP113, enabling:
diff --git a/decoding/welcome.mdx b/decoding/welcome.mdx
@@ -28,30 +28,38 @@ Explore the core modules of Decoding Bitcoin:
 <QuickLinks>
 
 <QuickLink
-    title="Scripts"
+    title="1. Transactions"
+    icon="transaction"
+    href="/decoding/roadmap"
+    description="Delve into the mechanics of bitcoin transactions, from creation to confirmation on the blockchain."
+></QuickLink>
+
+<QuickLink
+    title="2. Scripts"
     icon="scripts"
     href="/decoding/overview"
     description="Explore bitcoin scripts, their structure, and how they define the conditions for transactions."
 ></QuickLink>
 
 <QuickLink
-    title="Keys, Addresses"
+    title="3. Taproot"
+    icon="transaction"
+    href="/decoding/taproot-roadmap"
+    description="Understand Bitcoin's Taproot upgrade, including Schnorr signatures and MAST."
+></QuickLink>
+
+<QuickLink
+    title="4. Keys, Addresses"
     icon="keys"
     description="Learn about bitcoin keys and addresses, their creation, and their role in securing transactions."
 ></QuickLink>
 
 <QuickLink
-    title="Wallets"
+    title="5. Wallets"
     icon="wallets"
     description="Understand the different types of bitcoin wallets, how they work, and best practices for their use."
 ></QuickLink>
 
-<QuickLink
-    title="Transaction"
-    icon="transaction"
-    description="Delve into the mechanics of bitcoin transactions, from creation to confirmation on the blockchain."
-></QuickLink>
-
 </QuickLinks>
 
 Join our community on Discord to ask questions, get help, and connect with other learners.
diff --git a/static/images/topics/taproot/taproot-roadmap-light.svg b/static/images/topics/taproot/taproot-roadmap-light.svg
diff --git a/static/images/topics/taproot/taproot-roadmap.svg b/static/images/topics/taproot/taproot-roadmap.svg
