It’s about building consensus for valid transactions. I decide what is valid for my node and will not be upgrading to software that merges this request.
What mechanism is used for this consensus? If everybody has their own pool, how is this building consensus? My understanding of Bitcoin is consensus is built through proof of work and block validation.
What is block validation in your mind
The result of checking a block's validity in Bitcoin Core. This includes validating its header, merkle roots, and transactions, spending its coins, checking its coinbase, and protecting against duplicates.
The Bitcoin core team doesn’t decide what Bitcoin consensus is.
The users decide.
Since I use software with an OP_Return limit,
I will NOT be adding to the consensus that the limit should be removed.
You can choose to do that sure, just like many other users that choose to set the limit lower than Bitcoin core does by default.
The job of the node is to validate transactions according to their own policy. Not to blindly run any type of software any particular dev team tells them to.
I think you are confusing things here. Block validation does not have much to do with policy. Every node has to run the same block validation checks or risk inadvertently forking itself off, or getting forked off by an attacker feeding it a specially crafted block, and falling out of consensus. My choice as a user would be running Bitcoin Core, but I could also be running btcd, or libbitcoin, as long as they implement the exact same checks in their validation logic. Bitcoin Knots just re-uses the exact same block validation logic that Bitcoin Core does, so there is no difference there. We all have to apply the same logic, or risk falling out of consensus.
The difference that policy makes in the case where a Bitcoin Core and Bitcoin Knots client enforces different policy rules is that if a transactions enters a Bitcoin Core client's mempool, and is then included in a newly mined in a block, Bitcoin Core does not have to re-request the transaction from a peer and can validate the block with the transaction it already has. If Bitcoin Knots on the other hand does not have the transaction yet, it requests it from a peer first, and then validates the block with it. In the end, the result is the same. Both nodes validate the block in the same manner, persist the same block of transactions to disk, and have the same view of the set of unspent transaction outputs. Applying the same block validation rules is the consensus all nodes have to maintain with each other and policy does not really play into that.
That's just part of the broader consensus, and the most crucial part. Another part is the broader suite of tools within the software including the mempool policy and relaying options. What he said was not wrong.
There is no such thing as "broader consensus". There is consensus and there is policy. There is no fuzzy line in between them. Both are part of node software and policy at least being somewhat common between nodes is good for the health of the network to reduce latency and p2p traffic, but there is no consensus mechanism involved and it is not crucial. You can run a full node without a mempool at all. Maybe you are referring to what might be called the "social consensus" within the broader community of node runners to adopt similar policy rules?
This seems to be a semantic argument.
I’m sure you realize no one can force anyone else to run rules/policy/“consensus” that they disagree with. Even if they are bitcoin core devs.
The Bitcoin network is run by users. There is no leader
I agree with your last post here. The thinking of most core developers is that there is no point in maintaining an option that effectively achieves nothing. It is compared with a placebo. If transactions make it into blocks anyway, and there is no physical resource consumption downside, what is the point of keeping them out of the mempool?
Well I’m no expert but it seems to be that if ocean mines a block with a strict data limit, then on average it will drive big data transaction cost higher.
So yes it does matter imo.
Regardless, I am not in agreement that the current Bitcoin core software should remove the ability for users to set their own limit for op_return size
I think Ocean's market share is too small to have an effect here, though obviously that might change. They also use a different client already, so why should Bitcoin Core maintain something that they don't even directly use?
What does that even mean?
I'm not sure what you are getting at here. Do you mind elaborating?
"They also use a different client already, so why should Bitcoin Core maintain something that they don't even directly use?" -?
Oh, I was under the impression Ocean uses Knots exclusively. But I guess it could be relevant for people who would like to relay transactions to Ocean, or a Datum template provider.
Should add that I actually do support keeping the option to limit relaying these transactions.
We are also arguing on stackernews. thanks for the discussion and consistency.
I say it's a political issue at this point. bitcoin-core must stop appearing to support the forthcoming "built on bitcoin" shitcoins.
see NVK's comments to Livera
The PR should be rewritten after public discussion at the big conference coming up.
From a game theory perspective, this is an IPD (Iterated Prisoner's Dilemma), not a one-shot game—different strategies emerge, especially as the fee-to-subsidy ratio grows over time.
I have a feeling it will be. I'm usually not a mempool developer outside of getting its logic isolated from the rest of the consensus code, but I do care about data embedding too. I wrote my diploma thesis on the very topic.
