Dynamic Block Size

One thing I like about Monero that most coins do not do at all is their dynamic block size, it prevents many debates on what a block size should be and automatically scales to the traffic on the network.

Would like to suggest this idea to be implemented into Firo someday.

3 Likes

Hi, trymeout, I’m actually a big fan of dynamic block size but it has to be coupled with tail emission which currently there isn’t a strong community demand for it. I’m also actually in favor of tail emission but just that it’s not really a pressing concern right now as I think Bitcoin will suffer these issues earlier than us.

If the community is okay with it I totally am on board in implementing dynamic block size which is a pretty clever way to create a free market while not artificially cap on-chain scaling.

For those of you who don’t know what trymeout is suggesting you can read here:

6 Likes

I assume that you are concerned that dynamic block size = low fees = low hashrate when the coinbase reward declines. I think it doesn’t have to be this way. I’ve only skimmed this paper so far, but it designs a system of dynamic block size to target a given miner revenue level. “We offer an analytic expression for the [transaction confirmation] delay costs required to raise a certain revenue level.” For context, the article is published in a top economics journal.

2 Likes

Thanks @Rucknium! Nice to see you in our community as well. I’ll take a look through! I’m more concerned about when there is no more coinbase reward since Firo doesn’t have a tail emission.

2 Likes

Good to hear you also like the idea. And i support this too. Very clever the way monero does it and if we can bring it to Firo it would be awesome.

1 Like

I agree with ideology :+1:

1 Like

I’m also in favor of tail emission and dynamic block size. I always preferred Monero’s approach in that regard instead of Bitcoins architecture. I think there should always be some kind of guaranteed incentive to secure the chain… However what I would prefer much more… is a tail emission and full or partial fee burning… I think that would be more popular among folks who want super scarcity.

1 Like

We have seen people transact much more frequently during bull cycles (seen in high fees), yet transact much much less during bear cycles.
If a chain relied solely on fee incentives to secure the network, imo the chain would become disproportionately more vulnerable to attack during a bear cycle.

With the combination of a tail emission and a full or partial fee burning system. Firo could be deflationary of near deflationary during the good times, and during bad times have the block reward to offset a dramatic fall off in fee revenue incentive.

Personally I would lean toward a partial burn vs a full burn mechanism as a way to offer new fee revenue streams for nodes with the upcoming implantation of Elysium.

1 Like

Ideally we want to be able to keep fees low, as not to deter user participation and adoption which dynamic block size will help to do.
But we also want miners and nodes to be profitable. So imo we also NEED high transaction throughput and user engagement at some point in the future. This enables miners and nodes to be more profitable by leveraging economies of scale in terms of transaction/fee architecture.

Reuben said it has been shown that POW systems are compatible with scaling technologies such as sharding. If thats the case, I don’t think we should worry (within reason) in terms of short/medium term blockchain data growth.

2 Likes

Yes at the end of the day after Spark is deployed, the focus should be on increasing usability and adoption of the coin. While dynamic block size is a ‘nice to have’ and something I would support down the line, it’s not at the top of priorities at the moment as I do think we have bigger challenges to solve in the immediate future.

That being said, I do think that getting community input on the interest of such a proposal would be helpful so that once development schedules clear up this can be then implemented with community feedback already taken into account.