From: Antoine Riard <antoine.riard@gmail•com>
To: Ryan Grant <bitcoin-dev@rgrant•org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] On a new community process to specify covenants
Date: Sat, 23 Jul 2022 15:57:56 +0100 [thread overview]
Message-ID: <CALZpt+HfZZwrpzEcw6XVZv_RzeiX4iXvMGEWSto5xEdUatVWhQ@mail.gmail.com> (raw)
In-Reply-To: <CAMnpzfoAbzQhwoMMWwG6ssf4Cgwad-zRyhEZinZNifDhPXDEaA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5425 bytes --]
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 à 06:10, Ryan Grant <bitcoin-dev@rgrant•org> a écrit :
> +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.
>
[-- Attachment #2: Type: text/html, Size: 6150 bytes --]
next prev parent reply other threads:[~2022-07-23 14:58 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-20 20:42 Antoine Riard
2022-07-23 5:09 ` Ryan Grant
2022-07-23 14:57 ` Antoine Riard [this message]
2022-07-23 14:25 ` Michael Folkson
2022-07-23 16:41 ` Antoine Riard
2022-07-24 13:01 ` aliashraf.btc At protonmail
2022-07-24 23:40 ` ZmnSCPxj
2022-07-26 3:20 ` Antoine Riard
2022-07-26 3:18 ` Antoine Riard
2022-07-24 18:22 ` Bram Cohen
2022-07-24 20:26 ` aliashraf.btc At protonmail
2022-07-26 3:21 ` Antoine Riard
2022-07-26 16:02 ` Bram Cohen
2022-08-03 15:37 ` Billy Tetrud
2022-08-09 20:15 ` Antoine Riard
2022-08-27 21:01 ` Billy Tetrud
2022-08-30 15:46 ` Antoine Riard
2022-09-10 0:10 ` Antoine Riard
2022-10-07 15:33 ` Antoine Riard
2022-09-12 0:05 Buck O Perley
2022-09-13 16:02 ` Ryan Grant
2022-09-15 8:05 ` Devrandom
2022-09-16 19:08 ` Antoine Riard
2022-09-16 18:59 ` Antoine Riard
2022-09-17 7:52 ` Devrandom
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALZpt+HfZZwrpzEcw6XVZv_RzeiX4iXvMGEWSto5xEdUatVWhQ@mail.gmail.com \
--to=antoine.riard@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=bitcoin-dev@rgrant$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox