Difference between revisions of "Payments in Bitcoin"
 
(24 intermediate revisions by 4 users not shown)
Line 1: Line 1:
−
Payments are an important aspect of Bitcoin. Every transaction is a payment of some sort. Transactions are the only means through which information can be written onto the ledger. The process of block discovery is agreed upon through the acceptance of a [[Coinbase]] transaction as a valid payment. A block is simply the process of having a collection of payments set down, collated and agreed upon as valid.
+
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 many different ways to request and make payments.
+
There are several standards defined for Bitcoin SV that cover methods of requesting and performing payments.
  
−
==BIP-0270==
+
==BIP270==
−
[https://github.com/moneybutton/bips/blob/master/bip-0270.mediawiki BIP270] is a simplified 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), enabling both a better experience, simpler wallet infrastructure, advanced features such as multiple outputs, and better security against man-in-the-middle attacks. 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 between the payer and the payee, writing to the ledger only at the end to settle the transaction(s).
+
[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
 +
* Simpler wallet infrastructure
 +
* Multiple outputs
 +
* Improved security against man-in-the-middle attacks
  
−
This BIP is an optimisation of BIP-0070. Changes include:
+
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)
 
* Moves all signature exchange and validation to the communication later (usually HTTPS)
 
* Add multiple outputs
 
* Add multiple outputs
−
* An library optimised for peer to peer transaction management
+
* A library optimised for peer to peer transaction management
  
 
==BSVAlias==
 
==BSVAlias==
−
[[BSVAlias]] is a set of protocols that lay out a structure for making and receiving payments using identity as the means to link sender and receiver. [[Paymail]] is the first practical implementation of 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==
−
Any transaction that has both an nLocktime in the future or an nSequence that is less than 0xFFFFFFFF is in a [[Payment Channels|payment channel]].
+
[[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 transaction can be updated once, or many times between peers until either nSequence is finalised or nLocktime runs out and one of the parties transmits the transaction to the blockchain.
+
 
−
Payment channels are useful for streaming data, operating a sequence of events or operating with a live dataset in applications such as gaming and more.
+
Payment channels support extremely rapid transaction updates with only the final closing transaction being confirmed in the blockchain.
−
Payment channels have been unavailable since early versions of Bitcoin and are a new field with huge potential in many areas.
+
 
 +
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==
−
These are payment protocols where the payer is asked to broadcast a transaction to the network (instead of the payee) so the payee can scan the network for relevant transactions rather than handling the transaction peer-to-peer as with SPV.
+
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===
 +
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.
  
−
===BIP-0021===
+
===BIP21===
−
[https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki BIP-0021] has been one of the predominant means of making mobile payments in Bitcoin throughout it's history. Almost all QR codes based payment gateways used within Bitcoin are or are an extention of BIP0021. It itself is an extension of [https://tools.ietf.org/html/rfc3986 RFC-3986], the RFC standard for URIs (Universal Resource Identifiers).
+
[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).
  
−
===BIP-0070===
+
===BIP70===
−
[[https://bitcoinj.github.io/payment-protocol#protocol-overview BIP-0070]] was a payment protocol for reaching out to receivers using an extension of BIP-0021 that added a URL. The URL directed the phone to reach out to a server and provide it the address at the front of the QR code. This server would instruct the device making the query which address to send money to.
+
[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.

Retrieved from "https://wiki.bitcoinsv.io/index.php?title=Payments_in_Bitcoin&oldid=3062"