1

The block #492972 mined today, seems to be totally empty (except the 12.5 BTC reward, i.e. 90'000 USD as of today).

How can this happen?

Murch
  • 75,206
  • 34
  • 186
  • 622
Basj
  • 354
  • 2
  • 20

1 Answers1

2

Miners are free to mine empty blocks if they want. They do not HAVE to include transactions in them. Any block that is well-formatted and extends the blockchain is valid. Miners who do that (mining empty blocks) get the coinbase transaction (12.5BTC) and don't have to deal with the "hassle" of checking pending transactions. They lose the potential transaction fees though (much less than the reward).

Sure, if every miner did that, the bitcoin system would be over.

  • 1
    Why is it allowed that a block doesn't take any transaction at all? Shouldn't a block take all transactions since the previous mined block? – Basj Nov 03 '17 at 23:12
  • No, a block should not be forced to not be empty. Empty blocks allows the blockchain to continue when there are no transactions. Without empty blocks, the blockchain cannot continue when there are no transactions and Bitcoin would stop functioning. – Ava Chow Nov 04 '17 at 00:07
  • If you forced blocks to be non-empty (or even full), you'd just incentivize miners to stuff them with their own transactions. – Pieter Wuille Nov 04 '17 at 01:02
  • @PieterWuille What benefit would a miner have by doing that? Wouldn't that just be paying for the fee themselves and then collecting the same fee themselves, which puts them at zero? Isn't it better to include other people's transactions, so that a miner can profit from the fees? – Anderson Jun 15 '18 at 15:28
  • @AndrewChow and possibly Pieter Wuille too, I believe you misunderstood Basj's question in the comment above. He didn't say that blocks should be forced to be non-empty. Of course that would stop the blockchain if there are no unconfirmed transactions, but that is now highly unlikely. I think it's obvious that he was asking about the normal situation when there are transactions in the mempool (which is probably like 99.999% of the time). Notice the word "take" in his comment. I don't understand why your answers are based on a highly unlikely scenario, except if you wanted to explain theory. – Anderson Jun 15 '18 at 16:01
  • So the question is: why does the protocol allow miners to intentionally not include existing unconfirmed transactions, when including them can only be beneficial, not just for the users and the cryptocurrency as a whole, but for the miners too, because of the fees. We know the case when politics is more important than fees, and then the mempool went up because some big miners intentionally mined empty blocks, to push their agenda that BTC is slow and bad. I don't see any upside of mining empty blocks when there are unconfirmed transactions, for anyone. – Anderson Jun 15 '18 at 16:03
  • So couldn't this be changed with a protocol upgrade where a block is only valid if it includes as much as unconfirmed transactions as it can? I can't see a situation when that would be bad, only good for everyone. A simple version of the rules could be:
    1. If there are no unconfirmed transactions, an empty block would still be valid.
    2. If there are some unconfirmed transactions, but less than 1 MB, a block must include them all to be valid.
    3. If there is more than 1 MB of unconfirmed transactions, a block must be full to be valid.

    Isn't this what getblocktemplate already suggests?

    – Anderson Jun 15 '18 at 16:04
  • 1
    @Anderson The problem is that the network does not have agreement about unconfirmed transactions. Some nodes may have heard about them, others may not. If you add a rule that blocks are required to include as many unconfirmed transactions as possible, you've just introduced a vulnerability in the system where blocks with very recent transactions will split the network in two (nodes that haven't yet heard about the transaction will reject it). Moreover, if this was solvable (getting nodes to agree on what the unconfirmed transactions are), you would not need a blockchain anymore. – Pieter Wuille Jun 15 '18 at 17:06
  • @PieterWuille Thank you for the very informative and thought-provoking answer! I'm thinking about 2 proposals. 1. What if the rule were not so time-sensitive and excluded the most recent transactions, e.g. the ones from the last 30 seconds? So it would only require to include transactions up to a certain timestamp prior to the block solving. Wouldn't then all nodes know about these "older" transactions? 2. Could the rule be local, so that a miner can generate a valid block if he includes all the transactions that he knows about? 3. What is a better place to have discussions like this? :) – Anderson Jun 15 '18 at 20:08
  • @PieterWuille "...blocks with very recent transactions will split the network in two (nodes that haven't yet heard about the transaction will reject it)". Wait a minute, so why doesn't this already happen? I have seen transactions which have been confirmed after a second or two. How come those blocks are then accepted by the whole network? – Anderson Jun 15 '18 at 20:11
  • 1
    You can't require any node to know about any transaction, as there are no guarantees that others forward it to them. The validity of a block can only depend on the block itself and its parents, not on any other context that may differ between nodes. – Pieter Wuille Jun 15 '18 at 21:21
  • 1
    Why doesn't a split already happen? I was talking about a scenario under the rules you suggested ("blocks must contain all unconfirmed transactions they can"), because different nodes would enforce it differently. Currently there is no rule that a block must or mustn't contain anything. A miner is free to include a 2-second old transaction, or even include transactions the network has never seen. – Pieter Wuille Jun 15 '18 at 21:25
  • 1
    You perhaps want to take this discussion to #bitcoin or freenode irc, to bitcointalk.org, or to r/bitcoin on reddit. This is a very common and recurring question. – Pieter Wuille Jun 15 '18 at 21:26