From our white paper:
With this rich history to draw upon, it is now possible to identify and evaluate most of the design deficiencies of Bitcoin and other decentralized public blockchain networks, with an eye toward suitably addressing these problems in order to design a superior next generation of cryptocurrencies. The basic goal remains the same as in Satoshi’s paper: to create a private, censorship-resistant, non-state currency which can be utilized as the nucleus of a larger ecosystem.
2. Lack of privacy. Recording all transactions on a distributed public ledger is inherently anti-privacy. At least one third of all “anonymous” bitcoin addresses have been de-anonymized,
and this is enough to permit highly effective tracing (7) of money flows through the network.
5. A requirement to run full nodes in order to enjoy benefits fully. It is often argued that only users running “full nodes”(9) (i.e. nodes that download and verify the entire blockchain) can provide true decentralization and censorship-resistance to the network. Full nodes also allow users to generate and control their own private keys, and to specify transaction fees. Yet such nodes have an enormous footprint, imposing non-trivial hardware and bandwidth requirements.
6. The need to see all transactions, not just one’s own. Related to points #2 and #5, users who are not mining blocks should have no need to concern themselves with transactions belonging to other parties. (And for reasons of privacy, should not see others’ transactions.)
Our user client architecture is lightweight (addressing issue #5), provides access to private keys only on the user’s own device, and can access only the wallet’s own transactions (issue #6). Transaction receipts are seen only by payer and payee, and can be permanently deleted.
Because the protocol tunnels over XMPP, it provides innate connection encryption and a
superior resistance to protocol-based detection and interdiction, along with end-to-end
encryption and easy access to intra-community messaging (since wallet clients are also chat
By building out both the ecosystem demand for coins and the coin supply at the same time, the goal is to create a stable, private money that allows growth with low volatility – something the world has not seen since the years of the classical gold standard prior to WWI. (26)
By design, OTO presale vouchers are a privately issued virtual currency and not a commodity
The clearing mechanism used by the cryptocurrencies DASH (36) and PIVX (37) presents an
interesting middle case. Payments are submitted by ordinary client nodes, but aggregated and settled by “master nodes,” which are high-volume clients accorded special privileges. Although the motivation for this aggregation is privacy, via the obfuscation of individual transactions by mixing them with unrelated ones (using an algorithm known as “CoinJoin”) (38), the effect is to create a clearing layer (229) where the number of nodes involved with transaction settlement (~4600 for Dash) is much less than the total number of nodes in the system. The distributed ledger system Ripple similarly operates with a significant but fixed number of transaction validators. (39)
There are however consequences to raising the block size. The amount of memory required to verify 1MB Bitcoin blocks (never mind mining them) is already substantial. Devices with only a few gigabytes of RAM available perform block verification multiple times slower than devices with significantly more RAM. If the block size increased substantially (note the Bitcoin Unlimited plan called for gradual steps up to as high as 8GB!), it would very quickly require hardware well beyond the reach of casual retail users and small businesses. The result would of course be further centralization, not only of the mining function, but also of the verification of the blockchain by non-miners maintaining full nodes. This would have the eventual effect of centralizing all blockchain activity around a small number of participants that owned enormous computing resources. Ordinary users would be relegated to operating web-based clients hosted at those major vendors, probably no longer in sole control of their own private keys. Thus the B2X vision ultimately entails sacrificing the distributed, democratized, decentralized nature of Bitcoin on the altar of good customer service. To refer back to our pyramid diagram, B2X would shift Bitcoin from near the bottom of the pyramid upward to near the top, gaining efficiency while losing decentralization.
The other clear trend is the shift toward permissioned blockchains. (222) In any blockchain, there are three basic functional levels: the client can connect to the network and read data (it can download blocks); it can also submit transactions (meaning it has write access); and it can confirm transactions (by means of mining blocks). Put simply: read, write, and verify. In a permissioned blockchain, these functions can be accessed according to a node’s possession of a certain private key, or by virtue of connecting from a certain IP address, through some type of login protocol, or by some other means specified in software. For example, anyone might be able to download the client and browse completed transactions (similar to search functions at blockchain.info (92) for example). But only authorized terminals would be able to submit spends, and only a strictly pre-specified list of miners would be able to confirm them.
No blockchain-based fintech could ever be acceptable to the existing financial system, or to its regulatory apparatus, which allowed any device with an internet connection, run by any anonymous geek anywhere in the world, to connect to the network and start broadcasting transactions, let alone validating them. Indeed there are reasons why even a privately owned network (as for a niche altcoin) might want to block that from happening – preventing DDoS attacks for instance. On a purely public permissionless blockchain, there is no way to prevent anything at all, from high velocity “dusting” spends of tiny amounts of coins simply to soak up block space maliciously, to frequent repetitive large spends back and forth between wallets controlled by the same owner, made in an effort to bump up the calculated average transaction fees, to a full-blown 51% attack. (Bitcoin has already experienced all these kinds of attacks, and more, with the exception of a 51% attack.) For these reasons it’s also fairly probable that many Lightning network operators will ultimately deploy permissioned blockchains, too.
So where does all of this get us, in the end? Regardless of what happens to “resolve” the Bitcoin scaling debate, it seems that we are headed for, at best, a federated network of mostly centralized clearinghouses operating in competition with each other. Ironically, this is not dissimilar to the status quo which existed before Satoshi ever published his paper, with one distinct difference: in the past there was no distributed ledger of all posted transactions which could be read by anyone with permission. Thus the net effect of introducing blockchain tech into the mix will have been to reduce or eliminate privacy. This is of course completely contrary to the vision which animated early Bitcoin adopters, but it was the obvious likely result all along, at least to those who read Satoshi’s paper and
thought about how the concepts (93) it discussed would eventually integrate into the real world.
The Future of Private Money
When Friedrich Hayek (94) published The Denationalization of Money (95) in 1976, and Denationalization of Money: The Argument Refined in 1978, he argued for privately issued money as opposed to money issued by governments (or by central banks to which a government has contracted out the issuance of its money). Hayek concluded that privately issued currencies, competing with one another for market share, would result in a stable system which would better protect the interests of the users of such currencies. Similar arguments (96) continue to be made by scholars today. Certainly central bank fiat currencies have done precisely the opposite, mainly because their management is actually serving the interests of governments — and of the elites who own and operate those governments, of course — against the interests of the populace.
In regard to privacy however, Ripple is hardly a model to be emulated. Only duly KYC’d users can participate, and the company retains permanent records of all transactions. Moreover the target market for Ripple isn’t really retail usage at all: they are angling to compete with the SWIFT wire system (100) to handle bank-to-bank and cross-border transactions, using their XRP currency as a common vehicle. All of the 50-odd validator nodes on their network are operated by big companies, mostly financial services firms.
But what if an elastic-supply currency existed, managed by a private foundation, targeted at large existing niche markets, and issued onto a permissioned blockchain? What if this cryptocurrency provided its own built-in quasi-Lightning network to facilitate fast and truly private, anonymous and untraceable digital cash payments? What if the various components of this system utilized architectural data separation, and a partitioned business model combined with jurisdictional arbitrage, to provide a level of censorship resistance comparable to that of a widely distributed network of independent miners?
This vision is precisely our plan for the Ascension Project.
Achieving Performance, Privacy, and Business Opportunity (Lightning and then some!)
For Issuer asset types which are themselves cryptocurrencies, the voucher system acts like a
“Lightning” network, in which coins that are moved into the custody of the Issuer cease to circulate on their blockchain, and thereafter circulate in digital voucher form instead. Unlike coins, vouchers are always destroyed and replaced in every transaction. And because the VP signs only vouchers and never wallet balances or receipts, this provides a means to circulate cryptocurrencies anonymously and untraceably, without leaving any “footprints” on the native blockchain. In this way a layer of privacy is provided, as well as efficient, instant, irrevocable settlement. In computer science lingo, voucher payments are “ACID,” (103) that is: atomic, consistent, isolated, and durable. This deftly avoids the entire consensus problem arising from the need to make a decentralized blockchain consistent.
The VP’s operator vets the Issuers, along with the operators of other nodes (such as OFSs or SVMs). These business arrangements can therefore exploit jurisdictional arbitrage, and enforce the compartmentalization of data about users and customers. This by itself facilitates censorship resistance and privacy. For example, note that the VP, SVX, and any SVM (app) will never see an IP address of a user client, since the OFS acts as a built-in proxy. (There is also a separate proxy layer above the OFS, which like the rest of the network does not have a public-facing IP address.) In fact it doesn’t require a massively decentralized network to protect users and their activities, so long as this simple rule is followed: No entity which knows who or where a user is can know what they are doing; and conversely no entity which knows what a user is doing may know who or where they are.
For example, an SVM which supports online sports wagering will not be able to discern the country of origin of the players. In contrast, building such applications directly on the blockchain, which records the IP addresses of transaction submissions and posts everything to a permanent public ledger, depends wholly on the naive assumption that a given wallet address can never be associated with a player (ever!), in order to provide even a thin veneer of privacy.
A Superior Hybrid Concept
Contrary to prevailing belief, completely decentralized cryptocurrencies lacking a proprietor to steer them and keep them competitive, are not inherently superior to systems utilizing centralized payment clearing. Not only are decentralized currencies necessarily less efficient, inevitably exhibiting scaling problems which are extremely hard to solve, but their need for broad consensus as a prerequisite to make any changes is clearly inhibiting their flexibility, and hence their growth. (Except for growth in price, as institutional money (110) begins to chase “alpha” into the cryptocurrency space.) (111) Moreover from a privacy perspective the blockchain spells the end of all financial and transactional privacy. It’s been fairly called the beginning of the cashless control grid. This is a leading eason why governments and big banks love blockchain tech, and today are seen starting up their own blockchain projects. Potential solutions from within blockchain tech are perhaps possible (112), but still years in the future.
Ascension offers a hybrid approach: issue the coins on a distributed private blockchain, but then add an application layer above the blockchain which provides the benefits of centralized clearing, along with strong privacy, plus the tools to support natively a community of users and merchants. This will allow the Ascension Foundation to construct the demand side for its currency, at the same time that the supply side is constructed, both via token sales and by other methods. Since the value of any currency – even the mighty US dollar – is predicated on achieving a balance between supply (money creation rate) and demand (level of economic activity using that currency), new OTO/Lyra released into circulation will be balanced by simultaneously providing markets and apps where it can be utilized by its holders. In this way a stable private ecosystem can be developed around a privately issued money, much as the brilliant Friedrich Hayek envisioned more than 40 years ago.
The footprint of our wallet client is therefore extremely light, requiring no large data downloads and synchronizing with the network in only seconds following login. While it is now possible to do Jabber chat using browser plugins – thus making a separate dedicated program unnecessary – we do not consider it possible to provide a truly secure wallet client, which controls and manipulates private keys, within a browser plugin context. This is because browsers are bloatware with large attack surfaces, and also because hostile plugins (aimed at stealing keys and passwords) may be running within the same process address space on the device. Operating systems typically provide better firewalls between processes than what is achievable within a single process (the browser).
In keeping with security concerns, our clients generate all keypairs on the device, but do not store them there. Instead the private key (along with certain random hashes used as data storage indexes for wallet data) is wrapped up into a login data block, encrypted again using an input passphrase, and stored in the cloud at a hashed location. Unlike most cryptocurrency addresses, our wallet IDs are human-readable, resembling an email address, in the format
The user picks the handle (e.g. “bob”) while the system appends the differentiating sequence number, and the @publisher indicates the “domain” space in which the wallet was created. The user also selects a PIN, and two passwords: a “long-phrase” and a “passphrase.” The wallet ID + PIN is used to build a hash which accesses the long-phrase storage, so that the OFS gateway server cannot determine which wallet is attempting to log in. The alphanumeric long-phrase is always entered via a drop-down menu, only for the three characters randomly selected on any given login attempt. The passphrase is never transmitted over the network at all, but is used to decrypt the login block once it has been successfully retrieved using the long-phrase. This three-step login mechanism is more complex than a typical login/password procedure, but its very complexity removes any need for two-factor authentication. We consider two-factor wallet logins an unacceptable risk to privacy, because they link a wallet to an email address or phone number, which may itself be tied to a real life identity in third-party databases. Also,
phones and email accounts can be hacked and taken over by a variety of methods, making two-factor security of limited actual value.
In the cloud, all vouchers and receipts are stored at random hashes generated along with the wallet’s private keys, and encrypted using the wallet’s public key. This means that even someone who gained access to the SDS’s database would be: 1) unable to identify which objects belong to which wallets; and 2) unable to read any of the data anyway. Even if a wallet’s private key were compromised, that by itself would not enable the hacker to spend any of the wallet’s contents. Wallets only have read-access permissions to their vouchers. Write access is only by the Voucher Publisher (VP), which requires the wallet’s unique read-write capability passphrase, to supply to the SDS to gain folder update permission.
This passphrase is stored in the wallet’s login data block, but encrypted using the VP’s public key, not that of the wallet. This means that a wallet’s private key, by itself, cannot be used to steal from the wallet. Required is access to the entire contents of the login block, which can only be decrypted using the passphrase. Login blocks are stored at hashes which are not associated with the wallet ID by name, but can only be retrieved by building the proper hashes out of the wallet ID, PIN, and long-phrase. The net result of this is that a wallet can be pilfered only if the attacker has access to the wallet’s complete login credentials – in which case they could just log in normally! Complete details can be found here. (117)
The SVX API can of course be extended in the future. In particular, once the Ascension blockchain has been initialized it will become possible to add support for “atomic swaps” between the Ascension blockchain and other blockchains. An atomic swap is a mechanism by which coins are spent on one blockchain, but cannot be spent by the recipient until a corresponding spend of coins has been made on the other blockchain (or a timeout occurs, reversing the spend). Basically, Alice spends coins to Bob on blockchain A, but Bob cannot move those coins until he makes a corresponding spend of coins on blockchain B to Alice. The main problem with this mechanism is that it isn’t at all private; the spends on both blockchains are publicly associated. (For that matter, all exchanges performed via ShapeShift are published as well.) It is conceivable that protocol changes could be made to Bitcoin and other blockchain currencies, which would alleviate this concern. For example, MASTs (Merkleized Abstract
Syntax Trees) could be deployed (121) to make atomic swaps have an acceptable level of privacy protection. But in the near term it seems clear that p2p exchanges will continue to play a major role (122), even if fully decentralized exchanges (123) become a reality. Our SVX technology is p2p today and will evolve toward full decentralization in the future. (We consider decentralized exchange a “killer app” in itself.)
VI. The Ascension Blockchain: Private, Permissioned, and Performant
Consider the diagram below in Illustration 3, expanding the Ascension Blockchain component shown
in Illustration 2.
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 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. (225) However it does support recording non- transaction data in the public ledger (as exploited by Factom (125), among others.) There are also projects meant to bring smart contracts capabilities into Bitcoin, such as RootStock. (126) Given that we are ambivalent about the wisdom (127) 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 transaction malleability. (128)
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 (129) (or something else yet to be released!) may yet be adopted instead. (EOS however has a very naive and troubling attitude (232) 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:
1. 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.
11. 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.
13. 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 (133), to help them conduct their business.
Regardless, the relationship at the blockchain level will remain between the Issuer and AF.
Viewed as securities, they are also very peculiar. They do not generally represent equity in an enterprise, nor debt, nor a derivative wager placed on the future price of something. They are unregistered (without CUSIP numbers), (197) and are digital bearer instruments controlled by means of private encryption keys. (A point noted here (198) by investor and PayPal co-founder Peter Thiel.)
While the Ascension blockchain is not yet launched, our voucher network that sits on top of it is fully functional today. Moreover this network is not going away once our blockchain is
deployed; rather, it represents an integral part of our market solution for scalability and privacy.
The only secondary market for our coins that is currently available is the p2p escrow market
provided through the SVX API, where OTO can be swapped for bitcoin, litecoin, and other
assets. The AF does not make a market in the SVX, and any trading it does there (or
anywhere) is exclusively for its own account. Prices from trades made therein are kept private
between the parties to the trade, and are not published externally.
Kevin Wilkerson, Founder and CTO
Principal Implementer of the Voucher-Safe technology, Founder of the Digital Cash Alliance
Kevin has been involved with software development for more than 30 years, as a coder, a systems architect, and technical team lead. He has worked in areas as diverse as mechanical CAD/CAM, interactive cable television, e-commerce, and private communications technologies. He was involved in the digital gold industry in the 2000s, the predecessor to today’s cryptocurrencies. Kevin is the co- architect and principal implementer of the Voucher-Safe digital cash technology, which allows OTO and other assets to circulate privately off-chain. He is a former freedom movement political activist, science fiction author, and classical musician. Kevin founded the Digital Cash Alliance in 2015, and has been involved in a number of free market business enterprises.