Gold collapsing. Bitcoin UP.

[solex]

We are nearly 10 years into the Bitcoin saga and there has been so much water under the bridge that sometimes people forget the context for decisions and events which have taken us to where we are now.

Regarding the BU members rejecting CTOR, in a non-binding BUIP, they also gave a reasonable majority support for DSV. Both are disliked by nChain, though CTOR was on their website for a while earlier this year. It is fine for people to change their minds, but in a decentralized community, just because one mind is changed does not mean everyone else's does as well.

It is not possible to cherry-pick changes and expect to stay on the majority PoW chain. If BU was to try and forge a new fork which had DSV but no CTOR then we would rightly be a laughing stock in the history books for going off on such a tangent. As an org we need to be pragmatic and accept compromise, accept the good with the bad, and just move on. That is exactly the road which is being taken.

The Bitcoin XT developers argued for a "no change" event on 15 November and this was discussed at a number of developer meetings. All of ABC, BU and nChain wanted changes (in order to keep improving BCH quickly to grab market-share, but in different ways), so XT did not succeed with that argument. As it happened, on 31 August at Bangkok, nChain did propose a "no Change" for 15 November as part of a holding pattern, with the view of having an upgrade about 15 February 2019 instead. The idea of effectively postponing the upgrade did not receive much support from the the other miners and developers present,

Regarding the BitPay adaptive block limit algorithm. It's potential was appreciated early on and it was approved in BUIP002, nearly 3 long years ago! Instead BU forged ahead with emergent consensus (EC) because so many big-blockers wanted to hand full control of the block limit to the miners. As it turned out, we would have been better off with an adaptive limit, like BitPay, or BIP100, as this would have been more likely to secure majority mining support, even though that still had a developer determined algorithm. Oh, the benefits of 20/20 hindsight.

-------
edit: To be clear, the rolling 6-month general upgrade cycle is intended to allow BCH to advance changes quickly, to improve rapidly. Consensus on that approach has faded, so the alternative of BIP135 miner voting is now being advanced via BUIP098 and this fits with the XT model for upgrades.

 

[chriswilmer]

The thing about social engineering is that we're not well adapted to it. The virtue/moral of judging an idea by its merit, not the person who proposes it, is something that can be gamed. Someone (i.e., Craig), can propose a thousand bad ideas, and if every time you insist on judging the idea by its merit... something will slip through, we can't be perfect judges 100% of the time. It's like a Sybil-attack, but with a barrage of ideas/proposals rather than fake identities. The rational defense is to ignore someone after recognizing that they are a bad actor.

 

[Zarathustra]

@chriswilmer

> The rational defense is to ignore someone after recognizing that they are a bad actor

You don't ignore CSW. You are obsessed with him and this obsession determines your decision to prefer the bad code and the miners who are mainly mining the censored shit-project. The enemy of your enemy becomes your friend, and you follow him.

 

[Zarathustra]

i'm surprised this alternative hasn't been discussed more. assume for a moment that's what happens; then come May.

That's exactly our problem. We don't fight for our position. We became followers of an intransparently funded ABC agenda because we are obsessed with CSW.

 

[Christoph Bergmann]

Regarding the BU members rejecting CTOR, in a non-binding BUIP, they also gave a reasonable majority support for DSV. Both are disliked by nChain, though CTOR was on their website for a while earlier this year. It is fine for people to change their minds, but in a decentralized community, just because one mind is changed does not mean everyone else's does as well.

So, the ballot about CTOR was just a funny joke?

@Zarathustra

Exactly. Since days all what I say regarding the fork is answered with "but but but evil bad CSW did / said ..."

 

[Jonathan Vaage]

Bitcoin Unlimited Cash Edition v1.5.0.1 with optional SV support appears to have been released according to recent github activity.

Pending release notes:
https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/34324c9149696c760a9bb535d84a52809b6ce662/doc/release-notes-bucash.md

 

[BldSwtTrs]

 

[satoshis_sockpuppet]

prefer the bad code

Why is it bad code?

So, the ballot about CTOR was just a funny joke?

The way I see it: BU tried to get CTOR removed from the HF change set because of the ballot and the opinion of the BU devs. They didn't succeed with that, apparently also because miners advocated for ABC's HF plan.

Should BU release a client that has absolutely no chance of being used?

Miners and businesses advocated for ABC's HF plan. BU developed a client that is compatible to that.

In good faith BU also developed a client compatible to SV..(which imho is unnecessary because SV is just an empty threat by a scammer but you should be happy with this client.)

I distrust deadalnix, I don't like the way ABC acts and I don't see a reason for CTOR (but I am not too informed about that). But imho the HF plan of ABC is a compromise one can live with happily.
BCH is still on it's way to global adoption and neither deadalnix nor CSW will stop it.

 

[Zarathustra]

Hardly anyone has so much reverence for The Great Idol as Vin Armani.

"To Craig Wright: [...] I never questioned your intelligence [...] you're one of, if not the smartest person in bitcoin. Satoshi created a system whose expressed purpose was to prevent anyone party from taking it over. You found a way to do just that."

I love him who chastens his God, because he loves his God: for he must perish through the wrath of his God. Thus spake Zarathustra.

 

[Christoph Bergmann]

The way I see it: BU tried to get CTOR removed from the HF change set because of the ballot and the opinion of the BU devs. They didn't succeed with that, apparently also because miners advocated for ABC's HF plan.

Could be an explanation. I wonder what miner you mean - BCH or BTC miners

Should BU release a client that has absolutely no chance of being used?

Why not? If people want ABC, they can use ABC. BU is for giving users a choice. When did we stop believing into emergent consensus instead of developer-decided pre-consensus?

Miners and businesses advocated for ABC's HF plan. BU developed a client that is compatible to that.

I did not hear from a business or a miner that actively desires CTOR. Maybe Bitmain, but even here nothing official. Maybe I just missed, but usually I get my news.

I distrust deadalnix, I don't like the way ABC acts and I don't see a reason for CTOR (but I am not too informed about that). But imho the HF plan of ABC is a compromise one can live with happily.
BCH is still on it's way to global adoption and neither deadalnix nor CSW will stop it.

I don't think doing CTOR under these circumstances is a good compromise when you see "being free from centralized developer control" as a central value property of BCH.

 

[satoshis_sockpuppet]

Could be an explanation. I wonder what miner you mean - BCH or BTC miners

Well, these aren't two distinctive sets.

Why not? If people want ABC, they can use ABC. BU is for giving users a choice. When did we stop believing into emergent consensus instead of developer-decided pre-consensus?

a) I do not think, that EC is a characteristic feature of BU.
b) Can you link me to the BUIP discussion that in your view is contradicting to current BU releases?

I did not hear from a business or a miner that actively desires CTOR. Maybe Bitmain, but even here nothing official. Maybe I just missed, but usually I get my news.

Well, not CTOR especially, but the HF ABC proposed. And afaik ABC is sponsored by miners.

I don't think doing CTOR under these circumstances is a good compromise when you see "being free from centralized developer control" as a central value property of BCH.

I think you have a good instinct about ABC and deadalnix's desire to be the dictator of BCH. And I think I'd agree with you, that ABC is trying to force their will onto the BCH community which is a problem and might become a bigger problem later. But for now I think the first priority should be to have a clean fork on the 15th. And I think, that CTOR is a relatively small pill to swallow. I do not see real huge disagreements about BCH's future plan between BU/ABC/XT and even SV. So imho we have a very different situation to the core/btc disaster. And also, I see miners being confident and having the last say on BCH (why else would CSW have to buy so much HP?).

So, I do agree, that ABC is a problem and that deadalnix and his followers are a pain the ass. But imho that should be dealt with after the 15th.

 

[Norway]

We are nearly 10 years into the Bitcoin saga and there has been so much water under the bridge that sometimes people forget the context for decisions and events which have taken us to where we are now.

Regarding the BU members rejecting CTOR, in a non-binding BUIP, they also gave a reasonable majority support for DSV. Both are disliked by nChain, though CTOR was on their website for a while earlier this year. It is fine for people to change their minds, but in a decentralized community, just because one mind is changed does not mean everyone else's does as well.

It is not possible to cherry-pick changes and expect to stay on the majority PoW chain. If BU was to try and forge a new fork which had DSV but no CTOR then we would rightly be a laughing stock in the history books for going off on such a tangent. As an org we need to be pragmatic and accept compromise, accept the good with the bad, and just move on. That is exactly the road which is being taken.

The Bitcoin XT developers argued for a "no change" event on 15 November and this was discussed at a number of developer meetings. All of ABC, BU and nChain wanted changes (in order to keep improving BCH quickly to grab market-share, but in different ways), so XT did not succeed with that argument. As it happened, on 31 August at Bangkok, nChain did propose a "no Change" for 15 November as part of a holding pattern, with the view of having an upgrade about 15 February 2019 instead. The idea of effectively postponing the upgrade did not receive much support from the the other miners and developers present,

Regarding the BitPay adaptive block limit algorithm. It's potential was appreciated early on and it was approved in BUIP002, nearly 3 long years ago! Instead BU forged ahead with emergent consensus (EC) because so many big-blockers wanted to hand full control of the block limit to the miners. As it turned out, we would have been better off with an adaptive limit, like BitPay, or BIP100, as this would have been more likely to secure majority mining support, even though that still had a developer determined algorithm. Oh, the benefits of 20/20 hindsight.

-------
edit: To be clear, the rolling 6-month general upgrade cycle is intended to allow BCH to advance changes quickly, to improve rapidly. Consensus on that approach has faded, so the alternative of BIP135 miner voting is now being advanced via BUIP098 and this fits with the XT model for upgrades.

Great post, @solex. We need to be reminded of the history in this tornado of developing events.

I have changed my view since the happy fork in may. I think the core issue is what could be called developer consensus. This is the idea that developers from different clients come together, (sometimes with miners and other participants in the ecosystem), talk sensible and logical and find the right path for the protocol forward together.

I now think this is a pipe dream, undermining progress for the real bitcoin with all the uncertainty and threats of chain splits it brings.

The goal should not be to get developer consensus because it's a losing strategy. The goal should be to freeze the protocol as soon as possible and get rid of the max blocksize cap and other restrictions in the protocol and create stability.

We should not protect the weakest pools from competition. They are only holding everything back, and we need to grow fast. (A lot faster than @imaginary_username's scheme).

Poison blocks are overrated as a threat to the honeybadger. It's the fear of poison blocks and death of pools/businesses that can't keep up with infrastructure that has held bitcoin back the last five years.

 

[sickpig]

Bitcoin Unlimited Cash Edition v1.5.0.1 with optional SV support appears to have been released according to recent github activity.

Pending release notes:
https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/34324c9149696c760a9bb535d84a52809b6ce662/doc/release-notes-bucash.md

fwiw we are currently building the deterministic binaries. a last minute problem to get them built on macos have delayed the release process., but I'm sure we will be able to release tomorrow.

@Jonathan Vaage thanks for the URL fix

 

[Richy_T]

Bitcoin's Manifest Destiny is only apparent to those who understand the peculiarities of complex systems,

I'm not even sure it can be understood. It's more of a comprehension. I think if you attempt to understand it, you get too close and lose the bigger picture.

 

[majamalu]

@Richy_T You've understood.

Liquidity can not be designed by an engineer, for the same reason that prosperity can not be designed by an economist. The liquidity of a currency and the prosperity of a society are emergent phenomena of an extended order; a central authority can promote, discourage or punish them, but never create them.

 

[throwaway]

we need to grow fast. (A lot faster than @imaginary_username's scheme).

Are you talking about this scheme?
https://github.com/bitcoincashorg/bitcoincash.org/blob/5f087230d2d2aafa0490fe6cf58c807f8d8c31ba/spec/bip-adaptiveblocksize.mediawiki

(Up to) 10x every 45 days is plenty fast!

 

[Norway]

@throwaway
Yes, that's the scheme I'm talking about. Don't expect organic use to not have spikes.

The scheme is removing the freedom to set your own max blocksize built into ABC, BU and SV. It's a step backwards to subsidize weak pools and businesses.

 

[Epilido]

I wonder if all this bought hash power that CSW seems to be renting, they might not give him access to it just before the fork. Oops here were working on your refund please stand by ....

Gives a false sense of the power you have and removes a large amount of your cash at a very delicate time.

 

[cypherdoc]

fwiw we are currently building the deterministic binaries. a last minute problem to get them built on macos have delayed the release process., but I'm sure we will be able to release tomorrow.

@Jonathan Vaage thanks for the URL fix

great job you guys. this was the right thing to do.

 

[throwaway]

@Norway
While I do think that it would be ideal to allow everyone to choose their own limits, convincing everyone that such freedom is a good idea seems to be impossible.

Having something in the code that allows the limit to grow indefinitely (assuming that unnecessary 10TB ceiling is removed) without having to argue about it ever again is for me the next best thing.

I definitely expect usage spikes, but >10x spikes? I'm not sure.