Thread

Replies (27)

The closing section of that article, β€œunnamed crypto lawyer” agrees with the knots side. Every other section admits it’s a low risk attack vector, but they all admit it’s a risk. The knots side of the argument is acknowledging the risk, and deciding its not a risk they want to take. At this point I think both core and knots proponents understand you can chop up, compress, encrypt, encode etc data and get it onto the blockchain as it is. It’s not a technical competency thing, it’s a conservative vs progressive view point.
Thank you for the article. Historically I’ve had a lot of trust for the court team and many who are currently pro-v30, and it seems to have been very hard to get clear responses on specific concerns with this issue. This is the best such response I’ve seen from that camp. However this article and its somewhat misleading headline does NOT contain a strong argument sufficient enough to dispel concerns surrounding the v30 changes. Its content sums up as more neutral. While it points out some reassurances that are all based on current status quo there are several strong statements supporting the idea that this could trigger a downfall. Most of the reassurances here are dependent on two things 1) an assumption that there is too much interest in protecting Bitcoin for an attack to succeed, and 2) the hope that because you can already put small bits of data into the blockchain, find them and then reconstruct them all into something illegal isn’t different enough, from having fully intact readily visible illegal material, to trigger a substantial enough legal attack. Yet the article appears to be somewhat comprehensive as it does provide counter arguments to this, including a dozen statements that sound potentially damning and supportive of the β€œanti-v30” camp’s arguments. Nick Szabo who is credible in both Bitcoin and legal spaces, who was not included in the article shares the sentiment that the changes are an unwise threat. The article bolsters confidence that the current v30 changes should not be released but be tabled for more review and development. Does the article represent the strongest counter points the pro-v30 minds have?
The thing is, the one and only purpose of putting CSAM onto the chain would be to attack Bitcoin. There is no compelling case to be made that the blockchain or the relay network could be used as an uncensorable file sharing tool where in order to stop that, Bitcoin would need to be stopped. That's like forbidding all water pipes just because some sicko put poison into the water supply once. The attack of putting CSAM on the blockchain doesn't get materially harder with the relay network not supporting 100kB OP_RETURN as the blockchain already supports it and the attacker could get it mined over time by simply submitting it directly to small enough miners that don't filter. To re-iterate: Yes, it gets harder to submit that one picture of a crime but given what there is to be gained by destroying Bitcoin - if that was the downfall of Bitcoin - is many orders of magnitude more than what it would cost to put the material there, the difference is not material.
I can appreciate those points. Here’s where that seems to take us. - β€œpurpose of putting CSAM onto the chain would be to attack Bitcoin.” You are correct. - β€œβ€¦no compelling case …network could be used as an uncensorable file sharing tool …” Once someone can use software to access and view illegal content that is embedded in the blockchain, how would you go about stopping that? - β€œit gets harder to submit that one picture of a crime…” Correct. - β€œβ€¦many orders of magnitude more than what it would cost to put the material there…” Seems that’s actually a very small price to pay if it means you’ll gain or retain dominance over societies, especially when you can make those societies actually pay for that cost to begin with.
BitcoinIsFuture's avatar BitcoinIsFuture
This is what the evil shitcoiner Jameson Lopp and Citrea (Chanway labs too, Chaincode and so on) are after - the compromised defaults in Core config by the corrupted Core devs He is signaling to the compromised Core devs that undeprecating the option is acceptable because most node runners won't change the malicious defaults. And then adds a bit distraction about freedom which he doesn't care. He is a fiat and Ethereum cuck that doesn't care about Bitcoin thats why he loves inscriptions so much and that is why he excuses CSAM on Bitcoin. image View quoted note β†’
View quoted note →
"We're hearing things like Citrea is better than Ethereum," Chainway Labs co-founder Orkun Mahir Kılıç told CoinDesk. "It'll be better with time, because there's like $1 trillion, as of now, sitting in the Bitcoin blockchain. It is the most secure, battle-tested and decentralized blockchain. And we are bringing decentralized finance to it." 🀑🀑🀑
The technical reason is that maintaining code that isn't used anymore is an unnecessary burden and risk for bugs. So at 83B, the OP_RETURN is actually cheaper to be used than any method that would get the SegWit discount. That flips at 160B? So any protocol that would need more than 160B would bleed sats using OP_RETURN as it would have an unnecessarily high marginal cost. Now as that is true, it is a very valid argument to consider all protocols that use bigger than 160B OP_RETURNs uninformed or malicious.