คำอธิบายโดยละเอียดเกี่ยวกับการเปลี่ยนแปลงในวิธีการเปิดใช้งาน Bitcoin soft fork

以太坊爱好者

特邀专栏作者

2021-09-27 10:41

บทความนี้มีประมาณ 7782 คำ การอ่านทั้งหมดใช้เวลาประมาณ 12 นาที

ข้อเสนอการเปิดใช้งาน soft fork ใหม่มักจะได้รับการออกแบบมาเพื่อหลีกเลี่ยงปัญหาที่ soft fork ก่อนหน้า

ลิงค์ต้นฉบับ:

https://bitcoinops.org/en/topics/soft-fork-activation/

การเปิดใช้งานซอฟต์ฟอร์กหมายถึงช่วงเวลาที่ Bitcoin โหนดเต็มเริ่มเพิ่มกฎฉันทามติอย่างน้อยหนึ่งข้อ การเปลี่ยนแปลงนี้ทำให้เกิดความเสี่ยงในการประสานงานระหว่างโหนด ดังนั้น นักพัฒนาซอฟต์แวร์จึงใช้ความพยายามอย่างมากในช่วงหลายปีที่ผ่านมาเพื่อสร้างและปรับปรุงกลไกการเปิดใช้งาน soft fork เพื่อลดโอกาสที่จะเกิดปัญหาให้น้อยที่สุด

ประวัติศาสตร์

ชื่อเรื่องรอง

[2009] ความสูงของฮาร์ดโค้ด: เปิดใช้งานเลเยอร์ฉันทามติ nLockTime

soft fork แรกสุดที่รู้จักกันถูกนำมาใช้ในซอฟต์แวร์ Bitcoin เวอร์ชัน 0.1.6 (เปิดตัวในเดือนพฤศจิกายน 2552) ฮาร์ดโค้ดเพื่อเปิดใช้งานที่ความสูงของบล็อก 31,000 และเวลาจริงคือวันที่ 22 พฤศจิกายน 2552 ความสูงในการเปิดใช้งานแบบฮาร์ดโค้ดนี้ถูกใช้ใน soft fork ต้นอื่นอย่างน้อยหนึ่งรายการเมื่อ Satoshi Nakamoto ทำงานพัฒนาส่วนใหญ่

[2011] เวลาฮาร์ดโค้ดและการแทรกแซงด้วยตนเอง: BIP12OP_EVAL ล้มเหลว

หลังจากที่ Satoshi Nakamoto ออกจาก Bitcoin รหัส soft fork แรกที่รวมเข้ากับ Bitcoin คือ BIP12OP_EVAL แผนเดิมคือการใช้เวลาฮาร์ดโค้ดและการแทรกแซงด้วยตนเองเมื่อน้อยกว่า 50% ของกำลังการประมวลผลที่รองรับการเปลี่ยนแปลง อ้างจาก BIP12:

[...] ลูกค้าใหม่และนักขุดจะตีความ OP_EVAL เป็น no-op จนถึงวันที่ 1 กุมภาพันธ์ 2012 ก่อนหน้านี้ นักขุดที่ได้รับการสนับสนุนสามารถเขียน "OP_EVAL" ในบล็อกที่พวกเขาผลิตได้ ซึ่งสะดวกสำหรับเราในการคำนวณสัดส่วนของกำลังการประมวลผลที่รองรับ หากไม่มีการสนับสนุนมากกว่า 50% สำหรับการเปลี่ยนแปลงนี้ภายในวันที่ 15 มกราคม 2012 การเปิดใช้งานจะล่าช้าจนกว่าจะมีการสนับสนุนมากกว่า 50% สำหรับ OP_EVAL (หากเป็นที่แน่ชัดว่าการสนับสนุนส่วนใหญ่จะไม่เปิดใช้งานการอัปเกรดนี้ การอัปเกรด จะถูกยกเลิก)

การแทรกแซงด้วยตนเองอาจมีความจำเป็นเนื่องจาก OP_EVAL ถูกพบว่ามีช่องโหว่ร้ายแรงหลังจากที่รหัสเปิดใช้งานถูกผสาน แต่ก่อนที่จะเปิดตัว ในขณะที่ข้อบกพร่องได้รับการแก้ไข นักพัฒนาบางคนกังวลว่าอาจมีปัญหาอื่นๆ กับ opcode ใหม่อันทรงพลังนี้ ดังนั้นผู้คนจึงละทิ้งซอฟต์ฟอร์ก

[2012] ความพยายามอีกครั้งในเวลาฮาร์ดโค้ดและการแทรกแซงด้วยตนเอง: BIP16 P2SH

มีข้อเสนอแบบง่ายหลายอย่างที่จะแทนที่ OP_EVAL (ดู BIP13/16, 17, 18 และ 19 รวมถึงแนวคิดอื่นๆ) และ BIP13/16 Pay to Script Hash (P2SH) ได้รับการสนับสนุนจากนักพัฒนาส่วนใหญ่ P2SH ใช้กลไกการเปิดใช้งานเดียวกันกับ OP_EVAL เวลาเปิดใช้งานตามแผนเดิมคือวันที่ 1 มีนาคม 2012 แต่เมื่อถึงวันที่เรียกเก็บเงิน 15 กุมภาพันธ์ นักขุดน้อยกว่า 50% ใน 100 บล็อกล่าสุดระบุว่าพวกเขาจะใช้กฎ BIP16 ภายในเดือนมีนาคม สิ่งนี้ส่งผลให้เกิด "โซ่ทดแทนที่ค่อนข้างยาว" (การแยกโซ่) เนื่องจากนักขุดบางคนที่ยังคงใช้ BIP16 ในวันที่ 1 มีนาคมปฏิเสธบล็อกจากนักขุดส่วนใหญ่ (ไม่ได้ใช้กฎใหม่) วันที่ลงคะแนนครั้งที่สองคือสองสามพันบล็อกต่อมา คือวันที่ 15 มีนาคม ครั้งนี้ได้รับการสนับสนุนเพียงพอ ดังนั้นผู้พัฒนาจึงเปิดตัว Bitcoin 0.6.0 ในวันที่ 30 มีนาคม และตั้งเวลาเปิดใช้งานในวันที่ 1 เมษายน

[2012] เวลาฮาร์ดโค้ด: BIP30 ปฏิเสธที่จะคัดลอก txid

หลังจากการเปิดใช้งาน P2SH เสร็จสิ้น พบว่าธุรกรรมหลายรายการอาจแชร์ txid เดียวกัน ด้วยตัวของมันเอง ข้อผิดพลาดนี้จะทำให้เงินทุนของผู้ใช้ที่พยายามใช้ประโยชน์จากข้อผิดพลาดถูกทำลาย แต่อาจรวมกับพฤติกรรมแปลก ๆ บางอย่างในการสร้าง Merkle tree ของ Bitcoin เพื่อทำลายฉันทามติระหว่างโหนดต่างๆ (ดู CVE- 2012-2459) . soft fork ตัวแรกที่แก้ไขช่องโหว่นี้คือ BIP30 ซึ่งเพียงแค่ทำเครื่องหมายธุรกรรมที่ตามมาด้วย txid เหมือนกับว่าไม่ถูกต้อง หากธุรกรรมก่อนหน้านี้มีผลลัพธ์ที่ยังไม่ได้ใช้งาน การแก้ไขนี้ไม่ได้ขัดแย้งกันในหมู่ทีมพัฒนา ดังนั้นจึงเปิดใช้งานด้วยเวลาฮาร์ดโค้ดใน Bitcoin 0.6.0 ซึ่งรวมถึงพารามิเตอร์การเปิดใช้งาน P2SH

[2012] IsSuperMajority (ISM): คำนำหน้าฐานเหรียญ BIP34

แม้ว่า BIP30 จะแก้ไขปัญหาระยะสั้นที่เกิดจากการทับซ้อนของ txid แต่นักพัฒนา Bitcoin ทราบดีว่านี่เป็นมาตรการหยุดชั่วคราว และไม่มีเหตุผลใดที่ซอฟต์แวร์จะค้นหาดัชนีของธุรกรรมทั้งหมดด้วยเอาต์พุตที่ไม่ได้ใช้ทุกครั้งที่ได้รับธุรกรรมใหม่ ดังนั้นจึงมีการเสนอวิธีแก้ปัญหาที่สองโดยมุ่งกำจัดจุดอ่อนที่ทำให้การจำลองแบบ txid เป็นเวกเตอร์การโจมตีที่ใช้งานได้จริง นี่คือ BIP34 สำหรับการอัปเดตนี้ นักพัฒนาใช้วิธีการลงคะแนนเสียงของนักขุดที่คล้ายกับ BIP16 P2SH แต่ในครั้งนี้ นักขุดที่พร้อมรองรับ EIP34 จำเป็นต้องเพิ่มค่า nVersion ของบล็อกของตน ยิ่งไปกว่านั้น นักพัฒนาได้ดำเนินการตามกฎใหม่ในรหัส bitcoin โดยอัตโนมัติ ดังนั้นพวกเขาจึงสามารถเผยแพร่ซอฟต์แวร์ที่รองรับ soft fork ในขณะที่รอให้นักขุดทำการอัพเกรด กฎนี้จาก BIP34 ใช้กับฟังก์ชันที่เรียกว่า IsSUperMajority() ในตอนแรก มันมีเกณฑ์การเปิดใช้งานเดียว และเมื่อถึงเกณฑ์ กฎฉันทามติใหม่ของ BIP34 ก็เริ่มนำมาใช้:

กฎ 75%: หาก 75% ของ 1,000 บล็อกล่าสุดเป็น Vision2 หรือใหญ่กว่า ให้เริ่มปฏิเสธ Vision 2 บล็อกที่ไม่ถูกต้อง

ในระหว่างการพัฒนาคุณลักษณะนี้ ได้มีการตัดสินใจเพิ่มเกณฑ์การเปิดใช้งานที่สองเพื่อแก้ไขปัญหาที่ BIP34 ตั้งใจจะแก้ไขอย่างเด็ดขาด:

กฎ 95%: หาก 950 บล็อกจาก 1,000 บล็อกล่าสุดเป็นวิสัยทัศน์ 2 หรือมากกว่า ให้ปฏิเสธบล็อกการมองเห็น 1 ทั้งหมด

ปัญหาที่ทราบเกี่ยวกับกฎการปฏิเสธบล็อกเวอร์ชันเก่าคือ อาจมีบล็อกที่ไม่ถูกต้องหลายบล็อกต่อวัน เว้นแต่ว่านักขุดทุกคนจะอัปเกรดแล้ว (หาก 95% ของนักขุดเปิดใช้งานจริง แต่ละบล็อกมีโอกาส 5% ที่ไม่ถูกต้อง) โหนดที่ได้รับการอัปเกรดเพื่อบังคับใช้กฎ ISM จะปฏิเสธการบล็อกเหล่านี้ แต่โหนดที่เก่ากว่าและไคลเอ็นต์แบบไลท์จะไม่ทราบกฎและจะยอมรับกฎเหล่านั้น สิ่งนี้ทำให้เครือข่ายต้องพึ่งพานักขุดมากกว่าปกติที่จะไม่ขุดต่อไปหลังจากการบล็อกที่ไม่ถูกต้อง

[2015] ISM และ Verificationless Mining: BIP66 การเปิดใช้งาน DER ที่เข้มงวด

ในเดือนกันยายน 2014 Pieter Wuille พบความแตกต่างในการจัดการลายเซ็นที่เข้ารหัส DER ของ OpenSSL สำหรับแพลตฟอร์มต่างๆ สิ่งนี้สามารถใช้ประโยชน์ได้ ตัวอย่างเช่น เพื่อสร้างบล็อกที่จะผ่านการตรวจสอบความถูกต้องบนระบบปฏิบัติการ Linux แต่จะล้มเหลวในระบบปฏิบัติการ Windows ซึ่งผู้โจมตีจะสร้างการแบ่งห่วงโซ่ ณ จุดนั้น Wuille และผู้พัฒนารายอื่นหลายคนพัฒนาแพตช์นี้อย่างลับๆ และทำงานเพื่อเปิดใช้งานเป็นซอฟต์ฟอร์ก เพื่อให้มั่นใจว่าลายเซ็นทั้งหมดใช้รูปแบบเดียวกัน BIP66 ถูกสร้างขึ้นเพื่อสิ่งนี้ โดยประกาศเป็นขั้นตอนในการขจัดการพึ่งพา OpenSSL ของ Bitcoin (เป้าหมายที่แท้จริง ในที่สุดก็สำเร็จในปี 2019) หลังจาก BIP66 ได้รับการสนับสนุนเพียงพอจากผู้ใช้และนักพัฒนา (หลายคนไม่รู้ด้วยซ้ำว่ามีช่องโหว่ด้านความปลอดภัยอยู่) ก็ใช้กลไกการเปิดใช้งาน ISM แบบเดียวกับ BIP34 โดยเพิ่มหมายเลขเวอร์ชันบล็อกเป็น v3 และต้องการเกณฑ์ 95% บล็อกที่มี v2 และต่ำกว่า จากนั้นหมายเลขเวอร์ชันจะถูกปฏิเสธ

ถึงเกณฑ์ 75% ในวันที่ 4 กรกฎาคม 2558 และถึงเกณฑ์ 95% ที่ความสูงบล็อก 363725 โหนดทั้งหมดกำลังเรียกใช้ซอฟต์แวร์ Bitcoin Core v0.10.0 หรือใหม่กว่า (หรือการใช้งานที่เข้ากันได้) และการใช้งานจะเริ่มต้นกฎใหม่ อย่างไรก็ตาม ที่ความสูงของบล็อก 363731 นักขุดที่ไม่ได้อัปเกรดสร้างบล็อกที่ไม่มีหมายเลขเวอร์ชันปัจจุบัน ซึ่งไม่ใช่บล็อกที่ถูกต้องภายใต้กฎการเปิดใช้งาน ISM ใหม่ แต่นักขุดคนอื่นยังคงผลิตต่อไปหลังจากบล็อกที่ไม่ถูกต้องนี้ และในที่สุดก็สร้างเชนที่มีบล็อกที่ไม่ถูกต้อง 6 บล็อก ซึ่งหมายความว่าโหนดที่ไม่ได้อัปเกรดและไคลเอ็นต์แบบไลท์จำนวนมากจะถือว่าธุรกรรม 96 รายการในบล็อกแรกที่ไม่ถูกต้องเป็นธุรกรรมที่มีการยืนยันบล็อกสะสม 6 รายการ แม้ว่าพวกเขาจะยังไม่ได้รับการยืนยันแม้แต่บล็อกที่ถูกต้องในขณะนั้นก็ตาม ยืนยัน ในท้ายที่สุด นักพัฒนาไม่มีทางเลือกอื่นนอกจากต้องติดต่อผู้ให้บริการกลุ่มการขุดและให้พวกเขารีสตาร์ทซอฟต์แวร์ด้วยตนเองและกลับเข้าสู่เชนที่ใช้งานอยู่ เหตุการณ์ดังกล่าวเกิดขึ้นซ้ำอีกในวันถัดไป ทำให้ธุรกรรมบางรายการมีการยืนยันที่ไม่ถูกต้องสามครั้ง โชคดีที่ธุรกรรมปกติทั้งหมดในบล็อกหกและสามบล็อกนี้ถูกบรรจุลงในบล็อกที่ถูกต้องในภายหลัง ซึ่งหมายความว่าผู้ใช้ทั่วไปจะไม่ขาดทุน

บล็อกดั้งเดิมที่ไม่ถูกต้องที่ความสูง 363731 เป็นหนึ่งในประมาณ 5% ของบล็อกที่คาดว่าจะเกิดขึ้นทุกวันที่กลายเป็นบล็อกที่ไม่ถูกต้องเพียงเพราะใช้หมายเลขเวอร์ชันเก่า ความน่าจะเป็นที่บล็อกถัดไปจะถูกขุดโดยนักขุดที่ไม่ได้อัปเกรดคือ 5% ดังนั้นความน่าจะเป็นที่บล็อกสองบล็อกติดต่อกันคือบล็อกหมายเลขเวอร์ชันที่ถูกยกเลิกคือ 0.25% เนื่องจาก 95% ของนักขุดได้อัปเกรดแล้ว ความน่าจะเป็นที่ 6 บล็อกติดต่อกันจะถูกบล็อกด้วยหมายเลขเวอร์ชันที่ไม่ถูกต้องคือ 0.000002% - แต่ผู้ร้ายยังไม่ใช่โชคร้ายสุดขีด สิ่งที่ไม่พิจารณาคือนักขุดอาจทำ "การขุดโดยไม่มีการตรวจสอบ" นั่นคือหลังจากที่นักขุดได้รับบล็อกใหม่ พวกเขาจะดำเนินการผลิตต่อไปโดยไม่มีการตรวจสอบ ซึ่งสามารถปรับปรุงประสิทธิภาพได้เล็กน้อย ในขณะที่ซอฟต์แวร์การขุดที่ไม่ต้องตรวจสอบความถูกต้องสามารถจัดการหมายเลขรุ่นของบล็อกที่ไม่ถูกต้องได้อย่างง่ายดายในทางทฤษฎี แต่ฟีเจอร์นี้ยังไม่ได้นำมาใช้ในซอฟต์แวร์ที่นักขุดใช้ซึ่งทำการขุดบล็อกทั้ง 5 บล็อกในขณะนั้น ในที่สุด นักขุดจำนวนมากพออัพเกรดซอฟต์แวร์การขุดที่ไร้การพิสูจน์ หรืออัพเกรดโหนดของพวกเขา และการแยกเชนโดยไม่ตั้งใจที่เกี่ยวข้องกับการเปิดใช้งาน BIP66 ก็หายไป

ในการตอบสนองต่อปัญหาเหล่านี้ที่นำไปสู่การแยกในเดือนกรกฎาคม 2015 นักพัฒนาได้เพิ่มความพยายามเป็นสองเท่าเพื่อลดความจำเป็นในการขุดที่ไม่ต้องใช้การตรวจสอบ โดยผลลัพธ์เช่นการถ่ายทอดของบล็อกบีบอัด BIP152 และซอฟต์แวร์ FIBER นักพัฒนาก็เริ่มคิดเกี่ยวกับกลไกการเปิดใช้งานที่ดีกว่า ซึ่งก็คือโปรโตคอล BIP9 ที่จะกล่าวถึงในภายหลัง

[2015] ISM ล่าสุด: เปิดใช้งาน BIP65OP_CHECKLOCKTIMEVERIFY

ก่อน BIP66 DER soft fork ที่เข้มงวด มีคนเสนอให้ใช้ soft fork เพื่อเพิ่ม opcode ใหม่ OP_CHECKLOCKTIMEVERIFY (CLTV) ให้กับ Bitcoin แต่ถูกเลื่อนออกไปเนื่องจากการซ่อมแซมช่องโหว่ OpenSSL สิ่งนี้แสดงให้เห็นถึงจุดอ่อนอีกอย่างหนึ่งของกลไก ISM โดยใช้หมายเลขเวอร์ชันที่เพิ่มขึ้น - หากผู้ขุดส่งสัญญาณสนับสนุนข้อเสนอล่าสุด (วิสัยทัศน์ n) แสดงว่าสนับสนุนข้อเสนอก่อนหน้าทั้งหมดโดยปริยาย (เช่น วิสัยทัศน์ n-1) ซึ่งจะจำกัดความสามารถในการประสานงานการอัปเกรดหลายรายการพร้อมกันโดยใช้ ISM

อย่างไรก็ตาม แม้จะมีปัญหาบางประการเกี่ยวกับการเปิดใช้งาน BIP 66 แต่ ISM ก็ถูกนำมาใช้อีกครั้งในการเปิดใช้งาน BIP65 ที่ล่าช้า คราวนี้ไม่มีปัญหาอีกแล้ว

[2016] BIP9 versionbits: BIP68/112/113 การเปิดใช้งานเวลาล็อคสัมพัทธ์

BIP9 เสนอกลไกการเปิดใช้งานใหม่เพื่อแก้ปัญหาต่างๆ ของ ISM:

ลงโทษนักขุดโดยไม่จำเป็น: การเปิดใช้งาน ISM จะทำให้หมายเลขเวอร์ชันของบล็อกเพิ่มขึ้น และบล็อกที่สร้างโดยนักขุดที่ไม่เพิ่มหมายเลขเวอร์ชันจะถือว่าไม่ถูกต้อง แม้ว่าบล็อกนั้นจะไม่ละเมิดกฎอื่น ๆ ของ soft fork ก็ตาม ตัวอย่างเช่น ในการแบ่งเชนเมื่อวันที่ 4 กรกฎาคม 2015 การทำธุรกรรมทั้งหมดเป็นไปตามกฎของ Soft Fork - เหตุผลเดียวที่นักขุดเหล่านี้สูญเสีย $500,000 ก็เพราะการอัปเกรดนั้นต้องการให้ส่วนหัวของบล็อกต้องมี 3 และไม่ได้อัปเกรดนักขุดที่ใช้ 2 .
ยากต่อการขนาน: ด้วย ISM ต้องรอให้ส้อมหนึ่งทำงานเสร็จก่อนที่อีกส้อมหนึ่งจะเริ่มรวบรวมสัญญาณ แม้ว่าผู้พัฒนาจะเห็นว่าจำเป็นก็ตาม
ไม่อนุญาตให้มีความล้มเหลว: ISM ไม่ได้กำหนดเวลาหมดอายุ เมื่อปล่อยซอฟต์แวร์โหนดที่รอสัญญาณการเปิดใช้งาน โหนดที่รันซอฟต์แวร์ใหม่จะตรวจสอบสัญญาณจนกว่าการเปิดใช้งานจะเสร็จสมบูรณ์ ไม่มีทางที่จะแน่ใจได้ว่าผู้คนไม่ต้องการส้อมแบบนิ่มนี้เลย
เวลาเปิดใช้งานที่คาดเดาไม่ได้: ไม่สามารถทราบเวลาเปิดใช้งานที่แน่นอนล่วงหน้าได้ ซึ่งหมายความว่าเป็นเรื่องยากสำหรับนักพัฒนาโปรโตคอล ผู้ดูแลระบบผู้ค้า และผู้ดำเนินการกลุ่มการขุดที่จะนำมันไปใช้ทันทีหลังจากการเปิดใช้งาน แม้ว่าจะมีเหตุการณ์ฉุกเฉินที่ต้องการความรวดเร็ว คำถามตอบกลับ

บิตเวอร์ชัน BIP9 พยายามแก้ปัญหาเหล่านี้ ใช้ฟิลด์การมองเห็นภายในส่วนหัวของบล็อกเป็นฟิลด์บิต ข้อมูลในฟิลด์นี้ใช้สำหรับการส่งสัญญาณเท่านั้น - จะไม่ใช้เป็นพื้นฐานสำหรับบล็อกที่ไม่ถูกต้อง - และสามารถตั้งค่าแบบขนานได้ การวัดจะดำเนินการทุกๆ 2016 บล็อกเพื่อบีบอัดความเป็นไปได้ที่พลังแฮชเพียงเล็กน้อยจะโชคดีพอที่จะผ่านการสนับสนุน 95% ในที่สุด เมื่อถึงเกณฑ์การส่งสัญญาณ 95% จะมี "ช่วงการล็อก" เพิ่มเติมในช่วงปี 2559 (ประมาณสองสัปดาห์) ก่อนการเปิดใช้งาน เพื่อให้ทุกฝ่ายเตรียมพร้อมสำหรับการอัปเกรด หากไม่ถึงเกณฑ์การเปิดใช้งานก่อนเวลาหมดอายุ ความพยายามของ soft fork ทั้งหมดจะสิ้นสุดลง และรหัสที่ไม่ได้ใช้จะถูกลบออกในซอฟต์แวร์รุ่นหลัง

วิธีการเปิดใช้งานนี้ถูกใช้เป็นครั้งแรกในซอฟต์ฟอร์กของหมายเลขลำดับที่บังคับใช้ฉันทามติ BIP68, BIP112OP_CHECKSEQUENCEVERIFY และ nLockTime ที่กำหนดไว้ใน BIP113 ส้อมเข้าสู่เฟสล็อคอย่างรวดเร็ว จากนั้นเข้าสู่เฟสเปิดใช้งานโดยอัตโนมัติ

[2016-7] BIP9, BIP148 และ BIP91: BIP141/143 การเปิดใช้งานพยานแยก

ซอฟต์ฟอร์ก Segregated Witness เปิดตัวพร้อมพารามิเตอร์การเปิดใช้งาน BIP9 มีนักขุดเพียงไม่กี่คนที่แสดงความสนับสนุนอย่างรวดเร็ว แต่การสนับสนุนนั้นต่ำกว่าเกณฑ์ 95% ผู้ใช้ Bitcoin บางคนรู้สึกว่านักขุดกำลังรอฟีเจอร์ใหม่ที่เป็นประโยชน์อย่างไม่สมเหตุสมผล ดังนั้นจึงมีการพัฒนาการเปิดใช้งานโดยสมัครใจที่เรียกว่า BIP148 รูปแบบสุดท้ายของ BIP148 ระบุว่า นับจากวันที่กำหนด บล็อกทั้งหมดที่ไม่สนับสนุน segwit จะถูกปฏิเสธ

หลังจากการเกิดขึ้นของซอฟต์แวร์ที่ใช้ BIP148 มีโหนดสามประเภทในเครือข่าย - โหนดที่ไม่อัปเกรด, โหนด BIP9/141 และโหนด BIP148/141 - และความน่าจะเป็นที่จะตกอยู่ในข้อผิดพลาดที่สอดคล้องกันก็มีมากขึ้น หากนักขุดไม่รองรับ segwit และผู้ใช้ส่วนใหญ่ยังคงถือว่าบล็อกเหล่านี้ถูกต้อง ผู้ใช้ BIP148 อาจได้รับ bitcoins ที่ผู้ใช้รายอื่นเห็นว่าไม่ถูกต้อง นอกจากนี้ หากผู้ใช้ส่วนใหญ่สนับสนุน BIP148 แต่นักขุดยังคงสร้างบล็อกจำนวนมากที่ BIP148 ถือว่าไม่ถูกต้อง ผู้ใช้ที่ไม่ได้ใช้ BIP148 จะยอมรับ bitcoins ที่ผู้ใช้ BIP148 พิจารณาว่าไม่ถูกต้อง การอัปเกรดจะปลอดภัยก็ต่อเมื่อผู้ใช้ทำตามกฎเดียวกัน และพลังการประมวลผลส่วนใหญ่สนับสนุนกฎ BIP148

วิธีหนึ่งในการลดความเสี่ยงคือการให้เวลาเพียงพอสำหรับผู้ใช้ในการอัปเกรดเป็นโหนดที่บังคับให้เปิดใช้งาน segwit แต่ BIP148 ไม่สามารถทำเช่นนี้ได้เนื่องจากเป้าหมายคือเพื่อกระตุ้นกระบวนการ BIP9 ที่มีอยู่ ซึ่งหมายความว่า ซึ่งบังคับให้ผู้ขุดส่งสัญญาณสนับสนุน BIP9 นานก่อนหน้านั้น วันหมดอายุ ในฐานะที่เป็นทางเลือกที่อาจไม่เป็นที่นิยมสำหรับ BIP148 BIP149 เสนอให้ผู้ใช้อัปเกรดเพิ่มอีกหนึ่งปี BIP149 ไม่เคยได้รับการสนับสนุนจากสาธารณะมากนัก แต่เป็นข้อเสนอแรกที่ใช้ BIP8 ซึ่งจุดประกายให้เกิดการถกเถียงกันมากขึ้นในอีกไม่กี่ปีข้างหน้า

เมื่อ BIP148 เริ่มได้รับการสนับสนุนอย่างมีนัยสำคัญจากสาธารณชน นักขุด การแลกเปลี่ยน และตัวเลขในอุตสาหกรรมหลายรายแสดงการสนับสนุนสำหรับข้อเสนอสองขั้นตอนเพื่อเปิดใช้งาน Segregated Witness ในขณะที่ยังคงรักษาฉันทามติกับโหนดที่รองรับ BIP148 ขั้นตอนแรกเขียนขึ้นใน BIP91 ซึ่งปรับปรุงกฎของ BIP9 นักขุดสามารถใช้บิตฟิลด์ BIP9 เพื่อระบุว่าพวกเขาจะบังคับใช้กฎชั่วคราวหรือไม่: ปฏิเสธบล็อกทั้งหมดที่ไม่สนับสนุนสัญญาณ BIP141/143 Segregated Witness ซึ่งแตกต่างจาก BIP9 เกณฑ์ของ BIP91 นั้นลดลงจาก 95% เป็น 80% ในขณะที่ระยะเวลาการตรวจสอบและระยะเวลาการล็อคนั้นลดลงจากบล็อกปี 2559 เหลือ 336 บล็อก

BIP91 ล็อคและเปิดใช้งาน ต่อจากนั้น BIP141/143 จะถูกล็อคและเปิดใช้งาน เมื่อถูกล็อค มาตรการสนับสนุนที่จำเป็นของ BIP148 จะหมดอายุ

ขั้นตอนที่สองของข้อเสนอนี้จากนักขุด การแลกเปลี่ยน และตัวเลขในอุตสาหกรรมจำเป็นต้องมีการฮาร์ดฟอร์ก ซึ่งผู้ลงนามในข้อเสนอถอนตัวหลังจากผู้ใช้รายบุคคลและธุรกิจจำนวนมากคัดค้านอย่างรุนแรง

จนถึงทุกวันนี้ ผู้คนยังคงถกเถียงกันว่าเหตุการณ์เหล่านี้และเหตุการณ์อื่นๆ ที่เกิดขึ้นในช่วงเวลาเดียวกันมีบทบาทในการเปิดใช้งาน Segregated Witness มากน้อยเพียงใด

การเปิดใช้งานฉุกเฉิน

พบข้อบกพร่องร้ายแรงมากกว่าหนึ่งครั้งในรหัสฉันทามติและนักพัฒนาซอฟต์แวร์ออกแพตช์โดยไม่ผ่านกระบวนการเปิดใช้งาน การทำเช่นนั้นอาจส่งผลให้เกิดความล้มเหลวเป็นเอกฉันท์ แต่ยังช่วยกำจัดช่องโหว่สำหรับโหนดที่อัปเกรดในทันทีอีกด้วย เหตุการณ์สำคัญ ได้แก่ :

การใช้สายโซ่เพื่อแทนที่ความสูง (กรกฎาคม 2010): ในตอนแรก Bitcoin ถือว่าสายโซ่ที่มีบล็อกมากที่สุด ("สายโซ่ที่ยาวที่สุด") เป็นสายโซ่ที่ถูกต้อง หากทุกบล็อคมีความยากเท่ากัน โซ่ที่ยาวที่สุดนั้นจะเป็นโซ่ที่สะสมหลักฐานการทำงานมากที่สุดเช่นกัน แต่บล็อกที่แตกต่างกันมีความยากต่างกัน ดังนั้น soft fork ของ chainwork จึงเปิดตัวใน Bitcoin 0.3.3 และ chain ที่มีหลักฐานการทำงานสะสมมากที่สุดถือเป็น chain ที่ถูกต้อง
กำจัดข้อบกพร่องที่เลี่ยงผ่านสคริปต์ (กรกฎาคม 2010): เดิมที Bitcoin รวมสคริปต์ที่ใช้ UTXO (scriptSig) และสคริปต์ที่ป้องกัน UTXO (scriptPubKey) และประเมินพร้อมกัน การออกแบบนี้ช่วยให้สามารถยุติสคริปต์ก่อนที่กลไกการล็อกจะได้รับการประเมิน โดยออกด้วยสถานะสำเร็จ เช่น ก่อนเรียกใช้ OP_CHECKSIG เพื่อตรวจสอบลายเซ็น เดิมมีรายงานข้อผิดพลาดนี้ว่า scriptSig ที่ใช้ OP_TRUE OP_RETURN สามารถใช้บิตคอยน์ของใครก็ได้ ข้อผิดพลาดนี้ได้รับการแก้ไขครั้งแรกใน Bitcoin 0.3.6 โดยการทำให้ OP_RETURN ล้มเหลวเสมอ และกำหนดตัวเลขให้กับการแสดงผลอื่นๆ ในสคริปต์ แม้ว่าการเปลี่ยนแปลงทั้งหมดนี้จะเป็นแบบซอฟต์ฟอร์ก การเปลี่ยนแปลงรหัสเดียวกัน (ซึ่งภายหลังได้ลบข้อจำกัดบางอย่างออกไป) ยังส่งผลให้เกิดการเปลี่ยนแปลงรูปแบบฮาร์ดฟอร์กอีกด้วย แม้จะมีการเปลี่ยนแปลงครั้งใหญ่ ปัญหาพื้นฐานที่ scriptSig สามารถยุ่งเกี่ยวกับการทำงานของ scriptPubKeys ยังคงมีอยู่ ดังนั้น soft fork ตัวที่สองจึงถูกนำมาใช้ใน Bitcoin 0.3.8 ซึ่งทำให้ทั้งสองทำงานได้อย่างอิสระ
แก้ไขข้อผิดพลาดล้น (สิงหาคม 2010): มีคนสร้างธุรกรรมเพื่อใช้จ่าย 0.5 btc และสร้างสองผลลัพธ์มูลค่า 92,233,720,368.54277039 BTC Bitcoin กำหนดให้ค่าเอาต์พุตต้องไม่มากกว่าค่าอินพุตแต่วิธีการตรวจจับคือการเพิ่มค่าเอาต์พุตเป็นจำนวนเต็ม 64 บิตที่สามารถแสดงได้มากถึง 9,223,372,036,854,776 Satoshi (ประมาณ 92 ล้าน btc) Satoshi เริ่มต้นขึ้น ซึ่งหมายความว่าการทำธุรกรรมมีค่าใช้จ่ายเพียง -0.1 btc เท่านั้น สิ่งนี้ยังข้ามกฎอีกข้อหนึ่งที่ห้ามเอาต์พุตเชิงลบแต่ละรายการ แต่ไม่รวมค่าลบทั้งหมด - เนื่องจากถือว่าผลรวมของค่าบวกใด ๆ จะยังคงเป็นค่าบวก สิ่งนี้ทำให้ใครบางคนสามารถสร้าง 184 พันล้าน btc และเคล็ดลับนี้สามารถทำซ้ำได้โดยไม่มีค่าใช้จ่ายใด ๆ สร้าง bitcoin นับไม่ถ้วน ภายในไม่กี่ชั่วโมง Bitcoin 0.3.10 ได้เปิดตัวแพทช์ soft fork ที่จำกัดเอาต์พุตไว้ที่ 21 ล้าน btc นอกจากนี้ยังจำเป็นต้องละทิ้งเครือข่ายที่มีการทำธุรกรรมล้น — ความล้มเหลวโดยเจตนาเป็นเอกฉันท์ แต่จำเป็นสำหรับ Bitcoin ยังคงสมเหตุสมผล
แก้ไขปัญหาการล็อก BDB ชั่วคราว (มีนาคม 2013): ในช่วงต้นปี 2012 นักพัฒนา Bitcoin ตระหนักว่าหากมีการเปลี่ยนแปลงมากเกินไปกับฐานข้อมูล UTXO (สถานะเชน) ขีดจำกัดความสามารถเริ่มต้นข้อหนึ่งสำหรับข้อมูลสถานะเชนอาจเป็นได้ เกิน เนื่องจากบล็อค Bitcoin มีขนาดค่อนข้างเล็กในเวลานั้น จึงสังเกตได้เฉพาะเมื่อมีการจัดระเบียบบล็อคเชนใหม่ ทำให้ต้องประมวลผลธุรกรรมจากหลาย ๆ บล็อคพร้อมกัน โซลูชันง่ายๆ ถูกนำมาใช้ในขณะนั้น: ในระหว่างการปรับองค์กร ให้ประมวลผลธุรกรรมจากทีละบล็อกเท่านั้น ต่อมา บางคนเริ่มขอให้นักขุดเพิ่มขนาดบล็อกเริ่มต้นที่เป็นทางเลือกจาก 250 KB เมื่อวันที่ 12 มีนาคม 2013 นักขุดสร้างบล็อก ~1 MB ที่มีการทำธุรกรรมมากกว่า 1,700 รายการ ซึ่งเป็นบล็อก Bitcoin ที่ใหญ่ที่สุดในปัจจุบัน ซึ่งเกินความจุของฐานข้อมูลในหลาย ๆ โหนด ทำให้พวกเขาพิจารณาว่าบล็อกนั้นไม่ถูกต้องแม้ว่าจะเป็นไปตามข้อกำหนดทั้งหมดก็ตาม กฎฉันทามติที่ชัดเจนของ Bitcoin เพื่อทำให้น้ำกลายเป็นโคลนมากยิ่งขึ้น Bitcoin Core เวอร์ชันใหม่ได้รับการปล่อยตัว ซึ่งใช้เครื่องมือฐานข้อมูลอื่นโดยไม่มีข้อจำกัดนี้ ดังนั้นจึงสามารถรับบล็อกที่ใหญ่กว่านี้ได้อย่างปลอดภัย ดังนั้นโหนดเวอร์ชันต่างๆ จึงเกิดข้อผิดพลาดที่สอดคล้องกัน หลังจากวิเคราะห์สถานการณ์อย่างรวดเร็ว นักพัฒนาแนะนำให้ผู้ใช้ดาวน์เกรดชั่วคราวเป็นเวอร์ชันเก่า (ซึ่งจะปฏิเสธเวอร์ชันที่มีบล็อกขนาดใหญ่นี้) จากนั้นอัปเดตเป็นเวอร์ชันฉุกเฉิน ซึ่งจะลดขนาดบล็อกลงเหลือ 500 KB ชั่วคราวด้วย a soft fork เพื่อให้ผู้ใช้ทุกคนมีเวลาอัปเกรดเป็นเอ็นจิ้นฐานข้อมูลใหม่ และการดาวน์เกรดชั่วคราวนี้จะหมดอายุโดยอัตโนมัติหลังจากผ่านไปสองสามเดือน

การเปิดใช้งานในอนาคต

หลังจากประสบปัญหาในการเปิดใช้งาน Segwit มาหลายเดือน บางคนก็เริ่มคิดถึง BIP8 ผู้สนับสนุน BIP8 เชื่อว่าสามารถแก้ปัญหาบางอย่างของ BIP9 ได้:

อนุญาตการเปิดใช้งานแบบบังคับ: BIP8 เป็นลักษณะทั่วไปของ BIP148 นักขุดสามารถส่งสัญญาณการสนับสนุนโดยสมัครใจในช่วงเวลาที่รอการเปิดใช้งาน แต่ยังกำหนดช่วงเวลายื่นคำขาดในระหว่างที่นักขุดต้องส่งสัญญาณสนับสนุน มิฉะนั้นบล็อคที่ผลิตอาจกลายเป็นโมฆะ ต่อมา ผู้คนได้ออกแบบพารามิเตอร์ LockinOnTimeout (LOT) เพื่อทริกเกอร์การกระทำนี้: โหนดที่ใช้ LOT=true จะกำหนดให้นักขุดส่งสัญญาณในช่วงเวลาสุดท้ายเมื่อการเปิดใช้งานกำลังจะหมดเวลา โหนดที่ใช้ LOT=false จะไม่ต้องการ นี้ แต่กฎใหม่จะยังคงมีผลหากมีการบล็อกเพียงพอ
ใช้ระดับความสูงแทนเวลา: BIP9 เริ่มและหยุดการตรวจสอบสัญญาณการเปิดใช้งานตามค่าเฉลี่ยของเวลาที่นักขุดเขียนบล็อก ดังนั้นจึงเป็นไปได้ที่นักขุดจะควบคุมเวลานี้ ซึ่งจะขัดขวางการทำงานของ LOT=true ดังนั้น BIP8 จึงเสนอให้ใช้ความสูงของบล็อกแทนเวลา

ความยืดหยุ่นของ BIP8 ทำให้เป็นหนึ่งในหลายข้อเสนอการเปิดใช้งานของ taproot soft fork แม้ว่านักวิจารณ์จะวิพากษ์วิจารณ์ในบางแง่มุม เช่น การตั้งค่าบางอย่างที่อนุญาตให้คนงานเหมืองปฏิเสธที่จะเปิดใช้งานข้อเสนอที่มีการสนับสนุนจากชุมชนในวงกว้าง ส่งเสริมกลุ่ม "จับ" กลไกการส่งสัญญาณที่ใช้โดยกลุ่มอื่น ทำให้นักขุดต้องทำการเปลี่ยนแปลงเล็กน้อยกับบล็อกที่ผลิต ดูเหมือนว่าจะให้อำนาจแก่นักพัฒนาเหนือกฎที่เป็นเอกฉันท์และเพิ่มความเสี่ยงของความล้มเหลวที่เป็นเอกฉันท์ ขณะที่เขียนบทความนี้ การอภิปรายเกี่ยวกับวิธีการเปิดใช้งาน taproot ยังคงดำเนินต่อไป

มีการกล่าวถึงแนวคิดอื่น ๆ รวมถึง "การเปิดใช้งาน soft-fork ที่น่าจะเป็น (sporks)", "การเปิดใช้งาน soft-fork แบบหลายขั้นตอน (MSFA)", "การเปิดใช้งานการลดเกณฑ์ (decthresh)", "การคืนค่าความสูงหรือเวลาการเปิดใช้งานแบบฮาร์ดโค้ด (วันธง)", และ "ระยะเวลาสัญญาณสั้นลงหลังจากดีเลย์การเปิดใช้งาน (การทดลองใช้แบบเร็ว)"