Cập nhật nghiên cứu: 2026-10-03. Trọng tâm đã chuyển từ shhhhh sang giao thức BIP352 theo yêu cầu Grand Master. Nghiên cứu chỉ đọc; không kết nối ví, ký giao dịch, chạy ví hay mã của dự án.
1. Kết luận chính
Silent Payments là một cải tiến thực chất cho việc nhận Bitcoin: công bố một địa chỉ lâu dài nhưng mỗi lần thanh toán tạo ra một output Taproot khác nhau. Người quan sát không thể chỉ lấy địa chỉ công bố để tra toàn bộ dòng tiền như với địa chỉ Bitcoin bị tái sử dụng. Giao thức không cần giao dịch thông báo riêng và không tạo thêm loại tài sản. Đổi lại, người nhận phải tìm khoản thanh toán bằng cách quét dữ liệu giao dịch. BIP352
Ba kết luận quyết định cách đánh giá:
- Giá trị cốt lõi là kết hợp trải nghiệm nhận tiền với quyền riêng tư. Địa chỉ nhận có thể nằm trên website hoặc hồ sơ công khai mà không tự động trở thành bảng sao kê cho cả thế giới.
- Đây không phải hệ thống ẩn danh toàn bộ giao dịch. Số tiền BTC, input, output và quan hệ chi tiêu vẫn nằm trên blockchain. Giao thức che liên kết giữa địa chỉ nhận công khai và output; không xóa lịch sử UTXO, thông tin KYC hay dấu vết mạng.
- Cách ví quét quan trọng không kém nhãn “hỗ trợ Silent Payments”. Quét trên thiết bị từ dữ liệu chung và giao scan key cho server là hai mô hình quyền riêng tư khác nhau. Ví thứ hai có thể tiện hơn nhưng server có khả năng nhận diện khoản thanh toán. Mô hình scanner
Đánh giá: đáng nghiên cứu như hạ tầng Bitcoin có ứng dụng rõ ràng, đặc biệt cho quyên góp, nhận tiền không cần tương tác và địa chỉ nhận công khai lâu dài. Chưa có cơ sở suy từ tiềm năng này ra thành công thương mại đại chúng, mức độ sử dụng toàn mạng hoặc giá trị của một token gắn câu chuyện Silent Payments.
2. Giao thức là gì — và không phải là gì?
Silent Payments được đặc tả ở BIP352, thuộc lớp ứng dụng. Bản đặc tả truy xuất có trạng thái Complete, phiên bản tài liệu 1.1.1. Giao thức dùng các cấu trúc Bitcoin/Taproot hiện có, không yêu cầu một soft fork riêng để tạo và chi tiêu output Silent Payments. “Complete” là trạng thái đặc tả, không phải chứng nhận mọi ví triển khai đều an toàn. BIP352, phần đầu và Specification
Cần tách ba đối tượng:
- Bitcoin: tài sản BTC, sổ cái và quy tắc xác thực giao dịch.
- Silent Payments: cách bên gửi suy ra output nhận tiền từ địa chỉ thanh toán công khai, và cách bên nhận tìm rồi chi tiêu output đó.
- Ví, scanner, ứng dụng: phần mềm hiện thực hóa giao thức, có quyết định riêng về lưu khóa, phục hồi, dữ liệu mạng và mức độ tin cậy server.
Silent Payments không phải blockchain mới, L2, mixer, hệ thống confidential amounts hay nền tảng phát hành token. Giao thức không định nghĩa native token hoặc quyền thu phí thuộc về người giữ token. Một ứng dụng có thể kết hợp nó với Ordinals/BRC-20, nhưng tính hợp lệ, trạng thái sở hữu và khả năng giao dịch của token vẫn cần các quy tắc/indexer và phần mềm tương ứng.
3. Cơ chế: bên gửi tạo địa chỉ, bên nhận tìm thanh toán
Hai loại địa chỉ cần phân biệt
- Địa chỉ công bố: mainnet Silent Payments v0 bắt đầu bằng
sp1q…, chứa hai public key: scan và spend. Đây là địa chỉ được phép tái sử dụng. - Output trên blockchain: một khóa nhận Taproot một lần, thường biểu diễn bằng
bc1p…. Không đưa địa chỉ output này trở lại làm địa chỉ nhận lâu dài: thanh toán trực tiếp tới nó có thể không được quy trình quét Silent Payments phát hiện. BIP352, giải thích và cảnh báo địa chỉ
Luồng hoạt động
- Người nhận công bố địa chỉ
sp1q…. Địa chỉ có public scan key và public spend key; không công bố private key. - Ví bên gửi chọn input, rồi tính bí mật chung bằng ECDH. Nó kết hợp khóa của các input đủ điều kiện với public scan key của người nhận. Dữ liệu input được đưa vào phép dẫn xuất để tránh tái tạo cùng địa chỉ khi thanh toán ở lần khác.
- Ví bên gửi điều chỉnh public spend key để tạo output Taproot một lần. Giao dịch gửi BTC tới output đó, không gửi “tới chuỗi sp1” như một script trên blockchain.
- Ví bên nhận quét giao dịch đủ điều kiện. Từ public key của input, private scan key và dữ liệu giao dịch, nó tính cùng bí mật chung rồi kiểm tra output nào khớp.
- Bên nhận chi tiêu với private spend key đã được điều chỉnh. Có quyền quét không đồng nghĩa có quyền lấy tiền.
Sơ đồ khái niệm — mũi tên biểu thị dữ liệu/phép dẫn xuất, không phải bằng chứng của một giao dịch thực: địa chỉ sp1q… + khóa input bên gửi → output Taproot mới → blockchain; dữ liệu blockchain + private scan key bên nhận → nhận diện output; output được nhận diện + private spend key → khả năng chi tiêu. Nguồn: BIP352.
Với trường hợp không dùng label, công thức giải thích rút gọn là:
A = tổng public key của các input đủ điều kiện
h = hash có nhãn của outpoint nhỏ nhất và A
S = h × a × B_scan = h × b_scan × A
P_k = B_spend + hash có nhãn(S || k) × G
a là tổng scalar input của bên gửi sau quy tắc chuẩn hóa; b_scan là private scan key bên nhận; G là điểm sinh; k phân biệt output trong một nhóm. Đây là cách đọc cơ chế, không phải mã triển khai: serialization, kiểm tra scalar, parity của Taproot, input eligibility, label và giới hạn nhóm đều phải theo đặc tả đầy đủ.
Điểm tinh tế: output phụ thuộc input. Thay input khi tăng phí bằng RBF đòi hỏi tính lại output Silent Payments; không thể tùy tiện ghép thêm input sau khi đã chốt địa chỉ như giao dịch thông thường. BIP352 cũng không khuyến nghị mặc định mô hình nhiều bên không tin nhau như CoinJoin, do chưa có chứng minh bảo mật hình thức cho môi trường cộng tác đó. BIP352, Selecting inputs và Functional tests
4. Quyền riêng tư: bảo vệ khỏi ai?
Đối thủ A — người nhìn blockchain và biết địa chỉ sp1q…: không có bí mật dẫn xuất hoặc scan key nên không thể đơn thuần chuyển địa chỉ công bố thành danh sách output của người nhận. Output hòa vào cấu trúc Taproot. Đây là bảo đảm thiết kế quan trọng nhất.
Đối thủ B — người đã gửi một khoản tiền: biết giao dịch mình tạo và output mình gửi. Silent Payments không làm bên gửi quên khoản thanh toán đó; thông tin có thể được tiết lộ ra ngoài.
Đối thủ C — đơn vị vận hành scanner có private scan key và public spend key: có thể tìm khoản nhận và quan sát khi output được chi tiêu. Nếu giữ lại scan key, khả năng quét không bị thu hồi chỉ vì người dùng ngắt kết nối. “Chỉ giữ trong RAM” là chính sách vận hành cần tin cậy, không phải khóa tự hết hạn bằng mật mã. Frigate, tài liệu scanning
Đối thủ D — tổ chức biết danh tính/UTXO hoặc quan sát mạng: giao thức không tự loại bỏ liên kết với sàn KYC, IP, thời gian thanh toán, số tiền đặc trưng, việc gộp nhiều UTXO hay yêu cầu tra cứu hậu kỳ. Việc không có dấu hiệu chuyên biệt của Silent Payments không có nghĩa không thể suy luận bằng dữ liệu khác.
Vì vậy, câu “người ngoài không thể liên kết bằng địa chỉ công bố” đúng phạm vi hơn câu “mọi giao dịch đều ẩn danh”. Ngay cả ví quét từ tweak server cũng phải chú ý cách tải block/giao dịch sau khi tìm thấy khoản nhận; yêu cầu rất đặc trưng có thể làm lộ sự quan tâm tới output.
Một hạn chế dễ bị bỏ qua: các label chia sẻ cùng public scan key vẫn có thể được liên hệ với nhau khi các địa chỉ được công bố. Label giúp phân loại nguồn nhận, không tạo nhiều danh tính độc lập. BIP352, Labels
5. Chi phí thật nằm ở việc tìm tiền, không phải giao dịch thông báo
Silent Payments loại bỏ giao dịch notification chuyên biệt. Tuy nhiên, không có overhead thông báo trên blockchain không có nghĩa tổng chi phí sử dụng bằng không: người nhận hoặc scanner phải tải dữ liệu và làm phép toán elliptic curve.
Có ba kiến trúc chính:
Tự vận hành node/scanner
Dữ liệu và phép quét nằm trong hệ thống do người dùng kiểm soát. Không phải giao scan key cho nhà cung cấp công cộng. Đổi lại cần vận hành, cập nhật, quản lý tài nguyên và bảo vệ máy quét. Tự host không có nghĩa thiết bị không thể bị xâm nhập.
Tweak server, quét trên thiết bị
Server tạo dữ liệu chung từ mỗi giao dịch đủ điều kiện; ví tải dữ liệu đó rồi kết hợp với scan key trên thiết bị. Server không được nhận scan key để tự tính danh sách khoản nhận. Đây là mô hình Cake Wallet mô tả; tài liệu cũng nói nếu node được chọn không có tweak index, việc quét chuyển sang server mặc định của Cake mà không thay thiết lập node dùng cho phần còn lại của ví. Cake docs
Ưu điểm là giữ bí mật quét trên thiết bị. Đánh đổi là băng thông, CPU/pin và thời gian phục hồi. Vẫn phải xử lý dữ liệu thiếu/sai hoặc bị server trì hoãn, và riêng tư mạng không tự xuất hiện chỉ vì không gửi khóa.
Remote scanner, giao scan key cho server
Server nhận private scan key cùng public spend key, thực hiện quét và trả khoản phù hợp. Frigate hỗ trợ mô hình này, gồm quét lịch sử và theo dõi mempool. Nó có thể giảm tải thiết bị nhưng bên vận hành nhìn được các khoản nhận. Theo thiết kế, chỉ scan key không đủ chi tiêu tiền; vẫn có rủi ro metadata và phụ thuộc dịch vụ. Sparrow nhận qua Frigate được mô tả trong danh mục hỗ trợ và tài liệu scanner. Frigate README, danh mục ví
Mô hình thứ ba là lựa chọn đánh đổi, không phải “Silent Payments bị phá”. Người dùng chỉ cần biết chính xác mình đang bảo vệ khỏi toàn bộ người ngoài hay ngoại trừ server đã chọn.
Không lấy benchmark cũ làm chi phí hiện tại
BIP352 mô tả 33 byte dữ liệu tweak cho mỗi giao dịch đủ điều kiện, chưa phải toàn bộ traffic của ví. Nếu giả định 3.500 giao dịch đủ điều kiện trong một block, phép tính cho riêng dữ liệu này là 115.500 byte. Đó là ví dụ điều kiện, không phải đo đạc block hiện tại.
Con số 7–12 kB/block trong Appendix A dựa trên dữ liệu tháng 01/2023 đến tháng 07/2024. Không dùng nó để khẳng định điện thoại hiện nay luôn quét nhẹ. Tỷ lệ Taproot, lượng giao dịch đủ điều kiện, cách lọc, tần suất quét và phần mềm đều ảnh hưởng chi phí. BIP352, Appendix A
Có thể giảm tải bằng quét từ thời điểm tạo ví, bỏ output đã chi tiêu khi chỉ phục hồi số dư, hoặc dùng lọc giá trị nhỏ. Nhưng phục hồi số dư không đồng nghĩa phục hồi toàn bộ lịch sử; lọc khoản nhỏ có thể bỏ qua tiền hợp lệ. Mất metadata label không tự đồng nghĩa mất tiền: ví phục hồi cần quét label change 0 và tập/phạm vi label đã dùng hoặc có thể đã dùng; giới hạn tìm kiếm của phần mềm có thể khiến khoản nhận chưa được phát hiện. BIP352 cũng yêu cầu một match mật mã phải tiếp tục bước quét kế tiếp ngay cả khi ví không muốn hiển thị/spend output đó.
Bản tài liệu 1.1.0 bổ sung giới hạn nhóm 2.323 để hạn chế trường hợp quét đối kháng có độ phức tạp bậc hai. Đây là biện pháp giảm worst case, không phải miễn trừ chi phí quét trong mọi tình huống. BIP352, K_max và Changelog
6. Mức độ trưởng thành: tách đặc tả, thư viện, ví và server
Đặc tả nền tảng
- BIP352: Complete; phiên bản tài liệu đọc được 1.1.1. Phiên bản tài liệu này không phải “địa chỉ Silent Payments v1”; địa chỉ hiện được đặc tả là v0.
- BIP374: Draft, phiên bản 0.3.0; DLEQ chứng minh quan hệ giữa các điểm elliptic curve mà không lộ scalar bí mật. Có ý nghĩa khi thành phần ký và thành phần tính output phải kiểm chứng nhau.
- BIP375: Draft, phiên bản 0.1.2; thêm dữ liệu/quy tắc PSBTv2 để gửi tới Silent Payments.
- BIP376: Draft; thêm dữ liệu PSBTv2 để chi tiêu output Silent Payments đã nhận.
Nguồn: BIP352, BIP374, BIP375, BIP376.
DLEQ không phải bằng chứng rằng giao dịch đã được ẩn danh, ví đã audit hoặc dự án đáng tin. Nó xác thực một mệnh đề mật mã cụ thể. Một proof hợp lệ vẫn cần ràng buộc đúng input, output, địa chỉ nhận và phiên bản quy tắc.
Ví và scanner có tài liệu triển khai
- Cake Wallet: tài liệu chính thức hướng dẫn cả gửi lẫn nhận, bật quét và quét từ ngày/block cụ thể. Đây là bằng chứng tính năng được tài liệu hóa; nghiên cứu này không chạy app để xác nhận mọi nền tảng/phiên bản.
- Sparrow: release chính thức 2.5.5 ngày 2026-09-17 có nhiều thay đổi liên quan Silent Payments, gồm kiểm tra output script trước ký và sửa các tình huống quét/PSBT. Đó là bằng chứng triển khai thực và tiếp tục hoàn thiện, không chỉ roadmap. Receiving có đánh đổi scanner như trên. Release
- Dana/BlindBit Desktop: danh mục hỗ trợ xếp vào gửi và nhận, nhưng có cảnh báo thử nghiệm/alpha. Không xếp ngang mức bảo đảm với phần mềm đã được thẩm định chỉ từ một hàng “supported”. Danh mục, cập nhật 2026-09-30
- Các ví send-only: danh mục tách riêng, không được diễn giải là đã hỗ trợ nhận/phục hồi. Tương tự, hardware signer không tự quét blockchain; cần một chuỗi phần mềm tương thích.
- Frigate: có mã/tài liệu cho scanner phía server, dùng private scan key theo phiên làm việc. Bản specification cho index server còn ghi WIP; chuẩn API và khả năng chuyển backend chưa đồng nghĩa đã ổn định phổ quát. Frigate, index specification
Bitcoin Core
Đối chiếu trực tiếp GitHub API cho thấy PR nền BIP352 #35301 đã merge vào master ngày 2026-09-23. Tuy nhiên, PR gửi #35302 và nhận #32966 vẫn open và draft tại thời điểm kiểm tra. API releases/latest trả v31.1, phát hành 2026-07-08, trước merge nền BIP352. Vì vậy không thể nói ví Bitcoin Core stable đã phát hành đầy đủ gửi/nhận Silent Payments. Base PR, gửi, nhận, stable release
Tracking issue là bản đồ công việc, nhưng checkbox có thể chậm cập nhật hơn trạng thái PR. Không dùng nó thay thế kiểm tra merge và release. Tiến bộ trong thư viện mật mã/full-node scanning cũng không tự hoàn tất kiến trúc ví nhẹ. Không có cơ sở cam kết ngày phát hành gửi/nhận kế tiếp. Tracking issue
7. Khi nào dùng Silent Payments thay vì phương án hiện có?
So với địa chỉ Bitcoin tĩnh bị tái sử dụng: Silent Payments là cải thiện rõ khi địa chỉ cần công bố lâu dài. Địa chỉ thông thường cho người ngoài tra số dư/lịch sử trực tiếp; sp1q… không cho phép phép tra cứu tương đương chỉ bằng địa chỉ công bố.
So với xin địa chỉ mới cho mỗi lần nhận: địa chỉ mới đã giải quyết phần lớn vấn đề reuse khi bên nhận có thể tương tác. Silent Payments nổi bật khi việc tương tác khó, người nhận offline hoặc không muốn vận hành hệ thống cấp địa chỉ mới. Nếu website có hệ thống hóa đơn và yêu cầu đối soát riêng từng khách hàng, không nên mặc định thay thế toàn bộ bằng một mã nhận chung.
So với BIP47/PayNym v1: BIP47 có giao dịch notification ban đầu để thiết lập quan hệ, sau đó ví có thể theo dõi các địa chỉ suy ra. Silent Payments bỏ notification và dấu vết/chi phí đi kèm nhưng chuyển gánh nặng sang quét giao dịch. BIP47 là baseline hữu ích chứ không chỉ “phiên bản cũ kém hơn”: cơ chế scan khác có lợi cho trải nghiệm ví nhẹ. BIP47, Notification Transaction
Không xem Silent Payments là thay thế CoinJoin/PayJoin hoặc mọi công cụ quyền riêng tư khác. Các công cụ có đối tượng bảo vệ khác nhau. Trong phạm vi đã kiểm tra, BIP352 còn cảnh báo về mô hình cộng tác; việc kết hợp phải được chứng minh trong implementation, không suy từ chữ “compatible” thành an toàn mặc định.
8. Giá trị thực và nút thắt phổ cập
Nơi lợi ích phù hợp với cơ chế
- Quyên góp và tips công khai: đăng một địa chỉ lâu dài mà không công khai một bảng sao kê dễ tra. Đây là trường hợp có độ khớp cao nhất với thiết kế không tương tác.
- Thanh toán cho người không thường xuyên online: bên gửi có thể tự dẫn xuất địa chỉ nhận, người nhận quét khi trở lại. Độ trễ thấy tiền phụ thuộc scanner, không có nghĩa BTC cần bên nhận online mới tới được.
- Ví coi trọng quyền riêng tư người nhận: đưa chống reuse vào trải nghiệm mặc định thay vì bắt người dùng nhớ đổi địa chỉ mỗi lần.
Nút thắt không nằm ở việc tạo thêm token
- Sender support: cả bên gửi phải có ví/luồng gửi hiểu
sp1q…; không thể giả định mọi sàn hoặc ví thường đều trả tiền trực tiếp tới mã này. - Receiving UX: quét nền, pin, mempool, thời gian catch-up và thông báo dễ gây hiểu nhầm “chưa nhận được”.
- Recovery/interoperability: seed không đủ nếu phần mềm phục hồi không hiểu cách dẫn xuất/quét tương ứng; metadata label và thời điểm tạo ví ảnh hưởng tốc độ và độ bao phủ.
- Hardware và PSBT: không chỉ cần ký Schnorr thông thường; signer/coordinator phải xử lý đúng tweak và kiểm chứng output.
- Hiểu mô hình tin cậy: một ví nhanh bằng scan-key server và một ví giữ scan key tại máy không cung cấp cùng mức bảo vệ đối với nhà cung cấp.
Diễn giải: nếu sender support, scan UX và phục hồi đủ tốt, Silent Payments có thể trở thành tính năng nhận BTC hữu ích mà người dùng không phải nghĩ nhiều về mật mã. Nếu trải nghiệm hoặc tương thích vẫn khó, giao thức có thể tiếp tục tập trung vào người dùng kỹ thuật và trường hợp nhận tiền nhạy cảm. Chưa đủ dữ liệu để chọn một kịch bản thành kết quả chắc chắn.
Không ước lượng tổng số giao dịch Silent Payments từ toàn bộ output Taproot: output được thiết kế không mang dấu hiệu riêng, nên đó sẽ là phép đo sai. Không có chuỗi số liệu toàn mạng đủ kiểm chứng trong phạm vi thu thập để kết luận market share, DAU hoặc tốc độ adoption.
9. shhhhh: một ví dụ phụ, không phải tài sản đại diện giao thức
Dữ liệu inscription đã đối chiếu cho thấy shhhhh là BRC-20, không phải native token của BIP352. Nguồn công bố cũng gọi nó là meme được triển khai bằng Silent Payments. Deploy payload, bài công bố
Website công bố proof và verifier cho quan hệ deploy với địa chỉ Silent Payments. Mã/proof đã được đọc thụ động nhưng không chạy để xác nhận DLEQ hợp lệ. Ngay cả proof hợp lệ cũng chỉ xác nhận mệnh đề provenance cụ thể, không chứng minh mọi chuyển token đều riêng tư. Chủ động công bố ECDH share và dữ liệu dẫn xuất còn phục vụ việc cho người ngoài đối chiếu liên kết này. Proof
Thảo luận gốc trên X có một đính chính hữu ích: triển khai dùng Silent Payments không đồng nghĩa private transfer của BRC-20. Tranh luận về gánh nặng scan dẫn tới mô tả ví/Frigate của dự án; đó vẫn là công bố kế hoạch và lựa chọn kiến trúc, không phải nghiệm thu triển khai an toàn. Đính chính, câu hỏi về scanning, phản hồi kiến trúc
Kết luận cho trường hợp này: shhhhh là cửa ngõ để phát hiện chủ đề Silent Payments, không phải cách sở hữu giao thức. Không thấy trong BIP352 một cơ chế khiến người giữ token này được hưởng phí, quyền quản trị hoặc lợi ích kinh tế từ mọi ví triển khai Silent Payments.
10. Cách đánh giá một ví trước khi sử dụng thực tế
Đây là tiêu chí thẩm định, không phải hướng dẫn giao dịch hay yêu cầu cung cấp khóa:
- Kiểm tra gửi / nhận / chi tiêu / phục hồi riêng biệt; nhãn “support” có thể chỉ nói tới gửi.
- Xác định scan key có rời thiết bị không, gửi cho ai, và có thể thay backend bằng server riêng không.
- Kiểm tra đúng bản phát hành, nền tảng, tài liệu bảo mật và đường tải chính thức; bản thử nghiệm không nên dùng cho khoản tiền đáng kể.
- Xem cách ví xử lý RBF, reorg, khoản nhỏ, label và quét từ birthday; số dư không hiển thị không tự chứng minh tiền mất.
- Kiểm tra khả năng phục hồi trong phần mềm hiểu Silent Payments và sao lưu metadata cần thiết, không gửi seed/private key/scan key cho trợ lý hay website kiểm tra.
- Không kỳ vọng Silent Payments thay thế coin control, vệ sinh UTXO hoặc bảo vệ metadata mạng.
Nghiên cứu này không thực hiện thử nghiệm gửi/nhận hoặc phục hồi ví, không thẩm định mã nguồn toàn bộ và không xác nhận chính sách “không lưu scan key” của bất kỳ server công cộng nào.
11. Điều gì sẽ làm thay đổi đánh giá?
Củng cố triển vọng: phát hành gửi/nhận hoàn chỉnh trong thêm ví được sử dụng thực; kiểm thử interoperability và phục hồi độc lập; dữ liệu scan trên thiết bị phổ biến với thời gian/điện năng/băng thông được đo rõ; trải nghiệm cho phép chọn backend và hiểu quyền riêng tư; xử lý tốt hardware/PSBT.
Làm giảm triển vọng: lỗ hổng dẫn xuất/phục hồi gây mất tiền; mô hình scan-key outsourcing trở thành mặc định mà người dùng không hiểu; filtering bỏ tiền hợp lệ mà không thể phát hiện/phục hồi; hỗ trợ chỉ tồn tại ở demo hoặc người gửi không dùng được.
Chưa thể kết luận: mức adoption toàn mạng, chi phí quét hiện hành trên điện thoại phổ thông, audit độc lập xuyên suốt các ví, và tác động thương mại dài hạn. Những phần này cần dữ liệu/kiểm thử khác, không thể lấp bằng bài X hoặc danh mục tính năng.
12. Nguồn, cách đọc bằng chứng và giới hạn
Ưu tiên: đặc tả BIP cho bảo đảm thiết kế; mã/tài liệu scanner cho mô hình tin cậy; release/docs ví cho tính năng được công bố; X để truy nguồn tranh luận và đính chính. Không xem nhiều bài cùng chép một công bố là các xác nhận độc lập. Tìm kiếm web công khai chưa tìm được bài X gốc riêng về merge Bitcoin Core; kết luận về trạng thái Core dựa trên GitHub API, không dựa vào suy đoán đồng thuận trên X. Những bài X dùng ở đây là thảo luận cụ thể, không phải mẫu đại diện toàn cộng đồng.
Các nguồn chính được gắn cạnh phát biểu:
- BIP352: cơ chế, input eligibility, scanning, label, recovery, Appendix A và changelog.
- BIP374/375/376: giới hạn ý nghĩa DLEQ và vai trò PSBT/hardware.
- Frigate và index-server specification: kiến trúc server/scan key; specification còn WIP.
- Cake docs, Sparrow release 2.5.5: tính năng gửi/nhận hoặc thay đổi thực tế được tài liệu hóa, không phải kết quả test do nghiên cứu này chạy.
- silentpayments.xyz: tài liệu cộng đồng chuyên đề và danh mục cập nhật 2026-09-30; cần đối chiếu implementation cho khẳng định về từng ví.
- BIP47: baseline payment-code v1 để so sánh notification với chi phí scanning.
- X và shhhhh: trường hợp minh họa về phân biệt provenance, privacy và câu chuyện token, không được dùng làm bằng chứng phổ cập toàn giao thức.
Một số trang chuyên đề hết thời gian khi tải trực tiếp; nội dung tương ứng được đọc từ repository nguồn của website. Công cụ trích xuất trung gian hết tín dụng; đã chuyển sang HTTP trực tiếp và browser. Không né đăng nhập, ký ví hoặc chạy mã dự án để lấp khoảng trống. Bằng chứng ghi nhận theo thời điểm truy xuất; nhánh master, PR, thư viện và chính sách ví có thể thay đổi sau ngày nghiên cứu.
Giới hạn kết luận: báo cáo đánh giá thiết kế và các triển khai được tài liệu hóa, không chứng nhận an toàn sản phẩm, tính ẩn danh thực tế của một giao dịch, hay lợi nhuận đầu tư.