Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes

[Jeremy <jlrubin@mit.edu>]

[-- Attachment #1: Type: text/plain, Size: 3969 bytes --]

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 <https://twitter.com/JeremyRubin>
<https://twitter.com/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
>

[-- Attachment #2: Type: text/html, Size: 8056 bytes --]