Greg Sanders [ARCHIVE] on Nostr: 📅 Original date posted:2023-07-20 🗒️ Summary of this message: Antoine ...
📅 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>;
🗒️ 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>;