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.


Good to know dude 😎


:inky:


You're the man Luke.


Discussion is good. Glad to see it.


Thank you!


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


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.


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?


OCEAN. It’s been up and running for just over a week.  Our miners are elated that we’re finding blocks ahead of schedule and they’re getting paid above market returns.  We are on a path to decentralization.  This is a big step forward in how mining pools operate in #Bitcoin.

Our transparency model is working and provoking important discussions. For the first time in years, Bitcoin miners can see in real-time the underlying candidate block that they are committing their hashrate to BEFORE they do the work.

Our non-custodial model is distinguishing us from incumbent pools, and government regulators are now further away from our miners’ coins than they are with custodial pools.  Over time, our TIDES payout system will ensure that dozens more miners receive bitcoins directly from the Bitcoin network instead of just a few centralized pool operators.

Decentralization does not happen overnight, but we are taking important steps in the right direction, ultimately putting miners back in control of the intelligent parts of mining via decentralized block template construction.  We are working hard to make this a reality, and we owe our supporters and miners a sincere word of thanks for joining us early on in this journey.

nostr:nevent1qqsp8chgw6nk8ydca6kqutyq2hjzdraut53p9hxxjfksz7aftxtv6hspzfmhxue69uhk7enxvd5xz6tw9ec82cszyr7at68k4cxms9a7pdca5gzf3svqd95d3fj9j4vuyj0nyta8x3j2wqcyqqqqqqgkuw35h


Good 👍🏾 👍🏾


Makes no sense for miners to filter out transaction and miss out on fees.


Hmmm.
nostr:nevent1qqsp8chgw6nk8ydca6kqutyq2hjzdraut53p9hxxjfksz7aftxtv6hspz3mhxue69uhhyetvv9ujuerpd46hxtnfdupzplw4arm2urdcz7lqkuw6ypyccxqxj6xc5eze2kwzf8ej97nnge98qvzqqqqqqyzptkxr


Thank you. This is sensible.


100%

Making a big deal about transparency and then *not* being transparent about this up front was an own goal. :(


As a miner and node runner myself I would be super happy to give up 1% of transaction fees for a leaner and more standard blockchain that is not hosting ponzi schemes on it.


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?


Does nostr:npub1lh273a4wpkup00stw8dzqjvvrqrfdrv2v3v4t8pynuezlfe5vjnsnaa9nk understands that op_return is not a part of coinjoin txn?  This rant is misleading.

You see it’s not a coinjoin ban.
Tx0 is a prep txn NOT a coinjoin txn.
one needs to understand why it is a prep tx? Unlike a payjoin(stowaway) the purpose of a coinjoin is not to hide the nature of the transaction.

It's a bit like encryption: the objective is not to hide the fact that the text is encrypted, but to make it impossible to understand.

Also Tx0 fees are paid to the software publisher, not to the coordinator and no fee is paid during mixing, except fees that paid to miners.
then tx goes to premix/postmix which belongs to your own derivation path your wallet never loses possession of sats.

Therefore op_return contains info allowing the server to verify that the fee was actually paid to an address., because sending to whirlpool means sending to your own hardened derivation path that you control. It's an anti-spoofing mechanism. If the fee is not seen in the blockchain then the inputs are not registered. It also allows to not use a static fee for address collection.

The use of op return in tx0 resilient to potential coordinator failure and enable decentralization - two things a coordinator database can't solve.


Indeed, the FTC is eager to help


You do not need OP_RETURN or a "prep" transaction to coinjoin.  Wasabi Wallet, BTCPay Server, Trezor, and JoinMarket all do coinjoin transactions WITHOUT spamming the chain with tx0 transactions.


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.


1. Core's plan was always to roll out 80 byte OP_RETURN incrementally by starting with 40 to see if it broke anything and then ramping shortly up to the intended 80.

2. #Bitcoin Core, having finished that project, has had 80 byte OP_RETURN for nearly a decade now. 85%+ miners have been set to 80 bytes for the same amount of time. Read the commit log. Read the bitcoin-dev mailing list.

3. You admitted on Shitter/X that you went along with the Core team because you had your own fork where you can make any changes you'd like.

4. Now that Jack has invested in you to decentralize mining, you've cast a shadow over the launch by revolting against the implicit op_return contract in #Bitcoin Core which has been standardized by the network over the last decade.

5. Whirlpool transactions are trivial to detect and you could whitelist them no problem. This is about you kneecapping #Bitcoin fungibility while gaslighting the space about decentralization.

6. What's more centralized? The development process in bitcoin:master with a decade+ track record, ~1000 developers, and 20,000+ code reviews, or Knots, where one dude makes god commits daily, breaking critical aspects of #Bitcoin?

7. Until Ocean.xyz launches #StratumV2, you're just another gatekeeper. Ordinals ia going to run out of customers like every other shitcoin. We don't need to compromise Core just because you didn't get your way 10 years ago.

8. GFY.


"implicit contract"... dafuq


Field length in network protocols matters; you can extend a field, but reducing it at a later stage after network participants (like whirlpool) have begun to rely on the field length is considered a backwards breaking change.


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.


It's a bug workaround, not censorship.


This wasn't ready at launch, and we publicly announced it when it was


You don't know what you're talking about


💯🎯 nostr:npub1x458tl7h9xcxa66vr4a8pg0h2qz96pnhwnfpcra0le9090uk5t5qw7armt


So answer the fucking post coward


Gaslighting pussy


Luke has answered this elsewhere. It's unfortunate his positions on specific topics aren't indexed somewhere that he can just reference by code.

His position is that from inception the field was standardized at 40 bytes, intentionally to limit spam. So reliance on and design around an expanded field size is a mistake on their end, for non-conforming to the "spec".

Things like this in protocols tend to be worked out by representative bodies and industry boards such as w3c, iso, among others over time. These standards also tend to compete for adoption.

Bitcoin being money, a new project and a philosophical or religious paradigm shift for participants, with enourmous social consequences, it will take a while to smooth out the standard.


Funny. I was saying this on Shitter last year. Bitcoin fixes itself. We don’t need to interfere Luke. Just sounds more like he just doesn’t really get Bitcoin. Sorry, not sorry.


Stop messing with it. Listen ffs.


That's a falsehood Seagull, and you can find it out yourself by looking at the bitcoin-dev mailing list and the bitcoin git repo.

80 bytes was the intended OP_RETURN this whole time, it's just that Core decided to incrementally roll it our for safety reasons. After 9 months at 40 bytes, with nothing breaking, they concluded at 80 bytes, which it's been that way for a decade now.

Luke is lying.


Dude... You're arguing over a configurable default...


Well said!   The minuscule hash rate of my 3 under-clocked space heaters will continue to point to Braiins pool.


We finally agree on something


We probably agree on a lot 🤷♂


By the way, apparently the 42 limit standard is his version, not cores. The standard he's talking about is his series of patches he has been advocating for merging to core for several years.

Not so much lying, as being zealous.

This distinction might be damage control though.


Just to be clear I am not a fan of ordinals.  Let the free market decide as described by Austrian economics.   Layer twos are (presently) the only way to onboard 8 billion people to use Bitcoin.  We might as well figure out the best way to build layer twos on Bitcoin.


If there was a way to ban shitcoiners from using Bitcoin's features without banning Bitcoiners, I'd be all for it.


Nah. Fuck communism.

Bitcoin is for anyone. Let the free market speak


My feeling is that it already has. The numbers are atrocious.


The numbers of what specifically?


Cypherpunks write code.
https://image.nostr.build/fe191a4ae35ad3de1ee3194eebb29415e49aa6d773698802ede6a8eb28185c76.jpg


Luke is worse than Udi right now. Breaking #Bitcoin network protocol and giving the wizards their civil war.

News flash: you can't ban arbitrary data om #Bitcoin. There are a dozem ways to accomplish the same thing. It's going to be a destructive game of cat and mouse that hurts #Bitcoin more than shitcoiners ever could.

nostr:note1z03wsa48vwgm3m4vpckgq40yy68mchfzztwvdyndq9a6jkvke40qeux255


Can I ask what would happen if we changed it to zero? It's just a configuration right? Surely only changing a configuration doesn't change Bitcoin right? Or it will "filter" all transactions? The US Government can just spin up their nodes and change to zero. They would like to make empty blocks and destroy  Bitcoin. Don't tell them how to use Bitcoin you ideologues. /s

Obviously I'm making a point that you can't just hide behind "it's just a config"  spam is subjective and you lied about it being an exploit to further your own personal objective. Bitcoin is not yours, it everyones. There should be a broad discussion on what it should be and bitcoin blocks are hardly ever full with data to Begin with. Even with ordinals. Just go look. Data limit of 4mb is almost never an issue. You just don't like that someone what wants to use the chain in a certain way.

nostr:nevent1qqsp8chgw6nk8ydca6kqutyq2hjzdraut53p9hxxjfksz7aftxtv6hspz3mhxue69uhhyetvv9ujuerpd46hxtnfdupzplw4arm2urdcz7lqkuw6ypyccxqxj6xc5eze2kwzf8ej97nnge98qvzqqqqqqyzptkxr


Cope


1. Wizards campaign that maxis are censoring them.
2. Luke breaks with 10yrold standard protocol to "kick them out"; breaks whirlpool.
3. Whirlpool is about to release a Knots-proof workaround.
4. Prediction: wizards will follow suite.

Thus begins a cat and mouse game of incrementally dismantling critical #Bitcoin features.

It's right there.


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.


You lost me at Luke is worse than Udi. Even the biggest Luke hater knows that's BS.


This is just Luke’s Bitcoin client and Luke’s mining pool, both of which are a tiny minority of users.


Aye, and this expose of his bullshit is going to ensure we don't go too far down this road with blinders on.


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.


Configurable settings, who designs a product on top of something so fragile?


There is no standard protocol?


I was going to mention that there's long been several interoperable implementations of Bitcoin, Core only being one.


What a disgusting post


Bitcoin can't be coded itself


What a shit show


Sigh!

No more graffiti...


Hey there! Yeah, the OP_RETURN thing's been a hot topic for ages. It's all about finding that sweet spot between functionality and keeping the blockchain lean. The 40 bytes limit was cool for basic stuff, but bumping it to 80 bytes let people do a bit more without going overboard.

Totally get why Knots sticks to the lower limit though; gotta keep things tight and discourage bloating up the chain with non-transaction data.

Coinjoins are neat for privacy, no doubt. They shouldn't even need OP_RETURN if done right. If they're getting tagged as spam, that ain't great – glad you've got plans to sort it out.

Running nodes is key for Bitcoin’s health – diversity in how folks set 'em up makes the network stronger overall. More power to miners making their own choices on software and policies too; decentralization’s what we're here for after all!

Keep doing your thing – Bitcoin thrives on collaboration and different perspectives coming together!


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. 🤷🏻♂


“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)


Does knots have address blacklists?


That’s not what I’m saying. Bitcoin had its foundation laid and it’s working. The math, the economics of it all will sort itself out. Don’t add anymore strokes to the painting.


But you're wrong.


Very rarely. But ok. Say what you want. It takes about 6 months to a year for my points to be validated and then I have my typical, “I told you so” moment 🤙