Gold collapsing. Bitcoin UP.

[cypherdoc]

from your article:

ViaBTC was able to win the race by sheer force of hashrate.

FUD much? ViaBTC and BTC.TOP are the SAME size hashrate-wise. in fact, BTC.TOP is slightly larger:

https://cash.coin.dance/blocks/thisweek

and even more FUD. what is this?:

ViaBTC had enough hashrate and luck

plus, YOUR network measuring all this consisted of NON-mining nodes. no wonder BTC.TOP's smaller block got to your non-mining node network first. but both of those pools are probably connected to the same small world-relay-network which would have made all it's mining nodes aware of ViaBTC's block first (max one hop and <2s relay, iirc), thus they were destined to win the race anyways. you're not even measuring the relevant network, yet you make all these wild assumptions. as well, orphan races come around once a week, thus making these races rare. imo, what you observed is not surprising and certainly not a demonstration of the "large vs small miner big block attack". more like luck and circumstances. furthermore, ViaBTC's hash is only around 7%; what's the likelihood they consciously try to mine two consecutive blocks in a row attempting a selfish mining attack? would it be worth it for them? UNLIKELY and NO.

 

[cypherdoc]

a walk back in time. an arrow to keep in your quiver:

https://www.reddit.com/r/btc/comments/61jbrh/bitcoin_core_advocates_for_full_blocks_and_high/

 

[jtoomim]

My article was not discussing the game theory of bloat blocks. Its discussion was for large blocks from any cause, including organic demand. My point was that if we have very large blocks (for whatever reason) with the current code, things will likely go southward. ViaBTC wasn't trying to make BTC.TOP start an orphan race; ViaBTC was just trying to clear the mempool.

If there will never actually be any very large blocks, then you're right, there would be no drawback to raising the block size limits without first improving the code. However, if there never will actually be very large blocks, then there's no benefit to raising it either.
[doublepost=1537133688,1537132562][/doublepost]

from your article:

ViaBTC was able to win the race by sheer force of hashrate.

FUD much? ViaBTC and BTC.TOP are the SAME size hashrate-wise. in fact, BTC.TOP is slightly larger:

ViaBTC has 6 EH/s of SHA256 hashrate on BTC right now. BCH has 3.5 EH/s of hashrate right now for the entire network. If ViaBTC had borrowed hashrate from their BTC pool to confirm their BCH block, they would be expected to take 7 minutes to mine a block. They actually only took about 4 minutes. Yes, it's possible they just got lucky with their 0.3 EH/s typical of BCH hashrate; that would have happened within 4 minutes in 3.4% of attempts, On the other hand, with 6.3 PH/s, a 4-minute block would happen in 51% of all attempts. Given that data, Bayes' theorem says we should take the BTC hashrate hypothesis a lot more seriously than we did before.

plus, YOUR network measuring all this consisted of NON-mining nodes. no wonder BTC.TOP's smaller block got to your non-mining node network first. but both of those pools are probably connected to the same small world-relay-network which would have made all it's mining nodes aware of ViaBTC's block first (max one hop and <2s relay, iirc),

CSW's "Small world network" explanation does not make sense from a network engineer's perspective. Not all hops are created equal. A 1 MB message sent over a single hop that crosses the globe with significant packet loss will be slow no matter what, and will usually be slower than a multi-hop path with the same total latency but lower packet loss per hop. (For the selfish-mining context that CSW made the theory for, it's even more wrong: a 1 MB message over a long hop will always be slower than a 1 packet message sent over the same distance.)

For more information on this, please read this reddit comment:


If your 2 second latency small world network hypothesis were correct, then BTC.TOP would almost certainly have received ViaBTC's first block before mining their own, and there probably would not have been an orphan race at all. A 2 second delay only results in a 0.3% orphan rate risk.

 

[Norway]

@jtoomim
What do you think the default EB-setting in BU should be?

 

[jtoomim]

I think 32 MB is about right for now.

 

[cypherdoc]

Given that data, Bayes' theorem says we should take the BTC hashrate hypothesis a lot more seriously than we did before.

if you really believe that ViaBTC would try to game the system this way by borrowing hash from BTC in an attempt to "confirm" their 6MB block at height 546011, then why would they mine the follow on block 546012 with an equivalent size of 6MB? better to just mine an empty block to quickly propagate it and orphan BTC.TOP's competing block.

@MarkBLundeberg

 

[jtoomim]

546011 was the shared parent. The orphan race happened at 546012. I made a mistake on the heights in my article, which I have fixed.

The block that won the orphan race was 1.35 MB, incidentally. However, I don't think that's relevant.

The only time that it makes sense to mine empty blocks is when you have downloaded the header of someone else's block, but have not yet downloaded the full block. As ViaBTC was building on their own block, they clearly already had that.

If you want to be a stickler for details, you might note that the breakeven fee for ViaBTC would have been double the normal value in this circumstance. Normally, miners will choose to only accept transactions that pay enough of a fee to offset the marginal orphan cost of including that transaction. With a block propagation speed of 1000 kB/s, a block reward of 12.5 BCH, and a block interval of 600 seconds, that becomes:

0.5 * 1250000000 sat/block * 1/600 blocks/sec / 1000000 bytes/sec
= 1.042 sat/byte

Note: the 0.5 factor comes from the fact that the size of the blocks you send out is only half of the mechanisms that can cause orphan races, and you're expected to win half of the orphan races that result; the other half come from other people sending blocks slowly to you.

In this case, though, they had two blocks at stake, so the minimum fee that they should have accepted would have been twice the normal amount, and they should have rejected any transactions offering fees below 2 sat/byte. However, this is such a minor aspect of a rare circumstance that I doubt that they performed this optimization.

 

[Norway]

What do you think the default EB-setting in BU should be?

I think 32 MB is about right for now.

Why?

 

[cypherdoc]

On the other hand, with 6.3 PH/s, a 4-minute block would happen in 51% of all attempts

do you actively monitor the rest of network for a competing block after you push a block? how?

how hard would it be for ViaBTC to repurpose all its BTC hash to BCH in such a short time period? and at what cost to forfeiting the time for BTC hashing?

 

[Christoph Bergmann]

Block propagation data from Bitcoin Cash's stress test:

https://medium.com/@j_73307/block-propagation-data-from-bitcoin-cashs-stress-test-5b1d7d39a234

Nice article, nice data. The more science and data we have, the better.

However, there is one thing with your analyses I don't get: Who cares if non-mining-nodes get blocks with latency? It's not ideal, but also no harm for the network or the maintainer of the nodes. Only mining pools have problems when they get blocks too late.

I also miss a note to the game-theoretic mechanics of parallel validation, which might be usable to create a mechanism for miners to not let blocks grow above a latency-increasing size.

 

[cypherdoc]

@jtoomim

data collection aside, how much of your thinking is driven by this? in other comments you've referred to Coingeek as a behemoth or bully, iirc :

 

[cypherdoc]

or... they could just have the node outside of chain?
cant they organize such that the generation/acceptance of blocks & TX happens outside the firewall and the mindless mining machines are in chain?

somebody already suggested that:

[doublepost=1537200482,1537199702][/doublepost]

The block that won the orphan race was 1.35 MB, incidentally. However, I don't think that's relevant.

why? the smaller a follow on block, the faster it will propagate to seal down the race block and win the orphan race for someone like ViaBTC. the optimal block for that is an empty block.

If there will never actually be any very large blocks, then you're right, there would be no drawback to raising the block size limits without first improving the code.

incorrect. there's a perception issue that Bitcoin can't scale. elevating the 128MB default blocksize sends the recurring signal that BCH is open for business. removing it entirely signals that devs have finally decided to get out of the way. w/o a limit, large miners won't be incentivized to create a stream of orphans that hurt the users/merchants out of fear of damaging the price and secondarily the large corresponding investments in hardware they've made into the space. not to mention being ostracized by their hashers for doing bad deeds and being ostracized from the SWN of mining relay.

If ViaBTC had borrowed hashrate from their BTC pool to confirm their BCH block, they would be expected to take 7 minutes to mine a block. They actually only took about 4 minutes.

shouldn't this be discoverable? surely you of all people should be able to uncover this? i'd seriously rethink my position if you could. this would be a first demonstration of some massive shenanigans coming from a miner.

Given that data, Bayes' theorem says we should take the BTC hashrate hypothesis a lot more seriously than we did before.

sorry for my skepticism in regards to yet another in an endless series of theoretical miner attacks that have been promulgated since 2009 with not one, except for maybe ghash who got punished severely as a result, ever being proven.

 

[cypherdoc]

If your 2 second latency small world network hypothesis were correct, then BTC.TOP would almost certainly have received ViaBTC's first block before mining their own, and there probably would not have been an orphan race at all. A 2 second delay only results in a 0.3% orphan rate risk.

i disagree with this too. let's assume there is a SWN as CSW described that takes a max 2s to propagate a block to all connected miners. let's say BTCTOP is at the outer edge of that network taking the full 2s for any ViaBTC block to get to them. ViaBTC mines the 6MB at 0 time and BTCTOP mines their competing block at 1s. not an unrealistic scenario at all since orphans do usually happen from simultaneously mined blocks roughly. all other miners on the SWN get ViaBTC's block first and mine away on it. BTCTOP's 1s block still propagates out to the p2p network of non-mining nodes you were monitoring b/c it's so small giving you the false impression that it was first and that everyone, including the SWN miners are mining on top of BTCTOP's block, as opposed to the reality that it's mining on top of ViaBTC's.

i noticed elsewhere that you have introduced yet another argument that perhaps the SWN doesn't even exist. the reality is that since the earliest days of BTC mining, pools have either directly connected to each other, used a relay network, or inserted full nodes into the stratum listening protocols of other miners. this has always been a strong indicator to me that miners want to work together vs attacking each other and was evidenced to me by the smooth linear increase in blocksizes produced btwn 2009-2015. proving that the BCH miners have decided not to connect to each other, unlike the past, is a burden that i believe lies on you. sure, it's possible that the p2p protocols, like xthin, have eliminated the need for such a connected network but given your own arguments of severe bandwidth restrictions currently existing on the network, i'd think the miners are continuing their past behavior of remaining connected. it'd be nice to get definitive proof on what exactly they are doing. i perused the orphan rates on blockchain.info and i was amazed that they are down to less than once a month whereas when i mined they occurred once per day. something is causing the massive improvement of this metric.

 

[AdrianX]

The Core propaganda playbook is in full swing this time on the BCH network. source https://www.bitcoincash.org/

Only those who agree to ABC's dominant leadership get a mention, in this episode:

How to Change Consensus Rules as a Small Group with Influence.

Core is plaid by ABC
CTOR is the new Segwit
BU playing the same role, nowhere to be seen
Bitcoin SV is the new Bitcoin XT. (untested - and rushed a word used to belittle new implementations)

I love the details "(coming soon)" under compatible implementations.

 

[cypherdoc]

i'd recommend that everyone watch the entire video of @jtoomim's talk. it's excellent. same type of analysis and general conclusions on the BTC network in Dec 2015 as was published recently on the BCH network as a result of the stress test. he also talks about the concept of locks. esp watch the Q&A where queries were made about issues similar to what i've brought up above, namely:

1. why wasn't the relay network analyzed? aren't those the relevant players?
2. small sample of only ~20 non-mining nodes analyzed on the BTC chain and similarly only 9 non mining nodes on the BCH chain.
3. remember the FUD about how ROW miners might be forced to centralize into China to be closer to the 65% majority of Chinese miners just to stay competitive by having immediate access to Chinese produced blocks? how'd that theory turn out? just the opposite occurred, Chinese miners are being forced to disperse round the world by the gvt; point being that while a technical argument can make infinite sense in one time frame of conditions and assumptions, it can be totally blown out of the water by a political or socioeconomic event. this is precisely the environment that Bitcoin finds itself in; a complex web of socioeconomic, political, and technical factors that are unpredictable no matter the amount of data you mine since they involve human behavior and motivations, which by themselves are unpredictable. thus, the folly of relying on technical factors only and the reasoning behind my argument of continuing to do what's worked (bigger blocks):


lots of good stuff in there.

 

[AdrianX]

Here is an interesting look at the Bitcoin ecosystem from the perspective of an outsider. The good news is there is lots of opportunity for improvement.

https://entertainment.slashdot.org/story/18/09/17/2026248/it-only-took-37-seconds-for-two-bitcoin-celebs-to-start-fighting-on-a-cruise-ship

 

[cypherdoc]

at ~47kB per block in BCH today, we're at the same relative place when BTC blocks were <100-200kB and the limit was 1MB (2009-2014). if the large miner vs small miner big block centralization attack was a real threat, as it was supposedly back then and as it is continuously FUD'd today, where are all the continuous >>>47kB (or even 32MB) large miner generated big blocks that would drive out all the small miners?

 

[Norway]

This article by @digitsu explains many of the reasons I'm proposing 10 terabyte default EB in BUIP 101.

https://www.yours.org/content/the-big-bch-debate-----stability-or-features--sv-vs-abc-cd4f8e575a89#comment-38baa46e4155

 

[cypherdoc]

hey, congratulations to xthins! look at that dump!:

https://i.imgur.com/g0tUqys.png
[doublepost=1537328578][/doublepost]

at ~47kB per block in BCH today, we're at the same relative place when BTC blocks were <100-200kB and the limit was 1MB (2009-2014). if the large miner vs small miner big block centralization attack was a real threat, as it was supposedly back then and as it is continuously FUD'd today, where are all the continuous >>>47kB (or even 32MB) large miner generated big blocks that would drive out all the small miners?

or do miners, large and small, merely make blocksizes according to economic demand, like i claim they do?

 

[freetrader]

@pretsie Can you corroborate your claims about working together with those companies with some evidence?