What would Satoshi say about BIP110?

[PepeLapiu]

So we know that core barely acknowledges spam as a problem as they did nothing about spam ever since the spam attack started 5 years go. Core rejected ordinal filters as "too controversial" and recently blew up a spam filter with core 30.

And the now gone Gloria Zhao refered to spam as "use cases we have today" and she implied Satoshi failed to design bitcoin for those "use cases".
source: https://youtu.be/ctks7f-gpaU

Unfortunately, these are all lies. Satoshi was very clear about the idea of accepting " use cases" other than money, when someone tried to burden bitcoin with more bloat and more shit on chain:

Piling every proof-of-work quorum system in the world into one dataset doesn't scale.

Bitcoin and BitDNS can be used separately.  Users shouldn't have to download all of both to use one or the other.  BitDNS users may not want to download everything the next several unrelated networks decide to pile in either.

The networks need to have separate fates.  BitDNS users might be completely liberal about adding any large data features since relatively few domain registrars are needed, while Bitcoin users might get increasingly tyrannical about limiting the size of the chain so it's easy for lots of users and small devices.

Spam apologists also love to claim that nothing can be done about spam and that the fees are the filter. But here is what Satoshi had to say about that:

That's a cool feature until it gets popular and somebody decides it would be fun to flood the payment network with millions of transactions to transfer the latest Lady Gaga video to all their friends...

That's one of the reasons for transaction fees.  There are other things we can do if necessary.

So I think it's pretty obvious, Satoshi didn't think spam can't be stopped. And he was already aware that things other than the fees could and should be done to protect bitcoin from chain bloat.

I think Satoshi would fully support BIP110 today.

[goldphysicalbitcoin]

Satoshi Nakamoto doesn't care about these proposals at all; everything will ultimately be determined by the market, just like the 2017 block size controversy, which eventually led to the fork coin BCH.

[ertil]

Satoshi failed to design bitcoin for those "use cases"

What do you think?  If I made a Bitcoin payment integration for this, would anyone be interested in running it?  It might be the first fully automated service available to buy with Bitcoins.  The advantage it could offer over the free services is general file upload hosting of large files without making downloading users go to the upload site and jump through hoops.  It would give a normal link directly to the file.

See? Satoshi thought seriously about making a service for file hosting, where you could pay with Bitcoins for that. So, what now? Do you still want to dig deeper into what Satoshi said? Or can you now accept the fact, that he is not a God?

Because Satoshi also included User Interface for playing poker in the first Bitcoin client. And there are more such things, which could destroy the perfect image of the "payment only" system.

Also note, that in the old times, there were no altcoins, and we had just fiat, and Bitcoin. And it is natural, that people tried a lot of ideas, which would be rejected today. So, bringing some old posts from Satoshi, or other early adopters, can actually lead to more use cases, instead of less, and this is not what you want, if you try to focus only on payments.

Or, should I mention times, when people tried to integrate Bitcoin client with HTTP servers, and things like that? Would you also scream, that Bitcoin shouldn't do that, and be surprised again, if old posts from early adopters would be quoted?

[nemesis_incarnate]

Satoshi Nakamoto doesn't care about these proposals at all; everything will ultimately be determined by the market, just like the 2017 block size controversy, which eventually led to the fork coin BCH.

Everybody would pick a side, debate, laugh and cry, and in the end, the consensus would be found 

[Ucy]

Ofcourse, if transaction fees can't discourage uploading of large/unrelated data,  then do whatever is right and necessary to stop that from happening. The whitepaper is clear on the purpose of Bitcoin — a  peer-to-peer electronic cash system .
Almost everything going into the Blockchain should be cash related and possibly light, other unrelated things should be non frequent (or barely happen), good, very helpful to the system/owner, do not prevent or slow down the use of Bitcoin for it purpose. In summary, the Bitcoin system should not be abused or misused.

[NeuroticFish]

filter

If I tell you that I don't like the spam, that's a huge understatement.
I'll add that it saddens me greatly that Core did this move - and they did it in this way.

However, adding censorship - for any good reason now - is the road to perdition, so a big no.
Today you filter spam, next you filter "dirty" coins, soon afterwards you filter this or that country, ... sounds like a bright future, isn't it?

Given this, depicting everything in black and white, in "this side holding the truth" and "the other side liars and c***d p**n lovers" is also just as bad and wrong.
Adding Satoshi name into the equation is just a cheap attempt to manipulate the mobs, hence I will not guess for you.

[d5000]

Satoshi would never have supported a BIP which can lead to confiscation of coins. He was quite clear in his whitepaper that Bitcoin was to be a trustless system. Now if everybody can propose a software update which confiscates your coins with the miners' help, then it is not longer a trustless system, because then you have to trust future developers and miners to not confiscate your coins.

One could argue that he actually "confiscated" the coins in the 2010 bug, but these coins were created against the consensus rules every Bitcoin user normally was aware of (the 21 million limit).

I don't know what he'd done exactly, but I guess if spam was a problem he would have called for a development of a better solution without any confiscation. I am also sure he knew the limitations of policy/standardness, as he himself developed the IsStandard() check in version 0.3.18.

My best guess for an emergency anti-spam system which could make data storage a lot more expensive is still a consensus-enforced high dust limit for all outputs except the last one (and that last one shouldn't be allowed to contain OP_RETURN). It could even be tied to the size of the output in the case of OP_RETURN outputs.

[Cypra]

I think this debate mixes two different questions: spam policy and confiscation risk.

I disagree with the idea that “the market decides everything” as a complete answer. Markets matter, but protocol rules still define what kind of market we get. Saying “just let the market handle it” ignores that default node policy and consensus shape incentives long before users can react.

At the same time, I agree with the concern that any proposal must avoid creating a path to arbitrary confiscation. If users feel coins can be reassigned through social pressure and miner coordination, trust in Bitcoin’s neutrality is damaged.

The better approach is to target spam economics directly without affecting ownership guarantees. In other words, raise the cost of abusive patterns, keep validation simple for normal users, and preserve trustless property rights. That seems closer to Bitcoin’s original design goals than either extreme.

[stwenhao]

One could argue that he actually "confiscated" the coins in the 2010 bug

Nothing was "confiscated". Coinbase transactions had below 100 confirmations, so they were safe to reorg, because no miner could move it yet, or consider it "confirmed". And everything else was just confirmed later.

Also, fixing Value Overflow Incident was a soft-fork, not a hard-fork, as some people think. If you apply the old rules to the new client, it will sync everything, which means, that no backward compatibility was broken.

a consensus-enforced high dust limit for all outputs except the last one

Why except the last one?

[hero_the_bossman]

filter

If I tell you that I don't like the spam, that's a huge understatement.
I'll add that it saddens me greatly that Core did this move - and they did it in this way.

However, adding censorship - for any good reason now - is the road to perdition, so a big no.
Today you filter spam, next you filter "dirty" coins, soon afterwards you filter this or that country, ... sounds like a bright future, isn't it?

Given this, depicting everything in black and white, in "this side holding the truth" and "the other side liars and c***d p**n lovers" is also just as bad and wrong.
Adding Satoshi name into the equation is just a cheap attempt to manipulate the mobs, hence I will not guess for you.

Their "courageous fighters with spam" and ours "peeps that allow chain to become a big server for p****".

I agree with the censor part.. It would become the same system BTC was built around and in counter.

[ABCbits]

FWIW, Jameson Lopp made a long blog post about this BIP on https://blog.lopp.net/a-laymans-guide-to-bip-110/.

My best guess for an emergency anti-spam system which could make data storage a lot more expensive is still a consensus-enforced high dust limit for all outputs except the last one (and that last one shouldn't be allowed to contain OP_RETURN). It could even be tied to the size of the output in the case of OP_RETURN outputs.

Personally i would also add change that make script that contain parts that impossible to be executed as non-standard or invalid.

a consensus-enforced high dust limit for all outputs except the last one

Why except the last one?

I would guess it's for change address/UTXO. But in that case, it should limited to 1 new UTXO rather than last UTXO since it would reduce privacy.

[stwenhao]

Personally i would also add change that make script that contain parts that impossible to be executed as non-standard or invalid.

How do you know, if something is "impossible to be executed"? There are many scripts, where you can never be sure about it. For example: many people thought that 37iy592iNBLTPyF4y2iyxpacHsbvV48ZyZ is unspendable, but it was recently moved, by interpreting OP_1 as a fake public key, and making 0-of-1 multisig.

A good example is this topic: https://bitcointalk.org/index.php?topic=5525584.msg64927364#msg64927364

See, how many coins were moved in the meantime? In some cases, like OP_RETURN, or "OP_FALSE OP_VERIFY", you can be sure about it. But in many cases, you don't know, if something is spendable or not. And what then?

Also, 3Dnnf49MfH6yUntqY6SxPactLGP16mhTUq is an interesting edge case, because 0.04 BTCs out of 0.05 BTCs are spendable, but in a very non-standard way, because some coins existed, before P2SH was activated.

[PepeLapiu]

(...)

You are clearly cherry picking part of his message. If you read the full post, it's clear Satoshi was not suggesting file hosting on the bitcoin chain. But rather a payment method for file hosting sites.

If I tell you that I don't like the spam, that's a huge understatement.
I'll add that it saddens me greatly that Core did this move - and they did it in this way.

However, adding censorship - for any good reason now - is the road to perdition, so a big no.

It's ridiculous to claim that preventing non-monetary data on a monetary network is censorship. It's not.

There are countless shitcoins that are built especially for file sharing and other shitcoin degen stuff. Bitcoin is not a file sharing network. Preventing non-monetary data is required if we want bitcoin to survive.

Preventing you from preaching Judaism in my Muslim temple is not censorship. Your Jew preaching does not belong there. Just as your files and jpegs don't belong on bitcoin.

Filters have been around since the very beginning of bitcoin. It's only shitcoiners who claim that preventing non-monetary data is censorship. Get the fuck outta here with that nonsense.

Today you filter spam, next you filter "dirty" coins, soon afterwards you filter this or that country, ... sounds like a bright future, isn't it?

False equivalency. If you use fake pubkeys, fake scripthash, fake witness, the Segwit exploit, or the Taproot exploit, you are abusing the network and you should be dealt with aggressively.

And can we for a minute stop pretending that 90,000 nodes don't know the difference between Iranian UTXOs and monkey jpegs, please?

[BlackBoss_]

Satoshi would never have supported a BIP which can lead to confiscation of coins. He was quite clear in his whitepaper that Bitcoin was to be a trustless system. Now if everybody can propose a software update which confiscates your coins with the miners' help, then it is not longer a trustless system, because then you have to trust future developers and miners to not confiscate your coins.

It's opposite with reasons why Bitcoin was created by Satoshi Nakamoto and the Bitcoin founder can not support any BIP for coin confiscation.

After failure with MARA mining pool to censor Bitcoin transactions, there are new attempts with BIP110 in order to enforce kind of censorship and even more terrible, coin confiscation on Bitcoin blockchain.
Obsevering Bitcoin mining pools.
https://ir.mara.com/news-events/press-releases/detail/1233/correction-marathon-digital-holdings-to-launch-the-first-north-american-based-bitcoin-mining-pool-fully-compliant-with-u-s-regulations
https://ir.mara.com/news-events/press-releases/detail/1239/marathon-digital-holdings-becomes-the-first-north-american-enterprise-miner-to-produce-fully-aml-and-ofac-compliant-bitcoin
https://mempool.space/block/000000000000000000003f8cb66fe1ecfb38754abc9c4d4a62b71de45fef8777

[DaveF]

So in the 1st block mined Satoshi put "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks" in the block.
I'm sure if he could have been bothered to he would have put in a jpg of it if he thought nocoiners like luke and his buddies would try to force what could be put in.

110 is a dead as BSV, and hopefully will fork off and go away.


-Dave

[d5000]

Why except the last one?

Because otherwise it would make many payments impossible without a de facto confiscation.

Imagine the dust limit is 1000 sats. You have 2 UTXOs with 1000 sats each, and you have a payment for 1100 sats. You would then be forced to "donate" 900 sats as transaction fees if the last output wasn't "liberated" from the dust limit.

As I wrote many times the most problematic spam is fake pubkey spam, and that would be made much more expensive than now with such a measure. OP_RETURN spam can also be tackled with it, even if it's less problematic.

That would allow to set a relatively high consensus-enforced dust limit, and also probably to remove the dust limit for the last output completely.

However I can only emphasize that this should be an emergency measure, and only be implemented if there's a real spam problem. As of February 2026, there is none.

But in that case, it should limited to 1 new UTXO rather than last UTXO since it would reduce privacy.

I think this would be no big difference, but how is it more privacy friendly? I think that if only one of the outputs isn't "dust limited", the ordering doesn't really matter. Or am I wrong?

[PepeLapiu]

So in the 1st block mined Satoshi put "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks" in the block.

What you are refering to here is the coinbase miner inscription. It's basically a tiny 40B space that is most often used for the miner or pool to sign their name and tell us who mined this block.
If the miner leaves it empty, it gets replaced by random data. In other words, it's a very small space, it doesn't add data to the block, and it's reserved for the miner who finds the block.

I'm sure if he could have been bothered to he would have put in a jpg of it if he thought nocoiners like luke and his buddies would try to force what could be put in.

So you call Luke and Mechanic nocoiners? You think I have to support cramming blocks with non-monetary shitcoin junk in order to be a real bitcoiner? Really?

Bitcoin is money, not a jpeg repository.

In fact, I believe if he had though that the genesis block inscription would be used as an excuse to fill blocks with spam, Satoshi would have left it blank.

110 is a dead as BSV, and hopefully will fork off and go away.

The block war was won on the premise that the nodes run the network, not the miners, not the devs. Bitcoin belongs to the nodes. The miners have to respect the rules set out by the nodes.

And today, the coretards are doing everything to try to tell us nodes don't matter. Who sounds more like a BSV/BCH shitcoiner now?

However I can only emphasize that this should be an emergency measure, and only be implemented if there's a real spam problem. As of February 2026, there is none.

There really is an emergency. Just like when BSV lifted the op_return limit, their chain got filled with illicit material and child p**n. The very sane thing is likely to happen with Bitcoin, and caused entirely by wreckless core 30. Here are some of the possible actors likely to do this:

- A government agency or central bank bent on destroying or slowing down bitcoin adoption.

- A bad actor with a large put position who wants to see the price tank after the chain gets filled with child p**n and other disgusting material.

- A degenerate who just doesn't want the legal risk of keeping the disgusting files on his own machine and decides to dump the legal risk on the 90,000 nodes.

- Any of the zillion useless shitcoiner bent on attacking bitcoin to promote his own shitcoin

- It could even be someone on my camp, wanting to pollute the chain as a warning sign and a way to build support for BIP110.

The fact is, polluting the chain keeps getting easier and easier with time as core gets busy gas lighting us into doing nothing about spam and garbage.

Because otherwise it would make many payments impossible without a de facto confiscation.

Imagine the dust limit is 1000 sats. You have 2 UTXOs with 1000 sats each, and you have a payment for 1100 sats. You would then be forced to "donate" 900 sats as transaction fees if the last output wasn't "liberated" from the dust limit.

There are ways to prevent this. One way would be for the wallet to post a warning message saying the transaction could result in the lost of 900 sats.

And other way would be to make a dust limit exception for one of the inputs to be re-used as a sub-dust output. Though is is not best for privacy. But many wallets and users don't care all that much about privacy. And let's be honest here, breaking the privacy for 900 sats is not a big deal.

And other solution would be for the wallet to tack on more inputs to increase the change address to above the dust limit. But this would require that more input UTXOs are available.

An other option would be to make an exception with an output with a signed message. This would ensure the below dust UTXO is indeed not a fake pubkey.

But I can see my BIP idea made you think?

How do you feel about my other part of the BIP where I would limit the amount of Segwit data to 200B per input?

[stwenhao]

Imagine the dust limit is 1000 sats. You have 2 UTXOs with 1000 sats each, and you have a payment for 1100 sats. You would then be forced to "donate" 900 sats as transaction fees if the last output wasn't "liberated" from the dust limit.

1. Dust limit is relay-only rule, not consensus rule.
2. It works today in that way. The current dust limit is applied to each and every UTXO, and I don't know, why it should stop being implemented in that way. Are people complaining, that if they have two UTXOs with 10 satoshis each, then they cannot make a new UTXO of 9 satoshis?
3. If your payment to fees ratio is 11:9, then you should use proper sighashes, to accumulate your change into your other address, or switch to a second layer.

[PepeLapiu]

1. Dust limit is relay-only rule, not consensus rule.
2. It works today in that way. The current dust limit is applied to each and every UTXO, and I don't know, why it should stop being implemented in that way. Are people complaining, that if they have two UTXOs with 10 satoshis each, then they cannot make a new UTXO of 9 satoshis?
3. If your payment to fees ratio is 11:9, then you should use proper sighashes, to accumulate your change into your other address, or switch to a second layer.

What d5000 is talking about appears to be similar to my BIP idea.
I propose to raise the dust limit to 5000 sats at the consensus level. And at each halvening, that dust limit would also halve to 2500 sats, 1250, 625, and so on...

So you would not be able to make a payment on chain for less than 5000 sats unless that address was one of the inputs. This would make unspendable fake pubkeys drastically more expensive. And it would force spammers to consolidate UTXOs to keep spamming bitcoin.

And even if they find a way around it, the spammers would be forced to tie up a lot more capital into their shitcoinery.

The reason why it should be done at the consensus level is to prevent miner/spammer collusion with spanware such as LibreRelay and SlipStream. As we see clear evidence that big pools are making considerable strides in bypassing filters.

My proposal would also limit the Segwit data to 200B per input. So if your tx contains 5 inputs, you would only be able to put 1000B into the Segwit discount. More than that, and your tx gets rejected at the consensus level, not at the filter level.

This would make it considerably more expensive for attackers to shove their file in the Segwit discount. And it would make it more appealing for them to use the op_return option, which is less damaging to the network, according to coretards anyways.

The drawback of this for real bitcoin monetary users is that it would make it impossible to send less than 5,000 sats on chain (LN would be their option here) and it would make wallets with less than 5000 sats unspeadable until the user adds more coin, or waits until the next halvening. All this would be mitigated by proper wallet design.

With my proposal, a spammer who wants to shove a 5kB picture in Segwit would have to either create 50 5,000 sats UTXOs, or consolidate previous 50 UTXOs in order to get 5kB of Segwit discount. At this point, the op_return option is the cheaper option.

But I'm putting my BIP idea on the back burner right now. I don't want to take any market attention away from BIP110 as I support it and I don't want to compete with it.

However I can only emphasize that this should be an emergency measure, and only be implemented if there's a real spam problem. As of February 2026, there is none.

I think you are incredibly naive to think there is no spam problem. It's been a problem for the last 5 years. I see no reason to believe that even if it has slowed down, it's not likely to come back.

And I think the mere aggresivity against spam for the last few months night be enough to deter a lot of them and make spam investors more to more hospitable shitcoins.

That would allow to set a relatively high consensus-enforced dust limit, and also probably to remove the dust limit for the last output completely.

I think allowing a dust limit exception for the last output is a bad idea. Spammers could easily find a way to make their fake pubkey the last output in the TX. And I remind you that it's possible, even relatively easy to create a TX without a change address.

I also considered making an exception to the dust limit for a signed address. While that would prevent the spammers from creating cheap fake pubkeys, I think it would allow too much leaway for Segwit spammers.

I think making an expection for one of the inputs is best. I agree that it would be a bad thing for privacy. But the user could stack up inputs to make the change go above 5,000 sats. And it would only be a privacy problem for a very small amount of <5,000 sats. The CIA/NSA are probably not too worried about 5,000 sats UTXOs.

[NeuroticFish]

It's ridiculous to claim

Imho your claims are short sighted and they are the actually ridiculous ones.

But this is the whole direction of this BIP110 "debate" (well, since everybody is ignoring the other side's arguments and consider them "ridiculous claims", it's actually far from a debate) : split the community around a topic that looks great if you don't look into it carefully, advertise it to the max and let them fight over it. Some sort of sick "divide and conquer".