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 smmore >80b op_returns happening after the announcement with a 14x spike in >80b op_returms. 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 glowing charm and your infinite 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.

[d5000]

I think I'll provide some examples to you to elaborate the point further.

Sorry, I don't understand. Please rephrase.

Status quo is:
- You can in theory send a tx with 100 outputs with 1 satoshi each. This would be non-standard, but you can pay a miner. Cost: 100 sats (+ fees).
- Even if we go by standard transactions: Dust limit seems to be currently 546 sats. Your 100-output fake pubkey transaction would then cost 54600 sats (+ fees), i.e. 0.000546 BTC => about 48 USD.

Now change to your original model:

- 100 outputs with a 5000 sat dust limit, without exception for a change output: 500000 sat (+ fees) => about 440 USD.

With the change output exception:

- 99 outputs with 5000 sat dust limit, with exception for a change output (546 sats) => about 437 USD.

The difference to the original is less than 1%, and you have solved the "confiscation" problem with payments. Is it worth it? Yes.

Now your fear is that the attacker would then send 100 transactions with 546 sats each and connect them to form a NFT or something similar.

In your second example, you're on to something:

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.

You are correct here, the spammer would be able to get a single fake pubkey for a cost of the normal dust limit (e.g. 546 sats, or less if he pays a miner). He would however have a quite high overhead as he not only would need to pay fees for the overhead for 100 transactions, but also always send the 5000+ sats around in a second output. He can of course automate that but it would be expensive anyway.

Basically he would be able to pay around six times less (750-800 sats per output, all fees included - if he pays a miner to lower the "normal" dust limit to less than 546 sats, then he would need to pay much more fees to the miner, MARA slipstream for example charges 2-4 sat/vbyte when the normal fee is 1 sat/vbyte or less) of the "normal" cost, but to the cost of a much more elaborate setup.

If you are still afraid of this, then instead to reuse an address which I continue not to like, it could be another condition which ensures that the "change output" is not a fake pubkey. For example you could require a signature in addition to the pubkey hash, just like it was proposed in the Bitcoindev mailing list. This would make the output bigger, but it could be an option for privacy-oriented people. However this would afaik be a new transaction type and thus need a soft fork. I'll think about other options, it would surprise me if Bitcoin Script is that unflexible to not provide a better option (and current standardness policy, which limits scripts, wouldn't matter here).

You're of course correct that you can always add additional inputs. But in many cases this would be hassle for the payer as I already wrote, e.g. in the case of RBF. Also it would make UTXO hygiene sometimes more difficult. You normally want the least amount of inputs in your transactions, to avoid that chain analysis companies associate them together.

Before I really support such a BIP, I'd also need to analyze what such a measure would mean for contracts, like Lightning, but also things like CoinJoins. That wouldn't be overnight, and it depends on other factors if I'm willing to do that.

I consider such a BIP an emergency measure, and it would only be needed imo if the spam problem really increases to intolerable levels (2023 levels would be already enough for me probably to considerate it "intolerable" and make me more likely to support something like this). As a preventive measure, I'm against it. But it doesn't harm to think about defense lines against a new spam attack.

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

You wrote that if you have a wallet (A) with less than 5000 sat, you would have to first send more sats to that wallet to move these 5000 sats.

All what I meant is that it is not necessary to do that additional transaction, if you have another wallet B with some sats on it (minimum between both: 5000 + fees). You then sign the UTXOs on wallet A, copy the partially signed transaction into wallet B, and use the coins of wallet B to be able to "fill" the output of 5000 sats. It's a technical detail, and in reality irrelevant for the discussion. It would save an unnecessary transaction.

Ah, and regarding the 50% halving reduction, I could agree to that, because it's indeed simpler as the complicated Moores Law + difficulty mechanism and it is relatively unlikely that Bitcoin price more than doubles in 4 years.

[PepeLapiu]

First and foremost, HAPPY NEW YEAR!!!

About paying off miners to get below the dust limit. You have to understand my BIP requires a soft fork, as its a tightening of the consensus rules. The attackers would not be able to collude with miners to get sub dust limit outputs. The tx would be rejected by all nodes at the consensus rules level. And a block containing such tx would be rejected by all nodes. They would not be able to pay off the miners for sub dust limit outputs anymore than they could pay off the miners to do a double spend, or spend coin they don't have. It's a hard consensus change, not a soft policy change.

At this point, in an environment of corporatized and centralized mining polls only too happy to lower fees below 1 sat/vB to allow more inscriptions, and with services expressly built to facilitate more spam (OpenRelay and SlipStream), policy is not strong enough to do anything meaningful. Miners no longer care about soft policy. We need this at the hard consensus level.

Okay, now about the privacy concern. I think you are being concerned about a very little problem that could be easily mitigated.

Say you are doing a tx with a change output of <5,000 sats.

A poorly designed wallet with little or no privacy concerns would dimly make one of the inputs the change address to avoid the 5,000 dust limit. Hell, some wallets are still doing that with all change addresses, regardless of amount of change. A few wallets still re-use addresses all the time. Not that you and I would use those wallets.

A better designed wallet would add more inputs until the change output gets to 5,000+ SATs. And if you don't have enough SATs to do that, the wallet would warn you about the privacy concern. And advise you to pimp out your wife and kids to get more SATs, or accept the privacy risk.

In any way, we are talking about a mere 5,000 SATs or less with compromised privacy. You would have to have a balance of less than 5,500 SATs in your wallet for this to become a concern. I don't think the NSA and CIA are too concerned about your sub 5,000 SATs wallet balance. And in 2 years, after the halvening, it becomes even less of a concern with 2,500 SATs dust limit.

Now, you might like the new idea I'm working on as an improvement to my planned BIP, to eliminate the Segwit exploit.

If you look at the two following Segwit exploit txs, you will see that they both send 330 SATs into the offending addresses, only enough to skirt the current dust limit:

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

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

They both go just above the current dust limit with 330 SATs per offending output. My BIP would force the Segwit exploit attacker to send 5,000 SATs to the offending outputs. Which would respectively make the transactions 2.6x more expensive and 2.3x more expensive.

Not enough to counter the ~75% Segwit discount they both enjoy. But now, enters stage left, my new idea:

If you apply the following formula to both tx above:

(tx size - tx virtual size) / (outputs + inputs)

You get to see how much Segwit data per entry (input or output) they each use. Which is respectively 6.80kB/entry and 9.08kB/entry of Segwit data.

But I looked up countless (100's maybe) monetary transactions, and all of them had less than 110b/entry of Segwit data.

So my BIP would also propose to reject (at consensus level) all txs with more than 500b/entry of Segwit data. This would effectively kill the Segwit exploit, and have no effect on monetary transactions. With plenty of room for monetary tx to dump 4x more data in Segwit if the case ever evolves to need more Segwit data.

What you think?