path: root/25/531e0592221eb2652fc54c3c4bee7bcb4e3da8

Return-Path: <dscotese@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 660C6AAC
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 19 Jan 2016 06:07:54 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com
	[209.85.214.174])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DACC3EB
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 19 Jan 2016 06:07:52 +0000 (UTC)
Received: by mail-ob0-f174.google.com with SMTP id py5so211157663obc.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 18 Jan 2016 22:07:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:date:message-id:subject
	:from:to:cc:content-type;
	bh=Ulnclb4rwRIZQ6E7vf/Qn62zSsWd7duG4xv1JftjVgw=;
	b=MCq5fNt30svavUTtS1Uz26UqGnilV2KrXenTjDfukfZlKuegm9JVfFD4GT8OxLwZTK
	MgEEpopCMnzngs8jDoxQ7/WVt7BoF1hNosyKZlDB9avZQQTiJOcV5ENu2JHQiK3KTUXo
	/G92PMibUCLl4xoxm/9i4wqkEt00fa7wmpz7FUCiLwsgjHQwgzKbLKMH8ii3jQyLMfZ9
	4T7qPtxHFM6vzzu8VtIhCvF93HQTZFNjaLk2Pr1uKd1JjyY3SAHqZCWUnNePuJrfl5A1
	rkv3JMbr23Cs3azZQcbytyQzfocKWoTpmJMjWMqa216ck5Nc37QeuBORV6Rw440KRVY9
	vUKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:sender:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=Ulnclb4rwRIZQ6E7vf/Qn62zSsWd7duG4xv1JftjVgw=;
	b=fvhoW6pnjCpwA/+dh985wqyFWoA34j1y2vPhmCGCK2/1RPUmGk547rirrNiXbbaJHp
	ngf+WxPGJXOEoHjN6OD3BvJmomuxJCPbM7A/3WlTu3GMChy8OLKhC4q6kXuVRc/Y6tRT
	H57wW2iD7o2Kgx8XOYtUhYi4XFEKqOdBfYf785vWTRG8iz+/c2Zp4xSP4/slQCoAle2F
	6MMcGFGYTs/zKqoPyhoJSE5Yigip8eJfxr79v5lqn8AMy9Qv4LZzvko2YthyhDfjF68m
	MVXJKj7Bl7RDMRg3+aGmpBOK+Tyb/ZfdTLvlVw/4JgzqeQUYYQNQ8Wf9SymtvOWZd5P8
	1pUQ==
X-Gm-Message-State: ALoCoQmYouFhkMMltBSD1MLqjKJQssZ+SqEHjnXzWfnAmYo6VEz4zBrCHE77s3ikm8QiTsZEJOFzt6G9mHp+NvTg3wAba1UQMg==
MIME-Version: 1.0
X-Received: by 10.182.240.138 with SMTP id wa10mr21721750obc.42.1453183672176; 
	Mon, 18 Jan 2016 22:07:52 -0800 (PST)
Sender: dscotese@gmail.com
Received: by 10.60.55.71 with HTTP; Mon, 18 Jan 2016 22:07:52 -0800 (PST)
In-Reply-To: <201601190212.30685.luke@dashjr.org>
References: <64B72DF6-BE37-4624-ADAA-CE28C14A4227@gmail.com>
	<201509042145.34410.luke@dashjr.org>
	<CAAxp-m8JW-WOCem6a4RmBk7HOV3cCc02r5r=BkEDyUBu84u4=A@mail.gmail.com>
	<201601190212.30685.luke@dashjr.org>
Date: Mon, 18 Jan 2016 22:07:52 -0800
X-Google-Sender-Auth: YNob3glD8wWYkwMMgzAbUkgTuCc
Message-ID: <CAGLBAhdanrqDDA2keA8gLLD-0w1YcEnysA3Cz+1nTOLDAd4Wkg@mail.gmail.com>
From: Dave Scotese <dscotese@litmocracy.com>
To: Luke Dashjr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary=089e016348a892da7c0529a9b073
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham
	version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Tue, 19 Jan 2016 15:36:09 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
	Gregory Maxwell <gmaxwell@gmail.com>
Subject: Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Jan 2016 06:07:54 -0000

--089e016348a892da7c0529a9b073
Content-Type: text/plain; charset=UTF-8

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

--089e016348a892da7c0529a9b073
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>This seems like a good place to point out t=
hat attempts to identify individuals (either by name or simply as an indivi=
dual human being) are futile as well as destructive.=C2=A0 &quot;1%&quot; u=
sually means &quot;one out of every 100 people&quot; but this requires iden=
tification of individuals as individuals.=C2=A0 One person can look like ma=
ny in Bitcoin, which is why such an effort is futile.=C2=A0 Additionally, o=
ne person may be far more affected by a decision than others, which is why =
it&#39;s destructive.<br><br></div>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.=C2=A0 Many will argue that=
 we don&#39;t want the system to be controlled by those who hold the most b=
itcoin.=C2=A0 I understand that sentiment, but A) I simply disagree, and B)=
 Finding something better seems impossible to me.<br><br></div>A simple met=
hod is the following:<br></div>A message can be constructed saying: &quot;A=
s of block X, the holder(s) of Y BTC controlled by [public key] agrees that=
 Z,&quot; where X, Y, Z, and the [public key] are the only things that chan=
ge.=C2=A0 This message can be signed by the private key matching the [publi=
c key] in the message.=C2=A0 Anyone interested in measuring consensus on an=
ything relative to bitcoin holders can advertise for such signed messages t=
o 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) an=
d provide a measure of agreement about Z.=C2=A0 Change your mind?=C2=A0 Jus=
t move your BTC to a different address.<br></div><div class=3D"gmail_extra"=
><br><div class=3D"gmail_quote">On Mon, Jan 18, 2016 at 6:12 PM, Luke Dashj=
r via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists=
.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.o=
rg</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Saturday, Sep=
tember 05, 2015 9:19:51 PM Andy Chase wrote:<br>
&gt; Okay for sure yeah writing another proposal that reflects the current =
state<br>
&gt; of affairs as people see it might provide some interesting perspective=
 on<br>
&gt; this proposal. I would welcome that.<br>
<br>
Are you saying your proposal is intentionally not intended to reflect the<b=
r>
reality? I wasn&#39;t talking about a &quot;current state of affairs&quot; =
for BIPs as much<br>
as that that the acceptance of BIPs is *defined by* the state of affairs.<b=
r>
<br>
Overall, I think something *similar to* this proposal is a good idea, but I=
<br>
disagree with how this proposal currently approaches the problem. Instead,<=
br>
what I would recommend is a specification based on BIP 123 that specifies t=
he<br>
conditions under which a proposal is *known to be* accepted by the communit=
y<br>
(ie, discerning, not deciding), and establishes a way for a committee to<br=
>
review the BIP and *determine* if these conditions have been met. This woul=
d<br>
avoid a &quot;disconnect&quot; between the &quot;official status&quot; and =
reality, making the BIP<br>
process more useful to everyone.<br>
<br>
Reviewing your current proposal:<br>
<br>
&gt; * It sets up &#39;&#39;&#39;committees&#39;&#39;&#39; for reviewing co=
mments and indicating<br>
&gt; acceptance under precise conditions.<br>
<br>
As mentioned, IMO a committee shouldn&#39;t be indicating acceptance, as mu=
ch as<br>
it should be *determining* acceptance.<br>
<br>
&gt; ** Committees are authorized groups that represent client authors, min=
ers,<br>
&gt; merchants, and users (each as a segment). Each one must represent at l=
east<br>
&gt; 1% stake in the Bitcoin ecosystem.<br>
<br>
1% seems like an awful lot to dedicate to BIP status changes.<br>
<br>
&gt; A committee system is used to organize the essential concerns of each<=
br>
&gt; segment of the Bitcoin ecosystem. Although each segment may have many<=
br>
&gt; different viewpoints on each BIP, in order to seek a decisive yes/no o=
n a<br>
&gt; BIP, a representational authoritative structure is sought. This struct=
ure<br>
&gt; should be fluid, allowing people to move away from committees that do =
not<br>
&gt; reflect their views and should be re-validated on each BIP evaluation.=
<br>
<br>
That sounds very time consuming. And what happens if these committees don&#=
39;t<br>
represent the community? What about when only part of the community - let&#=
39;s<br>
say 10% - decides to adopt a BIP that doesn&#39;t require consensus? Logica=
lly<br>
that BIP should still proceed...<br>
<br>
&gt; ** Proof of claim and minimum 1% stake via:<br>
&gt; *** Software: proof of ownership and user base (Min 1% of Bitcoin user=
base)<br>
<br>
But the Bitcoin user base is completely unknown, and tracking software user=
<br>
base is a privacy violation.<br>
<br>
&gt; ** Merchant: proof of economic activity (Min 1% of Bitcoin economic<br=
>
&gt; activity)<br>
<br>
Bitcoin economic activity is also unknown, and it seems likely that merchan=
ts<br>
consider their own activity confidential.<br>
<br>
&gt; Mining: proof of work (Min 1% of Hashpower)<br>
<br>
This needs a proper specification. How do miners express their positions?<b=
r>
<br>
&gt; A BIP Process Manager should be chosen who is in charge of:<br>
<br>
Chosen how, and by whom?<br>
<br>
&gt; =3D=3D Conditions for activation =3D=3D<br>
&gt;<br>
&gt; In order for this process BIP to become active, it must succeed by its=
 own<br>
&gt; rules. At least a 4% sample of the Bitcoin community must be represent=
ed,<br>
&gt; with at least one committee in each segment included. Once at least on=
e<br>
&gt; committee has submitted a declaration, a request for comments will be =
called<br>
&gt; and the process should be completed from there.<br>
<br>
Until this BIP is active, its rules do not apply, so this would be a form o=
f<br>
circular reasoning. I like the idea of putting conditions for activation in=
<br>
the BIP text, but I don&#39;t think we can just let the author set any cond=
itions<br>
they like either...<br>
<br>
Luke<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature"><div dir=3D"ltr">I like to provide some work at no charge to prove =
my value. Do you need a techie?=C2=A0 <br>I own <a href=3D"http://www.litmo=
cracy.com" target=3D"_blank">Litmocracy</a> and <a href=3D"http://www.memer=
acing.net" target=3D"_blank">Meme Racing</a> (in alpha). <br>I&#39;m the we=
bmaster for <a href=3D"http://www.voluntaryist.com" target=3D"_blank">The V=
oluntaryist</a> which now accepts Bitcoin.<br>I also code for <a href=3D"ht=
tp://dollarvigilante.com/" target=3D"_blank">The Dollar Vigilante</a>.<br>&=
quot;He ought to find it more profitable to play by the rules&quot; - Satos=
hi Nakamoto</div></div>
</div>

--089e016348a892da7c0529a9b073--