Here’s an additional case we might want to consider regarding Output Standardness (P2PKH, P2SH, P2SH32). It can be worked around, but is inelegant and adds size/op-code overhead:
1 Like
So, to start, this is technically a different topic. Yes, they are both standard-rules, but they are not really all that much related.
That said, I’d be supportive of removing the standard rules requiring “only known templates in output scripts” completely. The p2sh wrap makes all things possible anyway, so it’s not really limiting people and your example is a good point why having that check actually hurts.
However, it probably should wait until after the VM-limits CHIP has activated because we likely don’t want to just allow any-length output scripts, and the VM-limits chip could be a great place to synchronize the introductiion of limits.
2 Likes
A fresh round of contention about filter limits & OP_RETURN in BTC land has once again highlighted the problems of consensus/standardness disparity.
We’re already closing some of the gap with P2S CHIP. What about the rest? Is there room for a follow-up CHIP that closes the gap completely? VM Limits is about to ship, so that is no longer in question.
2 Likes
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.
2 Likes
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
2 Likes
Agreed on this. The alternative would definitely would cause more headaches.
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.
what problems are people having (on Bitcoin Cash!!) that removing standardness rules solves?
These rules that are left are there for a reason, so to remove one or more, some stronger reason must exist that makes the whole a positive change.
I haven’t really seen anything more than a feelng of cleanlyness.
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.
1 Like
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.
Can you explain the thing that you worry about?
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.
1 Like
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.
4 Likes
Note that exploiting standardness vs consensus gaps does have other edge cases and impacts.
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.
3 Likes
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;
Here a post from 5 years ago detailing it;
Specifically (bold mine):
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?
3 Likes
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
