Mike Hearn response to "An Open Letter to the Bitcoin Community"

[knight22]

https://www.reddit.com/r/Bitcoin/comments/3j8rg1/an_open_letter_to_the_bitcoin_community_from_the/cunzj9z

I wasn't asked to sign it. The first time I saw it was today.
Regardless, now I've read it, the letter contains a few statements I would have found it tough to agree with.
It refers to "the consensus building process". There is no such process. This point has been hammered home over and over again by now, but unfortunately, the Bitcoin Core developers seem to be in denial about it. Whenever we ask somebody to write down this process or tell us what it is, most of them go silent and Adam points to "BIP 1", which doesn't specify any decision making process or means for resolving disagreement. It suggests a continuation of the mentality that every decision has one clearly correct answer on which literally everyone can agree if only there is enough time spent talking. That's clearly not the case here.
I'm honestly not sure what else I can do at this point. The Core developers continue to insist that they have some deeply scientific, academic and professional decision making process. They just won't say what it is. They will say, though, "give it more time".
It says:

We ask the community to not prejudge and instead work collaboratively to reach the best outcome through the existing process and the supporting workshops
This sounds fantastic - there is an existing process and the workshops will support that process.

But this just continues to reflect confusion around what these workshops are actually intended to do. The website FAQ says:
https://scalingbitcoin.org/montreal2015/

Absolutely no decisions are made at workshops
There will probably be no debate

Additionally it says governance will not be discussed.
So we have a project that has no formal process (or even an informal one really), yet claims the workshops will help support that process, whilst simultaneously saying that the workshops won't involve any decision making or governance discussion.
I find this to be a rather inconsistent approach.
The final statement I'd disagree with is this one:

We believe this is the way forward and reinforces the existing review process that has served the Bitcoin development community (and Bitcoin in general) well to date

The process that served Bitcoin well to date was Satoshi being maintainer, and then Gavin. That was the case up until April of last year. Lots of people really don't like this idea because it sounds so fragile, but for most of Bitcoin's history technical disputes were resolved through Gavin making proposals, listening to feedback and then making a decision in reasonable amounts of time. Bitcoin was not being served by this non-existent fairy tale process that the existing Bitcoin Core guys want so badly to believe in.

[BayAreaCoins]

https://www.reddit.com/r/Bitcoin/comments/3j8rg1/an_open_letter_to_the_bitcoin_community_from_the/cunzj9z

I wasn't asked to sign it. The first time I saw it was today.
Regardless, now I've read it, the letter contains a few statements I would have found it tough to agree with.
It refers to "the consensus building process". There is no such process. This point has been hammered home over and over again by now, but unfortunately, the Bitcoin Core developers seem to be in denial about it. Whenever we ask somebody to write down this process or tell us what it is, most of them go silent and Adam points to "BIP 1", which doesn't specify any decision making process or means for resolving disagreement. It suggests a continuation of the mentality that every decision has one clearly correct answer on which literally everyone can agree if only there is enough time spent talking. That's clearly not the case here.
I'm honestly not sure what else I can do at this point. The Core developers continue to insist that they have some deeply scientific, academic and professional decision making process. They just won't say what it is. They will say, though, "give it more time".
It says:

We ask the community to not prejudge and instead work collaboratively to reach the best outcome through the existing process and the supporting workshops
This sounds fantastic - there is an existing process and the workshops will support that process.

But this just continues to reflect confusion around what these workshops are actually intended to do. The website FAQ says:
https://scalingbitcoin.org/montreal2015/

Absolutely no decisions are made at workshops
There will probably be no debate

Additionally it says governance will not be discussed.
So we have a project that has no formal process (or even an informal one really), yet claims the workshops will help support that process, whilst simultaneously saying that the workshops won't involve any decision making or governance discussion.
I find this to be a rather inconsistent approach.
The final statement I'd disagree with is this one:

We believe this is the way forward and reinforces the existing review process that has served the Bitcoin development community (and Bitcoin in general) well to date

The process that served Bitcoin well to date was Satoshi being maintainer, and then Gavin. That was the case up until April of last year. Lots of people really don't like this idea because it sounds so fragile, but for most of Bitcoin's history technical disputes were resolved through Gavin making proposals, listening to feedback and then making a decision in reasonable amounts of time. Bitcoin was not being served by this non-existent fairy tale process that the existing Bitcoin Core guys want so badly to believe in.

Fuck Mike, fuck XT, fuck you and fuck Coinwallet.eu. (199.27.135.46)

[BitProdigy]

A Proposal for the Consensus Building Process:

1) All BIP's have equal weight in the voting process.

2)Miners vote with each newly mined Block.

3) BIPs are revised and amended according to argument and reservations submitted so that they are molded into the best possible versions that everyone is happy with.

4) Once 75% of blocks mined within the last 1000 blocks is in support of one BIP, an alert is sent out to everyone indicating that they should switch over to supporting this BIP.

5) Once 90% of blocks mined within the last 1000 blocks indicates support of the BIP the debate is over and the new BIP is implemented, all blocks that do not include the new BIP protocol changes are after that point rejected.


Historically the threshold has been 95% such as with BIP69, but I suggest lowering that to 90%. Agree? Disagree?

A few of us are working on creating an Open Letter to the Devs from The Bitcoin Community which will include this proposal. If you would like to help us shape this document PM me and I will send you a link to the Google Doc so you can help us write the letter.

[knight22]

- snip-

Fuck Mike, fuck XT, fuck you and fuck Coinwallet.eu. (199.27.135.46)

Why? Because he is pointing how the decision making process is actually broken which is true?

[BayAreaCoins]

- snip-

Fuck Mike, fuck XT, fuck you and fuck Coinwallet.eu. (199.27.135.46)

Why? Because he is pointing how the decision making process is actually broken which is true?

No because he's a threat to freedom and god only knows what else.



BEWARE OF MIKE HEARN ALL USER READING THIS

[BitProdigy]

Mike Hearn seems like he doesn't believe in the Decentralized Consensus Decision Making model at a deep philosophical level and he thinks we should elect a benevolent dictator to make decisions for us.

I disagree, I think the decentralized consensus decision making model works. We don't need a king to make a decision.

[knight22]

- snip-

Fuck Mike, fuck XT, fuck you and fuck Coinwallet.eu. (199.27.135.46)

Why? Because he is pointing how the decision making process is actually broken which is true?

No because he's a threat to freedom and god only knows what else.



BEWARE OF MIKE HEARN ALL USER READING THIS

I distrust Hearn probably more than you do. It doesn't make his statement less true nonetheless.

[Hellot]

The only thing Mike Hearn will agree with is himself.  He appears to want no other solution than the one that makes him the decision maker.
 
"To aid the technical consensus building process we are organizing a pair of workshops to collect technical criteria, present proposals and evaluate technical materials and data with academic discipline and analysis that fully considers the complex tradeoffs between decentralization, utility, security and operational realities."

He is complaining about people getting together to discuss paths forward and his complaint is that "nobody can write it down".  The process can't be written down because it is constantly evolving and Hearn will evolve or not be a factor.

[IIOII]

The only thing Mike Hearn will agree with is himself.  He appears to want no other solution than the one that makes him the decision maker.
 
"To aid the technical consensus building process we are organizing a pair of workshops to collect technical criteria, present proposals and evaluate technical materials and data with academic discipline and analysis that fully considers the complex tradeoffs between decentralization, utility, security and operational realities."

He is complaining about people getting together to discuss paths forward and his complaint is that "nobody can write it down".  The process can't be written down because it is constantly evolving and Hearn will evolve or not be a factor.

Couldn't have said it better!

However it's important to note that lead Altcoin-bully Mike Hearn has never been a relevant factor in Bitcoin Core development. It is really strange that he is given such a huge media presence.

[NeuroticFish]

If you read well between the lines, you can see all the info

Even if there was not a good/real decision making process, I can understand that. Bitcoin is still young.
But the current course of actions tell that in the future there will be a decision making process, which has to be made good.

Mike still doesn't seem to like that. Understandable, it'll make his decisions look foolish.

[chrisvl]

https://www.reddit.com/r/Bitcoin/comments/3j8rg1/an_open_letter_to_the_bitcoin_community_from_the/cunzj9z

I wasn't asked to sign it. The first time I saw it was today.
Regardless, now I've read it, the letter contains a few statements I would have found it tough to agree with.
It refers to "the consensus building process". There is no such process. This point has been hammered home over and over again by now, but unfortunately, the Bitcoin Core developers seem to be in denial about it. Whenever we ask somebody to write down this process or tell us what it is, most of them go silent and Adam points to "BIP 1", which doesn't specify any decision making process or means for resolving disagreement. It suggests a continuation of the mentality that every decision has one clearly correct answer on which literally everyone can agree if only there is enough time spent talking. That's clearly not the case here.
I'm honestly not sure what else I can do at this point. The Core developers continue to insist that they have some deeply scientific, academic and professional decision making process. They just won't say what it is. They will say, though, "give it more time".
It says:

We ask the community to not prejudge and instead work collaboratively to reach the best outcome through the existing process and the supporting workshops
This sounds fantastic - there is an existing process and the workshops will support that process.

But this just continues to reflect confusion around what these workshops are actually intended to do. The website FAQ says:
https://scalingbitcoin.org/montreal2015/

Absolutely no decisions are made at workshops
There will probably be no debate

Additionally it says governance will not be discussed.
So we have a project that has no formal process (or even an informal one really), yet claims the workshops will help support that process, whilst simultaneously saying that the workshops won't involve any decision making or governance discussion.
I find this to be a rather inconsistent approach.
The final statement I'd disagree with is this one:

We believe this is the way forward and reinforces the existing review process that has served the Bitcoin development community (and Bitcoin in general) well to date

The process that served Bitcoin well to date was Satoshi being maintainer, and then Gavin. That was the case up until April of last year. Lots of people really don't like this idea because it sounds so fragile, but for most of Bitcoin's history technical disputes were resolved through Gavin making proposals, listening to feedback and then making a decision in reasonable amounts of time. Bitcoin was not being served by this non-existent fairy tale process that the existing Bitcoin Core guys want so badly to believe in.

Fuck Mike, fuck XT, fuck you and fuck Coinwallet.eu. (199.27.135.46)

It is logical to express your opinion but the way to express it is not reasonable,and I think the members of the community should not be expressed in the way as thou expressive,if everyone started cursing the forum will become a mess.
As old user and legendary rank you should give good example to the other members..

[dothebeats]

It's funny how Mike believes that some kind of a dictator should exist in a decentralized network to decide for all of us. It's just contradicting one of the main concepts of bitcoin lol. Do you XT guys really want centralization to happen in bitcoin because Mike believes that there is no such thing as 'consensus building process'? So in case there really is no such thing (there wasn't any, even Luke-jr admitted), they as the main devs of their proposal would make the decision for all of us to fix things? No, just no.

The process that served Bitcoin well to date was Satoshi being maintainer, and then Gavin.

Not an anti-Gavin here, but dude, let's face it, after Satoshi left bitcoin, Gavin was not the only one who developed it, there are other devs in the project contributing too. Yes, he was the lead dev, but it isn't right that all credits on bitcoin development should go to him.

[poeEDgar]

It's funny. The XT guys keep saying "the development process is centralized" as if it means something (in fact, that's a red herring and a moot point that has nothing to do with decentralization of the bitcoin protocol). And yet, they are willing to back Hearn's contention that bitcoin needs a benevolent "maintainer" that will push his own ideas forward when the other devs disagree.

That's all well and good, but don't be surprised when we oppose bad ideas pushed by such benevolent "maintainers."

[HostFat]

None is pushing anyone to run some code on your computer.
You are free to run the code that you prefer.

You are free to run the code from the """consensus model""" of the Bitcon Core, or the benevolent "maintainers" of the Bitcoin XT. (but there should be even other models, why not?)

[poeEDgar]

None is pushing anyone to run some code on your computer.
You are free to run the code that you prefer.

You are free to run the code from the """consensus model""" of the Bitcon Core, or the benevolent "maintainers" of the Bitcoin XT. (but there should be even other models, why not?)

Ah, but should we refrain from discussing the merits of any of the options? Or do you discourage that?

[jonald_fyookball]

Once again, Mike making more sense than the Blockstream clowns who want to wave a few workshops in your face and make you believe your opinion matters.

[poeEDgar]

Once again, Mike making more sense than the Blockstream clowns who want to wave a few workshops in your face and make you believe your opinion matters.

What are you suggesting?

Whether or not the consensus process is broken, Gavin and Hearn's code needs to stand on its own two feet and face rigorous testing. Such a reckless approach to scaling will never be supported by those who have a real stake in bitcoin.

[HostFat]

Such a reckless approach to scaling will never be supported by those who have a real stake in bitcoin.

Speak for yourself. Don't put opinions on the mouth of others.

[poeEDgar]

Such a reckless approach to scaling will never be supported by those who have a real stake in bitcoin.

Speak for yourself. Don't put opinions on the mouth of others.

Yeah, it was an opinion. And I stand by it. I have faith in the bitcoin community not to destroy itself (as misplaced as that faith may be).

[jonald_fyookball]

Once again, Mike making more sense than the Blockstream clowns who want to wave a few workshops in your face and make you believe your opinion matters.

What are you suggesting?

Whether or not the consensus process is broken, Gavin and Hearn's code needs to stand on its own two feet and face rigorous testing. Such a reckless approach to scaling will never be supported by those who have a real stake in bitcoin.

I'm suggesting Mikes comments make sense.  Blockstream's don't. 

Didn't Gavin run extensive tests on bigger blocks?  More important,
why is Blockstream stonewalling even bip102?

[brg444]

Once again, Mike making more sense than the Blockstream clowns who want to wave a few workshops in your face and make you believe your opinion matters.

What are you suggesting?

Whether or not the consensus process is broken, Gavin and Hearn's code needs to stand on its own two feet and face rigorous testing. Such a reckless approach to scaling will never be supported by those who have a real stake in bitcoin.

I'm suggesting Mikes comments make sense.  Blockstream's don't. 

Didn't Gavin run extensive tests on bigger blocks?  More important,
why is Blockstream stonewalling even bip102?

Yes. Largely broken, half baked bunch of non sense.

What exactly doesn't make sense in Blockstream's comment?

I seen you commenting in another thread spouting about intellectual honesty, boy sometimes it looks to me as if we're not reading the same conversations.

[knight22]

Once again, Mike making more sense than the Blockstream clowns who want to wave a few workshops in your face and make you believe your opinion matters.

What are you suggesting?

Whether or not the consensus process is broken, Gavin and Hearn's code needs to stand on its own two feet and face rigorous testing. Such a reckless approach to scaling will never be supported by those who have a real stake in bitcoin.

I'm suggesting Mikes comments make sense.  Blockstream's don't. 

Didn't Gavin run extensive tests on bigger blocks?  More important,
why is Blockstream stonewalling even bip102?

Yes. Largely broken, half baked bunch of non sense.

What exactly doesn't make sense in Blockstream's comment?

I seen you commenting in another thread spouting about intellectual honesty, boy sometimes it looks to me as if we're not reading the same conversations.

If it wasn't broken, XT would not came out to existence and you and I wouldn't be arguing about it.

[jonald_fyookball]

Already answered what doesnt make sense in my original response to the "An Open Letter to the Bitcoin Community" thread

[Hellot]

If it wasn't broken, XT would not came out to existence and you and I wouldn't be arguing about it.

That's like saying if XYZ wasn't bad it wouldn't be illegal.  If you have nothing to hide, why do you need to hide things.  It's a straw man argument.

[jonald_fyookball]

If it wasn't broken, XT would not came out to existence and you and I wouldn't be arguing about it.

That's like saying if XYZ wasn't bad it wouldn't be illegal.  If you have nothing to hide, why do you need to hide things.  It's a straw man argument.

The reason Gavin did choose XT to implement Bip 101 is that the other developers wouldn't agree in Core. 
Hard to argue with that.

[Hellot]

If it wasn't broken, XT would not came out to existence and you and I wouldn't be arguing about it.

That's like saying if XYZ wasn't bad it wouldn't be illegal.  If you have nothing to hide, why do you need to hide things.  It's a straw man argument.

The reason Gavin did choose XT to implement Bip 101 is that the other developers wouldn't agree in Core. 
Hard to argue with that.

 
That isn't evidence that it is broken. 

[knight22]

If it wasn't broken, XT would not came out to existence and you and I wouldn't be arguing about it.

That's like saying if XYZ wasn't bad it wouldn't be illegal.  If you have nothing to hide, why do you need to hide things.  It's a straw man argument.

The reason Gavin did choose XT to implement Bip 101 is that the other developers wouldn't agree in Core. 
Hard to argue with that.

 
That isn't evidence that it is broken. 

You are in denial then. XT is a direct cause of Core decision process being broken.

[poeEDgar]

You are in denial then. XT is a direct cause of Core decision process being broken.

This is irrelevant to the merits of XT or BIP101. That is the principal concern.

The reason Gavin did choose XT to implement Bip 101 is that the other developers wouldn't agree in Core. 
Hard to argue with that.

That everyone disagrees with someone doesn't logically entail that he is correct, or that his proposal has merit.

[Amph]

None is pushing anyone to run some code on your computer.
You are free to run the code that you prefer.

You are free to run the code from the """consensus model""" of the Bitcon Core, or the benevolent "maintainers" of the Bitcoin XT. (but there should be even other models, why not?)

what happen(very unlikely scenario) if everyone choose XT and i'm the only one remaining with core? i'm fucked right?

i think people should not only choose their solution, but should determinate together what is the best or the, less worst solution, for bitcoin, right now everyone is jumping on what's is better for him/her

[jonald_fyookball]

You are in denial then. XT is a direct cause of Core decision process being broken.

This is irrelevant to the merits of XT or BIP101. That is the principal concern.

The reason Gavin did choose XT to implement Bip 101 is that the other developers wouldn't agree in Core. 
Hard to argue with that.

That everyone disagrees with someone doesn't logically entail that he is correct, or that his proposal has merit.

You're right.  Some people want to scale Bitcoin on the main chain and some people don't.  Pick a side.

[Hellot]

If it wasn't broken, XT would not came out to existence and you and I wouldn't be arguing about it.

That's like saying if XYZ wasn't bad it wouldn't be illegal.  If you have nothing to hide, why do you need to hide things.  It's a straw man argument.

The reason Gavin did choose XT to implement Bip 101 is that the other developers wouldn't agree in Core. 
Hard to argue with that.

 
That isn't evidence that it is broken. 

You are in denial then. XT is a direct cause of Core decision process being broken.

Now you are moving the goal post from bitcoin is broken to the decision making process is broken, which is it?  Let me guess, both are broken!

[knight22]

If it wasn't broken, XT would not came out to existence and you and I wouldn't be arguing about it.

That's like saying if XYZ wasn't bad it wouldn't be illegal.  If you have nothing to hide, why do you need to hide things.  It's a straw man argument.

The reason Gavin did choose XT to implement Bip 101 is that the other developers wouldn't agree in Core. 
Hard to argue with that.

 
That isn't evidence that it is broken. 

You are in denial then. XT is a direct cause of Core decision process being broken.

Now you are moving the goal post from bitcoin is broken to the decision making process is broken, which is it?  Let me guess, both are broken!

Mike's point always has been about Core decision making process and that's why he and Gavin created XT.

[poeEDgar]

You are in denial then. XT is a direct cause of Core decision process being broken.

This is irrelevant to the merits of XT or BIP101. That is the principal concern.

The reason Gavin did choose XT to implement Bip 101 is that the other developers wouldn't agree in Core. 
Hard to argue with that.

That everyone disagrees with someone doesn't logically entail that he is correct, or that his proposal has merit.

You're right.  Some people want to scale Bitcoin on the main chain and some people don't.  Pick a side.

Why are you picking sides, making this a sectarian battle or sorts? That's part of the problem. Some of us are trying to have a constructive discussion about the merits of proposals that have been offered, and about the merits of other potential solutions.

I want to see bitcoin scaled responsibly, incrementally over time to deal with issues of scaling as they arise....rather than hard-coding scheduled capacity increases to a level where we could never contemplate the conditions that will govern network security (1x vs 8000x, 1MB vs 8GB). It's simply irresponsible to assume that what holds true at 1MB holds true at 8GB -- that's insulting to thinking people. And it's insulting that people think we should just accept the course: recklessly increase the block size limit now, and when shit hits the fan, fork it back down. I don't want to wait until a compromise of network security forces us to soft fork the limit back down (presumably after people have lost shit tons of money).

[knight22]

You are in denial then. XT is a direct cause of Core decision process being broken.

This is irrelevant to the merits of XT or BIP101. That is the principal concern.

The reason Gavin did choose XT to implement Bip 101 is that the other developers wouldn't agree in Core.  
Hard to argue with that.

That everyone disagrees with someone doesn't logically entail that he is correct, or that his proposal has merit.

You're right.  Some people want to scale Bitcoin on the main chain and some people don't.  Pick a side.

Why are you picking sides, making this a sectarian battle or sorts? That's part of the problem. Some of us are trying to have a constructive discussion about the merits of proposals that have been offered, and about the merits of other potential solutions.

I want to see bitcoin scaled responsibly, incrementally over time to deal with issues of scaling as they arise....rather than hard-coding scheduled capacity increases to a level where we could never contemplate the conditions that will govern network security (1x vs 8000x, 1MB vs 8GB). It's simply irresponsible to assume that what holds true at 1MB holds true at 8GB -- that's insulting to thinking people. And it's insulting that people think we should just accept the course: recklessly increase the block size limit now, and when shit hits the fan, fork it back down. I don't want to wait until a compromise of network security forces us to soft fork the limit back down (presumably after people have lost shit tons of money).

I think no one would argue with that. The problem is much more on the Core side incapable of making any decision in a timely manner. A decision that will mitigate the risks from every point of views. Waiting or an absolute risk free solution is delusional and outright impossible as no one can 100% accurately predict the future. Of course that attitude will creates some frictions at some point in time and here we are.

[dothebeats]

If it wasn't broken, XT would not came out to existence and you and I wouldn't be arguing about it.

That's like saying if XYZ wasn't bad it wouldn't be illegal.  If you have nothing to hide, why do you need to hide things.  It's a straw man argument.

The reason Gavin did choose XT to implement Bip 101 is that the other developers wouldn't agree in Core. 
Hard to argue with that.

 
That isn't evidence that it is broken. 

You are in denial then. XT is a direct cause of Core decision process being broken.

Now you are moving the goal post from bitcoin is broken to the decision making process is broken, which is it?  Let me guess, both are broken!

Mike's point always has been about Core decision making process and that's why he and Gavin created XT.

They created XT so as to solve only the decision making process that is absent within Core? I see the point of scaling, but this one just got me, also those somewhat unclear intentions of Mike Hearn on wanting a 'dictator' to decide for what's best in the community.

[knight22]

If it wasn't broken, XT would not came out to existence and you and I wouldn't be arguing about it.

That's like saying if XYZ wasn't bad it wouldn't be illegal.  If you have nothing to hide, why do you need to hide things.  It's a straw man argument.

The reason Gavin did choose XT to implement Bip 101 is that the other developers wouldn't agree in Core. 
Hard to argue with that.

 
That isn't evidence that it is broken. 

You are in denial then. XT is a direct cause of Core decision process being broken.

Now you are moving the goal post from bitcoin is broken to the decision making process is broken, which is it?  Let me guess, both are broken!

Mike's point always has been about Core decision making process and that's why he and Gavin created XT.

They created XT so as to solve only the decision making process that is absent within Core? I see the point of scaling, but this one just got me, also those somewhat unclear intentions of Mike Hearn on wanting a 'dictator' to decide for what's best in the community.

His argument being: I can't be a real dictator over bitcoin (only bitcoinXT) as any body can fork the code as we just did. He has a point though.

[Hellot]

If it wasn't broken, XT would not came out to existence and you and I wouldn't be arguing about it.

That's like saying if XYZ wasn't bad it wouldn't be illegal.  If you have nothing to hide, why do you need to hide things.  It's a straw man argument.

The reason Gavin did choose XT to implement Bip 101 is that the other developers wouldn't agree in Core. 
Hard to argue with that.

 
That isn't evidence that it is broken. 

You are in denial then. XT is a direct cause of Core decision process being broken.

Now you are moving the goal post from bitcoin is broken to the decision making process is broken, which is it?  Let me guess, both are broken!

Mike's point always has been about Core decision making process and that's why he and Gavin created XT.

You have said that bitcoin is broken and that's why XT exists, and then you changed it to core decision making is broken and that's why XT exists.  So was XT created to cure bitcoin or to cure core decision making?  Because not everyone agrees that bitcoin is broken, and in fact some very smart people think it is just fine for now and nothing needs to change.  What is working is that no one person has been able to usurp control of the process and that is why it seems chaotic when it really isn't.  When you look at any system and only see one part of it, it is very difficult to see the whole system and come to conclusions about it.  Look at our history of scientific investigation for examples.

What we have now is a healthy system with healthy discussion about a few individuals who want less discussion and are actively working to disable it for the future.  It's up to us if we empower them to do that.  I will not contribute to cutting off my own tongue.

[jonald_fyookball]

Why are you picking sides, making this a sectarian battle or sorts?  

That's just how I see the current reality.

Gavin, Mike, Jeff, some major companies, and most of the miners want to scale Bitcoin on the main chain.
Adam, Greg, and Blockstream don't.  (They've said so in both their words and actions.)

I agree with you that there are technical considerations, but I also think people aren't
cognizant of the reality of the situation.

 

[dothebeats]

If it wasn't broken, XT would not came out to existence and you and I wouldn't be arguing about it.

That's like saying if XYZ wasn't bad it wouldn't be illegal.  If you have nothing to hide, why do you need to hide things.  It's a straw man argument.

The reason Gavin did choose XT to implement Bip 101 is that the other developers wouldn't agree in Core. 
Hard to argue with that.

 
That isn't evidence that it is broken. 

You are in denial then. XT is a direct cause of Core decision process being broken.

Now you are moving the goal post from bitcoin is broken to the decision making process is broken, which is it?  Let me guess, both are broken!

Mike's point always has been about Core decision making process and that's why he and Gavin created XT.

They created XT so as to solve only the decision making process that is absent within Core? I see the point of scaling, but this one just got me, also those somewhat unclear intentions of Mike Hearn on wanting a 'dictator' to decide for what's best in the community.

His argument being: I can't be a real dictator over bitcoin (only bitcoinXT) as any body can fork the code as we just did. He has a point though.

A few posts before this one, you said that bitcoin is broken so that we need to fix things up. Another few more posts, you said that Gavin and Hearn created XT so as to fix the 'consensus making process' that is lacking in Core. I'm not a pro on economy, tech, coding or anything above technical level on bitcoin, but I see that pushing this 8MB max block size limit isn't necessary yet. Scaling? That is too much for a scale! We don't even fill a 1MB block on most cases. .4MB is the largest I've seen even if transaction numbers peaked. And the approach of 'fixing things when the problem is present' doesn't sound appealing to me either (the approach of the Core guys), but come on, 8MB is too high for a limit. I doubt that we will ever see an eighth of that limit being filled within the next years to come.

[knight22]

If it wasn't broken, XT would not came out to existence and you and I wouldn't be arguing about it.

That's like saying if XYZ wasn't bad it wouldn't be illegal.  If you have nothing to hide, why do you need to hide things.  It's a straw man argument.

The reason Gavin did choose XT to implement Bip 101 is that the other developers wouldn't agree in Core.  
Hard to argue with that.

 
That isn't evidence that it is broken.  

You are in denial then. XT is a direct cause of Core decision process being broken.

Now you are moving the goal post from bitcoin is broken to the decision making process is broken, which is it?  Let me guess, both are broken!

Mike's point always has been about Core decision making process and that's why he and Gavin created XT.

They created XT so as to solve only the decision making process that is absent within Core? I see the point of scaling, but this one just got me, also those somewhat unclear intentions of Mike Hearn on wanting a 'dictator' to decide for what's best in the community.

His argument being: I can't be a real dictator over bitcoin (only bitcoinXT) as any body can fork the code as we just did. He has a point though.

A few posts before this one, you said that bitcoin is broken so that we need to fix things up. Another few more posts, you said that Gavin and Hearn created XT so as to fix the 'consensus making process' that is lacking in Core. I'm not a pro on economy, tech, coding or anything above technical level on bitcoin, but I see that pushing this 8MB max block size limit isn't necessary yet. Scaling? That is too much for a scale! We don't even fill a 1MB block on most cases. .4MB is the largest I've seen even if transaction numbers peaked. And the approach of 'fixing things when the problem is present' doesn't sound appealing to me either (the approach of the Core guys), but come on, 8MB is too high for a limit. I doubt that we will ever see an eighth of that limit being filled within the next years to come.

What's the problem then? 8 mb being just a limit.

[dothebeats]

If it wasn't broken, XT would not came out to existence and you and I wouldn't be arguing about it.

That's like saying if XYZ wasn't bad it wouldn't be illegal.  If you have nothing to hide, why do you need to hide things.  It's a straw man argument.

The reason Gavin did choose XT to implement Bip 101 is that the other developers wouldn't agree in Core.  
Hard to argue with that.

 
That isn't evidence that it is broken.  

You are in denial then. XT is a direct cause of Core decision process being broken.

Now you are moving the goal post from bitcoin is broken to the decision making process is broken, which is it?  Let me guess, both are broken!

Mike's point always has been about Core decision making process and that's why he and Gavin created XT.

They created XT so as to solve only the decision making process that is absent within Core? I see the point of scaling, but this one just got me, also those somewhat unclear intentions of Mike Hearn on wanting a 'dictator' to decide for what's best in the community.

His argument being: I can't be a real dictator over bitcoin (only bitcoinXT) as any body can fork the code as we just did. He has a point though.

A few posts before this one, you said that bitcoin is broken so that we need to fix things up. Another few more posts, you said that Gavin and Hearn created XT so as to fix the 'consensus making process' that is lacking in Core. I'm not a pro on economy, tech, coding or anything above technical level on bitcoin, but I see that pushing this 8MB max block size limit isn't necessary yet. Scaling? That is too much for a scale! We don't even fill a 1MB block on most cases. .4MB is the largest I've seen even if transaction numbers peaked. And the approach of 'fixing things when the problem is present' doesn't sound appealing to me either (the approach of the Core guys), but come on, 8MB is too high for a limit. I doubt that we will ever see an eighth of that limit being filled within the next years to come.

What's the problem then? 8 mb being just a limit.

Say that XT is implemented, 8 MB is present, and yet we don't get those previous 1 MB block size limit filled, but you have these 2 fellas making decisions for the whole network. 8 MB is just a limit, but the decisions on the code on the network being made only by those 2 guys? No, just no.

I'm a fan of bigger blocks, but I think 8 MB is just too much atm. If there is an option to make it flexible, that would be great.

[poeEDgar]

You are in denial then. XT is a direct cause of Core decision process being broken.

This is irrelevant to the merits of XT or BIP101. That is the principal concern.

The reason Gavin did choose XT to implement Bip 101 is that the other developers wouldn't agree in Core.  
Hard to argue with that.

That everyone disagrees with someone doesn't logically entail that he is correct, or that his proposal has merit.

You're right.  Some people want to scale Bitcoin on the main chain and some people don't.  Pick a side.

Why are you picking sides, making this a sectarian battle or sorts? That's part of the problem. Some of us are trying to have a constructive discussion about the merits of proposals that have been offered, and about the merits of other potential solutions.

I want to see bitcoin scaled responsibly, incrementally over time to deal with issues of scaling as they arise....rather than hard-coding scheduled capacity increases to a level where we could never contemplate the conditions that will govern network security (1x vs 8000x, 1MB vs 8GB). It's simply irresponsible to assume that what holds true at 1MB holds true at 8GB -- that's insulting to thinking people. And it's insulting that people think we should just accept the course: recklessly increase the block size limit now, and when shit hits the fan, fork it back down. I don't want to wait until a compromise of network security forces us to soft fork the limit back down (presumably after people have lost shit tons of money).

I think no one would argue with that. The problem is much more on the Core side incapable of making any decision in a timely manner. A decision that will mitigate the risks from every point of views. Waiting or an absolute risk free solution is delusional and outright impossible as no one can 100% accurately predict the future. Of course that attitude will creates some frictions at some point in time and here we are.

Considering we have never actually threatened the block limit (and on average are at less than 50% capacity even now), I'd say that "incapable of making any decision in a timely manner" is quite inaccurate. These discussions are important, and we should keep moving the debate forward. But it's silly to act like we should have already implemented a block size limit increase that may jeopardize network security.

That is far more important than the hypothetical future situation where blocks are full.

That everyone disagrees doesn't by default make Gavin and Hearn correct; it only means they made the first attempt. While that's laudable (or nefarious, depending on your take), this doesn't mean that BIP101 merits any support. The content of their proposal must merit that support. From where I stand, it doesn't.

[Hellot]

If it wasn't broken, XT would not came out to existence and you and I wouldn't be arguing about it.

That's like saying if XYZ wasn't bad it wouldn't be illegal.  If you have nothing to hide, why do you need to hide things.  It's a straw man argument.

The reason Gavin did choose XT to implement Bip 101 is that the other developers wouldn't agree in Core.  
Hard to argue with that.

 
That isn't evidence that it is broken.  

You are in denial then. XT is a direct cause of Core decision process being broken.

Now you are moving the goal post from bitcoin is broken to the decision making process is broken, which is it?  Let me guess, both are broken!

Mike's point always has been about Core decision making process and that's why he and Gavin created XT.

They created XT so as to solve only the decision making process that is absent within Core? I see the point of scaling, but this one just got me, also those somewhat unclear intentions of Mike Hearn on wanting a 'dictator' to decide for what's best in the community.

His argument being: I can't be a real dictator over bitcoin (only bitcoinXT) as any body can fork the code as we just did. He has a point though.

A few posts before this one, you said that bitcoin is broken so that we need to fix things up. Another few more posts, you said that Gavin and Hearn created XT so as to fix the 'consensus making process' that is lacking in Core. I'm not a pro on economy, tech, coding or anything above technical level on bitcoin, but I see that pushing this 8MB max block size limit isn't necessary yet. Scaling? That is too much for a scale! We don't even fill a 1MB block on most cases. .4MB is the largest I've seen even if transaction numbers peaked. And the approach of 'fixing things when the problem is present' doesn't sound appealing to me either (the approach of the Core guys), but come on, 8MB is too high for a limit. I doubt that we will ever see an eighth of that limit being filled within the next years to come.

What's the problem then? 8 mb being just a limit.

The problem is how we get there.  It looks very much like we are being steered into making a premature decision that makes it harder for us to have a say over future decisions.  We have a few devs who have created what they think is a solution to a future problem and we have coinwallet.eu trying to force the issue now.  So it looks very much like we are being pressured to make a decision when we don't need to and obviously that is creating blowback.

[brg444]

Why are you picking sides, making this a sectarian battle or sorts?  

That's just how I see the current reality.

Gavin, Mike, Jeff, some major companies, and most of the miners want to scale Bitcoin on the main chain.
Adam, Greg, and Blockstream don't.  (They've said so in both their words and actions.)  

Oh so only them signed this letter heh?

intellectual dishonesty

 

[jonald_fyookball]

poeEDgar,

you make some fair points.

Still, I think it is outrageous that the devs refuse
to accept even Bip 102 with its 2 MB limit.
It's clear to me they do not want main chain scaling
and that it is counter to their business interests.

[knight22]

If it wasn't broken, XT would not came out to existence and you and I wouldn't be arguing about it.

That's like saying if XYZ wasn't bad it wouldn't be illegal.  If you have nothing to hide, why do you need to hide things.  It's a straw man argument.

The reason Gavin did choose XT to implement Bip 101 is that the other developers wouldn't agree in Core.  
Hard to argue with that.

 
That isn't evidence that it is broken.  

You are in denial then. XT is a direct cause of Core decision process being broken.

Now you are moving the goal post from bitcoin is broken to the decision making process is broken, which is it?  Let me guess, both are broken!

Mike's point always has been about Core decision making process and that's why he and Gavin created XT.

They created XT so as to solve only the decision making process that is absent within Core? I see the point of scaling, but this one just got me, also those somewhat unclear intentions of Mike Hearn on wanting a 'dictator' to decide for what's best in the community.

His argument being: I can't be a real dictator over bitcoin (only bitcoinXT) as any body can fork the code as we just did. He has a point though.

A few posts before this one, you said that bitcoin is broken so that we need to fix things up. Another few more posts, you said that Gavin and Hearn created XT so as to fix the 'consensus making process' that is lacking in Core. I'm not a pro on economy, tech, coding or anything above technical level on bitcoin, but I see that pushing this 8MB max block size limit isn't necessary yet. Scaling? That is too much for a scale! We don't even fill a 1MB block on most cases. .4MB is the largest I've seen even if transaction numbers peaked. And the approach of 'fixing things when the problem is present' doesn't sound appealing to me either (the approach of the Core guys), but come on, 8MB is too high for a limit. I doubt that we will ever see an eighth of that limit being filled within the next years to come.

What's the problem then? 8 mb being just a limit.

The problem is how we get there.  It looks very much like we are being steered into making a premature decision that makes it harder for us to have a say over future decisions.  We have a few devs who have created what they think is a solution to a future problem and we have coinwallet.eu trying to force the issue now.  So it looks very much like we are being pressured to make a decision when we don't need to and obviously that is creating blowback.

Well, you can say we don't need to make a decision now as much as you want but those behind Coinwallet clearly disagree and are putting their money where their mouth is. It is this "we can wait forever" attitude that is creating all this mess.

[dothebeats]

poeEDgar,

you make some fair points.

Still, I think it is outrageous that the devs refuse
to accept even Bip 102 with its 2 MB limit.
It's clear to me they do not want main chain scaling
and that it is counter to their business interests.

2 MB seems plausible for the next year or so, and I've been following the stance of Core devs and XT devs. So far, Core devs made some interesting points, also XT especially in increasing the block size limit to scale. But what I cannot comprehend to is why the heck does these Core guys don't want to increase the blocks even with just a single megabyte? Workshops? What are we going to do with that? I'd say find a solution, not delay this problem by months or weeks before you Core guys talk again.

[jonald_fyookball]

poeEDgar,

you make some fair points.

Still, I think it is outrageous that the devs refuse
to accept even Bip 102 with its 2 MB limit.
It's clear to me they do not want main chain scaling
and that it is counter to their business interests.

2 MB seems plausible for the next year or so, and I've been following the stance of Core devs and XT devs. So far, Core devs made some interesting points, also XT especially in increasing the block size limit to scale. But what I cannot comprehend to is why the heck does these Core guys doesn't want to increase the blocks even with just a single megabyte? Workshops? What are we going to do with that? I'd say find a solution, not delay this problem by months or weeks before you Core guys talk again.

You can't comprehend that they are in the business of Bitcoin extensibility and that they took $21M in venture capital and that they really want the main chain to scale as little as possible?

[dothebeats]

poeEDgar,

you make some fair points.

Still, I think it is outrageous that the devs refuse
to accept even Bip 102 with its 2 MB limit.
It's clear to me they do not want main chain scaling
and that it is counter to their business interests.

2 MB seems plausible for the next year or so, and I've been following the stance of Core devs and XT devs. So far, Core devs made some interesting points, also XT especially in increasing the block size limit to scale. But what I cannot comprehend to is why the heck does these Core guys doesn't want to increase the blocks even with just a single megabyte? Workshops? What are we going to do with that? I'd say find a solution, not delay this problem by months or weeks before you Core guys talk again.

You can't comprehend that they are in the business of Bitcoin extensibility and that they took $21M in venture capital and that they really actually do not want the main chain to scale beyond 1mb?

I know that, but don't these guys get paid well in working for bitcoin? I don't like either sides, and I don't judge ad hominem, but these Core guys should do what's right for all and not what's right for their pocket. Same thing with Hearn and Gavin. If they want centralization, just create their own coin and not involve bitcoin or whatsoever. This problem just set drawbacks on bitcoin and are not actually helping in anyway.

[brg444]

poeEDgar,

you make some fair points.

Still, I think it is outrageous that the devs refuse
to accept even Bip 102 with its 2 MB limit.
It's clear to me they do not want main chain scaling
and that it is counter to their business interests.

What's outrageous is you keep spreading the same lies you disingenuous troll.

Devs have not refused any increase, they are actively considering how to best proceed. You're just a goddamn liar.

We've continuously demonstrated the block size has no impact on their business interests how long can you wave it away?

intellectual dishonesty

Seriously, how can you look at yourself in the mirror.

[poeEDgar]

What's the problem then? 8 mb being just a limit.

This is another irrelevant point I see raised often. This discussion is about scaling. It only bears fruit if we approach this as if increased block capacity will actually be used. If we all agree that 1MB blocks will never be filled, why even bother discussing this at all?

One thing that I think BIP101 supporters don't realize is that there may be future incentives that encourage filling block capacity. And while most people assume that organic adoption will be the cause, that is not necessarily the case.

The first manifestation of this: the blockchain stress test. In this case, economic disincentives be damned, in order to bloat blocks. So here we have a situation where we argue in favor increasing the block size limit due to the argument that organic adoption is happening and is exponential (that is quite a controversial statement, too). But in reality, blocks are being filled with spam transactions that are intended to do nothing but fill capacity. Meanwhile, bigger and bigger blocks --> bigger and bigger block propagation delays --> higher and higher volumes of orphaned blocks. Then there is the possibility of hardware and bandwidth limitations not improving to the extent demanded by BIP101's scaling schedule. More importantly are the problems that have not made themselves apparent yet -- as conditions at 1MB =/= conditions at 8GB. A more reasonable middle ground that is in tune with actual transaction growth will allow us to deal with the issues that come with scaling in real time, rather than on a prescribed schedule determined by Moore's Law, which could easily outrun our abilities to maintain network security. (I have still yet to see a compelling reason why Moore's Law has any relevance here, anyway)

So, we might be inviting blockchain bloat without even achieving the sort of organic adoption implied by BIP101. And we will be jeopardizing network security in the process. This is part of the danger of allowing for potential scaling that bears no relevance to actual growth in transaction volume.

[poeEDgar]

The problem is how we get there.  It looks very much like we are being steered into making a premature decision that makes it harder for us to have a say over future decisions.  We have a few devs who have created what they think is a solution to a future problem and we have coinwallet.eu trying to force the issue now.  So it looks very much like we are being pressured to make a decision when we don't need to and obviously that is creating blowback.

Bingo.

[jonald_fyookball]

poeEDgar,

you make some fair points.

Still, I think it is outrageous that the devs refuse
to accept even Bip 102 with its 2 MB limit.
It's clear to me they do not want main chain scaling
and that it is counter to their business interests.

2 MB seems plausible for the next year or so, and I've been following the stance of Core devs and XT devs. So far, Core devs made some interesting points, also XT especially in increasing the block size limit to scale. But what I cannot comprehend to is why the heck does these Core guys doesn't want to increase the blocks even with just a single megabyte? Workshops? What are we going to do with that? I'd say find a solution, not delay this problem by months or weeks before you Core guys talk again.

You can't comprehend that they are in the business of Bitcoin extensibility and that they took $21M in venture capital and that they really actually do not want the main chain to scale beyond 1mb?

I know that, but don't these guys get paid well in working for bitcoin? I don't like either sides, and I don't judge ad hominem, but these Core guys should do what's right for all and not what's right for their pocket. Same thing with Hearn and Gavin. If they want centralization, just create their own coin and not involve bitcoin or whatsoever. This problem just set drawbacks on bitcoin and are not actually helping in anyway.

Well that's part of the problem.  

No, I don't think they were getting paid in working for Bitcoin.

Gavin and 2 other people were getting paid for working on Bitcoin (formerly by the Bitcoin foundation) now from MIT.

Greg and those guys I don't think were being paid so they formed a company and their
plan was to tackle the scalability challenges and they had a certain plan and mindset about it.

And now that they took VC money, they are even more biased that their way is the way to
scale bitcoin.


 

[brg444]

poeEDgar,

you make some fair points.

Still, I think it is outrageous that the devs refuse
to accept even Bip 102 with its 2 MB limit.
It's clear to me they do not want main chain scaling
and that it is counter to their business interests.

2 MB seems plausible for the next year or so, and I've been following the stance of Core devs and XT devs. So far, Core devs made some interesting points, also XT especially in increasing the block size limit to scale. But what I cannot comprehend to is why the heck does these Core guys doesn't want to increase the blocks even with just a single megabyte? Workshops? What are we going to do with that? I'd say find a solution, not delay this problem by months or weeks before you Core guys talk again.

You can't comprehend that they are in the business of Bitcoin extensibility and that they took $21M in venture capital and that they really actually do not want the main chain to scale beyond 1mb?

I know that, but don't these guys get paid well in working for bitcoin? I don't like either sides, and I don't judge ad hominem, but these Core guys should do what's right for all and not what's right for their pocket. Same thing with Hearn and Gavin. If they want centralization, just create their own coin and not involve bitcoin or whatsoever. This problem just set drawbacks on bitcoin and are not actually helping in anyway.

Well that's part of the problem.  

No, I don't think they were getting paid in working for Bitcoin.

Gavin and 2 other people were getting paid for working on Bitcoin (formerly by the Bitcoin foundation) now from MIT.

Greg and those guys I don't think were being paid so they formed a company and their
plan was to tackle the scalability challenges and they had a certain plan and mindset about it.

And now that they took VC money, they are even more biased that their way is the way to
scale bitcoin.

Blockstream was never meant as a transaction scaling solution. Liar.

[knight22]

The problem is how we get there.  It looks very much like we are being steered into making a premature decision that makes it harder for us to have a say over future decisions.  We have a few devs who have created what they think is a solution to a future problem and we have coinwallet.eu trying to force the issue now.  So it looks very much like we are being pressured to make a decision when we don't need to and obviously that is creating blowback.

Bingo.

There is no bingo. What got us here is Core failing to deliver a solution in a timely manner.

Core is the problem, nothing else. Accusing the market that might be ready to make a move and that is sending clear signals is just immature.

[brg444]

The problem is how we get there.  It looks very much like we are being steered into making a premature decision that makes it harder for us to have a say over future decisions.  We have a few devs who have created what they think is a solution to a future problem and we have coinwallet.eu trying to force the issue now.  So it looks very much like we are being pressured to make a decision when we don't need to and obviously that is creating blowback.

Bingo.

There is no bingo. What got us here is Core failing to deliver a solution in a timely manner.

Core is the problem, nothing else. Accusing the market that might be ready to make a move and that is sending clear signals is just immature.

You were sold the lie that it was a pressing matter and that we should address it with urgency. What do you know anyway about their actions?

Much work has already been done in this area, from substantial improvements in CPU bottlenecks, memory usage, network efficiency, and initial block download times, to algorithmic scaling in general.

These guys have been busy fixing bottlenecks that necessarily meant your 8MB blocks would've been useless. They are the scalability champions of Bitcoin so far in its life and you impressionable noob would rather we side with two irresponsible defectors who themselves stifled technical discussion and consequently derailed the incentive to continue productive work toward resolution of the issue by wasting time doing damage control because of the XT fiasco.

Mike & Gavin's actions are the epitome of dishonesty and incompetence. I am absolutely joyous that they have shown their true face and their exile from the community will be a blessing.

[knight22]

The problem is how we get there.  It looks very much like we are being steered into making a premature decision that makes it harder for us to have a say over future decisions.  We have a few devs who have created what they think is a solution to a future problem and we have coinwallet.eu trying to force the issue now.  So it looks very much like we are being pressured to make a decision when we don't need to and obviously that is creating blowback.

Bingo.

There is no bingo. What got us here is Core failing to deliver a solution in a timely manner.

Core is the problem, nothing else. Accusing the market that might be ready to make a move and that is sending clear signals is just immature.

You were sold the lie that it was a pressing matter and that we should address it with urgency. What do you know anyway about their actions?

Much work has already been done in this area, from substantial improvements in CPU bottlenecks, memory usage, network efficiency, and initial block download times, to algorithmic scaling in general.

These guys have been busy fixing bottlenecks that necessarily meant your 8MB blocks would've been useless. They are the scalability champions of Bitcoin so far in its life and you impressionable noob would rather we side with two irresponsible defectors who themselves stifled technical discussion and consequently derailed the incentive to continue productive work toward resolution of the issue by wasting time doing damage control because of the XT fiasco.

Mike & Gavin's actions are the epitome of dishonesty and incompetence. I am absolutely joyous that they have shown their true face and their exile from the community will be a blessing.

Core should clearly revise their priorities then. Their prioritizations are an obvious failure. No one could argue with that.

[dothebeats]

The problem is how we get there.  It looks very much like we are being steered into making a premature decision that makes it harder for us to have a say over future decisions.  We have a few devs who have created what they think is a solution to a future problem and we have coinwallet.eu trying to force the issue now.  So it looks very much like we are being pressured to make a decision when we don't need to and obviously that is creating blowback.

Bingo.

There is no bingo. What got us here is Core failing to deliver a solution in a timely manner.

Core is the problem, nothing else. Accusing the market that might be ready to make a move and that is sending clear signals is just immature.

And what do you mean here by timely? Are there any deadlines that the devs should meet so as to ensure that there would be no problems in bitcoin? As far as I know, there is none, only a few groups are forcing the issue that we need to 'scale' things and because of that we need bigger blocks. Yes, we do need them in the future, but not anytime soon.

[jonald_fyookball]

In 12 months, average blocksize will be about 1mb on the current trajectory,
never mind spikes, unforseen circumstances, and the many months time
needed for consensus and rollout.

How long do you think we should wait?

[brg444]

Core should clearly revise their priorities then. Their prioritizations are an obvious failure. No one could argue with that.

Failure? How?

I don't see how the Bitcoin network running smoothly as it stands (which it wouldn't if it wasn't for their work) is a failure?

[adamstgBit]

In 12 months, average blocksize will be about 1mb on the current trajectory,
never mind spikes, unforseen circumstances, and the many months time
needed for consensus and rollout.

How long do you think we should wait?

~11.5months  

[poeEDgar]

poeEDgar,

you make some fair points.

Still, I think it is outrageous that the devs refuse
to accept even Bip 102 with its 2 MB limit.
It's clear to me they do not want main chain scaling
and that it is counter to their business interests.

I think that in order to establish that point about their "business interests", you need to prove that their objections to the solutions proposed to date are without merit. (I also wouldn't mind an explanation as to how Blockstream's business model works and why they are incentivized against increasing block size. I have done a moderate level of research, but I would like to hear from BIP101 supporters why they are so confident that there is a clear conflict of interest here.)

I don't think it is unreasonable that devs don't explicitly support one proposal or another at this point. I think these discussions need to be further fleshed out. The most responsible approach is to poke as many holes as you can in every proposal, and see if the result is robust enough to move forward. If you look at how this debate unfolded, it should be clear why devs aren't joining "Team BIP100" or "Team BIP102" or "Team BIP103." Doing so just results in more sectarian debate, which tends not to be about technical merit. Ie. this gets us nowhere.

The situation is not nearly as urgent as people are making it out to be. We won't be pushing the limit for a year or more, and even then, a temporary fee market is preferable to rolling out an update when there may be legitimate concerns about how it may adversely affect network security.

I think BIP102 is the most reasonable solution put forth thus far. I think any exponential scaling is dangerous (certainly when it is not warranted by real capacity needs), as it puts the protocol into untested conditions where new problems will surely arise. An incremental, gradual process is far superior, as it allows us to a) move forward with scaling without b) jeopardizing network security to unprecedented extent.

However, I don't consider myself to be on "Team BIP102" because I don't want to be biased against potentially better solutions that may arise, and I want to see more rigorous debate, with more emphasis on the technical issues of scaling. Less politics and accusations of nefarious intention, more discussion of technical merits.

Core is the problem, nothing else.

Core should clearly revise their priorities then. Their prioritizations are an obvious failure.

Like this.

[brg444]

In 12 months, average blocksize will be about 1mb on the current trajectory,
never mind spikes, unforseen circumstances, and the many months time
needed for consensus and rollout.

How long do you think we should wait?

If a solution is obviously needed consensus will be easy establish once we've taken the time to lay out the proper alternatives for implementation.

It is absolutely reasonable to stay as long as possible under current limit and reaching it so far has caused nothing but healthy fee pressure.

Understand that there is still a ton of spam transactions on the network daily which could be better handled off-chain for their absolutely don't need the security of Bitcoin.

[jonald_fyookball]

poeEDgar,

you make some fair points.

Still, I think it is outrageous that the devs refuse
to accept even Bip 102 with its 2 MB limit.
It's clear to me they do not want main chain scaling
and that it is counter to their business interests.

I think that in order to establish that point about their "business interests", you need to prove that their objections to the solutions proposed to date are without merit. (I also wouldn't mind an explanation as to how Blockstream's business model works and why they are incentivized against increasing block size. I have done a moderate level of research, but I would like to hear from BIP101 supporters why they are so confident that there is a clear conflict of interest here.)

I don't think it is unreasonable that devs don't explicitly support one proposal or another at this point. I think these discussions need to be further fleshed out. The most responsible approach is to poke as many holes as you can in every proposal, and see if the result is robust enough to move forward. If you look at how this debate unfolded, it should be clear why devs aren't joining "Team BIP100" or "Team BIP102" or "Team BIP103." Doing so just results in more sectarian debate, which tends not to be about technical merit. Ie. this gets us nowhere.

The situation is not nearly as urgent as people are making it out to be. We won't be pushing the limit for a year or more, and even then, a temporary fee market is preferable to rolling out an update when there may be legitimate concerns about how it may adversely affect network security.

I think BIP102 is the most reasonable solution put forth thus far. I think any exponential scaling is dangerous (certainly when it is not warranted by real capacity needs), as it puts the protocol into untested conditions where new problems will surely arise. An incremental, gradual process is far superior, as it allows us to a) move forward with scaling without b) jeopardizing network security to unprecedented extent.

However, I don't consider myself to be on "Team BIP102" because I don't want to be biased against potentially better solutions that may arise, and I want to see more rigorous debate, with more emphasis on the technical issues of scaling. Less politics and accusations of nefarious intention, more discussion of technical merits.

Core is the problem, nothing else.

Core should clearly revise their priorities then. Their prioritizations are an obvious failure.

Like this.

I started another thread "is Greg Maxwell wrong about the blocksize" where I give my thoughts on his blocksize comments.

The conflict of interest, while relevant, isn't critical to showing a clear failure to act.  In other words, regardless of
their motives, the core team hasn't come to a consensus, despite some very reasonable proposals (BIP 102) and
in fact have argued nothing should be done until there is a backlog. 

While you may feel Gavin is on the deep end of the pool, Greg is certainly on the other extreme.

[poeEDgar]

In 12 months, average blocksize will be about 1mb on the current trajectory,
never mind spikes, unforseen circumstances, and the many months time
needed for consensus and rollout.

How long do you think we should wait?

As long as it takes to ensure that we are approaching network security responsibly. The idea of full blocks/fee market pales in comparison to the potential losses that will be incurred when exponential scaling causes unexpected threats to security.

If BIP101 supporters came around to a more responsible, incremental approach that is line with real transaction growth -- not transaction growth that they want to happen -- this issue would be a lot less controversial.

[jonald_fyookball]

If BIP101 supporters came around to a more responsible, incremental approach that is line with real transaction growth -- not transaction growth that they want to happen -- this issue would be a lot less controversial.

I agree with that statement... but as I have little to zero contact or influence with Gavin (although he might be reading this), there's not much I can personally do.

[adamstgBit]

If BIP101 supporters came around to a more responsible, incremental approach that is line with real transaction growth -- not transaction growth that they want to happen -- this issue would be a lot less controversial.

I agree with that statement... but as I have little to zero contact or influence with Gavin (although he might be reading this), there's not much I can personally do.

the miners too agree on a "approach that is line with real transaction growth"
https://www.blocktrail.com/BTC/pools
>60% hashing for BIP100

[poeEDgar]

In other words, regardless of
their motives, the core team hasn't come to a consensus, despite some very reasonable proposals (BIP 102) and
in fact have argued nothing should be done until there is a backlog. 

While you may feel Gavin is on the deep end of the pool, Greg is certainly on the other extreme.

Like I said earlier, doing nothing is preferable to jeopardizing security.

I'm also not convinced that waiting until there is a consistent backlog is necessarily wrong. That may have been Satoshi's intent when he said we can change the limit when we need to, in response to the suggestion in 2010 that the block size limit be removed.

I think we all know that this debate really began in earnest following the first stress test and the release of the XT client. Not much time has passed at all. Like I said, I'm not sure it's appropriate for devs to "pick a team" just yet. I think that may simply cause more devolution in this debate.

I have found Greg's approach to be pretty compelling, as he gives considerable forethought to the issues and potential issues that come with scaling. This is in contrast to Gavin's approach, which I believe boils down to this and little more:

I woulda thunk you were old enough to be confident that technology DOES improve. In fits and starts, but over the long term it definitely gets better.

Sure, technology gets better. That's not a very good basis to support the extent of scaling suggested in BIP101. And his cavalier attitude towards the potential problems that it may cause is a bit insulting.

[forevernoob]

Anyone know if Mike Hearn calls himself a libertarian?
I know Gavin does.

Not that it matters but it's interesting to me. Mike & Gavin are really pushing the regulatory agenda.

[jonald_fyookball]

Like I said earlier, doing nothing is preferable to jeopardizing security.

again, most people agree Bip102 doesn't jeopardize security , but the devs would rather do nothing.
Doing nothing until there is a crisis and then rushing an emergency fix seems more dangerous than going with a reasonable approach now and testing the hell out of it.  And this is preferable to jeopardizing adoption too.

[brg444]

Like I said earlier, doing nothing is preferable to jeopardizing security.

again, most people agree Bip102 doesn't jeopardize security , but the devs would rather do nothing.
Doing nothing until there is a crisis and then rushing an emergency fix seems more dangerous than going with a reasonable approach now and testing the hell out of it.  And this is preferable to jeopardizing adoption too.

If we have the opportunity to fork the network only once this is what we should aim for. There is still no hurry to adopt BIP102 or any proposals until every alternative has been worked through.

[poeEDgar]

Like I said earlier, doing nothing is preferable to jeopardizing security.

again, most people agree Bip102 doesn't jeopardize security , but the devs would rather do nothing.
Doing nothing until there is a crisis and then rushing an emergency fix seems more dangerous than going with a reasonable approach now and testing the hell out of it.  And this is preferable to jeopardizing adoption too.

I believe I have already addressed this. I agree that a simple doubling of the block size is unlikely to jeopardize security. But I'm not sure that it is wise for devs to force the debate at this point by throwing their weight behind this or that proposal, though. The urgency is overstated; if we are still at this impasse in 9 months or a year, I will agree with you, assuming we are actually pushing the 1MB block limit.

However, I don't consider myself to be on "Team BIP102" because I don't want to be biased against potentially better solutions that may arise, and I want to see more rigorous debate, with more emphasis on the technical issues of scaling. Less politics and accusations of nefarious intention, more discussion of technical merits.

[agath]

A Proposal for the Consensus Building Process:

1) All BIP's have equal weight in the voting process.

2)Miners vote with each newly mined Block.

3) BIPs are revised and amended according to argument and reservations submitted so that they are molded into the best possible versions that everyone is happy with.

4) Once 75% of blocks mined within the last 1000 blocks is in support of one BIP, an alert is sent out to everyone indicating that they should switch over to supporting this BIP.

5) Once 90% of blocks mined within the last 1000 blocks indicates support of the BIP the debate is over and the new BIP is implemented, all blocks that do not include the new BIP protocol changes are after that point rejected.


Historically the threshold has been 95% such as with BIP69, but I suggest lowering that to 90%. Agree? Disagree?

A few of us are working on creating an Open Letter to the Devs from The Bitcoin Community which will include this proposal. If you would like to help us shape this document PM me and I will send you a link to the Google Doc so you can help us write the letter.

What if someone implements a BIP that "establishes that consensus should be aknowledged with only 100 out of 1000 blocks", and this BIP gets >90% of the last blocks mined? :-)

[HostFat]

https://www.reddit.com/r/Bitcoin/comments/3j8rg1/an_open_letter_to_the_bitcoin_community_from_the/cuo15pt

I'd be happy if they come to some form of agreement at the second workshop. The website does not suggest that this will happen - the statement that absolutely no decisions are made at workshops (plural) seems definitive.
Still, it may be that whoever wrote the website FAQ isn't really representative of what the attendees will do or want. From the outside looking in, it doesn't seem like a great start. But perhaps things will happen anyway, despite the public statements of some of the attendees.
Regardless, the underlying problems remain. Gavin was having private discussions with some of the signers of this letter months ago, or trying to. So was I. Back in April I asked Wladimir privately what his proposed timeline was for a block size increase, and on that same thread Gavin proposed a one-time bump to 20mb with no further increases (as he'd tested that already). Wladimir didn't even bother replying to us.
Gavin also tried talking to Gregory Maxwell in private. So have I. He simply doesn't respond to our emails either.
There is just no way this project can be credible when key players are signing open letters saying they want some kind of amazing consensus building process .... and yet refuse to even reply to emails from developers who have been contributing to Bitcoin for longer than they have even been around.

[squatter]

https://www.reddit.com/r/Bitcoin/comments/3j8rg1/an_open_letter_to_the_bitcoin_community_from_the/cuo15pt

I'd be happy if they come to some form of agreement at the second workshop. The website does not suggest that this will happen - the statement that absolutely no decisions are made at workshops (plural) seems definitive.
Still, it may be that whoever wrote the website FAQ isn't really representative of what the attendees will do or want. From the outside looking in, it doesn't seem like a great start. But perhaps things will happen anyway, despite the public statements of some of the attendees.
Regardless, the underlying problems remain. Gavin was having private discussions with some of the signers of this letter months ago, or trying to. So was I. Back in April I asked Wladimir privately what his proposed timeline was for a block size increase, and on that same thread Gavin proposed a one-time bump to 20mb with no further increases (as he'd tested that already). Wladimir didn't even bother replying to us.
Gavin also tried talking to Gregory Maxwell in private. So have I. He simply doesn't respond to our emails either.
There is just no way this project can be credible when key players are signing open letters saying they want some kind of amazing consensus building process .... and yet refuse to even reply to emails from developers who have been contributing to Bitcoin for longer than they have even been around.

he is right as far as this: Wladimir and Gregory should have given them a courtesy response to the effect of, "no we are not implementing a 20x or a 8000x capacity increase. the small minority of developers that supports such drastic measures -- irrespective of real growth in transactions -- have shown no forethought as to why the drastic nature of these changes is necessary, nor have they accounted for the these various security related issues (x, y, z, ab, cd, ef, gh, etc) that may arise under such conditions"

[brg444]

on that same thread Gavin proposed a one-time bump to 20mb with no further increases (as he'd tested that already). Wladimir didn't even bother replying to us.

 

[brg444]

https://www.reddit.com/r/Bitcoin/comments/3j8rg1/an_open_letter_to_the_bitcoin_community_from_the/cuo15pt

I'd be happy if they come to some form of agreement at the second workshop. The website does not suggest that this will happen - the statement that absolutely no decisions are made at workshops (plural) seems definitive.
Still, it may be that whoever wrote the website FAQ isn't really representative of what the attendees will do or want. From the outside looking in, it doesn't seem like a great start. But perhaps things will happen anyway, despite the public statements of some of the attendees.
Regardless, the underlying problems remain. Gavin was having private discussions with some of the signers of this letter months ago, or trying to. So was I. Back in April I asked Wladimir privately what his proposed timeline was for a block size increase, and on that same thread Gavin proposed a one-time bump to 20mb with no further increases (as he'd tested that already). Wladimir didn't even bother replying to us.
Gavin also tried talking to Gregory Maxwell in private. So have I. He simply doesn't respond to our emails either.
There is just no way this project can be credible when key players are signing open letters saying they want some kind of amazing consensus building process .... and yet refuse to even reply to emails from developers who have been contributing to Bitcoin for longer than they have even been around.

he is right as far as this: Wladimir and Gregory should have given them a courtesy response to the effect of, "no we are not implementing a 20x or a 8000x capacity increase. the small minority of developers that supports such drastic measures -- irrespective of real growth in transactions -- have shown no forethought as to why the drastic nature of these changes is necessary, nor have they accounted for the these various security related issues (x, y, z, ab, cd, ef, gh, etc) that may arise under such conditions"

A simple "Gavin "tests" are broken and we pointed out to you why it is so" could've done the trick as well.

[BayAreaCoins]

on that same thread Gavin proposed a one-time bump to 20mb with no further increases (as he'd tested that already). Wladimir didn't even bother replying to us.

 

 

[brg444]

on that same thread Gavin proposed a one-time bump to 20mb with no further increases (as he'd tested that already). Wladimir didn't even bother replying to us.

 

 

There is nothing sensible about pushing for a 20mb increase under current circumstances, further increased planned or not.

[johnyj]

It's about how to reach a consensus on a complex topic

You don't need any vote for the validity of "1+1=2", you always reach 100% consensus. The reason you need to vote is because the topic is too complex that majority of participants can not grasp

However, if a topic is too difficult for majority to understand, then you have a complexity problem: The complexity make participants lose their decision making ability, thus they have to rely on political practice (to be more precise, dice casting) to make a decision

In such case, I guess simulation will be a better way to see into the future: Suppose that an airplane's crew member are all dead fighting terrorists, none of the survivors have ever flied an airplane, your best bet is to let the one who have played a lot of flight simulation to land the airplane

[meono]

It's about how to reach a consensus on a complex topic

You don't need any vote for the validity of "1+1=2", you always reach 100% consensus. The reason you need to vote is because the topic is too complex that majority of participants can not grasp

However, if a topic is too difficult for majority to understand, then you have a complexity problem: The complexity make participants lose their decision making ability, thus they have to rely on political practice (to be more precise, dice casting) to make a decision

In such case, I guess simulation will be a better way to see into the future: Suppose that an airplane's crew member are all dead fighting terrorists, none of the survivors have ever flied an airplane, your best bet is to let the one who have played a lot of flight simulation to land the airplane

Lol another dumb analogy again. Why do you keep embarrassing yourself? Can you just stop talking about things you dont understand?

[johnyj]

It's about how to reach a consensus on a complex topic

You don't need any vote for the validity of "1+1=2", you always reach 100% consensus. The reason you need to vote is because the topic is too complex that majority of participants can not grasp

However, if a topic is too difficult for majority to understand, then you have a complexity problem: The complexity make participants lose their decision making ability, thus they have to rely on political practice (to be more precise, dice casting) to make a decision

In such case, I guess simulation will be a better way to see into the future: Suppose that an airplane's crew member are all dead fighting terrorists, none of the survivors have ever flied an airplane, your best bet is to let the one who have played a lot of flight simulation to land the airplane

Lol another dumb analogy again. Why do you keep embarrassing yourself? Can you just stop talking about things you dont understand?

Lol another dumb sentence again. Why do you keep embarrassing yourself? Can you just stop talking about things you don't understand?

I throw your words back to you. You see, all your talk here are empty templates that can apply to anyone anything, does not make any sense

[tss]

https://www.reddit.com/r/Bitcoin/comments/3j8rg1/an_open_letter_to_the_bitcoin_community_from_the/cunzj9z

I wasn't asked to sign it. The first time I saw it was today.
Regardless, now I've read it, the letter contains a few statements I would have found it tough to agree with.
It refers to "the consensus building process". There is no such process. This point has been hammered home over and over again by now, but unfortunately, the Bitcoin Core developers seem to be in denial about it. Whenever we ask somebody to write down this process or tell us what it is, most of them go silent and Adam points to "BIP 1", which doesn't specify any decision making process or means for resolving disagreement. It suggests a continuation of the mentality that every decision has one clearly correct answer on which literally everyone can agree if only there is enough time spent talking. That's clearly not the case here.
I'm honestly not sure what else I can do at this point. The Core developers continue to insist that they have some deeply scientific, academic and professional decision making process. They just won't say what it is. They will say, though, "give it more time".
It says:

We ask the community to not prejudge and instead work collaboratively to reach the best outcome through the existing process and the supporting workshops
This sounds fantastic - there is an existing process and the workshops will support that process.

But this just continues to reflect confusion around what these workshops are actually intended to do. The website FAQ says:
https://scalingbitcoin.org/montreal2015/

Absolutely no decisions are made at workshops
There will probably be no debate

Additionally it says governance will not be discussed.
So we have a project that has no formal process (or even an informal one really), yet claims the workshops will help support that process, whilst simultaneously saying that the workshops won't involve any decision making or governance discussion.
I find this to be a rather inconsistent approach.
The final statement I'd disagree with is this one:

We believe this is the way forward and reinforces the existing review process that has served the Bitcoin development community (and Bitcoin in general) well to date

The process that served Bitcoin well to date was Satoshi being maintainer, and then Gavin. That was the case up until April of last year. Lots of people really don't like this idea because it sounds so fragile, but for most of Bitcoin's history technical disputes were resolved through Gavin making proposals, listening to feedback and then making a decision in reasonable amounts of time. Bitcoin was not being served by this non-existent fairy tale process that the existing Bitcoin Core guys want so badly to believe in.

Fuck Mike, fuck XT, fuck you and fuck Coinwallet.eu. (199.27.135.46)

i have been quiet for quite some time on this subject hating and stressing in my head. hard to keep up the fight against all of the fud being posted. it really takes the energy out of you.

you my friend hit the nail on the head. +21m

Fuck Mike, fuck XT, fuck you

edited for clarity

[tadakaluri]

Interestingly this is his last tweet:

I'm getting a few mistaken follows due to sharing a name with a Bitcoin dev. I like Bitcoin, I wrote about it once, I don't develop for it.

[brg444]

Interestingly this is his last tweet:

I'm getting a few mistaken follows due to sharing a name with a Bitcoin dev. I like Bitcoin, I wrote about it once, I don't develop for it.

Well that's obviously cause it is indeed not the right guy 

This is Mike's twitter account https://twitter.com/OctSkyward

[Kakmakr]

Gavin said something that is very true. You cannot fall back on a system where a benevolent dictator makes all the final decisions, like it was done when he was still the Lead maintainer, as he called it. Why? Because that person can get run down by a truck as he put it and you will have a leadership void. 

I just know one thing, the status quo is not working and needs to be improved. If workshops is the answer for this, then we have to explore it, before we wipe it off the table as a possible solution. That is one way of doing it, and we need to explore it.

The workshop at least give more that 5 people a opportunity to state their case and to raise their concerns. ^hmf^