[bitcoin-dev] CTV BIP Meeting #8 Notes

[bitcoin-dev] CTV BIP Meeting #8 Notes

[alicexbt]

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

Hi Bitcoin Developers,

Summary for the last CTV meeting:

Topics:

1)APO version of the simple vault
2)APO as alternative to CTV
3)fiatjaf's CTV spacechain demo
4)Compare CTV with other covenant proposals
5)Recursive covenants
6)Responding to FUD

===================================================
APO version of the simple vault
===================================================

- It is vulnerable to the half-spend problem, where multiple vaulted outputs (of the same denomination) can be spent together, burning all but the first to fees. Fixing this requires amending APOAS to cover the current input index.
- The unvault transaction is third-party malleable (it can have more inputs added to it). One practical implication is that you can't hand a list of the unvault txids to a watchtower, you have to tell them which outpoints to watch which is less privacy-preserving. Fixing this requires amending APOAS to cover the number of inputs.
Both of these issues are fixed by the BIP 118 changes suggested by darosior (although they still not officially spec'd afaik), which would basically make APO have a CTV-equivalent hash mode (minus scriptSig of other inputs)
- simple-apo-vault could use APO-as-spec'd with SIGHASH_SINGLE|SIGHASH_ANYONECANPAY, which would solve the half-spend problem (but not malleability) and have some other interesting properties, like more natural dynamic fees (add inputs+change) and the ability spend multiple vaulted outputs together. This would, however, introduce a tx pinning attack vector and prevent rate-limited vaults.

===================================================
APO as alternative to CTV
===================================================

- Current APO is unusable as a CTV alternative, (revised)APO seems to be as useful as CTV is (plus some extra flexibility from existing sighash flags)
- Main drawbacks being the additional witness satisfaction cost, the network-side full-node validation costs of checking a signature instead of just a hash, and not being segwit0-compatible (meaning, among others, not quantumphobic-friendly)
- Its about 3x for APO-in-taproot vs CTV-in-taproot. CTV-in-segwitv0 and CTV-in-bare-spk get you even more savings
- APO is far from being ready, let alone (revised)APO
- APOv2 would be both better for Eltoo and better for CTV, since you can use a trick to make the signatures smaller
- "layered commitments" is essential for eltoo to be usable or not is unclear. AJ Towns thinks it is required while Christian Decker thinks it is not.

===================================================
fiatjaf's CTV spacechain demo
===================================================

https://github.com/fiatjaf/simple-ctv-spacechain

===================================================
Compare CTV with other covenant proposals
===================================================

Unlike crypto primitves (e.g., BLS vs Schnorr), there's not really actually a defined way to compare them. So one exercise of value would be if everyone tries to actually either agree to or come up with their own framework for comparing covenants.

Billy Tetrud's email: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020402.html

- Prefers CTV for several reasons. Mainly because of being simple, documentation, code, tools, review and testing.
- Everything else either introduces malleability, infinite recursion, or has interactions with other proposed opcodes that could introduce potentially undesirable effects like those.
- Anything involving OP_CAT is out for the time being. There are so many things it can enable that it seems most people aren't comfortable adding it at the moment.
- APO wallet vaults seem rather hacky, inefficient, and limited.
- TLUV is built for evictions, TLUV + IN_OUT_AMOUNT and OP_CHECKOUTPUTVERIFY allows recursive covenants

===================================================
Recursive covenants
===================================================

jamesob:
I don't particularly understand the aversion to infinite recursion, which seems no different than the risk of potentially burning your coins. It's not like infinite recursion on bitcoin is some kind of DoS vector or poses execution overhead like an Ethereum VM bug might.

rgrant:
i think people who want recursion for cool stuff are worried that pedestrian stuff will prevent it.

jeremyrubin:
i think people are afraid of weird shit happening, less so of recursion in particular

hsjoberg:
"Recursive covenants" is the boogie man

shesek:
"recursion" translates to "complex black magic" for nondevs' -- recursion is the new turing completeness

===================================================
Responding to FUD
===================================================

- It could be a good idea to include showing a way to do blacklists in the bug bounty offer
- The potential concerns about recursive covenants have to clearly explained so they can be properly examined.
- An article about CTV myths similar to segwit: : https://blog.blockstream.com/en-segwit-myths-debunked/
- Some users think CTV might delay eltoo

TL;DR
"The initial resistance came from the Speedy Trial proposal. Then later on rumors and FUD started spreading around regarding CTV and covenants."
- hsjoberg

https://gnusha.org/ctv-bip-review/2022-05-03.log

/dev/fd0

Sent with [ProtonMail](https://protonmail.com/) secure email.

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

Re: [bitcoin-dev] CTV BIP Meeting #8 Notes

[Jorge Timón]

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

I think people may be scared of potential attacks based on covenants. For
example, visacoin.
But there was a thread with ideas of possible attacks based on covenants.
To me the most scary one is visacoin, specially seeing what happened in
canada and other places lately and the general censorship in the west, the
supposed war on "misinformation" going on (really a war against truth imo,
but whatever) it's getting really scary. But perhaps someone else can be
more scared about a covenant to add demurrage fees to coins or something, I
don't know.

https://bitcointalk.org/index.php?topic=278122

For example, what if Justin Castro, sorry, Justin Trudeu mandated a
visacoin covenant for all withdrawals from canadian exchanges?
What if ursula von der mengele, sorry, von der leyen wants to do the same
in europe?
What if nina Nina Jankowicz decides visacoin covenants are the best way to
"stop misinformation"?

Covenants can enable many attacks on bitcoin, not just new cool features.

Now, perhaps I am crazy for thinking there's a war against truth going on,
I don't know.
Perhaps most devs and bitcoin users love those lying politicians I
mentioned.
Perhaps I'm too biased because my political views. Or perhaps the people
who don't consider Justin a criminal against humanity are biased.

I guess this goes beyond the scope of this mailing list though. Perhaps we
should go back to the bitcoin forums to discuss this kind of thing.





On Sat, May 7, 2022 at 10:54 AM alicexbt via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Bitcoin Developers,
>
> Summary for the last CTV meeting:
>
> Topics:
>
> 1)APO version of the simple vault
> 2)APO as alternative to CTV
> 3)fiatjaf's CTV spacechain demo
> 4)Compare CTV with other covenant proposals
> 5)Recursive covenants
> 6)Responding to FUD
>
> ===================================================
> APO version of the simple vault
> ===================================================
>
> - It is vulnerable to the half-spend problem, where multiple vaulted
> outputs (of the same denomination) can be spent together, burning all but
> the first to fees. Fixing this requires amending APOAS to cover the current
> input index.
> - The unvault transaction is third-party malleable (it can have more
> inputs added to it). One practical implication is that you can't hand a
> list of the unvault txids to a watchtower, you have to tell them which
> outpoints to watch which is less privacy-preserving. Fixing this requires
> amending APOAS to cover the number of inputs.
> Both of these issues are fixed by the BIP 118 changes suggested by
> darosior (although they still not officially spec'd afaik), which would
> basically make APO have a CTV-equivalent hash mode (minus scriptSig of
> other inputs)
> - simple-apo-vault could use APO-as-spec'd with
> SIGHASH_SINGLE|SIGHASH_ANYONECANPAY, which would solve the half-spend
> problem (but not malleability) and have some other interesting properties,
> like more natural dynamic fees (add inputs+change) and the ability spend
> multiple vaulted outputs together. This would, however, introduce a tx
> pinning attack vector and prevent rate-limited vaults.
>
> ===================================================
> APO as alternative to CTV
> ===================================================
>
> - Current APO is unusable as a CTV alternative, (revised)APO seems to be
> as useful as CTV is (plus some extra flexibility from existing sighash
> flags)
> - Main drawbacks being the additional witness satisfaction cost, the
> network-side full-node validation costs of checking a signature instead of
> just a hash, and not being segwit0-compatible (meaning, among others, not
> quantumphobic-friendly)
> - Its about 3x for APO-in-taproot vs CTV-in-taproot. CTV-in-segwitv0 and
> CTV-in-bare-spk get you even more savings
> - APO is far from being ready, let alone (revised)APO
> - APOv2 would be both better for Eltoo and better for CTV, since you can
> use a trick to make the signatures smaller
> - "layered commitments" is essential for eltoo to be usable or not is
> unclear. AJ Towns thinks it is required while Christian Decker thinks it is
> not.
>
> ===================================================
> fiatjaf's CTV spacechain demo
> ===================================================
>
> https://github.com/fiatjaf/simple-ctv-spacechain
>
> ===================================================
> Compare CTV with other covenant proposals
> ===================================================
>
> Unlike crypto primitves (e.g., BLS vs Schnorr), there's not really
> actually a defined way to compare them. So one exercise of value would be
> if everyone tries to actually either agree to or come up with their own
> framework for comparing covenants.
>
> Billy Tetrud's email:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020402.html
>
> - Prefers CTV for several reasons. Mainly because of being simple,
> documentation, code, tools, review and testing.
> - Everything else either introduces malleability, infinite recursion, or
> has interactions with other proposed opcodes that could introduce
> potentially undesirable effects like those.
> - Anything involving OP_CAT is out for the time being. There are so many
> things it can enable that it seems most people aren't comfortable adding it
> at the moment.
> - APO wallet vaults seem rather hacky, inefficient, and limited.
> - TLUV is built for evictions, TLUV + IN_OUT_AMOUNT and
> OP_CHECKOUTPUTVERIFY allows recursive covenants
>
> ===================================================
> Recursive covenants
> ===================================================
>
> jamesob:
> I don't particularly understand the aversion to infinite recursion, which
> seems no different than the risk of potentially burning your coins. It's
> not like infinite recursion on bitcoin is some kind of DoS vector or poses
> execution overhead like an Ethereum VM bug might.
>
> rgrant:
> i think people who want recursion for cool stuff are worried that
> pedestrian stuff will prevent it.
>
> jeremyrubin:
> i think people are afraid of weird shit happening, less so of recursion in
> particular
>
> hsjoberg:
> "Recursive covenants" is the boogie man
>
> shesek:
> "recursion" translates to "complex black magic" for nondevs' -- recursion
> is the new turing completeness
>
> ===================================================
> Responding to FUD
> ===================================================
>
> - It could be a good idea to include showing a way to do blacklists in the
> bug bounty offer
> - The potential concerns about recursive covenants have to clearly
> explained so they can be properly examined.
> - An article about CTV myths similar to segwit: :
> https://blog.blockstream.com/en-segwit-myths-debunked/
> - Some users think CTV might delay eltoo
>
> TL;DR
> "The initial resistance came from the Speedy Trial proposal. Then later on
> rumors and FUD started spreading around regarding CTV and covenants."
> - hsjoberg
>
> https://gnusha.org/ctv-bip-review/2022-05-03.log
>
>
> /dev/fd0
> Sent with ProtonMail <https://protonmail.com/> secure email.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

Re: [bitcoin-dev] CTV BIP Meeting #8 Notes

[ZmnSCPxj]

Good morning Jorge,

> I think people may be scared of potential attacks based on covenants. For example, visacoin.
> But there was a thread with ideas of possible attacks based on covenants.
> To me the most scary one is visacoin, specially seeing what happened in canada and other places lately and the general censorship in the west, the supposed war on "misinformation" going on (really a war against truth imo, but whatever) it's getting really scary. But perhaps someone else can be more scared about a covenant to add demurrage fees to coins or something, I don't know.
> https://bitcointalk.org/index.php?topic=278122

This requires *recursive* covenants.

At the time the post was made, no distinction was seen between recursive and non-recursive covenants, which is why the post points out that covenants suck.
The idea then was that anything powerful enough to provide covenants would also be powerful enough to provide *recursive* covenants, so there was no distinction made between recursive and non-recursive covenants (the latter was thought to be impossible).

However, `OP_CTV` turns out to enable sort-of covenants, but by construction *cannot* provide recursion.
It is just barely powerful enough to make a covenant, but not powerful enough to make *recursive* covenants.

That is why today we distinguish between recursive and non-recursive covenant opcodes, because we now have opcode designs that provides non-recursive covenants (when previously it was thought all covenant opcodes would provide recursion).

`visacoin` can only work as a recursive covenant, thus it is not possible to use `OP_CTV` to implement `visacoin`, regardless of your political views.

(I was also misinformed in the past and ignored `OP_CTV` since I thought that, like all the other covenant opcodes, it would enable recursive covenants.)


Regards,
ZmnSCPxj

Re: [bitcoin-dev] CTV BIP Meeting #8 Notes

[Billy Tetrud]

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

>  This requires *recursive* covenants.

Actually, for practical use, any walled-garden requires *dynamic*
covenants, not recursive covenants. CTV can get arbitrarily close to
recursive covenants, because you can have an arbitrarily long string of
covenants. But this doesn't help someone implement visacoin because CTV
only allows a specific predefined iteration of transactions, meaning that
while "locked" into the covenant sequence, the coins can't be used in any
way like normal coins - you can't choose who you pay, the sequence is
predetermined.

Even covenants that allow infinite recursion (like OP_TLUV and OP_CD
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip-constraindestination.md>)
don't automatically allow for practical walled gardens. Recursion
definitely allows creating walled gardens, but those gardens would be
impractically static. You could add millions of potential addresses to send
to, which would "only" quadruple the size of your transactions, but if
anyone creates a new address you want to send to, you wouldn't be able to.
Everyone would have to have a single address whitelisted into every
government-bitcoin output. If someone lost their key and needs to create a
new wallet, suddenly no one would be able to pay them.

In order to really build a wallet garden, infinite recursion isn't really
necessary nor sufficient. You need to be able to dynamically specify
destination addresses. For example, if you were a government that wants to
make a walled garden where you (the government) could confiscate the funds
whenever you wanted, you'd have to have a covenant that allows the end-user
to specify an arbitrary public key to send money to. The covenant might
require that user to send to another covenant that has a government spend
path, but also has a spend path for that user-defined public key. That way,
you (the government) could allow people to send to each other arbitrarily,
while still ensuring that you (the government) could spend the funds no
matter where they may have been sent. Even without recursive covenants, you
could have arbitrarily long chains of these, say 1 million long, where at
the end of the chain the user must send your coins back to the government
who can then send them back with another million-long chain of covenants to
work with.

OP_CHECKOUTPUTVERIFY <https://fc16.ifca.ai/bitcoin/papers/MES16.pdf> can do
this kind of dynamicness, and OP_PUSHOUTPUTSTACK
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/pos/bip-pushoutputstack.md>
can
enable it for things like OP_TLUV and OP_CD. I personally think dynamic
covenants are a *good* thing, as it enables more secure wallet vaults,
among other things. And I'm not worried about a government creating a
in-bitcoin visa-coin. Why? Because they can already do it today. They have
been able to do it for 9 years already. How?

Replace the covenant above with a multisig wallet. The government has 2
keys, you have 1 key. Every time you make a transaction, you request the
government's signature on it. The government then only signs if you're
sending to a wallet they approve of. They might only sign when you're
sending to another multisig wallet that the government has 2 of 3 keys for.
Its a very similar walled garden, where the only difference is that the
government needs to actively sign, which I'm sure wouldn't be a huge
challenge for the intrepid dictator of the land. You want to add
demurage fees? Easy, the government just spends the fee out of everyone's
wallets every so often.

On the other hand, OP_CTV *cannot* be used for such a thing. No combination
of future opcodes can enable either recursion or dynamicness to an OP_CTV
call.



On Sat, May 7, 2022 at 5:40 PM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Good morning Jorge,
>
> > I think people may be scared of potential attacks based on covenants.
> For example, visacoin.
> > But there was a thread with ideas of possible attacks based on covenants.
> > To me the most scary one is visacoin, specially seeing what happened in
> canada and other places lately and the general censorship in the west, the
> supposed war on "misinformation" going on (really a war against truth imo,
> but whatever) it's getting really scary. But perhaps someone else can be
> more scared about a covenant to add demurrage fees to coins or something, I
> don't know.
> > https://bitcointalk.org/index.php?topic=278122
>
> This requires *recursive* covenants.
>
> At the time the post was made, no distinction was seen between recursive
> and non-recursive covenants, which is why the post points out that
> covenants suck.
> The idea then was that anything powerful enough to provide covenants would
> also be powerful enough to provide *recursive* covenants, so there was no
> distinction made between recursive and non-recursive covenants (the latter
> was thought to be impossible).
>
> However, `OP_CTV` turns out to enable sort-of covenants, but by
> construction *cannot* provide recursion.
> It is just barely powerful enough to make a covenant, but not powerful
> enough to make *recursive* covenants.
>
> That is why today we distinguish between recursive and non-recursive
> covenant opcodes, because we now have opcode designs that provides
> non-recursive covenants (when previously it was thought all covenant
> opcodes would provide recursion).
>
> `visacoin` can only work as a recursive covenant, thus it is not possible
> to use `OP_CTV` to implement `visacoin`, regardless of your political views.
>
> (I was also misinformed in the past and ignored `OP_CTV` since I thought
> that, like all the other covenant opcodes, it would enable recursive
> covenants.)
>
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

Re: [bitcoin-dev] CTV BIP Meeting #8 Notes

[Keagan McClelland]

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

> > > To me the most scary one is visacoin, specially seeing what happened
in canada and other places lately and the general censorship in the west,
the supposed war on "misinformation" going on (really a war against truth
imo, but whatever) it's getting really scary. But perhaps someone else can
be more scared about a covenant to add demurrage fees to coins or
something, I don't know.
> > > https://bitcointalk.org/index.php?topic=278122

> > This requires *recursive* covenants.

> Actually, for practical use, any walled-garden requires *dynamic*
covenants, not recursive covenants.

There's actually also a very straight forward defense for those who do not
want to receive "tainted" coins. In every covenant design I've seen to date
(including recursive designs) it requires that the receiver generate a
script that is "compliant" with the covenant provisions to which the sender
is bound. The consequence of this is that you can't receive coins that are
bound by covenants you weren't aware of*. So if you don't want to receive
restricted coins, just don't generate an address with those restrictions
embedded. As long as you can specify the spend conditions upon the receipt
of your funds, it really doesn't matter how others are structuring their
own spend conditions. So long as the verification of those conditions can
be predictably verified by the rest of the network, all risk incurred is
quarantined to the receiver of the funds. Worst case scenario is that no
one wants to agree to those conditions and the funds are effectively burned.

It's not hard to make the case that any time funds are being transferred
between organizations with incompatible interests (external to a firm),
that they will want to be completely free to choose their own spend
conditions and will not wish to inherit the conditions of the spender.
Correspondingly, any well implemented covenant contract will include
provisions for escaping the recursion loop if some sufficiently high bar is
met by the administrators of those funds. Unless governments can mandate
that you generate these addresses AND force you to accept funds bound by
them for your services**, I don't actually see how this is a real concern.

*This requires good wallet tooling and standards but that isn't materially
different than wallets experimenting with non-standard recovery policies.

**This is a reason to oppose legal tender laws for Bitcoin imo.

Keagan

On Sun, May 8, 2022 at 11:32 AM Billy Tetrud via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> >  This requires *recursive* covenants.
>
> Actually, for practical use, any walled-garden requires *dynamic*
> covenants, not recursive covenants. CTV can get arbitrarily close to
> recursive covenants, because you can have an arbitrarily long string of
> covenants. But this doesn't help someone implement visacoin because CTV
> only allows a specific predefined iteration of transactions, meaning that
> while "locked" into the covenant sequence, the coins can't be used in any
> way like normal coins - you can't choose who you pay, the sequence is
> predetermined.
>
> Even covenants that allow infinite recursion (like OP_TLUV and OP_CD
> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip-constraindestination.md>)
> don't automatically allow for practical walled gardens. Recursion
> definitely allows creating walled gardens, but those gardens would be
> impractically static. You could add millions of potential addresses to send
> to, which would "only" quadruple the size of your transactions, but if
> anyone creates a new address you want to send to, you wouldn't be able to.
> Everyone would have to have a single address whitelisted into every
> government-bitcoin output. If someone lost their key and needs to create a
> new wallet, suddenly no one would be able to pay them.
>
> In order to really build a wallet garden, infinite recursion isn't really
> necessary nor sufficient. You need to be able to dynamically specify
> destination addresses. For example, if you were a government that wants to
> make a walled garden where you (the government) could confiscate the funds
> whenever you wanted, you'd have to have a covenant that allows the end-user
> to specify an arbitrary public key to send money to. The covenant might
> require that user to send to another covenant that has a government spend
> path, but also has a spend path for that user-defined public key. That way,
> you (the government) could allow people to send to each other arbitrarily,
> while still ensuring that you (the government) could spend the funds no
> matter where they may have been sent. Even without recursive covenants, you
> could have arbitrarily long chains of these, say 1 million long, where at
> the end of the chain the user must send your coins back to the government
> who can then send them back with another million-long chain of covenants to
> work with.
>
> OP_CHECKOUTPUTVERIFY <https://fc16.ifca.ai/bitcoin/papers/MES16.pdf> can
> do this kind of dynamicness, and OP_PUSHOUTPUTSTACK
> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/pos/bip-pushoutputstack.md> can
> enable it for things like OP_TLUV and OP_CD. I personally think dynamic
> covenants are a *good* thing, as it enables more secure wallet vaults,
> among other things. And I'm not worried about a government creating a
> in-bitcoin visa-coin. Why? Because they can already do it today. They have
> been able to do it for 9 years already. How?
>
> Replace the covenant above with a multisig wallet. The government has 2
> keys, you have 1 key. Every time you make a transaction, you request the
> government's signature on it. The government then only signs if you're
> sending to a wallet they approve of. They might only sign when you're
> sending to another multisig wallet that the government has 2 of 3 keys for.
> Its a very similar walled garden, where the only difference is that the
> government needs to actively sign, which I'm sure wouldn't be a huge
> challenge for the intrepid dictator of the land. You want to add
> demurage fees? Easy, the government just spends the fee out of everyone's
> wallets every so often.
>
> On the other hand, OP_CTV *cannot* be used for such a thing. No
> combination of future opcodes can enable either recursion or dynamicness to
> an OP_CTV call.
>
>
>
> On Sat, May 7, 2022 at 5:40 PM ZmnSCPxj via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Good morning Jorge,
>>
>> > I think people may be scared of potential attacks based on covenants.
>> For example, visacoin.
>> > But there was a thread with ideas of possible attacks based on
>> covenants.
>> > To me the most scary one is visacoin, specially seeing what happened in
>> canada and other places lately and the general censorship in the west, the
>> supposed war on "misinformation" going on (really a war against truth imo,
>> but whatever) it's getting really scary. But perhaps someone else can be
>> more scared about a covenant to add demurrage fees to coins or something, I
>> don't know.
>> > https://bitcointalk.org/index.php?topic=278122
>>
>> This requires *recursive* covenants.
>>
>> At the time the post was made, no distinction was seen between recursive
>> and non-recursive covenants, which is why the post points out that
>> covenants suck.
>> The idea then was that anything powerful enough to provide covenants
>> would also be powerful enough to provide *recursive* covenants, so there
>> was no distinction made between recursive and non-recursive covenants (the
>> latter was thought to be impossible).
>>
>> However, `OP_CTV` turns out to enable sort-of covenants, but by
>> construction *cannot* provide recursion.
>> It is just barely powerful enough to make a covenant, but not powerful
>> enough to make *recursive* covenants.
>>
>> That is why today we distinguish between recursive and non-recursive
>> covenant opcodes, because we now have opcode designs that provides
>> non-recursive covenants (when previously it was thought all covenant
>> opcodes would provide recursion).
>>
>> `visacoin` can only work as a recursive covenant, thus it is not possible
>> to use `OP_CTV` to implement `visacoin`, regardless of your political views.
>>
>> (I was also misinformed in the past and ignored `OP_CTV` since I thought
>> that, like all the other covenant opcodes, it would enable recursive
>> covenants.)
>>
>>
>> Regards,
>> ZmnSCPxj
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

Re: [bitcoin-dev] CTV BIP Meeting #8 Notes

[Billy Tetrud]

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

>  So if you don't want to receive restricted coins, just don't generate an
address with those restrictions embedded.

This is an interesting point that I for some reason haven't thought of
before. However...

> Unless governments can mandate that you generate these addresses AND
force you to accept funds bound by them for your services**, I don't
actually see how this is a real concern.

Actually, I think only the second is necessary. For example, if there was a
law that compelled giving a good or service if payment of a publicly
advertised amount was paid, and someone pays to an address that can be
shown is spendable by the merchant's keys in a way that the government
accepts, it doesn't matter whether the recipient can or has generated the
address.

Regardless I do think its still important to note that a government could
do that today using multisig.

> This is a reason to oppose legal tender laws for Bitcoin imo.

I agree.

On Mon, May 9, 2022 at 10:23 AM Keagan McClelland <
keagan.mcclelland@gmail.com> wrote:

> > > > To me the most scary one is visacoin, specially seeing what happened
> in canada and other places lately and the general censorship in the west,
> the supposed war on "misinformation" going on (really a war against truth
> imo, but whatever) it's getting really scary. But perhaps someone else can
> be more scared about a covenant to add demurrage fees to coins or
> something, I don't know.
> > > > https://bitcointalk.org/index.php?topic=278122
>
> > > This requires *recursive* covenants.
>
> > Actually, for practical use, any walled-garden requires *dynamic*
> covenants, not recursive covenants.
>
> There's actually also a very straight forward defense for those who do not
> want to receive "tainted" coins. In every covenant design I've seen to date
> (including recursive designs) it requires that the receiver generate a
> script that is "compliant" with the covenant provisions to which the sender
> is bound. The consequence of this is that you can't receive coins that are
> bound by covenants you weren't aware of*. So if you don't want to receive
> restricted coins, just don't generate an address with those restrictions
> embedded. As long as you can specify the spend conditions upon the receipt
> of your funds, it really doesn't matter how others are structuring their
> own spend conditions. So long as the verification of those conditions can
> be predictably verified by the rest of the network, all risk incurred is
> quarantined to the receiver of the funds. Worst case scenario is that no
> one wants to agree to those conditions and the funds are effectively burned.
>
> It's not hard to make the case that any time funds are being transferred
> between organizations with incompatible interests (external to a firm),
> that they will want to be completely free to choose their own spend
> conditions and will not wish to inherit the conditions of the spender.
> Correspondingly, any well implemented covenant contract will include
> provisions for escaping the recursion loop if some sufficiently high bar is
> met by the administrators of those funds. Unless governments can mandate
> that you generate these addresses AND force you to accept funds bound by
> them for your services**, I don't actually see how this is a real concern.
>
> *This requires good wallet tooling and standards but that isn't materially
> different than wallets experimenting with non-standard recovery policies.
>
> **This is a reason to oppose legal tender laws for Bitcoin imo.
>
> Keagan
>
> On Sun, May 8, 2022 at 11:32 AM Billy Tetrud via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> >  This requires *recursive* covenants.
>>
>> Actually, for practical use, any walled-garden requires *dynamic*
>> covenants, not recursive covenants. CTV can get arbitrarily close to
>> recursive covenants, because you can have an arbitrarily long string of
>> covenants. But this doesn't help someone implement visacoin because CTV
>> only allows a specific predefined iteration of transactions, meaning that
>> while "locked" into the covenant sequence, the coins can't be used in any
>> way like normal coins - you can't choose who you pay, the sequence is
>> predetermined.
>>
>> Even covenants that allow infinite recursion (like OP_TLUV and OP_CD
>> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip-constraindestination.md>)
>> don't automatically allow for practical walled gardens. Recursion
>> definitely allows creating walled gardens, but those gardens would be
>> impractically static. You could add millions of potential addresses to send
>> to, which would "only" quadruple the size of your transactions, but if
>> anyone creates a new address you want to send to, you wouldn't be able to.
>> Everyone would have to have a single address whitelisted into every
>> government-bitcoin output. If someone lost their key and needs to create a
>> new wallet, suddenly no one would be able to pay them.
>>
>> In order to really build a wallet garden, infinite recursion isn't really
>> necessary nor sufficient. You need to be able to dynamically specify
>> destination addresses. For example, if you were a government that wants to
>> make a walled garden where you (the government) could confiscate the funds
>> whenever you wanted, you'd have to have a covenant that allows the end-user
>> to specify an arbitrary public key to send money to. The covenant might
>> require that user to send to another covenant that has a government spend
>> path, but also has a spend path for that user-defined public key. That way,
>> you (the government) could allow people to send to each other arbitrarily,
>> while still ensuring that you (the government) could spend the funds no
>> matter where they may have been sent. Even without recursive covenants, you
>> could have arbitrarily long chains of these, say 1 million long, where at
>> the end of the chain the user must send your coins back to the government
>> who can then send them back with another million-long chain of covenants to
>> work with.
>>
>> OP_CHECKOUTPUTVERIFY <https://fc16.ifca.ai/bitcoin/papers/MES16.pdf> can
>> do this kind of dynamicness, and OP_PUSHOUTPUTSTACK
>> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/pos/bip-pushoutputstack.md> can
>> enable it for things like OP_TLUV and OP_CD. I personally think dynamic
>> covenants are a *good* thing, as it enables more secure wallet vaults,
>> among other things. And I'm not worried about a government creating a
>> in-bitcoin visa-coin. Why? Because they can already do it today. They have
>> been able to do it for 9 years already. How?
>>
>> Replace the covenant above with a multisig wallet. The government has 2
>> keys, you have 1 key. Every time you make a transaction, you request the
>> government's signature on it. The government then only signs if you're
>> sending to a wallet they approve of. They might only sign when you're
>> sending to another multisig wallet that the government has 2 of 3 keys for.
>> Its a very similar walled garden, where the only difference is that the
>> government needs to actively sign, which I'm sure wouldn't be a huge
>> challenge for the intrepid dictator of the land. You want to add
>> demurage fees? Easy, the government just spends the fee out of everyone's
>> wallets every so often.
>>
>> On the other hand, OP_CTV *cannot* be used for such a thing. No
>> combination of future opcodes can enable either recursion or dynamicness to
>> an OP_CTV call.
>>
>>
>>
>> On Sat, May 7, 2022 at 5:40 PM ZmnSCPxj via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Good morning Jorge,
>>>
>>> > I think people may be scared of potential attacks based on covenants.
>>> For example, visacoin.
>>> > But there was a thread with ideas of possible attacks based on
>>> covenants.
>>> > To me the most scary one is visacoin, specially seeing what happened
>>> in canada and other places lately and the general censorship in the west,
>>> the supposed war on "misinformation" going on (really a war against truth
>>> imo, but whatever) it's getting really scary. But perhaps someone else can
>>> be more scared about a covenant to add demurrage fees to coins or
>>> something, I don't know.
>>> > https://bitcointalk.org/index.php?topic=278122
>>>
>>> This requires *recursive* covenants.
>>>
>>> At the time the post was made, no distinction was seen between recursive
>>> and non-recursive covenants, which is why the post points out that
>>> covenants suck.
>>> The idea then was that anything powerful enough to provide covenants
>>> would also be powerful enough to provide *recursive* covenants, so there
>>> was no distinction made between recursive and non-recursive covenants (the
>>> latter was thought to be impossible).
>>>
>>> However, `OP_CTV` turns out to enable sort-of covenants, but by
>>> construction *cannot* provide recursion.
>>> It is just barely powerful enough to make a covenant, but not powerful
>>> enough to make *recursive* covenants.
>>>
>>> That is why today we distinguish between recursive and non-recursive
>>> covenant opcodes, because we now have opcode designs that provides
>>> non-recursive covenants (when previously it was thought all covenant
>>> opcodes would provide recursion).
>>>
>>> `visacoin` can only work as a recursive covenant, thus it is not
>>> possible to use `OP_CTV` to implement `visacoin`, regardless of your
>>> political views.
>>>
>>> (I was also misinformed in the past and ignored `OP_CTV` since I thought
>>> that, like all the other covenant opcodes, it would enable recursive
>>> covenants.)
>>>
>>>
>>> Regards,
>>> ZmnSCPxj
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>

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

Re: [bitcoin-dev] CTV BIP Meeting #8 Notes

[Jorge Timón]

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

I think something like visacoin could be kind of feasible without recursive
covenants. But as billy points out, I guess they could kind of do it with
multisig too.

I fail to understand why non recursive covenants are called covenants at
all. Probably I'm missing something, but I guess that's another topic.


On Tue, May 10, 2022 at 5:11 PM Billy Tetrud via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> >  So if you don't want to receive restricted coins, just don't generate
> an address with those restrictions embedded.
>
> This is an interesting point that I for some reason haven't thought of
> before. However...
>
> > Unless governments can mandate that you generate these addresses AND
> force you to accept funds bound by them for your services**, I don't
> actually see how this is a real concern.
>
> Actually, I think only the second is necessary. For example, if there was
> a law that compelled giving a good or service if payment of a publicly
> advertised amount was paid, and someone pays to an address that can be
> shown is spendable by the merchant's keys in a way that the government
> accepts, it doesn't matter whether the recipient can or has generated the
> address.
>
> Regardless I do think its still important to note that a government could
> do that today using multisig.
>
> > This is a reason to oppose legal tender laws for Bitcoin imo.
>
> I agree.
>
> On Mon, May 9, 2022 at 10:23 AM Keagan McClelland <
> keagan.mcclelland@gmail.com> wrote:
>
>> > > > To me the most scary one is visacoin, specially seeing what
>> happened in canada and other places lately and the general censorship in
>> the west, the supposed war on "misinformation" going on (really a war
>> against truth imo, but whatever) it's getting really scary. But perhaps
>> someone else can be more scared about a covenant to add demurrage fees to
>> coins or something, I don't know.
>> > > > https://bitcointalk.org/index.php?topic=278122
>>
>> > > This requires *recursive* covenants.
>>
>> > Actually, for practical use, any walled-garden requires *dynamic*
>> covenants, not recursive covenants.
>>
>> There's actually also a very straight forward defense for those who do
>> not want to receive "tainted" coins. In every covenant design I've seen to
>> date (including recursive designs) it requires that the receiver generate a
>> script that is "compliant" with the covenant provisions to which the sender
>> is bound. The consequence of this is that you can't receive coins that are
>> bound by covenants you weren't aware of*. So if you don't want to receive
>> restricted coins, just don't generate an address with those restrictions
>> embedded. As long as you can specify the spend conditions upon the receipt
>> of your funds, it really doesn't matter how others are structuring their
>> own spend conditions. So long as the verification of those conditions can
>> be predictably verified by the rest of the network, all risk incurred is
>> quarantined to the receiver of the funds. Worst case scenario is that no
>> one wants to agree to those conditions and the funds are effectively burned.
>>
>> It's not hard to make the case that any time funds are being transferred
>> between organizations with incompatible interests (external to a firm),
>> that they will want to be completely free to choose their own spend
>> conditions and will not wish to inherit the conditions of the spender.
>> Correspondingly, any well implemented covenant contract will include
>> provisions for escaping the recursion loop if some sufficiently high bar is
>> met by the administrators of those funds. Unless governments can mandate
>> that you generate these addresses AND force you to accept funds bound by
>> them for your services**, I don't actually see how this is a real concern.
>>
>> *This requires good wallet tooling and standards but that isn't
>> materially different than wallets experimenting with non-standard recovery
>> policies.
>>
>> **This is a reason to oppose legal tender laws for Bitcoin imo.
>>
>> Keagan
>>
>> On Sun, May 8, 2022 at 11:32 AM Billy Tetrud via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> >  This requires *recursive* covenants.
>>>
>>> Actually, for practical use, any walled-garden requires *dynamic*
>>> covenants, not recursive covenants. CTV can get arbitrarily close to
>>> recursive covenants, because you can have an arbitrarily long string of
>>> covenants. But this doesn't help someone implement visacoin because CTV
>>> only allows a specific predefined iteration of transactions, meaning that
>>> while "locked" into the covenant sequence, the coins can't be used in any
>>> way like normal coins - you can't choose who you pay, the sequence is
>>> predetermined.
>>>
>>> Even covenants that allow infinite recursion (like OP_TLUV and OP_CD
>>> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip-constraindestination.md>)
>>> don't automatically allow for practical walled gardens. Recursion
>>> definitely allows creating walled gardens, but those gardens would be
>>> impractically static. You could add millions of potential addresses to send
>>> to, which would "only" quadruple the size of your transactions, but if
>>> anyone creates a new address you want to send to, you wouldn't be able to.
>>> Everyone would have to have a single address whitelisted into every
>>> government-bitcoin output. If someone lost their key and needs to create a
>>> new wallet, suddenly no one would be able to pay them.
>>>
>>> In order to really build a wallet garden, infinite recursion isn't
>>> really necessary nor sufficient. You need to be able to dynamically specify
>>> destination addresses. For example, if you were a government that wants to
>>> make a walled garden where you (the government) could confiscate the funds
>>> whenever you wanted, you'd have to have a covenant that allows the end-user
>>> to specify an arbitrary public key to send money to. The covenant might
>>> require that user to send to another covenant that has a government spend
>>> path, but also has a spend path for that user-defined public key. That way,
>>> you (the government) could allow people to send to each other arbitrarily,
>>> while still ensuring that you (the government) could spend the funds no
>>> matter where they may have been sent. Even without recursive covenants, you
>>> could have arbitrarily long chains of these, say 1 million long, where at
>>> the end of the chain the user must send your coins back to the government
>>> who can then send them back with another million-long chain of covenants to
>>> work with.
>>>
>>> OP_CHECKOUTPUTVERIFY <https://fc16.ifca.ai/bitcoin/papers/MES16.pdf> can
>>> do this kind of dynamicness, and OP_PUSHOUTPUTSTACK
>>> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/pos/bip-pushoutputstack.md> can
>>> enable it for things like OP_TLUV and OP_CD. I personally think dynamic
>>> covenants are a *good* thing, as it enables more secure wallet vaults,
>>> among other things. And I'm not worried about a government creating a
>>> in-bitcoin visa-coin. Why? Because they can already do it today. They have
>>> been able to do it for 9 years already. How?
>>>
>>> Replace the covenant above with a multisig wallet. The government has 2
>>> keys, you have 1 key. Every time you make a transaction, you request the
>>> government's signature on it. The government then only signs if you're
>>> sending to a wallet they approve of. They might only sign when you're
>>> sending to another multisig wallet that the government has 2 of 3 keys for.
>>> Its a very similar walled garden, where the only difference is that the
>>> government needs to actively sign, which I'm sure wouldn't be a huge
>>> challenge for the intrepid dictator of the land. You want to add
>>> demurage fees? Easy, the government just spends the fee out of everyone's
>>> wallets every so often.
>>>
>>> On the other hand, OP_CTV *cannot* be used for such a thing. No
>>> combination of future opcodes can enable either recursion or dynamicness to
>>> an OP_CTV call.
>>>
>>>
>>>
>>> On Sat, May 7, 2022 at 5:40 PM ZmnSCPxj via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>>> Good morning Jorge,
>>>>
>>>> > I think people may be scared of potential attacks based on covenants.
>>>> For example, visacoin.
>>>> > But there was a thread with ideas of possible attacks based on
>>>> covenants.
>>>> > To me the most scary one is visacoin, specially seeing what happened
>>>> in canada and other places lately and the general censorship in the west,
>>>> the supposed war on "misinformation" going on (really a war against truth
>>>> imo, but whatever) it's getting really scary. But perhaps someone else can
>>>> be more scared about a covenant to add demurrage fees to coins or
>>>> something, I don't know.
>>>> > https://bitcointalk.org/index.php?topic=278122
>>>>
>>>> This requires *recursive* covenants.
>>>>
>>>> At the time the post was made, no distinction was seen between
>>>> recursive and non-recursive covenants, which is why the post points out
>>>> that covenants suck.
>>>> The idea then was that anything powerful enough to provide covenants
>>>> would also be powerful enough to provide *recursive* covenants, so there
>>>> was no distinction made between recursive and non-recursive covenants (the
>>>> latter was thought to be impossible).
>>>>
>>>> However, `OP_CTV` turns out to enable sort-of covenants, but by
>>>> construction *cannot* provide recursion.
>>>> It is just barely powerful enough to make a covenant, but not powerful
>>>> enough to make *recursive* covenants.
>>>>
>>>> That is why today we distinguish between recursive and non-recursive
>>>> covenant opcodes, because we now have opcode designs that provides
>>>> non-recursive covenants (when previously it was thought all covenant
>>>> opcodes would provide recursion).
>>>>
>>>> `visacoin` can only work as a recursive covenant, thus it is not
>>>> possible to use `OP_CTV` to implement `visacoin`, regardless of your
>>>> political views.
>>>>
>>>> (I was also misinformed in the past and ignored `OP_CTV` since I
>>>> thought that, like all the other covenant opcodes, it would enable
>>>> recursive covenants.)
>>>>
>>>>
>>>> Regards,
>>>> ZmnSCPxj
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev@lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

Re: [bitcoin-dev] CTV BIP Meeting #8 Notes

[ZmnSCPxj]

Good morning Jorge,

> I fail to understand why non recursive covenants are called covenants at all. Probably I'm missing something, but I guess that's another topic.

A covenant simply promises that something will happen in the future.

A recursive covenant guarantees that the same thing will happen in the future.

Thus, non-recursive covenants can be useful.

Consider `OP_EVICT`, for example, which is designed for a very specific use-case, and avoids recursion.

Regards,
ZmnSCPxj

Re: [bitcoin-dev] CTV BIP Meeting #8 Notes

[Billy Tetrud]

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

@Jorge & Zmn
>  A recursive covenant guarantees that the same thing will happen in the
future.

Just a clarification: a recursive covenant does not necessarily guarantee
any particular thing will happen in the future. Both recursives and a
non-recursive covenant opcodes *can* be used to guarantee something will
happen. Neither *necessarily* guarantee anything (because of
the possibility of alternative spend paths). A covenant isn't just a
promise, its a restriction.

A "recursive covenant" opcode is one that allows loops in the progression
through covenant addresses. Here's an example of a set of transitions from
one address with a covenant in the spend path to another (or "exit" which
does not have a covenant restriction):

A -> B
A -> C
B -> C
C -> A
C -> exit

The possible combinations of changes are:

A -> B -> C -> exit
A -> C -> A -> ...
A -> B -> C -> A -> ...

This would be a recursive covenant with an exit. Remove the exit
transition, and you have a walled garden. Even with this walled garden, you
can avoid going through address B (since you can skip directly to C).

A covenant opcode that can allow for infinite recursion (often talked about
as a "recursive covenant") can be used to return to a previous state, which
allows for permanent walled gardens.

So I would instead characterize a bitcoin covenant as:

A covenant in an input script places a requirement/restriction on the
output script(s) that input sends to. Pretty much any covenant allows for a
chain or graph of covenant-laden addresses to be prescribed, while a
"recursive covenant" opcode allows previous nodes in that graph to be
returned to such that the states can be looped through forever (which may
or may not have some way to exit).

One potentially confusing thing about the way covenants are usually talked
about is that in technical discussions about the risks of covenants, what
is being talked about is not what a particular covenant opcode always does,
but rather what the boundaries are on what can be done with that opcode.
Pretty much any recursive covenant you could design would be able to be
used to create normal simple non-walled-garden situations. The question is,
since they do allow someone to create walled gardens, is that ok.

I suppose maybe an interesting possibility would be to have a covenant
limit placed into a covenant opcode. Eg, let's say that you have
OP_LIMITEDCOVENANT (OP_LC) and OP_LC specifies that the maximum covenant
chain is 100. The 100th consecutive output with an OP_LC use could simply
ignore it and be spent normally to anywhere (given that the rest of the
script allows it). This could effectively prevent the ability to create
walled gardens, without eliminating most interesting use cases. Among
people who care about covenants on this mailing list, the consensus seems
to be that infinitely recursive covenants are not something to be afraid
of. However, if maybe something like this could make more powerful
covenants acceptable to a larger group of people, it could be worth doing.

On Thu, May 12, 2022 at 7:20 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> Good morning Jorge,
>
> > I fail to understand why non recursive covenants are called covenants at
> all. Probably I'm missing something, but I guess that's another topic.
>
> A covenant simply promises that something will happen in the future.
>
> A recursive covenant guarantees that the same thing will happen in the
> future.
>
> Thus, non-recursive covenants can be useful.
>
> Consider `OP_EVICT`, for example, which is designed for a very specific
> use-case, and avoids recursion.
>
> Regards,
> ZmnSCPxj
>

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