จดหมายข่าว Bitcoin Optech ให้ข้อมูลสรุประดับสูงสุดแก่ผู้อ่านมากที่สุด ข่าวทางเทคนิคที่สำคัญที่เกิดขึ้นใน Bitcoin พร้อมด้วยแหล่งข้อมูลที่ช่วยให้พวกเขาเรียนรู้เพิ่มเติม เพื่อช่วยให้ผู้อ่านของเราได้รับข้อมูลล่าสุดเกี่ยวกับ Bitcoin เรากำลังเผยแพร่ฉบับล่าสุดของจดหมายข่าวด้านล่างนี้ อย่าลืมสมัครรับเนื้อหานี้ตรงไปยังกล่องจดหมายของคุณ
จดหมายข่าวของสัปดาห์นี้สรุป BIP ที่เสนอสองรายการที่เกี่ยวข้องกับการสนับสนุนกระเป๋าเงินสำหรับ taproot และรวมถึงส่วนปกติของเราที่อธิบายคำถามและคำตอบที่เลือกใน Bitcoin Stack การแลกเปลี่ยน วิธีเตรียมตัวสำหรับ taproot และการเปลี่ยนแปลงที่โดดเด่นของโครงการโครงสร้างพื้นฐาน Bitcoin ยอดนิยม
ข่าวสาร
- ส่วนขยาย PSBT สำหรับ taproot: Andrew Chow โพสต์ เสนอ BIP ไปยังรายชื่อผู้รับจดหมายของ Bitcoin-Dev ที่กำหนดช่องใหม่สำหรับ PSBT เพื่อใช้เมื่อใช้จ่ายหรือสร้างผลลัพธ์ taproot ฟิลด์ขยายทั้ง PSBT เวอร์ชันดั้งเดิม 0 และ PSBT เวอร์ชัน 2 ที่เสนอ (ดู จดหมายข่าว #128) รองรับทั้งการใช้คีย์พาธและสคริปต์พาธ
BIP ที่เสนอยังแนะนำว่าอินพุต P2TR ใน PSBT สามารถละเว้นสำเนาของธุรกรรมก่อนหน้าได้ เนื่องจาก taproot แก้ไขการโจมตีค่าธรรมเนียมที่มากเกินไปสำหรับอินพุต segwit ของ v0 (ดู จดหมายข่าว #101) - เส้นทางที่มาของคีย์สำหรับ single-sig P2TR: Andrew Chow โพสต์ วินาที เสนอ BIP ไปยังรายชื่อผู้รับจดหมายของ Bitcoin-Dev ซึ่งแนะนำ BIP32 เส้นทางที่มาเพื่อใช้สำหรับกระเป๋าเงินที่สร้างที่อยู่ taproot ซิกเดียว Chow ตั้งข้อสังเกตว่า BIP นั้นคล้ายกับ BIP49 สำหรับที่อยู่ P2WPKH ที่หุ้มด้วย P2SH และ BIP84 สำหรับที่อยู่ P2WPKH ดั้งเดิม
เลือกถาม & ตอบจาก Bitcoin Stack Exchange
Bitcoin Stack Exchange เป็นหนึ่งในสถานที่แรกๆ ที่ผู้มีส่วนร่วมของ Optech ค้นหาคำตอบสำหรับคำถามของพวกเขา—หรือเมื่อเรามีเวลาว่างเล็กน้อยเพื่อช่วยให้สงสัยหรือ ผู้ใช้สับสน ในฟีเจอร์รายเดือนนี้ เราเน้นคำถามและคำตอบที่ได้รับคะแนนสูงสุดตั้งแต่อัปเดตครั้งล่าสุด
การเตรียมพร้อมสำหรับ taproot #2: taproot คุ้มกับ single-sig หรือไม่
ซีรีส์รายสัปดาห์เกี่ยวกับวิธีที่นักพัฒนาและผู้ให้บริการสามารถเตรียมพร้อมสำหรับการเปิดใช้งาน taproot ที่กำลังจะเกิดขึ้นที่ความสูงของบล็อก 709,632
การใช้ เครื่องคำนวณขนาดธุรกรรม เราสามารถเปรียบเทียบขนาดของธุรกรรม single-sig ประเภทต่างๆ ตามที่คาดไว้ ธุรกรรมที่ใช้อินพุตและเอาต์พุต P2WPKH นั้นเล็กกว่าธุรกรรมที่ใช้อินพุตและเอาต์พุต P2PKH มาก แต่อาจน่าแปลกใจที่ธุรกรรม P2TR นั้นใหญ่กว่าธุรกรรม P2WPKH ที่เทียบเท่ากันเล็กน้อย
| P2PKH (ดั้งเดิม) | P2WPKH (segwit v0) | P2TR (taproot/segwit v1) | |
|---|---|---|---|
|
ผลลัพธ์ |
34 |
31 |
43 |
|
อินพุต |
148 |
68 |
57.5 |
|
2-in, 2-out tx |
374 |
208.5 |
211.5 |
นั่นอาจทำให้ดูเหมือน การต่อต้านสำหรับ single-sig wallets ในการใช้จ่าย taproot เพื่อเตรียมพร้อมสำหรับบล็อก 709,632 แต่การมองอย่างใกล้ชิดพบว่ามีข้อดีหลายประการในการใช้ P2TR สำหรับ single-sig ทั้งสำหรับผู้ใช้กระเป๋าเงินและสำหรับเครือข่ายโดยรวม
- ใช้จ่ายถูกกว่า: มีค่าใช้จ่ายน้อยลงประมาณ 15% ที่ระดับอินพุตเพื่อใช้ P2TR UTXO แบบซิกเดียว เมื่อเทียบกับการใช้ P2WPKH UTXO การวิเคราะห์ที่ง่ายเกินไป เช่น ตารางด้านบนจะซ่อนรายละเอียดที่ผู้ใช้จ่ายไม่สามารถเลือกที่อยู่ที่ต้องการจ่ายได้ ดังนั้นหากคุณใช้ P2WPKH และคนอื่นๆ อัปเกรดเป็น P2TR ขนาดปกติของ 2-in-ธุรกรรมแบบ 2 ออกจะเป็น 232.5 vbytes ในขณะที่ธุรกรรม P2TR ทั้งหมดจะยังคงเป็น 211.5 vbytes เท่านั้น
- ความเป็นส่วนตัว: แม้ว่าความเป็นส่วนตัวบางส่วนจะสูญหายไปเมื่อผู้ใช้ในช่วงแรกเปลี่ยนรูปแบบสคริปต์ใหม่ ผู้ใช้เปลี่ยนไปใช้ taproot ด้วย รับความเป็นส่วนตัวเพิ่มขึ้นทันที ธุรกรรมของคุณจะดูแยกไม่ออกจากคนที่ทำงานในช่องทาง LN ใหม่และมีประสิทธิภาพมากขึ้น DLC รักษาความปลอดภัย multisignatures แผนการกู้คืนการสำรองข้อมูล wallet ที่ชาญฉลาดต่างๆ หรือการพัฒนาผู้บุกเบิกอื่นๆ อีกหลายร้อยรายการ
การใช้ P2TR สำหรับ single-sig ตอนนี้ยังทำให้ wallet ของคุณอัปเกรดเป็น multisignature, tapscripts, LN support, หรือคุณลักษณะอื่นๆ ในภายหลังโดยไม่กระทบต่อความเป็นส่วนตัวของผู้ใช้ปัจจุบันของคุณ ไม่สำคัญว่าจะได้รับ UTXO เวอร์ชันเก่าหรือซอฟต์แวร์เวอร์ชันใหม่ โดย UTXO ทั้งสองจะมีลักษณะเหมือน onchain เดียวกัน - สะดวกกว่าสำหรับอุปกรณ์เซ็นชื่อด้วยฮาร์ดแวร์: นับตั้งแต่การค้นพบ ค่าธรรมเนียมการโจมตีเกิน อุปกรณ์ลงนามด้วยฮาร์ดแวร์หลายเครื่องปฏิเสธที่จะลงนามในธุรกรรม เว้นแต่ UTXO แต่ละรายการที่ใช้ในธุรกรรมนั้นจะมาพร้อมกับข้อมูลเมตาที่มีสำเนาของส่วนสำคัญของธุรกรรมทั้งหมดซึ่งสร้าง UTXO นั้น สิ่งนี้จะเพิ่มการประมวลผลในกรณีที่แย่ที่สุดที่ผู้เซ็นชื่อฮาร์ดแวร์จำเป็นต้องดำเนินการอย่างมาก และเป็นปัญหาโดยเฉพาะสำหรับผู้เซ็นชื่อฮาร์ดแวร์ที่ใช้รหัส QR ขนาดจำกัดเป็นสื่อกลางในการสื่อสารหลัก Taproot ขจัดช่องโหว่ที่อยู่เบื้องหลังการโจมตีของค่าธรรมเนียมที่มากเกินไป จึงสามารถปรับปรุงประสิทธิภาพของผู้ลงนามฮาร์ดแวร์ได้อย่างมาก
- feerates ที่คาดเดาได้มากขึ้น: ลายเซ็น ECDSA สำหรับ P2PKH และ P2WPKH UTXO อาจมีขนาดแตกต่างกันไป (ดู จดหมายข่าว #3). เนื่องจากกระเป๋าเงินจำเป็นต้องเลือกอัตราค่าธรรมเนียมของธุรกรรมก่อนที่จะสร้างลายเซ็น กระเป๋าเงินส่วนใหญ่จะใช้ขนาดลายเซ็นที่แย่ที่สุดและยอมรับว่าพวกเขาจะจ่ายค่าธรรมเนียมมากเกินไปเล็กน้อยเมื่อมีการสร้างลายเซ็นที่มีขนาดเล็กลง สำหรับ P2TR จะทราบขนาดที่แน่นอนของลายเซ็นล่วงหน้า ทำให้กระเป๋าเงินสามารถเลือกอัตราค่าธรรมเนียมที่แม่นยำได้อย่างน่าเชื่อถือ
- ช่วยเหลือโหนดทั้งหมด: ความปลอดภัยโดยรวมของระบบ Bitcoin ขึ้นอยู่กับเปอร์เซ็นต์ของผู้ใช้ Bitcoin ที่มีนัยสำคัญ ตรวจสอบทุกธุรกรรมที่ได้รับการยืนยันด้วยโหนดของตนเอง ซึ่งรวมถึงการตรวจสอบธุรกรรมที่กระเป๋าเงินของคุณสร้างขึ้น ลายเซ็น schnorr สามารถตรวจสอบเป็นกลุ่มได้อย่างมีประสิทธิภาพ ลดจำนวนโหนดรอบ CPU ลงประมาณ 1/2 เมื่อตรวจสอบลายเซ็นระหว่างกระบวนการติดตามบล็อกก่อนหน้า แม้ว่าคุณจะปฏิเสธทุกประเด็นในรายการนี้ ให้พิจารณาเตรียมใช้ taproot เพื่อประโยชน์ของผู้ที่ใช้งานโหนดแบบเต็ม
การเปลี่ยนแปลงโค้ดและเอกสารสำคัญๆ
การเปลี่ยนแปลงที่โดดเด่นในสัปดาห์นี้ใน Bitcoin Core, C-Lightning, Eclair, LND, สนิม-สายฟ้า, libsecp256k1, อินเทอร์เฟซกระเป๋าสตางค์ของฮาร์ดแวร์ (HWI), สนิม Bitcoin, เซิร์ฟเวอร์ BTCPay, ข้อเสนอการปรับปรุง Bitcoin (BIP) และ สายฟ้า
- Bitcoin Core #22154 เพิ่มโค้ดที่อนุญาตให้ผู้ใช้สร้าง bech32m สำหรับสคริปต์ P2TR หลังจากเปิดใช้งาน taproot ในบล็อก 709,632 เช่น โดยโทรไปที่ getnewaddress””bech32m. หากธุรกรรมมีที่อยู่ bech32m หลังการเปิดใช้งาน taproot กระเป๋าเงิน descriptor จะใช้เอาต์พุตการเปลี่ยนแปลง P2TR ด้วย คุณลักษณะนี้ใช้กับกระเป๋าเงินที่มีคำอธิบาย taproot เท่านั้น (ดู จดหมายข่าว #152)
- Bitcoin Core #22166 เพิ่มการรองรับการอนุมาน taproot tr() descriptors จากเอาต์พุต ทำให้รองรับ taproot descriptor พื้นฐานได้สำเร็จ การอนุมานตัวอธิบายใช้เพื่อให้ข้อมูลที่ถูกต้องมากขึ้นในการตอบสนองต่อการเรียก RPC เช่น listunspent
- Bitcoin Core #20966 เปลี่ยนชื่อและรูปแบบของไฟล์ banlist ที่บันทึกไว้จาก banlist.dat (ตามข้อความแอดเดอร์โปรโตคอล P2P ที่ต่อเนื่องกัน) เป็น banlist.json การอัปเดตรูปแบบไฟล์ทำให้รายการใหม่สามารถจัดเก็บรายการห้ามสำหรับเพียร์บน Tor v3 และเพียร์บนเครือข่ายอื่นที่มีที่อยู่กว้างกว่า 128 บิต ซึ่งเป็นความกว้างสูงสุดที่ข้อความ addr ดั้งเดิมสามารถมีได้
- Bitcoin Core #21056 เพิ่มพารามิเตอร์-rpcwaittimeout ใหม่ให้กับ bitcoin-cli พารามิเตอร์-rpcwait ที่มีอยู่จะทำให้การส่งคำสั่งล่าช้า (การโทร RPC) จนกว่าเซิร์ฟเวอร์ bitcoind จะเริ่มทำงาน พารามิเตอร์ใหม่จะหยุดการรอหลังจากจำนวนวินาทีที่ระบุ ทำให้เกิดข้อผิดพลาด
- C-Lightning #4606 อนุญาตให้สร้างใบแจ้งหนี้มากกว่า 0.043 BTC หลังจากการเปลี่ยนแปลงที่คล้ายกันใน LND (ดู Newsletter #93) และการเปลี่ยนแปลงข้อกำหนดที่อธิบายไว้ในตอนต่อไป รายการ
- BOLT #877 ลบขีดจำกัดจำนวนเงินต่อการชำระเงินระดับโปรโตคอลที่เริ่มนำมาใช้เพื่อหลีกเลี่ยงความสูญเสียที่สำคัญที่เกิดจากข้อบกพร่องในการใช้งาน สิ่งนี้เกิดขึ้นหลังจากการใช้งาน option_support_large_channel อย่างแพร่หลายในปี 2020 ซึ่ง (เมื่อเปิดใช้งาน) ได้ลบขีดจำกัดจำนวนต่อช่อง ดูหัวข้อใน ช่องขนาดใหญ่สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับข้อจำกัดทั้งสองนี้
ค้นหา โพสต์ต้นฉบับที่นี่
โปรด สมัครรับจดหมายข่าว Bitcoin Optech โดยตรงเพื่อรับเนื้อหานี้ตรงไปยังกล่องจดหมายของคุณทุกเดือน
