"4000 tps is easily achievable" - of course... wiki always knows the truth
And then one can only wonder why a 250KB block needs over one second to get verified by my i5 CPU, occupying 100% of it, while doing it..

I think you are not aware of what kind of world we are living in.
If only rich and powerful can run a bitcoin node - then it will become very easy for a government to shut it down. Especially after you disable support for Tor.

Really?  Then where live must be far behind the rest of the world, since the internet speed does not seem to have improved here over the last couple of years. Thus no reason to assume that it will improve much in the next couple of years...

As for the CPU usage, I think 7 tx/sec seems to be a tolerable maximum, since it adds up to about 15 elliptic curve verify ops, per second.
If you have a CPU with 2 cores, and about 2 GHz clock - it can stand it in a background.
But if you make it 150 EC ops/s, leaving the came CPU, you are just killing all these poor people's home PCs - and that's not even counting the bandwidth, nor the memory requirements.

So yeah, if you want to make a bitcoin node available only for the rich - then increasing the block size is probably the best way to go
But if your goal is to just handle more transactions per second, you should rather try to push the inevitable centralization into more democratic directions - ones that don't give advantages to the rich. Meaning: many centralized payment processors who settle their balances with each other through the bitcoin blockchain - this seems to be a natural and democratic way to go forward, IMHO.

Thanks - first time I'm seeing this video, its nice.

You cannot argue with one thing from it; by increasing the blocks size, just to keep up with the growing number of txs, you will eventually end up with a system where a bitcoin node can by run only by rich people and only in data centers.
Set the limit to 10+MB and its almost certain that 5 years from now nobody will be able to run a bitcoin node at his home PC, through a DLS connection, not to mention via Tor.

I couldn't agree more.

You could think of P2P client systems, to the bitcoin network that would take care of small transactions and even make them faster, also using some sort of blockchains, though sort of compressing them in the actual chain, for a fee.
Hell, if you think about it, you can even involve mining there, as long as it gets cheaper than the bitcoin chain fees.
Just leave the 1MB block limit and you will see it bloomig (good for everyone), while the actual bitcoin network will be able to breath out.

Besides, IMO it's also too dangerous to change anything in this protocol.

So at it has been show here, if we just make the block size unlimited, and let the miners decide, it will only encourage the mining arm race - the only thing that the chain may be afraid of.
At the very moment when a set of nodes decide that they wont accept block with a valid difficulty, just because it is too big for "their standards" - that's the moment of the disaster.
So we won't just stick to the traditional 1MB? That's the best way, IMHO.

I just mentioned that I read it all the time: "bitcoin is not for microtransactions" - and I agree with it.
But it was not my entry point - rather a by the way argument.

My point was: if it doesn't scale further, just get advantage of it's fine design that has a built in mechanisms to solve it.
Though, at the other hand, I understand the politics and the need to balance between the resource consumption vs. making the system available for anyone, in order for it to become successful.
So yeah, why not 10MB

Thanks @DeathAndTaxes
You have some good point here, that I had not considered.
Still, I don't quite understand the argument why 10MB is "better" than 1MB.
Better for who? And can to prove it?

Someone asked me whether $7.50 is a micro-transaction..
Well: if it's lower than the remaining 2000+ txs that went into a block - then yes.
Obviously whether something was a micro or not, is a relative term.
If you are aiming into Bitcoin becoming the new global currency, then even $1000 would be a micro-transaction.

Anyone here seem to agree that sooner or later we will get to that point when we will have to say 'enough is enough'.

So why not to just keep this point at the 1MB, as Satoshi originally designed?

If you don't increase MAX_BLOCK_SIZE people will naturally start using BTC payment processors, which will take the load off the net, and which has to eventually happen anyway.

I watched Gavin's presentation from the San Jose conference and I learned that it is actually being planed to increase the MAX_BLOCK_SIZE withing new next 10 or 20 months.

Please don't do it.

As I have read it many times before, and I completely agree with it: Bitcoin is not designed for micro-transactions.

The network does not scale, we have a worldwide economic crisis and the Moore's law does not seem to be any longer applicable; our internet connections got stuck at what a DLS's copper can do, and the CPU's also don't seem to be getting the speed as much, as they were 10 years ago.

As an average bitcoin user, but also a developer who understand all the pros and cons behind increasing MAX_BLOCK_SIZE, I beg you: don't do it! Instead, do the other thing that Gavin mentioned in his presentation; implement a proper fee discovery mechanism into the client, so anyone would be able to decide how much fee he needs to pay to have his tx mined withing the next N hours...

Please let the fee market to work. The fees behind the transaction is a great feature invented by Satoshi - don't break it, but get advantage of it instead. They will take the load off the net and the net needs it.

Oh, I just figured out what I was doing wrong handling these "getblocks" requests with 29 different locator hashes up to the genesis block.

Originally I had thought that the only limit, for building the "inv" reply, should be either reaching the hash_stop or the max 500 records.
But now I figured that I should have ignored the remaining locators after matching on a first one from the list - which almost always points to the end of my tree, so in most cases the reply should be just empty, and not 500 hashes long.
At least that's how satoshi does it..
So after fixing this in my code, the upload bandwidth usage looks indeed much better - and the whole idea of 29 locator hashes makes much more sense, as well.

Anyway, sorry - my bad.
Mike's node might be indeed in a data center

yeah, your pkscript looks ok - it's probably how you hash it.

If you manage to build it yourself and put debugs where you need them - then yes

After you get there you may find "-par=1" command line switch useful - otherwise it executes several scripts at a time and then its easy to get lost.

I think if you had it really working, you'd be showing us also the stack states from when you are executing the pkscript.
You made quite a big shortcut, so its kind of hard to say if you have everything order on the way.
Assuming 'yes' and if you'd want to take it from this point, I'd start from comparing your txSignatureHash with what bitcoind would print in this place - it's most likely a different one.

after the signature script, you need to execute pkscript, of each input that the transaction is spending.
it's where the fun starts, so good luck

Now were talking - numbers, I like.

Now imagine that the blocks will be growing in size... not unlikely reaching the max of 1MB around the end of this year...
This great router, that you are advertising, will not stand a chance with the average 10 min new block mining events, especially if 10 of them appear within 20min period. It will be so laggy, that you will just prefer to not use it, because it will never have the most recent info. Or even if it does, you wont be sure...

So my point was that it just won't work. For this kind of hardware better look into solutions that are not actual nodes, but only download transactions that belong to their wallet. This could work.

I'm telling you.

I'm not too familiar with the source code, but I know that to verify signatures of the last 288 blocks, using a modern PC, you would need at least a couple of minutes.
And since the bitcoin needs less than one minute to boot on my PC, the only explanation is that it does not redo the signatures verification.

Just put a debug in CKey::Verify and see it gets printed at startup.

You're welcome to try me at your party

AFAIK, it does not verify the last 288 blocks, per se.
It does re-apply transactions from the last blocks at each boot, but without an actual verification their of signatures.
Or am I wrong?

Single 600MHz core, with 256 MB of RAM - right?

That's why I seriously doubt it.
I think you underestimate the power that is needed for a single ECDSA verify calculation, not to mention memory needed to take a real-time care of a database with almost 6 millions of unspent outputs.

If you don't believe me, just start it with an empty DB and see by when it catches up. I'm telling you: probably never
Though the first 100+k blocks should go wonderfully - no doubts about it