pull down to refresh
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)
(2/2)
256 byte control blocks limit (you know about this one too) is problematic for advanced scripting that is possible today.
I don't know of any common uses for Taptrees deeper than 7 levels that aren't achievable using other methods. Do you?
Anyway, this is also addressed in the BIP. See "Isn't the limit on Taproot control blocks too restrictive?"
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.
BIP-110 is not a recurring softfork, so this comment is not applicable. It is active for one year, and then it expires, unless the Bitcoin community fails to come up with a suitable permanent solution, in which case we could opt to extend it.
You cannot run this forever either, because upgrades are blocked.
Yes, I see no reason why the Bitcoin community would decide to restrict upgrades indefinitely. But again, that is outside the scope of BIP-110.
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.
I very much doubt that everyone would wait until lock-in to start reviewing. But if that happens, the 45% that fail to upgrade will only be putting their own earnings in jeopardy.
Anyway, my code has been reviewed by competent developers, and Knots has a long track record of functioning well. If you doubt the integrity of the activation/consensus code, I certainly encourage you to review it sooner, rather than later.
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]
There is urgency to reject the data storage use case. We have just experienced two years of serious spam attacks, and the damage could be much worse next time if we allow data storage to become an officially supported use case, which is what the adoption of Core 30 is causing.
However, there is not enough urgency, in my view, to skip the important process of building consensus among the community. Bitcoiners need to agree that this change is the correct one. I think once some time has passed and discussions have been allowed to proceed, and miners have begun to signal, that Bitcoiners will ultimately decide that BIP-110 is the proper course of action.
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.
"Vibe coding" is not how I would characterize the process I used to develop the tests. I used an LLM to help scaffold the tests, but I carefully reviewed them to make sure they are doing what they are supposed to be doing. Again, please let me know if you see any issues with them. There is probably at least a month or two left before activation.
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.
This is incoherent. I am not "releasing a MASF and a UASF at once". I am releasing an activation client with a version of BIP9 that has been modified to allow a max_activation_height, an active_duration (expiry), mandatory signaling, and a custom threshold. You can review the activation parameters here: https://github.com/bitcoinknots/bitcoin/pull/238/changes#diff-e20339c384d6f19b519ea2de7f4ba4fed92a36d66a80f0339b09927c3fa38d6dR120-R128
I am not trying to mangle your words. I am trying to say that:
- You agree with BIP-110's goal (to reject data storage), and
- You agree that BIP-110 is the best method of achieving this goal (because no better way to reject data storage has been proposed).
If you disagree with either of these statements, feel free to explain why. If you agree with both statements, then it would be irrational to oppose BIP-110.
I think that the OP_[NOT]IF restrictions in tapscript are limiting actual usecases too, but I haven't checked your implementation of this.
No known use cases use OP_IF/OP_NOTIF in Tapscript. There is a tiny possibility that some funds could be affected, but this is very unlikely. Again, see the BIP's "Tradeoffs" section to find where this has already been addressed.
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.
I appreciate your honest and thorough feedback. I hope that I can persuade you to support BIP-110, as I earnestly believe it is the best way forward for Bitcoin. I have tried to be kind, and I ask the same in return if I get something wrong.
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.
Measured how?