จดหมายข่าว Bitcoin Optech ให้ข้อมูลสรุประดับสูงสุดแก่ผู้อ่านมากที่สุด ข่าวทางเทคนิคที่สำคัญที่เกิดขึ้นใน Bitcoin พร้อมด้วยแหล่งข้อมูลที่ช่วยให้พวกเขาเรียนรู้เพิ่มเติม เพื่อช่วยให้ผู้อ่านของเราได้รับข้อมูลล่าสุดเกี่ยวกับ Bitcoin เรากำลังเผยแพร่ฉบับล่าสุดของจดหมายข่าวด้านล่างนี้ อย่าลืมสมัครรับเนื้อหานี้ตรงไปยังกล่องจดหมายของคุณ
จดหมายข่าวประจำสัปดาห์นี้สรุปการสนทนาเกี่ยวกับ opcode ใหม่และลิงก์ไปยังหน้า wiki ที่อัปเดตเพื่อติดตามการสนับสนุน bech32m รวมทั้งยังมีส่วนปกติของเราที่มีไฮไลท์จากการประชุม Bitcoin Core PR Review Club คำแนะนำเกี่ยวกับการจัดเตรียม taproot และคำอธิบายเกี่ยวกับการเปลี่ยนแปลงที่โดดเด่นในโครงการโครงสร้างพื้นฐาน Bitcoin ยอดนิยม
News
- ขอข้อเสนอแนะการออกแบบ OP_CHECKSIGFROMSTACK: Jeremy Rubin โพสต์ไปยังรายชื่อผู้รับจดหมายของ Bitcoin-Dev ร่างข้อกำหนดสำหรับ OP_CHECKSIGFROMSTACK opcode และขอความคิดเห็นจากนักพัฒนาที่ต้องการการออกแบบทางเลือก มีการพูดคุยถึงทางเลือกอื่น แต่เธรดยังแยกออกเป็นการอภิปรายว่า OP_CAT opcode ควรได้รับการแนะนำในเวลาเดียวกัน
- OP_CAT และ OP_CSFS จะช่วยให้มีการพิจารณาธุรกรรมโดยพลการ—ความสามารถในการรับ bitcoins ไปยัง สคริปต์ที่สามารถตรวจสอบเกือบทุกส่วนของธุรกรรมที่ใช้ bitcoins เหล่านั้นในภายหลัง สิ่งนี้สามารถเปิดใช้งานคุณสมบัติขั้นสูงมากมาย (รวมถึงเวอร์ชัน1 ของการอัปเกรดอื่นๆ ที่เสนอ เช่น SIGHASH_ANYPREVOUT และ OP_CHECKTEMPLATEVERIFY) แต่ OP_CAT ยังทำให้สามารถสร้าง พันธสัญญา ซึ่งอาจจำกัดความสามารถในการใช้จ่ายของ bitcoin ใดๆ ที่ผูกมัดต่อพันธสัญญาอย่างถาวร บางคนมี ปฏิเสธที่จะอนุญาตพันธสัญญาใน Bitcoin แต่ อาร์กิวเมนต์คือ สร้างเพื่อให้เกิดปัญหากรณีที่เลวร้ายที่สุดของสัญญาแบบเรียกซ้ำใน Bitcoin ในวันนี้ ดังนั้นเราจึงไม่ควรกังวลเกี่ยวกับการเปิดใช้งาน OP_CAT หรือ opcode ที่คล้ายกัน
- ทั้งๆ การสนทนา Rubin ตัดสินใจว่าเขาต้องการให้ข้อเสนอ OP_CSFS เป็นอิสระจากข้อเสนอใดๆ เพื่อเพิ่ม OP_CAT, การโต้เถียงว่า OP_CSFS มีประโยชน์เพียงพอในตัวมันเอง
- การติดตามการรองรับ bech32m: หน้า Bitcoin Wiki สำหรับ การนำ bech32 เป็น อัปเดตเพื่อติดตามว่าซอฟต์แวร์และบริการใดสนับสนุนการใช้จ่ายหรือการรับใน bech32m ที่อยู่สำหรับ taproot
- Bitcoin Core PR Review Club
ในส่วนรายเดือนนี้ เรา สรุป Bitcoin Core PR Review Club เน้นคำถามและคำตอบที่สำคัญ คลิกที่คำถามด้านล่างเพื่อดูสรุปคำตอบจากการประชุม
ใช้ตัวช่วย script_util สำหรับการสร้างสคริปต์ P2{PKH,SH,WPKH,WSH} เป็น PR โดย Sebastian Falbesoner ซึ่งใช้แทนการสร้างสคริปต์ด้วยตนเองด้วยการเรียกใช้ฟังก์ชันตัวช่วย script_util ในการทดสอบการทำงานและแก้ไขข้อผิดพลาด ในฟังก์ชัน get_multisig() การประชุมชมรมทบทวนแจกแจงคำศัพท์และประเภทเอาต์พุตสคริปต์แต่ละประเภทที่ใช้ในการประชาสัมพันธ์ - key_to_p2pkh_script, script_to_p2sh_script, key_to_p2wpkh_scriptand script_to_p2wsh_script ใน script_util.py ทำอะไรได้บ้าง
เหล่านี้เป็นฟังก์ชันตัวช่วยในการสร้างออบเจ็กต์ CScript สำหรับ Pay to Public Key Hash, Pay to Script Hash, Pay to Witness Public Key Hash และ Pay to Witness Script Hash script จากกุญแจสาธารณะและสคริปต์ ➚ - กำหนด scriptPubKey, scriptSig และพยาน
scriptPubKey และ scriptSig เป็นฟิลด์ในเอาต์พุตและอินพุตของธุรกรรม ตามลำดับ เพื่อกำหนดและเป็นไปตามเงื่อนไขการใช้จ่าย พยานเป็นพื้นที่เพิ่มเติมสำหรับจุดประสงค์เดียวกันกับพยานที่แยกจากกัน ข้อกำหนดในการใช้จ่ายมีผลผูกพันใน scriptPubKey ของผลลัพธ์และการป้อนข้อมูลที่ใช้จะต้องมาพร้อมกับข้อมูลที่ตรงตามเงื่อนไขเหล่านั้นใน scriptSig และ/หรือพยาน ➚ - กำหนดสคริปต์การแลกและสคริปต์การเป็นพยาน ความสัมพันธ์ระหว่างพวกเขาคืออะไร
ประเภทเอาต์พุต P2SH และ P2WSH ผูกมัดกับแฮชสคริปต์ใน scriptPubKey เมื่อผลลัพธ์ถูกใช้ไป ผู้ใช้จ่ายต้องจัดเตรียมสคริปต์เอง พร้อมด้วยลายเซ็นหรือข้อมูลอื่น ๆ ที่จำเป็นเพื่อให้ผ่าน สคริปต์นี้เรียกว่าสคริปต์ไถ่ถอนเมื่ออยู่ในสคริปต์ซิกและสคริปต์พยานเมื่ออยู่ในพยาน ในแง่นั้น พวกเขามีความคล้ายคลึงกัน สคริปต์การแลกใช้คือเอาต์พุต P2SH สคริปต์พยานสำหรับเอาต์พุต P2WSH อย่างไรก็ตาม สิ่งเหล่านี้ไม่ได้แยกออกจากกัน เนื่องจากธุรกรรมที่ใช้เอาต์พุต P2SH-P2WSH มีทั้งสองอย่าง ➚ - ในการส่งเหรียญให้กับผู้ที่มีเงื่อนไขการใช้จ่ายที่เข้ารหัสในสคริปต์ สิ่งที่รวมอยู่ใน scriptPubKey ของผลลัพธ์คืออะไร สิ่งที่ต้องระบุในการป้อนข้อมูลเมื่อมีการใช้จ่ายเหรียญ
scriptPubKey มีแฮชของสคริปต์และ opcodes เพื่อตรวจสอบการจับคู่: OP_HASH160 OP_PUSHBYTES_20 <20B script hash> OP_EQUAL scriptSig ประกอบด้วยสคริปต์และสแต็กเริ่มต้น ➚ - เหตุใดเราจึงใช้ Pay-To-Script-Hash แทน Pay-To-Script
แรงจูงใจหลัก ตามที่ระบุไว้ใน BIP16 คือการสร้างวิธีการทั่วไปในการจัดหาเงินทุนสำหรับธุรกรรมที่ซับซ้อนโดยพลการ ในขณะที่วางภาระในการจัดหาเงื่อนไขการใช้จ่ายให้กับผู้ที่แลกเงิน ผู้เข้าร่วมยังกล่าวด้วยว่าการไม่นำสคริปต์ออกจาก scriptPubKeys หมายความว่าจะไม่มีการจ่ายค่าธรรมเนียมที่เกี่ยวข้องจนกว่าจะมีการแลกใช้และส่งผลให้ชุด UTXO มีขนาดเล็กลง ➚ - เมื่อโหนดที่ไม่ใช่ Segwit ตรวจสอบอินพุต P2SH-P2WSH จะทำอย่างไร โหนดที่เปิดใช้งาน Segwit ทำอะไรนอกเหนือจากขั้นตอนที่ดำเนินการโดยโหนดที่ไม่ใช่ Segwit
โหนดที่ไม่ใช่ Segwit จะไม่เห็นพยาน มันเพียงบังคับใช้กฎ P2SH โดยตรวจสอบว่าการแลกสคริปต์ตรงกับแฮชที่คอมมิตใน scriptPubKey โหนด Segwit รับรู้ข้อมูลนี้เป็นโปรแกรมพยาน และใช้ข้อมูลพยานและ scriptCode ที่เหมาะสมเพื่อบังคับใช้กฎ Segwit ➚ - เกิดอะไรขึ้นกับสคริปต์ P2SH-P2WSH ใน get_multisig() function?
มันใช้สคริปต์พยานแทนแฮชในสคริปต์แลก P2SH-P2WSH ➚ - การเตรียมพร้อมสำหรับ taproot #4: จาก P2WPKH เป็น single-sig P2TR
A รายสัปดาห์ ซีรีส์เกี่ยวกับวิธีที่นักพัฒนาและผู้ให้บริการสามารถเตรียมพร้อมสำหรับการเปิดใช้งาน taproot ที่กำลังจะเกิดขึ้นที่ความสูงของบล็อก 709,632
สำหรับกระเป๋าเงินที่รองรับการรับและการใช้จ่าย v0 segwit แล้ว เอาต์พุต P2WPKH การอัปเกรดเป็น v1 segwit P2TR สำหรับ single-sig น่าจะเป็นเรื่องง่าย นี่คือขั้นตอนหลัก: - ใช้เส้นทางการรับคีย์ BIP32 ใหม่: คุณไม่จำเป็นต้องเปลี่ยน BIP32 รหัสกำหนดลำดับชั้น (HD) และผู้ใช้ของคุณไม่จำเป็นต้องเปลี่ยนเมล็ดพันธุ์2 อย่างไรก็ตาม ขอแนะนำให้ใช้เส้นทางที่มาใหม่สำหรับคีย์สาธารณะ P2TR ของคุณ (เช่น กำหนดโดย BIP86); ถ้าคุณไม่ทำเช่นนี้ มี การโจมตีที่เป็นไปได้ที่อาจเกิดขึ้นได้หากคุณใช้คีย์เดียวกันกับทั้ง ECDSA และ schnorr signatures.
- ปรับแต่งคีย์สาธารณะของคุณด้วยแฮชของมัน: แม้ว่าในทางเทคนิคจะไม่จำเป็นสำหรับ single-sig โดยเฉพาะอย่างยิ่งเมื่อคีย์ทั้งหมดของคุณมาจาก BIP32 ที่เลือกแบบสุ่ม เมล็ดพันธุ์ BIP341 แนะนำให้คีย์ของคุณคอมมิตกับโครงสร้าง scripthash ที่ใช้ไม่ได้ ซึ่งทำได้ง่ายๆ เพียงใช้การดำเนินการเพิ่ม Elliptic Curve ที่รวมคีย์สาธารณะของคุณด้วยจุดโค้งของแฮชของคีย์นั้น ข้อดีของการปฏิบัติตามคำแนะนำนี้คือ คุณจะสามารถใช้รหัสเดียวกันได้หากคุณเพิ่ม รองรับหลายลายเซ็น หรือหากคุณเพิ่มการรองรับสำหรับ tr() descriptors.
- สร้างที่อยู่และตรวจสอบที่อยู่: ใช้ bech32m เพื่อสร้างที่อยู่ของคุณ การชำระเงินจะถูกส่งไปยัง scriptPubKey OP_1
คุณสามารถสแกนหาธุรกรรมที่จ่ายสคริปต์โดยใช้วิธีใดก็ตามที่คุณใช้สแกนหาที่อยู่ segwit v0 เช่น P2WPKH - การสร้างธุรกรรมการใช้จ่าย: ช่องที่ไม่ใช่พยานสำหรับ taproot จะเหมือนกับ P2WPKH ดังนั้น คุณไม่จำเป็นต้องกังวลเกี่ยวกับการเปลี่ยนแปลงในการทำให้เป็นอนุกรมของธุรกรรม
- สร้างข้อความลายเซ็น: นี่เป็นข้อผูกมัดต่อข้อมูลจากธุรกรรมการใช้จ่าย ข้อมูลส่วนใหญ่เหมือนกับสิ่งที่คุณลงนามในธุรกรรม P2WPKH แต่ลำดับของฟิลด์คือ เปลี่ยนแปลงและมีการลงนามเพิ่มเติมบางอย่าง การดำเนินการนี้เป็นเพียงเรื่องของการทำให้เป็นอนุกรมและแฮชข้อมูลต่างๆ ดังนั้นการเขียนโค้ดจึงควรเป็นเรื่องง่าย
- ลงนามในแฮชของข้อความลายเซ็น: มีวิธีต่างๆ ในการสร้างลายเซ็น schnorr สิ่งที่ดีที่สุดไม่ใช่การ”ม้วน crypto ของคุณเอง”แต่ให้ใช้ฟังก์ชันจากห้องสมุดที่ได้รับการตรวจสอบอย่างดีที่คุณไว้วางใจ แต่ถ้าคุณทำไม่ได้ด้วยเหตุผลบางอย่าง BIP340 มีอัลกอริธึมที่ควรจะใช้งานได้ง่าย หากคุณมีพื้นฐานสำหรับการสร้างลายเซ็น ECDSA แล้ว เมื่อคุณมีลายเซ็นของคุณแล้ว ให้ใส่ลงในข้อมูลพยานที่คุณป้อนและส่งธุรกรรมการใช้จ่ายของคุณ
- แม้ก่อนที่ taproot จะเปิดใช้งานที่บล็อก 709,632 คุณสามารถทดสอบรหัสของคุณโดยใช้ testnet สาธารณะ ค่าเริ่มต้น signet หรือโหมดลงทะเบียนส่วนตัวของ Bitcoin Core หากคุณเพิ่มการสนับสนุน taproot ให้กับกระเป๋าเงินโอเพ่นซอร์สของคุณ เราขอแนะนำให้คุณเพิ่มลิงก์ไปยัง PR ที่ใช้งานบน taproot ใช้ และ หน้าการยอมรับ bech32m ของ Bitcoin Wiki เพื่อให้นักพัฒนาคนอื่นๆ สามารถเรียนรู้จากโค้ดของคุณ
เผยแพร่และเผยแพร่ผู้สมัคร
รุ่นใหม่และเปิดตัวผู้สมัครสำหรับโครงการโครงสร้างพื้นฐาน Bitcoin ยอดนิยม โปรดพิจารณาอัปเกรดเป็นรุ่นใหม่หรือช่วยทดสอบผู้สมัครรุ่น - LND 0.13.1-beta.rc2 เป็นรุ่นบำรุงรักษาที่มีการปรับปรุงเล็กน้อยและแก้ไขข้อบกพร่องสำหรับฟีเจอร์ที่เปิดตัวใน 0.13.0-beta
การเปลี่ยนแปลงที่สำคัญและเอกสารประกอบ
- การเปลี่ยนแปลงที่สำคัญในสัปดาห์นี้ใน Bitcoin Core, C-Lightning, Eclair, LND, Rust-Lighting, libsecp256k1, อินเทอร์เฟซกระเป๋าสตางค์ของฮาร์ดแวร์ (HWI), สนิม Bitcoin, เซิร์ฟเวอร์ BTCPay, ข้อเสนอการปรับปรุง Bitcoin (BIP) และ สายฟ้า
- C-Lightning #4625 อัปเดต ข้อเสนอ LN เพื่อให้ตรงกับ การเปลี่ยนแปลงข้อกำหนด โดยเฉพาะอย่างยิ่ง ข้อเสนอไม่จำเป็นต้องมีลายเซ็นอีกต่อไป ซึ่งจะทำให้สตริงที่เข้ารหัสสำหรับข้อเสนอสั้นลงอย่างมาก ปรับปรุงการจดจำโค้ด QR ได้
- Eclair #1746 เพิ่มการรองรับการจำลองข้อมูลไปยังฐานข้อมูล PostsgreSQL ควบคู่ไปกับฐานข้อมูล SQLite หลัก คุณลักษณะนี้มีขึ้นเพื่ออำนวยความสะดวกในการทดสอบเซิร์ฟเวอร์ที่ต้องการเปลี่ยนแบ็กเอนด์ในท้ายที่สุด ปีที่แล้ว Roman Taranchenko วิศวกรของ Suredbits อธิบายการปรับแต่ง Eclair สำหรับใช้ในองค์กรด้วยแบ็กเอนด์ PostgreSQL ใน Optech รายงานภาคสนาม
- LND #5447 เพิ่ม เอกสารที่อธิบายวิธีตั้งค่าโหนด LND หลายโหนดในคลัสเตอร์ที่มีฐานข้อมูลสำรองซึ่งจำลองแบบระหว่างโหนดของคลัสเตอร์และอนุญาตให้เฟลโอเวอร์โดยอัตโนมัติ ผู้อ่านที่สนใจอาจต้องการเปรียบเทียบสิ่งนี้กับแนวทางของ Eclair และอธิบายไว้ใน จดหมายข่าว #128.
- Libsecp256k1 #844 ทำการอัปเดตหลายรายการใน API สำหรับ ลายเซ็น schnorr ที่โดดเด่นที่สุดคือตกลงที่อนุญาตให้เซ็นชื่อและยืนยันข้อความในความยาวเท่าใดก็ได้ การใช้ลายเซ็นในปัจจุบันทั้งหมดใน Bitcoin จะลงนามในแฮชขนาด 32 ไบต์ แต่การอนุญาตให้ลงชื่อข้อมูลที่มีความยาวผันแปรอาจมีประโยชน์สำหรับแอปพลิเคชันภายนอก Bitcoin หรือเพื่อเปิดใช้งาน opcode ใหม่ เช่น OP_CHECKSIGFROMSTACK ไปยัง ยืนยันลายเซ็นที่สร้างขึ้นสำหรับระบบที่ไม่ใช่ Bitcoin คาดว่า BIP340 ข้อมูลจำเพาะของลายเซ็น schnorr สำหรับ Bitcoin จะได้รับการอัปเดตเพื่ออธิบายการลงนามข้อมูลความยาวผันแปรได้อย่างปลอดภัย
- BIPs #943 อัปเดต BIP118 เพื่อสร้าง taproot และ tapscript ที่เปิดใช้งานเร็วๆ นี้ แทนที่จะเป็น SegWit v0 นอกจากนี้ การแก้ไขนี้ยังเปลี่ยนชื่อเป็น SIGHASH_ANYPREVOUT จาก SIGHASH_NOINPUT เพื่อแสดงว่าขณะนี้มีการอ้างถึงการตั้งค่าสถานะ sighash เป็น “ANYPREVOUT” เนื่องจากแม้ว่า prevout ใดๆ อาจใช้กับลายเซ็นได้ แต่บางแง่มุมของข้อมูลที่ป้อนก็ยังคงถูกผูกมัด
- เซิร์ฟเวอร์ BTCPay #2655 ส่งสัญญาณไปยังเว็บเบราว์เซอร์ว่าพวกเขาไม่ควรส่งช่องอ้างอิง HTTP เมื่อผู้ใช้คลิกลิงก์ไปยังธุรกรรมใน ตัวสำรวจบล็อก เพื่อหลีกเลี่ยงไม่ให้ผู้สำรวจบล็อกทราบว่าผู้ใช้มาจากเซิร์ฟเวอร์ BTCPay ใด ข้อมูลดังกล่าวเป็นหลักฐานที่ชัดเจนว่าเซิร์ฟเวอร์มีต้นกำเนิดหรือได้รับธุรกรรมที่กำลังดูอยู่ในเครื่องมือสำรวจบล็อก แม้จะมีการเปลี่ยนแปลงนี้ ผู้ใช้ที่ต้องการความเป็นส่วนตัวอย่างเข้มงวดควรหลีกเลี่ยงการค้นหาธุรกรรมของตนเองในเครื่องมือสำรวจการบล็อกบุคคลที่สาม
- เชิงอรรถ
- การใช้ OP_CHECKSIGFROMSTACK (OP_CSFS) เพื่อใช้คุณสมบัติหลักของข้อเสนอ เช่น BIP118 SIGHASH_ANYPREVOUT หรือ BIP119 OP_CHECKTEMPLATEVERIFY จะต้องมีพื้นที่บล็อกมากกว่าข้อเสนอที่ปรับให้เหมาะสมหากใช้การใช้จ่ายของสคริปต์พาธ อาร์กิวเมนต์ที่สนับสนุน OP_CSFS คืออนุญาตให้เริ่มต้นด้วยการสร้างทั่วไปและพิสูจน์ว่าผู้คนจะใช้คุณลักษณะนี้จริงก่อนที่จะใช้การเปลี่ยนแปลงที่เป็นเอกฉันท์เพื่อเพิ่มการใช้งานที่มีประสิทธิภาพมากขึ้น นอกจากนี้ ด้วยการเปิดตัว taproot ใช้คีย์พาธ สคริปต์ใดๆ สามารถแก้ไขได้ด้วยการใช้พื้นที่บล็อกน้อยที่สุดในบางสถานการณ์ ซึ่งอาจช่วยลดความจำเป็นในการสร้างเฉพาะที่ช่วยประหยัดพื้นที่ในสถานการณ์ที่ไม่เหมาะสม ↩
- เมื่อ Electrum อัปเกรดเป็น segwit v0 ใครก็ตามที่ต้องการรับที่อยู่ bech32 จะต้องสร้างเมล็ดพันธุ์ใหม่ ไม่จำเป็นในทางเทคนิค แต่อนุญาตให้ผู้เขียน Electrum แนะนำ คุณลักษณะในวิธีการได้มาซึ่งเมล็ดพันธุ์ที่กำหนดเอง หนึ่งในคุณสมบัติเหล่านั้นคือความสามารถสำหรับหมายเลขเวอร์ชันของเมล็ดพันธุ์เพื่อระบุว่าสคริปต์ใดที่ควรจะใช้กับเมล็ดพันธุ์ ซึ่งช่วยให้เลิกใช้งานสคริปต์เก่าได้อย่างปลอดภัย (เช่น อาจมีการเปิดตัว Electrum เวอร์ชันในอนาคตที่ไม่รองรับการรับที่อยู่ P2PKH แบบเดิมอีกต่อไป)
ในช่วงเวลาเดียวกันนักพัฒนาซอฟต์แวร์ Electrum ได้ปรับใช้ Seed ที่มีเวอร์ชันของตน นักพัฒนา Bitcoin Core ก็ได้เริ่มต้นขึ้น โดยใช้ ตัวอธิบายสคริปต์เอาต์พุตเพื่อแก้ปัญหาเดียวกันในการอนุญาตการเลิกใช้งานสคริปต์ (นอกเหนือจากการแก้ปัญหาอื่นๆ) ตารางต่อไปนี้เปรียบเทียบ seeded รุ่นต่างๆ ของ Electrum และตัวอธิบายของ Bitcoin Core กับวิธีสคริปต์โดยปริยายที่เคยใช้โดย wallet ทั้งสองและยังคงใช้กันทั่วไปใน wallet อื่นๆ ส่วนใหญ่
ค้นหา โพสต์ต้นฉบับที่นี่
โปรด สมัครรับจดหมายข่าว Bitcoin Optech โดยตรงเพื่อรับเนื้อหานี้ตรงไปยังกล่องจดหมายของคุณทุกเดือน
