Avatar
Super Testnet
2183e94758481d0f124fbd93c56ccaa45e7e545ceeb8d52848f98253f497b975
Open source dev w/ bitcoin focus | supertestnet.org bc1qefhunyf8rsq77f38k07hn2e5njp0acxhlheksn

let me be more clear:

AM-ul-GAM [first and last syllables rhyme with "jam"]

or

uh-MALL-gum

I am making a list of technical people against relaxing the op_return filter

If you know someone I should add to the list, please let me know in this thread or make a PR

https://github.com/supertestnet/list_of_technical_people_against_relaxing_the_op_return_filter

me too

but I'm not sure we mean the same thing

I mentally pronounced it as AH-mal-GAM for years, where the first and last vowels are pronounced like they rhyme with "ram" or "jam" or "bam," and the middle one sounds like "mull" as in "I'll mull it over."

But a few years ago I think I learned it's supposed to be pronounced uh-MALL-gum and now I sort of read it both ways when I see it

In your head, do you pronounce it as amalgam or amalgam

> Am I mistaken in thinking we would rather have all the garbage in op return vs elsewhere

I don't agree with that. I don't want them to use bitcoin's blockchain to store their spam at all. If the choice *was* "op_return or elsewhere," I would choose "elsewhere," and by it I would mean "somewhere that isn't bitcoin's blockchain." But in fact spammers have another choice: don't post spam anywhere at all. That is the outcome I prefer.

> If filters drive spammers to pollute other parts of the chain can you actually claim that filters have worked?

This is the fallacy of false dichotomy. You act as if spammers have only two choices: spam op_returns or spam more harmful places. But they have another choice: don't post spam on bitcoin at all.

> If people want larger and cheap data storage currently it is my understanding that they wrap data in taproot scripts because the size limits are much larger and the witness discount makes it much cheaper

For values larger than ~153 bytes, yes. But for values lower than that, inscriptions cost more because they require two transactions: the commit tx and the reveal tx. Whereas op_returns only require 1 transaction.

Some core devs lately

Idk why more people don't mine with them

To me it looks like you make more money with Ocean than with any other pool, with one exception: a miner with a significantly-above-average amount of hashrate could do better with SBI Crypto

Ocean also finds blocks regularly enough nowadays that I don't see why their variance would make a significant difference, but I've spoken to at least one person who says it makes a big difference because with non-Ocean pools you get a single daily payout that's almost always the same size as yesterday, whereas with Ocean, payouts are sporadic and have different sizes each time. Apparently, even though Ocean's payouts end up being slightly larger when averaged out over time, some miners find the accounting annoying enough to just use a regular pool where you earn slightly less but it's more consistent

Thank you for the recommendation! My most recent nostr app is called Nostr Threads: https://github.com/supertestnet/nostr_threads

I made it because of a disappointing aspect of njump.me. Normally, I like that app, and use it to share nostr posts outside of nostr. But, if I want to share a thread with multiple posts in it, njump only shows one post at a time. Other tools, like Primal, do a better job, but they throw a lot of "junk" on the screen like login buttons and the whole "People in this Note" section. I wanted something that can cleanly show "just" the content I found interesting. So I made one.

To use it, just grab the nevent string of the "last" post in an interesting thread, and paste it into Nostr Threads. It will download each post in the thread, present them in a clean way, and give you a nice, shareable link so that you can share that content with others.

Ocean hit a new personal best of 17 exahash today

They've never had more hashrate than they do now

I think this is similar to the USA's activity before it entered world war 2. The USA supplied warships to the Allies and even commissioned its own navy to defend Allied vessels, including by engaging in naval combat with Germany, though no war was declared til December 1941.

Every cpu cycle you spend relaying spam is wasted

If you want to be less wasteful, consider running Knots

> why not just price out spam by doing more economic transactions?

one reason why is because to "just" do more economic transactions is to needlessly throw out another helpful mitigation

it is like saying "you should break all your windows -- you can keep your room warm by just exercising constantly"

yeah I suppose I could but that's no reason to smash my windows, which *also* help keep my room warm

one of the reasons they gave appears in the release notes for v0.9.0

"This change is not an endorsement of storing data in the blockchain. The OP_RETURN change creates a provably-prunable output, to avoid data storage schemes – some of which were already deployed – that were storing arbitrary data such as images as forever-unspendable TX outputs, bloating bitcoin’s UTXO database. ... Storing arbitrary data in the blockchain is still a bad idea; it is less costly and far more efficient to store non-currency data elsewhere."

source: https://bitcoin.org/en/release/v0.9.0#opreturn-and-data-in-the-block-chain

> It is either illegal to run a node or not. You are either serving CSAM or not.

You seem to be equating these two things but I don't think that's valid. If the blockchain became illegal the moment *any* CSAM entered it, then it would already be illegal, because there is already a small amount of CSAM on it. (source: https://www.theguardian.com/technology/2018/mar/20/child-abuse-imagery-bitcoin-blockchain-illegal-content)

Since it is not illegal, it must follow that a small amount of CSAM does not make the blockchain illegal. And therefore it is not binary, as you seem to be claiming. Spam filters that help reduce the amount of CSAM are good even if they don't entirely eliminate it.

Replying to ihsotas

I guess what I’m driving at is this: what is the taxonomy of the current near the limit transactions? 76 bytes is say a 4 byte prefix, 32 byte hash and 40 bytes worth of meta data. It’s possible that for the vast majority of transactions using op return these near limit totals are the sweet spot that accomplish something worthwhile and generally need 60-90 bytes to achieve. The filter perhaps drives some near term efficiency but over time the economics determine what happens.

Perhaps the time stamping and 2nd layer anchoring that makes up the the majority of use case for larger than 40 byte op return transactions naturally cluster around this point because it is close to the sweet spot between economic worth whileness and ease of implementation. The economics could be that limit and all the filter does is create a cliff like drop off vs a gradual slop downward that would occur under purely economic pressures. The over all dampening effect of filters may be vastly over stated by your data if it turns out there is not much natural demand for Say 95 byte plus transactions.

If there is ever economic value in 100 byte transactions I expect no amount of filtering will matter. I just don’t think there is a ton of demand above what is being made use of currently.

I don’t know about you but when I look back at my transactions for my early use I cringe at the number of sats I parted with to fees. I think this psychology mechanism will only get amplified as the average user isn’t sitting on large stacks of corn.

> all the filter does is create a cliff like drop off vs a gradual slop downward that would occur under purely economic pressures

This sounds like it is exactly the point I am trying to make. People who say the filters do nothing can't account for the cliff; if the filters did nothing, there would be a gradual slope til you get to about 153 bytes, where inscriptions become cheaper. And those weren't cheaper til segwit, so there would probably be no slope til then. Because there is a cliff, that means there are spammers out there who decided not to go through the trouble of bypassing the filter, and that means the filter worked.