even i'm a sr. member here, i don't actually understand everything about bitcoin that's why i find your post very useful
Topic: A guide to how Bitcoin works under the hood. Blockchain and Transactions (Read 2486 times)
May 27, 2015, 09:03:55 PM
thank you so much for this. i learned a lot from your guide
even i'm a sr. member here, i don't actually understand everything about bitcoin that's why i find your post very useful
even i'm a sr. member here, i don't actually understand everything about bitcoin that's why i find your post very useful
May 27, 2015, 08:51:50 PM
Thank you for taking you time to write this, even beign familiarized with btc for 2/3 years i didn't knew all those technical facts about it, should totally get promoted on bigginners area could solve some issues newbies got on btc and also make them more interested in this awsome feature (btc).
May 27, 2015, 05:53:10 AM
interesting post. You should ask a moderator to add you descriptions in one of the pinned threads on this section. Otherwise this thread will be "disappered" soon on page 2, 3, 4..... No newbie will see and read it anymore.
hero member
Activity: 560
Merit: 509
I prefer Zakir over Muhammed when mentioning me!
May 26, 2015, 09:27:23 AM
About transaction fees:
Now the fee is no more the difference between all inputs and all outputs, but it is determined by the client in relation to its size and priority, am I right?
Now the fee is no more the difference between all inputs and all outputs, but it is determined by the client in relation to its size and priority, am I right?
It has not changed. {...}
Transaction fee reduced.
May 26, 2015, 04:00:32 AM
About transaction fees:
Now the fee is no more the difference between all inputs and all outputs, but it is determined by the client in relation to its size and priority, am I right?
Now the fee is no more the difference between all inputs and all outputs, but it is determined by the client in relation to its size and priority, am I right?
It has not changed. The fee is paid by making the outputs less than the inputs. The amount is determined by the client, generally by using the policies in Bitcoin Core that consider the size of the transaction and the age of the bitcoins.
May 25, 2015, 05:34:51 PM
Hi,
I know this is an old post and maybe things have changed since 2013.
About transaction fees:
Now the fee is no more the difference between all inputs and all outputs, but it is determined by the client in relation to its size and priority, am I right?
When was this modification established?
I know this is an old post and maybe things have changed since 2013.
About transaction fees:
Now the fee is no more the difference between all inputs and all outputs, but it is determined by the client in relation to its size and priority, am I right?
When was this modification established?
April 05, 2013, 06:16:47 AM
Bitcoin isn't something that you can learn in a few hours. Practically all of the mainstream media has "explained" bitcoin wrong, and this post is aimed at providing a somewhat technical read of how bitcoin works under the hood. So, let's get started!
Transaction
At it's core, Bitcoin is about transactions. Transactions simply send bitcoins from inputs to outputs. What are inputs and outputs? Let's say I have 5 bitcoins. I send 4 BTC to an address, 1GLadosEkeAsLReqS3yQ51E1R3wVtbJCDF.
There is one input. It's the transaction ID of my 5 BTC, along with a signature. The signature is like a passphrase - only the person who knows the private key (password, generated and stored automatically in your wallet) to an address can spend it. It works because the bitcoin software verifies that the signature is valid before accepting a transaction, otherwise it goes straight to /dev/null.
There's two outputs. A 4 BTC output to the 1GLados [..] address I sent to. The second output is 0.9995 BTC, to another address I just newly generated - a change address. Inputs can be only fully spent, so if I want to spend 4 BTC, I will have to spend my full 5 BTC and send the rest back to me.
What about the 0.0005 BTC? The difference between input and output sum is the transaction fee. In this case, the 0.0005 BTC goes to the miner who minted this block.
The transaction ID? It is a hash of the entire transaction. Hashes are a one way cryptography function - they're effectively a random mapping function. Two different transactions will never have the same transaction ID - really.
What are inputs? They're former outputs! If I want to spend all of the 0.9995 BTC I have left, then my input would be the transaction ID of my first transaction, plus the output ID 2. (In this case, ID 1 is my 4 BTC to 1Glados, ID 2 is my change).
So an input is sent to an output which is then later referred to as the input when you want to spend the coins.
Blocks
Blocks are simply a list of transactions. Miners run programs that tries to create blocks. They listen to the network, put the new transactions they heard about, and if they have a fee they're happy with, include it in the block they are working on. Now, to successfully mine a block, the hash (remember, hashes are basically random and unpredictable) of the block needs to start with a number of zeroes. Like this: 0000000000efc2r [..]. So a miner just repeatably tries to make a block with a hash that starts with a lot of zeroes.
How many zeroes? That is determined by the difficulty. The difficulty is automatically determined, and it's how fast the last 2016 blocks where mined. The difficulty makes sure that there's on average, a block every 10 minutes - regardless of how many people are mining for stability reasons. As hashing / mining for blocks is just luck, sometimes there might be four blocks in a minute, sometimes there might be no blocks for a hour.
When a transaction is included in a block, it gets 1 confirmations. The miner also gets a block subsidy to reward them (and distribute the remaining bitcoins), currently 25 BTC which halves every four years until it gets to zero. After a block is minted and announced to the network, miners will now try to build blocks off that block - referring to the previous block. This is how the blockchain works.
[Block 22730] -> [Block 22731] -> [Block 22732] [ORPHANED BLOCK]
...............\-> [Block 22731] -> [Block 22732] -> [Block 22733] [LONGEST CHAIN]
Huh? Let's say the latest block generated is 22730. We know it, not because it has an ID, but because it refers to a previous block (22729) which refers to a previous block which refers to a previous block... and if you go all the way back - you count 22731 blocks. That's how blocks are given numbers.
Now, the latest block generated is 22730. A miner generates 22731, with the 25 BTC subsidy going to them and transactions they heard about. Another miner also generates a block referring to 22730 as it's parent, with their own subsidy address and their own transactions they know. So now we have two blocks at height 22731. The blockchain now has a fork.
Some clients heard about the first block, while some clients heard about the second block. Now, a portion of miners are building upon the first block 22731, while the other portion is building upon (referring to) the second block 22731. A transaction included in the 'first 22731' isn't included in the other block. Some clients now see that transaction with 1 confirmation, while others see it as unconfirmed (0 confirmations).
Soon, a miner generated block 22732 with it's parent being the first block! The transaction included in that earlier block now has 2 confirmations to some users and services. Now, since this blockchain is longer (22732 > 22731), clients will now update their latest block to 22732. However - just then, another miner had some good luck and generated blocks 22732 (referring to the second block) and 22733 in less than a second. Clients see that 22733 > 22732, and moves to the second blockchain. That now becomes the main blockchain, with the first being orphaned.
So what happens? That transaction included in one block but not another? 2 confirmations to 0 (unconfirmed). Now, assume the person sending the TX is malicious, and has got a double spend (spend the same inputs, to a different output controlled by the attacker) into the second block which is now the main chain. Services or users who accepted the "2 confirmations" transaction.. just lost those coins. This is the danger with accepting transactions with few confirmations.
Generally speaking, it's safe to accept TXes with at least 6 confirmations. Of course, if you know someone personally or if it's from a reputable service, then you can accept it even when it's unconfirmed.
Transaction
At it's core, Bitcoin is about transactions. Transactions simply send bitcoins from inputs to outputs. What are inputs and outputs? Let's say I have 5 bitcoins. I send 4 BTC to an address, 1GLadosEkeAsLReqS3yQ51E1R3wVtbJCDF.
There is one input. It's the transaction ID of my 5 BTC, along with a signature. The signature is like a passphrase - only the person who knows the private key (password, generated and stored automatically in your wallet) to an address can spend it. It works because the bitcoin software verifies that the signature is valid before accepting a transaction, otherwise it goes straight to /dev/null.
There's two outputs. A 4 BTC output to the 1GLados [..] address I sent to. The second output is 0.9995 BTC, to another address I just newly generated - a change address. Inputs can be only fully spent, so if I want to spend 4 BTC, I will have to spend my full 5 BTC and send the rest back to me.
What about the 0.0005 BTC? The difference between input and output sum is the transaction fee. In this case, the 0.0005 BTC goes to the miner who minted this block.
The transaction ID? It is a hash of the entire transaction. Hashes are a one way cryptography function - they're effectively a random mapping function. Two different transactions will never have the same transaction ID - really.
What are inputs? They're former outputs! If I want to spend all of the 0.9995 BTC I have left, then my input would be the transaction ID of my first transaction, plus the output ID 2. (In this case, ID 1 is my 4 BTC to 1Glados, ID 2 is my change).
So an input is sent to an output which is then later referred to as the input when you want to spend the coins.
Blocks
Blocks are simply a list of transactions. Miners run programs that tries to create blocks. They listen to the network, put the new transactions they heard about, and if they have a fee they're happy with, include it in the block they are working on. Now, to successfully mine a block, the hash (remember, hashes are basically random and unpredictable) of the block needs to start with a number of zeroes. Like this: 0000000000efc2r [..]. So a miner just repeatably tries to make a block with a hash that starts with a lot of zeroes.
How many zeroes? That is determined by the difficulty. The difficulty is automatically determined, and it's how fast the last 2016 blocks where mined. The difficulty makes sure that there's on average, a block every 10 minutes - regardless of how many people are mining for stability reasons. As hashing / mining for blocks is just luck, sometimes there might be four blocks in a minute, sometimes there might be no blocks for a hour.
When a transaction is included in a block, it gets 1 confirmations. The miner also gets a block subsidy to reward them (and distribute the remaining bitcoins), currently 25 BTC which halves every four years until it gets to zero. After a block is minted and announced to the network, miners will now try to build blocks off that block - referring to the previous block. This is how the blockchain works.
[Block 22730] -> [Block 22731] -> [Block 22732] [ORPHANED BLOCK]
...............\-> [Block 22731] -> [Block 22732] -> [Block 22733] [LONGEST CHAIN]
Huh? Let's say the latest block generated is 22730. We know it, not because it has an ID, but because it refers to a previous block (22729) which refers to a previous block which refers to a previous block... and if you go all the way back - you count 22731 blocks. That's how blocks are given numbers.
Now, the latest block generated is 22730. A miner generates 22731, with the 25 BTC subsidy going to them and transactions they heard about. Another miner also generates a block referring to 22730 as it's parent, with their own subsidy address and their own transactions they know. So now we have two blocks at height 22731. The blockchain now has a fork.
Some clients heard about the first block, while some clients heard about the second block. Now, a portion of miners are building upon the first block 22731, while the other portion is building upon (referring to) the second block 22731. A transaction included in the 'first 22731' isn't included in the other block. Some clients now see that transaction with 1 confirmation, while others see it as unconfirmed (0 confirmations).
Soon, a miner generated block 22732 with it's parent being the first block! The transaction included in that earlier block now has 2 confirmations to some users and services. Now, since this blockchain is longer (22732 > 22731), clients will now update their latest block to 22732. However - just then, another miner had some good luck and generated blocks 22732 (referring to the second block) and 22733 in less than a second. Clients see that 22733 > 22732, and moves to the second blockchain. That now becomes the main blockchain, with the first being orphaned.
So what happens? That transaction included in one block but not another? 2 confirmations to 0 (unconfirmed). Now, assume the person sending the TX is malicious, and has got a double spend (spend the same inputs, to a different output controlled by the attacker) into the second block which is now the main chain. Services or users who accepted the "2 confirmations" transaction.. just lost those coins. This is the danger with accepting transactions with few confirmations.
Generally speaking, it's safe to accept TXes with at least 6 confirmations. Of course, if you know someone personally or if it's from a reputable service, then you can accept it even when it's unconfirmed.
Jump to: