Replying to Avatar Bill Cypher

Here is what I learned arguing with people on both sides of the op_return argument. Cunningham's Law in full effect for sure.

1. The Bitcoin blocksize limit is unaffected by the PR. A full archival node is going to grow hard drive storage at up to 4MB every 10 minutes, that number does not change.

2. That 4MB is with maxed out witness data. The base block limit is 1MB, also unchanged.

3. Op_return is base block data while most current arbitrary data schemes store in the larger witness data area.

4. The true limits were always only at the block total level. The total can be made up of any combination of sizes of the sub fields, this is unchanged. My initial assumption on this was backwards. I thought the block limit came from the collection of limits of sub types of data because of my background in networking where that is how the TCPIP packet limits are set. See my incorrect posts earlier where I got this wrong and got corrected.

5. Any "limit" on any particular field size that you set only affects your mempool. This means those limits affect what is in RAM on your node only, not drive space or bandwidth consumption.

6. Your node always validated blocks with any op_return that fits into the base block. This is true of core, libre, and knots. This is why the large op_returns during the dispute did not cause a chain fork even though knots had a limit of 80.

7. More bluntly, nothing changes about what blocks validate. The node runners still have full control over validation and they are not being asked to change validation rules.

8. Only what is carried in mempool will change and no hardware usage changes for nodes.

9. From a TX side, getting nodes to carry the larger op_returns in mempool means they don't have to pay miner accelerator markups. Removing the markup will make op_returns cheaper than the witness data schemes used by most current arbitrary data. This is the entire purpose of the change.

10. Changing op_return to be cheaper than witness data should get arbitrary data users to prioritize using op_return.

11. Witness data cannot be purged from a pruned node without losing economic transactions. Op_returns can be purged in a pruned node, though this may change if future L2s require op_return arbitrary data. That would only affect node runners who wanted to support that L2.

12. 11 means that after the change pruned nodes should have lower hard drive capacity requirements for the same amount of arbitrary data stored on chain.

13. Very slowly for the back of the class. It should be easier for people who don't want to store arbitrary data to not store arbitrary on their node hard drives after the change.

14. Not keeping large op_returns in mempool means you have an incomplete view of who you are bidding against when you set fees for your on chain transactions. Right now this is not a big deal because there aren't many large open_returns. Once there are more, particularly during arbitrary data rushes like the taproot wizards craze, you may wait many blocks after paying what you thought was a next block fee.

15. 14 is most important for lightning where timely automated transactions can be critical such as justice transactions.

16. Mempool has a user set size limit. It drops transactions based on fee. Only the highest fee TXs stay in mempool if mempool size exceeds your limit. This means that storing large op_returns in mempool does not increase RAM requirements for your node.

17. Satoshi stored arbitrary data in op_return not witness data.

So TLDR.

I support the change now. For people who don't want their node resources used for arbitrary data, this makes it easier for you while Knots actually makes it harder. I'll be staying on core and I will be upgrading.

That said, I still think core and the insiders who support this handled it like a bunch of asshats. Pathetic public relations and they need to do much better in the future if they want to be taken seriously. If one person doesn't get it they may be an idiot, if the entire class doesn't get it you are a shitty teacher. Stop condescending and work on your teaching skills.

Great summary thanks

Reply to this note

Please Login to reply.

Discussion

Thanks. The real shocker detail to me is that if you follow the rabbit hole all the way down running knots increases the likelihood of storing arbitrary data.

Is that because the data would be stored elsewhere (like current state of things somewhat), and that is not prunable?

I haven't tried to follow too closely, figured I'd let dust settle.

Yep, current cheapest place is witness data because pool accelerators that bypass nodes charge a markup. Witness data is needed to know every economic transaction. Removing the accelerator markup makes op_return cheaper. Op_return can be pruned without losing any info about economic transactions.

Your post distilled down most of what I've gathered nicely. The noise then would seem to be mostly about process and other drama on GitHub.

Or maybe it's that default changes to core are as good as law (for now). Thus it is signaling that bitcoin wont resist spam and will make it cheaper and easier, even if the data is prunable...

I probably need to think about it more.

Yeah, core definitly fucked up the public relations on this and a lot of people are just opposed out of spite.

If you've never dealt with trying to filter data it is easy to think it should be easy to filter however you want. The reality is it is impossible if you have a determined adversary, this is why spam emails still get through after all these years.

We will never stop them but we can engage in harm reduction. Getting them to put their data into prunable fields instead of fields we can never prune reduces harm.

Since the block size is unchanged I don't see this affecting the ability of regular people to run full archival nodes. Note that the knots people aren't switching to pruned nodes, they just get a mempool filter that causes them to not have accurate mempools.

I get that no one node has a perfectly accurate picture of the entire global mempool. That doesn't make it smart to intentionally make your own mempool innacurate.

Yes, as someone who doesn't deeply understand the mechanics of this particular spam nor the general theory of spam mitigation, agree.

It's a bit more than bad PR because of blind reliance on core implementation by majority means they get to make this type of call. Silver lining might be that awareness raised over a lesser issue than one that may come in future, at which time we can hope for more diverse options and more educated users, and changes to core defaults won't be law necessarily 🤔

$2T USD total market value and we are still letting the devs talk directly to the users. No corporation that size would dream of doing something so stupid. Big companies use a translator for Dev <-> User communication for a reason.

I don't like the idea of some suits interfacing with node runners more than devs...

Conclusion is maybe there should be no such thing as "The devs"?

I'd be willing to take the job of translating between dev and human for the core team. I promise not to wear a suit.

You need more conflict of interest to gain interest from Opensats.

I hear Vitalik is having public relations issues too. I could apply for the same role for him and be one of those people with 2 full time do nothing jobs. That should be conflict of interest enough, slinging ETH got Loop in after all.

With a name like Bill Cypher, I think I might support that.