On September 23, Matt Corallo, collaborator of the Client Bitcoin Core, presented a technical proposal that aims to simplify the way in which payments with Bitcoin (BTC) are made.
The approach, published as a draft under the proposed name of improvement of Bitcoin 321 (BIP-321), must be debated by developers and bitcoiners before it can be implemented in the protocol.
According to the repository of the proposal, the objective is to define a new scheme of “URI” addresses (uniform resource identifier) for Bitcoin, that is, links that contain payment instructions and can be opened from web browsers or by QR codes.
These links already exist in the current standard, included in the BIP-21but the new document promises an update that reflect the «Modern use of bitcoin and prepare the terrain for future extensions ».
In simple terms, an URI is a link that begins with «Bitcoin:» followed by an additional address or parameters describing the payment.
By clicking on that link or scanning it, a compatible purse can Interpret the instruction and guide the user in the execution of the payment.
It is true that applications such as Aqua already offer more friendly payment experiences, with short addresses or payment links that simplify the user’s interaction.
The difference is that they do it at the application level: each Wallet implements its own solution.
What Matt Corallo raises is to carry that type of Facilities at the level of the Bitcoin protocol. That means that any wallet or service that follows the standard could adopt the same payment method, without depending on a particular app.
In other words, it is not a replacement for what already exists in Aqua or other wallets, but an attempt to unify and standardize those functions to be native to Bitcoin and do not depend on external developments.
Most outstanding aspects of the new proposal for Bitcoin
According to the BIP-321 text, the most relevant changes are as follows:
- Expanded compatibility: Modern directions such as BECH32 and BECH32M are included, as well as bases inherited bases58. The integration of other payment methods, such as Lightning or Silent Payments invoices, is also planned.
- Additional parameters: The scheme allows adding data as an exact amount in BTC, name of the recipient, a descriptive message or a unique transaction identifier.
- Payment test (Proof of Payment, Pop): The possibility is added that the application that initiated the payment receives confirmation when it has been completed. For payments ON-CHAINthe test would be the complete transaction in hexadecimal format; For lightning, preimaging payment.
- Security rules: Bitcoin customers should never execute a payment without user authorization. Each instruction must be reviewed and manually confirmedalthough in some cases it may be automated under the user’s decision.
- Integration with operating systems: Graphic purses should be recorded as default applications to handle “bitcoin:” links, so when opening a link the system directly invokes the wallet.
A standard for evolving bitcoin
The document presented by Corallo ensures that the BIP-21, in force so far, originated in previous versions (BIP-20) and was outdated against new practices such as the use of lightning or addresses with greater privacy.
In this sense, the new draft seeks to unify criteria and generate a framework for future developments.
The logic behind this scheme is that a payment link does not represent a person, but A unique transfer instruction.
In Bitcoin it is recommended not to reuse addresses, so each “URI” should be considered a temporary payment identifier and not a fixed identity of the receiver.
In addition, the author of BIP-321 emphasizes that the incorporation of the payment test can be key in scenarios where there is no public registry of transactions, such as in Lightning. There, unlike the main Bitcoin chain, there is no global accounting book that can be monitored.
The discussion is now open among the developers and technical actors of Bitcoin, who They must evaluate the relevance of the changes and the way to integrate them into future versions of the protocol.