1. Due to the limit some parties just store data in non-opreturn outputs. This bloats the utxo set, which harmful because all nodes must have rapid access to the utxo data, it can't be pruned. Data stored as 'addresses' cannot be distinguished from real addresses, so it cannot be blocked. It is not significantly less efficient[1] than using op_return.  It's actively done and at least some of the users will change behavior if this is fixed.

2. Multiple major miners ignore these limits, which makes the limit ineffectual for anyone who sends directly to the miners.  People have tried to convince miners to stop, but they have earned hundreds of millions of dollars in fees mining non-standard transactions.  This has been the state for years.

3. Parties sending directly to miners undermine bitcoin's decentralization because bigger miners make bigger profits (no one will bother establishing a relationship with a 1% miner), it also encourages miners to bypass other non-consensus rules.

4. When nodes widely do not relay transactions that get mined anyways the result is that block propagation is massively slowed. Missing one transaction will make it take three times longer per hop to transfer blocks, if the total missing data is significant it can easily take 10 times longer or more.  When propagation is slow it benefits larger miners and hurts smaller ones, regardless of which side of a delay the miners are on.  This is yet another centralization pressure, since less profitable miners are bankrupted over time. (and unsurprisingly, it's also the largest miners that bypass the relay policy)

5. The limit and option add additional code complexity and make bitcoin less simple, and less maintainable.  Because there is an option testing really ought to consider multiple settings and how they interact with everything else, otherwise there may be interactions (but in practice it's probably just under-tested).  These costs might make sense if the functionality was useful, but it's not-- see 2, 3, 1.  That said I doubt anyone is particularly committed to removing the setting, it's just the cleanest thing to do and it's objectively not useful.

6. Changing the limit to some other value retains all of the above problems, it's a non-solution, except maybe it might be enough for some particular fake-output user to switch over...  but that smacks of appointing people to adjudicate over one application vs another--  and that should be avoided as much as possible, as Bitcoin's fundamental value is a system of money which minimizes third party human influence.  The resultant down sides can be justifiable for something that actually works, but once it doesn't work I don't know how it could be justified.

I spent a lot of time supporting the limited size when it was first introduced and received an inordinate amount of abuse over it.  It was a limit that made sense at a different time in a different world and was successful in educating people about commitments. Since miners bypass this policy as well as others, it's moot now and actually causing some harm (fake outputs in the utxo set, direct to miner relationship, increased block relay time).

Can you suggest any reason that it shouldn't be done?  I'm waiting to hear an answer that isn't just a rant about shitcoins or spam, none of which is particularly relevant argument against removing the limit.


1.  PeopleFake addresses are about 80% efficient asymptotically-- basically from the need to include an output amount every 32 bytes of stored data, which I think is pretty good. But if that wasn't enough opreturn wouldn't be what they'd use, they'd shove stuff in the witnesses. But people embedding data in Bitcoin transactions inherently don't care much about how efficient it is.  If you just want to store data on the internet the cost to store it *forever* in Amazon S3, which is a pretty expensive option, is on the order of a hundred thousand times less expensive than the minimum bitcoin feerates.  All of the price sensitive 'data storage' has already been eliminated.

1. Due to the limit some parties just store data in non-opreturn outputs. This bloats the utxo set, which harmful. The because all nodes must have rapid access to the utxo data, it can't be pruned. Data stored as 'addresses' cannot be distinguished from real addresses, so it cannot be blocked. It is not significantly less efficient[1] for the users than using op_return.  It's actively done and at least some of the users will change behavior if this is fixed.

2. Multiple major miners ignore these limits, which makes the limit ineffectual for anyone who sends directly to the miners.  People have tried to convince miners to stop, but they have earned hundreds of millions of dollars in fees mining non-standard transactions.  This has been the state for years.

3. Parties sending directly to miners undermine bitcoin's decentralization because bigger miners make bigger profits (no one will bother establishing a relationship with a 1% miner), it also encourages miners to bypass other non-consensus rules.

4. When nodes widely do not relay transactions that get mined anyways the result is that block propagation is massively slowed. Missing one transaction will make it take three times longer per hop to transfer blocks, if the total missing data is significant it can easily take 10 times longer or more.  When propagation is slow it benefits larger miners and hurts smaller ones, regardless of which side of a delay the miners are on.  This is yet another centralization pressure, since less profitable miners are bankrupted over time. (and unsurprisingly, it's also the largest miners that bypass the relay policy)

5. The limit and option add additional code complexity and make bitcoin less simple, and less maintainable.  Because there is an option testing really ought to consider multiple settings and how they interact with everything else, otherwise there may be interactions (but in practice it's probably just under-tested).  These costs might make sense if the functionality was useful, but it's not-- see 2, 3, 1.  That said I doubt anyone is particularly committed to removing the setting, it's just the cleanest thing to do and it's objectively not useful.

6. Changing the limit to some other value retains all of the above problems, it's a non-solution, except maybe it might be enough for some particular fake-output user to switch over...  but that smacks of appointing people to adjudicate over one application vs another--  and that should be avoided as much as possible, as Bitcoin's fundamental value is a system of money which minimizes third party human influence.  The resultant down sides can be justifiable for something that actually works, but once it doesn't work I don't know how it could be justified.

I spent a lot of time supporting the limited size when it was first introduced and received an inordinate amount of abuse over it.  It was a limit that made sense at a different time in a different world and was successful in educating people about commitments. Since miners bypass this policy as well as others, it's moot now and actually causing some harm (fake outputs in the utxo set, direct to miner relationship, increased block relay time).

Can you suggest any reason that it shouldn't be done?  I'm waiting to hear an answer that isn't just a rant about shitcoins or spam, none of which is particularly relevant argument against removing the limit.



1.  People embedding data in Bitcoin transactions inherently don't care much about how efficient it is.  If you just want to store data on the internet the cost to store it *forever* in Amazon S3, which is a pretty expensive option, is on the order of a hundred thousand times less expensive than the minimum bitcoin feerates.  All of the price sensitive 'data storage' has already been eliminated.

1. Due to the limit some parties just store data in non-opreturn outputs. This bloats the utxo set, which harmful. The data cannot be distinguished from addresses, so it cannot be blocked. It is nonot significantly less efficient[1] for the users than using op_return.  It's actively done and at least some of the users will change behavior if this is fixed.

2. Multiple major miners ignore these limits, which makes the limit ineffectual for anyone who sends directly to the miners.  People have tried to convince miners to stop, but they have earned hundreds of millions of dollars in fees mining non-standard transactions.

3. Parties sending directly to miners undermine bitcoin's decentralization because bigger miners make bigger profits (no one will bother establishing a relationship with a 1% miner), it also encourages miners to bypass other non-consensus rules.

4. When nodes widely do not relay transactions that get mined anyways the result is that block propagation is massively slowed. Missing one transaction will make it take three times longer per hop to transfer blocks, if the total missing data is significant it can easily take 10 times longer or more.  When propagation is slow it benefits larger miners and hurts smaller ones, regardless of which side of a delay the miners are on.  This is yet another centralization pressure, since less profitable miners are bankrupted over time.

5. The limit and option add additional code complexity and make bitcoin less simple, and less maintainable.  Because there is an option testing really ought to consider multiple settings and how they interact with everything else, otherwise there may be interactions (but in practice it's probably just under-tested).  These costs might make sense if the functionality was useful, but it's not-- see 2, 3, 1.  That said I doubt anyone is particularly committed to removing the setting, it's just the cleanest thing to do and it's objectively not useful.

6. Changing the limit to some other value retains all of the above problems, it's a non-solution, except maybe it might be enough for some particular fake-output user to switch over...  but that smacks of appointing people to adjudicate over one application vs another--  and that should be avoided as much as possible, as Bitcoin's fundamental value is a system of money which minimizes third party human influence.

I spent a lot of time supporting the limited size when it was first introduced and received an inordinate amount of abuse over it.  It was a limit that made sense at a different time in a different world and was successful in educating people about commitments. Since miners bypass this policy as well as others, it's moot now and actually causing some harm.

Can you suggest any reason that it shouldn't be done?



1.  People embedding data in Bitcoin transactions inherently don't care much about how efficient it is.  If you just want to store data on the internet the cost to store it *forever* in Amazon S3, which is a pretty expensive option, is on the order of a hundred thousand times less expensive than the minimum bitcoin feerates.  All of the price sensitive 'data storage' has already been eliminated.

1. Due to the limit some parties just store data in non-opreturn outputs. This bloats the utxo set, which harmful. The data cannot be distinguished from addresses, so it cannot be blocked. It is no less efficient for the users than using op_return.  It's actively done and at least some of the users will change behavior if this is fixed.

2. Multiple major miners ignore these limits, which makes the limit ineffectual for anyone who sends directly to the miners.  People have tried to convince miners to stop, but they have earned hundreds of millions of dollars in fees mining non-standard transactions.

3. Parties sending directly to miners undermine bitcoin's decentralization because bigger miners make bigger profits (no one will bother establishing a relationship with a 1% miner), it also encourages miners to bypass other non-consensus rules.

4. When nodes widely do not relay transactions that get mined anyways the result is that block propagation is massively slowed. Missing one transaction will make it take three times longer per hop to transfer blocks, if the total missing data is significant it can easily take 10 times longer or more.  When propagation is slow it benefits larger miners and hurts smaller ones, regardless of which side of a delay the miners are on.  This is yet another centralization pressure, since less profitable miners are bankrupted over time.

5. The limit and option add additional code complexity and make bitcoin less simple, and less maintainable.  Because there is an option testing really ought to consider multiple settings and how they interact with everything else, otherwise there may be interactions (but in practice it's probably just under-tested).  These costs might make sense if the functionality was useful, but it's not-- see 2, 3, 1.  That said I doubt anyone is particularly committed to removing the setting, it's just the cleanest thing to do and it's objectively not useful.

6. Changing the limit to some other value retains all of the above problems, it's a non-solution, except maybe it might be enough for some particular fake-output user to switch over...  but that smacks of appointing people to adjudicate over one application vs another--  and that should be avoided as much as possible, as Bitcoin's fundamental value is a system of money which minimizes third party human influence.

I spent a lot of time supporting the limited size when it was first introduced and received an inordinate amount of abuse over it.  It was a limit that made sense at a different time in a different world and was successful in educating people about commitments. Since miners bypass this policy as well as others, it's moot now and actually causing some harm.

Can you suggest any reason that it shouldn't be done?