📅 Original date posted:2023-07-20
🗒️ Summary of this message: Antoine acknowledges Greg's development approach but raises concerns about the authority of BOLTs and the technical fitness of Simplicity for small party channels.
📝 Original message:
Hi antoine,
Simplicity was just a stand in for "functionally complete" handwave.
Cheers,
Greg
On Thu, Jul 20, 2023, 1:46 AM Antoine Riard <antoine.riard at gmail.com> wrote:
> Hi Greg,
>
> I'm very meeting your development approach with regards to starting smalls
> about consensus change primitives, and I think taproot has demonstrated
> some good historical process, which has good archives about how development
> was conducted (e.g the community-wide taproot review of which the Bitcoin
> Contracting Primitives WG was built on this experience [0]).
>
> I don't know about saying that the BOLTs (and its process) should be
> authoritative over the running code of implementations. While it's
> definitely a mark of some bar of technical review and inter-compatibility,
> I think ultimately each BOLT has to be judged individually on its own
> technical merits. And I think we had a bunch of cases in the past when "the
> map is not the territory". Even there are few areas of critical Lightning
> operations which are not documented by the BOLTs to the best of my
> knowledge (such as fee-bumping and transactions broadcast reactions as it
> was for on-chain DLCs [1]).
>
> Lastly, there is a huge area of uncertainty about the technical fitness of
> Simplicity for 2/small party channels. I remember a Russell O'connor
> presentation about Simplicity back in Paris (2017 or 2018 ?) and asking him
> how it would work in a chain of transactions, while the answer was iirc
> "yes it has been designed with this constraint", it's a very open question
> when you have off-chain states which advances in independence from the
> on-chain state between a dynamic number of counterparties (kinda the
> interactivity issue for payment pools). Here I guess you would have to come
> to a consensus to the model of logic followed for the analysis of such
> distributed systems e.g Leslie Lamport's temporal logic [2]. Additionally,
> the theoretical foundations on the Coq prover are still actively studied by
> Xavier Leroy at the College de France and some novel insights might be
> interesting for using formal verification in terms of Bitcoin consensus
> changes development (and I don't know if all the works and lessons have
> been translated from French to English).
>
> Best,
> Antoine
>
> [0] https://github.com/ajtowns/taproot-review
> [1]
> https://github.com/discreetlogcontracts/dlcspecs/blob/master/Non-Interactive-Protocol.md
> [2] https://en.wikipedia.org/wiki/Temporal_logic_of_actions
>
> Le mer. 19 juil. 2023 à 21:45, Greg Sanders <gsanders87 at gmail.com> a
> écrit :
>
>> Hello Keagen,
>>
>> Most of the complexity of LN cannot be resolved with covenants. Of the
>> things that can be simplified in my experience, you're going to need more
>> than CTV to get significant gains. And in the end, channels can only get so
>> simple since we have many other BOLTs to deal with. And even then, you're
>> going to have to convince LN spec writers to include such changes, whatever
>> they are, then get deployment.
>>
>> Step 1 is finding a primitive that seems interesting. It's important to
>> moderate enthusiasm for any primitive with reality, and probably by being
>> concrete by writing specs that use a primitive, and code it up to discover
>> what we're overlooking. We're always overlooking something! In my humble
>> opinion these are step 2 and 3 of gathering mind-share.
>>
>> As a more productive tact, if we're thinking beyond 2/small party
>> channels, probably better to snap your fingers, pretend we have Simplicity,
>> see what we can build, and work backwards from there to see if we can
>> accomplish this within the confines of bitcoin script?
>>
>> Cheers,
>> Greg
>>
>> On Wed, Jul 19, 2023 at 3:59 PM Keagan McClelland via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Hi Antoine,
>>>
>>> Thank you for the effort you've put towards this. I generally agree that
>>> a smooth functioning Lightning Network is of greater importance than
>>> advanced contracting capabilities. However, as I dive deeper into some of
>>> the more ambitious goals for LN development I am learning that a great deal
>>> of complexity of some current lightning (LN) proposals can be handily
>>> discharged with CTV. While I am not intimately familiar with all of the
>>> other covenant schemes to the same level of technical proficiency, I have a
>>> suspicion that a number of them, if not all of them, are capable of
>>> discharging the same flavor and amount of complexity as well. Others should
>>> chime in if they can confirm this claim.
>>>
>>> I have been publicly on the record as supporting the addition of some
>>> covenant scheme into Bitcoin for some time and have long held on
>>> theoretical grounds that the addition of such a mechanism is both necessary
>>> and inevitable if Bitcoin is to survive in the long term. However, as I've
>>> started to work more directly with the Lightning protocol, these
>>> theoretical and purely logical arguments became far more concrete and
>>> immediately beneficial.
>>>
>>> I say this primarily to challenge the idea that covenants are a
>>> distraction from lightning development. It may very well be that your areas
>>> of focus on LN preclude you from splitting your attention and none of this
>>> email should be interpreted as a criticism of you applying your efforts in
>>> the highest leverage manner you can manage. That said, I don't want
>>> observers of this thread to walk away with the impression that they are two
>>> independent efforts as covenants can significantly contribute to LN's
>>> maturity. When and how should they be prioritized? Unfortunately I don't
>>> feel able to comment on that at this time. All I know is that Lightning
>>> would almost certainly benefit substantially from having a covenant
>>> primitive.
>>>
>>> Cheers,
>>> Keags
>>>
>>> On Tue, Jul 18, 2023 at 3:40 PM Antoine Riard via bitcoin-dev <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> Hi list,
>>>>
>>>> Last year amid the failure of the CTV speedy trial activation and
>>>> intense conversations about a rainbow of covenant proposals, I introduced
>>>> the idea of a new community process to specify covenants [0]. This post is
>>>> to resume the experiment so far and officially mark the process maintenance
>>>> as "up for grabs", as I won't actively pursue it further (after wavering on
>>>> such a decision a bit during May / June).
>>>>
>>>> Few of the goals announced at that time were to build a consistent
>>>> framework to evaluate covenant proposals, see the common grounds between
>>>> proposals if they could be composed or combined by their authors, open the
>>>> consensus changes development process beyond the historical boundaries of
>>>> Bitcoin Core and maintain high-quality technical archive as a consensus
>>>> discussions have spawned half a decade from intellectual conception to
>>>> activation in average (at least for segwit, schnorr, taproot).
>>>>
>>>> Such effort was a speak-by-the-act answer to the issues in
>>>> consensus development changes pointed out by Jeremy Rubin in April of last
>>>> year [1]: namely the lack of a "codified checklist" for consensus changes,
>>>> that "consensus is memoryless" and "bitcoin core is not bitcoin"
>>>> (independently of the technical concerns as I have as limited or
>>>> non-adequate primitive for vaults / payment pools I expressed during the
>>>> same time). Other complementary initiatives have been undertaken during the
>>>> same period, AJ with the bitcoin-inquisition fork where the community of
>>>> developers and contracting primitives of researchers on a consensus-enabled
>>>> fork of core [2]. And Dave Harding with the careful archiving of all
>>>> covenant proposals under the Optech umbrella [3].
>>>>
>>>> About the Bitcoin Contracting Primitives WG, a Github repository was
>>>> started and maintained to archive and document all the primitives (apo,
>>>> tluv, ctv, the taproot annex, sighash_group, CSFS, cat, txhash, evict,
>>>> check_output_covenant_verify, inherited ids, anyamount, singletons,
>>>> op_vault) and the corresponding protocols (payment pools, vaults,
>>>> drivechains, trust-minimized mining pools payouts). We had a total of 6
>>>> monthly meetings on the Libera chat #bitcoin-contracting-primitives-wg for
>>>> a number of more than 20 individual attendees representing most of the
>>>> parts of the community. I think (missing march logs). Numerous in-depth
>>>> discussions did happen on the repository and on the channel on things like
>>>> "merkelized all the things" or "payment pools for miners payoffs".
>>>>
>>>> As I've been busy on the Lightning-side and other Bitcoin projects,
>>>> I've not run an online meeting since the month of April, while still having
>>>> a bunch of fruitful technical discussions with folks involved in the effort
>>>> at conferences and elsewhere. I launched the effort as an experiment with
>>>> the soft commitment to dedicate 20% of my time on it, after few successful
>>>> sessions I think such a process has an interest of its own, however it
>>>> comes with direct competition of my time to work on Lightning robustness.
>>>> Getting my hands dirty on low-level LDK development recently made me
>>>> realize we still have years of titan work to get a secure and reliable
>>>> Lightning Network.
>>>>
>>>> As such, between extended covenant capabilities for advanced contracts
>>>> coming as a reality for Bitcoin _or_ LN working smoothly at scale with
>>>> 50-100M UTXO-sharing users on it during the next 5-7 years cycle, I think
>>>> the latter goal is more critical for Bitcoin existential survival, and
>>>> where on a personal title I'll allocate the best of my time and energy (and
>>>> somehow it match the "slow" technical activity on bitcoin-inquisition
>>>> mostly done by Lightning hands).
>>>>
>>>> This is my personal conclusion only on the state of Bitcoin
>>>> technological momentum, and this is quite tainted by my deep background in
>>>> Lightning development. If you've been working on covenant changes
>>>> proposals, please don't take it as a discouragement, I think Taproot
>>>> (privacy-preserving script policies behind the taproot tree branches) and
>>>> Schnorr (for native multi-sig) soft forks have shown how it can improve the
>>>> building of self-custody solutions by one or two order of magnitude, and
>>>> small incremental changes might be good enough to have a lower technical
>>>> consensus bar.
>>>>
>>>> On my side, I'll pursue pure R&D works on CoinPool, notably coming with
>>>> better solutions with the interactivity issue and mass-compression of
>>>> withdrawal and design exotic advanced Bitcoin contracts based on the
>>>> taproot annex, though more in a "l'art pour l'art" approach for the time
>>>> being [4]. Additionally, I might start to submit an in-depth security
>>>> review of consensus changes under pseudonyms, it has already been done in
>>>> the past and somehow it's good practice in terms of "message neutrality"
>>>> [5]. If folks wanna experiment in terms of payment pools deployment, Greg
>>>> Maxwell's old joinpool can be used today (and somehow it's worthy of its
>>>> own as a net advance for coinjoins).
>>>>
>>>> I'll honestly acknowledge towards the community, I might have
>>>> overpromised with the kickstart of this new process aiming to move the
>>>> frontlines in matters of Bitcoin consensus changes development process. On
>>>> the other hand, I think enough sessions of the working group have been
>>>> runned and enough marks of technical interests have been collected to
>>>> demonstrate the minimal value of such a process, so I would estimate my
>>>> open-source balance sheet towards the community to be in good standing ?
>>>> (open-minded question).
>>>>
>>>> I don't think Bitcoin fundamentally lacks compelling technical
>>>> proposals to advance the capabilities of Bitcoin Script today, nor the
>>>> crowd of seasoned and smart protocol developers to evaluate mature
>>>> proposals end-to-end and on multiple dimensions with a spirit of
>>>> independence. Rather, I believe what Bitcoin is lacking is a small crowd of
>>>> technical historians and archivist doing the work of assessing, collecting
>>>> and preserving consensus changes proposals and QA devs to ensure any
>>>> consensus change proposals has world-class battle-ground testing before to
>>>> be considered for deployment, ideally with the best standards of Bitcoin
>>>> decentralization and FOSS neutrality [6].
>>>>
>>>> If you would like to pursue the maintenance and nurturing of the
>>>> Bitcoin Contracting Primitives WG (or the bitcoin-inquisition fork or
>>>> collaborate with Optech to organize industry-wise workshop on covenants at
>>>> the image of what has been done in 2019 for Taproot), that you're willing
>>>> to show proof-of-work and you estimate that operational ground, legal
>>>> information or financial resources will anchor your individual work on the
>>>> long-term, don't hesitate to reach out, I'll see what I can do with a
>>>> disinterested mind [7].
>>>>
>>>> With humility,
>>>> Antoine
>>>>
>>>> [0]
>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020763.html
>>>> [1]
>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020233.html
>>>> [2]
>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020921.html
>>>> [3] https://github.com/bitcoinops/bitcoinops.github.io/pull/806
>>>> [4] Version 0.2 of the CoinPool whitepaper addressing most of the
>>>> remaining "Big Problems" is still pending on my visit to co-author Gleb
>>>> Naumenko in Ukraine, which has been postponed few times in light of the
>>>> conflict operational evolutions.
>>>> [5] See
>>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017614.html.
>>>> For the philosophical reasons of doing so, I invite you to read Foucault's
>>>> famous essay "Le philosophe masque".
>>>> [6] Somehow I come to share Jeremy's thesis's "Product management is
>>>> not "my Job" it's yours" in matters of consensus changes. I believe we
>>>> might be past the technical complexity threshold where even simple
>>>> consensus changes can be conducted from A to Z as a one man job or even by
>>>> a group of 2/3 elite devs.
>>>> [7] I've been reached out multiple times and consistently by R&D
>>>> non-profits, plebs whales and VC firms who were interested to commit
>>>> resources to advance softforks and covenants in the Bitcoin space, no doubt
>>>> when you're reliable and with a track record, folks are ready to offer you
>>>> opportunities to work full-time on consensus changes.
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230720/5ec20265/attachment-0001.html>;
Greg Sanders [ARCHIVE] /
npub1jd…3gh0m
2023-07-20 09:54:06
in reply to nevent1q…4xe6
Author Public Key
npub1jdl3plz00rvxwc6g2ckemzrgg0amx5wen4kfvs3laxtssxvk9cvsf3gh0mPublished at
2023-07-20 09:54:06Event JSON
{
"id": "63998d564bbabc37997dbe8c07eab2c5b98d5532b118316817806a8463512acf",
"pubkey": "937f10fc4f78d8676348562d9d886843fbb351d99d6c96423fe9970819962e19",
"created_at": 1689846846,
"kind": 1,
"tags": [
[
"e",
"221a8dd02153540d63b18d45c4b280de2cb388a88adc30d8d08d797172aa19b8",
"",
"root"
],
[
"e",
"d73e430e279d97e643b2f6889f7c61b7c3a9a907b7fb0ea96c63a3ce7f10aab3",
"",
"reply"
],
[
"p",
"6485bc56963b51c9043d0855cca9f78fcbd0ce135a195c3f969e18ca54a0d551"
]
],
"content": "📅 Original date posted:2023-07-20\n🗒️ Summary of this message: Antoine acknowledges Greg's development approach but raises concerns about the authority of BOLTs and the technical fitness of Simplicity for small party channels.\n📝 Original message:\nHi antoine,\n\nSimplicity was just a stand in for \"functionally complete\" handwave.\n\nCheers,\nGreg\n\nOn Thu, Jul 20, 2023, 1:46 AM Antoine Riard \u003cantoine.riard at gmail.com\u003e wrote:\n\n\u003e Hi Greg,\n\u003e\n\u003e I'm very meeting your development approach with regards to starting smalls\n\u003e about consensus change primitives, and I think taproot has demonstrated\n\u003e some good historical process, which has good archives about how development\n\u003e was conducted (e.g the community-wide taproot review of which the Bitcoin\n\u003e Contracting Primitives WG was built on this experience [0]).\n\u003e\n\u003e I don't know about saying that the BOLTs (and its process) should be\n\u003e authoritative over the running code of implementations. While it's\n\u003e definitely a mark of some bar of technical review and inter-compatibility,\n\u003e I think ultimately each BOLT has to be judged individually on its own\n\u003e technical merits. And I think we had a bunch of cases in the past when \"the\n\u003e map is not the territory\". Even there are few areas of critical Lightning\n\u003e operations which are not documented by the BOLTs to the best of my\n\u003e knowledge (such as fee-bumping and transactions broadcast reactions as it\n\u003e was for on-chain DLCs [1]).\n\u003e\n\u003e Lastly, there is a huge area of uncertainty about the technical fitness of\n\u003e Simplicity for 2/small party channels. I remember a Russell O'connor\n\u003e presentation about Simplicity back in Paris (2017 or 2018 ?) and asking him\n\u003e how it would work in a chain of transactions, while the answer was iirc\n\u003e \"yes it has been designed with this constraint\", it's a very open question\n\u003e when you have off-chain states which advances in independence from the\n\u003e on-chain state between a dynamic number of counterparties (kinda the\n\u003e interactivity issue for payment pools). Here I guess you would have to come\n\u003e to a consensus to the model of logic followed for the analysis of such\n\u003e distributed systems e.g Leslie Lamport's temporal logic [2]. Additionally,\n\u003e the theoretical foundations on the Coq prover are still actively studied by\n\u003e Xavier Leroy at the College de France and some novel insights might be\n\u003e interesting for using formal verification in terms of Bitcoin consensus\n\u003e changes development (and I don't know if all the works and lessons have\n\u003e been translated from French to English).\n\u003e\n\u003e Best,\n\u003e Antoine\n\u003e\n\u003e [0] https://github.com/ajtowns/taproot-review\n\u003e [1]\n\u003e https://github.com/discreetlogcontracts/dlcspecs/blob/master/Non-Interactive-Protocol.md\n\u003e [2] https://en.wikipedia.org/wiki/Temporal_logic_of_actions\n\u003e\n\u003e Le mer. 19 juil. 2023 à 21:45, Greg Sanders \u003cgsanders87 at gmail.com\u003e a\n\u003e écrit :\n\u003e\n\u003e\u003e Hello Keagen,\n\u003e\u003e\n\u003e\u003e Most of the complexity of LN cannot be resolved with covenants. Of the\n\u003e\u003e things that can be simplified in my experience, you're going to need more\n\u003e\u003e than CTV to get significant gains. And in the end, channels can only get so\n\u003e\u003e simple since we have many other BOLTs to deal with. And even then, you're\n\u003e\u003e going to have to convince LN spec writers to include such changes, whatever\n\u003e\u003e they are, then get deployment.\n\u003e\u003e\n\u003e\u003e Step 1 is finding a primitive that seems interesting. It's important to\n\u003e\u003e moderate enthusiasm for any primitive with reality, and probably by being\n\u003e\u003e concrete by writing specs that use a primitive, and code it up to discover\n\u003e\u003e what we're overlooking. We're always overlooking something! In my humble\n\u003e\u003e opinion these are step 2 and 3 of gathering mind-share.\n\u003e\u003e\n\u003e\u003e As a more productive tact, if we're thinking beyond 2/small party\n\u003e\u003e channels, probably better to snap your fingers, pretend we have Simplicity,\n\u003e\u003e see what we can build, and work backwards from there to see if we can\n\u003e\u003e accomplish this within the confines of bitcoin script?\n\u003e\u003e\n\u003e\u003e Cheers,\n\u003e\u003e Greg\n\u003e\u003e\n\u003e\u003e On Wed, Jul 19, 2023 at 3:59 PM Keagan McClelland via bitcoin-dev \u003c\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e Hi Antoine,\n\u003e\u003e\u003e\n\u003e\u003e\u003e Thank you for the effort you've put towards this. I generally agree that\n\u003e\u003e\u003e a smooth functioning Lightning Network is of greater importance than\n\u003e\u003e\u003e advanced contracting capabilities. However, as I dive deeper into some of\n\u003e\u003e\u003e the more ambitious goals for LN development I am learning that a great deal\n\u003e\u003e\u003e of complexity of some current lightning (LN) proposals can be handily\n\u003e\u003e\u003e discharged with CTV. While I am not intimately familiar with all of the\n\u003e\u003e\u003e other covenant schemes to the same level of technical proficiency, I have a\n\u003e\u003e\u003e suspicion that a number of them, if not all of them, are capable of\n\u003e\u003e\u003e discharging the same flavor and amount of complexity as well. Others should\n\u003e\u003e\u003e chime in if they can confirm this claim.\n\u003e\u003e\u003e\n\u003e\u003e\u003e I have been publicly on the record as supporting the addition of some\n\u003e\u003e\u003e covenant scheme into Bitcoin for some time and have long held on\n\u003e\u003e\u003e theoretical grounds that the addition of such a mechanism is both necessary\n\u003e\u003e\u003e and inevitable if Bitcoin is to survive in the long term. However, as I've\n\u003e\u003e\u003e started to work more directly with the Lightning protocol, these\n\u003e\u003e\u003e theoretical and purely logical arguments became far more concrete and\n\u003e\u003e\u003e immediately beneficial.\n\u003e\u003e\u003e\n\u003e\u003e\u003e I say this primarily to challenge the idea that covenants are a\n\u003e\u003e\u003e distraction from lightning development. It may very well be that your areas\n\u003e\u003e\u003e of focus on LN preclude you from splitting your attention and none of this\n\u003e\u003e\u003e email should be interpreted as a criticism of you applying your efforts in\n\u003e\u003e\u003e the highest leverage manner you can manage. That said, I don't want\n\u003e\u003e\u003e observers of this thread to walk away with the impression that they are two\n\u003e\u003e\u003e independent efforts as covenants can significantly contribute to LN's\n\u003e\u003e\u003e maturity. When and how should they be prioritized? Unfortunately I don't\n\u003e\u003e\u003e feel able to comment on that at this time. All I know is that Lightning\n\u003e\u003e\u003e would almost certainly benefit substantially from having a covenant\n\u003e\u003e\u003e primitive.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Cheers,\n\u003e\u003e\u003e Keags\n\u003e\u003e\u003e\n\u003e\u003e\u003e On Tue, Jul 18, 2023 at 3:40 PM Antoine Riard via bitcoin-dev \u003c\n\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e Hi list,\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e Last year amid the failure of the CTV speedy trial activation and\n\u003e\u003e\u003e\u003e intense conversations about a rainbow of covenant proposals, I introduced\n\u003e\u003e\u003e\u003e the idea of a new community process to specify covenants [0]. This post is\n\u003e\u003e\u003e\u003e to resume the experiment so far and officially mark the process maintenance\n\u003e\u003e\u003e\u003e as \"up for grabs\", as I won't actively pursue it further (after wavering on\n\u003e\u003e\u003e\u003e such a decision a bit during May / June).\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e Few of the goals announced at that time were to build a consistent\n\u003e\u003e\u003e\u003e framework to evaluate covenant proposals, see the common grounds between\n\u003e\u003e\u003e\u003e proposals if they could be composed or combined by their authors, open the\n\u003e\u003e\u003e\u003e consensus changes development process beyond the historical boundaries of\n\u003e\u003e\u003e\u003e Bitcoin Core and maintain high-quality technical archive as a consensus\n\u003e\u003e\u003e\u003e discussions have spawned half a decade from intellectual conception to\n\u003e\u003e\u003e\u003e activation in average (at least for segwit, schnorr, taproot).\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e Such effort was a speak-by-the-act answer to the issues in\n\u003e\u003e\u003e\u003e consensus development changes pointed out by Jeremy Rubin in April of last\n\u003e\u003e\u003e\u003e year [1]: namely the lack of a \"codified checklist\" for consensus changes,\n\u003e\u003e\u003e\u003e that \"consensus is memoryless\" and \"bitcoin core is not bitcoin\"\n\u003e\u003e\u003e\u003e (independently of the technical concerns as I have as limited or\n\u003e\u003e\u003e\u003e non-adequate primitive for vaults / payment pools I expressed during the\n\u003e\u003e\u003e\u003e same time). Other complementary initiatives have been undertaken during the\n\u003e\u003e\u003e\u003e same period, AJ with the bitcoin-inquisition fork where the community of\n\u003e\u003e\u003e\u003e developers and contracting primitives of researchers on a consensus-enabled\n\u003e\u003e\u003e\u003e fork of core [2]. And Dave Harding with the careful archiving of all\n\u003e\u003e\u003e\u003e covenant proposals under the Optech umbrella [3].\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e About the Bitcoin Contracting Primitives WG, a Github repository was\n\u003e\u003e\u003e\u003e started and maintained to archive and document all the primitives (apo,\n\u003e\u003e\u003e\u003e tluv, ctv, the taproot annex, sighash_group, CSFS, cat, txhash, evict,\n\u003e\u003e\u003e\u003e check_output_covenant_verify, inherited ids, anyamount, singletons,\n\u003e\u003e\u003e\u003e op_vault) and the corresponding protocols (payment pools, vaults,\n\u003e\u003e\u003e\u003e drivechains, trust-minimized mining pools payouts). We had a total of 6\n\u003e\u003e\u003e\u003e monthly meetings on the Libera chat #bitcoin-contracting-primitives-wg for\n\u003e\u003e\u003e\u003e a number of more than 20 individual attendees representing most of the\n\u003e\u003e\u003e\u003e parts of the community. I think (missing march logs). Numerous in-depth\n\u003e\u003e\u003e\u003e discussions did happen on the repository and on the channel on things like\n\u003e\u003e\u003e\u003e \"merkelized all the things\" or \"payment pools for miners payoffs\".\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e As I've been busy on the Lightning-side and other Bitcoin projects,\n\u003e\u003e\u003e\u003e I've not run an online meeting since the month of April, while still having\n\u003e\u003e\u003e\u003e a bunch of fruitful technical discussions with folks involved in the effort\n\u003e\u003e\u003e\u003e at conferences and elsewhere. I launched the effort as an experiment with\n\u003e\u003e\u003e\u003e the soft commitment to dedicate 20% of my time on it, after few successful\n\u003e\u003e\u003e\u003e sessions I think such a process has an interest of its own, however it\n\u003e\u003e\u003e\u003e comes with direct competition of my time to work on Lightning robustness.\n\u003e\u003e\u003e\u003e Getting my hands dirty on low-level LDK development recently made me\n\u003e\u003e\u003e\u003e realize we still have years of titan work to get a secure and reliable\n\u003e\u003e\u003e\u003e Lightning Network.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e As such, between extended covenant capabilities for advanced contracts\n\u003e\u003e\u003e\u003e coming as a reality for Bitcoin _or_ LN working smoothly at scale with\n\u003e\u003e\u003e\u003e 50-100M UTXO-sharing users on it during the next 5-7 years cycle, I think\n\u003e\u003e\u003e\u003e the latter goal is more critical for Bitcoin existential survival, and\n\u003e\u003e\u003e\u003e where on a personal title I'll allocate the best of my time and energy (and\n\u003e\u003e\u003e\u003e somehow it match the \"slow\" technical activity on bitcoin-inquisition\n\u003e\u003e\u003e\u003e mostly done by Lightning hands).\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e This is my personal conclusion only on the state of Bitcoin\n\u003e\u003e\u003e\u003e technological momentum, and this is quite tainted by my deep background in\n\u003e\u003e\u003e\u003e Lightning development. If you've been working on covenant changes\n\u003e\u003e\u003e\u003e proposals, please don't take it as a discouragement, I think Taproot\n\u003e\u003e\u003e\u003e (privacy-preserving script policies behind the taproot tree branches) and\n\u003e\u003e\u003e\u003e Schnorr (for native multi-sig) soft forks have shown how it can improve the\n\u003e\u003e\u003e\u003e building of self-custody solutions by one or two order of magnitude, and\n\u003e\u003e\u003e\u003e small incremental changes might be good enough to have a lower technical\n\u003e\u003e\u003e\u003e consensus bar.\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e On my side, I'll pursue pure R\u0026D works on CoinPool, notably coming with\n\u003e\u003e\u003e\u003e better solutions with the interactivity issue and mass-compression of\n\u003e\u003e\u003e\u003e withdrawal and design exotic advanced Bitcoin contracts based on the\n\u003e\u003e\u003e\u003e taproot annex, though more in a \"l'art pour l'art\" approach for the time\n\u003e\u003e\u003e\u003e being [4]. Additionally, I might start to submit an in-depth security\n\u003e\u003e\u003e\u003e review of consensus changes under pseudonyms, it has already been done in\n\u003e\u003e\u003e\u003e the past and somehow it's good practice in terms of \"message neutrality\"\n\u003e\u003e\u003e\u003e [5]. If folks wanna experiment in terms of payment pools deployment, Greg\n\u003e\u003e\u003e\u003e Maxwell's old joinpool can be used today (and somehow it's worthy of its\n\u003e\u003e\u003e\u003e own as a net advance for coinjoins).\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e I'll honestly acknowledge towards the community, I might have\n\u003e\u003e\u003e\u003e overpromised with the kickstart of this new process aiming to move the\n\u003e\u003e\u003e\u003e frontlines in matters of Bitcoin consensus changes development process. On\n\u003e\u003e\u003e\u003e the other hand, I think enough sessions of the working group have been\n\u003e\u003e\u003e\u003e runned and enough marks of technical interests have been collected to\n\u003e\u003e\u003e\u003e demonstrate the minimal value of such a process, so I would estimate my\n\u003e\u003e\u003e\u003e open-source balance sheet towards the community to be in good standing ?\n\u003e\u003e\u003e\u003e (open-minded question).\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e I don't think Bitcoin fundamentally lacks compelling technical\n\u003e\u003e\u003e\u003e proposals to advance the capabilities of Bitcoin Script today, nor the\n\u003e\u003e\u003e\u003e crowd of seasoned and smart protocol developers to evaluate mature\n\u003e\u003e\u003e\u003e proposals end-to-end and on multiple dimensions with a spirit of\n\u003e\u003e\u003e\u003e independence. Rather, I believe what Bitcoin is lacking is a small crowd of\n\u003e\u003e\u003e\u003e technical historians and archivist doing the work of assessing, collecting\n\u003e\u003e\u003e\u003e and preserving consensus changes proposals and QA devs to ensure any\n\u003e\u003e\u003e\u003e consensus change proposals has world-class battle-ground testing before to\n\u003e\u003e\u003e\u003e be considered for deployment, ideally with the best standards of Bitcoin\n\u003e\u003e\u003e\u003e decentralization and FOSS neutrality [6].\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e If you would like to pursue the maintenance and nurturing of the\n\u003e\u003e\u003e\u003e Bitcoin Contracting Primitives WG (or the bitcoin-inquisition fork or\n\u003e\u003e\u003e\u003e collaborate with Optech to organize industry-wise workshop on covenants at\n\u003e\u003e\u003e\u003e the image of what has been done in 2019 for Taproot), that you're willing\n\u003e\u003e\u003e\u003e to show proof-of-work and you estimate that operational ground, legal\n\u003e\u003e\u003e\u003e information or financial resources will anchor your individual work on the\n\u003e\u003e\u003e\u003e long-term, don't hesitate to reach out, I'll see what I can do with a\n\u003e\u003e\u003e\u003e disinterested mind [7].\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e With humility,\n\u003e\u003e\u003e\u003e Antoine\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e\u003e [0]\n\u003e\u003e\u003e\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020763.html\n\u003e\u003e\u003e\u003e [1]\n\u003e\u003e\u003e\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020233.html\n\u003e\u003e\u003e\u003e [2]\n\u003e\u003e\u003e\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020921.html\n\u003e\u003e\u003e\u003e [3] https://github.com/bitcoinops/bitcoinops.github.io/pull/806\n\u003e\u003e\u003e\u003e [4] Version 0.2 of the CoinPool whitepaper addressing most of the\n\u003e\u003e\u003e\u003e remaining \"Big Problems\" is still pending on my visit to co-author Gleb\n\u003e\u003e\u003e\u003e Naumenko in Ukraine, which has been postponed few times in light of the\n\u003e\u003e\u003e\u003e conflict operational evolutions.\n\u003e\u003e\u003e\u003e [5] See\n\u003e\u003e\u003e\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017614.html.\n\u003e\u003e\u003e\u003e For the philosophical reasons of doing so, I invite you to read Foucault's\n\u003e\u003e\u003e\u003e famous essay \"Le philosophe masque\".\n\u003e\u003e\u003e\u003e [6] Somehow I come to share Jeremy's thesis's \"Product management is\n\u003e\u003e\u003e\u003e not \"my Job\" it's yours\" in matters of consensus changes. I believe we\n\u003e\u003e\u003e\u003e might be past the technical complexity threshold where even simple\n\u003e\u003e\u003e\u003e consensus changes can be conducted from A to Z as a one man job or even by\n\u003e\u003e\u003e\u003e a group of 2/3 elite devs.\n\u003e\u003e\u003e\u003e [7] I've been reached out multiple times and consistently by R\u0026D\n\u003e\u003e\u003e\u003e non-profits, plebs whales and VC firms who were interested to commit\n\u003e\u003e\u003e\u003e resources to advance softforks and covenants in the Bitcoin space, no doubt\n\u003e\u003e\u003e\u003e when you're reliable and with a track record, folks are ready to offer you\n\u003e\u003e\u003e\u003e opportunities to work full-time on consensus changes.\n\u003e\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\u003e\u003e\n\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\u003e\n\u003e\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230720/5ec20265/attachment-0001.html\u003e",
"sig": "57d64c8ff7143ba9b46c8dc67d5c0bc80fe20ca6f1a7f0c4ef0e72b0b813a0fa6677454310220e5b9cb10c5bc501f6296befa353b17b2f09d0617a2869f3a393"
}