From: Buck O Perley <buck.perley@protonmail•com>
To: "bitcoin-dev@lists•linuxfoundation.org"
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] On a new community process to specify covenants
Date: Mon, 12 Sep 2022 00:05:18 +0000 [thread overview]
Message-ID: <BQjnkZZajHKYBOUFAin8toHgNHhG346VUR4GQx6bSi2ftOuNTK1c1d4LWN4Zmr0tUg2w3xgtIZJSphBORYgWw4PPXq5pGFoZJk2Lx6AokuQ=@protonmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 3429 bytes --]
Hi Antoine,
First just wanted to thank you for taking the initiative to
put this together. I think that as the community and
ecosystem continue to grow, it's going to be an important
part of the process to have groups like this develop. Hopefully
they allow us to resist the "Tyranny of Structurelessness" without
resorting to formalized governance processes and systems.
> Defining a communication channel is still an open question: IRC, Slack,
Discord, Discourse, ...
I would vote against Slack. IRC is probably the best but maybe too
high a barrier to entry? Publishing logs at least would counter
concerns of it being exclusive. Maybe discord as an alternative.
> About the starting point for regular meetings, I think the good timing is
somewhere in November, after the upcoming cycle of Bitcoin conferences,
+1
> softfork activation discussions will be considered as
off-topic and discouraged. This is first and foremost a long-term R&D
effort.
I understand the reason for this but I do have some concerns that
it's not as off-topic as most of us would like. It shouldn't
be a priority but how any of these primitives end up getting activated
is part of the proposal itself in my opinion.
I think it also became clear in some of the discussions over the past
~year that maybe there were more concerns than people realized about
even the taproot activation process, whether the method used or if it
was done too quickly. An example of where there might be
some intersection with the WG as proposed is the question of how much
research, security audits, etc. are "enough" before it should be
considered for activation?
Maybe as a way to keep these topics separate, it would make sense
for activation to have its own WG. As norms develop around this one,
they could inform creating a separate space focused on forwarding
research and discussion around how to introduce upgrades to bitcoin.
In general it would be nice to have multiple of these groups
happening at once, and finding a way that they can operate separate
from centralized companies. To my mind, there's no good reason why
a supposedly decentralized protocol should have to be focusing on only
one set of protocol advancements at a time. The linear way that
discussions post-Taproot activation took shape ("What do you think the
next bitcoin softfork should be?") is a sign of weakness in my opinion.
Definitely a big red flag that we should be concerned with.
Couple other comments from the proposal/repo:
* it seems like there might be some opportunities to work with
bipbounty.org which grew out of the organic bounty donations that
were made towards finding CTV vulnerabilities. For example,
if the group develops specific, achievable research goals (building
out use cases, researching vulnerabilities or limitations, etc.),
bipbounty.org could help support these efforts in a more decentralized
way by diversifying funding.
* Any thoughts on starting to commit to an in-person meetup to happen
~6 months - 1 year after the start of the regular online meetings?
That should be plenty of time for people to plan and formalize
a location and it seems like other IRL dev meetups have been
very productive in terms of knowledge sharing and setting priorities.
An in-person meetup would give a nice goal to work towards and a way
to measure progress.
[-- Attachment #2: publickey - buck.perley@protonmail.com - 0xC64EEB00.asc --]
[-- Type: application/pgp-keys, Size: 608 bytes --]
next reply other threads:[~2022-09-12 0:05 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-12 0:05 Buck O Perley [this message]
2022-09-13 16:02 ` Ryan Grant
2022-09-15 8:05 ` Devrandom
2022-09-16 19:08 ` Antoine Riard
2022-09-16 18:59 ` Antoine Riard
2022-09-17 7:52 ` Devrandom
-- strict thread matches above, loose matches on Subject: below --
2022-07-20 20:42 Antoine Riard
2022-07-23 5:09 ` Ryan Grant
2022-07-23 14:57 ` Antoine Riard
2022-07-23 14:25 ` Michael Folkson
2022-07-23 16:41 ` Antoine Riard
2022-07-24 13:01 ` aliashraf.btc At protonmail
2022-07-24 23:40 ` ZmnSCPxj
2022-07-26 3:20 ` Antoine Riard
2022-07-26 3:18 ` Antoine Riard
2022-07-24 18:22 ` Bram Cohen
2022-07-24 20:26 ` aliashraf.btc At protonmail
2022-07-26 3:21 ` Antoine Riard
2022-07-26 16:02 ` Bram Cohen
2022-08-03 15:37 ` Billy Tetrud
2022-08-09 20:15 ` Antoine Riard
2022-08-27 21:01 ` Billy Tetrud
2022-08-30 15:46 ` Antoine Riard
2022-09-10 0:10 ` Antoine Riard
2022-10-07 15:33 ` Antoine Riard
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='BQjnkZZajHKYBOUFAin8toHgNHhG346VUR4GQx6bSi2ftOuNTK1c1d4LWN4Zmr0tUg2w3xgtIZJSphBORYgWw4PPXq5pGFoZJk2Lx6AokuQ=@protonmail.com' \
--to=buck.perley@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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