Been thinking a lot about my BIP idea to tackle spam. Expanded it quite a bit actually. Would love to hear your thoughts on it.
So, basically, most of my suggestions would initially be filters. This gives users time to adjust before they become consensus rules after a fork. The last one can only be done at that time.
Thoughts on a New BIP Proposal Against Spam?
5 replies 473 views
Interesting. So you’re suggesting a Segwit limit of 0.2kb per input? That’s kinda low.
Like, if a transaction has a single input, it’ll just block more complex stuff like 2-of-2 multisig, right? What if those multisigs come from exchanges, though? Could you end up blocking your own funds?
I reached out to @ertil via PM to get his take on this. Honestly, his posts sound super technical but most won't catch if he’s bluffing or not.
Don't fall for it, guys. If something's confusing, press him to break it down. His aim seems to be throwing around jargon.
Let’s break down the witness space from your earlier example. The total witness space in your transaction is actually over 200 bytes.
You’ll need two signatures instead of one, and keeping it safe from chain reorganizations is key. The private key doesn’t matter if the coin is already spent, right?
Signature campaigns would definitely not vibe with your idea if they send out less than 100k satoshis weekly. Quick question though:
1. What do you mean by re-used input?
2. Who signs the two messages? Just the sender?
I think you're talking about address reuse, which is just bad news. If BIP-110 supporters want to make it easier for people to reuse addresses, that's a major privacy risk.
How would they handle weird scripts like "OP_CHECKSIG OP_NOT" that accept invalid signatures? Would they even restrict those?