Jorge Timón [ARCHIVE] on Nostr: 📅 Original date posted:2022-05-12 📝 Original message:I think something like ...

📅 Original date posted:2022-05-12
📝 Original message: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 at 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 at 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 at 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 at 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 at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220512/8e84e535/attachment.html>;