Thread

This is their same stupid argument! They keep saying this. It is red herring. It focuses on another issue that has nothing to do with op_return.

nostr:nprofile1qqsfnw64j8y3zesqlpz3qlf3lx6eutmu0cy6rluq96z0r4pa54tu5eqpz4mhxue69uhkummnw3ezummcw3ezuer9wchsz9thwden5te0wfjkccte9ejxzmt4wvhxjme04cq3qh In the abstract he is right, in practice it is irrelevant here is why: With the current 80 byte you cannot get any image, illicit or otherwise, relayed around the network's mempools. Because of this it will reach miner. Therefore your have to use a service such as Slipstream to get attempt the miner yo include it directly. The miners offering this are publicly traded entities. They will review the content that you are attempting to upload to the chain since they are liable for enabling its transmission. If the content is illicit they will obviously stop any upload (and hopefully report you). At that point your are effectively out of options other than trying to mine a block yourself, which is effectively impossible of course. So yes any transaction included in a mined block is transmitted around the network. But in practice the worst type of illegal content is just about being kept out by the current filters and set of incentives. It seems obvious therefore that it would be a grave mistake to mess around with this delicate balance by removing existing filters.

Yes that's exactly my whole problem with removing or messing around with filters and also with moving the 80byte to 100kb.

Apparently this PortlandHODL guy runs Slipstream for $MARA. Portland has stolen data from Comast as has been bragging on a Twitter SPACE about DDOS attacking Knots runners. The CEO of $MARA was in attendance and laughing. So, looks like the CEO of $MARA is not so concerned about crime, about stealing data from an ISP and using the data to disrupt people's internet / run up their ISP bills. Local law enforcement should look into this. Does Comcast know about this ? Sounds like an issue for the SEC, CFTC and FBI. It's all public on Twitter.

Lopp is already known for his false narrative. nostr:nevent1qqs9mnye99pkh22xl8cqrzyyfmlpmvkwel3ua68a96ea9mqdlrqlq2qpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz550mq

Its also explained in that video in the first few minutes. nostr:nevent1qqsg5jc7cqkt5yhdsgh8jp2lw4ul42yyl0xkt2wkr34qzgqh6fuuhygpzpmhxue69uhkummnw3ezumt0d5hsz9thwden5te0wfjkccte9ejxzmt4wvhxjme0qy2hwumn8ghj7un9d3shjtn90p5hgtnsw43z7qu0y8a

Basically, this is correct. As long as you want your node to serve as a source of truth for the blockchain, once data gets in it, you can't really get rid of it. That is, after a node has verified each block, it could conceivably prune all the op_return data, for example; but then, the node would be useless for anyone else to subsequently download a block and verify it for themselves. This is, of course, a strawman argument. Virtually no one argues that node policy filters make it impossible for undesirable data to make it into the blockchain; but filters that are practically ubiquitous (at least until Core 30 goes live) do obviously hinder it - requiring, as of yet, non-standard measures to evade. A consensus rules 'filter' could potentially be a different story - but that would likely come with opening a Pandora's box that I doubt there's much, if any, serious appetite for.

This argument conflates two separate issues: 1. Relaying unconfirmed transactions 2. Relaying blocks validated by your node. The first is something you should be able to control and filter as a node runner. The second you cannot control if you want to be a part of the current network as a node runner. Saying "filters don't work" is saying you shouldn't control what UNCONFIRMED transaction your node propagates because some other node might send it along to a miner and eventually get included into a block which you HAVE to relay to be part of the network. Filtering txns makes it less likely that a spam transaction makes it into a block though obviously not impossible.