Gold collapsing. Bitcoin UP.

[jonny1000]

Can I just draw your attention to this: I support competing compatible clients is not the same as: I support viable competing clients.

I never said they were the same. Your point that I am somehow against competition is false. I support competing compatible clients. I only support incompatible clients if there is strong consensus across the entire community for the change.

 

[pekatete]

I know you never said that, and what you are effectively saying is that you ONLY support un-viable compatible competing clients (i.e excluding BU, XT and Classic), you are just not bold enough to spell it out.

 

[jonny1000]

BU is compatible with both Core and Classic

That is false. For example if a 3MB block is made and gets 10 confs, BU will be on a different chain to Classic.

I am fine with BU, if the default is set to 1MB and n= infinity. In exactly the same way I would be ok with a client with the default block reward schedule but a setting that allowed users to increase the value. This is the same as Core, users can increase the block reward to 50btc forever if they like. Just putting that option in the GUI makes no difference to me. There should be warnings to the users.

 

[freetrader]

I only support incompatible clients if there is strong consensus across the entire community for the change.

Doesn't this only mean that you'll be among the last 5% over the finish line?

 

[jonny1000]

"what you are effectively saying is that you ONLY support un-viable compatible competing clients"

Sorry, I have no idea what you mean. I do support viable competing compatible ones and unviable ones for that matter.
[doublepost=1465675042][/doublepost]

Doesn't this only mean that you'll be among the last 5% over the finish line?

No

 

[Peter R]

That is false. For example if a 3MB block is made and gets 10 confs, BU will be on a different chain to Classic.

If a 3MB block got 10 confirmation AND became the longest chain it would mean that there was widespread support for 3 MB blocks (excluding the 51% attack scenario which always exists). Classic nodes would have increased their block size limits by that time so they will be on the same chain. Non-upgraded nodes will just stop seeing blocks and know that something is wrong.

Is it that hard to understand that nodes have an incentive to stay on the same chain?

I am fine with BU, if the default is set to 1MB and n= infinity. In exactly the same way I would be ok with a client with the default block reward schedule but a setting that allowed users to increase the value. This is the same as Core, users can increase the block reward to 50btc forever if they like. Just putting that option in the GUI makes no difference to me. There should be warnings to the users.

It would be great if Core added an option in the GUI for users to increase their block size limits. I'm sure this debate would be over in no time then. Which is also why they won't.

 

[jonny1000]

If a 3MB block got 10 confirmation AND became the longest chain it would mean that there was widespread support for 3 MB blocks (excluding the 51% attack scenario which always exists). Classic nodes would have increased their block size limits by that time so they will be on the same chain

Well yes, if you mean by compatible that the user closes the existing program and then downloads and installs a new version of the software, then everything is compatible and the word compatible has no meaning.

It would be great if Core added an option in the GUI for users to increase their block size limits. I'm sure this debate would be over in no time then. Which is also why they won't.

This is the situiation we are in now, its just that Core users need to change a number and recompile. If there were a setting in the GUI, I would be arguing with just as much vigor that users should not change that setting without strong consensus across the entire community. I would say 95% of miners should signal support for changing the setting before users actually change it. We would be in exactly the same situation as we are in now and you would be just as frustrated.

 

[pekatete]

"what you are effectively saying is that you ONLY support un-viable compatible competing clients"

Sorry, I have no idea what you mean. I do support viable competing compatible ones and unviable ones for that matter.

Of-course you have no idea what I mean, you are forgiven for playing dumb for the lurkers (if only you got into the habit of responding to direct questions with clarity, that'd help to streamline your pedantic nature!).

But now that you've expressly excluded BU and Classic (from my list of viable clients), that leaves only XT (ahem!). If I missed out any other competing client(s) you believe is / are viable, feel free to list them here.

 

[cypherdoc]

"The team "in power" is decided by compatible software people choose to run."-@jonny1000

That we know is made exceedingly difficult, if not impossible, by Kore gang using SF's to track through critical changes to code that users, full nodes, and miners have to take our leave else leave the system entirely. That has alot of old timers rightly pissed off.

And i've already told you that we've heard the fear expressed by guys like lombrozzo and Todd about losing power. Can't you hear?

 

[Peter R]

"Well yes, if you mean by compatible that the user closes the existing program and then downloads and installs a new version of the software, then everything is compatible and the word compatible has no meaning." -- @jonny1000

No, this is not what I mean. For example, if the network were attacked and a chain that contained transactions that created millions of coins out of thin air were mined then users would not "download and install a new version of the software" to be compatible.

It seems you view Bitcoin purely as software. When you draw the system boundary for Bitcoin, it encloses only the software running on the 5000 or so nodes across the globe. When I draw the system boundary for Bitcoin, it encloses you and I, everyone in this thread, as well as millions of other people as well.

To understand how the system might actually behave, it is not enough to naively extrapolate what the rules currently encoded into some piece of software would do at some point in the future. You must also take into account how the people might change the software they use. Doing otherwise misses the very essence of Nakamoto consensus.

 

[cypherdoc]

Man, you're dense. Consensus isn't possible given the events of the last year and the degree which kore dev revealed themselves. And, btw, you keep declaring victory so why don't you release the 2MBHF yourselves since you feel everyone is on your side?or maybe you really don't feel that way .

"You're advocating (more like begging) those who support a limit increase to stop supporting it until such time as the Core centralized authority says it's acceptable."

You can still support a block size limit increase. I support it now and always have done. I am asking you to stop supporting the activation of the increase on the network until there is consensus across the entire community.

 

[AdrianX]

I would be arguing with just as much vigor that users should not change that setting without strong consensus across the entire community. I would say 95% of miners should signal support for changing the setting before users actually change it. We would be in exactly the same situation as we are in now and you would be just as frustrated.

In other works you'll be advocating for political consensus. And once you had 95% political consensus you'll be OK going from no quantifiable support to 95% quantifiable support.

Good news for us is what's said is not reality but what actually is recorded on the blockchain is.

Classic is nothing more than a 100% compatible Bitcoin client and a practical vote for bigger blocks.

Please go release a 95% consensus version of Core for a 2MB hard fork and I'll vote for it too.

But stop stalling real support and asking for political support.

 

[cypherdoc]

Like I said. I'm beginning to think the best way to do this is release the 2MBHF without an activation threshold to avoid the oppressive politics that go into undermining any ideas/signaling contrary to kore and to allow 51% of miners to kick off a larger block chain without permission from kore dev and if they understand that the community in aggregate is with them. The economics and game theory suggest that this new HF should win.

This is false. Please stop misrepresenting our position. Read my view below in black and white:

I support competing compatible clients

Was that clear enough for you?
[doublepost=1465673127][/doublepost]

The 1MB limit rule was a softfork imposed on the network. At some point removing this becomes a hardfork. We can discuss the techicaliites of this if you want. Was it before the majorty of nodes adopted the rule? 1 block after the rule became active? 2 blocks after the rule became active? 6 blocks after the rule became active? I do not know, but what is clear is several years later, the 1MB rule is adopted by the network and removing now is a hardfork.
[doublepost=1465673368][/doublepost]

That is fine, you are unlikey to get any significant support. In the event that your hardfork has no mechanism or deisre to ensure activation occus with strong consensus and your fork gets significant support, that should cause the community to rally behind the exisiting rules. That should not be a problem because:

1. Support will eventually fall to insignifant levels and then we can do a HF, or
2. If support remains significant, the consensus rules will not be eliminated, but Bitcoin remains flexible since we can do almost anything with softforks

 

[jonny1000]

Of-course you have no idea what I mean, you are forgiven for playing dumb for the lurkers (if only you got into the habit of responding to direct questions with clarity, that'd help to streamline your pedantic nature!).

But now that you've expressly excluded BU and Classic (from my list of viable clients), that leaves only XT (ahem!). If I missed out any other competing client(s) you believe is / are viable, feel free to list them here.

XT, Classic and BU are all deliberately incompatible with the existing rules. This is a fact not an opinion. I still support competing compatible clients.
[doublepost=1465678848][/doublepost]

To understand how the system might actually behave, it is not enough to naively extrapolate what the rules currently encoded into some piece of software would do at some point in the future. You must also take into account how the people might change the software they use. Doing otherwise misses the very essence of Nakamoto consensus.

Yes. But The software code of BU and Classic are incompatible. People could chose to do anything. Just because I state a fact that two software versions are incompatible does not mean I am assuming anything about human behaviour. If you define compatibility that way it has no meaning.
[doublepost=1465679027][/doublepost]

Please go release a 95% consensus version of Core for a 2MB hard fork and I'll vote for it too

5 devs already committed to do this. It is very likely to get support as long as there are no significant threats, attacks or pressure to do it. It looks like Classic support is now approaching insignificant levels so we should be fine.

 

[Zarathustra]

"XT, Classic and BU are all deliberately incompatible with the existing rules."

No, Kore is incompatible with the rules. Full blocks are against one of the most important rules.

 

[cypherdoc]

Details details
[doublepost=1465687451][/doublepost]Boom

 

[theZerg]

I came here specifically to read cypherdoc say boom and was not disappointed!

 

[cypherdoc]

I'll be honest.

I don't think @rocks made the right decision.

 

[theZerg]

What? did he sell?

 

[dwaltrip]

Hot damn. Above 600. Looks like bitcoin has some fight in it yet.