Gold collapsing. Bitcoin UP.

[79b79aa8]

I keep having to repeat that the maximum block limit in BU is 2.1GB. There is a default limit setting which is pitched above organic demand, as the miners have long made it clear that they welcome guidance on defaults in software, like most users do. That guidance can be ignored, as we see in BTC where the Core default of 750KB is ignored by all the miners. So, BSV is following suit with a much higher limit. Very good.

To be clear, BU has not changed its model. If BCH blocks remain smaller than 32MB in a future scenario where the BCH mempool clogs up BTC-style causing excessive fees, loss of usage, crippling network effect, then the miners have a solution: use the BU client to mine larger blocks.

@solex, but as we know, the limit is not the essence, but the capacity that the software can handle. to remain competitive, capacity handling has to be under constant improvement. as far as i can see (not too far, communication has been lacking) this ceased being the top priority for BU. it would have been top priority had @Norway's no limit BUIP passed and the released software was under risk of stalling. but we voted no to such ulysses-tied-to-the-mast tactics, vouching for prudent engineering instead. the result seems however to have been a loss of focus.

 

[Norway]

@trinoxol, I would love to be wrong about this. I wish EC were the solution we needed. But each time I calculate the incentives, I find that they're perverse. If you can explain to me how my math is wrong, I would very much appreciate it.

It's ok that you don't understand how locking down the protocol and removing the limit is the market solution to scaling. You don't have to understand it to be useful to me. Just keep pounding the message that BCH should not increase the default setting until you deem it safe.

I'm rooting for you @jtoomim! And if someone wants to split the BCH chain to increase the default value or any other reason, I'm rooting for that too. Investor wins, right?

Best of luck with your endeavour to sement the 32MB limit (until you deem it "safe" to increase).

 

[trinoxol]

@jtoomim Thanks for responding. I tried following the math but it's too much. I admit that I can't refute you mathematically.

The mere fact that one miner is more profitable than the other is nothing to object to. I think what you are saying is if one miner has an advantage in propagation speed they can disproportionately participate in the reward. This would incentivize larger pools. Is this different from selfish mining?

Are the effects that you are pointing out even relevant in their size? I foresee a future where block propagation generally is extremely quick. Miners, that lose races, are forced to quickly upgrade their systems so that there no longer is any relevant disadvantage.

> The premise that a large block will harm the miner who creates it is based on the idea that a large block will be likely to create an orphan race.

If the block is very big other miners will simply not mine on top of it. That way the orphan race is always lost.

> If the percentage of hashrate that has seen A's block is linearly increasing over time, then the average competing block will be mined when sqrt(2) of the competition has not seen the block yet, or 49.5% of the network hashrate.

I do not follow this. Can you elaborate on where the numbers are coming from?

> If A was able to mine at least 1/30 BR more worth of transaction fees

On BSV all pending transactions will nearly always fit into the next block. There will not be any backlog that can be profited from. At least it would be so rare that the effects we are speaking about here are irrelevant.

> small pools will be unable to compete with large pools

Why is that? Because larger pools benefit disproportionately from a difficulty reduction?

Another question is if there will be any pools at all. Mining operations are expected to be large. There will be no need to pay pool fees.

Again, thank you for engaging in good faith with the "other camp". This is too rare these days (on all sides involved).

 

[Norway]

It's really weired to watch people discuss future orphan races and block propagation time when the issue is solved with IBS.

In the future, miners will not wait to tell other miners what the block they are building looks like. There is no reason to hold back this information until a block is found.

When a future miner accepts a tx to his block candidate, he will share that with the other miners in a constant stream. And when he finds a block, he just has to share the block header.

Problem solved.

 

[trinoxol]

Yeah, this is my understanding as well. Block propagation will be a solved problem for all practical purposes.

When CTOR was introduced I thought that the forced ordering was thwarting certain optimizations that I could think of. In particular, it thwarts the idea of building a block from an incremental stream of transactions simply by appending. @jtoomin What's your take on that?

 

[trinoxol]

@freetrader That's 200 byte per transaction which is about as small as you can get. This is a block maximally optimized for transaction count.

 

[Christoph Bergmann]

It's really weired to watch people discuss future orphan races and block propagation time when the issue is solved with IBS.

In the future, miners will not wait to tell other miners what the block they are building looks like. There is no reason to hold back this information until a block is found.

When a future miner accepts a tx to his block candidate, he will share that with the other miners in a constant stream. And when he finds a block, he just has to share the block header.

Problem solved.

IMHO the problem has never existed at all, it's just another episode of Peter Todd's idea that with an unlimited blocksize a big evil miner will make such big blocks that he's the only one left. While in reality - a thing hard to get for theorists - a miner doing this just shoots in his own face. We have seen this over and over on bsv, and no matter how loud the btc and bsv small blockers shout that it is a failure - it is just a success if the initial model.

 

[cypherdoc]

>btc and bsv bch

i keep waiting for my 128MB spam/attack blocks and soon to be 2GB. @jtoomim?

[doublepost=1563156508][/doublepost]

"we will not allow it until..."

"... i get around to it."

@jtoomim = @freetrader : "i have other interests".
[doublepost=1563156602][/doublepost]>"Could be a couple of months, or it could be longer."

aka 18mo
[doublepost=1563156663][/doublepost]Welcome to the World of BCH Development.
You'll get your new world monetary system when we say so.

 

[79b79aa8]

the fundamental problem is with the BCH model.

the diverse priorities of a group of developers, themselves divided into factions, hardly coalesce into a unified plan for a global currency.

 

[cypherdoc]

it's almost as if they have no incentive
[doublepost=1563158885,1563158183][/doublepost]certainly no urgency.

meanwhile, it could be claimed billions of people are suffering from inflation.

 

[Richy_T]

When CTOR was introduced I thought that the forced ordering was thwarting certain optimizations that I could think of. In particular, it thwarts the idea of building a block from an incremental stream of transactions simply by appending. @jtoomin What's your take on that?

Without being supportive of CTOR, I believe that's not a particularly worthwhile optimization since you still have to hash the block each time you change it.

 

[trinoxol]

The hash comes in the form of a Merkle tree. Updating the tail of the tree involves processing the tail plus O(log n) internal tree nodes. Incremental updates are efficient.

 

[cypherdoc]

it's amazing to watch the extent to which even old timers are contorting themselves to call themselves big blockists:


the only conclusion you can draw from an interchange like this is that BCH, BU, and BTC do not trust miners. which is really odd given that miners are the only ones being paid directly by the protocol and have the most resources at risk invested into the system not only in terms of money but also work.

Why is it that I can take myself all the way back to 2011 to rehash old arguments in defense of miners?

 

[Norway]

Without being supportive of CTOR, I believe that's not a particularly worthwhile optimization since you still have to hash the block each time you change it.

Did you read the paper on IBS?

 

[cypherdoc]

sometimes even I forget why I distrust devs so much.

back in 2011, BCT was filled with mostly devs and assorted technical types. the few of you around at that time know this to be true. you also know this logically HAS to be true since technical types were the only ones that could wrap their heads around the technical details so early on and the investors for the most part hadn't yet driven up the price since they weren't around. having started this thread in August (unbeknownst to me a monster to be) I was known to be a "speculator". esp since I was also the #1 poster in terms of frequency then and for several more years until the thread purge. when the price dumped from 32 to 1.98 between July and November (seemed an eternity at the time) , I got suddenly attacked by many of these folks to the insane tune of being called A "Manipulator". can you believe that? what a bunch of whiny bitches. these clowns had no idea of the economic incentives driving Bitcoin at that time and to be into the far future and were barfing up btc by the barrel fulls while screaming at all the "speculators" ruining their precious coin when all that was happening was normal price volatility. then came the attacks on the miners, by these same devs, as a bunch of greedy ignorant pseudo speculators that couldn't be trusted. that's when I knew I was mostly dealing with a bunch of economic ignoramuses technical or not.

BCH, and unfortunately BU , is BTC core all over again. you can see it so plainly in the same recycled arguments against raising the blocksize

 

[freetrader]

Just like BTC, BCH has its own set of dogmatic beliefs about why scaling doesn't work. It's just the same.

This is false. The central belief of Bitcoin Cash is that Bitcoin can scale.

BSV inherited this belief but is taking a different approach. Best of luck to them.

Propagandizing against BCH using false information however, does them - and you - no credit.
It is one of the reasons people find BSV's community not much different than the Core community we were glad to leave behind. Disinformation and censorship will not a successful Bitcoin make.

When BCH and BSV split I did not fully understand why. It totally makes sense now. BSV is an entirely different league and it's fundamentally incompatible with the way BCH wants to go about things.

Indeed the way BSV goes about some things is fundamentally incompatible with our ethos in Bitcoin.

I think in the long run the BCH community is better off without some of those behaviors borne out of misconceptions.

There is no middle ground. No compromise is possible. BTC and BCH must be refuted and go away.

If you can't even refute jtoomim's math but see it fit to negate the BCH view on scaling, then you'll be in for a rude surprise in the future as Bitcoin Cash will not be refuted on technical grounds.
[doublepost=1563184933][/doublepost]

the fundamental problem is with the BCH model.

the diverse priorities of a group of developers, themselves divided into factions, hardly coalesce into a unified plan for a global currency.

And yet Bitcoin Cash outperforms your planned economy.

Also, I am running Linux, an operating system which has been developed by a group of developers with diverse priorities, divided into more factions than I can count, yet which somehow coalesced into a usable platform for running the world's mission critical infrastructure.
[doublepost=1563185218,1563184385][/doublepost]

i keep waiting for my 128MB spam/attack blocks and soon to be 2GB. @jtoomim?

We have been saying all along that the bigger the actual capacity, the harder it becomes to attack such a network.

You keep building a strawman that we believe Bitcoin can be easily attacked with spam blocks at great scale. This only demonstrates your own misunderstanding or intention to ascribe views to BCH developers which they do not hold.

Do you realize that by such actions, you actually turn people off of BSV because they think that its supporters must be uninformed, crazy or malicious?

Welcome to the World of BCH Development.
You'll get your new world monetary system when we say so.

I don't think you understand how the free market and free software work.

 

[cypherdoc]

oh brother.

>We have been saying all along that the bigger the actual capacity, the harder it becomes to attack such a network.

that's precisely NOT what BCH and BTC are saying. the fud is that the larger the blocksize limit, the easier it is to produce big attack blocks by a malicious big miner to gain an advantage due to perceived network propagation and local processing inefficiencies. so I ask again, where are they?

 

[freetrader]

that's precisely NOT what BCH and BTC are saying. the fud is that the larger the blocksize limit, the easier it is to produce big attack blocks by a malicious big miner

This is simply wrong. There is no such FUD from BCH developers.
The FUD is that you're trying to ascribe such views to us.

I've seen it said countless times by developers now working on Bitcoin Cash that the smaller the block size limit, the easier it is to fill up blocks with spam.
Obviously conversely, the larger the block size limit, the more costly a spam attack becomes. Show me where a BCH developer argues differently.

Somewhere along the line you got a completely wrong idea about this. Maybe it explains why you hold other mistaken views about Bitcoin Cash.

 

[shadders]

The hash comes in the form of a Merkle tree. Updating the tail of the tree involves processing the tail plus O(log n) internal tree nodes. Incremental updates are efficient.

This guy gets it...

 

[cypherdoc]

look at this shameless manipulator. typical BCH:

[doublepost=1563195344][/doublepost]

This is simply wrong. There is no such FUD from BCH developers.
The FUD is that you're trying to ascribe such views to us.

I've seen it said countless times by developers now working on Bitcoin Cash that the smaller the block size limit, the easier it is to fill up blocks with spam.
Obviously conversely, the larger the block size limit, the more costly a spam attack becomes. Show me where a BCH developer argues differently.

Somewhere along the line you got a completely wrong idea about this. Maybe it explains why you hold other mistaken views about Bitcoin Cash.

why do you shamelessly misstate my argument?