A response to some of Chris Guida's points I posted on Delving:
Discussion
I can't for the life of me figure out how to find Chris Guida's @ . If anyone could find that it would be appreciated, not that it matters much.
search: guida, found posts
nostr:npub19z2uxvxz8uurr9kqa7vgmek6swurk3vra40ec8kmpf2eemx3lyqq6zfkd4
What is the purpose of filters and "standard transactions" then? If policing is bad at any layer because it could interfere with future innovation, then isn't this a case to remove all filters and be gone with any sort of standard transaction filtering?
(If I am reading your post correctly.)
Yes, good question. There are relay standardness policies like minrelayfee that are about DOS protection for nodes in terms of bandwidth etc.
I should probably research it, but as i remember there are others that are not like that, perhaps non-standard scriptpubkey types, and those would fit into the rubric of what I'm saying here, agreed.
Hmm as I write that I realized the obvious point that unrestricted scriptpubkey types might themselves represent a dos threat: but there's a still a distinction to be made, right, between limits on size (and parsing computation), and limits on "type".
There is a distinction and it indeed gets a bit fuzzy. I.e. outputs bigger than 64?bytes (iirc) require extra allocations when writing to disk, but obviously that's no argument for prohibiting other types. A weaker reason with stronger (lol!) assumptions about its usage is that it should be theoretically spendable unless marked as such. Some script pubkeys might not be, which is a reason to only allow "types" that at least formally are.
Yeah i came to the same conclusion when i thought about it. It's obviously the practical choice to use a limited set, while the op_return carve out for data is ... not obvious, but has a clear purpose but can be argued against, for sure.