Bitcoin Forum
May 30, 2024, 07:01:39 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: How many confirmations?  (Read 1248 times)
mikewirth (OP)
Sr. Member
****
Offline Offline

Activity: 532
Merit: 250


View Profile
May 16, 2015, 03:49:27 PM
 #1

Lets say I send some bitcoin to an address in a normal bitcoin transaction.  How many confirmations will it need before another transaction which spends those bitcoins will be accepted by nodes?
roslinpl
Legendary
*
Offline Offline

Activity: 2212
Merit: 1199


View Profile WWW
May 16, 2015, 04:04:02 PM
 #2

Lets say I send some bitcoin to an address in a normal bitcoin transaction.  How many confirmations will it need before another transaction which spends those bitcoins will be accepted by nodes?

Hey,

You should read this ( https://en.bitcoin.it/wiki/Confirmation ) to understand confirmations better:

Quote
After a transaction is broadcast to the Bitcoin network, it may be included in a block that is published to the network. When that happens it is said that the transaction has been mined at a depth of 1 block. With each subsequent block that is found, the number of blocks deep is increased by one. To be secure against double spending, a transaction should not be considered as confirmed until it is a certain number of blocks deep.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.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. Coins generated aren't considered valid by the Bitcoin protocol for 100 blocks. It is advisable to wait some additional time for a better chance that the transaction will be propogated by all nodes. Some older bitcoin clients won't show generated coins as confirmed until they are 120 blocks deep.


Best regards.

Muhammed Zakir
Hero Member
*****
Offline Offline

Activity: 560
Merit: 506


I prefer Zakir over Muhammed when mentioning me!


View Profile WWW
May 16, 2015, 04:04:59 PM
 #3

You can send a transaction which has inputs from an unconfirmed transaction but it is not a good idea to spend an unconfirmed UTXO as it is not sure whether the first transaction will be confirmed.

rmorris1965
Newbie
*
Offline Offline

Activity: 2
Merit: 0


View Profile
May 17, 2015, 10:42:23 AM
 #4

This is very helpful!

Thanks for the explanation!!  Grin
DannyHamilton
Legendary
*
Offline Offline

Activity: 3402
Merit: 4657



View Profile
May 17, 2015, 04:55:44 PM
 #5

Lets say I send some bitcoin to an address in a normal bitcoin transaction.  How many confirmations will it need before another transaction which spends those bitcoins will be accepted by nodes?

Zero.

It is possible (though ill-advised) to send a transaction, and then immediately use that new unspent output to fund another transaction.  In general, all nodes will accept and relay both transactions, and all miners (and mining pools) will consider confirming both transaction.

There is some risk however in using the outputs of an unconfirmed transaction to fund a transaction.  Due to the malleable nature of a bitcoin transaction ID, it is possible that a modified version of the first transaction which changes its hash will become confirmed, thereby making the second transaction invalid.  As such, if at all possible, it is advised to wait for at least 1 confirmation on a transaction before spending any of its outputs.
Muhammed Zakir
Hero Member
*****
Offline Offline

Activity: 560
Merit: 506


I prefer Zakir over Muhammed when mentioning me!


View Profile WWW
May 17, 2015, 05:00:15 PM
 #6

-snip-
Due to the malleable nature of a bitcoin transaction ID, it is possible that a modified version of the first transaction which changes its hash will become confirmed, {...}

Can you please explain this part further? Thank you!

DumbFruit
Sr. Member
****
Offline Offline

Activity: 433
Merit: 263


View Profile
May 20, 2015, 05:24:49 PM
 #7

-snip-
Due to the malleable nature of a bitcoin transaction ID, it is possible that a modified version of the first transaction which changes its hash will become confirmed, {...}

Can you please explain this part further? Thank you!

Transactions in Bitcoin have an ID that can be arbitrarily changed before their inclusion in a block, or if a reorganization happens. This is an intended feature of Bitcoin which allows things like CoinJoin.

https://en.bitcoin.it/wiki/Transaction_Malleability
https://bitcointalk.org/index.php?topic=279249.0

By their (dumb) fruits shall ye know them indeed...
bandana
Full Member
***
Offline Offline

Activity: 140
Merit: 100


View Profile
May 21, 2015, 03:20:04 PM
 #8

confirmations are placed to maintain a security towards the transaction. generally it takes 3 confirmations for a transaction.
you can place the next transaction before the last one gets confirmed. the miners will transact both of them.
you can also use unconfirmed transactions but it is recommended to use a confirmed transaction for security purposes.
shjsmith
Newbie
*
Offline Offline

Activity: 6
Merit: 0


View Profile
May 21, 2015, 04:05:26 PM
 #9

helpful tips and guide on bitcoin. much appreciated  Roll Eyes
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!