Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process

[Dave Scotese via bitcoin-dev]

This seems like a good place to point out that attempts to identify
individuals (either by name or simply as an individual human being) are
futile as well as destructive.  "1%" usually means "one out of every 100
people" but this requires identification of individuals as individuals.
One person can look like many in Bitcoin, which is why such an effort is
futile.  Additionally, one person may be far more affected by a decision
than others, which is why it's destructive.

I like the idea of measuring consensus, and there are proto-ideas in my
head about how that can be done, based not on individual people, but on
amounts of bitcoin.  Many will argue that we don't want the system to be
controlled by those who hold the most bitcoin.  I understand that
sentiment, but A) I simply disagree, and B) Finding something better seems
impossible to me.

A simple method is the following:
A message can be constructed saying: "As of block X, the holder(s) of Y BTC
controlled by [public key] agrees that Z," where X, Y, Z, and the [public
key] are the only things that change.  This message can be signed by the
private key matching the [public key] in the message.  Anyone interested in
measuring consensus on anything relative to bitcoin holders can advertise
for such signed messages to be sent to a repository of their choice which
would validate each message (that [public key] (still) holds Y BTC and that
the signature is valid) and provide a measure of agreement about Z.  Change
your mind?  Just move your BTC to a different address.

On Mon, Jan 18, 2016 at 6:12 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Saturday, September 05, 2015 9:19:51 PM Andy Chase wrote:
> > Okay for sure yeah writing another proposal that reflects the current
> state
> > of affairs as people see it might provide some interesting perspective on
> > this proposal. I would welcome that.
>
> Are you saying your proposal is intentionally not intended to reflect the
> reality? I wasn't talking about a "current state of affairs" for BIPs as
> much
> as that that the acceptance of BIPs is *defined by* the state of affairs.
>
> Overall, I think something *similar to* this proposal is a good idea, but I
> disagree with how this proposal currently approaches the problem. Instead,
> what I would recommend is a specification based on BIP 123 that specifies
> the
> conditions under which a proposal is *known to be* accepted by the
> community
> (ie, discerning, not deciding), and establishes a way for a committee to
> review the BIP and *determine* if these conditions have been met. This
> would
> avoid a "disconnect" between the "official status" and reality, making the
> BIP
> process more useful to everyone.
>
> Reviewing your current proposal:
>
> > * It sets up '''committees''' for reviewing comments and indicating
> > acceptance under precise conditions.
>
> As mentioned, IMO a committee shouldn't be indicating acceptance, as much
> as
> it should be *determining* acceptance.
>
> > ** Committees are authorized groups that represent client authors,
> miners,
> > merchants, and users (each as a segment). Each one must represent at
> least
> > 1% stake in the Bitcoin ecosystem.
>
> 1% seems like an awful lot to dedicate to BIP status changes.
>
> > A committee system is used to organize the essential concerns of each
> > segment of the Bitcoin ecosystem. Although each segment may have many
> > different viewpoints on each BIP, in order to seek a decisive yes/no on a
> > BIP, a representational authoritative structure is sought. This structure
> > should be fluid, allowing people to move away from committees that do not
> > reflect their views and should be re-validated on each BIP evaluation.
>
> That sounds very time consuming. And what happens if these committees don't
> represent the community? What about when only part of the community - let's
> say 10% - decides to adopt a BIP that doesn't require consensus? Logically
> that BIP should still proceed...
>
> > ** Proof of claim and minimum 1% stake via:
> > *** Software: proof of ownership and user base (Min 1% of Bitcoin
> userbase)
>
> But the Bitcoin user base is completely unknown, and tracking software user
> base is a privacy violation.
>
> > ** Merchant: proof of economic activity (Min 1% of Bitcoin economic
> > activity)
>
> Bitcoin economic activity is also unknown, and it seems likely that
> merchants
> consider their own activity confidential.
>
> > Mining: proof of work (Min 1% of Hashpower)
>
> This needs a proper specification. How do miners express their positions?
>
> > A BIP Process Manager should be chosen who is in charge of:
>
> Chosen how, and by whom?
>
> > == Conditions for activation ==
> >
> > In order for this process BIP to become active, it must succeed by its
> own
> > rules. At least a 4% sample of the Bitcoin community must be represented,
> > with at least one committee in each segment included. Once at least one
> > committee has 

Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process

[Luke Dashjr via bitcoin-dev]

On Saturday, September 05, 2015 9:19:51 PM Andy Chase wrote:
> Okay for sure yeah writing another proposal that reflects the current state
> of affairs as people see it might provide some interesting perspective on
> this proposal. I would welcome that.

Are you saying your proposal is intentionally not intended to reflect the 
reality? I wasn't talking about a "current state of affairs" for BIPs as much 
as that that the acceptance of BIPs is *defined by* the state of affairs.

Overall, I think something *similar to* this proposal is a good idea, but I 
disagree with how this proposal currently approaches the problem. Instead, 
what I would recommend is a specification based on BIP 123 that specifies the 
conditions under which a proposal is *known to be* accepted by the community 
(ie, discerning, not deciding), and establishes a way for a committee to 
review the BIP and *determine* if these conditions have been met. This would 
avoid a "disconnect" between the "official status" and reality, making the BIP 
process more useful to everyone.

Reviewing your current proposal:

> * It sets up '''committees''' for reviewing comments and indicating
> acceptance under precise conditions.

As mentioned, IMO a committee shouldn't be indicating acceptance, as much as 
it should be *determining* acceptance.

> ** Committees are authorized groups that represent client authors, miners,
> merchants, and users (each as a segment). Each one must represent at least
> 1% stake in the Bitcoin ecosystem.

1% seems like an awful lot to dedicate to BIP status changes.

> A committee system is used to organize the essential concerns of each
> segment of the Bitcoin ecosystem. Although each segment may have many
> different viewpoints on each BIP, in order to seek a decisive yes/no on a
> BIP, a representational authoritative structure is sought. This structure
> should be fluid, allowing people to move away from committees that do not
> reflect their views and should be re-validated on each BIP evaluation.

That sounds very time consuming. And what happens if these committees don't 
represent the community? What about when only part of the community - let's 
say 10% - decides to adopt a BIP that doesn't require consensus? Logically 
that BIP should still proceed...

> ** Proof of claim and minimum 1% stake via:
> *** Software: proof of ownership and user base (Min 1% of Bitcoin userbase)

But the Bitcoin user base is completely unknown, and tracking software user 
base is a privacy violation.

> ** Merchant: proof of economic activity (Min 1% of Bitcoin economic
> activity)

Bitcoin economic activity is also unknown, and it seems likely that merchants 
consider their own activity confidential.

> Mining: proof of work (Min 1% of Hashpower)

This needs a proper specification. How do miners express their positions?

> A BIP Process Manager should be chosen who is in charge of:

Chosen how, and by whom?

> == Conditions for activation ==
>
> In order for this process BIP to become active, it must succeed by its own
> rules. At least a 4% sample of the Bitcoin community must be represented,
> with at least one committee in each segment included. Once at least one
> committee has submitted a declaration, a request for comments will be called
> and the process should be completed from there.

Until this BIP is active, its rules do not apply, so this would be a form of 
circular reasoning. I like the idea of putting conditions for activation in 
the BIP text, but I don't think we can just let the author set any conditions 
they like either...

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process

[Andy Chase via bitcoin-dev]

Wanted to throw up here some feedback I got off-list. Source:
http://bitco.in/forum/threads/bitcoinxt-dispute-resolution-etc.36/#post-602

 [1] 

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

 [2] 

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.

 [3] 

> 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 

Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process

[Andy Chase via bitcoin-dev]

Thanks for your response BTC Drak, I will attempt to summarize your
points and respond to them:

* Some BIPs are not consensus critical -- True, see my response to Luke
* BIPs do not imply usage -- This I covered in my paper.
* Acceptance can be defined by actual use -- That's one way of doing it

> Getting back to your specific proposal. It seems to focus more on
> getting BIPs accepted in the sense of published

Wildly incorrect. My BIP had nothing to do with getting published. The
first words you can read in my proposal are as follows:

> The current process for accepting a BIP is not clearly defined. While 
> BIP-0001 defines the process for writing and submitting a Bitcoin Improvement 
> Proposal to the community it does not specify the precise method for which 
> BIPs are considered accepted or rejected. This proposal sets up a method for 
> determining BIP acceptance.

* but the proposal is "complete" when the proposer is happy with the final text.

This would be a cool inclusion. That is the intent of my "Submit for
comments" process.

---

Overall your post seemed to miss the point of my proposal, but that's
likely my fault for poor wording. I'm trying to develop a process of
coming to "consensus" i.e. gathering feedback and reducing opinions
down to a yes/no should this BIP happen or should we find a better
solution.

Importantly, it's not client specific. It's just a way of saying "hey
everyone, here's a problem and solution that a lot of people agree on"
or "hey everyone, here's a problem and solution that has a few
problems with it"

It's true that even if a "BIP" is "accepted" by my proposal it still
may not actually happen (this is mentioned in my proposal), and I
believe that's healthy. We can't force a change on anyone nor should
we.

---

Since so many people are missing the actual problem I'm solving,
here's another way of wording it: A BIP is proposed and goes through
the process. A PR is submitted that matches the BIP perfectly, and is
submitted and vetted. Should wladimir merge it?

My process isn't perfect solution that would make it so we could
replace wladimir with a wladBot. But it's a tool we can use for
gathering meaningful information to help guide that decision. Waiting
on all objections to be handled works okay so far but won't work
forever.


On Mon, Sep 7, 2015 at 12:37 PM, Btc Drak  wrote:
>
> Sorry not to reply earlier. I have a rather long post. I've split it
> into two sections, one explaining the background and secondly talking
> very specifically about your proposal and possible areas to look at.
>
> I think there's a key misunderstanding about BIPs and "who decides
> what in Bitcoin". A BIP usually defines some problem and a solutions
> or helps communicate proposals to the technical community. They are
> sort of mini white papers on specific topics often with reference
> implementations attached. They may be consensus critical, or not. The
> process for getting a BIP published is fairly loose in that it really
> just requires some discussion and relevance to Bitcoin regardless of
> whether the proposal is something that would be accepted or used by
> others in the ecosystem. The BIP editor is obviously going to filter
> out obvious nonesense and that shouldn't be controversial but obvious
> when you see it.
>
> You need to separate out the idea of BIPs as is, and implementations
> of BIPs in Bitcoin software (like Bitcoin Core).
>
> Take BIP64 for example. It's a proposal that adds a service to nodes
> allowing anyone to query the UTXO set on the p2p network. Bitcoin Core
> as a project has not implemented it but was instead implemented in XT
> and is utilised by Lighthouse. So the BIP specification is there in
> the BIPs repository. As far as the bitcoin ecosystem goes, only
> Bitcoin XT and lighthouse utilise it so far.
>
> BIP101 is another example, but one of a consensus critical proposal
> that would change the Bitcoin protocol (i.e. requires a hard fork). It
> was adopted by only the XT project and so far no other software. At
> the time of writing miners have chosen not to run implementations of
> BIP101.
>
> You can see the BIPs authoring and publishing process is a separate
> issue entirely to the implementation and acceptance by the Bitcoin
> ecosystem.
>
> For non-consensus critical proposals like BIP64, or maybe one relating
> to privacy (how to order transaction output for example), you could
> judge acceptance of the proposal by the number of software projects
> that implement the proposal, and the number of users it impacts. If a
> proposal is utilised by many projects, but not the few projects that
> have the majority of users, one could not claim wide acceptance.
>
> For consensus critical proposals like BIP66 (Strict DER encoding) this
> BIP was implemented in at least two bitcoin software implementations.
> Over 95% of miners adopted the proposal over a 4.5 month period. The
> BIP became de facto accepted, and in fact, once 95% 

Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process

[Btc Drak via bitcoin-dev]

Sorry not to reply earlier. I have a rather long post. I've split it
into two sections, one explaining the background and secondly talking
very specifically about your proposal and possible areas to look at.

I think there's a key misunderstanding about BIPs and "who decides
what in Bitcoin". A BIP usually defines some problem and a solutions
or helps communicate proposals to the technical community. They are
sort of mini white papers on specific topics often with reference
implementations attached. They may be consensus critical, or not. The
process for getting a BIP published is fairly loose in that it really
just requires some discussion and relevance to Bitcoin regardless of
whether the proposal is something that would be accepted or used by
others in the ecosystem. The BIP editor is obviously going to filter
out obvious nonesense and that shouldn't be controversial but obvious
when you see it.

You need to separate out the idea of BIPs as is, and implementations
of BIPs in Bitcoin software (like Bitcoin Core).

Take BIP64 for example. It's a proposal that adds a service to nodes
allowing anyone to query the UTXO set on the p2p network. Bitcoin Core
as a project has not implemented it but was instead implemented in XT
and is utilised by Lighthouse. So the BIP specification is there in
the BIPs repository. As far as the bitcoin ecosystem goes, only
Bitcoin XT and lighthouse utilise it so far.

BIP101 is another example, but one of a consensus critical proposal
that would change the Bitcoin protocol (i.e. requires a hard fork). It
was adopted by only the XT project and so far no other software. At
the time of writing miners have chosen not to run implementations of
BIP101.

You can see the BIPs authoring and publishing process is a separate
issue entirely to the implementation and acceptance by the Bitcoin
ecosystem.

For non-consensus critical proposals like BIP64, or maybe one relating
to privacy (how to order transaction output for example), you could
judge acceptance of the proposal by the number of software projects
that implement the proposal, and the number of users it impacts. If a
proposal is utilised by many projects, but not the few projects that
have the majority of users, one could not claim wide acceptance.

For consensus critical proposals like BIP66 (Strict DER encoding) this
BIP was implemented in at least two bitcoin software implementations.
Over 95% of miners adopted the proposal over a 4.5 month period. The
BIP became de facto accepted, and in fact, once 95% lock-in was
achieved, the BIP became Final by rights that the consensus rules for
the Bitcoin network had changed.

In the case of consensus critical proposals like that, you can only
write proposals, implement it in software and hope they are adopted.

Now where does the confusion arise? Well, Bitcoin Core is the de facto
reference implementation by virtue of having the largest technical
contributor base and the widest userbase of any Bitcoin full node
implementation. This is where I believe, the community get stuck in
their assumptions and is so obvious it may have been overlooked.

Consensus rule changes to Bitcoin Core are always documented as BIPs
so the exact details can be picked up by other software implementers
(if they so desire). Take CHECKLOCKTIMEVERIFY a new widely anticipated
opcode. The proposal implemented in Bitcoin Core and eventually
merged. Peter also authored BIP65 (required because without it, his
proposal could not be considered for Bitcoin Core).

It is not that BIP65 was somehow "accepted", in fact, as it stands,
BIP65 is still just a draft because while there is a BIP and a
reference implementation in Bitcoin Core, the consensus changes to the
Bitcoin protocol have not been proposed to the community (through a
soft fork), and thus acceptance is still only a possibility (although
acceptance is extremely likely because service providers are literally
chomping at the bit waiting for deployment).

Also I would like to note that it's only an internal rule of Bitcoin
Core that consensus rule changes require a formal BIP. It is not a
requirement laid down from the BIP gods. BIPs simply serve as a way to
communicate ideas and proposals. The community at large will decide if
a BIP becomes widely adopted or not. Of course, Bitcoin Core has a
major influence on this because they have the largest user base. It is
relevant to say the large userbase is not just a historical artefact
by virtue of being the first Bitcoin implementation. Bitcoin Core is
widely trusted by commercial users because of the high developer
count, wide technical expertise and relative security given knowing
that they will be supported with security and maintenance releases.

YOUR PROPOSAL

Getting back to your specific proposal. It seems to focus more on
getting BIPs accepted in the sense of published and missed the wider
picture. As I have detailed, getting published isnt a problem. Anyone
can make a proposal, so long as it's not obviously 

Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process

[Andy Chase via bitcoin-dev]

Dang you are right Thomas! I'm just pretty excited about this proposal and
sparking a discussion on this issue.

Here's some updates and thoughts:

   - Luke said: "BIPs wouldn't be recognised as such because nobody cares
   to meet the higher requirements"
  - Possibly true, but maybe not! I think people like having a say
  especially people with a lot of money on the line or those who are really
  passionate about Bitcoin
  - One counter example, I emailed all the sponsors of the workshop
  conference about their stance in regards to scalability going into the
  workshop and I got a 47% response rate (with 21% responding with
a concrete
  answer). See here:
  
https://www.reddit.com/r/bitcoinxt/comments/3isqmf/which_of_the_scaling_bitcoin_conference_sponsors/cujg3vc
  - One example that agrees with you, I talked to the #bitcoin-assets
  community and they seemed very against participating in future
BIPs or even
  allowing discussion with people outside their community:
  http://pastebin.com/H5WeNwu3
   - I'm seeking a historian or political science expert to assist me in
   this area. If you guys know any I'd be glad to talk to them about working
   with them.
   - Many people are complaining about the stake part, and are worried
   about the ambiguity. I firmly believe that proof of stake is a poor voting
   mechanism because it gives the most power to those that have a lot of
   money.
  - I think proof of stake might work for merchants to prove they have
  a decent economic stake if they sign with a well-known cold
wallet address,
  but I agree with someone that said merchants may be hesitant about doing
  that.


On Sun, Sep 6, 2015 at 6:36 AM, Thomas Kerin  wrote:

> Normally allocation comes after about 2 weeks or so, not 2 days!
> On 5 Sep 2015 10:20 pm, "Andy Chase via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Okay for sure yeah writing another proposal that reflects the current
>> state of affairs as people see it might provide some interesting
>> perspective on this proposal. I would welcome that.
>>
>> Greg: With no other direct comments appearing to be inbound I'd like to
>> move forward with this one and get a number assigned to it. Thanks!
>>
>> Thanks to all for the discussion!
>>
>> On Fri, Sep 4, 2015 at 2:45 PM, Luke Dashjr  wrote:
>>
>>> On Friday, September 04, 2015 9:36:42 PM Andy Chase wrote:
>>> > I understand your concerns. What kinds of changes do you think should
>>> go
>>> > through a process like this? Just hard forks?
>>>
>>> The process loses meaning if it doesn't reflect reality. So only
>>> hardforks
>>> should go through the hardfork process; only softforks through the
>>> softfork
>>> process; etc. Trying to make one-size-fits-all just means de facto
>>> accepted
>>> BIPs wouldn't be recognised as such because nobody cares to meet the
>>> higher
>>> requirements.
>>>
>>> Luke
>>>
>>
>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process

[Andy Chase via bitcoin-dev]

Okay for sure yeah writing another proposal that reflects the current state
of affairs as people see it might provide some interesting perspective on
this proposal. I would welcome that.

Greg: With no other direct comments appearing to be inbound I'd like to
move forward with this one and get a number assigned to it. Thanks!

Thanks to all for the discussion!

On Fri, Sep 4, 2015 at 2:45 PM, Luke Dashjr  wrote:

> On Friday, September 04, 2015 9:36:42 PM Andy Chase wrote:
> > I understand your concerns. What kinds of changes do you think should go
> > through a process like this? Just hard forks?
>
> The process loses meaning if it doesn't reflect reality. So only hardforks
> should go through the hardfork process; only softforks through the softfork
> process; etc. Trying to make one-size-fits-all just means de facto accepted
> BIPs wouldn't be recognised as such because nobody cares to meet the higher
> requirements.
>
> Luke
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process

[Btc Drak via bitcoin-dev]

I'm rather perplexed about this proposal. What exactly is wrong with
the existing BIPs process? I mean, it seems to me anyone can publish a
BIP pretty easily in the BIPs repository. There doesnt seems to be any
real barrier to entry whatsoever. I know there have been all manner of
aspersions, but having just written two BIPs there was no friction at
all.

Whether the ecosystem adopts a BIP is another question of course, but
that's out of scope of the BIPs project anyhow. Take BIP101
controversial as it gets, but it's there. Whether Bitcoin implementers
implement it is another kettle of fish and a matter for each project
to decide. It's absolutely NOT the realm of the BIPs project itself.
Bitcoin Core does not make any consensus critical changes with a BIP.
Where one seeks to establish certain standards, say for privacy, a BIP
would be appropriate so the ecosystem can harmonise methodology across
the board.

The status of a BIP is not really determined by anyone, it's by
adoption - that's where consensus happens. There's a little legroom
around this but I'm not entirely sure what you are trying to solve.
Yes the process is loose, but is it broken? There have been a flood of
BIPs added recently with zero bureaucracy or friction.

BIP0001 is the BIP that defines the BIP process. Interestingly enough
the only BIP that might be controversial is in fact a BIP to change
the way BIPs are handled!

So I'd really prefer to start this conversation with a breakdown of
what you think is broken first before tackling what may or may not
need fixing. I would be very cautious bringing "administrative"
burdens to the process or evicting common sense from the proceedings.
Much of the debates around consensus building seem to negate the
importance of common sense and the simple fact that "it's obvious when
you see it".

I'm sure there can be improvements, but for me personally, I need to
see what is broken before I can make any judgement on a potential way
forward, and if it's not broken, we should leave it alone.


On Fri, Sep 4, 2015 at 5:40 AM, Andy Chase via bitcoin-dev
 wrote:
> As posted:
>
> **Enforcement/Organization** I agree with your comments. I don't believe in
> setting up an organization to manage this process (would be too much power
> and not really needed because the internet is pretty good at information
> sharing). Therefore, I designed it around the assumption that participation
> is voluntary. This means that it's hard to enforce rules like forcing groups
> to see the other side. Groupthink/Echo chambers is real and is bad but it's
> hard to change human nature.
>
> In regards to enforcement, I believe that the best approach would be to
> motivate committees to produce the best opinion they can (and also proof of
> stake, another weak point in this proposal), as the better they can do this
> the more likely the community will accept their opinion as valid and
> important.
>
> Indeed, I believe that without an organization managing the process, it's up
> to each individual reader of each BIP/Opinions set to make the decision on
> whether or not there is clear and true community acceptance.
>
> 
>
> **Committee versus another approach**
>
> Pros of using Committees:
>
> * Committees are used today in many fields with a range of success. Lots of
> previous work to work off of here, history is established.
> * Many segments already have committee-like structures (Merchants produce
> shared signed documents, miners often represent themselves, User groups have
> representatives like voting on subreddit moderators, Core Devs have Core
> Devs)
> * Committees can filter a range of opinions down to a yes/no
> * Committees have real people that can be talked to, contacted, etc.
> * Much easier to proof stake in a range (People generally accept the Bitcoin
> Core has 70-90% of the market share) vs someone trying to proof they make up
> (.01% of the Bitcoin user-base)
> * Committees have some stability, encourages experience and expertise
> (Committee members can be knowledgeable in their area and adequately
> understand BIPs)
>
> Cons:
>
> * Fear of committees working in the dark, censoring opinions (i.e. "Dark
> smokey room of fat cats") (Possible solution: make committee power fluid
> i.e. easily abandon-able: miners can change pools, users can change client
> forks, change merchants, users can re-group, encourage transparency)
> * More centralized, centralization of power (generally bad) (Possible
> solution: encourage smaller committees)
> * Centralization pressure (groups may seek to consolidate to gain power)
> (Possible solution: Segmentation)
> * Encourages groupthink, political maneuvers, turns good people into
> politicians, mud-tossing
>
> **Another possible approach: micro votes**
>
> Pros:
>
> * Each user can represent themselves, no censorship
> * People feel more involved and empowered
>
> Cons:
>
> * How to prove and prevent manipulation?
> * Only 

Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process

[Andy Chase via bitcoin-dev]

Thanks for your thoughts.

My proposal isn't perfect for sure. There's likely much better ways to do
it. But to be clear what I'm trying to solve is basically this:

Who makes high-level Bitcoin decisions? Miners, client devs, merchants, or
users? Let's set up a system where everyone has a say and clear acceptance
can be reached.

---

My motivation for writing this proposal is stated right at the start:
> "The current process for accepting a BIP is not clearly defined. While
BIP-0001 defines the process for writing and submitting a Bitcoin
Improvement Proposal to the community it does not specify the precise
method for which BIPs are considered accepted or rejected."

BIPs are considered "accepted" right now based on an undefined system,
quite honestly. Btc Drak: What's the system for accepting a BIP? Words like
"consensus" come up but they aren't defined. My goal is to define a system
that makes finding "consensus" (I like the word "acceptance" better) in a
clear and fair way.

I.e. what's broken?

* Being sure that a proposal is widely accepted or rejected
* Preventing deadlock (i.e. one person's weak objections preventing
acceptance)
* Receiving feedback from important segments like user groups,
merchants/exchanges, etc. in a systematic and clear way instead of going
and forth or having "oracles" on technical advisory boards.

> Yes the process is loose, but is it broken?

Yes/No. Work gets done with the current process. Work can get done with
this process. The goal is for this process is to be safer/clearer/better
defined way.

> There have been a flood of
> BIPs added recently with zero bureaucracy or friction.

As we move forward, we want to balance the powers in such a way that we may
want to pause a bit before we accept each proposal. 2 weeks for comments +
2 weeks for opinions will slow things down, but it shouldn't stall
meaningful work. I used 4 weeks for the process with the understanding that
most proposals are clear and easily acceptable. Controversial proposals
will likely need more time and thus will likely have be submitted at least
twice to discover a clear response.

"Accepting" a BIP means just that: It's accepted. What's acceptance mean?
This proposal provides an answer.

Client implementations, users, miners, and merchants can feel safe
implementing and using a feature that has clear acceptance. This process
isn't meant to force anything on client implementors, users, miners, or
merchants.

On Fri, Sep 4, 2015 at 12:20 PM, Btc Drak  wrote:

> I'm rather perplexed about this proposal. What exactly is wrong with
> the existing BIPs process? I mean, it seems to me anyone can publish a
> BIP pretty easily in the BIPs repository. There doesnt seems to be any
> real barrier to entry whatsoever. I know there have been all manner of
> aspersions, but having just written two BIPs there was no friction at
> all.
>
> Whether the ecosystem adopts a BIP is another question of course, but
> that's out of scope of the BIPs project anyhow. Take BIP101
> controversial as it gets, but it's there. Whether Bitcoin implementers
> implement it is another kettle of fish and a matter for each project
> to decide. It's absolutely NOT the realm of the BIPs project itself.
> Bitcoin Core does not make any consensus critical changes with a BIP.
> Where one seeks to establish certain standards, say for privacy, a BIP
> would be appropriate so the ecosystem can harmonise methodology across
> the board.
>
> The status of a BIP is not really determined by anyone, it's by
> adoption - that's where consensus happens. There's a little legroom
> around this but I'm not entirely sure what you are trying to solve.
> Yes the process is loose, but is it broken? There have been a flood of
> BIPs added recently with zero bureaucracy or friction.
>
> BIP0001 is the BIP that defines the BIP process. Interestingly enough
> the only BIP that might be controversial is in fact a BIP to change
> the way BIPs are handled!
>
> So I'd really prefer to start this conversation with a breakdown of
> what you think is broken first before tackling what may or may not
> need fixing. I would be very cautious bringing "administrative"
> burdens to the process or evicting common sense from the proceedings.
> Much of the debates around consensus building seem to negate the
> importance of common sense and the simple fact that "it's obvious when
> you see it".
>
> I'm sure there can be improvements, but for me personally, I need to
> see what is broken before I can make any judgement on a potential way
> forward, and if it's not broken, we should leave it alone.
>
>
> On Fri, Sep 4, 2015 at 5:40 AM, Andy Chase via bitcoin-dev
>  wrote:
> > As posted:
> >
> > **Enforcement/Organization** I agree with your comments. I don't believe
> in
> > setting up an organization to manage this process (would be too much
> power
> > and not really needed because the internet is pretty good at 

Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process

[Peter Todd via bitcoin-dev]

On Fri, Sep 04, 2015 at 01:13:18PM -0700, Andy Chase via bitcoin-dev wrote:
> Thanks for your thoughts.
> 
> My proposal isn't perfect for sure. There's likely much better ways to do
> it. But to be clear what I'm trying to solve is basically this:
> 
> Who makes high-level Bitcoin decisions? Miners, client devs, merchants, or
> users? Let's set up a system where everyone has a say and clear acceptance
> can be reached.

It depends on a case-by-case basis.

E.g. for soft-forks miners can do what they want with little ability for
other parties to have a say. For non-consensus-related standards - e.g.
address formats - it's quite possible for a BIP to be "accepted" even if
only a small group of users use the standard. For hard-forks almost
everyone is involved, though who can stop a fork isn't as well defined.

IMO trying to "set up a system" in that kind of environment is silly,
and likely to be a bureaucratic waste of time. Let the market decide, as
has happened previously. If you're idea isn't getting acceptance, do a
better job of convincing the people who need to adopt it that it is a
good idea.

No amount of words on paper will change the fact that we can't force
people to run software they don't want to run. The entire formal part of
the BIP process is simply a convenience so we have clear, short, numbers
that we can refer to when discussing ideas and standards. The rest of
the process - e.g. what Adam Back and others have been referring to when
attempting to dissuade Hearn and Andresen - is by definition always
going to be a fuzzy, situation-specific, and generally undefined
process.

Or put another way, even if you did create your proposed process, the
first time those committees "approved" a BIP that relevant stakeholders
disagreed with, you'd find out pretty quickly that "clear acceptance" of
your 4% sample would fall apart the moment the other 96% realized what a
tiny minority was intending to do. Particularly if it was one of the
inhernet cases where the underlying math means a particular group - like
miners - has the ability to override what another group wants out of
Bitcoin.

-- 
'peter'[:-1]@petertodd.org
10f9e95aff6454fedb9d0a4b92a4108e9449c507936f9f18


signature.asc
Description: Digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process

[Luke Dashjr via bitcoin-dev]

On Friday, September 04, 2015 8:13:18 PM Andy Chase via bitcoin-dev wrote:
> Who makes high-level Bitcoin decisions? Miners, client devs, merchants, or
> users? Let's set up a system where everyone has a say and clear acceptance
> can be reached.

For hardforks (removing consensus rules), economic consensus: people who 
accept payment in bitcoins weighted by their actual volume of such payments. 
A supermajority subset may arguably be sufficient for some hardforks (which 
don't violate Bitcoin's social contract) since they can effectively compel 
the remaining economy to comply.

For softforks (adding consensus rules), a majority of miners: they can "51% 
attack" miners who don't go along with it.

Anything else does not necessarily need universal agreement, so are 
completely up to the whim of individual software projects. If someone doesn't 
like a decision in Core (for example), they can safely fork the code. If any 
significant amount of people use their fork, then the BIP is accepted whether 
or not Core later adopts it.

Note this "system" is really describing a lack of a system - that is, what 
naturally must happen for changes to occur. Softforks have a relatively 
mature technical method for measuring support and deploying (which I believe 
someone else is already working on a BIP describing), but the same thing is 
impractical for hardforks. Some formal way to measure actual economic 
acceptance seems like a good idea to study, but it needs to be reasonably 
accurate so as to not change the outcome from its natural/necessary result.

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process

[Andy Chase via bitcoin-dev]

I understand your concerns. What kinds of changes do you think should go
through a process like this? Just hard forks?

I was thinking that an advantage of making all BIPs use this process is
that it makes it familiar and well used. Kinda like a muscle grows stronger
with use. If only hard forks go through the process then there's the risk
that the process has to be spun up whenever they happen which might cause
confusion.

Another reason I was thinking is that even small, local changes, it doesn't
hurt to have a few more people take a look at it and approve it.

The bureaucracy only applies to BIPs, not PRs. There's only been 18
approved/final/accepted BIPs in 4 years since BIP-0001. That's only about
~5 per year. I get that bureaucracy is often a waste of time, but I just
don't think every second counts for these things.

On Fri, Sep 4, 2015 at 2:01 PM, Luke Dashjr  wrote:

> On Friday, September 04, 2015 8:13:18 PM Andy Chase via bitcoin-dev wrote:
> > Who makes high-level Bitcoin decisions? Miners, client devs, merchants,
> or
> > users? Let's set up a system where everyone has a say and clear
> acceptance
> > can be reached.
>
> For hardforks (removing consensus rules), economic consensus: people who
> accept payment in bitcoins weighted by their actual volume of such
> payments.
> A supermajority subset may arguably be sufficient for some hardforks (which
> don't violate Bitcoin's social contract) since they can effectively compel
> the remaining economy to comply.
>
> For softforks (adding consensus rules), a majority of miners: they can "51%
> attack" miners who don't go along with it.
>
> Anything else does not necessarily need universal agreement, so are
> completely up to the whim of individual software projects. If someone
> doesn't
> like a decision in Core (for example), they can safely fork the code. If
> any
> significant amount of people use their fork, then the BIP is accepted
> whether
> or not Core later adopts it.
>
> Note this "system" is really describing a lack of a system - that is, what
> naturally must happen for changes to occur. Softforks have a relatively
> mature technical method for measuring support and deploying (which I
> believe
> someone else is already working on a BIP describing), but the same thing is
> impractical for hardforks. Some formal way to measure actual economic
> acceptance seems like a good idea to study, but it needs to be reasonably
> accurate so as to not change the outcome from its natural/necessary result.
>
> Luke
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process

[Luke Dashjr via bitcoin-dev]

On Friday, September 04, 2015 9:36:42 PM Andy Chase wrote:
> I understand your concerns. What kinds of changes do you think should go
> through a process like this? Just hard forks?

The process loses meaning if it doesn't reflect reality. So only hardforks 
should go through the hardfork process; only softforks through the softfork 
process; etc. Trying to make one-size-fits-all just means de facto accepted 
BIPs wouldn't be recognised as such because nobody cares to meet the higher 
requirements.

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process

[Bryan Bishop via bitcoin-dev]

On Thu, Sep 3, 2015 at 7:30 PM, Andy Chase via bitcoin-dev
 wrote:
> I wrote the BIP mostly to stir the pot on ideas of governance

Some quick comments:

I have some objects that I am not ready to put into words, but I do
think there are easily some major objections to committee design. If I
vanish and never respond with my objections, perhaps there's an IETF
RFC about this already

Something that may mitigate my possible objections would be some
mandatory requirement about ecosystem echo-chambers making many
attempts and efforts at steelman representations of alternative
viewpoints. Understanding objections at a fundamental level, enough to
make strong steelman statements, is very important to ensure that the
competing opinions are not censored from consideration. Pathological
integration and internalization of these steelman arguments can be
very useful, even if the process looks unusual.

Your process does not have to replace any particular BIP process
as-is, but rather could be an alternative that proceeds on its own
perhaps indefinitely without replacement. I don't think too many BIP
processes are necessarily incompatible except by namespace collision.

https://gist.github.com/andychase/dddb83c294295879308b#gistcomment-1566432

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process

[Andy Chase via bitcoin-dev]

> Any such a BIP like this needs to
> document the natural forces involved in real-world acceptance, not try to
lay
> down "rules" that people are expected to follow.

That's my goal: to take the hodgepodge of we already use for acceptance,
and apply rules that allow true acceptance to be identified in a clearer
way.

If people don't follow the "rules" then the system simply won't work, this
is mentioned in the last section.

On Thu, Sep 3, 2015 at 5:41 PM, Luke Dashjr  wrote:

> On Friday, September 04, 2015 12:30:50 AM Andy Chase via bitcoin-dev wrote:
> > Here's a BIP. I wrote the BIP mostly to stir the pot on ideas of
> > governance, but I’m moderately serious about it.
>
> Sigh. There is *no governance at all*. Any such a BIP like this needs to
> document the natural forces involved in real-world acceptance, not try to
> lay
> down "rules" that people are expected to follow.
>
> For hardforks, that means economic consensus. For softforks, miner
> majority.
> For basically anything else, real-world implementation and use (by any
> significant quantity of people).
>
> Luke
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process

[Luke Dashjr via bitcoin-dev]

On Friday, September 04, 2015 12:30:50 AM Andy Chase via bitcoin-dev wrote:
> Here's a BIP. I wrote the BIP mostly to stir the pot on ideas of
> governance, but I’m moderately serious about it.

Sigh. There is *no governance at all*. Any such a BIP like this needs to 
document the natural forces involved in real-world acceptance, not try to lay 
down "rules" that people are expected to follow.

For hardforks, that means economic consensus. For softforks, miner majority. 
For basically anything else, real-world implementation and use (by any 
significant quantity of people).

Luke
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev