pull down to refresh

Discussion has begun again on if we should activate BIP 119

OP_CTV provides the most functionality for how simple it is. There is also a technical audience that thinks that we should activate. There are also some proposals like LNHance that also incorporate OP_CTV into a combo of opcodes that they want to activate.
One might argue that some people may have reviewed OP_CTV and not found anything, but there is no monetary incentive to research and identify issues. The only thing is that there is a GIANT bounty of 5.5 BTC to be claimed if someone finds a problem with OP_CTV. It has been almost 5 years since the bounty was opened.
OP_CTV also provides the path to many upgrades to the Bitcoin ecosystem, some being
  • Vaults
  • Channel factories
  • Joinpools
  • Congestion control
  • efficent DLCs and more
So I urge the readers to learn more about OP_CTV and to take it one step further by asking your peers to activate OP_CTV.

Questions

  • What do you think about BIP 119?
  • Would you activate BIP 119?
  • Do you have any concerns about BIP 119?
  • Would you rather ossify Bitcoin?

Resources to learn more about OP_CTV


Please boost and share this post if you think BIP 119 should be activated
it its worth noting there is a similar opcode OP_TEMPLATEHASH
279 sats \ 0 replies \ @optimism 7h
Per https://en.bitcoin.it/wiki/Covenants_support, there are still some no 1 and a handful of weak 2. I think that with a functional demo on inquisition (or a similar signet), the notable no can be addressed and, if the weak opinions are correct that there is not enough benefit to be had on its own, this can also be used to show a combination.
Instead of building an activation client, build a signet.

Footnotes

  1. most notably jonasnick/e9627f56, which is comprehensive
  2. mostly arguing that it's too small a benefit to activate it on its own (instagibbs/eeb9d801, delbonis/14d1802c).
reply
18 sats \ 1 reply \ @ca 17h
Who said it was a technical question?
reply
What would you say the objection to the BIP is?
reply
What's got the skeptics worried?
reply
They might be worried in general and would rather ossify than do something that may make sense
reply
It has no technical merit
reply
In this post, you just mention that OP_CTV will be used for Ethereum like contracts, but you don't specify why that doesn't makes Bitcoin not used as money and instead for centralized applications.
Vaults, Congestion control, and efficient DLC's can be done in a self-custodial manner, which is enabled by OP_CTV, so I'm confused where that generalization is coming from. There may be SOME applications that are centralized but without OP_CTV, they WILL be built in a centralized manner because they cannot build it any other way.
Care to explain?
reply
Ethereum like contracts, but you don't specify why that doesn't makes Bitcoin not used as money and instead for centralized applications.
ETH trash is centralized applications. So is every fake L2.
Vaults, Congestion control
Already debonk'd vaults and congestion control in that thread, those are absolute straw grasping nonsense.
DLC's
Haven't seen much on these yet but also sounds desperate, the whole idea of DLC's are defi adjacent and equally retarded. They still depend on an oracle, and what you're ultimately trading on them is credit, not money. Handwaving more defi jibberish as a use-case and calling it ok because its self-custodial is not technical merit.
This script kiddie attitude that Bitcoin needs to be part of an application stack for these nerdsniping projects for people that don't appreciate what Bitcoin already is has got to end. Let it be with this worthless shitfork.
You do realize its value is upstream of why you are even here? and that the only reason it is valuable is because its stable, predictable and resistant to being a sandbox for hipsters? Hipsters that can't appreciate a neutral world reserve currency for what it is and will therefore never be happy with it?
reply
Do you think there is any soft fork currently that would be worth while or worth exploring or are you pro ossification?
reply
I'm not dogmatically pro-ossification, I reserve the right to update the battle plan if the battlefield conditions change, but I'm not aware of any new op_code that solves a mission critical problem on the world reserve currency.
I think a lot more important things could be done on the shell if people weren't trying to bastardize art to fit in with the DeFi clowns. I attribute most of that to mis-aligned incentives, how long until you announce you've been working with Spiral or other NGO?
reply
I agree with you, a lot of these L2 proposals smell a bit like feature creep to me, like putting the cart before the horse, make-work to justify the existence of pre-existing engineering teams or organizations.
That being said, what do you see as the current mission critical problems, and which ones are of a technical nature?
reply
I don't see anything at the base layer, I know there's one or two consensus cleanup items that need a patch eventually, but even that narrative has been diluted by people that want to bundle in a bunch of non-critical items and spread fear so people act hastily.
If something is imminently critical, and real, the fix must be acute. In that scenario it will have no problem getting consensus. Ossification is a straw man they loom over people to say if we don't fix things the way they want today we'll never fix them.
Mining centralization is at spooky levels, but that's a market condition that is transient and already healing by the day.
Distribution is a concern, but not critical. That's a reflection of the real world economy, so again market driven, not technical.
Culture/incentives are probably the biggest risk, there's very few principled people that have the ability to do principled things. Fortunately, bitcoin's technical design is literally built to mitigate that cultural/incentive risk. Every time a script kiddie or NGO wants to change Bitcoin I appreciate it for what it is even more.
reply
0 sats \ 0 replies \ @ek 7h
If something is imminently critical, and real, the fix must be acute. In that scenario it will have no problem getting consensus.
What makes you believe it will be easy to convince more and more users of anything, when I think we agree we live in a world where most people can’t think for themselves and just trust and believe mainstream narratives?
In your opinion what is a mission critical problem that you would like to see addressed with or without an op code?
Ik you mentioned utxo ownership as one of your concerns before.
reply
None imminently critical.
utxo ownership as one of your concerns
Distribution is a concern, obviously more distributed is better, but that's a market/econ function not a technical one. Reality is most of the world doesn't have any money to save at all, and the relatively few people with a lot of money to save can buy an out-sized share of Bitcoin, which compounds the problem of distribution because Bitcoin is so scarce. Every wealthy person that buys Bitcoin makes it more expensive for someone with no money that doesn't have any.
Distribution relative to scarcity also creates price risk for early adopters, any purchasing power above Saylor's cost basis is less reliable than it would be were those coins more distributed.
Not a concern, but a reality, is that distribution is only technically limited by supply. That is a recognition that trust and centralization are necessary for "scale" to a mythical cohort of users, but does not imbue the notion that trust and centralization must be accommodated in Bitcoin itself, as trust and centrality are external systems.
reply
75 sats \ 6 replies \ @ek 9h
Didn’t you build CLINK ndebits with the assumption that the one who wants to get paid needs to sign the events? So it turned out to essentially be a protocol for custodians, unless that assumption is broken, including the UX of it?
And then you complain about centralized applications? That’s funny, ngl
reply
21 sats \ 2 replies \ @Taj 6h
You waited till he was sleeping to throw that grenade, will wait till he wakes to watch the show 😂😂 ⚰️
reply
25 sats \ 1 reply \ @ek 5h
I didn't wait; I live in a different time zone, that's all.
You can subscribe to my comment via ... to receive notifications of any replies.
reply
0 sats \ 0 replies \ @Taj 4h
🤣🤣
reply
turned out to essentially be a protocol for custodians
LNURL became a protocol for custodians, because the setup lift is too high for casuals. Pub/CLINK solves that for self-sustodians.
centralized applications
Pub is DE-centralizing, by being self-hosted software hitting a new lower bound on setup lift.
Not sure if you're trying to be funny by comparing self-hosted Lightning node software to Bitcoin consensus changes based around at-scale central-coordinators.
By your logic Bitcoin Core is itself a centralized application.
I'll assume it was a bad joke and you're not that retarded.
reply
0 sats \ 1 reply \ @ek 1h
Cool, you dodged my question about how you designed CLINK and instead started talking about Pub. Reads like what I said is true, but you're too embarrassed to admit it here.
For other readers, here is my discussion with him on GitHub about this issue.
reply
Pub is the CLINK reference server, CLINK is a protocol of Pub philosophy, no high-friction web-server required, maximum distribution.
Subscriptions are one functionality, and yes people subscribe to services. Your landscaper provides a service you subscribe to, and he invoices you periodically for that service. CLINK also does ad-hoc.
How is that catering to a custodian? How is enabling small business that functionality in disintermediated way, when it hasn't been available, centralizing over decentralizing?
The only embarrassment here is your desperate attempt find an equivalency to NGO astroturf and being a person in a technical position with zero grasp of architecture.
Are you too embarassed to admit that you're actually not that technical and the average landscaper running a VPS threatens your ego? that the elitist NGO gatekeepers who want at-scale centralized neobank solutions are your idols?
reply
Everything becomes classic in this terminology.
reply