From: Luke Dashjr <luke@dashjr•org>
To: Andy Chase <theandychase@gmail•com>
Cc: bitcoin-dev@lists•linuxfoundation.org, gmaxwell@gmail•com
Subject: Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process
Date: Tue, 19 Jan 2016 02:12:29 +0000 [thread overview]
Message-ID: <201601190212.30685.luke@dashjr.org> (raw)
In-Reply-To: <CAAxp-m8JW-WOCem6a4RmBk7HOV3cCc02r5r=BkEDyUBu84u4=A@mail.gmail.com>
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
next prev parent reply other threads:[~2016-01-19 2:13 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-04 0:30 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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201601190212.30685.luke@dashjr.org \
--to=luke@dashjr$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=gmaxwell@gmail$(echo .)com \
--cc=theandychase@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox