diff options
| author | Antoine Riard <antoine.riard@gmail.com> | 2022-09-16 14:59:50 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-09-16 19:00:07 +0000 |
| commit | 405385a08de7a147e902231204bfb2d8497dc9dd (patch) | |
| tree | 53ff215cf9886ea1b76eeac0e8f936c152d4d28f | |
| parent | 02459f5074699dc6894beda8df4a1246f691e398 (diff) | |
| download | pi-bitcoindev-405385a08de7a147e902231204bfb2d8497dc9dd.tar.gz pi-bitcoindev-405385a08de7a147e902231204bfb2d8497dc9dd.zip | |
Re: [bitcoin-dev] On a new community process to specify covenants
| -rw-r--r-- | 36/d1291441730a6a557f284f51c1e76a9db93507 | 561 |
1 files changed, 561 insertions, 0 deletions
diff --git a/36/d1291441730a6a557f284f51c1e76a9db93507 b/36/d1291441730a6a557f284f51c1e76a9db93507 new file mode 100644 index 000000000..b8f5fe331 --- /dev/null +++ b/36/d1291441730a6a557f284f51c1e76a9db93507 @@ -0,0 +1,561 @@ +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>> First just wanted to thank you for ta= +king the initiative to <br>> put this together. I think that as the comm= +unity and <br>> ecosystem continue to grow, it's going to be an impo= +rtant <br>> part of the process to have groups like this develop. Hopefu= +lly<br>> they allow us to resist the "Tyranny of Structurelessness&= +quot; without <br>> 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'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's a tradition we'll keep maintaining.<br><br>> 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>> I underst= +and the reason for this but I do have some concerns that<br>> it's n= +ot as off-topic as most of us would like. It shouldn't<br>> be a pri= +ority but how any of these primitives end up getting activated<br>> is p= +art 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 d= +one too quickly. An example of where there might be <br>> some intersect= +ion with the WG as proposed is the question of how much <br>> research, = +security audits, etc. are "enough" before it should be <br>> 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 "why".<br><br>Where I believe ther= +e 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 relevan= +t 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 t= +o be already disseminated across the ecosystem, I hope in the future we'= +;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'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'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'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>> Maybe as a way to keep these topi= +cs 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 s= +eparate space focused on forwarding <br>> 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'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>> In general it wou= +ld be nice to have multiple of these groups<br>> happening at once, and = +finding a way that they can operate separate<br>> from centralized compa= +nies. To my mind, there's no good reason why<br>> a supposedly decen= +tralized protocol should have to be focusing on only<br>> one set of pro= +tocol advancements at a time. The linear way that<br>> discussions post-= +Taproot activation took shape ("What do you think the<br>> next bit= +coin softfork should be?") 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'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'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 & 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'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= +>> * 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>> were made towards finding CTV vulner= +abilities. For example, <br>> if the group develops specific, achievable= + research goals (building<br>> out use cases, researching vulnerabilitie= +s or limitations, etc.), <br>> <a href=3D"http://bipbounty.org">bipbount= +y.org</a> could help support these efforts in a more decentralized<br>> = +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 "moonshots" projects.<br><br>> * A= +ny 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 p= +roductive 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>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 me= +etings 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.<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 <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev= +@lists.linuxfoundation.org</a>> 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'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 "Tyranny of Structurelessness" withou= +t <br> +resorting to formalized governance processes and systems. <br> +<br> +> 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> +> 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> +> softfork activation discussions will be considered as<br> +off-topic and discouraged. This is first and foremost a long-term R&D<b= +r> +effort.<br> +<br> +I understand the reason for this but I do have some concerns that<br> +it's not as off-topic as most of us would like. It shouldn'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 "enough" 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'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 ("What do you think the= +<br> +next bitcoin softfork should be?") 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-- + |