Again, a block with 0 transactions is accepted

[Remember remember the 5th of November]

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.

Re-read my posts. I said that blocks which have only a coinbase transaction delay the confirmation of new transactions. I've never said or implied that such blocks delay the finding of new blocks.

[1714787559]

1714787559

[1714787559]

1714787559

[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.

Re-read my posts. I said that blocks which have only a coinbase transaction delay the confirmation of new transactions.

I know what you said.  I'm telling you that they don't.  You don't believe me, and I'm not sure how to help you understand this.

[mmeijeri]

That's a good point, but it does affect the average rate of non-empty blocks per unit of time, doesn't it? And that does delay transactions a bit.

[Remember remember the 5th of November]

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.

Re-read my posts. I said that blocks which have only a coinbase transaction delay the confirmation of new transactions.

I know what you said.  I'm telling you that they don't.  You don't believe me, and I'm not sure how to help you understand this.

No you don't understand. A transaction's FIRST confirmation is achieved when a miner includes the transaction in his block.

[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.

Re-read my posts. I said that blocks which have only a coinbase transaction delay the confirmation of new transactions.

I know what you said.  I'm telling you that they don't.  You don't believe me, and I'm not sure how to help you understand this.

No you don't understand. A transaction's FIRST confirmation is achieved when a miner includes the transaction in his block.

I know this. But the fact that someone chooses to solve blocks that have only a coinbase transaction does not significantly affect the amount of time before that FIRST confirmation is achieved.  If the miner/pool that is solving blocks that only have a coinbase transction is contribution a significant amount of hash power to the network, then they may delay transactions that are created after the next difficulty adjustment, but at the current difficulty, they are not delaying anyone's FIRST confirmation by solving empty blocks (as compared to simply not participating in mining).

[niko]

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).

A hypothetical extreme case, unlikely to arrive at without people taking corrective actions: let's assume that zero-tx miner starts obtaining more and more hashing power, to the point of holding 99% of the network. I broadcast a transaction, the chances of it getting included in the next block are only 1%. Ergo, I will have to wait longer on average for my tx to get included. Is this correct, or am I falling for some form of gambler's fallacy.

[DannyHamilton]

That's a good point, but it does affect the average rate of non-empty blocks per unit of time, doesn't it? And that does delay transactions a bit.

If they are contributing a significant amount of hash power, then they will increase the difficulty at the next difficulty adjustment.  This could delay those future transactions after the difficulty adjsutment, but at the current difficulty, they are not significantly delaying anything (no more than a fraction of a second).

[Remember remember the 5th of November]

That's a good point, but it does affect the average rate of non-empty blocks per unit of time, doesn't it? And that does delay transactions a bit.

(no more than a fraction of a second).

Transactions always get relayed to nodes regardless of whether blocks get solved or not.

https://en.bitcoin.it/wiki/Block#What_is_the_maximum_number_of_blocks.3F

blocks just keep getting added to the end of the chain at an average rate of one every 10 minutes.

While variance plays a huge role here, if we accept that a miner mines a block with only a coinbase tx, a user would need wait up to 10 more minutes, of course this means the miner of the next block needs to add include the said TX.

[mmeijeri]

If they are contributing a significant amount of hash power, then they will increase the difficulty at the next difficulty adjustment.  This could delay those future transactions after the difficulty adjsutment, but at the current difficulty, they are not significantly delaying anything (no more than a fraction of a second).

I'm not talking about additional hashing power. Assume hashing power remains constant over time. On average a block is found every ten minutes. Some percentage of these block is empty. If it is 50%, we get a non-empty block every twenty minutes. If it is 0%, then we get a non-empty block every ten minutes. Empty blocks still add confirmations for transactions that are already in the block chain, but they add no first confirmations. Doesn't it follow that first confirmations are delayed even though block creation isn't?

[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).

A hypothetical extreme case, unlikely to arrive at without people taking corrective actions: let's assume that zero-tx miner starts obtaining more and more hashing power, to the point of holding 99% of the network. I broadcast a transaction, the chances of it getting included in the next block are only 1%. Ergo, I will have to wait longer on average for my tx to get included. Is this correct, or am I falling for some form of gambler's fallacy.

If the miner were to gain that 99% of the network hashing power all at once before the next difficulty adjustment, then you would see blocks being solved every 6 seconds.  1 out of every 100 of those blocks "on average" (in other words every 10 minutes "on average") would be a block from some other miner that actually includes transactions.  The blockchain would grow fast, and once people got their first confirmation (in approximately 10 minutes on average), they would get the rest of their confirmations very quickly.

Now eventually, a difficulty adjustment would occur.  At that time, blocks would slow down and confirmations would start coming slower.  If the "0 transaction miner" then stopped mining completely, you wouldn't see confirmations every 10 minutes on average, you'd still see them every 16.67 hours on average.  This would continue until the next difficulty adjustment.

So, the "0 confirmation miner" can delay transactions that will occur later (after the next difficulty adjustment), but they have no effect on the time for your first confirmation at the current difficulty.

[DannyHamilton]

While variance plays a huge role here, if we accept that a miner mines a block with only a coinbase tx, a user would need wait up to 10 more minutes, of course this means the miner of the next block needs to add include the said TX.

I keep telling you that this isn't true.  I'm not sure how else to explain it.  What a "0 transaction miner" does do is affect the future difficulty adjustment.  This can delay the FIRST confirmation for future transactions after the next difficulty adjustment, by increasing the difficulty.  It does not increase the amount of time for a FIRST confirmation at the current difficulty as compared to that "0 transaction miner" choosing not to participate in mining.

[Remember remember the 5th of November]

While variance plays a huge role here, if we accept that a miner mines a block with only a coinbase tx, a user would need wait up to 10 more minutes, of course this means the miner of the next block needs to add include the said TX.

I keep telling you that this isn't true.  I'm not sure how else to explain it.  What a "0 transaction miner" does do is affect the future difficulty adjustment.  This can delay the FIRST confirmation for future transactions after the next difficulty adjustment, by increasing the difficulty.  It does not increase the amount of time for a FIRST confirmation at the current difficulty as compared to that "0 transaction miner" choosing not to participate in mining.

And I keep telling you that you are wrong. A miner that mines only the coinbase tx still moves the blocks and doesn't delay the difficulty adjustment at all. Difficulty is adjusted every 2016 blocks.

[mmeijeri]

What a "0 transaction miner" does do is affect the future difficulty adjustment.

How so? The difficulty adjustment depends on the time it took to produce the latest 2016 blocks, not the latest 2016 non-empty blocks, doesn't it? If total hashing power stays constant, a decision to switch from including transactions to producing empty blocks shouldn't have any influence on difficulty, should it?

[DannyHamilton]

If they are contributing a significant amount of hash power, then they will increase the difficulty at the next difficulty adjustment.  This could delay those future transactions after the difficulty adjsutment, but at the current difficulty, they are not significantly delaying anything (no more than a fraction of a second).

I'm not talking about additional hashing power. Assume hashing power remains constant over time. On average a block is found every ten minutes. Some percentage of these block is empty. If it is 50%, we get a non-empty block every twenty minutes. If it is 0%, then we get a non-empty block every ten minutes. Empty blocks still add confirmations for transactions that are already in the block chain, but they add no first confirmations. Doesn't it follow that first confirmations are delayed even though block creation isn't?

It depends on how much hashing power they are providing and how long they've been providing that much hashing power.

Using your 50% empty blocks.  If 1,008 of the blocks broadcast prior to the last difficulty adjustment were from the miner who is solving "empty" blocks, then the difficulty would adjust such that the rest of the network would only solve a block on average every 20 minutes for the next 2,016 blocks.  This 20 minutes for a FIRST confirmation would exist even if the miner who was solving "empty" blocks stopped mining immediately after the adjustment.  The 20 minutes for a FIRST confirmation would exist even if the miner who was solving "empty" blocks suddenly doubled his hash power immediately after the adjustment (and there for started broadcasting 66% of the solved blocks).

[Remember remember the 5th of November]

If they are contributing a significant amount of hash power, then they will increase the difficulty at the next difficulty adjustment.  This could delay those future transactions after the difficulty adjsutment, but at the current difficulty, they are not significantly delaying anything (no more than a fraction of a second).

I'm not talking about additional hashing power. Assume hashing power remains constant over time. On average a block is found every ten minutes. Some percentage of these block is empty. If it is 50%, we get a non-empty block every twenty minutes. If it is 0%, then we get a non-empty block every ten minutes. Empty blocks still add confirmations for transactions that are already in the block chain, but they add no first confirmations. Doesn't it follow that first confirmations are delayed even though block creation isn't?

It depends on how much hashing power they are providing and how long they've been providing that much hashing power.

Using your 50% empty blocks.  If 1,008 of the blocks broadcast prior to the last difficulty adjustment were from the miner who is solving "empty" blocks, then the difficulty would adjust such that the rest of the network would only solve a block on average every 20 minutes for the next 2,016 blocks.  This 20 minutes for a FIRST confirmation would exist even if the miner who was solving "empty" blocks stopped mining immediately after the adjustment.  The 20 minutes for a FIRST confirmation would exist even if the miner who was solving "empty" blocks suddenly doubled his hash power immediately after the adjustment (and there for started broadcasting 66% of the solved blocks).

You really need to re-read the Bitcoin protocol. Anyway, what you are describing is an attack whereby a miner with a lot of hashing power suddenly stops mining before the next difficulty adjustment, at which point when the new difficulty comes(which will be higher depending on the hashing power) then yes, it will be sort of as you say, but we aren't talking about that.

[DannyHamilton]

What a "0 transaction miner" does do is affect the future difficulty adjustment.

How so? The difficulty adjustment depends on the time it took to produce the latest 2016 blocks, not the latest 2016 non-empty blocks, doesn't it? If total hashing power stays constant, a decision to switch from including transactions to producing empty blocks shouldn't have any influence on difficulty, should it?

I think maybe the issue some of are having in agreeing on the effect is that some of you are comparing a miner who solves an "empty" block to that same miner solving a block with transactions in it, whereas I'm comparing a miner (or botnet) solving an "empty" block to that same miner (or botnet) not participating in mining at all due to restrictions designed to prevent "empty" blocks.

If we aren't comparing the same thing, then obviously we aren't going to com to the same conclusion.

The other thing to keep in mind, is that if that miner (who solved an "empty" block) had been working on a block that had transactions, then the nonce he found (by working on the "empty" block) wouldn't have been a valid nonce for the block with transactions.  Therefore, you can't really compare that miner working on a "full" block vs. that same miner working on an "empty" block, since the more realistic comparison would be that miner solving that "empty" block vs. some other miner solving a "full" block later.

The only adverse affect that a miner working on empty blocks has on the network, is to increase the mining difficulty at the next adjustment (or keep in increased to the same level that he did during a previous difficulty adjustment).

[DannyHamilton]

You really need to re-read the Bitcoin protocol.

As do you, along with some studies in probability and randomness.  Assuming that we are both talking about the same thing here, I'm pretty confident in what I'm saying.  I suspect that our disagreement stems from each of us discussing a different scenario without realizing it.  Otherwise, you may need to re-think what you are trying to say.

[Remember remember the 5th of November]

You really need to re-read the Bitcoin protocol.

The other thing to keep in mind, is that if that miner (who solved an "empty" block) had been working on a block that had transactions, then the nonce he found (by working on the "empty" block) wouldn't have been a valid nonce for the block with transactions.  Therefore, you can't really compare that miner working on a "full" block vs. that same miner working on an "empty" block, since the more realistic comparison would be that miner solving that "empty" block vs. some other miner solving a "full" block later.

As do you, along with some studies in probability and randomness.  Assuming that we are both talking about the same thing here, I'm pretty confident in what I'm saying.  I suspect that our disagreement stems from each of us discussing a different scenario without realizing it.  Otherwise, you need to re-think what you are trying to say.

Obviously a block with transactions and a block without transactions will have different merkle roots. The merkle root changes very often.

[mmeijeri]

I think maybe the issue some of are having in agreeing on the effect is that some of you are comparing a miner who solves an "empty" block to that same miner solving a block with transactions in it, whereas I'm comparing a miner (or botnet) solving an "empty" block to that same miner (or botnet) not participating in mining at all due to restrictions designed to prevent "empty" blocks.

If we aren't comparing the same thing, then obviously we aren't going to com to the same conclusion.

Yeah, it looks that way.

The other thing to keep in mind, is that if that miner (who solved an "empty" block) had been working on a block that had transactions, then the nonce he found (by working on the "empty" block) wouldn't have been a valid nonce for the block with transactions.  Therefore, you can't really compare that miner working on a "full" block vs. that same miner working on an "empty" block, since the more realistic comparison would be that miner solving that "empty" block vs. some other miner solving a "full" block later.

Sure, the nonce would be different, but why does that matter? Empty blocks aren't easier to solve than non-empty ones.

The only adverse affect that a miner working on empty blocks has on the network, is to increase the mining difficulty at the next adjustment (or keep in increased to the same level that he did during a previous difficulty adjustment).

If new rules force the miner to include transactions rather than forcing him to leave the network, then they have zero effect on difficulty, while they do have an effect on first confirmations. Do you disagree with that?

[DannyHamilton]

The only adverse affect that a miner working on empty blocks has on the network, is to increase the mining difficulty at the next adjustment (or keep in increased to the same level that he did during a previous difficulty adjustment).

If new rules force the miner to include transactions rather than forcing him to leave the network, then they have zero effect on difficulty, while they do have an effect on first confirmations. Do you disagree with that?

There is already a financial incentive for the miner to include transactions.  If the miner is choosing to earn less money so they can create "empty" blocks, then they have a specific reason that they choose to mine "empty" blocks.  If the miner specifically wants to earn less money and mine "empty" blocks, and you change the rules so they have to include transactions, don't you think they are more likely to simply quit mining?

Furthermore, in your example, the only way the miner affects the time of first confirmation is by adjusting the difficulty at the previous adjustment (to increase the time of first confirmation), and then adding additional hashing power to first confirmations during the current difficulty (assuming they continue mining without "empty" blocks.