Altchain PoP Lifecycle

See: VAIF

Overview

There are two cycles involved in the end-to-end PoP mining lifecycle:

• Altchain-to-VeriBlock (altchain fingerprints are published to VeriBlock)
• VeriBlock-to-Bitcoin (VeriBlock fingerprints are published to Bitcoin)

Both require a daemon (of the chain that's being secured), block mining software (for PoW chains this is a PoW miner and accompanying pool software, for PoS chains this is generally built-in to the staking functionality of the daemon, etc.), and PoP mining software.

Altchain and VeriBlock PoP mining is not a 1:1 relationship; ex: 1000 altchain-to-VeriBlock publications could occur, and only a single VeriBlock-to-Bitcoin publication could occur in a particular time period.

Applications:

• APM – Altchain PoP Miner
• VPM – VeriBlock PoP Miner
• Altchain Daemon
  • Has two file storage mechanisms: (1) current blockchain storage, (2) new file storage that Integration-Library persists to.
• VeriBlock Daemon (NodeCore)
• Bitcoin Daemon

Data Objects

ATV – Altchain-to-VeriBlock

1. APM assembles, but calls NC to build it
2. Big container:
   1. VeriBlockTransaction: VBK normal TX containing altchain state data and altchain PoP miner payout information
   2. VeriBlockMerklePath: Merkle path proving inclusion of the VeriBlock Transaction in the ContainingVBKHeader
   3. ContainingVBKHeader: VeriBlock block header of block containing the VeriBlock Transaction
   4. ContextVBKHeader[]: Array of VeriBlock headers which connect the ContainingVBKHeader to the last-known VeriBlock header of the altchain
3. Persisted by Integration Library (potential for future optimizations in how this is stored)

VTB – VeriBlock-to-Bitcoin

1. APM assembles, but calls NC to build it
2. Big container:
   1. VBKPoPTransaction: A VeriBlock-to-Bitcoin transaction containing a Bitcoin transaction authenticated to a provided Bitcoin block header with a Bitcoin merkle root, sufficient Bitcoin block headers to provide Bitcoin context to the VeriBlock network, and VeriBlock PoP miner payout information
   2. VBKMerklePath: A VeriBlock Merkle Path proving inclusion of the VBKPoPTransaction in the VBKHeaderOfProof
   3. VBKHeaderOfProof: VeriBlock block header of the VeriBlock block containing the VBKPoPTransaction
   4. VBKContextHeader[]: Array of VeriBlock headers which ContainingVBKHeader to the last-known VeriBlock header of the altchain

Tx: Altchain PoP transaction containing an ATV and VTBs

Standard flow

Given Altchain daemon has a block that will be secured by a PoP miner:

1. APM constructs a VBK Tx that protects that Altchain block
   1. This contains data field (the size of which depends on the altchain block header size, block hash/identifier size, and altchain PoP miner payout information size)
2. VPM constructs a BTC Tx that protects a VeriBlock keystone block which is or occurs after the block containing the VBK Tx containing Altchain information (note, many different altchains could each have many publications in this period of VeriBlock blocks)
   1. VeriBlock data is put in BTC OP_RETURN (or the alternative encoding format is used); 80 bytes (VBK block header (64 bytes) + VeriBlock PoP miner payout info (16 bytes))
3. VPM constructs a VBK PoP Tx proving inclusion of the generated Bitcoin transaction in the Bitcoin blockchain
4. APM
   1. Constructs ATV
      1. Original data sent to VBK as a VBK transaction
   2. Constructs VTB[] (usually VTB count = 2-4)
   3. Submits both data objects to Altchain daemon (maybe 5-30KB of data, depending on altchain, VeriBlock, and Bitcoin blocktimes; note that an upcoming optimization will de-duplicate multiple VTBs which contain significantly overlapping data, which will greatly reduce the size of multiple VTBs stored by an altchain)
5. Altchain Daemon
   1. Constructs and submit TX to network
      1. Has entire ATV, VTB[] → has about 10-20KB of data (even bigger than VBK TX, has additional scaffolding)
      2. Serialize data stored in new transaction format/type (Bitcoin-based uses two new script opcodes: OP_ATV, OP_VTB)
6. When Altchain block (which contains the TX) is accepted:
   1. All full nodes write two objects:
      1. Write the Tx via the block (default behavior) → most likely this is NOT the daemon that the APM submitted the Tx to, but rather the winning miner that bundles the TX together and creates the block
      2. Writes (ATV, VTB[]) to Integration Library persistent store for future lookup.
7. ...multiple (4-6 hours depending on blocktimes and altchain PoP parameters) later:
   1. Altchain PoP miner who secured block M receives a reward in altchain tokens/coins M+N blocks after endorsed altchain block from Altchain coinbase reward (including fees)
   2. VeriBlock PoP miner gets paid out in VeriBlock tokens/coins (500 blocks after endorsed VeriBlock block)

Final Result – state that is affected:

1. 2 VBK TX exist (generally multiple of each):
   1. Regular VBK transaction containing altchain state data
   2. PoP VBK transaction containing a proof of publication of VeriBlock state data to Bitcoin
2. VBK reward payout (will occur in future VeriBlock coinbase payout)
3. BTC TX exists containing VeriBlock state data
4. ALT TX exists containing a proof of publication of altchain state data to VeriBlock, and a proof of publication of VeriBlock state data to Bitcoin
5. ALT will write out ATV, VTB[] to the Integration Library storage
6. ALT reward payout (will occur in future altchain coinbase payout)