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

Yes, at this point, the block size limit debate is sound and fury, signifying nothing.  If the market wants to increase the block size limit, then it will increase the block size limit.

I've shown these diagrams a lot because I think they reveal the essence of the situation.  If the limit remains to the right of Q*, then it doesn't really matter what the limit is because it does not affect the free market dynamics.  However, if the limit falls to the left of Q*, then the pressure due to the deadweight loss will eventually cause a fork to move the limit back to the right of Q*!  

TL/DR: There is no way to stop Bitcoin from growing.  

How can we loose that free choice if anyone is free to release an alternate client the same way XT would have. If it get enough support it will simply be adopted.

Hitler political campaign was not an open source project... Or are you are saying that bitcoin can be controlled with the same kind of propaganda tactics?

You completely and conveniently ignore what I'm saying.  This is a POSSIBLE PATH that could come about IN THE FUTURE.  So, saying that it isn't in XT today doesn't counter anything.  You are arguing with yourself.  Here, I'll agree with you...  "what could become the future is not true in the present."

What is factual is the relationship between these possibilities and the XT creator's past proposals.  In other words, it is based on what the "benevolent dictator" could do if he had enough control over Bitcoin clients and miner code. 

The question isn't whether you have free choice today to not install XT.  If you didn't, I wouldn't spend my time typing this.  It is whether you can lose that free choice by trusting future releases of XT loaded with its patches (e.g., blacklisting) and other protocol changes.

As a crude comparison, since you are hooked on the tyranny concept, Hitler didn't start out his political campaign with a proposal to exterminate people.  He started it with proposals the people wanted to hear... to restore Germany to its former glory and prosperity.  Those who trusted him in the beginning began a journey that years later seemed regrettably unstoppable until Germany lost the war.  Tyrants can be very benevolent and seemingly benign in the beginning.  In 1933, Germany had a choice. 

Having the requirement in place that 75% of the miners have to agree with this change first is in fact giving the choice to the market, considering that the miners would most likely not implement such a change without the economic majority also being on board as well. Hayek also defined totalitarianism as the desire to organise the whole of society and attain a definite social goal, this is also certainly not the case with XT.

Really? Did your teacher somehow forget to teach you Hayek?

Let me explain it to you simply. Within Bitcoin XT today only the blocksize increase itself is fundamental to the protocol, and you can just run a BIP101 only version of XT or Core. These things that you are claiming here are completely counter factual and inaccurate. Therefore it is accurate to refer to your statements as conjecture because you have no proof backing up your statements.

This has not been proposed for XT and has not been implemented in the code.
The use of checkpoints has not been proposed for XT and has not been implemented in the code.
This has not been proposed for XT and has not been implemented in the code.
This has not been proposed for XT and has not been implemented in the code.
Because #1-4 are not true it will not make it hard to just run another implementation of Bitcoin.

I have studied political philosophy so I am well aware of how to predict and recognize tyranny, having 75% of the miners to agree with a fork in advance is not a tyranny by any stretch of the definition. Also to be the benevolent dictator of your implementation of Bitcoin is not wrong, and is not the same as being the benevolent dictator of Bitcoin. This is a very important distinction, I do hope that you can come to understand this difference. In the case of Bitcoin the code is all that really matters, so attacking the person has no relevance. What matters is what is in the code now, and none of the things you have mentioned are in the code now, it is completely counter factual. I am also aware of where you are getting this information from and you are quoting Mike Hearn out of context from a time before BIP101 was even implemented in XT and they where discussing hypothetical worst case scenarios. It does not even matter if Mike Hearn believes these things, since if he did try to implement these features like you claim he will, then people can simply just not use his implementation of Bitcoin and use another instead, it is that simple.

I thought I heard all of his bad ideas, but 8 nodes is a new one.  Do you have a link to this proposal so I can add it to my collection?

"In mathematics, a conjecture is a conclusion or proposition based on incomplete information, but for which no proof has been found.[1][2] Conjectures such as the Riemann hypothesis (still a conjecture) or Fermat's Last Theorem (now proven, while has been called, Fermat's conjecture) have shaped much of mathematical history as new areas of mathematics are developed in order to solve them." (wikipedia)

How on earth do you apply the term "conjecture" to discussion about future possibilities? 

As for the benevolent dictator's past proposals, definitely not conjecture. E.g.,

https://bitcointalksearch.org/topic/mike-hearn-foundations-law-policy-chair-is-pushing-blacklists-right-now-333824

Its not about "level of adoption" (there is no healthy drive besides the "hide secure y'all wealth" thing), but rather about the "late-comers" pump of litecoin & co that ensues..

So what is the plan?

What level of wild bitcoin adoption do you expect?

You do realize that "wild" metric implies "wild" block size increase as well? Where does that get us?

I am glad that you can see that it could have been the other way around and that Core does not have any type of "authoritative" or "official" status in this regard. Anyone can propose a fork that could seriously screw with the design philosophy and this is not wrong or a coup of Bitcoin. Whether that fork is adopted or not is up to people and that is a part of the design philosophy of Bitcoin.

That is why it would not be wrong to propose a fork increasing the supply of Bitcoin for instance, whether you can get people to support it is a different matter all together. The only conceivable way to carry out a coup of Bitcoin would be to somehow circumvent the consensus mechanism itself by somehow going against the 51% of miners, I am not sure if this is even possible. It could also be considered a coup if force is used to coerce miners and full node operators. However this is not what XT is proposing to do.

It still stands that if one of these five Core developers becomes unreasonable and refuses any change to the block size whatsoever and no compromise can be reached then the only way to increase the block size would be to fork away from the Core development team. This reliance on these five people at the very least should be considered a hypothetical problem that could happen one day if it has not already happened.

I was not even talking about XT, however this stuff that you are saying is completely inaccurate and I do not understand while you feel the need to even say such things. To support BIP101 is just to support bigger blocks not the incumbent banking system, and 8 nodes running the whole network, this is just hyperbole and conjecture. You are being unnecessarily polarizing. I would support a 12.5% increase per year or a dynamic block size instead in the intrest of compromise and consensus after all.

https://github.com/bitcoinxt/bitcoinxt/tree/only-bigblocks

A friendly reminder that scalability is not the same as throughput.

If you go from one megabyte to eight megabytes, you have eight times more transactions maybe, but as somebody on Reddit said, model demand is infinite.  If you actually want to pile on transactions, there is no plausible block size that you can choose that would make that possible.  So let's not play around.  Let's actually scale bitcoin algorithmically in a way that can make sense....Moving from one megabyte to eight megabytes is a kind of a constant factor change.  It doesn't change the game and there's also confusion about what scaling means....So scaling means how do the system resources change as you put more demands on it.  So, you know, this ON squared factor.  That's what scaling is about, the characteristics as it grows.  What people really mean when they talk about scale in a kind of colloquial sense is they mean what's the throughput of the system.  So changing the block size constant from one megabyte to eight megabytes -- okay, that changes the throughput, but it hasn't improved the scalability and, in fact, presumably the scalability went up by a factor sixty-four very loosely to get an eight times throughput increase, which is a very inefficient way to go about getting more scale and will sooner or later hit some just implied bottlenecks....I think many of the more technical people involved in bitcoin understand that is just increasing throughput technology kicking the can down the road, but the real scalability and high throughput comes from algorithmic improvements that reduce network resource utilization and add other advantages.

-Dr. Adam Back, https://www.weusecoins.com/adam-back-lightning-network/

Although you're representing my views almost accurately (which is a strange experience, don't expect too much effort from me before I regret replying to you), you're still not getting it quite right.

Remember how differently this could have happened; Gavin Andresen used to be the lead developer for Bitcoin Core. He voluntarily handed control over to Wladimir van der Laan to work at the Bitcoin Foundation. If that didn't happen, the entire course of the block limit contention might have played out quite differently. I can imagine various plausible scenarios where I would have backed a fork away from Andresen's control of the Core client, especially when you bear in mind how ill-considered his approach to the scaling issue retrospectively.

So, the main reason to either support or reject a blockchain fork proposal can be made for good reasons. Your reasoning suggests that no-one could ever be so callous as to propose a fork in order to screw with the design philosophy, but that's totally naive. Hearn represents the incumbent banking system in every way except admission; every proposal of his (including his philosophising about 8 nodes running the whole network etc) pushes centralisation while cheerfully inviting the audience to believe that 8 nodes is as decentralised as is needed. What would you expect an erstwhile coup progenitor to do, announce it unspun in advance?

I agree that it might not be enough of an increase, which is why a dynamic block size or a greater increase would be better. However I would consider both options far better then just keeping the one megabyte block size in place, which I know you do not advocate. That however I see as the greatest threat even if it is a result of disagreement of how and when to increase the blocksize.

So I am personally happy to compromise so that we can reach consensus sooner. You already know that I disagree with considering XT to be a coup, so lets not go over that again we have both made our arguments already.

The possibility exists however that in order to bring about a dynamic block size we would still need to hard fork away from the Core development team if they can not all agree with each other internally, since as far as I understand it, there are five Core developers that essentially have the ability to veto each other, such a system could lead to a stalemate. Though I suppose we can cross that bridge once and if we come to it.

Re: 12.5% yearly.

What if something or other suddenly starts driving bitcoin adoption wildly? It doesn't leave the market open to a dev team hashrate coup like XT (as the miners roundly disfavoured that much disruption/uncertainty), but a competing cryptocoin that can handle the spike might try to make an opportunity out of that kind of situation.

I would support a yearly 12.5% increase, even if I think it might be to small. I would also support a dynamic blocksize increase. I just want the blocksize to be increased to be honest. Not increasing the blocksize at all is what concerns me the most. This article explains well why I think that not increasing the blocksize at all would not be good for Bitcoin.

https://bitcointalksearch.org/topic/permanently-keeping-the-1mb-anti-spam-restriction-is-a-great-idea-946236

Many Gavinblock fans won't agree to such a tiny increase, because they know it eats into their XT coalition's raison d'être.

Those Gavinistas and 1MBers will unite to stop the Wuilleblockers.

Alliances shift, deadlock continues.   

You're being conciliatory, so I will read your idea through. When I said I didn't have time though, I actually meant that, so I can't answer you meaningfully right now, but I will take a look at it and respond.

interesting discussion, but stick to the topic.

Fair enough.  So back to the issue, is this amendment an improvement over the original or not?  That's all I'm really looking for out of all this.  Is it at least a step in the right direction?