>
@jtoomim I was referring to the information presented in your second video, it's out of date.
Yes, I know it's out of date. That's why I posted it second, and why I use numbers from the first video whenever possible. However, the second video covers a lot of material that the first video does not address, like China. The Gigablock initiative explicitly avoided having any nodes in China, which is a big departure from the actual Bitcoin mining network. The 9 MB blocks in my tests often took around 200 seconds to cross the China border, whereas the non-China nodes got the same block in about 20 seconds, or 10x faster. Xthin will reduce all of those numbers, but will not change that ratio.
> it's not the limit that dictates the size its the miners capacity. Glad to know you approve a blocksize higher than your purported struggles with 4MB blocks we're making progress ;-).
The software stack I currently use for mining has only 2-4 MB capacity for block generation with acceptable performance, but up to 30 MB for block receiving and validation with acceptable performance. That 30 MB receive limit comes from Bitcoin ABC's block propagation algorithm, and applies to basically everyone. The 2-4 MB generation limit comes from p2pool's inefficient code, and only applies to me as long as I choose to use p2pool. I use a receive limit of 32 MB and a generation limit of 4 MB. I'm arguing for keeping the consensus limit of about 32 MB until Graphene is mature. That's all.
> why if are you validating in parallel and doing header first mining for the first 13 seconds?
Headers-first mining is not implemented in any full-node software, nor is it implemented in any open-source pool software that I know of except p2pool (which has its own scaling issues). I do not think that it is a good idea to require miners to develop their own software in order to be able to mine competitively. If they're told they have to either hire a developer for $20,000 to write them good pool software, or suffer a 4% orphan rate disadvantage, or pay a large pool a 2% fee, they're going to choose to join the large pool. We don't want them to do that. If we had HFM in BU or ABC or XT, then I agree, that would change things. But we currently don't have that feature. The only pools that have HFM are the large ones with >10% of the network hashrate, and those are exactly the pools that we want to avoid encouraging people to use.
> Anyway, that estimate seems high to me, it would imply a validation time closing in on 2-5 minutes on average
No. 5 minutes would be a 39% orphan rate. 2 minutes is an 18% orphan rate. The formula is
1 - e^(-t / T)
where t is the delay and T is the 600 sec block interval. A 10% orphan rate would be a delay of about 63.25 seconds. At 1.6 MB/s for Xthin, that would imply a block size of about 101 MB.
> But it is good news, as a miner, I can say I would rather charge a higher fee and make a smaller block that risk a 10% orphan
That's only true if you are a small miner. If you have enough hashrate, then you won't see as much of an orphan rate increase as your competition will, because the block propagation time from your node to your node is 0. When your competition's blocks get orphaned, that lowers the difficulty and increases your revenue. So if your increased orphan rate risk is smaller than your competition's increased orphan rate risk, you can actually benefit from making your blocks bigger. In the extreme case, if you have 51% of the network hashrate, you'll see a near-0% orphan rate no matter what, so you should make your blocks as big as possible.
You can still benefit from making large blocks if you only have 30% of the network hashrate. If you can get your block quickly to at least 40% of the rest of the network, then it will end up being at least 70% mining in your support and less than 30% mining against you. This becomes mathematically equivalent to the
Outcast attack. Due to the heavy packet loss when crossing the China border, the Outcast attack tends to naturally happen. My estimate is that Coingeek would actually benefit slightly if they consistently mined 101 MB blocks compared to mining 1 MB blocks, even if they did not collect any transaction fees.
The presence of transaction fees to offset the orphan rate risk makes this worse. A transaction fee that offsets 90% of the marginal orphan rate risk for a 1% pool will offset 129% of the marginal orphan rate risk for a large pool. The large pool will then mine 101 MB blocks and see a 0.1 * (1 - 0.3) = 7% loss in revenue from orphan rates, but will gain 9% from transaction fees, for a net of 2%. Meanwhile, everyone else on the network will get a 0.1 * (0.3) = 3% loss in revenue from orphan rates, causing the difficulty to fall by 4.2%. This increases the revenue for the large block mining pool by 6.2%, and increase revenue for everyone else by 4.2%. That attracts more miners to the large pool, and the large pool gets even larger, strengthening their advantage. Furthermore, users learn that they can get away with lower fees, so fewer transactions are issued with enough fees for small pools to take advantage of.
