馃搮 Original date posted:2022-04-24
馃摑 Original message:On Sun, Apr 24, 2022 at 2:17 PM Michael Folkson <
michaelfolkson at protonmail.com> wrote:
> Hi Jorge
>
> > Can we agree now that resisting a bip8 proposal is simpler and cleaner
> than resisting a speedy trial proposal?
>
> Personally I'd rather stick to one challenge at a time :) Currently we are
> facing a contentious soft fork activation attempt of CTV using an
> alternative client which we expect [1] to be a Speedy Trial deployment.
> Once this is resolved we can discuss the lessons and observations that come
> out of this.
>
That sounds reasonable to me. Fair enough.
> > Is there any PR to actively resist the proposal on bitcoin core?
>
> Not currently. Unless this becomes really, really messy and starts to pose
> a true existential threat to Bitcoin itself I think it best that attempts
> to actively resist the proposal are done outside of Bitcoin Core in an
> alternative client(s). Contrary to what some CTV proponents say getting
> anything consensus related into Bitcoin Core is extremely difficult
> (especially at short notice). There is no BDFL or Linus Torvalds like
> figure, there are a large number of contributors (and maintainers) who all
> have differing personal views. Hence directing people to have this
> discussion on a particular PR in the Bitcoin Core repo seems to me to be
> counterproductive and a massive distraction to other work that is going on
> on Bitcoin Core. We've already started to see online attacks on Bitcoin
> Core by CTV proponents [2] claiming an "old guard trying to assert
> dictatorship over the Bitcoin protocol". It is nonsense of course but
> directing that nonsense to the Bitcoin Core repo is surely not the right
> way to go.
>
> As I've said in previous emails there is a Libera (and Freenode now) IRC
> channel ##ursf that has been set up to discuss an alternative client. We'll
> get a conversation log up too. And of course we wait for confirmation on
> what the Speedy Trial deployment parameters for this attempted CTV soft
> fork are going to be.
>
> [1]: https://blog.bitmex.com/op_ctv-summer-softfork-shenanigans/
> [2]:
> https://twitter.com/ProofOfKeags/status/1517574210691887105?s=20&t=_jgRh3kkYP3kn1qLuzGXrQ
>
>
I disagree that it shouldn't be on bitcoin core, but I guess such a
proposal would get many nacks.
But if there are no speedy trial parameters yet, I guess we need to wait
for that; whether the code for resisting it ends up in bitcoin core or not.
Thanks for the clarifications.
--
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
> ------- Original Message -------
> On Saturday, April 23rd, 2022 at 21:40, Jorge Tim贸n <jtimon at jtimon.cc>
> wrote:
>
> I've been calling them "controversial softforks" for long.
> I hate to be right some times, but I guess I'm happy that I'm not the only
> one who distrusts jeremy rubin anymore.
>
> Can we agree now that resisting a bip8 proposal is simpler and cleaner
> than resisting a speedy trial proposal?
> I guess now we don't need to discuss it in hypothetical terms anymore, do
> we?
>
> Is there any PR to actively resist the proposal on bitcoin core?
>
>
>
>
>
>
> On Thu, Apr 21, 2022 at 8:16 PM Michael Folkson via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Ok so we've had to scramble a bit as I don't think anyone except perhaps
>> Jeremy thought that there would be a Speedy Trial signaling period for a
>> CTV soft fork planned to start on May 5th [1]. That is two weeks away.
>>
>> (I have to take what he says at face value. I can understand why one
>> would be skeptical.)
>>
>> Understandably this has angered and surprised a few people including some
>> of those who have voiced opposition to a CTV soft fork activation being
>> attempted in the first place [2].
>>
>> As I've said in a previous post [3] the Bitcoin Core 23.0 release
>> candidate (and older versions) does not include any CTV code or CTV
>> activation code. If a miner runs Bitcoin Core 23.0 out the box it will not
>> signal for CTV. If by some chance CTV was to activate through some other
>> software release Bitcoin Core releases would not apply CTV rules but they
>> also wouldn't reject blocks that apply CTV rules. Hence it is prudent to
>> prepare for an eventuality where the miner signaling threshold might be
>> reached but the community wants to prevent the attempted soft fork from
>> activating. (I personally don't think a 90 percent miner signaling
>> threshold will be reached but I wouldn't want to bet Bitcoin's future on
>> it.)
>>
>> I've tentatively labelled this effort a User Resisted Soft Fork (URSF)
>> but I'm open to better names. I certainly don't want to discourage those
>> who dislike or oppose UASFs from contributing to this effort and
>> potentially ultimately running a URSF release. If you don't want this
>> rushed CTV soft fork to activate we are all on the same side whatever we
>> call it.
>>
>> For now I've set up a ##ursf channel on Libera IRC to monitor
>> developments and discuss working on an additional release that if run may
>> ultimately reject blocks that signal for CTV.
>>
>> The intention of this would be to provide additional direction and
>> incentive to miners that the community does not want this soft fork to be
>> activated. To repeat running a Bitcoin Core release will not signal for a
>> CTV soft fork out the box. If a miner runs a Bitcoin Core release it will
>> not signal for CTV.
>>
>> Apologies that this is rushed. But as always with Jeremy caution and
>> conservatism seems to be thrown out the window and we have to react to
>> that. It goes without saying that this is not how Bitcoin consensus changes
>> should be attempted.
>>
>> [1]: https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/
>> [2]:
>> https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
>> [3]:
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020235.html
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at protonmail.com
>> Keybase: michaelfolkson
>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220424/4bd0bb7e/attachment-0001.html>;
Jorge Tim贸n [ARCHIVE] /
npub1fx鈥l2d8
2023-06-07 23:07:54
in reply to nevent1q鈥n7n
Author Public Key
npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8Published at
2023-06-07 23:07:54Event JSON
{
"id": "61b2279a46f5eec77380d3d4381d22aa5fbed6433ca68670a0f253f398f1985e",
"pubkey": "498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84",
"created_at": 1686179274,
"kind": 1,
"tags": [
[
"e",
"2ad3d3403e1d63b96ae96eb1c1f2ba31d1c1dccbc5720a099543ffc26240da8b",
"",
"root"
],
[
"e",
"c243aef4e383e5d9eb746dbc8ed3921d22fd0e58d556d01fa40bf87f811c6b38",
"",
"reply"
],
[
"p",
"7c4981f0d3c5eec97631de273b25b6435f0f33e0fa6cce270ddd3f3b8797d26a"
]
],
"content": "馃搮 Original date posted:2022-04-24\n馃摑 Original message:On Sun, Apr 24, 2022 at 2:17 PM Michael Folkson \u003c\nmichaelfolkson at protonmail.com\u003e wrote:\n\n\u003e Hi Jorge\n\u003e\n\u003e \u003e Can we agree now that resisting a bip8 proposal is simpler and cleaner\n\u003e than resisting a speedy trial proposal?\n\u003e\n\u003e Personally I'd rather stick to one challenge at a time :) Currently we are\n\u003e facing a contentious soft fork activation attempt of CTV using an\n\u003e alternative client which we expect [1] to be a Speedy Trial deployment.\n\u003e Once this is resolved we can discuss the lessons and observations that come\n\u003e out of this.\n\u003e\n\nThat sounds reasonable to me. Fair enough.\n\n\n\u003e \u003e Is there any PR to actively resist the proposal on bitcoin core?\n\u003e\n\u003e Not currently. Unless this becomes really, really messy and starts to pose\n\u003e a true existential threat to Bitcoin itself I think it best that attempts\n\u003e to actively resist the proposal are done outside of Bitcoin Core in an\n\u003e alternative client(s). Contrary to what some CTV proponents say getting\n\u003e anything consensus related into Bitcoin Core is extremely difficult\n\u003e (especially at short notice). There is no BDFL or Linus Torvalds like\n\u003e figure, there are a large number of contributors (and maintainers) who all\n\u003e have differing personal views. Hence directing people to have this\n\u003e discussion on a particular PR in the Bitcoin Core repo seems to me to be\n\u003e counterproductive and a massive distraction to other work that is going on\n\u003e on Bitcoin Core. We've already started to see online attacks on Bitcoin\n\u003e Core by CTV proponents [2] claiming an \"old guard trying to assert\n\u003e dictatorship over the Bitcoin protocol\". It is nonsense of course but\n\u003e directing that nonsense to the Bitcoin Core repo is surely not the right\n\u003e way to go.\n\u003e\n\u003e As I've said in previous emails there is a Libera (and Freenode now) IRC\n\u003e channel ##ursf that has been set up to discuss an alternative client. We'll\n\u003e get a conversation log up too. And of course we wait for confirmation on\n\u003e what the Speedy Trial deployment parameters for this attempted CTV soft\n\u003e fork are going to be.\n\u003e\n\u003e [1]: https://blog.bitmex.com/op_ctv-summer-softfork-shenanigans/\n\u003e [2]:\n\u003e https://twitter.com/ProofOfKeags/status/1517574210691887105?s=20\u0026t=_jgRh3kkYP3kn1qLuzGXrQ\n\u003e\n\u003e\nI disagree that it shouldn't be on bitcoin core, but I guess such a\nproposal would get many nacks.\nBut if there are no speedy trial parameters yet, I guess we need to wait\nfor that; whether the code for resisting it ends up in bitcoin core or not.\nThanks for the clarifications.\n\n--\n\u003e Michael Folkson\n\u003e Email: michaelfolkson at protonmail.com\n\u003e Keybase: michaelfolkson\n\u003e PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3\n\u003e\n\u003e ------- Original Message -------\n\u003e On Saturday, April 23rd, 2022 at 21:40, Jorge Tim贸n \u003cjtimon at jtimon.cc\u003e\n\u003e wrote:\n\u003e\n\u003e I've been calling them \"controversial softforks\" for long.\n\u003e I hate to be right some times, but I guess I'm happy that I'm not the only\n\u003e one who distrusts jeremy rubin anymore.\n\u003e\n\u003e Can we agree now that resisting a bip8 proposal is simpler and cleaner\n\u003e than resisting a speedy trial proposal?\n\u003e I guess now we don't need to discuss it in hypothetical terms anymore, do\n\u003e we?\n\u003e\n\u003e Is there any PR to actively resist the proposal on bitcoin core?\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e On Thu, Apr 21, 2022 at 8:16 PM Michael Folkson via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e Ok so we've had to scramble a bit as I don't think anyone except perhaps\n\u003e\u003e Jeremy thought that there would be a Speedy Trial signaling period for a\n\u003e\u003e CTV soft fork planned to start on May 5th [1]. That is two weeks away.\n\u003e\u003e\n\u003e\u003e (I have to take what he says at face value. I can understand why one\n\u003e\u003e would be skeptical.)\n\u003e\u003e\n\u003e\u003e Understandably this has angered and surprised a few people including some\n\u003e\u003e of those who have voiced opposition to a CTV soft fork activation being\n\u003e\u003e attempted in the first place [2].\n\u003e\u003e\n\u003e\u003e As I've said in a previous post [3] the Bitcoin Core 23.0 release\n\u003e\u003e candidate (and older versions) does not include any CTV code or CTV\n\u003e\u003e activation code. If a miner runs Bitcoin Core 23.0 out the box it will not\n\u003e\u003e signal for CTV. If by some chance CTV was to activate through some other\n\u003e\u003e software release Bitcoin Core releases would not apply CTV rules but they\n\u003e\u003e also wouldn't reject blocks that apply CTV rules. Hence it is prudent to\n\u003e\u003e prepare for an eventuality where the miner signaling threshold might be\n\u003e\u003e reached but the community wants to prevent the attempted soft fork from\n\u003e\u003e activating. (I personally don't think a 90 percent miner signaling\n\u003e\u003e threshold will be reached but I wouldn't want to bet Bitcoin's future on\n\u003e\u003e it.)\n\u003e\u003e\n\u003e\u003e I've tentatively labelled this effort a User Resisted Soft Fork (URSF)\n\u003e\u003e but I'm open to better names. I certainly don't want to discourage those\n\u003e\u003e who dislike or oppose UASFs from contributing to this effort and\n\u003e\u003e potentially ultimately running a URSF release. If you don't want this\n\u003e\u003e rushed CTV soft fork to activate we are all on the same side whatever we\n\u003e\u003e call it.\n\u003e\u003e\n\u003e\u003e For now I've set up a ##ursf channel on Libera IRC to monitor\n\u003e\u003e developments and discuss working on an additional release that if run may\n\u003e\u003e ultimately reject blocks that signal for CTV.\n\u003e\u003e\n\u003e\u003e The intention of this would be to provide additional direction and\n\u003e\u003e incentive to miners that the community does not want this soft fork to be\n\u003e\u003e activated. To repeat running a Bitcoin Core release will not signal for a\n\u003e\u003e CTV soft fork out the box. If a miner runs a Bitcoin Core release it will\n\u003e\u003e not signal for CTV.\n\u003e\u003e\n\u003e\u003e Apologies that this is rushed. But as always with Jeremy caution and\n\u003e\u003e conservatism seems to be thrown out the window and we have to react to\n\u003e\u003e that. It goes without saying that this is not how Bitcoin consensus changes\n\u003e\u003e should be attempted.\n\u003e\u003e\n\u003e\u003e [1]: https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/\n\u003e\u003e [2]:\n\u003e\u003e https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718\n\u003e\u003e [3]:\n\u003e\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020235.html\n\u003e\u003e\n\u003e\u003e --\n\u003e\u003e Michael Folkson\n\u003e\u003e Email: michaelfolkson at protonmail.com\n\u003e\u003e Keybase: michaelfolkson\n\u003e\u003e PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220424/4bd0bb7e/attachment-0001.html\u003e",
"sig": "76d72addaf24286c73800ac467618cb63f37fe916231d6a232354abbeea4b883137275085487d140dd5b2f9bd2a70038e9d819d5cc5d52a996c22da97c2e7906"
}