Gold collapsing. Bitcoin UP.

[Zarathustra]

As far as I interpret his explanation, Amaury thought passing BUIP 101 would be to the long-term benefit of BU.

Indeed. Just like hitting him into the face until knockout. It would be to the long-term benefit of Amaury. It would make him even stronger than he already is, lol.

 

[Christoph Bergmann]

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.

Freetrader already expressed it perfectly.

In what disturbing reality is it "long-term benefit of BU" if you sabotage the voting mechanism to introduce sth you think is a bug which will eventually make people lose money and decrease trust in BU code and governance for a long time?

Edit: Zarathustra answered the question. I was thinking in the line of "poisening someone to help him taking better care of himself longterm."

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

Lol. I can't count how often I have been accused to only want big blocks because of Roger Ver. Feels like I'm in a loop.

I could go on, but other people here made better points than I could ...

 

[Mengerian]

@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.

Yeah, I'll grant you may have a point there. Although I don't think the idea of fixing the Merkle tree vulnerability originated from ABC, but the specific fix of 100-byte min Tx size (rather than just =/= 64 bytes or something else) seems like it was decided arbitrarily.

On the other hand, it seems like pretty minor issue.

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

Yeah, I'd agree with that. I guess the reasoning behind having non-public meetings is so that people can talk freely without having to play to the crowd, and be able to make mistakes.

Personally, I'm going to try to discuss stuff publicly from the start. I already did this, for example, giving a talk about CTOR at the Tokyo conference in March. I'll just try to redouble my efforts to do that even more.

 

[imaginary_username]

@Mengerian obviously people should be able (and encouraged) to talk a lot closed - it's where thought experiments happen without scrutiny and very valuable. But closed meetings cannot be the basis of decisions, whether that decision is perceived as "final" (Core) or "take it or leave it, hash decide lmao" (BCH).

Definitely salute your efforts at broadcasting information and facilitating conversation! I'm trying to do that myself, as well as quite a few other well-intentioned and open minded people who are not on dev teams directly.

 

[Wecx]

@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.

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.

I fully agree with this post if I didn't take into consideration Amaury's nature. I think his harmless troll ways of making a point are just his personality and shouldn't be taken seriously. As you pointed out he stood up in front of miners and told them how large block size caps can be exploited, which you agree with. If BUIP101 would have passed would BU devs have actually raised the Default to 10TB if it was dangerous? If not, then maybe Amaury point that bikeshedding over the default limits is wasting a lot of time has some merit. Just look at all the discussion over 10TB default limit when the actual blocksize is under 100kb. Perhaps, we are trolling ourselves at this point and we didn't need Amaury's assistance. I think there are actual individuals out there who wish the project harm and focusing on Amaury's troll vote is tilting at windmills.

 

[freetrader]

His "harmless troll ways" as you describe them may be his nature, but voting on BU issues isn't the place for that. It's the place where the rubber meets the road for bona fide action in BU matters and adhering to the Articles of Federation.

 

[Wecx]

I am not condoning his actions or saying he should or shouldn't act the way he did, but Amaury is a long-time BU member and do we really want to go down the rabbit-hole of accusing him of attempting to intentionally sabotage the client?

 

[Mengerian]

Indeed. Just like hitting him into the face until knockout. It would be to the long-term benefit of Amaury. It would make him even stronger than he already is, lol.

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?

 

[solex]

BU is a very broad organization, with its membership covering many areas of expertise as well as other specific cryptocurrency commitments. I feel this is a great strength as we certainly can't be an echo-chamber when some members have diametrically opposed views to each other. It also means that the final result of voting decisions is closer to the proverbial "wisdom of the crowd". I like the idea of trusting that paradigm and seeing where it takes BU in 2, 5, 10 years time.

The difficulty with the specific allegation of people not voting in the organization's best interests is a grey-scale measurement from a bunch of other grey scales:
a) the scale of whether any given BUIP is deemed "good" or "harmful" to the org.
b) the scale of whether any given vote was privately a sincere or insincere decision.
c) the scale of whether any public justification given for a specific vote is accurate or inaccurate.
d) the scale of interpretation of (a) (b) and (c) by others as to how much they align with a "majority" interpretation.

BUIP101 is a very unusual and interesting case as it showed even support and opposition, by a large number of members. In other situations, where the majority is one-sided then the minority are never asked to explain themselves or suffer criticism later.

Every vote brings in new members and therefore gently advances the shape of the org. As long as these inductions are the will of the majority then any unusual voting by a minority will not be material overall. Nevertheless, we hope and expect that all member votes are cast with best intentions for BU.

 

[freetrader]

Or do you blame the guy who said "this whole thing was a dumb situation" but voted for it?

We have the voting options "ABSTAIN" and "SPOIL" for when you either don't know if something is a good idea, or want to let someone (in your example the group) make their own mistakes or think an issue up for vote is dumb and want to express that.

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.

 

[Wecx]

Freetrader pointed out that there is a breakdown in communication between ABC and BU. Maybe, then, that can be mended and the course can be set anew. Everyone has the same goal: Peer to Peer Electronic Cash, Onchain Scaling, Free Markets, Financial Freedom and Separation of Money and State. It doesn't matter which client is being run if they all work together to bring the best changes to Bitcoin. In the end, if we increase adoption all the things I mentioned we want will come true and our investments become profitable.
[doublepost=1539206758][/doublepost]

We have the voting options "ABSTAIN" and "SPOIL" for when you either don't know if something is a good idea, or want to let someone (in your example the group) make their own mistakes or think an issue up for vote is dumb and want to express that.

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.

What is the solution though? What kind of recourse would you suggest? I can only think of moving forward and repairing what cooperation was lost and moving toward a common goal.

 

[freetrader]

I completely concur with @imaginary_username on this:

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.

I was disappointed in the abandonment of the bitcoin-ml mailing list as a viable place to broadly discuss proposals and issues affecting various stakeholders. It met the criteria for a neutral place with trackable discussions and opinions.

I've suggested to use on-chain facilities like Memo before. They're coming along nicely, with ability to upload documents. But I think they're still too cumbersome overall to be accepted, and some would be opposed to using them for such purposes, plus there's a barrier in terms of fees to post. In terms of a proper historical record though I'd say it could give us a lot we don't have right now.

Open to better suggestions.

 

[theZerg]

Yeah, I'll grant you may have a point there. Although I don't think the idea of fixing the Merkle tree vulnerability originated from ABC, but the specific fix of 100-byte min Tx size (rather than just =/= 64 bytes or something else) seems like it was decided arbitrarily.

On the other hand, it seems like pretty minor issue.



Yeah, I'd agree with that. I guess the reasoning behind having non-public meetings is so that people can talk freely without having to play to the crowd, and be able to make mistakes.

Personally, I'm going to try to discuss stuff publicly from the start. I already did this, for example, giving a talk about CTOR at the Tokyo conference in March. I'll just try to redouble my efforts to do that even more.

I first brought it to the attention of the BCH dev community after @awemany showed it to me. But yes, the original discoverer (sergio demain lerner: https://bitslog.wordpress.com/2018/06/09/leaf-node-weakness-in-bitcoin-merkle-tree-design/) suggested "A simple soft-forking solution is to invalidate blocks having transactions of size equal to 64." Yet we turn around and the number is committed to ABC and released as 100 bytes with no justification, discussion, or even a notification. WTF?
[doublepost=1539222235][/doublepost]

Freetrader pointed out that there is a breakdown in communication between ABC and BU.

What about ABC and XT, and ABC and flowee? There's arguably a breakdown in communication between ABC and anyone who expresses an alternate opinion. These feature discussions instantly became political not technical... are you WITH ABC or AGAINST? Are you WITH nChain or AGAINST? As we saw with the reluctance of Core to simply increase the block size to 2MB, this tends to result in poor decision making, with the obvious consequences.

This is why I'm "for" unbundling the features and moving to miner voting and activation.

 

[awemany]

@Mengerian :

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.

BUIP101 was close. I don't think it would have been fatal in any sense and there's a few provisions in the articles wrt. BUIPs and PRs to the lead dev that would have prevented major damage. However, it would have IMO still been a distraction and would not have helped.

@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 would be quite surprised if you would not be majorly pissed at that person for trying to do so, whether successful or not.

This surely doesn't feel like "be excellent to each other". I find it surprising that you defend this.

 

[Christoph Bergmann]

The difficulty with the specific allegation of people not voting in the organization's best interests is a grey-scale measurement from a bunch of other grey scales:
a) the scale of whether any given BUIP is deemed "good" or "harmful" to the org.
b) the scale of whether any given vote was privately a sincere or insincere decision.
c) the scale of whether any public justification given for a specific vote is accurate or inaccurate.
d) the scale of interpretation of (a) (b) and (c) by others as to how much they align with a "majority" interpretation.

a) is not related to this case. Every member has to make up for his own if this BUIP is good or harmful. That is the purpose of the votinjg.
b) yes, this is in nearly every case a grey scale. Except members explain their motivation on social media, like in this case.
c) Is there any reason to think the given explanations by the two ABC devs have been inaccurate? They had the chance to explain us how they really mean their statements.

Sure, you can grey-scale those things, you can try to find excuses for it, "they don't meant what they said and we have to know if the BUIP is good or bad to understand their intentions and so on." But by doing so you set an exempel: BU will not defend itself against malice voting, even if people mock the BU community by explicitly stating that they voted with malintentions.

If this has no consequences, BU's voting process is broken.

 

[imaginary_username]

Article 2 (X) provides for a mechanism for no-confidence BUIP to remove any member, not just officers, at least if I'm interpreting it correctly.

While I find their voting behavior distasteful, I do not think there are sufficient grounds to conduct membership removal, which sets a very dangerous precedence and should only be done in the very most dire of situations; therefore I would not support such an initiative against deadalnix and shammah. That said, if the articles provide for it (did I interprete it right, @solex ?), I can't stop anyone from putting it forward.

 

[theZerg]

Clearly in some sense ABC is in competition with Bitcoin Unlimited and in another sense we are cooperating. This is actually one of the most effective and productive social organizations since cooperation is needed to accomplish more than 1 person's effort, yet competition keeps people from getting lazy.

Having leaders (or citizens) of the competition vote in your election is generally disallowed due to the obvious potential for abuse.

However, while Amaury and Shammah were able to rise above that and vote for what they believed to be the good of BCH, then they were on the "cooperating" side.

Yet here we have a clear and documented instance where they voted against their own beliefs to throw what they believed would be a problem on our laps.

The articles of federation actually use possibly legally binding language, although let's be clear the chance of actual legal action is zero while I have anything to say about it:

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. I agree to follow the rules outlined in Articles 2,3,
and 4 for all matters pertaining to Bitcoin Unlimited. I
further recognize that becoming a member of the Bitcoin
Unlimited Federation and simultaneously working to
undermine the Bitcoin Unlimited Vision will inflict
substantial harm on the other members of
the Bitcoin Unlimited Confederation, including but not limited to,
loss of Member's time quantified by the average hourly
wage of a principal engineer in the USA, loss of member
monetary donations, and loss of opportunity.


Article 1 talks about a lot of things but notably about how Core is run entirely by engineers who are not listening to others.

"The Bitcoin Unlimited project seeks to provide a voice, in terms of code and hash power, to all stakeholders in the Bitcoin
ecosystem."

It also says "we acknowledge that Bitcoin is fundamentally a decentralized system and thus we will not assert centralized ownership of the protocol." "As a foundational principle, we assert that Bitcoin is and should be whatever its users define by the code they run and the rules they vote for with their hash power."

I wonder if these two ABC developers believe in these tenets. The ABC structure is a dictatorship, with little opportunity for voice. Amaury and Shammah are no longer participating in the biweekly inter-client dev meetings, where they could listen to others' feedback. ABC is in a fight with nChain and (correct me if I am wrong) is claiming the right to the BCH name no matter what happens WRT hash power. This is claiming centralized ownership of the protocol.

There's another key sentence in Article 1:

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


So I'm asking @deadalnix and @shammah to do the right thing. If you cannot rise above disputes and vote for what is best for Bitcoin Unlimited you need to recuse yourself by giving up your membership. This would be the "right" thing to do. But if you choose not to do so, remember that your votes are public. These displays of pettiness ultimately only reflect poorly on yourselves and your project.

 

[lunar]

@ryanXcharles The destroyer of myths.

Great panel session.

CoinSpice #bchdevcon Periscope link

https://twitter.com/CoinSpice

 

[Richy_T]

"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."

Reads like an admission of attempted sabotage to me.
[doublepost=1539304238][/doublepost]

Or do we now have to judge whether people have the correct motivation?

I think this is a reasonable function of the BU governance structure. Especially when someone has made clear their motivation by writing it down and publishing it to the world.

 

[Richy_T]

What about ABC and XT, and ABC and flowee? There's arguably a breakdown in communication between ABC and anyone who expresses an alternate opinion.

And, of course, IIRC, ABC itself came about because of breakdown in communication between Amaury and one of our BU locals. It seems like it happens when it's convenient.
[doublepost=1539305838][/doublepost]

Article 2 (X) provides for a mechanism for no-confidence BUIP to remove any member, not just officers, at least if I'm interpreting it correctly.

If it does not rise to that level, how about a motion of censure? Since that would have no actual effect other than voicing disapproval, could that be done withing the BU rules?