pull down to refresh
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. ↩
Thanks for the feedback.
It doesn't help.
I think it helps a lot to explicitly declare by consensus that arbitrary data storage is not a supported use case. Almost every Bitcoiner I've ever met wants Bitcoin to be money, and thinks it should not be data storage.
I don't think Bitcoin can survive as money if it is also trying to be data storage in addition to being money. I think the spam attacks we endured recently would not have happened if Bitcoiners had committed to rejecting the data storage case prior to 2023. Part of the spammers' narrative was "we're helping Bitcoin by contributing fees to miners". BIP-110 sends a clear signal that filling blocks with data spam that makes Bitcoin less useful as money, far from "helping", is an abuse. So in the future, if shitcoiners attempt similar attacks again, such activity will be immediately recognized as abuse and promptly filtered.
The witness inscription protocol for spreading over multiple utxo already exists because shitcoiner orditards needed it.
Yes, this is why BIP-110 explicitly invalidates inscriptions. Core 30 sends a message that inscriptions are an officially sanctioned use of Bitcoin, because part of the rationale for removing the OP_RETURN limit was "people are already using inscriptions anyway". BIP-110 restores the situation to how it should be (and how it was from 2010-2022), which is that Bitcoiners actively resist data spam without ceding an inch. This is necessary in order for Bitcoin to succeed in its mission of becoming the new global reserve asset.
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_RETURN scriptPubKey size exclusion
OP_PUSHDATA* exception for BIP16
The reason for the OP_RETURN and BIP16 exceptions are explained in the BIP:
OP_RETURN:
What about OP_RETURN? Why not get rid of it entirely?
OP_RETURN outputs are provably unspendable, and nodes do not need to store them in the UTXO set. Historically, up to 83 bytes have been tolerated only to avoid unprovably unspendable spam in other output scripts, and no legitimate uses have ever been found. With the advent of pay-to-contract and Taproot, it is now also possible to commit to external data in the Taptree, making even hypothetical use of OP_RETURN deprecated. However, to avoid breaking legacy protocols that still include such outputs, this proposal allows these outputs.
BIP16:
Why is there an exception for BIP16 redeemScripts?
The content of redeemScripts are another script, which is then executed. Its contents are then also subject to the same OP_PUSHDATA* restrictions. Restricting it is not only unnecessary, but would reduce the ability to make use of the intended script capabilities, and could impact legitimate real-world usage.
You can read the entire rationale here: https://github.com/dathonohm/bips/blob/reduced-data/bip-0110.mediawiki#specification-nuance. Let me know if anything is not clear and I can update the BIP document.
What if a change is needed on short notice that needs more than 34 bytes?
What change would that be? Taproot allows for very complex spending conditions, even limited to 7 levels deep as in BIP-110.
This is also explained in the BIP:
Why limit scriptPubKeys to 34 bytes?
scriptPubKeys must be stored indefinitely in quick-access memory (often RAM) by all fully validating nodes. They generally cannot be pruned. They are also a direct cost to the sender rather than the receiver. For these reasons, modern usage is all 34 bytes or smaller in practice; actual spending conditions have been moved to the witness, and the scriptPubKey simply commits to them in advance with a hash. Furthermore, large scriptPubKeys, in addition to being a data embedding vector, can be abused to create malicious transactions and blocks ("poison blocks") that take a long time to validate. Large scriptPubKeys, thus carrying a large abuse potential and no benefit, are invalidated by this BIP.
Again, let me know if you think this section could be clarified.
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.
This is also addressed in the BIP:
Why make spending undefined witness/Tapleaf versions invalid?
Since they are undefined, witness stacks spending these versions are completely unlimited currently to allow maximum flexibility in future upgrades. Any future upgrade, however, would need more than a year of coordination, so this softfork will not actually restrict it, and only safeguards against abuse in the meantime.
It is very doubtful that GSR or LNHANCE would have consensus by the time BIP-110 expires (September 2027 or earlier), but if it does, then there is no problem - we can just activate the new features then. (It is worth noting that CTV, a component of LNHANCE, would be compatible with BIP-110 since it uses OP_NOP rather than OP_SUCCESS. But again, if there is consensus for a proposal that needs upgrade hooks, waiting a year to deploy it would not be out of the ordinary.)
(1/2, continued in reply)
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.
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.