From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id AFE59C002D for ; Sat, 23 Jul 2022 14:58:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 7F69940995 for ; Sat, 23 Jul 2022 14:58:10 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 7F69940995 Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=dlQ3KPmv 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 smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89ztR8VeDxJ2 for ; Sat, 23 Jul 2022 14:58:09 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org DFA86408A2 Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) by smtp4.osuosl.org (Postfix) with ESMTPS id DFA86408A2 for ; Sat, 23 Jul 2022 14:58:08 +0000 (UTC) Received: by mail-io1-xd2b.google.com with SMTP id z132so5605707iof.0 for ; Sat, 23 Jul 2022 07:58:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2tSdaeGo/YvP4u2hIsjS+DUHI7CS8X9GM0X5cBrbkiM=; b=dlQ3KPmvr3R98xK2GyAb6Pp7XlDY12c5BxvTs3D7wHdnvLUKAJs/badCAUX0nWnYVd Q950vvlNCd35qDtivBEojSFQENGwre1KN7orEXXxXWw+thphvezcVO8c0szYN45cA4Ar KI30tUPXXOd/bD+FIrLb14SYaU26SXkhJ9QIZHJuReOmj/X7olmta6UuoCBHPPkhV6b/ wssDHrUxondQGC7JousM62O3gUrVRWLkqluFuuGiCgl7hsykzBb4rDwVyvkYzadd4Kti Tc7tCPQbAlqGCI+Bbgr+o/hodFs4hvudFTZGO/Ree7+wtpNq8ZXiqlXsXir6cSTZvVhc r1Og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2tSdaeGo/YvP4u2hIsjS+DUHI7CS8X9GM0X5cBrbkiM=; b=L5ycq7njxXVouDE0tawQTs1cbQvm0aT2oPl/akdBtx6TKzMGorfwHsERYNam7HFJGG H4c8SJrtIfJyo+fbKlfX9DVq/RA/7IFrQCqAsGRoaI5LtrM7SdvBemfBBZfZ+mW55eMW JnBUkhdPflsCkfU5+4jlTib4xQIgaDiSAXzOn+cZ2x57ZVGJ8Fnhp9XaD1USV1ErBBGZ 2nuPkQlFSYD3jQCcCY7vGk0R7dCwpnGZNIDP8JggABSMlgk64+muDbfQqa+jAE9py7od bPKuSRdtggLgoKdbSY3s5xOqjk9xGQQ6RuUl4Ms5JUHlIoRmh3OCVnsjTcssbeL5qkkE QwBA== X-Gm-Message-State: AJIora8f2dqv8x32tf0bfnovUTgsODLftD15BE2rTXiEhtKSKmADAZz2 DeMEhOy09jXVnQUg+aHSkxlxKvRTTvBhNBnAtyRR4d3jniE= X-Google-Smtp-Source: AGRyM1uc4wKdyQrgg5/82q4xGLbuf91aVpFCRt6C1ZUV2/GOjeit1HgiM2Q3i2F4+fsHknJvwjx55XvG5I+nYPV2XAE= X-Received: by 2002:a05:6638:1483:b0:33f:7944:a30d with SMTP id j3-20020a056638148300b0033f7944a30dmr1967248jak.155.1658588287780; Sat, 23 Jul 2022 07:58:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Antoine Riard Date: Sat, 23 Jul 2022 15:57:56 +0100 Message-ID: To: Ryan Grant Content-Type: multipart/alternative; boundary="000000000000b8ccfb05e47a2d21" X-Mailman-Approved-At: Sat, 23 Jul 2022 15:00:22 +0000 Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2022 14:58:10 -0000 --000000000000b8ccfb05e47a2d21 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ryan, > Certain human/organizational limitations prevent things being said in > logged channels that sometimes can be shared in person. Sometimes > people break through misunderstandings in person, through either > informal mingling or the use of Chatham House rules. So I would also > advocate restarting the Scaling Bitcoin conferences, twice a year. Just for clarity, I'm proposing online meetings on IRC, not in-person. But yes, logged channels can be really narrow on topics and in person sometimes let people grasp the bigger picture or wider context more easily. In my opinion, to build understanding and sync on a complex topic there is nothing like an old school whiteboard session. That being said, higher-bandwidth communication channels like invite-only events come at the price of openness and context-archiving, which matters a lot in Bitcoin. So I think it's good to have a mix of both. It could be interesting to restart Scaling Bitcoin confs, the scaling landscape has grown wild in the past years (statechains, payment pools, federated chaumian banks, new types of sidechains, etc), though I've not heard about orgas kicking them again. > I perceived a lot of "Oh, well it's also fine to just wait and see > what comes" in the prior discussions. The idea that we should reopen > this discussion presumes that it is better to not wait, because having > even imperfect covenant designs will cause the ecosystem to explore > what use cases to allocate developer interest in (as long as the fees > are not too far off - yeah I'm looking at you, CSFS). Because of > this, I also propose asking some of the more advanced scripting > technologists to reveal what of their work is currently science, what > is engineering, and what is product-oriented with understandable > delivery dates. I think that if more people understood the answers to > these questions then there would be more room for incremental > exploration of the space. For sure, there is a "chicken-and-egg" issue, in the sense that lack of certainty on finding consensus on covenant designs can deter some of the most experienced and knowledgeable developers to invest time in building and maturing use-cases toolchains demonstrating the worthiness of such consensus change. One way to avoid this circular dependency can be to start with a state-of-Bitcoin-art version of the protocol, deploy then once there is economic traffic, propose protocol improvement requiring consensus changes back to the community. This is more or less what Lightning is doing with ANYPREVOUT, now there is like 4,300 BTC locked on the network, it's easier to argue there is economic interest. Though ultimately, I don't believe you will ever solve that dead-end risk of Bitcoin research to attract automatically more developers. It's common to any scientific endeavor, as in the end it's more an "inner taste" and exploration for its own sake that drives long-term research. On the second point, giving clarity on the state of advanced scripting use-cases, effectively I believe it would be an informative task to do for each use-case "champion". Speaking for payments pools, solving the high-interactivity issue is still science [0], a pool design for like 10-100 participants assuming liveliness we might have known engineering solutions [1], yet with still a lot of trade-offs to explore on the core pool tree mechanism, and now the real unknown and hard task might be to say a "product-oriented" with delivery dates. From my LDK experience, counts 3/4 years at best to build and mature any FOSS production-ready Bitcoin codebase though in reality if you have to request other changes in the ecosystem like mempools ones for a L2, you don't know. So for discussion clarity, yes it's good if champions give an honest account of knowns and unknowns of their use-cases. I would have loved all the mempool issues affecting Lightning to have been detected and mitigations development started earlier in the protocol genesis. Thanks for the feedback, keeping track of them. Le sam. 23 juil. 2022 =C3=A0 06:10, Ryan Grant a = =C3=A9crit : > +1 I'd participate. > > Certain human/organizational limitations prevent things being said in > logged channels that sometimes can be shared in person. Sometimes > people break through misunderstandings in person, through either > informal mingling or the use of Chatham House rules. So I would also > advocate restarting the Scaling Bitcoin conferences, twice a year. > > One request for the agenda: > I perceived a lot of "Oh, well it's also fine to just wait and see > what comes" in the prior discussions. The idea that we should reopen > this discussion presumes that it is better to not wait, because having > even imperfect covenant designs will cause the ecosystem to explore > what use cases to allocate developer interest in (as long as the fees > are not too far off - yeah I'm looking at you, CSFS). Because of > this, I also propose asking some of the more advanced scripting > technologists to reveal what of their work is currently science, what > is engineering, and what is product-oriented with understandable > delivery dates. I think that if more people understood the answers to > these questions then there would be more room for incremental > exploration of the space. > --000000000000b8ccfb05e47a2d21 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ryan,

> =C2=A0Certain human/organ= izational limitations prevent things being said in
> logged channel= s that sometimes can be shared in person.=C2=A0 Sometimes
> people br= eak through misunderstandings in person, through either
> informal mi= ngling or the use of Chatham House rules.=C2=A0 So I would also
> adv= ocate restarting the Scaling Bitcoin conferences, twice a year.

Just for clarity, I'm proposing online meetings on IRC,=C2=A0no= t in-person. But yes, logged channels can be really narrow on topics and in= person sometimes let people grasp the bigger picture or wider context more= easily. In my opinion, to build understanding and sync on a complex topic = there is nothing like an old school whiteboard session. That being said, hi= gher-bandwidth communication channels like invite-only events come at the p= rice of openness=C2=A0and context-archiving,=C2=A0which matters a lot in Bi= tcoin. So I think it's good to have a mix of both. It could be interest= ing to restart Scaling Bitcoin confs, the scaling landscape has grown wild = in the past years (statechains, payment pools, federated chaumian banks, ne= w types of sidechains, etc), though I've not heard about orgas kicking = them again.

> I perceived a lot of "Oh, we= ll it's also fine to just wait and see
> what comes" in the = prior discussions.=C2=A0 The idea that we should reopen
> this discus= sion presumes that it is better to not wait, because having
> even im= perfect covenant designs will cause the ecosystem to explore
> what u= se cases to allocate developer interest in (as long as the fees
> are= not too far off - yeah I'm looking at you, CSFS).=C2=A0 Because of
= > this, I also propose asking some of the more advanced scripting
>= ; technologists to reveal what of their work is currently science, what
= > is engineering, and what is product-oriented with understandable
&g= t; delivery dates.=C2=A0 I think that if more people understood the answers= to
> these questions then there would be more room for incremental> exploration of the space.

For sure, the= re is a "chicken-and-egg" issue, in the sense that lack of certai= nty on finding consensus on covenant designs can deter some of the most exp= erienced and knowledgeable developers to invest time in building and maturi= ng use-cases toolchains demonstrating the worthiness of such consensus chan= ge. One way to avoid this circular dependency can be to start with a state-= of-Bitcoin-art version of the protocol, deploy then once there is economic = traffic, propose protocol improvement requiring consensus changes back to t= he community. This is more or less what Lightning is doing with ANYPREVOUT,= now there is like 4,300 BTC locked on the network, it's easier to argu= e there is economic interest. Though ultimately, I don't believe you wi= ll ever solve that dead-end risk of Bitcoin research to=C2=A0attract automa= tically more developers. It's common to any scientific endeavor, as in = the end it's more an "inner taste" and exploration for its ow= n sake that drives long-term research.

On the seco= nd point, giving clarity on the state of advanced scripting use-cases, effe= ctively I believe it would be an informative task to do for each use-case &= quot;champion". Speaking for payments pools, solving the high-interact= ivity issue is still science [0], a pool design for like 10-100 participant= s assuming liveliness we might have known engineering solutions [1], yet wi= th still a lot of trade-offs to explore on the core pool tree mechanism, an= d now the real unknown and hard task might be to say a "product-orient= ed" with delivery dates. From my LDK experience, counts 3/4 years at b= est to build and mature any FOSS production-ready Bitcoin codebase though i= n reality if you have to request other changes in the ecosystem like mempoo= ls ones for a L2, you don't know.=C2=A0 So for discussion clarity, yes = it's good if champions give an honest account of knowns and unknowns of= their use-cases. I would have loved all the mempool issues affecting Light= ning to have been detected and mitigations development started earlier in t= he protocol genesis.

Thanks for the feedback, keep= ing track of them.



<= br>

Le=C2=A0sam. 23 juil. 2022 =C3=A0=C2=A006:10, Ryan Grant <bitcoin-dev@rgrant.org> a =C3= =A9crit=C2=A0:
+1=C2=A0 I'd participate.

Certain human/organizational limitations prevent things being said in
logged channels that sometimes can be shared in person.=C2=A0 Sometimes
people break through misunderstandings in person, through either
informal mingling or the use of Chatham House rules.=C2=A0 So I would also<= br> advocate restarting the Scaling Bitcoin conferences, twice a year.

One request for the agenda:
I perceived a lot of "Oh, well it's also fine to just wait and see=
what comes" in the prior discussions.=C2=A0 The idea that we should re= open
this discussion presumes that it is better to not wait, because having
even imperfect covenant designs will cause the ecosystem to explore
what use cases to allocate developer interest in (as long as the fees
are not too far off - yeah I'm looking at you, CSFS).=C2=A0 Because of<= br> this, I also propose asking some of the more advanced scripting
technologists to reveal what of their work is currently science, what
is engineering, and what is product-oriented with understandable
delivery dates.=C2=A0 I think that if more people understood the answers to=
these questions then there would be more room for incremental
exploration of the space.
--000000000000b8ccfb05e47a2d21--