View source for Discord Tech FAQ 20190407

See: [[Main_Page]]

__TOC__

== Overview ==

This page contains several FAQ questions pulled from Discord on April 7, 2019.

Names have been removed, and some edits have been made for continuity and a wiki page is a different medium than a chat channel.

'''DISCLAIMER:''' Some technical simplifications were made just for sake of a chat channel, such as ignoring irrelevant edge cases or approximating as "close enough" given the context of the discussion.

While Discord is public and anyone could read the original comments (see: [[Social_Links]]), we edited into a wiki page so more people could easily see the content.

== General FAQ ==

Just catching up on the chat. Please note that the whitepaper out there is old and the PoP protocol has evolved since then. VeriBlock uses a form of block reference braiding mixed with finality delay parameters that make any privately-mined chain have to perform PoP publications which give full visibility of the chain (where the attack starts, proof the attack is being produced at a sufficient difficulty, whether the attack is still possible).


=== PoP and an attacking chain ===


<pre>
QUESTION:
Wouldn't the IEO have been a good opportunity to bring your whitepaper up to date?

In Section 6.2 of your whitepaper you write "To mitigate this attack, blockchain networks simply weight blocks closer to the forking point with significantly more weight (so the sum might look something like 100 * weight0 + 70 * weight1 + 55 * weight2 …),"

So why can't the attacker produce  an offline chain which is absolutely better than the main chain?

</pre>

Annoyance with some of the following info not being covered in the existing whitepaper is totally understandable; the timing unfortunately didn't work out to get it updated in time. We are in the process of updating it now.

There were 6 key attributes we were looking for when we designed PoP (SI being a security inheriting chain, SP being a security providing chain, so for now SI=VeriBlock, SP=Bitcoin):

1. The failure of one or several consecutive SI blocks (up to a particular limit) to be published to the SP chain should not reduce the quality of the security the SI chain enjoys

2. Any attacker generating an alternate history of the SI chain should have to regularly announce the state of their chain to the SP chain in a timely fashion

3. An attacker should not be  able to "purchase" a higher rating for their competing SI fork than the legitimate SI fork receives by doing more or more frequent PoP publications to the SP chain

4. The fork resolution should eventually and predictably reach finality, where the lack of publications of a competing SI chain up to SI height 'n' in the SP blockchain ensures the SI chain cannot be forked back before 'n' without the attacker needing to reorganize the SP chain. The finality delay permitted for straggler SI publications to make it into the SP chain should be sufficiently large that an attacker cannot generate an offline chain which has an infinitely higher score

5. The fork resolution algorithm should require minimal processing power and bandwidth so that SPV wallets can function with full security, and any downstream SI chains which secure to the SI chain in question (ex, SI=VeriBlock here) don't have to store and process tons of PoP information regarding the SI->SP chain

6. The reward scheme for PoP shouldn't incentivize SI or SP block miners to censor PoP mining activity, even if they themselves are engaged in the PoP mining process

So let's take it one attribute at a time:

1. We introduce a new form of blockchain reference braiding which we call "keystoning," where keystone blocks occur at a regular interval, which on VeriBlock is every 20th block. Every block, in addition to referencing the previous block, also references the two most recent keystones (except for the block immediately following a keystone, which references three previous keystone blocks because it's previous block is also a keystone).
Because of this reference braiding, a PoP publication of any block gives context to which previous keystones it connects to.

[[File:wp_pop_1.png|400px]]

So for example, block 100 references block 99, block 80, and block 60.

<pre>
The problem is that point 2  and point 4 are essentially mutually exclusive.
</pre>

They aren't, because Bitcoin acts as a "clock" which gives a concept of "time" that can be used. I'm giving background on some stuff that's helpful for the explanation.

So to use this keystone reference information, we construct a "reduced publication view" which is used for consensus resolution. For a visual example of a version of VeriBlock where the keystone_interval is 3:

<pre>
QUESTION:
Either you have finality or not. 
Caes 1: You have finality
This means that, if an attacker reaches finality for its attacking chain, the main chain is doomed because then he just can wait as long as he wants until he decides to eventually broadcast his chain and destroy the main chain. (This is the attack I describe in my article)

Case 2. You don't have finality
This means an attacker can prepare his attack unnoticed (this is the attack described in Section 6.2 in your whitepaper).

You can't have your cake and eat it
</pre>

Finality for SI blocks is delayed based on the competition of publications on the SP blockchain.

If SI block 'n' (pedantic note—n is technically a keystone period, but referring to it as a block height is a lot easier for illustration purposes) is published to SP block 'm' and the finality delay is 'd', then the lack of publications of other SI forks which reorganize at or before SI height n once the SP chain reaches height n+d means that the SI chain has Bitcoin finality up to height n. In the event that there is an attacking SI fork published within that sufficient timeframe, then neither fork has reached finality yet.

Based on SI publications in the SP chain, fork resolution constructs a "reduced publication view" that summarizes the state of all possible competing forks of the SI chain:

For example, an SI chain with a keystone every 3rd block might have publications that look something like this:

[[File:wp_pop_2.png|600px]]

Assuming an attack started on the SI chain above height 57, then the reduced publication view would look like this:

[[File:wp_pop_3.png|800px]]

An attacking fork might have a reduced publication view where block 60 is seen in SP 60, making that fork have a slightly higher weight.

Finality is eventually reached when the attacker stops generating a valid SI fork and publishing it to the SP chain in-step with the "legitimate" SI chain

Publications for a particular SI block at a timestamp 't' cannot be in an SP block which embeds timestamp 't' (pedantically they can; but their effective SP height is set to the first SP block which has a timestamp above that of the SI block)

The difficulty adjustment algorithm of the SI chain prevents an attacker from manipulating the timestamp they embed in their SI blocks to escape the finality window by publishing a block height 'n+large_number' so many SP blocks ahead of the legitimate chain reaching that block that the finality window closes and the attacker's chain is the winning chain.

For an attack spanning approximately 'a' keystone periods, if an attacker published SI blocks n, n+r, ..., n+(a-1)r to the SP chain before SI blocks n, n+r, ..., n+(a-1)r, then they would have a chain with a higher weight, which they could release on the SP chain and reorganize it to their chain. However this is public knowledge and EAD has been triggered, so exchanges, merchants, etc. would wait until the attack either succeeds or fails before settling transactions which are after block n in the SI chain. If the attacker abandons their offline chain, then the finality period on the SP chain passes where n+ar of the attacker's chain cannot be published, therefore the weights of n+ar, n+(a+1)r, etc. of the legitimate chain soon outrun the previously-higher relative score of the attacker chain.

As a side-note, this is a bit of a simplification and some things aren't fully explained because Discord really isn't the best format for this stuff; the updated whitepaper will explain all the details (ex: technically exchanges/merchants would want to freeze transaction processing for transactions above height n-r+1 instead of n).

Also note 57 being "stable" in the reduced publication view above means it is stable for a given fork resolution situation where the competing fork references the same block 57 as the legitimate network; there could also exist an attack which started at block 55, and when fork resolution is run on its PoP publication to the SP chain, 54 would be considered stable in that context.

Finally, the keystone period of r=3 and reference braiding of i=2 is generally a bad combination; it's done for illustration purposes because drawing it out with something like r=20 in the case of VeriBlock would be a pain

=== Is there any mechanism to prevent an attacking chain from reorging the network? ===

No; that's where you start to get into the "can't have your cake and eat it too" territory. Mathematically, there is really no such thing as the "legitimate" chain and the "attacking" chain (although we use the terms as a convenience, where the "legitimate" chain is the one that public nodes are currently operating with the knowledge of, and the "attacking" chain is the one that's being privately produced). All that a fork resolution algorithm can see (without introducing weak subjectivity, that is) is whether each chain is valid (publications contain valid block headers and/or alternate validator set proofs in the case of PoS/DPoS), and how early each of them made it to the SP chain.
The way PoP prevents double-spends is by making all attacks public prior to transaction finalization.

The tweaks basically being ways to cause network disruption combined with very carefully-timed block releases. Large blocks that take a long time for some nodes to process, denial-of-service attacks of all types (whether it be just raw traffic load to target nodes, protocol-level "hard to process" jobs like complex smart contracts, transactions with tons of signatures to validate, etc.)

=== Why couldn't an exchange not credit deposits after detecting a reorg ===

If an exchange halted deposits once a reorg actually happened on the chain, then it's too late because they already cleared funds for transactions which the attack could double-spend. But if you're talking about when a potential reorg is detected based on publications of the SI chain to the SP chain, then that's exactly what our Early Attack Detection metrics do; they use publications on the SP chain to determine whether a fork of the SI chain at a particular height is mathematically possible without an SP reorg, and signal when a particular block height on the SI chain has reached SP-finality (and thus, transactions at or before that height are actually more secure than transactions on the SP chain).

=== What would an exchange would do if they see an attacking chain that will soon reorg the network? ===

When EAD detects publications in the SP chain which could cause an SI reorganization at or above SI height 'n', it would signal to the user (whether that be an exchange, merchant, etc.) that transactions in SI blocks at or above 'n' are not safe to accept yet. 

That's the easier way to think about it, in reality what's really going on is the exchange doesn't accept a deposit transaction in block 'n' until EAD clears that an attack against block 'n' is not mathematically possible (or as we say, SI block 'n' has reached Bitcoin-finality).

Pedantically it isn't a "double-spend" that is detected, but rather a potential reorg on the SI chain at or above a particular height, which could potentially include one or more double-spend transactions.

=== Weighting Algorithm ===

The way the weighting algorithm works, an attacker cannot produce valid PoP publications for an offline chain which are absolutely better than the main VeriBlock chain.


=== Can you provide an overview of different parts of PoP ===

There are two parts to this; Proof-of-Proof ("PoP") as a general consensus protocol, and VeriBlock as a concrete implementation. In Proof-of-Proof, an SI (or "security inheriting") chain secures to an SP (or "security providing") chain. VeriBlock secures to Bitcoin using PoP, and other blockchains can secure to VeriBlock using PoP.

Proof-of-Proof introduces a new form of mining, called PoP mining, which incentivizes the periodic publication of an SI chain's state to an SP chain. These publications include a "Proof-of-X" of the SI chain, which validate that the attacker is generating SI blocks in a valid manner as it pertains to the "intermediate consensus" protocol (PoW, PoC, PoS, dPoS, ...) as an anti-spam mechanism (i.e. in the PoW case, an attacker can't just publish hashes that are below a certain target, they publish the entire header which validates the header produces a valid PoW solution). 

A braided block referencing pattern ("keystoning") is referenced in the SI chain, such that the publication of a single SI block provides context for a large number of SI blocks. As a result, a number of SI blocks can occur without publication to the SP chain without compromising the security of the SI chain.

There is a "finality delay" which the SI chain's fork resolution algorithm uses. When two SI forks are compared against each other in fork resolution, the forks are scored based on relative publication times of each keystone period to the SP chain.

The finality delay period represents the number of SP blocks from when the first SI block at a particular keystone height is published where additional publications of alternate SI blocks at that keystone height don't have any value, and "publication continuity" is lost.

For example, if the finality delay period is 'd', then if an SI chain's block 'n' is published to SP block 'm', the lack of publications of any SI chain blocks which compete with 'n' (publications of the same keystone period) for d blocks mean that SI block n has SP-finality (a reorganization of the SP chain would be required to insert PoP transactions into the SP chain that represent a reorganization of the SI chain back to somewhere in the keystone period containing block 'n').

Early Attack Detection refers to analyzing these publications in the SP blockchain to determine whether a particular SI block (and thus, the transactions contained within) have reached Bitcoin-finality or not. If competing publications for an SI chain exist in the SP chain, then transactions in the challenged period of SI blocks should not be cleared until either a. the attacker's reorganization of the SI chain occurs, or b. the attacker abandons their alternate chain for the duration of d SP chain blocks.

Anyone can use EAD as it's just a lense through which to view public information on the SP chain. Individual parties can decide what risk level of transactions they are comfortable accepting. If someone is happy with the security of the chain's "intermediate consensus" protocol (PoW, PoC, PoS, DPoS, ...), then they can operate just as they did before adoption of PoP. If they want the full guarantee of the security of the SP blockchain, then they can wait until d blocks have passed on the SP chain without contentious publication.

=== Confirmation Time ===

<pre>
QUESTION:
So PoP Does rely on at least 1 bitcoin confirmation?  thus detecting at approximately 10 minute intervals?
</pre>

The finality delay 'd' in SP blocks is generally >1 because it has to account for attackers who would be able to produce an attacking SI block 'n' (and publish it to the SP chain) some amount of time before the "legitimate" network produces the same SI block 'n' and PoP miners publish it to the SP chain. 

A number of countermeasures exist which can box this risk period into a finite amount (the aggression of the SI difficulty adjustment algorithm, the blocktime of the SI chain, etc.). Additionally, costs can be calculated for the expenditure in SI consensus ownership requirements in order to out-perform the "legitimate" SI chain's existing fork resolution weighting.

<pre>
QUESTION:
the delay would typically be greater than 10 minutes, as PoP's themselves  can be forged

creating a system that can be forged, to help prevent double-spending on another system, that can only be verified every 10, 20, maybe 30 minutes seems like a lot of effort, compared to existing methods such as just detecting hash rate spikes?    or checking the debug.log, or monitoring for competing hashes?  all of which work in realtime?

why would a delayed detection method be chosen and why is it marketed as early?
</pre>

"Forged" as in an attacker with significant SI consensus power could reach an SI block height 'n' before the legitimate network reaches it.

PoP is an additive technology; it layers on top of the existing consensus protocol. Exchanges and sophisticated merchants do already implement technologies which give them some indication of potential chain issues, but they don't offer the same double-spend protection PoP provides. PoP says "if you trust the consensus of SP chain (ex: BItcoin), then this SI transaction is as safe to accept as transactions on the SP chain itself" (with regards to double-spending). 

Hashrate spikes on a chain can be produced in private, and don't reveal themselves until the reorganization occurs, and the exchange has already lost funds. The debug.log wouldn't show any indication of an attack until it occurs, assuming the attacker is at least semi-sophisticated. Monitoring for competing hashes requires that these competing hashes (or more preferably, the Proof-of-X of the SI chain's underlying block generation and intermediate consensus protocol) be published somewhere that the SI chain's consensus protocol references, which is exactly what PoP provides.

Roughly $20M was stolen from exchanges by double-spend attacks in 2018.

"Early Attack Detection" refers to the attack being detected prior to settlement of the transaction. It's essentially the choice between a blockchain's current consensus protocol, or a blockchain's current consensus protocol with a guarantee that if a user waits until EAD metrics indicate a transaction has reached SP-finality ("Bitcoin-finality" for example), then it is as secure (technically, more secure) than a transaction on the SP chain (Bitcoin) itself.

Other attack detection metrics that exchanges/merchants/etc. already use could be used on some chains as a trigger that PoP EAD metrics should be listened to, or transactions (or total transaction volume in a time period) could require EAD metrics signal SP-finality, etc.

Most attack indicators that are in use today don't give any kind of finality guarantee, they're just potential red flags that something is amiss. For example someone could monitor hashrate rentals for a particular algorithm on NiceHash (etc.) and when a significant increase in rentals on that market occurs, assume any chain using that algorithm with a hashrate lower than the prediction of what was NiceHash rented could be under attack. However this has a critical flaw: an attacker could wait an hour (or a day, or a week) for their deposit to clear, and then begin renting the power to build an alternate chain. This also doesn't account for the attacker controlling their own mining power rather than having to rent it. It's also likely to generate a lot of false positives.

A reasonably sophisticated attacker won't leak out any evidence of the attack until after the deposit has been cleared.

PoP forces the attacker to publicly announce their attack within a certain timeframe, otherwise the attack is mathematically impossible to execute without a reorganization of the SP (ex: Bitcoin) chain.

The space is also moving towards layer-2 scaling technologies where the confirmation time of an on-chain transaction is less relevant than the assurance it is secure. If you open up a payment channel, exchanges might not accept deposits from your payment channel until EAD gives it the Bitcoin-finality stamp of approval. But once the payment channel reaches Bitcoin-finality, then you can send transactions "instantly" for the duration the channel is open and operable.

The analogy is I don't mind waiting a bit of time to open a bank account, but when I checkout at a grocery store I don't want to hang around the register. On-chain transactions will always have value, but payment channels take off a lot of that pressure.

There might be some confusion as to what type of attack we're talking about. A double-spend attack is a chain being built in private (no evidence in logs files, pool hashrates, hashrate rental unless the attacker doesn't know what they're doing), and then being release to the network, reorganizing the chain to a different tip, and overwriting one or more mutually exclusive transactions in the legitimate chain.

PoP doesn't claim to offer instant attack detection, early attack detection refers to the attack being detected before settlement.

If an exchange knows it has to wait 'n' SP blocks and then they can accept an SI transaction with the full double-spend protection enjoyed by transactions on the SP chain, then they will wait 'n' SP blocks, and EAD will let them know if an issue occurs in that timeframe (at which point they'll wait until EAD indicates the issue is resolved), otherwise the transaction is safe (unless an SP and SI reorg occurs).

From an end-user perspective, transactions on an altchain using VeriBlock will have the following lifecycle:

[[File:Wp_pop_4.png|400px]]

Double-spend attacks are the result of a reorganization which generally occurs from a privately mined chain being released to the network.
Unless we're talking about something like 0-conf double-spends with something like RBF, but that's something entirely different.

<pre>
QUESTION
double spend is always the result of re-oganization yes, but unless the hash rate has been dropped down at some point you will immediately notice it in the chain.     You will see competing hashes, you will see an immediate abberation in the block times.      It's all there.  the very moment this happens you will see  "reorganize' in the debug.log
</pre>

That is assuming that the attacker is redirecting hashrate which was previously running on the main blockchain to mine a private chain. You also won't see competing hashes until the attacker releases their fork to the network.
A reorganization in debug.log will only be visible after the attack occurred.

Additionally the hashrate measure of a blockchain is always an estimate based on solve times. As an example with Bitcoin, the probability that a block takes 20 minutes to solve (instead of 10) is roughly 13.5%. So once every ~1.23 hours, it would look like 50% of the hashrate of Bitcoin stepped away based on the 1-block time. The probability that only two blocks occur in a period of 40 minutes is ~14.7%

PoP works by forcing the attacker to publish periodic indicators of their privately mined chain to the SP blockchain in a timely fashion (the details as to what that means were covered in a discussion a few hours ago on this channel) otherwise their reorganization will not be considered valid by the SI chain.

With Veriblock your chain can't win if you don't announce on the SP chain that you are mining.  it is the difference between generating the blocks in private versus publishing them (or some provable indicator that they exist) publicly.

We also discussed Horizen's implementation a few hours ago here (scroll up if you're interested). Their weighting is based on the "clock" (existing block height) of a particular node and is subject to weak subjectivity.

PoP uses the "clock" of the publication latency of SI blocks to the SP chain (ex: Bitcoin) which can be deterministically verified.

<pre>
QUESTION
Those seem like extremely minor differences.
I can see advantages and disadvantages to both sides, and both can be implemented at the exchange level without tampering with the blockchain.
</pre>

Neither can be implemented without modifying the blockchain's consensus.

If the consensus protocol doesn't use the publication timeliness to resolve consensus, then the attacker isn't forced to produce publications which would inform exchanges/merchants/etc. of the pending attack.

You can use the wayback machine to see the veriblock.com site back in May of 2017 where it references PoP and the inheritance of Bitcoin security.

=== Early Attack Detection ===

Early Attack Dectection works because the blockchain-level consensus protocol enforces it. Imagine a transaction had a real-time indicator of whether it was unconfirmed, secured by only the native PoW/PoS/DPoS/PoC consensus of the blockchain by X number of blocks, or whether it would require forking Bitcoin for Y number of blocks as well.

Unless the consensus protocol enforces rules which can be used to derive security metrics, everything else is guesswork. We could come up with a ton of indicators that try to predict "strange behavior", but they aren't going to give anyone an assurance that a particular transaction is guaranteed to be as secure (or more secure) than a transaction on Bitcoin with N confirmations.

If the blockchain does enforce consensus rules,  then the question is what the trade-off for enforcing those rules is. Perhaps it results in weak subjectivity which can be abused to fracture the network. Perhaps it involves trusted parties and isn't decentralized.