path: root/e9/e2d92243fcdddd753a52c9a1e119a41c50d5aa

Return-Path: <benjamin.l.cordes@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 7910FF3E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  3 Sep 2015 04:55:18 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com
	[209.85.214.171])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9A66524C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  3 Sep 2015 04:55:17 +0000 (UTC)
Received: by obcts10 with SMTP id ts10so26336273obc.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 02 Sep 2015 21:55:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=r+a93gr1v5wVFb3fNWuj/DoriP2M7W8STWZG2nKBA1U=;
	b=tdLKD4L+pfkR7KgRABwL4stuBa68OLqogrQPPypA1waCenqhij38gPuRkgoWohQnve
	RzVs6bgJtkWuvs8zmxVcaewyN9aUxEsDiWezKTHbqvRY70209ncwYgbbIIZxilsEKUas
	MfD7bPhZrW1yvWAnhQJF6k9DFrRBsWSTN4t51qNxv7/2ouyHSVH2nVeox654e24dkWtn
	bEHuvKupuRqTtE0OmqjmmkdmrWFj9yDF2NodNbXWbN6+FLDq3pB3RiToXVP7sCDlelwb
	xuQcgZtcenvit/eJ0vTjq7CdeRa8gZ2rCe+VHHbqoaGpSUq1LiReheGJhDAzaleS/cqk
	k6PQ==
MIME-Version: 1.0
X-Received: by 10.60.69.39 with SMTP id b7mr23562201oeu.51.1441256117063; Wed,
	02 Sep 2015 21:55:17 -0700 (PDT)
Received: by 10.202.201.213 with HTTP; Wed, 2 Sep 2015 21:55:17 -0700 (PDT)
In-Reply-To: <CADm_WcawXU3b5g_kuUCKxHQ2YVRPmVh6g33qWDWqdw-X4tSE7Q@mail.gmail.com>
References: <CADm_WcZpOxLJdxENe=GXqrp17C-Q2karunOvzegGz-NQ2b_AEg@mail.gmail.com>
	<CADm_WcZEbAe_+VXxS1eMKQ1SM3KiJwVDS50-GtfUPw-Mdd5O2w@mail.gmail.com>
	<201509030017.43036.luke@dashjr.org>
	<CADm_WcawXU3b5g_kuUCKxHQ2YVRPmVh6g33qWDWqdw-X4tSE7Q@mail.gmail.com>
Date: Thu, 3 Sep 2015 05:55:17 +0100
Message-ID: <CAOoPuRZLHGhmbu1a0NeDZDaFmUFf=yP3_k8jTawcRbhztyWT9w@mail.gmail.com>
From: Benjamin <benjamin.l.cordes@gmail.com>
To: Jeff Garzik <jgarzik@gmail.com>
Content-Type: multipart/alternative; boundary=001a11330e68e35c63051ed09698
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,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
Cc: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 100 repo
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: Thu, 03 Sep 2015 04:55:18 -0000

--001a11330e68e35c63051ed09698
Content-Type: text/plain; charset=UTF-8

I would be helpful to describe what is meant by "votes". As far as I
understand this would be a semi-automatic process - nodes encode values
which in turn are hardcoded in software, or is this completely automated
without any intervention at all? Is there the possibility that nodes decide
by encode votes, but somehow this decision is not adhered to? Is 4. a 51%
rule?

Under 2. it might make sense to specify values in the range (1MB steps
e.g.). The number of options could have an effect. For example if the vote
has 4 possible values or 32 possible values can make a difference in
outcomes.

With regards to 1. Bitcoin does not have a fee market, although I agree
that might be a good goal. There is no price-determination of fees and no
definition of quality of service. A fee market would entail some matching
of demand and supply to establish a price. Users would adjust fee to win a
transaction slow in a deterministic way. However currently the user has no
way of knowing what effect a fee might have. So this would necessarily
include some kind pricing-mechanism with actual commitments. Bitcoin as a
system is quite far away from such a capability. It would mean Bitcoin is
capable of adapting to how it is used. For example that would allow to
shift transactions from high demand period to low demand period. I'm not
aware of any proposal to make an actual functioning fee market in Bitcoin
(or even the conceptual primitives).



On Thu, Sep 3, 2015 at 5:09 AM, Jeff Garzik via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Oh, and answering your question about the 1M:  It is a safety rail.  It
> can perform no worse on the low end than the current system.  Eliminates
> unlikely scenarios that squeeze users.
>
>
> On Wed, Sep 2, 2015 at 8:17 PM, Luke Dashjr <luke@dashjr.org> wrote:
>
>> On Wednesday, September 02, 2015 11:58:54 PM Jeff Garzik via bitcoin-dev
>> wrote:
>> > The repo: https://github.com/jgarzik/bip100
>>
>> What is the purpose of the newly added 1 MB floor? It seems clear from the
>> current information available that 1 MB is presently too high for the
>> limit,
>> and it is entirely one-sided to only allow increases when decreases are
>> much
>> more likely to be needed in the short term.
>>
>> Must the new size limit votes use 11 bytes of coinbase? Why not just use a
>> numeric value pushed after height? Since this is a hardfork, I suggest
>> increasing the coinbase length to allow for 100 bytes *in addition* to the
>> pushed height and size-vote.
>>
>> I suggest combining 2 & 4 into a single rule lifting the 1 MB limit to 32
>> MB
>> (or whatever value is deemed appropriate) to make it clear that the limit
>> remains a part of the consensus protocol and p2p protocol limits are not
>> to
>> have an effect on consensus rules.
>>
>> Furthermore, I suggest modifying the voting to require 50% to set the
>> limit
>> floor. This has the effect of merely coordinating what miners can already
>> effectively do today by rejecting blocks larger than some collusion-
>> determined limit.
>>
>> Thoughts?
>>
>> Luke
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

<div dir=3D"ltr">I would be helpful to describe what is meant by &quot;vote=
s&quot;. As far as I understand this would be a semi-automatic process - no=
des encode values which in turn are hardcoded in software, or is this compl=
etely automated without any intervention at all?=C2=A0Is there the possibil=
ity that nodes decide by encode votes, but somehow this decision is not adh=
ered to?=C2=A0Is 4. a 51% rule?<div><br></div><div>Under 2. it might make s=
ense to specify values in the range (1MB steps e.g.). The number of options=
 could have an effect. For example if the vote has 4 possible values or 32 =
possible values can make a difference in outcomes.<div><br></div><div>With =
regards to 1. Bitcoin does not have a fee market, although I agree that mig=
ht be a good goal. There is no price-determination of fees and no definitio=
n of quality of service. A fee market would entail some matching of demand =
and supply to establish a price. Users would adjust fee to win a transactio=
n slow in a deterministic way. However currently the user has no way of kno=
wing what effect a fee might have. So this would necessarily include some k=
ind pricing-mechanism with actual commitments. Bitcoin as a system is quite=
 far away from such a capability. It would mean Bitcoin is capable of adapt=
ing to how it is used. For example that would allow to shift transactions f=
rom high demand period to low demand period. I&#39;m not aware of any propo=
sal to make an actual functioning fee market in Bitcoin (or even the concep=
tual primitives).</div><div><br></div><div><br></div></div></div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Sep 3, 2015 at 5:09=
 AM, Jeff Garzik via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bi=
tcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.li=
nuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div dir=3D"ltr">Oh, and answering your question about the 1M: =C2=A0It is a=
 safety rail.=C2=A0 It can perform no worse on the low end than the current=
 system.=C2=A0 Eliminates unlikely scenarios that squeeze users.<div><br></=
div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><span c=
lass=3D"">On Wed, Sep 2, 2015 at 8:17 PM, Luke Dashjr <span dir=3D"ltr">&lt=
;<a href=3D"mailto:luke@dashjr.org" target=3D"_blank">luke@dashjr.org</a>&g=
t;</span> wrote:<br></span><span class=3D""><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
On Wednesday, September 02, 2015 11:58:54 PM Jeff Garzik via bitcoin-dev<br=
>
wrote:<br>
&gt; The repo: <a href=3D"https://github.com/jgarzik/bip100" rel=3D"norefer=
rer" target=3D"_blank">https://github.com/jgarzik/bip100</a><br>
<br>
What is the purpose of the newly added 1 MB floor? It seems clear from the<=
br>
current information available that 1 MB is presently too high for the limit=
,<br>
and it is entirely one-sided to only allow increases when decreases are muc=
h<br>
more likely to be needed in the short term.<br>
<br>
Must the new size limit votes use 11 bytes of coinbase? Why not just use a<=
br>
numeric value pushed after height? Since this is a hardfork, I suggest<br>
increasing the coinbase length to allow for 100 bytes *in addition* to the<=
br>
pushed height and size-vote.<br>
<br>
I suggest combining 2 &amp; 4 into a single rule lifting the 1 MB limit to =
32 MB<br>
(or whatever value is deemed appropriate) to make it clear that the limit<b=
r>
remains a part of the consensus protocol and p2p protocol limits are not to=
<br>
have an effect on consensus rules.<br>
<br>
Furthermore, I suggest modifying the voting to require 50% to set the limit=
<br>
floor. This has the effect of merely coordinating what miners can already<b=
r>
effectively do today by rejecting blocks larger than some collusion-<br>
determined limit.<br>
<br>
Thoughts?<br>
<span><font color=3D"#888888"><br>
Luke<br>
</font></span></blockquote></span></div><br></div>
<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>
<br></blockquote></div><br></div>

--001a11330e68e35c63051ed09698--