ทำไมใช้งาน Hardware Wallet ควรทำความเข้าใจเรื่อง BIP?

BIPs (Bitcoin Improvement Proposals) คืออะไร

BIPs (Bitcoin Improvement Proposals) คือมาตรฐานการเสนอการเปลี่ยนแปลงเพื่อให้ทุกคนและทุก Node ในเครือข่ายยอมรับร่วมกัน (Consensus), ในยุคแรกเริ่ม Bitcoin ใช้วิธีการสุ่มสร้างคู่ private key และ public key ขึ้นมาทีละคู่(เช่น paper wallet) โดยไม่สามารถนำข้อมูลเหล่านี้ไปต่อยอดเพื่อให้รองรับกับเทคโนโลยีใหม่ๆให้ผู้ใช้งานเข้าถึงได้สะดวกรวดเร็วจึงเป็นสาเหตุของการพัฒนา BIP, การศึกษาเรื่อง BIP คือการทำความเข้าใจ "วิวัฒนาการ" ของ Bitcoin ซึ่งในบทความนี้จะพาทุกท่านมาเข้าใจโครงสร้างแบบผิวเผิญ เพื่อช่วยให้ทุกท่านไม่หลงทางหากมีความสนใจและตัดสินใจจะศึกษาลงลึกในส่วนต่างๆของพื้นฐาน Bitcoin technology ต่อไป

หมวดการปกป้อง Private Key และ Seed

BIP-38 Passphrase-protected Private Key

ก่อนที่จะมีมาตรฐานนี้ หากคุณพิมพ์ Private Key(ที่ขึ้นต้นด้วย 5 หรือK/L) ลงบนกระดาษ แล้วใครก็ตามที่มาแอบเห็นกระดาษแผ่นนั้นหรือแอบถ่ายรูปไป เขาก็จะสามารถขโมยเงินคุณได้ทันที ซึ่ง BIP-38 เข้ามาแก้ปัญหานี้โดยการนำ Private Key มา "เข้ารหัส" (Encryption) ด้วยรหัสผ่านที่คุณตั้งขึ้น ผลลัพธ์ที่ได้จะเป็นข้อความชุดใหม่ที่ขึ้นต้นด้วย "6P..." เสมอ ซึ่งตัวมันเองไม่ใช่ Private Key ที่ใช้จ่ายเงินได้ทันที แต่ต้องมี "รหัสผ่าน" มาปลดล็อคก่อน

BIP-39 Mnemonic Code

ต่อยอดจากหลักการของ BIP-32, การแปลง Seed ที่เป็นตัวเลขฐานสิบหกที่จำยาก ให้กลายเป็น "12 หรือ 24 คำ" (Seed Phrase) ที่เราใช้กันในปัจจุบันช่วยให้จำหรือจดบันทึกง่ายขึ้น ซึ่งในส่วนนี้ผู้ใช้งานส่วนมากคุ้นกันดีอยู่แล้ว

BIP-32 Hierarchical Deterministic Wallets

การสร้างโครงสร้างกุญแจ จาก Seed ชุดเดียวสามารถแตกกิ่งก้านสาขาออกมาได้ไม่จำกัด โดยเราจะมีชุด Master key ที่เรียกว่า Root key

• นำ Root key ไปคำนวนผ่าน HMAC-SHA512 แล้วเราจะได้ Xprv กับ Chain code มา
• นำ Xprv ที่ได้มาไปคำนวนผ่าน Trapdoor function (secp256k1) แล้วเราจะได้ Xpub มา
• นำ Xpub, Chain code, Derivation path ไปคำนวนผ่าน HMAC-SHA512 แล้วเราจะได้คู่ privateกับpublic key ย่อยๆมา ซึ่งแต่ละคู่จะต่างกันที่ Derivation path เท่านั้น แต่ Xpub กับ Chain code ใช้เหมือนกันหมด

โครงสร้าง Derivation path คือ m / account(0) / address_index(i)(ขี้นต้นด้วยเลข1)

BIP43 The Purpose Pillar

เป็นหลักการที่ใช้ต่อยอดและควบคู่กับ BIP-32 โดยการนำชุดข้อมูลชุดเดียวมาแบ่งเป็นหลายๆเวอร์ชั่น, นี่คือต้นกำเนิดของหลักการใช้ Derivation path ซึ่งในทางเทคนิค BIP-43 เสนอให้ใช้ "Purpose" เป็นระดับแรก (Level 1) ของโครงสร้าง Path และเป็นรูปแบบ Hardened Derivation เสมอ เพื่อความปลอดภัยไม่ให้ Hacker เจาะ chain code ผ่าน Xpub key ได้ (โครงสร้างมาตรฐานที่ BIP-43 กำหนดคือ: m / purpose' / *)

หมวดมาตรฐาน Derivation Path สำหรับ Wallet

BIP-44 Legacy

เป็นการนำหลักการของ BIP-43 มาใช้ ถือว่าเป็น "มาตรฐานหลัก" ที่ทำให้กระเป๋าเงิน(Wallet) ทั่วโลกคุยกันรู้เรื่อง จะสร้าง address ชนิด Legacy ที่มีค่าธรรมเนียมแพงที่สุด ซึ่ง BIP-44 คือต้นกำเนิดที่วางรากฐาน "ทางเดินของกุญแจ" ให้กับมาตรฐานเหรียญคริปโตฯรุ่นหลังทั้งหมด และแทบทุกโปรเจ็กคริปโตในปัจจุบันก็ยังใช้มาตรฐานนี้อยู่ [ในรูปแบบนี้ address จะขึ้นต้นด้วยเลข1]โครงสร้าง Derivation path คือ m / 44’ / coin_type' / account' / change / address_index

BIP-49 Nested Segwit(P2SH-P2WPKH)

กลไกมันคือการเอา SegWit(BIP-141) ไปใส่ไว้ข้างใน P2SH(BIP-16) เพื่อให้เราสามารถใช้เทคโนโลยี SegWit(BIP-141) ได้ แม้ว่าผู้โอนหรือผู้รับเงินจะยังใช้กระเป๋าเงินรุ่นเก่าที่ไม่รู้จัก SegWit ก็ตาม [ในรูปแบบนี้ address จะขึ้นต้นด้วยเลข3]โครงสร้าง Derivation path คือ m / 49' / coin_type' / account' / change / address_index

BIP-84 Native SegWit (P2WSH)

เดิมที address ของ BIP-49 จะเป็นข้อความรูปแบบ Base58Check ซึ่งในเวอร์ชั่นนี้คือการใช้รูปแบบ address เป็น Bech32 ตามมาตรฐานของ BIP-173 เพื่อลดความผิดพลาดและเพิ่มความแม่นยำในการระบุ address [ในรูปแบบนี้ address จะขึ้นต้นด้วย bc1q]โครงสร้าง Derivation path คือ m / 84' / coin_type' / account' / change / address_index

BIP-86 Pay-to-Taproot (P2TR)

คือการนำเอาหลักการ BIP-340, 341, 342, 322 มาใช้งานจริง ผลลัพธ์ก็คือหน้าตาของธุรกรรมจะเหมือนกับธุรกรรมทั่วไปที่ไม่ได้มีความซับซ้อน เพราะ script ส่วนใหญ่จะถูกซ่อนแล้วเปิดเผยแค่บางส่วน [ในรูปแบบนี้ address จะขึ้นต้นด้วย bc1p]โครงสร้าง Derivation path คือ m / 86' / coin_type' / account' / change / address_index

หมวด Script, Multisig และ Smart Contract พื้นฐาน

BIP-13,16 Pay to Script Hash (P2SH)

คือหลักการที่สร้างขึ้นเพื่อรองรับธุรกรรมที่ซับซ้อนด้วยการใช้ “script” เช่นสร้าง Multisig wallet(ต้องเซ็นอนุมัติหลายคน) หรือสร้าง TimeLock transaction(ธุรกรรมแบบกำหนดเวลา) หากทุกท่านจะเข้าใจว่านี่คือ “smart contact” ในระบบ bitcoin ก็ไม่ผิด

BIP-45 P2SH Multisignature Wallets

เป็นมาตรฐานที่ถูกออกแบบมาเพื่อ "กระเป๋าเงินแบบหลายรายนาม(Multisig Wallets)” ในยุคแรกๆ เมื่อเรามีพื้นฐานการสร้าง script จาก BIP13,16 แล้ว เราก็จะสร้างรูปแบบ script นี้ให้เป็นการอนุมัติแบบหลายลายเซ็น เพื่อเพิ่มความปลอดภัยของเงินในกระเป๋าโครงสร้าง Derivation path คือ m / 45' / cosigner_index / change / address_index

BIP-48 Multi-Script Hierarchy

ต่อยอดจาก BIP-45 ด้วยการเพิ่ม script type เข้ามา จึงสามารถใช้ได้กับ address แบบ Nested Segwit(Base58) และแบบ Native Segwit(Bech32) ขึ้นอยู่กับ script typeโครงสร้าง Derivation path คือ m / 48' / coin_type' / account' / script_type' / change / address_indexNest Segwit คือ m / 48' / coin_type' / account' / 1' / change / address_indexNative Segwit คือ m / 48' / coin_type' / account' / 2' / change / address_index

หมวด SegWit, Transaction และ PSBT

BIP-141 Segregated Witness (SegWit)

ต่อยอดจาก BIP-13 และ16, คือการแยกส่วน "ลายเซ็น" (Witness) ออกจากข้อมูลธุรกรรมหลัก ทำให้บล็อกขนาด 1MB เดิมสามารถบรรจุธุรกรรมได้มากขึ้น (เสมือนขยายเป็น 4MB ในทางทฤษฎี) เพื่อแก้ปัญหา Transaction Malleability และช่วยให้ขยายขนาดเครือข่าย (Scaling) ได้ และยังเป็นรากฐานให้เกิด Lightning Networkโครงสร้าง Derivation path คือ m / account(0) / address_index(i)(ขึ้นต้นด้วยเลข3)

BIP-174 Partially Signed Bitcoin Transaction(PSBT)

PSBT คือ "ไฟล์มาตรฐาน" ที่ทำให้เราสามารถเซ็นธุรกรรมแบบออฟไลน์ หรือเซ็นร่วมกันหลายคนได้ โดยที่ทุกคนคุยภาษาเดียวกัน มันเป็นสิ่งที่ทำให้การใช้งาน Hardware Wallet และการทำธุรกรรมแบบ Multisig สะดวกและปลอดภัยขึ้นมหาศาล ลองนึกภาพว่าคุณต้องการสร้างธุรกรรมแบบที่ต้องให้คน 3 คนช่วยกันเซ็นชื่อ (Multisig) ในสมัยก่อน คุณต้องส่งไฟล์ธุรกรรมดิบที่ซับซ้อนไปมา ซึ่งเสี่ยงต่อความผิดพลาดและดูยากมาก เพราะงั้น BIP-174 จึงเข้ามาแก้ปัญหานี้โดยการสร้าง PSBT ที่ทำหน้าที่เป็น "แบบฟอร์ม" ที่บรรจุข้อมูลที่จำเป็นทั้งหมดเพื่อให้แต่ละฝ่ายเซ็นชื่อได้โดยไม่ต้องเชื่อมต่อกับ Blockchain โดยตรง

หมวด TimeLock และ Lightning Network

BIP-65 CHECKLOCKTIMEVERIFY (CLTV)

ต่อยอดจาก BIP-13และ16, เรามีสิ่งที่เรียกว่า nLockTime ซึ่งเป็นการล็อคที่ระดับ "ตัวธุรกรรม" (Transaction) คือต้องรอให้ถึงเวลาที่กำหนดก่อน ธุรกรรมนั้นถึงจะถูกส่งเข้าเครือข่ายได้ แต่ข้อเสียคือ ถ้าคุณเปลี่ยนใจ หรือทำกุญแจหายระหว่างนั้น มันจะจัดการยากมาก BIP-65 (CLTV) แก้ปัญหานี้โดยการ ย้ายการล็อคเวลาไปไว้ที่ "Script (เงื่อนไขการรับเงิน)" แทน หมายความว่า คุณสามารถส่ง Bitcoin ไปไว้ใน Address หนึ่งได้ทันที แต่เหรียญนั้นจะ "ขยับไม่ได้" จนกว่าเวลาจะไปถึงจุดที่ระบุไว้ใน Script

BIP-68 Relative Locktime

คือการนำ BIP-65 มาใช้จริงด้วยการระบุเวลาล่วงหน้าเป็นรูปแบบวันที่และเวลา หรือเป็น Block height ก็ได้

BIP-112 CSV - CheckSequenceVerify

ต่อเนื่องจาก BIP-65, ตัวนี้สำคัญมากสำหรับใช้ในการสร้าง Lightning Channel เพราะมันคือการล็อคเวลาแบบ "สัมพัทธ์" (Relative Timelock) เช่น บอกว่า "เงินนี้จะถอนได้หลังจากที่ธุรกรรมนี้ถูกบันทึกลงบล็อกไปแล้ว 1,000 บล็อก"

หมวด Address Format และ Encoding

BIP-173 (Bech32)

เดิมทีในระบบ Bitcoin จะมีการส่งข้อมูลกันในรูปแบบ Base58Check ซึ่งมีข้อเสียหลายอย่างที่นักพัฒนาอยากแก้ไข จึงเป็นเหตุให้พัฒนามาส่งข้อมูลกันในรูปแบบ Bech32

• การตรวจจับความผิดพลาด (Superior Error Detection)
• ไม่แยกตัวพิมพ์เล็ก-พิมพ์ใหญ่ (Case Insensitivity)
• QR code มีความหนาแน่นน้อยกว่า สามารถสแกนได้ง่ายและแม่นยำกว่า
• ประหยัดค่าธรรมเนียมกว่าแบบเดิม

หมวด Taproot และ Schnorr

BIP-340 Schnorr Signatures Scheme

ต่อยอดจาก BIP-13,16,และ173, ที่ก่อนหน้านี้ Bitcoin ใช้ลายเซ็นแบบ ECDSA (Native Segwit) แต่ BIP-340 นำ Schnorr Signatures มาใช้แทน ซึ่งมีคุณสมบัติที่เหนือกว่ามากด้วยการทำ Signature Aggregation คือการรวมข้อมูลลายเซ็น ทำให้ประหยัดพื้นที่ข้อมูล, ประหยัดค่าธรรมเนียม, คนนอกสอดส่องแล้วดูไม่ออกว่าเป็น Multisignature

BIP-341 Taproot

ต่อยอดจาก BIP-13,16,และ173, พัฒนาการส่งข้อความจากรูปแบบ Bech32 เป็น Bech32m, คือการนำโครงสร้างที่เรียกว่า MAST (Merklized Alternative Script Trees) และ Taproot Output มาใช้ ทำให้ซ่อนธุรกรรมที่มีข้อมูลซับซ้อนให้ดูเหมือนธุรกรรมธรรมดา ส่งผลให้ประหยัดพื้นที่และรักษาความลับของเงื่อนไขธุรกรรมได้ดีเยี่ยม ซึ่งใน Native Segwit ซ่อนไม่ได้

BIP-342 Tapscript

ต่อยอดจาก BIP-341และ342, เพื่อให้รองรับ Schnorr และ Taproot ระบบจำเป็นต้องอัปเดตภาษาฉบับปรับปรุงที่ใช้เขียนคำสั่ง (Script) ใหม่ เรียกว่า Tapscript, Op_codes เพิ่มคำสั่งใหม่ๆ เพื่อให้การตรวจสอบ Schnorr Signature ทำงานได้รวดเร็ว ความยืดหยุ่นของเทคโนโลยีนี้คือปลดล็อคข้อจำกัดเดิมๆ ของ Script ทำให้ในอนาคต Bitcoin สามารถอัปเกรดฟีเจอร์ใหม่ๆ ได้ง่ายขึ้นโดยไม่ต้องทำ Hard Fork

หมวด Message Signing และ Advanced Usage

BIP-322 Generic Signed Message

สิ่งที่สำคัญที่สุดในขั้นตอนสุดท้ายคือการ Sign transaction ซึ่งก่อนหน้านี้ Bitcoin มีวิธีการที่เรียกว่า "Legacy Message Signing" ซึ่งมักจะอยู่ในแอปกระเป๋าเงินทั่วไป ปัญหาคือ ไม่รองรับ Segwit และ Multisig แถมยังความปลอดภัยต่ำ BIP-322 นี้จึงเข้ามาแก้ปัญหานี้ ทำให้รองรับ address ได้ทุกประเภท ทั้ง Legacy, SegWit (P2SH), Native SegWit (Bech32), และ Taproot (Bech32m)

หมวดการจัดการ Seed ขั้นสูง

BIP-85 Deterministic Derivation of Keys across Wallets

เป็นการนำหลักการ BIP-32 มาใช้ ช่วยให้คุณเก็บรักษาแค่ Seed หลัก (Master Seed) ไว้เพียงชุดเดียวพอ แล้วสั่งให้มันคำนวณสร้าง Seed ชุดใหม่ (Child Seed) เพื่อเอาไปใส่ในแอปมือถือ แต่ก่อนถ้าคุณอยากใช้กระเป๋าหลายใบ คุณต้องเก็บจด Seed Phrase 12-24 คำแยกกันหลายชุด ซึ่งเสี่ยงต่อการหายหรือถูกขโมย เพราะงั้น Master Seed จะช่วยแก้ปัญหานี้โดยตรงโครงสร้าง Derivation path คือ m / 83696968' / setup_code' / index'สร้าง Seed 12-24 คำ m / 83696968' / 0' / index'สร้าง WIF Seed m / 83696968' / 1' / index'สร้างข้อความทั่วไป m / 83696968' / 2' / index'

หมายเหตุ

อาจจะยังมี BIPs บางส่วนที่ไม่ได้พูดถึงเช่น BIP-152,157,158,176 ซึ่งมันคือกลไกหลังบ้านที่ผู้ใช้งาน bitcoin สัมผัสมันอยู่ทุกวันแบบไม่รู้ตัว, และอาจจะยังมีบาง BIPs ที่ตกหล่นไปจากบทความนี้ ผู้อ่านสามารถคอมเม้นเสริมได้