What would Satoshi say about BIP110?

[d5000]

@PepeLapiu:

I will not accept any proposal which doesn't have an exception for at least one change output. Fearing a single fake pubkey output of a transaction is simply paranoia. And putting more restrictions on that output, like adding some kind of signature, doesn't make sense because we'd then create additional blockchain bloat. We've already discussed that and there is no way I'll change my mind. I'm already WAY too understanding with the poor Knots camp.

I only would support any additional restriction for the change output if and only if:

- that "BIP" is first implemented with the unrestricted change exception for 1 output
- and then REALLY there is a spam wave using that for spam, with over ~20% of blocks filled with data.

Then the additional restriction can be implemented in a second step. But probability for that is close to 0%.

By the way that wasn't your idea but @franky1's idea (yeah, somewhen he has some interesting thoughts). I brought it up in one of our discussions and now you are trying to sell it as yours.

[PepeLapiu]

Imho your claims are short sighted and they are the actually ridiculous ones.

You did not quote or address any of my so-called claims.

For the last 5 years the nodes have been asking for filters and core was too busy making room for the spam corporations they were financed by.

After 5 years of this shit, spammers and shitcoiners have started to make bitcoin their home. And now you actually think bitcoin is a genuine file sharing network. It's not, it never was, and we are going to make sure it won't be in the future. Don't let the door hit you in the ass on your way out, shitcoiner.

I will not accept any proposal which doesn't have an exception for at least one change output.

There would be an exception for the change output by re-using one of the inputs.

I know, I know, you think it's a privacy leak. It's less than 5,000 sats, stop making a big deal out of it.

Think about it, the vast majority of wallets and users don't care all that much about privacy for <5,000 sats UTXOs when that's all they have left. Those wallets and users will have no problems re-using an input as a change address whenever required. Hell, many wallets still re-use addresses.

The more privacy minded wallets like Samurai, Wasabi, and Sparrow could easily show a warning and offer the user to tack on an other input if available, or re-use an input for change, or give up the change as miner fee (in cases where the change is only a few sats), or even offer to cancel the send.

You are making it a bigger deal than it really is. To me, the biggest inconvenience to users is having a temporarity unspendable sub-dust balance.

I personally care about my privacy. So I would expect my Sparrow wallet to get around the 5000 dust limit by adding more inputs to increase the change address to above 5000 sats. And in the rare case when I have 9000 sats in my wallet, and I end up with a 4000 sats change address, I don't think I would mind at all re-using an input for change. I'm not scared of the NSA breaking down my door and charging me with money laundering over a 4000 sats re-used change UTXO.

Fearing a single fake pubkey output of a transaction is simply paranoia.

I actually don't think fake pubkeys are that much of a problem. To me, the problem is core that conveniently uses the fake pubkeys as a perpetual excuse to make more room for spam. And they keep claiming fake pubkeys can't be mitigated or prevented, that is a lie. My BIP would shut them up and take away one of their excuses for pushing more spam.

And putting more restrictions on that output, like adding some kind of signature, doesn't make sense because we'd then create additional blockchain bloat.

Not really, that signed message could easily be made to expire after a week or so. And it would only be used very seldomly when all you have left in your wallet after a spend, is less than 5,000 sats.

The vast majority of users don't care all that much about privacy. And those who do can easily absorb the minor inconvenience of not being able to spend, or lose the last >5,000 sats balance.

We've already discussed that and there is no way I'll change my mind. I'm already WAY too understanding with the poor Knots camp.

You are wrong to frame it as a "Knots camp" thing. This could be easily sold as a core 30 companion. They keep claiming that op_return is less damaging, and that is their excuse for blowing up the spam filter. Yet everyone understands no existing spammer is going to move to much more expensive op_return. All because "mue fake pubkeys"

I only would support any additional restriction for the change output if and only if:

- that "BIP" is first implemented with the unrestricted change exception for 1 output

I'll think about it. It might be an acceptae compromise.

- and then REALLY there is a spam wave using that for spam, with over ~20% of blocks filled with data.

Stop it. The moment we start talking about fighting spam, it seems to have the effect of reducing spam, albeit likely temporarily. Don't be so short sighted and just wait until it starts getting worst again. And I Aldo thing 20% of spam per block is way too much and unacceptable.

I guaranty it, if you could somehow gun down and silence every monetary maximalist bitcoiner, the spammers would come back in force. Do I need to remind you that less than a couple of months ago, over 50% of blocks were spam?

I brought it up in one of our discussions and now you are trying to sell it as yours.

I came up with the two ideas on my own. But I'm an anon, and I don't care about getting famous or getting credit. I would gladly have someone else read my ideas and implement them himself in his own BIP. I'm not an attention whore.

If I have to take it up on my own, it will be only after BIP110 is over and done. I don't want to compete with BIP110 as I support it.

I think BIP110 will susceed. All it takes is an intolerant minority to be agresive about it. BIP110 nodes have nothing to lose. They are going to take it to the bitter end. They (we) know that this attack needs to he curtailed if bitcoin is to survive in the long run.

I expect the spam to gradually dies down until August when BIP110 is activated. There is still a non-zero chance that BIP110 fails. If so, unless we keep fighting, the spam will gradually come back.

Not gonna happen on my watch.

[ABCbits]

Personally i would also add change that make script that contain parts that impossible to be executed as non-standard or invalid.

How do you know, if something is "impossible to be executed"?

In some cases, like OP_RETURN, or "OP_FALSE OP_VERIFY", you can be sure about it.

I totally forget Bitcoin scripting can be really weird or unusual. Only using known cases (such as one you mentioned) could work, but it would lead to "cat and mouse".

But in that case, it should limited to 1 new UTXO rather than last UTXO since it would reduce privacy.

I think this would be no big difference, but how is it more privacy friendly? I think that if only one of the outputs isn't "dust limited", the ordering doesn't really matter. Or am I wrong?

I was assuming more wallet developer would simply use last output as change, no matter it above or below limit. If that happens, blockchain analyzer can have higher certainty with their analysis.

[PepeLapiu]

But in that case, it should limited to 1 new UTXO rather than last UTXO since it would reduce privacy.

I think this would be no big difference, but how is it more privacy friendly? I think that if only one of the outputs isn't "dust limited", the ordering doesn't really matter. Or am I wrong?

What I propose is that the only output that would be allowed exception to the dust limit would be if you re-use an input as change address.

Wallets and users that don't care about the privacy for a <5000 UTXO would do this automatically whenever the change output is below the dust limit

Wallets that do care about privacy would have several options:

- Warning window telling the sender one of his input will be re-used and this could cause a minor privacy leak.

- Warning window telling the sender his change will be forfeited to the miner. In this case the miner fee could be set to 0sat/vB plus the <5000 sats change.

- Warning window (or automatically done) to add an other input as to increase the change output to >5000 sats.

- Warning window with a combination of any of the above.

In any case, I think you are wrong to frame it as confiscation without addressing the fact that this is already happening. If have 2000 sats and I attempt to send you 1600 sats plus 100 sats miner fee, my Electrum Android wallet donates(or confiscates?) the remaining 300 sats to the miner.

This would still happen with my suggested BIP. But due to the larger amount a good wallet would give you options and warnings.

The two bigger inconveniences of my proposal is that a balance of <5,000 sats would become temporarily unspendable. And you would not be able to send anyone less than 5000 sats.

The change output limit is really a much smaller inconvenience in my views. If the wallet is designed properly.

An other more complicated option if you really want to send me 4000 sats, would be to do a multisig. We both commit 1000 sats to the multisig. You get 6000 sats change output (minus fee). And I get the 1400 sats spend.

@PepeLapiu:

I will not accept any proposal which doesn't have an exception for at least one change output. Fearing a single fake pubkey output of a transaction is simply paranoia.

I don't really fear fake pubkeys. In fact if fake pubkeys were the only spam option, it's likely the spammers would be far fewer as fake pubkeys are more expensive than the Segwit and Taproot exploits.

What I fear is core using the fake pubkeys FUD as an excuse to give up more space to the spammers.  

Core claims that fake pubkeys can't be stopped. They are wrong, they are lying. My proposal would greatly reduce unspendable fake pubkeys (but not spendable fake pubkeys). And other ideas could completely prevent fake pubkeys.

For example, it could be required that every output be either a re-used input, or with a signed message. The signed message could be made to expire after a week or so to prevent chain bloat. Or the message could be made to automatically expire once the tx is confirmed. But this would require a major overhaul of all wallets. I don't think we need to go that far as fake pubkeys is not a big problem in my book. It's the core fake pubkeys FUD I dislike the most.