pull down to refresh
144 sats \ 27 replies \ @ek 23 Oct \ parent \ on: "Quasi-consensus": help me understand this conversation with Chris Guida bitcoin
Is it also fine if a nation state does that as a “user of the network”? They can spin up as many “users of the network” as they want.
as far as my node is concerned, it is very difficult to tell the difference between a node and bot.
I once brought this up to Mechanic and he said it would be trivial to notice a government spinning up a large quantity of nodes.
and when I asked how he knew that this hadn't already happened, he stopped talking to me, like Chris.
reply
So, have you found out yourself or just posted your story to mock a person?
reply
No, but that's not because of how they're using the network. It's because they shouldn't exist in the first place.
Does spinning up tons of nodes reduce the ability of existing nodes to broadcast to miners? I'm not sure why it would, at least not to a significant extent.
Let's say that literally every person who runs a node voluntarily opted for a mempool policy that doesn't transmit certain consensus valid transactions. Why am I supposed to care that this is possible?
reply
Does spinning up tons of nodes reduce the ability of existing nodes to broadcast to miners?
Yes, if they are maliciously used to eclipse nodes.
reply
isolated from all honest peers but remains connected to at least one malicious peer
That seems like a pretty extreme condition, and doesn't seem like something that would come about simply by spinning up a bunch of nodes. They'd also have to prevent connections to any honest peer.
reply
doesn't seem like something that would come about simply by spinning up a bunch of nodes
Your node connects to random peers. If most peers are malicious, the chance is higher that all of your 8 outbound connections (default) will be consumed by only malicious peers.
They'd also have to prevent connections to any honest peer.
You don’t know who is a honest peer or not.
reply
Sure, but why am I only connecting to these newly spun up malicious peers?
Are you talking about long-term dynamics or immediate impact of spinning up a ton of nodes? I was thinking about the latter.
reply
reply
I certainly don't, but I don't know whether it's something people can know. Either way, it's not my point.
At t1, I'm connected to whomever I'm connected to. If they're all malicious, sucks for me. If some are honest, apparently I don't have to worry about an eclipse attack.
At t2, some dick spins up a ton of malicious nodes. My previous condition is unchanged.
reply
Let's say that literally every person who runs a node voluntarily opted for a mempool policy that doesn't transmit certain consensus valid transactions.
I suspect new ways of reaching miners would emerge.
If not, why wouldn't this aligned group of node runners just use their mempool polices to determine the block validation rules (I think this is a better term for consensus rules, courtesy of #1263085) of Bitcoin?
Does spinning up tons of nodes reduce the ability of existing nodes to broadcast to miners? I'm not sure why it would, at least not to a significant extent.
Isn't this your contention from earlier? (#1262882)
It's fine for the users of the network, acting in aggregate, to make certain types of transactions difficult or expensive.
How could users of the network make certain types of valid transactions difficult or expensive except by impinging on the ability to nodes that disagree with them via having many many more nodes?
Personally, I don't believe the relay network is an effective way to increase the costs of getting a valid transaction confirmed. Possibly it achieves this effect in the very short term, but the incentives are such that it will quickly get routed around.
reply
Isn't this your contention from earlier?
No. Or, it wasn't my intention to make that contention.
I suspect new ways of reaching miners would emerge.
As do I, but I chose an intentionally extreme example to help articulate my thoughts.
How could users of the network make certain types of valid transactions difficult or expensive except by impinging on the ability to nodes that disagree with them via having many many more nodes?
Maybe it's been answered in the other comments, but number of nodes doesn't seem like the driving factor. It's about paths to successful miners, which will typically be related to number of nodes, but might not be in some extreme cases.
reply
we are mostly in agreement.
I know that there has been a lot of work done on the p2p network part of bitcoin software. In general, I believe this has been aimed at making it difficult to eclipse a particular node or prevent a node form learning about new blocks.
I brought up the number of nodes ("many many more nodes") because it's the only thing I've heard put forward as a reason that filtering is useful at all. I, too, disagree that numerical eclipse is ineffective, but I've never heard anyone provide another reason why running filters is important.
reply
If filters don't work (and I'm not arguing that they do), why is there such a stark cutoff at the old OP_RETURN limit?
This is why I was bringing up the case of everyone on the network opting for a particular policy. As I understand it, basically all nodes had the same policy in that regard and we hardly ever saw transactions that didn't conform to it.
reply
This was a point Chris brought up and that I did not respond to.
I'd sat that chart he presented showing a clear absence of OP_RETURNs is evidence that there really hasn't been much economic demand for op returns that are bigger.
As I understand it, basically all nodes had the same policy in that regard and we hardly ever saw transactions that didn't conform to it.
Mempool policy can nudge one way or the other, but I believe it is very gentle and as soon as there is any kind of sustained demand for transactions that go against policy, it will quickly crumble.
reply
The drop off is so steep, though.
Unless there's a particular reason for demand in the 80-83 range but not in the 84-87, it seems ludicrously coincidental that it just happens to perfectly match the default Core policy.
reply
I agree, but I'm inclined to believe this story:
I think mostly people have mostly produced op-returns in under the old limit because it didn't occur to them to do bigger, or if it did, they didn't think it was worth the trouble. but I also don't think that will last.
I'm not sure I'd support it, but I would have given much more credence to a proposal to change block validation rules and limit op-returns there than this foolishness with mempool policy.
I seem not to have done a very good job, but I'm trying to argue that block validation rules are such that the using mempool policies in this way is illogical. the validity rules of bitcoin are designed to break such inconsistencies.
mempool policy rules are a like thin ice over a lake. they may form a barrier, but it's treacherous and not to be trusted.