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 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 >