3-way comparison between 2minBlock/InfraBlock/Tailstorm, as objective as humanly possible for me

#1

I have created a comprehensive 3-way comparison between 2 minute blocks / Infrastructure Blocks / Tailstorm.

I tried to keep it as objective as it is even humanly possible for me. My hope here is that by reviewing this it will be easier to understand advantages and disadvantages of each solution so that in the future we can arrive at the best possible option that will accelerate and raise BCH to new heights.

Here is a TL;DR screenshot version:

3-way-comparison-2min-Infra-TailStorm
3-way-comparison-2min-Infra-TailStorm803Ă—347 79 KB

Here is the full version, in ODT format and in Excel format (hopefully the excel format will work too without any issues):

ODT
https://gitlab.com/ShadowOfHarbringer/docs/-/raw/master/2minuteblock_vs_infrablock_vs_tailstorm_comparison.ods?ref_type=heads&inline=false

XLS
https://gitlab.com/ShadowOfHarbringer/docs/-/raw/master/2minuteblock_vs_infrablock_vs_tailstorm_comparison.xlsx?ref_type=heads&inline=false

If you guys have any suggestions for further improvement and increasing objectivity even more, I am all open.

2 Likes
#2

Me too, but I reach different conclusions.

image
image1237Ă—586 133 KB

edit, attached ods file: 2minuteblock_vs_infrablock_vs_tailstorm_comparison.ods · 3e43e8994bd3ccdea17fed50f1a8a43834e99b6b · ac-0353f40e / fablous · GitLab

5 Likes
#3

Quick look:

More-or-less correct.

The “unpredictable orphans of iBlocks” is an advantage (not a problem because it’s added value), should be in green.

Also it’s not “unpredictable”. It’s super easy to predict that the orphan rate of iBlocks will be Very High.

Which is, again, completely fine.

EDIT / PS.:

I did not make a row with Inner-Chain-Orphan-Rate because such a row would be only valid for 1 out of 4 options.

So makes zero sense to put it in anyway :man_shrugging:

#4

OK, so where is the ODT?

EDIT:

Ooooh, I see. You made changes to my ODT.

#5

This seems more in line with my thinking. Can you remind me why original tailstorm vs the alteration you were thinking would result in different wallet compatibility issues?

#6

A thought on InfraBlock. Thoughts @ShadowOfHarbringer @bitcoincashautist ?

with iBCH — you now have a new incentive mechanism which is dependent on DEXs existing, and otherwise. The incentive mechanism relies on the tools the consensus provides — you have just created circularity in reliability of the network where the token requires a consensus change and for these new tools we need to hope that platforms built on the network exist
you can’t have an incentive mechanism to secure the chain that is reliant on a service built on the chain that assumes security of the chain

#7

Yes.

Congratulations, you have just described the basic Nakamoto Consensus.

The “circulability in reliability of the network where the token requires consensus change” is exactly how BCH and BTC works.

The whole world had to get in consensus that Bitcoin is actually valuable and build tools and ecosystem around it, the world had to make a decision that this crazy idea of currency independent from governments works.

Everything you said is a clone how Bitcoin works already. Because iBCH is also a smaller clone of how BCH works already.

We are creating a smaller, less efficient BCH that can do things BCH cannot do. But without this “smaller BCH” the things would be otherwise impossible.

#8

Original Tailstorm is essentially soft-forking faster blocks: summary blocks look like normal blocks to non-upgraded software with only noticeable difference being difficulty reduction to 1/K or 0 (depending on implementation details). This would reduce SPV security for non-upgraded software.

My variant is hard-forking faster blocks: chain would really speed up to 12s blocks and non-upgraded software would observe that too, and every now and then there’d be a 0-difficulty block accepted (shimmed in uncles). This would preserve SPV security, but would probably break some software due to blocks being so fast and height estimates not holding anymore.

1 Like
#9

You should definitely write a whitepaper or CHIP for it, I would love to put it into the comparison.

#10

New update has been released, containing new “Stakeholder’s Effort to Implement” section and some minor bugfixes.

TL;DR version:

3-way-comparison-2min-Infra-TailStorm
3-way-comparison-2min-Infra-TailStorm741Ă—543 114 KB

FULL version with annotations and sources:

ODT
https://gitlab.com/ShadowOfHarbringer/docs/-/raw/master/2minuteblock_vs_infrablock_vs_tailstorm_comparison.ods?ref_type=heads&inline=false

XLS
https://gitlab.com/ShadowOfHarbringer/docs/-/raw/master/2minuteblock_vs_infrablock_vs_tailstorm_comparison.xlsx?ref_type=heads&inline=false

#11

Having 2 NC blockchains interwoven together is not anymore “basic Nakamoto Consensus”. Why don’t we just merge with LTC and have miners mine LTC blocks as infra and BCH blocks as outer blocks? That would be absurd of course, but how is iBCH / BCH different from the absurd LTC / BCH idea?

Few more questions:

  • Could miners just stop mining BCH blocks and switch to iBCH if iBCH would get too valuable and/or BCH halvings exhausted BCH subsidy relative to iBCH subsidy?
  • Could miners charge BCH fee for TX inclusion in infraBlocks? Could they charge iBCH for inclusion in outerBlocks?
  • Could miners just mine empty iBCH blocks to get some occasional bonus (iBCH subsidy) while avoiding network overheads?
#12

Correct. It’s now 2 Nakamoto Consensensuses with each one being semi-independent.

Each compiments each other and each serves a function.

Beautiful, isn’t it?

Erm, this is what you are doing by proposing/rallying for 2 minute blocks.

You are basically trying to merge the thing that makes LTC “LTC”.

However I have not ever seen a competitor “win” by copying its competion. That’s a beta move.

To really really win, you have to make a bold, amazing, powerful move that nobody else does. That’s how you win.

EDIT:

I am very busy right now, I will address the rest of your points later.

1 Like
#13

OK, I have a little time now, I will answer your more complicated technical questions.

That’s impossible, it would break consensus.

  1. In InfraBlocks, whether a mined block has BCH reward or iBCH reward, depends solely on difficulty of mined block. A miner cannot just “drop”/“stop mining” a certain type of blocks because it would break consensus rules and the block would be rejected. (Also how would that even work??)

  2. Also, there are no separate blocks for BCH and iBCH. It’s all the same block with 2 sub-containers. All the data is always there.

  3. Maybe miners could intentionally orphan BCH blocks if they bring no reward? But there is no incentive for it. People who are not in a haste or pay in Brick&Mortar stores will pay the “normal” fee and will want to be included in 10-minute blocks. Would make zero sense for a miner standpoint to just drop 1 block in 60 because it is paid less. It’s still money, miners are strongly incentivized against something like that.

  4. The miner never knows whether he will mine BCH or iBCH blocks. It’s completely random. When the solution satisfies Di = D/60, it is treated by consensus rules as infraBlock. If the solution also satisfies D, it is treated as normal block. How would even such dropping scheme work? Miners would have to intentionally orphan normal blocks, which is allowed (like now in BCH), but they are strongly incentivized against it. It’s still extra cash and improved functionality of the network.

Charging iBCH for inclusion in outerBlocks/normalBlocks is against consensus rules, so they cannot do it with a “HARD” rule. But of course, miners can set fee policy how they want, so some miners may just not include certain transactions in both of their outerBlock, innerBlock.

Miners can also not include ANY transactions at all in any block and it is allowed.

…but this is exactly how it works now with both BCH and BTC.

Of course they can. But they can also mine empty BCH blocks now to avoid overhead.

So, how is that different?

You are basically describing Nakamoto Consensus all the time.

#14

Ohhhh, after a thinking session I may understand what you meant by that.

You mean a situation, where miner intentionally orphans all blocks with difficulty = D, so that he ends up mining only InfrastructureBlocks?

Well in this case, he cannot include any normal transactions in it, because, as described in the whitepaper, for transaction to be included in InnerBlock, the transaction has to have a specially crafted output that can be only spent as a miner fee in InfraBlocks.

obraz

So such a miner would be unable to collect the transaction with “normal”, cheaper BCH fees. Basically, something like this could only work if people suddenly completely stopped doing normal transactions and only used Fast Finality Transactions.

But people are incentivized against such an action, because :

  • The FF Transactions are(by default) 2 times more expensive than normal transactions.
  • People who use 0-conf have no need for fast finality TXes. 0-conf is superior, it’s instant (under 2 seconds in australia and 3-4 seconds in philipines: as seen on adoption videos)

EDIT: Another thing is that, the definition of “longest chain” (consensus) only depends on standard blocks.

So if other miners just mine a standard block and attach it to ANY InfraBlock, it’s considered the longest chain by consensus rules. Total length of the inner chain is completely irrelevant.

Thus, the evil plan of the miner to only mine InfraBlocks and skip Normal Blocks, is foiled.

As per whitepaper:

obraz
obraz829Ă—169 31.6 KB

1 Like