How VeriBlock PoP BFI Protects Altchains

From Veriblock Wiki
Revision as of 19:38, 22 July 2021 by FuzzyBot (talk | contribs) (FuzzyBot moved page How VeriBlock PoP BFI Protects Altchains/en to How VeriBlock PoP vBFI Protects Altchains/en without leaving a redirect: Part of translatable page "How VeriBlock PoP BFI Protects Altchains")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

See: VAIF

Overview

Users of a VeriBlock-PoP-secured altchain can use the Bitcoin Finality Indicator ("BFI") to easily determine exactly when a transaction on an altchain network has as much (technically, more) security as a transaction on Bitcoin itself.

Proof-of-Proof ("PoP") functions by incentivizing PoP miners to publish fingerprints of a security-inheriting blockchain to a security-providing blockchain in exchange for a reward.

In the event that an attacker attempts to reorganize the security-inheriting blockchain, the fork resolution protocol consults these previously-published fingerprints to determine whether the fork is valid or not.

If the alternate security-inheriting blockchain fork lacks sufficient publications in the security-providing blockchain (publications do not exist, are too late [past the finality window] in the security-providing blockchain compared to same-height publications of the 'legitimate' security-inheriting chain, and/or the publications of the fork do not contain sufficient context to provide a complete [no gaps] view of the fork), then it is rejected.

If the alternate security-inheriting blockchain fork has publications to the security-providing blockchain that are better than the publications of the 'legitimate' current security-inheriting chain, then the fork is accepted. However, this forces the attacker to announce their attack in-step with the building of the legitimate main chain; announcing to the world where their attack starts (which blocks are threatened), and also indicating when their attack is abandoned (they stop building an 'offline' chain).

In the absence of such malicious attacking publications for a particular time period (measured in VeriBlock and Bitcoin blocks), the altchain has a mathematical guarantee that unless Bitcoin blocks themselves are reversed (Bitcoin experiences a 51% attack), those altchain blocks can never be replaced. This guarantee is provided by the Bitcoin Finality Indicator ("BFI") which indicates when an altchain block (and its included transactions) have achieved Bitcoin finality, meaning that Bitcoin itself would have to be 51% attacked in order to be able to fork the altchain block off the network and perform a double-spend. In the presence of such malicious attacking publications, everyone can see which altchain blocks are (and are not) threatened by the attack, and know not to finalize/confirm any transactions in such blocks until the attacker either succeeds in a reorg (but no double-spending occurred because nobody confirmed transactions in those blocks which were under attack), or the attacker gives up (and the cessation of malicious attacking publications extending the attacker's chain for a particular time period (measured in VeriBlock and Bitcoin blocks) provides the same mathematical guarantee, albeit delayed, that Bitcoin itself would have to experience a 51% attack in order for those previously-under-attack altchain blocks to ever be reorganized off the chain.

A Proof-of-Proof secured altchain protects its users from double-spend (51%) attacks by emitting real-time security statistics for any block (and the transactions included therein) on the altchain network by looking at these malicious publications (or a lack thereof). These security statistics indicate exactly how difficult replacing a particular block (containing a particular transaction) on the altchain network is, ranging from only needing to reorganize n altchain blocks, to needing to reorganize n VeriBlock blocks, to needing to reorganize n Bitcoin blocks. When the number of Bitcoin blocks an attacker would need to reorganize a particular altchain block is greater than zero, that altchain block (and all contained transactions) have achieved Bitcoin-finality, meaning Bitcoin itself would have to experience a 51% attack in order to be able to reverse that altchain block (and all contained transactions).

See: PoP_FAQ#.22VBK_does_not_protect.2C_it_just_detects.22

How VeriBlock Protects my Altchain

Proof-of-Proof ("PoP") functions by incentivizing PoP miners to publish fingerprints of a security-inheriting chain to a highly secure security-providing chain.

As explained in the overview, the fork resolution protocol of the security-inheriting chain consults these publications in the event of a proposed reorganization.

The software which produces the block security statistics proactively looks at the publications for a particular security-inheriting chain in a particular security-providing chain to determine whether it is mathematically possible for an attacker to reorganize the security-inheriting chain without also reorganizing the security-providing chain. In the example of VeriBlock or altchains secured using VeriBlock, BFI indicates whether it is mathematically possible to reorganize a particular VeriBlock/altchain block without 51% attacking Bitcoin (and if it isn't, how many Bitcoin blocks would have to be reversed), and whether an attacker is currently publishing malicious fingerprints of a reorganization of the VeriBlock/altchain (and if so, which blocks are in danger of being reorganized from the published fingerprints of the attack).

BFI Example

Here is a visual demonstration (simulated for illustration purposes) of how PoP security and BFI works from VeriBlock to Bitcoin (and for altchains, the process is extremely similar).


An attacker sent a transaction to a would-be victim in a VeriBlock block after 39580, and then started building an attacking VeriBlock chain and performing PoP publications. The attacking chain is longer and has more PoW, and without PoP it would win and result in a chain reorganization/double-spend. In the picture below, the VeriBlock PoP security explorer shows keystones (every 20 blocks for VeriBlock), such that the attacker is at least 40 blocks longer than the main chain.

Because PoP forces the attacker to publish themselves to Bitcoin, everyone can see the attack is happening (there is no surprise reorg), and that the attacker is deliberately hiding their blocks from the altchain.

Note: even though the attacker has not released their fork to the network yet, we can see the geometry of their attack (when did it start, what blocks does it challenge, and how long is it) because of the Proof-of-Proof publications they were requried to produce in order to have a chance at having their fork accepted by the network.

Ead attack 1.png


The attacker didn't release their reorganization to the network because whoever they were trying to double-spend against was BFI-aware and wasn't confirming the transaction yet (such as an exchange accepting a deposit).

Eventually the attacker gave up and stopped building their offline chain (and performing PoP publications of it), because the victim they were trying to double-spend against refused to confirm their transaction until BFI indicated that the attack was resolved, and that the block containing the transaction in question achieved Bitcoin-finality (it is mathematically impossible now to reverse that VeriBlock block unless a 51% attack of Bitcoin occurred as well).

Ead attack 2.png


All attacks becomes very obvious to any observer:

  • Not publishing PoP endorsements will result in the attacker's chain losing when released, even if they have more blocks/higher cumulative PoW/PoS weight/etc.
  • Publishing PoP endorsements will notify all observers that an attack is occurring.
  • Waiting too long (past the finality period) to publish PoP endorsements (such as mounting a surprise attack) will result in stale PoP that will lose during fork resolution, so no reorg can be caused
  • Conflicting PoP Proofs makes consensus attacks extremely obvious to all observers. Everyone can then withhold activities that would cause any loss from overwritten transactions (such as an exchange confirming deposits or a merchant delivering goods).

Every option for the attacker results in them spending resources but being unable to perform a double-spend.

Summary

No matter how the attacker tries, they come out behind. The worst they can do is spend exorbitant resources to delay the network. They can no longer steal, reverse, or double-spend transactions.

EAD-Workflow-High-Level.png