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

[Billy Tetrud <billy.tetrud@gmail.com>]

[-- 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 --]