Difference between revisions of "Payments in Bitcoin"

Line 23: Line 23:
  
 
==Payment Channels==
 
==Payment Channels==
Any transaction that has both an [[nLocktime]] in the future and an [[nSequence]] that is less than 0xFFFFFFFF is not finalised, and potentially from a [[Payment Channels|payment channel]].
+
[[Payment Channels]] are a mechanism where two or more parties can directly and trustlessly exchange and update a transaction. The mechanism includes methods for establishing, or opening, a payment channel, updating the channel, and finalizing, 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 the early versions of Bitcoin and have been re-enabled since the [[Genesis upgrade]], enabling many potential use cases.
+
 
 +
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==

Revision as of 12:44, 5 May 2020

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 and trustlessly exchange and update a transaction. The mechanism includes methods for establishing, or opening, a payment channel, updating the channel, and finalizing, 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 it's history. Almost all QR codes 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 a script or address linked to the QR code.