Detail Whitepaper GitHub Comment Analysis

WebSite	https://pivx.org/
GitHub	PIVX-Project/PIVX
Update Date	2018 Aug 31 08:08:19

Circulating Supply	56,781,168
Total Supply	56,781,168
Max Supply	0
Price	$0.90523374
Volume 24h	$679,902
Market Cap	$51,400,224
Change 24h	-3.84%
Update Date	September 26th 2018, 1:25:14 am

v1

Povil adopts the equity certificate (PoS) 2.0 protocol of bitcoin and runs on the bitcoin core 0.10. X code library. It makes use of the master node network to realize the public decentralization and supervision, and at the same time to enhance the privacy of transactions. Its main goal is to achieve near-instant private transactions and to create a sustainable network management mechanism that protects the interests of all users. We are currently working on these goals, and while some features are under development, they will be implemented in the near future.

Povil adopts the equity certificate (PoS) 2.0protocol of bitcoin and runs on the bitcoin core 0.10. X code library.

There is a two-phase process for voting to implement consensus changes that would create a hard forking scenario.

First, it’s important to note that the Decred blockchain has specifically designated two different block intervals for the voting process. There is a Stake Version Interval (SVI) of 2016 blocks (~1 week) and a Rule Change Interval (RCI) of 8064 blocks (~4 weeks). 4 Stake Version Intervals fit within 1 Rule Change Interval.

The first step of the voting process is to meet the upgrade threshold on the network. After the hard fork code is released (such as the sdiff algorithm change in v1.0.0), a majority of the nodes on the network participating in PoW/PoS need to first upgrade before the voting can be scheduled to begin. For Proof-of-Work, at least 95% of the 1000 most recent blocks must have the latest block version. For Proof-of-Stake, 75% of the votes cast within a single SVI must have the latest vote version. Once miner and voter upgrade thresholds are met, the voting is scheduled to begin on the first block of the next RCI (due to there being 4 SVIs per RCI, it can take up to 6048 blocks [3 SVIs] for the next RCI to begin).

The second step of this process is the actual voting. A single RCI transpires while a maximum of 40320 votes are cast. The votes are tallied at the final block of the RCI, and outcomes are determined prior to the next block being mined.

There are a few possible outcomes of a vote:

If more than 90% of all votes within the RCI are “Abstain” votes, the agenda vote remains active for the next RCI.
If all non-abstaining votes within the RCI fail to meet the 75% Yes or No majority threshold, the agenda vote remains active for next RCI.
If 75% of all non-abstaining votes within the RCI are in support of the agenda (“Yes”), the agenda is considered locked in and the consensus changes will activate 8064 blocks after the vote passed.
If 75% of all non-abstaining votes within the RCI are in opposition of the agenda (“No”), the agenda fails and the consensus changes will never activate.
If an agenda reaches its expiration before ever reaching a 75% majority vote, the agenda expires and the consensus changes will never activate.

Below is a diagram of the entire cycle for a single agenda with consensus upgrades.

Transaction Format

Field	Description	Size
Version	Transaction version. This number is used to signify how the transaction should be interpreted	4 bytes
Input count	The number of inputs in the transaction encoded as a variable-length integer	1-9 bytes
Inputs	Serialized list of all the transaction’s inputs	Variable
Output count	The number of outputs in the transaction encoded as a variable-length integer	1-9 bytes
Outputs	Serialized list of all the transaction’s outputs	Variable
Lock time	The time when a transaction can be spent. (usually zero, in which case it has no effect)	4 bytes
Expiry	The block height at which the transaction expires and is no longer valid	4 bytes

Inputs

Inputs spend previously-made outputs. There are two types of transaction inputs: Witness and non-witness.

Non-Witness Inputs

A non-witness transaction input is a reference to an unspent output and a sequence number. A reference to an unspent output is called an “outpoint.” Outpoints have three fields:

Field	Description	Size
Transaction hash	The hash of the transaction which contains the output being spent	32 bytes
Output index	The index of the output being spent	4 bytes
Tree	Which tree the output being spent is in. This is required because there is more than one tree used to locate transactions in a block.	1 byte

In addition to an outpoint, non-witness inputs contain a sequence number. This number has more historical significance than relevant usage; however, its most relevant purpose is to enable “locking” of payments so that they cannot be redeemed until a certain time.

Witness Inputs

A witness transaction input contains the data necessary to prove that an output can be spent. Witness inputs contain four fields of data:

Field	Description
Value	The amount of coins that the output being spent transfers.
Block height	The height of the block containing the transaction in which the output being spent is located.
Block index	The index of the transaction in which the output being spent is located.
Signature script	The script that satisfies the requirements of the script in the output being spent.

Outputs

Outputs are transfers of DCR that can be spent by inputs. Outputs always have three fields of data:

Field	Description	Size
Value	The amount of DCR being sent by the output.	8 bytes
Version	The version of the output. This number is used to signify how the output should be interpreted.	2 bytes
Public key script	The script that must be satisfied to spend the output	Variable

Serialization

The format displayed above is not the format that transactions are sent and received in. When sending or receiving transactions, they can be serialized in a few ways. The way that a transaction should be deserialized can be determined from its version. Transaction versions occupy four bytes, but those four bytes are actually used to store two separate values. The first two bytes of a transaction’s version denote its actual version number. The second two bytes denote its serialization format.

Serialization Formats¶

When serializing, there are two main parts of a transaction: Its “prefix” and its witness data. The transaction prefix is comprised of:

Inputs (without any witness data)
Outputs
Lock time
Expiry

The witness data of a transaction involves only its inputs. The included data fields of its inputs depend on the specific serialization format. This format can be any one of the following:

0 (Full serialization) - The transaction’s prefix is located immediately before its witness data.
1 (No witness) - The transaction’s prefix is the only data present.
2 (Only witness) - The transaction’s witness data is the only data present. For each input, this includes its value, block height, block index, and signature script.
3 (Witness signing) - The transaction’s witness data is the only data present, and is serialized for signing purposes. For each input, this includes only its signature script.
4 (Witness signing with value) - The transaction’s witness data is the only data present, and is serialized for signing purposes. Unlike the Witness signing format, this format includes the value of each input before its signature script.

The figure below shows the percentage of block bonus amounts (Y axis) of the primary node (red) and equity node points (blue) relative to the total coin supply locked by the primary node (X axis) starting from block 648,000 (mid-may 2017), where each block bonus is fixed at 5 PIV. The diagram below shows the annual percentage returns from 648000 theory, in which each block set red line said each of the master node maintenance cost is zero holders master node, and the green line is under the hypothesis that the logic of the master node regression curve, each master node maintenance personnel maintenance cost is $300 a year, the price of us $1 each of the PIV.

Decred (/ˈdi:ˈkred/, /dɪˈkred/, dee-cred) is an open, progressive, and self-funding cryptocurrency with a system of community-based governance integrated into its blockchain. The project mission is to develop technology for the public benefit, with a primary focus on cryptocurrency technology.

Decred’s governance is based on the principle of ticket-holder voting. The ultimate decision-making force for the project is the voting of active tickets.

Holders of DCR can time-lock their funds in exchange for tickets. Tickets allow one to participate in Decred’s governance in three ways, two on-chain and one off-chain.

In each block, five live tickets are selected pseudo-randomly and called to vote on-chain. Tickets are called to vote after an average of around 28 days, once a ticket has voted the DCR which was time-locked to buy it matures (un-locks) after 256 blocks, along with a portion of the block reward.

On-chain voting serves the following purposes:

Agenda voting to approve or reject a proposed change to the consensus rules of the protocol. A proposed change must be approved by 75% of non-abstaining tickets to take effect.
Voting to approve the work of PoW Miners. In order for a PoW Miner to receive their share of the block reward, at least three of the five tickets called in the subsequent block must approve their block. This gives ticket-holders power over PoW Miners in the case of undesirable behavior by miners (e.g. mining empty blocks), although this power is yet to be exercised on mainnet.

Decred’s on-chain governance is supplemented by Politeia proposal voting, which doesn’t happen directly on-chain but is woven into the Decred blockchain in some ways.

Politeia proposals concern the direction of the project, they may involve spending the project subsidy fund (10% of the block reward goes into this fund to support development of the project) or amending the Decred Constitution or other policies.

Politeia is built around the concept of transparent censorship, using dcrtime. Users cannot be silently censored, they can prove that censorship has occurred.

The Politeia web platform is a reddit-style space to facilitate submitting, viewing and discussing proposals.

Politeia proposals are approved/rejected through “snap” voting. When proposals move to a vote, all live tickets at that moment are eligible to vote Yes/No on the proposal while voting remains open (one week period). Ticket-holders vote through their wallet.