Topic: blocksize solution: longest chain decides - page 3. (Read 2175 times)

These costs, as it has been explained to you repeatedly, are trivial given incremental centralization. In other words miners are incentivized to centralize so as to limit their orphan risks and create larger blocks.

"The miners" cannot enforce a limit. Individual miners can "vote" for a certain limit but never enforce it for the whole network. Under no block size cap, smaller miners have no control and can easily be choked out of the network by larger ones putting more hashpower in support of "their" limit.

No limit is the most guaranteed way to turn Bitcoin into Govcoin and Peter knows this.

You lost me.  Come again?

bitcoin no limit! fuck ya! miners would simply always include some maximum amount of TX to make sure other miners accept it and keep mining on top of it.

https://en.bitcoin.it/wiki/Bitcoin_Improvement_Proposals

Ok cool.  Let's.

Is there a BIP for this?

If not, can we create one?

Yes.  Gavin says there's some memory overflow attack (but I think this limit is node dependent and to fend off this attack the limit can be made very large).

Sickpig (forum member here) suggested that the block size limit was a transport layer constraint that crept into the consensus layer.  I agree.  I don't think we really need a protocol enforced limit because:

1. There is a significant economic cost to producing large spam blocks as an attack.  

2. There is a physical limitation to how large a block can be (due to bandwidth and other constraints).  

3. The miners can enforce an effective limit anyways.  

BIP100 seems redundant (and dangerous if it's not based on majority votes).  Let's get rid of the limit and let the miners sort it out.  

That is nice to read.  Have others proposed this too?

Can you think of reasons AGAINST it?

I think it could be one of those things where not having
a limit sounds like a bad idea on the surface, but the miners
actually can self police themselves.  If a block is ridiculously
huge, throw it out!  If 51% of the network agrees, its probably ok.

I just wonder what would happen if a really huge block was allowed
to stay in the chain.  What kind of edge cases are possible here?

There are a few good reasons to support removing the block size limit from the consensus rules.

1.  It is the simplest possible solution to expanding the block size, involving removing code from the consensus critical code.
2.  It does not require divination (technology forecasting) and resulting contentious numbers that are trolling for argument.
3.  It relies on the existing "longest chain" mechanism and does not require a new distributed algorithm
4.  With the existence of numerous complex proposals (BIPs and otherwise) to increase the block size, this is the only proposal that can possibly serve as a focal point (Schelling point) on which the community can reach agreement.

Not necessarily.  It depends what kind of change are we talking about.

What I'm hypothesizing in this thread here, is that maybe blocksize
shouldn't be a protocol rule to begin with.

It may have been a mere quip, but it was on topic.

Are you suggesting that the threshold for consensus in a hard fork be lowered to 51%?

I fail to see what Mike Hearn or checkpoints has to do with this conversation. Please stay on topic.

@ Peter R,

thanks for the comments.  Yes the longest chain "will" decide.  The hardcoding of a blocksize
is part of consensus just as they are running the same codebase overall.  I question the wisdom
of making that part of the code at all.  However, it seems that having no limit could be problematic,
and as Panther pointed out, miners do want some predictability, which is why I'm liking Bip100 more.
Do you know if Jeff Garzik ever considered making it a 51% vote?

Ask Mike Hearn why he thinks checkpoints might be necessary, just in case this happens.

Jonald is correct: the longest chain (composed of valid transactions) should and will decide just like it's historically done and just like what is described in the Bitcoin white paper.  

Although we've had an explicit block size limit since the summer of 2010, the economic effects of this limit were nil.  The limit was far above the free-market equilibrium point for block space production, and so did not serve to distort the market.  

The proposals in favour of a restrictive block size limit would act as a "production quota" that would force the block size limit smaller than its free-market equilibrium size.  As shown in the figure below, economic theory suggest that we suffer a "deadweight loss" of economic activity equal to the area shaded brown in the lower chart below.  This is an entirely different economic model than the one Bitcoin has been operating on until recently.



My understanding is that a production quota that distorts the free market dynamics (lower chart) can only be of a net social good if it serves to reduce or eliminate some negative externality, and the net loss of economic activity is outweighed by the net gain from reducing that externality. I suppose the small-blockers could argue that the negative externality is "centralization" or "insufficient hash power for security"; however, as theZerg points out, the area shaded brown is also "unmet" demand that could leak into an alt-coin or a sidechain...  

BIP101's proposed increases are unnecessarily large and also favors large miners.

You soft-fork proposition amounts to having miners vote which is IMO never a good idea. At a certain point large miners, which should become the majority, will be incentivized to create as large a block as they can and would veto such attempt to "cancel" the increase.

Most major Bitcoin mining outfits (21 Inc., BitFury, BTCChina, etc.) support BIP 100, whereas amid services (BitGo, BitPay, Circle, Blockchain.info, etc.) most support BIP 101.

I don't like BIP 100 because it gives too much control over a small minority of miners. BIP 100 also does not address loan term scale-ability issues, but rather kicks the can down the road a little bit (it acts like Congress).

I like BIP 101 because it immediately (nearly so) increases the maximum block size (which is needed) and causes the maximum block size to increase over time in accordance with what is roughly the rate of moores law. There are some critics who say that moores law is slowing down and will not keep with with maximum block size increases of BIP 101. To counter this argument, I would suggest a compromise in which, the maximum block size would increase every ~105,000 blocks (as is the case with BIP 101), however at block size increase minus 15,000 blocks a soft fork proposal would automatically be put into place that would stop/cancel the next maximum block size doubling. The soft for proposal, could say for example, if at any time from block size increase minus 15,000 blocks up until block size increase minus 2,000 blocks that 90% of the most recent blocks agrees with the soft fork then the next block size doubling will be canceled, and will instead take place at 105k blocks in the future.

For example, if the maximum block size is about to increase from 32 MB to 64 MB at block 700,000, and the miners agree to a soft fork opposing this increase by including a flag in 90% of the most recent 1,000 found blocks, then the maximum block size will not increase at block 700,000, and the maximum block size will be scheduled to increase to 64 MB at block 805,000 (assuming that a similar soft fork would not be approved immediately prior to the increase)

You make a good point that the miners want to know which blocks will be valid.  I guess I'm seeing the wisdom of Bip100 where it can float but does so in an organized manner.

I wonder what bip100 would look like if we change the voting from 80 percent to 51 percent.  It would eliminate the so called 21 percent attack and make things more orderly.

I am not aware of any reorg in which 3+ valid blocks were properly propagated, zero additional blocks were broadcast for 5+ minutes then those 3 blocks were orphaned (I am not an expert, and as a result I may not be aware of a situation that has occured that matches this description).

In your proposal, what is considered "valid" is not really known until after the fact. As it stands now, the largest three mining pools are finding roughly 53% of the blocks, if these three mining pools were to make it a habit to orphan chains that do not contain any of their found blocks in the most recent three blocks, then all of them would see a mass exodus of miners, however if this were to happen under your proposal, these pools could easily claim they were ignoring blocks that were "too large".

Miners need certainty to know if a certain block is going to ultimately be accepted into the "final" blockchain.

Yes but that is no different than ignoring any other "longer" chain that the mining node deems invalid.  
In your example, the miner ignoring the blocks is going against consensus and therefore will sooner or
later have a shorter chain than the main one.