Topic: Guide to how Bitcoin works (Read 11327 times)
Ah, right, my calculation was off. Nevermind then.
My "oldest" transaction is from 7/11 (roughly 6 days ago). It has 2983 confirmations, which even at a "slow" estimate of every 10 minutes, that was 8 hours ago. :-S And it doesn't increase when the number of blocks does.
How did you compute that time? 2983 confirmations / 6 confirmations per hour ≐ 497 hours ≐ 21 days.
The result is this big because currently, block are generated much faster than one per 10 minutes.
Is it possible that your confirmations are rising so quickly because multiple people are generating the same blocks at the same time? I know one of the devs mentioned that this does happen, and it makes things act weird until the blocks are verified by multiple other clients, at which point one of them wins out. It may be that the confirmations are tracking all of the blocks, not just the ones that ultimately win out...?
Or, is it possible that each subsequent block is also getting confirmed? In other words, block 66,000 was the block in which your transaction took place... so then when block 66,001 is created, you get 1 confirmation. Then when block 66,002 is created, it in turn confirmed block 66,001, so you get 2 more confirmations - bringing the total to 3...?
Still wrapping my head around parts of it, so I may be way off.
Or, is it possible that each subsequent block is also getting confirmed? In other words, block 66,000 was the block in which your transaction took place... so then when block 66,001 is created, you get 1 confirmation. Then when block 66,002 is created, it in turn confirmed block 66,001, so you get 2 more confirmations - bringing the total to 3...?
Still wrapping my head around parts of it, so I may be way off.
My "oldest" transaction is from 7/11 (roughly 6 days ago). It has 2983 confirmations, which even at a "slow" estimate of every 10 minutes, that was 8 hours ago. :-S And it doesn't increase when the number of blocks does.
Also, A coin, block, transaction etc are all concepts. =P When I say "trace", I mean that a coin is nothing more than it's history of transactions, found within blocks.
If that's how you want to define Coin that's up to you. I still maintain that a Coin is not a "thing", a block is, and a transactions is, but a coin is not.
Quote
I'm going into the technical detail here because I want to make sure I have it right before I generalize or simplify things. I'd also like to incorporate how it works at this core level, because a lot of the confusion I've seen new users have stems from the fact that they don't understand that, and figuring that out really helped me personally.
That certainly sounds sensible.
Quote
As for verifications, that's what I thought at first. However, the "Confirmations" goes up at a very disproportionate rate to blocks generated. If a verification/confirmation was simply someone burying it in the chain with future blocks, then it would get one confirmation every 10 minutes. So, The only other explanation I can think of is that the verification/confirmations happen every time someone "checks" to make sure that the block the transaction is contained in is correct (by hashing it and comparing to the target value), which is done roughly once per user on the network (thus, a rapid increase when a transaction first occurs, as it propogates through the network, followed by the very slow incremental increase as new users "log on" and verify the blocks that happened in their absence.)
Have you measured how quickly the blocks are generating lately? It's more than 1 every 10 minutes.Try doing a transaction and noting the block number when it goes to 1/unconfirmed. You will then see that the confirmation value is the same as the number of blocks 'elapsed'.
I left out chain because that was the whole "previous hash" part of the block, forgot to explicitly state it.
Also, A coin, block, transaction etc are all concepts. =P When I say "trace", I mean that a coin is nothing more than it's history of transactions, found within blocks.
I'm going into the technical detail here because I want to make sure I have it right before I generalize or simplify things. I'd also like to incorporate how it works at this core level, because a lot of the confusion I've seen new users have stems from the fact that they don't understand that, and figuring that out really helped me personally.
As for verifications, that's what I thought at first. However, the "Confirmations" goes up at a very disproportionate rate to blocks generated. If a verification/confirmation was simply someone burying it in the chain with future blocks, then it would get one confirmation every 10 minutes. So, The only other explanation I can think of is that the verification/confirmations happen every time someone "checks" to make sure that the block the transaction is contained in is correct (by hashing it and comparing to the target value), which is done roughly once per user on the network (thus, a rapid increase when a transaction first occurs, as it propogates through the network, followed by the very slow incremental increase as new users "log on" and verify the blocks that happened in their absence.)
Also, A coin, block, transaction etc are all concepts. =P When I say "trace", I mean that a coin is nothing more than it's history of transactions, found within blocks.
I'm going into the technical detail here because I want to make sure I have it right before I generalize or simplify things. I'd also like to incorporate how it works at this core level, because a lot of the confusion I've seen new users have stems from the fact that they don't understand that, and figuring that out really helped me personally.
As for verifications, that's what I thought at first. However, the "Confirmations" goes up at a very disproportionate rate to blocks generated. If a verification/confirmation was simply someone burying it in the chain with future blocks, then it would get one confirmation every 10 minutes. So, The only other explanation I can think of is that the verification/confirmations happen every time someone "checks" to make sure that the block the transaction is contained in is correct (by hashing it and comparing to the target value), which is done roughly once per user on the network (thus, a rapid increase when a transaction first occurs, as it propogates through the network, followed by the very slow incremental increase as new users "log on" and verify the blocks that happened in their absence.)
Coin: A cryptographically secure "trace" of all transactions back to the generation of said coin.
Block: A cryptographically secure record of all transactions occurring in a (roughly) 10 minute time period.
Transaction: A publicly announced transfer of ownership of a bitcoin.
Block: A cryptographically secure record of all transactions occurring in a (roughly) 10 minute time period.
Transaction: A publicly announced transfer of ownership of a bitcoin.
Important things you have left out:
"Address" and "Chain"
A "Coin" is not a thing. A coin is a concept. An address 'holds' coins.
Block is correct. Blocks form a chain.
Transaction is a transfer of coins from one address to another address.
Quote
The general process for creating a block:
Create a section of memory containing: Timestamp, the previous blocks hash, an integer we'll call "Nonce", and a set of transactions.
Add a transaction to said block which transfers 50 btc to you out of thin air. Because this contains your bitcoin address, this makes the block of memory unique to you.
Ok, You seem to be going into a lot of technical detail for a general guide.Create a section of memory containing: Timestamp, the previous blocks hash, an integer we'll call "Nonce", and a set of transactions.
Add a transaction to said block which transfers 50 btc to you out of thin air. Because this contains your bitcoin address, this makes the block of memory unique to you.
What you have said here is correct, but it took me a while to work out what you were trying to say.
Quote
Until the solution is found:
- Check to see if someone's already solved the block. If so, keep the section of memory in tact, but look at their solution.
- Check to see that all the transactions are in the block, the timestamp and previous hash are correct, and the hash of the whole thing produces something less than the target. If so, tell everyone you've verified the block, and start listening to see if other people have verified it. Once a certain number of people have verified it's accuracy, (120 to be exact), wipe the section of memory above clean and start over.
- Check for new transactions. If so, add it to the section of memory above.
- Hash the section of memory, producing it's "DNA"/Signature (I've found that's the best way to explain hashes to someone unfamiliar with them)
- Compare this hash to a "target" value. This is some value that all of the clients agree upon. If it's less, Shout bingo.
- Otherwise, increase the value of Nonce and loop.
- Check to see if someone's already solved the block. If so, keep the section of memory in tact, but look at their solution.
- Check to see that all the transactions are in the block, the timestamp and previous hash are correct, and the hash of the whole thing produces something less than the target. If so, tell everyone you've verified the block, and start listening to see if other people have verified it. Once a certain number of people have verified it's accuracy, (120 to be exact), wipe the section of memory above clean and start over.
- Check for new transactions. If so, add it to the section of memory above.
- Hash the section of memory, producing it's "DNA"/Signature (I've found that's the best way to explain hashes to someone unfamiliar with them)
- Compare this hash to a "target" value. This is some value that all of the clients agree upon. If it's less, Shout bingo.
- Otherwise, increase the value of Nonce and loop.
Your ideas about verification are wrong.
Once you receive a 'solved' block, you see if you think it is good. if it is, you start again using this recent blocks hash.
A block becomes 'confirmed' or 'verified' as by being buried deeper in the chain as new blocks are added.
I found the rest of this loop a little confusing, it seems more or less right though.
Quote
When reconnecting to the network, you have to download blocks that were solved since you last DC'd. Each one you download, you verify it
This is correct.Quote
, and broadcast whether you found it was valid or not. This is what increases the "confirmations" count in the UI.
This is not.Hopefully some of that is helpful.
Try asking specific questions about the bits you don't understand.
>.< Yea, I've read the wiki, as well as the PDF/Whitepaper.
Is the above information generally accurate? If so, I'll go ahead and finish up my guide (written much more succinctly than this post, I should hope) and post it here for other people to digest. 
Unfortunately, not really. Did you check out the wiki? It's being constantly updated.
I'll make another post trying to explain where you've gone wrong, but it might take a little time.
I'm currently in the process of writing a very concise guide of how bitcoin works for those new to the system and without the benefit of the background in programming I had. I just want to make sure I have it all correct, so here's my understanding of the core concepts:
Coin: A cryptographically secure "trace" of all transactions back to the generation of said coin.
Block: A cryptographically secure record of all transactions occurring in a (roughly) 10 minute time period.
Transaction: A publicly announced transfer of ownership of a bitcoin.
The general process for creating a block:
Create a section of memory containing: Timestamp, the previous blocks hash, an integer we'll call "Nonce", and a set of transactions.
Add a transaction to said block which transfers 50 btc to you out of thin air. Because this contains your bitcoin address, this makes the block of memory unique to you.
Until the solution is found:
- Check to see if someone's already solved the block. If so, keep the section of memory in tact, but look at their solution.
- Check to see that all the transactions are in the block, the timestamp and previous hash are correct, and the hash of the whole thing produces something less than the target. If so, tell everyone you've verified the block, and start listening to see if other people have verified it. Once a certain number of people have verified it's accuracy, (120 to be exact), wipe the section of memory above clean and start over.
- Check for new transactions. If so, add it to the section of memory above.
- Hash the section of memory, producing it's "DNA"/Signature (I've found that's the best way to explain hashes to someone unfamiliar with them)
- Compare this hash to a "target" value. This is some value that all of the clients agree upon. If it's less, Shout bingo.
- Otherwise, increase the value of Nonce and loop.
When reconnecting to the network, you have to download blocks that were solved since you last DC'd. Each one you download, you verify it, and broadcast whether you found it was valid or not. This is what increases the "confirmations" count in the UI.
Is the above information generally accurate? If so, I'll go ahead and finish up my guide (written much more succinctly than this post, I should hope) and post it here for other people to digest.
Coin: A cryptographically secure "trace" of all transactions back to the generation of said coin.
Block: A cryptographically secure record of all transactions occurring in a (roughly) 10 minute time period.
Transaction: A publicly announced transfer of ownership of a bitcoin.
The general process for creating a block:
Create a section of memory containing: Timestamp, the previous blocks hash, an integer we'll call "Nonce", and a set of transactions.
Add a transaction to said block which transfers 50 btc to you out of thin air. Because this contains your bitcoin address, this makes the block of memory unique to you.
Until the solution is found:
- Check to see if someone's already solved the block. If so, keep the section of memory in tact, but look at their solution.
- Check to see that all the transactions are in the block, the timestamp and previous hash are correct, and the hash of the whole thing produces something less than the target. If so, tell everyone you've verified the block, and start listening to see if other people have verified it. Once a certain number of people have verified it's accuracy, (120 to be exact), wipe the section of memory above clean and start over.
- Check for new transactions. If so, add it to the section of memory above.
- Hash the section of memory, producing it's "DNA"/Signature (I've found that's the best way to explain hashes to someone unfamiliar with them)
- Compare this hash to a "target" value. This is some value that all of the clients agree upon. If it's less, Shout bingo.
- Otherwise, increase the value of Nonce and loop.
When reconnecting to the network, you have to download blocks that were solved since you last DC'd. Each one you download, you verify it, and broadcast whether you found it was valid or not. This is what increases the "confirmations" count in the UI.
Is the above information generally accurate? If so, I'll go ahead and finish up my guide (written much more succinctly than this post, I should hope) and post it here for other people to digest.
Jump to: