For anyone not aware nostr:nprofile1qqsve2jcud7fnjzmchn4gq52wx9agey9uhfukv69dy0v4wpuw4w53nqpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcuseaka PR to remove the filter entirely was NOT merged. A PR was merged an hour ago to uncap the limit but keep the filter. Core kept an unnecessary filter (imo) to appease plebs and they're still going to be mad about this non issue.

I'll admit I'm wrong when you show me how your filter can stop my transaction from propogating through the network.

News flash, it can't and if it could then Bitcoin would be useless. Read that again. "...your filter can stop my transaction..."

That's NOT something we want in Bitcoin. No matter what you think spam is or isn't. Bitcoin should be uncensorable period. Luckily for everyone, it is. Let them waste generation wealth on silly pictures and just leave it alone. Bitcoin is fine.

nostr:nevent1qqsra5agttcfk77mqdwj5rquvg8t6l09vczjgxk6vfvwk93k208d2dspzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtczypan77qrw5r5daz4gyazy8uqje0wed577vy096k3m2yuctyfzt5ksqcyqqqqqqgy264qp

Reply to this note

Please Login to reply.

Discussion

No one wants to censor your transaction, Node runners want to stop you spamming the chain with useless data. If it's a financial transaction, then it's fine.

Spamming or including spam in blocks? What do you mean? No one is stopping anyone from making whatever mempool policy they want. Especially now as they're not even removing the filter. Carry on in Core 30 with the same filter if you want. Gossip is going to relay these transactions no matter what your filter says. Now your node won't gossip about it to others so you can reduce how much they are "talked about" between nodes but the network will absolutely always know about them.

They can continue to use their work around, but they won't be accepted as standard transactions on the protocol.

Okay and? I just went over this standard and non standard are arbitrary as well... Semantics. A transactions standardness has no bearing on its inclusion in a block.

Then send it within the protocol standards then.

I think you're confused. Non standard transactions are with the protocol standards...

"No one wants to censor your transaction, they just want to censor transaction if it's not a certain kind of transaction."

Do you understand the conundrum we have here?

Do whatever you want in your mempool. Don't make the same argument for consensus rules. There is no way to stop "non financial transactions" from being included in a block. I'd argue any consensus tx is a financial tx. They're paying a fee in a currency to a miner. That's financial. You're free to disagree and make your mempool reject whatever you want.

You aren't making any sense. There is no grey area, a transaction is a financial transaction or it's not.

Finance refers to monetary resources and to the study and discipline of money, currency, assets and liabilities.

Any transaction that involves money is financial by definition. there is no grey area. This is financial.

https://mempool.space/tx/376ef7eba8eebb013ec8d2cacc21c8e8ab7ab960645df459c292071aeb4b8fef

(I just picked a random one)

You can deflect that nonsense elsewhere buddy.

Explain how it's nonsense. Make a real argument. Again this is all arbitrary. That's my whole point and you refuse to acknowledge that because you don't like certain zeros and ones being passed around

I run Knots, there is nothing to discuss. Vitalik is waiting for you.

I'm not defecting. You are. I'm not a shitcoiner and I have no motivations to shitcoin on bitcoin. You can achieve the same results of knots with core. But you don't understand the technicals so you're just virtue signalling by running knots. I don't care what you run.

Do not attribute motive to me where I have none because you can't argue facts.

You failed to demonstrate how but πŸ«‚

We are speaking a different language/cannot agree on first principles, so it makes no sense to continue. Luckily we don't need to agree as Bitcoin is decentralised and doesn't care.

Nodes set mempool policies for their own mempool.

A matter is not a non-issue if parties have an issue. Why not lower the node default limit instead of raised (or eliminated) if it is a non-issue?

Obviously some do care.

I believe it's a non-issue because the detractors motivations for setting that policy are inconsequential to the results. It doesn't matter if you raise or lower it that's the whole argument.

The argument to eliminate would be precisely because it doesn't do anything in practice with the actual network only to the local nodes Mempool. The reason detractors do not want it and their mental are not performance related. Their motivations are altruistic. Bitcoin is software. Computers don't care about your altruism. Does the filter meaningfully impact node performance or hardware requirements? Does it change the network?

If the answer is no to both, then data carrier filtering is useless code. If it's useless code it should be removed from core, the reference implementation, and if users want to just truly be altruistic they can run a fork or not update and keep using the filter (If it were removed which it isn't...)

Carving out the subjective pro/con arguments (meaningful vs. useless,) then ask, is the limit important enough to move to a consensus-level check (i.e. required to be passed to be included in the block)? The argument to remove it because it’s β€œuseless code” bypasses the intent of the code, which should be addressed.

The code does what it intends on doing. It filters transactions from your personal mempool. What is the effect of the code on the network?

Nothing.

Because your personal mempool has no effect on what gets mined.

If I'm wrong or you disagree, explain how.

We should remove code from the repo that does nothing in practice.

A consensus level change is a hard fork. You can count me out. I'll lean to sell the fork, but will keep them for a couple months. The winner will probably be clear by then. If the fork coin does not outprice the original in that time frame, it never will.

Code we don’t see as effective sometimes is effective or beneficial for some when the network is operating in the extreme or when concentration occurs.

Even not in the extreme, measuring the effectiveness of something should follow if it does what it is meant to do, and in this case it is meant to stop a node from recognising/relaying a transaction over the limit.

Agreed on the hard fork point.

side note:

modulo is pretty sick. Thanks for making it.

Thanksβ€”a lot of work went into making the modulo key. Being physical it unexpectedly gives positive vibes.

I’d zap you some thanks but I get errors fetching your invoice for some reason.

I’ll think about a response to your response.