bitcoin-dev

Combined summary - BIP 21 Updates

The recent discussions within the Bitcoin development community have brought attention to the limitations of the current BIP 21 standard, which primarily focuses on transactions using base58 addresses and lacks official support for more advanced addressing schemes like Segwit and Taproot.

Given the significant adoption of wallets that can handle these newer types of addresses and decode lightning payment instructions from URI query parameters, there's a consensus on the need to modernize BIP 21. This update would not only accommodate the inclusion of Segwit and Taproot addresses in URI bodies but also support the evolving Bitcoin payment landscape, including Silent Payments and BOLT 12. The proposal suggests enhancing BIP 21 URIs to enable the embedding of various payment instructions through distinct query parameters, making the body of the URI optional for schemes that do not require a standard on-chain fallback. This approach aims to ensure compatibility with existing wallets by allowing them to ignore unrecognized new query parameters and reject invalid URIs without a body.

Furthermore, a new Bitcoin Improvement Proposal (BIP) is being drafted to introduce an additional feature aimed at enriching the payment process. This includes the implementation of a "payment info callback" parameter, which does not affect current wallet operations but offers an important functionality for specific use cases, such as nostr zaps. The proposal outlines the mechanics of a Proof of Payment mechanism where the URI may contain a "pop" (or "req-pop") parameter. This parameter enables the construction of a URI that the wallet application can open post-payment to provide proof of payment completion or other relevant information. The parameter must be a percent-encoded URI prefix, following RFC 3986 section 2.1 guidelines. Upon payment completion, supported wallet applications will percent-decode this URI, append it with payment information, and open it with the system's default handler, barring certain schemes like HTTP or JavaScript to ensure security. For on-chain transactions, the payment information should include the full transaction data in hex format, while for BOLT 11 invoice payments, it should be the hex-encoded payment preimage. This innovative approach facilitates a more transparent and verifiable payment process, potentially setting a new standard for payment information sharing across different payment methods within the Bitcoin ecosystem.

Discussion History

0
Matt CoralloOriginal Post
May 30, 2024 21:54 UTC
1
November 12, 2024 16:07 UTC