Tổng quan về các loại địa chỉ Bitcoin

Tác giả: Anony, BTC Study

Khi người dùng tiếp xúc với Bitcoin, họ thường gặp phải khái niệm về "Địa chỉ". Khi bạn cố gắng nhận thanh toán Bitcoin, bạn cần cung cấp địa chỉ của mình. Khi kiểm tra xem khoản thanh toán đã được nhận trong block explorer hay chưa, địa chỉ cụ thể thường được sử dụng làm điều kiện tìm kiếm.

Bạn có thể nghĩ: "Địa chỉ này tương đương với một tài khoản ngân hàng trong thế giới Bitcoin và có thể được sử dụng để nhận Bitcoin." Nhưng cách hiểu này có thể vẫn khiến bạn bối rối khi gặp một số tình huống trong quá trình sử dụng ví. Ví dụ: khi bạn sử dụng ví phần mềm Bitcoin lần đầu tiên, nó có thể yêu cầu bạn chọn một "loại" địa chỉ, chẳng hạn như: "Bech32 (SegWit)", "P2PKH", "Nested-SegWit (P2SH)", v.v. Ngay cả khi bạn muốn chuyển sang ví phần mềm khác, điều đó sẽ khiến bạn lo sợ: ví phần mềm mới có thể cung cấp cho bạn một bộ địa chỉ Bitcoin hoàn toàn khác với ví phần mềm ban đầu; bạn nên làm gì lúc này?

Bài viết này nhằm giải thích hơi sâu về khái niệm địa chỉ Bitcoin và các loại địa chỉ nhằm giúp người đọc giải quyết các vấn đề có thể gặp phải trong quá trình tự động giữ Bitcoin Một số vấn đề gặp phải bao gồm nhưng không giới hạn ở việc lựa chọn loại địa chỉ và những sự cố có thể xảy ra trong quá trình di chuyển ví phần mềm.

Chương cuối sẽ tập trung mô tả đặc điểm và tính kinh tế của các địa chỉ khác nhau mà độc giả có thể tiếp xúc nếu bạn không quan tâm đến chi tiết kỹ thuật; , hoặc chỉ muốn nhanh chóng để xác minh thông tin, bạn có thể bỏ qua chương cuối cùng; nhưng nếu bạn muốn lập kế hoạch cho một phương pháp tự lưu giữ, bạn nên đọc lại từ đầu.

Nói một cách đơn giản, địa chỉ Bitcoin thực sự là kết quả của quá trình mã hóa (dịch) đặc biệt của dữ liệu chính được sử dụng trong các tập lệnh Bitcoin được tiêu chuẩn hóa. Phương pháp mã hóa làm cho nó trở nên đặc biệt; phù hợp hơn cho việc phân phối và cung cấp khả năng nhắc nhở các lỗi và sự khác biệt trong nền kinh tế của nó đến từ sự khác biệt về nền kinh tế của tập lệnh Bitcoin cơ bản.

Tập lệnh Bitcoin được tiêu chuẩn hóa

Như chúng ta đã biết, Bitcoin là một loại tiền điện tử chạy trong mạng ngang hàng. Trong khi phát triển Bitcoin, Satoshi Nakamoto đã thiết kế một hình thức tồn tại cho loại tiền tệ được biết đến với cái tên “UTXO”. Định dạng này làm cho quỹ Bitcoin không giống như tiền nằm trong tài khoản này sang tài khoản khác mà giống như một tấm séc độc lập nối tiếp một tài khoản khác. Những "kiểm tra" này ghi lại hai thông tin chính: mệnh giá của số tiền (bằng "sats"); và khóa công khai của tập lệnh (scriptPubkey), được sử dụng để xác định các trường hợp mà số tiền có thể được chi tiêu. Khóa công khai của tập lệnh giống như một ổ khóa cần có một khóa cụ thể để mở.

Satoshi Nakamoto nhận ra rằng nếu chúng ta có thể tùy chỉnh các ổ khóa thông minh thì Bitcoin có thể được sử dụng linh hoạt hơn trong các tình huống khác nhau. Do đó, anh ấy cũng đã thiết kế một ngôn ngữ lập trình có tên là "Bitcoin Script" và chế độ xác minh giao dịch dựa trên UTXO, do đó, chúng ta có thể viết một chương trình được sử dụng làm khóa chung của tập lệnh và khi chi tiêu số tiền liên quan, nó có thể dựa trên đó; các thủ tục được xác nhận.

Sự đổi mới này mang lại một khó khăn thực tế: khi một giao dịch được truyền bá trong mạng ngang hàng, nút nhận giao dịch trước tiên sẽ thực hiện một số công việc xác minh. Nếu ngôn ngữ lập trình và lập trình có lỗ hổng cố hữu cho phép các nút gặp sự cố trong quá trình xác thực giao dịch thì các giao dịch khai thác lỗ hổng này có thể được sử dụng để làm sập toàn bộ mạng. Làm cách nào để đạt được sự cân bằng giữa việc phổ biến giao dịch miễn phí và tính bảo mật của mạng?

Ngoài việc cố tình hạn chế tính linh hoạt của Tập lệnh Bitcoin, Satoshi Nakamoto còn nghĩ ra một cách: chuyển đổi một số tập lệnh được biết là đủ ngắn gọn và sẽ không gây ra lỗi Được xác định là "Tập lệnh Bitcoin được tiêu chuẩn hóa" ^[1] ;Khi chi tiền bằng cách sử dụng tập lệnh như vậy, giao dịch được coi là "giao dịch Bitcoin tiêu chuẩn" và có thể lan truyền mà không bị cản trở trên mạng. Ngược lại, nếu tập lệnh tiêu chuẩn hóa như vậy không được sử dụng, ngay cả khi giao dịch hợp lệ, nó chỉ có thể được gửi trực tiếp cho người khai thác, những người sẽ đóng gói nó thành các khối và khai thác chúng, sau đó lan truyền ra toàn bộ mạng. Điều này hạn chế các giao dịch có thể gây ra sự cố bảo mật lan truyền trong mạng và gây ra sự cố nút.

Có hai tập lệnh Bitcoin được tiêu chuẩn hóa được triển khai sớm nhất: "P2PKH" và "P2PK"; như tên cho thấy, chúng đặt khóa chung vào khóa chung của tập lệnh ( hoặc hàm băm của khóa chung), yêu cầu các giao dịch chi tiền để cung cấp chữ ký của khóa chung đó (khóa riêng cơ bản).

Khóa công khai của tập lệnh P2PKH giống như thế này:

OP_DUP OP_HASH160 55ae51684c43435da751ac8d2173b2652eb64105 OP_EQUALVERIFY OP_CHECKSIG

(từ trang web khoa học Bitcoin nổi tiếng: tìm hiểu cho tôi về bitcoin)

Khái niệm về địa chỉ

Các tập lệnh được tiêu chuẩn hóa cho phép hệ thống Bitcoin có các chức năng cơ bản (cá nhân có thể giữ Bitcoin và bắt đầu thanh toán bằng tiền điện tử cho người khác bằng cách giữ khóa riêng). Tuy nhiên, đó vẫn là dữ liệu được thiết kế cho máy tính - đối tượng phải hiểu các chuỗi này chính là máy tính. Máy tính không nhạy cảm với độ dài của chuỗi và sẽ không mắc lỗi khi sao chép dữ liệu. Và mọi người thì ngược lại về nhiều mặt.

Vấn đề là mọi người, với tư cách là người dùng hệ thống này, phải xử lý dữ liệu này: khi một người nhận được khoản thanh toán Bitcoin, những gì TA yêu cầu là Người kia bên gửi quỹ Bitcoin tới tập lệnh Bitcoin do TA kiểm soát (hoặc TA có thể mở khóa thành công); ngoài ra, khi TA muốn giữ tiền của mình trong thời gian dài, TA có thể cần phải sao lưu Bitcoin của chính mình; kịch bản.

Chúng ta nên làm gì vào lúc này? Một chuỗi dài như trên rõ ràng là không phù hợp để truyền tải (quá dài), cũng như không phù hợp để sao lưu (dễ sao chép sai).

Chúng tôi đã đề cập trước đó rằng các tập lệnh phù hợp với hầu hết mọi người đều được tiêu chuẩn hóa. Việc tiêu chuẩn hóa này có nghĩa là hai tập lệnh chỉ có một điểm khác biệt ở một chỗ. dữ liệu khóa: Đối với hai tập lệnh P2PKH, điểm khác biệt duy nhất là các giá trị băm khóa công khai được ghi lại là khác nhau. Do đó, khi nhận thanh toán, chúng tôi chỉ cần cung cấp giá trị băm này và loại tập lệnh (đó là tập lệnh P2PKH) là đủ. Người trả tiền (phần mềm) sẽ sử dụng thông tin này để khôi phục tập lệnh Bitcoin hoàn chỉnh và gửi Bitcoin đến đúng địa điểm trong giao dịch.

Hơn nữa, (Satoshi Nakamoto, người quen thuộc với kỹ thuật, đã nhận ra), chúng ta không thể chuyển dạng thập lục phân của giá trị băm này (55ae51684c43435da751ac8d2173b2652eb64105 , 40 ký tự). Với sự trợ giúp của các phương pháp mã hóa được thiết kế đặc biệt, chúng ta có thể chuyển đổi nó thành dạng ngắn hơn, dễ đọc hơn.

Đây là "địa chỉ": dữ liệu được mã hóa mang thông tin quan trọng cho phép chúng tôi khôi phục chính xác tập lệnh Bitcoin.

Phương pháp mã hóa

Base58

"Base58" [2]  Đây là một phương pháp mã hóa được phát minh bởi Satoshi Nakamoto, được sửa đổi từ phương thức mã hóa nổi tiếng "Base64". Bộ ký tự của Base64 bao gồm: tất cả các số và chữ hoa, chữ thường và hai ký hiệu ("+" và "/"); Satoshi Nakamoto đã xóa số 0, chữ hoa I và O, chữ l thường và các ký hiệu khỏi nó, và nó trở thành Base58.

Việc xóa này là có chủ ý. Bản tự báo cáo của Satoshi Nakamoto là:

Tại sao lại sử dụng base58 thay vì base64?

• Không 0OIl được sử dụng vì các ký tự này trông giống nhau và có thể được sử dụng để tạo các tài khoản trông gần giống nhau.

• Không dễ để mọi người chấp nhận điều đó có các chữ cái trong số tài khoản và các ký tự không phải là số.

• Nếu bạn không sử dụng dấu chấm câu, trong E-Mail thường không bị gián đoạn do ngắt dòng.

• Nhấp đúp để chọn toàn bộ chuỗi. Vì chỉ có chữ và số.

– Satoshi Nakamoto, Bitcoin v0. (base58.h)

Địa chỉ cần được khôi phục về tập lệnh Bitcoin. Do đó, chỉ cần sai một ký tự, số tiền có thể được gửi đến tập lệnh Bitcoin hoàn toàn khác (có thể là tập lệnh hoàn toàn không thể mở khóa!) , dẫn đến mất tiền; thậm chí tệ hơn, nếu cho phép những ký tự khó hiểu như vậy, phần mềm độc hại có thể lặng lẽ thay thế địa chỉ của bạn bằng một địa chỉ trông giống nhau nhưng thực tế lại bị kẻ tấn công kiểm soát, khiến bạn mất tiền khi nhận thanh toán.

Do đó, những cân nhắc của Satoshi Nakamoto là hoàn toàn có lý.

Trước khi thực hiện mã hóa Base58, chúng ta cũng cần thêm mã loại làm tiền tố cho dữ liệu chính (chẳng hạn như giá trị băm trong tập lệnh P2PKH ở trên), và với 4 byte đầu tiên của kết quả của hai thao tác SHA256 liên tiếp của dữ liệu chính của tiền tố được sử dụng làm hậu tố.

• Tiền tố có thể mô tả nhanh chóng loại và mục đích của dữ liệu một cách chính xác nhờ vào phần bổ sung; của tiền tố, dữ liệu Loại giống nhau sẽ luôn xuất hiện với cùng phần đầu trong kết quả được mã hóa Base58. Đây là lý do tại sao chúng ta chỉ cần nhìn vào phần đầu của địa chỉ Bitcoin để biết đó là loại địa chỉ nào.

• Hậu tố có thể đóng vai trò là tổng kiểm tra: nếu bạn nhập địa chỉ có lỗi phiên mã vào phần mềm, phần mềm sẽ Cảnh báo rằng bạn có thể đã mắc lỗi (mặc dù bạn không thể biết mình đã mắc lỗi ở đâu).

Nghĩa là, trước khi bắt đầu mã hóa, chúng ta cần tạo một chuỗi như thế này:

Nhập mã + dữ liệu khóa + SHA256 (SHA256 (mã nhập + dữ liệu khóa)) [0:4] ("+" ở đây Nó có nghĩa là nối chuỗi)

Với P2PKH ở trên Lấy tập lệnh làm ví dụ, trước tiên chúng ta cần thêm tiền tố  00 vào dữ liệu chính (55ae51684c43435da751ac8d2173b2652eb64105); sau đó chạy hai phép tính SHA256 liên tiếp trên dữ liệu này; 4 byte đầu tiên (hex 8 ký tự, 96ab3cb1), làm hậu tố, nhận  0055ae51684c43435da751ac8d2173b2652eb6410596ab3cb1. Cuối cùng, chạy mã hóa Base58, chúng ta nhận được: 18p3G8gQ3oKy4U9EqnWs7UZswdqAMhE3r8.

Chuỗi này không chỉ chứa thông tin chính được sử dụng trong tập lệnh Bitcoin (giá trị băm khóa công khai) mà còn giải thích cách sử dụng nó ( Tiền tố  1  chỉ ra rằng nó cần được khôi phục về tập lệnh P2PKH), nó cũng có chức năng phát hiện lỗi phiên mã và nó vẫn chỉ có 34 ký tự, ngắn hơn giá trị băm ban đầu.

Bech32

"Bech32" được tài trợ bởi BIP 0173 [3]< /a> Phương pháp mã hóa được xác định, hai tác giả của BIP này là Pieter Wuille và Greg Maxwell. Tuy nhiên, mã hóa này cũng có nguồn gốc riêng: "Bech" dùng để chỉ "BCH" [4], là một phương pháp được phát triển bởi ba nhà toán học vào năm 1959 và 1960. Thuật toán mã hóa sửa lỗi tuần hoàn được phát minh vào năm 2001 (tên BCH xuất phát từ họ của ba nhà toán học này). Còn “32” có nghĩa là bộ ký tự của phương pháp mã hóa này chỉ có 32 ký tự: chữ và số tiếng Anh viết thường, không bao gồm số “1”, các chữ cái “b”, “i” và “o”.

Việc xem xét BIP này là tận dụng cơ hội nâng cấp "SegWit" để cung cấp hai tập lệnh chuẩn hóa mới "P2WPKH" và "P2WSH" Địa chỉ sử dụng phương pháp mã hóa mới.

Ở phần đầu BIP 0173, các tác giả đã chỉ ra những điểm chưa đạt yêu cầu của Base58:

• Base58 sử dụng cả chữ cái tiếng Anh viết hoa và viết thường, khiến dữ liệu của nó không thể sử dụng chế độ "bảng chữ cái số" nhỏ hơn khi được vẽ thành mã QR , chỉ lớn hơn ". dữ liệu byte" có thể được sử dụng người mẫu.

• Việc sử dụng cả chữ hoa và chữ thường cũng gây khó khăn cho việc sao chép, gõ trên bàn phím di động và đọc to.

• Việc kiểm tra tổng yêu cầu hai thao tác SHA256 liên tiếp, tốc độ chậm và không có chức năng xác định lỗi.

• Hầu hết các phương pháp mã hóa có thể xác định lỗi chỉ phù hợp với các tình huống trong đó kích thước bộ ký tự là lũy thừa nguyên tố và 58 không phải là quyền lực hàng đầu.

• Giải mã Base58 phức tạp hơn và hoạt động chậm hơn.

Vì vậy, phương pháp mới này của Bech32 chỉ sử dụng chữ và số viết thường khi cần thiết (chẳng hạn như vẽ mã QR), những điều này các chữ cái có thể được thay đổi thành tất cả chữ hoa để thể hiện nhỏ gọn hơn. Đồng thời, Bech32 còn có khả năng xác định lỗi: nó không chỉ có thể phát hiện bạn đã sao chép lỗi mà còn chỉ ra những từ bạn đã sao chép sai (khả năng tìm lỗi này tốt hơn nhiều so với Base58).

Trên thực tế, thuật toán BCH còn có chức năng "sửa lỗi": nó không chỉ có thể chỉ ra những chữ số bạn sao chép sai mà còn chỉ ra đó là chữ số nào nên có tính cách. Tuy nhiên, các tác giả của BIP 0173 đã phát hiện ra những nguy hiểm cố hữu của nó: một mặt, việc tăng cường chức năng sửa lỗi sẽ làm suy yếu chức năng định vị lỗi; mặt khác, nếu người dùng quá tin tưởng vào khả năng sửa lỗi của phần mềm; phần mềm có thể đánh lừa người dùng. Dữ liệu không chính xác đã nhập sẽ được sửa thành dữ liệu "hợp lệ nhưng vô dụng" - mặc dù là một phần dữ liệu được mã hóa BCH, nó hợp lệ, tuy nhiên, người nhận thanh toán có thể không kiểm soát được tập lệnh Bitcoin. thậm chí không phải thứ mà bất cứ ai cũng có thể kiểm soát được. Điều này cực kỳ nguy hiểm. Vì vậy, BIP 0173 thận trọng nhắc nhở: "Ngoài việc nhắc nhở người dùng những ký tự nào có thể đã bị sao chép sai, phần mềm không nên triển khai khả năng sửa lỗi (đưa ra gợi ý sửa)".

Ngoài ra, Bech32 tuân theo mẫu mã hóa Base58:

• Bech32 Sẽ có là một đoạn ở đầu dữ liệu "Dữ liệu có ý nghĩa (hrp)" tương tự như tiền tố trong Base58, có thể cho biết đây là loại dữ liệu gì.

• hrp Có Nhiều ký tự được sử dụng hơn 32; do đó, Bech32 cũng sử dụng số "1" làm dấu phân cách để phân tách hrp và dữ liệu thực tế cần giải mã.

• Ngoài Bitcoin, còn có nhiều dự án khác cũng sử dụng Bech32; dữ liệu của các dự án khác nhau sử dụng hrp để phân biệt lẫn nhau; . Đây là danh sách các HRP đã đăng ký, rất thú vị (nhưng chỉ thú vị thôi) [5].

• Bech32 cũng thiết kế tổng kiểm tra chiếm 6 ký tự cuối cùng của dữ liệu được mã hóa.

Giả sử chúng ta sử dụng chính xác giá trị băm khóa công khai giống như trong trường hợp trên, tập lệnh P2WPKH của nó sẽ như thế này: < code>0 55ae51684c43435da751ac8d2173b2652eb64105 (vâng, nó đơn giản và trừu tượng hơn P2PKH ban đầu); Địa chỉ được mã hóa Bech32 là: bc1q2kh9z6zvgdp4mf634jxjzuajv5htvsg9ulykp8, dài 42 ký tự.

Bech32m

"Bech32m" được tài trợ bởi BIP 0350 ^{[6]< /a>} Phương thức mã hóa được xác định. Nó được đề xuất vì các nhà phát triển đã phát hiện ra lỗ hổng trong mã hóa Bech32:

Khi ký tự cuối cùng là "p", hãy chèn trước ký tự Hoặc xóa bất kỳ số "q" nào sẽ không gây ra lỗi tổng kiểm tra thì cơ chế tổng kiểm tra sẽ hoàn toàn vô dụng.

Nếu không thêm tập lệnh Bitcoin chuẩn hóa nào nữa, vấn đề này có thể được giải quyết dễ dàng: cả địa chỉ P2WPKH và địa chỉ P2WSH đều có độ dài nhất định, chỉ cần thêm xác minh độ dài . Tuy nhiên, vì trong tương lai chúng tôi sẽ thêm các tập lệnh chuẩn hóa mới có độ dài địa chỉ có thể thay đổi nên cần phải khắc phục vấn đề này.

Bech32m khắc phục sự cố này bằng cách thay đổi một tham số trong trình tạo tổng kiểm tra Bech32.

Hiện tại, Bech32m chỉ được sử dụng để mã hóa địa chỉ của tập lệnh "P2TR" được thêm vào khi nâng cấp "Taproot". Nó có thể được sử dụng trong việc mã hóa địa chỉ của các tập lệnh được tiêu chuẩn hóa khác trong tương lai.

Kinh tế

Sau khi chúng tôi hiểu rằng một địa chỉ là một đại diện đặc biệt của tập lệnh Bitcoin được tiêu chuẩn hóa và loại địa chỉ thực sự đến từ loại tập lệnh Bitcoin được tiêu chuẩn hóa, tại sao các loại địa chỉ khác nhau lại có tính kinh tế khác nhau - khi chi tiêu Ở đó có thể có giá phí xử lý khác nhau - vấn đề có thể được giải quyết dễ dàng. Điều này là do các tập lệnh Bitcoin khác nhau có tính kinh tế khác nhau.

Để duy trì tính phân cấp và bảo mật của mạng, kích thước khối của Bitcoin bị giới hạn và có những tập lệnh có thể làm cho khối lượng giao dịch nhỏ hơn. thuận lợi.

Về vấn đề này, thay đổi lớn nhất chắc chắn là soft fork “SegWit” được kích hoạt vào năm 2017. Mặc dù SegWit mang đến hai tập lệnh chuẩn hóa mới "P2WPKH" và "P2WSH", nhưng nó cũng thiết kế chế độ xác minh giao dịch mới cho hai tập lệnh này:

Trong các tập lệnh Bitcoin cũ, dữ liệu (chẳng hạn như chữ ký điện tử) được sử dụng cho quá trình xác minh được xác định bởi khóa chung của tập lệnh sẽ được đặt trong giao dịch (trường scriptSignature ) ; Vấn đề về "Tính dễ tan chảy của giao dịch"  ^[7], cản trở chúng tôi sử dụng tập lệnh Bitcoin để lập trình các ứng dụng nhiều bên và thậm chí khiến ví hoàn toàn không thể theo dõi các giao dịch.

Chế độ xác minh giao dịch của Segregated Witness sẽ đặt phần dữ liệu này ra bên ngoài giao dịch (trường nhân chứng  và , Segregated Witness giới thiệu một đơn vị mới để đo khối lượng ("byte ảo (vByte)"). Dữ liệu được đặt trong trường nhân chứng sẽ được giảm giá khi đo khối lượng (đây là một thiết kế có chủ ý, nhằm làm cho các Giao dịch của Segregated Witness tiết kiệm hơn so với giao dịch truyền thống).

Kết quả cuối cùng là các tập lệnh loại SegWit P2WPKH và P2WSH có tính kinh tế tốt hơn đáng kể so với các tập lệnh truyền thống P2PKH và P2SH: một mặt, sự cô lập Tập lệnh công khai mặt khác, khóa của tập lệnh nhân chứng ngắn gọn hơn; mặt khác, chữ ký của tập lệnh truyền thống được đặt trong giao dịch và chữ ký của tập lệnh nhân chứng tách biệt được đặt bên ngoài giao dịch. Ngay cả khi khối lượng dữ liệu giống nhau. vByte của cái sau nhỏ hơn.

Đây là bảng minh họa lượng không gian mà các loại tập lệnh khác nhau chiếm khi được sử dụng làm đầu vào và đầu ra của giao dịch.

- Ảnh từ:Optech Limited Weekly · Đang chờ xác nhận   ;-

Sau đó, đây là công cụ tính khối lượng giao dịch có thể cho bạn biết khối lượng giao dịch ở các mức khác nhau của một loại tập lệnh nhất định sẽ dẫn đến kết quả là bao nhiêu TRONG .

Lưu ý: Khi xem xét tính kinh tế, bạn không thể chỉ so sánh kích thước của tập lệnh khi được sử dụng làm đầu vào, vì nói chung, các giao dịch Bitcoin sẽ có "đầu ra thay đổi" ” (Số tiền bạn đóng góp cho một giao dịch thường lớn hơn số tiền thanh toán, do đó bạn sẽ chuyển một số tiền về cho chính mình). Đầu ra thay đổi thường sẽ sử dụng cùng loại tập lệnh với địa chỉ thanh toán của ví này.

Loại địa chỉ

Phần này sẽ giới thiệu các đặc điểm và tính kinh tế của các loại địa chỉ khác nhau mà người dùng có thể tiếp xúc.

P2PKH

• Sử dụng Base58 Phương pháp mã hóa. Bắt đầu bằng số "1" và thường dài 34 ký tự.

• Dành cho ví chữ ký đơn.

• Nền kinh tế kém.

• Ví dụ (giống như trên): 18p3G8gQ3oKy4U9EqnWs7UZswdqAMhE3r8

P2SH

• Sử dụng mã hóa Base58. Bắt đầu bằng số "3" và thường dài 34 ký tự.

• Địa chỉ P2SH mà người dùng thường tiếp xúc nhất thực chất là một tập lệnh có tên "Nested SegWit (P2SH)", địa chỉ, tên có nghĩa là "tập lệnh P2SH đóng gói tập lệnh Nhân chứng tách biệt".

• Có thể đã đạt được Kiểu đóng gói này là khả năng của chính P2SH, nhưng mục đích cơ bản của việc xác định kiểu đóng gói này là giải quyết vấn đề tương thích của phần mềm ví. Vì địa chỉ Segregated Witness sử dụng phương thức mã hóa mới nên phần mềm ví không triển khai phương thức mới sẽ nhận ra địa chỉ Segregated Witness là đầu vào không chính xác và không thể khôi phục tập lệnh Bitcoin hợp lệ từ địa chỉ đó. Tập lệnh Nested SegWit P2SH cung cấp một sự thỏa hiệp thích hợp: ví của người trả tiền (bất kể nó có được nâng cấp hay không) sẽ hiểu địa chỉ đó là địa chỉ P2SH thông thường, sau đó khôi phục tập lệnh P2SH và xây dựng chính xác giao dịch của người nhận sau đó; tiêu tiền, bạn có thể thu được một số lợi ích do Segwit mang lại (với phần mềm ví hỗ trợ Segwit).

• Khi cả hai đều là ví chữ ký đơn, nền kinh tế sẽ tốt hơn P2PKH.

• Có thể được sử dụng trong ví đa chữ ký (có hoặc không có tính năng Segregated Witness).

• Ví dụ: 38Y2PBD1mihxtoVncaSz3oC2vRrjNF8sA2 (Tập lệnh P2SH này đóng gói tập lệnh P2PKH giống như trên, mặc dù điều này Không có lợi ích gì )

P2WPKH

• Kịch bản SegWit gốc. Sử dụng mã hóa Bech32, bắt đầu bằng số và chữ cái "bc1q" và dài 42 ký tự.

• Dành cho ví chữ ký đơn.

• Nền kinh tế tốt hơn đáng kể so với P2PKH và tốt hơn Nested SegWit P2SH.

• Ví dụ (giống như trên): bc1q2kh9z6zvgdp4mf634jxjzuajv5htvsg9ulykp8

P2WSH

• Kịch bản SegWit gốc. Sử dụng mã hóa Bech32, bắt đầu bằng số và chữ cái "bc1q" và dài 62 ký tự.

• Thường được sử dụng trong ví đa chữ ký.

• Khi được sử dụng làm ví đa chữ ký, nền kinh tế sẽ tốt hơn đáng kể so với P2SH.

• Ví dụ: bc1q56cuwyqlmq64aq0y3c8swd8a9gefe4wf7faxe2uyatyahfrly5aq0e6mfc (Tập lệnh P2WSH này đóng gói tập lệnh P2PKH giống như trên, mặc dù điều này Không có lợi ích gì )

P2TR

• Kịch bản SegWit gốc (Taproot là "SegWit v1"). Sử dụng mã hóa Bech32m, bắt đầu bằng "bc1p" và dài 62 ký tự.

• Có thể được sử dụng cho cả ví chữ ký đơn và ví đa chữ ký.

• Là ví một chữ ký, nền kinh tế tốt hơn P2WPKH một chút, nhưng hầu như không có sự khác biệt (ở đây giả định rằng đầu vào và đầu ra thay đổi là chi phí vốn có của giao dịch; càng sử dụng nhiều đầu vào thì lợi thế của P2TR càng lớn).

• Khi được sử dụng làm ví đa chữ ký, với sự trợ giúp của một số thuật toán tổng hợp chữ ký Schnorr, nền kinh tế thậm chí còn có thể tốt hơn P2WSH. Nhưng tại thời điểm viết bài (tháng 11 năm 2024), phần mềm ví hiếm khi triển khai các thuật toán tổng hợp như vậy vì tính phức tạp trong tương tác của các thuật toán này.

• Sự khác biệt chính giữa P2TR và các tập lệnh tiêu chuẩn Bitcoin trước đây là tập lệnh gốc phân biệt giữa người dùng ví chữ ký đơn và các chức năng tập lệnh nâng cao ("hợp đồng thông minh"), cái trước sẽ sử dụng tập lệnh băm khóa công khai, trong khi cái sau (bao gồm các thiết bị tiên tiến như thiết bị đa chữ ký và kênh Lightning) sẽ sử dụng tập lệnh băm tập lệnh đổi thưởng P2TR lần đầu tiên được thống nhất. chúng tôi không thể lấy được từ tập lệnh/địa chỉ Việc sử dụng nó có thể được suy ra trực tiếp từ hình thức bên ngoài của nó. Vì vậy, P2TR sẽ có quyền riêng tư tốt hơn về lâu dài.

• Tính đến thời điểm hiện tại, không phải tất cả các ví đều hỗ trợ địa chỉ P2TR (nhưng hầu hết tất cả các ví đều hỗ trợ P2WPKH và P2WSH). Phạm vi lựa chọn và khả năng di chuyển của người dùng tương đối hạn chế. Ngoài ra, việc hỗ trợ cài đặt đa chữ ký dựa trên P2TR thậm chí còn thưa thớt.

• Ví dụ (được chọn ngẫu nhiên): bc1pxy5r3slcqc2nhc0r5698gmsqwruenj9c8pzmsy5cedp3649wyktstc6z3c

Kết luận

Một địa chỉ đại diện cho một tập lệnh Bitcoin cụ thể; tập lệnh Bitcoin như vậy được tiêu chuẩn hóa và có thể được khôi phục hoàn toàn dựa trên thông tin trong địa chỉ. Các phương pháp mã hóa đặc biệt được sử dụng để làm cho địa chỉ gọn hơn và có các tính năng kiểm tra lỗi phiên âm. Tính kinh tế của các loại địa chỉ khác nhau xuất phát từ tính kinh tế của các tập lệnh Bitcoin được tiêu chuẩn hóa đằng sau chúng.

Phụ lục A. Bộ mô tả

Trong phần "Khái niệm về Địa chỉ", chúng tôi đã đề cập rằng có hai trường hợp mà người dùng có thể cần một bản ghi tập lệnh nhỏ gọn và đáng tin cậy: kịch bản thanh toán (giao hàng) và kịch bản lưu ký dài hạn.

Trong phần "Phương pháp mã hóa", chúng ta có thể thấy rằng thiết kế của các phương pháp mã hóa này chủ yếu dựa trên quá trình phân phối chứ không phải dựa trên kịch bản lưu trữ dài hạn. Vì vậy, địa chỉ nên được lưu như thế nào trong kịch bản lưu ký?

May mắn thay, giờ đây chúng ta có một cách thích hợp để biểu diễn một tập hợp các địa chỉ (chứ không phải một), đó là bộ mô tả đầu ra "output (address) description" "output descriptor ".

Kể từ khi Bitcoin ra đời và sự xuất hiện của khái niệm địa chỉ, công nghệ và thói quen bảo mật của quyền lưu ký tự trị đã được cải thiện rất nhiều. Một cải tiến lớn là cái gọi là "ví xác định phân cấp (HD)". Ý tưởng là sử dụng một phần tài liệu bí mật để suy ra nhiều khóa riêng theo thuật toán ngẫu nhiên xác định, sau đó lấy ra nhiều địa chỉ, sao cho trên một địa chỉ. tay nó có thể đáp ứng yêu cầu "không sử dụng lại" thói quen bảo mật cũng có thể giảm bớt gánh nặng sao lưu khóa riêng tư nhiều nhất có thể.

Bộ mô tả cũng dựa trên khái niệm này. Cách tiếp cận của nó là thể hiện loại địa chỉ và các bước để tạo tập hợp địa chỉ này ở dạng văn bản thuần túy, cộng với Tổng kiểm tra đại tràng. Ví dụ:

wpkh([8b47f816/84h/0h/0h]xpub6C8vwWQ[...] NgW2SnfL /<0;1>/*)#c38kz2nr

Từ văn bản trên, chúng ta có thể thấy rằng nó đại diện cho một tập hợp địa chỉ P2WPKH và khóa chung được sử dụng trong tập hợp địa chỉ này là từ dấu vân tay ;8b47f816 Khóa công khai chính dựa trên 84h/0h/0h BIP32 Bắt nguồn từ đường dẫn phái sinh; và sử dụng đường dẫn phái sinh của  0  và  1  để phân biệt địa chỉ thanh toán và địa chỉ thay đổi. Cuối cùng, c38kz2nr là tổng kiểm tra, có thể được sử dụng để xác minh xem có bất kỳ lỗi phiên âm nào hay không.

Một chuỗi như vậy rất thích hợp cho việc lưu trữ lâu dài và cũng rất phù hợp cho việc di chuyển ví, vì nó đã mô tả đầy đủ quá trình tạo ra bộ địa chỉ này .

Chú thích cuối trang

1. https://en.bitcoin.it/wiki/Script #Script_examples ↩

2. https://learnmeabitcoin.com/Technical/keys/base58/ ↩

3. https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki ↩

4. https://en.wikipedia.org/wiki/BCH_code ↩

5. https://github.com /satoshilabs/slips/blob/master/slip-0173.md ↩

6. https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki ↩

7. ht tps://www.btcstudy.org/2022/10/07/segregated-witness-benefits/#%E4%BF%AE%E5%A4%8D%E7%86%94%E8%9E%8D%E6% 80%A7%E9%97%AE%E9%A2%98 ↩