Re: [bitcoin-dev] On a new community process to specify covenants

Re: [bitcoin-dev] On a new community process to specify covenants

[Buck O Perley]

[-- Attachment #1: Type: text/plain, Size: 3429 bytes --]

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&D
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. 

[-- Attachment #2: publickey - buck.perley@protonmail.com - 0xC64EEB00.asc --]
[-- Type: application/pgp-keys, Size: 608 bytes --]

Re: [bitcoin-dev] On a new community process to specify covenants

[Ryan Grant]

On Mon, Sep 12, 2022 at 2:47 AM Buck O Perley via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> 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.

Re: [bitcoin-dev] On a new community process to specify covenants

[Devrandom]

[-- Attachment #1: Type: text/plain, Size: 1458 bytes --]

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
> <bitcoin-dev@lists.linuxfoundation.org> 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.

[-- Attachment #2: Type: text/html, Size: 2046 bytes --]

Re: [bitcoin-dev] On a new community process to specify covenants

[Antoine Riard]

[-- Attachment #1: Type: text/plain, Size: 12870 bytes --]

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&D" 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 softfork should be?") is a sign of weakness in my opinion.
> Definitely a big red flag that we should be concerned with.

I agree with the sentiment, that it would be worthy to have multiple groups
happening at once, in a asynchronous and decentralized fashion, neutral
from centralized companies or cultural mobs. However, on the linearity of
the discussions post-Taproot, from my perspective the reason doesn't have
to be found in any community stakeholder bottlenecking or whatever but
rather in the limited subset of experienced Bitcoin protocol engineers we
have across the ecosystem. From quick mental maths, the number of active
folks with more than 4/5 years of experience and decent practical knowledge
of the critical Bitcoin subsystems to be able to work on consensus upgrades
is likely to be evaluated to two dozens. No more. And they're already the
most busy of the ecosystem: maintaining the critical pieces of code,
catching the bugs during reviews, doing active security research, caring
about the Q&A & release process, sharing back the knowledge towards new
devs...

Of course, everyone of them as the choice to prioritize consensus upgrades
over other tasks, but in the long-term it's likely at the detriment of
outcome valued by the community as a whole (e.g hardening the base-layer
P2P stack against high grade attacks, solving Lightning numerous liquidity
issues, etc).

Real weakness is the fact that as a community we're bleeding too much
seasoned protocol engineers for XYZ reasons.

> * 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.

First and foremost, thanks to everyone dedicating resources (engineering,
financial, operational, legal, ...) towards making Bitcoin stronger. About
bipbounty.org, I would like to observe the neutrality of the
decision-making process in the fund allocation could be better, especially
in terms of high-impact and sensitive subjects like consensus upgrades. It
sounds like the unique team member is also the technical author of the only
bounty displayed so far... Academics, law and medecine have centuries-long
traditions of board or peer-to-peer decision-making structure to allocate
scientific and engineering ressources with minimal guarantees of neutrality.

I think it would be valuable for this effort to structure for the
long-term, it would be great to have more community people dedicating their
own personal time on doing the hard operational and legal work to make
things sustainable. I would say there is definitively a need for more
Bitcoin researchers working on multiple-years scale "moonshots" projects.

> * 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.

Yeah, I think in-person meetups would be very valuable and personally I've
always appreciated the knowledge sharing, priorities setting and
productivity boost of all the Bitcoin engineering meetings I've had the
opportunity to attend. 6 months - 1 year after the start of the regular
online meetings sounds like a good timeline, there is a preliminary step of
folks flooding and exchanging on their expectations, taking the process
habits and doing seminal work.

Best,
Antoine

Le dim. 11 sept. 2022 à 22:47, Buck O Perley via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a écrit :

> 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&D
> 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.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 14274 bytes --]

Re: [bitcoin-dev] On a new community process to specify covenants

[Antoine Riard]

[-- Attachment #1: Type: text/plain, Size: 2343 bytes --]

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
>> <bitcoin-dev@lists.linuxfoundation.org> 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
>

[-- Attachment #2: Type: text/html, Size: 3400 bytes --]

Re: [bitcoin-dev] On a new community process to specify covenants

[Devrandom]

[-- Attachment #1: Type: text/plain, Size: 989 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 1543 bytes --]

Re: [bitcoin-dev] On a new community process to specify covenants

[Antoine Riard]

[-- Attachment #1: Type: text/plain, Size: 13184 bytes --]

Hi all,

Following up my September's mail on the setting of a new decentralized,
open and neutral community process dedicated to covenants R&D, 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&D 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 <antoine.riard@gmail.com> 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 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
> complete, I don't believe you can squeeze the implications with the mempool
> rules and combination with any consistent fee-bumping strategy. To say
> things politely, those areas have been a quagmire of vulnerabilities,
> attacks and defects for second-layers Bitcoin protocols during the last
> years [20].
>
> Considering the abundant problem-space offered by covenants, I believe
> there is a reasonable groundwork to pursue in building the use-cases
> understanding (e.g prototype, pseudo-specification, documentation, ...) and
> building consensus on the framework of criterias on which to evaluate them
> [21]. It might raise a really high bar for any covenant proposal compared
> to previous softforks, however I think it would adequately reflect the
> growth in Bitcoin complexity and funds at stakes during the last years.
>
> Moving towards this outcome, I would like to propose a new covenant open
> specification process, in the same spirit as we have with the BOLTs or
> dlcspecs. We would have regular meetings (biweekly/monthly ?), an open
> agenda where topics of discussion can be pinned in advance and
> documentation artifacts would be built with time driven by consensus (e.g
> 1st phase could be to collect, pseudo-specify and find champion(s) for
> known use-cases ?) and no timeframe. Starting date could be September /
> October / November (later, 2023 ?), giving time for anyone interested in
> such a covenant process to allocate development and contribution bandwidth
> in function of their involvement interest.
>
> Learning from the good but specially from the bad with setting up the L2
> onchain support meetings last year, I think it would be better to keep the
> agenda open, loose and free as much we can in a "burn-the-roadmap" spirit,
> avoiding to create a sense of commitment or perceived signaling in the
> process participants towards any covenant solution. I would guess things to
> be experimental and evolutionary and folks to spend the first meetings
> actually to express what they would like the covenant process to be about
> (and yes that means if you're a domain expert and you find the pace of
> things too slow sometimes, you have to learn to handle your own
> frustration...).
>
> In a "decentralize-everything" fashion, I believe it would be good to have
> rotating meeting chairs and multiple covenant documentation archivists. I'm
> super happy to spend the time and energy bootstrapping well such covenant
> process effort, though as it's Bitcoin learn to decentralize yourself.
>
> I'm really curious what the outcome of such a covenant process would look
> like. We might end up concluding that complex covenants are too unsafe by
> enabling sophisticated MEV-attacks against LN [22]. Or even if there is an
> emergent technical consensus, it doesn't mean there is a real market
> interest for such covenant solutions. That said, I'm not sure if it's
> really a subject of concern when you're reasoning as a scientist/engineer
> and you value technical statements in terms of accuracy, systematic
> relevance and intrinsic interest.
>
> Overall, my motivation to kick-start such a process stays in the fact that
> covenants are required building blocks to enable scalable payments pools
> design like CoinPool. I believe payments pools are a) cool and b) a good
> shot at scaling Bitcoin as a payment system once we have reached
> scalability limits of Lightning, still under the same security model for
> users. However, as a community we might sense it's not the good timing for
> a covenant process. I'm really fine with that outcome as there are still
> holes to patch in LN to keep me busy enough for the coming years.
>
> Zooming out, I believe with any discussion about covenants or other soft
> forks, the hard part isn't about coming up with the best technical solution
> to a set of problems but in the iterative process where all voices are
> listened to reach (or not) consensus on what is actually meant by "best"
> and if the problems are accurate. The real physics of Bitcoin is the
> physics of people. It's a work of patience.
>
> Anyways, eager to collect feedbacks on what the ideal covenant
> specification process looks like. As usual, all opinions and mistakes are
> my own.
>
> Cheers,
> Antoine
>
> [0] https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki
> [1] https://bitcoinops.org/en/topics/op_checksigfromstack/
> [2] https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki
> [3]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019419.html
> [4]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html
> [5] https://github.com/jl2012/bips/blob/vault/bip-0ZZZ.mediawiki
> [6] https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298
> [7]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019926.html
> [8]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015700.html
> [9]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.html
> [10] https://github.com/bitcoin/bips/blob/master/bip-0116.mediawiki
> [11]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019808.html
> [12]
> https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#Congestion_Controlled_Transactions
> [13]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017964.html
> [14]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002448.html
> [15] http://fc17.ifca.ai/bitcoin/papers/bitcoin17-final28.pdf
> [16]
> https://github.com/ariard/talk-slides/blob/master/advanced-contracts.pdf
> [17] https://blog.bitmex.com/taproot-you-betcha/
> [18]
> https://gist.github.com/RubenSomsen/c9f0a92493e06b0e29acced61ca9f49a#spacechains
> [19] https://gist.github.com/RubenSomsen/bf08664b3d174551ab7361ffb835fcef
> [20] https://github.com/jamesob/mempool.work
> [21] https://github.com/bitcoinops/bitcoinops.github.io/pull/806
> [22] https://blog.bitmex.com/txwithhold-smart-contracts/
>

[-- Attachment #2: Type: text/html, Size: 15858 bytes --]

Re: [bitcoin-dev] On a new community process to specify covenants

[Antoine Riard]

[-- Attachment #1: Type: text/plain, Size: 11516 bytes --]

Hi all,

Following up on my July's mail proposing to setup a new community process
dedicated to covenant R&D, 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&D
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 <antoine.riard@gmail.com> 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 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
> complete, I don't believe you can squeeze the implications with the mempool
> rules and combination with any consistent fee-bumping strategy. To say
> things politely, those areas have been a quagmire of vulnerabilities,
> attacks and defects for second-layers Bitcoin protocols during the last
> years [20].
>
> Considering the abundant problem-space offered by covenants, I believe
> there is a reasonable groundwork to pursue in building the use-cases
> understanding (e.g prototype, pseudo-specification, documentation, ...) and
> building consensus on the framework of criterias on which to evaluate them
> [21]. It might raise a really high bar for any covenant proposal compared
> to previous softforks, however I think it would adequately reflect the
> growth in Bitcoin complexity and funds at stakes during the last years.
>
> Moving towards this outcome, I would like to propose a new covenant open
> specification process, in the same spirit as we have with the BOLTs or
> dlcspecs. We would have regular meetings (biweekly/monthly ?), an open
> agenda where topics of discussion can be pinned in advance and
> documentation artifacts would be built with time driven by consensus (e.g
> 1st phase could be to collect, pseudo-specify and find champion(s) for
> known use-cases ?) and no timeframe. Starting date could be September /
> October / November (later, 2023 ?), giving time for anyone interested in
> such a covenant process to allocate development and contribution bandwidth
> in function of their involvement interest.
>
> Learning from the good but specially from the bad with setting up the L2
> onchain support meetings last year, I think it would be better to keep the
> agenda open, loose and free as much we can in a "burn-the-roadmap" spirit,
> avoiding to create a sense of commitment or perceived signaling in the
> process participants towards any covenant solution. I would guess things to
> be experimental and evolutionary and folks to spend the first meetings
> actually to express what they would like the covenant process to be about
> (and yes that means if you're a domain expert and you find the pace of
> things too slow sometimes, you have to learn to handle your own
> frustration...).
>
> In a "decentralize-everything" fashion, I believe it would be good to have
> rotating meeting chairs and multiple covenant documentation archivists. I'm
> super happy to spend the time and energy bootstrapping well such covenant
> process effort, though as it's Bitcoin learn to decentralize yourself.
>
> I'm really curious what the outcome of such a covenant process would look
> like. We might end up concluding that complex covenants are too unsafe by
> enabling sophisticated MEV-attacks against LN [22]. Or even if there is an
> emergent technical consensus, it doesn't mean there is a real market
> interest for such covenant solutions. That said, I'm not sure if it's
> really a subject of concern when you're reasoning as a scientist/engineer
> and you value technical statements in terms of accuracy, systematic
> relevance and intrinsic interest.
>
> Overall, my motivation to kick-start such a process stays in the fact that
> covenants are required building blocks to enable scalable payments pools
> design like CoinPool. I believe payments pools are a) cool and b) a good
> shot at scaling Bitcoin as a payment system once we have reached
> scalability limits of Lightning, still under the same security model for
> users. However, as a community we might sense it's not the good timing for
> a covenant process. I'm really fine with that outcome as there are still
> holes to patch in LN to keep me busy enough for the coming years.
>
> Zooming out, I believe with any discussion about covenants or other soft
> forks, the hard part isn't about coming up with the best technical solution
> to a set of problems but in the iterative process where all voices are
> listened to reach (or not) consensus on what is actually meant by "best"
> and if the problems are accurate. The real physics of Bitcoin is the
> physics of people. It's a work of patience.
>
> Anyways, eager to collect feedbacks on what the ideal covenant
> specification process looks like. As usual, all opinions and mistakes are
> my own.
>
> Cheers,
> Antoine
>
> [0] https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki
> [1] https://bitcoinops.org/en/topics/op_checksigfromstack/
> [2] https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki
> [3]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019419.html
> [4]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html
> [5] https://github.com/jl2012/bips/blob/vault/bip-0ZZZ.mediawiki
> [6] https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298
> [7]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019926.html
> [8]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015700.html
> [9]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.html
> [10] https://github.com/bitcoin/bips/blob/master/bip-0116.mediawiki
> [11]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019808.html
> [12]
> https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#Congestion_Controlled_Transactions
> [13]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017964.html
> [14]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002448.html
> [15] http://fc17.ifca.ai/bitcoin/papers/bitcoin17-final28.pdf
> [16]
> https://github.com/ariard/talk-slides/blob/master/advanced-contracts.pdf
> [17] https://blog.bitmex.com/taproot-you-betcha/
> [18]
> https://gist.github.com/RubenSomsen/c9f0a92493e06b0e29acced61ca9f49a#spacechains
> [19] https://gist.github.com/RubenSomsen/bf08664b3d174551ab7361ffb835fcef
> [20] https://github.com/jamesob/mempool.work
> [21] https://github.com/bitcoinops/bitcoinops.github.io/pull/806
> [22] https://blog.bitmex.com/txwithhold-smart-contracts/
>

[-- Attachment #2: Type: text/html, Size: 14270 bytes --]

Re: [bitcoin-dev] On a new community process to specify covenants

[Antoine Riard]

[-- Attachment #1: Type: text/plain, Size: 16445 bytes --]

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&D
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 <billy.tetrud@gmail.com> 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 <antoine.riard@gmail.com>
> 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
>> 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
>> 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.
>>
>> Yeah, again I don't see meetings as bounded in time rather happening
>> regularly as we have with LN ones. I guess it's going to take at least a
>> good year for working group participants to take habits and familiarity
>> with the problem space and reach consensus on the process itself. Further,
>> 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, and that can evaluate quickly in
>> function of new findings or issues arising. I think it's more interesting
>> to seek a lack of consensus in the sense of opposite opinions or blocking
>> arguments. I wouldn't disqualify thumbs up or thumbs down per se, there are
>> marks of interest in a specific proposal, though I lean to agree that I
>> find more interesting too laid-out evaluations and thought processes.
>>
>> > 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).
>>
>> For sure, in the function of new feedback arising it's good to constantly
>> reevaluate proposals. Hopefully, I think any looping should make proposals
>> more formalized and accurate. We might also have the "easy" covenants
>> moving faster than the "hard" ones across the phases. I believe the
>> covenant problem space might be solved in an evolutionary way, layer by
>> layer akin to how LN moves forward.
>>
>> Le mer. 3 août 2022 à 11:37, Billy Tetrud <billy.tetrud@gmail.com> a
>> écrit :
>>
>>> @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 <antoine.riard@gmail.com>
>>>> 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
>>>>
>>>

[-- Attachment #2: Type: text/html, Size: 18957 bytes --]

Re: [bitcoin-dev] On a new community process to specify covenants

[Billy Tetrud]

[-- Attachment #1: Type: text/plain, Size: 14452 bytes --]

>  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 <antoine.riard@gmail.com>
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
> 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
> 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.
>
> Yeah, again I don't see meetings as bounded in time rather happening
> regularly as we have with LN ones. I guess it's going to take at least a
> good year for working group participants to take habits and familiarity
> with the problem space and reach consensus on the process itself. Further,
> 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, and that can evaluate quickly in
> function of new findings or issues arising. I think it's more interesting
> to seek a lack of consensus in the sense of opposite opinions or blocking
> arguments. I wouldn't disqualify thumbs up or thumbs down per se, there are
> marks of interest in a specific proposal, though I lean to agree that I
> find more interesting too laid-out evaluations and thought processes.
>
> > 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).
>
> For sure, in the function of new feedback arising it's good to constantly
> reevaluate proposals. Hopefully, I think any looping should make proposals
> more formalized and accurate. We might also have the "easy" covenants
> moving faster than the "hard" ones across the phases. I believe the
> covenant problem space might be solved in an evolutionary way, layer by
> layer akin to how LN moves forward.
>
> Le mer. 3 août 2022 à 11:37, Billy Tetrud <billy.tetrud@gmail.com> a
> écrit :
>
>> @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 <antoine.riard@gmail.com>
>>> 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
>>>
>>

[-- Attachment #2: Type: text/html, Size: 16500 bytes --]

Re: [bitcoin-dev] On a new community process to specify covenants

[Antoine Riard]

[-- Attachment #1: Type: text/plain, Size: 12794 bytes --]

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
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.

Yeah, again I don't see meetings as bounded in time rather happening
regularly as we have with LN ones. I guess it's going to take at least a
good year for working group participants to take habits and familiarity
with the problem space and reach consensus on the process itself. Further,
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, and that can evaluate quickly in
function of new findings or issues arising. I think it's more interesting
to seek a lack of consensus in the sense of opposite opinions or blocking
arguments. I wouldn't disqualify thumbs up or thumbs down per se, there are
marks of interest in a specific proposal, though I lean to agree that I
find more interesting too laid-out evaluations and thought processes.

> 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).

For sure, in the function of new feedback arising it's good to constantly
reevaluate proposals. Hopefully, I think any looping should make proposals
more formalized and accurate. We might also have the "easy" covenants
moving faster than the "hard" ones across the phases. I believe the
covenant problem space might be solved in an evolutionary way, layer by
layer akin to how LN moves forward.

Le mer. 3 août 2022 à 11:37, Billy Tetrud <billy.tetrud@gmail.com> a écrit :

> @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 <antoine.riard@gmail.com>
>> 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
>>
>

[-- Attachment #2: Type: text/html, Size: 14742 bytes --]

Re: [bitcoin-dev] On a new community process to specify covenants

[Billy Tetrud]

[-- Attachment #1: Type: text/plain, Size: 4829 bytes --]

@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 <antoine.riard@gmail.com>
> 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
>

[-- Attachment #2: Type: text/html, Size: 6298 bytes --]

Re: [bitcoin-dev] On a new community process to specify covenants

[Bram Cohen]

[-- Attachment #1: Type: text/plain, Size: 549 bytes --]

On Mon, Jul 25, 2022 at 8:21 PM Antoine Riard <antoine.riard@gmail.com>
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)

[-- Attachment #2: Type: text/html, Size: 1263 bytes --]

Re: [bitcoin-dev] On a new community process to specify covenants

[Antoine Riard]

[-- Attachment #1: Type: text/plain, Size: 1296 bytes --]

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 <bram@chia.net> 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.
>

[-- Attachment #2: Type: text/html, Size: 1925 bytes --]

Re: [bitcoin-dev] On a new community process to specify covenants

[Antoine Riard]

[-- Attachment #1: Type: text/plain, Size: 5754 bytes --]

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 <ZmnSCPxj@protonmail.com> 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,
> 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
>

[-- Attachment #2: Type: text/html, Size: 6511 bytes --]

Re: [bitcoin-dev] On a new community process to specify covenants

[Antoine Riard]

[-- Attachment #1: Type: text/plain, Size: 3308 bytes --]

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.btc@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,
>
>
>

[-- Attachment #2: Type: text/html, Size: 4447 bytes --]

Re: [bitcoin-dev] On a new community process to specify covenants

[ZmnSCPxj]

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

Re: [bitcoin-dev] On a new community process to specify covenants

[aliashraf.btc At protonmail]

[-- Attachment #1: Type: text/plain, Size: 2088 bytes --]

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 <bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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.

[-- Attachment #2: Type: text/html, Size: 3285 bytes --]

Re: [bitcoin-dev] On a new community process to specify covenants

[Bram Cohen]

[-- Attachment #1: Type: text/plain, Size: 830 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 1204 bytes --]

Re: [bitcoin-dev] On a new community process to specify covenants

[aliashraf.btc At protonmail]

[-- Attachment #1: Type: text/plain, Size: 1768 bytes --]

------- 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,

[-- Attachment #2: Type: text/html, Size: 2627 bytes --]

Re: [bitcoin-dev] On a new community process to specify covenants

[Antoine Riard]

[-- Attachment #1: Type: text/plain, Size: 15505 bytes --]

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 <
michaelfolkson@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
> 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
> 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 <
> bitcoin-dev@lists.linuxfoundation.org> 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
> complete, I don't believe you can squeeze the implications with the mempool
> rules and combination with any consistent fee-bumping strategy. To say
> things politely, those areas have been a quagmire of vulnerabilities,
> attacks and defects for second-layers Bitcoin protocols during the last
> years [20].
>
> Considering the abundant problem-space offered by covenants, I believe
> there is a reasonable groundwork to pursue in building the use-cases
> understanding (e.g prototype, pseudo-specification, documentation, ...) and
> building consensus on the framework of criterias on which to evaluate them
> [21]. It might raise a really high bar for any covenant proposal compared
> to previous softforks, however I think it would adequately reflect the
> growth in Bitcoin complexity and funds at stakes during the last years.
>
> Moving towards this outcome, I would like to propose a new covenant open
> specification process, in the same spirit as we have with the BOLTs or
> dlcspecs. We would have regular meetings (biweekly/monthly ?), an open
> agenda where topics of discussion can be pinned in advance and
> documentation artifacts would be built with time driven by consensus (e.g
> 1st phase could be to collect, pseudo-specify and find champion(s) for
> known use-cases ?) and no timeframe. Starting date could be September /
> October / November (later, 2023 ?), giving time for anyone interested in
> such a covenant process to allocate development and contribution bandwidth
> in function of their involvement interest.
>
> Learning from the good but specially from the bad with setting up the L2
> onchain support meetings last year, I think it would be better to keep the
> agenda open, loose and free as much we can in a "burn-the-roadmap" spirit,
> avoiding to create a sense of commitment or perceived signaling in the
> process participants towards any covenant solution. I would guess things to
> be experimental and evolutionary and folks to spend the first meetings
> actually to express what they would like the covenant process to be about
> (and yes that means if you're a domain expert and you find the pace of
> things too slow sometimes, you have to learn to handle your own
> frustration...).
>
> In a "decentralize-everything" fashion, I believe it would be good to have
> rotating meeting chairs and multiple covenant documentation archivists. I'm
> super happy to spend the time and energy bootstrapping well such covenant
> process effort, though as it's Bitcoin learn to decentralize yourself.
>
> I'm really curious what the outcome of such a covenant process would look
> like. We might end up concluding that complex covenants are too unsafe by
> enabling sophisticated MEV-attacks against LN [22]. Or even if there is an
> emergent technical consensus, it doesn't mean there is a real market
> interest for such covenant solutions. That said, I'm not sure if it's
> really a subject of concern when you're reasoning as a scientist/engineer
> and you value technical statements in terms of accuracy, systematic
> relevance and intrinsic interest.
>
> Overall, my motivation to kick-start such a process stays in the fact that
> covenants are required building blocks to enable scalable payments pools
> design like CoinPool. I believe payments pools are a) cool and b) a good
> shot at scaling Bitcoin as a payment system once we have reached
> scalability limits of Lightning, still under the same security model for
> users. However, as a community we might sense it's not the good timing for
> a covenant process. I'm really fine with that outcome as there are still
> holes to patch in LN to keep me busy enough for the coming years.
>
> Zooming out, I believe with any discussion about covenants or other soft
> forks, the hard part isn't about coming up with the best technical solution
> to a set of problems but in the iterative process where all voices are
> listened to reach (or not) consensus on what is actually meant by "best"
> and if the problems are accurate. The real physics of Bitcoin is the
> physics of people. It's a work of patience.
>
> Anyways, eager to collect feedbacks on what the ideal covenant
> specification process looks like. As usual, all opinions and mistakes are
> my own.
>
> Cheers,
> Antoine
>
> [0] https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki
> [1] https://bitcoinops.org/en/topics/op_checksigfromstack/
> [2] https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki
> [3]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019419.html
> [4]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html
> [5] https://github.com/jl2012/bips/blob/vault/bip-0ZZZ.mediawiki
> [6] https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298
> [7]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019926.html
> [8]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015700.html
> [9]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.html
> [10] https://github.com/bitcoin/bips/blob/master/bip-0116.mediawiki
> [11]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019808.html
> [12]
> https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#Congestion_Controlled_Transactions
> [13]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017964.html
> [14]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002448.html
> [15] http://fc17.ifca.ai/bitcoin/papers/bitcoin17-final28.pdf
> [16]
> https://github.com/ariard/talk-slides/blob/master/advanced-contracts.pdf
> [17] https://blog.bitmex.com/taproot-you-betcha/
> [18]
> https://gist.github.com/RubenSomsen/c9f0a92493e06b0e29acced61ca9f49a#spacechains
> [19] https://gist.github.com/RubenSomsen/bf08664b3d174551ab7361ffb835fcef
> [20] https://github.com/jamesob/mempool.work
> [21] https://github.com/bitcoinops/bitcoinops.github.io/pull/806
> [22] https://blog.bitmex.com/txwithhold-smart-contracts/
>
>
>

[-- Attachment #2: Type: text/html, Size: 22167 bytes --]

Re: [bitcoin-dev] On a new community process to specify covenants

[Antoine Riard]

[-- Attachment #1: Type: text/plain, Size: 5425 bytes --]

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 <bitcoin-dev@rgrant.org> 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
> 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.
>

[-- Attachment #2: Type: text/html, Size: 6150 bytes --]

Re: [bitcoin-dev] On a new community process to specify covenants

[Michael Folkson]

[-- Attachment #1: Type: text/plain, Size: 10826 bytes --]

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 <bitcoin-dev@lists.linuxfoundation.org> 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 complete, I don't believe you can squeeze the implications with the mempool rules and combination with any consistent fee-bumping strategy. To say things politely, those areas have been a quagmire of vulnerabilities, attacks and defects for second-layers Bitcoin protocols during the last years [20].
>
> Considering the abundant problem-space offered by covenants, I believe there is a reasonable groundwork to pursue in building the use-cases understanding (e.g prototype, pseudo-specification, documentation, ...) and building consensus on the framework of criterias on which to evaluate them [21]. It might raise a really high bar for any covenant proposal compared to previous softforks, however I think it would adequately reflect the growth in Bitcoin complexity and funds at stakes during the last years.
>
> Moving towards this outcome, I would like to propose a new covenant open specification process, in the same spirit as we have with the BOLTs or dlcspecs. We would have regular meetings (biweekly/monthly ?), an open agenda where topics of discussion can be pinned in advance and documentation artifacts would be built with time driven by consensus (e.g 1st phase could be to collect, pseudo-specify and find champion(s) for known use-cases ?) and no timeframe. Starting date could be September / October / November (later, 2023 ?), giving time for anyone interested in such a covenant process to allocate development and contribution bandwidth in function of their involvement interest.
>
> Learning from the good but specially from the bad with setting up the L2 onchain support meetings last year, I think it would be better to keep the agenda open, loose and free as much we can in a "burn-the-roadmap" spirit, avoiding to create a sense of commitment or perceived signaling in the process participants towards any covenant solution. I would guess things to be experimental and evolutionary and folks to spend the first meetings actually to express what they would like the covenant process to be about (and yes that means if you're a domain expert and you find the pace of things too slow sometimes, you have to learn to handle your own frustration...).
>
> In a "decentralize-everything" fashion, I believe it would be good to have rotating meeting chairs and multiple covenant documentation archivists. I'm super happy to spend the time and energy bootstrapping well such covenant process effort, though as it's Bitcoin learn to decentralize yourself.
>
> I'm really curious what the outcome of such a covenant process would look like. We might end up concluding that complex covenants are too unsafe by enabling sophisticated MEV-attacks against LN [22]. Or even if there is an emergent technical consensus, it doesn't mean there is a real market interest for such covenant solutions. That said, I'm not sure if it's really a subject of concern when you're reasoning as a scientist/engineer and you value technical statements in terms of accuracy, systematic relevance and intrinsic interest.
>
> Overall, my motivation to kick-start such a process stays in the fact that covenants are required building blocks to enable scalable payments pools design like CoinPool. I believe payments pools are a) cool and b) a good shot at scaling Bitcoin as a payment system once we have reached scalability limits of Lightning, still under the same security model for users. However, as a community we might sense it's not the good timing for a covenant process. I'm really fine with that outcome as there are still holes to patch in LN to keep me busy enough for the coming years.
>
> Zooming out, I believe with any discussion about covenants or other soft forks, the hard part isn't about coming up with the best technical solution to a set of problems but in the iterative process where all voices are listened to reach (or not) consensus on what is actually meant by "best" and if the problems are accurate. The real physics of Bitcoin is the physics of people. It's a work of patience.
>
> Anyways, eager to collect feedbacks on what the ideal covenant specification process looks like. As usual, all opinions and mistakes are my own.
>
> Cheers,
> Antoine
>
> [0] https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki
> [1] https://bitcoinops.org/en/topics/op_checksigfromstack/
> [2] https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki
> [3] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019419.html
> [4] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html
> [5] https://github.com/jl2012/bips/blob/vault/bip-0ZZZ.mediawiki
> [6] https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298
> [7] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019926.html
> [8] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015700.html
> [9] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.html
> [10] https://github.com/bitcoin/bips/blob/master/bip-0116.mediawiki
> [11] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019808.html
> [12] https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#Congestion_Controlled_Transactions
> [13] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017964.html
> [14] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002448.html
> [15] http://fc17.ifca.ai/bitcoin/papers/bitcoin17-final28.pdf
> [16] https://github.com/ariard/talk-slides/blob/master/advanced-contracts.pdf
> [17] https://blog.bitmex.com/taproot-you-betcha/
> [18] https://gist.github.com/RubenSomsen/c9f0a92493e06b0e29acced61ca9f49a#spacechains
> [19] https://gist.github.com/RubenSomsen/bf08664b3d174551ab7361ffb835fcef
> [20] https://github.com/jamesob/mempool.work
> [21] https://github.com/bitcoinops/bitcoinops.github.io/pull/806
> [22] https://blog.bitmex.com/txwithhold-smart-contracts/

[-- Attachment #2: Type: text/html, Size: 16935 bytes --]

Re: [bitcoin-dev] On a new community process to specify covenants

[Ryan Grant]

+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] On a new community process to specify covenants

[Antoine Riard]

[-- Attachment #1: Type: text/plain, Size: 8936 bytes --]

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
complete, I don't believe you can squeeze the implications with the mempool
rules and combination with any consistent fee-bumping strategy. To say
things politely, those areas have been a quagmire of vulnerabilities,
attacks and defects for second-layers Bitcoin protocols during the last
years [20].

Considering the abundant problem-space offered by covenants, I believe
there is a reasonable groundwork to pursue in building the use-cases
understanding (e.g prototype, pseudo-specification, documentation, ...) and
building consensus on the framework of criterias on which to evaluate them
[21]. It might raise a really high bar for any covenant proposal compared
to previous softforks, however I think it would adequately reflect the
growth in Bitcoin complexity and funds at stakes during the last years.

Moving towards this outcome, I would like to propose a new covenant open
specification process, in the same spirit as we have with the BOLTs or
dlcspecs. We would have regular meetings (biweekly/monthly ?), an open
agenda where topics of discussion can be pinned in advance and
documentation artifacts would be built with time driven by consensus (e.g
1st phase could be to collect, pseudo-specify and find champion(s) for
known use-cases ?) and no timeframe. Starting date could be September /
October / November (later, 2023 ?), giving time for anyone interested in
such a covenant process to allocate development and contribution bandwidth
in function of their involvement interest.

Learning from the good but specially from the bad with setting up the L2
onchain support meetings last year, I think it would be better to keep the
agenda open, loose and free as much we can in a "burn-the-roadmap" spirit,
avoiding to create a sense of commitment or perceived signaling in the
process participants towards any covenant solution. I would guess things to
be experimental and evolutionary and folks to spend the first meetings
actually to express what they would like the covenant process to be about
(and yes that means if you're a domain expert and you find the pace of
things too slow sometimes, you have to learn to handle your own
frustration...).

In a "decentralize-everything" fashion, I believe it would be good to have
rotating meeting chairs and multiple covenant documentation archivists. I'm
super happy to spend the time and energy bootstrapping well such covenant
process effort, though as it's Bitcoin learn to decentralize yourself.

I'm really curious what the outcome of such a covenant process would look
like. We might end up concluding that complex covenants are too unsafe by
enabling sophisticated MEV-attacks against LN [22]. Or even if there is an
emergent technical consensus, it doesn't mean there is a real market
interest for such covenant solutions. That said, I'm not sure if it's
really a subject of concern when you're reasoning as a scientist/engineer
and you value technical statements in terms of accuracy, systematic
relevance and intrinsic interest.

Overall, my motivation to kick-start such a process stays in the fact that
covenants are required building blocks to enable scalable payments pools
design like CoinPool. I believe payments pools are a) cool and b) a good
shot at scaling Bitcoin as a payment system once we have reached
scalability limits of Lightning, still under the same security model for
users. However, as a community we might sense it's not the good timing for
a covenant process. I'm really fine with that outcome as there are still
holes to patch in LN to keep me busy enough for the coming years.

Zooming out, I believe with any discussion about covenants or other soft
forks, the hard part isn't about coming up with the best technical solution
to a set of problems but in the iterative process where all voices are
listened to reach (or not) consensus on what is actually meant by "best"
and if the problems are accurate. The real physics of Bitcoin is the
physics of people. It's a work of patience.

Anyways, eager to collect feedbacks on what the ideal covenant
specification process looks like. As usual, all opinions and mistakes are
my own.

Cheers,
Antoine

[0] https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki
[1] https://bitcoinops.org/en/topics/op_checksigfromstack/
[2] https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki
[3]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019419.html
[4]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html
[5] https://github.com/jl2012/bips/blob/vault/bip-0ZZZ.mediawiki
[6] https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298
[7]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019926.html
[8]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015700.html
[9]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.html
[10] https://github.com/bitcoin/bips/blob/master/bip-0116.mediawiki
[11]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019808.html
[12]
https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#Congestion_Controlled_Transactions
[13]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017964.html
[14]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002448.html
[15] http://fc17.ifca.ai/bitcoin/papers/bitcoin17-final28.pdf
[16]
https://github.com/ariard/talk-slides/blob/master/advanced-contracts.pdf
[17] https://blog.bitmex.com/taproot-you-betcha/
[18]
https://gist.github.com/RubenSomsen/c9f0a92493e06b0e29acced61ca9f49a#spacechains
[19] https://gist.github.com/RubenSomsen/bf08664b3d174551ab7361ffb835fcef
[20] https://github.com/jamesob/mempool.work
[21] https://github.com/bitcoinops/bitcoinops.github.io/pull/806
[22] https://blog.bitmex.com/txwithhold-smart-contracts/

[-- Attachment #2: Type: text/html, Size: 11189 bytes --]