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 oy 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.

[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 fak e 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.