อธิบายประเภทที่อยู่ Bitcoin

คำตอบโดยตรง

เปรียบเทียบรูปแบบที่อยู่ legacy, nested SegWit, native SegWit และ Taproot, คำนำหน้า, ความเข้ากันได้ และขีดจำกัดด้านความปลอดภัย.

ที่อยู่ Bitcoin สองแห่งสามารถรับ BTC ได้ทั้งคู่ แต่ยังสร้างโครงสร้างธุรกรรมที่แตกต่างกันภายใต้ ที่อยู่ mainnet ที่ขึ้นต้นด้วย 1, อันหนึ่งขึ้นต้นด้วย 3, ที่อยู่ bc1q และที่อยู่ bc1p สามารถเป็นปลายทางที่ถูกต้องทั้งหมด แต่ไม่จำเป็นต้องแสดงถึงสคริปต์ การเข้ารหัส หรือเงื่อนไขการใช้จ่ายในอนาคตเดียวกัน.

ความแตกต่างนั้นมองข้ามได้ง่ายเพราะกระเป๋าเงินแสดงที่อยู่เป็นสตริงเดียว ภายใต้มัน ที่อยู่จะบอกซอฟต์แวร์วิธีสร้างเอาต์พุตธุรกรรม เมื่อเอาต์พุตนั้นได้รับการยืนยัน มันจะกลายเป็น UTXO ที่ต้องใช้จ่ายในภายหลังตามกฎสคริปต์ที่เข้ารหัสโดยเอาต์พุตนั้น.

คำถามเชิงปฏิบัติจึงไม่ใช่เพียงแค่ “คำนำหน้าไหนใหม่กว่า?” แต่เป็นว่าที่อยู่นั้นเป็นของเครือข่าย Bitcoin ที่ตั้งใจไว้หรือไม่, แทนประเภทเอาต์พุตใด, ซอฟต์แวร์ส่งรองรับรูปแบบนั้นหรือไม่, และที่อยู่สามารถบอกอะไรได้—และไม่ได้—ก่อนที่คุณจะอนุมัติการชำระเงิน.

ที่อยู่ Bitcoin แทนอะไร

ที่อยู่ Bitcoin ไม่ใช่บัญชีในความหมายของธนาคาร มันไม่มี bitcoin, ถือคีย์ส่วนตัว หรือให้มุมมองที่สมบูรณ์ของยอดคงเหลือในกระเป๋าเงิน มันคือการเข้ารหัสที่มนุษย์อ่านได้ซึ่งช่วยให้กระเป๋าเงินสร้างเอาต์พุตธุรกรรมเฉพาะ.

ความสัมพันธ์ที่เรียบง่ายคือ:

ที่อยู่ Bitcoin
        ↓
การถอดรหัสที่อยู่
        ↓
scriptPubKey
        ↓
เอาต์พุตธุรกรรม
        ↓
UTXO ที่ได้รับการยืนยัน
        ↓
เงื่อนไขการใช้จ่ายในอนาคต

เมื่อคุณส่ง bitcoin, กระเป๋าเงินไม่ได้ย้ายวัตถุจากสตริงที่อยู่หนึ่งไปยังอีกอันหนึ่ง มันใช้ UTXO ที่มีอยู่เป็นอินพุตธุรกรรมและสร้างเอาต์พุตใหม่ ที่อยู่ปลายทางให้ข้อมูลที่จำเป็นในการสร้างหนึ่งในเอาต์พุตเหล่านั้น.

นี่คือเหตุผลว่าทำไมรูปแบบที่อยู่จึงมีความสำคัญในทางเทคนิค ที่อยู่ P2PKH นำไปสู่สคริปต์เอาต์พุตที่แตกต่างจากที่อยู่ P2WPKH เอาต์พุต Taproot P2TR ก็แตกต่างอีกครั้ง เอาต์พุตเหล่านั้นทั้งหมดสามารถแทน bitcoin ที่ใช้จ่ายได้ แต่เงื่อนไขและการทำให้เป็นอนุกรมที่ใช้เมื่อใช้จ่ายไม่เหมือนกัน.

ที่อยู่ไม่ใช่คีย์ส่วนตัว

คีย์ส่วนตัวยังคงแยกจากที่อยู่ กระเป๋าเงินใช้เนื้อหาคีย์ส่วนตัวเพื่อสร้างลายเซ็นหรือข้อมูล witness ที่จำเป็นตามเงื่อนไขการใช้จ่าย การเผยแพร่ที่อยู่สำหรับรับไม่ได้เผยแพร่คีย์ส่วนตัว.

สิ่งที่ตรงกันข้ามก็สำคัญเช่นกัน: การเห็นที่อยู่ไม่ได้พิสูจน์ว่าบุคคลใดบุคคลหนึ่งควบคุมคีย์ที่เกี่ยวข้อง การวิเคราะห์ blockchain สามารถสังเกตธุรกรรมและเอาต์พุตได้ แต่สตริงที่อยู่เพียงอย่างเดียวไม่ใช่หลักฐานยืนยันตัวตน.

ทำไมจึงมีหลายรูปแบบ

Bitcoin มีรูปแบบที่อยู่หลายแบบเพราะระบบธุรกรรมมีการพัฒนาในขณะที่รักษาความเข้ากันได้กับเอาต์พุตเก่า รูปแบบใหม่ไม่ได้แทนที่เอาต์พุตเก่าบน blockchain แต่พวกเขาแนะนำวิธีการเพิ่มเติมในการแสดงเงื่อนไขการใช้จ่าย.

รูปแบบสี่แบบที่ผู้ใช้ส่วนใหญ่พบเจอบน Bitcoin mainnet คือ:

• P2PKH แบบเดิม, โดยทั่วไปแสดงด้วยที่อยู่ที่ขึ้นต้นด้วย 1.
• P2SH, โดยทั่วไปขึ้นต้นด้วย 3; nested SegWit เป็นหนึ่งในการใช้งานที่สำคัญของ P2SH แต่ไม่ใช่เพียงอย่างเดียว.
• เนทีฟ SegWit, เข้ารหัสด้วย Bech32 และโดยทั่วไปขึ้นต้นด้วย bc1q สำหรับ witness เวอร์ชัน 0.
• Taproot, เข้ารหัสด้วย Bech32m และขึ้นต้นด้วย bc1p สำหรับ witness เวอร์ชัน 1 เอาต์พุต P2TR.

การเปลี่ยนแปลงที่สำคัญไม่ใช่รูปลักษณ์ของสตริง แต่คือสิ่งที่ปลายทางที่ถอดรหัสแล้วบอกให้กระเป๋าเงินวางในเอาต์พุตใหม่.

เปรียบเทียบประเภทที่อยู่ Bitcoin

ชื่อสามัญ	คำนำหน้าเมนเน็ต	การเข้ารหัส	ผลลัพธ์ทั่วไป	สิ่งที่คำนำหน้าบอกคุณ
Legacy	1	Base58Check	P2PKH	ตระกูลเวอร์ชันไบต์สำหรับที่อยู่ public-key-hash ของเมนเน็ต
P2SH (รวมถึง nested SegWit)	3	Base58Check	P2SH; nested SegWit เป็นหนึ่งในโครงสร้าง redeem-script ที่เป็นไปได้	ปลายทางคือ P2SH ไม่ใช่ redeem script ที่แน่นอนภายในนั้น
เนทีฟ SegWit	bc1q	Bech32	Witness v0 โดยทั่วไปคือ P2WPKH หรือ P2WSH	ปลายทาง Bech32 witness-version-0 ของ Mainnet
Taproot	bc1p	Bech32m	P2TR	ปลายทาง Taproot witness-version-1 ของ Mainnet

ตารางนี้มีประโยชน์สำหรับการระบุ แต่คำนำหน้าไม่ใช่คำอธิบายที่สมบูรณ์ของพฤติกรรมการใช้จ่ายในอนาคต ตัวอย่างที่ชัดเจนที่สุดคือ 3... address: มันระบุ P2SH แต่ P2SH สามารถผูกมัดกับ redeem scripts ได้หลายแบบ Nested SegWit เป็นเพียงหนึ่งในความเป็นไปได้.

ที่อยู่ Legacy P2PKH

Legacy pay-to-public-key-hash หรือ P2PKH เป็นรูปแบบที่อยู่ที่เกี่ยวข้องกับซอฟต์แวร์กระเป๋าเงิน Bitcoin ในยุคแรก บน mainnet ที่อยู่ Base58Check เหล่านี้มักจะขึ้นต้นด้วย 1.

ที่อยู่แสดงถึงแฮชของคีย์สาธารณะ เมื่อกระเป๋าเงินจ่ายไปยังปลายทางนั้น มันจะสร้างสคริปต์ล็อก P2PKH ที่ต้องการลายเซ็นที่ถูกต้องและคีย์สาธารณะที่เกี่ยวข้องเมื่อใช้จ่ายเอาต์พุต.

OP_DUP
OP_HASH160

OP_EQUALVERIFY
OP_CHECKSIG

ดังนั้นที่อยู่ที่มองเห็นจึงไม่ใช่สคริปต์เอง กระเป๋าเงินจะถอดรหัสที่อยู่ Base58Check แยกรุ่นและเพย์โหลด แล้วสร้าง scriptPubKey ที่เหมาะสม.

เอาต์พุต P2PKH ยังคงเป็นเอาต์พุต Bitcoin ที่ถูกต้อง “Legacy” ไม่ได้หมายความว่าไม่ถูกต้องหรือไม่ปลอดภัยโดยอัตโนมัติ ความแตกต่างจะเกี่ยวข้องเมื่อเปรียบเทียบโครงสร้างธุรกรรม: การใช้จ่ายเอาต์พุต P2PKH แบบดั้งเดิมจะวางข้อมูลปลดล็อกในสคริปต์อินพุตแทนที่จะใช้การทำให้เป็นอนุกรม witness ของ SegWit.

ความแตกต่างนั้นสามารถเพิ่มน้ำหนักธุรกรรมเมื่อเทียบกับการใช้จ่ายคีย์ SegWit ทั่วไป มันไม่ได้หมายความว่าการชำระเงิน P2PKH มีค่าธรรมเนียมเฉพาะโดยอัตโนมัติ จำนวนอินพุต จำนวนเอาต์พุต อัตราค่าธรรมเนียมที่เลือก และส่วนที่เหลือของธุรกรรมที่ลงนามแล้วยังคงกำหนดต้นทุนสุดท้าย.

P2SH และ Nested SegWit

Pay-to-script-hash หรือ P2SH ย้ายส่วนหนึ่งของตรรกะการใช้จ่ายไปไว้เบื้องหลังแฮช ที่อยู่ P2SH บน mainnet ใช้ Base58Check และมักจะขึ้นต้นด้วย 3.

เอาต์พุต P2SH มาตรฐานวางแฮชของ redeem script ในสคริปต์ล็อก:

OP_HASH160

OP_EQUAL

สคริปต์ไถ่ถอนเต็มจะถูกระบุเมื่อผลลัพธ์ถูกใช้จ่ายเท่านั้น สิ่งนี้สร้างเครื่องมือความเข้ากันได้ที่สำคัญเมื่อเปิดตัว SegWit: โปรแกรมพยาน SegWit สามารถวางไว้ในสคริปต์ไถ่ถอน P2SH ทำให้ผู้ส่งที่เข้าใจที่อยู่ P2SH ทั่วไปสามารถจ่ายผลลัพธ์ที่จะถูกใช้จ่ายในภายหลังด้วยกฎ SegWit.

โครงสร้างคีย์เดียวทั่วไปเรียกว่า P2SH-P2WPKH:

ที่อยู่ P2SH
    ↓
แฮชของ redeemScript
    ↓
redeemScript มีโปรแกรมพยาน P2WPKH
    ↓
ลายเซ็นและคีย์สาธารณะถูกระบุผ่านข้อมูลพยานเมื่อใช้จ่าย

คำนำหน้า 3 ไม่ได้พิสูจน์ว่าเป็น SegWit

นี่เป็นหนึ่งในข้อจำกัดที่สำคัญที่สุดของการระบุที่อยู่ด้วยสายตา ที่อยู่ที่ขึ้นต้นด้วย 3 บอกคุณว่าปลายทางใช้เวอร์ชันที่อยู่ P2SH ของ mainnet มันไม่เปิดเผยสคริปต์ไถ่ถอนเต็มก่อนที่ผลลัพธ์จะถูกใช้จ่าย.

P2SH มีอยู่ก่อน SegWit และสามารถห่อหุ้มสคริปต์อื่น ๆ ได้ การปฏิบัติต่อทุก 3... ที่อยู่เป็น “ที่อยู่ SegWit” จึงกว้างเกินไป.

ขอบเขตทางเทคนิค: คำนำหน้าระบุรูปแบบที่อยู่ภายนอก มันไม่ได้พิสูจน์สคริปต์ที่แน่นอนที่ซ่อนอยู่หลังแฮช P2SH.

Native SegWit และ bc1q

Native SegWit ลบตัวห่อหุ้มความเข้ากันได้ของ P2SH และแสดงโปรแกรมพยานโดยตรง BIP 173 แนะนำการเข้ารหัส Bech32 สำหรับที่อยู่ Native SegWit.

บน Bitcoin mainnet ส่วนที่มนุษย์อ่านได้คือ bc. เวอร์ชันพยาน 0 สร้างที่อยู่ที่รู้จักกันทั่วไปโดยการขึ้นต้น bc1q.

ผลลัพธ์เวอร์ชันพยาน 0 ทั่วไปสองแบบคือ:

• P2WPKH: โปรแกรมพยาน 20 ไบต์ที่ใช้ทั่วไปสำหรับการชำระเงินกระเป๋าเงินคีย์เดียว.
• P2WSH: โปรแกรมพยาน 32 ไบต์ที่ผูกมัดกับสคริปต์พยาน.

ที่อยู่เองให้เวอร์ชันพยานและโปรแกรมแก่กระเป๋าเงิน สำหรับเวอร์ชันพยาน 0 สคริปต์ผลลัพธ์ทั่วไปมีรูปแบบเหล่านี้:

P2WPKH: OP_0 
P2WSH:  OP_0

เอาต์พุตมี witness program โดยตรงแทนที่จะเป็นตัวห่อ P2SH เมื่อ UTXO ถูกใช้ ข้อมูลลายเซ็นหรือสคริปต์ที่ witness program ต้องการจะถูกจัดหาใน witness ของธุรกรรมแทนที่จะเป็น scriptSig แบบ P2PKH ดั้งเดิม.

Bech32 ยังเปลี่ยนการตรวจจับข้อผิดพลาดด้วย

Bech32 ไม่ใช่แค่ตัวอักษรที่แตกต่างกัน มันรวม checksum ที่ออกแบบมาสำหรับตระกูลที่อยู่เหล่านี้และแยกส่วนเครือข่ายที่มนุษย์อ่านได้ออกจากข้อมูล witness ที่เข้ารหัส.

สตริง Bech32 ต้องไม่ผสมตัวพิมพ์ใหญ่และตัวพิมพ์เล็ก โดยปกติกระเป๋าเงินจะแสดงที่อยู่ Bech32 ของ Bitcoin mainnet เป็นตัวพิมพ์เล็ก การเข้ารหัสแบบตัวพิมพ์ใหญ่ทั้งหมดสามารถใช้ได้ตามข้อกำหนด แต่การผสมตัวพิมพ์ใหญ่และเล็กไม่ถูกต้อง.

Taproot และ bc1p

Taproot แนะนำ pay-to-Taproot หรือเอาต์พุต P2TR P2TR ใช้ witness version 1 พร้อม witness program ขนาด 32 ไบต์ บน Bitcoin mainnet ที่อยู่ผลลัพธ์จะเริ่มต้นด้วย bc1p.

Witness version 1 และสูงกว่าใช้ Bech32m แทน checksum Bech32 ดั้งเดิม BIP 350 แนะนำการเปลี่ยนแปลงนี้หลังจากพบจุดอ่อนในการใช้พฤติกรรม checksum Bech32 ดั้งเดิมสำหรับ witness version ที่ใหม่กว่า.

นี่ให้กฎการระบุที่ใช้งานได้จริง:

bc1q... → witness version 0 → Bech32
bc1p... → witness version 1 P2TR → Bech32m

สคริปต์ล็อก P2TR ที่เกี่ยวข้องใช้ witness version 1 และคีย์เอาต์พุต Taproot ขนาด 32 ไบต์:

OP_1

เอาต์พุต P2TR ผูกพันกับคีย์เอาต์พุต Taproot นั้น สามารถใช้จ่ายในภายหลังผ่าน key path หรือหากมีการผูกพันกับ script tree ก็สามารถใช้จ่ายผ่าน script path ที่เปิดเผยที่ถูกต้องได้.

ที่อยู่ไม่ได้เปิดเผยว่าจะใช้ path ใดในที่สุด การเห็น bc1p บอกคุณว่าเอาต์พุตเป็น P2TR ไม่ได้บอกว่าผู้ใช้จ่ายในอนาคตจะใช้ลายเซ็น key-path หรือเปิดเผย script path.

คำนำหน้า Bitcoin บอกอะไรคุณจริงๆ

คำนำหน้ามีประโยชน์เพราะช่วยให้มนุษย์ระบุตระกูลที่อยู่และเครือข่ายที่น่าจะเป็นได้อย่างรวดเร็ว ควรถือเป็นการตรวจสอบเบื้องต้น ไม่ใช่การตรวจสอบที่สมบูรณ์.

ตัวอย่างการขึ้นต้น	ความหมายหลักน่าจะเป็นบน mainnet	สิ่งที่มันไม่ได้พิสูจน์
1...	ที่อยู่ mainnet P2PKH	เจ้าของ ยอดคงเหลือ หรือตัวตนของผู้รับ
3...	ที่อยู่ mainnet P2SH	ว่า redeem script เป็น SegWit แบบซ้อน
bc1q...	ที่อยู่ native witness-version-0	ไม่ว่าจะเป็น P2WPKH หรือ P2WSH โดยดูจากคำนำหน้าเพียงอย่างเดียว
bc1p...	ที่อยู่ witness-version-1 P2TR	path การใช้จ่าย Taproot ใดจะถูกใช้ในภายหลัง

คำนำหน้าไม่สามารถยืนยันตัวตนของบุคคลที่ให้ที่อยู่แก่คุณได้ ที่อยู่ที่เข้ารหัสอย่างสมบูรณ์และตรวจสอบ checksum ถูกต้องก็ยังอาจเป็นของผู้รับที่ผิดได้.

เครือข่ายมาก่อนประเภทที่อยู่

ก่อนที่จะเลือกระหว่าง Legacy, SegWit หรือ Taproot ให้ยืนยันว่าที่อยู่นั้นเป็นของเครือข่าย Bitcoin ที่คุณตั้งใจจะใช้.

ที่อยู่ตระกูล Bech32 ทำให้มองเห็นได้ผ่านส่วนที่มนุษย์อ่านได้ BIP 173 กำหนด bc สำหรับ mainnet Bitcoin และ tb สำหรับที่อยู่ testnet Bitcoin ดังนั้นส่วนที่มนุษย์อ่านได้จึงเป็นส่วนหนึ่งของการตรวจสอบเครือข่าย ไม่ใช่การตกแต่ง.

ตระกูลที่อยู่ Base58Check ยังใช้ version bytes ที่แตกต่างกันระหว่างเครือข่าย mainnet และ test แม้ว่าความแตกต่างจะสังเกตเห็นได้น้อยกว่าสำหรับผู้ใช้ที่ดูเพียงสตริง.

กระเป๋าเงินควรปฏิเสธการรวมกันของเครือข่าย/ที่อยู่ที่ไม่รองรับ แต่ความรับผิดชอบสุดท้ายยังคงเป็นการยืนยันเครือข่ายที่แสดงโดยแอปพลิเคชันที่ส่ง การรู้จักรูปแบบที่อยู่ไม่ใช่สิ่งทดแทนการตรวจสอบเครือข่าย.

สำหรับบริบทธุรกรรมที่กว้างขึ้น—อินพุต เอาต์พุต การยืนยัน และเลเยอร์ฐาน Bitcoin—ใช้ ข้อมูลอ้างอิงเครือข่าย Bitcoin.

ประเภทที่อยู่และค่าธรรมเนียมธุรกรรม

เป็นเรื่องปกติที่จะได้ยินว่าที่อยู่ Bitcoin ที่ใหม่กว่านั้น “ถูกกว่า” ข้อความนั้นมีประโยชน์ในเชิงทิศทางในการเปรียบเทียบบางอย่าง แต่เรียบง่ายเกินไปที่จะใช้เป็นกฎค่าธรรมเนียม.

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

SegWit ยังเปลี่ยนการนับ Weight ของธุรกรรมเนื่องจาก witness bytes มีน้ำหนักแตกต่างจาก non-witness bytes ดังนั้นการใช้จ่ายคีย์ Native SegWit ทั่วไปจึงมีโปรไฟล์ Weight ที่แตกต่างจากการใช้จ่าย Legacy P2PKH ที่เทียบเคียงได้ สิ่งนี้ส่งผลต่อขนาดเสมือนเมื่อใช้จ่าย UTXO แต่ก็ยังไม่ได้กำหนดค่าธรรมเนียมทั้งหมดล่วงหน้า.

จำนวน BTC ที่เท่ากันสามารถนำไปสู่ต้นทุนในอนาคตที่แตกต่างกัน

พิจารณาผู้ใช้สองคนที่แต่ละคนได้รับ bitcoin ในจำนวนเท่ากัน คนหนึ่งได้รับเอาต์พุต P2PKH และอีกคนได้รับเอาต์พุต P2WPKH มูลค่าเท่ากัน โครงสร้างอินพุตในอนาคตไม่เท่ากัน.

เมื่อใช้จ่าย UTXO เหล่านั้นในภายหลัง ข้อมูลปลดล็อกของพวกมันจะถูกทำให้เป็นอนุกรมแตกต่างกัน สิ่งนี้เปลี่ยน Weight ของธุรกรรมและดังนั้นขนาดเสมือน ที่อัตรา sat/vB เท่ากัน vSize ที่แตกต่างกันหมายถึงค่าธรรมเนียมรวมที่แตกต่างกัน.

นี่คือสถานการณ์ทางเทคนิคเชิงอธิบาย ไม่ใช่บันทึกธุรกรรมของผู้ใช้หรือการอ้างสิทธิ์เกี่ยวกับกระเป๋าเงินเฉพาะ.

ประเภทที่อยู่ยังคง ไม่ กำหนดค่าธรรมเนียมสุดท้ายด้วยตัวเอง ธุรกรรมที่มีอินพุต SegWit ที่มีประสิทธิภาพจำนวนมากอาจมีขนาดใหญ่กว่าธุรกรรมที่มีอินพุต Legacy เพียงตัวเดียว จำนวนเอาต์พุต ลายเซ็น เส้นทางสคริปต์ และอัตราค่าธรรมเนียมที่เลือกก็มีความสำคัญเช่นกัน.

สำหรับความสัมพันธ์เต็มรูปแบบระหว่าง Weight ขนาดเสมือน และ sat/vB อ่าน วิธีที่ค่าธรรมเนียมธุรกรรม Bitcoin ทำงาน. เมื่อคุณต้องการประมาณการเฉพาะธุรกรรมมากกว่าการเปรียบเทียบเชิงแนวคิด ให้ใช้ เครื่องคำนวณค่าธรรมเนียมธุรกรรม Bitcoin.

ความเข้ากันได้คือการตรวจสอบผู้ส่ง

ที่อยู่ Bitcoin ที่ถูกต้องไม่มีประโยชน์ต่อขั้นตอนการชำระเงินหากกระเป๋าเงินผู้ส่งหรือบริการถอนเงินไม่เข้าใจรูปแบบ.

ความแตกต่างนี้สำคัญเป็นพิเศษในช่วงการนำ Native SegWit และต่อมา Taproot มาใช้ เครือข่าย Bitcoin สามารถรับรู้ประเภทเอาต์พุตได้ในขณะที่แอปพลิเคชันเก่าขาดการสนับสนุนสำหรับการสร้างปลายทางนั้น.

เมื่อบริการปฏิเสธที่อยู่ bc1q หรือ bc1p ห้ามแก้ไขที่อยู่ด้วยตนเอง ห้ามลบอักขระ เปลี่ยนคำนำหน้า หรือแปลงผ่านเว็บไซต์ตามอำเภอใจ ใช้รูปแบบที่อยู่ที่กระเป๋าเงินผู้รับของคุณสร้างขึ้นจริงและผู้ส่งรองรับอย่างชัดเจน.

การส่งระหว่างรูปแบบไม่ใช่การแปลง

คุณไม่จำเป็นต้องมีกระเป๋าเงิน Legacy เพื่อจ่ายที่อยู่ Legacy หรือกระเป๋าเงิน Taproot เพื่อจ่ายที่อยู่ Taproot ในแง่ของการจับคู่รูปแบบต้นทางและปลายทาง ธุรกรรมที่ส่งจะใช้ UTXO ที่รองรับซึ่งกระเป๋าเงินเลือกและสร้างเอาต์พุตใหม่สำหรับสคริปต์ปลายทาง.

คำถามที่เกี่ยวข้องคือซอฟต์แวร์ส่งสามารถถอดรหัสและสร้างเอาต์พุตปลายทางที่ร้องขอได้หรือไม่.

ที่อยู่ที่ถูกต้องยังอาจผิดได้

Checksum จับข้อผิดพลาดในการคัดลอกบางอย่าง แต่ไม่ได้ยืนยันตัวตนของผู้รับที่ตั้งใจไว้.

หากมัลแวร์แทนที่ที่อยู่ที่คัดลอกด้วยที่อยู่ Bitcoin ที่ถูกต้องอื่น การแทนที่นั้นสามารถผ่านการตรวจสอบ checksum ได้อย่างสมบูรณ์แบบ รูปแบบทางเทคนิคถูกต้อง แต่ปลายทางผิด.

นี่คือเหตุผลที่ “กระเป๋าเงินยอมรับที่อยู่” ไม่ใช่การตรวจสอบความปลอดภัยขั้นสุดท้าย การยอมรับบอกคุณว่าซอฟต์แวร์รู้จักปลายทางที่ถูกต้องหรือรองรับ แต่ไม่ได้พิสูจน์ว่าที่อยู่นั้นมาจากไหน.

ตรวจสอบก่อนส่ง

กระบวนการตรวจสอบที่มีประโยชน์แยกการตรวจสอบรูปแบบออกจากการตรวจสอบผู้รับ.

1. ยืนยันเครือข่าย. ตรวจสอบให้แน่ใจว่ากระเป๋าเงินหรือบริการส่ง Bitcoin บนเครือข่าย Bitcoin ที่ตั้งใจไว้ ไม่ใช่สินทรัพย์อื่นหรือสภาพแวดล้อมการทดสอบ.
2. อ่านตระกูลที่อยู่. A 1, 3, bc1q หรือ bc1p คำนำหน้าให้เบาะแสรูปแบบเบื้องต้น.
3. ยืนยันการสนับสนุนผู้ส่ง. บริการถอนเงินหรือกระเป๋าเงินต้องยอมรับรูปแบบปลายทางอย่างชัดเจน.
4. ตรวจสอบปลายทางผ่านช่องทางที่เชื่อถือได้. เปรียบเทียบที่อยู่ทั้งหมดบนจอแสดงผลที่เชื่อถือได้เมื่อทำได้ แทนที่จะพึ่งพาเฉพาะอักขระนำหน้าและท้ายสองสามตัว.
5. ตรวจสอบหน้าจอธุรกรรมสุดท้ายของกระเป๋าเงิน. ยืนยันผู้รับ จำนวนเงิน ค่าธรรมเนียมเครือข่าย และเงินทอนก่อนลงนาม.
6. ปกป้องข้อมูลส่วนตัว. การตรวจสอบที่อยู่ผู้รับไม่จำเป็นต้องให้คุณป้อน seed phrase หรือคีย์ส่วนตัวลงในเว็บไซต์.

สำหรับการโอนเงินจำนวนมากหรือที่ละเอียดอ่อนในการดำเนินงาน องค์กรต่างๆ มักเพิ่มขั้นตอนการตรวจสอบปลายทางอิสระ ขั้นตอนเหล่านั้นเป็นการควบคุมการดำเนินงาน ไม่ใช่คุณสมบัติของรูปแบบที่อยู่ Bitcoin เฉพาะ.

การใช้ที่อยู่ซ้ำเป็นปัญหาที่แยกต่างหาก

ที่อยู่ Bitcoin ไม่หมดอายุที่ระดับโปรโตคอลเพียงเพราะถูกใช้ครั้งเดียว หากเงื่อนไขการใช้จ่ายที่เกี่ยวข้องยังคงควบคุมได้ การชำระเงินในอนาคตไปยังที่อยู่เดียวกันยังคงสร้างเอาต์พุตที่ถูกต้องได้.

นั่นไม่ได้ทำให้การใช้ที่อยู่ซ้ำเป็นที่น่าพอใจ การใช้ที่อยู่รับซ้ำอาจทำให้ธุรกรรมเชื่อมโยงกันได้ง่ายขึ้นบนบล็อกเชนสาธารณะและลดความเป็นส่วนตัว.

คำถามความเป็นส่วนตัวนี้แยกจากการที่อยู่เป็น P2PKH, P2SH, P2WPKH หรือ P2TR รูปแบบที่อยู่สมัยใหม่ไม่ได้ทำให้การใช้ปลายทางที่มองเห็นเดียวกันซ้ำๆ เป็นส่วนตัว.

ข้อจำกัดของการตรวจสอบที่อยู่

การตรวจสอบรูปแบบตอบคำถามแคบๆ: สตริงสามารถถอดรหัสเป็นปลายทาง Bitcoin ประเภทที่คาดหวังภายใต้กฎที่อยู่ที่เกี่ยวข้องได้หรือไม่ ไม่ได้ยืนยันตัวตนของผู้ให้ที่อยู่ พิสูจน์ความเป็นเจ้าของคีย์ส่วนตัว พิสูจน์ยอดคงเหลือทั้งหมดของกระเป๋าเงิน รับประกันว่าบริการรองรับรูปแบบ หรือกำหนดค่าธรรมเนียมธุรกรรมสุดท้าย.

นอกจากนี้ยังไม่สามารถเปิดเผยข้อมูลที่ซ่อนโดยเจตนาจากการสร้างเอาต์พุต ที่อยู่ P2SH ไม่เปิดเผย redeem script เต็มก่อนการใช้จ่าย และที่อยู่ P2TR ไม่บอกคุณล่วงหน้าว่าการใช้จ่ายในอนาคตจะใช้เส้นทางคีย์หรือเปิดเผยเส้นทางสคริปต์ ปฏิบัติต่อการถอดรหัสที่สำเร็จเป็นหนึ่งในการตรวจสอบในกระบวนการชำระเงิน ไม่ใช่เป็นหลักฐานว่าข้อสมมติโดยรอบทั้งหมดถูกต้อง.

การเลือกรูปแบบการรับ

ตัวเลือกที่ปลอดภัยที่สุดคือการใช้ที่อยู่ที่สร้างโดยกระเป๋าเงินที่คุณควบคุมจริง แทนที่จะสร้างหรือแปลงที่อยู่ด้วยตนเอง.

หากกระเป๋าเงินผู้รับมีที่อยู่มากกว่าหนึ่งประเภท ให้ใช้ประเภทที่ตรงกับนโยบายสคริปต์ที่ตั้งใจของกระเป๋าเงิน และผู้ส่งสามารถถอดรหัสได้ ที่อยู่ P2WPKH เหมาะสมเมื่อกระเป๋าเงินสร้างปลายทาง key-hash witness-version-0 โดยตั้งใจ ที่อยู่ P2TR เหมาะสมเมื่อกระเป๋าเงินสร้างปลายทาง Taproot โดยตั้งใจ และผู้ส่งรองรับ ปลายทาง P2PKH หรือ P2SH ที่เก่ากว่ายังคงใช้ได้เมื่อเวิร์กโฟลว์ต้องการรูปแบบเหล่านั้น.

อย่าเลือกรูปแบบเพียงเพราะมีคนอ้างว่ามัน “ถูกที่สุด” ผลลัพธ์ที่คุณสร้างวันนี้จะกลายเป็นอินพุตเมื่อถูกใช้จ่ายในภายหลัง และต้นทุนสุดท้ายของธุรกรรมในอนาคตนั้นขึ้นอยู่กับโครงสร้างธุรกรรมทั้งหมดและอัตราค่าธรรมเนียม.

ที่อยู่ควรมาจากกระเป๋าเงินผู้รับ ผู้ส่งควรรองรับ เครือข่ายควรตรงกัน การตรวจสอบสามอย่างนี้สำคัญกว่าการไล่ตามคำนำหน้าเพียงอย่างเดียว.

คำถามที่พบบ่อยเกี่ยวกับที่อยู่ Bitcoin

ความแตกต่างระหว่าง bc1q และ bc1p คืออะไร?

bc1q โดยทั่วไปคือจุดเริ่มต้นของที่อยู่ mainnet witness-version-0 ของ Bitcoin ที่เข้ารหัสด้วย Bech32 เช่น P2WPKH หรือ P2WSH. bc1p ระบุที่อยู่ P2TR witness-version-1 ของ mainnet ที่เข้ารหัสด้วย Bech32m.

ทุกที่อยู่ Bitcoin ที่ขึ้นต้นด้วย 3 ใช้ SegWit หรือไม่?

ไม่ ที่อยู่ mainnet ที่ขึ้นต้นด้วย 3 คือที่อยู่ P2SH SegWit แบบซ้อนสามารถใช้ P2SH ได้ แต่ P2SH สามารถผูกมัดกับ redeem script อื่นๆ ได้ ดังนั้นคำนำหน้าเพียงอย่างเดียวไม่ได้พิสูจน์ว่าเอาต์พุตเป็น SegWit แบบซ้อน.

ที่อยู่ Bitcoin ตัวพิมพ์ใหญ่เล็กมีความสำคัญหรือไม่?

ที่อยู่ Base58Check ใช้ตัวอักษรที่คำนึงถึงตัวพิมพ์ใหญ่เล็ก การเข้ารหัส Bech32 และ Bech32m ต้องไม่ผสมตัวพิมพ์ใหญ่และตัวพิมพ์เล็ก กระเป๋าเงิน Bitcoin ปกติจะแสดงเป็นตัวพิมพ์เล็ก อย่าเปลี่ยนตัวพิมพ์ของที่อยู่ด้วยตนเอง.

ฉันสามารถส่ง Bitcoin จากที่อยู่ประเภทหนึ่งไปยังอีกประเภทหนึ่งได้หรือไม่?

ได้ เมื่อกระเป๋าเงินผู้ส่งรองรับรูปแบบปลายทาง ธุรกรรมสามารถใช้จ่ายอินพุตประเภทหนึ่งที่รองรับ และสร้างเอาต์พุตประเภทอื่นที่รองรับ คำนำหน้าต้นทางและปลายทางไม่จำเป็นต้องตรงกัน.

ที่อยู่ Bitcoin หมดอายุหรือไม่?

ไม่มีกฎโปรโตคอลใดทำให้ที่อยู่ Bitcoin ปกติหมดอายุหลังจากวันที่กำหนดหรือหลังการชำระเงินหนึ่งครั้ง กระเป๋าเงินมักสร้างที่อยู่รับใหม่เพราะการใช้ที่อยู่ซ้ำอาจลดความเป็นส่วนตัว ไม่ใช่เพราะที่อยู่ที่สร้างไว้ก่อนหน้านี้จะไม่ถูกต้องโดยอัตโนมัติ.

ฉันควรใช้ที่อยู่ Bitcoin ประเภทใด?

ใช้ที่อยู่ที่สร้างโดยกระเป๋าเงินผู้รับสำหรับเครือข่าย Bitcoin และประเภทสคริปต์ที่คุณตั้งใจจะใช้ จากนั้นยืนยันว่าผู้ส่งรองรับรูปแบบนั้น SegWit แบบเนทีฟเป็นเรื่องปกติสำหรับการชำระเงินสมัยใหม่ ในขณะที่ Taproot เหมาะสมเมื่อทั้งสองฝ่ายรองรับ P2TR อย่าแปลงรูปแบบที่อยู่หนึ่งเป็นอีกรูปแบบหนึ่งด้วยตนเอง.

แหล่งข้อมูลทางเทคนิค

คำอธิบายรูปแบบที่อยู่ข้างต้นอ้างอิงจาก Bitcoin Improvement Proposals และเอกสาร Bitcoin Core ข้อมูลอ้างอิงเหล่านี้กำหนดการเข้ารหัสที่อยู่ โปรแกรม witness และพฤติกรรมสคริปต์ แต่ไม่ได้พิสูจน์ตัวตนหรือความปลอดภัยของที่อยู่รับเฉพาะ แนวทางการอ้างอิงที่กว้างขึ้นของ BitcoinToolkit อธิบายไว้ใน แหล่งข้อมูล page.

• BIP 13: รูปแบบที่อยู่สำหรับ pay-to-script-hash — ระบุรูปแบบที่อยู่ P2SH แบบ Base58Check.
• BIP 16: จ่ายไปยังสคริปต์แฮช — กำหนดโมเดลการใช้จ่าย P2SH และการประเมิน redeem-script.
• BIP 49: โครงร่างการสร้างสำหรับ P2WPKH ซ้อนใน P2SH — บันทึกโครงสร้าง SegWit แบบซ้อนคีย์เดียวทั่วไปที่กล่าวถึงในคู่มือนี้.
• BIP 141: วิทเนสแบบแยก — กำหนดโปรแกรม witness ธุรกรรม Weight และความหมายของเอาต์พุต SegWit.
• BIP 173: รูปแบบที่อยู่ Base32 สำหรับเอาต์พุต witness v0-16 แบบเนทีฟ — แนะนำการเข้ารหัสที่อยู่ SegWit แบบเนทีฟ Bech32.
• BIP 350: รูปแบบ Bech32m สำหรับที่อยู่ witness v1+ — กำหนด Bech32m และกฎ checksum สำหรับเวอร์ชัน witness ที่ใหม่กว่า.
• BIP 341: Taproot — กำหนดกฎเอาต์พุตและการใช้จ่าย Taproot รวมถึง P2TR witness version 1.
• Bitcoin Core ตัวอธิบายเอาต์พุต — บันทึกคำอธิบายโครงสร้างของสคริปต์เอาต์พุต Bitcoin ทั่วไปและนิพจน์คีย์.

แหล่งข้อมูล

1. BIP 13: รูปแบบที่อยู่ P2SH
2. BIP 141: วิทเนสแบบแยก
3. BIP 173: ที่อยู่ SegWit แบบเนทีฟ Bech32
4. BIP 350: Bech32m
5. BIP 341: Taproot
6. Bitcoin Core ตัวอธิบายเอาต์พุต

พบข้อผิดพลาด? รายงานปัญหาด้านเนื้อหา หรืออ่าน นโยบายการแก้ไข.