all i can say is thank god we’re not all stuck on a single client or relay. checks and balances.
Discussion
Yeah, I am honestly surprised there aren't more implementations of Bitcoin in every language with a million config toggles. If only Libbitcoin worked...
I mean thats way more risky for bitcoin. You need a single canonical client for consensus critical code. If things break on nostr noones cares. If your money breaks thats a big problem.
Your money wouldn't break though? Your UTXO is still valid, your transactions would still be broadcasted, and you would have values that tell peers what you find valid.
Think this way: if you only used dollar bills that have certain serial numbers all you are doing is making it more difficult for yourself to acquire valid dollars (in your opinion). But most people use default configs so there's your general consensus. Unless one of the defaults is obnoxious or dumb most will toggle off as a step of setup.
validity is defined by the implementation. Any slight bug can cause a divergenge and the situation would end up like this when trying to figure out whos wallets have the correct balance and spend-ability conditions for the same utxos
*points to btcd exploits*
And this is why libbitcoinkernel and forks of Bitcoin Core is a better idea. Change policy, not consensus.
That is already the case with node mempools, no? My mempool doesn't accept over 80 bytes in OP_RETURN data. Other peers do. My node finds those transactions invalid.
The implementation that has a bug is the same as a Core node that accepts 400k bytes of data in a trasaction to my node.
mempool policy/standardness is not consensus code. It just extra rules on top that try to reduce the spam on the p2p network and which transactions you want to keep around in your “ready to accept” queue, aka mempool.
Since there could be more transactions you could fit in your system memory, mempool policy helps make sure you see transactions that have non-spammy things like some reasonable min fee or excessive data carrier sizes (this is the controversial bit, whether its worth maintaining that logic you can hack around anyways)
With or without this core setting you can still give the transaction to a miner directly to mine it, since consensus code doesn’t care about policy.
It's so funny I feel like we are saying the same thing at different times.
My point is that if I run code that I agree with my mempool doesn't propagate things I consider to be spam. I have no illusions that if a miner mines a valid block with transactions I dislike, I will still have to store that block in my UTXO set. But the choice of not propagating trash is what is up for debate here not the bounds of a valid transaction in the block.
I mean i have always been on the side of relaxing standardness (i miss puzzle transactions) but i think core is always going to side on removing knobs that produce foot guns, not adding more powerful customization. I think i plugin system would be cool so you could implement any logic you want, so noone would have to argue. I think the concern then would be social media campaigns for people to download certain plugins without realizing the effects it would have on tx distribution.
Man, if social media campains to influence people are the problem, I heard about this neat protocol...do you like purple?
How is removing the OP Return limit reducing happen stance of foot guns?
> When the polite avenue is blocked, determined users turn to impolite ones. Some use bare multisig or craft fake output public keys that do enter the UTXO set, exactly the outcome OP_RETURN was invented to avoid.
I’m kinda tired of talking about this tbh. The linked document has everything you need to know
To be clear there is no canonical implementation of bitcoin. The software does a few things invariably and the rest is preference. Validations, unconfirmed transaction pool, peer connection, and transaction broadcasting.
This is the way.