{"type":"rich","version":"1.0","title":"Antoine Riard [ARCHIVE] wrote","author_name":"Antoine Riard [ARCHIVE] (npub1vj…4x8dd)","author_url":"https://yabu.me/npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8dd","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2023-07-18\n🗒️ Summary of this message: Last year, a new community process for specifying covenants was introduced, but the person behind it will no longer actively pursue it. Efforts were made to build a framework for evaluating covenant proposals and expand the consensus changes development process. Other initiatives were also undertaken during the same period. A Github repository was created to document Bitcoin contracting primitives and corresponding protocols. Monthly meetings were held with attendees from various parts of the community. However, the person behind the process has been busy with other Bitcoin projects and has not held online meetings since April.\n📝 Original message:\nHi list,\n\nLast year amid the failure of the CTV speedy trial activation and intense\nconversations about a rainbow of covenant proposals, I introduced the idea\nof a new community process to specify covenants [0]. This post is to resume\nthe experiment so far and officially mark the process maintenance as \"up\nfor grabs\", as I won't actively pursue it further (after wavering on such a\ndecision a bit during May / June).\n\nFew of the goals announced at that time were to build a consistent\nframework to evaluate covenant proposals, see the common grounds between\nproposals if they could be composed or combined by their authors, open the\nconsensus  changes development process beyond the historical boundaries of\nBitcoin Core and maintain high-quality technical archive as a consensus\ndiscussions have spawned half a decade from intellectual conception to\nactivation in average (at least for segwit, schnorr, taproot).\n\nSuch effort was a speak-by-the-act answer to the issues in\nconsensus development changes pointed out by Jeremy Rubin in April of last\nyear [1]: namely the lack of a \"codified checklist\" for consensus changes,\nthat \"consensus is memoryless\" and \"bitcoin core is not bitcoin\"\n(independently of the technical concerns as I have as limited or\nnon-adequate primitive for vaults / payment pools I expressed during the\nsame time). Other complementary initiatives have been undertaken during the\nsame period, AJ with the bitcoin-inquisition fork where the community of\ndevelopers and contracting primitives of researchers on a consensus-enabled\nfork of core [2]. And Dave Harding with the careful archiving of all\ncovenant proposals under the Optech umbrella [3].\n\nAbout the Bitcoin Contracting Primitives WG, a Github repository was\nstarted and maintained to archive and document all the primitives (apo,\ntluv, ctv, the taproot annex, sighash_group, CSFS, cat, txhash, evict,\ncheck_output_covenant_verify, inherited ids, anyamount, singletons,\nop_vault) and the corresponding protocols (payment pools, vaults,\ndrivechains, trust-minimized mining pools payouts). We had a total of 6\nmonthly meetings on the Libera chat #bitcoin-contracting-primitives-wg for\na number of more than 20 individual attendees representing most of the\nparts of the community. I think (missing march logs). Numerous in-depth\ndiscussions did happen on the repository and on the channel on things like\n\"merkelized all the things\" or \"payment pools for miners payoffs\".\n\nAs I've been busy on the Lightning-side and other Bitcoin projects, I've\nnot run an online meeting since the month of April, while still having a\nbunch of fruitful technical discussions with folks involved in the effort\nat conferences and elsewhere. I launched the effort as an experiment with\nthe soft commitment to dedicate 20% of my time on it, after few successful\nsessions I think such a process has an interest of its own, however it\ncomes with direct competition of my time to work on Lightning robustness.\nGetting my hands dirty on low-level LDK development recently made me\nrealize we still have years of titan work to get a secure and reliable\nLightning Network.\n\nAs such, between extended covenant capabilities for advanced contracts\ncoming as a reality for Bitcoin _or_ LN working smoothly at scale with\n50-100M UTXO-sharing users on it during the next 5-7 years cycle, I think\nthe latter goal is more critical for Bitcoin existential survival, and\nwhere on a personal title I'll allocate the best of my time and energy (and\nsomehow it match the \"slow\" technical activity on bitcoin-inquisition\nmostly done by Lightning hands).\n\nThis is my personal conclusion only on the state of Bitcoin technological\nmomentum, and this is quite tainted by my deep background in Lightning\ndevelopment. If you've been working on covenant changes proposals, please\ndon't take it as a discouragement, I think Taproot (privacy-preserving\nscript policies behind the taproot tree branches) and Schnorr (for native\nmulti-sig) soft forks have shown how it can improve the building of\nself-custody solutions by one or two order of magnitude, and small\nincremental changes might be good enough to have a lower technical\nconsensus bar.\n\nOn my side, I'll pursue pure R\u0026D works on CoinPool, notably coming with\nbetter solutions with the interactivity issue and mass-compression of\nwithdrawal and design exotic advanced Bitcoin contracts based on the\ntaproot annex, though more in a \"l'art pour l'art\" approach for the time\nbeing [4]. Additionally, I might start to submit an in-depth security\nreview of consensus changes under pseudonyms, it has already been done in\nthe past and somehow it's good practice in terms of \"message neutrality\"\n[5]. If folks wanna experiment in terms of payment pools deployment, Greg\nMaxwell's old joinpool can be used today (and somehow it's worthy of its\nown as a net advance for coinjoins).\n\nI'll honestly acknowledge towards the community, I might have overpromised\nwith the kickstart of this new process aiming to move the frontlines in\nmatters of Bitcoin consensus changes development process. On the other\nhand, I think enough sessions of the working group have been runned and\nenough marks of technical interests have been collected to demonstrate the\nminimal value of such a process, so I would estimate my open-source balance\nsheet towards the community to be in good standing ? (open-minded question).\n\nI don't think Bitcoin fundamentally lacks compelling technical proposals to\nadvance the capabilities of Bitcoin Script today, nor the crowd of seasoned\nand smart protocol developers to evaluate mature proposals end-to-end and\non multiple dimensions with a spirit of independence. Rather, I believe\nwhat Bitcoin is lacking is a small crowd of technical historians and\narchivist doing the work of assessing, collecting and preserving consensus\nchanges proposals and QA devs to ensure any consensus change proposals has\nworld-class battle-ground testing before to be considered for deployment,\nideally with the best standards of Bitcoin decentralization and FOSS\nneutrality [6].\n\nIf you would like to pursue the maintenance and nurturing of the Bitcoin\nContracting Primitives WG (or the bitcoin-inquisition fork or collaborate\nwith Optech to organize industry-wise workshop on covenants at the image of\nwhat has been done in 2019 for Taproot), that you're willing to show\nproof-of-work and you estimate that operational ground, legal information\nor financial resources will anchor your individual work on the long-term,\ndon't hesitate to reach out, I'll see what I can do with a disinterested\nmind [7].\n\nWith humility,\nAntoine\n\n[0]\nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020763.html\n[1]\nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020233.html\n[2]\nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020921.html\n[3] https://github.com/bitcoinops/bitcoinops.github.io/pull/806\n[4] Version 0.2 of the CoinPool whitepaper addressing most of the remaining\n\"Big Problems\" is still pending on my visit to co-author Gleb Naumenko in\nUkraine, which has been postponed few times in light of the conflict\noperational evolutions.\n[5] See\nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017614.html.\nFor the philosophical reasons of doing so, I invite you to read Foucault's\nfamous essay \"Le philosophe masque\".\n[6] Somehow I come to share Jeremy's thesis's \"Product management is not\n\"my Job\" it's yours\" in matters of consensus changes. I believe we might be\npast the technical complexity threshold where even simple consensus changes\ncan be conducted from A to Z as a one man job or even by a group of 2/3\nelite devs.\n[7] I've been reached out multiple times and consistently by R\u0026D\nnon-profits, plebs whales and VC firms who were interested to commit\nresources to advance softforks and covenants in the Bitcoin space, no doubt\nwhen you're reliable and with a track record, folks are ready to offer you\nopportunities to work full-time on consensus changes.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230718/0be965a9/attachment.html\u003e"}