Spearheading the future implementation of Weak Blocks (Intermediate Blocks) for BCH proof of work

Consensus
#1

During the discussion about DeFi systems that use Automatic Market Makers (AMMs) on Bitcoin Cash it turned out that giving Bitcoin Cash the ability of weak confirmations that are faster than default 10 minute confirmations would be potentially extremely beneficial not only to the DeFi systems, but to massive number of use cases.

Ultimately it came down to me to spearhead this idea forward in order to research whether it can be done at all and what are possible implementation details.

The technology basics:

Weak blocks are small “intermediate blocks” that miners mine in between normal, “big” blocks. They contain partial, weaker Proofs Of Work. The miners add transactions to the blocks and mine them, consecutively adding next blocks on top of previous blocks in a chain, exactly like they do with normal blocks, as defined in Nakamoto Consensus by Satoshi Nakamoto.

Theoretical advantages of this scheme:

  • Faster (weak) confirmation time of transactions, without affecting the main blocktime of the network and significantly altering consensus. My personal suggestion is 15 second block time.
  • Works great for Bitcoin Cash PR efforts, because Bitcoin Cash can be advertised as “the network with fastest confirmations” after the implementation (assuming 15 second block time is used for the intermediate/weak blocks)
  • Significantly decreases the likeliness of miner-assisted double-spending attacks. Makes them harder to execute and more complicated. (EDIT: After investigation it seems this may be not true)
  • Positively affects DeFi systems, which are very confirmation-time-sensitive and hugely benefit from very short confirmation times for good user experience.
  • Positively affects merchants and exchanges, that can use the weak confirmation as sufficient proof that a transaction will go through and not be reversed in a miner-assisted attack, thus allowing the users to transfer his funds faster.
  • Psychological reasons: Pretty much any BCH transaction benefits because it can get Proof Of Work behind itself much faster, adding psychological validity and legitimity to the sent money. It’s important to say that 0-confirmation already works well enough for 99.9% use cases of 99% people who mostly send smaller sums of money, so this is mainly a psychological solution. But still, it works because it affects people.

Theoretical disadvantages of this scheme I can see at this time:

  • The change would probably significantly alter consensus, it’s consensus-critical, so it needs developers with high technical skills and good understanding of the underlying cryptography. The possibility of critical bugs and failures is very high and even the smallest bug in such critical code can have massive negative consequences.
  • AFAIK the person that originally came out with the idea is not part of the BCH ecosystem right now, so coding + debugging and also repairing in case of some malfunction later in time can be extra difficult on top of already being difficult due to above

Advanced technological considerations:

Of what I understand about the technology (I am ready to be corrected though, not expecting that I will get everything right on first try),

  1. The miners mine weak/intermediate blocks in a chain, like they would mine normal blocks
  2. Each consecutive blocks contains the proof of work of itself, which is built on the proof of work of all previous blocks in the chain
  3. On average, after X=39 intermediate blocks [assuming 15 second weak block time; X = (600 / 15) - 1 = 39], a normal block gets mined that is built on the proof of work of the last(39th) weak/intermediate block.
  4. Alternatively, the miner can also skip the intermediate/weak blocks completely and just build the chain normally. It can also mine on top of any previous Weak Block in chain, thus orphaning some weak blocks (as it would work with normal Nakamoto Consensus). There is no penalty for not following the weak block chain.

Existing (unfinished) implementations:

  1. Storm/Bobtail proposal. Not completely sure if this is Work In Progress or maybe it was finished.

References:

Caveats:

My assumption is that miners will not be forced to always mine on top of the weak blocks, the weak blocks should be “optional”, because otherwise that would directly alter basic nakamoto consensus, which we probably do not want to do.

But this creates a problem: How do we make miners mine the weak blocks despite they do not need to? Well, the answer is the same answer Satoshi would give: Incentives. Penalties and Rewards of some sort.

During my discussion in BCH’s Telegram channels, we brainstormed 3 possible incentives so far:

  1. Rewarding miners with a specialized CashToken that can only be obtained as a mining reward for the weak blocks. The CashToken would be scarce, like BCH, could even follow the exact same basic mining schedule (21 million total in existence/halving every 4 years).

    The CashToken will automatically gain trading value after some time, because this is simply how human mind works. Everything that is scarce and works and is useful will have some value.

  2. Including an extra Transaction Fee that can only be acquired by a miner by mining a weak/intermediate block and not otherwise.

    How precisely this could be implemented: Unclear at this time. Main problem is that transaction format of Bitcoin Cash would have to be changed to accomodate the extra fee in another field.

  3. A “donation pool” that people can donate their funds voluntarily to. Such funds could only be claimed by mining weak blocks.

Possibility of future implementation:

Currently unknown. Topic up for discussion.

Proposed time of future implementation:

Cannot be determined at this time. Topic up for discussion.

#2

As initial FYI – I have attached the original whitepaper here before Bobtail was merged into the pro forma TailStorm. This is an excellent read to get up to speed. storm-wp-2019-08-30.pdf (520.4 KB)

The first question that pops into my head – will this alter the ability for miners to switch between BCH and BTC chains easily? SHA256 won’t change, but the benefits/drawbacks would also need to be discussed.

All of these points are quite valuable and deserve further discussion.

BU ended up completing an implementation of this on a separate testnet. The second iteration of Storm called TailStorm (merge of Storm and Bobtail). Base is still there, at least for the BU implementation, but 100% still this is a large change that would require significant work.

I don’t see this as likely – what would those coins be used for? What would drive its value? Seems like an overcomplication.

The other two suggestions…I don’t know how I feel about.

Topic 3.6 in the attached WP discusses incentive mechanisms which I will quote below:

To address the other main concern with regular weak blocks from above, which is the lack of incentives to follow and build them, it is hereby proposed to change the POW measurement rule in Bitcoin from the chain of most cumulative strong POW to one where weak POW is used to break the tie of a strong block race by selecting the chain which has more WPOW in that situation.

If delta blocks are preferred in this way, a miner has an interest to select and merge those delta tips that will make the resulting mined weak block the longest chain in the above WPOW chain length metric. A miner furthermore has an incentive to share his (or her) weak block as it will make sure that the network tends towards his (or her) reading of the situation in case there are conflicting transactions. As s-/he does not necessarily know in each instance and at each point in time whether a transaction will be double-spent, s-/he has an incentive to preventatively argue for his variant of reality by publishing a found weak solution to the POW problem.

However, should this incentive turn out to not be strong enough, a more direct incentive could be - and this is rather a discussion than a proposal - reward sharing amongst WPOW blocks. The approach would be to add another soft fork that demands a miner share his block reward among all the delta blocks that make up the strong chain tip that s-/he found.

It should be without question that any consensus change should only be implemented with strong support from the userbase, developers and general members of the ecosystem and in case a more comprehensive instant confirmation solution is deemed really desirable. As a side note, a potential further tweak to a delta block scheme could be to estimate the desired delta block difficulty and the WPOW threshold dynamically and adjust it independently from the strong blocks difficulty.

1 Like
#3

In Bitcoin proper (including BitcoinCash) the difficulty is directly responsible for the proof of work, the both are also set in stone by the difficulty adjustment algorithm.

This is needed because if it were not so, as the quoted WP suggests, then a perfectly valid block can be out there for minutes before an even better block comes by THAT DOES NOT EXTEND IT and thus replaces it.
In the Satoshi whitepaper he writes in the conclusion:

They vote with their CPU power, expressing their acceptance of
valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them.

The idea to include how much a miner communicated, or was able to follow sub-consensus, is a pretty darn big deviation from “valid” vs “invalid”…

#4

Hmmm yes, I am not sure if the difficulty of the weak sub-chain can be just calculated from the difficulty of the main chain by dividing it by N, or does it need its own difficulty adjustment algorithm (which can be the same as the mainchain algo)?

  • N = number of sub-blocks “between” normal blocks.
#5

3.4 and 3.6 of the WP briefly discuss a mechanism

#6

Updated the article, added this section for clarity. Some people thought this proposal is a type of pre-consensus. This is not the case, the whole scheme is optional:

  1. Alternatively, the miner can also skip the intermediate/weak blocks completely and just build the chain normally. It can also mine on top of any previous Weak Block in chain, thus orphaning some weak blocks (as it would work with normal Nakamoto Consensus). There is no penalty for not following the weak block chain .
1 Like
#7

Weak blocks are a neat idea. Thanks for placing here a topic that allows the different people to add their opinion so it is searchable and such.

This is also several years old and a lot of us have gone over this various times so I don’t expect a lot of heated debate :rofl: Just old farts sharing their thoughts.

In your post you did touch on other stuff to, let me briefly also comment on those:

AMMs

AMMs are the inversion of the basic trade where exactly one key (and one owner) can spent something. It inverts it by allowing anyone to do so, as that is the permissionless base of such decentralized finance (defi).

On top of this base people can build centralized trading houses and that doesn’t actually cause things to become not-defi. There are always more trading houses to go to since they can be started permissionlessly.

The worry that the 10 minute blocktime is going to create a bad user experience is then also quite a lot easier to solve. It is NOT required to do this in a way that is perfectly free and open to the entire world to mess up at any time. No, it can be solved in any way that we’ve been building such software for ages. By making the trading more centralized of the one ‘shard’ (aka capital) being only traded at one centralized place. With a full node that has a lot of connections throughout the network and some good old smart developers operating the server, it is an entirely solvable problem now.

No need for faster blocks, just more control over which chain is being followed and more investment in code that works around anyone else.

Tokens and economics

Tokens are great, they have the ability to move a lot more than just plan old simple payments to the BitcoinCash network.

Tokens also can be used as silly pictures and gambling.

The basic premise of what gives BitcoinCash value is that trades on-chain represent actual economic activity in the world. I buy something in the store, this generates a transaction on-chain. The value rises.

Tokens could indirectly be about BitcoinCash using transactions, but they don’t have to be.

If you’re to have more token transactions on chain than BitcoinCash transactions, its like a tree with branches thicker and heavier than the trunk. The system will break.

So, in short, the normal boring transactions of the paying kind are always and forever going to have to be main event and any changes proposed are going to have to be given more attention than we’ve seen here.

Weak Blocks

Now we finally get to the real thing.

This is a neat idea. It is born from the concept of mining pools. A miner tells the mining-pool-operator that it found a ‘weak block’ in order to prove to the operator that it is actually mining. A weak block is one that basically targets a much lower difficulty than the target difficulty. A weak block can be so strong that it is used as a final block.

What is important is that miners in a pool don’t really build the blocks. They just mine a header. As such reporting that a weak-block was found is also just reporting about a single header of 80 bytes.

And this is the first question that this whole setup raises: if weak blocks are supposed to be useful for finding out which transactions will be included, then somehow the list of transactions needs to be uploaded somewhere.

I’m sure that the weakblocks people thought about HOW to do that. But the question is not how. The question is what that does to the system of Bitcoin.

Remember that Avalanche was based on this same concept, but they added voting to transactions. And this is an issue that will be brought up too. A miner that finds a weak block that doesn’t have a transaction that the previous weak block has could consciously omitted that transaction (too low fee, perhaps). Or they didn’t receive the transaction yet. We don’t know.

But now we have a decision point. To include this transaction or that. The same with actually two conflicting transactions. Having the information what another miner is doing isn’t all that useful unless you know what do to with that information…

To make a long story short, the main conflict that this and similar systems bring up isn’t about communication.

The main issue here is that either miners follow some leader, or miners make their decisions completely themselves.

In the first case you just threw away permissionless mining.
In the second case you don’t need weak blocks, they don’t add anything. Listeners can’t derive any information from them that has low risk. There is no actual benefit.

1 Like
#8

The final tailstorm paper can be found here: https://people.cs.umass.edu/~gbiss/tailstorm.pdf

If subblocks are optional then…

is not true.

Additionally, if the miners are rewarded at all for mining subblocks but they are not required by consensus then the incentives are to never use them rather than use them in order to maximize rewards. if there is no reward for them then again, incentives are to never use them because that is extra processing work for no reward.

2 Likes
#9

accurate. i realised later there was a simpler path to implementation that would have resulted in less changes but it was too late.

#10

That is what we did for subblock PoW for tailstorm

assuming the hashrate remains fixed, the subblock difficulty will be 1/K of the full block where K is the number of subblocks needed to make a full block

1 Like
#11

Is it possible to “merge mine” mini blocks in a way that if one of the small blocks can turn out “good enough” to be instead used as a normal “big block”, then it is just mined as big block instead?

What I mean is I would not want to waste Hashpower to mine something that is optional.

Best solution would be to mine both at the same time, and if the result is sufficient, it can instead be used as a normal, “big” block.

#12

Well then, this is definitely a problem.

#13

Thank you for sharing the final paper! Going to take a read.

#15

Skimming the PDF provided by Griffith, parallel mining is used to largely avoid wasted blocks.

Doesn’t seem to work how you’re thinking, either, though. sub blocks act as votes for summary blocks — actually benefiting a bunch of issues that exist today — still reading, but this isn’t the same idea as weak and strong blocks — this is far more interesting.

@Griffith Very curious – is there a reason Bobtail was not implemented on Nexa? Thusfar I see mostly good in this paper.

#16

Well if this is so, then this is not really what I want and what I am pushing.

The sub-blocks should be merge-mined both at the same time, so hashpower is never wasted.

Any sub-block that accidentally achieves the difficulty of normal block, simply becomes normal block.

Another question is, whether such a scheme is possible.

I will investigate how merged mining works in order to maybe come up with such a solution.

#17

Have you read the paper yet? I’m not sure you’re grasping the concept (and that’s likely because of my rushed explanation). The votes concept isn’t exactly accurate, was on a train. Many sub blocks make up a summary block – so little wasted. They can work like this

Screenshot 2024-07-11 at 10.29.05
Screenshot 2024-07-11 at 10.29.051742×540 75.3 KB

#18

On my way there. I need proper sleep too, you know.

#19

Just edited my comment that should help with visualization.

#20

There are plans to implement tailstorm in a hardfork. It was not included at chain launch because it was not done yet. That is really the only reason.

A little history on the progression of the protocols BU worked with…
weakblocks is the term used in Storm. They are called proofs in Bobtail. Tailstorm calls them subblocks.

I think it was… Peter Rizun? who began tinkering with the weakblock idea that became storm and awemany who had started to implement it. It was originally thought that the weakblocks should be optional because amaury was gatekeeping consensus changes at the time. However, we found that storm needed to be added to consensus otherwise incentives dictated that it was better not to use the protocol (i touched on that briefly in a previous post). Without consensus changes the feature was broken and was dropped.

Bobtail, as you pointed out, has a lot of positives. The issue is that there are intra-block attacks possible with bobtail that had not been considered. A few proof-witholding attacks were found. The original paper never claimed to address all attacks, it only showed that inter block attacks could be mitigated with bobtail. This was the reason for tailstorm.

Tailstorm adds mitigation for proof/subblock withholding attacks (intra-block attacks). Discounting the subblock reward based on the topology of how they were linked seemed to encourage people to reveal their subblocks quickly. It also allows for the proofs/subblocks to be used for preconsensus without overriding PoW like avalanche did.

If you want you can think of tailstorm as bobtail 2.0, a bobtail with more consideration for attack mitigation.

4 Likes
Tailstorm: A Secure and Fair Blockchain for Cash Transactions
#21

Nit: even now chainwork of a block is determined by the target difficulty and NOT by actual difficulty of the winning hash. In other words, if a miner gets lucky and finds a hash with more 0s than needed, his block WILL NOT weigh more than a competitor with less 0s (but still above target).

1 Like