Câu trả lời trực tiếp
So sánh các định dạng địa chỉ legacy, nested SegWit, native SegWit và Taproot, tiền tố, khả năng tương thích và giới hạn an toàn.
Hai địa chỉ Bitcoin đều có thể nhận BTC nhưng vẫn tạo ra các cấu trúc giao dịch khác nhau bên dưới. Một địa chỉ mainnet bắt đầu bằng 1, một địa chỉ bắt đầu bằng 3, một địa chỉ bc1q và một địa chỉ bc1p đều có thể là đích đến hợp lệ, nhưng chúng không nhất thiết đại diện cho cùng một script, mã hóa hoặc điều kiện chi tiêu trong tương lai.
Sự khác biệt đó dễ bị bỏ qua vì ví hiển thị địa chỉ như một chuỗi duy nhất. Bên dưới nó, địa chỉ cho phần mềm biết cách xây dựng đầu ra giao dịch. Khi đầu ra đó được xác nhận, nó trở thành UTXO mà sau này phải được chi tiêu theo các quy tắc script được mã hóa bởi đầu ra đó.
Do đó, câu hỏi thực tế không chỉ đơn giản là “Tiền tố nào mới hơn?” Mà là địa chỉ có thuộc mạng Bitcoin dự định hay không, nó đại diện cho loại đầu ra nào, phần mềm gửi có hỗ trợ định dạng đó hay không, và địa chỉ có thể—và không thể—cho bạn biết điều gì trước khi bạn ủy quyền thanh toán.
Địa chỉ Bitcoin đại diện cho điều gì
Địa chỉ Bitcoin không phải là tài khoản theo nghĩa ngân hàng. Nó không chứa bitcoin, không giữ khóa riêng tư hoặc cung cấp cái nhìn đầy đủ về số dư ví. Nó là một mã hóa dễ đọc giúp ví xây dựng một đầu ra giao dịch cụ thể.
Mối quan hệ đơn giản hóa là:
Địa chỉ Bitcoin
↓
Giải mã địa chỉ
↓
scriptPubKey
↓
Đầu ra giao dịch
↓
UTXO đã xác nhận
↓
Điều kiện chi tiêu trong tương laiKhi bạn gửi bitcoin, ví không di chuyển một đối tượng từ chuỗi địa chỉ này sang chuỗi địa chỉ khác. Nó tiêu thụ các UTXO hiện có làm đầu vào giao dịch và tạo ra các đầu ra mới. Địa chỉ đích cung cấp thông tin cần thiết để xây dựng một trong các đầu ra đó.
Đây là lý do tại sao định dạng địa chỉ lại quan trọng về mặt kỹ thuật. Địa chỉ P2PKH dẫn đến một script đầu ra khác với địa chỉ P2WPKH. Đầu ra Taproot P2TR lại khác nữa. Những đầu ra đó đều có thể đại diện cho bitcoin có thể chi tiêu, nhưng các điều kiện và cách tuần tự hóa được sử dụng khi chúng được chi tiêu không giống nhau.
Địa chỉ không phải là khóa riêng tư
Khóa riêng tư vẫn tách biệt với địa chỉ. Ví sử dụng vật liệu khóa riêng tư để tạo chữ ký hoặc dữ liệu witness theo yêu cầu của điều kiện chi tiêu. Việc công bố địa chỉ nhận không công bố khóa riêng tư.
Điều ngược lại cũng quan trọng: việc nhìn thấy một địa chỉ không chứng minh rằng một người cụ thể kiểm soát khóa tương ứng. Phân tích blockchain có thể quan sát các giao dịch và đầu ra, nhưng một chuỗi địa chỉ đơn lẻ không phải là bằng chứng nhận dạng.
Tại sao tồn tại nhiều định dạng
Bitcoin có nhiều định dạng địa chỉ vì hệ thống giao dịch đã phát triển trong khi vẫn duy trì khả năng tương thích với các đầu ra cũ. Các định dạng mới không thay thế các đầu ra cũ trên blockchain. Thay vào đó, chúng giới thiệu các cách bổ sung để thể hiện các điều kiện chi tiêu.
Bốn định dạng mà hầu hết người dùng gặp trên mainnet Bitcoin là:
- P2PKH cũ, thường được hiển thị với địa chỉ bắt đầu bằng
1. - P2SH, thường bắt đầu bằng
3; SegWit lồng nhau là một cách sử dụng quan trọng của P2SH, nhưng không phải là cách duy nhất. - Native SegWit, được mã hóa bằng Bech32 và thường bắt đầu bằng
bc1qcho witness phiên bản 0. - Taproot, được mã hóa bằng Bech32m và bắt đầu bằng
bc1pcho đầu ra P2TR witness phiên bản 1.
Thay đổi quan trọng không phải là hình thức của chuỗi. Mà là đích đến đã giải mã cho ví biết phải đặt gì trong đầu ra mới.
So sánh các loại địa chỉ Bitcoin
| Tên thường gọi | Tiền tố mainnet | Mã hóa | Đầu ra điển hình | Tiền tố cho bạn biết điều gì |
|---|---|---|---|---|
| Legacy | 1 | Base58Check | P2PKH | Họ phiên bản byte cho địa chỉ băm khóa công khai mainnet |
| P2SH (bao gồm SegWit lồng nhau) | 3 | Base58Check | P2SH; SegWit lồng là một trong những cấu trúc redeem-script có thể | Đích đến là P2SH, không phải chính xác redeem script bên trong nó |
| Native SegWit | bc1q | Bech32 | Witness v0, thường là P2WPKH hoặc P2WSH | Đích đến Bech32 mainnet witness-version-0 |
| Taproot | bc1p | Bech32m | P2TR | Đích đến Taproot mainnet witness-version-1 |
Bảng này hữu ích để nhận dạng, nhưng tiền tố không phải là mô tả đầy đủ về hành vi chi tiêu trong tương lai. Ví dụ rõ ràng nhất là một 3... địa chỉ: nó xác định P2SH, nhưng P2SH có thể cam kết với nhiều redeem script. SegWit lồng chỉ là một khả năng.
Địa chỉ Legacy P2PKH
Legacy pay-to-public-key-hash, hay P2PKH, là định dạng địa chỉ gắn liền nhất với phần mềm ví Bitcoin ban đầu. Trên mainnet, các địa chỉ Base58Check này thường bắt đầu bằng 1.
Địa chỉ đại diện cho một hash của khóa công khai. Khi một ví thanh toán đến đích đó, nó tạo ra một locking script P2PKH yêu cầu chữ ký hợp lệ và khóa công khai tương ứng khi output được chi tiêu.
OP_DUP
OP_HASH160
<20-byte public-key hash>
OP_EQUALVERIFY
OP_CHECKSIGDo đó, địa chỉ hiển thị không phải là script. Ví giải mã địa chỉ Base58Check, trích xuất phiên bản và payload, và xây dựng scriptPubKey thích hợp.
Output P2PKH vẫn là output Bitcoin hợp lệ. “Legacy” không có nghĩa là không hợp lệ hoặc tự động không an toàn. Sự khác biệt trở nên liên quan khi so sánh cấu trúc giao dịch: chi tiêu output P2PKH truyền thống đặt dữ liệu mở khóa trong input script thay vì sử dụng tuần tự hóa witness của SegWit.
Sự khác biệt đó có thể làm tăng trọng lượng giao dịch so với chi tiêu khóa SegWit thông thường. Nó không có nghĩa là thanh toán P2PKH tự động có một mức phí cụ thể. Số lượng input, số lượng output, mức phí được chọn và phần còn lại của giao dịch đã ký vẫn quyết định chi phí cuối cùng.
P2SH và SegWit lồng
Pay-to-script-hash, hay P2SH, chuyển một phần logic chi tiêu ra sau một hash. Địa chỉ P2SH mainnet sử dụng Base58Check và thường bắt đầu bằng 3.
Một output P2SH tiêu chuẩn đặt hash của redeem-script trong locking script:
OP_HASH160
<20-byte script hash>
OP_EQUALToàn bộ redeem script chỉ được cung cấp khi output được tiêu xài. Điều này tạo ra một công cụ tương thích quan trọng khi SegWit được giới thiệu: một chương trình witness SegWit có thể được đặt bên trong redeem script P2SH, cho phép người gửi hiểu về địa chỉ P2SH thông thường có thể trả cho một output mà sau này sẽ được tiêu xài bằng quy tắc SegWit.
Một cấu trúc một khóa phổ biến được gọi là P2SH-P2WPKH:
Địa chỉ P2SH
↓
hash của redeemScript
↓
redeemScript chứa một chương trình witness P2WPKH
↓
chữ ký và khóa công khai được cung cấp qua dữ liệu witness khi tiêu xàiTiền tố 3 không chứng minh SegWit
Đây là một trong những giới hạn quan trọng nhất của việc nhận dạng địa chỉ bằng mắt thường. Một địa chỉ bắt đầu bằng 3 cho bạn biết rằng điểm đến sử dụng phiên bản địa chỉ P2SH mainnet. Nó không tiết lộ toàn bộ redeem script trước khi output được tiêu xài.
P2SH đã tồn tại trước SegWit và có thể bao bọc các script khác. Việc coi mọi 3... địa chỉ là “địa chỉ SegWit” do đó quá rộng.
Ranh giới kỹ thuật: tiền tố xác định định dạng địa chỉ bên ngoài. Nó không chứng minh chính xác script ẩn sau hash P2SH.
Native SegWit và bc1q
Native SegWit loại bỏ lớp tương thích P2SH và đại diện trực tiếp chương trình witness. BIP 173 giới thiệu mã hóa Bech32 cho địa chỉ native SegWit.
Trên mainnet Bitcoin, phần có thể đọc được bởi con người là bc. Phiên bản witness 0 tạo ra các địa chỉ thường được nhận biết bởi phần đầu bc1q.
Hai output phổ biến của witness-version-0 là:
- P2WPKH: một chương trình witness 20-byte thường được sử dụng cho thanh toán ví một khóa.
- P2WSH: một chương trình witness 32-byte cam kết với một witness script.
Bản thân địa chỉ cung cấp cho ví phiên bản witness và chương trình witness. Đối với phiên bản witness 0, các tập lệnh đầu ra phổ biến có các dạng sau:
P2WPKH: OP_0 <20-byte key hash>
P2WSH: OP_0 <32-byte script hash>Đầu ra trực tiếp chứa chương trình witness thay vì một trình bọc P2SH. Khi UTXO được tiêu, chữ ký hoặc dữ liệu tập lệnh được yêu cầu bởi chương trình witness được cung cấp trong witness của giao dịch thay vì trong scriptSig kiểu P2PKH truyền thống.
Bech32 cũng thay đổi cách phát hiện lỗi
Bech32 không chỉ đơn thuần là một bảng chữ cái khác. Nó bao gồm một checksum được thiết kế cho họ địa chỉ này và tách phần mạng có thể đọc được của con người khỏi dữ liệu witness được mã hóa.
Chuỗi Bech32 không được trộn lẫn chữ hoa và chữ thường. Ví thường hiển thị địa chỉ Bech32 của mạng chính Bitcoin ở dạng chữ thường. Mã hóa hoàn toàn chữ hoa có thể hợp lệ theo đặc tả, nhưng trộn lẫn chữ hoa chữ thường là không hợp lệ.
Taproot và bc1p
Taproot giới thiệu pay-to-Taproot, hay P2TR, outputs. P2TR sử dụng witness version 1 với một chương trình witness 32-byte. Trên mainnet Bitcoin, địa chỉ kết quả bắt đầu bằng bc1p.
Witness version 1 trở lên sử dụng Bech32m thay vì checksum Bech32 gốc. BIP 350 giới thiệu thay đổi này sau khi xác định điểm yếu trong việc sử dụng hành vi checksum Bech32 gốc cho các phiên bản witness mới hơn.
Điều này đưa ra một quy tắc nhận dạng thực tế:
bc1q... → phiên bản witness 0 → Bech32
bc1p... → phiên bản witness 1 P2TR → Bech32mScript khóa P2TR tương ứng sử dụng witness version 1 và khóa đầu ra Taproot 32-byte:
OP_1 <32-byte Taproot output key>Một output P2TR cam kết với khóa đầu ra Taproot đó. Nó có thể được chi tiêu sau này thông qua key path hoặc, nếu một cây script đã được cam kết, thông qua một script path hợp lệ được tiết lộ.
Địa chỉ không tiết lộ path nào sẽ được sử dụng cuối cùng. Việc thấy bc1p cho bạn biết rằng output là P2TR. Nó không cho bạn biết liệu người chi tiêu trong tương lai sẽ sử dụng chữ ký key-path hay tiết lộ một script path.
Những Tiền Tố Bitcoin Thực Sự Cho Bạn Biết Điều Gì
Tiền tố hữu ích vì chúng cho phép con người nhanh chóng xác định họ địa chỉ và mạng lưới có khả năng. Chúng nên được coi là kiểm tra ban đầu, không phải là xác thực hoàn chỉnh.
| Ví dụ bắt đầu | Ý nghĩa mainnet có khả năng | Điều nó không chứng minh |
|---|---|---|
1... | Địa chỉ mainnet P2PKH | Chủ sở hữu, số dư hoặc danh tính người nhận |
3... | Địa chỉ mainnet P2SH | Rằng redeem script được lồng SegWit |
bc1q... | Địa chỉ native witness-version-0 | Liệu nó là P2WPKH hay P2WSH chỉ bằng tiền tố |
bc1p... | Địa chỉ witness-version-1 P2TR | Path chi tiêu Taproot nào sẽ được sử dụng sau này |
Tiền tố cũng không thể xác thực người đã đưa cho bạn địa chỉ. Một địa chỉ được mã hóa hoàn hảo, checksum hợp lệ vẫn có thể thuộc về người nhận sai.
Mạng Lưới Đến Trước Loại Địa Chỉ
Trước khi chọn giữa Legacy, SegWit hoặc Taproot, hãy xác nhận rằng địa chỉ thuộc về mạng lưới Bitcoin mà bạn định sử dụng.
Các địa chỉ họ Bech32 làm cho điều này hiển thị thông qua phần human-readable của chúng. BIP 173 định nghĩa bc cho mainnet Bitcoin và tb cho địa chỉ testnet Bitcoin. Phần human-readable do đó là một phần của xác thực mạng lưới, không phải trang trí.
Các họ địa chỉ Base58Check cũng sử dụng các byte phiên bản khác nhau giữa mainnet và test networks, mặc dù sự khác biệt ít rõ ràng hơn đối với người dùng chỉ nhìn vào chuỗi.
Ví tiền nên từ chối kết hợp mạng/địa chỉ không được hỗ trợ, nhưng trách nhiệm cuối cùng vẫn là xác nhận mạng lưới được hiển thị bởi ứng dụng gửi. Nhận dạng định dạng địa chỉ không thay thế cho việc xác minh mạng lưới.
Đối với bối cảnh giao dịch rộng hơn—inputs, outputs, xác nhận và lớp cơ sở Bitcoin—sử dụng Tài liệu tham khảo mạng Bitcoin.
Loại Địa Chỉ và Phí Giao Dịch
Người ta thường nghe rằng địa chỉ Bitcoin mới hơn “rẻ hơn.” Tuyên bố đó hữu ích về mặt định hướng trong một số so sánh, nhưng quá đơn giản để sử dụng như một quy tắc phí.
Địa chỉ được chọn bởi người nhận ảnh hưởng đến loại và kích thước tuần tự hóa của output được tạo ngày hôm nay. Quan trọng hơn, khi output đó được chi tiêu sau này, loại script của nó ảnh hưởng đến cấu trúc của input giao dịch tương ứng.
SegWit cũng thay đổi cách tính Weight giao dịch vì các byte witness được tính trọng số khác với các byte không phải witness. Do đó, một key spend Native SegWit phổ biến có cấu hình Weight khác với một spend Legacy P2PKH tương đương. Điều đó ảnh hưởng đến kích thước ảo khi UTXO được chi tiêu, nhưng nó vẫn không cố định tổng phí trước.
Cùng một số tiền BTC có thể dẫn đến chi phí tương lai khác nhau
Hãy xem xét hai người dùng mỗi người nhận cùng một số bitcoin. Một người nhận output P2PKH và người kia nhận output P2WPKH. Giá trị là giống hệt nhau. Cấu trúc input tương lai thì không.
Khi các UTXO đó được chi tiêu sau này, dữ liệu mở khóa của chúng được tuần tự hóa khác nhau. Điều đó thay đổi Weight giao dịch và do đó kích thước ảo. Ở cùng mức sat/vB, vSize khác nhau có nghĩa là tổng phí khác nhau.
Đây là một kịch bản kỹ thuật minh họa, không phải bản ghi giao dịch người dùng hoặc tuyên bố về một ví cụ thể.
Loại địa chỉ vẫn không không tự xác định phí cuối cùng. Một giao dịch có nhiều đầu vào SegWit hiệu quả có thể lớn hơn một giao dịch chỉ có một đầu vào Legacy. Số lượng đầu ra, chữ ký, đường dẫn script và mức phí được chọn cũng quan trọng.
Để biết mối quan hệ đầy đủ giữa Weight, kích thước ảo và sat/vB, hãy đọc cách hoạt động của phí giao dịch Bitcoin. Khi bạn cần ước tính cụ thể cho giao dịch thay vì so sánh khái niệm, hãy sử dụng Bitcoin Máy tính phí giao dịch.
Khả năng tương thích là kiểm tra của người gửi
Một địa chỉ Bitcoin hợp lệ không hữu ích cho quy trình thanh toán nếu ví gửi hoặc dịch vụ rút tiền không hiểu định dạng.
Sự khác biệt này đặc biệt quan trọng trong quá trình áp dụng Native SegWit và sau đó là Taproot. Mạng Bitcoin có thể nhận ra loại đầu ra trong khi các ứng dụng cũ thiếu hỗ trợ để tạo đích đến đó.
Khi dịch vụ từ chối địa chỉ bc1q hoặc bc1p địa chỉ, không thay đổi địa chỉ theo cách thủ công. Không xóa ký tự, thay đổi tiền tố hoặc chuyển đổi qua một trang web tùy ý. Sử dụng định dạng địa chỉ mà ví nhận của bạn thực sự tạo ra và người gửi hỗ trợ rõ ràng.
Gửi giữa các định dạng không phải là chuyển đổi
Bạn không cần ví Legacy để trả cho địa chỉ Legacy hoặc ví Taproot để trả cho địa chỉ Taproot theo nghĩa khớp định dạng nguồn và đích. Giao dịch gửi tiêu thụ bất kỳ UTXO nào được hỗ trợ mà ví chọn và tạo đầu ra mới cho script đích.
Câu hỏi liên quan là liệu phần mềm gửi có thể giải mã và xây dựng đầu ra đích được yêu cầu hay không.
Địa chỉ hợp lệ vẫn có thể sai
Tổng kiểm tra bắt một số lỗi phiên âm. Chúng không xác thực người nhận dự kiến.
Nếu phần mềm độc hại thay thế địa chỉ đã sao chép bằng một địa chỉ Bitcoin hợp lệ khác, bản thay thế có thể vượt qua xác thực tổng kiểm tra hoàn hảo. Định dạng kỹ thuật là hợp lệ; đích đến là sai.
Đây là lý do tại sao “ví đã chấp nhận địa chỉ” không phải là kiểm tra an toàn cuối cùng. Chấp nhận cho bạn biết rằng phần mềm đã nhận ra một đích đến hợp lệ hoặc được hỗ trợ. Nó không chứng minh địa chỉ đến từ đâu.
Xác minh trước khi gửi
Một quy trình xác minh hữu ích tách biệt xác thực định dạng khỏi xác thực người nhận.
- Xác nhận mạng. Đảm bảo ví hoặc dịch vụ đang gửi Bitcoin trên mạng Bitcoin dự kiến thay vì tài sản khác hoặc môi trường thử nghiệm.
- Đọc họ địa chỉ. A
1,3,bc1qhoặcbc1ptiền tố cung cấp cho bạn manh mối định dạng ban đầu. - Xác nhận hỗ trợ của người gửi. Dịch vụ rút tiền hoặc ví phải chấp nhận rõ ràng định dạng đích.
- Xác minh đích đến qua kênh đáng tin cậy. So sánh địa chỉ đầy đủ trên màn hình đáng tin cậy khi thực tế thay vì chỉ dựa vào một vài ký tự đầu và cuối.
- Xem lại màn hình giao dịch cuối cùng của ví. Xác nhận người nhận, số tiền, phí mạng và bất kỳ tiền thừa nào trước khi ký.
- Bảo vệ vật liệu riêng tư. Xác minh địa chỉ nhận không bao giờ yêu cầu bạn nhập cụm từ hạt giống hoặc khóa riêng tư vào một trang web.
Đối với các chuyển khoản lớn hoặc nhạy cảm về mặt hoạt động, các tổ chức thường thêm quy trình xác minh đích độc lập. Các quy trình đó là kiểm soát hoạt động, không phải là thuộc tính của một định dạng địa chỉ Bitcoin cụ thể.
Tái sử dụng địa chỉ là một vấn đề riêng biệt
Một địa chỉ Bitcoin không hết hạn ở cấp độ giao thức chỉ vì nó đã được sử dụng một lần. Nếu điều kiện chi tiêu tương ứng vẫn có thể kiểm soát, các khoản thanh toán trong tương lai đến cùng địa chỉ vẫn có thể tạo đầu ra hợp lệ.
Điều đó không làm cho việc tái sử dụng địa chỉ trở nên mong muốn. Tái sử dụng địa chỉ nhận có thể làm cho các giao dịch dễ liên kết hơn trên blockchain công khai và có thể giảm quyền riêng tư.
Câu hỏi về quyền riêng tư này tách biệt với việc địa chỉ là P2PKH, P2SH, P2WPKH hay P2TR. Một định dạng địa chỉ hiện đại không làm cho việc sử dụng lặp lại cùng một đích đến hiển thị trở nên riêng tư.
Giới hạn của xác thực địa chỉ
Xác thực định dạng trả lời một câu hỏi hẹp: liệu chuỗi có thể được giải mã như loại đích Bitcoin dự kiến theo các quy tắc địa chỉ liên quan hay không. Nó không xác thực người cung cấp nó, chứng minh quyền sở hữu khóa riêng tư, chứng minh tổng số dư của ví, đảm bảo rằng dịch vụ hỗ trợ định dạng hoặc xác định phí giao dịch cuối cùng.
Nó cũng không thể tiết lộ thông tin cố tình ẩn bởi cấu trúc đầu ra. Một địa chỉ P2SH không tiết lộ script redeem đầy đủ trước khi chi tiêu, và một địa chỉ P2TR không cho bạn biết trước liệu chi tiêu trong tương lai sẽ sử dụng đường dẫn khóa hay tiết lộ đường dẫn script. Hãy coi việc giải mã thành công là một kiểm tra trong quy trình thanh toán, không phải là bằng chứng rằng mọi giả định xung quanh là đúng.
Chọn định dạng nhận
Mặc định an toàn nhất là sử dụng địa chỉ được tạo bởi ví mà bạn thực sự kiểm soát thay vì tự xây dựng hoặc chuyển đổi địa chỉ theo cách thủ công.
Nếu ví nhận cung cấp nhiều loại địa chỉ, hãy sử dụng loại phù hợp với chính sách script dự kiến của ví và loại mà người gửi có thể giải mã. Địa chỉ P2WPKH phù hợp khi ví cố ý tạo đích key-hash witness-version-0. Địa chỉ P2TR phù hợp khi ví cố ý tạo đích Taproot và người gửi hỗ trợ nó. Các đích P2PKH hoặc P2SH cũ hơn vẫn hợp lệ khi quy trình làm việc yêu cầu các định dạng đó.
Không chọn định dạng chỉ vì ai đó tuyên bố nó “rẻ nhất.” Đầu ra bạn tạo hôm nay chỉ trở thành đầu vào khi nó được chi tiêu sau này, và chi phí cuối cùng của giao dịch tương lai đó phụ thuộc vào cấu trúc giao dịch đầy đủ và tỷ lệ phí.
Địa chỉ nên đến từ ví nhận. Người gửi nên hỗ trợ nó. Mạng lưới nên khớp. Ba kiểm tra đó quan trọng hơn việc theo đuổi một tiền tố riêng lẻ.
Câu hỏi thường gặp về địa chỉ Bitcoin
Sự khác biệt giữa bc1q và bc1p là gì?
bc1q thường là phần đầu của địa chỉ witness-version-0 mainnet Bitcoin được mã hóa bằng Bech32, chẳng hạn như P2WPKH hoặc P2WSH. bc1p xác định địa chỉ P2TR witness-version-1 mainnet được mã hóa bằng Bech32m.
Có phải mọi địa chỉ Bitcoin bắt đầu bằng 3 đều sử dụng SegWit?
Không. Một địa chỉ mainnet bắt đầu bằng 3 là địa chỉ P2SH. SegWit lồng nhau có thể sử dụng P2SH, nhưng P2SH có thể cam kết với các redeem script khác, vì vậy chỉ riêng tiền tố không chứng minh rằng đầu ra là SegWit lồng nhau.
Địa chỉ Bitcoin có phân biệt chữ hoa chữ thường không?
Địa chỉ Base58Check sử dụng bảng chữ cái phân biệt chữ hoa chữ thường. Mã hóa Bech32 và Bech32m không được trộn lẫn chữ hoa và chữ thường; ví Bitcoin thường hiển thị chúng ở dạng chữ thường. Không thay đổi chữ hoa chữ thường của địa chỉ theo cách thủ công.
Tôi có thể gửi Bitcoin từ loại địa chỉ này sang loại địa chỉ khác không?
Có, khi ví gửi hỗ trợ định dạng đích. Một giao dịch có thể chi tiêu một loại đầu vào được hỗ trợ và tạo một loại đầu ra được hỗ trợ khác. Tiền tố nguồn và đích không cần phải khớp.
Địa chỉ Bitcoin có hết hạn không?
Không có quy tắc giao thức nào làm cho địa chỉ Bitcoin thông thường hết hạn sau một ngày nhất định hoặc sau một lần thanh toán. Ví thường tạo địa chỉ nhận mới vì việc tái sử dụng địa chỉ có thể làm giảm quyền riêng tư, không phải vì các địa chỉ được tạo trước đó tự động trở nên không hợp lệ.
Tôi nên sử dụng loại địa chỉ Bitcoin nào?
Sử dụng địa chỉ được tạo bởi ví nhận cho mạng Bitcoin và loại script bạn định sử dụng, sau đó xác nhận rằng người gửi hỗ trợ định dạng đó. SegWit gốc phổ biến cho các khoản thanh toán hiện đại, trong khi Taproot phù hợp khi cả hai bên hỗ trợ P2TR. Không tự chuyển đổi định dạng địa chỉ này sang định dạng khác.
Nguồn Kỹ Thuật
Các mô tả định dạng địa chỉ ở trên dựa trên Đề xuất cải tiến Bitcoin và tài liệu Bitcoin Core. Các tài liệu tham khảo này xác định mã hóa địa chỉ, chương trình witness và hành vi script; chúng không chứng minh danh tính hoặc độ an toàn của một địa chỉ nhận cụ thể. Cách tiếp cận nguồn rộng hơn của BitcoinToolkit được mô tả trên Nguồn dữ liệu page.
- BIP 13: Định dạng địa chỉ cho pay-to-script-hash — chỉ định định dạng địa chỉ P2SH Base58Check.
- BIP 16: Thanh toán bằng Script Hash — xác định mô hình chi tiêu P2SH và đánh giá redeem-script.
- BIP 49: Sơ đồ dẫn xuất cho P2WPKH-lồng-trong-P2SH — ghi lại cấu trúc SegWit lồng nhau một khóa phổ biến được thảo luận trong hướng dẫn này.
- BIP 141: Segregated Witness — xác định chương trình witness, Weight giao dịch và ngữ nghĩa đầu ra SegWit.
- BIP 173: Định dạng địa chỉ Base32 cho đầu ra witness v0-16 gốc — giới thiệu mã hóa địa chỉ SegWit gốc Bech32.
- BIP 350: Định dạng Bech32m cho địa chỉ witness v1+ — xác định Bech32m và quy tắc checksum cho các phiên bản witness mới hơn.
- BIP 341: Taproot — xác định quy tắc đầu ra và chi tiêu Taproot, bao gồm witness version 1 P2TR.
- Bộ mô tả đầu ra Bitcoin Core — ghi lại các mô tả có cấu trúc về script đầu ra Bitcoin phổ biến và biểu thức khóa.
Nguồn
Tìm thấy lỗi? Báo cáo vấn đề nội dung hoặc đọc Chính sách sửa lỗi.