Topic: Gold collapsing. Bitcoin UP. - page 196. (Read 2032248 times)

Welcome to the thread! 

I've seen ideas like "3x the average of the last N blocks" before.  I don't think it's necessarily a bad idea.  The problem I see, though, is that there's no hard limit at all in that case.  I predict that people will then want another limit on top of this 3x dynamic limit in order to feel safe.  Now we're back to the same place as we are now…but with increased complexity (dynamic + hard limit). 

That being said, I do think the risk of miners publishing "ginormous" blocks if there was no cap at all is small.  Based on real data, TradeBlock today estimated that it would take 137 seconds for a 8 MB block to propagate to half the nodes.  By the time a 100 MB spam-block propagated, miners would have found another two and the spam block would be orphaned.  The probability of success of such a spam attack is thus inversely proportional to the damage it can cause. 

Perhaps the bitcoin economy has matured enough that a set max block size is not actually needed anymore?!

What if we had some type of patch that eliminated "silly sized blocks" and allowed miners to set any soft limit they want? Have it something like: allow any size as long as it's not more than x3 (or other number) the previous months average block size.

Market incentives will drive each mining pools soft limits. Increasing the limits will stimulate growth (increase centralization if done too fast compared to technology because of resources needed) while smaller blocks will increase fees. Some may like smaller blocks because of risk of orphans while others will want large blocks to grow the user base of people using bitcoins. Allowing a x3 size block means that as long as a minority are making small blocks, those who want larger ones can still help grow the "silly size" limit and those who have weak internet connections just have to download the blocks and can continue making small ones.

A spam attacker could only create large blocks that were bigger than all the pools soft limits only by mining it himself and the largest block he could create would be a x3 of the blocks on the system. And just like it's in their economic self interest to not get bigger than 51% it would also be in pools own self interest to not have a soft limit that would risk too much centralization of the system by making it too large for current technology and allows for the system to rapidly adapt at the time. The fact that most mining is done by pools means that the soft limit can be more fluid.

Ultimately if we let pools set any limit they want would they set limits that would allow bitcoin to thrive? If we assume the majority of pools act in the interest of a growing decentralized system would max block size be needed anymore other than something to prevent a "silly size" block?

You've just restated Gresham's Law.

Hard money is a delusion.

What you really want is soft money that is decentralized and thus remains permission-less (censorship-free).

Kudos for this post because you've influenced some of my thinking about perpetual debasement in such an idealized system.

My prior comments on this issue:

My take was that Mike was nominating Gavin for the role, but they seem to have quite a good 'alignment' on solutions to 'problems'.  Apparently the two had been somewhat covertly meeting with various financial services and other captains of industry and there was a strong consensus that it would be better to have a 'point man' who they could rely on to make things happen in the Bitcoin ecosystem faster and more reliably.  One of the things I noted in Adam Back's characteristically polite and to-the-point note to Mike was him asking for more information on these meetings since most of rest of the developers were unaware of them and a bit surprised.

I think you changed the wording a bit.  I said no to this:


Which I took to mean that "I accept that off-chain solutions could play a role in the future to help with scaling."  I never meant to imply that I believed there could be a solution that doesn't involve blocksize scaling at all.  I think regardless of the role played by off-chain solutions, we must scale up the blocksize for all the good reasons DeathAndTaxes lists here.  Only later will we find out how much demand there is for off-chain TXs.    

Telling the entire core dev team, the commercial bitcoin players and the bitcoin user community that if they didn't like it, they were powerless to stop him? This is friendly gesture in your eyes?

I'm not even being rhetorical using the word "hostile", Gavin and Mike's attitude was exactly that: hostile.

Well, the facts are that Gavin literally did just that; an alternative, hardforked client with a 20 MB block limit, and anyone from the core deve team that didn't like that could watch while he lobbies miners, services and merchants to accept the new client. That was what he said, he has not retracted it, nor confessed the ulterior motive you are affording him. Those are the facts, are they not?

Ok, so if you accept that the blocksize is not the only solution to the problem, then would you also accept that your guess for the rate of block size increase can only be sensibly made when the overall context you are applying it to is known? i.e. design first how you intend to mitigate the problems that bigger blocks bring, then you come up with your goldilocks increase curve?


If only raw hot air could solve this problem, we'd have finished with this probelm a long time ago  

Good point.  He likely would have started at a cap less than 1 MB (not sure about 50k though ).  Seems we both agree that getting it exactly right is unnecessary and difficult. 

More likely the 1 MB would have started at a much lower number as 1 MB was both overkill for near-term usage and hard to support with current technology at the time. 1 MB was clearly chosen with an expectation that it wouldn't be changed very soon. So given an autoscaling limit, it might well have been something more like 50K + 50%/year, giving us approximately 600K now.

FWIW, I think 600K would still be a reasonable limit for the present (if that were in effect we'd likely see better fee management tooling), but I also think something like 2-3 MB is reasonable, or maybe 1 MB plus 50% per year (or a tapering growth rate or something). As you say getting it exactly right is difficult and unnecessary.

the use of the term hostile is propaganda.

its not hostile, it's only hostile if you are feeling threatened like maybe the majority of Core developer working on another another hard fork and want to leverage block size increase with your proposed improvements.

if you're a user choosing the software to protect your investment is a way of expressing decentralization from a centralized control system run by the Core developers.  

You have no clue how to develop software.
It seems you live in illusion and you even believe it is you and your "bitcointalk speculation thread" who developed bitcoin.

I don't know as any other person who based his opinion on fact. I can for sure observe public community  reactions to Gavin's behaviour, though.

I think it's fine.  20MB + 50%/yr was fine with me too.  There isn't one set of "magic numbers" that we need to find or everything comes collapsing down. 


Me too.  The better job he does at guessing, the less energy he (and us) will have to throw at this debate in the future. 

Yep, busted, in this bizarro world the G-man are behind the most anonymous and resilient e-cash ever invented and the starving (for freedom) masses are behind the biggest paradoxy financial panopticon ever shilled on the Internet.

No, I'm just trying to make the point that there's no way not to guess.  A lot of people think the "static" 1 MB limit is somehow neutral while a growing cap is more of a guess.  They're both guesses.  One will turn out to be more accurate than the other and thus require less tweaking going forward...

On that note, starting with a good open-loop response is not the only way to get a good closed-loop one.  There's another way: throw a lot of energy at your system!  Or in Bitcoin's case, a lot of debate and arguments!!    

Now imagine if Satoshi had taken another few moments when implementing the cap.  He writes this in the code:

- "Let's set the cap at 1 MB for now…"

- "…but since Nielsen's Law suggests 50% growth per year, let's make the cap increase by 50% each year too…"

- "…this may need some tweaking in the future, but it's better to make a guess that's slightly off, than one that ridiculously off (like a static limit)!"

If he had done this, the blocksize limit would be set at 11.4 MB now and I bet everyone would be pretty happy.  It would just be taken for granted that "of course the limit grows with time because the systems grows with time too!"

I agree. Gavin's threat of a unilateral hardfork did successfully concentrate minds on coming up with solutions to the problem. How do you know that his intention was not to stage a dev-team coup? He behaved exactly as if he really intended to, nothing suggested otherwise (although I don't claim to be aware of every bit of public commentary Gavin has made, as previously mentioned, I am not a twitter user  )

As far as I remember the debate about the max block size cap started a "long" time ago,
an it risked to stall indefinitely.

In my opinion Gavin's conduct has objectively an accelerating effect on the decision
process. I dare to say that such "extreme" attitude had stimulated a lot devs
in focusing to find a solution and to come to a compromise.

I'm not saying that his proposal is perfect or better than any others on the table, just
stating that his strategy have moved the situation toward a new equilibrium by a long shot.

There's a faint suggestion here that there is only one possible way to make bitcoin scale up, and it involves guessing which block size corresponds to which required rate of transactions. Which implies you believe the whole thing scales up using block size increases only. Is this really what you're implying?