Quote from: subSTRATA on November 02, 2012, 01:53:42 PM

Quote from: kjj on November 02, 2012, 01:44:16 PM

Quote from: subSTRATA on November 02, 2012, 01:03:51 PM

I'm pointing to ridicule situation - there are thousands of unconfirmed transaction but block will be accepted, which means
blockchain size will be increased by 1, even though mentioned block has no transactions other than 50BTCs payout. Since
that is possible, it's possible for determined attacker to "freeze" all non-BTC-generating transactions (almost) indefinitely.

Not really. There are actually several ways to counter this if we ever need to... we can make it costly to be antisocial if we really need to.

How much worse the situation must become for that to happen? If there are already ways to fight it, why wait with implementation?

Because we don't want to make rules like that. The reference client makes up the bulk of the network, so any rules in there carry a lot of weight. Until the network is more diversified, the devs are cautious about such things.

Miners should be allowed to include or exclude transactions according to whatever rules they want. And nodes should be allowed to dislike certain blocks, to some extent. By putting rules in the reference client, the devs would be forcing their rules on everyone, and they don't want to, and simply won't do it unless things get pretty ugly.

Blocks with no transactions are still doing part of their job, just not all of it. And they are still valid.

The idea that I proposed, in case you are interested, is to keep a timestamp on transactions in the memory pool, and to check them when a new block comes in. If the new block doesn't include some fraction (10%? 25%? ) of the transactions that you knew about at some time prior to the block coming in (1 minute before? 5? 10? ), just quarantine the block until another block comes in, assuming that there was a sufficient number of known transactions (50? 100? ). The new block will either be a better replacement for the antisocial block, or a block that builds on top of it.

This way, miners would have an incentive to include transactions, because more transactions means that a larger fraction of the network will relay your blocks, spreading it quicker, reducing your chances of getting orphaned.

Note that this proposal is actually fairly complicated, and no one would want to have to actually write it, nor maintain it. It has the advantage of not centralizing control, but that's about all it has going for it. Other solutions are possible, with varying combinations of complexity and ease of implementation, and the devs don't want to do any of them unless they actually have to.