From: Michael Folkson <michaelfolkson@gmail•com>
To: jlrubin@mit•edu,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes
Date: Wed, 24 Mar 2021 11:23:53 +0000 [thread overview]
Message-ID: <CAFvNmHTtH=ohCY1e3nS5GVACzbBJs1MCEcYO-yxzRFOQqgULqQ@mail.gmail.com> (raw)
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
next reply other threads:[~2021-03-24 11:24 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-24 11:23 Michael Folkson [this message]
2021-03-24 18:10 ` Jeremy
2021-03-24 19:14 ` Michael Folkson
-- 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='CAFvNmHTtH=ohCY1e3nS5GVACzbBJs1MCEcYO-yxzRFOQqgULqQ@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