ผ่ารหัสลับ Bitcoin 0.1.0: เมื่อ AI ชุบชีวิตโค้ด Satoshi ไบต์ต่อไบต์ และความจริงสุดระทึกของเวอร์ชันแรกที่ต่างจากปัจจุบันลิบลับ

1. ปริศนา 15 ปีของ Satoshi: เมื่อบิตคอยน์ก้อนแรกไม่ได้ถูกสร้างมาให้คอมไพล์ซ้ำได้

ในโลกของระบบกระจายศูนย์ (Decentralized Systems) ทุกคนมักเชื่อในคติพจน์ยอดฮิตที่ว่า “Don’t Trust, Verify” — อย่าไว้ใจใคร ให้ตรวจสอบโค้ดด้วยตัวเอง

แต่สำหรับประวัติศาสตร์ 15 ปีของ Bitcoin มีเรื่องตลกร้ายระดับตำนานที่วิศวกรซอฟต์แวร์ระดับท็อปต่างทราบดี: ไม่มีใครในโลกสามารถเอาซอร์สโค้ดต้นฉบับ Bitcoin v0.1.0 ที่ Satoshi Nakamoto ปล่อยออกมาในวันที่ 9 มกราคม 2009 มาคอมไพล์ให้ได้ไฟล์รันไทม์ bitcoin.exe ที่ตรงกับไฟล์ที่ปล่อยให้ดาวน์โหลดในวันแรกได้แม้แต่คนเดียว!

ไฟล์ bitcoin.exe ขนาดดั้งเดิม 6,440,960 ไบต์ ที่มีค่า SHA-256 Checksum คือ:

fbcac071d92e26d82ec917214e334bd43850c0691f113bab1d4741c9bdd30d2d

มันกลายเป็นเสมือน “วัตถุโบราณดิจิทัล (Digital Relic)” ที่ถูกแช่แข็งไว้ในกาลเวลา เพราะในยุคปี 2008–2009 วงการซอฟต์แวร์ยังไม่มีแนวคิดเรื่อง Deterministic / Reproducible Builds (การคอมไพล์โค้ดเดิมในสภาพแวดล้อมใดก็ได้ แล้วต้องได้ไบนารีระดับบิตและไบต์ตรงกัน 100%) ยุคนั้นคอมไพเลอร์แต่ละตัวจะประทับ Timestamp ลงใน Header ของ Portable Executable (PE), ลิงเกอร์จะจัดเรียง Memory Section และ Object Padding ตามอารมณ์ของ Toolchain บนเครื่องของนักพัฒนา

ผลลัพธ์คือ ตลอดสิบกว่าปีที่ผ่านมา ชุมชนนักพัฒนาทำได้เพียงแค่มองไฟล์ bitcoin.exe ของ Satoshi แล้วตั้งคำถามในใจลึกๆ ว่า:

“ไบนารีที่ผู้คนรันกันในวันแรก มีโค้ดลับหรือความผิดพลาดประหลาดที่ไม่มีอยู่ในซอร์สโค้ดซ่อนอยู่หรือไม่? หรือว่า Satoshi แอบใส่อะไรไว้ก่อนส่งมอบให้โลก?”

จนกระทั่งในเดือนตุลาคม 2026 นักพัฒนาในชื่อ t4t5 (Tristan) ร่วมมือกับโมเดลปัญญาประดิษฐ์ (AI Assistant - Claude) ดำเนินการ Digital Binary Archaeology ถอดรหัสย้อนรอยสภาพแวดล้อมระบบปฏิบัติการ Windows XP ของ Satoshi จนสามารถคอมไพล์ bitcoin.exe และแพ็กไฟล์ .rar ออกมาได้ ตรงกันแบบ Byte-for-Byte (100% Match) เป็นครั้งแรกในประวัติศาสตร์!

flowchart LR
    subgraph Mystery["15 Years of Mystery (2009-2026)"]
        S1["Satoshi's Source Code (0.1.0)"] -->|Modern GCC / Clang| B1["Mismatch Executable ❌"]
        S2["Satoshi's bitcoin.exe (2009)"] -->|SHA-256| H1["fbcac071d... (Unverifiable Archive)"]
    end

    subgraph Solved["AI Reverse-Engineering Breakthrough (t4t5)"]
        A1["AI Binary Diffing & PE Analysis"] --> T1["Reconstruct Satoshi's WinXP Toolchain"]
        T1 --> T2["MinGW GCC 3.4.5 + binutils Swap + Wine 32-bit"]
        T2 --> B2["Rebuilt bitcoin.exe"]
        B2 -->|SHA-256 Match| H2["fbcac071d... (100% Byte Match! ✅)"]
    end

    style Mystery fill:#2d3748,stroke:#4a5568,color:#fff
    style Solved fill:#1a365d,stroke:#3182ce,color:#fff
    style H2 fill:#22543d,stroke:#38a169,stroke-width:2px,color:#fff

ทว่าสิ่งที่น่าทึ่งยิ่งกว่าการจับคู่บิตและไบต์ คือเมื่อเรากางสถาปัตยกรรมของ Bitcoin v0.1.0 ออกมาดูเทียบกับ Modern Bitcoin Core (v28.x) ในปัจจุบัน เราจะพบว่า Bitcoin รุ่นแรกไม่ได้เป็นอย่างที่คุณคิดเลยแม้แต่น้อย!

มันมีระบบ “โอนเงินผ่าน IP Address ตรงๆ”, ระบบค้นหาเพื่อนผ่านห้องแชท “IRC”, เอนจินฐานข้อมูล “Berkeley DB” ที่พร้อมพังทุกเมื่อ, และระบบสคริปต์ที่อัดแน่นด้วย Opcode อันตรายจนเกือบทำให้ระบบล่มสลาย ทั้งหมดนี้ถูกประกอบขึ้นเป็นโปรแกรม GUI ชิ้นเดียวบน Windows XP

บทความนี้จะพาทุกคนดำดิ่งสู่การชันสูตรเชิงวิศวกรรมระบบ (Systems Engineering Autopsy) ทั้งเบื้องหลังการใช้ AI ชุบชีวิตไบนารีระดับไบต์ และการเปรียบเทียบสถาปัตยกรรมข้ามกาลเวลาระหว่าง Bitcoin v0.1.0 กับ Modern Bitcoin Core

---

2. กายวิภาคของการถอดรหัส: AI แกะรอยเครื่องคอมพ์ของ Satoshi ได้อย่างไร?

การทำให้ซอร์สโค้ดภาษา C++ ยุคปี 2008 คอมไพล์ออกมาได้ไบนารีตรงกันระดับไบต์บนสถาปัตยกรรม x86 ไม่ใช่เรื่องของการกดปุ่ม make แต่เป็นการสืบสวนร่องรอยทางนิติวิทยาศาสตร์ดิจิทัล (Digital Forensics)

โปรเจกต์โอเพนซอร์ส t4t5/bitcoin-0.1-rebuilt เผยให้เห็นขั้นตอนที่นักพัฒนาและ AI ต้องฝ่าฟันอุปสรรคระดับบิต 4 ประการใหญ่:

sequenceDiagram
    autonumber
    actor Dev as Developer (t4t5)
    participant AI as AI Engine (Claude)
    participant Bin as Satoshi's Original PE Binary
    participant Tool as Historical Toolchain (Wine/Docker)

    Dev->>AI: อัปโหลด Binary Diffs & Structural PE Headers
    AI->>Bin: ตรวจสอบ COFF Header, Import Directory & Section Alignment
    AI-->>Dev: ชี้เป้า: IAT Thunk ห่างกัน 8 ไบต์ แปลว่าใช้ binutils ปี 2008
    Dev->>Tool: ประกอบ MinGW gcc 3.4.5 + binutils-2.18.50
    Dev->>Tool: รันคอมไพล์ wxWidgets และ Berkeley DB
    Tool-->>AI: เกิด Discrepancy ใน Object Padding
    AI-->>Dev: ค้นพบ 'Franken-Toolchain': Satoshi อัปเกรด binutils ระหว่างทาง!
    Dev->>Tool: สลับ binutils-2.17 สร้าง deps แล้วใช้ 2.18 ลิงก์ bitcoin.exe
    Tool-->>Dev: SHA-256 ตรงเป๊ะ: fbcac071... (0 Bytes Difference)

A. ปริศนา “Franken-Toolchain” ที่ไม่มีในประวัติศาสตร์

เมื่อนำไบนารีต้นฉบับมาแกะด้วย objdump และตรวจสอบโครงสร้าง Portable Executable (PE) ทางทีมวิจัยพบสิ่งผิดปกติ:

• โค้ดของไลบรารีภายนอกอย่าง wxWidgets 2.8.9 และ Berkeley DB 4.7.25 ถูกคอมไพล์ด้วย GNU Binutils ยุคเก่า (binutils-2.17.50-20060824-1)
• แต่ตัวไฟล์ปฏิบัติการหลัก bitcoin.exe และ Object Files ของ Bitcoin กลับมีลักษณะของ Import Address Table (IAT) thunks ที่ถูกจัดเรียงเว้นระยะ 8 ไบต์ และมีโครงสร้าง Padding สอดคล้องกับสแนปช็อตที่ใหม่กว่าอย่าง binutils-2.18.50-20080109-2

นั่นหมายความว่า: ในระหว่างที่ Satoshi กำลังพัฒนา Bitcoin เขาได้ทำการอัปเกรดเครื่องมือพัฒนาบนเครื่องส่วนตัวของเขา! เขาไม่ได้คอมไพล์ทุกอย่างใหม่ตั้งแต่ต้น แต่คอมไพล์ไลบรารีค้างไว้ด้วย toolchain เก่า แล้วพอมาบิลด์ตัวโปรแกรมหลัก จึงใช้ toolchain ใหม่ ลิงเกอร์ (GNU ld) จึงทิ้งลายเซ็นผสม (Hybrid Footprint) เอาไว้ในไฟล์

B. กับดัก Windows Shell (cmd.exe vs MSYS)

หนึ่งในจุดที่ทำให้การคอมไพล์ล้มเหลวมาตลอดหลายปี คือนักพัฒนามักพยายามคอมไพล์โค้ดผ่าน MSYS Shell (สภาพแวดล้อมสไตล์ Unix บน Windows) แต่ AI ได้ช่วยชี้ให้เห็นความแตกต่างของ Path Separator:

• หากคอมไพล์ผ่าน MSYS คอมไพเลอร์จะแปลง Path เป็นฟอร์แมต /c/build/... ซึ่งส่งผลต่อ Macro ในการดีบักและข้อความ String ภายในไบนารี
• Satoshi รันคำสั่ง mingw32-make ตรงๆ จาก Windows Command Prompt (cmd.exe) แบบดั้งเดิม ซึ่งใช้ Backslash (\) และตัวแปรสภาพแวดล้อมของ Windows XP แท้ๆ

C. การย้อนเวลาของ PE Header Timestamp

ในหัวไฟล์ PE/COFF จะมีฟิลด์ 32-bit ชื่อ TimeDateStamp ซึ่งบันทึกเวลาเป็น Unix Epoch ของวินาทีที่ไฟล์ถูกลิงก์เสร็จสิ้น จากการวิเคราะห์เชิงลึก พบว่าไฟล์ bitcoin.exe ดั้งเดิมถูกลิงก์เสร็จสมบูรณ์เมื่อ:

Epoch Time: 1231629367
UTC: Saturday, January 10, 2009, 23:16:07 UTC

การสร้างไฟล์ให้ตรงกันทุกไบต์ จึงจำเป็นต้องควบคุมสภาพแวดล้อมระบบหรือแก้ไขส่วนหัวไบต์ให้อยู่ในวินาทีประวัติศาสตร์นี้อย่างแม่นยำ

D. รายละเอียด Line Endings (CRLF vs LF) ใน wxWidgets Manifest

แม้แต่ไฟล์ wx/msw/wx.rc (Resource Script ของ wxWidgets GUI) การที่ Git บน Linux แปลงตัวตัดบรรทัดจาก CRLF (\r\n) เป็น LF (\n) ก็ทำให้ผลลัพธ์ของ Resource Compiler (windres) มีขนาดต่างกัน 4 ไบต์ และส่งผลให้แฮช SHA-256 คลาดเคลื่อนทันที

ด้วยความช่วยเหลือของ AI ในการวิเคราะห์ Binary Diff แต่ละ Section (เทียบระหว่าง .text, .data, .rdata, .bss) ทำให้ในที่สุด ทีมงานสามารถเซ็ตอัปคอนเทนเนอร์ 32-bit Wine บน Linux เพื่อสั่งรัน MinGW gcc 3.4.5 บนจำลอง Windows XP และผลิตไฟล์ออกมาได้แฮชตรงกัน 100%

💡 บทเรียนสำคัญด้าน Supply Chain Security: การพิสูจน์ได้ว่าโค้ดต้นฉบับคอมไพล์ออกมาได้ไบนารีตรงกันทุกไบต์ ยืนยันข้อเท็จจริงสำคัญทางประวัติศาสตร์ว่า Satoshi ไม่ได้แอบใส่โทรจัน, คีย์ลับ, หรือโค้ดดักจับข้อมูลใดๆ ลงในไฟล์รันไทม์ที่แจกจ่ายในวันแรก มันคือสิ่งที่ซอร์สโค้ดบอกไว้ทุกประการ

---

3. สถาปัตยกรรมระดับลึก: Bitcoin v0.1.0 vs Modern Bitcoin Core (v28.x)

เมื่อตัดภาพมาดูเนื้อในของสถาปัตยกรรม ความแตกต่างระหว่างซอฟต์แวร์ที่ Satoshi เขียนขึ้นในปี 2008 กับ Bitcoin Core ในยุคปัจจุบัน เปรียบเสมือนเครื่องบินปีกไม้สองชั้นของพี่น้องตระกูลไรท์ เทียบกับเครื่องบินรบสเตลท์ยุคที่ 5

flowchart TD
    subgraph V01["สถาปัตยกรรม Bitcoin v0.1.0 (ปี 2009) - Monolithic UI Client"]
        direction TB
        UI1["wxWidgets Desktop GUI\n(ปุ่ม Checkbox 'Generate Coins')"]
        NET1["irc.cpp\n(IRC Bootstrap ค้นหา IP ผ่านห้องแชท #bitcoin)"]
        IP1["Pay-to-IP Direct Transfer\n(ต่อ TCP เข้าพอร์ต 8333 ขอ Public Key ตรงๆ)"]
        CRY1["OpenSSL Direct Calls\n(Non-canonical DER Signatures)"]
        DB1["Oracle Berkeley DB (BDB)\n(เก็บทั้ง Chain Index และ Wallet ใน db.cpp)"]
        MIN1["Internal CPU Miner Thread\n(คำนวณ SHA-256 วนลูปในโปรเซสเดียวกัน)"]

        UI1 --- NET1
        UI1 --- IP1
        UI1 --- CRY1
        UI1 --- DB1
        UI1 --- MIN1
    end

    subgraph Modern["สถาปัตยกรรม Modern Bitcoin Core v28.x (2026) - Hardened Modular"]
        direction TB
        DAEMON["bitcoind (Headless Daemon Engine)"]
        P2P["Modern P2P Networking\n(Tor v3, I2P, ASMap, Feeler Connections)"]
        SEC["libsecp256k1 Engine\n(Constant-Time, Schnorr Signatures, Taproot)"]
        STOR["LevelDB + SQLite\n(LevelDB สำหรับ UTXO / SQLite สำหรับ Descriptors)"]
        CONS["libbitcoinconsensus\n(Deterministic Verification, Script Sandbox)"]
        MIN2["Stratum V2 Protocol\n(แยก Mining Pool / ASIC Hardware อิสระ)"]
        IPC["Multiprocess IPC / Cap'n Proto Sandboxing"]

        DAEMON --- P2P
        DAEMON --- SEC
        DAEMON --- STOR
        DAEMON --- CONS
        DAEMON --- MIN2
        DAEMON --- IPC
    end

    style V01 fill:#2d3748,stroke:#e53e3e,stroke-width:2px,color:#fff
    style Modern fill:#1a365d,stroke:#38a169,stroke-width:2px,color:#fff

ตารางเปรียบเทียบเชิงสถาปัตยกรรม (Side-by-Side Deep Comparison)

มิติทางวิศวกรรม	Bitcoin v0.1.0 (มกราคม 2009)	Modern Bitcoin Core v28.x (2026)
โครงสร้างสถาปัตยกรรม	Monolithic C++ รวมทุกอย่าง (~14,000 บรรทัด) GUI ผูกติดกับ Core	Modular, Multiprocess Architecture (แยก Daemon, GUI, Wallet ผ่าน IPC)
Peer Discovery (ค้นหาโหนด)	เชื่อมต่อเข้าห้องแชท IRC (#bitcoin) บน EFnet หรือสแกน IP ท้องถิ่น	DNS Seeders, P2P Addr Gossip (BIP155 addrv2), Hardcoded Seeds
โปรโตคอลการรับ-ส่งเงิน	Pay-to-IP (ต่อ Socket ส่งเงินให้ IP ตรงๆ) และ Base58 Address	UTXO Script-based (P2PKH, P2SH, SegWit v0/v1, Taproot MAST)
เอนจินการเข้ารหัส (Crypto)	เรียกใช้งานฟังก์ชันของ OpenSSL โดยตรง	libsecp256k1 (Constant-time, ออกแบบเฉพาะสำหรับ Bitcoin)
ระบบฐานข้อมูล (Storage)	Oracle Berkeley DB (BDB) สำหรับบล็อกและกระเป๋าเงิน	LevelDB (UTXO Set / Chainstate) + SQLite (Descriptor Wallets)
การขุดเหรียญ (Mining)	ขุดผ่าน CPU Thread ภายในโปรแกรม (กดปุ่มบน GUI)	Stratum V1/V2 Protocol เชื่อมต่อกับเครื่องขุด ASIC ภายนอก
ความเป็นส่วนตัวของโหนด	เปิดเผย Public IP ชัดเจน ไม่มีระบบซ่อนตัว	รองรับ Tor v3 Onion Services, I2P, CJDNS, Compact Filters (BIP157/158)
ขนาดบล็อก (Block Size Limit)	ไม่มีขีดจำกัดขนาดบล็อก (No Limit)	บล็อกถูกจำกัดด้วย Block Weight 4,000,000 Weight Units (SegWit)
การทดสอบและ Verification	ไม่มี Unit Test Suite, ไม่มี Fuzzing, สร้างบน Windows XP	LLVM LibFuzzer, OSS-Fuzz, Functional Test Suites, Guix Reproducible Builds

---

4. ชำแหละเครื่องในที่หายไป: 4 กลไกสุดช็อกในโค้ดของ Satoshi

หากคุณเปิดดูซอร์สโค้ดของ Bitcoin 0.1.0 ในไฟล์อย่าง main.cpp, net.cpp, irc.cpp, และ script.cpp คุณจะพบกับการตัดสินใจเชิงวิศวกรรมที่ทั้งฉลาดหลักแหลมและชวนขนลุกในคราวเดียวกัน:

กลไกที่ 1: Pay-to-IP — เมื่อคุณสามารถโอนบิตคอยน์เข้า IP Address ได้ตรงๆ!

ในยุคแรก Satoshi มองว่าการส่งเงินควรจะง่ายเหมือนการกดส่งไฟล์ P2P ในโปรแกรมอย่าง BitTorrent หรือ Skype ในโค้ดจึงมีฟังก์ชันที่ชื่อว่า IP Transaction:

// ตัวอย่างโค้ดใน net.cpp ของ Bitcoin v0.1.0
bool ConnectSocket(const CAddress& addrConnect, SOCKET& hSocketRet)
{
    hSocketRet = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
    if (hSocketRet == INVALID_SOCKET)
        return false;

    struct sockaddr_in sockaddr;
    addrConnect.GetSockAddr(&sockaddr);

    // เชื่อมต่อ TCP ตรงไปยัง IP ของผู้รับผ่านพอร์ต 8333
    if (connect(hSocketRet, (struct sockaddr*)&sockaddr, sizeof(sockaddr)) == SOCKET_ERROR)
    {
        closesocket(hSocketRet);
        return false;
    }
    return true;
}

เมื่อคุณกรอก IP Address ของเพื่อนในช่องโอนเงิน:

1. โปรแกรมของคุณจะยิง TCP Socket ไปที่ IP ปลายทางที่พอร์ต 8333
2. เครื่องปลายทางจะตอบกลับด้วย Public Key ของตนเอง
3. เครื่องของคุณจะสร้างธุรกรรมโอนเงินให้ Public Key นั้น แล้วบรอดแคสต์ลงเครือข่าย

🛑 จุดเสี่ยงระดับวิกฤต (The Fatal Loophole): ฟังก์ชัน Pay-to-IP คือฝันร้ายด้านความปลอดภัยขั้นสูงสุด! มันเปิดโอกาสให้เกิดการโจมตีแบบ Man-in-the-Middle (MITM) และ BGP Hijacking ผู้ให้บริการอินเทอร์เน็ต (ISP) หรือแฮกเกอร์ที่ดักฟังทราฟฟิกสามารถสลับ Public Key ของผู้รับเป็นของตัวเองระหว่างการเชื่อมต่อ TCP แบบไม่เข้ารหัส ทำให้เงินถูกขโมยไปในทันที! ฟังก์ชันนี้ถูกตัดทิ้งอย่างถาวรใน Bitcoin v0.3.19

---

กลไกที่ 2: ระบบค้นหาเพื่อนผ่านห้องแชท IRC (irc.cpp)

ก่อนที่ระบบกระจายศูนย์จะมี DNS Seeds หรือ Kademlia DHT บิตคอยน์จะหาเพื่อนโหนดแรกเจอได้อย่างไร? คำตอบของ Satoshi คือ: ใช้บริการเซิร์ฟเวอร์ IRC สาธารณะ!

flowchart LR
    NodeA["โหนด A (เริ่มทำงาน)"] -->|แปลง IP เป็น Nickname\nเช่น u127001001| IRC["เซิร์ฟเวอร์ EFnet IRC\n(ห้องแชท #bitcoin)"]
    NodeB["โหนด B (กำลังออนไลน์)"] -->|อ่านรายชื่อ Users ในห้อง| IRC
    NodeB -->|ถอดรหัส Nickname เป็น IP| NodeA
    NodeA <-->|สร้างการเชื่อมต่อ P2P โดยตรง| NodeB

    style IRC fill:#742a2a,stroke:#e53e3e,stroke-width:2px,color:#fff
    style NodeA fill:#1a365d,stroke:#3182ce,color:#fff
    style NodeB fill:#22543d,stroke:#38a169,color:#fff

ในไฟล์ irc.cpp เมื่อโปรแกรมเปิดขึ้นมา มันจะเชื่อมต่อเข้าไปที่เซิร์ฟเวอร์ IRC ของเครือข่าย EFnet หรือ OFTC จากนั้นนำ IP Address และ Port ของเครื่องตัวเองมาเข้ารหัส Base58 หรือตัวเลข แล้วตั้งเป็น Nickname เข้าไปนั่งรออยู่ในห้อง #bitcoin

โหนดอื่นๆ ที่เข้ามาในห้องจะดึงรายชื่อผู้ใช้ทั้งหมดในห้องแชท แล้วถอดรหัส Nickname กลับมาเป็น IP เพื่อเริ่มยิงคำขอเชื่อมต่อ P2P!

⚠️ ทำไมวิธีนี้ถึงพังในโลกความเป็นจริง? หากเซิร์ฟเวอร์ IRC ถูกบล็อก (DDoS) หรือถูกแฮกเกอร์ยึดสิทธิ์ Channel Operator แฮกเกอร์สามารถเตะโหนดทั้งหมดออกจากห้อง หรือส่ง IP ปลอมของตัวเองเพื่อทำ Sybil Attack และแยกเครือข่ายบิตคอยน์ออกจากกัน (Network Partition) ในเวอร์ชันปัจจุบัน Bitcoin จึงเปลี่ยนมาใช้ DNS Seeds และระบบ P2P Peer Gossip แทนอย่างสมบูรณ์

---

กลไกที่ 3: หายนะ OpenSSL และปัญหา Signature Malleability

ในเวอร์ชัน 0.1.0 Satoshi ไม่ได้เขียนไลบรารีการคำนวณทางคณิตศาสตร์ Elliptic Curve (ECDSA บนเส้นโค้ง secp256k1) ขึ้นมาเอง แต่เรียกใช้ฟังก์ชัน ECDSA_verify() จากไลบรารี OpenSSL โดยตรง

ปัญหาคือ OpenSSL ถูกออกแบบมาสำหรับโปรโตคอล TLS/SSL ของเว็บเซิร์ฟเวอร์ ไม่ได้ถูกออกแบบมาสำหรับระบบฉันทามติ (Consensus Protocol) ที่ต้องการผลลัพธ์ที่แน่นอนระดับบิตบนทุกระบบปฏิบัติการ:

1. Non-Canonical DER Signatures: OpenSSL ในยุคนั้นยอมรับลายเซ็นดิจิทัลที่มีโครงสร้างแบบหลวมๆ ลายเซ็นที่มีค่า $S$ แบบปกติ หรือค่าคู่ตรงข้าม $-S \pmod n$ ต่างก็ผ่านการตรวจสอบความถูกต้องทั้งคู่
2. Transaction Malleability: แฮกเกอร์สามารถดักจับธุรกรรมกลางทาง เปลี่ยนรูปแปลงค่า $S$ ของลายเซ็น ทำให้ค่า Hash (Transaction ID) เปลี่ยนไป ทั้งที่เนื้อหาการโอนเงินยังเหมือนเดิม!

ความหละหลวมของ OpenSSL ในยุคแรกนี้เองที่เป็นหนึ่งในต้นตอของวิกฤต Mt. Gox ในปี 2014 และเป็นเหตุผลที่ทีมพัฒนา Bitcoin Core ต้องสร้างไลบรารี libsecp256k1 ขึ้นมาใหม่ทั้งหมด ซึ่งเป็นโค้ดแบบ Constant-Time ไม่ใช้หน่วยความจำแบบไดนามิก และให้ผลลัพธ์เหมือนกันทุกประการบนทุก CPU สถาปัตยกรรม

---

กลไกที่ 4: บั๊กคำนวณ Difficulty Adjustment (Off-by-One Bug)

ใน Whitepaper บิตคอยน์ระบุว่าความยากในการขุด (Difficulty) จะปรับทุกๆ 2,016 บล็อก เพื่อรักษาเวลาเฉลี่ยให้อยู่ที่ 10 นาทีต่อบล็อก (ประมาณ 2 สัปดาห์):

$\text{Target}_{\text{new}} = \text{Target}_{\text{old}} \times \frac{\text{Actual Timespan}}{1,209,600 \text{ วินาที}}$

แต่ในโค้ด main.cpp ของ Satoshi กลับมีบั๊ก Off-by-One ในการคำนวณช่วงเวลา:

// โค้ดต้นฉบับใน main.cpp
int nBlockEstimate = 2016;
// ...
const CBlockIndex* pindexFirst = pindexLast;
for (int i = 0; pindexFirst && i < nBlockEstimate - 1; i++)
    pindexFirst = pindexFirst->pprev;

สังเกตตรงเงื่อนไข i < nBlockEstimate - 1 (วนลูป 2015 ครั้ง)! แทนที่ระบบจะนำ Timestamp ของบล็อกปัจจุบันลบด้วยบล็อกแรกเมื่อ 2,016 บล็อกที่แล้ว ระบบกลับนำไปลบกับบล็อกที่ 2,015 ทำให้ช่วงเวลาที่นำมาคำนวณสั้นกว่าความจริงไป 1 บล็อกเสมอ

💡 ทำไมบั๊กนี้ถึงยังอยู่ในบิตคอยน์ปัจจุบัน? เนื่องจากบิตคอยน์ทำงานด้วยระบบฉันทามติ (Consensus) หากมีใครพยายามแก้บั๊กนี้ให้คำนวณครบ 2,016 บล็อก บล็อกที่ถูกขุดขึ้นมาใหม่จะถือว่าไม่ถูกต้อง (Invalid) สำหรับโหนดรุ่นเก่าทันที และจะทำให้เกิดการแตกแยกสายโซ่ (Hard Fork)! บั๊กนี้จึงกลายเป็น “กฎเหล็กถาวร (Bug-turned-Feature)” ของเครือข่ายบิตคอยน์ที่ต้องเก็บรักษาไว้ตลอดไป

---

5. จุดตายในอดีต: เมื่อช่องโหว่เกือบทำลายล้าง Bitcoin

ความไร้เดียงสาของโค้ดในเวอร์ชัน 0.1.0 ทำให้บิตคอยน์ในยุคแรกต้องผ่านวิกฤตความเป็นความตายที่เกือบทำให้โปรเจกต์ต้องปิดตัวลง:

timeline
    title มหากาพย์ช่องโหว่และจุดวิกฤตในประวัติศาสตร์ Bitcoin
    2010 : CVE-2010-5139 Value Overflow Incident (เสก 1.84 แสนล้าน BTC ที่บล็อก 74,638)
         : ปิด 15 Opcodes ใน Script Engine (แก้ปัญหา DoS Stack Crash)
         : กำหนด 1MB Block Size Limit เพื่อป้องกัน Memory Exhaustion
    2013 : CVE-2013-3220 Berkeley DB vs LevelDB Split (วิกฤต Fork ระหว่างโหนด 0.7 กับ 0.8)
    2014 : Mt. Gox Collapse & Transaction Malleability (ผลพวงจากการพึ่งพา OpenSSL)
    2015 : เปิดตัว libsecp256k1 และสถาปัตยกรรม Deterministic Verification
    2026 : โปรเจกต์ bitcoin-0.1-rebuilt พิสูจน์ไบนารีต้นฉบับตรงกัน 100% ไร้ Backdoor

1. วิกฤตเสกเงิน 184,000,000,000 BTC (CVE-2010-5139)

ในวันที่ 15 สิงหาคม 2010 ที่บล็อกหมายเลข 74,638 มีแฮกเกอร์นิรนามสร้างธุรกรรมแปลกประหลาดที่ส่งผลลัพธ์เป็นเงิน 1.84 แสนล้านบิตคอยน์ เข้ากระเป๋า 2 ใบ!

สาเหตุเกิดจากในโค้ด C++ ของ Satoshi มีการตรวจสอบผลรวมของ Transaction Output ด้วยตัวแปร integer แบบดั้งเดิม เมื่อแฮกเกอร์ใส่ค่าติดลบเข้าไป ทำให้เกิดอาการ Integer Overflow ข้ามขีดจำกัดสูงสุดของ 64-bit integer ค่าผลรวมจึงตีกลับกลายเป็นค่าบวกขนาดเล็กที่ผ่านการตรวจสอบได้อย่างง่ายดาย! Satoshi ต้องเร่งปล่อยแพตช์ฉุกเฉินเวอร์ชัน 0.3.10 ภายในเวลาไม่กี่ชั่วโมงเพื่อ Hard Fork ลบธุรกรรมดังกล่าวทิ้ง

2. วิกฤต Berkeley DB ล็อกแตก (CVE-2013-3220)

ในเวอร์ชัน 0.1.0 Satoshi ใช้ Oracle Berkeley DB (BDB) เป็นเอนจินจัดเก็บข้อมูลทั้งหมด แต่ BDB มีข้อจำกัดเรื่อง max_locks (จำนวน Lock สูงสุดที่อนุญาตให้เปิดพร้อมกัน)

เมื่อบิตคอยน์อัปเกรดเป็นเวอร์ชัน 0.8 ในปี 2013 ทีมพัฒนาได้เปลี่ยนมาใช้ LevelDB ของ Google ซึ่งไม่มีข้อจำกัดเรื่อง Lock ปรากฏว่าเกิดบล็อกขนาดใหญ่ที่มี Transaction Input จำนวนมหาศาล โหนดที่รัน LevelDB (0.8) สามารถตรวจสอบบล็อกผ่านได้อย่างสบาย แต่โหนดรุ่นเก่าที่ยังใช้ Berkeley DB (0.7) กลับเกิดอาการ Lock Exhaustion และปฏิเสธบล็อกนั้น ส่งผลให้เครือข่ายบิตคอยน์แตกออกเป็น 2 สายโซ่ (Chain Split) เป็นเวลานานหลายชั่วโมง จนกระทั่งนักขุดต้องยอมย้อนกลับไปใช้เวอร์ชัน 0.7 เพื่อรอการแก้ไข

---

6. พิมพ์เขียวปฏิบัติการ: Rebuild โค้ด Satoshi และวิธีรัน Node ปัจจุบันให้ปลอดภัย

A. พิมพ์เขียวการ Rebuild Bitcoin v0.1.0 ด้วย Docker (ท้าพิสูจน์ Byte-for-Byte)

หากคุณต้องการสัมผัสประวัติศาสตร์และพิสูจน์ด้วยตาตนเองว่าคอมไพเลอร์โบราณสามารถสร้างไบนารีที่ตรงกับแฮช SHA-256 ของ Satoshi ได้จริง คุณสามารถรันสคริปต์ของโปรเจกต์ bitcoin-0.1-rebuilt บน Linux Host (x86-64) ได้ดังนี้:

# 1. โคลนคลังข้อมูลย้อนรอยประวัติศาสตร์
git clone https://github.com/t4t5/bitcoin-0.1-rebuilt.git
cd bitcoin-0.1-rebuilt

# 2. เริ่มต้นกระบวนการประกอบร่าง Toolchain ผ่าน Docker และ Wine 32-bit
./build.sh

เมื่อกระบวนการคอมไพล์และลิงก์ PE เสร็จสิ้น คุณจะได้รับเอาต์พุตตรวจสอบความถูกต้อง:

=== Verifying Rebuilt Binaries ===
bitcoin.exe SHA-256: fbcac071d92e26d82ec917214e334bd43850c0691f113bab1d4741c9bdd30d2d
Status: 100% BYTE-FOR-BYTE MATCH!
Archive: bitcoin-0.1.0.rar SHA-256 MATCH VERIFIED!

---

B. พิมพ์เขียวการตั้งค่า Modern Bitcoin Node (Hardened bitcoin.conf)

สำหรับผู้ที่รันโหนดในปัจจุบัน คุณไม่สามารถใช้ค่าเริ่มต้นที่เปลือยเปล่าเหมือนยุค Satoshi ได้ นี่คือตัวอย่างไฟล์คอนฟิกูเรชันสำหรับการรัน Bitcoin Core v28+ ระดับ Hardened เพื่อความปลอดภัยและปิดจุดอ่อนทางเครือข่าย:

# /etc/bitcoin/bitcoin.conf (Hardened Production Node Config)

# 1. Network & Privacy Hardening
listen=1
maxconnections=40
# บังคับเชื่อมต่อผ่าน Tor Onion Service v3 เท่านั้น เพื่อความเป็นส่วนตัวสูงสุด
proxy=127.0.0.1:9050
listenonion=1
onlynet=onion

# 2. Protection Against Sybil & Eclipse Attacks
# เปิดใช้งาน ASMap เพื่อกระจายการเชื่อมต่อไปยัง Autonomous System Numbers ที่หลากหลาย
asmap=/etc/bitcoin/asmap.dat
# เปิดใช้งาน Feeler Connections เพื่อทดสอบโหนดใหม่ๆ อย่างต่อเนื่อง
discover=0

# 3. RPC Interface Isolation (ป้องกันการแฮกเจาะระบบควบคุม)
server=1
rpcbind=127.0.0.1
rpcallowip=127.0.0.1
# ห้ามเปิดเผยพอร์ต RPC สู่ Public IP เป็นอันขาด
disablewallet=0

# 4. Resource Allocation & DoS Prevention
dbcache=4096
maxmempool=300
mempoolexpiry=72
# ปฏิเสธธุรกรรมที่ใช้ Non-standard Scripts เพื่อลดความเสี่ยง 0-day
permitbaremultisig=0

# 5. Security & Verification
checkblocks=6
checklevel=3

💡 สูตรแนะนำการตั้งค่า Asmap: การใส่พารามิเตอร์ asmap ใน Bitcoin Core ช่วยให้โหนดของคุณไม่ถูกล้อมรอบด้วย IP ที่มาจากผู้ให้บริการคลาวด์หรือ Data Center เจ้าเดียวกัน เป็นเกราะป้องกันสำคัญที่สุดในการต้านทานการโจมตีแบบ Eclipse Attack

---

7. บทสรุป: ความงดงามของระบบที่พัฒนาผ่านบาดแผล

มหากาพย์การใช้ AI ชุบชีวิต Bitcoin v0.1.0 ให้กลับมามีลมหายใจตรงกันทุกไบต์ของโปรเจกต์ bitcoin-0.1-rebuilt ไม่เพียงแต่เป็นชัยชนะของวงการ Digital Archaeology และการพิสูจน์ความบริสุทธิ์ของตัวตน Satoshi Nakamoto เท่านั้น

แต่มันยังสอนบทเรียนทางวิศวกรรมซอฟต์แวร์ที่ทรงพลังที่สุดบทหนึ่งแก่เรา:

“ไม่มีระบบกระจายศูนย์ใดที่สมบูรณ์แบบตั้งแต่วันแรก”

บิตคอยน์ไม่ได้ประสบความสำเร็จเพราะโค้ดเวอร์ชันแรกถูกเขียนขึ้นมาอย่างเลิศเลอไร้ที่ติ ในทางกลับกัน โค้ดรุ่นบุกเบิกของ Satoshi เต็มไปด้วยความเสี่ยง ทั้งการพึ่งพาโปรโตคอลแชทอย่าง IRC, การโอนเงินตรงผ่าน IP, หรือการผูกติดกับ OpenSSL และ Berkeley DB

แต่สิ่งที่ทำให้บิตคอยน์กลายเป็นโครงสร้างพื้นฐานทางการเงินที่มีมูลค่าระดับล้านล้านดอลลาร์ในปัจจุบัน คือ ความสามารถในการปรับตัวและเรียนรู้ผ่านบาดแผล (Anti-fragility) การที่นักพัฒนานับร้อยชีวิตตลอด 15 ปีที่ผ่านมาร่วมกันตัดเนื้อร้าย อุดช่องโหว่ ปลดระวางเครื่องมือเก่า และสร้างสรรค์มาตรฐานระดับสูงอย่าง libsecp256k1 และ Reproducible Guix Builds ขึ้นมา

การมองย้อนกลับไปดู bitcoin.exe ไบต์แรก จึงไม่ใช่การจับผิดความไร้เดียงสาในอดีต แต่เป็นการสดุดีจิตวิญญาณแห่งวิศวกรรม ที่เปลี่ยนโปรเจกต์ทดลองชิ้นเล็กๆ บน Windows XP ให้กลายเป็นระบบที่ไม่มีใครสามารถหยุดยั้งได้ในวันนี้

---

8. แหล่งข้อมูลอ้างอิงและเอกสารทางเทคนิค (Canonical References)

1. t4t5/bitcoin-0.1-rebuilt GitHub Repository: คลังข้อมูลซอร์สโค้ดและสคริปต์การทำ Reproducible Build ไบนารีต้นฉบับ
   https://github.com/t4t5/bitcoin-0.1-rebuilt
2. Satoshi Nakamoto Institute: บันทึกและคลังไฟล์ดาวน์โหลดประวัติศาสตร์ Bitcoin v0.1.0 RAR Archive
   https://nakamotoinstitute.org/bitcoin/
3. Bitcoin Core Release Notes & Architecture History: เอกสารการพัฒนาและบันทึกการเปลี่ยนแปลงสถาปัตยกรรม
   https://bitcoincore.org/en/releases/
4. NVD NIST - CVE-2010-5139: รายละเอียดช่องโหว่ Value Overflow Incident (184 พันล้าน BTC)
   https://nvd.nist.gov/vuln/detail/CVE-2010-5139
5. NVD NIST - CVE-2013-3220: รายละเอียดช่องโหว่ Berkeley DB Lock Limit Consensus Fork
   https://nvd.nist.gov/vuln/detail/CVE-2013-3220
6. libsecp256k1 Official Repository: เอนจินการคำนวณทางคณิตศาสตร์ Elliptic Curve สำหรับ Bitcoin
   https://github.com/bitcoin-core/secp256k1
7. Bitcoin Improvement Proposals (BIPs):
   • BIP 155: addrv2 message for P2P network
   • BIP 340: Schnorr Signatures for secp256k1
   • BIP 341: Taproot: SegWit version 1 spending rules