From: Eric Lombrozo <elombrozo@gmail•com>
To: Rusty Russell <rusty@rustcorp•com.au>,
Gregory Maxwell <gmaxwell@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.
Date: Wed, 30 Sep 2015 19:54:34 -0700 [thread overview]
Message-ID: <A0342136-AA7C-4355-BCDA-C6AE8D6BCCB4@gmail.com> (raw)
In-Reply-To: <87bncjph6c.fsf@rustcorp.com.au>
[-- Attachment #1: Type: text/plain, Size: 2369 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 2879 bytes --]
next prev parent reply other threads:[~2015-10-01 2:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-30 2:30 Rusty Russell
2015-09-30 2:57 ` Gregory Maxwell
2015-09-30 4:46 ` Eric Lombrozo
2015-09-30 5:09 ` Eric Lombrozo
2015-10-01 0:26 ` Rusty Russell
2015-10-01 2:54 ` Eric Lombrozo [this message]
2015-10-02 1:22 ` Rusty Russell
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=A0342136-AA7C-4355-BCDA-C6AE8D6BCCB4@gmail.com \
--to=elombrozo@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=gmaxwell@gmail$(echo .)com \
--cc=pieter.wuille@gmail$(echo .)com \
--cc=rusty@rustcorp$(echo .)com.au \
/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