User-Agent: K-9 Mail for Android
In-Reply-To: <87bncjph6c.fsf@rustcorp.com.au>
References: <87zj04fxkw.fsf@rustcorp.com.au>
	<CAAS2fgTXP0j6K3sxp=HL9j2-xvO8y_VnpG+iZw9kaxmnxZQjSw@mail.gmail.com>
	<87bncjph6c.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----IOGPRRM1JMEXHC69MOAJFU5LC1UZ14"
Content-Transfer-Encoding: 8bit
From: Eric Lombrozo <elombrozo@gmail.com>
Date: Wed, 30 Sep 2015 19:54:34 -0700
To: Rusty Russell <rusty@rustcorp.com.au>, Gregory Maxwell <gmaxwell@gmail.com>
Message-ID: <A0342136-AA7C-4355-BCDA-C6AE8D6BCCB4@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
	Pieter Wuille <pieter.wuille@gmail.com>
Subject: Re: [bitcoin-dev] Versionbits BIP (009) minor revision proposal.
Precedence: list

------IOGPRRM1JMEXHC69MOAJFU5LC1UZ14
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8

I can go along with making it optional but recommended for the first deployment and making it mandatory later on. It would be purely informational for now...but it will give us valuable data.

As has been said before, most of these BIP deployments will likely be accompanied by recommended default settings for miners. Assuming the BIP itself is not very controversial, the gravest dangers come not so much from miners (or pool operators, more accurately) deliberately choosing to lie...but more from either shortcuts taken in implementations and/or bugs. Collecting additional data will help spot faulty implementations and allow us to intervene.

Eventually, I imagine a much more sophisticated signaling mechanism where endusers can be given highly informative messages regarding changes and we can have a way of directing people to resources where they can learn more about the new features.

- Eric

On September 30, 2015 5:26:51 PM PDT, Rusty Russell <rusty@rustcorp.com.au> wrote:
>Gregory Maxwell <gmaxwell@gmail.com> writes:
>> I can, however, argue it the other way (and probably have in the
>> past):  The bit is easily checked by thin clients, so thin clients
>> could use it to reject potentially ill-fated blocks from non-upgraded
>> miners post switch (which otherwise they couldn't reject without
>> inspecting the whole thing). This is an improvement over not forcing
>> the bit, and it's why I was previously in favor of the way the
>> versions were enforced.  But, experience has played out other ways,
>> and thin clients have not done anything useful with the version
>> numbers.
>>
>> A middle ground might be to require setting the bit for a period of
>> time after rule enforcing begins, but don't enforce the bit, just
>> enforce validity of the block under new rules.  Thus a thin client
>> could treat these blocks with increased skepticism.
>
>Introducing this later would trigger warnings on older clients, who
>would consider the bit to represent a new soft fork :(
>
>So if we want this middle ground, we should sew it in now, though it
>adds a other state.  Simplest is to have miners keep setting the bit
>for
>another 2016 blocks.  If we want to later, we can make this a consensus
>rule.
>
>"Bitcoin is hard, let's go shopping!"  "With Bitcoin!"  "..."
>Rusty.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
------IOGPRRM1JMEXHC69MOAJFU5LC1UZ14
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: 8bit

<html><head></head><body>I can go along with making it optional but recommended for the first deployment and making it mandatory later on. It would be purely informational for now...but it will give us valuable data.<br>
<br>
As has been said before, most of these BIP deployments will likely be accompanied by recommended default settings for miners. Assuming the BIP itself is not very controversial, the gravest dangers come not so much from miners (or pool operators, more accurately) deliberately choosing to lie...but more from either shortcuts taken in implementations and/or bugs. Collecting additional data will help spot faulty implementations and allow us to intervene.<br>
<br>
Eventually, I imagine a much more sophisticated signaling mechanism where endusers can be given highly informative messages regarding changes and we can have a way of directing people to resources where they can learn more about the new features.<br>
<br>
- Eric<br><br><div class="gmail_quote">On September 30, 2015 5:26:51 PM PDT, Rusty Russell &lt;rusty@rustcorp.com.au&gt; wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">Gregory Maxwell &lt;gmaxwell@gmail.com&gt; writes:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> I can, however, argue it the other way (and probably have in the<br /> past):  The bit is easily checked by thin clients, so thin clients<br /> could use it to reject potentially ill-fated blocks from non-upgraded<br /> miners post switch (which otherwise they couldn't reject without<br /> inspecting the whole thing). This is an improvement over not forcing<br /> the bit, and it's why I was previously in favor of the way the<br /> versions were enforced.  But, experience has played out other ways,<br /> and thin clients have not done anything useful with the version<br /> numbers.<br /><br /> A middle ground might be to require setting the bit for a period of<br /> time after rule enforcing begins, but don't enforce the bit, just<br /> enforce validity of the block under new rules.  T
 hus a
thin client<br /> could treat these blocks with increased skepticism.<br /></blockquote><br />Introducing this later would trigger warnings on older clients, who<br />would consider the bit to represent a new soft fork :(<br /><br />So if we want this middle ground, we should sew it in now, though it<br />adds a other state.  Simplest is to have miners keep setting the bit for<br />another 2016 blocks.  If we want to later, we can make this a consensus<br />rule.<br /><br />"Bitcoin is hard, let's go shopping!"  "With Bitcoin!"  "..."<br />Rusty.<br /></pre></blockquote></div><br>
-- <br>
Sent from my Android device with K-9 Mail. Please excuse my brevity.</body></html>
------IOGPRRM1JMEXHC69MOAJFU5LC1UZ14--