BIP Draft - Instant Partial Confirmation

From Bitcoin Wiki
Revision as of 03:53, 1 August 2012 by Casascius (talk | contribs)
Jump to: navigation, search

This page describes a BIP (Bitcoin Improvement Proposal).
Please see BIP 2 for more information about BIPs and creating them. Please do not just create a wiki page.

  BIP: Draft
  Title: Instant Partial Confirmation
  Author: Mike Caldwell <casascius@mc2cs.com>
  Status: Draft
  Type: Standards Track
  Created: 2012-07-31

Abstract

This BIP proposes a scheme to enable parties to a transaction to receive a reliable confirmation of their transaction from miners in a deterministic predictable timeframe, and compensates miners financially for providing this service.

With the service described by this BIP, instead of waiting an average of 10 minutes for 1 confirmation, a transactor could potentially receive 0.51 or more confirmations within 10 seconds of issuing it (representing 51% of the mining power on the network), and have a much higher level of confidence that the transaction will be confirmed.

Motivation

One of the most frequently discussed issues with Bitcoin is the fact that transactions are subject to double-spending until it is confirmed by the network, and the time it takes to receive such confirmations is too great for them to be of any use in a retail setting. The present consensus is that the best practice is for merchants to assume the risk of fraud for the smaller items, and only insist on confirmations for transactions where the cost of committing fraud is believed to be greater than the anticipated benefit from such a fraud.

While such a consensus has practical merit, there will still be situations where merchants are uncomfortable with the level of faith required, and who would gladly pay for a technically-based solution to mitigate their risk.

Another frequently discussed issue with Bitcoin is the observation that the total volume of transaction fees is orders of magnitude smaller than the block reward. Presently, miners provide no services to individual Bitcoin users, rather, they provide services to the network as a whole. This proposal represents an opportunity for Bitcoin miners to offer a valuable service to customers willing to pay for it, potentially providing a significant enhancement to the total volume of transaction fees collected into new blocks solved by miners.

Specification

This proposal, in a nutshell, is that the parties to a transaction are invited to directly contact a large number of miners using a best-effort datagram protocol (specifically, UDP), send them their transaction, and in return, receive a digitally signed informal acknowledgment of the transaction. The digital signature serves two purposes: one, to establish the authenticity of the promise, and two, to allow the recipient of the promise to assign a weight to the commitments in units of "fractional confirmations".

Bitcoin transaction confirmations are normally counted with integers. In the paradigm of Bitcoin as known today, a brand new transaction is considered "unconfirmed" and starts out with 0 confirmations. When it is first seen in a block, it has 1 confirmation. In contrast, with Instant Partial Confirmation, a transaction starts out with 0 confirmations, but immediately starts to accumulate a fractional confirmation count - greater than zero but less than one - as individual commitments are received and correlated with their likely known hash power based on recent blocks.

The specification itself rests on three distinct prongs described as follows:

  1. Miners SHOULD advertise their willingness to provide the Instant Partial Confirmation (IPC) service with a notation in their coinbase transactions. The notation references support for IPC, and includes contact information consisting of an IP address (IPv4/IPv6) and a UDP port number.
  2. In order to request IPC services, a party to a transaction send a UDP message to the miners who mined the most recent 2016 blocks. Only one message is needed whenever more than one block contains identical contact information. The message shall contain the entire transaction to be partially confirmed, a return path (IP and UDP port) for the response, and proof that the requester is a party to the transaction.
  3. Miners may choose whether to respond. If a miner grants the partial confirmation, the response MUST be signed (typically by the private key corresponding to the coinbase transaction). A partial confirmation response from a miner is a commitment to include that transaction into a block, as well as an assertion that no prior transactions have been received that would ordinarily cause the new transaction to be rejected. If the new transaction is not valid or conflicts with a previously received transaction, the miner MUST NOT offer a partial confirmation. If the miner believes that a double spend is in progress, the miner MAY send a signed message to that effect, indicating a negative confirmation.

Users wishing to use the service must include a transaction fee in their outgoing transactions that satisfies a market-defined threshold established by the miners. Each miner is free to establish his/her own minimum price for providing the service. Miners do not respond to IPC requests when the transaction fee is less than the minimum amount they demand. The higher the fee paid, the more miners will respond to the IPC request, directly influencing the total fractional confirmation that will be achieved in the seconds following the broadcast.


Backwards compatibility

This proposal contemplates adding new data to coinbase transactions, which has already been shown quite clearly to be possible without any ill effects on existing clients. The new data is completely optional.

This proposal contemplates providing services completely through out-of-band communication (with respect to the Bitcoin peer-to-peer protocol). No compatibility issues are expected. Nodes are free to disregard any message received through such out-of-band communication without consequence (other than perhaps, of course, a lower fractional confirmation value for the party requesting it).