PoP Whitepaper

From Goldcoin Wiki
Jump to navigation Jump to search

Coding will begin on the Proof of Participation (PoP) protocol in late 2019.


Goldcoin was launched on the Bitcointalk.org forum on May 15, 2013 and is a peer-to-peer version of electronic cash that allows online payments to be sent directly from one party to another without going through a financial institution.

Like Bitcoin, Goldcoin currently uses a Proof of Work (PoW) based consensus mechanism to secure its blockchain. The concept was adapted to money by Hal Finney in 2004 through the idea of "reusable proof of work." However, over the years it has become abundantly clear, that Proof of Work is not a sustainable mechanism due to its ever-increasing energy consumption.

Goldcoin's History

Until now, The GoldCoin network has been secured by a standard Proof of Work (PoW) consensus mechanism. At a later date, the historical information regarding Goldcoin will be added to this paper.

Note: In the future this document will provide a more detailed historical account of Goldcoin's design and development.

Better Consensus Mechanism Needed

Problems with Proof of Work

In the traditional Proof of Work model used by most cryptocurrencies, network security is provided by peers doing work. They deploy their resources (computation/processing time) to reconcile double-spending transactions, and to impose an extraordinary cost on those who would attempt to reverse transactions. Coins are awarded to peers in exchange for work, with the frequency and amount varying with each cryptocurrency’s operational parameters. This process is known as mining.

The frequency of block generation, which determines each cryptocurrency’s available mining reward, is generally intended to stay constant. As a result, the difficulty of the required work for earning a reward must increase as the work capacity of the network increases.

As a Proof of Work network becomes stronger, there is less incentive for an individual peer to support the network, because their potential reward is split among a greater number of peers. In search of profitability, miners keep adding resources in the form of specialized, proprietary hardware that requires significant capital investment and high ongoing energy demands. As time progresses, the network becomes more and more centralized as smaller peers (those who can do less work) drop out or combine their resources into pools.

The protocol is fair in the sense that a miner with p fraction of the total computational power can win the reward and create a block with the probability p. An attacker is required to solve the same tasks as the rest of the Bitcoin network; i.e., an attack on Bitcoin will only be successful if the attacker can bring to bear significant computational resources.[1]

Mining requires a great deal of computing power to run different cryptographic calculations to unlock the computational challenges. The computing power translates into a high amount of electricity and power needed for the proof of work. Today, it is estimated that Bitcoin mining uses the same amount of electricity as Austria and could power more than 6 million U.S. households.[2]

It is obvious even to the most casual observer that this consensus mechanism is not sustainable and must be replaced.

Problems with Proof of Stake

Proof of stake is a consensus mechanism for digital currencies that is an alternative to proof of work used in Bitcoin. The main declared advantages of proof of stake approaches are the absence of expensive computations and hence a lower entry barrier for block generation rewards.

The idea behind proof of stake is simple: instead of mining power, the probability to create a block and receive the associated reward is proportional to a user’s ownership stake in the system. An individual stakeholder who has p fraction of the total number of coins in circulation creates a new block with p probability.[3]

The rationale behind proof of stake is the following: users with the highest stakes in the system have the most interest to maintain a secure network, as they will suffer the most if the reputation and price of the cryptocurrency would diminish because of the attacks. To mount a successful attack, an outside attacker would need to acquire most of the currency, which would be prohibitively expensive for a popular system.

The problem is this system incentivizes users to accumulate coins rather than use them in the ecosystem. Additionally, large stake holders have a disproportionate amount of voting power in the system which can lead to the centralization of power. These large stake holders can also become attractive targets to attackers.

The Solution

A New System: Proof of Participation

What is needed is a system that does not incentivize the accumulation of hashing power or the accumulation of tokens. Goldcoin offers a new consensus mechanism and solution to this problem with the introduction of Proof of Participation (PoP).

If each participating node is entered into an equal lottery system, users will not be motivated to accumulate wasteful computing resources nor will they be motivated to accumulate large numbers of coins to increase their odds of receiving a reward.

Goldcoin uses a system where each participating node can be thought of as a tiny mining rig. As long as the node has been validated and contains an address containing a minimum of 100 GLC, that account will earn an equal right to generate a block. The total reward received as a result of block generation is the current block subsidy along with any transaction fees located within the block.

Subsequent blocks are generated based on verifiable, unique, and almost-unpredictable information from the preceding block. Blocks are linked by virtue of these connections, creating a chain of blocks (and transactions) that can be traced all the way back to the genesis block.

Block generation time is targeted at 120 seconds.

The security of the blockchain is ensured using the following rules of the Proof of Participation algorithm:

  • A cumulative difficulty value is stored as a parameter in each block, and each subsequent block derives its new difficulty from the previous blocks value. In case of ambiguity, the network achieves consensus by selecting the block or chain fragment with the highest cumulative difficulty. This is covered in more detail in section 3.4.1
  • To help minimize the creation of botnets, no more than 2 nodes are permitted within any class C IPv4 subnet range. If more then two nodes are detected in a restricted subnet range, the 2 nodes with the oldest average coin age are allowed.
  • Each participating node must have an effective balance of at least 100 GLC. To prevent botnets, these coins must be stationary for a minimum of 1440 blocks (6 days) before they can contribute to the wallet’s effective balance. Wallets that contain less than 100 GLC will be considered normal nodes and not eligible for the reward lottery.
  • To reduce local disk requirement, a node can operate as a light client or manually enable pruning in the configuration file.
  • To keep an attacker from generating a new chain all the way from the genesis block, peers allow chain re-organization of no more than 9 blocks behind the current block height. Any block submitted at a height lower than this threshold is rejected.
  • Due to the extremely low probability of any account taking control of the blockchain by generating its own chain of blocks, transactions are deemed safe once they are encoded into a block that is 10 blocks behind the current block height.

Contrast with Peercoin's Proof of Stake

Peercoin uses a coin age parameter as part of its mining probability algorithm. In that system, the longer your Peercoins have been stationary in your account (to a maximum of 90 days), the more power (coin age) they have to mint a block. The act of minting a block requires the consumption of coin age value, and the network determines consensus by selecting the chain with the largest total consumed coin age.

When Peercoin blocks are orphaned, the consumed coin age is released back to the blocks originating account. As a result, the cost to attack the Peercoin network is low, since attackers can keep attempting to generate blocks (referred to as grinding stake) until they succeed. Peercoin minimizes these and other risks by centrally broadcasting blockchain checkpoints several times a day, to freeze the blockchain and lock in transactions.

Goldcoin does not use coin age in this way. Each account’s chance of mining a block is purely random, just as long as the node meets the participation requirement (100 GLC, passes IP filter, etc.), and is based on the time since the last block (which is shared by all forging accounts) and the base target value (which is also shared by all accounts).

Core Technologies

Electronic Coins

The total supply of Goldcoin is 72,245,700 coins, divisible to eight decimal places. Currently, these coins are minted using the original Proof of Work consensus system. After the hard fork introducing Proof of Participation, Goldcoin will be mined by randomly chosen participating network nodes.

Network Nodes

A node on the Goldcoin network is any device that is contributing transaction or block data to the network. Any device running the Goldcoin software is seen as a node. Nodes are sometimes referred to as "Peers".

Nodes can be subdivided into two types: participating and normal. A participating node is simply a node that is tagged with an encrypted token derived from an account private key; this token can be decoded to reveal a specific Goldcoin account address and balance that are associated with a node.

Participating nodes are given a higher level of accountability and trust, so participating nodes are more trusted than normal nodes on the network. The larger the balance of an account tied to a participating node, the more trust that is given to that node. While an attacker might wish to participate in order to gain trustworthiness within the network and then use that trust for malicious purposes; the barrier to entry (cost and age of GLC required to build adequate trust) discourages such abuse.

Each node on the Goldcoin network has the ability to process and broadcast both transactions and block information. Blocks are validated as they are received from other nodes. All possible block parameters are verified, including the effective balance of the block generators account. This proves that the generating account actually contains the effective balance that won it the right to generate the block, and in cases where block validation fails, nodes may be blacklisted temporarily to prevent the propagation of invalid block data.

Each node features a built-in DDOS (Distributed Denial of Services) defense mechanism which restricts the number of network requests from any other node to 30 per second.


As in other crypto-currencies, the ledger of GLC transactions is built and stored in a linked series of blocks, known as a blockchain. This ledger provides a permanent record of transactions that have taken place, and also establishes the order in which transactions have occurred. A copy of the blockchain is kept on every node in the Goldcoin network, and every account that is unlocked on a node (by supplying the account private key) has the ability to generate blocks, as long as at least one incoming transaction to the account has been confirmed 500 times. Any account that meets these criteria is referred to as an active account.

In Goldcoin, each block contains up to 4040 transactions, all prefaced by a block header that contains identifying parameters. Each transaction in a block is represented by common transaction data, specific transaction types also include transaction attachment, and certain transactions may include one or more additional appendices. The maximum block size is 2MB.

All blocks contain the following parameters:

  • A block version, block height value, and block identifier
  • A block timestamp, expressed in seconds since the genesis block
  • The ID of the account that generated the block, as well as that accounts public key
  • The ID and hash of the previous block The number of transactions stored in the block
  • The total amount of GLC represented by transactions and fees in the block
  • Transaction data for all transactions included in the block, including their transaction IDs
  • The payload length of the block, and the hash value of the block payload
  • The block’s generation signature
  • A signature for the entire block
  • The base target value and cumulative difficulty for the block

Block Creation (Minting)

Three values are key to determining which account is eligible to generate a block, which account earns the right to generate a block, and which block is taken to be the authoritative one in times of conflict: base target value, target value and cumulative difficulty.

Base Target Value

In order to win the right to forge (generate) a block, all active Goldcoin accounts compete by attempting to generate a hash value that is lower than a given base target value. This base target value varies from block to block, and is derived from the previous block base target multiplied by the amount of time that was required to generate that block using a formula that ensures 2.5 minute average block time.

The calculation is based on the following constants:

  • MAXRATIO=165 - max ratio by which the target is decreased when block time is larger than 120 seconds.
  • MINRATIO=135 - min ratio by which the target is increased when block time is smaller than 120 seconds.
  • GAMMA=(0.64?)

And the following variables:

  • S - average block time for the last 3 blocks
  • Tp - previous base target
  • Tb - calculated base target

The base target is calculated as follows:

  • If S>150
   Tb = (Tp * Min(S, MAXRATIO)) / 120
  • Else
   Tb = Tp - Tp * GAMMA * ( - Max(S, MINRATIO)) / 120;

The the idea is to make target adjustments gradual using the MIN and MAX ratio constants and increase the target, thus reducing block times, at a faster rate than decreasing the target, using the GAMMA constant, since the block time is bounded by 0 from below but can be infinitely large.

Target Value

Each account calculates its own target value, based on its current effective stake. This value is:

<math>T=T_{b}\times S\times B_{e}</math>


T is the new target value

Tb is the base target value

S is the time since the last block, in seconds

Be is the effective balance of the account

As can be seen from the formula, the target value grows with each second that passes since the timestamp of the previous block. The maximum target value is 1.53722867 x 1017 and the minimum target value is one half of the previous blocks base target value.

This target value and the base target value are the same for all accounts attempting to forge on top of a specific block. The only account-specific parameter is the effective balance parameter.

Cumulative Difficulty

The cumulative difficulty value is derived from the base target value, using the formula:



Dcb is the difficulty of the current block

Dpb is the difficulty of the previous block

Tb is the base target value for the current block

The Mining Algorithm

Each block on the chain has a generation signature parameter. To participate in the block forging process, an active account digitally signs the generation signature of the previous block with its own public key. This creates a 64-byte signature, which is then hashed using SHA256. The first 8 bytes of the resulting hash are converted to a number, referred to as the account hit.

The hit is compared to the current target value. If the computed hit is lower than the target, then the next block can be generated. As noted in the target value formula, the target value increases with each passing second. Even if there are only a few active accounts on the network, one of them will eventually generate a block because the target value will become very large. Therefore, you can calculate the time it will take any account to forge a block by comparing the account hit value to the target value.

Even though any node can query the effective balance for any active account, and it is possible to iterate through all active accounts in order to determine their individual value, it is impossible to predict which account will next win the right to mine a block since the reward is completely randomized between participating nodes. Therefore, a balance shifting attack is futile.

When an active account is awarded the right to generate a block, it bundles up to 4040 available, unconfirmed transactions into a new block, and populates the block with all of its required parameters. This block is then broadcast to the network as a candidate for the blockchain.

The payload value, generating account, and all of the signatures on each block can be verified by all network nodes who receive it. In a situation where multiple blocks are generated, nodes will select the block with the highest cumulative difficulty value as the authoritative block. As block data is shared between peers, forks (non-authoritative chain fragments) are detected and dismantled by examining the chains cumulative difficulty values stored in each fork.

A node which receives a valid block representing a chain with larger cumulative difficulty than its own, will determine the highest common block between its own chain and the chain represented by the new block, then remove its own blocks from the chain down to the common block and undo any side effects of these blocks then build it's own chain based on blocks received from other nodes.


Goldcoin implements a brain wallet as part of its design: all accounts are stored on the network, with private keys for each possible account address directly derived from each accounts passphrase using a combination of SHA256 and Curve25519 operations.

Each account is represented by a 64-bit number, and this number is expressed as an account address using a Reed-Solomon error-correcting notation that allows for detection of up to four errors in an account address, or correction of up to two errors. This practically eliminates the risk that a typo in account address would result in lose of funds. Account addresses are always prefaced by an GME- prefix, making Goldcoin account addresses easily recognizable and distinguishable from address formats used by other blockchains.

The Reed-Solomon-encoded account address associated with a secret passphrase is generated as follows:

  1. The secret passphrase is hashed with SHA256 to derive the accounts private key.
  2. The private key is encrypted with Curve25519 to derive the accounts public key.
  3. The public key is hashed with SHA256 to derive the account ID.
  4. The first 64 bits of the account ID are the visible account number.
  5. Reed-Solomon encoding of the visible account number, prefixed with GLC-, generates the account address.

When an account is accessed by a secret passphrase for the very first time, it is not secured by a public key. When the first outgoing transaction from an account is made, the 256-bit public key derived from the passphrase is stored on the blockchain, and this secures the account. The address space for public keys (2256) is larger than the address space for account numbers (264), so there is no one-to-one mapping of passphrases to account numbers and collisions are possible. These collisions are detected and prevented in the following way: once a specific passphrase is used to access an account, and that account is secured by a 256-bit public key, no other public-private key pair is permitted to access that account number.

Account Balance Properties

For each Goldcoin account, several different types of balances are available. Each type serves a different purpose, and many of these values are checked as part of transaction validation and processing.

  • The effective balance of an account is used as the basis for an account's forging calculations[4]. An account's effective balance consists of all tokens that have been stationary in that account for 1440 blocks. In addition, the Account Leasing feature allows an account's effective balance to be assigned to another account for a temporary period. The account effective balance is calculated from the confirmed balance by reducing all balance additions during the last 1440 blocks.
  • The guaranteed balance of an account consists of all tokens that have been stationary in an account for 1440 blocks. Unlike the effective balance, this balance cannot be assigned to any other account.
  • The confirmed balance of an account accounts for all transactions that have had at least one confirmation.
  • The unconfirmed balance of an account is the one that is displayed in Goldcoin clients. It represents the confirmed balance of an account, minus the tokens involved in unconfirmed, sent transactions or locked by specific transaction types such as CurrencyReserveIncrease and Shuffling transactions or locked by phased transactions not applied or cancelled yet.
  • The mined balance of an account shows the total amount of GLC that have been earned as a result of successfully mining blocks.


Transactions are the only means Goldcoin accounts have of altering their state or balance. Each transaction performs only one function, the record of which is permanently stored on the network once that transaction has been included in a block.

Transaction Fees

Transaction fees are the primary mechanism through which GLC are recirculated back into the network. Every transaction requires a minimum fee. When an Goldcoin node mines a block, all of the transaction fees included in that block are awarded to the mining node as a reward. Unlike with blockchains, minimum transaction fees are enforced by the blockchain therefore transactions which do not specify a fee larger than the minimal fee for this transaction type won't be accepted by nodes.

Transaction Confirmations

All GLC transactions are considered unconfirmed until they are included in a valid network block. Newly-created blocks are distributed to the network by the node (and associated account) that creates them, and a transaction that is included in a block is considered as having received one confirmation. As subsequent blocks are added to the existing blockchain, each additional block adds one more confirmation to the number of confirmations for a transaction.

If a transaction is not included in a block before its deadline, it expires and is removed from the transaction pool.

Transaction Deadlines

Every transaction contains a deadline parameter, set to a number of minutes from the time the transaction is submitted to the network. The default deadline is 1440 minutes (24 hours). A transaction that has been broadcast to the network but has not been included in a block yet is referred to as an unconfirmed transaction.

If a transaction has not been included in a block before the transaction deadline expires, the transaction is removed from the network.

Transactions may be left unconfirmed until their deadline expire, because they are permanently invalid or malformed, or because they do not meet certain temporary conditions such as sufficient balances, or because blocks are being filled with transactions that have offered to pay higher transaction fees.

Transaction Types

Categorizing GLC transactions into types and subtypes allows for modular growth and development of the GLC Protocol without creating dependencies on other base functions. As features are added to the Goldcoin core, new transaction types and subtypes can be added to support them.

Multiple transaction types and associated subtypes are supported by Goldcoin. Each type dictates a given transactions required and optional parameters, as well as its processing method. A complete list of all transaction types and sub types is out of the scope of this document.

Transaction Creation and Processing

The details of creating and processing an GLC transaction are as follows:

  1. The sender specifies parameters for the transaction. Types of transactions vary, and the desired type is specified at transaction creation, but several parameters must be specified for all transactions:
    • private key for the sending account
    • specified fee for the transaction
    • deadline for the transaction
    • an optional referenced transaction
  2. All values for the transaction inputs are checked. For example, mandatory parameters must be specified; fees cannot be less than the minimum fee for this transaction type; a transaction deadline cannot be less than one minute into the future; if a referenced transaction is specified, then the current transaction cannot be processed until the referenced transaction has been processed.
  3. If no exceptions are thrown as a result of parameter checking:
    1. The public key for the generating account is computed using the supplied secret passphrase
    2. Account information for the generating account is retrieved, and transaction parameters are further validated:
      • The sending account’s balance cannot be zero
      • The sending account’s unconfirmed balance[5] must not be lower than the transaction amount plus the transaction fee
  4. If the sending account has sufficient funds for the transaction:
    1. A new transaction is created, with a type and subtype value set to match the kind of transaction being made. All specified parameters are included. A unique transaction ID is generated with the creation of the object
    2. The transaction is signed using the sending account’s private key
    3. The encrypted transaction data is placed within a message instructing network peers to process the transaction
    4. The transaction is broadcast to all peers on the network
    5. The server responds with a result code:
      • the transaction ID, if the transaction creation was successful
      • an error code and error message if any of the parameter checks fail.

Cryptographic Foundations

Key exchange in Goldcoin is based on the Curve25519 algorithm, which generates a shared secret key using a fast, efficient, high-security elliptic-curve Diffie-Hellman function[6]. The algorithm was first demonstrated by Daniel J. Bernstein in 2006.

Message signing in Goldcoin is implemented using the Elliptic-Curve Korean Certificate-based Digital Signature Algorithm (EC-KCDSA), specified as part of IEEE P1363a by the KCDSA Task Force team in 1998.

Both algorithms were chosen for their balance of speed and security for a key size of only 32 bytes.

Encryption Algorithm

When Alice sends an encrypted plaintext to Bob, she:

  1. Calculates a shared secret:
    • shared_secret = Curve25519(Alice_private_key, Bob_public_key)
  2. Calculates N seeds:
    • seedn = SHA256(seedn-1), where seed0 = SHA256(shared_secret)
  3. Calculates N keys:
    • keyn = SHA256(Inv(seedn)), where Inv(X) is the inversion of all bits of X
  4. Encrypts the plaintext:
    • ciphertext[n] = plaintext[n] XOR keyn

Upon receipt Bob decrypts the ciphertext:

  1. Calculates a shared secret:
    • shared_secret = Curve25519(Bob_private_key, Alice_public_key)
  2. Calculates N seeds (this is identical to Alices step):
    • seedn = SHA256(seedn-1), where seed0 = SHA256(shared_secret)
  3. Calculates N keys (this is identical to Alices step):
    • keyn = SHA256(Inv(seedn)), where Inv(X) is the inversion of all bits of X
  4. Decrypts the ciphertext:
    • plaintext[n] = ciphertext[n] XOR keyn

Note: If someone guesses part of the plaintext, he can decode some part of subsequent messages between Alice and Bob if they use the same key pairs. As a result, it’s advised to generate a new pair of private/public keys for each communication.


Attacks Vectors

Nothing at Stake

In a nothing at stake attack, forgers attempt to build blocks on top of every fork they see because doing so costs them almost nothing, and because ignoring any fork may mean losing out on the block rewards that would be earned if that fork were to become the chain with the largest cumulative difficulty.

While this attack is theoretically possible, it is currently not practical. The Goldcoin network does not experience long blockchain forks, and the low block reward does not provide a strong profit incentive; further, compromising network security and trust for the sake of such small gains would make any victory pyrrhic.

A feature called Economic Clustering will be available soon that provides further protection against attacks of this nature by forcing transactions to include hashes of previous blocks, and by grouping nodes into clusters that can detect unusual behavior on the network and impose penalties (in the form of temporary loss of the ability to forge).

Botnet Attack

A malicious user might try to spin up a botnet to increase his chances at winning a block reward. Since each client node (wallet) must have a minimum balance of 100 GLC and be connecting from a unique IPv4 subnet address, an 'attacker's' would have to perform some work to create each participating node.

In the event a botnet were created, it becomes a botnet of nodes doing work for the network (more discussion needed).

History Attack

In a history attack, someone acquires a large number of coins, sells them, and then attempts to create a successful fork from just before the time when their coins were sold or traded. If the attack fails, the attempt costs nothing because the coins have already been sold or traded; if the attack succeeds, the attacker gets their coins back. Extreme forms of this attack involve obtaining the private keys from old accounts and using them to build a successful chain right from the genesis block.

In Goldcoin, the basic history attack generally fails because all coins must be stationary for 1440 blocks before they can be used for node validation; moreover, the effective balance of the account that generates each block is verified as part of block validation. The extreme form of this attack generally fails because the Goldcoin blockchain cannot be re-organized more than 10 blocks behind the current block height. This limits the time frame in which a bad actor could mount this form of attack.

Transaction Fees

As the value of Goldcoin increases, the cost of minimum transactions fees, expressed in fiat terms, also increases. Plans are underway to reduce the minimum fee, scaled according to transaction byte-size, in order for micro-transactions to be practical.


  1. https://bitfury.com/content/downloads/pos-vs-pow-1.0.2.pdf
  2. https://digiconomist.net/bitcoin-energy-consumption
  3. https://bitfury.com/content/downloads/pos-vs-pow-1.0.2.pdf
  4. See for more information on how this balance is used.
  5. This is defined as the accounts current balance, minus amounts related to all unconfirmed, sent transactions. In general, this is the account balance that is displayed in real-time in a Goldcoin client interface.
  6. For more information: https://en.wikipedia.org/wiki/Diffie–Hellman_key_exchange

The NXT whitepaper was used as a template for this document. A special thank you to the original authors.