path: root/36/d1291441730a6a557f284f51c1e76a9db93507

Return-Path: <antoine.riard@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 181A8C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 16 Sep 2022 19:00:07 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id DDB00843A9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 16 Sep 2022 19:00:06 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org DDB00843A9
Authentication-Results: smtp1.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=j2uLEeXf
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id g4PkFJH72PMP
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 16 Sep 2022 19:00:04 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org C9C9D843D0
Received: from mail-il1-x136.google.com (mail-il1-x136.google.com
 [IPv6:2607:f8b0:4864:20::136])
 by smtp1.osuosl.org (Postfix) with ESMTPS id C9C9D843D0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 16 Sep 2022 19:00:03 +0000 (UTC)
Received: by mail-il1-x136.google.com with SMTP id l6so11800669ilk.13
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 16 Sep 2022 12:00:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date;
 bh=9QZA3TLeHN8SoF7ByU2Tzli3ncw7qMJZ5pN0ydMDP0I=;
 b=j2uLEeXfSP2tGTNlhKVfxZMCV6duzo+Xgba0JPgwneHBsUZbxjq1R3GGVFarznVWkj
 jKl3WHNnCq4XCPoiHawekkj7eSvaTC9PYZDnaWObBrSi4liySEgWvBTViyft9VErph7n
 DLDkQOqX1ynSv6RJnFBbCm8jc7x+jUH2XH21PZ6gk4d3SBfu7D8K/LcTyFroGJQcJl1J
 J1rLG/6d26xMp+PGpwP8Yz9ICVS9VsMVjY6dcW9M0m4zT5ck6QHyavh8dWF3ymCJN13G
 M3WpqAsrUxA7myJagyFylN0yHnwpwRuR8neBxqMsPktknMskRMIjUsGRdIlNzw64pdTJ
 1cDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :x-gm-message-state:from:to:cc:subject:date;
 bh=9QZA3TLeHN8SoF7ByU2Tzli3ncw7qMJZ5pN0ydMDP0I=;
 b=dxyp4/Sfa4xIgI+Z8oJuFQbths8JkunpGlg2FqwrIRX+4Mzw5iJw9/2WJtzBuY/ith
 ZGFFHaqLgy8/Jt3lajQ6V1sBKKZY4R58UiTYsqzhNoNifq5UfVHsDU9+ENFc54LLuiEV
 YNXoPUGUFDTkaWJwWtZqvha/hXzMy/R7H+Jr+SD+QCGtzZ/SzS09XDKEctgYNpUJe8/P
 LpPorTT8A2UkxovyGEqXv7xLsp/YUjuOg/bIPZt0jK0ewtBKr/AAirp3yjVdbLW+J4zY
 4zfOoKO++tdvCn+Q6qEsf9D6O5ObUK4pYLv9jzi2clwe46NRU9mqOkAwEiAXizUmWfHB
 8Svg==
X-Gm-Message-State: ACrzQf0r4oY74QqdMDVh4NiTCSlER7OP8TJOiY9/Fof6mJMd7PLwBplo
 pvvQ3kGsHDSea9uK6p+LuuJZjZjNG/NCQmcgD9Y=
X-Google-Smtp-Source: AMsMyM7AhGMRm/StjloSsKAWpk2cvafK/TsTFZzm8hD8jlq+4u+1/yk4ZeOghAlM9l8hTq67VtVazMe8yQgi3HsTtV0=
X-Received: by 2002:a05:6e02:1102:b0:2ea:da70:efea with SMTP id
 u2-20020a056e02110200b002eada70efeamr3039215ilk.70.1663354802687; Fri, 16 Sep
 2022 12:00:02 -0700 (PDT)
MIME-Version: 1.0
References: <BQjnkZZajHKYBOUFAin8toHgNHhG346VUR4GQx6bSi2ftOuNTK1c1d4LWN4Zmr0tUg2w3xgtIZJSphBORYgWw4PPXq5pGFoZJk2Lx6AokuQ=@protonmail.com>
In-Reply-To: <BQjnkZZajHKYBOUFAin8toHgNHhG346VUR4GQx6bSi2ftOuNTK1c1d4LWN4Zmr0tUg2w3xgtIZJSphBORYgWw4PPXq5pGFoZJk2Lx6AokuQ=@protonmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Fri, 16 Sep 2022 14:59:50 -0400
Message-ID: <CALZpt+HaeyA8U_6G6RMZCzK944qs4i1ZtcQ=gvAYHm-NSFe4xw@mail.gmail.com>
To: Buck O Perley <buck.perley@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000026545705e8cff878"
X-Mailman-Approved-At: Fri, 16 Sep 2022 19:18:15 +0000
Subject: Re: [bitcoin-dev] On a new community process to specify covenants
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Sep 2022 19:00:07 -0000

--00000000000026545705e8cff878
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Buck,

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

Thanks for the words. Effectively, organic WGs are likely good avenues for
the ecosystem to make steady and substantial progress during the coming
future. If there is any structure in the development of Bitcoin it's the
rich network of open, neutral and decentralized communication networks and
spaces that has been nurtured through the past decade and I hope that's a
tradition we'll keep maintaining.

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

I would say I really like IRC too. The strong text-based format, the lack
of avatar emoji, the low-bar to participate pseudonymously, the leveling
field for non-native speakers contrary to audio and the easiness to grab
the mics, all features valuable for such a process I think.

If IRC is still considered a technical high-bar for a standard
communication organ by many community stakeholders, discord is an
alternative.

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

From my understanding, how any of these primitives end up getting activated
is more a deployment methodology concern. What is more interesting is why
any of those primitives would be valuable as a Bitcoin upgrade. Beyond
proposing and refining primitives design and associated use-cases, there is
significant work to collect feedback on many dimensions and set of
criterias that matters to community stakeholders to achieve a consistent
and sound "why".

Where I believe there is an interaction between the "why" and "how" is that
during activation discussion some participant might bring new information
about shortcomings of a proposal, and as such if it's estimated relevant
could induce a step back to the "R&D" whiteboard phase, in a circular
feedback loop fashion. As those steps back are not free in terms of
community engineering resources, especially if deployment code starts to be
already disseminated across the ecosystem, I hope in the future we'll leave
reasonable time (in function of the complexity of the proposal) between
upgrade phases for grounded objections to raise.

From my memory, about the taproot activation process it's correct that a
lot of people had discussions about producing more proof-of-work, e.g back
in 2019, LN devs were excited to PoC PTLC in the context of the structured
taproot review.
It didn't happen because it would have implied good refactoring works in
all implementations for that to happen and coordination with cryptographic
libraries dependencies.

In fact, it's likely the difficulty target for consensus upgrades to be
dynamic with the complexity of the ecosystem and stakes at risk increasing
modulo the amount of Bitcoin engineering resources dedicated.

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

I think it could be interesting for activation to have its own WG. I
wouldn't call myself super knowledgeable in upgrades activation. I believe
it could be worthy for such WG to do the archival work of documentation and
referencing well all
the previous upgrades discussions, the set of signals and data points that
has been deemed as valuable by the community, etc.

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

I agree with the sentiment, that it would be worthy to have multiple groups
happening at once, in a asynchronous and decentralized fashion, neutral
from centralized companies or cultural mobs. However, on the linearity of
the discussions post-Taproot, from my perspective the reason doesn't have
to be found in any community stakeholder bottlenecking or whatever but
rather in the limited subset of experienced Bitcoin protocol engineers we
have across the ecosystem. From quick mental maths, the number of active
folks with more than 4/5 years of experience and decent practical knowledge
of the critical Bitcoin subsystems to be able to work on consensus upgrades
is likely to be evaluated to two dozens. No more. And they're already the
most busy of the ecosystem: maintaining the critical pieces of code,
catching the bugs during reviews, doing active security research, caring
about the Q&A & release process, sharing back the knowledge towards new
devs...

Of course, everyone of them as the choice to prioritize consensus upgrades
over other tasks, but in the long-term it's likely at the detriment of
outcome valued by the community as a whole (e.g hardening the base-layer
P2P stack against high grade attacks, solving Lightning numerous liquidity
issues, etc).

Real weakness is the fact that as a community we're bleeding too much
seasoned protocol engineers for XYZ reasons.

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

First and foremost, thanks to everyone dedicating resources (engineering,
financial, operational, legal, ...) towards making Bitcoin stronger. About
bipbounty.org, I would like to observe the neutrality of the
decision-making process in the fund allocation could be better, especially
in terms of high-impact and sensitive subjects like consensus upgrades. It
sounds like the unique team member is also the technical author of the only
bounty displayed so far... Academics, law and medecine have centuries-long
traditions of board or peer-to-peer decision-making structure to allocate
scientific and engineering ressources with minimal guarantees of neutrality=
.

I think it would be valuable for this effort to structure for the
long-term, it would be great to have more community people dedicating their
own personal time on doing the hard operational and legal work to make
things sustainable. I would say there is definitively a need for more
Bitcoin researchers working on multiple-years scale "moonshots" projects.

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

Yeah, I think in-person meetups would be very valuable and personally I've
always appreciated the knowledge sharing, priorities setting and
productivity boost of all the Bitcoin engineering meetings I've had the
opportunity to attend. 6 months - 1 year after the start of the regular
online meetings sounds like a good timeline, there is a preliminary step of
folks flooding and exchanging on their expectations, taking the process
habits and doing seminal work.

Best,
Antoine

Le dim. 11 sept. 2022 =C3=A0 22:47, Buck O Perley via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit :

> 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.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--00000000000026545705e8cff878
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Buck,<br><br>&gt; First just wanted to thank you for ta=
king the initiative to <br>&gt; put this together. I think that as the comm=
unity and <br>&gt; ecosystem continue to grow, it&#39;s going to be an impo=
rtant <br>&gt; part of the process to have groups like this develop. Hopefu=
lly<br>&gt; they allow us to resist the &quot;Tyranny of Structurelessness&=
quot; without <br>&gt; resorting to formalized governance processes and sys=
tems. <br><br>Thanks for the words. Effectively, organic WGs are likely goo=
d avenues for the ecosystem to make steady and substantial progress during =
the coming future. If there is any structure in the development of Bitcoin =
it&#39;s the rich network of open, neutral and decentralized communication =
networks and spaces that has been nurtured through the past decade and I ho=
pe that&#39;s a tradition we&#39;ll keep maintaining.<br><br>&gt; Defining =
a communication channel is still an open question: IRC, Slack,<br>Discord, =
Discourse, ...<br><br>I would vote against Slack. IRC is probably the best =
but maybe too high a barrier to entry? Publishing logs at least would count=
er concerns of it being exclusive. Maybe discord as an alternative.<br><br>=
I would say I really like IRC too. The strong text-based format, the lack o=
f avatar emoji, the low-bar to participate pseudonymously, the leveling fie=
ld for non-native speakers contrary to audio and the easiness to grab the m=
ics, all features valuable for such a process I think.<br><br>If IRC is sti=
ll considered a technical high-bar for a standard communication organ by ma=
ny community stakeholders, discord is an alternative.<br><br>&gt; I underst=
and the reason for this but I do have some concerns that<br>&gt; it&#39;s n=
ot as off-topic as most of us would like. It shouldn&#39;t<br>&gt; be a pri=
ority but how any of these primitives end up getting activated<br>&gt; is p=
art of the proposal itself in my opinion. <br>&gt; <br>&gt; I think it also=
 became clear in some of the discussions over the past <br>&gt; ~year that =
maybe there were more concerns than people realized about<br>&gt; even the =
taproot activation process, whether the method used or if it <br>&gt; was d=
one too quickly. An example of where there might be <br>&gt; some intersect=
ion with the WG as proposed is the question of how much <br>&gt; research, =
security audits, etc. are &quot;enough&quot; before it should be <br>&gt; c=
onsidered for activation? <br><br>From my understanding, how any of these p=
rimitives end up getting activated is more a deployment methodology concern=
. What is more interesting is why any of those primitives would be valuable=
 as a Bitcoin upgrade. Beyond proposing and refining primitives design and =
associated use-cases, there is significant work to collect feedback on many=
 dimensions and set of criterias that matters to community stakeholders to =
achieve a consistent and sound &quot;why&quot;.<br><br>Where I believe ther=
e is an interaction between the &quot;why&quot; and &quot;how&quot; is that=
 during activation discussion some participant might bring new information =
about shortcomings of a proposal, and as such if it&#39;s estimated relevan=
t could induce a step back to the &quot;R&amp;D&quot; whiteboard phase, in =
a circular feedback loop fashion. As those steps back are not free in terms=
 of community engineering resources, especially if deployment code starts t=
o be already disseminated across the ecosystem, I hope in the future we&#39=
;ll leave reasonable time (in function of the complexity of the proposal) b=
etween upgrade phases for grounded objections to raise.<br><br>From my memo=
ry, about the taproot activation process it&#39;s correct that a lot of peo=
ple had discussions about producing more proof-of-work, e.g back in 2019, L=
N devs were excited to PoC PTLC in the context of the structured taproot re=
view.<br>It didn&#39;t happen because it would have implied good refactorin=
g works in all implementations for that to happen and coordination with cry=
ptographic libraries dependencies.<br><br>In fact, it&#39;s likely the diff=
iculty target for consensus upgrades to be dynamic with the complexity of t=
he ecosystem and stakes at risk increasing modulo the amount of Bitcoin eng=
ineering resources dedicated.<br><br>&gt; Maybe as a way to keep these topi=
cs separate, it would make sense <br>&gt; for activation to have its own WG=
. As norms develop around this one, <br>&gt; they could inform creating a s=
eparate space focused on forwarding <br>&gt; research and discussion around=
 how to introduce upgrades to bitcoin. <br><br>I think it could be interest=
ing for activation to have its own WG. I wouldn&#39;t call myself super kno=
wledgeable in upgrades activation. I believe it could be worthy for such WG=
 to do the archival work of documentation and referencing well all<br>the p=
revious upgrades discussions, the set of signals and data points that has b=
een deemed as valuable by the community, etc.<br><br>&gt; In general it wou=
ld be nice to have multiple of these groups<br>&gt; happening at once, and =
finding a way that they can operate separate<br>&gt; from centralized compa=
nies. To my mind, there&#39;s no good reason why<br>&gt; a supposedly decen=
tralized protocol should have to be focusing on only<br>&gt; one set of pro=
tocol advancements at a time. The linear way that<br>&gt; discussions post-=
Taproot activation took shape (&quot;What do you think the<br>&gt; next bit=
coin softfork should be?&quot;) is a sign of weakness in my opinion. <br>&g=
t; Definitely a big red flag that we should be concerned with. <br><br>I ag=
ree with the sentiment, that it would be worthy to have multiple groups hap=
pening at once, in a asynchronous and decentralized fashion, neutral from c=
entralized companies or cultural mobs. However, on the linearity of the dis=
cussions post-Taproot, from my perspective the reason doesn&#39;t have to b=
e found in any community stakeholder bottlenecking or whatever but rather i=
n the limited subset of experienced Bitcoin protocol engineers we have acro=
ss the ecosystem. From quick mental maths, the number of active folks with =
more than 4/5 years of experience and decent practical knowledge of the cri=
tical Bitcoin subsystems to be able to work on consensus upgrades is likely=
 to be evaluated to two dozens. No more. And they&#39;re already the most b=
usy of the ecosystem: maintaining the critical pieces of code, catching the=
 bugs during reviews, doing active security research, caring about the Q&am=
p;A &amp; release process, sharing back the knowledge towards new devs...<b=
r><br>Of course, everyone of them as the choice to prioritize consensus upg=
rades over other tasks, but in the long-term it&#39;s likely at the detrime=
nt of outcome valued by the community as a whole (e.g hardening the base-la=
yer P2P stack against high grade attacks, solving Lightning numerous liquid=
ity issues, etc).<br><br>Real weakness is the fact that as a community we&#=
39;re bleeding too much seasoned protocol engineers for XYZ reasons.<br><br=
>&gt; * it seems like there might be some opportunities to work with <br>&g=
t; <a href=3D"http://bipbounty.org">bipbounty.org</a> which grew out of the=
 organic bounty donations that<br>&gt; were made towards finding CTV vulner=
abilities. For example, <br>&gt; if the group develops specific, achievable=
 research goals (building<br>&gt; out use cases, researching vulnerabilitie=
s or limitations, etc.), <br>&gt; <a href=3D"http://bipbounty.org">bipbount=
y.org</a> could help support these efforts in a more decentralized<br>&gt; =
way by diversifying funding. <br><br>First and foremost, thanks to everyone=
 dedicating resources (engineering, financial, operational, legal, ...) tow=
ards making Bitcoin stronger. About <a href=3D"http://bipbounty.org">bipbou=
nty.org</a>, I would like to observe the neutrality of the decision-making =
process in the fund allocation could be better, especially in terms of high=
-impact and sensitive subjects like consensus upgrades. It sounds like the =
unique team member is also the technical author of the only bounty displaye=
d so far... Academics, law and medecine have centuries-long traditions of b=
oard or peer-to-peer decision-making structure to allocate scientific and e=
ngineering ressources with minimal guarantees of neutrality.<br><br>I think=
 it would be valuable for this effort to structure for the long-term, it wo=
uld be great to have more community people dedicating their own personal ti=
me on doing the hard operational and legal work to make things sustainable.=
 I would say there is definitively a need for more Bitcoin researchers work=
ing on multiple-years scale &quot;moonshots&quot; projects.<br><br>&gt; * A=
ny thoughts on starting to commit to an in-person meetup to happen <br>&gt;=
 ~6 months - 1 year after the start of the regular online meetings? <br>&gt=
; That should be plenty of time for people to plan and formalize <br>&gt; a=
 location and it seems like other IRL dev meetups have been <br>&gt; very p=
roductive in terms of knowledge sharing and setting priorities. <br>&gt; An=
 in-person meetup would give a nice goal to work towards and a way<br>&gt; =
to measure progress. <br><br>Yeah, I think in-person meetups would be very =
valuable and personally I&#39;ve always appreciated the knowledge sharing, =
priorities setting and productivity boost of all the Bitcoin engineering me=
etings I&#39;ve had the opportunity to attend. 6 months - 1 year after the =
start of the regular online meetings sounds like a good timeline, there is =
a preliminary step of folks flooding and exchanging on their expectations, =
taking the process habits and doing seminal work.<br><br>Best,<br>Antoine<b=
r></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr=
">Le=C2=A0dim. 11 sept. 2022 =C3=A0=C2=A022:47, Buck O Perley via bitcoin-d=
ev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev=
@lists.linuxfoundation.org</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex">Hi Antoine,<br>
<br>
First just wanted to thank you for taking the initiative to <br>
put this together. I think that as the community and <br>
ecosystem continue to grow, it&#39;s going to be an important <br>
part of the process to have groups like this develop. Hopefully<br>
they allow us to resist the &quot;Tyranny of Structurelessness&quot; withou=
t <br>
resorting to formalized governance processes and systems. <br>
<br>
&gt; Defining a communication channel is still an open question: IRC, Slack=
,<br>
Discord, Discourse, ...<br>
<br>
I would vote against Slack. IRC is probably the best but maybe too<br>
high a barrier to entry? Publishing logs at least would counter<br>
concerns of it being exclusive. Maybe discord as an alternative. <br>
<br>
&gt; About the starting point for regular meetings, I think the good timing=
 is<br>
somewhere in November, after the upcoming cycle of Bitcoin conferences,<br>
<br>
+1 <br>
<br>
&gt; softfork activation discussions will be considered as<br>
off-topic and discouraged. This is first and foremost a long-term R&amp;D<b=
r>
effort.<br>
<br>
I understand the reason for this but I do have some concerns that<br>
it&#39;s not as off-topic as most of us would like. It shouldn&#39;t<br>
be a priority but how any of these primitives end up getting activated<br>
is part of the proposal itself in my opinion. <br>
<br>
I think it also became clear in some of the discussions over the past <br>
~year that maybe there were more concerns than people realized about<br>
even the taproot activation process, whether the method used or if it <br>
was done too quickly. An example of where there might be <br>
some intersection with the WG as proposed is the question of how much <br>
research, security audits, etc. are &quot;enough&quot; before it should be =
<br>
considered for activation? <br>
<br>
Maybe as a way to keep these topics separate, it would make sense <br>
for activation to have its own WG. As norms develop around this one, <br>
they could inform creating a separate space focused on forwarding <br>
research and discussion around how to introduce upgrades to bitcoin. <br>
<br>
In general it would be nice to have multiple of these groups<br>
happening at once, and finding a way that they can operate separate<br>
from centralized companies. To my mind, there&#39;s no good reason why<br>
a supposedly decentralized protocol should have to be focusing on only<br>
one set of protocol advancements at a time. The linear way that<br>
discussions post-Taproot activation took shape (&quot;What do you think the=
<br>
next bitcoin softfork should be?&quot;) is a sign of weakness in my opinion=
. <br>
Definitely a big red flag that we should be concerned with. <br>
<br>
Couple other comments from the proposal/repo:<br>
<br>
* it seems like there might be some opportunities to work with <br>
<a href=3D"http://bipbounty.org" rel=3D"noreferrer" target=3D"_blank">bipbo=
unty.org</a> which grew out of the organic bounty donations that<br>
were made towards finding CTV vulnerabilities. For example, <br>
if the group develops specific, achievable research goals (building<br>
out use cases, researching vulnerabilities or limitations, etc.), <br>
<a href=3D"http://bipbounty.org" rel=3D"noreferrer" target=3D"_blank">bipbo=
unty.org</a> could help support these efforts in a more decentralized<br>
way by diversifying funding. <br>
<br>
* Any thoughts on starting to commit to an in-person meetup to happen <br>
~6 months - 1 year after the start of the regular online meetings? <br>
That should be plenty of time for people to plan and formalize <br>
a location and it seems like other IRL dev meetups have been <br>
very productive in terms of knowledge sharing and setting priorities. <br>
An in-person meetup would give a nice goal to work towards and a way<br>
to measure progress. <br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--00000000000026545705e8cff878--