BIP119/OP_CTV: is this a unilateral fork, and does anyone care?

[Carlton Banks]

according to https://utxos.org/signals, the answer to my question is no.


But if we look at:

https://bitcoin/bips/blob/master/bip-0119.mediawiki

...and https://github.com/bitcoin/bitcoin/pull/21702

then it is a little less clear.


Some reddit personalities (who are also devs in some cases) have expressed disquiet that the author of BIP119/CheckTemplateVerify is acting too unilaterally, and for sure, he is not following the process that previous soft-forks went through in order to gain acceptance.


So I guess my question is not technical: is this not inherently political, even if BIP119's author intends it to be, or even realizes it at all? Because the proposal seems ok, but it seems that acceptance of this way of working sets a precedent for someone else to propose similar such fork-activations, only to claim "this is how forks are done now", then we might have the Classic/Unlimited/BIP10x/hard fork nonsense repeated again.


usual thread rules; no trolling, no trolls

sorry if off-topic, feel free to move

[1714907150]

1714907150

[1714907150]

1714907150

[1714907150]

1714907150

[1714907150]

1714907150

[1714907150]

1714907150

[Carlton Banks]

Note that I'm deliberately not calling anyone out by name.

The reason is to try to keep anything personal out of the discussion, but that's just my style for this, do as you feel when replying.

[takuma sato]

There's a number of people showing concerns about this including Adam Back.


    Adam Back: https://twitter.com/adam3us/status/1477958056776540164?s=20

    AJ Towns: https://twitter.com/ajtowns/status/1478053356337655808?s=20

    Bob McElrath: https://twitter.com/BobMcElrath/status/1478041639608332294?s=20

    BitcoinLizard: https://bitcoinlizard.net/@lizard/107551151151139108

    Bitcoin Mechanic: https://bitcoinhackers.org/@bitcoinmechanic/107559135239166278

    BlueMatt: https://twitter.com/TheBlueMatt/status/1477818234153930752?s=20

    darosior: https://twitter.com/darosior/status/1474375244991369218?s=20

    francispouliot_: https://twitter.com/francispouliot_/status/1477839674253131778?s=20

    John Carvalho: https://github.com/JeremyRubin/utxos.org/issues/28

    Michael Folkson: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019728.html

    Neil Woodfine: https://twitter.com/nwoodfine/status/1478322485137272838?s=20

    OneSirMeow: https://twitter.com/OneSirMeow/status/1477793495414943747?s=20

    Peter Todd: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019738.html

    Sachin Meier: https://twitter.com/SachinMeier/status/1474511286205562882?s=20

    yojoots: https://twitter.com/yojoots/status/1477837507588939778?s=20

    zndtoshi: https://twitter.com/zndtoshi/status/1483520867971776530?s=20

[Carlton Banks]

it was cancelled, so any concern is already out of date

I'm not sure, I find the whole episode a little bizarre, but I considered the author's behavior was consistently... odd, in respect of the course of BIP119. So, consistently odd, is, well, at least consistent.

Still, show's over I think.

[BitoKoing]

The way the dev acted seemed incredibly suspicious to say the least. I'm glad the community called out his bullshit and the way he tried to impose this fork on BTC. This guy seems to be either backed by powerful economic actors who don't like BTC or a narcissistic silicon valley style dev, maybe a mix of the two.

Is it really over? We must always keep our eyes open to tricks like this.

[garlonicon]

Is it really over?

No, it is not. It failed once, but definitely it is not over. People are trying to sum it up, and create the same thing in a different way. Because, as with each proposal, there was a feedback. And it will be processed, some things will be changed here and there in some BIPs, and then it will come back later, in a different form. Why? Because some people want covenants, vaults, and other stuff for their protocols and applications.

[DaveF]

There should probably be a discussion of is this the best way of doing it, if so fine lets keep it this way and make it a procedure. And if you don't follow it feel free to leave.
OR
This is the way we do it now, lets have a long discussion with a lot of input from everyone and come up with a process to do this.

....but it seems that acceptance of this way of working sets a precedent for someone else to propose similar such fork-activations, only to claim "this is how forks are done now"...

And that is the core of the issue. If there is a list of steps, and things that need to be submitted and how to do it and where to do it and what is needed. And once all of that is done, these are the next steps.
It is a lot more difficult to have things like this happen.
Because, if every time more BIPs show up, and the acceptance process is although well documented, does vary a little bit over time and how people see it.

Which is the issue. What is a little bit? OK fine *that* is a little bit, here is a little bit more. And then 10 years from now you can't even see where the 1st little bit was because the acceptance process has changed that much. If it is written down and followed to the letter although it does make things more difficult it will prevent things like this. And if *anyone* wants to change it, everyone (or a majority or 75% or whatever) has to agree.

-Dave

[n0nce]

Is it really over?

No, it is not. It failed once, but definitely it is not over. People are trying to sum it up, and create the same thing in a different way. Because, as with each proposal, there was a feedback. And it will be processed, some things will be changed here and there in some BIPs, and then it will come back later, in a different form. Why? Because some people want covenants, vaults, and other stuff for their protocols and applications.

What do you guys think about just building such things on top of 'layer 2' or even 'layer 3' in the future? I think there's a very compelling argument to be made that changes to the core of Bitcoin should be made very carefully and only if really needed; you can put the latest cool stuff on top of Lightning or Liquid [1] and experiment with it. If something goes wrong in LN or the sidechain's new interfaces and abilities, it doesn't hurt or affect Bitcoin itself.
Trying to cram everything into layer 1 feels a bit like overbloated kernel drivers, which obviously crash the whole system if there's a single segmentation fault. Just like you keep your drivers minimal and put all the logic into userspace, I believe we have to keep Bitcoin layer 1 minimal and put 'the logic' like complex smart contracts on higher layers. That way people can always go back to layer 1 when they're done with their NFT trading, lending, betting or whatever the new hot shit is and want to secure their capital back into the trusted, immutable L1 blockchain.

[1] https://www.bitcoinlightning.com/what-is-the-liquid-network-sidechain/

[garlonicon]

What do you guys think about just building such things on top of 'layer 2' or even 'layer 3' in the future?

I think it is partially possible. And this is the key: "partially". Because you can always form a federation, and just create any consensus rules on top of Lightning, but it will not be enforced by the first layer. So, the question is: how to enforce things on the first layer if needed? Because sometimes it is not possible without soft-forks. For example, sidechains could be deployed today as federations, but they cannot be deployed independently, in a trustless way, where anyone can be a miner, without asking for permission. Another thing is that some soft-forks can be unstoppable. For example, Paul Sztorc proposed sidechains. If you add that, then it is possible that no future soft-forks will be ever needed. And that could be dangerous, and lead to some problems, that you can observe in other chains, like ETH.

So, another reason of rejecting proposals is that inserting few lines of code here and there could implicitly add features that are unexpected or unwanted. For example, adding OP_CAT or OP_SUBSTR would mean that writing quines will be possible. Adding OP_CTV could allow recursive covenants, that could be used to trap another party into endless money eater. Another thing is that more complex and generic solutions are created: instead of adding new opcodes, people now think about new sighashes. Imagine adding SIGHASH_PREVOUT_SINGLE that would require a signature, where all previous outputs are hashed, but only one input is taken. Or even SIGHASH_PREVOUT_SINGLE|SIGHASH_PREVOUT_ANYONECANPAY, getting one-input-one-output from the previous transaction. Or maybe selecting each field by some bit-mask, where you could decide explicitly for each field, if you want to include that or not, by saying that you want to sign version, locktime, and one output of the previous transaction (and zeroing all other bits in some sighash).

To sum up: everything is flying, we don't know the future. People are worried that one simple change could cause a butterfly effect, and will force people to implement and support a bad proposal always and forever. Now we are in some "brainstorming phase", where everything can happen.

[odolvlobo]

In my view, the major objection has been that it doesn't follow "the process". I feel that any change should be judged on its merits and not on whether it follows "the process" or not.

I feel that having to follow "the process" leads to centralization, as having a process requires someone to dictate "the process" and someone to enforce "the process".

[NotATether]

So, another reason of rejecting proposals is that inserting few lines of code here and there could implicitly add features that are unexpected or unwanted. For example, adding OP_CAT or OP_SUBSTR would mean that writing quines will be possible. Adding OP_CTV could allow recursive covenants, that could be used to trap another party into endless money eater.

It wouldn't be too hard for Btcoin Core's script validator to put a limit on the number of commands executed recursively within a script.

So, if we restrict a bunch of OP_CTV's to occur at most once in the stack (of instructions), this problem you entioned would not exist, because it stamps out opcode nesting.

[garlonicon]

Again, it could partially work. Because you don't need full recursion inside a single transaction. You only need single recursion that is endless. For example, you could create a covenant that will allow moving coins from 2-of-2 multisig to always the same 2-of-2 multisig. Then, you could theoretically get a working channel, but in practice it would be impossible to close it without opening it again. And then, another party can always require at least N satoshis (or refuse to sign it), then you are endlessly locked in a channel.

Then, it does not matter that recursion is Turing-incomplete and can be easily checked in a single transaction, without reaching any limits. In practice, you can only send coins from multisig to multisig, you cannot move them somewhere else, burn it, or do anything else, because it is enforced by consensus.

And again, if OP_CTV allows quining, then it cannot be safely deployed. Even if you can only do a single recursion, it may be enough to form a quine. Or you can always do A->B->C->A, instead of A->B->A or A->A.

[Carlton Banks]

In my view, the major objection has been that it doesn't follow "the process". I feel that any change should be judged on its merits and not on whether it follows "the process" or not.

I feel that having to follow "the process" leads to centralization, as having a process requires someone to dictate "the process" and someone to enforce "the process".

right, I made a mistake in the OP in that I didn't mention that no formal process exists, and I think this is both intended and with good reason: any attempt to codify such a thing now would be to invite every vampire, goblin, three-headed dog, minotaur and necromancer to the proceedings before the serious trolls even arrived. If the opportunity couldn't be used to insert a flawed procedure into the project, then it would be equally useful as an attrition device instead, to wit the recent full-RBF nonsense, or the weirdo Github account that drones on endlessly about formalizing the process for adding maintainers. In the past, I think the original group of developers (2010 to ~2018) were good at settling points of disagreement about the project without resorting to hair-pulling, they were either truly sticking to technical arguing points to conform to the spirit of the white paper, and/or too busy to behave otherwise

[NotATether]

In the past, I think the original group of developers (2010 to ~2018) were good at settling points of disagreement about the project without resorting to hair-pulling, they were either truly sticking to technical arguing points to conform to the spirit of the white paper, and/or too busy to behave otherwise

So what's the deal now? Is it going to be more roasting on Github PR threads like the FullRBF debacle for the foreseeable future?

Because already it seems that a higher percentage of proposals are getting jammed at the mailing list these days. I.e. less features being added. And those features that do get added like Taproot take forever to get to every wallet implementation and platform.

[Carlton Banks]

seems like mostly healthy debate from what I've seen. There's a decent amount of new development going on, maybe it's not that visible because it's not in github projects board? (i'm using github as a webpage pretty minimally these days, so I don't know what bitcoin development looks like through that particular lens)

the fRBF stuff? it would be so trivial for some grey-hatter to in response destroy one of these 0-conf businesses with a targeted attack, so it was never going to amount to much anyway. I wouldn't be sympathetic if something like that happened, "a fool and their money" etc.