Re: [bitcoin-dev] Unlimited covenants, was Re: CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin

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

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

>  when people are talking about enabling covenants, we are talking about
whether OP_CAT should be allowed or not

Are they? Are you implying that anything that enables covenants is
equivalent to enabling OP_CAT? Generally when I think about enabling
covenants, I'm thinking more about OP_CTV (or some similarly specific opcode
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/bip-constraindestination.md>
).

> OP_TWEAK

I wasn't able to find anything about what that is. Would you mind
clarifying what that concept is?

On Mon, Jul 5, 2021 at 10:20 AM Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi ZmnSCPxj,
>
> I don't believe we need to ban Turing completeness for the sake of banning
> Turing completeness.  My concerns have always been around ensuring that
> transaction and block validation is not unduly burdensome for nodes.  So
> for Bitcoin Script, we want to bound the amount of resources needed to
> execute it, preferably as a linear function of weight[1], and preferably
> have it clear what the evaluation costs are going to be prior to
> evaluation[2].  We also want to keep Script execution as a pure function of
> the transaction data so that nodes do not need to reevaluate their mempool
> on every new block.  For consensus purposes we prefer to have simple
> primitive operations that have clear and precise semantics that are as
> likely as possible to be reimplemented correctly if they are reimplemented
> (or at least let us not make this problem worse than it already is).  In
> particular, Script needs to be easy to parse to avoid weird parsing
> machines that lead to security vulnerabilities within node software.
>
> While the above design constraints imply a prohibition on Turing complete
> computation within a single Script, they do not imply a prohibition on
> arbitrary, covenant-enabled computations that spans across multiple
> transactions.  Neither would these constraints prohibit some kind of STARK
> or SNARK tapleaf version that was somehow capable of succinctly
> representing arbitrary computations, so long as validation costs remain
> bounded.
>
> And while it is true that covenant-enabled computations could allow users
> to put their funds at risk through weird machines that manipulate their
> money on the blockchain, as longs as that weirdness stays at that level of
> the abstract Bitcoin Script machine, then I suppose it is *caveat emptor*;
> don't send your funds to random unverified Bitcoin Scripts, advice that is
> already the case today.  We can keep that potential weirdness at bay by
> keeping Script simple, and maintaining our understanding that the Script
> programs (like the rest of the blockchain data) are untrusted inputs and
> they need to be validated and scrutinized before interpretation.
>
> [1] In tapscript I believe all operations are linear time with the
> exception of OP_ROLL.  However OP_ROLL is still constrained by global
> limits on stack size, etc.
> [2] In Bitcoin Script, without loops of any kind, every opcode is
> evaluated at most once, so counting opcodes is an easy way to put an upper
> bound on your costs before evaluation.
>
> On Sun, Jul 4, 2021 at 8:51 PM ZmnSCPxj via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Good morning Dave,
>>
>> > On Sun, Jul 04, 2021 at 11:39:44AM -0700, Jeremy wrote:
>> >
>> > > However, I think the broader community is unconvinced by the cost
>> benefit
>> > > of arbitrary covenants. See
>> > >
>> https://medium.com/block-digest-mempool/my-worries-about-too-generalized-covenants-5eff33affbb6
>> > > as a recent example. Therefore as a critical part of building
>> consensus on
>> > > various techniques I've worked to emphasize that specific additions
>> do not
>> > > entail risk of accidentally introducing more than was bargained for to
>> > > respect the concerns of others.
>> >
>> > Respecting the concerns of others doesn't require lobotomizing useful
>> > tools. Being respectful can also be accomplished by politely showing
>> > that their concerns are unfounded (or at least less severe than they
>> > thought). This is almost always the better course IMO---it takes much
>> > more effort to satisfy additional engineering constraints (and prove to
>> > reviewers that you've done so!) than it does to simply discuss those
>> > concerns with reasonable stakeholders. As a demonstration, let's look
>> > at the concerns from Shinobi's post linked above:
>> >
>> > They seem to be worried that some Bitcoin users will choose to accept
>> > coins that can't subsequently be fungibily mixed with other bitcoins.
>> > But that's already been the case for a decade: users can accept altcoins
>> > that are non-fungible with bitcoins.
>> >
>> > They talk about covenants where spending is controlled by governments,
>> > but that seems to me exactly like China's CBDC trial.
>> >
>> > They talk about exchanges depositing users' BTC into a covenant, but
>> > that's just a variation on the classic not-your-keys-not-your-bitcoins
>> > problem. For all you know, your local exchange is keeping most of its
>> > BTC balance commitments in ETH or USDT.
>> >
>> > To me, it seems like the worst-case problems Shinobi describes with
>> > covenants are some of the same problems that already exist with
>> > altcoins. I don't see how recursive covenants could make any of those
>> > problems worse, and so I don't see any point in limiting Bitcoin's
>> > flexibility to avoid those problems when there are so many interesting
>> > and useful things that unlimited covenants could do.
>>
>> The "altcoins are even worse" argument does seem quite convincing, and if
>> Bitcoin can survive altcoins, surely it can survive covenants too?
>>
>> In before "turns out covenants are the next ICO".
>> i.e. ICOs are just colored coins, which are useful for keeping track of
>> various stuff, but have then been used as a vehicle to scam people.
>> But I suppose that is a problem that humans will always have: limited
>> cognition, so that *good* popular things that are outside your specific
>> field of study are indistinguishable from *bad* popular things.
>> So perhaps it should not be a concern on a technical level.
>> Maybe we should instead make articles about covenants so boring nobody
>> will hype about it (^^;)v.
>>
>> Increased functionality implies increased processing, and hopefully
>> computation devices are getting cheap enough that the increased processing
>> implied by new features should not be too onerous.
>>
>>
>>
>> To my mind, an "inescapable" covenant (i.e. one that requires the output
>> to be paid to the same covenant) is basically a Turing machine, and
>> equivalent to a `while (true);` loop.
>> In a `while (true);` loop, the state of the machine reverts back to the
>> same state, and it repeats again.
>> In an inescpable covenant, the control of some amount of funds reverts
>> back to the same controlling SCRIPT, and it repeats again.
>> Yes, you can certainly add more functionality on top of that loop, just
>> think of program main loops for games or daemons, which are, in essence,
>> "just" `while (true) ...`.
>> But basically, such unbounded infinite loops are possible only under
>> Turing machines, thus I consider covenants to be Turing-complete.
>> Principle of Least Power should make us wonder if we need full Turing
>> machines for the functionality.
>>
>> On the other hand --- codata processing *does* allow for unbounded loops,
>> without requiring full Turing-completeness; they just require total
>> functionality, not partial (and Turing-completeness is partial, not total).
>> Basically, data structures are unbounded storage, while codata structures
>> are unbounded processing.
>> Perhaps covenants can encode an upper bound on the number of recursions,
>> which prevents full Turing-completeness while allowing for a large number
>> of use-cases.
>>
>> (if the above paragraph makes no sense to you, hopefully this Wikipedia
>> article will help:
>> https://en.wikipedia.org/wiki/Total_functional_programming )
>> (basically my argument here is based on academic programming stuff, and
>> might not actually matter in real life)
>>
>> 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: 10321 bytes --]