Question about block chains (technical)

[b99999]

Hi,

This is a technical question, but as I'm still a newbie this is the only group I can post in.

I've been reading some stuff about how Bitcoin works and browsed through the source code.

I have a question related to high number of transactions.

So, in order to confirm a transaction, a new chain block has to be computed with that transaction inside it. Normally, Bitcoin clients receive information about transactions through the P2P network and they start computing new blocks.

The block computation thread takes transactions that a node received, bundles them together by priority etc and then tries to compute a valid node.
Then after it tries 65535 nonces (if I'm not reading the source code wrong) or 60 seconds elapsed, it rebuilds a block and tries again.

If this is correct, I have the following questions:

1) This means that nodes are trying blocks with different transactions - in other words once a valid block has been found, a node has to delete certain transactions and add new ones to the new try?

2) What happens if the number of transactions is very high? It appears to me as if either blocks will be very big (initially) or the confirming time will increase?


Thanks.

[1713512986]

1713512986

[BookLover]

1) Yes if I understand what you mean, Once a block is solved and a mining node sees it then it will update the work it's doing to not include transactions which have already been sent.

2) I believe most miners only allow a certain number of transaction in a block to prevent it from getting to large. The bitcoin client will then chose which transactions to chose based on their priority you can see the priority of the current unconfirmed transactions here: http://bitcoincharts.com/bitcoin/
I don't believe the amount of transactions is a very large factor in how long it takes to find a block.  It mainly has to do with the current difficulty and the luck of the miner.

[b99999]

1) Yes if I understand what you mean, Once a block is solved and a mining node sees it then it will update the work it's doing to not include transactions which have already been sent.

Thanks, that confirms what I was thinking about.

2) I believe most miners only allow a certain number of transaction in a block to prevent it from getting to large. The bitcoin client will then chose which transactions to chose based on their priority you can see the priority of the current unconfirmed transactions here: http://bitcoincharts.com/bitcoin/
I don't believe the amount of transactions is a very large factor in how long it takes to find a block.  It mainly has to do with the current difficulty and the luck of the miner.

Yeah, the amount of transactions shouldn't be a large factor in how long it takes to mine the block.
However, what I'm thinking (worried) about is this:

If we need a certain time to find a valid block (~every 10 minutes now), what happens if the number of transactions increases substantially? This can be a problem especially since, as you said, the number of transactions in a block is limited.

So, let's say hypothetically that we have 100 transactions in a block max, if we're getting 10000 transactions per second and we get only one block every couple of minutes we won't be able to confirm all transactions?

And what's even worse, once a block has been computed another node might have been working on 80 transactions from this block and 20 new. When the node that computed the block announces it, this other node has to stop what it's doing and start with a new block (although that does not affect the chance of finding a correct block).

My main worry here is how it will scale - currently the number of transactions is relatively low.

Thanks for answers so far

[bcforum]

The transactions are hashed into a Merkle tree and only a single hash representing the entire tree is included into the block. Because of this, the number of transactions doesn't impact the time required to find a block.

On the other hand, a block that is too large will take longer to propagate through the network, and will increase the chances of it becoming invalid later on (not part of the longest block chain.)

[b99999]

The transactions are hashed into a Merkle tree and only a single hash representing the entire tree is included into the block. Because of this, the number of transactions doesn't impact the time required to find a block.

On the other hand, a block that is too large will take longer to propagate through the network, and will increase the chances of it becoming invalid later on (not part of the longest block chain.)

Thanks - that makes sense - the Merkle tree is built of hashes of each transaction. Does the block later carry all information (the transaction information as well as the "hashed header")?  (guess I'm not that far into reading the code yet).

My main question is if it is possible to overwhelm the network with a high number of transactions. If a block can have only a limited number (n) of transaction, and we create a block every N minutes (so effectively, we can confirm only n transactions every N minutes having the throughput of n/N/60 per second), is it possible to create zillions of micro transactions to overwhelm the network?

I know micro transactions will be charged for, but if I have money to waste, can I impact the whole Bitcoin?

[bcforum]

Yes, all the transactions that are hashed together are included into the block that is sent.

The reference bitcoin client (which is used by most mining pools) will ignore (silently drop) transactions that are small, use recently acquired coins, and don't include a fee. This prevents them from propagating and also completing. This mitigates the impact of such an attack.

[Gabi]

A block DO NOT have a limited number of transactions. Sure, miners can choose what and how much transactions insert in each block but so far they include every available transactions.

The current bitcoin client anyway doesn't allow such a flood attack

[Pearikay]

A block DO NOT have a limited number of transactions. Sure, miners can choose what and how much transactions insert in each block but so far they include every available transactions.

The current bitcoin client anyway doesn't allow such a flood attack

This is true

[b99999]

Thanks for all the answers so far ... just one more question (I can't promise it's the last one  .

If I'm not wrong, the current client by default does not generate Bitcoins, meaning you have to manually start it with the -gen option.

Does this mean that currently such clients will never generate new blocks? If I'm not wrong (might have missed this in the code), currently only when generating new Bitcoins you also generate the blocks?

[Gabi]

Generating blocks is called "mining"

And yes, the bitcoin client doesn't mine. Why? Cause it would CPU mine and well CPU mining is sloooooow, compared to GPU mining.

Mining create new blocks and when a block is created, who find it receive 50 bitcoins

If you want to mine you have to download a GPU miner like Guiminer and have a supported graphic card. Forget CPU mining, you can do it but is slow, my Q9550 make like 20mhash/s, while my 6950 do like 320mhash/s. And if you want to mine, well, do it in a mining pool, with the current difficulty if you have few graphic cards it take months or even a year to find a block, by mining in a pool when a block is found the reward is divided by all the partecipants (of course by how many shares everyone submitted)

To solo mine and have a decent chance at finding blocks in a decent time you need a lot of hashing power...

[b99999]

Thanks a lot everyone, you really helped with the answers!