Dust BIP suggestion?

[PepeLapiu]

Disclaimer: This post needs maximum views. It concerns every bitcoin users. I do not wish to have mods move this thread to an other less visible section. Such action would constitute a form of censorship. Thank you

----------------------------------

I have a BIP idea but I don't have the coding skills to submit it myself. I would like to partner up with an interested C++ coder, or you can steal the idea from me if you please. Some credit would be appreciated.

My BIP would propose that the dust limit be raised to 5000 sats at the consensus level for 5 years.

The core team claims that blowing up op_return filter to 1250x it's original limit of 80 bytes was motivated by the UTXO bloat with the hope that arbitrary data attackers would use op_return instead of more harmful fake pubkeys.

But large arbitrary data attackers would have no incentive to move to op_return and lose the Taproot and Segwit discounts.

Raising the dust limit to 5000 SATs would make fake pubkeys more expensive and incentivize fake pubkey attackers towards the less harmful op_return option.

I would personally set the dust limit at a much higher minimum, but that could be a harder sell to others. I think 5000 SATs is an acceptable middle ground.

This would make sending small amounts of sats on chain a problem. Especially with the LN network. I think proper in wallet warnings could greatly mitigate this problem.

The reason for the 5 year expiry is because in case of a large price swing up or down, this dust limit could become too restrictive or not restrictive enough in the future.

Alternatively, the dust limit of 5000 SATs could get cut in half at every halvening. Or decrease by say 15% every year or so. Or be affixed to a fixed fiat price.

I find the idea of fixing the dust limit to the price of a BigMac an interesting idea, though I don't know how that could be implemented.6

Anyone interested in partnering with me on this? Or steal my BIP idea?

Edit: Let's imagine a theoretical world wide adoption. With current world population and chain capacity, that would leave us with around one tx on chain per person every 40 years or so.
At that point, miner fees would be EXTREMELY EXPENSIVE and moving $5 of SATs would be unthinkable on chain. Every small payment will have to occur on L2.
Desperately hanging on to small on chain payments makes no sense, if bitcoin is to grow, even as a not so world wide adoption scale.

[pooya87]

My BIP would propose that the dust limit be raised to 5000 sats at the consensus level for 5 years.

Stuff like dust limit is not and must never be a consensus rule. They must remain policy/standard rules.
Not to mention you are basically scheduling a hard for after 5 years because you can add a new "restriction" (ie. rejecting output values less than 5000 as invalid) with a soft fork but you can't remove them without a hard fork.
If we are to have a hard fork it should not be for such a weak rule.

Not to mention that it would make it impossible to use bitcoin for anything worth less than ~$5 and that's assuming price doesn't significantly go up in the next 5 years which we all know is not going to happen (price will shoot up). Also that's a type of censorship itself!

~ would use op_return instead of more harmful fake pubkeys.

There is a much simpler way if to prevent usage of fake pubkeys without needing any fork. All you have to do is write a single function with 5-10 LOC that would verify the pubkeys and reject them a non-standard refusing to relay.
Policy rules have worked for a decade, there is no reason to believe they won't any longer!

[PepeLapiu]

Stuff like dust limit is not and must never be a consensus rule. They must remain policy/standard rules.

I disagree. Large mining pools are now effectively ignoring policy and filters. Policy and filters are only working when miners are not as centralized as they are right now, and not as corrupt as they are right now.
Policy is too weak right now to deal with fake pubkeys and spam.

Not to mention you are basically scheduling a hard for after 5 years because you can add a new "restriction" (ie. rejecting output values less than 5000 as invalid) with a soft fork but you can't remove them without a hard fork.

False. The rule would automatically expire after 5 years if we use the 5 year way to go about it.

If we are to have a hard fork it should not be for such a weak rule.

Absoluty no hard fork required.

Not to mention that it would make it impossible to use bitcoin for anything worth less than ~$5 and that's assuming price doesn't significantly go up in the next 5 years which we all know is not going to happen (price will shoot up). Also that's a type of censorship itself!

Which is why I offered alternative ways to adjust the dust limit. It could half on every halvening. So at the next halvening, it would decrease to 2500 SATs dust limit, and so on.

Or it could go down by 10-15% every year.

Or it could be tied to the price of a BigMac, but that would be harder to implement. And it assumes McDonalds will always be around.

There is a much simpler way if to prevent usage of fake pubkeys without needing any fork. All you have to do is write a single function with 5-10 LOC that would verify the pubkeys and reject them a non-standard refusing to relay.

Please ellaborate. Because core seems to think they have to be extremely controversial and blow up a spam filter in order to mitigate fake pubkeys.

Policy rules have worked for a decade, there is no reason to believe they won't any longer!

Policy rules are not working anymore, obviously since the chain is full of spam, the UTXO set is blowing up, and services like SlipStream and OpenRelay are expressly used to bypass policy rules. Not to mention core is actively loosening policy rules in the middle of a 4 year long spam attack.

[gmaxwell]

Why would someone who has no issue paying 1000000 sats as fees which they lose forever mind needing to set aside a few thousand more sats that they can get back whenever?

The only 'cure' is for you to get treatment for your obsession related to imaginary transgressive pornography.  There is no current serious spam issue, fees are at a minimum, all we have is some pathetic mentally ill people who are suffering from some kind of fucked up anxiety disorder and now that they can't justify going around in a hazmat suit for covid anymore need something else to freak out about.   I'm sorry that you're sick but your dysfunction isn't going to allow you to fuck up bitcoin, and even if it did it wouldn't make you feel better because your panic anxiety is coming from inside yourself.  Until then please stop spreading misinformation and trying to infect others with your unreasonable anxiety.

People get a little argumentative over eliminating the penny-- and here you blithely want to eliminate bitcoin denominations worth less than $5 (at current prices) and don't even remark on why you think it's okay to continue to try to gut Bitcoin's functionality?  wtf.

There is a much simpler way if to prevent usage of fake pubkeys without needing any fork. All you have to do is write a single function with 5-10 LOC that would verify the pubkeys and reject them a non-standard refusing to relay.

Come on man.  You should realize that that must not work or it would have been done eons ago.

50% of all 32 byte strings are valid pubkeys, so if you implement that filtering then the people throwing crap in pubkeys will just implement encoding that just uses ones which are 'valid' (either by losing a few bits to a counter to just try several, or by implementing SVW encoding)--  then they're completely indistinguishable.  Or they can just use hash forms of address where 100% are indistinguishable out of the gate.

Worse, at least right now when they do use pubkeys one can perform that analysis and just not put them in the utxoset when they fail (since you can tell they can't be spent)--- but that option is lost once they use an indistinguishable encoding (hashes or making their pubkeys invalid).  Right now that skipping isn't done because it slows down synchronization by a lot (testing is a pubkey is valid or not is a significant percentage of the time it takes to validate a signature) and so it's not a win-- but at least it's an option for the future.

[PepeLapiu]

Why would someone who has no issue paying 1000000 sats as fees which they lose forever mind needing to set aside a few thousand more sats that they can get back whenever?

You fail to understand the basic logic here.

Core is attempting to nuke the op_return limit. They claim they are doing this to reduce the UTXO bloat. But there is no incentive for anyone to move to op_return.
If we make fake pubkeys more expensive by raising the dust limit to 5000 sats at the consensus level, they will be incentivized to use op_return as the cheaper option. This would reduce the UTXO bloat problem.

While I'm sure there are some spammers and fake pubkey users who have no problems throwing SATs around, the vast majority of them prefer to save money when they can. My proposal would push them towards the "harm reduced" op_return method.

Let's imagine a theoretical world wide adoption. With current world population and chain capacity, that would leave us with around one tx on chain per person every 40 years or so.

At that point, miner fees would be EXTREMELY EXPENSIVE and moving $5 of SATs would be unthinkable on chain. Every small payment will have to occur on L2.

Desperately hanging on to small on chain payments makes no sense, if bitcoin is to grow, even as a not so world wide adoption scale.

(Insults, blah, blah, personal attacks, blah, blah, lies, blah, blah...)

Whinny little bitch, STFU . Your insults will not be addressed.

[gmaxwell]

Core is attempting to nuke the op_return limit.

You are relentless on this lie.  *MINERS* removed the limit a long time ago, core had no say in it.  Once miners had removed it core was delusional for a time and failed to update to reflect the existing reality-- much to their shame and as a sign of incompetence in project management--, causing harm to the network in the form of poor block propagation which contributes to mining centralization and utxo bloating fake outputs.  The fake output incentive might be a worthwhile cost -- if the limit was still actually blocking outputs but it wasn't.

But in any case there is no more such limit-- not in practice for a long time due to major miners, and not in core any more.  And none of your agressively hysterical predictions came to pass.  It was, as many told you, a non-issue.  Continuing to harp about your wrong predictions from months ago will not make them true.

Nor will whining because you don't get a say in what bitcoin software I run, and the software I run makes your attempts to censor transactions you don't like moot.

But there is no incentive for anyone to move to op_return.

Over using fake outputs? Sure there is.

[PepeLapiu]

Core is attempting to nuke the op_return limit.

You are relentless on this lie.

Indisputable fact: core removed the filter limit. And they claimed to do this to reduce fake pubkeys and UTXO bloat.

Indisputable fact: nobody is moving away from fake pubkeys and into large op_return. So the core strategy is ineffective without a raise in the dust limit at the consensus level, to nudge arbitrary data users away from fake pubkeys and into op_return.

*MINERS* removed the limit a long time ago, core had no say in it.  Once miners had removed it core was delusional for a time and failed to update to reflect the existing reality

I don't care who started it first. It's not relevent. What is relevent here is that core wanted to reduce fake pubkeys by removing the filter default of 80 bytes. And that goal has failed, and it will keep on failing unless we provide an incentive for arbitrary data users to move to op_return. My proposal would do just that.

But there is no incentive for anyone to move to op_return.

Over using fake outputs? Sure there is.

Do tell. What incentives do fake pubkey users have to move to op_return?

Because, apparently, as you already said, the large op_return over 80 bytes is not being used. So clearly, fake pubkey users are not incintivized to move to op_return, or else they would do it.

My proposal would create more incentives for fake pubkey users to move to op_return.

There is a much simpler way if to prevent usage of fake pubkeys without needing any fork. All you have to do is write a single function with 5-10 LOC that would verify the pubkeys and reject them a non-standard refusing to relay.

Come on man.  You should realize that that must not work or it would have been done eons ago.

While I agree that pooya87's idea would likely not work, your dismissal of it is based on a fallacy. Luke Dashjr's proposed filter would have worked, and it still was not adopted, all because of political reasons.
So the idea that something can't work because it would have been done already, that is just false.

[Alphakilo]

Disclaimer: This post needs maximum views. It concerns every bitcoin users. I do not wish to have mods move this thread to an other less visible section. Such action would constitute a form of censorship. Thank you

----------------------------------

I have a BIP idea but I don't have the coding skills to submit it myself. I would like to partner up with an interested C++ coder, or you can steal the idea from me if you please. Some credit would be appreciated.

My BIP would propose that the dust limit be raised to 5000 sats at the consensus level for 5 years.

The core team claims that blowing up op_return filter to 1250x it's original limit of 80 bytes was motivated by the UTXO bloat with the hope that arbitrary data attackers would use op_return instead of more harmful fake pubkeys.

But large arbitrary data attackers would have no incentive to move to op_return and lose the Taproot and Segwit discounts.

Raising the dust limit to 5000 SATs would make fake pubkeys more expensive and incentivize fake pubkey attackers towards the less harmful op_return option.

I would personally set the dust limit at a much higher minimum, but that could be a harder sell to others. I think 5000 SATs is an acceptable middle ground.

This would make sending small amounts of sats on chain a problem. Especially with the LN network. I think proper in wallet warnings could greatly mitigate this problem.

The reason for the 5 year expiry is because in case of a large price swing up or down, this dust limit could become too restrictive or not restrictive enough in the future.

Alternatively, the dust limit of 5000 SATs could get cut in half at every halvening. Or decrease by say 15% every year or so. Or be affixed to a fixed fiat price.

I find the idea of fixing the dust limit to the price of a BigMac an interesting idea, though I don't know how that could be implemented.6

Anyone interested interested in partnering with me on this? Or steal my BIP idea?

Edit: I also feel that in order to be effective, and to prevent possible work a rounds, this dust limit should apply to both inputs and outputs. Yes, this would make some UTXOs unspenddable until the dust limit is lowered below the UTXO SATs balance. But it would prevent would be attackers of the dust limit.

I think you may find the dust limit policy an issue because most nodes which run Bitcoin core will not agree to effect the transaction simply because it isn't up to standard.

Also, the halving cleanup as it is known aims to cleanup or rather burn dust that hasn't been moved for up to 4 years.

Your idea is no longer a secret and this makes it easier not to work on it or make it a reality.

[PepeLapiu]

I think you may find the dust limit policy an issue because most nodes which run Bitcoin core will not agree to effect the transaction simply because it isn't up to standard.

I'm not suggesting a policy change, I'm suggesting a consensus change to 5000 SATs dust limit. At the consensus level, not at the policy level. And yes, I am aware that would require a soft fork.

Also, the halving cleanup as it is known aims to cleanup or rather burn dust that hasn't been moved for up to 4 years.

You must be referring to the Lynx BIP. The problem with The Cat and The Lynx (I like both) is that they have the stigma of confiscation. And spam defending retards like Maxwell will go hard on trying to defend the right of spammers to keep on spamming and using fake pubkeys and fake scripthash.

The beauty of my proposal is that it satisfies both the core 30 supporters and the anti-spam clan. In that increasing the dust limit to 5000 SATs would please the core 30 supporters as it would help nudge fake pubkey users to use op_return instead, and it would reduce UTXO set bloat. That should please the core 30 supporters.

And it would also result in less spam, which would please the anti-spam camp as well.

It's not going to please Greg Maxwell, but I don't think she can be happy with anything short of turning the entire BTC chain into a free dickpic sharing app.
 

Your idea is no longer a secret and this makes it easier not to work on it or make it a reality.

I don't get what you mean here. I would be happy for someone else to partner with me on this, or steal my idea. I'm not looking to get famous.

[pooya87]

Come on man.  You should realize that that must not work or it would have been done eons ago.

I'm not saying it's a perfect solution. I'm just throwing out an idea (pruning out provably unspendable outputs) that has a better chance of being implemented since there is no need for consensus rules change, compared to the idea that requires it.

I believe we must continue discussing all ideas instead of brutally shutting them down like the way OP is over the past couple of months! Because as we all know there exists a problem in Bitcoin. We all know it and we've all experienced it. We will not be able to fully fix it ever, but the general attitude so far has been "lets ignore it and hope it goes away, and if it didn't we'd live with it". This is dangerous attitude in my opinion because the problem doesn't go away, neither does the unsatisfied users. So when those who can do something are choosing the indifference route, the crazymanlukes of this world will take the stage and lead the unsatisfied users into abyss now 20% of the network runs Knots...

[gmaxwell]

I'm just throwing out an idea (pruning out provably unspendable outputs)

That isn't what you suggested-- you said "reject them a non-standard refusing to relay".   And that will have the effect of making people immediately switch off ones that are provable which will in effect take away the ability to prune them.   Pruning them is something anyone could do today-- you can't even tell that they're doing it.  Last I checked though is slowed down nodes a fair bit because the extra checking time was enough to offset any speedup from a somewhat smaller database.

Because as we all know there exists a problem in Bitcoin. We all know it and we've all experienced it. We will not be able to fully fix it ever, but the general attitude so far has been "lets ignore it and hope it goes away, and if it didn't we'd live with it". This is dangerous attitude in my opinion because the problem doesn't go away,

Wrt spam? It *did* go away-- at least in terms of something that is driving fees and causing issues!  It's now been over a year since there was major spam mediated congestion (june 2024, and really almost two years since most was gone by march 2024).

There may be some waves in the future, sure, but by design it's inherently self limiting.

With respect to parties like Pepe and the delusional coin confiscators at ocean-- they don't seem to be going away and perhaps something should be done.  The remaining problem is people *lying* to users to hype them up about a non-existing (or, at least, long past) crisis in order to exploit their fear for whatever their ends are...  As to what can be done about it, that's less clear.

But one thing: I don't care that some people are getting suckered into running broken or poorly maintained node software.  Some unlucky marks are always going to get tricked into buying BSV or knots coin or whatever.  It's sad, for sure.  But beyond putting out good information there really isn't anything that can be done to prevent ignorant people from hurting themselves.  It's a waste of time to try beyond that, and you'll get no gratitude for saving people from financial ruin.

[PepeLapiu]

So anyways, a fixed dustblimit wouldn't make sence as the price and purchasing power of bitcoin changes. A $5 dust limit today could become a a $50 or $500 dust limit when the price goes up. But I'm going to discuss the adjustment methods I suggested:

- The 5 year expiry: here the dust limit is set at 5000 SATs and the whole thing expires completely 5 years later. This is the simplest and most conservative one but also the most temporary one. It would fix most of the UTXO bloat problem for the next 5 years, than do nothing at all and an other fork is required. Should this possibly break anything, we just wait 5 years for it.

- The BigMac price index: here every 1000 blocks or so, or every halvening, we adjust the dust limit based on the price of a BigMac in SATs. This would be great, if a BigMac costs $100 after an hyperinflation period, and the price of BTC goes way up, the dust limit adjusts more accurately. But it requires that the BicMac always be a menu item, and McDonalds always exists. And I'm not sure how to implement this with an external index.

- Halving the dust at every halving: here the dust limit gets cut in half at the every halvening. So a 5000 SATs dust limit automatically becomes 2500 SATs. It implies the purchasing power of BTC doubles every 4 years. If not, the dust limit could becone too restrictive, or not restrictive enough, based on BTC price. It's clean, and easy to implement. I think I prefer this one to the rest. If we go this way, I would prefer the dust limit to start at 10,000 SATs so it becomes 5,000 SATs in 2 years when we halve again.

I'd be open to other ways of adjusting the dust limit. Any suggestions?

[gmaxwell]

It's a good thing Satoshi designed Bitcoin to avoid any need for central bankers dictating rates --- this way we get to watch PepeLapiu appoint himself the job.  Over and over again authoritarian fucks percieve Bitcoin's general independence from human influence as a power vacuum that they're desperate to fill.

[ABCbits]

I have a BIP idea but I don't have the coding skills to submit it myself. I would like to partner up with an interested C++ coder, or you can steal the idea from me if you please. Some credit would be appreciated.

My BIP would propose that the dust limit be raised to 5000 sats at the consensus level for 5 years.
--snip--

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.

- The BigMac price index: here every 1000 blocks or so, or every halvening, we adjust the dust limit based on the price of a BigMac in SATs. This would be great, if a BigMac costs $100 after an hyperinflation period, and the price of BTC goes way up, the dust limit adjusts more accurately. But it requires that the BicMac always be a menu item, and McDonalds always exists. And I'm not sure how to implement this with an external index.

Your idea is example of oracle problem. Other blockchain "solve" it by trusting one or more address, node or miner who submit external data regularly.

[PepeLapiu]

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.

Cut me some slack, will you? My idea won't solve world poverty or cancer either. I can't solve all problems. But I think my proposal would reduce spam, and reduce UTXO bloat.
You'd have to look for other proposals to fix other problems. Or perhaps my proposal could be added to other proposals.

Your idea is example of oracle problem. Other blockchain "solve" it by trusting one or more address, node or miner who submit external data regularly.

I don't think the BigMac idea is the best. Fun to discuss, but it requires too much trust in a centralized authority, and it also requires that the BigMac and McDonalds still exist in 5, 10, or 100 years.

I think the cutting in half of the dust limit at every halvening works best. It's easier for every wallet to predict than the price of a BigMac, for mitigation purposes.

Should we go with tying the dust limit to the price of something, perhaps the price of gold or silver would be preferable. We know gold and silver will still be around tomorrow and for the next 100 years.

The beauty of my proposal is that it offers something to both camps. The anti-spam camp gets less spam, and the core camp gets less UTXO bloat.

To be fair, I don't trust core. I think they used the UTXO bloat as a mere excuse to blow up the op_return filter. But now they are or record for wanting to move spammers away from fake pubkeys and into op_return. They would look like giant liars if they don't go along with it.

In the same way that (you know who) is looking pretty stupid right now, with all his huffing and puffing.

It's a good thing Satoshi designed Bitcoin to avoid any need for central bankers dictating rates --- this way we get to watch PepeLapiu appoint himself the job.  Over and over again authoritarian fucks percieve Bitcoin's general independence from human influence as a power vacuum that they're desperate to fill.

Please STFU. You are embarrassing yourself.
We both know you can't argue against this on a technical level, so.you resort to perpetual insults and strawman arguments