Ascension Blockchain

The Ascension blockchain will be forked from the latest open source version of a first generation blockchain. The most likely candidates for this, in descending order are: Ethereum Classic (ETC), Ethereum (ETH), Bitcoin (BTC). ETC retains a PoW mining mechanism, and will not be transitioning to PoS through the adoption of Casper. Bitcoin does not support Turing-complete smart contracts, but basic contract types are available through Ivy.
​However it does support recording nontransaction data in the public ledger (as exploited by Factom, among others.)

​There are also projects meant to bring smart contracts capabilities into Bitcoin, such as RootStock. Given that we are ambivalent about the wisdom of supporting Turing-complete executable code on a blockchain to begin with, we may elect not to support smart contracts. At the very least they will be will be very tightly controlled (as described below), if they are supported at all. Even the adoption of SegWit presents a minor problem in that it makes it impossible to validate a blockchain transaction after the fact without reference to separately stored extension blocks.
This is plainly sub-optimal unless block space limitation is a problem, as it was for BTC (but will not be for us).
​At least SegWit also fixes issues with transaction malleability : Ascension Blockchain Architecture fixes transaction malleability. ​

​​Consider the diagram, expanding the Ascension Blockchain component shown

• The black arrows indicate public blockchain messaging.
• ​The green arrows indicate private blockchain messaging, inside of a VPN.
• The red arrows indicate legal contractual relationships.

​The reason for this fundamental uncertainty about blockchain source is quite simply that the industry is in such a state of flux that a choice made today may prove to be a foolish one only a few months from now. Since we do not intend to deploy the Ascension blockchain sooner than 4Q2018 at the earliest (and do not have to be in a rush to do so since we already have a working system above our future blockchain), making a final choice at the time of this writing strikes us as unwise and unnecessary. It is even possible that a dark horse platform such as EOS, BCH, or Omni (or something else yet to be released!) may yet be adopted instead. (EOS however has a very naive and troubling attitude regarding privacy.)

In any event, whichever starting point is ultimately selected, we will then customize the functioning of that blockchain's software to implement the following operational parameters:

• The validation (mining) of blocks will only be accepted from network nodes which meet these criteria: a) are in possession of a signing key whose corresponding public key is on a list of authorized validators; and b) submit their block from an IP address on a private VPN.

• All mining nodes will also offer public-facing IP addresses for connection by non-validator client nodes, discoverable via the usual DNS seeds mechanisms. Messages between validating nodes will always travel over the VPN, in order to improve security, and evade national firewalls and potential packet censorship. (A VPN failure fallback to public IPs is allowed.)

• Mining pools (hereinafter just “miners”) will be under a legally binding contract with the Ascension Foundation (AF). Per the terms of this contract, they will provide to the network a specified minimum amount of hashing power, with a reasonable uptime guarantee. They will adopt and install software upgrades on a schedule stipulated by the AF. Miners will be established on all continents except Antarctica, in sufficient numbers to provide adequate redundancy and censorship resistance. VPN access will be provided to them by the AF.

• Miners receive block transaction fees for the blocks they mine, but will not receive block rewards when they mine a block. Instead, each miner will be paid a fixed sum of Lyra (the coins used on the Ascension blockchain) each day they are online, calculated as a prorata share of the AF daily mining budget, based on the percentage of total network hashing power being provided by that miner. The AF will recalculate its mining budget periodically, based on such factors as changes in total hashing power, number of miners under contract, and the price history of Lyra versus a basket of other currencies.

• Miners will agree not to mine any other cryptocurrency, including merged mining, using the same dedicated hardware they are providing to the AF network. They may mine other currencies as they like using entirely separate hardware. This proviso should eliminate the problem described here.

• Minting of new Lyra shall be conducted by the AF exclusively. This shall be done by means of a 'mint directive' message broadcast to miners, specifying the number of new coins to be created in an upcoming block (by default, the next block). This message must originate within the VPN and is a multi-signature transaction which must be signed by a majority of minting keys, established for this specific purpose, which are controlled by the AF board. This number of coins effectively becomes the “block reward” for the indicated block, with the distinction that the new coins will be paid to an address also belonging to the AF, instead of to the winning miner. (As noted above, miners do earn and retain the fees for transactions in a block.)

• When the Ascension genesis block is created, the number of coins specified in the very first 'mint directive' will specify, at minimum, an amount of coins equal to the total quantity of OTO vouchers then in circulation, plus the required backing for any other voucher currencies backed wholly or fractionally by Lyra. Thereafter the quantity of Lyra minted over time will reflect increases in circulating OTO and related (Lyra-backed) currencies, together with the implementation of the monetary goals of the AF board. It is likely that most blocks will lack a minting directive associated with them, thus the number of new coins per block will often be zero.

• Block size will initially be set at 1MB, with blocks occurring on average every 60 seconds. Given the available hash rate across all miners, the difficulty will be manipulated as required in order to maintain the desired block rate. Difficulty can be auto-adjusting, or explicitly set by AF. Block size can only be changed by means of a scheduled software update, to take effect as of a specific block number.

• Blockchain wallet clients operated by users (defined as any node without validator permission) will connect to public-facing IP addresses of miners, and of one another. All TCP/IP connections will be secured via TLS using self-signed certificates. (The point here being to transmit data over encrypted connections rather than to authenticate anonymous parties.) TLS will also be supported for RPC/JSON connections. User clients will be able to download all past blocks, and submit transactions to the network, denominated in Lyra, with fees also offered in Lyra, in the usual manner. A suitable threshold for minimum spends and/or fees may be specified in the software, in order to prevent nuisance dusting attacks. While users will not be required to install every software update released by the AF, wherever the changes in a new release require it, the Satoshi number of releases below a certain level will no longer be accepted when connecting to other nodes which have upgraded. Users with too-old versions will be notified that they need to update their software.

• Smart contracts (defined as any code posted to the blockchain meant for execution by other clients), can only be submitted into a block using a signing key duly authorized b permissions.

• In order to implement the permissions system outlined above, a versioned permissions block will be posted on the blockchain, and periodically updated. Each version of this JSON block will specify the list of public keys whose corresponding private keys are associated with particular permissions. For example, the keys belonging to the members of the mining pool, the keys permitted to publish smart contracts, the keys belonging to the AF for use in official mint directives, etc. Each permission block will specify the block number at which it becomes effective. Like mint directives, permission block updates must be signed by a majority of master keys belonging to the AF (whose fingerprints in this case are also hard-coded in the software). This mechanism allows for miners to enter or exit the system, for example.

• The OTO voucher Issuer (OTO.Money) manages ordinary client wallets holding at all times sufficient Lyra to back fully (100%) all OTO vouchers currently in circulation. When OTO is sold to the public, OTO.Money will purchase enough Lyra from the AF to cover any shortfall. The AF will satisfy the purchase either by transferring existing Lyra from wallets it controls to OTO.Money's wallets, or at its option create the new Lyra first via a mint directive, and then spend it to OTO.Money. Whenever a voucher wallet user redeems an OTO voucher for Lyra, OTO.Money will destroy (decirculate) the surrendered voucher and spend an equal amount of Lyra from its blockchain wallet to that of the redeeming user. Any additional voucher Issuers, now or in the future, who back their currency with Lyra, will operate in a similar manner. The AF will require periodic audits of Issuer reserves. Thus this is shown on the chart as a legal contractual relationship.

• A voucher Issuer such as OTO.Money may utilize an SVX as a sales portal to privately receive BTC, LTC, or other cryptocurrencies as payment for vouchers sold. They may also designate independent sales agents, such as CryptoWealth.com , to help them conduct their business. Regardless, the relationship at the blockchain level will remain between the Issuer and AF.

​

• The AF will monitor market conditions in order to make periodic adjustments to hash rate, mining budget, difficulty, block size, and the Lyra growth rate. The goal is stable liquidity. A payment system needs stable liquidity, and that stability cannot be reached if you aim to be a payment network before you are an established asset. Operating the Ascension blockchain and surrounding ecosystem according to these rules and guidelines should facilitate the fulfillment of our mission statement: “To promote the growth of robust, borderless, wealth-generating, free market ecosystems.” 

HOME
​