I've been thinking of a potential attack on the number of transactions that get processed.

Since a miner basically have an option of including transactions up to a maximum number (limited by the maximum block size at the moment, which is 1 MB (static const unsigned int MAX_BLOCK_SIZE = 1000000;), what is preventing a bad miner from not including any transactions?

For example, if an organization which wants to interrupt Bitcoin's operations comes into the game, they could have huge processing power and just keep on generating new blocks without any transactions? Yes, they are not getting the fee, but no transactions are getting processed either.

Is this possible or I'm missing something?

Hmm, I'm not sure I understand it completely yet ... Thanks for posting that link, it made some things more clear.

The one thing I don't understand is how the OP_EQUALVERIFY operation passes. This operation just verifies if the last two items on the stack are the same.

Now, the question is - who calls all this? The receiving side? Miners?

When I create a new transaction, I will put in TxIn:

scriptSig:
 - Sig of the whole transaction with my privatekey
 - My pubkey (I don't know anyone else's anyway)

TxOut:
scriptPubKey:
OP_DUP OP_HASH160 <receiver's address> OP_EQUALVERIFY OP_CHECKSIG


Now, who does the verification? From the graph you sent I understand how OP_CHECKSIG works.

What I don't understand is how OP_EQUALVERIFY passes because in the original transaction there is my pubkey and receiver's address.
So OP_DUP and OP_HASH160 will perform this on *my* pubkey so the result will not be the receiver's address??

I hope I'm clear trying to explain what I don't understand, it's the verification process and OP_EQUALVERIFY.

Thanks!

[Edit]
After checking the transaction jackjack posted http://blockexplorer.com/tx/4f6f864d3047bf441317fc0f5d1586325c9e740e923c7949cc28333ff74d19df#o1, it is clear that in the scriptSig is the Sig of the whole transaction and pubkey of the sender (TxIn). Now I don't get how it passes OP_EQUALVERIFY because it has the sender's pubkey in scriptSig and recipients address in scriptPubKey -- this makes sense that it is that way, but I don't see how it passes OP_EQUALVERIFY

Hmm, but how does the OP_EQUALVERIFY work then?

According to https://en.bitcoin.it/wiki/Transactions and what you wrote above on the stack the following gets pushed:

sig mypubkey

Then OP_DUP duplicates mypubkey:

sig mypubkey mypubkey

Then OP_HASH160 does this on mypubkey:

sig mypubkey hash160(mypubkey)

Then hash160(yourpubkey) gets pushed onto stack:

sig mypubkey hash160(mypubkey) hash160(yourpubkey)

And now OP_EQUALVERIFY checks if the last two hashes are the same. They won't be (unless I'm missing something)?
This means that in the TxIn I have to put your pubkey and not mine?

Cheers for answers so far!

Hi, I have a question about a transaction's content.

From https://en.bitcoin.it/wiki/Transactions a transaction will have two important parts:

TxIn: scriptSig
TxOut: scriptPubKey

Now, scriptSig contains a signature and a public key. My first question: this is the recepient's public key, right?

The scriptPubKey has this: OP_DUP OP_HASH160 404371705fa9bd789a2fcd52d2c580b65d35549d
OP_EQUALVERIFY OP_CHECKSIG

Second question: the hash there (4043...) is recepient's address, which is simply SHA256^2(recipient's pub key). Is that correct?

What I don't get is how the signature is checked? How does the client retrieve the sender's public key? Does it has to go and find the previous transaction (from TxIn) to retrieve the sender's public key in order to verify the signature?

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

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?

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?

Thanks, that confirms what I was thinking about.


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

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.