Gold collapsing. Bitcoin UP.

[Mengerian]

The question to ask is would you still vote in favor of a dumb idea if you realized you're the one paying the ultimate price, not some poor shlub.

If implementing BUIP 101 were harmful to BU, surely Andrew Stone and the other BU devs would be a able to make that assessment. I think that was part of Amaury's point: That voting on technical decisions like this doesn't make sense.

@deadalnix motivation here is in some sense akin to someone trying to slip a bug into someones code base for the sake of proving that a particular review process is lacking.

I don't think that's similar at all. In this case everything is out in the open, and Amaury made the technical argument of why he thought it was harmful. Nothing was hidden, and he wasn't trying to trick anyone, so it's completely different from slipping in a secret bug. Surely if BUIP101 were a harmful change the BU devs would be able to make that assessment also? Or do you assume Amaury is uniquely qualified to detect what is harmful to BU?

I find it surprising that you defend this.

I mean, I still disagree with Amaury for voting that way. But I see it more as an ineffective way for him to communicate his message (obvious from this discussion that his point is completely lost in the drama), not something that's malicious or intentionally harmful, and not deserving of getting kicked out of BU.

 

[Peter R]

So the analogy would be you propose a bunch of people vote on whether Amaury should punch himself in the face. Then they all debate it, some people say "it will be good, it will toughen him up", others say "no, this is a bad idea, it will hurt him"..

Then, someone comes along and says "This whole thing is a bad idea, but to point out how dumb this is, I'm voting for it".

Now who do you blame? Do you blame the people arguing that Amaury should punch himself? Do you blame Amaury for putting himself in an awkward position where he has to either punch himself or not honor his commitment to follow the vote? Or do you blame the guy who said "this whole thing was a dumb situation" but voted for it?

If someone think BU's governance model is "dumb" -- if they think it is dumb that we come to decisions by members voting -- then I'd rather them not vote at all (or abstain if they don't want their membership to expire). But why would such a person even want to be a member, if that's the case?

I think your analogy would make more sense if BU was not voluntary, but was instead the process used by all of BCH. Then I think you could make a good case for intentionally undermining the governance system by trying to make a mockery of it, as an attempt to change the system. But BU is voluntary. If someone thinks it's dumb, there is no need for them to be involved at all.

 

[Mengerian]

@Peter R To be clear, I'm not sure that Amaury was saying that BU's governance process is "dumb" in a general sense. I'm actually not exactly sure what he saying specifically with the vote. I just made up the analogy from Zarathustra's example as something that, to me, seemed closer to the actual situation.

I also don't want to really defend Amaury, I actually disagree with his vote. I just think the criticisms don't really add up.

But getting back to BU's governance process, let's get more specific. If the Lead Developer felt that BUIP 101 were dangerous, would he be obliged to implement it in BU's "official" release? It seems like the criticisms of Amaury's vote assume that this is the case. If that is the governance rule, it does seem like it could be a problem.

 

[Mengerian]

Thinking a bit more about Amaury vote, the way I interpret it he's saying: "I don't think this is a great idea, but if you guys think it's a good idea I think you should try it out".

That doesn't seem too terrible to me.

 

[solex]

Agreed @Mengerian

I consider the BU voting system to be extremely robust and working well. I also take its smooth operation very seriously. People are voting according to their opinion and that is all which can asked of them. A few votes may be questioned, especially after off-the-cuff remarks we have seen quoted. However, BUIPs are passed by a majority, so any individual vote is rarely material to the result. If it is material, then it is the will of many other BU members as well.

With regard to BUIP101, there was never going to be an instant effect. One massive hurdle, which @theZerg pointed out, was the accompanying test results which include the necessary 10TB blocks. Someone, please do the math for propagation times considering that 1GB blocks on the GTI took 10 minutes to propagate. We are talking about a block size ten thousand times larger than the GTI result, millions of times larger than current txn demand.

If this BUIP passed then likely there would have been a further BUIP raised to restore the default EB*. If that didn't pass, well, it would mean a scramble to come up with some other proposal, likely in co-ordination with ABC and XT, some form of BIP100. There is always a way to move forward.

Keeping perspective, we are 1 month away from a major event in the life of Bitcoin Cash, which could be a non-event, or a clusterfork of historic proportions which will have BlockstreamCore quaffing crates of "champaign" and hooting with laughter in an early Christmas & New year party. The priority is helping BU development make BUIP098 a success so it goes some way to mitigating the potential forking risks of 15 November.

* a default millions of times above current usage is no longer an effective default

 

[Christoph Bergmann]

Thinking a bit more about Amaury vote, the way I interpret it he's saying: "I don't think this is a great idea, but if you guys think it's a good idea I think you should try it out".

That doesn't seem too terrible to me.

He explicitly mentioned a bug and a damage. If he thounght "if you want it, try it", he should have just revoked his membership, because this is what voting members should not think. They have the duty to vote against something they consider dangerous.

But he didn't. Instead he voted in a way that faciliated what he thinks is a damage. This is not just "not caring" but clearly and beyond any doubt sabotaging. In best case sabotaging of BU's voting system, in worst case sabotaging of BU, the software and client.

I really don't understand why you try everything to defend them. It is obviously hostile and against BU rules.

@solex

Keeping perspective, we are 1 month away from a major event in the life of Bitcoin Cash, which could be a non-event, or a clusterfork of historic proportions which will have BlockstreamCore quaffing crates of "champaign" and hooting with laughter in an early Christmas & New year party.

Seems like a depressing choice between a "non-event" and a "clusterfuck"; a good arguemt against hardforking.

Imho you miss the third option: Celebrating independence of Bitcoin Cash by resisting an urge for unneeded und unwanted change which seems to have the support of a major hashpower.

 

[lunar]

If you're not reading Craigs daily Medium posts, you're missing out some outstanding signal.

this from today:

https://medium.com/@craig_10243/bitcoin-a-total-turing-machine-5a6c3c68f5a7
and full paper. (draft) https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3265146

Quite frankly, anyone still repeating the Core narrative that this guy is a technobabble fake, needs a reality check.

The implications of this paper will ripple out for decades.

https://coingeek.com/app/uploads/2018/03/SSRN-id3147440.pdf - Beyond Gödel

 

[bitsko]

Should I be ejected from the Unlimited party for considering it to be a testing bed of ideas as opposed to seeking for it to become the dominant monolithic implementation for the BCH network?

Am I allowed to have a different vision for BU and vote in that fashion, despite my view not being aligned with a certain portion of the voting body?

Node voting and node vote politics strike me as inherently geared to catering to certain perspectives given the philosophical prerequisites for buying into such a democratic structure. Is it then an attack for me to color my votes with such an understanding?

Even with greater philosophical differences is it odd for an individual to seek voice where a place is made to do so?

This looks like a petty witchhunt and reminds me of the last time cbergmann got all excited and demanded things on the internet.

free @deadalnix
free @micropresident
long live the left wing of bitcoin
node power to the people

 

[Richy_T]

BU is not some shitty nations-state type universal suffrage where anyone can vote for any reason including whether they like the color of the candidate's shoes. BU has a curated membership and votes are supposed to be cast in a manner which advances the BU software. "I'm not sure a about this but I think we should try it to see" is quite different from "This is going to fuck your shit up but you idiots need to learn a lesson". From what he wrote, I find it hard to see how people can confuse these two intentions.

I'm not saying Amaury should be kicked off but I do think this attitude is cause for concern and is the latest in a long line of questionable behavior. And it's not just him either. It seems we have a number of people who will do things that should raise eyebrows and there will be those who will fervently defend them.

I also don't think accusing people with genuine concerns with participating in a "witch-hunt" is helpful either. This modern practice of turning attacks up to 110% on people who disagree with you makes it hard to find common ground.

 

[Christoph Bergmann]

Should I be ejected from the Unlimited party for considering it to be a testing bed of ideas as opposed to seeking for it to become the dominant monolithic implementation for the BCH network?

Am I allowed to have a different vision for BU and vote in that fashion, despite my view not being aligned with a certain portion of the voting body?

If your vision for BU is to be a client to test bugs, yes. This is not what you signed up for when becoming a member. Either stay with what you signed, or get out.

You can do and think what you want. I don't care. But BU is not your mother. If you just vote to vandalize, you should be kicked out.

 

[freetrader]

If implementing BUIP 101 were harmful to BU, surely Andrew Stone and the other BU devs would be a able to make that assessment. I think that was part of Amaury's point: That voting on technical decisions like this doesn't make sense.

A reading of the Articles suggests that BU voting does cover voting on technical issues to do with the evolution of the software. If one thinks this doesn't make sense, one should either

a) submit a BUIP to amend the Articles
b) abstain from voting on BUIPs which relate to software changes
c) recuse oneself completely from BU membership if one thinks that others being able to vote on technical issues constitutes a severe flaw in the project, and one is not able to convince the rest of the membership of the merits of that idea
[doublepost=1539365883,1539365119][/doublepost]

If you're not reading Craigs daily Medium posts, you're missing out some outstanding signal.

this from today:

https://medium.com/@craig_10243/bitcoin-a-total-turing-machine-5a6c3c68f5a7
and full paper. (draft) https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3265146

Quite frankly, anyone still repeating the Core narrative that this guy is a technobabble fake, needs a reality check.

The implications of this paper will ripple out for decades.

https://coingeek.com/app/uploads/2018/03/SSRN-id3147440.pdf - Beyond Gödel

I should probably not feed the trolls, but "SSRN does not provide peer review for papers in the eLibrary."

Have either of these papers been published in a peer reviewed journal?
Where can one find the evidence?

 

[Norway]

With regard to BUIP101, there was never going to be an instant effect. One massive hurdle, which @theZerg pointed out, was the accompanying test results which include the necessary 10TB blocks. Someone, please do the math for propagation times considering that 1GB blocks on the GTI took 10 minutes to propagate. We are talking about a block size ten thousand times larger than the GTI result, millions of times larger than current txn demand.

If this BUIP passed then likely there would have been a further BUIP raised to restore the default EB*. If that didn't pass, well, it would mean a scramble to come up with some other proposal, likely in co-ordination with ABC and XT, some form of BIP100. There is always a way to move forward.

The demand for tests of 10 TB blocks show that neither @solex nor @theZerg understood BUIP 101. It's almost like you didn't read my article "10 terabyte: Is it too big?".

@torusJKL said he may raise a proposal where the default is "no limit". By the same logic, this proposal will be blocked because there is not enough energy in the universe to test blocks of infinite size.

"No limit" is not a crazy idea. I have repeatedly quoted Gavin Andresen on this subject. Both ABC and SV have it on their roadmaps. ABC doesn't give a timeframe for this, while SV put forward the date May 2020.

I'm a little disappointed that some of you planned to block a majority vote with misguided demands. I hope you will not do this if a "no limit" default gets a majority vote.

 

[solex]

@Norway, BUIP101 got a fair hearing. Please re-read the thread. You got masses of feedback but made no modification to reflect any of it. Expecting a change to be testable is not blocking it.

You keep quoting Gavin, but refuse to accept that BU has done, THREE years ago!, what Gavin asked for, which is, for practical purposes, removing the block size hard limit. This is done because BU has 4-byte variable and permits up to 2147MB, way beyond projected demand for many years. EB is a soft limit like Core's 750KB, which Gavin agreed with them to leave alone, way back in 2013.

Any BU user today can set their AD to zero and the effect of EB vanishes. The EB default is not holding the miners back. You want to remove a "technocratic" developer default. Well, for the benefit of readers here, who are not on slack, I paste the following info I wrote:

solex 8:23 AM
@Norway, My view is that the merit of BUIP101 is changing block limit variables from 4 to 8 bytes, but raising the EB beyond network capacity only makes the BU software less attractive to miners.
http://ivalue.cash/BKK-DAY1-EnglishOnly-Aug30-2018.mp3
Chief execs of almost all the BCH mining orgs were present at Bangkok.
Please go to 1:54:00 and listen to the miner's replies when I ask them about lifting the 8MB soft limit used for block generation. The translated reply at 1:56 is illuminating. The miners are conservative and want developers to advise them on limits. The default EB level is such advice about the maximum to accept.

Apart from bitcoin.com who can cope with living on the ragged edge, all the other miners are very conservative. What makes you think the BCH miners have to man-up, grow a pair, and do without the developer advice of an EB default?

"no limit" is just words. We are talking about software, where variables have to be defined. That is why I asked you about the 8-byte datatype. I have always been sympathetic to that proposal because of ossification risk, however, other people here have raised doubts about any imminent ossification in BCH.

Now that the BU membership has decided not to progress BUIP101, I ask that if you still want this change then take it to Bitcoin ABC and Bitcoin SV and ask them to develop and apply the patch. ABC should give you a good hearing, based on the voting. After this is successful then it would be a good time for @torusJKL to bring forward an appropriately revised BUIP102 so BU can catch up with what the other implementations have done.

 

[Zarathustra]

> @Norway, BUIP101 got a fair hearing. Please re-read the thread. You got masses of feedback but made no modification to reflect any of it. Expecting a change to be testable is not blocking it.

@solex
Miners can raise the default limit by orders of magnitude. Did the devs test that feature? If not, why not?

 

[Christoph Bergmann]

@solex

I agree with norway and zarathustra that having tested something noone can build is a bad requirement for Norways BUIP.

@Norway

I full agree with your motivation: Let's fix the blocksize-bug once and for all and freeze that protocol. But imho BU did this in early 2016 by enabling the ecosystem to achieve an emergent consensus. If the blocksize becomes a burden, it will be fixable. At least as long as it depends on BU. In my view you failed to address this; I will support you to make the EB/AD selection more clear / pressing, however.

The bullshit about the November Hardfork confirms why the protocol should be either completely frozen or just changed in a decentralized, emergent way, like with BIP135.

Imho this is a very critical moment for Bitcoin Cash. It has been clear since the beginning that the leaders oft the stewarding implementation of BCH did lack personal skills to responsibly fulfill the enormous duties that come with the task of stewarding a decentralized ecosystem full of crazy people that just got rid of the overregulation of the last stewards and reacts very sensible to developer's overambition to plan the system. I hoped that they will either work towards stepping back from that role, or grow over the personal limitations of their own ego, but this did not happen. Instead, it became worse. The hostile sabotage of BUIP098's voting is just the tipp of the iceberg.

The developers around our self-declared "bcash creator" seem not to understand that the time-planned November hardfork has enormous social costs, because "we did everything right and as agreed and everybody else did bad to us". Worse: They insist not just on shutting down the discussion of the fork (because they think they explained it enough and answered critiques --> did everything right), but on starting to discuss the next hardfork in six month. Are they too smart to learn? What do they expect to happen? Everybody saying sorry to the "bcash creator" for having had doubts and being a nice sheep again for the next unneeded protocol changes?

To be absolutely clear: Starting Bitcoin Cash was not meant to start a tech-project of ABC powered by Bitmain. This increasingly looks like a parody of Core. Core at least has some kind of "cypherpunk" vision, good reasons, a path forward and support of dozens, if not hundreds, of developers, and they act carefully on some way. ABC has nothing of this, but more bugs, more arrogance, more hostility, more protocol changing ambitions.

If Bitcoin Cash just replaced Core with ABC, instead of getting rid of developer's authority, it has officially become a shitcoin.

The current outview of Bitcoin Cash - implementing a feature nobody is excited about and a lot don't want on risk of a chainsplit - seems tailored of proofing us all wrong, of ridicouling what we hoped would fulfill Satoshi's vision. I will prefer a lot of undeveloped shitcoins over this authoritarian technocratic playground. This is why I stopped hesitating to push my opinion forward: If ABC gets its way, BCH is a lost case for me.

With BIP135 we have an alternative. Every feature that has been proposed can be activated in a careful and decentralized way. No risk of a chain-split, no dictatorship of one implementation, no chance for BTC-miners to just step in to enforce a change (like with the hardfork-date), but a sustainable model to handles protocol updates by hardforks.

There is only one reason to not want BIP135: To maintain a developer's committee's control over protocol changes. I consider this a catastrophic goal for Bitcoin Cash.

In my view it is an important moment to save BCH from repeating BTC history as a parody.

 

[imaginary_username]

I need to reiterate this from time to time, since some people obviously have not heard it: "developer's authority" has never existed and can never exist. Developers write software, and they convince miners and the ecosystem (exchanges, merchants) to adopt them, to follow one schedule or another, etc.; their "power" only goes so far as their ability to persuade. Assuming otherwise is like assuming clerks of congresspeople, the ones who "actually write the laws", have all the power. It's quite absurd to yell at the clerks for writing laws you or I dislike rather than the congresspeople who actually turn them into reality.

Hell, if you want someone reachable to yell at, yell at me! I run several nodes serving various functions, one of them is a (tiny) mining node. I choose which software I run, and my choice actually affects people and rigs who connect to my nodes, developers who use them, as well as relay performance of my peers.

If the players with actual power follows one developer team, they are the ones who ultimately need convincing. You can attempt to persuade them by proxy by persuading the dev team they have previously listened to, but make no mistake who actually hold the cards.

I'm doing my best to actually spread BUCash adoption - BU as an implementation has several edges over ABC like relay latency (very very important for merchant nodes) and partial parval (lockup prevention), while at the same time has had problems with stability until 1.3.0.1 (first hand experience), and only further amended at 1.4.0.0. I try to tell people about the good things while evaluate and feed back to devs about the bad things. Running nodes that get real world usage helps me do that.

If you are trying to convince miners and exchanges to run your software, the number 1 and number 2 items on the list are both confidence. Successfully avoiding bugs that competing implementations had (such as the April fork bug) helps that - thanks devs! Putting forward pointless bullshit like BUIP101 erodes that - thankfully it was not passed.

BU is gaining confidence, but it's not quite there yet, best illustrated by the fact that even SV forked from ABC that they purport to hate, not BU.

What have the people who sit back and complain about philosophy and politics all day actually done to further the BU vision, whether technology or governance?

>BTC-miners to just step in to enforce a change

You know that BCH is considered secure at all because >51% of BTC mining pools are friendly to us, right? Would you rather live in a world where we wake up every day not knowing if the chain would still exist, or imploded from Bitfury or Slush screwing with us?

 

[Christoph Bergmann]

@imaginary_username

I need to reiterate this from time to time, since some people obviously have not heard it: "developer's authority" has never existed and can never exist. Developers write software, and they convince miners and the ecosystem (exchanges, merchants) to adopt them, to follow one schedule or another, etc.; their "power" only goes so far as their ability to persuade. Assuming otherwise is like assuming clerks of congresspeople, the ones who "actually write the laws", have all the power. It's quite absurd to yell at the clerks for writing laws you or I dislike rather than the congresspeople who actually turn them into reality.

That's what Core told us so often, and your argument can be easily extented to "Amazon has no authority", because it are the merchants and buyers who use amazon. That's true on some way, because it's the market that has the option to chose authority, and the market makes and takes power.

But your example is good. Do you know how the word "Kanzler" (chancellor) originated? It literally meant the clerk who "actually wrote the laws", but managed to become the most important political figure of a lot of countries.

And don't get me wrong. I just constate that if the miners or the market give ABC it's way, for whatever reasons, it will do a heavy damage to Bitcoin Cash, at least in my view. There are a lot of other options, be it XT, BU or ABC without the fork / replay protection. If miners don't use them, they will have failed in my view to steward Bitcoin Cash.

If the players with actual power follows one developer team, they are the ones who ultimately need convincing. You can attempt to persuade them by proxy by persuading the dev team they have previously listened to, but make no mistake who actually hold the cards.

That's the reason why I currently try everything to spread my opinion. I want the actual powers to know what they risk.

I hope miners do the right thing. If not, I know the consequences for me. That's all.

BU is gaining confidence, but it's not quite there yet, best illustrated by the fact that even SV forked from ABC that they purport to hate, not BU.

There is the option to run XT or to run ABC without forking code. It doesn't matter what options the miners pick, just following the November hardfork is the worst option. In my view.

> You know that BCH is considered secure at all because >51% of BTC mining pools are friendly to us, right?

This is an uncomfortable setup, but to some degree acceptable when it just comes to "survice". Using it to "change" BCH is some other level of dependence.

 

[freetrader]

Judging by words, I don't think the ABC developers are opposed to BIP135 in future, they just seem to think that it won't work under the current circumstances where BCH still has the minority of hashpower in the (BTC / BCH) universe.

I think there can reasonably be disagreement on whether or not miner voting would cease to work given the existing situation w.r.t. BCH (which is fairly unclear to the public tbh).

The real problem I see is that BCH hashrate seems split already into two camps which no longer seek reconciliation. Right now they have engaged in a fight for survival, and definitely on the war path if not in "war mode". Solutions involving voting between parties tend to be ignored in wartime. But that doesn't mean they don't stand a chance - the first step is to deploy and offer the possibility.

All this doesn't make Bitcoin Cash a shitcoin for me. It means that there is large uncertainty about how this will resolve in November. There are dangerous games being played with the future of Bitcoin Cash, and it isn't all due to one camp or the other.

 

[Christoph Bergmann]

lol, it gets worse.

This is what I heart a lot in last days: The ABC fork is powered by hashrate. That's the game.

At the same time ABC developers refuse to let miners vote, and Amaury publicly spoke against Nakamoto consensus.

So ...

Either ABC fork has the hashrate majority: Than it is legitimized by hashpower.
Or it has the minority: Than it is still legitime, because hashpower doesn't matter.

lol. Everybody who's here since 2015 knows that game.

It is possible that ABC splits off at November 15th without developer consensus, community support and hashpower majority, but claims they have the legit BCH.

We can have several coins. ABC, SV, Do-Nothing, BIP135. And we have no valid criterium for what is the real coin.

You can't determine if it will change, what coin the real on is, and so on. This is not a the strategy to earn trust. This is just dumb.

The big Shitcoinization of Bitcoin Cash has begun. And if you guys don't realize this, you will have no chance to prevent it. If there is a chance at all.

 

[79b79aa8]

meanwhile gemini announced yesterday that it would wait at least until after the fork was resolved to list BCH. they listed LTC instead.

even today there is only one USDBCH onramp in many US states (coinbase). gemini would have been a second one. bittrex is gaining approval to list fiat pairs, they will have to achieve this state by state.