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