pull down to refresh
Social consensus is overwhelmingly in favor of rejecting data storage as a use case, and BIP-110 is the best way to accomplish this. If someone finds a better way, I will withdraw BIP-110. Failing that, there is absolutely no reason to oppose BIP-110.
Social consensus is overwhelmingly in favor.
Measured how?
Do you think that Bitcoin should officially support the arbitrary data storage use case?
No, but that is because there is no official.
I have not met a single non-troll who thinks that Bitcoin should officially support the data storage use case. That seems "official" enough for me.
Do you think that the Bitcoin consensus rules should be restricted to remove abuse?
This is not the motivation of BIP-110. Since you just said that you don't want Bitcoin to officially support the data storage use case, you should support BIP-110 as you are 100% in alignment with its goals, and there is no better proposal on the table to achieve said goals.
Why?
Off the top of my head:
- It doesn't help. The witness inscription protocol for spreading over multiple utxo already exists because shitcoiner orditards needed it.
- It's too restrictive and you know this because you made exceptions to the rules for existing solutions that can't be fit inside your proposed new rules, for example:
OP_RETURNscriptPubKey size exclusion. What if a change is needed on short notice that needs more than 34 bytes?OP_PUSHDATA*exception for BIP16
- Banning unused witness program numbers other than 0 and 1 and
OP_SUCCESS*explicitly removes future extension, which is a major setback for anyone working on protocol updates. You would explicitly block GSR,lnhance. - 256 byte control blocks limit (you know about this one too) is problematic for advanced scripting that is possible today.
- It's temporary and that means instability [1] If every year there needs to be an activation for another year, then this is just causing stress for a couple of months per year. You cannot run this forever either, because upgrades are blocked.
- 55% activation threshold means 45% has two weeks to adapt their software. Everyone that runs Core should run your unreviewed code forked from unreviewed Knots? That would be the worst outcome.
- UASF is like a nuke as it's best used as a deterrent, not a feature, unless there is a massive issue and high urgency. There is no urgency because to my memory you already shifted flag day 6 months. [2]
- I think that the
OP_[NOT]IFrestrictions in tapscript are limiting actual usecases too, but I haven't checked your implementation of this.
I probably have more reasons, this is just without re-reading the BIP text and some things, like the UASF/MASF concurrency are an assumption that I have not yet checked in your code. Apologies if I got something wrong, please be kind and correct me.
As much as GMax is smart sometimes, this is about the dumbest brainfart he has ever produced. ↩
It's still too early because the other day you said you were vibe coding the tests due to deadlines. Don't do that, especially not per point 6 above. Also note that you're shooting your entire load at once by releasing both MASF and UASF at once and you clearly have no idea how this will play out. I know that because you literally just told me I should support you based on you trying to mangle my words. That's really bad. ↩
Answer the question
By talking to Bitcoiners and noting that no one wants Bitcoin to officially support the data storage use case.
Do you want Bitcoin to officially support arbitrary data storage?
So you have no objective measurement other than the people you talk to.
There are also numbers of node operators signaling support for BIP-110, and eventually hashpower support. Those are pretty objective, I'd say.
Do you want Bitcoin to officially support arbitrary data storage?
I will also take your silence on this question as an answer in the negative.
Incoherent FUD like this proposed guide?