> what point since you just admitted they don't work

On the contrary, I think I proved they do. Their goal is to reduce the spam, and they succeed at that goal

> Your side made it about CSAM and CSAM is a 100% effective or 100% fail situation

I don't think so. If we keep out most CSAM but some makes it through, that's better than not keeping out any

> Can you explain to me how a 1 block delay or costing $300 instead of $150 is going to stop this alleged nation state attacker?

I don't know what allegation you are referring to, but I don't think the spam filters stop high-effort spammers -- they work by reducing the amount of spam from low-effort spammers

Source for the data: https://x.com/OrangeSurfBTC/status/1963339476257718764/photo/1

> There may not be many oversized op returns to begin with

In total, there are about 10**4 op_returns on the blockchain of size 76 bytes

For 77 byte op_returns, the count is also ~10**4 (i.e. ~10k)

For 78 byte op_returns, the count is also ~10**4 (i.e. ~10k)

For 79 byte op_returns, the count is also ~10**4 (i.e. ~10k)

For 80 byte op_returns, the count is slightly higher: ~10**4.1 (i.e. ~13k)

For 81 byte op_returns, the total count is 9. Not 9k, *9 in total.*

That's the data for the last 16 years, which I hope is a long enough time frame for you.

Why do you suppose there is a huge drop from tens of thousands to 9?

I don't know. If you count from genesis, I suspect op_returns are more common, because several popular protocols have used them since like 2012, and a few not-so-popular ones still use them today. Whereas inscriptions have only been used since 2023. But I suspect inscriptions are catching up and have many more *current* users than op_returns do.

because some people manage to bypass the filters

There, I've answered your question. Care to answer mine?

Excellent question for the "filters don't work" crowd:

Why are 81 byte op_returns three orders of magnitude less common than 80-byte ones?

Filterers know why: a filter filters out 81 byte op_returns but not 80 byte ones. But y'all say they don't work. Do you have *any* explanation? https://x.com/cguida6/status/1975273120287105531

waxwing seems to like my latest privacy idea, whose goal is to hide the amount sent in L1 transactions. It's a bit like to payjoin, but has lower liveness assumptions

he says: "i think that ticks all the boxes...a lot better than status quo...Good call"

https://supertestnet.github.io/nostr_threads/#nevent=nevent1qvzqqqqqqypzqe6msnl8tcsk4w28capcaegeefmh2dmdmuza4ha6vfut6qfwr4egqywhwumn8ghj7mn0wd68ytnzd96xxmmfdejhytnnda3kjctv9uq32amnwvaz7tmwdaehgu3wdau8gu3wv3jhvtcqyzs7fw8tk3nnkjnjfvke8svg7enq26hwray3z3dtmzlgn7hrwnp6veg22ua

> It's unfortunate that LN nodes in route could correlate it right?

They get to learn the preimage, and can derive its pubkey, subtract it from every pubkey that spent money recently, and check if the result is a pubkey they know. I think you can fix this by tweaking it twice, and sending your recipient one of the tweaks with your invoice. That way, routing nodes can only untweak one step, which isn't good enough. They would need to learn *both* tweaks to identify the recipient's "real" pubkey.

the sender could treat the preimage as a private key, derive its public key, tweak the recipient's public key with it, and use the tweaked public key as the keypath. Then the recipient can spend the money once they learn the preimage without using branch 1. Just add the privkey to their "real" privkey to derive the privkey of the tweaked public key.

Here's an idea for hiding amounts on bitcoin with reduced liveness assumptions compared to payjoin. Suppose you want to send someone 1000 sats without disclosing the amount on the blockchain, and you know your recipient's pubkey. Create a secret, hash it, and set up a script like this:

[

//branch 1

[ op_sha256, hash, op_equalverify, recipients_pubkey, op_checksig ],

//branch 2

[ 2016, op_checksequenceverify, op_drop, senders_pubkey, op_checksig ],

]

Deposit 100k sats into the address and send the recipient a lightning invoice for 99k sats, locked to the hash in branch 1. If they pay your invoice, they learn the secret, and sweep all 100k sats via branch 1. Outcome: your recipient nets 1k sats, because they sweep 100k sats from the address, but send away 99k sats on lightning.

If they don't pay your invoice, you wait for the timelock to expire and take back the money via branch 2. Outcome: your recipient gets nothing.

Either way, chain analysts just see 100k sats go into the address and come out again, but do not know how much was really sent. And, unlike a payjoin, your recipient did not need to be online when you funded the bitcoin address.

it certainly matters, for statistics such as "what is the most popular *brand* of bitcoin node software" -- the winner of that category is currently Bitcoin Core, which has ~77% market share compared to Knots' ~22%

but my question is, "what is the most popular version of bitcoin node software?" and for that question, the answer is Bitcoin Knots v29, which has about 13.9% market share, compared to 13.5% for the runner-up, Core v28.1.0

because the most popular version of Core has fewer than 13.5% share of the node count

the most popular version of Knots has a higher share than that

source of chart: https://bitcoin.clarkmoody.com/dashboard/

as of right now, more folks run Knots than any other version of bitcoin

yes, there is a noticable decline in Core numbers since April with a corresponding rise in Knots numbers

source of chart: https://coin.dance/nodes/all

Knots is Number One https://video.nostr.build/8d4634d59a3882b92b3f1e1e0431b8cffe4af68076594f8ea71a2e167ab4ae22.mp4

Yep

There are several reasons why government shutdowns don't really do anything

One is that the government somehow manages to spend more money *not* providing "non-essential services" than it spends *providing* them:nostr:nevent1qvzqqqqqqypzqgvra9r4sjqapufyl0vnc4kv4fz70e29em4c655y37vz206f0wt4qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qg7waehxw309ahx7um5wgkhqatz9emk2mrvdaexgetj9ehx2ap0qqst54lncnjct7xltateppna4lj39u6t0arqx6v3azn7ntttxq75nucwsaxq0

But it occurred to me today that there's another reason: since government shutdowns happen with some regularity, all government programs have an incentive to get listed as an essential service. So I looked it up and found out that's exactly what they've been doing for years now, and thus each "shutdown" shuts down less and less of the government every time it happens.

Did you know that the Department of Veterans Affairs ran out of money during the government shutdown of 1995, and had to halt operations? In 2009 they lobbied for a law, which passed, that funds their budget *two years at a time* so that it's unlikely to happen again. The president at the time said this law “ensures that [this department] will no longer be held hostage to the annual budget battles in Washington.” source: https://vva.org/programs/government-affairs/advance-appropriations-a-victory-for-veterans/

So now, other government services are lobbying for the same exemption. For example, in 2019, Senator Merkley proposed doing the same thing for the Indian Health Service, and his bill (the Indian Programs Advance Appropriations Act) passed in 2022 after years of lobbying by Indian groups. Thus that service is also one of the “essential services” that may continue operations during a government shutdown.

Basically, every government service has an incentive to lobby Congress to put them on the list of "essential services" so that government shutdowns don't affect them. And thus, nowadays, government shutdowns just don't do much.

yes, I think this is it!

And -- as a reminder -- even this low cost is only a fallback: if someone tries to cheat in a bitvm contract, you run this script, and the cheater has to pay the cost. If *no one* tries to cheat (which is the "happy path") the cost is 1 standard size btc tx, or ~300 vb, or ~$0.69

Yay, op_codeseperator finally does something! The L1 cost of creating a groth16 garbled circuit, and publishing its inputs on bitcoin for validation, is only 1800 vb. A standard bitcoin transaction is about 300 vb, so with this op_codeseparator trick and groth16, you can validate anything on bitcoin for the cost of about 6 standard bitcoin transactions. Which, at current costs of 4 sats per vb, is about 7200 sats, or a bit less than $9. https://gist.github.com/RobinLinus/0fc7405ad7485c35465efb7996a7b014