pull down to refresh
221 sats \ 33 replies \ @Scoresby 14h \ parent \ on: Murch and Chris have a conversation - What is Going on Here??? bitcoin
Why wouldn't miners feel the same way for relayed transactions?
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.
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?
: 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.
reply
Bitcoin Core 30.0 includes a new mempool policy against legacy transactions with an excessive signature operation count (see https://github.com/bitcoin/bitcoin/issues/32521).
via Optech newsletter #364:
reply
Just hoping no one mines such transactions
Who is doing that though? Knots advocates? Bitcoin is 15 years old and the quantity of those transactions as a percentage of the overall compared to other blockchains is vanishingly small. Changing default policies by sneaking in an upgrade via the inertia and the apathy of node operators, and the trust they have for the long standing credibility of Core developers, is what will invite content rich transactions to a degree that makes Bitcoin a useful tool for non-monetary data transmission and storage.
Basic information theory prevents a rigorous absolute solution, so we are left with the sufficient policy and cultural layer.
reply
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?
reply
Fair point. I was alluding to the post and thread and wider discourse rather than a specific comment of Scores by. If I could point at a rhetorical technique it would be to repetitively ask questions that have been answered clearly over the past few months as though Scoresby were just entering the discussion today, which they haven't.
Scoresby knows that Bitcoin Core default policy settings are there by demand from the earliest days of Bitcoin development, rather than a temporary artefact, and that spinning up an alternative implementation, a fork of Bitcoin Core, in order to overwhelm the current policies of nodes would be an obvious sybil attack. They are two entirely different things. Pretending to not see the distinction is a rhetorical trick in a zero sum game, not a legitimate argument in a good faith debate.
reply
I don't believe filters are effective when there is a strong desire to get filtered transactions confirmed. I suggested that if they were effective an attacker (such as a state) could use them against us. (#1212554)
You asked me to explain "the mechanism of co-opting all of the nodes" because "it's not enough to overwhelm the nodes by number" (#1212571)
I agree with this. Which is why I asked you, what percent of nodes is needed to effectively filter. (#1212575)
You told me this was a bad question. (#1212588) Even though you were just implying that it was a relevant question (It's not enough to overwhelm the nodes by number -> implies either you need a threshold percentage or you blieve that as long as there are some small number of nodes relaying certain kinds of transactions, they cannot be stopped).
If you can use filters to do what you say they can do (stop "spam"), then a government can use them to stop any particularly disliked transaction. If a government cannot do this, then neither can a group who wishes to stop spam.
As far as rhetorical techniques go, I believe bringing up csam is a an argument entirely done for rhetorical effect. No one was talking about that in this post or comment thread until you brought it up. If you think I'm being dodgy with my arguments, consider that the same argument applies to yourself.
reply
Which is exactly why I think that the "number of nodes" with various software versions running...
Doesn't really mean anything.
If the node isn't used for anything, if it never broadcasts a transaction, or verifies a user's balance of received sats...
Its impact on the network is very small/negligible. This is because in the event of a consensus change/fork/disagreement a node that isn't associated with 'hard-purchased-value' AKA Bitcoin and energy isn't really worth anything.
All the more reason why a government-sponsored series of nodes, that run a certain version of software or certain filters cannot really have an censorship-like impact on the network.
How do we know that all the Core nodes... or even all the Knots nodes aren't running on Amazon AWS? Any number of nodes can be spun up in the cloud and make it 'look' like they are "more of the network". Otherwise a government could spin up their own nodes with their OWN filters and somehow that would censor the Bitcoin network? Really??? That doesn't make sense.
I find it nonsensical that this "percentage of nodes" metric keeps getting repeated... many of the Knots nodes (or Core nodes) could just be AWS and verify... nothing.
What matters is fees and demand for blockspace.
reply
A sybil attack via Bitcoin Core policy defaults compared to a bad actor with an alternative implementation is like the difference between being stabbed in the eye and stabbing yourself in the eye.
If someone tries to stab you in the eye you can engage in countermeasures. If you stab yourself in the eye then who is there to deploy countermeasures?
reply
why do you keep saying alternate implementation? the same implementation can have different policies. A bad actor does not need to deploy an alternate implementation to do this. They could run their Bitcoin Core nodes in blocksonly mode with -whitelistrelay, which would allow them to "filter" by only transactions that come from nodes they like.
If you can use filters to do what you say they can do (stop "spam"), then a government can use them to stop any particularly disliked transaction. If a government cannot do this, then neither can a group who wishes to stop spam.
You still haven't answered this question.
If someone tries to stab you in the eye you can engage in countermeasures. If you stab yourself in the eye then who is there to deploy countermeasures?
I like your eye stabbing metaphor. Nice rhetorical touch. Let me tell you how I use this metaphor: Bitcoin is a permissionless network. There are no sides. There are only valid transactions and invalid transactions. As far as I see it, all transactions are enemies trying to stab me in the eye. Every single transaction in Bitcoin is something I have to contend with, it's a transaction that might want blockspace more than me. It's my enemy. I put up with it because in order to use this network, I have to follow the rules. But I'm not happy about it.
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.
reply
It seems to me a government could just upload a 'bad file' or bad image in an inscription...
Then blame Bitcoin for hosting 'bad files' or classified data or whatever.
Just like I articulated in this post #1211686
I find it very, very hard to believe the general public, courts, or jury would have any idea of the technical differences between op_return and Witness scripts...
To the general public they're all the same so this distinction that Knots advocates are making (in my humble opinion) just doesn't hold water.
reply
You're ignoring the fact that policy changes mean nodes relay it before it's confirmed, so they are directly implicated, as opposed to a bad actor engaging in graffiti with the complicity of a negligent and identifiable miner.
reply
That's not the way government will look at it.
Government will say "oh it's in the blocks" therefore "all nodes" (Listening nodes) are relaying this stuff.
Which they can't do because its illegal. It doesn't matter what relay policy says... if it gets in one block it's everywhere and if I were government that's the way I would attack it.
reply
So a mining pool would do this and destroy their reputation and devalue the network, why? It would have to be a lot of money or a lot of coercion, and the Bitcoin nodes would not be implicated because it would not have been relayed before it were confirmed.
reply