> 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 <[email protected]> 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 <[email protected]> > 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: [email protected] >> Keybase: michaelfolkson >> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 -- Michael Folkson Email: [email protected] Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 _______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
