pull down to refresh
102 sats \ 10 replies \ @Undisciplined 23 Oct \ parent \ on: "Quasi-consensus": help me understand this conversation with Chris Guida bitcoin
No. Or, it wasn't my intention to make that contention.
As do I, but I chose an intentionally extreme example to help articulate my thoughts.
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.
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.
reply
sure, I'm happy to agree that mempool policy has effects and that they may largely be determined by defaults. but I'm disagreeing (perhaps not with you) that the effects of mempool policy will remain in the face of demand for transactions that are counter to them.
In the filter debate, it has frequently been positioned as some kind of existential threat to bitcoin (spam is going to price out economic transactions! jpegs are going to make it expensive to run a node! CSAM is going to get node runners sent to jail!) and in all these cases, my contention is the only way to address the matter is via block validation rules. Mempool policy can only provide gentle nudges, and if any of the breathless fears of filter proponents were actually real threats, it would be trivial for a state actor to bring them to life by making such transactions.
Many people have also pointed out that ultimately it is impossible to prevent arbitrary data from being embedded in blocks. I recognize this truth, and therefore believe we must either accept that no valid transaction is a real threat to Bitcoin or accept that Bitcoin doesn't work.
reply
I'm with you on all of that, except the CSAM part.
If I'm understanding the concern correctly, it's specifically that by not filtering it there is a period of time when it is stored unencrypted on your device and then transmitted to others.
That's not an existential threat to bitcoin, but I do believe it will land people in prison and I would certainly adopt a mempool policy that doesn't allow it (or at least demonstrates I was trying to not allow it).