Again, a block with 0 transactions is accepted

[Shevek]

https://blockchain.info/block-height/238212

6 minutes after the previous.

In this thread is discussed similar event IMHO, pools, miners and nodes in general should reject such blocks. Bitcoin is a transaction system. If there is no transaction, the game is over.

[Remember remember the 5th of November]

While this miner is not adding transactions in his block, there will be times where there will be no TXes to add in a block and I am talking about edge-cases where a block is found seconds after another. Will you also reject those?

[Shevek]

While this miner is not adding transactions in his block, there will be times where there will be no TXes to add in a block and I am talking about edge-cases where a block is found seconds after another. Will you also reject those?

Yes.

I repeat: bitcoin is about transactions; so, no transaction should mean automatic rejection.

Perhaps this must be hardcoded in incoming releases of the client.

[jackjack]

Actually that won't change anything, the miner can create tons of dummy transactions

[Shevek]

Actually that won't change anything, the miner can create tons of dummy transactions

It's necessary, but perhaps not enough.

[bg002h]

Is the zero transaction block not an expression of market forces? I mean, if I want to charge high fees, I can artificially limit transactions by mining lots of blank blocks.

[Shevek]

Is the zero transaction block not an expression of market forces? I mean, if I want to charge high fees, I can artificially limit transactions by mining lots of blank blocks.

Even if not hardcoded, the rest of the network should reject such blocks. They are working hard with own and other's transactions. Nobody forces me to accept a block that is not including the transactions I want. So, block rejected and wait for a fair one.

This should be a real market, I think.

[DannyHamilton]

There is no such thing as a 0 transaction block.  Every block has at least 1 transaction in it.

Requiring additional transactions in a block is a useless requirement that won't accomplish anything.

So you will accept a block with only 2 transactions?  Fine, miner creates a second transaction paying bitcoins from one address in his own wallet to another address in his own wallet.  Problem solved?

You might not like blocks that don't have many transactions, but they are entirely valid and will occur occasionally.  Accept it and move on. It isn't going to change.

It has no effect on the ability of the rest of the network to solve blocks with transactions in them.

[bg002h]

Limits on the block size, IMHO, should be determined by the market with some temporary fail-safe stuff hard-wired into the code and updated as needed (like our current block chain protecting max block size).

If a miner wants no other transactions in a block (and forego the associated transaction fees), so be it. When the block limit has a reason to be set above 1 MB, it'll be up to miners to use that extra space in the block as they see fit.

[Shevek]

There is no such thing as a 0 transaction block.  Every block has at least 1 transaction in it.

Awesome observation  Please, make a gift of two or three more like this for my birthday 

Requiring additional transactions in a block is a useless requirement that won't accomplish anything.

So you will accept a block with only 2 transactions?  Fine, miner creates a second transaction paying bitcoins from one address in his own wallet to another address in his own wallet.  Problem solved?

See: https://bitcointalk.org/index.php?topic=212146.msg2277187#msg2277187

That is an example of fair policy I'd take if I rule a pool.

[Come-from-Beyond]

I repeat: bitcoin is about transactions; so, no transaction should mean automatic rejection.

That's not 100% true. Bitcoin is about securing the blockchain also. Even an empty block confirms previous transactions.

[cp1]

Does this just mean the transaction fees aren't high enough?  Shouldn't the fees be such that it's worth the overhead to include them in a block?

[grue]

Does this just mean the transaction fees aren't high enough?  Shouldn't the fees be such that it's worth the overhead to include them in a block?

the more likely explanation is that the block is mined by a botnet owner. if you don't include any transactions, you wouldn't need to verify them. if you don't need to verify them, you don't need to store the entire blockchain, which decreases detection.

[cp1]

the more likely explanation is that the block is mined by a botnet owner. if you don't include any transactions, you wouldn't need to verify them. if you don't need to verify them, you don't need to store the entire blockchain, which decreases detection.

Ah I've always wondered about those bitcoin botnets and how many computers they have working for them.  (And what percentage of compromised computers actually have a decent hash rate)

[DannyHamilton]

See: https://bitcointalk.org/index.php?topic=212146.msg2277187#msg2277187

That is an example of fair policy I'd take if I rule a pool.

Then you wouldn't have any miners participating in your pool, because they wouldn't ever get paid.

If you reject a single block, then you will be forced to reject any other blocks that are found by the rest of the network that build on top of that rejected block as well.

Then, any block your pool attempts to submit would be rejected by the rest of the network, because your blockchain would be "shorter" than the generally recognized one (since it would be missing all the blocks that they've already accepted.

The only way you could succeed would be to convince more than 50% of the total network hash power to agree with whatever rules you decide to implement.

[Shevek]

Does this just mean the transaction fees aren't high enough?  Shouldn't the fees be such that it's worth the overhead to include them in a block?

the more likely explanation is that the block is mined by a botnet owner. if you don't include any transactions, you wouldn't need to verify them. if you don't need to verify them, you don't need to store the entire blockchain, which decreases detection.

This makes sense... a good reason to hardcode rejection of 0-transaction blocks.

[DannyHamilton]

Does this just mean the transaction fees aren't high enough?  Shouldn't the fees be such that it's worth the overhead to include them in a block?

the more likely explanation is that the block is mined by a botnet owner. if you don't include any transactions, you wouldn't need to verify them. if you don't need to verify them, you don't need to store the entire blockchain, which decreases detection.

This makes sense... a good reason to hardcode rejection of 0-transaction blocks.

And again, it would be a useless effort.  The Botnet would then just create transactions sending back and forth between two addresses that the botnet owns.  It wouldn't need the blockchain to verify the transactions, since it would create them itself.

[Shevek]

Does this just mean the transaction fees aren't high enough?  Shouldn't the fees be such that it's worth the overhead to include them in a block?

the more likely explanation is that the block is mined by a botnet owner. if you don't include any transactions, you wouldn't need to verify them. if you don't need to verify them, you don't need to store the entire blockchain, which decreases detection.

This makes sense... a good reason to hardcode rejection of 0-transaction blocks.

And again, it would be a useless effort. 

"Effort" is too strong. It's an easy countermeasure that costs nothing. Easy points should be scored.

The Botnet would then just create transactions sending back and forth between two addresses that the botnet owns.  It wouldn't need the blockchain to verify the transactions, since it would create them itself.

Without the automatic rejection, you make the life of botnet owner easier.

[Shevek]

See: https://bitcointalk.org/index.php?topic=212146.msg2277187#msg2277187

That is an example of fair policy I'd take if I rule a pool.

Then you wouldn't have any miners participating in your pool, because they wouldn't ever get paid.

If you reject a single block, then you will be forced to reject any other blocks that are found by the rest of the network that build on top of that rejected block as well.

Not necessarily. If other miner finds a block, with the unfair block as antecedent, I would continue the chain. Of course.

But if I'm lucky and my pool finds a concurrent block, then I force the network to make a decision on my block or the unfair one.

The only way you could succeed would be to convince more than 50% of the total network hash power to agree with whatever rules you decide to implement.

If only the 3 biggest pools make an agreement on this matter, the problem is solved.

[Shevek]

These blocks are becoming too often...

https://blockchain.info/block-index/387154/00000000000000cf950f6997b14b4dc361ec59742d379e4439fc85fad6c9e10d