Nostr Archives

kratter ran peter thiels money before pivoting to become luke and mechanics attack dog rich for him to lecture anyone on ethics

💬 347 replies

Replies (50)

Tauri22d ago

I’ve read the proposal and a bunch of opinions from both sides to form an opinion. For example you quote certain passages from the website/github and interpret them in a way that fits your view. I read them and I interpret them in the opposite direction. The problem BIP110 addresses is severe enough to tighten the rules significantly but not to the point they break the foundations. In fact they reinforce them. Ironically the top down decision making of Core v30 made this fork necessary not just in principle but in practice. If you don’t know what I talk about it maybe you haven’t paid enough attention, or you simply prefer to think it’s a nothingburger. Maybe you should have applied this higher standard towards protocol development to Bitcoin Core too. Did you? Are you running v30? If not, why?

000

HHide&Seek22d ago

I am opposed to core v30 for the exact same reasons I am opposed to BIP110: sloppy engineering forced through the community with poor arguments. Btw, core v30 didn't enable posting contiguous harmful content on chain: it was enabled in 2013 by OP_RETURN, that was limitless at the consensus level from the start. And to be clear, the threat was well known all along. There are press articles from 2018/2019 that were FUDing about it during that bear. Anyone who's familiar with bitcoin, like Luke also is, has knew about this for years if not a decade — so why is it suddenly an emergency after all that time? Core 30 sucks and it shouldn't have happen - but it is simply not true that it made that attack viable, and anyone who thinks so is deeply miseducated about how bitcoin works. All of this is just ego war and people wanting to feel great about themselves. If the priority was to protect bitcoin against this attack, then capping OP_RETURN size would have been enough, and much much more likely to pass. But ofc they had to overdo and turn this into a personal vendetta, and now the chances of fixing the actual important thing by the end or the year are 0.

0000 sats

Tauri22d ago

Good, so we can establish a baseline around v30. I’m aware contiguous data isn’t new. The difference is that it wasn’t a systemic problem until the 2023 inscriptions exploit. Before that, large-scale data stuffing required convoluted workarounds and remained marginal. There wasn’t a real economic split between monetary and non-monetary use at scale. What changed wasn’t the code alone, but the incentives. Once a market formed around inscriptions and it became culturally normalized, the behavior scaled aggressively. The data reflects that shift. At that point, it stopped being edge-case experimentation and became an industrial use of blockspace for non-monetary payloads. Uncapping OP_RETURN without first addressing the underlying inscriptions vector only amplified the issue. It expanded one data pathway while leaving the more structurally problematic one untouched. Are you familiar with the mechanics of the inscriptions exploit? Or how it was handled in 2023? Understanding that context clarifies much of what followed with Core v30 and why BIP100 focuses not only on OP_RETURN but also on alternative data embedding methods. What looks like an overkill is actually trying to patch a leaking bucket with many holes. https://blockspaceweekly.substack.com/p/issue-3-three-yea…

UUXI22d ago

Agreed that this is not ideal and its a risk on bitcoin stability (assuming the BIP-110 fork is initially a minority chain), but in your opinion, what should we do about UTXO bloat (which is a risk on decentralization) ?

0000 sats

HHide&Seek21d ago

I think putting a hard cap on OP_RETURNs would be the single best non-risky thing to do. However, I think bitcoin adoption will cause blocks to be mostly full a few years from now - and the fees to be much higher. So it would only buy some time & avoid harmful content onchain.

0000 sats

HHide&Seek21d ago

That being said the cost of storage keeps getting lower and lower, but bitcoin block size is static, so all things consider it should only get easier to run nodes from now on.

0000 sats

dazzling21d ago

A change to the consensus rules of bitcoin. The rules that say whether a transaction is valid and can be added to a block. Or was that not your question? Any sarcasm here went straight over my head 🚸

0000 sats

JackTheMimic21d ago

Primary consensus rules (in plain English) - Bitcoin Controlled Supply Rule - Total supply of Bitcoins is controlled to a fixed number of 20,999,999.9769 Bitcoin. - Bitcoin Mining Reward Rule - How many Bitcoins are rewarded to the miner who creates a new Bitcoin block from the coinbase. Bitcoin Proof of Work Rule - The block hash must meet the cryptographic difficulty requirement. - Each Bitcoin transaction input must have the correct signature of its address owner. -Each Bitcoin transaction input can only be used once in the Bitcoin block. - Each Bitcoin transaction must be in the correct data format. - Each Bitcoin block must be in the correct data format. - Each Bitcoin block must contain the hash of the previous block in the blockchain. I am being pedantic but, my point was that nothing was "changed" persay. BIP 110 added rules and did not change the previous consensus rules. It would be fair to say "Only one side is pushing stricter rules for consensus"

000

LLee20d ago

Bitcoin either maintains censorship resistance, or it doesn’t. You cannot be a little bit pregnant. Bitcoin cannot be a little bit neutral. It is our money, AND the money of our adversaries. BIP110 is stupid. Its supporters are very stupid, and they are “here to fix spam.” Think about how big a person’s ego must be in order for them to believe they know how to roll back the chain and pick an alternate outcome based on a censorship campaign they created.

0000 sats

YEGHRO20d ago

Hey thanks for that opinion. Doesn’t really help clarify anything but, why not I suppose. What is your least liked thing about BIP110? What aspect of it do you think is the most “stupid”?

0000 sats

Staroleum20d ago

What are you saying? You’re trying to get technical but you start off with reducing added weight? Wtf is weight? It limits op return to 84 bytes and limits transaction outputs to 34 bytes.

0000 sats

Iihsotas20d ago

Weight as in the size of the chain on a nodes disk drive as opposed to the amount a node must hold in ram to make sure it can stay synced. Adding more ram to a node is not only more costly but may not be possible, so utxo bloat is far more worrisome than the bloat of the chain. Op return is chain bloat, and can be pruned utxo bloat we are stuck with forever.

0000 sats

HHide&Seek20d ago

Oh ok I get your point now... Especially considering the price of RAM, agreed. Well, that would be an heavy hit in the nuts of ordinals for sure. Now, taproot assets creates the exact same type of UTXO fragmentation, and is it perfectly BIP110-compatible. In any case, I think the previous wave is kind or dead, and BIP110 won't clean up the existing clutter... So the question is, will there be a new wave or not? And unfortunately the tools exist that would allow for one regardless of BIP110, so maybe there is a need for a different solution that specifically addresses low-value UTXO. (there is already an anti-dust policy that could be updated to higher values for example)

0000 sats

HHide&Seek22d ago

I'm familiar with this but either ways the facts are not siding with the idea of an emergency. Most ordinal projects are dead, investors are ruined, and tx fees have been ridiculously low for months. Besides, you are conflating two very different issues, just like BIP110 is doing. Capping OP_RETURN, which has outlived its utility, to protect nodes from hosting contiguous illegal content is arguably very important. Dealing with witness-embedded spam is secondary and optional. Witnesses can be pruned away, and it's not even sure jpegs are coming back. The were economically viable just because of a hype that is long gone and, would it come back, unsustainable by nature. As I said, by trying to achieve aggressively everything at once, this BIP is not only harmful to legitimate monetary projects lead by genuine bitcoiners, it's also condemning itself to fail, missing an historic opportunity to fix a long-standing vulnerability.

0000 sats

Tauri22d ago

This data disagrees with your lax view on spam abuse. That’s why I included the link in my previous post. Might be a good idea to give it a read, although you seem convinced your POV is infallible, so there might be no point in trying to convince you more.

0000 sats

dazzling21d ago

Adding a rule is changing the rule set, by most people's meaning of the words. But there is a slight difference. I shall endeavor to be clearer in the future. But my point stands, one side is trying to rush through a change in the consensus rule set by adding new rules. My main problem is the rush. That reeks of scammers trying to make people make mistakes by acting emotionally. Also the "temporary" part is just not sound money.

0000 sats

JackTheMimic21d ago

I completely agree about the Flag Day activation, completely unnecessary. If people want the software, then they can run the software. No need to put a timeline on it. Spam is a slow death that builds up. But I don't see temporary as a negative. It seems like a compromise in an attempt to find a better solution that is less restrictive for innovative usecases.

0000 sats

LLee20d ago

Let me spoon feed it. BIP110 undermines Bitcoin’s neutrality and risks a contentious chain split, in exchange for only modest relief from “spam.” More precisely… It turns Bitcoin from a neutral protocol into a curated ledger. Once consensus rules start classifying some valid transactions as “spam” and banning them, you’ve crossed from “any valid script is allowed” to “only socially approved uses are allowed,” which is fundamentally anti‑Bitcoin, and critically stupid. It weakens censorship resistance. If node software encodes policy views about which data types are acceptable, this opens the door to future content‑based restrictions driven by politics, regulation, and powerful actors. It introduces material chain‑split risk for a non‑critical reason. Because BIP‑110 tightens consensus rules that a minority of nodes enforce, blocks that include now‑forbidden data could be accepted by old nodes and rejected by upgraded ones, causing a minority fork over an aesthetic/ideological preference, not a security reason. In fact it creates greater external security risks I’ve already highlighted above. It sets a precedent that “content moderation at the consensus layer” is acceptable. And thus, it attacks “Bitcoin is hard money” and the “blockchain as immutable.” That’s why it gets a hard ‘fuck off!’ Furthermore, reviewing transaction types in consensus is far more dangerous than the spam itself, because it normalizes rule changes justified by subjective judgments about what counts as legitimate use. All of these fold into one overarching takeaway: that BIP110 is stupid, and those pushing it are very stupid.

0000 sats

YEGHRO20d ago

“Content moderation“ Bitcoin is money. It’s not a fucking social network for people to post their retard memes. I don’t agree with the hostile way they’re trying to push BIP110 but I also don’t disagree that bitcoin is money and should remain so. If you wanna post garbage data, that is non-monetary go to another chain or create a second layer solution.

0000 sats

HHide&Seek22d ago

Well once again if you cap op_return, that leaves only witness-embedded spam that you can prune away. Your graph actually confirms that it doesn't amount to much, so I'm pretty confused about how you're reading it? The point is, we could have gotten rid of that op_return part with a simple, consensual fix but instead they wanted to push it too far to prove something, and what'll we get is no fix at all because this thing is crappy and won't activate.

0000 sats

Tauri21d ago

I don’t care if it’s prunable or not. It makes running a node harder anyway. If the previous screenshot wasn’t clear, I hope this one is.

0000 sats

HHide&Seek21d ago

It just shows that 80% of the bloat nowadays comes from OP_RETURN, as I already explained. You really missed the point on that one. Btw, just a few years from now, our blocks will be systematically full of monetary transaction because of adoption. Do you think it will cause bitcoin to collapse, or to the least to centralize completely? Or, in your view, are non-monetary transactions the only ones that can cause a node to struggle? Because if full blocks are a threat to bitcoin, then mass-adoption is a threat to bitcoin too, isn't it? Then maybe we should make sure Bitcoin never expands and never growths, just like BIP110 proposes... :)

0000 sats

Tauri20d ago

I haven’t missed anything. The graphic just shows that: a) when you have two buckets, spammers will abuse both. b) if you close one, they’ll switch to the other, so you need to close both. c) fees can’t outprice spam, bc there’s infinite demand for free data storage > our blocks will be systematically full of monetary transaction because of adoption Good, that’s the whole point of the debate: save the 36% space used by spam to accommodate more financial transactions. In this regard BIP110 is a de facto scaling solution.

0000 sats

HHide&Seek20d ago

Not if both buckets are already full... Also it's not free if there's a fee 🤔. Anyway, I don't need to be convinced that spam is a bad thing. My point was that preventing contiguous harmful content onchain should be the priority for obvious reasons. But I think I already went over my point extensively so probably we should stop here?

0000 sats

Uumni20d ago

Why can't fees out price spam.. Has anyone done the numbers on this? Do minimal fees eliminate more than 95% of the spam? Some thoughts from another post: 📝 3cd8368b…

0000 sats