Again, a block with 0 transactions is accepted

[Remember remember the 5th of November]

These blocks are becoming too often...

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

The owner of address 1Baf75Ferj6A7AoN565gCQj9kGWbDMHfN9 and the person who generated that block is is the pool Eclipse.

[1714760829]

1714760829

[1714760829]

1714760829

[1714760829]

1714760829

[mmeijeri]

There's nothing wrong with blocks that only contain a coinbase transaction, they still add proof of work to secure the block chain.

[grue]

These blocks are becoming too often...

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

so 1 data point is enough for you to conclude it's "too often?"

[Remember remember the 5th of November]

There's nothing wrong with blocks that only contain a coinbase transaction, they still add proof of work to secure the block chain.

I think OP means that transactions don't get confirmed this way.

[Blueberry408]

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.

No hang on, bitcoin includes the ability to pass signed cryptograms for trust certification purposes. I don't think you're going to find that functionality separable from transaction processing... no?

[mmeijeri]

I think OP means that transactions don't get confirmed this way.

Sure, if zero transaction blocks are all we have.

[Remember remember the 5th of November]

I think OP means that transactions don't get confirmed this way.

Sure, if zero transaction blocks are all we have.

True, but if a block is found on avg every 10 minutes, and one is found but has only a coinbase transaction, then a user must wait an additional 10 minutes for his TX to confirm.

[mmeijeri]

OK, that's true.

[niko]

There's nothing wrong with blocks that only contain a coinbase transaction, they still add proof of work to secure the block chain.

I think OP means that transactions don't get confirmed this way.

Transactions from previous blocks do get confirmed this way. mmeijeri is correct.

[Remember remember the 5th of November]

There's nothing wrong with blocks that only contain a coinbase transaction, they still add proof of work to secure the block chain.

I think OP means that transactions don't get confirmed this way.

Transactions from previous blocks do get confirmed this way. mmeijeri is correct.

Yes, but new ones won't.

[Deafboy]

I'm becoming too old. I remember this exact discussion and proposed solutions when so called mystery miner gained significant percentage of the hash power and did not included any transactions besides the coinbase. The exact same discussion.

https://bitcointalk.org/index.php?topic=67634.20
There were more topics. Not sure if this is THE one.

[Shevek]

There's nothing wrong with blocks that only contain a coinbase transaction, they still add proof of work to secure the block chain.

Blocks with transactions ALSO secures the blockchain AND additionally provides the service bitcoin is destined to.

[niko]

There's nothing wrong with blocks that only contain a coinbase transaction, they still add proof of work to secure the block chain.

Blocks with transactions ALSO secures the blockchain AND additionally provides the service bitcoin is destined to.

OK, fair enough. My comment above was simply meant to point out that zero-tx blocks, while not optimal, still provide some service to the network. I don't think this is something worth worrying about. Let each user and miner (including the presumed botnet operator) decide what they want to do. As a user, I am comfortable with any of the likely outcomes.  Not a big deal, really.

[DannyHamilton]

I think OP means that transactions don't get confirmed this way.

Sure, if zero transaction blocks are all we have.

True, but if a block is found on avg every 10 minutes, and one is found but has only a coinbase transaction, then a user must wait an additional 10 minutes for his TX to confirm.

OK, that's true.

No it is not.  Block solutions are random.  The fact that someone just found a block has no bearing on how long it will take to find the next block.

The dice don't remember what the previous roll was. (And neither do the hashing functions).

[Remember remember the 5th of November]

I think OP means that transactions don't get confirmed this way.

Sure, if zero transaction blocks are all we have.

True, but if a block is found on avg every 10 minutes, and one is found but has only a coinbase transaction, then a user must wait an additional 10 minutes for his TX to confirm.

OK, that's true.

No it is not.  Block solutions are random.  The fact that someone just found a block has no bearing on how long it will take to find the next block.

The dice don't remember what the previous roll was. (And neither do the hashing functions).

Funny, if a Bitcoin developer worded the sentence in the same way you wouldn't have said that. This is why I secured my post by saying on average. It all depends on variance.

But the code in Bitcoin has been made so that blocks are found on average every 10 minutes.

[mmeijeri]

No it is not.  Block solutions are random.  The fact that someone just found a block has no bearing on how long it will take to find the next block.

The dice don't remember what the previous roll was. (And neither do the hashing functions).

I meant that it would take one confirmation longer, which on average is ten minutes. The calculations have to restart when a new block is found.

[DannyHamilton]

Funny, if a Bitcoin developer worded the sentence in the same way you wouldn't have said that.

I'm not sure what you mean by that?

This is why I secured my post by saying on average. It all depends on variance.

But the code in Bitcoin has been made so that blocks are found on average every 10 minutes.

Yes, in the same way that you'll roll a 1 on a six sided die every 6 rolls on average.  But the point is, if you roll your own die and get a 1, it has no bearing on whether or not my next roll will be a 1.  The fact that you "solved" a block before me, does not delay my ability to solve a block (ok, perhaps I'm delayed by a fraction of a second while I build a new block header, but it isn't enough of a delay to really matter as far as this discussion goes).

[Remember remember the 5th of November]

Funny, if a Bitcoin developer worded the sentence in the same way you wouldn't have said that.

I'm not sure what you mean by that?

This is why I secured my post by saying on average. It all depends on variance.

But the code in Bitcoin has been made so that blocks are found on average every 10 minutes.

Yes, in the same way that you'll roll a 1 on a six sided die every 6 rolls on average.  But the point is, if you roll your own die and get a 1, it has no bearing on whether or not my next roll will be a 1.  The fact that you "solved" a block before me, does not delay my ability to solve a block (ok, perhaps I'm delayed by a fraction of a second while I build a new block header, but it isn't enough of a delay to really matter as far as this discussion goes).

I have not said anything about delays. Mining is random, yes.

[DannyHamilton]

I meant that it would take one confirmation longer, which on average is ten minutes. The calculations have to restart when a new block is found.

The calculations restart every time a miner calculates a hash that doesn't solve a block.  That means that the calculations are already restarting more than 100,000,000,000,000 times every second.

Think about the dice, and (assuming that you understand that when you roll a 1 on a die it has no bearing on how many more rolls until I roll a 1 on my die) you'll realize that the empty block is not delaying anyone else's blocks significantly.

[DannyHamilton]

- snip -
I have not said anything about delays.
- snip -

- snip -
then a user must wait an additional 10 minutes for his TX to confirm.

How is "an additional 10 minutes" not considered a "delay"?