Topic: Again, a block with 0 transactions is accepted (Read 4414 times)

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.

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.

I plan to do the same thing in the following days

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.

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

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.

Just don't relay them

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?

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

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.

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.

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.

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.

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!!!!

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.

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

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

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

Hmmm. I suppose so.