Covenants Support - Bitcoin Wiki

[/dev /fd0]

Hi Bitcoin Developers,

I have created the first draft of a bitcoin wiki page to update opinions of bitcoin developers on different covenant proposals. It uses the same template as segwit support page. Feel free to add more opcodes as I only added the ones that looked relevant.

Wiki link: https://en.bitcoin.it/wiki/Covenants_support

I am aware of the opinions of some developers; however, I did not want to write on their behalf. Please add your GitHub username and share your opinions on the proposed opcodes. This would help in reaching a consensus on the next soft fork and make things easier.

Rationale for supporting OP_CTV: https://notes.dunst.be/slide/#/2/slide/view/Ekky-cAegV9dSOaNOjH9TStNOmAnrhDDc9hxHlmRs5M/embed/present/

I like a few other use cases however mainly interested in pools with covenants. This would help improve joinstr (coinjoin implementation).

/dev/fd0

floppy disk guy

[Jonas Nick]

Hi /dev/fd0,

I do not think the segwit support page serves as a suitable template for
building rough consensus, in general and for covenants in particular. It lacks
key characteristics that would help in (rough) consensus building as outlined in
RFC 7282 [0] (which I strongly recommend reading).

I propose the following changes:

1. Separate Technical Evaluation from Community Support

The ratings "Deficient" and "Wanting" are supposed to be assigned when a
proposal considered to have insufficient community support. This creates a
circular problem: the wiki page is meant to help build community support, but
the ratings already assume certain levels of support. This makes the ratings
less useful and risks creating self-fulfilling prophecies.

A simple solution would be to remove the "Wanting" and "Deficient"
categories.

2. Require Stating Reasons for Objections

As RFC 7282 states:

> Remember, coming to consensus is a matter of eliminating disagreement.

To achieve this, we need to clearly state objections to enable a meaningful
discussion. Each "No" rating should include a link to a mailing list post or
similar document that explicitly states the objection, covering aspects such
as technical deficiencies, likelihood of widespread adoption, and impact on
decentralization.

> Then, the purported failings
> of the choice can be examined by the working group. The objector
> might convince the rest of the group that the objections are valid
> and the working group might choose a different path. Conversely, the
> working group might convince the objector that the concerns can be
> addressed, or that the choice is simply unappealing (i.e., something
> the objector can "live with") and not a show-stopper.

Because there is no working group making decisions in Bitcoin,
community members must individually assess whether proposals have achieved
rough developer consensus.

Developers giving positive technical evaluations are also encouraged to share
their reasoning, as this can help inform others' assessments.

3. Add Links to BIP Drafts

All opcodes mentioned on the wiki page presumably have corresponding draft
BIPs. These should be linked to provide a clear basis for technical
evaluation.

[0] https://datatracker.ietf.org/doc/html/rfc7282

[/dev /fd0]

Hi Jonas,

Thank you for reviewing the wiki page.

> 1. Separate Technical Evaluation from Community Support

> A simple solution would be to remove the "Wanting" and "Deficient"
categories.

There are 7 options available to share opinion on an opcode and only 2 include community support. If a developer wants to ACK a proposal it is possible to use to 'prefer' or 'acceptable' and 'no' for NACK. 

We have already changed definition for 3 categories. I removed community support from 'no' and moonsettler rephrased 'prefer' and 'evaluating'. Removing some categories at this point breaks the whole table. 

At the end of the day bitcoin developers build for community so if someone wants to play safe and use 'deficient' and 'wanting', its their choice and I think we should allow such freedom to express themselves. 

>  2. Require Stating Reasons for Objections

A column for adding a link to rationale will be added this weekend. I had tweeted about it but forgot to update the mailing list thread.

>  Because there is no working group making decisions in Bitcoin,
> community members must individually assess whether proposals have achieved
> rough developer consensus.

>  Developers giving positive technical evaluations are also encouraged to share
> their reasoning, as this can help inform others' assessments.

I agree with you on this and I have requested everyone to respond to this thread.

>  3. Add Links to BIP Drafts

I have added the links to BIP drafts for all opcodes.

/dev/fd0

floppy disk guy

[Yuval Kogman]

On Sat, 7 Dec 2024 at 02:10, /dev /fd0 <alice...@gmail.com> wrote:
>
> There are 7 options available to share opinion on an opcode and only 2 include community support. If a developer wants to ACK a proposal it is possible to use to 'prefer' or 'acceptable' and 'no' for NACK.

the 6 options (+ "evaluating", which is not in the space) represent
only a subset of the product of two independent dimensions:

- a given dev's (hopefully reasoned) opinion on the technical merit of
a proposal
- and their (speculative, vibes based) opinion about community support.

> At the end of the day bitcoin developers build for community so if someone wants to play safe and use 'deficient' and 'wanting', its their choice and I think we should allow such freedom to express themselves.

to allow that full freedom to express themselves 8 options seem
necessary, not counting "evaluating":

{ no, weak, acceptable, prefer } x { sufficient community support,
insufficient }

(or alternatively, { no, weak, acceptable } is the technical merit
dimension, and then "prefer" seems redundant?)

anyway, supposing all pairs of values were expressible, the latter is
confounded or arguably even ill defined see
https://en.wikipedia.org/wiki/Keynesian_beauty_contest (and this is
exacerbated by the fact that the two values are combined into a single
dimension, e.g. if i strongly prefer something but it lacks community
support), so to allow people to e.g. only express a technical opinion,
and abstain from speculating on community support, we'd want:

{ ⊥, weak, acceptable, prefer } x { ⊥, sufficient, insufficient }

(where evaluating = (⊥, ⊥))

finally, even if the full set of possibilities was expressible, and
assuming the infinite regress of speculating on others' opinions about
others opinions was not an issue, it would still not be totally
orderable, so the color scheme is arguably misleading

both the partial ordering and the speculative nature add a lot of
ambiguity, i.e. different answers are likely to mean different things
to different respondents and to people reading the table

[Anthony Towns]

On Fri, Dec 06, 2024 at 09:45:31PM +0000, Jonas Nick wrote:
> I do not think the segwit support page serves as a suitable template for
> building rough consensus, in general and for covenants in particular.

The segwit page followed the example of the p2sh page [0]; I wasn't around
for that, but from the reporting it didn't sound like a particularly
clean result, with the result coming down to the proposers of BIP 16/17
respectively voting "No" and "Very weak" to the competition, and "No"
being worse than "Very weak". It's not a good example to follow.

[0] https://en.bitcoin.it/wiki/P2SH_Votes

The only polling question that's really necessary for establishing
that consensus exists is "have all my objections/concerns been
addressed? [yes/no]" (perhaps with a followup asking your top outstanding
concerns are). If the poll is widely open, and everyone's answer is
"yes"; that's consensus. (Even if some people's answers are "no"; it
might still be "rough" consensus, of course)

Personally, I find it hard to take any of this remotely seriously at this
point; the most recent example is reardencode's claim to have created
scripts for lightning-symmetry using either LNHANCE or CCV. This was
done via a tweet [1] and a gist [2], without any real exploration of
what the full transaction flow would look like. Did it have any chance of
working? Well, no, because it had an invented "3DROP" opcode instead of
"DROP 2DROP" or similar, just as if it were ChatGPT hallucinating what
a wallet script might look like. That would have failed as soon as it
had been run through any of the script test environments out there,
let alone through any actual node software, so it's clear that nobody
involved had done anything of the sort, even locally. If the proponents
aren't taking their proposals seriously, why on earth should anyone else?

[1] https://x.com/reardencode/status/1864749512113483993
[2] https://gist.github.com/reardencode/ae982ede45af12fe1ff7248fd6f1958c#file-ctv-csfs-vault-txt

Cheers,
aj

[Brandon Black]

Hi AJ,

On 2024-12-10 (Tue) at 06:13:50 +1000, Anthony Towns wrote:
> Personally, I find it hard to take any of this remotely seriously at this
> point; the most recent example is reardencode's claim to have created
> scripts for lightning-symmetry using either LNHANCE or CCV. This was
> done via a tweet [1] and a gist [2], without any real exploration of
> what the full transaction flow would look like. Did it have any chance of
> working? Well, no, because it had an invented "3DROP" opcode instead of
> "DROP 2DROP" or similar, just as if it were ChatGPT hallucinating what
> a wallet script might look like. That would have failed as soon as it
> had been run through any of the script test environments out there,
> let alone through any actual node software, so it's clear that nobody
> involved had done anything of the sort, even locally. If the proponents
> aren't taking their proposals seriously, why on earth should anyone else?
>
> [1] https://x.com/reardencode/status/1864749512113483993
> [2] https://gist.github.com/reardencode/ae982ede45af12fe1ff7248fd6f1958c#file-ctv-csfs-vault-txt

You've made two strange errors in your commentary here.

First, my example scripts for Lightning Symmetry all use opcodes that do
not exist in the script testing environments so I cannot run my scripts
through those environments. The point of the exercise is to demonstrate
how the potential opcodes can perform an example protocol and roughly
how the cost compares. The fact that I misglanced the opcode list
during drafting is completely irrelevant to the exercise.

Second, I am not a "proponent" of VAULT or CCV. I'm merely demonstrating
various ways that they can be used, as a service to those who are
discussing various options for upgrading bitcoin (as I strongly implied
in my post on X - I only wrote the script you found an error in because
of others' answers on Floppy's table).

In other words, it's hard to take your commentary seriously when you
don't bother to understand either the purpose and the context of what
you are commenting on.

Hope this clarifies.

All the best,

--Brandon

[Anthony Towns]

On Mon, Dec 09, 2024 at 12:45:35PM -0800, Brandon Black wrote:
> First, my example scripts for Lightning Symmetry all use opcodes that do
> not exist in the script testing environments so I cannot run my scripts
> through those environments.

You've implemented your code against bitcoin inquisition 27.x [0],
which already includes an "evalscript" subcommand [1] that allows you
to do precisely that, even without updating the functional test suite
so that CI passes. So, yes, you can run your scripts through testing
environments.

You can also easily tweak your scripts to run them through unmodified
testing environments to at least ensure you aren't making trivial errors
and to check the stack is working the way you think it should -- replace
the new commands with OP_NOP (for things like CTV) or OP_2DROP OP_VERIFY
(for things like CHECKSIGVERIFY, where an empty signature would fail,
and there are two other arguments to ignore).

> The fact that I misglanced the opcode list
> during drafting is completely irrelevant to the exercise.

That you made a mistake is perhaps excusable, though as someone proposing
to modify the script language, being more than glancingly familiar with
script as it is today seems like a pretty basic expectation. That you
didn't put your work through even the most basic testing cycle before
publicising it isn't so excusable. [2]

It's utterly astounding to me that you're publicising your project
as "lnhance" [3] and yet are willing to be that careless in your
demonstrations of how it might enhance the lightning network.

Cheers,
aj

[0] https://github.com/bitcoin-inquisition/bitcoin/pull/45
[1] https://github.com/bitcoin-inquisition/bitcoin/pull/58

[2] For instance, I made a claim above that you can use evalscript
with your inquisition pr. That's something that I should test,
and when I do, it turns out there's a line that needs fixing to
make that work. Here's what it looks like after that's done,
checking the first entry in the bip340 test vectors:

```
$ ./bitcoin-util -sigversion=tapscript -script_flags=CHECKSIGFROMSTACK evalscript '0x200000000000000000000000000000000000000000000000000000000000000000 0x20F9308A019258C31049344F85F89D5229B531C845836F99B08601F113BCE036F9 CHECKSIGFROMSTACK' E907831F80848D1069A5371B402410364BDF1C5F8307B0084C55F1CE2DCA821525F66A4A85EA8B71E482A74F382D2CE5EBEEE8FDB2172F477DF4900D310536C0
{
"script": {
"asm": "0000000000000000000000000000000000000000000000000000000000000000 f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9 OP_CHECKSIGFROMSTACK",
"hex": "20000000000000000000000000000000000000000000000000000000000000000020f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9cc",
"type": "nonstandard"
},
"sigversion": "tapscript",
"script_flags": [
"CHECKSIGFROMSTACK"
],
"stack-after": [
"01"
],
"sigop-count": 0,
"success": true
}
```

[3] https://www.lnhance.org/#team

[Brandon Black]

Hi AJ,

On 2024-12-11 (Wed) at 23:28:42 +1000, Anthony Towns wrote:
> On Mon, Dec 09, 2024 at 12:45:35PM -0800, Brandon Black wrote:
> > First, my example scripts for Lightning Symmetry all use opcodes that do
> > not exist in the script testing environments so I cannot run my scripts
> > through those environments.
>
> You've implemented your code against bitcoin inquisition 27.x [0],
> which already includes an "evalscript" subcommand [1] that allows you
> to do precisely that, even without updating the functional test suite
> so that CI passes. So, yes, you can run your scripts through testing
> environments.

There seems to still be some confusion here. The script you found a bug
in was using OP_VAULT, which I haven't implemented and which is not in
inquisition.

> You can also easily tweak your scripts to run them through unmodified
> testing environments to at least ensure you aren't making trivial errors
> and to check the stack is working the way you think it should -- replace
> the new commands with OP_NOP (for things like CTV) or OP_2DROP OP_VERIFY
> (for things like CHECKSIGVERIFY, where an empty signature would fail,
> and there are two other arguments to ignore).
>
> > The fact that I misglanced the opcode list
> > during drafting is completely irrelevant to the exercise.
>
> That you made a mistake is perhaps excusable, though as someone proposing
> to modify the script language, being more than glancingly familiar with
> script as it is today seems like a pretty basic expectation. That you
> didn't put your work through even the most basic testing cycle before
> publicising it isn't so excusable. [2]

I must have been unclear in how I published my recent script hacking to
trigger this type of response. I did not say, "here are production ready
scripts that I've validated for securing your funds." I hacked up a
proof of concept to demonstrate conceptually how certain types of things
can be done using certain proposed opcodes. Why would I have run them
through a testing environment? Why would I have worried about whether
there's 3DROP or only 3DUP? Those are irrelevant to whether CCV or VAULT
can be used as part of a Lightning Symmetry implementation. Details that
can be worked out later.

I published my results and how I arrived at them (in the gist showing my
expected stack progression) and anyone can correct me (as you did).

> It's utterly astounding to me that you're publicising your project
> as "lnhance" [3] and yet are willing to be that careless in your
> demonstrations of how it might enhance the lightning network.

My work on demonstrating how opcodes unrelated to LNHANCE can also be
used for Lightning Symmetry is somehow related to my work on LNHANCE
how?

Did I do something to offend you?

Best,

--Brandon