фото показано с : bitcoinmagazine.com

There are many differing opinions about BIP119. This Twitter Spaces conversation aims to clear up some of the confusion and offer explanations.

This is a recording of a recent Twitter Spaces conversation about BIP119 (OP_CTV). If you would like to submit an opinion about BIP119, please email Bitcoin Magazine.

Listen To The Conversation Here:

[0:06] Casey Rodarmor: --BIP repository and they'll request that a BIP number be assigned. If the proposal is sort of coherent and relevant to Bitcoin, the BIP editor will assign a BIP number and also might make requests for editing or make the document more clear, and then the document will be assigned a BIP number and the pull request will be merged into the repo.

I think the most important thing for people to keep in mind when they are thinking about what is the BIP is to just keep in mind that this is not a formal process for what is accepted and implemented in Bitcoin. If you come up with just an absolutely knuckle-draggingly moronic idea for Bitcoin, and it's reasonably well-formed, you can apply for a BIP number. And if it's relevant to Bitcoin and it's well-formed, the editor will assign it a BIP number and add it to the repository. It doesn't mean that anybody is going to implement it. It doesn't mean that it's a good idea. It's just a formal process that ideas for changes to Bitcoin go through before they actually are implemented by anybody.

The main purpose is so that when people go to implement a change, they're going to add it to Bitcoin core, maybe wallets are going to support it, then everybody knows, sort of, what the change is and what it contains. Does it make sense?

[1:44] Mark Goodwin: Yeah, I think that was a very good explanation. It's a lot of sense to me.

[1:47] Casey: Fun Fact: if you go back to BIP 1, the first BIP, which describes the BIP process, it was proposed by Amir Taaki, who is everybody's favorite revolutionary anarchist. I think he took up arms and went to fight in Rojava and Syria, so that's a little deep cut from Bitcoins history.

There's something else that people need to know about BIPs, which is that they don't get assigned an order. It doesn't go BIP-1, 2, 3, 4, they get assigned according to a topic area. And I don't remember what all the areas are but, for example, I know that the drive chain proposal, I think those were like BIP-100, BIP-101, BIP-102, and I couldn't tell you what the other topic areas are, but just keep in mind that BIPs are not assigned sequentially. So, it's incredibly confusing trying to figure out which BIP was proposed, and in what order.

[2:44] Mark: Got you. So there's no ordinal system to BIPs.

[2:48] Casey: That's right. Yeah.

[2:49] Mark: Roger that. All right. Well, then let's get into this particular one. So what is BIP-119 or otherwise known as OP_CTV.

[3:02] Casey: Yep. So, when you have money in Bitcoin, you don't have some balance which is like a number that goes up and down. You have a set of some number of outputs that you control and an output has some value in satoshis and it also has spending conditions, the conditions under which that output can be spent. The spending conditions are encoded in something called Bitcoin Script, which is a very simple programming language. If anybody's familiar, it's very similar to either fourth or PostScript. It's a very simple, stack-based programming language and you can use a script to encode the conditions under which an output can be spent.

So, one of the simplest forms of a condition is the transaction that spends this output must be signed by this public key. And so if you have a normal sort of vanilla wallet, your wallet is going to hold a bunch of outputs that are encumbered by a spending condition expressed in Script, which says that they can only be spent if a signature that matches your public key is provided so nobody can spend them but you.

Bitcoin has a bunch of unused opcodes, so these are things that currently do nothing, and they're reserved for future extensions to the protocol. So, finally getting to BIP-119, what BIP-119 does is it redefines one of these opcodes that does nothing, and it basically says, take the transaction that is like under consideration and hash certain parts of it. Things like the order and value of the inputs, which inputs are used, the lock time, the outputs, who the outputs are being spent to, or like what the locking conditions of the outputs are etcetera. So, it takes the current transaction and it takes all these bits of it and hashes it, and then it requires that that hash match some pre-existing, some hash that's been encoded in the spending script.

So, this is a very complicated way of saying it, but basically, it says that the transaction that spends this output must have a certain form, for example, which coins it spends-- sorry, coins and outputs, in this case, are synonymous. Which outputs it spends, which outputs it creates, and how it allocates satoshis between those different outputs. The name OP_CTV stands for OP, which is operation or opcode and CTV is Check Template Verify. I forget whether check or verify. Basically, it's called Check-Verify because it checks the condition and fails the script if that condition is not met and it's called Template because this sort of combination of properties of the transaction that it commits to is essentially a template for a transaction saying this pending transaction must be made according to this template, otherwise, you can't spend this coin. Does that make sense?

[6:38] Mark: Yeah, absolutely. So, perhaps one of these templates you might call a covenant perhaps?

[6:45] Casey: That's right. Yeah, that's right. Yeah.

[6:48] Mark: So, let's get into that a little bit and I know Jeremy just joined, which is awesome. Hello, Jeremy. Thank you for joining us. We're going over the very basics so feel free to jump in and correct us at any point. But, yeah, let's get into what our covenants are, Casey, and how it relates to that sort of template restriction model you're sort of talking about.

[7:06] Casey: Yep. So, I mean, I'm using the word Template but you could also say that it's a covenant. I kind of like the word Template because it's a little bit more friendly and, to me, at least, it's a little bit more evocative of what the opcode is actually doing. But I think we should restrict ourselves to talking about covenants, so, yeah, a covenant is some restriction that is placed on some coins. So, a very simple covenant is the sort of spending condition that I described before. Where, for example, you can only spend if you provide a signature, with some public key. That's like a very simple covenant, right? It restricts how this coin may be spent. And OP_CTV creates these transaction template covenants where it restricts other properties of the transaction.

Just to give a concrete example of why you would want this, I think the classic covenant example that is used for OP_CTV is that of a vault, so you have a bunch of coins, you don't want somebody to steal those coins, but you do want to be able to spend them. So, you send them into a vault and you use OP_CTV in the spending condition for the vault outputs that you create and the spending condition is that these coins, once you broadcast something like a spending transaction, you can send those coins or let me say this better - you can either send those coins to a hot wallet after some time out, like two weeks, or there's an alternative transaction that sends those coins to a cold wallet.

And so the idea is that the coins are in the vault and you can move them to your spending wallet, but it's going to take some time and at any time while they're moving to your spending wallet, you can, sort of, claw them back into cold storage. And the idea is you're walking around with your spending wallet, you do a withdrawal from the vault to your spending wallet, but then it gets stolen by an attacker or malware, whatever. And so, you have time to broadcast this alternate transaction that moves the coins back to your cold storage, which is like somewhere that you think is going to be safe. So, this gives you the convenience that you can get your funds out, and as long as your hot wallet is not compromised or you have a week or two to broadcast this other transaction, your funds are going to be safe.

[9:49] Guest 1: Hey, Casey, do you want to quickly define how that differs from Child-Pays-For-Parent or Replaced-By-Fee?

[9:58] Casey: Oh, sure. Yeah. So, Child-Pays-For-Parent and Replaced-By-Fee are both ways to replace transactions in the mempool before they've been mined by miners. So, there are ways to incentivize the miners to include one transaction over another. In some cases, they can be used to sort of prevent something that you don't want to be mined from being mined but it's a suggestion to the miners. It doesn't restrict them in terms of what they could do. So, in this case, yeah, you could use either one to sort of try to redirect funds, IE, like you create a bad transaction, maybe you create another transaction that uses RBF to do what you want but it's not enforceable. And then, if this bad transaction that you would like not to get mined is creating an output that an attacker controls, then they can also use RBF and Child-Pays-For-Parent to try to get the money to themselves. So, you and the attacker will sort of both be bidding to try to get the minor to mine the transaction that you wanted. It's kind of similar but it doesn't really provide hard guarantees.

[11:21] Shinobi: Hey, Casey, real quick and correct me if I misheard this, I'm kind of eating right now. But I think I heard you refer to like a normal, like script pov or like a public key script, like just a traditional output encumbrance as a covenant. I really would not consider any type of Bitcoin script a covenant, unless those encumbrance conditions are applied to future transactions. Because just dealing with the output that exists now that allows it to be freely spent, I would not definitionally call that a covenant. The whole notion of a covenant is that it's restricting the future spending conditions when you go to spend the existing output. And in a normal public key script, you have to meet the condition of providing a signature that matches that pov key and verifies but you can freely spend it everywhere.

The whole notion of a covenant is that when you meet any other spending condition, there are still restrictions limiting where you can spend it.

[12:35] Casey: That seems totally reasonable to me. I don't think I've thought about what the precise definition of a covenant is, but I can definitely see where you're coming from. Right? It's like a normal Bitcoin Script determines how it can be unlocked and then a covenant says what you can do with it from there.

[13:02] Shinobi: Exactly. Yeah.

[13:05] Casey: Yep. That's a totally fine definition that I'm perfectly comfortable with.

[13:08] Mark: Speaking in that field right there, one of the often-discussed features of OP_CTV is the time-locked release of funds with an example, sort of being like at the beginning of the month for rent, you can get a set amount of satoshis sent to an accessible wallet, which gives you the ability to still access when you need it knowingly but then also-- [crosstalk]

[13:36] Casey: Jeremy, I think your connection is kind of bad.

[13:39] Shinobi: I'm sorry. Robot Jeremy, can you put regular Jeremy on the phone with us?

[13:45] Mark: Bummer. Well, just to kind of finish what I was saying. The question there - how does this work, and why would a user pay the fee to construct a transaction in this way to sort of limit the amount of touch to their cold storage wallet? Why is this advantageous? Why would this be a feature used?

[14:10] Casey: So, one nice thing about this OP_CTV vault construction is that they don't need to get their cold wallet online. In the normal course of things, a cold wallet stays offline, doesn't need to sign any transactions, and only in the emergency case do they need to bring their cold wallet online and sign transactions. So, that's great. Your cold wallet can be super inconvenient. It can be spread under rocks in six different national parks or whatever and super secure and you can, yeah, just use your Bitcoin more comfortably in a more secure way.

[14:48] Mark: One of the other notable discuss features is sort of lovingly referred to as like, congestion control, sort of, fee market throttle mechanism that allows for distributing evenly in block space fees. How exactly does OP_CTV allow this to happen and make it available? And why would this be a good thing? Why would we want this even fee market?

[15:18] Casey: Right. The classic example is you have an exchange and you have a whole bunch of users who have coins on the exchange and they want to make a withdrawal and they don't actually really care or they have various levels of sensitivity in terms of when they want these coins to be spendable by them. But what they all want is they want to make sure that the coins will be spendable by them eventually. Like, before the withdrawal takes place, they're trusting the exchange to process the withdrawal. So, instead of waiting but let's say, additionally, space is limited and fees on the blockchain are very high.

So, how OP_CTV can help is the exchange can make a single very small transaction, that uses an OP_CTV spending condition, and that transaction is broadcast and mined immediately with a relatively high fee rate, and that transaction using OP_CTV sort of commits to expand into one or more transactions that actually pay out all of the customers. So, imagine, there are a thousand customers, they all want one Bitcoin off of the exchange, the exchange makes this one transaction that pays a thousand Bitcoin to each of these thousand users, but it doesn't actually create those outputs yet. It just commits to creating them in the future and the advantage of doing this is that this initial transaction that commits to paying all the users is very small.

And so, the exchange can pay a relatively high fee rate to get that transaction mined immediately, and once that transaction is mined, there's still another transaction that needs to be broadcast for the users to actually get those funds spendable in their own wallet, but those transactions no longer are relying on the exchange. You no longer have to trust the exchange that those transactions will happen. The initial transaction that was mined commits to all of those transactions. So, those transactions can happen later as users want them and wait for a lower fee rate period to get those transactions mined.

[17:41] Guest 2: So, just to clarify real quick, whereas now we have basically two types or classes of transactions, like in the memory pool, and then confirmed, this would add a whole new class to the mempool which would be those committed [inaudible] is that right?

[18:03] Casey: Yeah, sort of. It doesn't really add them. You wouldn't say that it adds this class of committed transactions to the mempool because transactions are committed, they're mined, and they're not in the mempool anymore. But, yeah, definitely adds this third class transaction state, which is this transaction is committed to be mined and it can be mined whenever anybody broadcasts on an appropriate template transaction that satisfies this.

[18:37] Jeremy Rubin: Well, I mean, Casey, I'd go a step further. It's just guaranteed to happen. Unless that original transaction is reorg out of the blockchain, it is literally impossible for the descending transactions to not eventually get mined because that originally committed output is only spendable through those predefined transactions. So, as soon as that first one is confirmed and has a good amount of work on top of it, all of the ones descending from it are absolutely guaranteed to eventually confirm because by consensus, literally, no other transaction could ever spend that confirmed output.

[19:21] Casey: So, guaranteed just seems like such a strong word. For example, somebody does still need to be holding onto the spending transaction, right? So, if the transaction that satisfies the template was lost and nobody was storing it, then those transactions would never happen. So, I see what you're saying, but like, guaranteed, man, guaranteed is a really strong word.

[19:48] Jeremy: As close to guaranteed as it could be. It's more guaranteed than a lightning channel state in that you can still try to double-spend a lightning channel with different states. But when you're using CTV, there is no other valid way to spend.

[20:05] Mark: Hey, when you have a UTXO, in general, how do you know that you can spend it?

[20:10] Casey: Is this a rhetorical, philosophical question? Do you know that you can satisfy the conditions of the spending script?

[20:17] Mark: Yeah, but until you've actually spent it, you don't know that you could spend it.

[20:20] Casey: Because maybe there's been some soft work that you missed that change the consensus rules?

[20:28] Mark: Sure. I mean, yeah, there are lots of things that can happen or maybe you lose the key in the future, and then you can't do it anymore. Maybe you're asleep for a long time and then UTXO becomes really popular and you don't remember where your coin was or maybe your wallet gets corrupted and then you go get it from a backup and you don't have the latest new descriptors that were derived before your life is backed up and now the money's gone. So, there are lots of things that can lead to issues in this. And I think it's one new class of something in a space of like, a lot of things that can happen like that but it's as guaranteed as anything if you have the information available to you at the time that you're able to estimate that you can receive that fund in the future.

[21:09] Casey: Yep. Yep. I mean or if it got insanely high, like, fees just skyrocket and you're never willing to pay the fees to get it mined.

[21:16] Mark: Yeah. And then how would you spend Bitcoin in the future as well if you're not willing to spend the fees for it?

[21:21] Casey: Right.

[21:22] [ads]

[23:20] Mark: Speaking of the fee market dynamics here, I honestly can, maybe be a devil's advocate here, see why people have apprehension about any mechanism that appears to affect the fee market dynamics of Bitcoin. Do you see any way in which this sort of throttling mechanism could negatively impact this natural market for block space? Is supply and demand curve smoothing a good thing for the open fee market of Bitcoin?

[23:48] Casey: I don't think I have a super nuanced take on this. It seems good to me. It seems like being able to smooth that demand and avoiding spiky fees is good. A more reliable, less volatile fee rate seems good so that people can plan ahead better, but I haven't thought about it enough to think that I have a deep take on this.

[24:22] Shinobi: I mean, in the simplistic case, Mark, when you use something like CTV and congestion control treaties, you’re kind of locking yourself into a fee rate because you're committing to the exact hash of an exact transaction. And so that fee rate has to be specified. So, for all the transactions in a congestion control tree unfurling, that fee is locked in. The only way that you could alter that would be with like Child-Pays-For-Parent if one of the outputs of one of them was freely unencumbered to be spent anywhere. But to go down a little bit of a rabbit hole, if you compose CTV with Taproot, in theory, you could have different tap tree spending paths that commit to different versions of a CTV congestion tree at different fee rates.

So, ultimately, you would either just have this blob of transactions that all have fee rates locked in that regardless of where the highest fee was, they would be in the same fee rate area of the mempool or if you want to go down a crazy complexity rabbit hole, there would be the potential to have different tap trees with different CTV paths and scripts so that you could kind of submit whichever ones you want based on the fee you're willing to pay and what the mempool is looking like at the time.

[25:57] Casey: I think you could also include like a small, anyone can spend output that somebody can use to attach a Child-Pays-For-Parent like at every stage in the unfurling, leave a little dangling output that can be used to bump the effect of a fee rate.

[26:15] Shinobi: Actually, I had not thought about that before right now. Yeah, that would be a lot simpler. It's no punch of different tap tree paths.

[26:23] Jeremy: And I think one thing that's important, too, is you can play with the parameters on anything like that where you could do, like, let's say there are 10 branching factors per node, so then the overhead of having one-off true output is pretty low. If it's 1 over 10.

[26:40] Mark: Sort of interesting it seems to me that covenants are sort of restrictive by design and yet, I think there's a lot of fear about expanding conditions with the new opcode bringing up these sort of unforeseen attack vectors. Do you guys see any validity to this that could come from such implementation?

[27:02] Jeremy: No, not with OP_CTV. With other covenant designs, there are potential worries of things you could do like get coins forever stuck in some extra spending condition they could never get out of. But with CTV, because you have to exactly define an exact transaction ahead of time, it's kind of impossible to make this general covenant that you can never get out of but people can still spend money around because it's not like you can have a CTV coin and then choose where to spend it. It's already decided ahead of time where it's going to be spent. So, there's no way to do weird things like the covenant where the government has to sign off on every transaction you make and can't deny it. That's just not possible to do with CTV.

That's personally one of the things that I really like about the proposal is it's so narrowly defined and specific that there's no risk of that type of thing being done with it.

[28:12] Casey: I think it's also just worth underlining how simple OP_CTV is. It's a very, very simple opcode. It looks at the transaction that's being processed, it hashes some bits of that transaction, and then it asserts that that hash is equal to the hash that it got is equal to some pre-existing hash. It's not like a sort of weird, arbitrary, smart contracting mechanism. It's a very extremely simple construct and I feel pretty confident that not only is it probably useful and probably can be used for the things that people want to do with it, that's like one part, but also, let's say that there was something wrong with it, then everybody could just ignore it. Everybody could just go back to not using OP_CTV and your coins would not be effective and nobody can somehow force you to accept an OP_CTV covenant that you didn't sign up for.

If you send somebody an address, there's no way they can send funds to that address and also encumber them with OP_CTV somehow at the same time. So, it's totally opt-in and if it's bad, you can just ignore it.

[29:33] Mark: Do you think kind of going off that, this would be a good time to define what a recursive covenant is versus not recursive covenant?

[29:44] Casey: Sure. So, a recursive covenant is just a covenant that is recursive - not helpful at all. Recursive meaning that you can say, okay, I have this Covenant X and then when you can satisfy the covenant, you can do something, but then some or all of the coins need to then go back to Covenant X. So, the sort of classic scary example of an evil recursive covenant was, like, the government publishes an address and says, every coin now has to be a multisig that includes this address and additionally whenever you spend from such a multisig output, it's enforced in the covenant that the funds also have to have this malevolent government address as a cosigner to the output. So, the covenant can sort of last indefinitely into the future.

OP_CTV does not enable this just by its very nature. An OP_CTV covenant can specify many steps into the future but it can't specify an infinite number of steps in the future. After some sequence of transactions being mined, the OP_CTV covenant terminates. It can't control what happens further down the line.

[31:09] Mark: Very cool. I guess just to let you know, we'll wrap up the first half hour and then I think we should open it up and kind of talk about the BIP process.

[31:17] Casey: Just go ham, you know.

[31:19] Mark: Yeah. I hope everyone's sharpened their canines and their knives. No, just kidding. All love here. But for me, I think one of the interesting parts of this debate is sort of the ossification versus the necessity of invention and where we have to go if we want to serve, say, five billion people on the Bitcoin Network. So, how could this BIP allow larger numbers of users to open batch channels for Layer Two solutions in a small amount of block space? How is this something that can help us scale?

[31:57] Shinobi: Well, I was just getting my knife sharp, Mark.

[32:01] Mark: Good. Good, Shinobi. Get ready.

[32:04] Shinobi: One of the biggest shortcomings with lightning is the limitation on opening and closing channels and there is just no way around that. If that bottleneck gets too large, then lightning just hits a scaling ceiling. So, CTV cannot-- I mean, Jeremy can probably spitball and get into and help with closing channels. But as far as what he's got written up and designed right now, they could absolutely help open channels and it's literally just everything about how a congestion control tree works, it's just using that, except at the end of that tree unfurling and everybody finally having unilateral control over their coins, they're just Lightning channels, instead of all the coins winding up in a single sig address. And it can be a lot more beneficial than just a normal withdrawal tree because once that initial output is confirmed, you can effectively treat those lightning channels as open and you can use them because, eventually, that tree of transactions is going to unfurl, unchain, and all get confirmed. And then those individual UTXOs that are lightning channels will actually be confirmed on-chain.

And so, like, there are still potentially, issues, really annoying shit, like if your channel counterparty stops responding to you while you can't go close the channel until the tree starts or finishes unfurling. But as long as your channel counterparty is cooperative, the minute that first output in the beginning of that congestion control tree is confirmed to the depth that you require for a normal lightning channel, you can treat all of the channels that that single output is committing to as open and you can start using them. So, it massively increases the scalability of onboarding people onto the lightning network. And that, I think, personally, is one of the biggest benefits of CTV. That is the most effective, impactful use case that I think personally comes out of that.

[34:37] Mark: Do you think right now, Shinobi, that Bitcoin could service the entire world without an additional opcode? Or I guess just additional development beyond just current operational upkeep?

[34:49] Shinobi: No. If Bitcoin froze where it is right now then the reality is 95% of people on this planet are going to be using custodians, they're not going to be able to solve custody of their own coins, and that's just the harsh reality. I think that Bitcoin eventually does have to ossify to be secure neutral money, but if that happens right now, kiss the entire idea of an entire planet of people self custodying their own coins and dealing with things in a self-sovereign way goodbye.

[35:27] Mark: Yep. I mean, if people get priced out of main chain transactions that will certainly happen, unfortunately. Well, not certainly happen, but certainly possible happening. All right. Well, I say, let's open things up.

[35:42] Casey: Can I ramble for a minute about Bitcoin governance?

[35:45] Mark: Please.

[35:46] Shinobi: Can anyone stop you?

[35:48] Casey: No, nobody can stop me. Actually, they can. I'm not a co-host. So, I think it's just really interesting to talk about what is Bitcoin's governance process and it's very chaotic and very messy, and I think that that is very much a good thing. Bitcoin just has all of these different stakeholders, it has users, it has developers, it has miners, it has exchanges, it has services, it has custody providers, it has all sorts of people doing all sorts of crazy things. The BIP process is kind of the only formal bit of governance that Bitcoin has and it's a very weak form of governance. It's not really there to tell anybody to do things. It's just there to sort of tell everybody the things that they might want to do. And I think that this is actually kind of good.

If you think about any sort of formal process that you might imagine for Bitcoin, some sort of vote or some sort of board, or some sort of miner voting or proof of stake, horrible, whatever. Any one of those processes is going to enshrine the ability to ramrod through a not great or a sort of contentious proposal if enough people agree to it. The current Bitcoin process which Jeremy is currently up to his knees in is this very messy thing where you sort of have to explain your idea and explain why you think it's a good idea, find people who want to use it, explain to them how it can benefit them, implement the code, write the spec, etcetera, etcetera, etcetera. But at the end of the day, there's no one party that can ram it through or no official entity that you can appeal to, to make your change happen.

And so that means that like, yeah, you sort of have to get this broad nebulous consensus of enough people and enough stakeholders, and if any one stakeholder, and by stakeholder, I don't mean individuals. But if anyone major sort of group of Bitcoin interests, really hates it, they can stop it from going through to some extent. And I think this is really good. But one problem with it is we do see the situation right now where, not to editorialize, but I think BIT-119 is great. I like it. I think it's simple. And there isn't a clear path for it to get into Bitcoin, but that's kind of because there's no clear path for anything to get into Bitcoin. That's okay but, yeah, also got to deal with some of the inconveniences that that poses. So, yeah, ramble over.

[38:40] Shinobi: Well, to respond to that with another ramble. Maybe the last six or seven years, this is how I've thought about how Bitcoin "governance" works. Bitcoin is just a mob. It's literally a mob of people currently engaged in a mindless thing in one direction and in order to change Bitcoin, you have to get up there and convince the mob to do something else without getting skewered alive, yeah, and that's just how that works. It's total anarchy. Sometimes maybe beating your head on the wall for a long time convince the mob to do something, maybe sometimes you can get a small fraction of the mob to break off and go form another one, and sometimes you get skewered alive.

[39:40] Guest 3: If I may interject there. I maybe interested to get my thoughts because it seems like a lot of the objections currently, I know we haven't really talked about controversy in this talk about controversy, but it's about technical consensus in the idea that CTV doesn't have technical consensus.

[39:57] Casey: Yeah. I mean, the developers are also in the mob, right? So, that's what technical convinces is. It's like talking to the mob of developers and trying to convince them what to do.

[40:09] Guest 3: Well, it seems like the inference with the technical consensus is something that happens before user consensus, right? Like, I mean, it seems from like my reading between the lines with the various threads and telegram channels, I don't know if you guys would agree with that, but there seems to be this overwhelming kind of voice from the kind of older group of developers that there needs to be some sort of technical consensus, and then there's user consensus and then there's that order of operation and it's that order of operations that's particularly in violation here.

[40:39] Jeremy: Hang on. I am very certain that I had a technical consensus. I am very uncertain what technical consensus is but I'm very certain that I have it for CTV and I think that's something that's like a weird position to be in but there's not really a rigorous definition of it. And there's also not really a rigorous definition of what threshold to these things you're supposed to be seeking and there are other parties that matter other than just like developers decided and now it's something that's ready to go. One concept that I really like to bring up is, in Judaism, if you are doing a rabbinic tribunal to decide if somebody should be put to death, just a little bit like a soft work, right? If we're deciding that we're going to put the existing version of Bitcoin to death permanently and we're gonna have a new version of Bitcoin.

If one of the people in that tribunal doesn't say that this person should not be put to death, they get to go free because every life has some redeeming property that should happen. In the same way, every software has some reason why it really shouldn't happen. If nobody can come up with a reason that's compelling that it shouldn't happen, then probably there's too much groupthink, and we've not done an actual job of thoroughly evaluating this thing because we all agree on how it should be. Actually, sometimes descent means that people have put thorough thought into actually considering the reasons why somebody might not like something, and when you see too much consent, consent is not consensus. It means, maybe there's groupthink going on.

And when I evaluated CTV under this regard, what I saw was across the board. The experts who you might want to speak to about this who have actually spent the time thinking about this issue, all basically had around the same line, which is, well, CTV seems okay, but it's kind of a subset of the things that I'm interested in and I'm not positive that the applications built on it will be sufficiently interesting for what I would like to build, right? So, under that lens, none of the experts had an actual issue with CTV as an implementation. Any issue like, oh, this is going to break this, or I think this will have an issue with some aspect of something else. It was just, "Oh, well, maybe I'd want something else in a couple of years," and that's not rival with CTV.

That's just like, okay, well, now, it's really a question now that this form of technical consensus, which is a form of acceptability has been reached, now, it's a question of, well, is this something if you're saying nobody wants to build on this, now, is this something other people want to build on? And if people do want to build meaningful things on it, then cowabunga, let's go. That's technical consensus, let's see what the market wants. And what happened, in this case, I believe, is a bunch of middle manager technical experts popped up saying, "This does not have technical consensus. This does not have technical consensus," without even really defining exactly what that means. And that's sort of where people then got this idea that there wasn't a technical consensus rather than actually making an honest effort at evaluating what other people had actually evaluated and why I was reading technical consensus from the statement of other people who are involved in the technical discussion so far.

[43:43] Shinobi: I mean, to build off that, Jeremy, what comes to my mind is the whole idea of rough consensus from the IETF and the whole basis of that has absolutely nothing to do with voting or a number of people who approve or disapprove. It is entirely about substantial material criticism and whether that criticism has been able to be addressed or not. And the entire notion is that - no matter how many or how few people raised criticism of something, if that criticism has been actually addressed and shown to not be a valid criticism, then something is considered to have a rough consensus. And I have not seen any valid criticism against CTV except we can do better. And if that's the whole argument, well, then that brings up the whole question of - well, how long do we sit around and wait? How many times can people just pop up at the last second, go, here's something that could be better and just keep doing that ad infinitum before we go, "This is enough."

[44:59] Jeremy: Hold on. Let's just say most regular Bitcoiners were against and who cares about whoever's the most influential people are, and even whatever technical consensus means. If most regular Bitcoiners, people that had gone on spaces, go to Bitcoin meetups that you meet at a conference. You know what? We don't like the idea of, kind of, maybe it's cool, maybe it's not. [crosstalk]

[45:32] Shinobi: Do you think that's not a negative? Do you think that's just like who cares or is that considered a negative to you in the process of consensus?

[45:39] Jeremy: I mean, basically, at that point, then they can make their choice of what to run or not to run, and that is the users say who is not a technical person who is not going to get involved in critiquing these things. Like, I'm sorry, dude. I used to be very sympathetic to that argument after Taproot, just no. With all the hoo-ha about Taproot and then after it was activated, most of the people I see in this space have no fucking clue how it works, anything about it. They were just repeating marketing sales pitches like nonsense without any actual understanding of what it can do, what it can't do, how it actually works.

The reality is most users have no fucking clue how any of this shit work or the technical reality of it. They have their choice, which is what to run or not to run.

[46:37] Pete Rizzo: So, is technical consensus, in your opinion, there's no issue, like, there's nothing wrong with it or it's technical consensus that this is 100% good because it seems like that's all this mean, right? Some people think consensus thinks, this is great, everybody loves it, and some people think rough consensus is, there's no problems. It sounds like that's what you're asserting, your guys's definition.

[47:01] Jeremy: Well, I think at least in as far as I can see it, I view the market in the general set of folks who exist in this space is determining some sort of roadmap of what types of way Bitcoin should be moving and I do not believe that is a thing that is in the hands of developers who do technical consensus. I think developers read what the market should be wanting and it asked for people, like how many times have you had a developer approached you and be like, "Hey, how can Bitcoin solve problems for you? Like what's not happening in Bitcoin right now? And what are the issues that you face that you feel are not things you can solve it the application layer?" And in that sort of a thing that you read from the ecosystem and then developers produce solutions for that and determine if those solutions are sufficient for what the market needs.

I don't think that it's a bunch of people who jerk around all day and come up with fancy toys and then put them on the market and see if they do well. To me, you may all agree on what the thing is to put out but really a lot of the process is in finding what the product consensus is, what people need, and what's going to actually solve problems and then determining if you can ship a solution. It's not about getting everybody on board with the thing they're most excited about.

[48:20] Guest 4: Yeah. So, Jeremy, I'm curious. I'm curious for you to agree with me on this. And Pete, this ties into your question as well. So, I think, in your definition of technical consensus versus product consensus, the line to me seems to be technical consensus is - can we agree that this new change does no harm, right? There's no downside that this is like a fine solution to a problem and that it definitely doesn't harm and users of the protocol. Have you guys like kind of like checkbox one and then and I do think actually CTV generally is there and then it's kind of like checkbox two which is, is this the best where best is very relative dependent on what your priorities are, is this is the best way to accomplish this in Bitcoin? Would you agree that that's kind of like the distinction that we're in right now?

[49:12] Jeremy: Yeah. I think so and I think a lot of where that gets tricky is there's like limited attention and limited time and if they're not rival at a protocol level, their rival in terms of what people spend time working on.

[49:27] Guest 4: Yeah, and so along those lines, one thing that has become pretty clear throughout the last couple of months of discussion is on a kind of what applications do we think are most valuable for covenants to enable? It seems like there's like general consensus being an overloaded word, but general agreement at least that the two types of applications are vaults and then payment pools. CTV does those both fine, there's working code for both of them in CPO, but I do think we've released-- that has successfully been shifted to where it's like covenants are good. It's okay to want covenants. And CTV is a non-harmful way to do covenants. Right? And now we have, I think this new third thing, which is the covenant that we introduced should produce really good vaults and really good payment pools, right? I think that's kind of like the current state, which is to be fair, worlds farther. We don't have any of that agreement a year ago, right? So, the conversation has been moved quite a bit, which I think is great.

[50:40] [ads]

[51:29] Mark: I wanted to ask a question. Just when we're talking about like point one of - we're agreeing that CTV does not cause any harm. I think this has been answered and in my rudimentary understanding of it right now, this is one of the things that I've particularly not kept up with at all. Covenants and CTV lately is just kind of been this big blank space for me. The one thing that I feel like a lot of the conversations on Twitter about covenants have been, is this idea of encumbering other people's addresses? Like there was a tweet today or something, somebody was saying, oh, there's a new law and the government says that, you were only going to be able to reset Bitcoin--

[52:16] Jeremy: That's not possible. That's just not possible with CTV. You could with other covenants, but not CTV.

[52:25] Mark: Yeah, I mean, I think it's a terminology issue.

[52:32] Jeremy: Specifically though the distinguishing between the example, because other people were saying, oh, you can just require that you have like a government multisig or whatever. It's like, well, no shit. You got a law that said any stupid thing, right? And it seems like this is obviously should be the case but if I give them my address that I generated from my keys and my wallet with whatever script I wanted and give it to them, it cannot be encumbered with any other CTV restriction. It's just my address and my control, correct? If they agreed to withdraw to it.

[53:14] Casey: Yeah, when you give somebody an address--

[53:16] Jeremy: That's already encumbered with everything, right?

[53:17] Casey: Yeah. Exactly. That address encodes or commits to the Bitcoin script that will spend those coins. So they cannot pay you to that address without using your script, which means that you specify, which means they cannot stick OP_CTV in there without making it essentially paying to a different address which is not the address you gave them. In that case, be sending you the coins.

[53:46] Mark: It didn't seem like that could possibly be the case, just on my understanding of that, but because I didn't quite know, I didn't really understand how a covenant would work any way that you could encumber things later down the road. I was admittedly like a little bit, like, "But how?"

[54:03] Jeremy: Also, I think, this is what a lot of the plebs, maybe, don't get, is that they think that they have formed a strong anti-consensus set with the technical consensus committee bureau or whatever, like, oh, CTV is not the thing but I think what's not really being realized or at least like clearly explained is that the reasons why general pleb kind are like, "Let's not rush this thing in. Let's think about it more," is precisely because there's a worry about introducing some of these really sophisticated complicated things that have a massive social risk for what Bitcoin will look like. And then almost universally, there is technical consensus among the technical wizards that we should have full-blown, pie-in-the-sky covenants. It's just a matter of time until we find the one that we like enough to advocate.

And I think that people don't necessarily see the storm brewing around that question that it is not something as far as I can tell talking to a lot, a lot of Bitcoin users is desired. People want Bitcoin to be the sound money, strongest store of value possible. They do not care about having every possible fucking application. What they do care about is having sound money and having a scale to the largest number of people possible without violating the soundness of the system. And that's really where something like CTV and there are other possibilities for things that can fill in gaps like that. It is a waypoint of not introducing almost anything more than is already possible today with the worst trust assumptions, but still doing something pretty useful that's like a covenant.

Anything more, you do start getting into the territory that you're talking about. And it's a difficult trade-off space, but I don't think people know why they agree to disagree over CTV. I don't think they realize that the way that the core development process or whatever technical consensus process is leading is into something that's much, much, much more complicated and has some of these negative trade-offs for like the what is Bitcoin question. Bitcoin is still going to look like Bitcoin with CTV but these other things will be a very different type of system.

[56:19] Shinobi: To translate that to pleb real quick, anybody worried about weird shit like the government forcing coins into some magic script where the government has to sign off on everything, and those coins can never escape that, it is absolutely impossible for CTV to do that. All the developers arguing against CTV are not arguing against CTV to avoid things like that. They are arguing against CTV because they want more complicated covenants that move closer and closer to things like that being possible. Now, that does not mean that every other covenant proposal out there enables things like that, but that's the direction that technical developers want to go is closer to things like that being possible.

[57:18] Jeremy: And the way that we typically dealt with this kind of controversy in the past with Bitcoin is by being patient. If enough people want to look at other stuff and see how it compares or whatever, like the thing that solves that is time, and one of the biggest things I'm hearing, and one of the biggest reasons there's controversy isn't because I'm hearing anybody say, like, "You know what, screw CTV, we want this instead." I'm not really hearing that. What I'm hearing is really, "We need time so that people can consider other things and CTV itself as well."

I mean, sure, CTV is solid, and pretty much everybody agrees CTV is solid but the thing that I hear people are saying a lot is they feel like we need more time in general, even at general plebs. We just got Taproot. It's so short and you think, well, who cares? Like logically if you're just being logical, who cares? It's good. People like it. It's not risky technically. Let's just do it. Who cares that ?it's not been a long time. I think people do care. And I think it matters.

[58:14] Casey: The complexity of other solutions and the simplicity of OP_CTV. None of the other things that have been proposed or are sort of considered as alternative covenants have the incredible bang-for-buck ratio of OP_CTV. OP_CTV is just so simple. It's like caveman technology and I mean that like in the best possible way. It has limitations, but everything that's sort of more flexible, winds up, being way, way, way, way, way more complicated. I think even if somebody came up with a more featureful covenant proposal, I think there's a good chance that I would still prefer to also have OP_CTV so that I could opt for that incredible simplicity when I didn't need those more featureful things of whatever, some arbitrary future coming that scheme can give.

And that, I think is an argument against why it's not like the sort of just wait and see argument, isn't super compelling for me. It's that, yeah, maybe somebody will come up with something, somebody else after a lot of development. But that thing will definitely be way more complicated than OP_CTV.

[59:28] Shinobi: Let me, really quick, to respond to what Casey was saying. Bitcoin changing is threading a needle. Yes, change should be approached cautiously, things should be analyzed thoroughly, and things should not just be done whimsically, but just look at pay to script hash, CLTV, and how quickly and easily those changes went through versus things like SUG would, like Taproot. Bitcoin is growing. It's getting bigger. And the bigger it grows, the more difficult, the more time-consuming, the more friction there will be to changes. And it's just a simple reality right now. Bitcoin as it is will not be a self-sovereign money for people in the world. It does not scale. It cannot accomplish that goal as Bitcoin is right now that is a pipe dream and we will see how the prognosis from 2010 play out if it froze right here, right now.

Everybody's going to be using banks. No one's going to be self-custodying their own money, nobody is going to have the freedom that that ability affords. So it's threading the needle, it's finding the balance between those two things. We have to approach change cautiously and actually think it through, but we can't just sit here on our asses and pretend like we can just wait forever. Because that day if Bitcoin is going to work will come where it's just not changeable anymore. And if it isn't scalable enough, by the time that day comes, then we are not going to have self-sovereign money for people. That's not going to happen.

[61:21] Casey: I really don't care about like the last five percent of people, I'm gonna still be able to use Bitcoin exactly the way it is forever.

[61:30] Shinobi: No, you won't, Casey. That's a fucking delusional pipe dream.

[61:33] Marshall: So, as a guy who tried to, I guess you could call it core score in my previous life would make it quite a classic. I'll tell you my optics are these - people gave the same, oh, we need to wait. It's like impossibly more complicated and it got in because Peter Wool was a homey of everybody else. Jeremy has pissed on a lot of people. He's pissed a lot of people off because that's just how the development community works. If you have committee access and you're not in the Homeboy Network, it's just a lot harder for you to get shit through. CLTV by Greg and Peter, they're in the Homeboy Network, it's easier to get shit through. That is just the nature of Open Source Development, Bitcoin, Linux, whatever. The fact is, this is more kind of developers bitching and pissing on each other than anything else regardless of the facade of, oh, it's too complex or, oh, we need more time. That's the reality as I see it.

I think the code is great. It's been fully audited. Jeremy has put the money where his mouth is, nobody's claim the bounty. Nobody really has shit to say. The excuse of, oh, we just got Taproot. You got Taproot because the miners were fucking paying attention. Most of the time, we're asleep at the wheel. I mean, let's be honest. That being said, like, that's not a good reason to not do something, and Jeremy and I talked a lot about this and it's up to him to self-market. And that's a big part of what this room's about.

And so in my opinion, as my history in Bitcoin, it's more about who likes you and the commit list and who doesn't like you. That's just kind of the politics as I see it.

[63:18] Mark: Yeah, I think that's a good spot. I'm not going to close it out. I want another 25 minutes for questions from the audience. So if the speakers on stage don't mind, I'm going to start pulling people up. Try and make it brief, ask your question, keep it on topic about CTV, and then we'll have the people on stage speak about it.

[63:35] Guy Swann: Can I say one thing real quick?

[63:37] Mark: Yeah, go ahead, Guy.

[63:39] Guy: In the fact of its controversy, I really think the reason that's drummed up so much controversy, not specifically in the developer community, but just because just in the pleb and Twitter in general, is that nobody knows what the hell it is. Like I still think like we just barely-- I mean how many years really did we spend just explaining the basics of Taproot and CTV, there's been lots of talks of covenants and stuff like the dev list and stuff like when I go through all that, but even I have just been kind of brushing over it because there's just so much of the other shit to go over. And so, what was a very basic question was something that I really didn't know. And the not very, very naive assumption of when someone says, oh, you can encumber further transactions in the future with what it can do, sounds like it could be a bad thing. So, I think a lot of it is just nobody knows what the hell's going on.

Generally, everybody's ignorant and nobody's got any time to cover all this stuff except for the people who do this all damn day.

[64:47] Jeremy: So, I think one thing I just want to add is that when I designed CTV, I literally designed it with that concern in mind, so I wasn't putting something out to then evaluate against, oh, do we do good enough for this? That was literally what I had in mind. People don't want covenants for this reason let me make something. And that's why it's sort of, in a little bit of a weird spot. And then in terms of timeline, like CTV specification was finished nine months before Taproot's spec was finished and the code has been done since then as well. And a lot of why it was not more in the public eye for the last while was people, kind of, I'm not going to say the word 'threatened' but kind of put a lot of pressure on me that if I talked about CTV too much before Taproot got done that I was going to destabilize the process that would lead to Taproot. It was going to be on my back that Taproot failed to get through.

So, I sit down, shut up, I didn't make complaints that I wanted to make about Taproot and I helped get Taproot activated, so that then, I would say, okay, now I can work on CTV. Now, people turn around and say, "Thanks for all the help, Motherfucker, get out of here, get away with your thing." And it's like, "Dude, I literally just help you get your things through so that I could like help get this thing through like, okay." And they're like, oh, but now the bar should be even higher. I'm like, all right, chill, I'll show you more work. I'll show you more work products. I'll make it better. I'm okay with all that, but I think people just don't really recognize what the actual process has been from my perspective, which is pretty freaking dysfunctional.

[66:22] Mark: For sure. Hudson had his hand up a long time ago at the beginning of this. So I just wanted to make sure you got a chance to speak there, brother.

[66:30] Hudson: Thanks so much. Yeah, so, I'm Hudson. I'll do a quick question. And basically, my background is I did some politics stuff in dark coin was kind of early Bitcoin but not super involved in the dev at the time because I was in college and then did Ethereum EIP, which is like BIP but for Ethereum, I was the lead editor.

[66:48] Guest 5: Hudson, can you talk just about Bitcoin, no other coins, please. Thank you.

[66:52] Mark: No, hang on, let him speak. This is a very respected person who's sharing wisdom and I want to learn anything that he has to share.

[66:59] Hudson: Yes. I'm not about to compare though. This is more just I actually learned from the BIP process and stuff. So, that's why I was here. But, yeah, I understand. I totally get it. So, yeah, basically from looking at Leekens' latest thread where they kind of discussed, hey, what's going on with CTV? A lot of what I saw were people who were semi-prominent within the Bitcoin Development Community kind of shitting on Jeremy and I looked into that a little bit more, and what really bothered me about that was that, was just like Marshall said. What Marshall said earlier is basically the summary of what I'm about to say, which is like it's like an Insider's Club. Like if they're going to tell Jeremy that they're not doing the right process or they broke some unspoken rule, why can't Luke Dash Jr. make an alternative Taproot implementation they push out widely and then expect that to go okay and still have all these very high-level accesses to get hub repos they've had for years.

It's like they like shush the crazy person, and just let him do his thing because they don't want to be political or cause conflict. But as long as people like Luke and others who are problematic within Bitcoin or allowed to have that level of leadership, that's kind of a symptom of a bigger root problem of a lack of accountability, a lack of process for how to get these things done. So, that's just kind of what I was thinking on that. But who else has a comment especially it's more into Bitcoin because why is this happening?

[68:22] Ryan Gentry: I mean, Hudson, I wouldn't say exactly from my point of view that it's like the Old Boys' Club and you're just in the club or not. I would just say it's more of a product of things getting bigger, the stakes getting bigger, and people being more paranoid, more skeptical, and just more analytical of people getting involved. Like, I do not see this as like an Old Boys Club that you're either a member of or not. I just see this as having gotten to the point where the degree of trust and respect amongst different groups or different individuals in this group who even, with that respect and that trust there, still are very animus between each other at times and really get into it. It just takes time to build that kind of trust. And I think the bigger Bitcoin gets, the more time that's going to take because people are going to be more skeptical, more paranoid because the stakes keep getting bigger.

[69:34] Guest 5: Ryan, that's not true. Jeremy has been a core dev for longer than damn near anybody else. That's not true. That's just not true.

[69:41] Hudson: Well, I guess the other thing is like, even, you can look at the analytics of it. Like, yeah, Jeremy's had commenced for a while, has had good code, never done anything malicious, but also like from the Bitcoin devs that I hear about like they'll be in groups of people from different cryptos and talk to them and be like, "Yeah, I have this opinion, so and so," it might be either anti-Bitcoin, it might be pro another crypto, nd then they'll say like, "But don't mention that I said this," and it's kind of like in a vein of like, well, wait, why? And it's like, "Well, I can't say that on Twitter because then I'll be outed. I'll be outcast."

[70:14] Ryan: Yeah, I don't know. It's big for the first guest to bring up but, in general, I think Luke has done a ton of great work for Bitcoin. He's widely regarded as one of the devs that understands the system the best and really interestingly, it seems a lot of the rebuttals or a lot of the source of the current controversy is actually, people disagreeing the speedy trial as a method that we should push through upgrades, which was Luke's position to begin with, which I think is pretty interesting. So, Bitcoin is definitely very different than Ethereum. We have our ways of doing so. Can they be improved? Like, of course, is our logic behind the way, things are, yes.

[70:57] Hudson: That's a great answer. Because, yeah, I basically obviously, I'm gonna get like, the worst parts of the drama with that so that's a very good answer. I appreciate the perspective there and unless there's anything else for me, I'll jump off and give my speakers lot to someone else with good questions as well.

[71:11] Mark: Thank you, Hudson. Yep. I appreciate the question. I'm gonna reorganize some of the speakers. So, if I knock you down, sorry about that, but I'm bringing up other people for questions.

[71:22] Casey: I mean, just in regards to, kind of, jumping off that last part, do we think there's been any dangerous precedent set in the way BIP-119 has been proposed with speedy trial? Does anyone take that position?

[71:41] Mark: I am of the exact same opinion as Luke. That speedy trial is a mistake. Jeremy, I said, UASF, I didn't say speedy trial. I said when UASF. I do not like the idea of Bitcoin core or miners or any more tangibly definable group being in control of the activation mechanism for proposals. I think that begins to get political, I think that begins to move in the direction where a more and more identifiable group is perceived as being in control of that, and I think that core specifically and miners should not have any direct role in it, I think things should be done with UASF. I don't think core should be doing anything but writing the validation logic for things. I think activation deployments should come from elsewhere. I do not think that miners should have a veto or an ability to cause something to activate or not. I think that users should be running activation logic and there is either enough of them to strong-arm everyone else along to the point that miners activate because they do not want to see their bottom line hurt to the point that core flips things on in the next release because something else activated it after their initial release with the validation logic.

I do not think that these definable identifiable groups should have anything to do with that. I think that would set the road of capturable processes that can be used maliciously.

[73:29] Jeremy: I don't disagree with that. I mean, I think if you see and read the post that I put out, I literally say, people ask me for AUSF and I've already committed myself that I'm not going to lead any AUSF process because I also don't think that a dev should lead AUSF either. And what I say is, look, I'm putting out a client that can do this. It's really up to the community to decide if this is the client that is the right one for them. And I guess when the question gets asked of like, is there an issue with the process by which I rolled this out? The question really is - what did I roll out? I rolled out a blog post with links to software people could build. I didn't go and say, "You have to run this." I didn't misrepresent what the action-reaction consequence or anything would be, it's like, "Look, here's software. If this is the software that you want that you think people should run, do it."

I even say you should get real loud and tell people why they shouldn't run this. And I think where it's been surprising to me is people haven't really read that I was inviting them to shoot it down. And then they're getting very personally aggressive towards me, rather than just like politely saying, we shouldn't do the proposal that you put out which I was clearly very open for that feedback. And now I think in terms of AUSF, it is more clear that that's the thing that should happen if there's something for CTV, I'm a man of my word, so I'm not going to lead the charge there, but I'm not also not going to be like sitting on anybody who's trying to do that.

[74:52] Ryan: Great brief word of clarification, Mark. I would say, like Jeremy just said, BIP-119 in this current controversy is just following the process that works for the last software. So, if there was any troubling precedent sent, it was set with Taproot not with what's happening right

Similar to Notcoin - Blum - Airdrops In 2024

origin »

185 +