update metadata
· 1 year ago
99f4705452882fb1a7e59cc61a7cbec0c7a56d8a
Parent:
35cc60a24
1 file changed +549 −64
- bitcoin-whitepaper.html +549 −64
Diff
--- a/bitcoin-whitepaper.html +++ b/bitcoin-whitepaper.html @@ -3,17 +3,18 @@ <head> <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> - <title>Bitcoin Whitepaper Explained: Technical Blueprint & Evolution</title> <!-- Title Updated --> + <title>Bitcoin Whitepaper Explained: Technical Blueprint & Evolution</title> <meta name="description" - content="A technically enhanced blueprint guide to Satoshi Nakamoto's Bitcoin whitepaper, including protocol evolution (SegWit, Taproot), consensus changes, and modern context." <!-- Description Updated --> + content="A technically enhanced blueprint guide to Satoshi Nakamoto's Bitcoin whitepaper. Includes core concepts, data structures, consensus formulas, algorithm details, protocol evolution (SegWit, Taproot), and modern context relevant for implementation." /> + <!-- CORRECTED Canonical URL --> <link rel="canonical" - href="YOUR_URL_HERE/bitcoin-whitepaper-blueprint-evolution.html" <!-- ** IMPORTANT: Replace with actual URL if hosted ** --> + href="https://cheatsheets.davidveksler.com/bitcoin-whitepaper.html" /> - <!-- Social Media Metadata (Update if needed) --> + <!-- Social Media Metadata (Updated URL) --> <meta property="og:title" content="Bitcoin Whitepaper Explained: Technical Blueprint & Evolution" @@ -25,9 +26,24 @@ <meta property="og:type" content="article" /> <meta property="og:url" - content="YOUR_URL_HERE/bitcoin-whitepaper-blueprint-evolution.html" <!-- ** IMPORTANT: Replace with actual URL if hosted ** --> + content="https://cheatsheets.davidveksler.com/bitcoin-whitepaper.html" /> - <!-- Add OG image URL if you have one --> + <!-- Optional: Add OG image URL --> + <!-- <meta property="og:image" content="YOUR_IMAGE_URL_HERE/bitcoin-whitepaper-og.png" /> --> + <!-- <meta property="og:image:alt" content="Diagram illustrating Bitcoin whitepaper concepts." /> --> + <meta name="twitter:card" content="summary" /> <!-- Changed to summary if no large image --> + <meta + name="twitter:title" + content="Bitcoin Whitepaper Explained: Technical Blueprint & Evolution" + /> + <meta + name="twitter:description" + content="A technically enhanced guide to the Bitcoin whitepaper." + /> + <!-- Optional: Add Twitter image URL --> + <!-- <meta name="twitter:image" content="YOUR_IMAGE_URL_HERE/bitcoin-whitepaper-og.png" /> --> + <!-- <meta name="twitter:image:alt" content="Diagram illustrating Bitcoin whitepaper concepts." /> --> + <link href="https://cdn.jsdelivr.net/npm/[email protected]/dist/css/bootstrap.min.css" @@ -45,7 +61,7 @@ /> <style> - /* --- CSS Styles: Blueprint Theme (Same as previous example) --- */ + /* --- CSS Styles: Blueprint Theme (Final Version) --- */ @keyframes subtlePulse { 0% { transform: scale(1); box-shadow: 0 2px 5px rgba(0,0,0,0.2); } 50% { transform: scale(1.01); box-shadow: 0 4px 10px rgba(0,0,0,0.3); } 100% { transform: scale(1); box-shadow: 0 2px 5px rgba(0,0,0,0.2); } } :root { --bp-bg-main: #0F172A; --bp-bg-container: #1E293B; --bp-bg-card: #334155; --bp-bg-card-content: #475569; @@ -58,10 +74,7 @@ --rule-border-color: var(--bp-rule-border-color); --rule-bg-color: var(--bp-rule-bg-color); --btc-orange: var(--bp-critical-color); --cat-color-intro: var(--bp-highlight); --cat-color-problem: var(--bp-critical-color); --cat-color-solution: var(--bp-accent-primary); --cat-color-mechanism: var(--bp-accent-primary-dark); --cat-color-technical: #A5B4FC; --cat-color-security: #F472B6; --cat-color-summary: #94A3B8; - --cat-color-resources: var(--bp-accent-primary); - /* New Category Color for Evolution */ - --cat-color-evolution: #34D399; /* Emerald/Green */ - + --cat-color-resources: var(--bp-accent-primary); --cat-color-evolution: #34D399; /* Emerald/Green */ --category-color: var(--cat-color-summary); color-scheme: dark; } body { background-color: var(--bg-main); background-image: linear-gradient(rgba(96, 165, 250, 0.08) 1px, transparent 1px), linear-gradient(90deg, rgba(96, 165, 250, 0.08) 1px, transparent 1px); background-size: 30px 30px; color: var(--text-primary); font-family: "Inter", sans-serif; padding-bottom: 3rem; font-size: 15px; box-sizing: border-box; line-height: 1.65; } @@ -78,11 +91,11 @@ .section-title { color: var(--category-color); margin: 0 0 1.5rem 0; font-weight: 700; text-transform: uppercase; letter-spacing: 0.1em; font-size: 0.9rem; border-bottom: 1px solid var(--border-color); padding: 0.4rem 0; display: block; position: relative; z-index: 15; font-family: 'Roboto Condensed', sans-serif; text-shadow: none; } .section-title .bi { margin-right: 0.5em; font-size: 1.1em; vertical-align: -0.1em;} .cat-intro > .section-title { --category-color: var(--cat-color-intro); } .cat-problem > .section-title { --category-color: var(--cat-color-problem); } .cat-solution > .section-title { --category-color: var(--cat-color-solution); } .cat-mechanism > .section-title { --category-color: var(--cat-color-mechanism); } .cat-technical > .section-title { --category-color: var(--cat-color-technical); } .cat-security > .section-title { --category-color: var(--cat-color-security); } .cat-summary > .section-title { --category-color: var(--cat-color-summary); } .cat-resources > .section-title { --category-color: var(--cat-color-resources); } - .cat-evolution > .section-title { --category-color: var(--cat-color-evolution); } /* Style for new section */ + .cat-evolution > .section-title { --category-color: var(--cat-color-evolution); } .info-card { background-color: var(--bg-card); border: 1px solid var(--bp-border-color); border-radius: 4px; box-shadow: 0 2px 5px rgba(0,0,0,0.2), inset 0 1px 2px rgba(0,0,0,0.1); height: 100%; display: flex; flex-direction: column; transition: border-color 0.3s ease, transform 0.2s ease; position: relative; z-index: 5; overflow: hidden; --category-color: var(--cat-color-summary); } .info-card.wp-type-intro { --category-color: var(--cat-color-intro); border-left: 3px solid var(--category-color); } .info-card.wp-type-problem { --category-color: var(--cat-color-problem); border-left: 3px solid var(--category-color); } .info-card.wp-type-solution { --category-color: var(--cat-color-solution); border-left: 3px solid var(--category-color); } .info-card.wp-type-mechanism { --category-color: var(--cat-color-mechanism); border-left: 3px solid var(--category-color); } .info-card.wp-type-technical { --category-color: var(--cat-color-technical); border-left: 3px solid var(--category-color); } .info-card.wp-type-security { --category-color: var(--cat-color-security); border-left: 3px solid var(--category-color); } .info-card.wp-type-summary { --category-color: var(--cat-color-summary); border-left: 3px solid var(--category-color); } .info-card.wp-type-resource { --category-color: var(--cat-color-resources); border-left: 3px solid var(--category-color); } - .info-card.wp-type-evolution { --category-color: var(--cat-color-evolution); border-left: 3px solid var(--category-color); } /* Style for new section cards */ + .info-card.wp-type-evolution { --category-color: var(--cat-color-evolution); border-left: 3px solid var(--category-color); } .info-card:hover { border-color: var(--category-color); transform: translateY(-2px); box-shadow: 0 4px 10px rgba(0,0,0,0.3), inset 0 1px 2px rgba(0,0,0,0.1); } .info-card .card-body { padding: 0; flex-grow: 1; display: flex; flex-direction: column; } @@ -97,6 +110,7 @@ .collapse-content li::before { content: '-'; display: block; position: absolute; left: 0.3em; top: 0.1em; font-weight: bold; color: var(--bp-accent-primary); font-size: 1.2em; } .collapse-content code { font-size: 0.8rem; color: var(--bp-highlight); background-color: var(--bp-bg-main); padding: 0.2em 0.4em; border-radius: 3px; font-family: "Fira Code", monospace; border: 1px solid var(--bp-border-color); } .collapse-content pre { display: block; padding: 0.8em; margin: 0.8em 0; background-color: var(--bp-bg-main); border: 1px solid var(--bp-border-color); border-radius: 3px; overflow-x: auto; line-height: 1.5; font-size: 0.8rem;} + .collapse-content pre code { padding: 0; border: none; background: none; font-size: inherit; } /* Reset code style within pre */ .collapse-content dl dt { font-weight: 700; margin-top: 0.6em; color: var(--bp-text-heading); font-family: 'Roboto Condensed', sans-serif; } .collapse-content dl dd { margin-left: 1.2em; margin-bottom: 0.4em; color: var(--bp-text-secondary); } .row > * { margin-bottom: 1.8rem; } @@ -116,6 +130,25 @@ .collapse-content a { color: var(--bp-accent-primary); } .collapse-content a:hover { color: var(--bp-text-heading); } .row + .row { border-top: 1px dashed var(--bp-border-color); margin-top: 1.8rem; padding-top: 1.8rem; } .abstract-text { font-style: normal; color: var(--bp-text-secondary); border-left: 2px solid var(--bp-highlight); padding-left: 1rem; margin: 1rem 0; font-size: 0.9rem; } + + /* Improved formula display */ + .formula { + font-family: "Fira Code", monospace; + color: var(--bp-text-primary); + background-color: color-mix(in srgb, var(--bp-bg-main) 80%, black); + padding: 1em; + border-radius: 4px; + border: 1px solid var(--bp-border-color); + overflow-x: auto; + line-height: 1.6; + font-size: 0.85rem; + margin: 1em 0; + } + .formula .comment { color: var(--bp-text-secondary); font-style: italic;} + .formula .var { color: var(--bp-highlight); } /* Highlight variables */ + .formula .op { color: var(--bp-accent-primary); } /* Highlight operators */ + .formula .num { color: #A5B4FC; } /* Number color */ + /* --- End CSS --- */ </style> </head> @@ -134,26 +167,485 @@ <div class="container" id="main-container"> - <!-- SECTION 0: Abstract & Intro (Keep as is) --> - <!-- ... content from previous version ... --> + <!-- ========================== --> + <!-- SECTION 0: Abstract & Intro --> + <!-- ========================== --> + <div class="schema-container cat-intro" data-section-id="section-intro"> + <h2 class="section-title" id="section-intro"> + <i class="bi bi-journal-text"></i> // 0. Introduction & Problem Statement + </h2> + <div class="row"> + <!-- Abstract --> + <div class="col-md-12"> + <div class="info-card wp-type-intro" id="card-abstract"> + <div class="card-body"> + <h5><i class="bi bi-card-text"></i> Abstract: Core Proposal</h5> + <div class="card-content-wrapper"> + <p class="summary abstract-text"> + A purely peer-to-peer electronic cash system is proposed, enabling direct online payments without financial intermediaries. Digital signatures provide ownership, but the double-spending problem is addressed using a P2P network that timestamps transactions into a hash-based Proof-of-Work chain. This chain forms an immutable record, with the longest chain representing the consensus view, secured by majority CPU power. + </p> + </div> + </div> + </div> + </div> + <!-- The Problem --> + <div class="col-lg-6 col-md-12"> + <div class="info-card wp-type-problem" id="card-problem"> + <div class="card-body"> + <h5><i class="bi bi-diagram-2"></i> The Problem: Trust-Based Model Limitations</h5> + <div class="card-content-wrapper"> + <p class="summary"> + Current internet commerce relies on <span class="term">trusted third parties</span>. This model prevents truly non-reversible transactions, adds mediation costs hindering small payments, burdens merchants with trust/fraud concerns, and lacks the finality of physical cash. + </p> + <button + class="btn btn-sm details-toggle" type="button" data-bs-toggle="collapse" data-bs-target="#collapseProblem" aria-expanded="false" aria-controls="collapseProblem"> + Weaknesses <i class="bi bi-chevron-down"></i> + </button> + </div> + </div> + <div class="collapse collapse-content" id="collapseProblem"> + <h6>Trust Model Drawbacks:</h6> + <ul> + <li><strong class="cons">Reversibility & Cost</strong></li> + <li><strong class="cons">Microtransaction Barrier</strong></li> + <li><strong class="cons">Trust Burden</strong></li> + <li><strong class="cons">Lack of Finality</strong></li> + </ul> + </div> + </div> + </div> + <!-- The Goal --> + <div class="col-lg-6 col-md-12"> + <div class="info-card wp-type-solution" id="card-goal"> + <div class="card-body"> + <h5><i class="bi bi-lightbulb"></i> The Solution: Cryptographic Proof System</h5> + <div class="card-content-wrapper"> + <p class="summary"> + The goal is an electronic payment system based on <span class="term">cryptographic proof</span>, not trust. Enabling direct P2P transactions, using computational proof to prevent double-spending and make reversals impractical. + </p> + <button + class="btn btn-sm details-toggle" type="button" data-bs-toggle="collapse" data-bs-target="#collapseGoal" aria-expanded="false" aria-controls="collapseGoal"> + Design Goals <i class="bi bi-chevron-down"></i> + </button> + </div> + </div> + <div class="collapse collapse-content" id="collapseGoal"> + <h6>System Design Goals:</h6> + <ul> + <li><strong class="pros">Peer-to-Peer</strong></li> + <li><strong class="pros">Trustless Operation</strong></li> + <li><strong class="pros">Double-Spending Prevention</strong></li> + <li><strong class="pros">Computational Irreversibility</strong></li> + <li><strong class="pros">Public Transaction Order Proof</strong></li> + <li><strong class="pros">Majority CPU Power Security</strong></li> + </ul> + </div> + </div> + </div> + </div><!-- /.row --> + </div><!-- /.schema-container --> - <!-- SECTION I: Core Technical Components (Keep as is, ensure ECDSA note is present) --> - <!-- ... content from previous version ... --> - <!-- SECTION II: Economic & Consensus Rules (Keep as is) --> - <!-- ... content from previous version ... --> + <!-- ================================================== --> + <!-- SECTION I: Core Technical Components --> + <!-- ================================================== --> + <div class="schema-container cat-mechanism" data-section-id="section-mechanism"> + <h2 class="section-title" id="section-mechanism"> + <i class="bi bi-motherboard"></i> // I. Core Technical Components + </h2> + <div class="row"> + <!-- Transactions --> + <div class="col-lg-6 col-md-12"> + <div class="info-card wp-type-mechanism" id="card-transactions"> + <div class="card-body"> + <h5><i class="bi bi-pen"></i> Spec §2: Transactions (Ownership & Structure)</h5> + <div class="card-content-wrapper"> + <p class="summary"> + Coin = chain of <span class="term">digital signatures</span>. Owner signs hash(prev_TX) + next_owner_pubkey. Payee verifies chain. Uses <span class="term">ECDSA</span> signatures (secp256k1). Basic structure: Inputs (prev_out, scriptSig), Outputs (value, scriptPubKey). Solves ownership, but not <span class="term">double-spending</span>. + </p> + <button + class="btn btn-sm details-toggle" type="button" data-bs-toggle="collapse" data-bs-target="#collapseTransactions" aria-expanded="false" aria-controls="collapseTransactions"> + Details & Algorithms <i class="bi bi-chevron-down"></i> + </button> + </div> + </div> + <div class="collapse collapse-content" id="collapseTransactions"> + <h6>Ownership & Verification:</h6> + <ul> + <li><strong>Signature Algorithm:</strong> <span class="term">ECDSA</span> over <code class="term">secp256k1</code> curve (*Standardized post-whitepaper*).</li> + <li>Signatures prove private key authorization for spending inputs.</li> + </ul> + <h6>Basic Transaction Structure (Conceptual):</h6> + <pre class="formula"><code><span class="comment">// Simplified Transaction Structure</span> +Transaction { + <span class="var">Version</span> <span class="comment">// uint32_t</span> + <span class="var">Inputs</span>[] { <span class="comment">// List of inputs</span> + <span class="var">PrevTxHash</span> <span class="comment">// 32-byte hash</span> + <span class="var">PrevOutputIndex</span> <span class="comment">// uint32_t</span> + <span class="var">ScriptSig</span> <span class="comment">// Variable length unlocking script</span> + } + <span class="var">Outputs</span>[] { <span class="comment">// List of outputs</span> + <span class="var">Value</span> <span class="comment">// uint64_t (Satoshis)</span> + <span class="var">ScriptPubKey</span> <span class="comment">// Variable length locking script</span> + } + <span class="var">Locktime</span> <span class="comment">// uint32_t</span> +}</code></pre> + <h6>Hashing:</h6> + <ul> + <li><strong>TXID:</strong> <code class="term">SHA256(SHA256(serialized_transaction))</code>.</li> + <li><strong>Address Hash (P2PKH):</strong> <code class="term">RIPEMD160(SHA256(PublicKey))</code>.</li> + </ul> + <h6><strong class="critical">Still Needs Double-Spend Prevention</strong></h6> + </div> + </div> + </div> + <!-- Timestamp Server --> + <div class="col-lg-6 col-md-12"> + <div class="info-card wp-type-mechanism" id="card-timestamp"> + <div class="card-body"> + <h5><i class="bi bi-clock"></i> Spec §3: Timestamp Server (Ordering Concept)</h5> + <div class="card-content-wrapper"> + <p class="summary"> + Concept: Distributed server timestamps blocks by hashing them. Each timestamp hash includes the previous timestamp hash, creating a reinforcing chain for chronological ordering. + </p> + </div> + </div> + </div> + </div> + <!-- Proof-of-Work --> + <div class="col-lg-6 col-md-12"> + <div class="info-card wp-type-mechanism" id="card-pow"> + <div class="card-body"> + <h5><i class="bi bi-cpu"></i> Spec §4: Proof-of-Work (Implementation)</h5> + <div class="card-content-wrapper"> + <p class="summary"> + P2P timestamping via <span class="term">PoW</span>. Nodes vary <span class="term">Nonce</span> in block header until hash is below <span class="term">Target</span>: <code class="term">SHA256(SHA256(header)) < Target</code>. Makes chain immutable; longest chain = consensus. + </p> + <button + class="btn btn-sm details-toggle" type="button" data-bs-toggle="collapse" data-bs-target="#collapsePoW" aria-expanded="false" aria-controls="collapsePoW"> + Header & Algorithm <i class="bi bi-chevron-down"></i> + </button> + </div> + </div> + <div class="collapse collapse-content" id="collapsePoW"> + <h6>Proof-of-Work Algorithm:</h6> + <pre class="formula"><code><span class="comment">// Find Nonce such that:</span> +<span class="op">SHA256</span>(<span class="op">SHA256</span>(<span class="var">BlockHeader</span>)) <span class="op"><</span> <span class="var">CurrentTarget</span></code></pre> + <h6>Block Header Structure (Core Fields - Approx 80 bytes):</h6> + <pre class="formula"><code>BlockHeader { + <span class="var">Version</span> <span class="comment">// int32_t</span> + <span class="var">PrevBlockHash</span> <span class="comment">// uint256 (32 bytes)</span> + <span class="var">MerkleRoot</span> <span class="comment">// uint256 (32 bytes)</span> + <span class="var">Timestamp</span> <span class="comment">// uint32_t (Unix epoch)</span> + <span class="var">Bits</span> <span class="comment">// uint32_t (Encoded Target)</span> + <span class="var">Nonce</span> <span class="comment">// uint32_t</span> +}</code></pre> + <h6>Consensus & Immutability:</h6> + <ul> + <li>Finding valid nonce is computationally expensive.</li> + <li>Changing past block requires re-doing PoW for it and all successors.</li> + <li>Longest chain (most cumulative PoW) is the accepted history.</li> + </ul> + </div> + </div> + </div> + <!-- Network --> + <div class="col-lg-6 col-md-12"> + <div class="info-card wp-type-mechanism" id="card-network"> + <div class="card-body"> + <h5><i class="bi bi-diagram-3"></i> Spec §5: Network (Operation Principles)</h5> + <div class="card-content-wrapper"> + <p class="summary"> + Nodes broadcast TXs & blocks. Validate received data. Build on longest valid chain. Minimal structure. <strong class="critical">*Network message protocol implementation-defined.*</strong> + </p> + <button + class="btn btn-sm details-toggle" type="button" data-bs-toggle="collapse" data-bs-target="#collapseNetwork" aria-expanded="false" aria-controls="collapseNetwork"> + Operational Steps <i class="bi bi-chevron-down"></i> + </button> + </div> + </div> + <div class="collapse collapse-content" id="collapseNetwork"> + <h6>Operational Flow Principles:</h6> + <ol> + <li>Broadcast valid TXs.</li> + <li>Collect TXs into blocks.</li> + <li>Find PoW.</li> + <li>Broadcast valid block.</li> + <li>Validate received block & TXs.</li> + <li>Accept valid block & build on it.</li> + </ol> + <h6>Consensus Dynamics:</h6> + <ul><li>Always extend the longest valid chain. Resolve forks via subsequent blocks.</li></ul> + </div> + </div> + </div> + </div><!-- /.row --> + </div><!-- /.schema-container --> - <!-- SECTION III: Optimizations & Usage Patterns (Keep as is, ensure address note is present) --> - <!-- ... content from previous version ... --> - <!-- SECTION IV: Security Calculations (Keep as is) --> - <!-- ... content from previous version ... --> + <!-- ============================== --> + <!-- SECTION II: Economic & Consensus Rules --> + <!-- ============================== --> + <div class="schema-container cat-technical" data-section-id="section-rules"> + <h2 class="section-title" id="section-rules"> + <i class="bi bi-bank"></i> // II. Economic & Consensus Rules + </h2> + <div class="row"> + <!-- Incentive Mechanism --> + <div class="col-lg-6 col-md-12"> + <div class="info-card wp-type-technical" id="card-incentive"> + <div class="card-body"> + <h5><i class="bi bi-award"></i> Spec §6: Incentive Model & Issuance</h5> + <div class="card-content-wrapper"> + <p class="summary"> + Incentives: <span class="term">Block Reward</span> (Coinbase) + <span class="term">Transaction Fees</span>. Initial reward: 50 BTC, halves every 210,000 blocks (~4 yrs). Max supply: ~21 Million BTC. + </p> + <button + class="btn btn-sm details-toggle" type="button" data-bs-toggle="collapse" data-bs-target="#collapseIncentive" aria-expanded="false" aria-controls="collapseIncentive"> + Coinbase Schedule <i class="bi bi-chevron-down"></i> + </button> + </div> + </div> + <div class="collapse collapse-content" id="collapseIncentive"> + <h6>Coin Issuance (Coinbase Reward Schedule):</h6> + <div class="formula"> +<pre><code><span class="var">INITIAL_REWARD</span> <span class="op">=</span> <span class="num">50</span> <span class="op">*</span> <span class="num">100_000_000</span><span class="comment">; // Satoshis (50 BTC)</span> +<span class="var">HALVING_INTERVAL</span> <span class="op">=</span> <span class="num">210_000</span><span class="comment">; // Blocks</span> + +<span class="comment">// Function to calculate reward for a given block height</span> +function calculate_reward(<span class="var">height</span>) { + <span class="var">halvings</span> <span class="op">=</span> <span class="var">height</span> <span class="op">/</span> <span class="var">HALVING_INTERVAL</span><span class="op">;</span> + if (<span class="var">halvings</span> <span class="op">>=</span> <span class="num">64</span>) return <span class="num">0</span><span class="op">;</span> <span class="comment">// Reward becomes 0 after 64 halvings</span> + <span class="var">reward</span> <span class="op">=</span> <span class="var">INITIAL_REWARD</span> <span class="op">>></span> <span class="var">halvings</span><span class="op">;</span> <span class="comment">// Right-shift is equivalent to dividing by 2^halvings</span> + return <span class="var">reward</span><span class="op">;</span> +} + +<span class="comment">// Example Heights:</span> +<span class="comment">// Height 0: Reward = 50 BTC</span> +<span class="comment">// Height 210,000: Reward = 25 BTC</span> +<span class="comment">// Height 420,000: Reward = 12.5 BTC</span> +<span class="comment">// ...</span> +<span class="comment">// Total Supply converges towards 21 Million BTC</span></code></pre> + </div> + <h6>Transaction Fees:</h6> + <ul><li>Fee = `Sum(Input Values) - Sum(Output Values)`</li></ul> + </div> + </div> + </div> + <!-- Difficulty Adjustment --> + <div class="col-lg-6 col-md-12"> + <div class="info-card wp-type-technical" id="card-difficulty"> + <div class="card-body"> + <h5><i class="bi bi-speedometer2"></i> Consensus Rule: Difficulty Adjustment</h5> + <div class="card-content-wrapper"> + <p class="summary"> + PoW <span class="term">Target</span> adjusts every <span class="term">2016 blocks</span> (~2 weeks) aiming for 10 min block time. Uses ratio of actual vs target time for last interval, clamped to 0.25x - 4x change. + </p> + <button + class="btn btn-sm details-toggle" type="button" data-bs-toggle="collapse" data-bs-target="#collapseDifficulty" aria-expanded="false" aria-controls="collapseDifficulty"> + Adjustment Formula <i class="bi bi-chevron-down"></i> + </button> + </div> + </div> + <div class="collapse collapse-content" id="collapseDifficulty"> + <h6>Difficulty Adjustment Logic (Conceptual):</h6> + <div class="formula"> +<pre><code><span class="comment">// Constants</span> +<span class="var">TARGET_TIMESPAN</span> <span class="op">=</span> <span class="num">14</span> <span class="op">*</span> <span class="num">24</span> <span class="op">*</span> <span class="num">60</span> <span class="op">*</span> <span class="num">60</span><span class="op">;</span> <span class="comment">// 2 weeks in seconds</span> +<span class="var">INTERVAL</span> <span class="op">=</span> <span class="num">2016</span><span class="op">;</span> <span class="comment">// Blocks</span> +<span class="var">MIN_ADJUST_FACTOR</span> <span class="op">=</span> <span class="num">0.25</span><span class="op">;</span> +<span class="var">MAX_ADJUST_FACTOR</span> <span class="op">=</span> <span class="num">4.0</span><span class="op">;</span> + +<span class="comment">// At block height H divisible by INTERVAL:</span> +<span class="var">current_block</span> <span class="op">=</span> get_block(<span class="var">H</span> <span class="op">-</span> <span class="num">1</span>)<span class="op">;</span> +<span class="var">first_block</span> <span class="op">=</span> get_block(<span class="var">H</span> <span class="op">-</span> <span class="var">INTERVAL</span>)<span class="op">;</span> + +<span class="var">actual_timespan</span> <span class="op">=</span> <span class="var">current_block.timestamp</span> <span class="op">-</span> <span class="var">first_block.timestamp</span><span class="op">;</span> + +<span class="comment">// Clamp actual_timespan to avoid extreme adjustments</span> +<span class="var">clamped_timespan</span> <span class="op">=</span> <span class="op">max</span>(<span class="var">TARGET_TIMESPAN</span> <span class="op">*</span> <span class="var">MIN_ADJUST_FACTOR</span>, + <span class="op">min</span>(<span class="var">actual_timespan</span>, <span class="var">TARGET_TIMESPAN</span> <span class="op">*</span> <span class="var">MAX_ADJUST_FACTOR</span>))<span class="op">;</span> + +<span class="comment">// Calculate new target</span> +<span class="var">old_target</span> <span class="op">=</span> decode_target_from_bits(<span class="var">current_block.bits</span>)<span class="op">;</span> +<span class="var">new_target</span> <span class="op">=</span> (<span class="var">old_target</span> <span class="op">*</span> <span class="var">clamped_timespan</span>) <span class="op">/</span> <span class="var">TARGET_TIMESPAN</span><span class="op">;</span> + +<span class="comment">// Ensure new_target does not exceed maximum possible target</span> +<span class="var">new_target</span> <span class="op">=</span> <span class="op">min</span>(<span class="var">new_target</span>, <span class="var">MAX_TARGET</span>)<span class="op">;</span> + +<span class="var">new_bits</span> <span class="op">=</span> encode_target_to_bits(<span class="var">new_target</span>)<span class="op">;</span> +<span class="comment">// Use new_bits in the header for the next INTERVAL blocks</span></code></pre> + </div> + <ul><li>Maintains ~10 minute average block time despite hashrate fluctuations.</li></ul> + </div> + </div> + </div> + </div><!-- /.row --> + </div><!-- /.schema-container --> + + + <!-- ================================== --> + <!-- SECTION III: Optimizations & Usage Patterns --> + <!-- ================================== --> + <div class="schema-container cat-technical" data-section-id="section-details"> + <h2 class="section-title" id="section-details-cont"> + <i class="bi bi-rulers"></i> // III. Optimizations & Usage Patterns + </h2> + <div class="row"> + <!-- Reclaiming Disk Space --> + <div class="col-lg-6 col-md-12"> + <div class="info-card wp-type-technical" id="card-diskspace"> + <div class="card-body"> + <h5><i class="bi bi-hdd"></i> Spec §7: Reclaiming Disk Space (Merkle Trees)</h5> + <div class="card-content-wrapper"> + <p class="summary"> + Allows pruning old spent TXs via <span class="term">Merkle Tree</span>. Only <span class="term">Merkle Root</span> in header. Uses <code class="term">SHA256(SHA256(...))</code> tree hashing. Enables SPV and reduces storage. + </p> + <button + class="btn btn-sm details-toggle" type="button" data-bs-toggle="collapse" data-bs-target="#collapseDiskSpace" aria-expanded="false" aria-controls="collapseDiskSpace"> + Details <i class="bi bi-chevron-down"></i> + </button> + </div> + </div> + <div class="collapse collapse-content" id="collapseDiskSpace"> + <h6>Merkle Tree Construction & Pruning:</h6> + <ul> + <li>TXIDs form leaves. Pairs hashed iteratively (<code class="term">SHA256(SHA256(L+R))</code>) to get root.</li> + <li>Root stored in header proves TX inclusion with minimal data (Merkle branch).</li> + <li>Allows full nodes to discard old, fully spent transaction data ("prune").</li> + </ul> + </div> + </div> + </div> + <!-- SPV --> + <div class="col-lg-6 col-md-12"> + <div class="info-card wp-type-technical" id="card-spv"> + <div class="card-body"> + <h5><i class="bi bi-search"></i> Spec §8: Simplified Payment Verification (SPV)</h5> + <div class="card-content-wrapper"> + <p class="summary"> + Verify payments without full node. <span class="term">SPV</span> clients get headers, request <span class="term">Merkle branch</span> to prove TX inclusion. Efficient but less secure (trusts longest chain validity). + </p> + <button + class="btn btn-sm details-toggle" type="button" data-bs-toggle="collapse" data-bs-target="#collapseSPV" aria-expanded="false" aria-controls="collapseSPV"> + Details <i class="bi bi-chevron-down"></i> + </button> + </div> + </div> + <div class="collapse collapse-content" id="collapseSPV"> + <h6>Lightweight Verification Process:</h6> + <ol> + <li>Get longest chain of headers.</li> + <li>Request Merkle proof for specific TXID.</li> + <li>Verify proof against header's Merkle Root.</li> + </ol> + <ul> + <li><strong class="cons">Security Tradeoff:</strong> Vulnerable to 51% attacks providing fake history. Doesn't validate all rules.</li> + </ul> + </div> + </div> + </div> + <!-- Combining Value --> + <div class="col-lg-6 col-md-12"> + <div class="info-card wp-type-technical" id="card-combine"> + <div class="card-body"> + <h5><i class="bi bi-plus-slash-minus"></i> Spec §9: Combining/Splitting Value (UTXOs)</h5> + <div class="card-content-wrapper"> + <p class="summary"> + Transactions use multiple <span class="term">inputs</span> (spending UTXOs) and create multiple <span class="term">outputs</span> (new UTXOs). Efficiently manages value flow like digital cash/change. + </p> + </div> + </div> + </div> + </div> + <!-- Privacy --> + <div class="col-lg-6 col-md-12"> + <div class="info-card wp-type-technical" id="card-privacy"> + <div class="card-body"> + <h5><i class="bi bi-eye-slash"></i> Spec §10: Privacy (Pseudonymity & Address Gen.)</h5> + <div class="card-content-wrapper"> + <p class="summary"> + Privacy via anonymous public keys (<span class="term">pseudonymity</span>). Public sees TXs between addresses. Use new keys per TX. Address (P2PKH): <code class="term">Base58Check(RIPEMD160(SHA256(pubkey)))</code>. + </p> + <button + class="btn btn-sm details-toggle" type="button" data-bs-toggle="collapse" data-bs-target="#collapsePrivacy" aria-expanded="false" aria-controls="collapsePrivacy"> + Address Generation & Limits <i class="bi bi-chevron-down"></i> + </button> + </div> + </div> + <div class="collapse collapse-content" id="collapsePrivacy"> + <h6>Address Generation (Conceptual P2PKH Flow):</h6> + <div class="formula"> +<pre><code><span class="var">PrivateKey</span> <span class="op">--ECDSA(secp256k1)--></span> <span class="var">PublicKey</span> +<span class="var">Hash160</span> <span class="op">=</span> <span class="op">RIPEMD160</span>(<span class="op">SHA256</span>(<span class="var">PublicKey</span>)) +<span class="var">Address</span> <span class="op">=</span> <span class="op">Base58CheckEncode</span>(<span class="var">VersionByte</span> <span class="op">+</span> <span class="var">Hash160</span>)</code></pre> + </div> + <ul> + <li>*Note: SegWit/Taproot use different address formats/derivations.*</li> + </ul> + <h6><strong class="cons">Privacy Limitations:</strong></h6> + <ul><li>Multi-input TXs link ownership. Address reuse harms privacy. External linking (KYC) possible.</li></ul> + </div> + </div> + </div> + </div><!-- /.row --> + </div><!-- /.schema-container --> <!-- ==================================== --> - <!-- SECTION V: Protocol Evolution & Modern Context (NEW SECTION) --> + <!-- SECTION IV: Security Calculations --> <!-- ==================================== --> - <div class="schema-container cat-evolution" data-section-id="section-evolution"> <!-- Added cat-evolution --> + <div class="schema-container cat-security" data-section-id="section-security"> + <h2 class="section-title" id="section-security"> + <i class="bi bi-shield-check"></i> // IV. Security Calculations + </h2> + <div class="row"> + <div class="col-md-12"> + <div class="info-card wp-type-security" id="card-calculations"> + <div class="card-body"> + <h5><i class="bi bi-graph-up"></i> Spec §11: Calculations (Attacker Success Probability)</h5> + <div class="card-content-wrapper"> + <p class="summary"> + Analyzes attacker probability (<span class="term">q</span> = attacker hash power fraction) of reversing a TX from <span class="term">z</span> confirmations behind. Modeled as Gambler's Ruin. Probability drops exponentially with <span class="term">z</span> if <span class="term">p > q</span> (honest majority). + </p> + <button + class="btn btn-sm details-toggle" type="button" data-bs-toggle="collapse" data-bs-target="#collapseCalculations" aria-expanded="false" aria-controls="collapseCalculations"> + Probability Analysis <i class="bi bi-chevron-down"></i> + </button> + </div> + </div> + <div class="collapse collapse-content" id="collapseCalculations"> + <h6>Double-Spend Attack Analysis (Gambler's Ruin):</h6> + <div class="formula"> +<pre><code><span class="var">p</span> <span class="op">=</span> probability honest network finds next block +<span class="var">q</span> <span class="op">=</span> probability attacker finds next block (hash power fraction) +<span class="var">z</span> <span class="op">=</span> number of confirmations attacker is behind + +<span class="comment">// Prob. attacker *ever* catches up from z blocks behind</span> +<span class="var">P_catchup</span> <span class="op">=</span> (<span class="var">q</span> <span class="op">/</span> <span class="var">p</span>)<span class="op">**</span><span class="var">z</span><span class="op">;</span> <span class="comment">// If p > q</span> +<span class="var">P_catchup</span> <span class="op">=</span> <span class="num">1</span><span class="op">;</span> <span class="comment">// If p <= q</span> + +<span class="comment">// Probability attacker succeeds after recipient waits for z blocks</span> +<span class="comment">// Involves Poisson distribution for attacker progress during wait time</span> +<span class="var">lambda</span> <span class="op">=</span> <span class="var">z</span> <span class="op">*</span> (<span class="var">q</span> <span class="op">/</span> <span class="var">p</span>)<span class="op">;</span> <span class="comment">// Expected attacker blocks during wait</span> +<span class="var">P_success</span> <span class="op">=</span> Sum[<span class="var">k</span><span class="op">=</span><span class="num">0</span> to <span class="op">infinity</span>] ( <span class="comment">// Sum over possible attacker progress k</span> + (<span class="op">exp</span>(<span class="op">-</span><span class="var">lambda</span>) <span class="op">*</span> <span class="var">lambda</span><span class="op">**</span><span class="var">k</span> <span class="op">/</span> <span class="var">k</span>!) <span class="op">*</span> <span class="comment">// Poisson probability of k blocks</span> + (<span class="op">min</span>(<span class="num">1</span>, (<span class="var">q</span><span class="op">/</span><span class="var">p</span>)<span class="op">**</span>(<span class="var">z</span><span class="op">-</span><span class="var">k</span>)) ) <span class="comment">// Prob. catching up from remaining deficit</span> + )<span class="op">;</span> <span class="comment">// Simplified - see paper for exact calculation/rearrangement</span> +</code></pre> + </div> + <ul><li>Shows strong probabilistic security increasing with confirmations.</li></ul> + </div> + </div> + </div> + </div><!-- /.row --> + </div><!-- /.schema-container --> + + + <!-- ==================================== --> + <!-- SECTION V: Protocol Evolution & Modern Context --> + <!-- ==================================== --> + <div class="schema-container cat-evolution" data-section-id="section-evolution"> <h2 class="section-title" id="section-evolution"> <i class="bi bi-git"></i> // V. Protocol Evolution & Modern Context </h2> @@ -165,20 +657,20 @@ <h5><i class="bi bi-graph-up-arrow"></i> Major Protocol Upgrades (Soft Forks)</h5> <div class="card-content-wrapper"> <p class="summary"> - Bitcoin evolves via backwards-compatible <span class="term">Soft Forks</span>, adding features without forcing all nodes to upgrade immediately. Key upgrades expanded scripting and efficiency. + Bitcoin evolves via backwards-compatible <span class="term">Soft Forks</span>. Key upgrades: <span class="term">P2SH</span> (BIP 16) for script hashes, <span class="term">SegWit</span> (BIPs 141-144) for efficiency & malleability fix, <span class="term">Taproot</span> (BIPs 340-342) for Schnorr sigs & script improvements. </p> <button class="btn btn-sm details-toggle" type="button" data-bs-toggle="collapse" data-bs-target="#collapseUpgrades" aria-expanded="false" aria-controls="collapseUpgrades"> - Key Soft Forks <i class="bi bi-chevron-down"></i> + Details <i class="bi bi-chevron-down"></i> </button> </div> </div> <div class="collapse collapse-content" id="collapseUpgrades"> - <h6>Significant Soft Forks Since Whitepaper:</h6> + <h6>Significant Soft Forks:</h6> <ul> - <li><strong>P2SH (Pay-to-Script-Hash, BIP 16):</strong> Enabled sending funds to the hash of a script, simplifying complex transactions like multisig by hiding complexity from the sender.</li> - <li><strong>SegWit (Segregated Witness, BIPs 141-144):</strong> Separated signature data ("witness") from transaction data, fixing transaction malleability, increasing effective block space (via block weight), and enabling Layer 2 solutions like Lightning. Introduced new address types (P2WPKH, P2WSH).</li> - <li><strong>Taproot (BIPs 340-342):</strong> Introduced Schnorr signatures (<span class="term">BIP 340</span>) for efficiency and improved privacy, MAST (<span class="term">BIP 114 via Tapscript</span>) for complex scripts appearing as simple keys, and Tapscript (<span class="term">BIP 342</span>) for future script upgrades. Introduced P2TR addresses.</li> + <li><strong>P2SH (2012):</strong> Simplified complex scripts (like multisig).</li> + <li><strong>SegWit (2017):</strong> Increased effective block space (via block weight), fixed malleability, enabled Lightning Network scaling.</li> + <li><strong>Taproot (2021):</strong> Introduced Schnorr signatures (efficiency, privacy potential), MAST (complex scripts look simple), Tapscript (future scripting flexibility).</li> </ul> </div> </div> @@ -190,22 +682,10 @@ <h5><i class="bi bi-check-all"></i> Other Consensus Rule Changes</h5> <div class="card-content-wrapper"> <p class="summary"> - Consensus rules have evolved beyond the whitepaper, notably regarding block capacity and script capabilities (timelocks). + Key consensus rules added/changed: Formalized <span class="term">Block Size Limit</span> (later <span class="term">Block Weight</span> with SegWit), added script <span class="term">Timelocks</span> (CLTV - BIP 65, CSV - BIP 112) enabling payment channels. </p> - <button - class="btn btn-sm details-toggle" type="button" data-bs-toggle="collapse" data-bs-target="#collapseConsensusChanges" aria-expanded="false" aria-controls="collapseConsensusChanges"> - Key Changes <i class="bi bi-chevron-down"></i> - </button> </div> </div> - <div class="collapse collapse-content" id="collapseConsensusChanges"> - <h6>Notable Consensus Rule Evolutions:</h6> - <ul> - <li><strong>Block Size Limit / Block Weight:</strong> An implicit limit existed initially, later formalized at 1MB. SegWit introduced <span class="term">block weight</span> (max 4M weight units), allowing larger blocks if they contain significant witness data, effectively increasing capacity.</li> - <li><strong>Timelocks (CLTV/CSV):</strong> Opcodes like `OP_CHECKLOCKTIMEVERIFY` (<span class="term">BIP 65</span>) and `OP_CHECKSEQUENCEVERIFY` (<span class="term">BIP 112</span>) were added, enabling transactions that can only be spent after a certain time or block height, crucial for payment channels (Lightning).</li> - <li><strong>Signature Algorithm Evolution:</strong> Moved from just ECDSA to include more efficient <span class="term">Schnorr signatures</span> with Taproot.</li> - </ul> - </div> </div> </div> <!-- Change Mechanisms --> @@ -215,7 +695,7 @@ <h5><i class="bi bi-bezier2"></i> Change Mechanisms (BIPs & Forks)</h5> <div class="card-content-wrapper"> <p class="summary"> - Protocol changes are proposed via <span class="term">BIPs</span> (Bitcoin Improvement Proposals) and typically activated via <span class="term">Soft Forks</span> (backwards-compatible). Contentious <span class="term">Hard Forks</span> (non-backwards-compatible) are generally avoided by the Bitcoin community. + Changes proposed via <span class="term">BIPs</span>, activated via <span class="term">Soft Forks</span> (backwards-compatible, opt-in for new rules). <span class="term">Hard Forks</span> (non-backwards-compatible) generally require near-universal consensus and are rare/contentious. </p> </div> </div> @@ -228,7 +708,7 @@ <h5><i class="bi bi-lightning-charge-fill"></i> Layer 2 Scaling (Lightning Network)</h5> <div class="card-content-wrapper"> <p class="summary"> - To handle transaction volume beyond the base layer capacity, <span class="term">Layer 2</span> solutions like the <span class="term">Lightning Network</span> have emerged. Built *on top* of Bitcoin, they enable near-instant, low-fee payments via off-chain channels, settling final balances on the main chain. + <span class="term">Lightning Network</span> built on Bitcoin enables fast, cheap, off-chain payments via channels, settling net results on-chain. Addresses base layer transaction throughput limitations. Enabled largely by SegWit and Timelocks. </p> </div> </div> @@ -241,7 +721,7 @@ <h5><i class="bi bi-memory"></i> Mining Hardware Evolution</h5> <div class="card-content-wrapper"> <p class="summary"> - Mining hardware rapidly specialized beyond the whitepaper's "CPU" assumption: CPU -> GPU -> FPGA -> <span class="term">ASIC</span> (Application-Specific Integrated Circuit). ASICs dominate mining today, significantly increasing network hashrate but also raising barriers to entry. + Mining evolved: CPU -> GPU -> FPGA -> <span class="term">ASIC</span>. ASICs dominate, massively increasing network hashrate and security cost, but centralizing hardware production and raising entry barriers. </p> </div> </div> @@ -254,7 +734,7 @@ <h5><i class="bi bi-person-bounding-box"></i> Privacy Context: Pseudonymity Reality</h5> <div class="card-content-wrapper"> <p class="summary"> - While keys are anonymous, linking addresses via multi-input TXs, address reuse, and external data (KYC) limits privacy. <span class="term">Chain analysis</span> techniques track fund flows. Bitcoin provides <span class="term">pseudonymity</span>, not guaranteed anonymity. Techniques like CoinJoin exist but aren't protocol-native. + Bitcoin offers <span class="term">pseudonymity</span>, not anonymity. Address reuse, multi-input linking, and external data (KYC) allow <span class="term">chain analysis</span>. Advanced techniques (CoinJoin, Taproot benefits) aim to improve privacy but are not foolproof. </p> </div> </div> @@ -265,34 +745,34 @@ <!-- ======================= --> - <!-- SECTION VI: Conclusion, Gaps & Resources (Updated Section Number) --> + <!-- SECTION VI: Conclusion, Gaps & Resources --> <!-- ======================= --> - <div class="schema-container cat-summary" data-section-id="section-conclusion"> <!-- Section Number Updated --> + <div class="schema-container cat-summary" data-section-id="section-conclusion"> <h2 class="section-title" id="section-conclusion"> <i class="bi bi-check2-square"></i> // VI. Conclusion, Implementation Gaps & Resources </h2> <div class="row"> - <!-- Conclusion (Keep as is) --> + <!-- Conclusion --> <div class="col-lg-6 col-md-12"> <div class="info-card wp-type-summary" id="card-conclusion"> <div class="card-body"> <h5><i class="bi bi-flag"></i> Spec §12: Conclusion</h5> <div class="card-content-wrapper"> <p class="summary"> - Satoshi proposed a trustless P2P electronic cash system using digital signatures for ownership and PoW consensus via the longest chain to prevent double-spending. Relies on simple rules, node honesty (incentivized), and majority CPU power. + Satoshi proposed a trustless P2P electronic cash system using digital signatures and PoW consensus (longest chain) to prevent double-spending. Relies on simple rules, incentives, and majority CPU power. </p> </div> </div> </div> </div> - <!-- Implementation Gaps (Keep as is) --> + <!-- Implementation Gaps --> <div class="col-lg-6 col-md-12"> <div class="info-card wp-type-problem" id="card-gaps"> <div class="card-body"> <h5><i class="bi bi-puzzle"></i> Implementation Gaps in Whitepaper</h5> <div class="card-content-wrapper"> <p class="summary"> - Whitepaper provides concepts. <strong class="critical">Implementation requires details NOT specified:</strong> P2P protocol, Script details, Full Consensus Rules (block weight, etc.), Serialization, Fork Activation. + Whitepaper provides concepts. <strong class="critical">Implementation requires details NOT specified:</strong> P2P protocol, Script opcodes/limits, Full Consensus Rules (block weight, etc.), Serialization, Fork Activation mechanisms. </p> <button class="btn btn-sm details-toggle" type="button" data-bs-toggle="collapse" data-bs-target="#collapseGaps" aria-expanded="false" aria-controls="collapseGaps"> @@ -303,17 +783,17 @@ <div class="collapse collapse-content" id="collapseGaps"> <h6>Areas Requiring External Specification / Implementation Choices:</h6> <ul> - <li><strong class="cons">P2P Network Protocol</strong></li> + <li><strong class="cons">P2P Network Protocol & Messages</strong></li> <li><strong class="cons">Scripting System Details & Opcodes</strong></li> - <li><strong class="cons">Full Consensus Rules (Block Weight, Maturity, etc.)</strong></li> + <li><strong class="cons">Full Consensus Rules (Block Weight, Coinbase Maturity, etc.)</strong></li> <li><strong class="cons">Data Serialization Formats</strong></li> - <li><strong class="cons">ECDSA Curve (secp256k1)</strong></li> - <li><strong class="term">Resources:</strong> <a href="https://developer.bitcoin.org/devguide/" target="_blank" rel="noopener noreferrer">Dev Guide</a>, <a href="https://en.bitcoin.it/wiki/Main_Page" target="_blank" rel="noopener noreferrer">Wiki</a>, <a href="https://github.com/bitcoin/bips" target="_blank" rel="noopener noreferrer">BIPs Repository</a>.</li> + <li><strong class="cons">ECDSA Curve (`secp256k1`)</strong></li> + <li><strong class="term">Resources:</strong> <a href="https://developer.bitcoin.org/devguide/" target="_blank" rel="noopener noreferrer">Dev Guide</a>, <a href="https://en.bitcoin.it/wiki/Main_Page" target="_blank" rel="noopener noreferrer">Wiki</a>, <a href="https://github.com/bitcoin/bips" target="_blank" rel="noopener noreferrer">BIPs Repo</a>.</li> </ul> </div> </div> </div> - <!-- Glossary (Keep as is) --> + <!-- Glossary --> <div class="col-lg-6 col-md-12"> <div class="info-card wp-type-summary" id="card-glossary-wp"> <div class="card-body"> @@ -327,16 +807,15 @@ </div> </div> <div class="collapse collapse-content" id="collapseGlossaryWp"> - <!-- Glossary content remains the same --> <dl><dt>Block</dt><dd>Timestamped collection of TXs secured by PoW.</dd><dt>Blockchain</dt><dd>Chain of blocks; public ledger.</dd><dt>Difficulty</dt><dd>Measure of how hard it is to find PoW hash.</dd><dt>Digital Signature</dt><dd>Proof of ownership via private key (ECDSA).</dd><dt>Double-Spending</dt><dd>Spending same money twice.</dd><dt>Hash</dt><dd>Cryptographic fingerprint (SHA256, RIPEMD160).</dd><dt>Incentive</dt><dd>Block reward + TX fees.</dd><dt>Longest Chain</dt><dd>Chain with most PoW; consensus history.</dd><dt>Merkle Tree</dt><dd>Hash tree summarizing TXs in a block.</dd><dt>Nonce</dt><dd>Value varied in header to find PoW.</dd><dt>Proof-of-Work (PoW)</dt><dd>Consensus mechanism requiring CPU effort.</dd><dt>SPV</dt><dd>Simplified Payment Verification.</dd><dt>Target</dt><dd>Threshold hash value must be below for PoW.</dd><dt>UTXO</dt><dd>Unspent Transaction Output (spendable coin).</dd></dl> </div> </div> </div> - <!-- Resources (Updated Links maybe) --> + <!-- Resources --> <div class="col-lg-6 col-md-12"> <div class="info-card wp-type-resource" id="card-resources-wp"> <div class="card-body"> - <h5><i class="bi bi-link-45deg"></i> Foundational Resources</h5> + <h5><i class="bi bi-link-45deg"></i> Foundational & Developer Resources</h5> <!-- Title Updated --> <div class="card-content-wrapper"> <p class="summary"> Links to the original paper and essential developer resources. @@ -357,7 +836,6 @@ <li><i class="bi bi-card-list"></i> BIPs Repository: <a href="https://github.com/bitcoin/bips" target="_blank" rel="noopener noreferrer">github.com/bitcoin/bips</a></li> </ul> <h6>Cited Precursors/Concepts:</h6> - <!-- Keep precursor links --> <ul><li>Hashcash Paper</li><li>B-money Paper</li><li>Timestamping (Haber/Stornetta Refs [3,4])</li><li>Merkle Trees (Merkle Ref [7])</li></ul> </div> </div> @@ -369,7 +847,14 @@ </div> <!-- /container --> <footer class="container text-center"> - <p id="footer-text">Bitcoin Whitepaper: Technical Blueprint & Evolution | Styles inspired by David Veksler's Cheatsheets</p> + <div> + <a href="https://www.linkedin.com/in/davidveksler/" title="David Veksler on LinkedIn" target="_blank" rel="noopener noreferrer" class="mx-2 link-secondary"> + <i class="bi bi-linkedin"></i> LinkedIn + </a> + <a href="https://cheatsheets.davidveksler.com/" title="Browse All Cheatsheets" class="mx-2 link-secondary"> + <i class="bi bi-collection"></i> All Cheatsheets + </a> + </div> </footer>