Difference between revisions of "Payments in Bitcoin"
| (3 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | Payments are an important aspect of Bitcoin | + | The term ''payments'' in a Bitcoin context generally refers the process of a purchaser paying for a good or service from a vendor. Payments are an important aspect of Bitcoin and it is crucial that comprehensive standards exist that enable parties and software systems to process payments in ways that cover a wide variety of use cases. |
| − | + | There are several standards defined for Bitcoin SV that cover methods of requesting and performing payments. | |
| − | + | ==BIP270== | |
| − | + | [https://github.com/moneybutton/bips/blob/master/bip-0270.mediawiki BIP270] is a streamlined version of the [https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki BIP70 Payment Protocol] introduced in 2013. It is a protocol for communication between a [[payment host]] (usually either a merchant, a payment processor, or simply the recipient's wallet) and their customer (the sender of the funds). It enables: | |
| − | == | + | * Improved user experience |
| − | [https://github.com/moneybutton/bips/blob/master/bip-0270.mediawiki BIP270] is a | ||
| − | * | ||
* Simpler wallet infrastructure | * Simpler wallet infrastructure | ||
* Multiple outputs | * Multiple outputs | ||
| − | * | + | * Improved security against man-in-the-middle attacks |
| − | + | BIP270 is designed for wallets that use [[Simplified Payment Verification]] to achieve huge improvements at scale. Transactions can be exchanged partially or in iterations. This is far faster when done peer to peer directly between the payer and the payee, writing to the ledger only at the end to settle the transaction(s). | |
| − | This BIP is an optimisation of | + | This BIP is an optimisation of BIP70. Changes include: |
* Moves all signature exchange and validation to the communication later (usually HTTPS) | * Moves all signature exchange and validation to the communication later (usually HTTPS) | ||
* Add multiple outputs | * Add multiple outputs | ||
| Line 20: | Line 18: | ||
==BSVAlias== | ==BSVAlias== | ||
| − | [[BSVAlias]] is a set of | + | [[BSVAlias]] is a set of standards for using email type identities with Bitcoin SV, with making and receiving payments as one of its first use-cases. |
[[Paymail]] is the first practical implementation of BSVAlias. | [[Paymail]] is the first practical implementation of BSVAlias. | ||
==Payment Channels== | ==Payment Channels== | ||
| − | + | [[Payment Channels]] are a mechanism where two or more parties can directly exchange and update a transaction. The mechanism includes: methods for establishing, or opening, updating, and finalising or closing the payment channel. The mechanism also covers the possibility of any of the parties becoming unresponsive, usually by enabling the recovery of funds after a fixed time. | |
| − | The | + | |
| − | Payment channels | + | Payment channels support extremely rapid transaction updates with only the final closing transaction being confirmed in the blockchain. |
| − | + | ||
| + | Payment channels can be useful for streaming data, operating a sequence of events, or operating with a live dataset in applications such as gaming and more. | ||
==Legacy Payment Protocols== | ==Legacy Payment Protocols== | ||
| − | + | Many of the legacy payment protocols used a mechanism where the payer is asked to broadcast a transaction to the network, and the payee would scan the network for relevant transactions rather than handling the transaction directly peer-to-peer as with [[Simplified_Payment_Verification|SPV]]. This mechanism does not scale when transaction volume increases and is inefficient. | |
===IP to IP payments=== | ===IP to IP payments=== | ||
| − | The original version of the Bitcoin node client had the facility to conduct IP | + | The original version of the Bitcoin node client had the facility to conduct IP to IP payments where a receiver could give a payer their IP address. The payer's client would reach out to the payee's client and request a public key for the payment to be addressed to. |
| − | This payment method was | + | This payment method had valid security concerns, but rather than addressing these concerns, the mechanism was removed. |
| − | New payment processes are in development which draw from this original idea | + | New payment processes are in development which draw from this original idea and will allow network peers to interact securely using cryptographically verified IP addresses. |
| − | === | + | ===BIP21=== |
| − | [https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki | + | [https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki BIP21] has been one of the predominant means of making mobile payments in Bitcoin throughout its history. Almost all QR code based payment gateways used within Bitcoin are, or are an extension of, BIP21. BIP21 itself is an extension of [https://tools.ietf.org/html/rfc3986 RFC-3986], the RFC standard for URIs (Universal Resource Identifiers). |
| − | === | + | ===BIP70=== |
| − | [https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki | + | [https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki BIP70] was a payment protocol for reaching out to receivers using an extension of BIP21 that added a URL. The URL directed the device to reach out to a server which would provide it with a script, or an address linked to the QR code. |
Latest revision as of 19:25, 27 April 2022
The term payments in a Bitcoin context generally refers the process of a purchaser paying for a good or service from a vendor. Payments are an important aspect of Bitcoin and it is crucial that comprehensive standards exist that enable parties and software systems to process payments in ways that cover a wide variety of use cases.
There are several standards defined for Bitcoin SV that cover methods of requesting and performing payments.
BIP270
BIP270 is a streamlined version of the BIP70 Payment Protocol introduced in 2013. It is a protocol for communication between a payment host (usually either a merchant, a payment processor, or simply the recipient's wallet) and their customer (the sender of the funds). It enables:
- Improved user experience
- Simpler wallet infrastructure
- Multiple outputs
- Improved security against man-in-the-middle attacks
BIP270 is designed for wallets that use Simplified Payment Verification to achieve huge improvements at scale. Transactions can be exchanged partially or in iterations. This is far faster when done peer to peer directly between the payer and the payee, writing to the ledger only at the end to settle the transaction(s).
This BIP is an optimisation of BIP70. Changes include:
- Moves all signature exchange and validation to the communication later (usually HTTPS)
- Add multiple outputs
- A library optimised for peer to peer transaction management
BSVAlias
BSVAlias is a set of standards for using email type identities with Bitcoin SV, with making and receiving payments as one of its first use-cases.
Paymail is the first practical implementation of BSVAlias.
Payment Channels
Payment Channels are a mechanism where two or more parties can directly exchange and update a transaction. The mechanism includes: methods for establishing, or opening, updating, and finalising or closing the payment channel. The mechanism also covers the possibility of any of the parties becoming unresponsive, usually by enabling the recovery of funds after a fixed time.
Payment channels support extremely rapid transaction updates with only the final closing transaction being confirmed in the blockchain.
Payment channels can be useful for streaming data, operating a sequence of events, or operating with a live dataset in applications such as gaming and more.
Legacy Payment Protocols
Many of the legacy payment protocols used a mechanism where the payer is asked to broadcast a transaction to the network, and the payee would scan the network for relevant transactions rather than handling the transaction directly peer-to-peer as with SPV. This mechanism does not scale when transaction volume increases and is inefficient.
IP to IP payments
The original version of the Bitcoin node client had the facility to conduct IP to IP payments where a receiver could give a payer their IP address. The payer's client would reach out to the payee's client and request a public key for the payment to be addressed to. This payment method had valid security concerns, but rather than addressing these concerns, the mechanism was removed. New payment processes are in development which draw from this original idea and will allow network peers to interact securely using cryptographically verified IP addresses.
BIP21
BIP21 has been one of the predominant means of making mobile payments in Bitcoin throughout its history. Almost all QR code based payment gateways used within Bitcoin are, or are an extension of, BIP21. BIP21 itself is an extension of RFC-3986, the RFC standard for URIs (Universal Resource Identifiers).
BIP70
BIP70 was a payment protocol for reaching out to receivers using an extension of BIP21 that added a URL. The URL directed the device to reach out to a server which would provide it with a script, or an address linked to the QR code.