From: Michael Folkson <michaelfolkson@gmail•com>
To: Jeremy <jlrubin@mit•edu>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes
Date: Wed, 24 Mar 2021 19:14:12 +0000 [thread overview]
Message-ID: <CAFvNmHR1a7e=20_Rjx0JOPOqibMxJy3J=KfoXNUeXwzb3_tzLw@mail.gmail.com> (raw)
In-Reply-To: <CAD5xwhi8f=w4htNURkZ_eDRgzoHxFYYvBmQWrqff15Spn+hTmA@mail.gmail.com>
> Your response strikes me as ingenuine with regards to "other projects" as it is a project I understand you to be one of the parties spearheading. I think it's misleading to not clarify that in your response.
I support Taproot activation and any project that can help bring that
about. As I have said many times I am 100 percent against an
incompatible UASF release with a Core ST release. However a UASF
project is well within its rights to work around finalized ST
parameters in Core to prepare for a possible (but unlikely) failed ST
deployment, *especially* in the case that Core is unable to.
> As you would ACK either full MTP or full height, but nacking "mixed, seems to be a fallacy of the excluded middle.
I just prefer consistency. If you prefer inconsistency that is your
right. Although "I have a preference for fully height based design,
correct" is another of your direct quotes from 6 days ago. So NACKing
that same approach 6 days later is a touch bizarre.
https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-802396191
> I further find your logic around point 2, 'To prevent a "marketed push to launch a UASF client."', to more aptly apply to ST with height.
"marketed push to launch a UASF client" is a direct quote from your
email. What marketing has to do with anything I have no idea. As I
said in my original response I would prefer not to make technical
decisions based on speculation for the marketing strategy of an
alternative project. That leads down a very dark road of merging in
PRs in response to "world computers" and "Turing completeness"
marketing.
Thanks
Michael
On Wed, Mar 24, 2021 at 6:10 PM Jeremy <jlrubin@mit•edu> wrote:
>
> Michael,
>
> Your response strikes me as ingenuine with regards to "other projects" as it is a project I understand you to be one of the parties spearheading. I think it's misleading to not clarify that in your response.
>
> Your NACK on MTP based ST does not have any merit. The only argument you made for nacking MTP based ST is it is "weird". "Weird" is not a technical argument, it's a normative statement.
>
> As you would ACK either full MTP or full height, but nacking "mixed, seems to be a fallacy of the excluded middle.
>
> AJ's note on this where it is technically justified to use MTP w/ min active height https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-792425221, as such it is not a weird choice at all. In fact, without further patching, if I understand correctly, you wouldn't want to use pure MTP without additional logic.
>
> I further find your logic around point 2, 'To prevent a "marketed push to launch a UASF client."', to more aptly apply to ST with height.
>
>
> Pushing for height based ST is causing additional review burden on contributors in service of enabling a fringe group's side project. That is actually making a technical decision on another project's marketing strategy, and is precisely why I NACK'd it.
>
> Even more outrageously, MTP based ST is easily compatible with a height based BIP8 LOT=true + minactiveheight client, so there really is not a good reason for the fuss. Note -- in general UASF is not the fringe group here -- it's the group trying to preempt the release of an ST client with a UASF client which is the fringe sentiment.
>
> For you to flip the exact argument that I made for rejecting ST Height onto ST MTP is no more than a "I know you are but what am I" argument, which I do not think holds water.
>
> Best,
>
> Jeremy
>
>
>
> --
> @JeremyRubin
>
>
> On Wed, Mar 24, 2021 at 4:24 AM Michael Folkson <michaelfolkson@gmail•com> wrote:
>>
>> Thanks for this Jeremy. I agree with the vast majority of this.
>>
>> For those that missed yesterday's meeting the meeting log is here:
>> http://gnusha.org/taproot-activation/2021-03-23.log
>>
>> Jeremy also livestreamed the meeting on his Twitch channel:
>> https://www.twitch.tv/videos/960346848
>>
>> On the choice between using block heights consistently or using a
>> weird mix of both block heights and MTP in the same activation
>> mechanism you can put me down for a NACK for the latter also.
>>
>> In addition I documented here the preferences for a consistent use of
>> block height:
>> https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-802336038
>>
>> If it was a direct choice between entirely block height or entirely
>> MTP then I probably wouldn't NACK either. But using a mix of both
>> makes no sense to me.
>>
>> The two arguments in favor of using a weird mix of block heights and
>> MTP appear to be:
>> 1) "additional review required to ensure height based activation"
>> 2) To prevent a "marketed push to launch a UASF client."
>>
>> On 1) I would argue that the additional review required is not
>> excessive by any means and we have the time to review a consistent use
>> of block height (especially if people spent their time reviewing a PR
>> with a consistent use of block height rather than arguing for a mix).
>> On 2) if we are making technical decisions based on speculating on the
>> marketing strategies of other projects Bitcoin Core is a very
>> different project to the project I thought it was.
>>
>> I personally would find it much easier to reason about timings and
>> time intervals of the different activation phases if block heights are
>> used consistently across the activation mechanism rather than a weird
>> mix of both block heights and MTP.
>>
>> Other than that, I agree it was an excellent meeting and thanks for
>> your efforts organizing and hosting the meeting.
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson@gmail•com
>> Keybase: michaelfolkson
>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
--
Michael Folkson
Email: michaelfolkson@gmail•com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
next prev parent reply other threads:[~2021-03-24 19:14 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-24 11:23 Michael Folkson
2021-03-24 18:10 ` Jeremy
2021-03-24 19:14 ` Michael Folkson [this message]
-- strict thread matches above, loose matches on Subject: below --
2021-03-24 3:46 Jeremy
2021-03-25 7:02 ` Anthony Towns
2021-03-25 14:30 ` Jeremy
2021-04-06 4:25 ` Rusty Russell
2021-04-07 1:20 ` Ryan Grant
2021-04-07 5:01 ` Rusty Russell
2021-04-07 13:42 ` Claus Ehrenberg
2021-04-07 15:25 ` eric
2021-04-07 17:13 ` Matt Corallo
2021-04-08 11:11 ` Anthony Towns
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='CAFvNmHR1a7e=20_Rjx0JOPOqibMxJy3J=KfoXNUeXwzb3_tzLw@mail.gmail.com' \
--to=michaelfolkson@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jlrubin@mit$(echo .)edu \
/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