Allowing people to efficiently and affordably sync and run nodes is a key feature of Bitcoin. It is imperative that people should be able to verify their own transactions and not have to rely on third parties to do so on their behalf. Don’t trust. Verify.
As an early Ethereum user I can personally vouch for the near impossibility for average Joes to run an Ethereum node which demands huge amounts of computing resources and disk space. Those experiences are now years old and I shudder to think how much worse the situation has gotten since.
Most likely over 99.9999% of Ethereum users rely on third parties for transaction validation which calls into question the decentralisation of the network.
In terms of running nodes I posit that Grin is among the best cryptocurrencies going which improves upon Bitcoin by pruning the blockchain to a more manageable size. Bitcoin’s ledger is now too large to be handled by any mobile device and requires a painful amount of time to replay millions of transactions and sync.
As time goes on I hope that Grin leverages its unique advantages to provide the most decentralized and trustless peer-to-peer electronic cash system in which users can easily sync up to verify transactions themselves, and even on mobile devices.
To wit, I present you Bitcoin Mechanic’s speech given in a debate with Peter Todd and others on whether or not Bitcoin Core should uncap the limit on OP_RETURN.
I really enjoyed that talk, I’ve always thought Bitcoin mechanic is a decent guy and find myself aligning with a lot of what he says. They absolutely should filter or at least cut back the size of the OP_RETURN field, it’s been abused to hell and back and going 18M-200M UTXOs because of bad actors.
It also made me appreciate Grin nodes more, being able to run one on a phone or even thin client bought on ebay for $25 is pretty amazing.
Very nice discussion, both sided are right in their own respect. My own opinion on the use of OP_RETURN and on this discussion is this:
I fully understand the wish to disincentivize the spamming of the Bitcoin UTXO set. I am so happy Grin makes it technically very hard to use the chain for data storage.
Bitcoin Core does not dictate but should within reason help facilitate users from “messaging” what they want and as such not propagating transaction they do not want to propagate. This is not centralization since you only facilitate decentralized messaging.
In the end core will turn out right, the intensives align with miners who do allow OP_RETURN so they will always win. Economics is more powerful then ideals unfortunately. Only if there would be a technical magical solution (like with grin) it would work to keep the chain from being used to store data.
It is not always about being right or wrong, both are right in their own respect. Even when you know the battle will be lost, it does not mean you should not allowed others or even facilitated them from trying. Moral economics are commendable, even if liberal economics often turn out winning.
For me this is similar to some things proposed by community members in the past. I do not necessarily think they would work or succeed as expected, but that should not stop us from trying them (e.g. CC large scale miner buying, grinconomics early on, webplugin).
If there would be something that differentiates CC from OC it would be the following IMO: It is more acceptable for the CC to use funds to experiment and to facilitate wishes from the community. Even if those wishes are sometimes putting the cart before the horse, likely to fail or are just experiments. Failure and experimentation is acceptable as long as they do not negatively impact the long term goals and success of the project and as long as they are not wasting too much funds or developer time that might be needed elsewhere.
The debate is about whether a specific form of friction is desirable or not. Namely the friction for relaying obviously data carrying transactions.
There is quite a bit of demand for storing spam data like monkey jpegs on bitcoin where it will forever be retrievable. There’s also a bit of an industry for facilitating doing so, with various choices of data embedding (some obvious like OP_RETURN, some hidden like in taproot scripts or in fake outputs), and various miners happy to have such transactions directly submitted to them, bypassing the bitcoin relay network.
What Peter Todd argues is that by keeping the friction, the spammers are incentivized to either choose nonobvious data carrying transactions or to submit obvious data carrying txs directly to willing miners. While the amount of spam is not meaningfully reduced, you get some more utxo set pollution and less tx prunability. And you signal that you hate spam.
Furthermore, when you refuse to accept a spam tx in your mempool, and you later receive a block that contains the spam tx, then you need to ask your peers to relay the tx again, so it also wastes some bandwidth.
While there’s something to be said for changing the default parameter setting as core did, I think that removing the option for users to set this parameter, when they strongly voiced their desire for doing so, is a questionable choice by core.
