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