Thread

Spam is subjective

If you consider the spammer’s opinion as objective, then sure it’s subjective.

Humans wrote bitcoin. The only objective things a bitcoin node knows are what its devs and users tell it. A Core node doesn't know what a valid tx is, except it does because a human told it via the consensus rules A Knots node doesn't know what a spam tx is, except it does because a human told it via the mempool policy

Aren't you also against inscriptions? Shouldn't knots also filter inscriptions? Maybe it does that already, I don't know.

> Aren't you also against inscriptions? Yes > Shouldn't knots also filter inscriptions? Yes > Maybe it does that already, I don't know It filters inscriptions that are larger than 83 bytes I would prefer it to filter all of them, but filtering the big ones is a decent start

Thanks good recap

Inscriptions are stored in witness (not op_return)? Does knots apply the 83 byte limit to witness too?

"Super testnet" man that's a dope name 👌 that name pops

Knots is maintained by a psychopath. I'll pass.

**** This just in.. pedoland under 'pedo software' "crisis" **** The U.S. is the only UN member state that has not yet ratified the Convention on the Rights of the Child. As of July 2025, child marriage is legal in 34 states.

They don't just think spam is good, they profit from spam.

You'll pass, and run core V30? If so, I wonder if that kinda slander goes both ways.

CSAM and monkey jpegs are not subject to be ibterpreted as anything but spam (or worse) when talking about Bitcoin's function - money.

Nah, it censors coinjoin txs so fuck off. nostr:nevent1qqsggmcerzfjlyrgsud3qa2k0d996d8ayug3j358axspswwzm59lv7gpyfmhxue69uhkummnw3ez6an9wf5kv6t9vsh8wetvd3hhyer9wghxuet5qgszrqlfgavys8g0zf8mmy79dn92ghn723wwawx49py0nqjn7jtmjagrqsqqqqqp9xkyjs

Passing on knots doesn't mean I have to run v30...

I have looked at bip444 and I think it is a good idea to temporarily invalidate the transaction types it identifies I do not think it's "emergency deployment" mechanism is wise, though it does sound fun

It applies it to inscription envelopes specifically, by testing for the existence of the bytes for "OP_FALSE OP_IF" in the witness

> Changing policy rules is an unworkable solution It works well at its primary job, which is filtering my own personal mempool > Mempool policy is a crutch It objectively reduces the negative impact of spam on my node > It will not stand the test of time because it can be easily circumvented, as...Libre Relay [shows] LibreRelay does not undermine the filters' ability to do their primary job well, which is to filter my own mempool and thus reduce the negative impact of spam on my node > I think you should put your considerable talents to work turning the coinbase into an on-chain privacy tool I already built that, I just don't care to market it

> If I'm not mistaken, BIP444 proposes having a council or group of people making decisions on what is "troublesome content". I didn't see anything explicitly about a council. If the "group" is defined as the set of miners, then I think it would be wrong to assert that this proposal "gives" them power to make decisions on what is troublesome content. On a related note, I think miners already have that power, implicitly, because they have a veto on what counts as valid in bitcoin. Specifically, even if all the non-mining bitcoin nodes consider some type of transaction valid, the set of miners can refuse to mine transactions of that type, thus effectively overriding the will of all other nodes. I think it would probably be unwise to ask them to formalize this power in some sort of coordination software and then begin using that software to manually "vote" on what counts as troublesome content. (Again, i do not think bip444 proposes this.) A group with that kind of power in bitcoin sounds like a bad idea to me, and although I think miners technically have that power already, it is not, to my knowledge, formalized in any sort of coordination/voting software. If such software gets written and widely deployed among miners, I think bitcoin would be in greater danger than it currently is of becoming "ruled by committee." Once more, I do not think bip444 proposes any such thing. > And is the method of invalidating transactions to invalidate the entire block? The proposed method is for miners to refuse to mine on top of any block containing a troublesome image. They would instead mine a replacement block without that image in it. > what about all the other transactions in that block, what happens to them? They go back into the mempool, to be mined in future blocks (presumably the very next one), except transactions such match the tx types identified in the bip, in which case those transactions would become invalid once this bip activates, either by the "emergency method" (which involves rolling back one block, and which sounds like a bad idea to me) or by the "flag day" method (which sounds like a decent idea to me).

Wait until you see some of the core contributors 😬

And the limit is the same 83B?

I think so. Here is the relevant code snippet: https://github.com/bitcoinknots/bitcoin/blob/eeb9cc1120661d0e9fd28ddb6fef2c04992a4666/src/script/script.cpp#L329 It is a function called DatacarrierBytes and I don't know c++ all that well but it appears to match transactions containing OP_FALSE OP_IF or OP_RETURN, and counts the number of bytes they carry as a payload. I assume this function gets called wherever the data arrives filter is applied, which I suppose is probably in policy.cpp -- though I haven't checked

Your mom is maintained by a psychopath

I don't know enough either, but I wonder if the is used also on inputs, or just outputs.

Come on man

Yes, Luke is a core contributor. He's on a different level.