{"type":"rich","version":"1.0","title":"Keagan McClelland [ARCHIVE] wrote","author_name":"Keagan McClelland [ARCHIVE] (npub1f2…ms289)","author_url":"https://yabu.me/npub1f2nxequ09nz44775vv6lkffq2plzqvrqramnk29eddmwcc9z7jys8ms289","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2023-07-19\n🗒️ Summary of this message: The author agrees that a smooth functioning Lightning Network is important, but believes that adding covenant schemes can help simplify LN development. They challenge the idea that covenants are a distraction and suggest that they can contribute to LN's maturity.\n📝 Original message:\nHi Antoine,\n\nThank you for the effort you've put towards this. I generally agree that a\nsmooth functioning Lightning Network is of greater importance than advanced\ncontracting capabilities. However, as I dive deeper into some of the more\nambitious goals for LN development I am learning that a great deal of\ncomplexity of some current lightning (LN) proposals can be handily\ndischarged with CTV. While I am not intimately familiar with all of the\nother covenant schemes to the same level of technical proficiency, I have a\nsuspicion that a number of them, if not all of them, are capable of\ndischarging the same flavor and amount of complexity as well. Others should\nchime in if they can confirm this claim.\n\nI have been publicly on the record as supporting the addition of some\ncovenant scheme into Bitcoin for some time and have long held on\ntheoretical grounds that the addition of such a mechanism is both necessary\nand inevitable if Bitcoin is to survive in the long term. However, as I've\nstarted to work more directly with the Lightning protocol, these\ntheoretical and purely logical arguments became far more concrete and\nimmediately beneficial.\n\nI say this primarily to challenge the idea that covenants are a distraction\nfrom lightning development. It may very well be that your areas of focus on\nLN preclude you from splitting your attention and none of this email should\nbe interpreted as a criticism of you applying your efforts in the highest\nleverage manner you can manage. That said, I don't want observers of this\nthread to walk away with the impression that they are two independent\nefforts as covenants can significantly contribute to LN's maturity. When\nand how should they be prioritized? Unfortunately I don't feel able to\ncomment on that at this time. All I know is that Lightning would almost\ncertainly benefit substantially from having a covenant primitive.\n\nCheers,\nKeags\n\nOn Tue, Jul 18, 2023 at 3:40 PM Antoine Riard via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Hi list,\n\u003e\n\u003e Last year amid the failure of the CTV speedy trial activation and intense\n\u003e conversations about a rainbow of covenant proposals, I introduced the idea\n\u003e of a new community process to specify covenants [0]. This post is to resume\n\u003e the experiment so far and officially mark the process maintenance as \"up\n\u003e for grabs\", as I won't actively pursue it further (after wavering on such a\n\u003e decision a bit during May / June).\n\u003e\n\u003e Few of the goals announced at that time were to build a consistent\n\u003e framework to evaluate covenant proposals, see the common grounds between\n\u003e proposals if they could be composed or combined by their authors, open the\n\u003e consensus  changes development process beyond the historical boundaries of\n\u003e Bitcoin Core and maintain high-quality technical archive as a consensus\n\u003e discussions have spawned half a decade from intellectual conception to\n\u003e activation in average (at least for segwit, schnorr, taproot).\n\u003e\n\u003e Such effort was a speak-by-the-act answer to the issues in\n\u003e consensus development changes pointed out by Jeremy Rubin in April of last\n\u003e year [1]: namely the lack of a \"codified checklist\" for consensus changes,\n\u003e that \"consensus is memoryless\" and \"bitcoin core is not bitcoin\"\n\u003e (independently of the technical concerns as I have as limited or\n\u003e non-adequate primitive for vaults / payment pools I expressed during the\n\u003e same time). Other complementary initiatives have been undertaken during the\n\u003e same period, AJ with the bitcoin-inquisition fork where the community of\n\u003e developers and contracting primitives of researchers on a consensus-enabled\n\u003e fork of core [2]. And Dave Harding with the careful archiving of all\n\u003e covenant proposals under the Optech umbrella [3].\n\u003e\n\u003e About the Bitcoin Contracting Primitives WG, a Github repository was\n\u003e started and maintained to archive and document all the primitives (apo,\n\u003e tluv, ctv, the taproot annex, sighash_group, CSFS, cat, txhash, evict,\n\u003e check_output_covenant_verify, inherited ids, anyamount, singletons,\n\u003e op_vault) and the corresponding protocols (payment pools, vaults,\n\u003e drivechains, trust-minimized mining pools payouts). We had a total of 6\n\u003e monthly meetings on the Libera chat #bitcoin-contracting-primitives-wg for\n\u003e a number of more than 20 individual attendees representing most of the\n\u003e parts of the community. I think (missing march logs). Numerous in-depth\n\u003e discussions did happen on the repository and on the channel on things like\n\u003e \"merkelized all the things\" or \"payment pools for miners payoffs\".\n\u003e\n\u003e As I've been busy on the Lightning-side and other Bitcoin projects, I've\n\u003e not run an online meeting since the month of April, while still having a\n\u003e bunch of fruitful technical discussions with folks involved in the effort\n\u003e at conferences and elsewhere. I launched the effort as an experiment with\n\u003e the soft commitment to dedicate 20% of my time on it, after few successful\n\u003e sessions I think such a process has an interest of its own, however it\n\u003e comes with direct competition of my time to work on Lightning robustness.\n\u003e Getting my hands dirty on low-level LDK development recently made me\n\u003e realize we still have years of titan work to get a secure and reliable\n\u003e Lightning Network.\n\u003e\n\u003e As such, between extended covenant capabilities for advanced contracts\n\u003e coming as a reality for Bitcoin _or_ LN working smoothly at scale with\n\u003e 50-100M UTXO-sharing users on it during the next 5-7 years cycle, I think\n\u003e the latter goal is more critical for Bitcoin existential survival, and\n\u003e where on a personal title I'll allocate the best of my time and energy (and\n\u003e somehow it match the \"slow\" technical activity on bitcoin-inquisition\n\u003e mostly done by Lightning hands).\n\u003e\n\u003e This is my personal conclusion only on the state of Bitcoin technological\n\u003e momentum, and this is quite tainted by my deep background in Lightning\n\u003e development. If you've been working on covenant changes proposals, please\n\u003e don't take it as a discouragement, I think Taproot (privacy-preserving\n\u003e script policies behind the taproot tree branches) and Schnorr (for native\n\u003e multi-sig) soft forks have shown how it can improve the building of\n\u003e self-custody solutions by one or two order of magnitude, and small\n\u003e incremental changes might be good enough to have a lower technical\n\u003e consensus bar.\n\u003e\n\u003e On my side, I'll pursue pure R\u0026D works on CoinPool, notably coming with\n\u003e better solutions with the interactivity issue and mass-compression of\n\u003e withdrawal and design exotic advanced Bitcoin contracts based on the\n\u003e taproot annex, though more in a \"l'art pour l'art\" approach for the time\n\u003e being [4]. Additionally, I might start to submit an in-depth security\n\u003e review of consensus changes under pseudonyms, it has already been done in\n\u003e the past and somehow it's good practice in terms of \"message neutrality\"\n\u003e [5]. If folks wanna experiment in terms of payment pools deployment, Greg\n\u003e Maxwell's old joinpool can be used today (and somehow it's worthy of its\n\u003e own as a net advance for coinjoins).\n\u003e\n\u003e I'll honestly acknowledge towards the community, I might have overpromised\n\u003e with the kickstart of this new process aiming to move the frontlines in\n\u003e matters of Bitcoin consensus changes development process. On the other\n\u003e hand, I think enough sessions of the working group have been runned and\n\u003e enough marks of technical interests have been collected to demonstrate the\n\u003e minimal value of such a process, so I would estimate my open-source balance\n\u003e sheet towards the community to be in good standing ? (open-minded question).\n\u003e\n\u003e I don't think Bitcoin fundamentally lacks compelling technical proposals\n\u003e to advance the capabilities of Bitcoin Script today, nor the crowd of\n\u003e seasoned and smart protocol developers to evaluate mature proposals\n\u003e end-to-end and on multiple dimensions with a spirit of independence.\n\u003e Rather, I believe what Bitcoin is lacking is a small crowd of technical\n\u003e historians and archivist doing the work of assessing, collecting and\n\u003e preserving consensus changes proposals and QA devs to ensure any consensus\n\u003e change proposals has world-class battle-ground testing before to be\n\u003e considered for deployment, ideally with the best standards of Bitcoin\n\u003e decentralization and FOSS neutrality [6].\n\u003e\n\u003e If you would like to pursue the maintenance and nurturing of the Bitcoin\n\u003e Contracting Primitives WG (or the bitcoin-inquisition fork or collaborate\n\u003e with Optech to organize industry-wise workshop on covenants at the image of\n\u003e what has been done in 2019 for Taproot), that you're willing to show\n\u003e proof-of-work and you estimate that operational ground, legal information\n\u003e or financial resources will anchor your individual work on the long-term,\n\u003e don't hesitate to reach out, I'll see what I can do with a disinterested\n\u003e mind [7].\n\u003e\n\u003e With humility,\n\u003e Antoine\n\u003e\n\u003e [0]\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020763.html\n\u003e [1]\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020233.html\n\u003e [2]\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020921.html\n\u003e [3] https://github.com/bitcoinops/bitcoinops.github.io/pull/806\n\u003e [4] Version 0.2 of the CoinPool whitepaper addressing most of the\n\u003e remaining \"Big Problems\" is still pending on my visit to co-author Gleb\n\u003e Naumenko in Ukraine, which has been postponed few times in light of the\n\u003e conflict operational evolutions.\n\u003e [5] See\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017614.html.\n\u003e For the philosophical reasons of doing so, I invite you to read Foucault's\n\u003e famous essay \"Le philosophe masque\".\n\u003e [6] Somehow I come to share Jeremy's thesis's \"Product management is not\n\u003e \"my Job\" it's yours\" in matters of consensus changes. I believe we might be\n\u003e past the technical complexity threshold where even simple consensus changes\n\u003e can be conducted from A to Z as a one man job or even by a group of 2/3\n\u003e elite devs.\n\u003e [7] I've been reached out multiple times and consistently by R\u0026D\n\u003e non-profits, plebs whales and VC firms who were interested to commit\n\u003e resources to advance softforks and covenants in the Bitcoin space, no doubt\n\u003e when you're reliable and with a track record, folks are ready to offer you\n\u003e opportunities to work full-time on consensus changes.\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230719/5dac7ac0/attachment.html\u003e"}