Gold collapsing. Bitcoin UP.

[solex]

I know this is disappointing for you @Norway. I certainly tip my hat at your campaign skills. BUIP101 went very close and probably helped with the turnout.

 

[imaginary_username]

...am just glad that I'm saved the trouble of keeping a single-purpose fork of BU indefinitely.

Don't worry, there are more sophisticated ways to implement a "blockcap that will never be hit" that simultaneously minimize the possible venues of attack (both technical and social!), and the upcoming workshops/conferences (see also: BUIP 092 / 103 ) are going to be good places to put them forward.

 

[Zarathustra]

Sorry @Norway, I like the 4-byte to 8-byte change, but not the default removal, as I have mentioned a lot lately!

It was not a default removal proposal. If it was, @awemany would have accepted it and @Norway would have won.
[doublepost=1539174899][/doublepost]

Don't worry, there are more sophisticated ways to implement a "blockcap that will never be hit" that simultaneously minimize the possible venues of attack (both technical and social!),

In theory, there are innumerable conceivable ways. In practice, there was not a single way for 10 years. Instead, another chance was missed.

 

[imaginary_username]

>In practice, there was not a single way for 10 years

Different ways differ in their merits and chances of being adopted. Most are superior in both to false advertisement.

 

[Christoph Bergmann]

This is disturbing:


"Because people do not seems to be convinced by reason, so in this case, the best move forward is to have them try it.
The fact that BU had already one crash bug due to improperly checking the limit aparently wasn't enough, and a second one is needed."

After ABC had two bugs in a few month, while BU runs withourt bugs for more than two years, after ABC demonstrated a weak performance on the stresstest, this statement is just an arrogant failure to grasp reality. Deadalnix should be suspended from being a Bitcoin Unlimited member as soon as possible.

 

[79b79aa8]

I want BU to support the upgrade plan that came out of the developer collaboration from the last several months, and be compatible with what is implemented by Bitcoin ABC.

the developer collaboration process was not properly delimited, manifestly broke down and produced an upgrade plan that is not agreed upon and threatens to split BCH. under those conditions it is no longer reasonable or principled to stick to it.

frankly, from the outside, it looks like ABC devs tried to slide CTOR by with little discussion and without attracting much attention. it did slide by at first, and then when eventually and predictably feathers were ruffled because of a change to the consensus rules, then the position changed to pretend to be wronged because of others' going back on the agreement.

CTOR (+ Merklix) alters bitcoin's fundamental design. effecting the change also breaks other people's software -- there is a long list -- and those responsible for that software will turn hostile to ABC the moment they have to start fixing what was broken, if they didn't already. projects will leave BCH or die because of the change. other projects will be slowed down and have to reallocate resources. yet ABC devs somehow insist the under-tested and under-discussed outcome of a poorly defined developer process justifies pushing the change.

furthermore, this is certainly not the first time that ABC acts in a we-know-best, we don't need to lobby for our changes because we are in control and we have thought this through so trust us attitude. it is dangerously self-assured, immature, and in stark contrast with how the experienced and level-headed devs in the space (within and without BU) operate. and don't tell me this is permissionless innovation and if it hadn't been because of ABC's heroic stance there would not be a BCH. this is a false narrative. work on a minimum viable fork began long before ABC came to be. it would have happened one way or the other.

if the BTC/BCH split taught us anything, it's that you can't slide by a change on the consensus rules without a fight. there are currently USD$8 billion of other people's money hanging on the future of BCH, and ABC is decidedly not the Open Market Committe. the sensible thing to do would be to stand down on CTOR. the present position is hubristic and in my assessment will end up being detrimental to ABC.

 

[Bagatell]

"and those responsible for that software will turn hostile to ABC the moment they have to start fixing what was broken""

https://www.reddit.com/r/btc/comments/9my15p/psa_if_ctor_is_implemented_in_november_i_will_be/

 

[freetrader]

I'd like to point out that the preamble of the Articles of Federation states:

In cases of potential conflict of interest, the ethical and socially accepted behavior should be to recuse oneself from such a position of influence.

and the final passage include the paragraph

I, the undersigned, substantially agree with the Bitcoin Unlimited Vision as defined in Article 1 and agree to work towards the success of Bitcoin as defined by Article 1.

We (members) work towards success of Bitcoin and BU here. We cannot afford to wilfully damage the reputation of BU since

working to undermine the Bitcoin Unlimited Vision will inflict substantial harm

All who are members are invested in Bitcoin Unlimited to some extent. If it suffers failures, it is our reputations and in probably all cases, investments, that suffer. Worse, we jeopardise the success of the Bitcoin project.

We are bound by the Articles to conduct our affairs within BU with integrity. If members feel they do not need to abide by the Articles, then they should recuse themselves and tend to their other interests.

 

[Wecx]

This is disturbing:


"Because people do not seems to be convinced by reason, so in this case, the best move forward is to have them try it.
The fact that BU had already one crash bug due to improperly checking the limit aparently wasn't enough, and a second one is needed."

After ABC had two bugs in a few month, while BU runs withourt bugs for more than two years, after ABC demonstrated a weak performance on the stresstest, this statement is just an arrogant failure to grasp reality. Deadalnix should be suspended from being a Bitcoin Unlimited member as soon as possible.

Wouldn't it be more productive to make a technical refutation of Deadalnix's position that BUIP101 would have introduced a bug by improperly checking the limit rather than advocate for his removal?

 

[Christoph Bergmann]

@Wecx

Yes, if he disclosed a bug in the BUIP discussion. Imho he is not talking about a bug. If he was, it would be even more malice that he voted FOR the activation of BUIP101. I'm not angry because he is against BUIP101 - I was too - I'm angry because he voted for it with the aim to damage BU. Also his collegue micropresident voted FOR it and publicly announced that his intent is to damage BU, which seems like ABC devs orchestrated this. That's more malintention as I ever seen from Core devs.

 

[Wecx]

I can see how that could be interpreted, but if voting to accept BUIP101 would damage BU then wouldn't that also condemn everyone else who voted for it to pass? Does BU actually vote on BUIPs that can harm the client? Should that not be against the rules and BUIPs be vetted? I think Deadalnix is just being hyperbolic, I don't think he actually is trying to harm BU.

 

[Christoph Bergmann]

No. It's the intention of a vote. Amaury and Micropresident think BUIP101 is a bad idea but voted FOR. There is no room for interpretation.

 

[Wecx]

I see what you mean. On the other hand, if technical BUIPs were vetted by the lead developer then deemed safe before voting then an "accepted" or "rejected" outcome would be trivial and then Amaury's and Shammah's position would be embarrassing. So this conversation brings up a deeper question: Are they correct that BU is voting on dangerous BUIP that can harm the client. If they are not correct and BUIP101 could not have harmed the client then if they thought it was a bad or good idea wouldn't make a difference. If they are correct that BUIP101 could harm the client, then are they serving BU by pointing it out? Also, technical BUIPs are non-binding anyway right? so wouldn't it be impossible to harm BU by voting on BUIP101? If, so, then it would be impossible for the intention to harm BU if it is well known that harmful BUIPs are non-binding unless they actually produced the code?

 

[Zarathustra]

Different ways differ in their merits and chances of being adopted.

The 'chances' of all different ways in the past 10 years have been exactly the same: zero.

 

[wrstuv31]

I see what you mean. On the other hand, if technical BUIPs were vetted by the lead developer then deemed safe before voting then an "accepted" or "rejected" outcome would be trivial and then Amaury's and Shammah's position would be embarrassing. So this conversation brings up a deeper question: Are they correct that BU is voting on dangerous BUIP that can harm the client. If they are not correct and BUIP101 could not have harmed the client then if they thought it was a bad or good idea wouldn't make a difference. If they are correct that BUIP101 could harm the client, then are they serving BU by pointing it out? Also, technical BUIPs are non-binding anyway right? so wouldn't it be impossible to harm BU by voting on BUIP101? If, so, then it would be impossible for the intention to harm BU if it is well known that harmful BUIPs are non-binding unless they actually produced the code?

Double think nonsense

 

[Wecx]

1) I assume good intentions. 2) What do you disagree with?
If harmful technical BUIPs are non-binding then does the responsibility fall on the people who voted for it or the lead developer who merged the code?

 

[Mengerian]

Deadalnix should be suspended from being a Bitcoin Unlimited member as soon as possible.

15 other people also voted for BUIP 101. Should they also be removed from being BU members?

Or do we now have to judge whether people have the correct motivation? As far as I interpret his explanation, Amaury thought passing BUIP 101 would be to the long-term benefit of BU.

the developer collaboration process was not properly delimited, manifestly broke down and produced an upgrade plan that is not agreed upon and threatens to split BCH. under those conditions it is no longer reasonable or principled to stick to it.

The collaboration broke down primarily for one simple reason: nChain wanted it to break down. They purposely muddied the waters and stoked confusion.

frankly, from the outside, it looks like ABC devs tried to slide CTOR by with little discussion and without attracting much attention. it did slide by at first, and then when eventually and predictably feathers were ruffled because of a change to the consensus rules, then the position changed to pretend to be wronged because of others' going back on the agreement.

Maybe it looks that way from the outside. ABC devs actually proposed just removing TTOR as a first step, others (I think Tom Harding suggested this for example) suggested it made more sense to go straight to CTOR. All other items in this upgrade, and the previous one, originated from groups other than ABC. The main thing the ABC people wanted was to have the upgrade features be implemented by Aug. 15th, so that everyone would have time to test and upgrade before the network upgrades on Nov 15th.

Also, I can only really speak for myself, but I don't think ABC devs are particularly concerned about having been supposedly "wronged". I definitely don't want any pity. It's more a matter of setting the record straight about what has happened to put the current situation into proper context.

furthermore, this is certainly not the first time that ABC acts in a we-know-best, we don't need to lobby for our changes because we are in control and we have thought this through so trust us attitude. it is dangerously self-assured, immature, and in stark contrast with how the experienced and level-headed devs in the space (within and without BU) operate.

It's unclear what your objection is here, you don't like the demeanor of the ABC devs? Should ABC not advocate and work towards the changes that they think are best for BCH? I gave a talk in March about CTOR, trying to get people discussing it. It's been on published roadmaps for about a year. Maybe more could have been done to "lobby" for it, but it sure wasn't kept secret, and it's hard when objections suddenly appear at the last minute.

and don't tell me this is permissionless innovation and if it hadn't been because of ABC's heroic stance there would not be a BCH. this is a false narrative. work on a minimum viable fork began long before ABC came to be. it would have happened one way or the other.

That's highly debatable, and impossible to determine what would have happened in an alternate reality. It was definitely not solely ABC that was responsible for Bitcoin Cash, many people worked hard to make it happen. Miners had to mine at a loss, for example. But I think it's fair to say that ABC was a key part of making it happen.

 

[freetrader]

All other items in this upgrade, and the previous one, originated from groups other than ABC

@Mengerian, which group proposed the 100 byte minimum tx size? I don't see any other groups who wanted the fix in that form. Complaints seem to have been ignored - once again.

15 other people also voted for BUIP 101. Should they also be removed from being BU members?

No. It isn't about being able to vote your conscience. That's always a right.

This is about voting out of spite to see BU fall.
These two were just a short time earlier standing in front of miners & others in Bangkok and telling them how very large block size caps could be exploited as a DoS vector unless some other safeguards were put in place.

I actually agree and defended that viewpoint. I still believe it holds true, which is why I voted to reject BUIP101 -- it didn't put forward the other measures that would be needed to do it safely.

Then he confirmed that he voted like he did because he thought it would be beneficial for BU to suffer another exploit. No offence, but BU should not be ignoring this, because it's not alright.
For me it signified that relations between ABC *leadership* and the BU *project* had broken down completely and that *some* ABC members were actively voting for something they considered would result in problems for BU.

That these would be problems in the short term makes things even worse imo.

I would like to see some understanding on their part of why this is something that I will not accept as a BU member.

 

[lunar]

IC...Uhhh OOhhh

SEC tightens the noose on ICO-funded startups - Decrypt and Yahoo research

Hundreds of startups that did token sales are finding out they’re in violation of securities law— including many that were sure they did it the right way.

"The law was pretty clear"
"SEC sees most ICOs as securities offerings—and companies failed to comply"

“Everybody’s holding their breath for the SEC to create some kind of coin rule, and they’re not going to,” says a securities attorney at one high-profile Silicon Valley firm. “They’re applying the same laws, the same statutes, the same rules, to stocks and bonds and everything else.”

The cull has begun. Good riddance.



edit link and ref

 

[imaginary_username]

So the more I look at it the more I found that all this fuss originated from an extremely unhealthy culture of secret meetings instead of full open discussion, the antithesis of forging consensus (even among reasonable people). Politically no matter what kind of change is proposed, people are guaranteed to feel upset and saboteurs will have wide-open chances to mess with the community since the moral high ground is shaky when the process is obscured.

A lot of things seem to trace back to this "November BCH London meeting" that supposedly had some, uh, representation from various groups including but not limited to nchain. Some news outlets report it to be as small as seven people (!), I'm not sure how accurate it is, but hot damn. That's almost IOTA level of dubiousness. If we are to survive, we can't keep having shit meetings like this determining future directions.

So much so, that we're gonna lose a very valuable service not from technical merits, but from objection to the political process: https://www.reddit.com/r/btc/comments/9my15p/psa_if_ctor_is_implemented_in_november_i_will_be/

Whether you think you're right or wrong, politics is a fact of life, and just saying "lol miner decide" is a fast track to ruin for scamsters and the virtuous alike. We can't afford to lose more well-intentioned people, a better process needs to be established pronto.
[doublepost=1539196744][/doublepost]"Wait so what process will you suggest?"

I don't know, but anything is better than what we have now: object on telegram, everyone have their own ubersecret little slacks, shout over twitter when things are merged and too late, have saboteurs conduct fake news campaigns to further the damage among all this.

The Linux kernel mailing lists have a benevolent dictator, but at least everything is 100% transparent and trackable, so people object to them less after things are settled - even that is preferable to this fictional "competition amirite" thing we like to tell ourselves are the best(TM). Hell, the much-maligned Core repo at least has friggin comments on github that people can trace reasonings, support and objections over. Despite being controlled by a few committers, even that is going to generate less political strife.

I'm not saying we should adopt either of these models, probably not, considering where we came from. But just parroting "hashpower lol" while conducting PR warfares is not a real solution either.

For starters, even with the current model, communications need to happen more in the wide open, and decisions made with a trackable trail of opinions and blame. That will be a good start.