Bitcoin Forum

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

6 minutes after the previous.

In this thread is discussed similar event (https://bitcointalk.org/index.php?topic=212146.0) 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.

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.

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

It's necessary, but perhaps not enough.

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.

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.

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.

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


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.

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

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.

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)

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.

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.

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


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

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.


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

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.

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

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

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

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?

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.

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

Yes, but new ones won't.

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.

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.

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.

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.

I'm not sure what you mean by that?


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.

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.

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

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.

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.

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

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

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

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'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?

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.

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.

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?

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.

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

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.

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

Yeah, it looks that way.


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


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.

How about instead of rejecting the block when it doesn't have at least 50% of the unconfirmed transactions you know of, you just don't relay it? Then you don't need 51% of the network to follow this new rule. Also, this rule may vary from node to node. Some nodes might have a ton of unconfirmed transactions they know about, so they reject a certain block that contains just under 50% of them, but the other nodes don't know about as many of those transactions, so they accept the block. (This is rather rare, though. The amount of unconfirmed transactions that each node knows about should equalize as transactions propagate) Those nodes could then fork the blockchain. Having it accept but just not relay those problematic blocks would solve that problem.

I think DannyHamilton is right. If a non-empty block is mined right now, then the time distance from now until the next non-empty block is (which will include your transaction), on average, 10 minutes. If an empty block is found in between, then it's still 10 minutes.

If a miner has just mined a block which includes your transaction, and is about to broadcast it, but then it receives an empty block, it doesn't say "Oh dang. Someone found a block. Now I have to wait another ten minutes until I'l allowed to mine another block. Better shut off the ASICs until then so I don't waste electricity" No. It just keeps on mining and will mine a block with your transaction much sooner than that (on average, because it's already been mining for a while).

Of course miners that mine empty blocks delays transactions.
They might be not affecting average block time, but they affect average 'block with transactions' time and that matters.

Do we have at least one empty block every 2016 blocks (probably yes)? If yes then such miners delay transactions all the time.

It's simple: A miner is free to include any transaction he wants. I'm operating a few well connected nodes. I'm free to not relay blocks that do not contain at least a minimum amount of transactions until the next block is found. I patched my clients to prevent relaying those blocks to give miners an incentive to include transactions. I do not relay the last block in the chain when I have a certain amount of open transactions in my pool, the block is the last block and the block included a much lower number of transactions than my pool when I first saw it.

Maybe we should include this feature into the official client to give miners an incentive to include transactions?!

Can of worms there. You would have a solved block discarded which contains dozens of transactions which people have been waiting on for a confirmation? Also, a spammer could immediately cripple the network by generating loads of new transactions. A few weeks ago I saw over 12,000 unconfirmed on blockchain.info, most were not legitimate. Only 2400 (on average) fit into the current block limit.

tl;dr

How about if you don't like what some miners are doing with regards to block creation, then start mining yourself so that you can enforce your own policy for which transactions get included in a block?

Mining yourself is not an option. You have no chance against the pools. The only thing everybody can do and should do is to establish a relay policy for blocks. Each miner (pool) is free to include whatever he wants but each node operator is free as well to relay whatever he wants. Without a relay policy you hand over to much power to the pools. The miners get a lot of money for doing their work. Part of this work is to include transactions. If miners act against my interest and do not include transactions I will not relay their blocks.

Thanks for the tip. Not everbody here are "becoming" as old as you  :D and these appointments are useful.

It depends on how often they become.

Nevertheless, I think this is a weakness of the protocol.

BTW somebody figures out how to poll the apis of blockexplorer.com / blockchain.info to get the list of blocks with only the generation TX?

Hmmm. I suppose so.

The miners producing empty blocks increase the difficulty.  So they do have an affect.

All miners increase difficulty. All miners add value. Miners who only produce empty blocks produce less value than others.

Let's say, the value they produce to bitcoin is much lesser than the value bitcoin produces for them.

Let's just agree to disagree on that point, but the end result is that it isn't going to change without overwhelming support, and I think you'll find it extremely difficult to get the overwhelming support that you need.  There are many like me who prefer to just leave it the way it is.

Interesting discussion, but a few points seem to have been missed.

1.  The blockchain grew from nothing and there were long periods when 0 transaction blocks were normal in the early days.  You need a system that can handle everything from zero to infinity, and the bitcoin protocol does this well (provided pruning and such get good solutions to handle long term growth).

2.  This was said already, but a brilliant incentive exists already to include transactions:  Greed.  Fees will keep transactions flowing.  This current (and temporary) period of time where 25BTC rewards are issued for empty blocks has created a brief window where transactions might not be included by a rogue miner, but I still don't see the threat.  Proof of work is still required, and if they want to give their fees to the next miner, then they're idiots - i'll take the fees gladly.  :)  As network use continues to grow the fees will I think quickly get more valuable than the reward.  Parity is almost certainly only 2 or 4 years away, and as the reward diminishes the problem will fix itself..

2a.  There is a bizarre edge case I thought of ages ago whereby one might be able to do a zero-tx block as a way of sort of "mining without the rush" - to essentially take as long as you wanted to process a block and then trick it into the network to snag the reward, but as I understand it now, I don't think this would work as you need the prior fresh block included in your proof of work declaration.  And this info only exists after said block is created.  And if a loophole existed here - the network would simply not work as everyone would dream up blocks in their free time and then apply them later, so I've discarded this notion completely.

3. Also said already - as long as the zero transaction block has valid proof of work, it does serve to secure prior transactions deeper in the chain.  So we're still getting part of what we need. 

4.  The statistical method used to deliver proof of work almost ensures that once in a very rare while (would love it if a statistician did the maths for us :), a miner would come up with an honest zero tx block - especially if they had some flakey connectivity.  I mean there was only 100 seconds between the prior block and the zero block, so there could be any number of ways this could happen without screaming foul.  And it's possible blocks could be solved within just a few seconds of each other - throw of the dice really.

This leaves me saying:  Meh.  We'll survive.

All the other ideas which have been thrown around to somehow stop zero blocks have horrible repercussions as far as I can tell.  So in the end I also must ask if a "fix" for such an edge case problem could even be worth it.

Now if we see it start to happen 15 times a day, then ignore everything i said 'cause we some hacker biatches we need to drop a boot on!!!!
:)

How does an empty block (~250 bytes) do you more harm than any other 250 byte, 25BTC transaction?  [All I can see is that it (slightly) increases the difficulty two weeks from today.  But if it included one or more transactions, it would still (slightly) increase the difficulty two weeks from today.]  Yes, it's a lost opportunity to include transactions, but is it really any worse than if the miner hadn't been mining at all?

If it ain't broke, don't fix it.

Because bitcoin IS about transactions. So, NO transactions, NO bitcoin. It is easy to understand.


I said, it is a weakness of the protocol, but it does not mean that it is fixable.

My point of view is that the miners keep the block chain running and acknowledge transactions. If I miner is not willing to do the second point it does not deserve the 25 BTC. My reaction was to change my bitcoin nodes to accept all blocks but I do not relay a block block if it is the last block, it includes only a fraction of the possible transactions and my local transaction pool sees much more transactions. If I see a block that better fit my rules I replace this last block by the new one.

If everybody includes this kind of change an "empty" block miner will have a small disadvantage.

This is a temporary problem, so why risk breaking the protocol with a change?

Fees are increasing steadily, and the block reward halves every four years. Probably during the time the reward is 12.5 BTC the fees per block will be begin exceeding that amount. So any miner producing empty blocks will be throwing away 50% of his potential revenue. Because difficulty will probably be 500+ million it will be uneconomic to mine empty blocks.

I'm not changing the protocol. It's my local decision to not relay a block or not. It is a similar change as the dust prevention in 0.8.2 for transactions. It's my local choice to relay transactions and blocks. You are right, in 20-30 years this might be no problem anymore. but as long as the block reward is high, I'm will not spent my bandwith to support miners that do not include (my) transactions.

On the flip side, you could think of like this:  "More fees for me!"  Personally, when I mine, I want to suck up as many fees as possible......  Problem solved - leave all the fee mining to me. 

Hmm.. that's a great idea - I WISH everyone but me would stop processing transactions and just submit zero blocks!  Might only have a verification every year or so (if I'm lucky) and it would be one monster of a giant block....  But man the fees would be awesome.... 

My precious fees......  Precious....

I'm not mining. I operate a bunch of dedicated servers in different locations that run full clients and are optimized to support a large number of connections. The fee is not interesting for me. A miner that is not including transactions is working against my goals. Why should I relay his transactions?

Just don't relay them

As jackjack stated and assuming the last word of your above post was "blocks", then I guess you're talking about suppressing one tx blocks (zero customer tx) from entry into the chain, which indeed you could do.  I'd be very impressed (verging on deeply disturbed) if you control enough of the network though to do this effectively.  8|

And stating the obvious, I guess you couldn't be talking about ignoring "approved" zero blocks as that would break your copy of the blockchain.

In the end, I'm not bothered either way 'cause the bitcoin project has much bigger fish to fry unfortunately.  I think the issue behind this post is like earth in the HHGTG:  "Mostly Harmless".

On the side, you seem like a good person to ask.  I'm going to be setting up some full clients also as a token of support for the project, do you know of a handy "best practices" guide to setting up a good strong node that helps the network?  (port forwarding rules, hardware, bandwidth needs, etc..)  I operate a lot of datacenters and computers around the world, and would be happy to contribute more stability than my randomly on/off laptops running the qt client can contribute.  I have searched the forum, wiki.it and web for stuff like "best practices bitcoin qt" and have come up with zilch.  I'd rather not fiddle - I just want to set them up nicely to let them run indefinitely with maybe GIT set up to make updates easier to pull if possible.  I don't want this as a new hobby, tips very welcome.

Maybe that can delay that empty block enough to allow a nearly-simultaneous block to be accepted before it
That's highly improbable but if more and more people do this that may have a small impact

This!

I changed my bitcoind copy to not relay the last block if it is small (I use a fixed value here) and my local transaction pool has much more transactions than the number of transactions in this block at the time I received this block.

If I'm the only one doing this, the effect is small. If a lot of people are filtering blocks with this method the small number of bad pool operators will be too late with some blocks and loose this block fee. This is an advantage for miners including user transactions in their blocks and an advantage for the other bitcoin users.

I plan to do the same thing in the following days

First thing is, I build bitcoind and not bitcoin-qt as a support node. It makes no sense to run the QT version if you only operate a support node. Then I changed the max number of connections to 2000 and made some quick and dirty hacks to make sure the bitcoin client runs with a large number of connections and relay transactions and block according to my local policy. In the firewall setup I make sure that connections to the bitcoind port can reach my running bitcoind and that bitcoind can reach the rest of the world. Up to a few hundred connections you can just start an unchanged headless bitcoind with a larger number of connections setup the firewall and you are done.

Interestingly, this makes yet another a good argument against the 'ASICS are ruining bitcoin' doomsayers.

Botnets should become increasingly useless with the deluge of people who are intentionally mining with specialized hardware.