Topic: Bitcoin XT - Officially #REKT (also goes for BIP101 fraud) - page 205. (Read 378996 times)

Him and his cargo cult are still entertaining the no block size cap idea in their new forum  

Damn, I wish my old pal cypherdick was around to enjoy the laughs but he ran away with his tail between his legs and leaving a yellow trail some time ago.  So sad.

Herr Hearn :


Dude is still convinced he's got the support of "the economic majority" 

Wonder the amount of USD he was granted by USG to "dangle" in front of the miners.

   Time for Schadenfreude Theater, courtesy of the dead-ender Gavinista Sad Pandas at https://groups.google.com/forum/#!topic/bitcoin-xt/IoGjEt89CeM.

bitcoin-xt ›
XT nodes dropping. I am concerned about adoption.







Aww, poor Team XT.  It's just so sad they are getting fukkin' rekt, exactly as predicted.   

One proposal involved having the max block size calculated based on previous blocks, allowing the max block size to scale automatically.  So, it won't necessarily need to hard fork every time. 

The public discussion is public.  The Core devs addressed this assertion... publicly.  He did not reply to their response. 

One public discussion went like this...

M2C: proposes patch and BIP.
C2M: technical issues with patch.  need test data and other standard things to address concerns.
M2C: vague political analogies (to demonstrate idealogical superiority).
C2M: "vague political analogies" don't address our technical concerns.
...
M2P: they didn't reply.
C2P: we replied, he chose to not reply to our technical concerns. 

this: https://medium.com/@twobitidiot/the-21mm-btc-soft-cap-71e14cd09946

This is what it all boils down to.

And the political arguments about revolution and social contract --

This is argumentum ad nauseam....

I never said that Blockstream decides on changes within Bitcoin core. However you are missing a very important point. The core developers do decide what changes are made to the Bitcoin core implementation. However the core developers should not decide what goes into the Bitcoin protocol, this is a very important distinction, it is the economic majority that should and does ultimately decide on what the Bitcoin protocol should be, not the core developers. That is why it is so important that we have multiple implementations of the Bitcoin protocol, including multiple competing development teams. Decentralization of development should be a natural extension of the ethos of Bitcoin.

Bitcoin is a giant living experiment, I do not think you can get around that no matter how much we prepare and plan. Some political experiments can only be carried out by actually implementing them on a large scale in reality, because the social dynamics are far to complex to attempt to predict and model every potential variable. The American revolution, Athenian democracy, central banking, fascism, the internet, the communist revolution, and there are many more examples in history where the only way to test such concepts is by actually implementing them in the real world. To think that Bitcoin should not be considered such a political and social experiment would be incorrect in my opinion. If we did apply this logic of needing absolute certainty of the effects of a hard fork it would in effect stifle all possibility for such a change. Since it is impossible to have such certainty in the first place, it in effect makes this an untenable position.

I also do not think that this will be the last hard fork, if we do get a sufficiently large enouth block size I do think that this would be the last hard fork I can imagine myself ever supporting. Since I personally can not foresee what other things will need to be changed to Bitcoin. I do not think it even should be changed at all beyond what we are discussing now, in terms of hard forks atleast. I do expect there to be more hard forks in the future, this is of political necessity. I would also expect Bitcoin to split at the next hard fork as well. When that does happen I will be on the conservative end of the spectrum thinking that we should not change Bitcoin. One of the reasons why I do support increasing the blocksize now is because I consider not increasing the block size as being the equivalent to breaking the social contract. It is ironic that you accuse me for having a fear of controversy when I am the one that is supporting a controversial fork. lol

I do not necessary think that BIP101 is the best technical solution, however right now it is the only alternative client that is proposing to increase the block size through consensus. Which is why I keep stressing the point that I would support a third option as soon as it becomes real, especially if that third alternative would represent a compromise between these two extreme positions.

So you'd rather create arbitrarily large limits now, so we can fork them back down after serious lapses in network security? (Can you guarantee network security in an 8GB environment? How?) As one example, is waiting for mass orphaning of blocks to appear > waiting for transaction volume to warrant raising the limit?

What did Nick Szabo call that -- the Mark Karpeles formula?

You're taking Satoshi out of context. Yes, that may be the eventual solution. That doesn't mean everything should be decided with one hard fork in 2015.


A need basis doesn't justify an 8000x scaling regime, when we have never scaled beyond 1x.

But there's no projection. It simply keeps doubling and the network don't grow at that rate.
Unless everybody will have Google Fiber 24/7 in a few years and there a mass adption like a big bank acceptin Bitcoin and promoting it, and that will not happen.

tbh there's more credibility to the "conspiracy"  that Gavin has been compromised by corporate interests than anything related to Blockstream 

Yes, the blockstream controversy is likely just another conspiracy theory. Along the lines of Gavin being a CIA mole, etc. I think it's just that the "community of devs" often disagree and Wladimir doesn't want to dictate the direction.

Blockstream does not decide if changes are made to the Bitcoin core, the community of devs does.

Yes, reduce if necessary.
What's the problem with this?

If technology and adoption won't grow at rates projected, and if all that slack would cause some issues, it would be easy to adjust the future limits downward.

So you want to increase to reduce later?
Very clever indeed.

Have you considered that it's technically much better to have generous limits which you can reduce via soft forks if needed, than having the limit set too low and then be forced to do another hard fork to raise it.

Also we've already had 32 MB limit in Bitcoin's history and it created no problems. And the fact that Satoshi's idea was to remove blocksize limit entirely when light clients became available.

Not necessarily.
If consensus is reached, a time/size limit can be imposed for every 2 years let's say then the blocksize can be increased gradually.

Exactly. My thinking is that allowing for exponential scaling in this fashion is basically turning the blockchain into a testnet for the next two decades. There is too much money at stake to naively assume that nothing will ever go [very, very] wrong on the path to scaling 8000x in block size limit when we have never scaled past 1x.

An incremental approach is the only responsible approach. As I said above, we can probably safely run a 2MB block regime coming from a .5MB environment -- but an 8GB block regime from a .5MB environment? That's simply irresponsible. Everything that can go wrong will go wrong.


I keep hearing this. People need to get over the fact that bitcoin is, and has always been, a work in progress. This is absolutely not the last contentious debate the community will have (likely this will pale in comparison to future issues). And it is very, very silly to have the mindset that "this is the fork to end all forks." Irrational fear of controversy, and of the idea of hard forking in the future (i.e. making decisions) is not an adequate reason to push a reckless regime of exponential scaling.