Consensus Change proposal: min tx size of 100 bytes, instead forbid 64 byte txs

It’s likely beneficial to be as inclusive as possible when picking two possible changes with the same costs. Comparison between change and no change, though, should not follow the same line of thought, for changing the rules has an inherent cost over not changing.

A comparison between change and no change should absolutely follow the same logic as long as you add that inherent extra cost to the change in the change vs no change scenario. The evaluation process is the same, does the benefit over time outweigh the immediate cost.

Unrelated to the philosophy:
Tom has made a couple of good points in noting how the non negligible benefits of this chain in the post above mine. It is clear that for a negligible cost there are non negligible benefits.

Yeah, this is another benefit I was thinking of, but didn’t feel I should bring up. Now that someone else mentioned it, I’m happy to pile on. As someone who has written an occasional regtest functional test for ABC, I can say it is definitely irksome to have to pad transactions, and this happens all the time because in regtest it’s most efficient to do mock transactions with OP_1 scriptpubkeys, no signature required. An OP_1 -> OP_1 tx is 61 bytes, or 71 if it has two such outputs; it is rare to hit 64 bytes exactly.

Another anecdote: The 100 byte limit caused many functional tests to fail in ABC. Amusingly they only found this out by surprise when the rule activated on mainnet, Nov 2018. (i.e., they had never tried running their functional test suite with the upgraded rules, and CTOR at the same time caused futher chaos).

1 Like

I kinda agree with both you and im_uname. The topic is essentially that people love to fix things in a project they adopt, the question is what to evaluate when the fix is in the protocol that a bunch of projects today implement.

So, yeah, you absolutely need to take cost into account of all implementations that need to change. The product owner of this change can’t just assume that they can outsource the work of a change to all the stakeholders. There needs to be some negotiation on that betwen the PO and the individual stake holders.

As a second metric we have the project-wide cost of future adoption. For BTC there are SegWit and LN which makes it much harder for developers to enter their ecosystem. This is a metric that IMOHO should count for something too. Making things more complex for future stake-holders to enter should have a large cost.
Making things simpler for future stake-holders to join our movement may aliviate some of the cost put upon the current stakeholders basically due to the fact that we all want and need BCH to have massive growth over the next decade.