Transaction confirmation

Transaction confirmation is needed to prevent double-spending of the same money. One of the main advantages of bitcoin is that it avoids the problem of double-spending, i.e. the risk that a digital currency token may be copied and spent more than once. In spite of having no central authority to verify that its tokens are not being duplicated, bitcoin successfully avoids double-spending through a system of decentralized transaction confirmation, based on the consensus of its users. Bitcoin transaction time is always changing and it depends on the miner's fee.

How to confirm bitcoin transaction?

A transaction is a transfer of value between Bitcoin wallets that gets included in the block chain. Bitcoin transactions are not immediate. When a user wishes to send bitcoins, information is broadcast from her wallet to the (users in the) network, who verify that she has enough coins, and that they have never been spent before. Once validated, miners will include this transaction – along with others – in a new block in the blockchain. This is called a transaction confirmation. The transaction is now said to be "unconfirmed bitcoin transaction".

Each time a new block is added to the chain (every ten minutes), the transaction is said to be confirmed again. As a consensus, many users wait for a transaction to be confirmed six times (after roughly sixty minutes) before accepting it as payment, to avoid double-spending. Users will usually show a transaction as "n/unconfirmed" until it is six blocks deep.

Example of the transaction confirmation time

Bitcoin confirmation time

The deeper a transaction is buried, the harder it will be to manipulate. Although 0/unconfirmed transactions could be reversed via Finney attack, race attack, or 51% attack, small amounts of money will not be worth the trouble. Larger sums are worth protecting under more bitcoin confirmations. The number six is just an arbitrary limit, beyond which the feasibility of an attacker being able to amass more than 10% of the network's hashrate for purposes of a transaction falsification becomes negligible (a risk lower than 0.1%).

Each additional confirmation is a new block being found and added to the end of the blockchain. Miners create blocks by solving the proof of work for their proposed block. The block interval has an average of 10 minutes but not every block interval is exactly 10 minutes. It follows a statistical process known as a poisson process, where random events happen with the same probability in each time interval. Another way of expressing this is that the mining process has no memory, at every second a block has the same chance of being found. Poisson processes are well-understood but can be unintuative.

There are lots of block intervals with a time less than 10 minutes but then a few block intervals much longer which bump up the average to 10 minutes. So the bitcoin network can get unlucky and a block won't be found for a whole hour.

In a 10 minute interval, the probability of a block being found is about 63% (or 1 - e^(-1)). So approximately two-thirds of the time a block will be found in 10 minutes or less. In 30 minutes a block has a 95% chance of being found, which rises to 99.7% if the time interval is 60 minutes.

Having understood how transactions occur, you should find out what affects the speed of processing and verification of information. To speed up the process, you need to know that it can slow down. Usually at the final time is affected by:

• network utilization;
• sharp jumps in the course;
• low commission.

The influence of the first factor is especially noticeable. When the system needs to process many requests, users have to wait. Especially long we have to wait in the days of peak activity, which is not often, but sometimes. Of great importance is the Commission paid to miners. The bigger it is, the higher the priority will be. The size of the transaction also has an additional impact: sending large amounts is much faster.

How many confirmations in bitcoin needed?

Although six confirmations is the consensus, merchants and exchanges that accept bitcoin as payment for their products and services should set their own standard of confirmations they require before accepting payment.

Freshly-minted bitcoins can only be used after 100 confirmations, to prevent coins from orphan blocks being spent. Older bitcoin client will not use newly-earned coins until they have 120 confirmations.

Number of Confirmations

How to Confirm a Pending or Stuck BItcoin Transaction

The classic bitcoin client will show a transaction as "n/unconfirmed" until the transaction is 6 blocks deep. Merchants and exchanges who accept bitcoins as payment can and should set their own threshold as to how many blocks are required until funds are considered confirmed. When potential loss due to double spending as nominal, as with very inexpensive or non-fungible items, people may choose not to wait for a transaction to be confirmed, and complete the exchange as soon as it is seen on the network. Most exchanges and other merchants who bear the risk from double spending require 6 or more blocks.

To find out how many checks are required to process the transaction and how long to wait for the receipt of funds, it is necessary to understand the features of cryptocurrency transfers. This process consists of several stages:

• addressee sends money;
• information about transactions is made in special blocks, each of which has a room and a hash (special data);
• the blocks are sent for scanning to different computers;
• if everything is done correctly, the received information replenishes various databases;
• checked blocks complete the chain;
• the money goes to the recipient.

To make a transfer, the transaction must be verified in 6 blocks. If this does not happen, cryptogenic reach the final destination. Accordingly, the speed of confirmation depends on the time of sending Finance.

There is nothing special about the default, often-cited figure of 6 blocks. It was chosen based on the assumption that an attacker is unlikely to amass more than 10% of the hashrate, and that a negligible risk of less than 0.1% is acceptable.Both these figures are arbitrary, however: 6 blocks are overkill for casual attackers, and at the same time powerless against more dedicated attackers with much more than 10% hashrate.

Freshly-mined coins cannot be spent for 100 blocks. It is advisable to wait some additional time for a better chance that the transaction will be propagated by all nodes. Some older bitcoin clients won't show generated coins as confirmed until they are 120 blocks deep.

How Many Confirmations Is Enough

Transactions with 0/unconfirmed can be reversed with not too much cost via Finney attack and race attack, but in some cases may still be acceptable especially for low-value goods and services, or ones which can be clawed back.

For transactions with confirmations, the website (https://people.xiph.org/~greg/attack_success.html) can be used to calculate the probability of a successful doublespend given a hashrate proportion and number of confirmations. Note that in the reality of bitcoin mining today, more than 6 confirmations are required. (60 confirmations to have <1% odds of succeeding against an entity with 40% hash power). See Section 11 of the (https://bitcoin.org/bitcoin.pdf bitcoin whitepaper) for the AttackerSuccessProbability formula.

Some mining enterprises may hide their hash power across several mining pools. Also mining ASICs can be temporarily overclocked to increase their hash power. This is less power-efficient but could be used for a brief burst of hashrate. For maximum safety, it is recommended that for the irreversible sale of items with value comparable to the block reward, a large number of confirmations (144 blocks = 1 day) is required before completing the exchange.

See also: Irreversible Transactions

Bitcoin transaction accelerator

Theoretically, it is impossible to speed up the confirmation of bitcoin transactions. Because it is impossible to increase the speed of data processing on another computer. But the reality is somewhat different. Cryptocurrency holders can take advantage of several options:

• the increase in the size of the commission;
• using proven reliable wallets;
• the opening of the transaction;
• using multifunction purses that support the creation of multipurpose.

Additionally, visitors can use the alternative, involving the procurement transaction as a reserve. This option requires the creation of a private, independent from the wallet address bitcoins.

Depending on conditions the time of making the bitcoin payment can be both immediate and delayed for a few days. Therefore, in order not to be in a difficult situation, you should think in advance about all the details and decide how to speed up the process. And the most important is the size of the Commission and the reliability of the selected wallet. If miners get a good reward, the priority of data processing will increase dramatically. A high-quality payment resource is able to make a financial transaction instant.

General format of a Bitcoin transaction (inside a block)

Field	Description	Size
Version no	currently 1	4 bytes
Flag	If present, always 0001, and indicates the presence of witness data	optional 2 byte array
In-counter	positive integer VI = VarInt	1 - 9 bytes
list of inputs	the first input of the first transaction is also called "coinbase" (its content was ignored in earlier versions)	<in-counter>-many inputs
Out-counter	positive integer VI = VarInt	1 - 9 bytes
list of outputs	the outputs of the first transaction spend the mined bitcoins for the block	<out-counter>-many outputs
Witnesses	A list of witnesses, 1 for each input, omitted if flag above is missing	variable, see Segregated_Witness
lock_time	if non-zero and sequence numbers are < 0xFFFFFFFF: block height or timestamp when transaction is final	4 bytes

Principle example of a Bitcoin transaction with 1 input and 1 output only

Data

Input:
Previous tx: f5d8ee39a430901c91a5917b9f2dc19d6d1a0e9cea205b009ca73dd04470b9a6
Index: 0
scriptSig: 304502206e21798a42fae0e854281abd38bacd1aeed3ee3738d9e1446618c4571d10
90db022100e2ac980643b0b82c0e88ffdfec6b64e3e6ba35e7ba5fdd7d5d6cc8d25c6b241501

Output:
Value: 5000000000
scriptPubKey: OP_DUP OP_HASH160 404371705fa9bd789a2fcd52d2c580b65d35549d
OP_EQUALVERIFY OP_CHECKSIG

Explanation

The input in this transaction imports 50 BTC from output #0 in transaction f5d8... Then the output sends 50 BTC to a Bitcoin address (expressed here in hexadecimal 4043... instead of the normal base58). When the recipient wants to spend this money, he will reference output #0 of this transaction in an input of his own transaction.

Input

An input is a reference to an output from a previous transaction. Multiple inputs are often listed in a transaction. All of the new transaction's input values (that is, the total coin value of the previous outputs referenced by the new transaction's inputs) are added up, and the total (less any transaction fee) is completely used by the outputs of the new transaction. Previous tx is a hash of a previous transaction. Index is the specific output in the referenced transaction. ScriptSig is the first half of a script (discussed in more detail later).

The script contains two components, a signature and a public key. The public key must match the hash given in the script of the redeemed output. The public key is used to verify the redeemers signature, which is the second component. More precisely, the second component is an ECDSA signature over a hash of a simplified version of the transaction. It, combined with the public key, proves the transaction was created by the real owner of the address in question. Various flags define how the transaction is simplified and can be used to create different types of payment.

Output

An output contains instructions for sending bitcoins. Value is the number of Satoshi (1 BTC = 100,000,000 Satoshi) that this output will be worth when claimed. ScriptPubKey is the second half of a script (discussed later). There can be more than one output, and they share the combined value of the inputs. Because each output from one transaction can only ever be referenced once by an input of a subsequent transaction, the entire combined input value needs to be sent in an output if you don't want to lose it. If the input is worth 50 BTC but you only want to send 25 BTC, Bitcoin will create two outputs worth 25 BTC: one to the destination, and one back to you (known as "change", though you send it to yourself). Any input bitcoins not redeemed in an output is considered a transaction fee; whoever generates the block can claim it by inserting it into the coinbase transaction of that block.

Verification

To verify that inputs are authorized to collect the values of referenced outputs, Bitcoin uses a custom Forth-like scripting system. The input's scriptSig and the referenced output's scriptPubKey are evaluated (in that order), with scriptPubKey using the values left on the stack by scriptSig. The input is authorized if scriptPubKey returns true. Through the scripting system, the sender can create very complex conditions that people have to meet in order to claim the output's value. For example, it's possible to create an output that can be claimed by anyone without any authorization. It's also possible to require that an input be signed by ten different keys, or be redeemable with a password instead of a key.

Types of Transaction

Bitcoin currently creates two different scriptSig/scriptPubKey pairs. These are described below.

It is possible to design more complex types of transactions, and link them together into cryptographically enforced agreements. These are known as Contracts.

Pay-to-PubkeyHash

scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>

A Bitcoin address is only a hash, so the sender can't provide a full public key in scriptPubKey. When redeeming coins that have been sent to a Bitcoin address, the recipient provides both the signature and the public key. The script verifies that the provided public key does hash to the hash in scriptPubKey, and then it also checks the signature against the public key.

Checking process:

Stack	Script	Description
Empty.	<sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG	scriptSig and scriptPubKey are combined.
<sig> <pubKey>	OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG	Constants are added to the stack.
<sig> <pubKey> <pubKey>	OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG	Top stack item is duplicated.
<sig> <pubKey> <pubHashA>	<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG	Top stack item is hashed.
<sig> <pubKey> <pubHashA> <pubKeyHash>	OP_EQUALVERIFY OP_CHECKSIG	Constant added.
<sig> <pubKey>	OP_CHECKSIG	Equality is checked between the top two stack items.
true	Empty.	Signature is checked for top two stack items.

Pay-to-Script-Hash

scriptPubKey: OP_HASH160 <scriptHash> OP_EQUAL 
scriptSig: ..signatures... <serialized script>

m-of-n multi-signature transaction:
scriptSig: 0 <sig1> ... <script>
script: OP_m <pubKey1> ... OP_n OP_CHECKMULTISIG

P2SH addresses were created with the motivation of moving "the responsibility for supplying the conditions to redeem a transaction from the sender of the funds to the redeemer. They allow the sender to fund an arbitrary transaction, no matter how complicated, using a 20-byte hash"1. Pay-to-Pubkey-hash addresses are similarly a 20-byte hash of the public key.

Pay-to-script-hash provides a means for complicated transactions, unlike the Pay-to-pubkey-hash, which has a specific definition for scriptPubKey, and scriptSig. The specification places no limitations on the script, and hence absolutely any contract can be funded using these addresses.

The scriptPubKey in the funding transaction is script which ensures that the script supplied in the redeeming transaction hashes to the script used to create the address.

In the scriptSig above, 'signatures' refers to any script which is sufficient to satisfy the following serialized script.

Checking process:

Stack	Script	Description
Empty.	0 <sig1> <sig2> OP_2 <pubKey1> <pubKey2> <pubKey3> OP_3 OP_CHECKMULTISIG	Only the scriptSig is used.
0 <sig1> <sig2> OP_2 <pubKey1> <pubKey2> <pubKey3> OP_3	OP_CHECKMULTISIG	Constants are added to the stack.
true	Empty	Signatures validated in the order of the keys in the script.

Bitcoin address

Main Page: Bitcoin address

Make Bitcoin Address

Bitcoin address is an identifier (account number), starting with 1 or 3 and containing 27-34 alphanumeric Latin characters (except 0, O, I). Bitcoin addresses can be also represented as a QR-code. The addresses are anonymous and do not contain information about the owner. A bitcoin address can be obtained for free, using, for example, Bitcoin software. Bitcoin address example:

14qViLJfdGaP4EeHnDyJbEGQysnCpwn1gd

Addresses can be generated at no cost by any user of Bitcoin. For example, using Bitcoin Core, one can click "New Address"fl and be assigned an address. It is also possible to get a Bitcoin address using an account at an exchange or online wallet service.

There are currently two bitcoin address format in common use:

Common P2PKH which begin with the number 1, eg: 6.

Newer P2SH type starting with the number 3, eg: 3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy.

See also

• Buy bitcoin
• Cryptocurrency list
• Block chain
• Bitcoin address
• Mining pools

External Links

• Bitcoin Mining
• Average Confirmation Time - Blockchain - Blockchain.info
• How Long do Bitcoin Transactions Take? - CoinCentral
• What are Bitcoin Blocks and Bitcoin Confirmations ? - 99Bitcoins
• Bitcoin Unconfirmed Transactions