📅 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>;
Eric Lombrozo [ARCHIVE] /
npub1az…t2krq
2023-06-07 17:42:07
in reply to nevent1q…qh0a
Author Public Key
npub1azvhdrf9fu6n0tm7yez4j6zcxcedp2ct6nrcq3z74naqs7kgpk8s5t2krqPublished at
2023-06-07 17:42:07Event JSON
{
"id": "aa4237eeeaec03f55961fba5fb711b0d3ca782d5b658c72eba12d9b2908c03ed",
"pubkey": "e899768d254f3537af7e26455968583632d0ab0bd4c780445eacfa087ac80d8f",
"created_at": 1686159727,
"kind": 1,
"tags": [
[
"e",
"5467b33e638c2bf26daaba633f09d6629bf593f533e890dd02eccf92002cd6b1",
"",
"root"
],
[
"e",
"2aa245fb94f3557881e3cb5d2d0b8e3d037b1a4c65cac709aa8b268962e5dfe5",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2015-09-30\n📝 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.\n\nAs 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.\n\nEventually, 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.\n\n- Eric\n\nOn September 30, 2015 5:26:51 PM PDT, Rusty Russell \u003crusty at rustcorp.com.au\u003e wrote:\n\u003eGregory Maxwell \u003cgmaxwell at gmail.com\u003e writes:\n\u003e\u003e I can, however, argue it the other way (and probably have in the\n\u003e\u003e past): The bit is easily checked by thin clients, so thin clients\n\u003e\u003e could use it to reject potentially ill-fated blocks from non-upgraded\n\u003e\u003e miners post switch (which otherwise they couldn't reject without\n\u003e\u003e inspecting the whole thing). This is an improvement over not forcing\n\u003e\u003e the bit, and it's why I was previously in favor of the way the\n\u003e\u003e versions were enforced. But, experience has played out other ways,\n\u003e\u003e and thin clients have not done anything useful with the version\n\u003e\u003e numbers.\n\u003e\u003e\n\u003e\u003e A middle ground might be to require setting the bit for a period of\n\u003e\u003e time after rule enforcing begins, but don't enforce the bit, just\n\u003e\u003e enforce validity of the block under new rules. Thus a thin client\n\u003e\u003e could treat these blocks with increased skepticism.\n\u003e\n\u003eIntroducing this later would trigger warnings on older clients, who\n\u003ewould consider the bit to represent a new soft fork :(\n\u003e\n\u003eSo if we want this middle ground, we should sew it in now, though it\n\u003eadds a other state. Simplest is to have miners keep setting the bit\n\u003efor\n\u003eanother 2016 blocks. If we want to later, we can make this a consensus\n\u003erule.\n\u003e\n\u003e\"Bitcoin is hard, let's go shopping!\" \"With Bitcoin!\" \"...\"\n\u003eRusty.\n\n-- \nSent from my Android device with K-9 Mail. Please excuse my brevity.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150930/1c6a92df/attachment.html\u003e",
"sig": "277f83091aeeadc3ff7e9eebc49250e8e8fe7a1c8a4c2becb1d1800e283c7ca16f8cab8ed6771b3b8d6a67fd1aa246a7603c345893fbd385a75b0e80c52d4c09"
}