
P2SH และกระเป๋าหลายลายเซ็น ปี 2012 ที่มาของที่อยู่ Bitcoin ขึ้นต้นด้วยเลข 3
1 เมษายน 2012 กฎ Pay to Script Hash เริ่มมีผลบน Bitcoin หลังการแข่งกันของข้อเสนอสามฉบับและการโหวตของนักขุดที่เลื่อนวันจากแผนแรก บทความนี้เปิดเอกสาร BIP 11 12 13 16 และ 17 ต้นฉบับ กับข้อมูลบนเชนรายเดือนสิบสี่ปี ไล่ดูว่า P2SH แก้ปัญหาอะไร ขึ้นมาได้อย่างไร และถูกใช้จริงแค่ไหน
ทุกวันนี้ถ้าเห็นที่อยู่ Bitcoin ที่ขึ้นต้นด้วยเลข 3 คนส่วนใหญ่ไม่ได้คิดอะไร แต่ที่อยู่แบบนี้มีที่มาจากการตัดสินใจครั้งใหญ่ของเครือข่ายเมื่อต้นปี 2012 ตอนที่นักพัฒนาอยากให้ Bitcoin ล็อกเงินด้วยเงื่อนไขที่ซับซ้อนกว่าลายเซ็นเดียว เช่น ต้องมีลายเซ็นสองในสามคนถึงจะใช้เงินได้ ทางออกที่ชนะคือข้อเสนอชื่อ Pay to Script Hash หรือ P2SH ซึ่งต้องผ่านการแข่งกันของข้อเสนอหลายตัวและการโหวตของนักขุด กว่าจะเริ่มมีผลในวันที่ 1 เมษายน 2012 บทความนี้เปิดเอกสาร BIP ต้นฉบับทุกฉบับที่เกี่ยวข้อง และข้อมูลบนเชนรายเดือนสิบสี่ปี ไล่ดูว่า P2SH แก้ปัญหาอะไร ขึ้นมาได้อย่างไร และถูกใช้จริงแค่ไหน
ปัญหาของปี 2011: เงื่อนไขที่ซับซ้อนส่งยาก
ปลายปี 2011 Bitcoin มีธุรกรรมแบบหลายลายเซ็นอยู่แล้ว เอกสาร BIP 11 ที่ Gavin Andresen เขียน ได้เลขประจำเมื่อวันที่ 18 ตุลาคม 2011 เสนอให้ธุรกรรมแบบ M-of-N หรือต้องมีลายเซ็น M จาก N คน เป็นธุรกรรมมาตรฐานที่โหนดยอมส่งต่อ
ภาพ: เอกสาร BIP 11 ใน repository bitcoin/bips บน GitHub
BIP 11 ยกตัวอย่างการใช้งานไว้ชัด เช่น กระเป๋าเงินที่มีบริการคุ้มครอง ใช้ลายเซ็นสองในสอง ลายเซ็นแรกมาจากคอมพิวเตอร์ของเจ้าของซึ่งอาจโดนแฮ็กได้ ลายเซ็นที่สองมาจากบริการคุ้มครองที่จะโทรถามเจ้าของก่อนว่าตั้งใจโอนจริงไหม และอีกตัวอย่างคือการฝากเงินกับคนกลางแบบ escrow ที่ต้องมีสองในสามฝ่ายเห็นชอบก่อนปล่อยเงิน
BIP 11 เขียนข้อควรระวังไว้ในตัวอย่างแรกด้วย ลูกค้าควรขอให้บริการคุ้มครองส่งสำเนากุญแจที่ใช้คุ้มครองกระเป๋ามาให้ เก็บไว้แบบออฟไลน์ เพื่อให้ยังใช้เงินได้แม้บริการนั้นจะปิดกิจการ ประโยคนี้เขียนไว้ตั้งแต่ปี 2011 แต่ยังเป็นหลักที่ใช้ได้กับกระเป๋าหลายลายเซ็นทุกแบบจนถึงวันนี้
ในทางเทคนิค BIP 11 อนุญาตให้ธุรกรรมแบบนี้เป็นมาตรฐานเฉพาะกรณีที่มีกุญแจไม่เกิน 3 ดอก และมีรายละเอียดแปลกอยู่ข้อหนึ่ง คือคำสั่ง OP_CHECKMULTISIG มีบั๊กที่ดึงข้อมูลออกเกินไปหนึ่งชิ้น ธุรกรรมที่ใช้จ่ายเงินจึงต้องใส่ค่าหลอก OP_0 ไว้ข้างหน้าเสมอ และเอกสารยังต้องขยายเพดานขนาดข้อมูลลายเซ็นที่โปรแกรมยอมส่งต่อจาก 200 ไบต์เป็น 500 ไบต์ เพื่อให้ธุรกรรมสามลายเซ็นผ่านได้
ปัญหาคือวิธีนี้วางภาระผิดคน เงื่อนไขทั้งหมดต้องถูกเขียนโดยคนส่งเงิน คนที่จะโอนเงินเข้ากระเป๋าหลายลายเซ็นต้องรู้กุญแจสาธารณะของทุกคน และต้องสร้างสคริปต์ยาวเหยียดเอง กระเป๋าเงินของคนส่งส่วนใหญ่ไม่รองรับ และไม่มีรูปแบบที่อยู่ที่สั้นพอให้คัดลอกหรือสแกนได้
สองในสามทำงานอย่างไรในชีวิตจริง
ตัวอย่าง escrow ใน BIP 11 อธิบายการใช้งานได้ชัดที่สุด มีสามฝ่าย คือผู้ซื้อ ผู้ขาย และคนกลางที่ทั้งสองฝ่ายไว้ใจให้ตัดสินข้อพิพาท ทุกฝ่ายส่งกุญแจสาธารณะของตัวเองมา ผู้ซื้อโอนเงินเข้าธุรกรรมแบบสองในสามลายเซ็น แล้วแจ้งรหัสธุรกรรมให้ผู้ขายกับคนกลางรู้
เมื่อผู้ขายส่งของครบตามตกลง ผู้ขายเซ็นธุรกรรมที่โอนเงินก้อนนั้นให้ตัวเอง แล้วขอให้ผู้ซื้อเซ็นร่วม ครบสองลายเซ็นเงินก็ไปถึงผู้ขาย ถ้าผู้ซื้อกับผู้ขายตกลงกันไม่ได้ คนกลางจะตัดสินว่าเงินควรไปทางไหน โดยเซ็นร่วมกับฝ่ายใดฝ่ายหนึ่ง
จุดสำคัญคือไม่มีใครฝ่ายเดียวเอาเงินไปได้ แม้แต่คนกลางเองก็ย้ายเงินไม่ได้ถ้าไม่มีผู้ซื้อหรือผู้ขายร่วมเซ็น ความไว้ใจถูกกระจายออกไปสามทาง แทนที่จะฝากไว้กับคนใดคนหนึ่ง หลักเดียวกันนี้คือพื้นฐานของบริการดูแลเหรียญแบบหลายฝ่ายและกระเป๋าหลายลายเซ็นที่ใช้กันทุกวันนี้
แนวคิดของ P2SH: ย้ายภาระไปให้คนรับ
ต้นปี 2012 Gavin Andresen เขียนเอกสาร BIP 16 ชื่อ Pay to Script Hash ได้เลขประจำเมื่อวันที่ 3 มกราคม 2012 หัวข้อ Motivation เขียนเป้าหมายไว้ในประโยคเดียว
ภาพ: เอกสาร BIP 16 ใน repository bitcoin/bips บน GitHub
"จุดประสงค์ของ pay-to-script-hash คือย้ายความรับผิดชอบในการกำหนดเงื่อนไขการใช้เงิน จากคนส่งเงินไปเป็นคนที่จะใช้เงินนั้น"
Gavin Andresen, BIP 16 Pay to Script Hash หัวข้อ Motivation ต้นฉบับ "The purpose of pay-to-script-hash is to move the responsibility for supplying the conditions to redeem a transaction from the sender of the funds to the redeemer."
วิธีทำเรียบง่ายมาก แทนที่จะเขียนเงื่อนไขทั้งหมดลงในธุรกรรมตอนส่ง คนส่งใส่แค่ค่า hash ขนาด 20 ไบต์ของสคริปต์เงื่อนไขนั้น เอกสารบอกว่าค่านี้สั้นพอจะสแกนจาก QR code หรือคัดลอกวางได้สบาย พอถึงวันที่คนรับจะใช้เงิน คนรับค่อยเปิดเผยสคริปต์เต็มออกมา พร้อมลายเซ็นที่สคริปต์ต้องการ เครือข่ายตรวจสองชั้น ชั้นแรกคือสคริปต์ที่เปิดเผยตรงกับค่า hash ที่ล็อกไว้ไหม ชั้นที่สองคือลายเซ็นครบตามเงื่อนไขในสคริปต์ไหม
แนวคิดนี้ไม่ได้ผ่านไปง่ายๆ หัวข้อ Rationale ของ BIP 16 ยอมรับเองว่าเหตุผลของข้อเสนอค่อนข้างเป็นที่ถกเถียง บางคนเห็นว่าไม่จำเป็น แค่ให้คนส่งได้สคริปต์เต็มไปเลยก็พอ Gavin Andresen ตอบไว้ในเอกสารว่า ข้อเสนอนี้จะเปลี่ยนระบบที่มีอยู่น้อยที่สุด เพราะร้านค้า เว็บเทรด และโปรแกรมต่างๆ รองรับที่อยู่ขนาด 20 ไบต์อยู่แล้ว จึงเริ่มรองรับกระเป๋าหลายลายเซ็นได้เร็วกว่า
"การรู้จำ scriptPubKey รูปแบบพิเศษแบบหนึ่ง แล้วตรวจสอบเพิ่มเมื่อเจอมันเป็นเรื่องที่ไม่สวย แต่ความเห็นร่วมคือทางเลือกอื่นไม่สวยยิ่งกว่า ซับซ้อนกว่า หรือขยายความสามารถของภาษาสคริปต์ไปในทางที่อันตราย"
Gavin Andresen, BIP 16 หัวข้อ Rationale ต้นฉบับ "Recognizing one 'special' form of scriptPubKey and performing extra validation when it is detected is ugly. However, the consensus is that the alternatives are either uglier, are more complex to implement, and/or expand the power of the expression language in dangerous ways."
ประโยคนี้บอกอะไรเกี่ยวกับวิธีคิดของนักพัฒนา Bitcoin ได้มาก เป้าหมายไม่ใช่วิธีที่สวยที่สุด แต่เป็นวิธีที่เสี่ยงน้อยที่สุด BIP 16 ยังเขียนไว้ด้วยว่าเอกสารนี้มาแทน BIP 12 ที่ Gavin เคยเสนอไว้เอง ซึ่งทำได้มากกว่า แต่ก็เปิดความสามารถให้ภาษาสคริปต์มากกว่าด้วย
เอกสาร BIP 13 ที่เขียนคู่กันกำหนดรูปแบบที่อยู่ใหม่สำหรับเรื่องนี้ ใช้ไบต์กำกับรุ่นเป็นเลข 5 ซึ่งพอแปลงด้วย Base58 แล้ว ตัวอักษรแรกของที่อยู่จะเป็นเลข 3 เสมอ ส่วนที่อยู่ของเครือข่ายทดสอบขึ้นต้นด้วยเลข 2 นี่คือที่มาของที่อยู่ขึ้นต้นด้วย 3 ที่เห็นกันจนถึงวันนี้ คนส่งเงินไม่ต้องรู้เลยว่าข้างหลังที่อยู่นั้นเป็นกระเป๋าหลายลายเซ็นหรือเงื่อนไขอะไร ส่งแบบเดียวกับที่อยู่ธรรมดาทุกประการ
ข้อเสนอสามตัวที่แข่งกัน
P2SH ไม่ใช่ทางเลือกเดียวในตอนนั้น เอกสาร BIP อีกสองฉบับจากช่วงเวลาเดียวกันเสนอทางแก้ปัญหาเดียวกันคนละแบบ
- BIP 12 OP_EVAL ของ Gavin Andresen เอง ได้เลขประจำวันเดียวกับ BIP 11 คือ 18 ตุลาคม 2011 เสนอคำสั่งใหม่ที่ให้สคริปต์รันสคริปต์อื่นข้างในได้ หัวข้อ Motivation ใช้ถ้อยคำคล้าย BIP 13 ว่าต้องการกระเป๋าที่ปลอดภัยตั้งแต่ต้นทางถึงปลายทาง สถานะปัจจุบันของเอกสารคือ Closed
- BIP 17 OP_CHECKHASHVERIFY ของ Luke Dashjr ได้เลขประจำวันที่ 18 มกราคม 2012 หัวข้อ Motivation เขียนเหมือน BIP 16 แทบคำต่อคำ แต่เสนอวิธีทำอีกแบบ คือเปลี่ยนความหมายของคำสั่ง OP_NOP2 ที่มีอยู่แล้วให้ทำหน้าที่ตรวจค่า hash สถานะปัจจุบันของเอกสารคือ Closed
- BIP 16 P2SH ของ Gavin Andresen คือตัวที่ชนะ สถานะปัจจุบันคือ Deployed
ภาพ: เอกสาร BIP 17 ข้อเสนอที่แข่งกับ P2SH ใน repository bitcoin/bips บน GitHub
ทั้งสามข้อเสนอเป็นซอฟต์ฟอร์ก คือเพิ่มกฎใหม่โดยที่โหนดเก่ายังทำงานต่อได้ ความต่างอยู่ที่รายละเอียดทางเทคนิคว่าจะให้สคริปต์ถูกตรวจแบบไหน การที่ข้อเสนอสองในสามถูกปิดไป แสดงให้เห็นว่าการเปลี่ยนกฎของ Bitcoin แม้จะเป็นเรื่องที่ทุกคนเห็นตรงกันว่าควรแก้ ก็ยังต้องเลือกวิธีที่ดีที่สุดวิธีเดียว ใครอยากเข้าใจเรื่องซอฟต์ฟอร์กเพิ่ม อ่านได้ที่Fork คืออะไร ต่าง Hard Fork กับ Soft Fork ยังไง
ให้นักขุดโหวตด้วยข้อความในบล็อก
เรื่องที่น่าสนใจที่สุดของ BIP 16 คือวิธีเปิดใช้งาน เอกสารเขียนกลไกการโหวตของนักขุดไว้ตรงๆ
ภาพ: หัวข้อ Backwards Compatibility ใน BIP 16 บน GitHub
ธุรกรรม coinbase คือธุรกรรมรายการแรกของทุกบล็อก เป็นรายการที่นักขุดใช้จ่ายรางวัลให้ตัวเอง และมีช่องข้อมูลที่นักขุดเขียนข้อความอะไรลงไปก็ได้ การขอให้นักขุดเขียนคำว่า /P2SH/ ลงในช่องนี้จึงเป็นวิธีนับเสียงที่ง่ายที่สุด ใครก็นับได้จากบล็อกเชนโดยไม่ต้องเชื่อคำบอกเล่าของใคร
นักขุดที่สนับสนุนให้อัปเกรดซอฟต์แวร์ แล้วใส่ข้อความ /P2SH/ ลงในธุรกรรม coinbase ของบล็อกที่ตัวเองขุด วันที่ 1 กุมภาพันธ์ 2012 จะนับบล็อกย้อนหลัง 7 วัน ถ้ามีบล็อกที่มีข้อความนี้ตั้งแต่ 550 บล็อกขึ้นไป กฎใหม่จะมีผลกับทุกบล็อกหลังวันที่ 15 กุมภาพันธ์ 2012 เวลา 00:00 น. GMT เอกสารอธิบายว่าหนึ่งสัปดาห์มีบล็อกราว 1,000 บล็อก 550 บล็อกจึงเท่ากับนักขุดราว 55% ของเครือข่าย และถ้าเสียงข้างมากไม่สนับสนุน การเปิดใช้จะถูกเลื่อนออกไป หรือถูกยกเลิกถ้าชัดเจนว่าจะไม่มีวันได้เสียงข้างมาก
วันที่มีผลจริงไม่ใช่วันที่ 15 กุมภาพันธ์ ส่วน Specification ของ BIP 16 ฉบับปัจจุบันเขียนว่ากฎใหม่ใช้กับบล็อกที่มีเวลาตั้งแต่ค่า 1333238400 เป็นต้นไป ซึ่งคือวันที่ 1 เมษายน 2012 ตามกฎที่เอกสารเขียนไว้เอง การเปิดใช้จึงถูกเลื่อนออกไปราวหกสัปดาห์จากแผนแรก
BIP 16 ยังเขียนถึงการโจมตีแบบหนึ่งที่ทำได้ในช่วงนั้นไว้อย่างเปิดเผย ผู้โจมตีสร้างธุรกรรม P2SH ที่โปรแกรมรุ่นเก่ามองว่าถูก แต่รุ่นใหม่มองว่าผิด ส่งเงินให้ตัวเอง แล้วสร้างธุรกรรมอีกรายการที่ใช้เงินก้อนนั้นจ่ายให้เหยื่อที่ยังใช้โปรแกรมรุ่นเก่า ขุดทั้งสองรายการลงบล็อกเดียว ถ้าเหยื่อยอมรับเงินหลังการยืนยันแค่บล็อกเดียว ผู้โจมตีจะได้ของไปฟรี เพราะเมื่อเครือข่ายส่วนใหญ่ปฏิเสธบล็อกนั้น ธุรกรรมทั้งสองก็หายไป เอกสารสรุปว่าการโจมตีนี้แพงและยาก เพราะต้องขุดบล็อกที่รู้ล่วงหน้าว่าจะถูกทิ้ง และแนะนำว่าไม่ควรรับเงินก้อนใหญ่หลังการยืนยันแค่บล็อกเดียวอยู่แล้ว
เอกสารยังเขียนถึงความเสี่ยงของช่วงเปลี่ยนผ่านไว้ตรงๆ ถ้านักขุดไม่ถึงครึ่งอัปเกรด อาจมีธุรกรรม P2SH ที่นักขุดรุ่นใหม่มองว่าผิด แต่นักขุดรุ่นเก่ามองว่าถูก แล้วเครือข่ายแยกเป็นสองฝั่ง การรอให้เสียงข้างมากชัดเจนก่อนจึงเป็นเงื่อนไขบังคับ ไม่ใช่แค่พิธีการ และเป็นแม่แบบของการเปิดใช้ซอฟต์ฟอร์กแบบให้นักขุดส่งสัญญาณที่ Bitcoin ใช้ต่อมาอีกหลายครั้ง รวมถึง SegWit ในปี 2017 และ Taproot ในปี 2021
ข้อจำกัดที่ติดมาด้วย
ข้อแรกเป็นเรื่องความปลอดภัยของเครือข่าย BIP 16 อธิบายว่า Bitcoin จำกัดจำนวนการตรวจลายเซ็นต่อบล็อกไว้ที่ 20,000 ครั้ง เพื่อกันไม่ให้นักขุดที่ไม่หวังดีส่งบล็อกที่ต้องตรวจลายเซ็นเป็นแสนครั้ง แล้วได้เปรียบเริ่มขุดบล็อกถัดไปก่อน ขณะที่คนอื่นยังตรวจบล็อกนั้นไม่เสร็จ สคริปต์ที่ซ่อนอยู่ใน P2SH จึงต้องถูกนับจำนวนการตรวจลายเซ็นรวมเข้าไปในเพดานนี้ด้วย เอกสารออกแบบวิธีนับให้ทำได้เร็ว ด้วยการไล่อ่านสคริปต์ครั้งเดียวโดยไม่ต้องรันจริง
P2SH ไม่ได้ไร้ข้อจำกัด BIP 16 หัวข้อย่อยเรื่องเพดาน 520 ไบต์อธิบายว่า สคริปต์ที่เปิดเผยตอนใช้เงินต้องไม่ยาวเกิน 520 ไบต์ เพราะมันถูกส่งเข้าไปเหมือนข้อมูลก้อนหนึ่ง ซึ่งมีเพดานนี้อยู่แล้ว ผลคือแม้คำสั่งตรวจหลายลายเซ็นจะรับกุญแจได้ถึง 20 ดอก แต่ในทางปฏิบัติกระเป๋า P2SH ใช้กุญแจแบบย่อได้สูงสุด 15 ดอก เอกสารคิดให้ดูว่า 3 ไบต์ บวกกุญแจ 15 ดอกดอกละ 34 ไบต์ ได้ 513 ไบต์ ยังไม่เกิน 520
ภาพ: หัวข้อ 520-byte limitation on serialized script size ใน BIP 16 บน GitHub
อีกข้อคือความเป็นส่วนตัว ตอนล็อกเงินไม่มีใครรู้ว่าข้างหลังที่อยู่ขึ้นต้นด้วย 3 มีเงื่อนไขอะไร แต่พอใช้เงิน สคริปต์ทั้งหมดต้องถูกเปิดเผยขึ้นบล็อกเชน ใครก็รู้ทันทีว่าเป็นกระเป๋ากี่ลายเซ็น ใช้กุญแจกี่ดอก ปัญหาข้อนี้เป็นหนึ่งในเหตุผลที่ Taproot ถูกออกแบบมาในเกือบสิบปีต่อมา
ถูกใช้จริงแค่ไหน
ข้อมูลรายวันจาก mainnet.observer นับจำนวนเงินก้อนใหม่ที่ถูกล็อกด้วย P2SH กราฟนี้ใช้ค่าเดือนธันวาคมของแต่ละปี คิดเป็นสัดส่วนของเงินก้อนใหม่ทั้งหมด
0.0%
ยังแทบไม่มีคนใช้
0.5%
สูงสุดของช่วง
40.8%
3.5%
สิ่งแรกที่เห็นคือช่วงเริ่มต้นช้ามาก ในเดือนเมษายน 2012 ที่กฎมีผล ทั้งเดือนมีการใช้จ่ายเงินจาก P2SH แค่ 32 ครั้ง ถึงสิ้นปี 2014 สัดส่วนของเงินก้อนใหม่ที่ล็อกด้วย P2SH ก็ยังอยู่ที่ราว 0.5% กฎพร้อมตั้งแต่ปี 2012 แต่กระเป๋าเงินและบริการต่างๆ ใช้เวลาอีกหลายปีกว่าจะรองรับ จนสิ้นปี 2016 สัดส่วนขึ้นมาอยู่ที่ราว 16.5%
ช่วงที่สองขึ้นแรงเพราะเหตุผลที่ไม่เกี่ยวกับหลายลายเซ็นโดยตรง หลัง SegWit เปิดใช้ในเดือนสิงหาคม 2017 กระเป๋าจำนวนมากใช้ SegWit แบบห่อไว้ใน P2SH เพื่อให้กระเป๋ารุ่นเก่าที่ส่งเงินไปที่อยู่ bc1 ไม่ได้ยังส่งไปที่อยู่ขึ้นต้นด้วย 3 ได้ ข้อมูลชุดเดียวกันแสดงว่า การใช้จ่ายแบบ SegWit ห่อใน P2SH มีแค่ราว 12,000 ครั้งในเดือนสิงหาคม 2017 แต่เดือนธันวาคม 2018 ขึ้นเป็นกว่า 5.1 ล้านครั้ง สัดส่วน P2SH จึงขึ้นไปสูงสุดราว 40.8% ในเดือนธันวาคม 2020
ถ้าแยกการใช้จ่ายจาก P2SH ในเดือนธันวาคม 2018 ออกเป็นประเภท จะเห็นว่า P2SH แบบดั้งเดิมที่ไม่ได้ห่อ SegWit มีราว 1.74 ล้านครั้ง SegWit แบบกุญแจเดียวที่ห่อใน P2SH มีราว 5.16 ล้านครั้ง และ SegWit แบบสคริปต์ที่ห่อใน P2SH มีราว 1.28 ล้านครั้ง การใช้งานส่วนใหญ่ของ P2SH ในช่วงที่มันสูงที่สุดจึงเป็นกระเป๋าลายเซ็นเดียวที่ใช้ P2SH เป็นทางผ่านไปสู่ SegWit ไม่ใช่กระเป๋าหลายลายเซ็นอย่างที่ออกแบบไว้ตอนแรก
หลังจากนั้นก็ลดลงต่อเนื่อง เพราะกระเป๋าส่วนใหญ่เปลี่ยนไปใช้ที่อยู่ SegWit แบบตรงและ Taproot ที่ไม่ต้องห่อแล้ว เดือนสิงหาคม 2026 สัดส่วนเหลือราว 3.5%
แล้วกระเป๋าหลายลายเซ็นจริงๆ มีเท่าไร
สัดส่วน P2SH ข้างบนนับรวมการห่อ SegWit ด้วย ถ้าอยากดูเฉพาะกระเป๋าหลายลายเซ็นจริงๆ mainnet.observer มีข้อมูลอีกชุด นับการใช้จ่ายเงินที่ต้องตรวจหลายลายเซ็น เทียบกับการใช้จ่ายทั้งหมด
0.5%
สูงสุดของช่วง
16.1%
ล่าสุด
2.7%
ภาพนี้ชัดกว่า การใช้จ่ายแบบหลายลายเซ็นขึ้นไปสูงสุดราว 16% ในช่วงปี 2016 ถึง 2018 จากนั้นทรงตัวราว 10 ถึง 13% จนถึงปี 2022 แล้วลดลงเหลือราว 2.7% ในเดือนสิงหาคม 2026 ส่วนหนึ่งเพราะกระเป๋าหลายลายเซ็นรุ่นใหม่ย้ายไปใช้ SegWit แบบตรงหรือ Taproot ซึ่งบางแบบรวมลายเซ็นหลายคนเป็นลายเซ็นเดียวได้ แล้วจะไม่ถูกนับเป็นการใช้จ่ายหลายลายเซ็นในข้อมูลชุดนี้ ตัวเลขนี้จึงบอกได้ว่าการใช้หลายลายเซ็นแบบเดิมลดลง แต่ไม่ได้บอกว่าคนใช้กระเป๋าหลายคนดูแลน้อยลง
นี่คือจุดที่เรื่องของ P2SH เชื่อมกับ Taproot โดยตรง ปัญหาข้อใหญ่ของ P2SH คือพอใช้เงิน ทุกคนเห็นว่าเป็นกระเป๋ากี่ลายเซ็น Taproot แก้ด้วยการให้กุญแจหลายดอกรวมกันเป็นกุญแจเดียวด้วยลายเซ็น Schnorr ถ้าทุกฝ่ายตกลงกัน ลายเซ็นที่ขึ้นบล็อกเชนจะหน้าตาเหมือนลายเซ็นของคนคนเดียว หลักคิดที่ P2SH วางไว้ในปี 2012 ว่าคนรับเป็นคนกำหนดเงื่อนไข จึงถูกต่อยอดไปอีกขั้นว่า คนนอกไม่จำเป็นต้องรู้ด้วยซ้ำว่ามีเงื่อนไข
เรื่องนี้เกี่ยวกับคนที่ใช้ Bitcoin อย่างไร
สำหรับคนทั่วไป ประโยชน์ที่ใหญ่ที่สุดของ P2SH คือความปลอดภัยแบบไม่ต้องพึ่งกุญแจดอกเดียว กระเป๋าสองในสามลายเซ็นทำให้ต่อให้กุญแจหนึ่งดอกหายหรือถูกขโมย เงินก็ยังปลอดภัย และยังกู้คืนได้ด้วยกุญแจอีกสองดอก คนที่ถือเหรียญจำนวนมากมักใช้กุญแจแต่ละดอกเก็บในHardware Walletคนละเครื่อง และเก็บไว้คนละที่
ข้อควรรู้คือกระเป๋าหลายลายเซ็นดูแลยากกว่ากระเป๋าธรรมดามาก การกู้คืนต้องมีทั้งกุญแจครบตามจำนวน และข้อมูลว่ากระเป๋าตั้งค่าไว้อย่างไร ใช้กุญแจสาธารณะของใครบ้าง ถ้าเก็บแค่กุญแจแต่ไม่เก็บข้อมูลการตั้งค่า อาจกู้เงินคืนไม่ได้แม้จะมีกุญแจครบ ใครยังไม่แน่ใจเรื่องการแยกเก็บกุญแจ อ่านพื้นฐานได้ที่Hot Wallet vs Cold Wallet
อีกเรื่องคือรูปแบบที่อยู่ ที่อยู่ขึ้นต้นด้วย 3 ยังรับเงินได้ตามปกติ แต่ค่าธรรมเนียมตอนใช้จ่ายมักแพงกว่าที่อยู่แบบ SegWit ตรงหรือ Taproot เพราะข้อมูลที่ต้องเปิดเผยมากกว่า ถ้ากระเป๋าให้เลือก ที่อยู่ขึ้นต้นด้วย bc1 มักประหยัดกว่า
คำถามที่พบบ่อย
P2SH คืออะไร
คือรูปแบบการล็อกเงินที่คนส่งใส่แค่ค่า hash ของสคริปต์เงื่อนไข แล้วคนรับค่อยเปิดเผยสคริปต์เต็มตอนใช้เงิน กำหนดไว้ใน BIP 16 ของ Gavin Andresen
P2SH เริ่มใช้งานเมื่อไร
กฎใหม่มีผลกับบล็อกที่มีเวลาตั้งแต่วันที่ 1 เมษายน 2012 เป็นต้นไป ตามที่ BIP 16 ระบุ แผนแรกในเอกสารคือหลังวันที่ 15 กุมภาพันธ์ 2012 ถ้านักขุดส่งสัญญาณครบ 550 จาก 1,000 บล็อก
ทำไมที่อยู่ P2SH ขึ้นต้นด้วยเลข 3
เพราะ BIP 13 กำหนดไบต์กำกับรุ่นเป็นเลข 5 ซึ่งเมื่อแปลงด้วย Base58 แล้วตัวอักษรแรกจะเป็นเลข 3 เสมอ
กระเป๋า P2SH ใช้กุญแจได้กี่ดอก
ในทางปฏิบัติสูงสุด 15 ดอกสำหรับกุญแจแบบย่อ เพราะสคริปต์ที่เปิดเผยต้องไม่เกิน 520 ไบต์ ตามที่ BIP 16 คิดไว้
ข้อเสนออื่นที่แข่งกับ P2SH มีอะไรบ้าง
BIP 12 OP_EVAL ของ Gavin Andresen และ BIP 17 OP_CHECKHASHVERIFY ของ Luke Dashjr ทั้งสองฉบับมีสถานะ Closed
ทำไมการเปิดใช้ P2SH ถึงต้องให้นักขุดโหวต
เพราะเป็นซอฟต์ฟอร์กที่เพิ่มกฎตรวจใหม่ ถ้านักขุดไม่ถึงครึ่งใช้กฎใหม่ อาจมีบล็อกที่นักขุดสองกลุ่มเห็นต่างกันว่าถูกหรือผิด แล้วเครือข่ายแยกออกเป็นสองฝั่ง BIP 16 จึงขอให้นักขุดส่งสัญญาณด้วยข้อความ /P2SH/ ก่อน และตั้งเกณฑ์ไว้ที่ราว 55% ของบล็อกในหนึ่งสัปดาห์
ที่อยู่ขึ้นต้นด้วย 3 เป็นกระเป๋าหลายลายเซ็นเสมอไหม
ไม่ ที่อยู่ขึ้นต้นด้วย 3 บอกแค่ว่าเป็น P2SH ข้างหลังอาจเป็นกระเป๋าหลายลายเซ็น หรือกระเป๋าลายเซ็นเดียวที่ห่อ SegWit ไว้ก็ได้ ข้อมูลช่วงปี 2018 แสดงว่าแบบหลังมีมากกว่า
สรุป
P2SH แก้ปัญหาที่ฟังดูเล็กแต่สำคัญมาก คือทำให้คนส่งเงินไม่ต้องรู้ว่าคนรับตั้งเงื่อนไขอะไรไว้ แค่ส่งไปที่ที่อยู่สั้นๆ ที่ขึ้นต้นด้วยเลข 3 เงื่อนไขทั้งหมดเป็นเรื่องของคนรับ กว่าจะได้ใช้ต้องผ่านการแข่งกันของข้อเสนอสามตัว และการโหวตของนักขุดที่เลื่อนวันมีผลจากกลางเดือนกุมภาพันธ์ไปเป็นวันที่ 1 เมษายน 2012
ข้อมูลบนเชนบอกว่ากฎพร้อมใช้ไม่ได้แปลว่าคนจะใช้ทันที P2SH ใช้เวลาสามปีกว่าจะขึ้นไปถึงระดับที่เห็นได้ในข้อมูล แล้วโตสูงสุดจากบทบาทที่ไม่มีใครวางแผนไว้ตอนออกแบบ คือการห่อ SegWit ให้กระเป๋ารุ่นเก่าส่งเงินได้ ก่อนจะค่อยๆ ถูกแทนที่ด้วยรูปแบบใหม่ที่ประหยัดและเป็นส่วนตัวกว่า แต่หลักคิดที่ว่าคนรับเป็นคนกำหนดเงื่อนไขเอง ยังเป็นรากฐานของทุกรูปแบบที่มาหลังจากนั้น