UPDATE: So, my BIP was meant to cut down on spam and maybe push some spammers to use op_return instead. But I realized that a consensus-driven dust limit might mess up a few things, like Bisq DEX and possibly some coin mixers too. So for now, I’ll just put this idea on hold.
Just a heads up: I want this post to get a lot of attention because it matters for all bitcoin users. I really don’t want mods to move it to a less visible spot since that would feel like censorship. Appreciate it.
I’ve got this BIP idea in my head, but I’m not a coder, so I can’t submit it on my own. I’m looking to team up with someone who knows C++ or, hey, feel free to take the idea if you want. A little credit would be cool though.
The idea is to raise the dust limit to 5000 sats at the consensus level for 5 years. The core team says they increased the op_return filter from 80 bytes to 1250 bytes to tackle UTXO bloat, hoping bad actors would use op_return instead of creating fake pubkeys.
But honestly, big attackers probably won’t bother switching to op_return if it means losing out on Taproot and Segwit benefits.
By bumping the dust limit to 5000 SATs, we can make fake pubkeys costlier and push those attackers towards the less harmful op_return option.
I’d personally set the dust limit way higher, but I get that might be a tough sell. I think 5000 SATs is a decent compromise.
This could make sending tiny amounts of sats on-chain tricky, especially with...
Proposal for Increasing Dust Limit in Bitcoin
19 replies 179 views
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!
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!
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.
False. The rule would automatically expire after 5 years if we use the 5 year way to go about it.
Absoluty no hard fork required.
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.
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 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.
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.
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.
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.
Whinny little bitch, STFU . Your insults will not be addressed.
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.
Over using fake outputs? Sure there is.
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.
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.
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.
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.
shard_minerSenior Member
Posts: 359 · Reputation: 1322
#8Sep 13, 2022, 04:23 PM
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.
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.
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.
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.
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...
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.
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.
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?
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.
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.
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.
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.
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.
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
I'm not 100% sure about this strategy but it seems a better attempt than "BIP-110". My suggestions are:
- Tie the minimum output value to hashrate, i.e. to difficulty. Hashrate is correlated to price (in real purchasing power), but hardware improvements increase the difficulty further, so a "technical progress factor" would be needed to prevent the value rising much faster than the value in USD. The exact formula for this "technical progress factor" could be defined due to the past relation between difficulty increase and price increase. It is also not necessary that the price is exactly the same in USD, the general order of magnitude being approximately constant is enough.
- One single change output should be allowed to be below this new output value limit, so no coins are confiscated by this new rule.
The second point should be a requirement for this "BIP attempt" to be even considered. Objections to this, like the possibility for "spammers" to use several transactions with one single output to circunvent the limit, aren't really a thing. This suggests an extreme spam demand we simply don't see and won't ever see. It would be easier to simply use several OP_RETURN transactions with 83 bytes. Or to use the witness technique.
I pointed out above why this would do nothing the spammers that plague your delusions but all of you are too smoothed brained to notice, you are just to fixated on trying to break bitcoin. At the very worst a spammer can just treat the inflated output value as a increased transaction fee, -- it's better than that though because the cost is recoverable. And the whole reason the spammers ever caught anyone's attention is that they have been willing and eager to pay fees a hundred times larger than that. Higher costs are what makes the NFTs scarce when they'd otherwise be endless in supply.
If the US government announced that they were concerned about people defacing US currency (an "issue"with similar impact and import to Bitcoin 'spam') and so they were eliminating all coins, bills, and electronic USD payments less than $5 people here would be celebrating USD's self-destruction. But pepe proposed limiting bitcoin denominations around a similar value and you celebrate.
You'd just as soon destroy bitcoin completely so long as it 'owns the spammers'. You are deranged, too fixated on harming your perceived enemy that you'll harm yourself and innocent people around you. Meanwhile your 'enemies' just laugh because the whole reason the NFTers use Bitcoin at all is because limits on the NFT supply are critical to increasing their value.
Let it be known that I do like BIP-110, The Cat, The Lynx, and even the EDD. I like them all. My proposal does not compete with any of them, it complements them.
I like it on a technical level, and I might look into it. However, at this point I still prefer the 50% haircut at every halvening. Because it's predictable, and every wallet could build the dust limit into.the wallet without waiting to find out what the new dust limit will be. Everyone will know.
My hope is that the price of BTC and popularity grows, miner fees will go up, and the dust limit will no longer be needed to deter fake pubkeys.
I don't believe there is a way to differentiate a change address from a spend address or fake pubkey. Therefore, your suggestion might not be possible.
Maybe an exception could be made if the change address is one of the sending addresses. This way, fake pubkeys would be prevented.
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.
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.
I don't think so. First of all, (you know who) is being completely retarded by suggesting that confiscatory BIPs should be banned. And he's likely going to try to claim my BIP too is confiscatory, but at this point he's lost all credibility.
Imagine you have a single 6000 SATs UTXO. And the miner fee is 1500 SATs. You would not be able to spend it because at least one output UTXO will be below 5000 SATs. Nodes will reject your tx, and any block that contains your tx.
Imagine you have 100,000 SATs and you want to send me 4,999 SATs. Your tx will be rejected by nodes in the same way as if you were trying to do a double spend.
Imagine you have 10,000 SATs and you want to send me 6,000 SATs when the miner fee is 1,000 SATs. That would create a change address of 3,000 SATs (below the 5000 SATs limit) and your tx would be rejected. Unless your change address is the same as one of your sending addresses.
If you are really desperate to send me less than 5,000 SATs, I'll see you on L2. Or we can wait until the next halving when the dust limit will be at 2500 SATs.
Imagine you have 3 UTXOs of 3,000 SATs each. You want to send me 5000 SATs. Your could combine the 3 UTXO and get a change address of 4000 SATs (minus miner fee). But only as long as your change address is the same as one of the inputs. Otherwise your tx will be rejected as invalid with a change address of less than 5000 SATs.
Your objection is not valid. A hike of the dust limit will make fake pubkeys more expensive. And op_return becomes a cheaper option for would be fake pubkey attackers.
It appears you are a slow reader, so I will type this slowly in order for you to better understand.
The very few spammers who are bent on payimg more and wasting more money on more expensive fake pubkeys will stay on fake pubkeys. But the vast majotity of them who want to save money will move to less expensive op_return. It's a win for core 30 with it's claim of wanting to reduce fake pubkeys and UTXO bloat. And it's a win for the anti-spam ones as this will result in "harm reduced" spam.
It's only a lost for you, because you'll have to explain it to your handlers.
Are you saying those who have been saying all along that the fees are the filter, they were lying all along? Are you calling core liars for the last 4 years?
Shocking revelation!!!
False equivalency and false assumption. You will still be able to send and receive smaller payments on L2.
The fiat equivalent would be that the bank is banning cheques and bank wires of less than $5 but still allow you to send under $5 with any other payment method (bank card, cash, credit card, ect...)
Are you just acting stupid? Or do you think everyone else is stupid?
Op_return is already cheaper to use and it is used! What evidence do you have that anything need to be improved with respect to that other than your own personal anxiety disorder and freakish sexual perversions? (don't think people don't notice you slipping out that I'm a woman in your sicko fantasies-- "not going to please Greg Maxwell, but I don't think she can be happy"-- or how interested you are in child porn).
It's certainly not due to spam floods driving up fees, since the last of those was well over a year ago. No-- the only emergency here is the one that exists in your delusional mind.
You seem bent on convincing people to trash bitcoin through whatever means you can find traction. Your past proposals have included: Fuck up block propagation? Bloat up the utxo set? Convince people to run some unreviewed fork of Bitcoin maintained by a nutjob? Gut bitcoin's smart contracting capability? Confiscate people's bitcoin one way? Confiscate coins another way? Hysterical conspiracy theories about new bitcoin core releases (which surprise surprise turned out to have no negative effects)? Now you try: Limit the blockchain to not allow payments under $5 (at current prices, god knows how much at future prices)?
There is literally no way of sabotaging bitcoin that would be too far for your goals-- so long as it involves imposing your will on others. Thread after thread after thread after thread, subforum after subform, flooding out the forum from multiple accounts, reply-guying every comment on the subject, relentlessly for months. It's hard to not get an impression that your goal *is* to sabotage Bitcoin.
Pepe's not done until Bitcoin won't run.
They're not stupid, which is why bitcoiners in general are not falling for the astroturf campaign.
That is false. Op_return is obviously not cheap enough compared to fake pubkeys because nobody is using op_return above 80 bytes.
There was a small spite of larger than 80 bytes op_return after core made the announcement. But there is no perceivable increase in >80b op_return since core 30 was released. And UTXO bloat continues to increase.
There is no evidence that anyone is moving from fake pubkeys to >80b op_return. My BIP would fit nicely with the stated goal of core 30 to want to reduce fake pubkeys and UTXO bloat.
False again. I didn't call you a woman, I called you a whinny little bitch. I like women, a lot. Whinny little bitches like you, not so much.
Where in this thread have I talked about any sort of emergency? And since when did fake pubkeys and UTXO bloat stop being a problem acknowledged on all sides?
Lies, lies, lies, stop lying. A dust limit at the consensus level would not slow down block propagation. It would invalidate blocks that contain dust outputs.
Gasligting, anyone?
My proposal would reduce UTXO bloat increase by making it even more cheap to move from fake pubkeys to op_return. Which, I though was the stated goal of core 30, no?
More lies. This is getting tiresome. A consensus change would have to be included in all clients, core, openrelay, knots, and all others would have to make the switch.
My BIP would not do any of those. Why don't you also claim my BIP would force everyone to beat their wives and strangle cute puppies while you are at it?
Yes, this was already addressed in the OP. You still will be able to use L2s for smaller payments.
No negative effects? I think you mean it has no effects at all, positive, or negative, so far. There is absolutely no perceivable increase in >80b op_return, which indicates core 30 fails at it's claimed goal. My proposal would help core 30 achieve it's goal.
Don't be so hard on yourself. I'm sure some people are dumb enough to not see past your gas lighting and perpetual bitching. Biden probably believes you, I hear he's off his meds....
?Reply
Sign in to reply to this topic
Related topics
- Erlay seems to have some issues here’s a better proposal for a bitcoin protocol without invites 3
- Bitcoin Core displaying coins (UTXOs) in a new tab 13
- Are you in favor of BIP-110? Let's get a Bitcoin poll going. 0
- Ways to earn some sats by contributing to bitcoin core development 5
- Exploring the Potential and Challenges of a Kardashev-Scale Bitcoin Network 3
- What can I do to fix this Bitcoin Core error? 8