Eric Lombrozo [ARCHIVE] on Nostr: 📅 Original date posted:2015-09-30 📝 Original message:I can go along with making ...
📅 Original date posted:2015-09-30
📝 Original message: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 at rustcorp.com.au> wrote:
>Gregory Maxwell <gmaxwell at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150930/1c6a92df/attachment.html>;
📝 Original message: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 at rustcorp.com.au> wrote:
>Gregory Maxwell <gmaxwell at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150930/1c6a92df/attachment.html>;