Covenant-Dependent Layer 2 and Soft-Forks

Just came across this cool review on covenant-dependent layer 2 from Peter Todd. He really brings up some solid points. I gotta say, covenants might be just what we need for lightning to take off and could seriously boost Bitcoin's use as actual currency. Right now, trying to get an off-chain Bitcoin transaction while offline is a mess, especially without enough incoming capacity or an UTXO. These issues just push folks toward custodial wallets like Wallet of Satoshi. But with covenants, we could see other layer-2 solutions like Ark and Coinpool come to life, which could give us the benefits of Lightning without some of the headaches. Or at least, shifting some of the issues to server providers instead of regular users. Todd wraps it up by saying that out of all the soft forks on the table, OP_CTV seems to offer the best compromises.

Very interesting, thanks for linking! I would appreciate an ELI5 (or maybe ELI12) of the different covenant-style proposals and their use cases. Maybe we can use this thread for that purpose? One for example I hadn't heard about is OP_EVICT, proposed here. It is discussed in Todd's text because it could make CoinPools and channel factories (=Lightning with multi-user channels) more efficient. I try to resume it: It allows a participant of a multisig to be "evicted" from that contract. The main use case is if a participant becomes unresponsive, instead of having to "dissolve" the multisig, the unresponsive participant can simply be excluded, with his funds being returned to him, and the rest of the participants can continue inside the contract. In other words, it would transform a N-of-N into a (N-1)-of-(N-1) multisig without having to re-arrange the multisig completely. (correct me if there's an error). (Edit: Have deleted one post below from mine, don't want to feed any drama.)

Someone who's technical and who truly understands OP_CTV and its pros and cons should start a topic to educate the community on what's actually safer/more secure/more feasible for "covenants" - OP_CTV of OP_CAT. Because from a community support standpoint, I see that the people behind OP_CAT are louder/has more support. But the fact that Udi supports it, makes me cynical on what's actually better. ELI-5 OP_CAT vs. OP_CTV topic for non-technical people?

Do you really think it's fair to the author for BlackHatCoiner to discredit him with false accusations only to then later reference his work? Either Peter Todd should be ignored like BlackHatCoiner was telling everyone to do originally, or BlackHatCoiner can clarify that the author does not deceive his audience for personal gain and that he made up the accusations against him. BlackHatCoiner can't have it both ways.

Someone's really annoyed by my actions. I'm glad it's this one. Signals that I'm doing right. I'm not withdrawing any assertions I've made about Peter Todd. He did shill Wasabi in the past, and called Samourai a honeypot, which in my view, seemed suspicious and biased. I never said Peter Todd should be ignored. That's just an outright lie. I have no one to apologize apart from the viewers of this thread who will likely read yet another derailed thread by this petty troll. Sorry for that; you'll do a great service to yourself by putting him on ignore. And Kruw... I really feel sorry for you, man. Now back on-topic. There's a great page to read about covenant proposals: https://covenants.info/. Until this point, I've only known about OP_CTV, and only partially understood how covenants would work with OP_CAT. I think there's another popular proposal, to have both OP_CTV and OP_TXHASH, which would enable transaction templating; ideal for solutions like Ark that need as little interactivity as possible. In general, there appears to be consensus converging to OP_CTV. Sounds like the least risky, and already implemented in Liquid. But, sure, we can use this thread to talk about covenants. I may create one in the future. It's a difficult task, though, but I'd say that OP_CAT will result in block space waste, which wouldn't find consensus under the current status quo, where the future relies on block space being valuable.

Why does that seem suspicious and biased? You claimed that Peter Todd was paid to cover up flaws in Wasabi. It turns out, there were no flaws and Peter Todd never took any money from Wasabi. You made up the false accusation against Peter Todd in order to cover up your initial false accusation against Wasabi. Did you read the research paper closely? Here's what Peter Todd says: In this case, there actually IS proof that Peter Todd accepted money to write things about covenants. So why aren't you claiming that he's being paid to cover up flaws in covenants?

Stop nit-picking, everyone knows Peter Todd is one of the most trustworthy and most intellectually-honest developers in the community. He wasn't shilling for Wasabi. Whether if it was right, or not, for him to say "some things" about other projects, we can be very sure that he was speaking from the side of honesty. BUT he's not perfect. I'm not saying he made a wrong claim or may have said something wrong, but everyone makes mistakes. Back to the topic, Thanks ser, and please tell us what's your opinion on why Andrew Poelstra's OP_CAT is more popular for the users/advocates of Ordinals, rather than Jeremy Rubin's OP_CTV.

So why are you getting upset at me for defending innocent open source Bitcoin contributors against false accusations? Shouldn't you be upset with BlackHatCoiner instead and telling him that he owes Peter Todd an apology for falsely accusing him of taking money to cover up flaws?

There was a topic about it: https://bitcointalk.org/index.php?topic=5220520.0 In general, there was some drama, regarding activation of OP_CTV, and it simply failed. If it wouldn't fail, then we could have OP_CTV first, and Taproot later. However, it is, what it is: soft-forks are difficult to deploy properly. We don't even have a clear consensus, how the next soft-fork should be deployed, whatever it will be. Which leads some people to create their proposals in a no-fork way, because then, it has a higher chance of succeeding. And also, OP_CAT is more generic. Why this is important? Because if you deploy for example OP_CTV, and you find out later, that "hey, we forgot about use case X", then it will be very difficult to activate yet another soft-fork, to add this functionality. However, with OP_CAT, it is more likely to cover everything (or even more than needed). For that reason, there would be quite strict limits, on top of OP_CAT. One example is 520 byte limit (it is unlikely, that OP_CAT will be deployed with a higher limit than that, as long as it is the maximum size of things, which can be pushed on a stack). Another example is 520-bit limit (65 bytes), which would be enough to cover a single signature. So, if OP_CAT enthusiasts will spam too much, then we could go with 65-byte limit, instead of 520-byte limit for OP_CAT. And also, if there will be no consensus for OP_CAT, then there is still OP_CHECKSIGFROMSTACK, which is more likely to be deployed, than OP_CTV, and which can do the same things (and a little bit more than that).

I'm telling you that there's actually no need to be upset. Because if a random pleb from the internet calls Peter Todd a "shill" for "something", then we could be very confident that it's not true. Leave him alone. They tried Speedy Trial? Was that it? But won't that also open the network to more possibilities of actually getting exploited/attacked? It's probably better to take the safer path with OP_CTV, no?

Very shocked Pikachu face here! So with perfect batching transactions, the usability of 90% of the space and no channel recycling, we would be able to create a channel for every owner of the smartphone in 4 years and if we add the obvious fact that business would also require one, make that 5 years. Now since this is almost laboratory style conditions it could be easily doubled! Not a fan of Todd since, well, let's not open another can of worms but I feel vindicated! This aside, I find imore interesting the the delve into the economic aspects of it, I honestly never thought of it why is he debating this versus US bond rates, and why even standalone, what part of the economic problems in this scenario am I missing?

Yes. But at the same time, it is very likely, to get no changes at all, so people are trying to push as many changes as possible, because extending a given thing will be very hard. The process of reaching consensus, talking with major mining pools, signalling support, picking this or that BIP, with this or that activation parameters, is difficult. Also, no matter if you talk about OP_CAT, or about OP_CTV, or about OP_CHECKSIGFROMSTACK, or about similar opcodes in that family. All of them have a huge potential for being "the last soft-fork". Which means, that it will be very hard to deploy them, and each of them will receive a lot of criticism. Another reason for OP_CAT is that if you deploy OP_CTV or OP_CHECKSIGFROMSTACK, then you may need OP_CAT for some use cases anyway. And because soft-fork is a slow process, then if you will get for example OP_CTV now, then you won't get OP_CAT or OP_CHECKSIGFROMSTACK for the next N years. Also, new opcodes will probably not be introduced, if they can be written as a combination of some existing opcodes. Which means, that if OP_CAT will be deployed, and OP_CTV could be re-written as a combination of OP_CAT and something else, then OP_CTV will not be deployed at all. And the same is true if OP_CTV will be there: the first deployed change will likely block all other changes, which can be 1:1 mapped with a slightly longer script. It is not "safer", because it was pushed too fast, and it "failed". It is a similar thing, like sidechains: there was some criticism, and there are still some not-yet-fixed issues here and there. And as long as this is the case, some people will disagree with the whole proposal, just because of that.

I'm not talking about the politics behind the proposal, or the logic behind "why" choosing one proposal over the other. I was merely talking about the exploitability that might put Bitcoin through technically. If the answer to the question is, "Yes, more possibility that the network is open to more exploitability", then perhaps choose the upgrade that does not open it as widely as OP_CAT? I believe OP_CTV and OP_CAT need to be discussed/studied more. Bitcoin as a network/protocol isn't in a hurry.

That's why it is activated in Signet, and also some other networks. And so far, it seems that some use cases are far from being typical, for example: with OP_CAT, you can lock a coin in a way, where you can move it, if you provide some Proof of Work inside your input script: https://delvingbitcoin.org/t/proof-of-work-based-signet-faucet/937 Every change can be always abused and exploited. For example: in TapScript, some limits were lifted, because bigger scripts may be needed for quantum resistance. But instead of going into this use case, people abused it, and created Ordinals. And the same with OP_CAT, OP_CTV, or anything else: it is created for some reasons, but people may always use it in another way. When some opcode is safer to use, then in the long-term, it may be more complicated. For example: we have OP_CHECKSIG, which is very specific. However, if we would have OP_CHECKSIGFROMSTACK, from the very beginning, then maybe things like HTLCs would never be needed in the first place, because you would have just a regular multisig, and it would work for all cases. Which means, that if you solve only a one particular use-case at a time, then you end up with a new opcode for every single functionality, and it will turn out to be more complicated, than just having a single opcode, handling all of them. Also note, that some changes were created specifically to block some use-cases, and it turned out to bring us even closer to the change, that people tried to block. For example: in Schnorr signatures, you cannot use traditional key recovery, like "<signature> OP_SWAP OP_CHECKSIG". However, if you instead use R-value as a generator, and also a public key as a generator, then suddenly, s-value of a signature contains the hash of the signed message (incremented by one). And then, you can actually enforce some transaction data, especially if you don't use SIGHASH_ALL, which will leave you some wiggle room, to make things tick.

Although, let's be clear. If I say "exploitability" I'm not saying something like Ordinals that may open new "uses cases" but they don't break the rules of the network. I'm obviously talking about those actual exploits that could actually allow bad actors to, for example, steal users' Bitcoins.  👍 But if to choose between OP_CTV or OP_CAT, would you prioritize safety and security, or would you make avoiding long-term complications a priority?

Well, with OP_CTV, OP_CAT, or other features, you can create a contract, like "you can move those coins, but only if you reveal your private key". Or: a different contract, like "give me 0.01 BTC to unlock your coins". So yes, a contract like "I can give you those coins, if you steal another coins from here" is definitely possible with that kind of features. And much, much more: https://bitcointalk.org/index.php?topic=278122.0 I wonder if any proposal will reach consensus in the first place. For example: a few years ago, the whole idea of using OP_CAT was rejected. But it went back, because it turned out, that people encountered a lot of cases, like "if we would only have OP_CAT, we could have this, this, and that". Another reason is that it would be under Taproot's umbrella, which means, that it will be always possible to spend by some public key, so it won't be "raw Script OP_CAT" (which could be much more dangerous). So, for me, it doesn't matter that much, which proposal will exactly get merged, as long as some features will be available. And I also wonder, if people will have enough courage to accept any of them in the first place, because long-term consequences are difficult to predict, for every proposal, even OP_CTV or OP_CHECKSIGFROMSTACK. Fortunately, many people are not tech-savvy enough to abuse everything right away, but I can tell you, that a lot of things can be built, even in the current system, but many people are unaware of those possibilities, because of their lack of technical knowledge. So, in general, I assume that nothing will be changed, and we would need to use OP_CHECKSIG in more creative ways, to get some features. But if anything will be merged, then some things may become just a little bit easier to implement. And as long, as it won't bring another wave of abuse, it is fine.