Dust Fork BIP suggestion?

[gmaxwell]

There is absolutely no perceivable increase in >80b op_return,

What does "perceivable" mean to you?  OP_returns aren't 'perceivable' at all generally because the bitcoin software intentionally doesn't show them.  There are op_returns over 80 bytes, as there were *before* Bitcoin Core 30 because, as I just reiterated in this thread and which you went on to lie about again:  Miners already removed the limit before a matching removal was proposed in Bitcoin Core.  You claimed that this would bring forth all kinds of negative effects, we can all see now that your hysterics were entirely misplaced ... and they continue to be misplaced.

[PepeLapiu]

There is absolutely no perceivable increase in >80b op_return,

What does "perceivable" mean to you?

Here I am copying the chain scan results of a friend, in an other discussion elsewhere:

I built an OP_RETURN indexer about 4 months ago because I wanted to be able to measure how bad v30 turns out to be in practice. It runs on a Raspberry Pi CM4, stores the data in a postgres db and took about 8 days to index the entire chain.

And here are the results of his scan up to the day when core made the release announcement:

Core v30 has so far been less damaging than I expected. Upto block 918777 (approximately the release announcement) the counts were
    size_bucket       |           count |         %
----------------------------+-------------------+-----------
 1-83 b                    | 166247234 |  99.99
 84-1000 b             |          13552 |     0.01
 1001-10000 b      |                 91 |     0.00
 10001-100000 b |                 22 |     0.00
 >100000 b.           |                   2 |     0.00

And here is the same scan up to block 929720:

Sat 27 Dec 14:00:01 CET 2025: Starting bucket counting

    size_bucket       |           count |          %
----------------------------+-------------------+-----------
 1-83 b.                   | 180249724 |  99.99
 84-1000 b.            |          13731 |     0.01
 1001-10000 b.     |               133 |    0.00
 10001-100000 b |                  55 |    0.00
 >100000 bytes    |                    2 |    0.00

And I should note you can see slightly more >80b op_returns happening after the announcement. But most of those occured during the few weeks after core made the announcement, and before the actual core 30 release. So in fact the release of core 30 shows no perceptible or significant move away from fake pubkeys and into >80b op_return.

I'll ask him to run the scan up to a different block height if you ask nicely, and if you can write two lines without acting like a butthurt little whinny bitch.

OP_returns aren't 'perceivable' at all generally because the bitcoin software intentionally doesn't show them.

Would you like to buy a bridge? Fresh paint on it, a real bargain. Limited time offer.

Miners already removed the limit before a matching removal was proposed in Bitcoin Core.

Stop repeating stuff I already addressed. It doesn't matter if miners did it first or not. Core blow up the op_return filter with core 30, and they claimed this would reduce UTXO bloat. I am on record on this forum, repeatedly saying that existing fake pubkey attackers are not likely to move to op_return. And they clearly have not.

You claimed that this would bring forth all kinds of negative effects

I was wrong. I see the light now. Op_return is the "harm reduction" method I have come to embrace. And I want to push the fake pubkey attackers to use op_return instead. Because core 30 alone certainly is not doing it on it's own.

Your charm and knowledge have convinced me!!!

[d5000]

I don't believe there is a way to differentiate a change address from a spend address or fake pubkey.

"Change output" is simply the last output of the transaction. There is no need to differentiate further. Fake pubkeys can't be spent anyway, as I already wrote elsewhere, so tools can be provided to erase them from nodes if someone really wants to put his data (fake pubkey etc.) into a change output.

For the incentive game, the dust limit increase is much more of a difference already to the status quo, than it would be the difference to except the last ("change") output.

One could even add one further condition:

Transactions as a whole must at least spend the "new dust limit", i.e. the dust limit would also work as a minimum transaction value. This prevents that a lot of transactions with a single, small outputs and fake pubkeys and/or dust outputs for Taproot envelopes (Ordinals and Cia.) are created. Single-output transactions would then have to respect the dust limit too for that single output.

The incentive difference to your original idea would be absolutely negligible in this case.

Maybe an exception could be made if the change address is one of the sending addresses. This way, fake pubkeys would be prevented.

This would encourage address reuse and make the coins vulnerable to quantum attacks and create privacy problems. So it's a clear no from me. The "minimum transaction spending limit" is enough to prevent your scenario of separate transactions encoding data.

And my BIP would not allow for any possible confiscation. If you have sub-5000 SATs UTXO, you will be able to consolidate them at any time with other inputs. You just won't be able to send less than 5000 SATs to any address.

Without the change exception, a confiscation would happen if you want to pay a merchant with an output which is bigger than the amount you pay, but not by much. Let's say: Your UTXO is 14500 sats, and you have to pay the merchant 10000 sats.

If you have a wallet with less than 5000 SATs in it, you would not be able to send it. But you could send an other 5000 SATs to this wallet in other to consolidate the UTXOs to something of more than 5000 SATs.

This is not true but the other way around: you can always consolidate if you create a raw transaction. So that's not the problem. The problem is the merchant scenario. Or imagine you want to be flexible with fees via RBF. Then even a swap or a deposit to an exchange where you have to previously announce the amount, could lead to a confiscation if you have to add more fees.

So if you want this BIP to have any minimal support: just accept the change output exception without the "forced address reuse". The minimum transaction value will do the trick

[PepeLapiu]

"Change output" is simply the last output of the transaction. There is no need to differentiate further.

I don't believe that is correct. Because in some cases, there is no such thing as a change address. For example if you were to send exactly the full amount of the inputs. In this case, looking for the last output would find something that is not a change address. I think it would only be too easy to pass off a fake pubkey as an apparent change address (based on your spotting method) to avoid the dust limit all together.

Fake pubkeys can't be spent anyway

Yes, I know. So raising the dust limit to 5000 SATs would cause the fake pubkey attacker to lose more money. That's the whole point of my proposal.

so tools can be provided to erase them from nodes if someone really wants to put his data (fake pubkey etc.) into a change output.

No, you don't understand. My proposal would ensure that all outputs be 5000+ SATs. Except for the miner fee, which is easy to spot, and for the change address, if it is going back to one of the inputs. Any transactions that does not fit this would be rejected at the consensus level, just as a double spend would be rejected.

In this way, any fake pubkey attacker would be forced to waste away 5000 SATs for each fake pubkey they use as an output.

The exception for the change address being the same as one of the inputs, would ensure the attacker is not trying to pass off his fake pubkey as a change address. Because an already used input is provably not a fake pubkey. Understood?

For the incentive game, the dust limit increase is much more of a difference already to the status quo, than it would be the difference to except the last ("change") output.

Sorry, I don't understand. Please rephrase.

Transactions as a whole must at least spend the "new dust limit", i.e. the dust limit would also work as a minimum transaction value.

That makes no sense. That would be too easy for the fake pubkey attacker to spend 100,000 SATs, create 10 fake pubkeys with 330 SATs each, and return the rest as change and miner fee.

There is no need to limit any inputs, because we know they are spendable, or they wouldn't be inputs. You can't use a fake pubkey as an input, they are unspendable.

Single-output transactions would then have to respect the dust limit too for that single output.

Again, no. All outputs, spare the change address to an input, and the miner fee, would have to be 5000 SATs or more.

This would encourage address reuse and make the coins vulnerable to quantum attacks and create privacy problems. So it's a clear no from me. The "minimum transaction spending limit" is enough to prevent your scenario of separate transactions encoding data.

While what you say is technically true, it is somewhat irrelevant. First, I think the quantum FUD is way overblown. We are many many years away from a quantum attack. And even if it does occur (but it won't), I'm pretty sure your <5000 SATs change UTXOs are the last thing you should worry about.

Furthermore, we are talking about edge cases here. How often have you had sub 10,000 UTXOs, and a change output of less than 5000 SATs? Not many times I bet. And so, the privacy issue of reusing an input for your change address is minimized to rather rarer times.

And a well designed privacy oriented wallet could just as easily add more inputs, as to spend more, to get a change address above 5000 SATs.

With such privacy oriented wallet, the problem of privacy leakage and quantum threat would only occur with wallets of less than 5000 SATs balance.

Without the change exception, a confiscation would happen if you want to pay a merchant with an output which is bigger than the amount you pay, but not by much. Let's say: Your UTXO is 14500 sats, and you have to pay the merchant 10000 sats.

As I view it, without the change exception, and if you don't reuse an input for your change, it still would not be confiscatory. Because the nodes would reject your transaction as invalid, and any block with your transaction would also be rejected by the nodes.

Which is why the change to one input exception is required.

I designed my proposal to ensure nothing could be misconstrued as confiscatory. I don't have any moral qualm about freezing dust outputs of attackers. But I made sure there is no confiscatory scenario to my proposal. Because people like (you know who) are bent on protecting the SATs of attackers.

If you have a wallet with less than 5000 SATs in it, you would not be able to send it. But you could send an other 5000 SATs to this wallet in other to consolidate the UTXOs to something of more than 5000 SATs.

This is not true but the other way around: you can always consolidate if you create a raw transaction. So that's not the problem. The problem is the merchant scenario. Or imagine you want to be flexible with fees via RBF. Then even a swap or a deposit to an exchange where you have to previously announce the amount, could lead to a confiscation if you have to add more fees.

I don't understand. Ellaborate in details like I'm 10 years old.

So if you want this BIP to have any minimal support: just accept the change output exception without the "forced address reuse". The minimum transaction value will do the trick

I believe you are misguided. I believe it's easy to confuse a spend output with a change output. Especially when a transaction can be created without any change output.

Say for example the spammer has a 5500 SATs UTXO, and assuming the miner fee is 400. He sends 5000 SATs to one if his own addresses, and 100 SATs to a fake pubkey, and the 400 SATs to miner fee. The system treats the 100 SATs fake pubkey output as a change address, and let's it through.

Not only did the attacker dodge the 5000 dust limit, he also dodged the current 300 SATs dust limit.

Thanx to you, asshole!! 😂

Look, it's very simple. In the case of a change output of less than 5000 SATs, the less privacy minded wallets will just send the change back to one of the inputs. And a privacy minded wallet would just add more inputs to increase the change above 5000 SATs.

And if you have so many UTXOs that small, you have poor UTXO hygiene, you deserve to have your privacy exposed, tarred, feathered, and walked out of town. 😁

But seriously, my BIP would incentivize proper UTXO hygiene. That's good for the UTXO set, no?

[PepeLapiu]

So if you want this BIP to have any minimal support: just accept the change output exception without the "forced address reuse". The minimum transaction value will do the trick

You have to understand how easy it would be to game the dust limit if we go along with your suggestion. In fact I could build a script to automate the whole gaming process in just half a day, and I'm not even a mediocre script writer. Or I could game the dust limit manually right now with my Electrum wallet.

You say that the change output is always the last output. That's not true. Because sometimes there is no such thing as a change output.

For example, say you have a 1310 SATs UTXO. If you know your miner fee will be 300 SATs, you could easily use the 1310 SATs UTXO as a single input, send 1000 SATs to an address you control, 10 SATs to a fake pubkey, and 300 as miner fee. That leaves no room for any change output. Well, the 1000 SATs output looks like the spend UTXO but it's really a stealth change address. And based on your change output spotting idea, the fake pubkey gets to look like a change output and the attacker saves even more money with my BIP than with the current system. He gets away with paying only 10 SATs for his fake pubkey instead of the current 330 SATs he has to pay right now.

And it gets even easier to game when you consider my Electrum wallet (and Sparrow too I think) allows me to construct a tx with several change addresses, and add more inputs to increase the change output(s) value.

My system is simpler and more bullet proof. Because all outputs have to be 5000 SATs or more, unless it's an output that returns change to one of the inputs.

With this system, the attacker can't get away with paying any less than 5000 sats for their fake pubkeys. And it fact, this would also make any form of spam, including the Segwit exploit attacks, more expensive. The only kind of spam not affected by my BIP is the op_return with 0 dust limit to it.

And your wallet would have two options when the change output is less than 5000 bytes:

- Either return the change to one of the inputs, albeit this is a privacy and quantum risk.

- Or pile on more inputs in order to increase the change to 5000 SATs or more, in order to sent the change to an unused pubkey.

The second option is the one a privacy oriented wallet would choose. And that would further reduce the UTXO set by making you consolidate your small UTXOs.

Makes sense?

BTW, I enjoy this exchange back and forth. It',# helped me fine time my proposal.

Since I started this thread, I realized the 50% dust limit reduction at every halvening is the best way to go, over other adjustment methods.

I also came up with the idea of making an exception for change to an input, as to allow more user flexibility and reducing unsoendable balances.

I also dropped the idea of imposing the dust limit for inputs. That was not a good thing, as an input could never be a fake pubkey. And imposing a dust limit on inputs would prevent users from consolidating UTXOs, which we want them to do.

[ABCbits]

Fake pubkeys can't be spent anyway

Yes, I know. So raising the dust limit to 5000 SATs would cause the fake pubkey attacker to lose more money. That's the whole point of my proposal.

I just remember that CounterParty protocol also use 1-of-3 P2MS, where 1 is valid pubkey and 2 are fake pubkey. That way, they could avoid losing 5000 satoshi for each output and just pay TX fee.

In Aug 2015, JP Janssen, the creator of OLGA, embedded a 20 kb, stamp-sized image in a Counterparty broadcast, with the data split among 172 multisig outputs. Interestingly, these weren't "fake key" multisig outputs. They were consolidated and spent in April 2017.

[PepeLapiu]

Fake pubkeys can't be spent anyway

Yes, I know. So raising the dust limit to 5000 SATs would cause the fake pubkey attacker to lose more money. That's the whole point of my proposal.

I just remember that CounterParty protocol also use 1-of-3 P2MS, where 1 is valid pubkey and 2 are fake pubkey. That way, they could avoid losing 5000 satoshi for each output and just pay TX fee.

In Aug 2015, JP Janssen, the creator of OLGA, embedded a 20 kb, stamp-sized image in a Counterparty broadcast, with the data split among 172 multisig outputs. Interestingly, these weren't "fake key" multisig outputs. They were consolidated and spent in April 2017.

I must admit you are talking gibberish to me right now. I don't even know if you are critisizing my proposal or not. Can you explain in simple terms?
If I understand you correctly, all 172 multidig outputs would all have to be above the dust limit to be valid. Unless they are paying to one of the inputs. No?

Your idea doesn't mention anything about discouraging people who use witness data to store arbitary data. So even your BIP is activated on Bitcoin network, spammer will just continue to use witness data (Ordinals or something else) which remain cheapest option.

I actually looked into it since you posted this comment. Here is what I found.

Here is how my BIP would actually help make Segwit exploit inscriptions more expensive. Take this instance of spam I found on mempool.space:

https://memepool.space/tx/226b8093ec247de2bed70a323f9b88c611073022e3b5d431523cb0eb705dbfe2?mode=details

A total of 26 outputs. 25 of them at 330 SATs and one output at 546 SATs (change address maybe?) for a total of 8796 SATs, not including miner fee of 64,312 SATs.

My BIP would force them to put at least 5000 sats in each of the twenty five 330 SATs outputs. Which raises the cost of the tx to 125,546 SATs, assuming they are using an input as the change address. Or 130,000 SATs if they don't. Add the miner fee to it for a total cost of 189,858 SATs, or 2.6x more expensive than without my proposal.

And here's my math on a tx with a single inscription, this one:

https://memepool.space/tx/bef22af39adbc334209b85f2e5e0439292f8b2f7a088316b4c1e6ebdffc5c4ef?mode=details

Fee was 3076 SATs and a single output was 330 SATs for a total cost of 3406 sats.

My proposal would force them to put 5000 sats in the output instead of 330 SATs for a total cost of 8076 SATs. That is a 2.4x increase in cost of using the Segwit exploit.

I like this. 2.6x or 2.3x more expensive is not enough to make them leave the Segwit exploit with a 4x discount. But it still makes the Segwit exploit attacker pay more none the less.