Yeah I would like to see an effort made for a ‘great standardness cleanup’
the P2S CHIP removes the output standardness and the ‘input bytecode length’ standardness
This leaves opreturn standardness, dust-amounts standardness and tx size standardness
If we were to align the relay rules with the consensus rules, then the question because which one to keep
the dust relay standardness rules don’t even seem standardized across implementations, see the standardness-docs.
converge on consensus
no max opreturn specific rule, except for max data item?
increasing the standard max tx size 10x (from 100kb to 1mb)
no dust limit?
converge on relay
opreturn max being consensus enforced at 220 but allowing multiple opreturns
lower the consensus by factor 10 (from 1mb to 100kb)
all implementations converging on the BCHN dust rules?
I’m not sure it will be easy to pick which to converge on or whether we need to consider on a case-by-case basis.
Note that (custom) nodes can still chose to not relay transactions according to any arbitrary criteria, so there is no guarantee that you’ll ever be able to change everyones relay policy (as we see now with Knots) but I think there likely won’t be any BCH node implementation which intentionally wants to introduce custom default network relay rules.
we don’t have to; I think what matters here is that the default is maximally permissive and then node operators / miners can further restrict it if they want
as opposed to status quo of being restrictive and then some operators may relax it and cause headaches for everyone else
I would not include min. fee and dust limit here, that would be dangerous to fully relax because right now there are no consensus limits on those; we may even want to research a good way to set some consensus limits there
I found this a really interesting breakdown as well with regards to the actual reasons for non-standardness transactions here
It’s being used to justify hijacking BTC even further, so caution required, but it’s good thoughts.
Feels like none of them apply to BCH though tbh.
DoS defence is covered by VM Limits.
Incentive alignment isn’t needed in BCH, we don’t have to “policy nudge wallet devs” cos it’s not full of RBF and some nonsense “fee market”. BCH wallet devs just make wallets that work lol.
Upgrade safety also not an issue, because we have the CHIP process for that and can hard fork.
Prevention is better than cure. We’re in a privileged & fantastic place to NOT be suffering the kind of drama & meltdown that BTC is, as well as having a smaller community more easily able to be aligned (FOR NOW). The gap between consensus & relay policies seems to just be a permanent location for hijackers to target in order to create drama and brinkmanship. If we seal those gaps, we fix the problem before it ever arises.
Note also that increasing BCH success is drawing attention from BTC defectors, converts & saboteurs. “Nobody in BCH wants to fight over policy stuff” - yes, right NOW, but there are very good odds that will become increasingly controversial as we grow, particularly from a pool of people that ARE of very strong opinions on that topic.
Does the potential for issues justify the effort & work needed? Well, that’s what we’re doing in this thread & with a potential CHIP proposal. No different than figuring out ABLA before the blocks are all full. At the very least, it would be nice to have a well-documented layout of what is and isn’t consensus and policy and the specific reasons for each. Even as involved in Bitcoin as I am, I’m not even fully clear & that’s the first step of the process - getting to clarity on the current situation and then secondarily evaluating the risks & potential improvements.
hey,
now, not because I’m disagreeing or something. I’m just not following the logic here.
What kind of things can hijackers do with regards to the differences between standardness and consensus?
For instance, transaction size. Maybe we should guard point of sale systems against huge transactions, making the difference between standard and consensus irrelevant.
But at the same time, double spend proofs would still kick in whenever anyone wants to abuse this, making this attack die before it begins.
Create enormous amounts of ecosystem stress & chaos arguing over different node implementations, which nodes allow which policy settings, why one group of devs is changing the defaults to this or to that etc. If you haven’t been following all the BTC drama, you can read up on the links on slide 4 here
What I’m concerned about at the moment is not really to do with technical problems, because as we both know everything is currently working fine. It’s all to do with social contention - which is far harder to solve once it gets rolling with a significant amount of non-technical people getting into the debate (which they inevitably do).
Hahaha, that is funny. There is literally zero risk of that in either BTC or BCH.
Look, the miners are extremely risk averse and have for years made it super clear that they ALL want to run the same mining software. So if there is a mistake in one, they will not get rejected by other miners because they run the same.
Ask the Verde guys about this, they made infrastructure to test a block template on multiple node implemenations. It basically got ignored. It wasn’t seen as useful by miners they talked to, because they don’t expect other full nodes to be used by the miners.
Even on BTC there is like one miner with a tiny sub-percentage of hashpower that is politically picking “the other” full node.
So this is a completely empty threat from the other teams.
Does it create drama? Sure, nobody doubts that. But it is completely without merit and that means that it makes no sense to worry about it. Drama based on lies will not go away by technical fixes.
This is the BTC Core writeup of how they think about policy vs consensus. Maybe worth looking into, with the caveat that chains are constantly diverging and they might have propaganda or incorrect assumptions in there too of course.
Things are heating up in the mining scene with a new initiative by several pools to join MARA in accepting non-standard transactions!
The three mining pools, representing over 36% of Bitcoin’s total computing power (hashrate), have agreed to support non-standard transactions (NSTs) — a critical piece of BitVM’s challenge-response mechanism, the firms said. Their support removes a key bottleneck to BitVM deployment and brings the system closer to widespread use.
The case for essentially bringing standardness & consensus into alignment growing stronger by the day it seems.
New problematic issue with exploiting the gap between standardness relay policies & consensus has emerged.
It’s become trendy on BTC for miners to include (non standard) sub 1 sat / vByte transactions in large batches (driven by Ordinals/Inscriptions demand, and a regular lack of competing “regular” transactions at 1 sat+ rates). Note: Bitcoin Core is currently 85 ish% of the network, Knots has grown to about 16%, although in this case I don’t believe there is a policy distinction (yet, it may be imminent). Regardless, because these transactions are outside Bitcoin Core policy, lots of node operators (including miners presumably) have to backfill these unheard transactions after a new block filled with them is published. This has massively reduced the benefit of compact blocks, as requesting maybe 10kb of new transactions has in some cases shot as high as 0.8 MB.
The Bitcoin Core plan is to lower the min relay fee for standard transactions, which is probably a good response, albeit 1) it’s kind of avoiding the greater issue that BTC is not only failing to drive the needed “oil tanker” fees to sustain security budget in the long run on a tiny blocksize it’s actually moving in the opposite direction with increasingly lower fees and 2) it’s upset the Knots filter guys who are becoming increasingly aware of the hijacking now that their desired filter changes to block Inscriptions are being continually ignored while filter changes to facilitate Inscriptions are being fasttracked.
In any case, the upshot for us is that this seems to be another data point that shrinking the gap between policy & consensus is a good idea to avoid this fragmentation of mempools encouraged by varying relay policies and/or incentives for miners to include non-standard/widely unheard transactions.
Edit: One line summary that this is a BIG impact
In June, we were requesting less than 10 kB worth of transactions per block on average for about 40-50% of blocks. Now, we are requesting close to 0.8 MB worth of transactions per block on average for about 70% of blocks.
This is a misunderstanding of the situation. The implication seems to be that if all policy rules become consensus rules that this issue would not exist.
Maybe so, but minimum relay fee being consensus is the natural result of that thought process. And that can’t be the intention.
Furthermore, relay rules are not limited in any way to fee level. The inclusion of certain op-returns has been a debate on BTC and is a relay rule too.
In Bitcoin Cash I expect a lot of innovation to happen on the side of the mining software where they pick and choose what to include. For instance higher days-destroyed may allow lower fees.
So, this is a misinterpretation of the issue.
But more importantly the solution has been known for some years, it’s just that nobody has implemented it yet. See;
Things are continuing to fall apart on BTC. The “Knots” guys have cottoned on to & accepted the Hijacking (apparently if the company is called “Chaincode” then that’s a real corporate takeover funded by bankers but if it’s called “Blockstream” it’s a conspiracy theory lol), but they still have loads of propaganda & are in a very confused state about everything while they sort through it.
As part of that, the latest panic is that Bitcoin Core’s upcoming change in v30 (coming next month in October) raises filters to allow 100 000 byte OP_RETURNs by default (instead of 80 as now, 40 on Knots & 220 on BCH). This matches the 100 000 consensus limit on both chains.
The panic is that this opens the floodgates to people posting child porn into the blockchain, which they are then required to process and validate while holding it in mempool. See this 1 hour video. There is of course already such material obscured in public keys and so forth since 2011 or earlier - and arbitrary data up to 100kb OP_RETURNs could already be got in around relay policy today (albeit with some culpability trackable to the miner who included it).
Nevertheless, it does once again raise interesting questions if the BCH community should consider lowering the OP_RETURN consensus limits from 100 000 bytes? Should consensus be the same as the current standard relay of 220 bytes? Or is there a better number lower than 100 000 it should be set at? What is the need for having consensus allowing such large OP_RETURNs? Is anyone using it? Can we close this issue with “undesirable” uploads to BCH (at least to the point of having increased “plausible deniability” that we’re operating a p2p cash system and not a free-for-all global hosting network of such material) before it becomes an issue for us?
Note this concern about such material is not theoretical. As per usual, BSV has already led the way by abandoning all reason on this topic and then immediately receiving the consequences of their actions. Source
I’ll just voice my opinion here that I am generally in support for closing the gap between standardness and consensus.
My understanding is that there is only a limited number of differences remaining, and while addressing them is certaintly not a high priority, I would welcome anyone who champions a CHIP to address any or all of those differences.
Ideally I would prefer each difference to be addressed by a separate CHIP, and I consider progress towards the overall goal of closing the gap to be valuable even if we never reach a state where all differences are entirely eliminated.
The discussion on filtering on BTC has literally nothing to do with BCH or with standardness rules, so not sure why that is being added here. It feels political. “Look at this bad effect, lets change this completely different thing because that would safe us!”.
The truth is that even if 100% of consensus and standardness are in agreement, miners can and should still be able to pick which transactions they include. That is required for an open market to work.
For instance a consensus rule on which fee is to be paid would not only be impractical, it would lead to bad effects economically and centralization and raising costs as a result. Look price fixing up as a economic / government topic if you want to know why this is. (also covered in “economics in one lesson” from Henry Hazlitt).
Filtering transactions is basically just free market at work, miners pick what they mine for reasons of their own. If you are against this, you are against free markets and you should likely not use Bitcoin Cash at all.
I prefer keeping fees and other aspects that the node can adjust out of the consensus rules. Perhaps we could establish a best practice for the node policy, but each miner should have the freedom to choose what they include in their transactions, and the free market should ultimately decide. Node can restrict further, but the protocol should leave everything open
