* [bitcoin-dev] [BIP/Draft] BIP Acceptance Process
@ 2015-09-04 0:30 Andy Chase
2015-09-04 0:41 ` Luke Dashjr
2015-09-04 0:43 ` Bryan Bishop
0 siblings, 2 replies; 21+ messages in thread
From: Andy Chase @ 2015-09-04 0:30 UTC (permalink / raw)
To: gmaxwell, bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 9487 bytes --]
Here’s a BIP. I wrote the BIP mostly to stir the pot on ideas of governance, but I’m moderately serious about it. This is set in Markdown for readability, but here’s the BIP-0001 Medawiki version: https://gist.github.com/andychase/dddb83c294295879308b <https://gist.github.com/andychase/dddb83c294295879308b>
Title: BIP Acceptance Process
Author: Andy Chase
Status: Draft
Type: Process
Created: 2015-08-31
Abstract
========
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.
This BIP has two parts:
- It sets up a process which a BIP goes through for comments
and acceptance.
- The Process is:
- BIP Draft
- Submitted for comments (2 weeks)
- Waiting on opinion (two weeks)
- Accepted or Deferred
- It sets up committees for reviewing comments and indicating
acceptance under precise conditions.
- 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.
BIP acceptance is defined as at least 70% of the represented percentage
stake in 3 out of the 4 Bitcoin segments.
Copyright
=========
This document is placed into the public domain.
Motivation
==========
BIPs represent important improvements to Bitcoin infrastructure, and in
order to foster continued innovation, the BIP process must have clearly
defined stages and acceptance acknowledgement.
Rationale
=========
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.
Weaknesses
==========
Each committee submits a declaration including their claim to represent
a certain percentage of the Bitcoin ecosystem in some way. Though
guidelines are given, it's up to each committee to prove their stake,
and it's up to the reader of the opinions to decide if a BIP was truly
accepted or rejected.
The author doesn't believe this is a problem because a BIP cannot be
forced on client authors, miners, merchants, or users. Ultimately this
BIP is a tool for determining whether a BIP is overwhelmingly accepted.
If one committee's validity claim becomes the factor that decides
whether the BIP will succeed or fail, this process simply didn't return
a clear answer and the BIP should be considered deferred.
Process
=======
- **Submit for Comments.** The first BIP champion named in the
proposal can call a "submit for comments" at any time by posting to
the [Dev Mailing
List](https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>)
mailling with the BIP number and a statement that the champion
intends to immediately submit the BIP for comments.
- The BIP must have been assigned BIP-number (i.e. been approved
by the BIP editor) to be submitted for comments.
- **Comments.**
- After a BIP has been submitted for comments, a two-week waiting
period begins in which the community should transition from
making suggestions about a proposal to publishing their opinions
or concerns on the proposal.
- **Reported Opinions.**
- After the waiting period has past, committees must submit a
summary of the comments which they have received from their
represented communities.
- The deadline for this opinion is four weeks after the BIP was
submitted for comments.
- Committees cannot reverse their decision after the deadline, but
at their request may flag their decision as "likely to change if
another submit for comments is called". Committees can change
their decision if a resubmit is called.
- Opinions must include:
- One of the following statements: "Intend to accept", "Intent
to implement", "Decline to accept", "Intend to accept, but
decline to implement".
- If rejected, the opinion must cite clear and specific
reasons for rejecting including a checklist for what must
happen or be change for their committee to accept
the proposal.
- If accepted, the committee must list why they accepted the
proposal and also include concerns they have or what about
the BIP that, if things changed, would cause the committee
to likely reverse their decision if another submit for
comments was called.
- **Accepted.**
- If at least 70% of the represented percentage stake in 3 out of
4 segments accept a proposal, a BIP is considered accepted.
- If a committee fails to submit an opinion, consider the
opinion "Decline to accept".
- The BIP cannot be substantially changed at this point, but can
be replaced. Minor changes or clarifications are allowed but
must be recorded in the document.
- **Deferred.**
- The acceptance test above is not met, a BIP is sent back
into suggestions.
- BIP can be modified and re-submitted for a comments no sooner
than two months after the date of the previous submit for
comments is called.
- A BIP is marked rejected after two failed submission attempts. A
rejected BIP can still be modified and re-submitted.
Committees
==========
**BIP Committees.**
- BIP Committees are representational structures that represent
critical segments of the Bitcoin ecosystem.
- Each committee must prove and maintain a clear claim that they
represent at least 1% of the Bitcoin ecosystem in some form.
- If an organization or community does not meet that requirement,
it should conglomerate itself with other communities and
organizations so that it does.
- The segments that committees can be based around are:
- Bitcoin software
- Merchants/services/payment processors
- Mining operators
- User communities
- A person may be represented by any number of segments, but a
committee cannot re-use the same resource as another committee in
the same segment.
- **Committee Declarations.** At any point, a Committee Declaration
can be posted.
- This Declaration contain details about:
- The segment the Committee is representing
- Who the committee claim to represent and it's compositional
makeup (if made up of multiple miner orgs, user orgs, companies,
clients, etc).
- Proof of claim and minimum 1% stake via:
- Software: proof of ownership and user base (Min 1% of
Bitcoin userbase)
- Merchant: proof of economic activity (Min 1% of Bitcoin
economic activity)
- Mining: proof of work (Min 1% of Hashpower)
- For a user organization, auditable signatures qualifies for
a valid committee (Min 1% of Bitcoin userbase)
- Who is running the committee, their names and roles
- How represented members can submit comments to the committee
- A code of conduct and code of ethics which the committee
promises to abide by
- A committee declaration is accepted if:
- The declaration includes all of the required elements
- The stake is considered valid
- Committee validation is considered when considering the results of
opinions submitted by committee on a BIP. A committee must have met
the required stake percentage before a BIP is submitted for
comments, and have maintained that stake until a valid opinion
is submitted.
- Committees can dissolve at any time or submit a declaration at
any time
- Declaration must have been submitted no later than the third day
following a BIP's request for comments to be eligible for
inclusion in a BIP
BIP Process Management Role
===========================
BIPs, Opinions, and Committee Declaration must be public at all times.
A BIP Process Manager should be chosen who is in charge of:
- Declaring where and how BIPs, Opinions, and Committee Declaration
should be posted and updated officially.
- Maintaining the security and authenticity of BIPs, Opinions, and
Committee Declarations
- Publishing advisory documents about what kinds of proof of stakes
are valid and what kinds should be rejected.
- Naming a series of successors for the roles of the BIP Process
Manager and BIP Editor (BIP-001) as needed.
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.
[-- Attachment #2: Type: text/html, Size: 14983 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process
2015-09-04 0:30 [bitcoin-dev] [BIP/Draft] BIP Acceptance Process Andy Chase
@ 2015-09-04 0:41 ` Luke Dashjr
2015-09-04 0:52 ` Andy Chase
2015-09-04 0:43 ` Bryan Bishop
1 sibling, 1 reply; 21+ messages in thread
From: Luke Dashjr @ 2015-09-04 0:41 UTC (permalink / raw)
To: bitcoin-dev, Andy Chase
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process
2015-09-04 0:30 [bitcoin-dev] [BIP/Draft] BIP Acceptance Process Andy Chase
2015-09-04 0:41 ` Luke Dashjr
@ 2015-09-04 0:43 ` Bryan Bishop
2015-09-04 4:40 ` Andy Chase
1 sibling, 1 reply; 21+ messages in thread
From: Bryan Bishop @ 2015-09-04 0:43 UTC (permalink / raw)
To: Andy Chase, Bryan Bishop; +Cc: Bitcoin Dev
On Thu, Sep 3, 2015 at 7:30 PM, Andy Chase via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> 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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process
2015-09-04 0:41 ` Luke Dashjr
@ 2015-09-04 0:52 ` Andy Chase
0 siblings, 0 replies; 21+ messages in thread
From: Andy Chase @ 2015-09-04 0:52 UTC (permalink / raw)
To: Luke Dashjr, bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 1144 bytes --]
> 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 <luke@dashjr•org> 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
>
[-- Attachment #2: Type: text/html, Size: 1628 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process
2015-09-04 0:43 ` Bryan Bishop
@ 2015-09-04 4:40 ` Andy Chase
2015-09-04 19:20 ` Btc Drak
0 siblings, 1 reply; 21+ messages in thread
From: Andy Chase @ 2015-09-04 4:40 UTC (permalink / raw)
To: Bryan Bishop, bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 4294 bytes --]
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 (.000001% 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 motivated people will contribute. Motivated people may be motivated
for bad reasons.
On Thu, Sep 3, 2015 at 5:43 PM, Bryan Bishop <kanzure@gmail•com> wrote:
> On Thu, Sep 3, 2015 at 7:30 PM, Andy Chase via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> 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
>
[-- Attachment #2: Type: text/html, Size: 5473 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process
2015-09-04 4:40 ` Andy Chase
@ 2015-09-04 19:20 ` Btc Drak
2015-09-04 20:13 ` Andy Chase
0 siblings, 1 reply; 21+ messages in thread
From: Btc Drak @ 2015-09-04 19:20 UTC (permalink / raw)
To: Andy Chase; +Cc: 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
<bitcoin-dev@lists•linuxfoundation.org> 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
> (.000001% 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 motivated people will contribute. Motivated people may be motivated
> for bad reasons.
>
>
> On Thu, Sep 3, 2015 at 5:43 PM, Bryan Bishop <kanzure@gmail•com> wrote:
>>
>> On Thu, Sep 3, 2015 at 7:30 PM, Andy Chase via bitcoin-dev
>> <bitcoin-dev@lists•linuxfoundation.org> 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
>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process
2015-09-04 19:20 ` Btc Drak
@ 2015-09-04 20:13 ` Andy Chase
2015-09-04 20:31 ` Peter Todd
` (2 more replies)
0 siblings, 3 replies; 21+ messages in thread
From: Andy Chase @ 2015-09-04 20:13 UTC (permalink / raw)
To: Btc Drak, bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 9628 bytes --]
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 <btcdrak@gmail•com> 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
> <bitcoin-dev@lists•linuxfoundation.org> 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
> > (.000001% 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 motivated people will contribute. Motivated people may be
> motivated
> > for bad reasons.
> >
> >
> > On Thu, Sep 3, 2015 at 5:43 PM, Bryan Bishop <kanzure@gmail•com> wrote:
> >>
> >> On Thu, Sep 3, 2015 at 7:30 PM, Andy Chase via bitcoin-dev
> >> <bitcoin-dev@lists•linuxfoundation.org> 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
> >
>
[-- Attachment #2: Type: text/html, Size: 12448 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process
2015-09-04 20:13 ` Andy Chase
@ 2015-09-04 20:31 ` Peter Todd
2015-09-04 20:42 ` Martin Becze
2015-09-04 21:05 ` Milly Bitcoin
2015-09-04 21:01 ` Luke Dashjr
2015-09-07 19:37 ` Btc Drak
2 siblings, 2 replies; 21+ messages in thread
From: Peter Todd @ 2015-09-04 20:31 UTC (permalink / raw)
To: Andy Chase; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 2268 bytes --]
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
000000000000000010f9e95aff6454fedb9d0a4b92a4108e9449c507936f9f18
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process
2015-09-04 20:31 ` Peter Todd
@ 2015-09-04 20:42 ` Martin Becze
2015-09-04 21:05 ` Milly Bitcoin
1 sibling, 0 replies; 21+ messages in thread
From: Martin Becze @ 2015-09-04 20:42 UTC (permalink / raw)
To: Peter Todd; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 2650 bytes --]
>> Let the market decide
How about Futarchy?
On Fri, Sep 4, 2015 at 8:31 PM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> 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
> 000000000000000010f9e95aff6454fedb9d0a4b92a4108e9449c507936f9f18
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
[-- Attachment #2: Type: text/html, Size: 3665 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process
2015-09-04 20:13 ` Andy Chase
2015-09-04 20:31 ` Peter Todd
@ 2015-09-04 21:01 ` Luke Dashjr
2015-09-04 21:36 ` Andy Chase
2015-09-07 19:37 ` Btc Drak
2 siblings, 1 reply; 21+ messages in thread
From: Luke Dashjr @ 2015-09-04 21:01 UTC (permalink / raw)
To: bitcoin-dev, Andy Chase
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process
2015-09-04 20:31 ` Peter Todd
2015-09-04 20:42 ` Martin Becze
@ 2015-09-04 21:05 ` Milly Bitcoin
1 sibling, 0 replies; 21+ messages in thread
From: Milly Bitcoin @ 2015-09-04 21:05 UTC (permalink / raw)
To: bitcoin-dev, pete
> IMO trying to "set up a system" in that kind of environment is silly,
The first step is to define the system that is currently in place.
There is a system in place but it is just close to the vest and
sometimes not discussed in public. This works when Bitcoin has a small
number of stakeholder but does not work well as other parties with
diverse interests get involved. You can't expect major players to
invest large sums when the process is controlled by a tiny group of
people where some of those people have rather unusual opinions about
things and limited experience outside of technical areas within Bitcoin.
You just don't have enough experience in working on large projects to
understand the benefits of the proposal discussed. I suggest you look
into into and get some experience instead of posting rants that
highlight your inexperience. What is silly is using a process that
involves hyperbolic twitter and reddit posts.
Basically such a process does not replace the analysis that is done now,
it just makes it transparent and attempts to make it consistent so there
is not all this confusion over comparing apples and oranges. Here is
link that discusses some of the benefits and limitations of doing this:
http://www.jakeman.com.au/media/whats-right-with-risk-matrices.
Russ
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process
2015-09-04 21:01 ` Luke Dashjr
@ 2015-09-04 21:36 ` Andy Chase
2015-09-04 21:45 ` Luke Dashjr
0 siblings, 1 reply; 21+ messages in thread
From: Andy Chase @ 2015-09-04 21:36 UTC (permalink / raw)
To: Luke Dashjr, bitcoin-dev, pete
[-- Attachment #1: Type: text/plain, Size: 2535 bytes --]
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 <luke@dashjr•org> 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
>
[-- Attachment #2: Type: text/html, Size: 3158 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process
2015-09-04 21:36 ` Andy Chase
@ 2015-09-04 21:45 ` Luke Dashjr
2015-09-05 21:19 ` Andy Chase
0 siblings, 1 reply; 21+ messages in thread
From: Luke Dashjr @ 2015-09-04 21:45 UTC (permalink / raw)
To: Andy Chase; +Cc: 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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process
2015-09-04 21:45 ` Luke Dashjr
@ 2015-09-05 21:19 ` Andy Chase
[not found] ` <CAHv+tb5ksyZKp5jLvmzFbD2vBOUrWn6ps80ODECVRqYj8m=PZA@mail.gmail.com>
2016-01-19 2:12 ` Luke Dashjr
0 siblings, 2 replies; 21+ messages in thread
From: Andy Chase @ 2015-09-05 21:19 UTC (permalink / raw)
To: Luke Dashjr, gmaxwell; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 962 bytes --]
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 <luke@dashjr•org> 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
>
[-- Attachment #2: Type: text/html, Size: 1430 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process
[not found] ` <CAHv+tb5ksyZKp5jLvmzFbD2vBOUrWn6ps80ODECVRqYj8m=PZA@mail.gmail.com>
@ 2015-09-06 20:44 ` Andy Chase
0 siblings, 0 replies; 21+ messages in thread
From: Andy Chase @ 2015-09-06 20:44 UTC (permalink / raw)
To: Thomas Kerin, bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 3195 bytes --]
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 <thomas.kerin@gmail•com> 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 <luke@dashjr•org> 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
>>
>>
[-- Attachment #2: Type: text/html, Size: 4784 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process
2015-09-04 20:13 ` Andy Chase
2015-09-04 20:31 ` Peter Todd
2015-09-04 21:01 ` Luke Dashjr
@ 2015-09-07 19:37 ` Btc Drak
2015-09-10 1:21 ` Andy Chase
2 siblings, 1 reply; 21+ messages in thread
From: Btc Drak @ 2015-09-07 19:37 UTC (permalink / raw)
To: Andy Chase; +Cc: 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 off topic or
nonsensical, there is no grounds to refuse to publish it.
Any part of your proposal which seems to infer governance of Bitcoin
is misplaced because it's not the place of BIPs. The Bitcoin Core
project is not the BIPs project and their rules are their own. They
are one implementation, and very influential one yes, but, not the one
true implementation to rule them all.
Where I do think the BIP-1 text falls down is with the workflow of
ACCEPTED/REJECTED because it does not really define who is accepting
and rejecting what and misses much of the reality of the process in
the real world. Given the purpose of BIPs is a formal way to
communicate technical proposals to the bitcoin community (i.e.
implementers and protocol consumers) the work flow needs to be
adjusted.
Anyone can submit a proposal and the state of the proposal can be
DRAFT or WITHDRAWN but draft here is confusing. Draft would suggest
it's a work in progress, but the proposal is "complete" when the
proposer is happy with the final text. Downstream implementers should
not attempt to write code (in my opinion) until the proposal has been
finalised by the authors. Only the author has the right to say when
their proposal is finished.
The states of Accepted / Rejected are easy for consensus critical
changes, especially once versionbits softforking is enacted and
proposals will have a timeout associated. Certainly for deployed
proposals you could say the proposal is "active" or better still
"pending approval". However "accepted" and "rejected" is difficult for
say privacy standards because how can you gauge or measure it. As I
said earlier, you might have a lot of small projects implementing some
privacy standards, but if the major wallets dont, and thus the
majority of users, how would you gauge it?
Something is a standard only when it becomes a standard by virtue of
having become a standard :)
"Replaced" is an easy state, when another proposal supercedes and
replaces an older one. Again the wording could be better here.
"deprecated" would also be appropriate in some circumstances.
I'm not making a concrete proposal, I'm just highlighting where BIP-1
sort of falls apart because of an incongruence with the workflow
states and what actually happens in real life.
Local to the BIPs project, I do think the BIPs editor, and guidelines
try to filter proposals by raising the bar: i.e. requiring proposal to
be polished through peer review before they are formally published as
draft BIPs. Though this process an author would a) get most of his
details right first time, and b) have some relative confidence his/her
idea was useful and withdraw any obvious bad proposals themselves. An
author may still decide, despite many objections from their peers they
want to proceed with publishing and nothing should stop them providing
it's relevant to the Bitcoin space. Peer review pressure is likely to
act as the best filtering mechanism in this case anyway (no-one would
want to be seen as an ass right?). Personally speaking, I felt quite
nervous proposing my own blocksize ideas. I sought opinions in private
first and had it been widely decried would probably not have pursued
it any further.
So in summary, I think some aspects of BIP-1 could do with polishing
as I have detailed, specially around the "workflow states" but not to
introduce any committees to the process, but where possible to extract
state from the real state of the BIP in the real world. In fact, this
is my direct argument against any forms of committee, in that the
state of a BIP is determined by factors outside of any particular
individual's or groups' purview.
On Fri, Sep 4, 2015 at 9:13 PM, Andy Chase <theandychase@gmail•com> 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.
>
> ---
>
> 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 <btcdrak@gmail•com> 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
>> <bitcoin-dev@lists•linuxfoundation.org> 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
>> > (.000001% 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 motivated people will contribute. Motivated people may be
>> > motivated
>> > for bad reasons.
>> >
>> >
>> > On Thu, Sep 3, 2015 at 5:43 PM, Bryan Bishop <kanzure@gmail•com> wrote:
>> >>
>> >> On Thu, Sep 3, 2015 at 7:30 PM, Andy Chase via bitcoin-dev
>> >> <bitcoin-dev@lists•linuxfoundation.org> 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
>> >
>
>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process
2015-09-07 19:37 ` Btc Drak
@ 2015-09-10 1:21 ` Andy Chase
2015-09-12 23:50 ` Andy Chase
0 siblings, 1 reply; 21+ messages in thread
From: Andy Chase @ 2015-09-10 1:21 UTC (permalink / raw)
To: Btc Drak, 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 <btcdrak@gmail•com> 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% 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 off topic or
> nonsensical, there is no grounds to refuse to publish it.
>
> Any part of your proposal which seems to infer governance of Bitcoin
> is misplaced because it's not the place of BIPs. The Bitcoin Core
> project is not the BIPs project and their rules are their own. They
> are one implementation, and very influential one yes, but, not the one
> true implementation to rule them all.
>
> Where I do think the BIP-1 text falls down is with the workflow of
> ACCEPTED/REJECTED because it does not really define who is accepting
> and rejecting what and misses much of the reality of the process in
> the real world. Given the purpose of BIPs is a formal way to
> communicate technical proposals to the bitcoin community (i.e.
> implementers and protocol consumers) the work flow needs to be
> adjusted.
>
> Anyone can submit a proposal and the state of the proposal can be
> DRAFT or WITHDRAWN but draft here is confusing. Draft would suggest
> it's a work in progress, but the proposal is "complete" when the
> proposer is happy with the final text. Downstream implementers should
> not attempt to write code (in my opinion) until the proposal has been
> finalised by the authors. Only the author has the right to say when
> their proposal is finished.
>
> The states of Accepted / Rejected are easy for consensus critical
> changes, especially once versionbits softforking is enacted and
> proposals will have a timeout associated. Certainly for deployed
> proposals you could say the proposal is "active" or better still
> "pending approval". However "accepted" and "rejected" is difficult for
> say privacy standards because how can you gauge or measure it. As I
> said earlier, you might have a lot of small projects implementing some
> privacy standards, but if the major wallets dont, and thus the
> majority of users, how would you gauge it?
>
> Something is a standard only when it becomes a standard by virtue of
> having become a standard :)
>
> "Replaced" is an easy state, when another proposal supercedes and
> replaces an older one. Again the wording could be better here.
> "deprecated" would also be appropriate in some circumstances.
>
> I'm not making a concrete proposal, I'm just highlighting where BIP-1
> sort of falls apart because of an incongruence with the workflow
> states and what actually happens in real life.
>
> Local to the BIPs project, I do think the BIPs editor, and guidelines
> try to filter proposals by raising the bar: i.e. requiring proposal to
> be polished through peer review before they are formally published as
> draft BIPs. Though this process an author would a) get most of his
> details right first time, and b) have some relative confidence his/her
> idea was useful and withdraw any obvious bad proposals themselves. An
> author may still decide, despite many objections from their peers they
> want to proceed with publishing and nothing should stop them providing
> it's relevant to the Bitcoin space. Peer review pressure is likely to
> act as the best filtering mechanism in this case anyway (no-one would
> want to be seen as an ass right?). Personally speaking, I felt quite
> nervous proposing my own blocksize ideas. I sought opinions in private
> first and had it been widely decried would probably not have pursued
> it any further.
>
> So in summary, I think some aspects of BIP-1 could do with polishing
> as I have detailed, specially around the "workflow states" but not to
> introduce any committees to the process, but where possible to extract
> state from the real state of the BIP in the real world. In fact, this
> is my direct argument against any forms of committee, in that the
> state of a BIP is determined by factors outside of any particular
> individual's or groups' purview.
>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process
2015-09-10 1:21 ` Andy Chase
@ 2015-09-12 23:50 ` Andy Chase
0 siblings, 0 replies; 21+ messages in thread
From: Andy Chase @ 2015-09-12 23:50 UTC (permalink / raw)
To: 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 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..
On Wed, Sep 9, 2015 at 6:21 PM, Andy Chase <theandychase@gmail•com> wrote:
> 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 <btcdrak@gmail•com> 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% 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 off topic or
>> nonsensical, there is no grounds to refuse to publish it.
>>
>> Any part of your proposal which seems to infer governance of Bitcoin
>> is misplaced because it's not the place of BIPs. The Bitcoin Core
>> project is not the BIPs project and their rules are their own. They
>> are one implementation, and very influential one yes, but, not the one
>> true implementation to rule them all.
>>
>> Where I do think the BIP-1 text falls down is with the workflow of
>> ACCEPTED/REJECTED because it does not really define who is accepting
>> and rejecting what and misses much of the reality of the process in
>> the real world. Given the purpose of BIPs is a formal way to
>> communicate technical proposals to the bitcoin community (i.e.
>> implementers and protocol consumers) the work flow needs to be
>> adjusted.
>>
>> Anyone can submit a proposal and the state of the proposal can be
>> DRAFT or WITHDRAWN but draft here is confusing. Draft would suggest
>> it's a work in progress, but the proposal is "complete" when the
>> proposer is happy with the final text. Downstream implementers should
>> not attempt to write code (in my opinion) until the proposal has been
>> finalised by the authors. Only the author has the right to say when
>> their proposal is finished.
>>
>> The states of Accepted / Rejected are easy for consensus critical
>> changes, especially once versionbits softforking is enacted and
>> proposals will have a timeout associated. Certainly for deployed
>> proposals you could say the proposal is "active" or better still
>> "pending approval". However "accepted" and "rejected" is difficult for
>> say privacy standards because how can you gauge or measure it. As I
>> said earlier, you might have a lot of small projects implementing some
>> privacy standards, but if the major wallets dont, and thus the
>> majority of users, how would you gauge it?
>>
>> Something is a standard only when it becomes a standard by virtue of
>> having become a standard :)
>>
>> "Replaced" is an easy state, when another proposal supercedes and
>> replaces an older one. Again the wording could be better here.
>> "deprecated" would also be appropriate in some circumstances.
>>
>> I'm not making a concrete proposal, I'm just highlighting where BIP-1
>> sort of falls apart because of an incongruence with the workflow
>> states and what actually happens in real life.
>>
>> Local to the BIPs project, I do think the BIPs editor, and guidelines
>> try to filter proposals by raising the bar: i.e. requiring proposal to
>> be polished through peer review before they are formally published as
>> draft BIPs. Though this process an author would a) get most of his
>> details right first time, and b) have some relative confidence his/her
>> idea was useful and withdraw any obvious bad proposals themselves. An
>> author may still decide, despite many objections from their peers they
>> want to proceed with publishing and nothing should stop them providing
>> it's relevant to the Bitcoin space. Peer review pressure is likely to
>> act as the best filtering mechanism in this case anyway (no-one would
>> want to be seen as an ass right?). Personally speaking, I felt quite
>> nervous proposing my own blocksize ideas. I sought opinions in private
>> first and had it been widely decried would probably not have pursued
>> it any further.
>>
>> So in summary, I think some aspects of BIP-1 could do with polishing
>> as I have detailed, specially around the "workflow states" but not to
>> introduce any committees to the process, but where possible to extract
>> state from the real state of the BIP in the real world. In fact, this
>> is my direct argument against any forms of committee, in that the
>> state of a BIP is determined by factors outside of any particular
>> individual's or groups' purview.
>>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process
2015-09-05 21:19 ` Andy Chase
[not found] ` <CAHv+tb5ksyZKp5jLvmzFbD2vBOUrWn6ps80ODECVRqYj8m=PZA@mail.gmail.com>
@ 2016-01-19 2:12 ` Luke Dashjr
2016-01-19 4:23 ` Andy Chase
2016-01-19 6:07 ` Dave Scotese
1 sibling, 2 replies; 21+ messages in thread
From: Luke Dashjr @ 2016-01-19 2:12 UTC (permalink / raw)
To: Andy Chase; +Cc: bitcoin-dev, gmaxwell
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process
2016-01-19 2:12 ` Luke Dashjr
@ 2016-01-19 4:23 ` Andy Chase
2016-01-19 6:07 ` Dave Scotese
1 sibling, 0 replies; 21+ messages in thread
From: Andy Chase @ 2016-01-19 4:23 UTC (permalink / raw)
To: Luke Dashjr; +Cc: Bitcoin Dev, gmaxwell
[-- Attachment #1: Type: text/plain, Size: 6113 bytes --]
Thanks for your comments Luke.
> Are you saying your proposal is intentionally not intended to reflect the
reality?
That's right. I want to be able to include more voices and be able to get a
clearer idea of acceptance then the process currently has available.
This process should work alongside the current one; not replace it.
> conditions under which a proposal is *known to be* accepted by the
community
*known to be* Is what I'm working towards; yes; but I think we need
additional tools/processes to determine that then what we currently have
available.
> As mentioned, IMO a committee shouldn't be indicating acceptance, as much
as
it should be *determining* acceptance.
The committee determine acceptance when taking their opinions in aggregate.
The source of their indication might be similar to what we currently have
(esp for Core Devs, etc.)
> That sounds very time consuming
Ok
> And what happens if these committees don't represent the community?
The committee structures are fluid-- that is users are able to re-organize
at any time.
> What about when only part of the community - let's say 10% - decides to
adopt a BIP that doesn't require consensus
This might happen, but is not a flaw in my process. My process makes it
clear they are going against the acceptance of the rest of the community. I
don't intend to "force" anyone to implement or use an accepted BIP. If that
is desired that's outside the scope of this BIP.
> But the Bitcoin user base is completely unknown, and tracking software
user base is a privacy violation.
I made a suggestion for this here:
https://gist.github.com/andychase/dddb83c294295879308b
If there are other ways for honest but anonymous voting mechanisms (that
aren't proof-of-stake since that's proof-of-most-money) I'd be all ears.
> Bitcoin economic activity is also unknown
> This needs a proper specification. How do miners express their positions?
I agree these are flaws in the proposal. I'm not sure that one way of
indicating should be considered valid forever, but may have to change over
time.
> Chosen how, and by whom?
I think the process could be used to determine this.
> but I don't think we can just let the author set any conditions they like
either
I'm not sure what you mean here but would love more information.
On Mon, Jan 18, 2016 at 6:12 PM, Luke Dashjr <luke@dashjr•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 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
>
[-- Attachment #2: Type: text/html, Size: 9029 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process
2016-01-19 2:12 ` Luke Dashjr
2016-01-19 4:23 ` Andy Chase
@ 2016-01-19 6:07 ` Dave Scotese
1 sibling, 0 replies; 21+ messages in thread
From: Dave Scotese @ 2016-01-19 6:07 UTC (permalink / raw)
To: Luke Dashjr; +Cc: Bitcoin Dev, Gregory Maxwell
[-- Attachment #1: Type: text/plain, Size: 6004 bytes --]
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 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
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
[-- Attachment #2: Type: text/html, Size: 7196 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2016-01-19 6:07 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-09-04 0:30 [bitcoin-dev] [BIP/Draft] BIP Acceptance Process Andy Chase
2015-09-04 0:41 ` Luke Dashjr
2015-09-04 0:52 ` Andy Chase
2015-09-04 0:43 ` Bryan Bishop
2015-09-04 4:40 ` Andy Chase
2015-09-04 19:20 ` Btc Drak
2015-09-04 20:13 ` Andy Chase
2015-09-04 20:31 ` Peter Todd
2015-09-04 20:42 ` Martin Becze
2015-09-04 21:05 ` Milly Bitcoin
2015-09-04 21:01 ` Luke Dashjr
2015-09-04 21:36 ` Andy Chase
2015-09-04 21:45 ` Luke Dashjr
2015-09-05 21:19 ` Andy Chase
[not found] ` <CAHv+tb5ksyZKp5jLvmzFbD2vBOUrWn6ps80ODECVRqYj8m=PZA@mail.gmail.com>
2015-09-06 20:44 ` Andy Chase
2016-01-19 2:12 ` Luke Dashjr
2016-01-19 4:23 ` Andy Chase
2016-01-19 6:07 ` Dave Scotese
2015-09-07 19:37 ` Btc Drak
2015-09-10 1:21 ` Andy Chase
2015-09-12 23:50 ` Andy Chase
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox