Altchain PoP Rewards

See: BTCSQ, Altchain_PoP_Miner

Overview

Altchain PoP mining takes VBK coins and rewards the native token (such as BTCSQ coins).

BTCSQ specifies two limits: number of ATVs per 1 BTCSQ block is 100, and altchain ID of BTCSQ has two last bytes 0x26ff which makes VBK blockchain think that the limit of ATVs from BTCSQ (with same altchain id) is 20 per 1 VBK block.

While there is complex gamification theory behind pop rewards, in general:

• If someone consistently runs the pop miner, and with sufficient fees to get included in blocks in a timeline manner, then they should consistently get rewards.
• The total pop reward is split amongst all the pop miners for that block. More pop miners means each individual reward is smaller.
• More timely endorsements are better than older (stale) endorsements.

There is a 150-block payout internal (for BTCSQ), so it could take a few hours before rewards show up. Payout block height = endorsed block height + 150.

Altchains have multiple rounds, with a "keystone" round getting 3x larger reward (so miners are incentived to at least mine the keystone). BTCSQ had 4 rounds, and round 4 is the keystone. Here is scale ratio for each round: https://github.com/VeriBlock/alt-integration-cpp/blob/master/include/veriblock/pop/blockchain/alt_chain_params.hpp#L93

See: How to run the Altchain_PoP_Miner

See: VeriBlock_and_Proof-of-Proof_FAQ#What_is_the_VBK_Token.2FCoin_Lifecycle.3F

Automation

Some miners automate the APM using the API: Altchain_PoP_Miner#API

FAQ

I pop mined, but I did not get any reward?

Wrong Altchain id

Modifies the altchain ID in the APM config file to something that didn't exist (or copied config in from another folder).

TestNet BTCSQ has an id = 16579303907010303 (0x3ae6ca000026ff in hex).

securityInheriting {
  vbtc: {
    // This can be set to [1,2,3,4]
    autoMineRounds: [4]
    payoutAddress: "<address here>"
    pluginKey: btc
    id: 16579303907010303

Cause

APM is not aware of this limit and keeps sending transactions while waiting for them to confirm. Two things happen:

• Operations which were started and had their transaction rejected will fail after a while with a "Failed Operation" message.

• Once some of those 1000 transactions are mined into a block new transactions are accepted by Nodecore again but are rejected because the signature index is too high. APM's wallet does not know some earlier transactions are rejected so keeps increasing the signature index and will not send a transaction using the signature index expected by Nodecore. Those operations will also fail after a while for the same reason as previous mentioned.

Solution

Easiest solution might be to impose a limit on the APM miner not being able to start a mining operation when there are more than x transactions in the mempool for its address. Same as Bitcoin which has a limit of ~24 unconfirmed transactions.

Also you can remove or increase the limitation in Nodecore. Not sure if this is feasible and what happens while others run Nodecore still having a lower limit.