From: Jeremy Rubin <jeremy.l.rubin@gmail.com>
To: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Subject: [bitcoin-dev] On The Drama
Date: Sun, 1 May 2022 20:16:58 -0700 [thread overview]
Message-ID: <CAD5xwhhZN63PmxytFxKy=8KCZUxpDCV8j3kyNj7jVW3+aqcVNA@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 4372 bytes --]
Developers,
I know that some of you may be interested in hearing my perspective on what
happened and why. I still do not know exactly what happened and why.
However, I can offer a brief explanation of what I perceived my main
actions to be and the response to them:
1. I published and shared to this list a blog post encouraging review on
viability of having a Speedy Trial (ST) with signalling beginning around
3.5 weeks (May 12th), in line with previously communicated materials.
2. I held a regularly scheduled meeting to discuss the viability of an
activation attempt, "The Agenda for the meeting will be an open discussion
on the possibility of activating CTV[CheckTemplateVerify] in 2022, why we
may or may not wish to do that, if we did want to do that what would need
to be done, what the path might look like if we do not do that."
3. If ST was deemed viable, I provided a pathway for sufficient review to
occur and I also wrote User Resisted Soft Fork(URSF) software to be used
such that miners are not unilaterally in control, as well as encouragement
for someone to author a User Activated Soft Fork(UASF) as a follow up if
miners "vetoed".
4. If ST was not viable, I gave encouragement to more thoroughly "re-evaluate
the design of CTV against alternatives that would take more time to prepare
engineering wise (e.g., more general covenants, small tweaks to CTV)"
5. I Made clear that CTV activation was "not a must. All actors must decide
if it’s in their own rational self-interest to have the soft-fork proceed."
6. I provided a review of rationale for why I thought this to be the right
next step for CTV, and for future soft forks to follow.
Since I posted my blog, there have been a flurry of inaccurate claims
lobbed at me across various platforms that I am trying to route around
consensus, force miners to do a ST, force users to accept a patch they
don't want, calls for me to face various repercussions, attacks on my
character, and more. Anyone is free to read the material I actually
communicated myself and evaluate the claims of bad-faith being made. I
accept responsibility that ultimately I may not have communicated these
things clearly enough.
I've kept my word to listen to feedback on parameters before any release:
- I've not released binaries for a ST CTV client in May, and won't be.
- I've kept my promise not to run a UASF process.
I hope you can believe me that I am not trying to do anything wanton to
Bitcoin. I am trying to do my best to accurately communicate my exact
intentions and plans along the way, and learn from the ways I fell short.
I cannot thank enough the (majority!) of individuals who understand this
and have provided overwhelming amounts of personal support to me through
these last weeks. While I do not mistake that personal support for support
of my views, I wanted to share the depth of support and appreciation that
the community has for the difficult tasks developers engage in. This isn't
specific to me; the community has immense respect for the sacrifices every
developer makes in choosing to work on Bitcoin. The hate may be loud and
public on the shallow surface, but the love and support runs deep.
At the same time, it has been eye opening for me to see the processes by
which a kernel of disinformation blossoms into a panic across the Bitcoin
community. For any Bitcoin contributor who might engage in consensus
processes: Agree or disagree with the quality of my actions, it's worth
spending a little time to trace how the response to my proposal was
instigated so that you harden your own defenses against such disinformation
campaigns in the future. I encourage you to look closely at what various
"respected members of the community" have lobbied for because they
represent dangerous precedents for all Bitcoin developers. I've yet to
fully form my thoughts around this.
If you do not think that my actions lived up with my perception of them,
feel free to give me, either publicly or privately, any feedback on how I
can do better going forward.
With respect to this thread, I'll read whatever you send, but I won't be
reply-all'ing here as I view this as largely off-topic for this list,
unless anyone feels strongly otherwise.
Best,
Jeremy
--
@JeremyRubin <https://twitter.com/JeremyRubin>
[-- Attachment #2: Type: text/html, Size: 6142 bytes --]
reply other threads:[~2022-05-02 3:17 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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='CAD5xwhhZN63PmxytFxKy=8KCZUxpDCV8j3kyNj7jVW3+aqcVNA@mail.gmail.com' \
--to=jeremy.l.rubin@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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