š
Original date posted:2022-01-19
š Original message:Eric, Luke
Can I request that you don't discuss activation methods for future soft forks on a thread for CTV BIP review? I (and a number of others [0]) do not support an upcoming activation attempt of standalone OP_CTV. If you want to discuss activation methods for soft forks generally it would be much better if you set up a separate thread. OP_CTV is not the only current soft fork proposal and there will likely be more.
The activation discussion for Taproot was deliberately kept separate from the review of the Taproot BIPs and implementation. It only commenced once there was overwhelming community consensus for the soft fork to be activated (months after in fact). Though you are free to discuss whatever topics you wish (obviously) discussing soft fork activation methods on a OP_CTV thread might give the mistaken impression that OP_CTV is the next soft fork to be activated which is mere speculation at this point. In an ideal world the promoters of OP_CTV would follow the strong precedent set by the authors and contributors to the Taproot BIPs but regrettably that seems to have gone out the window at this point.
Thanks
Michael
[0]: https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
--
Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
āāāāāāā Original Message āāāāāāā
On Tuesday, January 18th, 2022 at 11:00 PM, Eric Voskuil via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> -----Original Message-----
>
> From: Luke Dashjr luke at dashjr.org
>
> Sent: Tuesday, January 18, 2022 2:10 PM
>
> To: eric at voskuil.org
>
> Cc: 'Bitcoin Protocol Discussion' bitcoin-dev at lists.linuxfoundation.org
>
> Subject: Re: [bitcoin-dev] CTV BIP review
>
> On Tuesday 18 January 2022 22:02:24 eric at voskuil.org wrote:
>
> > The only material distinction between BIP9 and BIP8 is that the latter
> >
> > may activate without signaled support of hash power enforcement.
> >
> > As unenforced soft forks are not "backward compatible" they produce a
> >
> > chain split.
>
> Enforcement of the Bitcoin consensus protocol is by users, not miners.
Given that I stated "hash power enforcement" it is quite clear that this is
in fact only produced by mining. You are misrepresenting my statement to
make an emotional appeal. Without "hash power enforcement", a soft fork is
NOT backward compatible.
"[enforcement of] consensus protocol" is of course by merchants, but that is
not the question at hand. The question is explicitly compatibility. Anyone
can activate a soft fork at any time, but without "hash power enforcement"
soft forks are NOT backward compatible.
> Softforks never produce a chain split. Miners can, and might try to do it
to cause disruption in retaliation, but the softfork itself does not.
Maybe you are trying to split hairs given the fact that blocks are produced
only by miners, so only miners can "cause" a split.
But through not intention ("disruption in retaliation") whatsoever by
mining, a soft fork will result in those activating the rule being split off
the original chain unless majority hash power enforces the rule. The fact
that doing nothing apart from deploying the rule will result in a split is
the very definition of NOT compatible.
I assume you will argue that the original chain is not "valid" and therefore
irrelevant (as if no chain split occurred). But again the point is about
compatibility. The appearance of multiple chains, which appear valid
according to either the previous or new rules, is obviously the
incompatibility.
I shouldn't have to point this out, but observed chain splits have occurred
in more the one large scale soft fork deployment. These splits have only
been resolved through hash power enforcement. In 2010 it took 51 blocks
before the current chain took the lead. In 2012 minority chains persisted
for months. The deployment of soft forks caused these splits, NOT the
actions of miners. And unless majority hash power eventually enforces it,
the soft fork branch necessarily dies.
> > It was for this reason alone that BIP8 never gained sufficient
> >
> > support.
>
> BIP 8 in fact achieved consensus for Taproot activation.
Please define "achieved consensus", because by any definition I can imagine,
this is simply untrue.
> > This is one of the most misleading statements I've seen here. It's not
> >
> > technically a lie, because it states what "should" happen. But it is
> >
> > clearly intended to lead people to believe that BIP8 was actually used
> >
> > ("again") - it was not. ST was some technical tweaks to BIP9.
>
> BIP 8 was used to activate Taproot.
No, it wasn't. I find it hard to imaging how you rationalize such grossly
misleading statements.
> > The outright deception around this one topic has led to significant
> >
> > unnecessary conflict in the community. Make your argument, but make it
> >
> > honestly.
>
> You are the one attempting to deceive here.
That is for others to decide. I appreciate your responses above, since they
certainly help clarify what is happening here.
e
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Michael Folkson [ARCHIVE] /
npub103ā¦2kpam
2023-06-07 23:02:32
in reply to nevent1qā¦p9n8
Author Public Key
npub103ycruxnchhvja33mcnnkfdkgd0s7vlqlfkvufcdm5lnhpuh6f4q82kpamPublished at
2023-06-07 23:02:32Event JSON
{
"id": "6ce52e371c2040aecc8443756797f70f4f7f0dc4acecda1740befe4dfacc8d2d",
"pubkey": "7c4981f0d3c5eec97631de273b25b6435f0f33e0fa6cce270ddd3f3b8797d26a",
"created_at": 1686178952,
"kind": 1,
"tags": [
[
"e",
"03da030e3b313ae60c6ce63f7e2349e6c30d49bd45d38ae242a67e28557d2786",
"",
"root"
],
[
"e",
"a82b7e7da563f2be44cb80c57924deda363b88a981c982a103da9c38757d9981",
"",
"reply"
],
[
"p",
"1c6b6b98622ba25104591136013eadc67e5a75a9327400cb9f2b9ac5027462c3"
]
],
"content": "š
Original date posted:2022-01-19\nš Original message:Eric, Luke\n\nCan I request that you don't discuss activation methods for future soft forks on a thread for CTV BIP review? I (and a number of others [0]) do not support an upcoming activation attempt of standalone OP_CTV. If you want to discuss activation methods for soft forks generally it would be much better if you set up a separate thread. OP_CTV is not the only current soft fork proposal and there will likely be more.\n\nThe activation discussion for Taproot was deliberately kept separate from the review of the Taproot BIPs and implementation. It only commenced once there was overwhelming community consensus for the soft fork to be activated (months after in fact). Though you are free to discuss whatever topics you wish (obviously) discussing soft fork activation methods on a OP_CTV thread might give the mistaken impression that OP_CTV is the next soft fork to be activated which is mere speculation at this point. In an ideal world the promoters of OP_CTV would follow the strong precedent set by the authors and contributors to the Taproot BIPs but regrettably that seems to have gone out the window at this point.\n\nThanks\nMichael\n\n[0]: https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718\n--\nMichael Folkson\nEmail: michaelfolkson at protonmail.com\nKeybase: michaelfolkson\nPGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3\n\nāāāāāāā Original Message āāāāāāā\n\nOn Tuesday, January 18th, 2022 at 11:00 PM, Eric Voskuil via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e -----Original Message-----\n\u003e\n\u003e From: Luke Dashjr luke at dashjr.org\n\u003e\n\u003e Sent: Tuesday, January 18, 2022 2:10 PM\n\u003e\n\u003e To: eric at voskuil.org\n\u003e\n\u003e Cc: 'Bitcoin Protocol Discussion' bitcoin-dev at lists.linuxfoundation.org\n\u003e\n\u003e Subject: Re: [bitcoin-dev] CTV BIP review\n\u003e\n\u003e On Tuesday 18 January 2022 22:02:24 eric at voskuil.org wrote:\n\u003e\n\u003e \u003e The only material distinction between BIP9 and BIP8 is that the latter\n\u003e \u003e\n\u003e \u003e may activate without signaled support of hash power enforcement.\n\u003e \u003e\n\u003e \u003e As unenforced soft forks are not \"backward compatible\" they produce a\n\u003e \u003e\n\u003e \u003e chain split.\n\u003e\n\u003e Enforcement of the Bitcoin consensus protocol is by users, not miners.\n\nGiven that I stated \"hash power enforcement\" it is quite clear that this is\n\nin fact only produced by mining. You are misrepresenting my statement to\n\nmake an emotional appeal. Without \"hash power enforcement\", a soft fork is\n\nNOT backward compatible.\n\n\"[enforcement of] consensus protocol\" is of course by merchants, but that is\n\nnot the question at hand. The question is explicitly compatibility. Anyone\n\ncan activate a soft fork at any time, but without \"hash power enforcement\"\n\nsoft forks are NOT backward compatible.\n\n\u003e Softforks never produce a chain split. Miners can, and might try to do it\n\nto cause disruption in retaliation, but the softfork itself does not.\n\nMaybe you are trying to split hairs given the fact that blocks are produced\n\nonly by miners, so only miners can \"cause\" a split.\n\nBut through not intention (\"disruption in retaliation\") whatsoever by\n\nmining, a soft fork will result in those activating the rule being split off\n\nthe original chain unless majority hash power enforces the rule. The fact\n\nthat doing nothing apart from deploying the rule will result in a split is\n\nthe very definition of NOT compatible.\n\nI assume you will argue that the original chain is not \"valid\" and therefore\n\nirrelevant (as if no chain split occurred). But again the point is about\n\ncompatibility. The appearance of multiple chains, which appear valid\n\naccording to either the previous or new rules, is obviously the\n\nincompatibility.\n\nI shouldn't have to point this out, but observed chain splits have occurred\n\nin more the one large scale soft fork deployment. These splits have only\n\nbeen resolved through hash power enforcement. In 2010 it took 51 blocks\n\nbefore the current chain took the lead. In 2012 minority chains persisted\n\nfor months. The deployment of soft forks caused these splits, NOT the\n\nactions of miners. And unless majority hash power eventually enforces it,\n\nthe soft fork branch necessarily dies.\n\n\u003e \u003e It was for this reason alone that BIP8 never gained sufficient\n\u003e \u003e\n\u003e \u003e support.\n\u003e\n\u003e BIP 8 in fact achieved consensus for Taproot activation.\n\nPlease define \"achieved consensus\", because by any definition I can imagine,\n\nthis is simply untrue.\n\n\u003e \u003e This is one of the most misleading statements I've seen here. It's not\n\u003e \u003e\n\u003e \u003e technically a lie, because it states what \"should\" happen. But it is\n\u003e \u003e\n\u003e \u003e clearly intended to lead people to believe that BIP8 was actually used\n\u003e \u003e\n\u003e \u003e (\"again\") - it was not. ST was some technical tweaks to BIP9.\n\u003e\n\u003e BIP 8 was used to activate Taproot.\n\nNo, it wasn't. I find it hard to imaging how you rationalize such grossly\n\nmisleading statements.\n\n\u003e \u003e The outright deception around this one topic has led to significant\n\u003e \u003e\n\u003e \u003e unnecessary conflict in the community. Make your argument, but make it\n\u003e \u003e\n\u003e \u003e honestly.\n\u003e\n\u003e You are the one attempting to deceive here.\n\nThat is for others to decide. I appreciate your responses above, since they\n\ncertainly help clarify what is happening here.\n\ne\n\nbitcoin-dev mailing list\n\nbitcoin-dev at lists.linuxfoundation.org\n\nhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev",
"sig": "4beed26b5ee7d70c239826812ec4ac34d9fe842a54cc76fa61e0474e6297efafb320c95526abda846f77daaa73dd76de4a5dab1447b50cf02244fec8d0754fbb"
}