CTV+CSFS: Can we reach consensus on a first step towards covenants?

[AntoineP]

@stevenroose

Bitcoin users don’t use the bitcoin protocol. They use applications that application developers built on the protocol and it is these application developers that use the bitcoin protocol.

I mean… sure? What’s your point here?

@stevenroose

Bitcoin users shouldn’t be interested in DLCs.

I am interpreting this charitably as “Bitcoin users should be interested in applications enabled by DLCs, not by DLCs themselves”. I wholeheartedly agree and this has been a point i’ve raised a few times already: for consensus changes we should consider what is enabled to Bitcoin users down the road, and should only consider tools made available to app developers insofar as it may bring benefits to end users.

@stevenroose

You mention a failed company building on DLCs, while @1440000bytes mentions one that raised 30M in funding last week. Only mentioning one or the other is misleading.

I am sorry if this came across as misleading, this was absolutely not my intention. I am merely pointing out that we’ve been hearing about DLCs for years, companies were built to bring applications it enabled to market, and the market shrugged. Others also pointed out the lack of traction did not seem to be due to the performance limitations that would be lifted by CTV.

If DLCs are going to be used as a motivation for a CTV soft fork, it seems appropriate to ask how it’s going to 1) actually improve an application that 2) users actually care about.

@stevenroose

@AntoineP

Has BitVM seen any adoption from Bitcoin users, either directly or indirectly?

Again, no. Users won’t use BitVM, but developers will. And they are. BitVM is obviously a very young and complex project, but multiple teams with ample funding have been building an implementation in the last year.

Obviously my question about indirect users of BitVM was about whether anyone was using an application that a developer leveraged BitVM to build.

And if we are going to be uncharitable in interpreting each other’s points here let me be clearer. Handwavy claims about speculative applications of a not-yet-existing protocol are not appropriate to justify a Bitcoin soft fork in the near term.

You’ve also mentioned funding a few times now. Funding is good, and is a signal to take into consideration as presumably people that are putting money on a table have an incentive to properly research the market fit of a product. But this can’t be blindly followed in decisions about changing Bitcoin’s consensus rules, for obvious reasons.

@stevenroose

To me this shows that there is great demand for this expressiveness and developers are going to extreme lengths to obtain equivalent behavior in the ugliest possible ways.

There is some demand for more expressiveness from application developers for sure, that’s why we are here. But again, what should be demonstrated to motivate a soft fork is whether there is demand from Bitcoin users for the applications this expressiveness would enable.

@stevenroose

I find is quite disingenuous when people point to the lack of implementations as an argument against a protocol upgrade.

I don’t see how it relates to your quote of my message, but let me reply to your point in general. I think it’s reasonable to demonstrate usecases if they are going to be used as a motivation for a soft fork proposal. Demonstrating a usecase does not mean building a production-ready application. It merely means showing there is demand for the usecase and that the proposed change does indeed enable the usecase.

I guess what i’m describing is something akin to the “power user exploration phase” in @ajtowns’ Bitcoin Forking Guide.

@stevenroose

First of all, there were 0 implementations of taproot when it was deployed,

Huh, what? What does Taproot has to do with all this?

@stevenroose

we cannot expect our developer ecosystem to be building on features we are still pondering to even add or not

I think my previous comment addresses this, nobody expects a full production application to be built to motivate a soft fork.

@stevenroose

There is an enormous difference in time commitment between brainstorming how certain primitives can be combined to achieve certain functionality, and actually implementing them. I think people with sufficient experience don’t need the latter to be convinced of the former.

Maybe i don’t have enough experience, as you seem to imply, but i would argue the contrary. You seldom grasp all the ramifications of a protocol until you’ve actually implemented it.