Bitcoin Cash (BCH) stands out compared to Bitcoin (BTC) and Ethereum (ETH) due to its larger block size of 220 bytes , allowing more transactions to be processed directly on-chain without relying on second-layer solutions that can compromise decentralization. With lower fees and better accessibility, BCH is ideal for payments and data storage. I suggest increasing the OP_RETURN limit to 300 bytes and using it as a censorship-resistant social network, where users pay a small fee to post, which is passed on to miners. This possibility guarantees the increase of the user base, as well as guarantees fees to support the network when there are no reward coins due to programmed scarcity . I currently use it this way, but it was necessary to create a custom interface that displays the OP_RETURN in a timeline.
memo.cash exists, you can already make 220-byte posts there
why do you need 300 bytes in particular?
I would support going up to 1kB of data in OP_RETURN. High level thoughts:
Benefits:
- More data can be stored directly on chain. Concepts of this include having basic NFT art stored directly on chain rather than some third- or first-party server
- Wider variety of contracts could be possible
- Simplifying/enabling mechanics of certain applications
General:
- Calling for âdata storageâ on BCH is a bit of a slippery slope idea. BCH is meant to be a âCash System,â not a storage system. In the future, a decentralized storage layer (such as a FileCoin L2 with BCH as itâs native currency) would be very neat, but that sort of storage should be kept off chain.
- Chaining txs is already possible. Someone could theoretically just chain a bunch of txs together with OP_RETURNs to get to the desired total size. So large OP_RETURNs can still exist, but it is more complicated to do. Frankly, also less efficient overall. I could see parallels with BigInt and this. â However, reducing complexity can also encourage behavior that is not aligned with a âCash Systemâ and lead to the Considerations below
- Though pruning discussed in the Mitigants section below, in an âideal case,â what is the difference between someone maintaining a node with OP_RETURNs vs them hosting their own IPFS or other server? Maybe maintaining some sort of âproof of uploadâ on whatever these larger txs would beâŚ
- Miners could also choose to ignore larger OP_RETURNs or require a non-linear fee for them â general network not as effected (though transactions stuck in mempool).
Considerations:
- BCH is not meant to be a data storage chain, so why would we increase the limits? We only serve to bloat the chain and further stress node operators/others with no direct discernable benefit.
- Applications wanting to put data on chain could choose to keep data on their own servers, or another chain, why do they need to do it on the BCH chain?
- Someone could hypothetically introduce some bloat attack filling OP_RETURNs to bloat the BCH blockchain quickly.
- Arguments against an increase in OP_RETURN limits could likely also apply to the existing limit â why not lower the existing limit if higher OP_RETURNs are of issue?
Mitigants:
- OP_RETURN isnât free. Any data put on goes directly towards compensating the miners.
- OP_RETURN data is able to be pruned. Thereby miners/node operators could choose to not store larger OP_RETURNs and not bloat their chain. However, this becomes more complicated for general node operators. One could argue then they might not need to run a node, but alas, this does still add further complexity across the system.
- The bloat risk exists the same today as with normal transactions. This goes for pushing network requirements too. Any argument/data supporting that BCH doesnât get attacked in this manner, can apply any of those arguments to the potential risk of a bloat attack here.
hi,
I placed a small image with meaning and significance, and it is complete, meaning not fragmented.
explorer.electroncash.de/tx/01159eb6020b1cbb10f2b57eb4996c79020e8333a7b0bef24a1174cc43b683b0
explorer.electroncash.de/tx/1feda7c1c330eb240503949c8668ac554c2de23fb99f4a11cceb899d244a28fb
I suggest posting directly in the transaction, instead of using Memo.cash, because access can be blocked, as happened with X (formerly Twitter) recently in Brazil. The trend of blocks is imminent, as seen with the imprisonment of Pavel Durov and the blocking of X in Iran, Venezuela, Cuba, and last month in Brazil. Therefore, by using OP_RETURN, as proposed, censorship becomes unfeasible without banning the use of money. To achieve this, the OP_RETURN limit should be increased to 300 bytes, which would help provide greater coherence and meaning to the message left. Additionally, this approach would enhance resistance to censorship and generate fees for the network, as highlighted by our colleague. Currently, 220 bytes already suffice, but 300 would make the record more substantial without further burdening the network.
the site (a particular frontend) can be blocked but the protocol is open and actually publishes to OP_RETURNs under the hood, so you could just run a node and host a localhost instance: memocash (Memo) ¡ GitHub
sorry minisatoshi for quoting you, its just such a great list.
-
not a benefit, thatâs a downside. Imagine all your tweets being impossible to edit the moment you send it.
-
Hand waving. I doubt people have any actual real examples.
-
Simplifying, maybe. But this is a shared platform and your benefit (simpler) costs everyone else. So stop being lazy and optimize your app or do it properly. Internet space is cheap, bandwidth is cheap. Blockspace is not. So use the first two.
The immutability of it would be the reason that could be a benefit.
Non-editable posts is basically a major downside comparing to ANY social media out there.
So social media on blockchains kind of make less sense than non-blockchain ones.
Why not just place hashes and links to content in op_returns and have that stored elsewhere like IPFS, BitTorrent, Matrix or other networks more suited for social media?
PS.
You can have multiple links and multiple mirrors, so the content never disappears.
I donât entirely disagree. However, social media isnât necessarily the reason for this.
Doesnât solve immutability of content.
Yes, but the host-er of that data can change the content at those links at will.
Oh, but it does.
If you hash specific content in a strict way, the only content that when hashed returns the same value is âvalidâ.
Itâs perfectly immutable.
Depends.
In BitTorrent or IPFS the âhostâ cannot change the content. He can delete it tho. I am not sure about how for example Matrix and similar work tho - if it is possible to post hard-links to hashed immutable content there.
yes, hashing is a powerful thing. A cryptographic hash over content is unique and only applies to that specific content.
You will see all the decentralized âreddit replacementâ systems use such hash-pointers just like Bitcoin does.
Writing a good decentralized chat system isnât easy, but it is also not particularly hard. A lot of knowledge has been gained in the last decades on the topic.
People that want to have a shortcut and avoid doing the work by simply overloading some existing blockchain should be rejected. Maybe via miners we can increase the fees of op-return only transactions.
Because hosting non-financial data on-chain is like a stranger sticking a rope on your rear-bumper with a cart and thus avoiding needing their own car. Itâs fine if its just one or two, but at one point it just destroys the value of owning a car.
Requesting changes to the underlying protocol in order to make such leeching easier is a very strong sign that this point will come earlier rather than later.
Ha!
This is an excellent comparison indeed.
Generally no disagreement here. Miners can also choose to prune OP_RETURNs, so not much of a long-term storage issue.
But I would have no qualms with having miners charge more.
fun fact, the âpruning op returnâ idea is one of those myths that isnât actually based on fact.
No software does that, or can do that. There is frankly no benefit to doing so. Reason is the same as the one explained here: Supporting UTXO Commitments
In short, youâd need to implement chapter 7 to allow pruning. And then those op return utxoâs are nothing special or specific.