chip-bcmr VS ebaa

Creators of tokens on the BCH mainchain can leverage the advantages of having a following a standard and entering that info into the BCMR (Bitcoin Cash Metadata Registry). To help streamline the process developer Mathieu Geukens has created a handy generator to enter all your newly created token info and have it ready for submission.

The Paytaca wallet team has created an open source indexer for BCMR (Bitcoin Cash Metadata Registry) metadata. In the next release of their wallet new CashToken metadata will be shown in the wallet.

Now, just a couple of week after the publishing of the metadata chip, I guess he finally found it this also didn't make him happy.

You can find the full specification here: https://github.com/bitjson/chip-bcmr, and I'll be hosting a livestreamed tech talk + Q&A on Bitcoin Cash Metadata Registries tomorrow, November 1st at 13 UTC (9am Eastern time).

Bitcoin Cash upgrades through the CHIP emergent consensus system. Developer bitcoincashautist has published a new CHIP which aims to end the scaling debate by having the BCH blocksize scale via algorithm and is now implementation ready. For details on testing please see the CHIP.

Based on historical data, it would err on being too slow. Or, more to the point, of moving the block size limit in the wrong direction. Actual network capacity has increased a lot since 2017, and the block size limit should have a corresponding increase. Your simulations with historical data show that it would have decreased down to roughly 1.2 MB. This would be bad for BCH, as it would mean (a) occasional congestion and confirmation delays when bursts of on-chain activity occur, and (b) unnecessary dissuasion of further activity.

It's miner's own self-limits that would make us feel it in fees a little, the "hard" limit should never be the cause of fee pressure IMO, BTC users didn't feel the "hard" limit until end of '14. Here's an alternative history 2009-2017 with the algo: https://gitlab.com/0353F40E/ebaa/-/raw/main/img/fig2-alternate-history.png

Anyway, look at historical limit of 1MB... it wasn't being hit for a long time (the green curve didn't hit the limit, it was miners self-limiting their mined sizes), it started taking hits beginning of 2015, and that's when it should have started moving.

Yes, I get it, the "max produced" (now at 8MB) is the tool miners can use to negotiate size & fees with the market. BTC started having problems somewhere end of '14 start of '15 when first blocks at max_produced=max_accept started to appear. Later the frequency of such blocks increased and they couldn't raise the max_produced more in response to demand (it was 500kB, then 900kB, then hit the 1MB ceiling). The EB is firstly a DoS limit, ideally nobody would know it's even there, but it would prevent an adversary from announcing an obscenely-sized block and having nodes choke on it. Regular miners would just keep moving their "max produced" up in response to adoption, and the DoS limit would magically hover at some distance above that.

Yes, it would be a config parameter. I made a little tool that takes a list of blocksized and spits out a list of EBs, it's run with: