BitcoinXT dispute resolution, etc.

[theZerg]

I think that we should create a process to handle dispute resolution in XT, so that we don't end up in the same situation we are in with core in a few years. This process would be a formal mechanism that allows stakeholders to provide input to developers in regards to what features should be in XT. Of course, you'd still be allowed to fork XT or core if it didn't go your way but such a process would ensure that more than 2 devs get to decide what the XT branded Bitcoin is.

This kind of structure is what is missing from Core, is causing this huge mess, and making us look like amateur hour in the eyes of outsiders.

Frankly, if I felt like the economic majority of Bitcoin holders -- that is, if the users -- wanted to stick with 1MB, I'd shut up (and probably start working on a micro-payment coin to fill the gap). But the problem is that it seems like the situation is being driven by a few personalities, and there is no way to be certain.

Here are some topics:

1. Identifying stakeholders

2. Development conflict resolution

3. Development funding

What do you think of the idea? What kind of process would you like to see?

(I posted this first to the GCBU but the mod here thought it would make sense to break it out)

 

[cypherdoc]

#1 is problematic. there are many ppl who have dozens of cold wallet addresses tucked away and would never want to dig them out from underground vaults simply to demonstrate having a stake for voting purposes. Alan Reiner has warned us of this and he should know, of all ppl.

 

[seweso]

Voting should occur with coins on a specific date. That means you can move them and still vote with your old keys. And even so, people who don't want to vote, simply should not.

 

[theZerg]

It could be arranged so you'd only have to dig them out once, and then be able to vote those coins on many issues for as long as the coins do not move...

Voting proportional to your coins is probably controversial but I don't see how to do 1-vote per person without independent and distasteful identity verification.

 

[Andy Chase]

There's some ideas on this BIP draft here & comments: Committee-based BIP Acceptance Process [Dev]

 

[theZerg]

Interesting.

I like your idea that people can form representational groups which then collectively votes ("committees"). Basically an individual can delegate his vote to one, but take it away at any time. This allows one person to do the detail work on behalf of others.

I think that your 2 week then 2 week process is too constrained. I would propose that the groups have 2 weeks to respond, then an indetermine time occurs where the BIP author can work to resolve the open questions by corresponding directly with the groups. Then 2 week final arguments and voting.

I think a clear definition of what "accepted" means would be important. I think that "accepted" should mean that the master github branch, and relevant project releases should incorporate the BIP as soon as reasonably possible after a branch is created that passes security and code competence checks. In other words, the "YES" votes may have to implement the BIP or pay to have it implemented.

I think that you need to clearly define how the different groups prove their stake, and perhaps specify maximum ratios. That is, you can't have 100 committees with 99 merchant processors and 1 miner.

 

[Andy Chase]

Thanks theZerg for your response. You are one of of the first people to give me detailed comments instead of just explaining to me what a BIP is and how to submit one.

Timeline that's an important point. I've gotten that echoed from a few people now. I was thinking that a re-submit could be called if more time is needed but I think your method of allowing the author to have control over the pace makes a lot of sense.

What does accepted mean? "Accepted" is the hardest thing to grasp in this paper. There's just no way to force client authors, users, and miners, to integrate and use a change, even if one is accepted by my process. I.e. I'm trying to define what "accepted" even means, but maybe I should use different words that don't have baggage. Like my process could indicate "community greenlight" and client authors who refuse to follow "community greenlight" can do so, but they are going against the wishes of the community and that becomes obvious. Other client others (like btcd) might follow the greenlight recommendation instead and users are free to switch to that. Then there could also be "community redlight", and "no decision reached" in which there was conflicting views.

If I go this route, I could use the word "accepted" to mean something like "appears in the longest fork", or "is in use by multiple clients, merchants, & users" (for things like urls that aren't blockchain-related).

How to prove stake? "How groups prove their stake" is the hard question that has to be addressed in this proposal or any. I've pushed forward several recommendations but there's no perfect solution that everyone will accept. For users, in the comments I suggested a "community sample" method that requires that only a random few people in a group to give up their privacy.

Ratios The "accepted" or "greenlit" standard in my proposal is defined as: least 70% of the represented percentage stake in 3 out of the 4 Bitcoin segments. It's true that it seems weird to have 1 group in a segment by itself (seems like too much power), you have to recall that committees can consist of several groups that have agreed to act together. If the 1 miner group had conflicts they'd separate to make public both their views.

I'm interested in if you think that definition should be changed or if you are worried about those risks.

 

[theZerg]

What does accepted mean?

I like your "community greenlight" idea to cover how BIPs apply to the larger community of wallet providers. However, I also think that there should be stronger language applied to the Bitcoin Core or Bitcoin XT (if a XIP is submitted). That language should make it absolutely clear that committers can't revert or refuse to commit a change that implements the "greenlighted" BIP just because they don't agree with it.

How to prove stake?

I think we need to nail this down (even if imperfectly) to make this BIP real. Personally, I think that there should be at least one way to anonymously vote (say by owning coins). But I don't feel that there's any need to preserve anonymity for the other stakeholders. In fact, for some groups I think it would be bad to allow anonymous voters. If you own a bunch of coins, or prove massive mining capacity, there can be no doubt that you are incentivized to vote for what is best for bitcoin. But some vocal forum writer, speaker or professor might not care about Bitcoin's ultimate success, or be a paid shill or sockpuppet. But requiring identity at least these people are putting a little bit of their personal reputation behind their comments. Of course, companies already disclose their identities so no problem there.

But how do we choose which indirect stakeholders (companies, etc) get a vote? All I can think is that coin owners vote that this company is in fact important... this would be a once every 5 years or something vote not something you can give or take away every time a BIP is proposed.

Ratios
Somehow I missed that in your doc. Your proposal seems ok, although it may be hard to get consensus at those levels. And honestly I think that miners have too much power already -- I think that Bitcoin should be optimizing itself for users not for infrastructure. At the same time, I hope that miners realize that their business model requires consumer users (vs corporate users like bank 2 bank) so will probably vote what they believe is best for consumers..

 

[ladoga]

Just like now the development goals are set by developers of each implementation. They can do whatever they wish.

Users vote by choosing the software.

Keep it simple.