Oddbean

I’d wait for evidence on this one. There’s lots of bullshit going around about @OCEAN filtering out inscriptions, people are overly emotional, and when they do that they make stuff up or they exaggerate shit to an absurd degree whenever anything has a hint of helping their position. Wouldn’t surprise me in the least that this could be making the round even though it’s just people *equating* inscription filtering with coinjoin filtering and then sharing around “they’re filtering coinjoins!” This is basically par for the course every time some new drama unfolds. I’ll wait for some very robust data before believing that one.

I actually take a lot of what’s Samourai says with a grain of salt too. I stopped using them when it was shared/suspected that the mobile wallet was sharing the xpub with them, and they just went on a spree of insulting people. That doesn’t mean it’s true, but I couldn’t see anywhere that they denied it or explained why it would look that way. Maybe they are just rage Twitter users, but the convo of no clear answer to the claim & reacting like, with respect, fools - and over an issue that would essentially make their privacy wallet have the exact opposite of anything remotely private… just really turned me off. I haven’t gone back to them since. I’d love to be proven wrong, but I’ve not taken the time to look into it again & it seemed like the one group with the incentive to prove it wasn’t interested. I’ll look at the published data when I get a chance. Will be doing an episode on privacy stuff soon anyway so it will be good to look into.

Ok it looks like Luke has confirmed this is a filtering based on the OP_RETURN byte limit. So it’s not specifically filtering coinjoins, they just happen to be over the 42 byte limits for whatever reason. Both decisions seem odd to me, Luke says there’s no reason for using that many bytes, Samourai says the byte limit has been 80 for ages (which it has). So now I’m curious what that data is for in this scenario. And why either side cares about this. Seems like both have the capacity to fix this if the excessive OP_RETURN data isn’t even necessary. Also curious if this is something that specifically distinguishes whirlpool transactions from other types (which there might be numerous other ways that this happens), just because it would seem beneficial to look as inconspicuous as possible rather than stand out in whatever way their use of that may imply. In other words, this seems like something either party could fix potentially but knowing how stubborn they both are, it might not change.

I just read through it all. I was only pointing out being skeptical to someone who seemed to be taking it at face value. Accepting it because “everyone else is” is not the best strategy when it comes to this sort of social beef, imo.