วันที่ 30 พฤษภาคม 2025
จดหมายข่าวฉบับนี้สรุปการอภิปรายเกี่ยวกับผลกระทบที่อาจเกิดขึ้นต่อความเป็นส่วนตัวของเครือข่าย Lightning Network (LN) หากมีการนำระบบ “ความล้มเหลวที่สามารถระบุได้” (attributable failures) มาใช้ นอกจากนี้ยังมีส่วนปกติที่รวมถึงคำถามและคำตอบที่คัดสรรมาจาก Bitcoin Stack Exchange การประกาศเวอร์ชันใหม่และเวอร์ชันทดลองของซอฟต์แวร์ และคำอธิบายเกี่ยวกับการเปลี่ยนแปลงล่าสุดในซอฟต์แวร์โครงสร้างพื้นฐานของ Bitcoin ที่ได้รับความนิยม 
ข่าวสาร
● ความล้มเหลวที่สามารถระบุได้ลดความเป็นส่วนตัวของ LN หรือไม่?
Carla Kirk-Cohen ได้โพสต์การวิเคราะห์ใน Delving Bitcoin เกี่ยวกับผลกระทบที่อาจเกิดขึ้นต่อความเป็นส่วนตัวของผู้ใช้ LN หากเครือข่ายนำระบบ “ความล้มเหลวที่สามารถระบุได้” มาใช้ โดยเฉพาะอย่างยิ่งการแจ้งผู้ส่งเกี่ยวกับระยะเวลาที่ใช้ในการส่งต่อการชำระเงินในแต่ละขั้นตอน 
โดยอ้างถึงเอกสารหลายฉบับ เธออธิบายการโจมตีที่สามารถเปิดเผยตัวตนได้สองประเภท:
• ผู้โจมตีที่ดำเนินการโหนดส่งต่อหนึ่งหรือหลายโหนดใช้ข้อมูลเวลาเพื่อกำหนดจำนวนขั้นตอนที่ใช้ในการชำระเงิน (HTLC) ซึ่งสามารถรวมกับความรู้เกี่ยวกับโครงสร้างของเครือข่ายสาธารณะเพื่อจำกัดชุดของโหนดที่อาจเป็นผู้รับ 
• ผู้โจมตีใช้ระบบอิสระในการส่งต่อการจราจรของเครือข่าย IP เพื่อสังเกตการณ์การจราจรแบบพาสซีฟและรวมเข้ากับความรู้เกี่ยวกับความหน่วงของเครือข่าย IP ระหว่างโหนด (เช่น เวลาการตอบสนอง) รวมถึงความรู้เกี่ยวกับโครงสร้าง (และลักษณะอื่น ๆ) ของเครือข่าย Lightning สาธารณะ
เธอเสนอแนวทางแก้ไขที่เป็นไปได้ รวมถึง:
• กระตุ้นให้ผู้รับชะลอการยอมรับ HTLC โดยเพิ่มความล่าช้าแบบสุ่มเล็กน้อยเพื่อป้องกันการโจมตีที่พยายามระบุโหนดของผู้รับ 
• กระตุ้นให้ผู้ส่งชะลอการส่งการชำระเงินที่ล้มเหลว (หรือส่วนของ MPP) โดยเพิ่มความล่าช้าแบบสุ่มเล็กน้อยและใช้เส้นทางทางเลือกเพื่อป้องกันการโจมตีที่พยายามระบุโหนดของผู้ส่ง
• เพิ่มการแบ่งการชำระเงินด้วย MPP เพื่อทำให้การคาดเดาจำนวนเงินที่ใช้จ่ายยากขึ้น
• อนุญาตให้ผู้ส่งเลือกที่จะให้การชำระเงินของตนถูกส่งต่อช้าลง ตามที่เคยเสนอไว้ก่อนหน้านี้ (ดูจดหมายข่าวฉบับที่ 208) ซึ่งสามารถรวมกับการรวม HTLC ซึ่งได้ถูกนำมาใช้ใน LND แล้ว (แม้ว่าการเพิ่มความล่าช้าแบบสุ่มอาจเพิ่มความเป็นส่วนตัว)
• ลดความแม่นยำของการประทับเวลาของความล้มเหลวที่สามารถระบุได้เพื่อหลีกเลี่ยงการลงโทษโหนดส่งต่อที่เพิ่มความล่าช้าแบบสุ่มเล็กน้อย
การอภิปรายจากผู้เข้าร่วมหลายคนได้ประเมินข้อกังวลและแนวทางแก้ไขที่เสนออย่างละเอียด รวมถึงพิจารณาการโจมตีและการบรรเทาผลกระทบอื่น ๆ ที่เป็นไปได้
คำถามและคำตอบที่คัดสรรมาจาก Bitcoin Stack Exchange
Bitcoin Stack Exchange เป็นหนึ่งในแหล่งแรกที่ผู้ร่วมงานของ Optech มองหาเมื่อมีคำถาม หรือเมื่อมีเวลาว่างเล็กน้อยเพื่อช่วยผู้ใช้ที่อยากรู้อยากเห็นหรือสับสน ในคุณสมบัติประจำเดือนนี้ เราเน้นคำถามและคำตอบที่ได้รับคะแนนโหวตสูงสุดบางส่วนที่โพสต์ตั้งแต่การอัปเดตครั้งล่าสุดของเรา
• ธุรกรรมใดบ้างที่เข้าสู่ blockreconstructionextratxn? Glozow อธิบายว่าโครงสร้างข้อมูล extrapool (ดูจดหมายข่าวฉบับที่ 339) แคชธุรกรรมที่ถูกปฏิเสธและถูกแทนที่ที่โหนดเห็น และแสดงเกณฑ์สำหรับการยกเว้นและการขับออก 
• ทำไมใคร ๆ ถึงใช้ OP_RETURN แทนการจารึก นอกเหนือจากค่าธรรมเนียม? Sjors Provoost ชี้ให้เห็นว่านอกจากบางครั้งจะถูกกว่าแล้ว OP_RETURN ยังสามารถใช้สำหรับโปรโตคอลที่ต้องการให้ข้อมูลพร้อมใช้งานก่อนที่ธุรกรรมจะถูกใช้จ่าย ตรงข้ามกับข้อมูลพยานที่ถูกเปิดเผยในธุรกรรมที่ใช้จ่าย 
• ทำไมโหนด Bitcoin ของฉันถึงไม่รับการเชื่อมต่อขาเข้า? Lightlike ชี้ให้เห็นว่าโหนดใหม่บนเครือข่ายอาจใช้เวลาสักครู่เพื่อให้ที่อยู่ของมันถูกโฆษณาอย่างกว้างขวางบนเครือข่าย P2P และว่าโหนดจะไม่โฆษณาที่อยู่ของตนจนกว่า IBD จะเสร็จสมบูรณ์
• ฉันจะกำหนดค่าโหนดของฉันให้กรองธุรกรรมที่ใหญ่กว่า 400 ไบต์ได้อย่างไร? Antoine Poinsot ยืนยันว่าไม่มีตัวเลือกการกำหนดค่าใน Bitcoin Core เพื่อปรับแต่งขนาดธุรกรรมมาตรฐานสูงสุด เขาอธิบายว่าผู้ใช้ที่ต้องการปรับแต่งค่านั้นสามารถอัปเดตซอร์สโค้ดของตนได้ แต่เตือนเกี่ยวกับข้อเสียที่อาจเกิดขึ้นของค่าขนาดสูงสุดที่ใหญ่กว่าหรือเล็กกว่า 
• “โหนดที่ไม่สามารถกำหนดเส้นทางสาธารณะได้” ใน Bitcoin Core P2P หมายถึงอะไร? Pieter Wuille และ Vasil Dimov ให้ตัวอย่างของการเชื่อมต่อ P2P เช่น Tor ที่ไม่สามารถกำหนดเส้นทางบนอินเทอร์เน็ตทั่วโลกและปรากฏในผลลัพธ์ netinfo ของ Bitcoin Core ในกลุ่ม “npr” 
• ทำไมโหนดถึงต้องส่งต่อธุรกรรม? Pieter Wuille แสดงประโยชน์ของการส่งต่อธุรกรรมสำหรับผู้ดำเนินการโหนด: ความเป็นส่วนตัวเมื่อส่งต่อธุรกรรมของตนเองจากโหนดของตน การเผยแพร่บล็อกที่เร็วขึ้นหากผู้ใช้กำลังขุด และการกระจายอำนาจของเครือข่ายที่ดีขึ้นด้วยต้นทุนเพิ่มเติมเพียงเล็กน้อยนอกเหนือจากการส่งต่อบล็อก
• การขุดแบบเห็นแก่ตัว (selfish mining) ยังคงเป็นตัวเลือกอยู่หรือไม่เมื่อใช้บล็อกแบบกะทัดรัดและ FIBRE? Antoine Poinsot ตอบคำถามจากปี 2016 โดยระบุว่า “ใช่ การขุดแบบเห็นแก่ตัวยังคงเป็นการเพิ่มประสิทธิภาพที่เป็นไปได้แม้จะมีการปรับปรุงการเผยแพร่บล็อกแล้วก็ตาม ไม่ถูกต้องที่จะสรุปว่าการขุดแบบเห็นแก่ตัวในขณะนี้เป็นเพียงการโจมตีในทางทฤษฎีเท่านั้น” เขายังชี้ไปที่การจำลองการขุดที่เขาสร้างขึ้น
การเปิดตัวและเวอร์ชันทดลอง
การเปิดตัวและเวอร์ชันทดลองใหม่สำหรับโครงการโครงสร้างพื้นฐานของ Bitcoin ที่ได้รับความนิยม โปรดพิจารณาอัปเกรดเป็นเวอร์ชันใหม่หรือช่วยทดสอบเวอร์ชันทดลอง
• Core Lightning 25.05rc1 เป็นเวอร์ชันทดลองสำหรับเวอร์ชันหลักถัดไปของการใช้งานโหนด LN ที่ได้รับความนิยมนี้
• LDK 0.1.3 และ 0.1.4 เป็นการเปิดตัวของไลบรารีที่ได้รับความนิยมนี้สำหรับการสร้างแอปพลิเคชันที่เปิดใช้งาน LN เวอร์ชัน 0.1.3 ซึ่งถูกแท็กเป็นเวอร์ชันบน GitHub ในสัปดาห์นี้แต่ลงวันที่เมื่อเดือนที่แล้ว รวมถึงการแก้ไขสำหรับการโจมตีแบบปฏิเสธการให้บริการ (DoS) เวอร์ชัน 0.1.4 ซึ่งเป็นเวอร์ชันล่าสุด “แก้ไขช่องโหว่การขโมยเงินในกรณีที่เกิดขึ้นได้ยากมาก” ทั้งสองยังรวมถึงการแก้ไขข้อบกพร่องอื่นๆ
ต่อไปนี้คือการแปลเนื้อหาส่วน “การเปลี่ยนแปลงที่สำคัญในโค้ดและเอกสาร” จากจดหมายข่าว Bitcoin Optech Newsletter #356 เป็นภาษาไทยอย่างตรงไปตรงมาตามสไตล์ข่าวเทคโนโลยี:
⸻
การเปลี่ยนแปลงที่สำคัญในโค้ดและเอกสาร
การเปลี่ยนแปลงล่าสุดที่โดดเด่นในโปรเจกต์ Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), Lightning BOLTs, Lightning BLIPs, Bitcoin Inquisition และ BINANAs มีดังนี้:
• ● Bitcoin Core #31622
เพิ่มฟิลด์ประเภทลายเซ็น (signature hash type หรือ sighash) ใน PSBT (Partially Signed Bitcoin Transaction) หากค่า sighash นั้นแตกต่างจาก SIGHASH_DEFAULT หรือ SIGHASH_ALL ซึ่งเป็นค่าเริ่มต้นทั่วไป การรองรับ MuSig2 จำเป็นต้องให้ทุกฝ่ายเซ็นด้วย sighash ประเภทเดียวกัน ดังนั้นฟิลด์นี้จึงจำเป็นใน PSBT นอกจากนี้คำสั่ง RPC descriptorprocesspsbt ยังได้รับการอัปเดตให้ใช้ฟังก์ชัน SignPSBTInput เพื่อให้มั่นใจว่า sighash ที่ใช้ตรงกับที่ระบุใน CLI หากมีการกำหนดไว้
• ● Eclair #3065
เพิ่มการรองรับระบบ “ความล้มเหลวที่สามารถระบุได้” (attributable failures) ตามที่ระบุไว้ใน BOLTs #1044 (ดูจดหมายข่าวฉบับที่ #224) โดยค่าเริ่มต้นฟีเจอร์นี้จะถูกปิดการใช้งาน เนื่องจากสเปกยังไม่เสร็จสมบูรณ์ แต่สามารถเปิดใช้งานได้ด้วยการตั้งค่า eclair.features.option_attributable_failure = optional ความเข้ากันได้กับ LDK ได้รับการทดสอบเรียบร้อยแล้ว (ดูจดหมายข่าวฉบับที่ #349 สำหรับรายละเอียดการใช้งานของ LDK และโพรโตคอลนี้)
• ● LDK #3796
เพิ่มความเข้มงวดในการตรวจสอบยอดคงเหลือในช่องทาง โดยผู้ให้ทุน (funder) จะต้องมีเงินเพียงพอสำหรับค่าธรรมเนียมธุรกรรม commitment, ค่าผลลัพธ์ anchor จำนวน 2 จุดที่ 330 sat ต่อจุด และเงินสำรองของช่องทาง (channel reserve) ก่อนหน้านี้ funder สามารถดึงเงินจาก channel reserve มาใช้จ่ายใน anchor ได้ ซึ่งขณะนี้ไม่สามารถทำได้อีกต่อไป
• ● BIPs #1760
รวม BIP53 เข้ากับระบบ ซึ่งเป็นข้อเสนอ soft-fork ในระดับฉันทามติที่ห้ามไม่ให้มีธุรกรรมขนาด 64 ไบต์ (วัดโดยไม่รวมข้อมูล witness) เพื่อป้องกันช่องโหว่ของ Merkle Tree ที่สามารถถูกโจมตีจาก client แบบ SPV ได้ PR นี้เสนอวิธีแก้คล้ายกับวิธีหนึ่งที่รวมอยู่ใน soft-fork ทำความสะอาดฉันทามติ (consensus cleanup)
• ● BIPs #1850
ย้อนการอัปเดตก่อนหน้านี้ใน BIP48 ที่ได้สงวนค่า script type ที่เป็น 3 สำหรับ derivation แบบ Taproot (P2TR) (ดูจดหมายข่าวฉบับที่ #353) เนื่องจาก tapscript ไม่มีคำสั่ง OP_CHECKMULTISIG จึงไม่สามารถแสดงสคริปต์ output ที่อ้างอิงใน BIP67 ได้ (ซึ่ง BIP48 อ้างอิงอยู่) PR นี้ยังทำเครื่องหมายให้ BIP48 อยู่ในสถานะ “Final” เพื่อสะท้อนว่าจุดประสงค์ของ BIP นี้คือการกำหนดการใช้งานของเส้นทางอนุพันธ์ HD wallet แบบ m/48’ ให้กับอุตสาหกรรม ณ เวลาที่นำเสนอ ไม่ใช่เพื่อกำหนดพฤติกรรมใหม่
• ● BIPs #1793
รวม BIP443 ซึ่งเสนอการเพิ่ม opcode ใหม่ OP_CHECKCONTRACTVERIFY (OP_CCV) ที่อนุญาตให้ตรวจสอบว่า public key (ทั้งของ input และ output) ได้ผูกมัดกับข้อมูล任หนึ่งตามที่ระบุไว้ (arbitrary data) ดูจดหมายข่าวฉบับที่ #348 สำหรับข้อมูลเพิ่มเติมเกี่ยวกับ covenant ที่เสนอใหม่นี้
#siamstr #bitcoinoptech #newsletter 🗞️
quotingBitcoin Optech newsletter #356 is here:
note15a7…ak6q
- summarizes a discussion about the possible effects of attributable failures on LN privacy
- summarizes popular Q&A from Stack Exchange
- adds an attributable failures topic
- Optech Newsletter #356 Recap Podcast
https://bitcoinops.org/en/newsletters/2025/05/30/
Carla Kirk-Cohen posted to Delving Bitcoin an analysis of the possible consequences for the privacy of LN spenders and receivers if the network adopts attributable failures, particularly telling the spender the amount of time it took to forward a payment at each hop...
https://bitcoinops.org/en/newsletters/2025/05/30/#do-attributable-failures-reduce-ln-privacy
Selected Q&A from Bitcoin Stack Exchange:
- Which transactions get into blockreconstructionextratxn?
- Why would anyone use OP_RETURN over inscriptions, aside from fees?
- Why is my Bitcoin node not receiving incoming connections?
- How do I configure my node to filter out transactions larger than 400 bytes?
- What does “not publicly routable” node in Bitcoin Core P2P mean?
- Why would a node would ever relay a transaction?
- Is selfish mining still an option with compact blocks and FIBRE?
https://bitcoinops.org/en/newsletters/2025/05/30/#selected-qa-from-bitcoin-stack-exchange
Attributable failures are LN payment forwarding failures or delays that can be attributed to a pair of nodes, allowing spenders to avoid using slow or failure-prone nodes for future payments...
https://bitcoinops.org/en/topics/attributable-failures/
Bitcoin Optech will host an audio recap discussion of this newsletter on Riverside.fm Tuesday at 16:30 UTC. Join us to discuss or ask questions!
https://riverside.fm/studio/bitcoin-optech