Author

Topic: Bitcoin Blocks and Transactions (Read 1671 times)

full member
Activity: 134
Merit: 100
December 29, 2011, 03:58:05 PM
#11
Excellent. Makes perfect sense. Thanks again!
donator
Activity: 1218
Merit: 1079
Gerald Davis
December 29, 2011, 03:05:12 PM
#10
*BING* Perfect. Makes absolute sense now. Just back to one of my original questions - block pruning - Am I right in thinking that you could just truncate all blocks prior to the point where the likelyhood of anyone managing to replace the current block-chain with their own 'version of events' is nearly equal to zero?  

Thanks again for all this. It has been most instructive.

No you can't prune all prior blocks because what about addresses which aren't involved in the blocks you are keeping.   If you prune a transaction w/ an address that has no subsequent transaction (or prune the entire block) then data will be lost.  

However there are other methods to prune the block chain.   You can partially prune blocks and only keep the final transaction in a transaction chain.


To keep it simple say in block 100 someone (address A) mines 50 BTC.  It (the full 50 BTC) is then transfered to B, C, D, E, F.  Lets also assume there is no transaction fees and since full 50 BTC is transfered there is no change address.

If you reconstructed this from the block chain it might look something like this:

Coinbase -> Address A -> Address B -> Address C -> Address D ->  Address E -> Address F

Coinbase -> A is in block 100
A->B in block 123
B->C in block 3847
C->D in block 14101
D->E in block 15000

Say we assume transactions older than block 15,000 are cononical.  They are too deep (and behind hard checkpoints) to make their reversal possible.

We could keep the transaction D->E and prune all prior transactions from their respective blocks.  That would save ~4KB from the blockchain.  Now imagine doing this with every transaction chain.  Since blocks are created as a merkle tree we can remove transactions from the block leaving only the hash in the tree and still be able to validate the tree & block.  This is important because as long as 1 or more transaction from the block remains we need to be able to validate the block and transaction.

Obviously this example was simple because it involved only a single coinbase, and the "full" 50 BTC is transfered each time.  In reality pruning is much more complex.
full member
Activity: 134
Merit: 100
December 29, 2011, 03:00:03 PM
#9
*BING* Perfect. Makes absolute sense now. Just back to one of my original questions - block pruning - Am I right in thinking that you could just truncate all blocks prior to the point where the likelyhood of anyone managing to replace the current block-chain with their own 'version of events' is nearly equal to zero? 

Thanks again for all this. It has been most instructive.
donator
Activity: 1218
Merit: 1079
Gerald Davis
December 29, 2011, 02:43:01 PM
#8
Ah ok - getting there Wink , so every new transaction - in order to be confirmed - gets aggregated into the next new block minted? So a block's boundries are the number of unconfirmed transactions the miner has decides to include - so a block (and the transactions it contains) are forever fixed? If this is the case - what happens when blocks stop being minted? I know there is a 'transaction fee' (currently optional in most cases) - but I'm not certain how this would factor in when 21 million coins have been created?

Thanks again!

Yes.  A block contains whatever transaction the miner decides to include.  Once included in a block transactions are never included in any subsequent block.  Each transaction is only in one block for the current blockchian.

Yes.  A transaction if "fixed" once included in a block.  Remember a longer chain could replace the existing chain and that transaction would be replaced.  The deeper a transaction is in the block chain the less likely (rapidly approaching 0%) the chance that will happen.  This is why by default the client considers transactions older than 6 blocks (6 confirmations) to be trusted.

Mining never stops.  Block subsidies will decrease from 50 to 0 but minting will continue forever.
Miner reward = block subsidy (currently 50 BTC declining to 25 ~Dec 2012) + transaction fees for all transactions in the block.
full member
Activity: 134
Merit: 100
December 29, 2011, 02:26:40 PM
#7
Ah ok - getting there Wink , so every new transaction - in order to be confirmed - gets aggregated into the next new block minted? So a block's boundries are the number of unconfirmed transactions the miner has decides to include - so a block (and the transactions it contains) are forever fixed? If this is the case - what happens when blocks stop being minted? I know there is a 'transaction fee' (currently optional in most cases) - but I'm not certain how this would factor in when 21 million coins have been created?

Thanks again!
donator
Activity: 1218
Merit: 1079
Gerald Davis
December 29, 2011, 01:21:54 PM
#6
Thanks alot. That's cleared up a lot of my misunderstandings (I think) - still a few questions though. If I understand this correctly (here's hoping) - and please point out where I've clearly missed the point - :

  • A block is a series of transactions arranged in a tree I'd presume with the root address being the 'coinbase', owned by the miner?
  • A block comprises of all the transfers of ownership (transactions) pertaining to all of that block?
  • When a one or more of the addresses 'spends' (transfers ownership of some portion of the amount they currently own within the block), how does this get appended to the block chain? I mean - I'm not sure if I totally grasped this concept correctly, but when the user performs the transaction, do they broadcast the whole block (all the transactions since the coinbase) with their transfer declaration appended, and - if so - what happens when two or more addresses with ownership over some portion of the same block perform transactions involving it at the same time? E.g. ABC owns 20/50 DEF owns 30/50 - ABC transfers 10 to XYZ (with 10 output back to ABC) while DEF simaltaniously transfers ownership of 25 to LMN (with 5 output back to DEF)? I'm trying to picture in my head how the block-chain looks, how clients are able to not end up downloading blocks with (possibly) millions of transactions, and how blockexplorer etc are able to track down all transactions with relative ease - since you can't really do an SQL equivilant of SELECT transactions FROM block ORDER BY transaction_date... or can you?

Thanks for bearing with me.

Still getting it wrong.  coins are never in a block.  never.  not once, not ever.  never.  So it is nonsensical to say ABC has 20/50 and DEF has 30/50 of the coins in the block.  It is simpy ABC has 20 coins (of the 10 million minted so far),  DEF has 30.  Period. 

There are no coins.
There are simply addresses.  
Those addresses have values (1 BTC, 0.001 BTC, 10,000 BTC, etc).
You move value between addresses by a transaction.

Blocks are simply a collection of transactions.

Coins aren't stored in blocks.
Addresses are stored in blocks.
Blocks are simply a collection of transactions (instructions to move coins between addresses)

So say right now there are 128 transactions which aren't in any block.  The miners working right now have constructed a block w/ some/all of those unconfirmed transactions and are attempting to solve the block.  When one finds a hash smaller than the target they have solved the block and they publish their block to the network and it becomes the next block in the chain.  Those transaction are now confirmed and have become part of the blockchain.  Miners then update their lists of unconfirmed transactions and start work on the next block ... and next block .... and the next block forever.
full member
Activity: 134
Merit: 100
December 29, 2011, 01:15:16 PM
#5
Thanks alot. That's cleared up a lot of my misunderstandings (I think) - still a few questions though. If I understand this correctly (here's hoping) - and please point out where I've clearly missed the point - :

  • A block is a series of transactions arranged in a tree I'd presume with the root address being the 'coinbase', owned by the miner?
  • A block comprises of all the transfers of ownership (transactions) pertaining to all of that block?
  • When a one or more of the addresses 'spends' (transfers ownership of some portion of the amount they currently own within the block), how does this get appended to the block chain? I mean - I'm not sure if I totally grasped this concept correctly, but when the user performs the transaction, do they broadcast the whole block (all the transactions since the coinbase) with their transfer declaration appended, and - if so - what happens when two or more addresses with ownership over some portion of the same block perform transactions involving it at the same time? E.g. ABC owns 20/50 DEF owns 30/50 - ABC transfers 10 to XYZ (with 10 output back to ABC) while DEF simaltaniously transfers ownership of 25 to LMN (with 5 output back to DEF)? I'm trying to picture in my head how the block-chain looks, how clients are able to not end up downloading blocks with (possibly) millions of transactions, and how blockexplorer etc are able to track down all transactions with relative ease - since you can't really do an SQL equivilant of SELECT transactions FROM block ORDER BY transaction_date... or can you?

Thanks for bearing with me.
sr. member
Activity: 322
Merit: 251
FirstBits: 168Bc
December 29, 2011, 11:45:44 AM
#4
each block (currently valued at 50 BTC)

50 BTC is the reward for verifying a block. Within the block is a transaction from "nowhere" to a new address totaling 50 BTC (a gift from the block chain gods). Also within that block are numerous other transactions, all of which originated from some address(es) to new address(es) of various amounts collected from numerous unknown people.


Now, each block address can have it all or part of it's ownership transferred to any number of different recipients (pubkeys) through transactions.

And all of these transactions must be verified in a block before it is confirmed or accepted by the entire network.


Are transactions recorded against the block

Every valid transaction must be recorded within a block in order to be confirmed/accepted by the network.


if you've got BTC amount of 10, of which 5 came from Block Address A, and 5 came from Block Address B and you transfer all 10 BTC to another 'person' - are two transactions generated ... ?

Only one transaction is required. Though, what you describe is not a typical transaction. Typically a transaction is from one or more addresses from a single person to another address of another person and the remainder is send back to a new address of the first person (spare change).

Imagine you want to buy a chocolate for 8 pesos. You give a 5 peso coin and two 2 peso coins. The recipient returns a 1 peso coin. In this scenario you sent 9 coins from three 'addresses' to a single recipient who returned 1 coin to you (a new address). It's not a perfect analogy, but close..


If a block is eternal - how can it ever become 'spent'?

A block is a collection of transactions. Each transaction is from some set of addresses to another set of addresses. The balances of addresses are 'spend'. Transactions are recorded in blocks and both of which after an hour or so of uncontested confirmation become part of the permanent record.


The wiki indicates that Sathoshi's paper allows the merkel tree to be 'pruned'

Perhaps you should wait for the above to gell before diving into pruning the blockchain.


but what is to stop me creating multiple transactions of 10E-8 back to myself

You can create the transactions and you may choose to pay a transaction fee. If no miner bothers to lock your transactions in a block, then the network will never accept your transaction. Your transactions will be forever (or for a long long time) unconfirmed.
sr. member
Activity: 322
Merit: 251
FirstBits: 168Bc
December 29, 2011, 11:31:16 AM
#3
A transaction is just a line in a balance sheet something like:

AAA (which had 10 BTC) sends 6 BTC to BBB and 4 BTC to CCC

A block is a collection of transaction lines. The transactions and previous block are verified with a stamp of approval by a miner. This chain of blocks (verifying the previous) continues on linearly such that it becomes more and more difficult for any miner to reverse old blocks by claiming some alternate history of transactions.

The block chain is a bit like tradition, the older and more widely accepted, the more 'true' it becomes.
donator
Activity: 1218
Merit: 1079
Gerald Davis
December 29, 2011, 10:07:03 AM
#2
I think you misunderstand what blocks are.

First it is somewhat confusing but Bitcoins don't exist.  Bitcoins are simply a unit.  The block chain records the CURRENT VALUE of each address.  So there are ~10M BTC generated.  Thus the address add up to ~10M BTC.

The value is moved from one address to another via transactions.   To avoid someone creating 2 transactions with the same input we take unconfirmed transactions (transactions not yet in any block) and create a block.  We then try to find a hash which is smaller than th e required target.  If/when we do that block is transmitted to the network and the blockchain grows by one block.

Blocks are merely a collection of transactions.  Transactions involve addresses.  Addresses are where Bitcoins are stored.

Quote
how is potential fragmentation due to high volume, small denomination amounts addressed? Every transaction must be logged - but what is to stop me creating multiple transactions of 10E-8 back to myself - increasing the actual data size of any transaction that would then need to use that block's Bitcoins. E.g. I send 1 Btc to a target, comprised of 10E8 individual inputs - resulting in (i guess) a large amount of binary data. Even if there was no malicious intent, surely though the growth of bitcoin,


Fees.  You could do that but it would be prohibitively expensive.  Also as the block gets more than 50% full fees rise exponentially.  Eventually the cost to continue to send ultra small transactions will be a fortune.  Your bankroll limits how much spam you can generate.


Quote
fragmentation of blocks will become a problem (this assumes I've understood how transactions and blocks are linked).

There is no such thing as fragmentation of blocks however lots of small transactions take up block space and increase future computational cost so they are "penalized" w/ fees.  
full member
Activity: 134
Merit: 100
December 29, 2011, 09:22:49 AM
#1
Could someone please clarify a few points with regards to the blockchain and transactions. My understanding is that each block (currently valued at 50 BTC) forms a part of the block chain back to the genesis block. Now, each block can have it all or part of it's ownership transferred to any number of different recipients (pubkeys) through transactions.

  • Are transactions recorded against the block, or seperately to the block-chain? What I mean by this is - if you've got BTC amount of 10, of which 5 came from Block A, and 5 came from Block B and you transfer all 10 BTC to another 'person' - are two transactions generated - one per block indicating the transfer of ownership of that portion of the block to the recipient?
  • If a block is eternal - how can it ever become 'spent'? The wiki indicates that Sathoshi's paper allows the merkel tree to be 'pruned' of spent blocks (although this is not currently implemented). However, if all that is transferred is all/part ownership of a block - surely they can never be removed since someone may wish to 'spend' (transfer ownership) of the BTC's at any point in the future?. Meaning everyone requires the full block chain - or the ability to retrieve any part of that block chain - in order to validate a transaction containing 'early' blocks?
  • How is potential fragmentation due to high volume, small denomination amounts addressed? Every transaction must be logged - but what is to stop me creating multiple transactions of 10E-8 back to myself - increasing the actual data size of any transaction that would then need to use that block's Bitcoins. E.g. I send 1 Btc to a target, comprised of 10E8 individual inputs - resulting in (i guess) a large amount of binary data. Even if there was no malicious intent, surely though the growth of bitcoin, fragmentation of blocks will become a problem (this assumes I've understood how transactions and blocks are linked).

Much obliged for the assistance!
Jump to: