Difference between revisions of "BIP Draft - Instant Partial Confirmation"

From Bitcoin Wiki
Jump to: navigation, search
Line 3: Line 3:
   BIP: Draft
   BIP: Draft
   Title: Instant Partial Confirmation
   Title: Instant Partial Confirmation (IPC)
   Author: Mike Caldwell <casascius@mc2cs.com>
   Author: Mike Caldwell <casascius@mc2cs.com>
   Status: Draft
   Status: Draft

Revision as of 04:23, 1 August 2012

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 (IPC)
  Author: Mike Caldwell <casascius@mc2cs.com>
  Status: Draft
  Type: Standards Track
  Created: 2012-07-31


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 as compared to a zero-confirmation transaction.


One of the most frequently discussed issues with Bitcoin is the fact that transactions are subject to double-spending until confirmed by the network, and the time needed to receive such confirmations is too great and too unpredictable to be of practical use in a retail setting. The present consensus is that the best practice is for merchants to simply assume the risk of fraud for small transactions or those where the risk of loss to the merchant is trivial, and to 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 undoubtedly 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.

Meanwhile, 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.


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. By "transaction fee", this proposal refers to the usual and customary transaction fee already offered in transactions, which are denoted by a sum of transaction outputs that is less than the sum of transaction inputs.

The fee is not paid to any individual miner or provider of the IPC service, rather, it is entirely possible that the IPC fee may be earned by a miner who does not provide IPC services, simply by being the next one to solve a block shortly after the IPC service is used. During an initial implementation of IPC, the majority of the revenue generated by the few miners supporting IPC will be earned by miners not supporting it. However, the IPC service is likely to impose negligible costs on miners, in terms of computing resources and bandwidth. As all miners stand to benefit from IPC fees, all miners have an indirect incentive to support the IPC service, because as the fractional confirmation anticipated by customers approaches 1.0, the more likely they are to pay to use the service.

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).