pull down to refresh
0 sats \ 24 replies \ @Undisciplined 23 Oct \ parent \ on: "Quasi-consensus": help me understand this conversation with Chris Guida bitcoin
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?
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
reply
That's what I wanted to clarify. You're talking about the longer term situation.
Since they aren't permanent connections, how many malicious nodes does it take to consistently prevent connections to honest peers?
It seems like it would have to be an overwhelming share of the network, but that's just a gut impression.
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.
reply
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
Isn't that an argument that default mempool policy matters? Otherwise, as far as I know, there's no reason why 83 and 84 wouldn't be similar.
I take your point about this not being the right way to address a serious problem, if we had one, because it's easy to work around it, but I don't understand the case for it not clearly having an impact.