Free Floating PEG + 5K Limit

This update brings in 2 huge updates to Pegnet, and it affects pegnet users and miners. All users of pegnetd and all miners will have to update their software. For miners mining as part of a pool, only the pool operators will need to update.

The 2 major changes: Activate at block height 222270, estimated to be Dec 9, 2019, 17:00 UTC. You MUST update by this block height.

• Floating PEG Price (MINER UPDATE)
• 5K Conversion Limit (PEGNETD UPDATE)

Floating PEG Price

The PEG Price has been calculated by the equation Total Market Cap / Total PEG Supply, but this is now changing. That equation was used to bootstrap the network before PEG was listed on an exchange. Now that PEG is listed, the PEG price will come from the same sources as all other assets; the external market.

!!! As a miner, this means you have to update your miner software to recognize this change, as this will fork the pegnet chain. All miners will additionally have to add a polling source for the price of PEG. 3 Options are currently available:

• https://pegnetmarketcap.com/
• https://www.factoshi.io/pegnet
• https://www.coingecko.com/en/coins/pegnet

These can be enabled in the config by adding these lines: https://github.com/pegnet/pegnet/blob/7365ebab4df8b3922a2f0dffd73014c5c0e98267/config/defaultconfig.ini#L148-L150. Remember to set a priority >= 0, and double-check your datasource configuration with pegnet datasources. You can consult this wiki page for more information on configuring your datasources https://github.com/pegnet/pegnet/wiki/Configuring-Your-DataSources. This can be done before the activation height, the miners will automatically switch to include the PEG price at block height 222270. So update asap!

5K Conversion Limit

After the activation height, only 5K PEG per block can be created from conversions. If more than 5K PEG is requested to be converted in a block by 1 or more users, those users will instead receive a portion of the 5K PEG + a refund of their leftover amount. If you want to know why is this being implemented, please refer to this medium post here.

If you want to know how it is being implemented,

• Source Code for Proportional Payout
• Formulas for Proportional Payout
• The tl;dr (ok you have to read a little)
  • If you want to play around with the design, a simple google sheet was made during testing. Feel free to make a copy of it here

Other changes

Pegnetd Changelog:

• Richlist in the cli + api
• Refund output in PEG conversions. Until now, all conversions were whole. Now that partial conversions exist, since there is a limit of 5K PEG, an additional output exists; the refund. To accommodate this, all PEG conversions that have a refund will have an output in the transfer's outputs field that indicates the amount of the original asset returned. If you process the transaction outputs field regardless if it is a conversion or transfer, you will not have to update your code that handles txs. An example of this new api output can be found in the PR comments here.
• Performance boost in get txs call
• Free floating PEG activation
• 5K Conversion Limit activation

Pegnet Changelog:

• Modularized Grading, OPRs, Conversions, and more for external libraries (pegnetd uses this)
• Free floating PEG activation for the miner. Datasources were added for this update, and you must update your config.
• Some small miner enhancements

One Way Conversions for pFCT

Update By: Block height 220346 (Estimated to be Nov 25, 2019 17:47:00 UTC)

This update is required for all pegnet users. Miners do not need to update their mining software. This update enables one-way conversions for pFCT. This means that pFCT can convert into any pAsset, however, no pAsset can convert into pFCT. The only way to acquire pFCT is to convert FCT -> pFCT. The rationale behind this change can be found here. (The PIP process is still very new, and we plan to improve it and work with PIPs in the future.)

The activation of this feature is block height 220346 (Estimated to be Nov 25, 2019 17:47:00 UTC). You must update before this height, or risk having a forked node. If you update after this time, your database must be deleted and resynced from scratch.

Change Log:
Protocol Changes:

• One way conversions for pFCT

API Endpoints Updated:

• get-transactions now has an asset filter param

CLI Commands Updated:

• pegnetd get txs now has a --asset filter flag and --offset flag
• factom-walletd user/pass authentication now supported by pegnetd commands

API Endpoint Update v2

A new tag was needed to trigger the automatical build in the ci pipeline

This release marks an upgrade to the api set for interacting with pegnet transactions. The new apis can be found in the wiki here: https://github.com/pegnet/pegnetd/wiki/API. A large change in this update is how transactions are presented to the user. A transaction on pegnet can be either a:

• burn from FCT -> pFCT
• coinbase from mining rewards
• transfer from an asset changing ownership (person A -> person B)
• conversion from a change in asset, PEG -> pUSD

Every transaction is considered to be included inside of a batch. This is because Pegnet allows users to combine multiple transactions into a single entry. For consistency, if a hash is provided in the form of 64 hex characters, it can contain 0 or more transactions. It could be a factoid txid, a mining opr, or an entryhash. To provide a pegnet txid to a specific transaction, the index of the transaction in the batch must also be provided in the format of [TxIndex]-[Txhash].

E.g: 0-839809fd4f16200c97b1e53c6775c0efd55746db3c285461149adac3572694b3 is the first transaction associated with the given hash. If the batch contains more than 1 tx, you can use the prefix to report the txid of the single tx in the batch: 1-83980..., 2-83980.... There is no rule on the padding of the prefix. If a fixed length is needed for display purposes, leading 0s are accepted: 001-83980...

This change required a large update to the pegnet database, so a full resync is required. The pegnet node will automatically create a new database when using the latest codebase. No action is required to trigger this resync.

API Endpoints added:

• get-transactions : queries for all transactions related to a hash, address, or height
• get-transaction-status : Details if a transaction is executed, pending, or rejected.

API Endpoints changed:

• get-transaction : The params for this have changed
• get-transaction-entry : This api endpoint was dropped

CLI Commands Updqated/Added:

• `pegnetd get txs <entryhash | factoid txid | entryhash>
• pegnetd get tx <pegnet txid>
• pegnetd burn <FA-source> <FCT amount> : The FCT -> pFCT command has been added to pegnetd

API Endpoint Update

This release marks an upgrade to the api set for interacting with pegnet transactions. The new apis can be found in the wiki here: https://github.com/pegnet/pegnetd/wiki/API. A large change in this update is how transactions are presented to the user. A transaction on pegnet can be either a:

• burn from FCT -> pFCT
• coinbase from mining rewards
• transfer from an asset changing ownership (person A -> person B)
• conversion from a change in asset, PEG -> pUSD

Every transaction is considered to be included inside of a batch. This is because Pegnet allows users to combine multiple transactions into a single entry. For consistency, if a hash is provided in the form of 64 hex characters, it can contain 0 or more transactions. It could be a factoid txid, a mining opr, or an entryhash. To provide a pegnet txid to a specific transaction, the index of the transaction in the batch must also be provided in the format of [TxIndex]-[Txhash].

E.g: 0-839809fd4f16200c97b1e53c6775c0efd55746db3c285461149adac3572694b3 is the first transaction associated with the given hash. If the batch contains more than 1 tx, you can use the prefix to report the txid of the single tx in the batch: 1-83980..., 2-83980.... There is no rule on the padding of the prefix. If a fixed length is needed for display purposes, leading 0s are accepted: 001-83980...

This change required a large update to the pegnet database, so a full resync is required. The pegnet node will automatically create a new database when using the latest codebase. No action is required to trigger this resync.

API Endpoints added:

• get-transactions : queries for all transactions related to a hash, address, or height
• get-transaction-status : Details if a transaction is executed, pending, or rejected.

API Endpoints changed:

• get-transaction : The params for this have changed
• get-transaction-entry : This api endpoint was dropped

CLI Commands Updqated/Added:

• `pegnetd get txs <entryhash | factoid txid | entryhash>
• pegnetd get tx <pegnet txid>
• pegnetd burn <FA-source> <FCT amount> : The FCT -> pFCT command has been added to pegnetd

Pegnet PEG Conversions

This release activates PEG conversions at height 214287, roughly Oct 14, 2019 15:00 UTC. The equation to determine the price of PEG is total market cap of all assets / supply of PEG.

Sum(Each Asset Supply at height n-1 * Each Asset price at height n)
-------------------------------------------------------------
		PEG Supply at height n-1

Please update pegnetd by that date. You will have to resync pegnetd when using this version. We enforces a new sync incase any users update after the activation height. We want to ensure all users are using the correct balances.

ChangeLog:

• Added PEG conversions
• The daemon will create a default config file if you do not have one
• Miner api changes to remove hyphens from field names

Pegnet Blocked Sync Patch

This is a patch to correct syncing transactions that have duplicate addresses in both the inputs and the outputs. The sql db was using the entryhash + address as a primary key as an indexing tool for retrieving user's addresses. The secondary purpose was to know if an entryhash was already submitted.

The unique filter would not work if a user set themselves in the input and output. This patch handles this case. You will need this patch to sync on mainnet.

There is no change to any transactions on mainnet, all validation rules are the same. This was a client side bug, and does not affect the blockchain.

Pegnet Transactions + Conversion Daemon

pegnetd is a lightweight daemon + cli tool to interact with the pegnet chain and conduct transactions/conversions of pegnet assets. The daemon will need to be run against a live factomd instance to sync.

For all cli interactions dealing with private keys, factom-walletd acts as the private key store. So all inputs to transactions + conversions will need to be imported into a walletd instance that the cli has access too.

Please refer to https://github.com/pegnet/pegnetd#configuration for configuration instructions. All pegnetd cli tools can be found from pegnetd help

Transactions and conversions will go live around October 7, 2019 at 15 UTC (block height 213237). Currently all assets with a 0 rate will not be allowed to convert. This means PEG cannot be converted until miners decide to place a value for PEG.