pull down to refresh
500 sats \ 39 replies \ @Scoresby 15h \ on: Murch and Chris have a conversation - What is Going on Here??? bitcoin
I've never understood this about Guida's argument: if a lot of people want to use the chain for data, how does filtering stop it?
Even more agree with you here.
The anti-spam crowd says there are valid transactions that can harm bitcoin and potentially even pose an existential threat to it.
If this is true, why wouldn't a state use such transactions to attack bitcoin?
If a state does, do we believe filters will be able to stop them?
If the answer is no -> then anything that can get to the chain can (and probably will) be used as an attack). If there are valid transactions that can threaten the viability of Bitcoin, this is a major problem that we probably ought to address with a consensus change.
If the answer is yes -> what do we even need mining for? If filters can stop state actors from confirming valid chains, why wouldn't state actors use filters themselves to prevent us from sending "illegal" transactions?
The whole thing is nonsensical to me.
Either you think the spam transactions are a real problem and you propose a consensus change or you think they are not a serious problem.
Bad actors put CSAM directly into OP_Return on BSV, a comparable if inconsequential Blockchain, after they increased the limit to 100kb, exactly as is proposed in v30 of Bitcoin Core.
Why would states or other bad actors not do this as soon as it was possible?
Using specialised techniques to store fragmentary data that can reproduce an illegal image is an entirely different thing to storing the entire data in a single transaction within OP_Return.
reply
No one is talking about changing what can happen on the Bitcoin blockchain today. There is no change to consensus rules on the table.
Any limit increase only affects the relay of unconfirmed (valid) transactions).
Whatever transactions you are afraid of are valid on Bitcoin's blockchain right now.
reply
Another staw man argument, I know that, as does every prominent knots advocate. Nobody is saying spam transactions are invalid, but the valid spam transactions are not relayed due to Core defaults, and that has always been known. If a miner is paid directly to include a CSAM transaction that has not been relayed by nodes then they would obviously destroy their reputation by tarnishing that of Bitcoin, so that's never happened.
reply
If a miner is paid directly to include a CSAM transaction that has not been relayed by nodes then they would obviously destroy their reputation by tarnishing that of Bitcoin, so that's never happened.
Why wouldn't miners feel the same way for relayed transactions?
Using specialised techniques to store fragmentary data that can reproduce an illegal image is an entirely different thing to storing the entire data in a single transaction within OP_Return.
This statement makes it sound like you believed the only way to include an OP_RETURN of more than 80kb was to do the above.
Why would states or other bad actors not do this as soon as it was possible?
I don't know. But I doubt they are avoiding it because the transaction won't get relayed.
Which gets to my second point: if filters are that powerful, what will we do when a government decides to use filters to prevent transactions they don't like?
reply
: if filters are that powerful, what will we do when a government decides to use filters to prevent transactions they don't like?
Explain the mechanism of co-opting all of the nodes. Its not enough to overwhelm the nodes by number, if that were feasible.
reply
What percent of nodes on the relay network do you believe a government would need to successfully prevent a transaction from getting to miners?
reply
Its a bad question, it's not a matter of percentages.
If a government or other bad actors spun up 10% or 900% of the current node count using a Bitcoin Core fork it would identifiably be considered a sybil attack, by overwhelming the policy settings of existing nodes. Countermeasures would be deployed to mitigate the damage and demonstrate hostility to spam and CSAM in particular.
But by getting rid of policy settings entirely via Bitcoin Core software it gets rid of the idea that policies are part of the consensus mechanism and security of the network. You can believe that is the case, and other people disagree, and so we fight it out in public discourse.
Dismissing knots advocates with rhetorical techniques is just the strategy of people who want to change Bitcoin by getting rid of a core function of nodes within the system.
reply
the idea that policies are part of the consensus mechanism and security of the network.
This is what I'm struggling with. Eg. There are some valid transactions that could lead to quadratic hashing and that could cause nodes to get stuck or slow down.
But the only real solution to it is probably to do something to consensus code that fixes this.
Just hoping no one mines such transactions seems like a not very rigorous way to go about making a censorship resistant network.
I think the same thing applies to "spammy" transactions.
Dismissing knots advocates with rhetorical techniques is just the strategy of people who want to change Bitcoin by getting rid of a core function of nodes within the system.
Afaict, @Scoresby simply asked you questions. What rhetorical techniques did he use?
Because by being relayed first they are acting on the tacit approval of the network, or a significant portion of it, and are not more culpable than those nodes who saw the content and chose to relay it.
Bottom line: are nodes relating CSAM today? Would removing the filters as Core policy increase or decrease the likelihood of them doing so?
Bitcoin will always be vulnerable to spam, but being vulnerable doesn't mean that the system is destroyed by the vulnerability, unless nodes decide that this vulnerability is in fact a feature.
If spam is simply data, which has as much a place on the chain as any arbitrary data then bitcoin changes from a system that represents value via transaction data, to a protocol for sending and receiving data with intrinsic value, i.e. not a neutral medium of exchange.
reply
When did this become about CSAM? nobody was talking about this for the last year. It's all been utxo bloat and making it hard for node runners.
The CSAM stuff is a complete red herring.
unless nodes decide that this vulnerability is in fact a feature.
Nodes only decide whether a block is valid or not. And they exert the force of their decision by saying, "I don't want those coins you are trying to give me." They can't do anything else to influence what ends up in blocks.
If you run a node that isn't connected to a wallet (that isn't validating coins you want to receive), the node is useless and does nothing other than keeping an updated copy of the chain.
I'd go even further to say that if the relay network is essential to Bitcoin functioning, we aren't censorship resistant anymore.
reply
When did this become about CSAM? nobody was talking about this for the last year. It's all been utxo bloat and making it hard for node runners. The CSAM stuff is a complete red herring.
I don't believe it's a red herring at all. I've always been worried about the ability/ease of putting CSAM on the blockchain as an obvious government attack vector.
reply
Don't you think that a government could do it if they wanted to? If they are desirous of shutting down bitcoin in this manner, they don't have to increase the OP_RETURN size, they just have to get a miner to mine a transaction. Why would they go through all the trouble of subverting an entire open source project? Way more could go wrong.
After all, what prevents a GOVERNMENT from attacking Bitcoin by spending a relatively modest amount of money, taking Bitcoin and "dividing it up" into millions of UTXOs for which only THEY have the keys? Even more agree with you here.
What will this accomplish other that bloating the UTXO set?
reply
That's exactly what it would accomplish.... bloat the UTXO set faster (the set is always growing, typically). That makes it harder to run a node over time, and could be an attack vector. At least that's what I would do
reply