Re: [bitcoin-dev] On a new community process to specify covenants
Hi all, Following up my September's mail on the setting of a new decentralized, open and neutral community process dedicated to covenants R, a.k.a "Bitcoin Contracting Primitives WG", few updates. After collecting feedback on the adequate communication channel, a low access bar and pseudonymous participation sounds to be recurring criterias. As such, I would like to propose using IRC on Libera Chat. Opened the following chan: #bitcoin-contracting-primitives-wg If there are still strong likes for another communication channel, we can still consider it. For the 1st meeting date, I was thinking about the second week of November starting the 7th. About the day and time, we have the following list of Bitcoin open-source meetings happening across the ecosystem: - Bitcoin Core general developer meeting Thursday 19:00 UTC - Bitcoin Core wallet developer meeting Friday 19:00 UTC (every second week) - Bitcoin Core PR review club Wednesday 17:00 UTC - Lightning developer meeting Monday 20:00 UTC (bi-weekly, modulo weird Australian timezones details that I don't understand) - Core Lightning developer meeting Monday 20:00 UTC (every second week) - LDK developer meeting Monday 17:00 UTC (every second week) - LND PR review club Thursday 17:00 UTC (every second week) - LDK PR review club Tuesday 18:00 UTC (every second week) - DLC specs meeting Tuesday 19:00 CST (monthly) - LSP specs meeting Wednesday 10:00 UTC (every second week) This is a best effort to collect all the open-source engineering meetings across the ecosystem, though we might have more, feel free to point out the ones I'm forgetting. Minding all those meetings happenings and all the time zones, the usual times slots fitting most of the people are probably the ones between 16:00 UTC and 21:00 UTC. Looking forward to collecting what would be a good time slot for the happening of Bitcoin Contracting primitives WG. For the meeting frequency, I think we can start with a monthly frequency, then in function of the pace and sustained interest move to bi-weekly. No agenda, we'll see how things are evolving unconf style. In the process to collect and document all the known contracting protocol use-cases at: https://github.com/ariard/bitcoin-contracting-primitives-wg So far I've bookmarked the following list: - vaults - payment pools - channel factories - drivechains - eltoo channels - decentralized mining pools - scalable stateful contracts (e.g DLCs) - congestion control redux - non-interactive channels setups - state channels Though we're likely to see more emerge with time, feel free to point to the ones I'm forgetting. Recently, during a panel at a Bitcoin conference, I've been asked why such a primitives working group rather than a specialized WG on the use-case I'm mostly interested in (i.e payment pools). From my experience, the contracting primitives or covenant you're designing is more likely to be a function of the use-case properties you've in mind (e.g economic efficiency or flexibility), however it might not generalize well to the other contracting use-cases envisioned by a lot of other folks. One wishful thinking of setting up this R effort could yield one common contracting primitives toolchain servicing all the known use-cases. Though this is only wishful thinking and we'll see what happens, in fine Bitcoin development is kinda like jazz music, loosely structured, you launch the first few notes and then you listen to what the other musicians keep going on. Still open to more feedback on what the ideal Bitcoin contracting primitives WG would look like. Cheers, Antoine Le mer. 20 juil. 2022 à 16:42, Antoine Riard a écrit : > Hi, > > Discussions on covenants have been prolific and intense on this mailing > list and within the wider Bitcoin technical circles, I believe however > without succeeding to reach consensus on any new set of contracting > primitives satisfying the requirements of known covenant-enabled use-cases. > I think that's a fact to deplore as covenants would not only offer vast > extensions of the capabilities of Bitcoin as a system, i.e enabling new > types of multi-party contract protocols. But also empowering Bitcoin on its > fundamental value propositions of store of value (e.g by making vaults more > flexible) and payment system (e.g by making realistic channel > factories/payment pools). > > If we retain as a covenant definition, a spending constraint restricting > the transaction to which the spent UTXO can be spent, and enabling to > program contracts/protocols at the transaction-level instead of the > script-level, the list of Script primitives proposed during the last years > has grown large : ANYPREVOUT [0], CHECKSIGFROMSTACK [1], > CHECK_TEMPLATE_VERIFY [2], TAPROOT_LEAF_UPDATE_VERIFY [3], TXHASH [4], > PUSHTXDATA [5], CAT [6], EVICT [7], Grafroot delegation [8], SIGHASH_GROUP > [9], MERKLEBRANCHVERIFY [10] and more than I can't remember. Of course, all > the listed primitives are at different states of
Re: [bitcoin-dev] On a new community process to specify covenants
On Fri, Sep 16, 2022 at 9:18 PM Antoine Riard via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi Buck, > [...] > > I would vote against Slack. IRC is probably the best but maybe too high a > barrier to entry? Publishing logs at least would counter concerns of it > being exclusive. Maybe discord as an alternative. > > I would say I really like IRC too. The strong text-based format, the lack > of avatar emoji, the low-bar to participate pseudonymously, the leveling > field for non-native speakers contrary to audio and the easiness to grab > the mics, all features valuable for such a process I think. > > If IRC is still considered a technical high-bar for a standard > communication organ by many community stakeholders, discord is an > alternative. > I would rule out Discord, since it requires phone numbers. It doesn't require them for every user, but it's based on some risk measurement. The phone flow is probably more likely to be triggered by VPN / Tor. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] On a new community process to specify covenants
Hi Buck,
> First just wanted to thank you for taking the initiative to
> put this together. I think that as the community and
> ecosystem continue to grow, it's going to be an important
> part of the process to have groups like this develop. Hopefully
> they allow us to resist the "Tyranny of Structurelessness" without
> resorting to formalized governance processes and systems.
Thanks for the words. Effectively, organic WGs are likely good avenues for
the ecosystem to make steady and substantial progress during the coming
future. If there is any structure in the development of Bitcoin it's the
rich network of open, neutral and decentralized communication networks and
spaces that has been nurtured through the past decade and I hope that's a
tradition we'll keep maintaining.
> Defining a communication channel is still an open question: IRC, Slack,
Discord, Discourse, ...
I would vote against Slack. IRC is probably the best but maybe too high a
barrier to entry? Publishing logs at least would counter concerns of it
being exclusive. Maybe discord as an alternative.
I would say I really like IRC too. The strong text-based format, the lack
of avatar emoji, the low-bar to participate pseudonymously, the leveling
field for non-native speakers contrary to audio and the easiness to grab
the mics, all features valuable for such a process I think.
If IRC is still considered a technical high-bar for a standard
communication organ by many community stakeholders, discord is an
alternative.
> I understand the reason for this but I do have some concerns that
> it's not as off-topic as most of us would like. It shouldn't
> be a priority but how any of these primitives end up getting activated
> is part of the proposal itself in my opinion.
>
> I think it also became clear in some of the discussions over the past
> ~year that maybe there were more concerns than people realized about
> even the taproot activation process, whether the method used or if it
> was done too quickly. An example of where there might be
> some intersection with the WG as proposed is the question of how much
> research, security audits, etc. are "enough" before it should be
> considered for activation?
>From my understanding, how any of these primitives end up getting activated
is more a deployment methodology concern. What is more interesting is why
any of those primitives would be valuable as a Bitcoin upgrade. Beyond
proposing and refining primitives design and associated use-cases, there is
significant work to collect feedback on many dimensions and set of
criterias that matters to community stakeholders to achieve a consistent
and sound "why".
Where I believe there is an interaction between the "why" and "how" is that
during activation discussion some participant might bring new information
about shortcomings of a proposal, and as such if it's estimated relevant
could induce a step back to the "R" whiteboard phase, in a circular
feedback loop fashion. As those steps back are not free in terms of
community engineering resources, especially if deployment code starts to be
already disseminated across the ecosystem, I hope in the future we'll leave
reasonable time (in function of the complexity of the proposal) between
upgrade phases for grounded objections to raise.
>From my memory, about the taproot activation process it's correct that a
lot of people had discussions about producing more proof-of-work, e.g back
in 2019, LN devs were excited to PoC PTLC in the context of the structured
taproot review.
It didn't happen because it would have implied good refactoring works in
all implementations for that to happen and coordination with cryptographic
libraries dependencies.
In fact, it's likely the difficulty target for consensus upgrades to be
dynamic with the complexity of the ecosystem and stakes at risk increasing
modulo the amount of Bitcoin engineering resources dedicated.
> Maybe as a way to keep these topics separate, it would make sense
> for activation to have its own WG. As norms develop around this one,
> they could inform creating a separate space focused on forwarding
> research and discussion around how to introduce upgrades to bitcoin.
I think it could be interesting for activation to have its own WG. I
wouldn't call myself super knowledgeable in upgrades activation. I believe
it could be worthy for such WG to do the archival work of documentation and
referencing well all
the previous upgrades discussions, the set of signals and data points that
has been deemed as valuable by the community, etc.
> In general it would be nice to have multiple of these groups
> happening at once, and finding a way that they can operate separate
> from centralized companies. To my mind, there's no good reason why
> a supposedly decentralized protocol should have to be focusing on only
> one set of protocol advancements at a time. The linear way that
> discussions post-Taproot activation took shape ("What do you think the
> next bitcoin
Re: [bitcoin-dev] On a new community process to specify covenants
Hi Devrandom, > Agreed, anything that requires a phone number makes it difficult to be > pseudonymous. > > I recommend Matrix, since it doesn't require any privacy invasive > information and has e2ee by default for 1-1 conversations. Yeah sounds like people are opting for either Matrix or IRC and good to let cast open. If there are more things that the process could adopt to encourage or stay open to pseudonymous participation that's interesting to bookmark. Best, Antoine Le jeu. 15 sept. 2022 à 04:37, Devrandom via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> a écrit : > On Tue, Sep 13, 2022 at 6:03 PM Ryan Grant via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> On Mon, Sep 12, 2022 at 2:47 AM Buck O Perley via bitcoin-dev >> First just wanted to thank you >> for taking the initiative to >> > put this together. I think that as the community and >> > ecosystem continue to grow, it's going to be an important >> > part of the process to have groups like this develop. Hopefully >> > they allow us to resist the "Tyranny of Structurelessness" without >> > resorting to formalized governance processes and systems. >> >> Huh, lots of reading material behind that phrase. I'd heard it >> before, but hadn't looked it up. >> >> > > Defining a communication channel is still an open question: IRC, >> Slack, >> > Discord, Discourse, ... >> > >> > I would vote against Slack. IRC is probably the best but maybe too >> > high a barrier to entry? Publishing logs at least would counter >> > concerns of it being exclusive. Maybe discord as an alternative. >> >> I found Discord immediately wanted a phone number from me. I think >> IRC remains the lowest bar for participants to contribute. >> >> > Agreed, anything that requires a phone number makes it difficult to be > pseudonymous. > > I recommend Matrix, since it doesn't require any privacy invasive > information and has e2ee by default for 1-1 conversations. > > The Matrix room could optionally bridge to IRC if there is a significant > demand for that. > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] On a new community process to specify covenants
On Tue, Sep 13, 2022 at 6:03 PM Ryan Grant via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Mon, Sep 12, 2022 at 2:47 AM Buck O Perley via bitcoin-dev > First just wanted to thank you > for taking the initiative to > > put this together. I think that as the community and > > ecosystem continue to grow, it's going to be an important > > part of the process to have groups like this develop. Hopefully > > they allow us to resist the "Tyranny of Structurelessness" without > > resorting to formalized governance processes and systems. > > Huh, lots of reading material behind that phrase. I'd heard it > before, but hadn't looked it up. > > > > Defining a communication channel is still an open question: IRC, Slack, > > Discord, Discourse, ... > > > > I would vote against Slack. IRC is probably the best but maybe too > > high a barrier to entry? Publishing logs at least would counter > > concerns of it being exclusive. Maybe discord as an alternative. > > I found Discord immediately wanted a phone number from me. I think > IRC remains the lowest bar for participants to contribute. > > Agreed, anything that requires a phone number makes it difficult to be pseudonymous. I recommend Matrix, since it doesn't require any privacy invasive information and has e2ee by default for 1-1 conversations. The Matrix room could optionally bridge to IRC if there is a significant demand for that. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] On a new community process to specify covenants
On Mon, Sep 12, 2022 at 2:47 AM Buck O Perley via bitcoin-dev
First just wanted to thank you
for taking the initiative to
> put this together. I think that as the community and
> ecosystem continue to grow, it's going to be an important
> part of the process to have groups like this develop. Hopefully
> they allow us to resist the "Tyranny of Structurelessness" without
> resorting to formalized governance processes and systems.
Huh, lots of reading material behind that phrase. I'd heard it
before, but hadn't looked it up.
> > Defining a communication channel is still an open question: IRC, Slack,
> Discord, Discourse, ...
>
> I would vote against Slack. IRC is probably the best but maybe too
> high a barrier to entry? Publishing logs at least would counter
> concerns of it being exclusive. Maybe discord as an alternative.
I found Discord immediately wanted a phone number from me. I think
IRC remains the lowest bar for participants to contribute.
> > About the starting point for regular meetings, I think the good timing is
> somewhere in November, after the upcoming cycle of Bitcoin conferences,
+1
> Maybe as a way to keep these topics separate, it would make sense
> for activation to have its own WG. As norms develop around this one,
> they could inform creating a separate space focused on forwarding
> research and discussion around how to introduce upgrades to bitcoin.
I'd participate in this.
> In general it would be nice to have multiple of these groups
> happening at once, and finding a way that they can operate separate
> from centralized companies. To my mind, there's no good reason why
> a supposedly decentralized protocol should have to be focusing on only
> one set of protocol advancements at a time. The linear way that
> discussions post-Taproot activation took shape ("What do you think the
> next bitcoin softfork should be?") is a sign of weakness in my opinion.
> Definitely a big red flag that we should be concerned with.
Yes.
> * Any thoughts on starting to commit to an in-person meetup to happen
> ~6 months - 1 year after the start of the regular online meetings?
I think that sounds reasonable.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] On a new community process to specify covenants
Hi Antoine,
First just wanted to thank you for taking the initiative to
put this together. I think that as the community and
ecosystem continue to grow, it's going to be an important
part of the process to have groups like this develop. Hopefully
they allow us to resist the "Tyranny of Structurelessness" without
resorting to formalized governance processes and systems.
> Defining a communication channel is still an open question: IRC, Slack,
Discord, Discourse, ...
I would vote against Slack. IRC is probably the best but maybe too
high a barrier to entry? Publishing logs at least would counter
concerns of it being exclusive. Maybe discord as an alternative.
> About the starting point for regular meetings, I think the good timing is
somewhere in November, after the upcoming cycle of Bitcoin conferences,
+1
> softfork activation discussions will be considered as
off-topic and discouraged. This is first and foremost a long-term R
effort.
I understand the reason for this but I do have some concerns that
it's not as off-topic as most of us would like. It shouldn't
be a priority but how any of these primitives end up getting activated
is part of the proposal itself in my opinion.
I think it also became clear in some of the discussions over the past
~year that maybe there were more concerns than people realized about
even the taproot activation process, whether the method used or if it
was done too quickly. An example of where there might be
some intersection with the WG as proposed is the question of how much
research, security audits, etc. are "enough" before it should be
considered for activation?
Maybe as a way to keep these topics separate, it would make sense
for activation to have its own WG. As norms develop around this one,
they could inform creating a separate space focused on forwarding
research and discussion around how to introduce upgrades to bitcoin.
In general it would be nice to have multiple of these groups
happening at once, and finding a way that they can operate separate
from centralized companies. To my mind, there's no good reason why
a supposedly decentralized protocol should have to be focusing on only
one set of protocol advancements at a time. The linear way that
discussions post-Taproot activation took shape ("What do you think the
next bitcoin softfork should be?") is a sign of weakness in my opinion.
Definitely a big red flag that we should be concerned with.
Couple other comments from the proposal/repo:
* it seems like there might be some opportunities to work with
bipbounty.org which grew out of the organic bounty donations that
were made towards finding CTV vulnerabilities. For example,
if the group develops specific, achievable research goals (building
out use cases, researching vulnerabilities or limitations, etc.),
bipbounty.org could help support these efforts in a more decentralized
way by diversifying funding.
* Any thoughts on starting to commit to an in-person meetup to happen
~6 months - 1 year after the start of the regular online meetings?
That should be plenty of time for people to plan and formalize
a location and it seems like other IRL dev meetups have been
very productive in terms of knowledge sharing and setting priorities.
An in-person meetup would give a nice goal to work towards and a way
to measure progress.
publickey - buck.perley@protonmail.com - 0xC64EEB00.asc
Description: application/pgp-keys
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] On a new community process to specify covenants
Hi all, Following up on my July's mail proposing to setup a new community process dedicated to covenant R, after aggregating all the feedbacks received online/offline, I've started a repository to collect the use-cases and known design constraints: https://github.com/ariard/bitcoin-contracting-primitives-wg One notable change, the proposed process has been renamed to "Bitcoin Contracting Primitives WG", as covenants sound for few folks to be inaccurate in terms of scope to designate the whole range of techniques to enable/empower contracting applications. So far, I've documented the extension of the vault and payment pools use-cases. Use-case analysis is following somehow inspired by the reasoning framework as laid out by RFC 3426 [0]. This is a first shot and all current descriptions should only be taken as a "best-effort" for now. More use-cases descriptions coming soon. Hopefully we'll have a set of "champions" by use-case emerging with time. There is another ongoing effort to document the primitives themselves: https://github.com/bitcoinops/bitcoinops.github.io/pull/806 About the starting point for regular meetings, I think the good timing is somewhere in November, after the upcoming cycle of Bitcoin conferences, as I guess a good chunk of folks will attend them. Defining a communication channel is still an open question: IRC, Slack, Discord, Discourse, ... As discussed before, softfork activation discussions will be considered as off-topic and discouraged. This is first and foremost a long-term R effort. Contributors, reviewers and co-maintainers to the repository are welcome. All content is licensed under Creative Commons 4.0, though can be relicensed to another thing if it suits more (like all Bitcoin devs I'm only part-time lawyer). Still open to more feedbacks on what the ideal Bitcoin covenants/contracting primitives community process would looks like. Cheers, Antoine [0] https://www.rfc-editor.org/rfc/rfc3426.html Le mer. 20 juil. 2022 à 16:42, Antoine Riard a écrit : > Hi, > > Discussions on covenants have been prolific and intense on this mailing > list and within the wider Bitcoin technical circles, I believe however > without succeeding to reach consensus on any new set of contracting > primitives satisfying the requirements of known covenant-enabled use-cases. > I think that's a fact to deplore as covenants would not only offer vast > extensions of the capabilities of Bitcoin as a system, i.e enabling new > types of multi-party contract protocols. But also empowering Bitcoin on its > fundamental value propositions of store of value (e.g by making vaults more > flexible) and payment system (e.g by making realistic channel > factories/payment pools). > > If we retain as a covenant definition, a spending constraint restricting > the transaction to which the spent UTXO can be spent, and enabling to > program contracts/protocols at the transaction-level instead of the > script-level, the list of Script primitives proposed during the last years > has grown large : ANYPREVOUT [0], CHECKSIGFROMSTACK [1], > CHECK_TEMPLATE_VERIFY [2], TAPROOT_LEAF_UPDATE_VERIFY [3], TXHASH [4], > PUSHTXDATA [5], CAT [6], EVICT [7], Grafroot delegation [8], SIGHASH_GROUP > [9], MERKLEBRANCHVERIFY [10] and more than I can't remember. Of course, all > the listed primitives are at different states of formalization, some > already fully fleshed-out in BIPs, other still ideas on whiteboard, yet > they all extend the range of workable multi-party contract protocols. > > Indeed this range has grown wild. Without aiming to be exhaustive (I'm > certainly missing some interesting proposals lost in the abyss of > bitcointalk.org), we can mention the following use-cases: multi-party > stateful contracts [11], congestion trees [12], payment pools [13], "eltoo" > layered commitments [14], programmable vaults [15], multi-events contracts > [16], blockchain-as-oracle bets [17], spacechains [18], trustless > collateral lending [19], ... > > Minding all those facts, I would say the task of technical evaluation of > any covenant proposal sounds at least two fold. There is first reasoning > about the enabled protocols on a range of criterias such as scalability, > efficiency, simplicity, extensibility, robustness, data confidentiality, > etc. Asking questions like what are the interactions between layers, if any > ? Or how robust is the protocol, not just interactivity failure between > participant nodes but in the face of mempools spikes or internet > disruption ? Or if the performance is still acceptable on shared resources > like blockspace or routing tables if everyone is using this protocol ? Or > if the protocol minimizes regulatory attack surface or centralization > vectors ? > > Though once this step is achieved, there is still more reasoning work to > evaluate how good a fit is a proposed Script primitive, the > efficiency/simplicity/ease to use trade-offs, but also if there are no > functionality overlap or
Re: [bitcoin-dev] On a new community process to specify covenants
Hi Billy, > I was actually not thinking one large central in-person meeting, but many smaller decentralized in-person meetings where no one has to travel far. The meetings can be used to foster communication that can then be summarized and/or brought online and discussed with the larger group. Would certainly make all those date/visa/etc issues a lot easier. Minimizing travel hurdles for everyone sounds wise. About decentralized in-person meetings we already have a wide network of BitDev all around the world that can be opportunities to foster communication on covenant R advances. Staying interested in participating in in-person covenant-focus meetings though I won't volunteer to organize them, from my experience it's a real trade different from Bitcoin research engineering! > Fair enough. But I think part of the point here would be to use such a snapshot as an indicator that helps convince others that a particular idea has been discussed, thought through, and has actual well-reasoned support. Whatever you call it, it would be a useful set of data points. Yeah, collecting, building and maintaining a set of strong data points that would improve the community covenant information-gathering process. However, I think observing consensus is better left to everyone's personal judgement rather than proclaiming it. At best, we can monitor the lack of consensus. There is already an ongoing effort to document primitives : https://github.com/bitcoinops/bitcoinops.github.io/pull/806 and making progress on the use-cases collection soon. Le sam. 27 août 2022 à 22:01, Billy Tetrud a écrit : > > I would like to note it's real work for the organizers in terms of time > and energy: finding a common date making consensus, an acceptable host > country (i.e respecting the travel policy of the widest... > > I was actually not thinking one large central in-person meeting, but many > smaller decentralized in-person meetings where no one has to travel far. > The meetings can be used to foster communication that can then be > summarized and/or brought online and discussed with the larger group. Would > certainly make all those date/visa/etc issues a lot easier. > > > I would be even cautious about something restrained like "group > consensus" in Bitcoin FOSS. At best, it's just a snapshot of people's > understanding of the technical issues in state X at time T > > Fair enough. But I think part of the point here would be to use such a > snapshot as an indicator that helps convince others that a particular idea > has been discussed, thought through, and has actual well-reasoned support. > Whatever you call it, it would be a useful set of data points. > > > I believe the covenant problem space might be solved in an evolutionary > way, layer by layer akin to how LN moves forward. > > Definitely. > > > On Tue, Aug 9, 2022 at 3:15 PM Antoine Riard > wrote: > >> Hi Billy, >> >> Thanks for your interest in a covenant working group. >> >> > place for this kind of thing to happen. I also agree with Ryan Grant's >> > comment about in-person cut-through (ie cut through the BS and resolve >> > misunderstandings). Perhaps every 3 IRC meetings or so, an in-person >> meetup >> > can be organized in various locations to facilitate that kind of cut >> > through. >> >> I really appreciate in-person cut-through to resolve misunderstandings >> and accelerate the information synchronization across the stakeholders of a >> problem space. However, I would like to note it's real work for the >> organizers in terms of time and energy: finding a common date making >> consensus, an acceptable host country (i.e respecting the travel policy of >> the widest, e.g organizing Scaling in Israel in 2019 was an issue for some >> passport holders), a standard meeting location, seeking event sponsors, >> communicating all those infos well ahead to ease everyone travels, ensuring >> coffees & foods suiting many different diets, collecting topics of >> discussions, etc. Further, even assuming travel support, it can still be a >> prohibitive cost for a lot of participants, e.g if you have to request >> months ahead to the host country authorities a dedicated visa for the >> opportunity. I did a bit of in-person meetings organizing in the past, I'm >> clearly not interested in doing it anymore, though it would be cool if >> someone would like to do it for covenants in the future. >> >> > I would imagine the phases the group could go through is: >> > 1. Define the phases (these phases). This list of 6 phases could be a >> > starting point, but its probably best to open the floor to whether this >> > feels like a reasonable approach and if more phases are needed or if >> some >> > aren't. >> > 2. Define and prioritize the motivations (ie the various features and >> > functionality we want out of covenants, like the ones you listed). By >> > prioritize, I mostly mean figure out which motivations are most >> motivating >> > to people and rate them by strength of
Re: [bitcoin-dev] On a new community process to specify covenants
> I would like to note it's real work for the organizers in terms of time and energy: finding a common date making consensus, an acceptable host country (i.e respecting the travel policy of the widest... I was actually not thinking one large central in-person meeting, but many smaller decentralized in-person meetings where no one has to travel far. The meetings can be used to foster communication that can then be summarized and/or brought online and discussed with the larger group. Would certainly make all those date/visa/etc issues a lot easier. > I would be even cautious about something restrained like "group consensus" in Bitcoin FOSS. At best, it's just a snapshot of people's understanding of the technical issues in state X at time T Fair enough. But I think part of the point here would be to use such a snapshot as an indicator that helps convince others that a particular idea has been discussed, thought through, and has actual well-reasoned support. Whatever you call it, it would be a useful set of data points. > I believe the covenant problem space might be solved in an evolutionary way, layer by layer akin to how LN moves forward. Definitely. On Tue, Aug 9, 2022 at 3:15 PM Antoine Riard wrote: > Hi Billy, > > Thanks for your interest in a covenant working group. > > > place for this kind of thing to happen. I also agree with Ryan Grant's > > comment about in-person cut-through (ie cut through the BS and resolve > > misunderstandings). Perhaps every 3 IRC meetings or so, an in-person > meetup > > can be organized in various locations to facilitate that kind of cut > > through. > > I really appreciate in-person cut-through to resolve misunderstandings and > accelerate the information synchronization across the stakeholders of a > problem space. However, I would like to note it's real work for the > organizers in terms of time and energy: finding a common date making > consensus, an acceptable host country (i.e respecting the travel policy of > the widest, e.g organizing Scaling in Israel in 2019 was an issue for some > passport holders), a standard meeting location, seeking event sponsors, > communicating all those infos well ahead to ease everyone travels, ensuring > coffees & foods suiting many different diets, collecting topics of > discussions, etc. Further, even assuming travel support, it can still be a > prohibitive cost for a lot of participants, e.g if you have to request > months ahead to the host country authorities a dedicated visa for the > opportunity. I did a bit of in-person meetings organizing in the past, I'm > clearly not interested in doing it anymore, though it would be cool if > someone would like to do it for covenants in the future. > > > I would imagine the phases the group could go through is: > > 1. Define the phases (these phases). This list of 6 phases could be a > > starting point, but its probably best to open the floor to whether this > > feels like a reasonable approach and if more phases are needed or if some > > aren't. > > 2. Define and prioritize the motivations (ie the various features and > > functionality we want out of covenants, like the ones you listed). By > > prioritize, I mostly mean figure out which motivations are most > motivating > > to people and rate them by strength of motivation (rather than a ranked > > list). > > 3. Define and prioritize the relevant constraints. These are things to > > avoid in any covenant implementation. Constraints that have been brought > up > > in the past are things like preventing the possibility of infinite > covenant > > recursion, full enumeration, preventing dynamic state, etc. By prioritize > > here, it might be useful to categorize them into categories like "no > > tolerance", "some tolerance", "no reservations". Eg it might turn out > most > > people don't have any tolerance for infinite recursion, but don't mind > > non-full enumeration. > > 4. Other criteria? These are other criteria we might want to evaluate > > proposals according to. And some kind of way to prioritize them / > evaluate > > them against each other as trade offs. > > 5. Evaluate the proposals based on motivations, constraints, and other > > criteria. This phase shouldn't involve comparing them to each other. > > 6. Produce a set of conclusions/opinions on which proposals are worth > > pursuing further. This would be the phase where proposals are compared. > > Yes, I think overall a lot is making sense. Though it's good to keep > things as loose and see how it evaluates with time and new information > showing up. > > About 2., I think one more thing to define is the list of use-cases, I > would abstract out features and functionality from use-cases. E.g, I think > with the TLUV proposal, the taproot output editing feature enables both > "dynamic-amount" vault and scaling payment pools. > > About 3., I think this is going to be the hard part. Collecting all the > constraints and evaluating the risk tolerance of as-much-as-we-can >
Re: [bitcoin-dev] On a new community process to specify covenants
Hi Billy, Thanks for your interest in a covenant working group. > place for this kind of thing to happen. I also agree with Ryan Grant's > comment about in-person cut-through (ie cut through the BS and resolve > misunderstandings). Perhaps every 3 IRC meetings or so, an in-person meetup > can be organized in various locations to facilitate that kind of cut > through. I really appreciate in-person cut-through to resolve misunderstandings and accelerate the information synchronization across the stakeholders of a problem space. However, I would like to note it's real work for the organizers in terms of time and energy: finding a common date making consensus, an acceptable host country (i.e respecting the travel policy of the widest, e.g organizing Scaling in Israel in 2019 was an issue for some passport holders), a standard meeting location, seeking event sponsors, communicating all those infos well ahead to ease everyone travels, ensuring coffees & foods suiting many different diets, collecting topics of discussions, etc. Further, even assuming travel support, it can still be a prohibitive cost for a lot of participants, e.g if you have to request months ahead to the host country authorities a dedicated visa for the opportunity. I did a bit of in-person meetings organizing in the past, I'm clearly not interested in doing it anymore, though it would be cool if someone would like to do it for covenants in the future. > I would imagine the phases the group could go through is: > 1. Define the phases (these phases). This list of 6 phases could be a > starting point, but its probably best to open the floor to whether this > feels like a reasonable approach and if more phases are needed or if some > aren't. > 2. Define and prioritize the motivations (ie the various features and > functionality we want out of covenants, like the ones you listed). By > prioritize, I mostly mean figure out which motivations are most motivating > to people and rate them by strength of motivation (rather than a ranked > list). > 3. Define and prioritize the relevant constraints. These are things to > avoid in any covenant implementation. Constraints that have been brought up > in the past are things like preventing the possibility of infinite covenant > recursion, full enumeration, preventing dynamic state, etc. By prioritize > here, it might be useful to categorize them into categories like "no > tolerance", "some tolerance", "no reservations". Eg it might turn out most > people don't have any tolerance for infinite recursion, but don't mind > non-full enumeration. > 4. Other criteria? These are other criteria we might want to evaluate > proposals according to. And some kind of way to prioritize them / evaluate > them against each other as trade offs. > 5. Evaluate the proposals based on motivations, constraints, and other > criteria. This phase shouldn't involve comparing them to each other. > 6. Produce a set of conclusions/opinions on which proposals are worth > pursuing further. This would be the phase where proposals are compared. Yes, I think overall a lot is making sense. Though it's good to keep things as loose and see how it evaluates with time and new information showing up. About 2., I think one more thing to define is the list of use-cases, I would abstract out features and functionality from use-cases. E.g, I think with the TLUV proposal, the taproot output editing feature enables both "dynamic-amount" vault and scaling payment pools. About 3., I think this is going to be the hard part. Collecting all the constraints and evaluating the risk tolerance of as-much-as-we-can community stakeholders in face of known and plausible risks. E.g, again with TLUV, I think it would make from now on the taproot internal pubkey and tree of alternative scripts a kind of "dynamic state". About 4. I've quickly come to mind as additional criterias economic simulations of any feature, privacy advantages, toolchain implementations complexity, evolvability and composability with future features. About 6. I agree I think it's good to withhold comparison further down in the pipe we can, even if there is I would say some criteria-learning heuristics by mirroring features against another. > Each phase would probably span over more than one meeting. I imagine each > phase basically consisting of discussing each individual nominated item (ie > motivations, constraints, other criteria, or proposals) sequentially. The > consensus reached at the end of each phase would be considered of course a > group consensus of those who participated, not a global consensus, not a > "bitcoin community consensus". After each phase, the results of that phase > would be published more widely to get broader community feedback. These > results would include what the major opinions are, what level of consensus > each major opinion has, what the reasons/justifications behind each opinion > are, and various detailed opinions from individuals. It would be
Re: [bitcoin-dev] On a new community process to specify covenants
@Antoine I very much like your proposal of an open decentralized process for investigating the problem and solution spaces. IRC sounds like a reasonable place for this kind of thing to happen. I also agree with Ryan Grant's comment about in-person cut-through (ie cut through the BS and resolve misunderstandings). Perhaps every 3 IRC meetings or so, an in-person meetup can be organized in various locations to facilitate that kind of cut through. I would imagine the phases the group could go through is: 1. Define the phases (these phases). This list of 6 phases could be a starting point, but its probably best to open the floor to whether this feels like a reasonable approach and if more phases are needed or if some aren't. 2. Define and prioritize the motivations (ie the various features and functionality we want out of covenants, like the ones you listed). By prioritize, I mostly mean figure out which motivations are most motivating to people and rate them by strength of motivation (rather than a ranked list). 3. Define and prioritize the relevant constraints. These are things to avoid in any covenant implementation. Constraints that have been brought up in the past are things like preventing the possibility of infinite covenant recursion, full enumeration, preventing dynamic state, etc. By prioritize here, it might be useful to categorize them into categories like "no tolerance", "some tolerance", "no reservations". Eg it might turn out most people don't have any tolerance for infinite recursion, but don't mind non-full enumeration. 4. Other criteria? These are other criteria we might want to evaluate proposals according to. And some kind of way to prioritize them / evaluate them against each other as trade offs. 5. Evaluate the proposals based on motivations, constraints, and other criteria. This phase shouldn't involve comparing them to each other. 6. Produce a set of conclusions/opinions on which proposals are worth pursuing further. This would be the phase where proposals are compared. Each phase would probably span over more than one meeting. I imagine each phase basically consisting of discussing each individual nominated item (ie motivations, constraints, other criteria, or proposals) sequentially. The consensus reached at the end of each phase would be considered of course a group consensus of those who participated, not a global consensus, not a "bitcoin community consensus". After each phase, the results of that phase would be published more widely to get broader community feedback. These results would include what the major opinions are, what level of consensus each major opinion has, what the reasons/justifications behind each opinion are, and various detailed opinions from individuals. It would be especially great to have detailed evaluations of each proposal published by various people so anyone can go back and understand their thought process (as opposed to a list of names attached to basically a thumbs up or thumbs down). Think like a supreme court decision kind of thing. The process doesn't need to be complete after phase 6. Any previous phase could be revisited, but after a phase is revisited, the phases after it should probably be also revisited in order - or at least until its decided a previous phase needs to be revisited again. Each iteration would solidify consensus more about each phase. I would imagine the group might loop through phases 2, 3, and 4 a couple times (since constraints might conflict with motivating features). It might be likely that in phase 5 while evaluating proposals, people realize that there are additional criteria that should be added and can propose going back to step 4 to do that. Hopefully we would get to the point where the motivations and constraints and relatively solid consensuses and iterations can loop through phases 5 and 6 until the set of proposals the group thinks is worth pursuing is narrowed down (ideally to 1 or 2). On Tue, Jul 26, 2022 at 11:47 AM Bram Cohen via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Mon, Jul 25, 2022 at 8:21 PM Antoine Riard > wrote: > >> What would be the canonical definition and examples of capabilities in >> the Bitcoin context ? >> > > Payments into vaults which can only be accepted by that vault and are > guaranteed to be subject to the vault's restrictions (the vault has a > capability) > > Oracles whose validity can be verified on chain (so transactions can > depend on what they say. The oracle has a capability) > > Colored coins whose validity can be verified on chain (the colored coins > have a capability) > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] On a new community process to specify covenants
On Mon, Jul 25, 2022 at 8:21 PM Antoine Riard wrote: > What would be the canonical definition and examples of capabilities in the > Bitcoin context ? > Payments into vaults which can only be accepted by that vault and are guaranteed to be subject to the vault's restrictions (the vault has a capability) Oracles whose validity can be verified on chain (so transactions can depend on what they say. The oracle has a capability) Colored coins whose validity can be verified on chain (the colored coins have a capability) ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] On a new community process to specify covenants
What would be the canonical definition and examples of capabilities in the Bitcoin context ? In anycase, I believe it would be better to start a covenant process from the use-cases in themselves, and analyse the trade-offs of any set of contracting primitives, or even new Bitcoin fields if they're required building blocks of the use-cases. Le dim. 24 juil. 2022 à 14:23, Bram Cohen a écrit : > On Wed, Jul 20, 2022 at 2:46 PM Antoine Riard via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Indeed this range has grown wild. Without aiming to be exhaustive (I'm >> certainly missing some interesting proposals lost in the abyss of >> bitcointalk.org), we can mention the following use-cases: multi-party >> stateful contracts [11], congestion trees [12], payment pools [13], "eltoo" >> layered commitments [14], programmable vaults [15], multi-events contracts >> [16], blockchain-as-oracle bets [17], spacechains [18], trustless >> collateral lending [19], ... >> > > The big question you missed is whether capabilities are in scope for a > covenants proposal. In particular, vaults work a lot better when payments > to them are immediately locked up in the vault rather than it having to do > a step to accept them first. > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] On a new community process to specify covenants
Hi Zeeman, So on the first concern of using an "economic simulation" or sidechains/other cryptocurrencies to gather feedback about interest of Script extensions, I wonder about the value transitivity of such a process to measure consensus. Namely, if you have asset X picked up in system A, it doesn't tell you the same asset X is preferred in system B, unless I think you have the same agent. However, in cryptocurrencies, at least in Bitcoin, we assume pseudonymous participants. So it can be really hard to say it's the same agent to qualify its utility. Of course, you could have some linking between system A and system B, like signatures if the same signing scheme is used. However if it's possible why not use direct assets in system B to express a preference ? Maybe in the future if we have a privacy-preserving coins ownership proof system we could use that as one consensus indicator [0] ? At least in terms of community decision-making, the more we have trust-minimized data signals, _assuming_ we have the information capabilities to process them, the better we're. That said, about the covenant working group/process I'm proposing I would like to stay on the use-cases collection, deep trade-offs analysis and adequate covenant designs grounds. Activation really should be its own dedicated process, well-splitted in terms of communication channels, documentation archive and timeframes. About a generic contracting platform approach, I think for sure it would be a huge gain in flexibility for multi-party contract protocols design though there is at least three caveats in my opinion 1) we might open a Pandora Box enabling one to design trustless bribing contracts towards miners to attack existent deployed Bitcoin use-cases like Lightning (not a theoretical concern at all when we look on the wild west of Defi in other cryptocurrencies) 2) the multi-party contract protocol problem space is relatively early, we might evolve the primitive abstraction with which we're dealing and the language itself should evolve 3) we might still have to do a lot of economic engineering if the microcode operations or syntax units of the language are bounding well to validation nodes ressources. So IMHO, a lot of unknowns about a generic contracting platform (even if it's tempting from an application developer viewpoint I know) [0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002884.html [1] For example an input-output bundle abstraction might be better for fee-bumping reasons: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.html Le dim. 24 juil. 2022 à 19:40, ZmnSCPxj a écrit : > Good morning alia, Antoine, and list, > > > Hi Antoine, > > Claiming Taproot history, as best practice or a standard methodology in > bitcoin development, is just too much. Bitcoin development methodology is > an open problem, given the contemporary escalation/emergence of challenges, > history is not entitled to be hard coded as standard. > > > > Schnorr/MAST development history, is a good subject for case study, but > it is not guaranteed that the outcome to be always the same as your take. > > > > I'd suggest instead of inventing a multi-decades-lifecycle based > methodology (which is weird by itself, let alone installing it as a > standard for bitcoin projects), being open-mind enough for examining more > agile approaches and their inevitable effect on the course of discussions, > > A thing I have been mulling is how to prototype such mechanisms more > easily. > > A "reasonably standard" approach was pioneered in Elements Alpha, where an > entire federated sidechain is created and then used as a testbed for new > mechanisms, such as SegWit and `OP_CHECKSIGFROMSTACK`. > However, obviously the cost is fairly large, as you need an entire > federated sidechain. > > It does have the nice advantage that you can use "real" coins, with real > value (subject to the federation being trustworthy, admittedly) in order to > convincingly show a case for real-world use. > > As I pointed out in [Smart Contracts Unchained]( > https://zmnscpxj.github.io/bitcoin/unchained.html), an alternative to > using a blockchain would be to use federated individual coin outpoints. > > A thing I have been pondering is to create a generic contracting platform > with a richer language, which itself is just used to implement a set of > `OP_` SCRIPT opcodes. > This is similar to my [Microcode proposal]( > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020158.html) > earlier this year. > Thus, it would be possible to prototype new `OP_` codes, or change the > behavior of existing `OP_` codes (e.g. `SIGHASH_NOINPUT` would be a change > in behavior of existing `OP_CHECKSIG` and `OP_CHECKMULTISIG`), by having a > translation from `OP_` codes to the richer language. > Then you could prototype a new SCRIPT `OP_` code by providing your own > translation of the new `OP_` code and a SCRIPT that uses that `OP_` code, >
Re: [bitcoin-dev] On a new community process to specify covenants
Hi aliashraf, Well, reading the excerpt you're pointing to, I'm using the term "high standard" and deliberately not best practice. I hope with the increase in the funds at stakes in the ecosystem and the growth in the technical complexity, we'll set higher and higher standards in terms of Bitcoin development. For sure, I think engineering standards are not a thing to be encoded in a history book and we rest as "done". Rather more as a living matter, with the same type of reasoning practiced in common law based on cases or civil engineering based on disasters. About a multi-decades-lifecycle based methodology, not in the domain of consensus changes, but in terms of Core policy, I think I've always advocated for more documentation and communication towards the community [0]. However, it should be noted that any additional engineering process we hold as standard is to be enforced by a set of FOSS contributors, of which the time and energy is limited. So I think it's better to advance in an evolutionary and consensus-driven way, and hopefully avoid regression. That said, if you have concrete examples of good engineering practices we could adopt in Bitcoin development, especially w.r.t consensus changes, I'm curious about it. [0] https://github.com/bitcoin/bitcoin/issues/22806 Le dim. 24 juil. 2022 à 09:01, aliashraf.btc At protonmail < aliashraf@protonmail.com> a écrit : > --- Original Message --- > On Saturday, July 23rd, 2022 at 9:11 PM, Antoine Riard via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > Hi Michael, > > > I'm thinking such a covenant effort would be more a technical process > aiming to advance the state of covenant & contracting knowledge, collect > and document the use-cases, exchange engineering learnings from the > prototype, share the problem space, etc. In the same fashion we have the > BOLT one or even more remote the IETF working groups about a bunch of > Internet technology [0]. I think that Taproot/Schnorr has set a high > standard in terms of safety-first and careful Bitcoin engineering effort, > aggregating 8 years of thinking around MAST and friends but also exploring > other signature schemes like BLS. And I hope with covenants we aim for > higher standards, as if there is one learning from Taproot we could have > spent more time working out use-cases prototypes (e.g joinpools) and > standard libraries to mature, it could have save actual headache around > x-pubkeys [1] > > Hi Antoine, > Claiming Taproot history, as best practice or a standard methodology in > bitcoin development, is just too much. Bitcoin development methodology is > an open problem, given the contemporary escalation/emergence of challenges, > history is not entitled to be hard coded as standard. > > Schnorr/MAST development history, is a good subject for case study, but it > is not guaranteed that the outcome to be always the same as your take. > > I'd suggest instead of inventing a multi-decades-lifecycle based > methodology (which is weird by itself, let alone installing it as a > standard for bitcoin projects), being open-mind enough for examining more > agile approaches and their inevitable effect on the course of discussions, > > Cheers, > > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] On a new community process to specify covenants
Good morning alia, Antoine, and list, > Hi Antoine, > Claiming Taproot history, as best practice or a standard methodology in > bitcoin development, is just too much. Bitcoin development methodology is an > open problem, given the contemporary escalation/emergence of challenges, > history is not entitled to be hard coded as standard. > > Schnorr/MAST development history, is a good subject for case study, but it is > not guaranteed that the outcome to be always the same as your take. > > I'd suggest instead of inventing a multi-decades-lifecycle based methodology > (which is weird by itself, let alone installing it as a standard for bitcoin > projects), being open-mind enough for examining more agile approaches and > their inevitable effect on the course of discussions, A thing I have been mulling is how to prototype such mechanisms more easily. A "reasonably standard" approach was pioneered in Elements Alpha, where an entire federated sidechain is created and then used as a testbed for new mechanisms, such as SegWit and `OP_CHECKSIGFROMSTACK`. However, obviously the cost is fairly large, as you need an entire federated sidechain. It does have the nice advantage that you can use "real" coins, with real value (subject to the federation being trustworthy, admittedly) in order to convincingly show a case for real-world use. As I pointed out in [Smart Contracts Unchained](https://zmnscpxj.github.io/bitcoin/unchained.html), an alternative to using a blockchain would be to use federated individual coin outpoints. A thing I have been pondering is to create a generic contracting platform with a richer language, which itself is just used to implement a set of `OP_` SCRIPT opcodes. This is similar to my [Microcode proposal](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020158.html) earlier this year. Thus, it would be possible to prototype new `OP_` codes, or change the behavior of existing `OP_` codes (e.g. `SIGHASH_NOINPUT` would be a change in behavior of existing `OP_CHECKSIG` and `OP_CHECKMULTISIG`), by having a translation from `OP_` codes to the richer language. Then you could prototype a new SCRIPT `OP_` code by providing your own translation of the new `OP_` code and a SCRIPT that uses that `OP_` code, and using Smart Contract Unchained to use a real funds outpoint. Again, we can compare the Bitcoin consensus layer to a form of hardware: yes, we *could* patch it and change it, but that requires a ***LOT*** of work and the new software has to be redeployed by everyone, so it is, practically speaking, hardware. Microcode helps this by adding a softer layer without compromising the existing hard layer. So... what I have been thinking of is creating some kind of smart contracts unchained platform that allows prototyping new `OP_` codes using a microcode mechanism. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] On a new community process to specify covenants
I suppose it is more about spending from vaults, rather than locking in. A covenant would impose rules for spending tx.e.g. :Don't spend this output unless it is claimed by a tx which 1) Spends it as a whole in the very first output. 2) This output is P2SH with specified script pattern ( a TLC script with redeem options) Both normal and theft spends are enforced to lock the funds for a reasonable amount of time, providing opportunity for neutralizing the theft just in case. This is becoming more complex once the redeem (cold) key is susceptible to theft and should be prevented from being able to reclaim funds when the legitimate spends has time locked the funds. It is done by requiring the redeem path to comply with a similar pattern with modifications e.g. this (redeem) tx fails unless a specific txid is published at least n blocks earlier. This way a cold key only theft won't be able to take advantage because s/he has not access to the specific txid which is generated before and is kept as a 3rd secret, add whatever complexity you wish to. Sent with [Proton Mail](https://proton.me/) secure email. --- Original Message --- On Sunday, July 24th, 2022 at 10:52 PM, Bram Cohen via bitcoin-dev wrote: > On Wed, Jul 20, 2022 at 2:46 PM Antoine Riard via bitcoin-dev > wrote: > >> Indeed this range has grown wild. Without aiming to be exhaustive (I'm >> certainly missing some interesting proposals lost in the abyss of >> bitcointalk.org), we can mention the following use-cases: multi-party >> stateful contracts [11], congestion trees [12], payment pools [13], "eltoo" >> layered commitments [14], programmable vaults [15], multi-events contracts >> [16], blockchain-as-oracle bets [17], spacechains [18], trustless collateral >> lending [19], ... > > The big question you missed is whether capabilities are in scope for a > covenants proposal. In particular, vaults work a lot better when payments to > them are immediately locked up in the vault rather than it having to do a > step to accept them first.___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] On a new community process to specify covenants
On Wed, Jul 20, 2022 at 2:46 PM Antoine Riard via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Indeed this range has grown wild. Without aiming to be exhaustive (I'm > certainly missing some interesting proposals lost in the abyss of > bitcointalk.org), we can mention the following use-cases: multi-party > stateful contracts [11], congestion trees [12], payment pools [13], "eltoo" > layered commitments [14], programmable vaults [15], multi-events contracts > [16], blockchain-as-oracle bets [17], spacechains [18], trustless > collateral lending [19], ... > The big question you missed is whether capabilities are in scope for a covenants proposal. In particular, vaults work a lot better when payments to them are immediately locked up in the vault rather than it having to do a step to accept them first. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] On a new community process to specify covenants
--- Original Message --- On Saturday, July 23rd, 2022 at 9:11 PM, Antoine Riard via bitcoin-dev wrote: > Hi Michael, > > I'm thinking such a covenant effort would be more a technical process aiming > to advance the state of covenant & contracting knowledge, collect and > document the use-cases, exchange engineering learnings from the prototype, > share the problem space, etc. In the same fashion we have the BOLT one or > even more remote the IETF working groups about a bunch of Internet technology > [0]. I think that Taproot/Schnorr has set a high standard in terms of > safety-first and careful Bitcoin engineering effort, aggregating 8 years of > thinking around MAST and friends but also exploring other signature schemes > like BLS. And I hope with covenants we aim for higher standards, as if there > is one learning from Taproot we could have spent more time working out > use-cases prototypes (e.g joinpools) and standard libraries to mature, it > could have save actual headache around x-pubkeys [1] Hi Antoine, Claiming Taproot history, as best practice or a standard methodology in bitcoin development, is just too much. Bitcoin development methodology is an open problem, given the contemporary escalation/emergence of challenges, history is not entitled to be hard coded as standard. Schnorr/MAST development history, is a good subject for case study, but it is not guaranteed that the outcome to be always the same as your take. I'd suggest instead of inventing a multi-decades-lifecycle based methodology (which is weird by itself, let alone installing it as a standard for bitcoin projects), being open-mind enough for examining more agile approaches and their inevitable effect on the course of discussions, Cheers,___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] On a new community process to specify covenants
Hi Michael, > One cautionary word from someone who is probably still feeling the effects of burn out from the activation drama earlier in the year. No process can guarantee community > consensus at the end of it especially if some of those who we consider experts in this area only tentatively participate. The personal attacks and ignoring of views counter >to those who were pushing an activation attempt really should not be repeated. (Especially if this process is seeking to include those who we consider experts in this area > and don't want their participation to be perceived as tacit approval of whatever is attempted next.) I'm thinking such a covenant effort would be more a technical process aiming to advance the state of covenant & contracting knowledge, collect and document the use-cases, exchange engineering learnings from the prototype, share the problem space, etc. In the same fashion we have the BOLT one or even more remote the IETF working groups about a bunch of Internet technology [0]. I think that Taproot/Schnorr has set a high standard in terms of safety-first and careful Bitcoin engineering effort, aggregating 8 years of thinking around MAST and friends but also exploring other signature schemes like BLS. And I hope with covenants we aim for higher standards, as if there is one learning from Taproot we could have spent more time working out use-cases prototypes (e.g joinpools) and standard libraries to mature, it could have save actual headache around x-pubkeys [1] In my perspective, activation is more a matter of release engineering and community communications, and failing to a game-theory situation where miners incentives are computed is more a hint of a social layer failure. When we start to consider the moves and incentives of categories of Bitcoin players (miners, users, exchanges, ...), I would say we failed to keep the community as one and increase the safety risks for everyone's coins. Minding that, and to maximize the participation in such a covenant specification process, similar to the usual Chatham House rules in engineering meetings, I believe it could be good to have a "No Activation - No Timeframe" rule in such a covenant process, and defer any activation discussion to a future process of its own. > As long as this is understood and agreed by participants I can only see positives coming out of this. But please let's not repeat the activation drama from earlier in the year > because a process with a subset of those who we would consider experts in this area come to a view and then try to ram that view down everyone's throats by attempting > activation at the end of it. Maybe this will result in community consensus on covenant proposal(s) going forward but also maybe it won't. Either outcome is fine. At the very > least research will progress and work will be carried out that moves us in a positive direction During the last LN Summit in Oakland, there was chit-chat on how long it would take to get a mature version of Lightning, and the answer from a seasoned FOSS developer was 25 years. Considering the heavy LN problem-space, I think this was a wise take and I believe with covenants we would have to think in that 10/20 years perspective if we aim for a satisfying and complete covenant toolchain. It doesn't mean we are not going to be able to deploy piece by piece, however there is a strong emphasis to be done on the archiving part itself. Some of the process stakeholders might still not be active in their engineering careers when the issues should be weighted for consensus activation and transmission of knowledge across generations of stakeholders is going to be an issue (as we already see it in Bitcoin Core with some critical subsystems). And if there is never community consensus on covenant proposals, that's fine. To me the research would have been interesting in itself and I hope it will be the same for other participants. [0] https://datatracker.ietf.org/wg/ [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020663.html Le sam. 23 juil. 2022 à 15:25, Michael Folkson < michaelfolk...@protonmail.com> a écrit : > Hi Antoine > > This looks great and I can certainly see progress being made in a number > of directions on this. I thought you did a great job with the L2 onchain > support workshops and I'm sure you'll do a great job moving this forward. > > One cautionary word from someone who is probably still feeling the effects > of burn out from the activation drama earlier in the year. No process can > guarantee community consensus at the end of it especially if some of those > who we consider experts in this area only tentatively participate. The > personal attacks and ignoring of views counter to those who were pushing an > activation attempt really should not be repeated. (Especially if this > process is seeking to include those who we consider experts in this area > and don't want their participation to be perceived as tacit approval of >
Re: [bitcoin-dev] On a new community process to specify covenants
Hi Ryan, > Certain human/organizational limitations prevent things being said in > logged channels that sometimes can be shared in person. Sometimes > people break through misunderstandings in person, through either > informal mingling or the use of Chatham House rules. So I would also > advocate restarting the Scaling Bitcoin conferences, twice a year. Just for clarity, I'm proposing online meetings on IRC, not in-person. But yes, logged channels can be really narrow on topics and in person sometimes let people grasp the bigger picture or wider context more easily. In my opinion, to build understanding and sync on a complex topic there is nothing like an old school whiteboard session. That being said, higher-bandwidth communication channels like invite-only events come at the price of openness and context-archiving, which matters a lot in Bitcoin. So I think it's good to have a mix of both. It could be interesting to restart Scaling Bitcoin confs, the scaling landscape has grown wild in the past years (statechains, payment pools, federated chaumian banks, new types of sidechains, etc), though I've not heard about orgas kicking them again. > I perceived a lot of "Oh, well it's also fine to just wait and see > what comes" in the prior discussions. The idea that we should reopen > this discussion presumes that it is better to not wait, because having > even imperfect covenant designs will cause the ecosystem to explore > what use cases to allocate developer interest in (as long as the fees > are not too far off - yeah I'm looking at you, CSFS). Because of > this, I also propose asking some of the more advanced scripting > technologists to reveal what of their work is currently science, what > is engineering, and what is product-oriented with understandable > delivery dates. I think that if more people understood the answers to > these questions then there would be more room for incremental > exploration of the space. For sure, there is a "chicken-and-egg" issue, in the sense that lack of certainty on finding consensus on covenant designs can deter some of the most experienced and knowledgeable developers to invest time in building and maturing use-cases toolchains demonstrating the worthiness of such consensus change. One way to avoid this circular dependency can be to start with a state-of-Bitcoin-art version of the protocol, deploy then once there is economic traffic, propose protocol improvement requiring consensus changes back to the community. This is more or less what Lightning is doing with ANYPREVOUT, now there is like 4,300 BTC locked on the network, it's easier to argue there is economic interest. Though ultimately, I don't believe you will ever solve that dead-end risk of Bitcoin research to attract automatically more developers. It's common to any scientific endeavor, as in the end it's more an "inner taste" and exploration for its own sake that drives long-term research. On the second point, giving clarity on the state of advanced scripting use-cases, effectively I believe it would be an informative task to do for each use-case "champion". Speaking for payments pools, solving the high-interactivity issue is still science [0], a pool design for like 10-100 participants assuming liveliness we might have known engineering solutions [1], yet with still a lot of trade-offs to explore on the core pool tree mechanism, and now the real unknown and hard task might be to say a "product-oriented" with delivery dates. From my LDK experience, counts 3/4 years at best to build and mature any FOSS production-ready Bitcoin codebase though in reality if you have to request other changes in the ecosystem like mempools ones for a L2, you don't know. So for discussion clarity, yes it's good if champions give an honest account of knowns and unknowns of their use-cases. I would have loved all the mempool issues affecting Lightning to have been detected and mitigations development started earlier in the protocol genesis. Thanks for the feedback, keeping track of them. Le sam. 23 juil. 2022 à 06:10, Ryan Grant a écrit : > +1 I'd participate. > > Certain human/organizational limitations prevent things being said in > logged channels that sometimes can be shared in person. Sometimes > people break through misunderstandings in person, through either > informal mingling or the use of Chatham House rules. So I would also > advocate restarting the Scaling Bitcoin conferences, twice a year. > > One request for the agenda: > I perceived a lot of "Oh, well it's also fine to just wait and see > what comes" in the prior discussions. The idea that we should reopen > this discussion presumes that it is better to not wait, because having > even imperfect covenant designs will cause the ecosystem to explore > what use cases to allocate developer interest in (as long as the fees > are not too far off - yeah I'm looking at you, CSFS). Because of > this, I also propose asking some of the more advanced scripting
Re: [bitcoin-dev] On a new community process to specify covenants
Hi Antoine This looks great and I can certainly see progress being made in a number of directions on this. I thought you did a great job with the L2 onchain support workshops and I'm sure you'll do a great job moving this forward. One cautionary word from someone who is probably still feeling the effects of burn out from the activation drama earlier in the year. No process can guarantee community consensus at the end of it especially if some of those who we consider experts in this area only tentatively participate. The personal attacks and ignoring of views counter to those who were pushing an activation attempt really should not be repeated. (Especially if this process is seeking to include those who we consider experts in this area and don't want their participation to be perceived as tacit approval of whatever is attempted next.) As long as this is understood and agreed by participants I can only see positives coming out of this. But please let's not repeat the activation drama from earlier in the year because a process with a subset of those who we would consider experts in this area come to a view and then try to ram that view down everyone's throats by attempting activation at the end of it. Maybe this will result in community consensus on covenant proposal(s) going forward but also maybe it won't. Either outcome is fine. At the very least research will progress and work will be carried out that moves us in a positive direction. Thanks Michael -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Wednesday, July 20th, 2022 at 21:42, Antoine Riard via bitcoin-dev wrote: > Hi, > > Discussions on covenants have been prolific and intense on this mailing list > and within the wider Bitcoin technical circles, I believe however without > succeeding to reach consensus on any new set of contracting primitives > satisfying the requirements of known covenant-enabled use-cases. I think > that's a fact to deplore as covenants would not only offer vast extensions of > the capabilities of Bitcoin as a system, i.e enabling new types of > multi-party contract protocols. But also empowering Bitcoin on its > fundamental value propositions of store of value (e.g by making vaults more > flexible) and payment system (e.g by making realistic channel > factories/payment pools). > > If we retain as a covenant definition, a spending constraint restricting the > transaction to which the spent UTXO can be spent, and enabling to program > contracts/protocols at the transaction-level instead of the script-level, the > list of Script primitives proposed during the last years has grown large : > ANYPREVOUT [0], CHECKSIGFROMSTACK [1], CHECK_TEMPLATE_VERIFY [2], > TAPROOT_LEAF_UPDATE_VERIFY [3], TXHASH [4], PUSHTXDATA [5], CAT [6], EVICT > [7], Grafroot delegation [8], SIGHASH_GROUP [9], MERKLEBRANCHVERIFY [10] and > more than I can't remember. Of course, all the listed primitives are at > different states of formalization, some already fully fleshed-out in BIPs, > other still ideas on whiteboard, yet they all extend the range of workable > multi-party contract protocols. > > Indeed this range has grown wild. Without aiming to be exhaustive (I'm > certainly missing some interesting proposals lost in the abyss of > bitcointalk.org), we can mention the following use-cases: multi-party > stateful contracts [11], congestion trees [12], payment pools [13], "eltoo" > layered commitments [14], programmable vaults [15], multi-events contracts > [16], blockchain-as-oracle bets [17], spacechains [18], trustless collateral > lending [19], ... > > Minding all those facts, I would say the task of technical evaluation of any > covenant proposal sounds at least two fold. There is first reasoning about > the enabled protocols on a range of criterias such as scalability, > efficiency, simplicity, extensibility, robustness, data confidentiality, etc. > Asking questions like what are the interactions between layers, if any ? Or > how robust is the protocol, not just interactivity failure between > participant nodes but in the face of mempools spikes or internet disruption ? > Or if the performance is still acceptable on shared resources like blockspace > or routing tables if everyone is using this protocol ? Or if the protocol > minimizes regulatory attack surface or centralization vectors ? > > Though once this step is achieved, there is still more reasoning work to > evaluate how good a fit is a proposed Script primitive, the > efficiency/simplicity/ease to use trade-offs, but also if there are no > functionality overlap or hard constraints on the use-cases design themselves > or evolvability w.rt future Script extensions or generalization of the opcode > operations. > > Moreover, if you would like your evaluation of a covenant proposal to be
Re: [bitcoin-dev] On a new community process to specify covenants
+1 I'd participate. Certain human/organizational limitations prevent things being said in logged channels that sometimes can be shared in person. Sometimes people break through misunderstandings in person, through either informal mingling or the use of Chatham House rules. So I would also advocate restarting the Scaling Bitcoin conferences, twice a year. One request for the agenda: I perceived a lot of "Oh, well it's also fine to just wait and see what comes" in the prior discussions. The idea that we should reopen this discussion presumes that it is better to not wait, because having even imperfect covenant designs will cause the ecosystem to explore what use cases to allocate developer interest in (as long as the fees are not too far off - yeah I'm looking at you, CSFS). Because of this, I also propose asking some of the more advanced scripting technologists to reveal what of their work is currently science, what is engineering, and what is product-oriented with understandable delivery dates. I think that if more people understood the answers to these questions then there would be more room for incremental exploration of the space. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
