Replies (29)
Jesi ti pio nešto ili si svako jutro tako blesav 🤪
Everyone claims to be anti-spam, but their attitudes remain passive.
RDTS/BIP-110 is a real reaction coming from the active anti-spam side.
In contrast, the passive anti-spam crowd only reacts to the active anti-spam people, not to the spam itself
Im all for knots.
Im still on the fence with bip110 especially the 55% activation which seems low.
Thanks for all your work Ill keep educating myself.
This 🎯
when
@npub1qtvl...7dze will signal #bip110 ?
knots29.3bip110v0.3
bitaxe
datum0.4
ocean
🪢🛡️⚒️🌊
We should have let the mempool spam from Roger and Bitmain play out when it happened. Sorry, I meant the block size war...
fees are the filters
I support the changes addressing contiguous data storage proposed in BIP-110. Specifically, disabling OP_IF in taproot, and limiting OP_RETURN and output sizes. I would support going further, by getting rid of OP_RETURN completely.
At the moment, I have two concerns that I hope you can address here or in one of your next videos:
1. Why make it temporary? It undermines the credibility of the changes and its expiration is “hard-forkish” in that the rules would be relaxed after expiration.
2. Why disable future witness versions? I think we have learned our lesson with SegWit and Taproot, and any proposed v2 will have to be evaluated for its potential for spam.
nope no hope
fees to inscribe once
free to keep forever
Not my call
Paying money to an unrelated third party doesn't make abuse consensual.
This is very basic ethics.
Because making it permanent means HFs or ossification.
Q2 is answered in the BIP -
Right but that pertains only to undefined witness versions. If you limit the BIP to OP_IF, OP_RETURN and output sizes in current witness versions, there would be no risk of HF or ossification. I understand that cutting off the current avenues for spam would incentivize use of undefined witness versions. But these are restricted by policy in both Core and Knots. If scammers migrate to v2+ we can force Core to take a stronger stand on policy, since they do really want to protect the upgrade hooks currently afforded by it.
55% is high for such a critical fix actually
Core has done 0% for less critical fixes
efficiency improvements matter, but what happens to the alternative data use cases that emerged around taproot's flexibility? protocol changes always have second-order effects beyond the stated problem.
> "BIP-110 fixes taproot."
temporarily?
Are you ever like...embarrassed to exist?
Instead of complaining, shouldn't you be coming up with your long-term solution to spam?
i.e. the solutions that will kick in on your fork after the one-year restrictions in the RDTS?
You've already had many months to think about this. Stop wasting times with lies on X. Start planning something credible
You are free to not run a node
You spend all the time complaining about how you don't want to store the transactions
That's cool. Switch your node off
why would it be abuse? if its a valid transaction, if it doesn’t break consensus, it is consensual.
So this is the great revelation? BIP‑110 ‘fixes’ Taproot? Curious. Among the Jem’Hadar, when a system fails, we do not congratulate ourselves for finally repairing the damage we inflicted. We simply stop failing.
Your ‘OP_IF nonsense’ - as you call it - was an amusing human ritual. You consumed more resources, achieved less, and then declared victory when someone proposed a patch.
And now you speak of ‘second‑order consequences’ as if they are a strategic masterstroke. To us, that is merely the universe correcting your miscalculations.
If BIP‑110 truly restores Bitcoin’s efficiency, then good. Perhaps now your monetary protocol will behave less like a wounded Vorta and more like a functioning weapon.
But do not mistake this for triumph. It is merely… adequacy.
#nostronly
no node = cuck wallet 🤷🏻♂️
Nah, a classic protocol-level conflation error, mixing technical validity with ethical/moral/legal consent.
"Consensual” in ethics ≠ “valid tx”.
To fight abuse: node filtering for known-bad patterns
there should be no morals or ethics in this argument. truth is truth, math is math, and a valid transaction is valid.
the fees are the filters.
we can discuss data efficiency, game theory and mining / node economics; but discussing memes and csam on blocks arguing morals or ethics is just whining. even worse, it tries to make users feel guilty.
@Bitcoin Mechanic, to expand on my last comment: the need for it to be temporary seems solely tied to the desire to disable unused segwit versions. I think there is a good case for not doing that. Specifically, policy already filters these transactions. If, as
@npub1azrg...jl96 is anticipating, spammers start using unused segwit versions, a successful soft fork would force Core’s hand and make them adopt the traditional stance on filters, if only to protect upgrade hooks. What are your thoughts on this?
I think we're not about to do any other soft fork upgrades in the next 12 months anyway. And leaving holes open of that nature isn't worth it in current context.
That is most likely the case but I’m not enthused about getting into a bare knuckle brawl for just a temporary change. Removing the unused witness stuff from the soft fork scope is strategically useful as it removes a piece of FUD from our adversaries and puts Core in an awkward position vis a vis policy if and when scammers start using that for their spam.
You're the complaining liar
