Thank you for responding nostr:npub12rv5lskctqxxs2c8rf2zlzc7xx3qpvzs3w4etgemauy9thegr43sf485vg. It did help me understand your perspective more, but it also brought more questions:
1. So I appreciate your coverage of L2s. I do want L2s, bitcoin global scalability, and anonymity to succeed. And I do want bitcoin to be used as a medium of exchange at some point. But is scalability currently an issue? How much data does an L2 need currently to store data? Are L2s being hindered by op_return default cap rn? Do you think increasing the op_return cap slowly instead of removing it all together, would be the more responsible thing to do?
I might be totally wrong here, but my understanding is that op_return was working at filtering spam (there was no cat and mouse game with spam) and then taproot unintentionally gave spammers an alternative route. Shouldn’t that be addressed by devs instead? Doesn’t this also show us that making changes to the protocol can introduce unforeseen consequences? So again doesn’t going slowly seem more logical?
2. This is starting to get past my current knowledge regarding bitcoin mechanisms so I appreciate you trying to break it down for me. You said when L2 fee estimations are off there is a risk of losing money; does this mean fees could be a few sats more, or can a whole transaction get voided? Neither is acceptable but trying to understand severity there.
I guess I don’t want mining centralization or node software development centralization. Are you saying that when a large mining pool mines a block they get a head start on the next block because other nodes have to wait for that block header to get relayed? And the relay is slowed down when there isn’t node software/rule uniformity?
Anyway this is super interesting and I appreciate your insights. I do want to get things right as a node runner.