You can censor all you want. Just be transparent about it and don’t pussy foot around. People can join your pool or not, it is their choice but you not informing people your intentions from the beginning ruined your own reputation and now people don’t trust you. No one to blame but yourself
The OP_RETURN discussion is not new and dates back to 2014 when Bitcoin Core 0.9.0 was released with the OP_RETURN policy included which was intended to discourage more egregious forms of spam. At that time, 40 bytes was the default max datacarriersize limit across all node implementations; this was and still is sufficiently large for tying data to a transaction (32 bytes for a hash and 8 bytes for a unique identifier). Core subsequently increasing the default to 80 bytes was an entirely voluntary decision and in no way contradicts the design objective that OP_RETURN creates a provably-prunable output to minimise damage caused by data storage schemes, which have always been discouraged as abusive. There are also other good technical reasons which I have chosen to retain the lower default in Bitcoin Knots, and no justification for increasing it.
It is not my intention, nor that of my team at
nostr:npub1qtvl2em0llpnnllffhat8zltugwwz97x79gfmxfz4qk52n6zpk3qq87dze, to filter coinjoins. These present an innovative tool for increasing Bitcoin’s privacy and, when constructed properly, coinjoins can easily stay within the OP_RETURN limit (indeed, there is no reason for them to have *any* OP_RETURN data at all). I have some ideas on how to alleviate the recent issue where some coinjoin transactions were flagged as spam from Knots v25, and I am willing, with the full resources of my team, to work collaboratively on a solution in good faith.
Bitcoin does and always has allowed nodes to set filters based on multiple sets of criteria and Knots v25’s defaults are IMO what is best for Bitcoin at this time. Others may disagree and that is ok. They are free to (and should) run their own nodes - it is good for Bitcoin to have more people running nodes, including miners, and there should be a natural diversity in node policies. As was stated before, OCEAN is on a path to decentralization and very soon we are going to be in a position where hashers will be able to fully participate as miners and perform the intelligent parts of mining such as deciding which version of node software to run and what filters or other policies to apply to block template construction.
Discussion
We're not censoring. They're just exceeding a limit that goes back a decade. We didn't do anything here
It would have helped to point out the details and difference out during the launch event, or on the website.
The missed opportunity to do this marketing right cost goodwill.
Hopefully y’all can openly remedy.
100%
Making a big deal about transparency and then *not* being transparent about this up front was an own goal. :(
I think the point here is to have some conviction on running under a standard-based umbrella.
If you don't like it the conversation continues and you're welcome to create your own mining pool which allows this kind of garbo data.
Did you also bitch about browsers decision to maintain standards adherence, or were you totally cool with IE fucking everything up in their interpretations of HTML rendering?
Yes, Luke has views and convictions. This is great.
The launch missed these sorely. Whoever is Luke’s marketing counterpart either did not understand the finer points and implications of Luke’s standards, or failed to communicate these.
Either way not great.
This wasn't ready at launch, and we publicly announced it when it was
How would you define censorship?
Based on my understanding of it, it is a filter, framed as a filter against spam.
So where would this turn into censorship in your opinion?
If a couple of BTC wizards can raise fees for actual BTC users during a bull run cycle and it causes a slow in BTC adoption THAT is censorship. Limiting the amount of spammable data on chain is not censorship, if anything this is anti DDOS protection. are DDOS blockers censorship?
right on Kartoshi, fuckturds should all move to San Francisco where they can choose to shit openly in the streets and at in the same breath bitch about not having privacy during their shitting shitstorm session, morale will improve once Core implements CVE-2023-50428 remedy. Can't wait till the shit litterers WEF cuckturds have better imagination than obfuscating shit as useful data on-chain.
“Causing a slow during a bull run” cannot be reasonably called censorship, anymore than outbidding someone at an auction is “censoring” them from buying the painting (or whatever). There can be considerations about the way to deal with tons of arbitrary data being shoved into the chain, and basically filtering by node policy probably wouldn’t be a bad idea, could slightly raise fees necessary for JPEGS and NFTS to get into blocks over honest bitcoin transactions.
(funny, something like ocean mining and stratum v2 use would be optimal for node policy having the largest impact)
Well if it was using multiple criteria to isolate and remove all coinjoins of any kind, then it would be censoring coinjoins/privacy use. But if it is simply setting a different limit to one particular transaction characteristic which just happens to catch some coinjoins and not others, then clearly it isn’t censoring anything, or singling out a TX type, or specifically refusing certain addresses because they are deemed “bad.”
Imagine it like this: you setup an email filter to send all emails with the word “unsubscribe” (since it’s always at the bottoms of newsletters & ads) to the spam folder. But it accidentally catches a couple of emails from your friend where they mentioned unsubscribing from Disney+ because Ashoka sucks. Did you censor your friend? Would it seem disproportionate if he got angry and demanded an explanation, and accused you of censoring him and not being open with your email filters?
This whole thing seems to have been a big stink over nothing. Doesn’t seem like anyone was acting in bad faith to me. 🤷🏻♂️