Ok, started reading through the whitepaper, and have some questions. Before I raise them however, given this is a new consensus protocol, it might be best to present a simple example using imaginary coins and people, so that we can all visualize how this works.
Now the questions:
1. If I understand this correctly, every PoP miner would need to transact on the BTC network and embed in their transaction the entire block header of the SI chain, which is being mined by the PoW miners. The two issues I see are a) You are asking PoP miners to pay BTC transaction fees, b) It becomes a race of who does it first so some PoP miners might opt to pay higher fees for their transaction to be mined first and c) The financial incentive would need to be significant for a PoP miner to do so, and cover the BTC fees
2. While you are saying that it would not be practical for someone who forks the BTC chain to take over (re-write) the SI chain, considering that the SI chain would probably be made up of a small amount of hashing power (otherwise, why would you need the hashing power of BTC), and there would already be large pools in play, all they would need to do is also fork the SI chain and provide a solution for the next block faster.
Generally, chapter 6 which deals with #2 above reads very weak, there seems to be some wishful thinking and statements along the lines of "As such, anyone watching the SP blockchain would see what block(s) are at risk for the fork, how much stronger (or weaker) the current chain is compared to the adversarial party’s chain, and could potentially use some means (like balance-based voting) to invalidate the adversarial chain before it is released to the network." don't inspire confidence.
It is ok if you haven't figured everything out yet, be upfront and work with the community. Right now this seems like an overcomplicated solution looking for problem though.
Don't mean to sound critical, and apologies if I have misunderstood anything.
Hey Aris, thanks for taking a look at the whitepaper! For clarification, the PoP whitepaper describes the consensus protocol itself, not specifically the utility of the VeriBlock blockchain (except in a short aside near the end), so my example case is going to speak below about the most simple PoP implementation for clarity: one blockchain securing directly to Bitcoin, without using the VeriBlock blockchain as an intermediate aggregation layer. However, I get into the utility of the VeriBlock blockchain as well later in the post.
For your inquiry about an example case with fictitious coins and people:
Say you launch ArisCoin tomorrow (for simplicity, say it's a PoW blockchain with a 10 minute blocktime), and you use PoP to secure to Bitcoin (directly, in the simplified case).
Your PoW miners bundle transactions on the network into blocks and mine them using traditional PoW, and your PoP miners take the latest 'fingerprint' of ArisCoin (which in the case of a PoW blockchain is the most recent block header), and they publish this block header to Bitcoin (paying a Bitcoin transaction fee). Let's say your total block reward is worth $100 at current market value, and you dedicate 20% of the block reward to PoP miners. This means that, every block, your network pays $20 to PoP miners collectively. Similar to how PoW provides a total bounty and many people compete for slices of that reward, so too do PoP miners compete for the total PoP miner reward (and PoP mining can be done in a pool similar to PoW, so we can conclude that the variability risk can be dramatically reduced). Simplistically, if a high-priority Bitcoin transaction costs $4, we would expect slightly less than 5 transactions on average per block of ArisCoin to Bitcoin on behalf of PoP miners (there are more complexities at play here too, which we'll table for brevity).
PoP miners, to receive their reward, must complete a full cycle of PoP mining: they must publish the fingerprint of ArisCoin to Bitcoin, and then (after waiting for a period of time) must construct a proof that they successfully published this data to Bitcoin (Bitcoin transaction including the data, Merkle path to the Merkle root of the containing block, the header of the containing block, and (if required), additional contextual Bitcoin block headers to link the block the PoP miner published data in to the latest Bitcoin block known about by ArisCoin from previous PoP publication data.
Once a PoP miner completes this full cycle, the ArisCoin PoW miners can include the PoP miner's proof-of-publication in their blocks (and can be incentivized to do so in a variety of means). Once these proof-of-publications are included in the blockchain, they can be referenced in the event that a blockchain fork is presented to the network, and the fork resolution algorithm for ArisCoin determines which version of the blockchain's history is valid based on which one has the highest PoP score (which is calculated as a combined metric of the relative timeliness and volume of publications of each fork's blocks in Bitcoin itself). As a result, anyone wanting to make a fork which will be accepted as valid (they can perform a valid double-spend attack) must publish data to Bitcoin in a timely manner (in-step with the building of the "legitimate" or "original" history), thereby announcing their attack to the world, and allowing merchants/exchanges/users to respond by simply waiting until they can see with mathematical certainty that the state of the forking blockchain has been abandoned according to its presence in the Bitcoin blockchain (in other words, its presence in Bitcoin is not sufficient for it to be accepted as a more valid history than the history the exchange/merchant/user is currently aware of).
Now to the specific questions:
1. If I understand this correctly, every PoP miner would need to transact on the BTC network and embed in their transaction the entire block header of the SI chain, which is being mined by the PoW miners. The two issues I see are a) You are asking PoP miners to pay BTC transaction fees, b) It becomes a race of who does it first so some PoP miners might opt to pay higher fees for their transaction to be mined first and c) The financial incentive would need to be significant for a PoP miner to do so, and cover the BTC fees
PoP miners need to transact on the BTC network if they are securing a blockchain directly to Bitcoin. If the security-inheriting blockchain pays (at current exchange rates) $x to PoP miners per block and Bitcoin transaction fees are $y, then we expect on average for slightly less than y/x Bitcoin transactions to be done by PoP miners on behalf of the blockchain they're securing per block. If a blockchain is secured to VeriBlock, then PoP miners of that blockchain need to transact on the VBK network, and similar math applies, although in general VeriBlock will have far lower per-transaction fees because it has more space for PoP transactions, PoP transactions can be much smaller on VeriBlock than on Bitcoin, and PoP transactions on VBK aren't competing with as many use cases as they are on Bitcoin. If a PoP miner expects to spend $x to earn $y on average, and y>x, then the incentive model functions correctly. and if y<=x, then some PoP miners will stop PoP mining, and y will quickly become bigger than x again.
Part of the mining process is competitive behavior in the Bitcoin fee market; similar to how a PoW miner who buys higher performance hardware has a higher chance of mining a block, a PoP miner who pays a higher fee has a higher chance of claiming a portion of the PoP reward for the block they secure.
2. While you are saying that it would not be practical for someone who forks the BTC chain to take over (re-write) the SI chain, considering that the SI chain would probably be made up of a small amount of hashing power (otherwise, why would you need the hashing power of BTC), and there would already be large pools in play, all they would need to do is also fork the SI chain and provide a solution for the next block faster.
To clarify, are you referring to the following section of the whitepaper:
In the event that an adversarial party successfully forks the SP blockchain, they can re-write the forked SP blockchain blocks with new PoP data, enabling them to produce a SI blockchain with a higher PoP weight. The amount/length (measured in real-world time, not blocks) of the SI blockchain they are able to rewrite is approximately equal to the distance they successfully fork the SP blockchain for.
Note that a fork of the SP blockchain without specific intention to fork the SI blockchain won’t result in a SI blockchain fork. However, such a reorganization of the SP blockchain will cause the SI blockchain’s PoP mining transactions which occurred in the forked SP blockchain blocks to no longer exist in the SP blockchain, and thus hold no weight.
If so, this is referring to the fact that, even *if* the security-providing blockchain is forked, this doesn't necessarily mean that the security-inheriting blockchains are forked. For example, if 100 blockchains all secured with PoP to "SecureChain" (a generic high-security PoW blockchain, such as Bitcoin) and SecureChain suffered a PoW reorganization for a significant depth (say, 6 blocks), this doesn't directly cause those 100 blockchains to also reorganize at all. They still have their own native security in this instance, so the adversary who forked SecureChain would have to also perform the work required to override the intermediate consensus algorithms of any of those 100 blockchains that they also want to reorganize. While the security profile of these 100 blockchains is that, to fork them beyond a certain depth would require also forking SecureChain itself, simply the difficult act of forking SecureChain doesn't fork those blockchains without additional extra effort being spent on each blockchain the attacker wishes to manipulate.
Generally, chapter 6 which deals with #2 above reads very weak, there seems to be some wishful thinking and statements along the lines of "As such, anyone watching the SP blockchain would see what block(s) are at risk for the fork, how much stronger (or weaker) the current chain is compared to the adversarial party’s chain, and could potentially use some means (like balance-based voting) to invalidate the adversarial chain before it is released to the network." don't inspire confidence.
Normally, the security against double-spend attacks comes from the ability of exchanges/merchants/users to see in real-time whether there is a potential pending fork brewing for the security-inheriting blockchain in question: for an attacker to propose a potential fork later, they have to include fingerprints of their attacking chain in the security-providing blockchain in a timely fashion relative to the publications of the "legitimate" chain, thereby announcing their fork to the world. These exchanges/merchants/users now simply wait until they get mathematically sound confirmation that the purported attacking chain has withered away (is no longer being published in a timely fashion relative to the "legitimate" chain). Assuming exchanges/merchants/users listen to the available security metrics, this downgrades the potential for a forking attack which doesn't fork the security-providing blockchain itself from being able to perform a double-spend to simply delaying confirmation of transactions on the network while the security issue resolves itself.
The statement that some kind of voting mechanism may be employed to invalidate a chain is in reference to a blockchain, if it so chooses, to allow users on the "legitimate" chain to vote with their balances (or some other resource) that the brewing "illegitimate" chain should not be accepted. This is not an important/required part of the PoP consensus protocol, but simply a potential direction for adoption of PoP by some systems to explore (the VeriBlock blockchain itself will not implement this, and we don't plan to recommend such a voting system to be used on any other blockchain using PoP through VeriBlock). I'll look into updating the PoP whitepaper to make this clear.
Thanks for looking into the tech behind PoP! If you have any other questions or if the above answers didn't completely address your questions, I'd love to continue the conversation
