Re: [bitcoin-dev] On the experiment of the Bitcoin Contracting Primitives WG and marking this community process "up for grabs"
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 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@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
Re: [bitcoin-dev] On the experiment of the Bitcoin Contracting Primitives WG and marking this community process "up for grabs"
Hi Keagan, On the claim that advanced contracting capabilities can improve the Lightning Network, yes this is a claim I can back and why with Gleb we published ideas about payment pools back in 2020, pointing out clearly the limitations of 2-party payment channels in terms of privacy and scalability dimensions [0]. There are few discussions on the same thread on trade-off of hashchain covenants like CTV in terms of off-chain constructions, where they can be evaluated on a bunch of dimensions like key management, fee cost, liquidity counterparty interactivity and security risks among others. I don't know if Bitcoin _needs_ covenant schemes to survive on the long term though yes I'll join the appreciation than few covenants (notable ones improving payment pools or channel factories and self-custody solutions) are increasing the odds of success of Bitcoin survival on dimensions like onboarding / transactional scaling and "non-first-party to self-sovereign custody" shapes of solutions. On a theoretical proof that covenants are formally needed, well one would have to reduce Bitcoin (and probably Lightning and the mining ecosystem) to a workable game-theory, and define this game to rely on practice assumptions to bound the dynamics of the "real-world" context [1]. On the latest claim that Lightning of today *might* benefit from a covenant primitive, it's hard to evaluate as the foundations of channel operations are quite under intense re-works from taproot, schnorr and package relay (affecting all the dimensions). Yet one might notice that "high-level" Lightning is more isolated than those ongoing changes, and where covenant primitives might be useful. I think there is a widely-known issue among the DLC development community on the limitations of signatures compared to CTV-like "hash-chain" in matters of financial engineering expressivity over a wide outcome space [2], [3], [4]. We experimented in the past DLC integration in LDK, though never so far to evaluate the practical performance bounds of curve points addition on what what you can express as advanced contracts (the original coinpool post points to the factorial complexity bound for withdrawal of unknown order and therefore covenant capabilities improves the issue, though here it's an issue of _any_ state being dependent on an unknown combination of oracle-sourced events). Best, Antoine [0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017964.html [1] E.g the delicate difference between the "theory" and "practice" from the viewpoint of physics, I would send back to Einstein's general theory where few (anecdotic?) experiments have cast doubts on its validity, e.g Miller's experiment in the 20s, and the echoes it had in scientific epistemology during the XXth. [2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019808.html [3] https://mailmanlists.org/pipermail/dlc-dev/2021-November/91.html [4] https://github.com/bitcoinops/bitcoinops.github.io/pull/806#issuecomment-1232073574 Le mer. 19 juil. 2023 à 19:29, Keagan McClelland < keagan.mcclell...@gmail.com> a écrit : > 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
Re: [bitcoin-dev] On the experiment of the Bitcoin Contracting Primitives WG and marking this community process "up for grabs"
Hi antoine, Simplicity was just a stand in for "functionally complete" handwave. Cheers, Greg On Thu, Jul 20, 2023, 1:46 AM Antoine Riard 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 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@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
