|
Preclus (OP)
|
 |
March 07, 2016, 03:08:57 AM |
|
I've read some long discussions about the pros and cons of miner's publishing zero transaction blocks (as 'some' are doing now).
The TL;DR is that:
Let's say the blocksize was 10MB and it took 10 minutes to solve a block. Miners would work on solving it but a large zero-miner would quickly solve a zero sized block. They would them publish it to their "large miner friends" who would start solving a next block.
Whoever solved the 10MB block would likely get their block orphaned if the empty block + next block was published immediately after the block was solved/broadcast. And whoever was working on the longer chain would be already working on the next empty block + next block.
In a way, publishing empty blocks seems to create an artificial cap on blocksize, does it not? As the blocksize gets larger and it takes longer to solve blocks, publishing empty transactions can cause more and more transactions to be orphaned.
Additionally, some (many?) people support miners publishing empty blocks. There seems some back and forth whether this should be allowed at all. As it is part of the protocol, disallowing it would seem about impossible at this point in time.
Doesn't this basically put a blocksize limit in the hands of the large miners? And isn't this just a way for the largest miners to gain an advantage over the others? Or is there some reason this is a "good thing"?
|
|
|
|
|
|
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
|
|
|
|
|
|
Preclus (OP)
|
|
March 07, 2016, 03:56:33 AM |
|
The stackexchange links didn't have much information but the discussion in the bitcointalk mining group had a decent discussion and a lot of data. Thank you for posting it, I hadn't seen it before. There are a few discussions on reddit about it but for the most part, it didn't seem there was any consensus on how it affected the network. My question still is.. don't zero transaction blocks effectively limit the blocksize? For example, I would guess you couldn't have a blocksize of 100MB as large miners would publish zero transaction blocks, maybe even multiple zero sized blocks, to orphan other miner's work while they work on making a longer chain. When the block transaction time gets long enough, it seems like the system would break down. And that orphaned work decreases the hashing rate of the entire network. So, these types of transactions seem to artificially cap the total number of transactions and thus the "effective blocksize"? Or do zero transaction blocks cause a decrease of the effective hashing power of the network that is constant against increases in blocksize? |
|
|
|
|
|
watashi-kokoto
|
|
March 07, 2016, 01:35:47 PM |
|
I've read some long discussions
EDIT: Please, stop reading some discussions, and study how the system actually works. You don't know how Bitcoin actually works. |
|
|
|
|
|
watashi-kokoto
|
|
March 07, 2016, 01:54:12 PM |
|
Modern Bitcoin mining is very different than years ago.
All pools use SPV mining. This means miner believes a new block header is valid and mine upon it.
This reduces orphan risk. During the period a whole block transactions are buffered, the receiver mines an empty block.
Why empty block? To avoid accidental double spend /double confirm. Double spend could cause the miner to lose funds from the reward due to block becoming invalid.
The block size is not as relevant anymore, but orphan risk is still present during the one second or so latency window after mining a block.
|
|
|
|
|
|
Preclus (OP)
|
|
March 08, 2016, 05:12:37 AM
Last edit: March 08, 2016, 05:25:28 AM by Preclus |
|
Modern Bitcoin mining is very different than years ago.
All pools use SPV mining. This means miner believes a new block header is valid and mine upon it.
This reduces orphan risk. During the period a whole block transactions are buffered, the receiver mines an empty block.
Why empty block? To avoid accidental double spend /double confirm. Double spend could cause the miner to lose funds from the reward due to block becoming invalid.
The block size is not as relevant anymore, but orphan risk is still present during the one second or so latency window after mining a block.
That is all made clear in the thread I referred to above [ correction: thread other poster referred to]. I suggest you read the full thread if you haven't. One of the arguments for mining empty blocks is to prevent double-spend. But the argument is specious and the real reason seems to be miners trying to gain advantage for themselves. My question stands: Does allowing empty blocks effectively put an real-world limit on the blocksize? |
|
|
|
|
CIYAM
Legendary
 Offline
Activity: 1890
Merit: 1075
Ian Knowles - CIYAM Lead Developer
|
|
March 08, 2016, 05:16:11 AM |
|
Obviously empty blocks means that txs that otherwise could have been in those blocks are instead sitting in the memory pool (delaying their confirmation and reducing the effective TPS rate).
It is interesting that the CEO of AntPool has recently made public his support for Bitcoin Classic (and 2MB blocks) yet their pool is the one responsible for nearly all of the empty (1 tx) blocks at the moment.
(if he is really of the opinion that we need larger blocks now you'd think he'd bother to have his pool fill up the blocks that they are mining currently)
|
|
|
|
|
Preclus (OP)
|
|
March 08, 2016, 05:27:12 AM |
|
Obviously empty blocks means that txs that otherwise could have been in those blocks are instead sitting in the memory pool (delaying their confirmation and reducing the effective TPS rate).
So, if it does decrease the effective TPS rate, at some point is it an effective limit on the blocksize as well? Or is the effect of empty blocks constant with respect to blocksize? If it does effectively limit the blocksize, what is the limit? |
|
|
|
|
achow101
Staff
Legendary
Offline
Activity: 3388
Merit: 6578
Just writing some code
|
|
March 08, 2016, 05:31:02 AM |
|
Obviously empty blocks means that txs that otherwise could have been in those blocks are instead sitting in the memory pool (delaying their confirmation and reducing the effective TPS rate).
So, if it does decrease the effective TPS rate, at some point is it an effective limit on the blocksize as well? Or is the effect of empty blocks constant with respect to blocksize? If it does effectively limit the blocksize, what is the limit? No. The size of a block does not matter in how quickly the block is solved. A block with no transactions and a full block both have the same probability of being the solution. |
|
|
|
|
Preclus (OP)
|
|
March 08, 2016, 06:02:34 AM |
|
No. The size of a block does not matter in how quickly the block is solved. A block with no transactions and a full block both have the same probability of being the solution.
The size of the block doesn't matter but you can start solving for an empty block before you can start solving for a block with transactions. Described in the thread referenced above: Why do some pools do that? Is there an advantage?
Time. Get the details of the last block mined, immediately start mining for the next - at this point 'empty' - block (and your chance at the block subsidy). Then while things are busily mining away, build new headers that do include transactions, and at the next opportune moment start mining on that. It's just a small sliver of time, but against an otherwise equal opponent, collecting transactions by default would be a losing strategy in the long run. |
|
|
|
|
CIYAM
Legendary
Offline
Activity: 1890
Merit: 1075
Ian Knowles - CIYAM Lead Developer
|
|
March 08, 2016, 06:09:20 AM |
|
Whilst it is true that mining an empty block can be done faster as the block reward diminishes the omission of txs for the slightly better chance of winning the block reward becomes less attractive (so after the next halving one would expect to see fewer such empty blocks and even fewer after the following halving, etc.).
This is what is described as the "fee market" and will eventually be the only reward that miners will receive.
|
|
|
|
|
Laviathon
|
|
March 08, 2016, 06:22:19 AM |
|
If you find a block 30 seconds after another block is found and there is no backlogged que at all maybe. Its been a long time since i have seen any empty block. I have seen some small ones but not empty.
|
|
|
|
CIYAM
Legendary
Offline
Activity: 1890
Merit: 1075
Ian Knowles - CIYAM Lead Developer
|
|
March 08, 2016, 06:25:43 AM |
|
|
|
|
|
-ck
Legendary
Offline
Activity: 4102
Merit: 1631
Ruu \o/
|
|
March 08, 2016, 09:46:09 AM |
|
Modern Bitcoin mining is very different than years ago.
All pools use SPV mining. This means miner believes a new block header is valid and mine upon it.
This reduces orphan risk. During the period a whole block transactions are buffered, the receiver mines an empty block.
Why empty block? To avoid accidental double spend /double confirm. Double spend could cause the miner to lose funds from the reward due to block becoming invalid.
The block size is not as relevant anymore, but orphan risk is still present during the one second or so latency window after mining a block.
Horse shit. Only Chinese pools use SPV mining. The alleged benefits you list there are no more than propaganda. Other pools get by fine with full verification of blocks and transactions on new block generation without delays getting work out to miners, nor an increase in orphans. |
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
|
|
|
achow101
Staff
Legendary
Offline
Activity: 3388
Merit: 6578
Just writing some code
|
|
March 08, 2016, 01:10:16 PM |
|
No. The size of a block does not matter in how quickly the block is solved. A block with no transactions and a full block both have the same probability of being the solution.
The size of the block doesn't matter but you can start solving for an empty block before you can start solving for a block with transactions. Described in the thread referenced above: Why do some pools do that? Is there an advantage?
Time. Get the details of the last block mined, immediately start mining for the next - at this point 'empty' - block (and your chance at the block subsidy). Then while things are busily mining away, build new headers that do include transactions, and at the next opportune moment start mining on that. It's just a small sliver of time, but against an otherwise equal opponent, collecting transactions by default would be a losing strategy in the long run.Not necessarily. Look at ckpool. They do full verification of blocks and produce very few empty blocks and have few orphans. With a dedicated server and decent setup and software, the time to verify a block to begin mining on it is negligible. |
|
|
|
|
Laviathon
|
|
March 08, 2016, 01:54:37 PM |
|
401582 14:50:11 / 401583 14:50:36 = 21 Seconds 401556 10:03:58 / 401557 10:04:39 = 41 seconds 401538 07:35:40 / 401539 07:36:39 = 59 seconds 401511 02:48:24 / 401512 02:48:52 = 28 Seconds I will say I stand corrected on not seeing empty blocks but all the above were no where close to the estimated 10 minutes per block that the ecosystem that bitcoin is based on. I do agree some more diversity as to the pool would be good for bitcoin. After all I have a pool and am running core 0.12.0 over classic or the other options. People are never going to leave the big pool though and loose the constant dust that they are getting. |
|
|
|
|
PassThePopcorn
|
|
March 09, 2016, 04:17:16 PM |
|
401582 14:50:11 / 401583 14:50:36 = 21 Seconds 401556 10:03:58 / 401557 10:04:39 = 41 seconds 401538 07:35:40 / 401539 07:36:39 = 59 seconds 401511 02:48:24 / 401512 02:48:52 = 28 Seconds I will say I stand corrected on not seeing empty blocks but all the above were no where close to the estimated 10 minutes per block that the ecosystem that bitcoin is based on. I do agree some more diversity as to the pool would be good for bitcoin. After all I have a pool and am running core 0.12.0 over classic or the other options. People are never going to leave the big pool though and loose the constant dust that they are getting. 401870 - 1m29s Full block 401873 - ~3mins Full Block 401879 - ~5 mins Full Block 401882 - ~2mins Full Block There are other short blocks that were filled if you look for them. |
|
|
|
|
jonnybravo0311
Legendary
Offline
Activity: 1344
Merit: 1023
Mine at Jonny's Pool
|
|
March 10, 2016, 03:34:19 PM |
|
I wonder why -ck didn't merge this with my empty block thread. At any rate, you ask very pertinent questions Preclus. We recently had a very large backlog of unconfirmed transactions floating around. People flooded to the forum asking why their transactions were not getting confirmed. There was plenty of bad press produced claiming the bitcoin network was doomed. Claims were made that block size absolutely needed to be increased immediately. If you read my empty block thread you'll also notice how many single transaction (only the coinbase) blocks are added to the chain. During that time we were experiencing a backlog of transactions, had AntPool produced only half as many empty blocks as they did, there would not have been a backlog. So, does this have an effect on transactions per second? Absolutely - at least from a throughput point of view. Let's assume that in order to maintain parity, I need to consume a throughput of 1500 transactions per block. Obviously if one or more actors are cheating and not putting any transactions in their blocks, then the overall throughput rate goes down and transactions become backlogged. I've been urging people to stop mining on pools that produce empty blocks and move. Yes, I run my own pool and would love to see more miners on it. However, it is more important to have miners stop pointing their hash to the bad-for-bitcoin pools, and there are plenty of choices out there, including, but certainly not limited to my own. |
Jonny's Pool - Mine with us and help us grow! Support a pool that supports Bitcoin, not a hardware manufacturer's pockets! No SPV cheats. No empty blocks.
|
|
|
-ck
Legendary
Offline
Activity: 4102
Merit: 1631
Ruu \o/
|
|
March 10, 2016, 08:18:21 PM |
|
I wonder why -ck didn't merge this with my empty block thread. This thread was moved from another non-mining part of the forum, and moderators dont have a merge function. Maybe in ten years whenever the new forum software gets finished we'll have the option.. but this is all offtopic banter. |
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
|
|
|
|
Laviathon
|
|
March 11, 2016, 04:50:18 AM |
|
I've been urging people to stop mining on pools that produce empty blocks and move. Yes, I run my own pool and would love to see more miners on it. However, it is more important to have miners stop pointing their hash to the bad-for-bitcoin pools, and there are plenty of choices out there, including, but certainly not limited to my own.
I just do not understand this empty block thing. What is it they are doing to cause this specifically? |
|
|
|
|
