Bitcoin Mechanic's avatar
Bitcoin Mechanic
npub1wnlu...n3wr
Bitcoin Mechanic's avatar
GrassFedBitcoin 10 months ago
Neutral monetary network = Defensible Neutral file storage = Indefensible This necessarily means maintaining the ability to discriminate between monetary activity and file storage. This is self evidently the only way Bitcoin can realistically continue to exist without centralized gatekeepers having to moderate everything for us because we couldn't handle it ourselves.
Bitcoin Mechanic's avatar
GrassFedBitcoin 10 months ago
Old methods of storing evil stuff required obfuscation: they would need to break it up into multiple chunks and reassembly would require specific software and knowledge of what the data is and how to reconstruct and interpret it exactly. The old formats looked like this: "Hi, I'm a Bitcoin transaction, here's my first output of 45 outputs - <filepart1>, here's my second output <filepart2>, here's my third output<filepart3>" along with a tonne of other stuff that has to get parsed out when processing the highly obfuscated material. This is thankfully also true of inscriptions. OP_RETURN however is just a dump for raw, serialized data. It's not the same. It says the equivalent of "Hi I'm a Bitcoin transaction, here's an unspendable output: <file> end". This wasn't a problem for tiny OP_RETURNs i.e their current limit of 80 bytes. If they're permitted to be 100kb, that's where the abuse begins. And that's the end of plausible deniability. When the stuff gets processed - which it has to be for your node to verify that they are valid transactions - then you just have a raw, unadulterated file that will trigger primitive antivirus/forensics software to alert the user: "Hi, you have CP on your computer." You now need a licence to run a Bitcoin node, everyone thinks you're disgusting if you do, and they're not even wrong.
The contents of the blockchain overwhelmingly reflect the default mempool policies set within Bitcoin Core. This is an obvious fact. The pretence otherwise is simply due to Core developers not wanting to have any responsibility in the matter. Which is entirely understandable, but lying to justify this is continuing to destroy trust.
Core have given up trying to deny users the ability to configure datacarriersize - definitely stepping back from the ledge so that's progress. What remains is a new default that will be 2,500x the size of what it is currently. Remains ridiculous, sorry. Core nodes should not - by default - cause users to relay more non-monetary activity around the network than necessary as it is obviously not in their interest. 40 bytes - the old default - was reasonable. This allowed side chains and hashes of however much data you wanted. 80 bytes was an unnecessary compromise. Changing it to 100,000 bytes by default which is "all" the latest PR does is reckless. The excuse that "at that size, the inscriptions hack is cheaper anyway so who cares" is not valid. The solution is to implement the fully functional filter that makes life harder and more expensive for inscribers - not blow out OP RETURN limits which provides an easier, if more expensive method of doing what the inscribers are doing. Fix the filters. Stop trying to play reverse whack-a-mole appeasing spammers constantly pushing for changes to Bitcoin.
"I'm not here to tell you Rust is the best programming language....you should have figured that out by now"
The fewer lightning channels I have the simpler and more enjoyable life becomes.