MIME-Version: 1.0
References: <CALZpt+FhpZETHP8UpDGgw-Wg=m4Hxm8y9XZ9kXYgmt90_6Zt6w@mail.gmail.com>
 <CAMnpzfoAbzQhwoMMWwG6ssf4Cgwad-zRyhEZinZNifDhPXDEaA@mail.gmail.com>
In-Reply-To: <CAMnpzfoAbzQhwoMMWwG6ssf4Cgwad-zRyhEZinZNifDhPXDEaA@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Sat, 23 Jul 2022 15:57:56 +0100
Message-ID: <CALZpt+HfZZwrpzEcw6XVZv_RzeiX4iXvMGEWSto5xEdUatVWhQ@mail.gmail.com>
To: Ryan Grant <bitcoin-dev@rgrant.org>
Content-Type: multipart/alternative; boundary="000000000000b8ccfb05e47a2d21"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] On a new community process to specify covenants
Precedence: list

--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 <bitcoin-dev@rgrant.org> 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

<div dir=3D"ltr">Hi Ryan,<div><br></div><div>&gt; =C2=A0Certain human/organ=
izational limitations prevent things being said in</div>&gt; logged channel=
s that sometimes can be shared in person.=C2=A0 Sometimes<br>&gt; people br=
eak through misunderstandings in person, through either<br>&gt; informal mi=
ngling or the use of Chatham House rules.=C2=A0 So I would also<br>&gt; adv=
ocate restarting the Scaling Bitcoin conferences, twice a year.<div><br></d=
iv><div>Just for clarity, I&#39;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&#39;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&#39;ve not heard about orgas kicking =
them again.</div><div><br></div><div>&gt; I perceived a lot of &quot;Oh, we=
ll it&#39;s also fine to just wait and see<br>&gt; what comes&quot; in the =
prior discussions.=C2=A0 The idea that we should reopen<br>&gt; this discus=
sion presumes that it is better to not wait, because having<br>&gt; even im=
perfect covenant designs will cause the ecosystem to explore<br>&gt; what u=
se cases to allocate developer interest in (as long as the fees<br>&gt; are=
 not too far off - yeah I&#39;m looking at you, CSFS).=C2=A0 Because of<br>=
&gt; this, I also propose asking some of the more advanced scripting<br>&gt=
; technologists to reveal what of their work is currently science, what<br>=
&gt; is engineering, and what is product-oriented with understandable<br>&g=
t; delivery dates.=C2=A0 I think that if more people understood the answers=
 to<br>&gt; these questions then there would be more room for incremental<b=
r>&gt; exploration of the space.<br></div><div><br></div><div>For sure, the=
re is a &quot;chicken-and-egg&quot; 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&#39;s easier to argu=
e there is economic interest. Though ultimately, I don&#39;t believe you wi=
ll ever solve that dead-end risk of Bitcoin research to=C2=A0attract automa=
tically more developers. It&#39;s common to any scientific endeavor, as in =
the end it&#39;s more an &quot;inner taste&quot; and exploration for its ow=
n sake that drives long-term research.</div><div><br></div><div>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&quot;. 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 &quot;product-orient=
ed&quot; 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&#39;t know.=C2=A0 So for discussion clarity, yes =
it&#39;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.</div><div><br></div><div>Thanks for the feedback, keep=
ing track of them.</div><div><br></div><div><br></div><div><br></div><div><=
br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gma=
il_attr">Le=C2=A0sam. 23 juil. 2022 =C3=A0=C2=A006:10, Ryan Grant &lt;<a hr=
ef=3D"mailto:bitcoin-dev@rgrant.org">bitcoin-dev@rgrant.org</a>&gt; a =C3=
=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-=
color:rgb(204,204,204);padding-left:1ex">+1=C2=A0 I&#39;d participate.<br>
<br>
Certain human/organizational limitations prevent things being said in<br>
logged channels that sometimes can be shared in person.=C2=A0 Sometimes<br>
people break through misunderstandings in person, through either<br>
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.<br>
<br>
One request for the agenda:<br>
I perceived a lot of &quot;Oh, well it&#39;s also fine to just wait and see=
<br>
what comes&quot; in the prior discussions.=C2=A0 The idea that we should re=
open<br>
this discussion presumes that it is better to not wait, because having<br>
even imperfect covenant designs will cause the ecosystem to explore<br>
what use cases to allocate developer interest in (as long as the fees<br>
are not too far off - yeah I&#39;m looking at you, CSFS).=C2=A0 Because of<=
br>
this, I also propose asking some of the more advanced scripting<br>
technologists to reveal what of their work is currently science, what<br>
is engineering, and what is product-oriented with understandable<br>
delivery dates.=C2=A0 I think that if more people understood the answers to=
<br>
these questions then there would be more room for incremental<br>
exploration of the space.<br>
</blockquote></div>

--000000000000b8ccfb05e47a2d21--