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