> 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 ). > 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 >