Thoughts on BIP-119 - OP_CTV debate ?
58 sats \ 9 comments \ @criptoluis 9 May 2022 bitcoin
As a journalist I've been covering the OP_CTV proposal described on BIP-119 since 2020. I've seen this development evolve as well the discussion around since then.
I've learned that while recent activation proposal could be considered a kind of attack on Bitcoin, OP_CTV can be a good functionality to add to Bitcoin, but it needs more revision by other peers as well the users (market) doesn't seem to be engaged about it yet (there's no demand for this)
I wrote three articles last week on the different angles of the debate. Even tho it's in spanish, I post this here to connect with other peers as me and some other friends are looking to post more spanish written content on Stacker.News. Many people seem to ignore we hispanics are hardcore bitcoiners too ;)
So here are the articles as publishes on CriptoNoticias.com:
  1. Why some developers oppose BIP-119? : https://www.criptonoticias.com/tecnologia/controversia-bitcoin-por-que-varios-desarrolladores-oponen-bip-119/
  2. Why developers doubt about technical integrity on BIP-119? : https://www.criptonoticias.com/tecnologia/desarrolladores-bitcoin-dudan-integridad-tecnica-bip119/
  3. Jeremy Rubin's reasons for activate BIP-119: https://www.criptonoticias.com/tecnologia/cuales-son-razones-favor-activar-bip-119-bitcoin/
I'd like to read your thoughts on this debate and share ideas with you.
write
preview
related posts
11 sats \ 1 reply \ @Majjin 9 May 2022
I like CTV, but I don't think it has to be activated right this minute. The good thing about this debate is that it got a lot more people to actually look into the soft fork. Most people don't keep on top of new developments on Bitcoin. It will take a while, but I think the right time to activate is when a lot of people are educated on the topic and its as uncontroversial as Taproot was.
I think that the Bitcoin Core devs really need to make more of an effort to clear up communication with developers outside their bubble. We don't want the code to be centralized around a small group of devs.
reply
10 sats \ 0 replies \ @criptoluis OP 9 May 2022 freebie
Agree!
Just one thing: Bitcoin Core has centralized Bitcoin protocol implementation. That's a good thing as having many different implementations can be a serious challenge in regards of compatibility between them.
That said, I like core work and I respect their decisions to not include other proposals or developments in their code, but i definitely agree they should have better communication outside their bubble.
Also, I've read some proposals on bitcoin dev mailing list about creating new consensus mechanisms besides voting with your node. I will look forward on what this whole debate can generate in the future. Thank you for your comment!
reply
5 sats \ 2 replies \ @TheBTCManual 9 May 2022
I like the functionality but don't think it's something bitcoin desperately needs right now or even in the next few years. I say add it on Liquid for the minority of people who would use it and lets move on from the debate
reply
5 sats \ 1 reply \ @criptoluis OP 9 May 2022 freebie
Haha! Adam Back said something similar but I think they are working on some other kind of covenants. Also, there's a chance for Litecoin to implement OP_CTV too and see how it works, as they did with SegWit.
reply
0 sats \ 0 replies \ @TheBTCManual 9 May 2022
LOL, well it would give some of us a reason to use liquid :P, and we don't have to annoy wallets providers with changing their roadmap to support it for those who may not run their own nodes.
I'd also like to see if its live on a side chain so we can see how these exploits people talk about can be done, lets battle test this one in real time
I had no idea they still do work on litecoin lol, colour me shocked.
reply
3 sats \ 1 reply \ @timechain 9 May 2022
There was a great point raised by Guy on Bitcoin Audible (Guy's Take #54). He makes an argument not on the code having any bugs, but a possible game theory situation where commitments that could really disrupt block space economics.
Here's my best summery of the idea, please listen to the episode, he does a much better job:
It involved the possibility of exchanges wanting to do withdrawls to one address with commitments to each customer. Of course people will eventually have to unroll (and pay fees) (burden placed on customer, not exchange) to truly get their bitcoin. People said this could get used to get through periods of high congestion, however it will always save exchanges money, so why wouldn't they, even in periods of low congestion. If all things remaining equal, fee market-wise, early "unrollers" have to pay more fees, pushing off unrolling but, as blockspace becomes more scarce, people will start to panic by unrolling all their utxos. Soon all the accumulated "blockspace debt" will be attempted to be paid off, spiking fees crazy high. John Carvalo called this a "tx grenade." In addition, it also is a great way to spam network without paying much fees.
Once again, he explains it alot better. If 119 goes through, awareness needs to be raised that although its good to get your coins off exchanges, commited utxos are only truly yours once you pay your fee. Which can be really low like now, or really high in the future, exacerbated by people FOMOing into unrolling.
reply
0 sats \ 0 replies \ @criptoluis OP 9 May 2022 freebie
This is surprising. Certainly, exchanges wouldn't have the incentive to pay for fees even in low congestion moments. This could be done with a simple modification on their terms and services and leave this responsability to their clients. Definitely, in the long term, Bitcoin is destined to base its security on user transaction fees.
Thank you for your comment!
1 sat \ 0 replies \ @fanis 9 May 2022
I like CTV and what Jeremy tried to do with it: proposing a quite minimal implementation of Covenants so that we can take this first step without too much risks. On the other hand, I think that's what got him:
  • some people don't want CTV because it doesn't provide full capability covenants while still requiring a soft fork (and the associated risks) and are more in favor of waiting for another implementation that might take more to the table in one soft fork.
  • other people repeat the non sense they see online and believe CTV is extremely dangerous because it enables some covenants. Well, it's not.
  • other people don't understand what covenants are.
On the other hand, I'm not even sure Jeremy himself strongly believed the activation would happen as he laid down in his plan. To me, the purpose of the move was much more to make the discussion finally happen, and gather as much feedback (negative and positive) as possible. In this respect, Jeremy's strategy succeeded tremendously. Now, I just hope it didn't alienate too much a part of the community to the sole idea of Bitcoin Covenants in the process.
reply
0 sats \ 0 replies \ @itsrealfake 9 May 2022
i made this comment in a diff thread
enabling CTV seems like a pretty obvious attack vector to me.
  1. create a covenenant that prevents spending to non-whitelist addresses
  2. enforce miners/exchanges to only allow sending to addresses utilizing the covenant
  3. all of the sudden, hodlrs are corralled.
reply