First-generation cryptocurrencies (FGCs) such as Bitcoin, Litecoin, Namecoin, and so on have been instrumental in introducing the public to the idea of cryptocurrency and in establishing a basic mathematical paradigm by which such currencies may operate. As such, they are of historic importance to the field of finance, though at this writing they have yet to become practically significant in society at large. The idea of a decentralized, peer-to-peer architecture and a tamper-resistant monetary base appeal to the spirit of the age. During the induction phase (where we currently are, with large numbers of coins still undistributed and with a small holder base,) FGCs have in some ways functioned as their designers intended. However, some of their properties, as they stand, are obstacles to their long-term success as accepted tokens of exchange. Thus, FGCs may be viewed, not as final, perfected systems, but as an evolving experiment which will ultimately lead to next-generation versions. A discussion of what such might look like might logically begin with a review of existing issues. If this post is excessively lengthy, I apologize, but I know no way to make it much shorter.
Tendency to Centralization:
Though FGCs are presently reasonably decentralized, there are factors inherent in their design which will encourage, even impose, a more centralized model of operation as time goes by. First, FGCs depend for their operation on a block chain, a digital entity encapsulating every transaction that has happened dating back to the currencies' launch. By its nature, this type of block chain will grow rapidly and without limit, ultimately becoming unwieldy for ordinary end-users running a client program on ordinary personal computers. There are signs of this already--Bitcoin's block chain already takes weeks to download on some slower machines, and Litecoin's is becoming quite unwieldy, as well. It will only get worse; eventually, only giant server farms (operated by large, multinational corporations) will be the only practical option for coping with the computational needs of the system. This is certainly not what the creators of the systems intended. There is a school of thought which holds that this centralization makes no practical difference to the end-user and should not be cause for concern. However, a centralized cryptocurrency might ultimately amount to litle more than another Visa or Paypal clone, something which the world does not terribly need at the moment.
Also, FGCs depend on virtual mining as a mechanism for initial distribution of the currency. There is no doubt that this has been a brilliant gimmick for attracting users and for getting people to associate a unit of the currency with value. However, as the currency moves out of the early induction phase, this model will create more problems than it solves. As difficulty increases and reward decreases, ever more exotic and expensive hardware (e.g. ASICs) is required to continue to play the game. Mining is already a venture out of reach for the average user for many of the FGCs, and is gradually being concentrated in fewer, more highly-funded operations. These operations are businesses and perforce must have a business model to continue to exist; thus, they will have to pass on the escalating cost of what they do to the ordinary user in the form of rising transaction fees. And much of this mining activity, especially in the later stages, is parasitic overhead for the system as a whole; it consumes an increasing amount of computational resources and energy while not really contributing to the actual function of the system as intended. Furthermore, the difficulty jumps and fluctuations that occur in the mining process create a class of problems all their own. For these reasons, I do not like the mining process built into FGCs; I think a next-generation cryptocurrency should find a different way to do things.
In summary, it should be more efficient than FGCs and should not only be decentralized at launch but also have a reasonable prospect of remaining that way. There are examples (such as BitTorrent) of peer-to-peer systems that have successfully stayed decentralized, but whether these cases have anything to teach us is not clear.
Volatility and the Dominance of Speculators:
FGCs have been plagued by a market too thin with legitimate commerce compared to the volume of currency speculation they tend to attract. Thus, especially in the induction stage, there is a tendency for them to become trapped in an endless pump-and-dump cycle driven by currency speculators, with one bubble and crash following another. This state of affairs becomes self-reinforcing because the unstable currency value discourages acceptance by buyers and sellers of real goods and services. Although a mature currency might theoretically have a deeper real market and be somewhat less vulnerable to this problem, the issue itself drives merchants and buyers away and is worth looking at.
The Lost and Found Coin Problems:
In a typical "hard-capped" FGC, there is a limit to how many coins will ever be issued. For an auxiliary currency, this is not in itself a problem, but over time an increasing number of coins become trapped in dead addresses due to forgotten keys, lost or malfunctioning computers, the death of address holders, and so on, effectively becoming lost to the system forever. Typically no effort is made to distinguish these fossil addresses from other addresses which have merely been dormant for long periods of time but which are not truly lost. Thus, when the currency is in the mature stage, the number of units will undergo a quasi-exponential decay as the years go by. Some claim that this is not a real problem as users can just compensate by using smaller and smaller fractions of the unit to entoken a given value. However, it is psychologically awkward, at the very least---ordinary users are not comfortable transacting in quadrillionths or quintillionths of a unit and would be put off by the prospect. So this is a problem worth addressing. There is also potentially a related problem: if, in the future, when users are transacting in small fractions of a unit, old addresses with large balances which were long assumed lost happened to be rediscovered, this could cause large disruptions in the money supply, even hyperinflationary spikes. "Soft-capped" currencies are slightly less vulnerable to these issues, but their inflationary nature is a barrier to adoption in an environment where hard-capped currencies are freely available. A next-generation cryptocurrency should thus make a serious effort to confront these issues.
Privacy concerns:
Despite being touted as "anonymous," FGCs are anything but in their native form. The block chain encodes an explicit, public record of every transaction conducted involving every address which has ever existed. Even if the system itself attaches no names to the addresses, forensic techniques such as behavior cluster analysis can usually pinpoint who the owner of a given address actually is, given such a wealth of data. Furthermore, unless anonymizing services such as Tor are utilized, it is quite easy to match coin addresses with IP addresses. If we are at all serious about privacy, having less publicly available data is another desirable attribute for a next-generation cryptocurrency.
Transaction Clearing Time:
This is the most difficult problem of all to solve, and I am not sure if a complete solution is really possible. In a typical FGC, clearing a robustly confirmed transaction requires (depending on system and circumstances) anywhere from two minutes at best to three or more hours at the worst. While adequate for online transactions, this performance is hopelessly inadequate for the bricks-and-mortar/vending machine environment; thus, present cryptocurrencies can be used only indirectly in such transactions through some sort of third-party front-end service which can clear transactions much more quickly. For a cryptocurrency to work natively in such environments would probably require the clearing time to be reduced to around 20 seconds; no cashier facing a long line of customers at a checkout is likely to tolerate much more than that, nor is a customer waiting for a canned soda from a machine. Achieving such speed would (among other things) require block-generation frequency to be raised by a factor of between 4 (optimistically) and 600 (pessimistically) versus current systems. I am not qualified to speak to how possible this is, but it would be a major breakthrough if in fact attained. Even some improvement short of this goal would likely be of some use to expand the range of niches wherein a currency may be used.
The Nerdiness Barrier:
Cryptocurrencies as currently implemented are not at all user-friendly compared to traditional financial media. Even if one does not delve into the arcana of cryptography, hash rates, and so forth, there is still much that is intimidating and unfamiliar to the man on the street. These instruments do not work quite like anything else. Bringing user-friendliness to them is not so much a matter of internal system design as it is an ergonomics issue for coders. Clients need to be written that are truly intuitive and easy for the average person, automating (at least by default) such tasks as most users will not wish to perform manually. I will say no more about this.
IMAGINING THE SOLUTION
There is no unique answer to the issues outlined; what follows is of course just one particular vision. None of the ideas which follow are original, though my particular synthesis of them may be. Some have been proposed independently by several writers, in fact.
In imagining our future cryptocurrency, one of the key elements is replacing the perpetually growing, full historical chain with something that might be called a rolling truncated block chain, with a block discarding algorithm that deletes blocks no longer in active use. Something like this was actually proposed by the founder(s) of Bitcoin, though for reasons unknown it was never implemented. The number of blocks needed to confirm current transactions is said to be relatively small, encompassing perhaps only the last few hours of network activity containing uncleared transactions. The rolling truncated block chain will grow in size during the induction phase of the currency as network traffic increases, but will stabilize in size as the user base stabilizes in the mature phase, and it may well remain small enough that even desktop computers of modest power could still host a full node; there would then be much less push toward giant, centralized servers. The block chain would be supplemented by a current ledger which would be just a list of all active or dormant addresses together with their respective balances and last time accessed (suitably encrypted and distributed to discourage spoofing.) The only time that a copy of the full historical block chain might still be useful is in bootstrapping new nodes, but even here a workaround may be possible: the system might, on demand, using the data from the current ledger and the truncated chain, synthesize a temporary pseudo-genesis block to append to the back of the current chain (pretending, in effect, that the system just came into existence at the current hour in the current state.) This could make it possible to bootstrap a new node without having to archive the full historical chain anywhere.
If the previous strategy is not possible, and if the full historical block chain absolutely must be preserved within the system, a fallback strategy would be to do so as a distributed archive, something like the way a RAID hard-drive array works. Some number of encrypted copies of every block (perhaps 10?) could be randomly distributed among the active nodes; thus, rather than the whole chain, each node would need to archive only a small collection of (mostly nonconsecutive) blocks. The encryption key would be automatically generated within the system and would not be available to the users, but the system itself could nevertheless retrieve what information is needed to bootstrap new nodes. It would be exceedingly difficult and laborious for unauthorized persons to reconstruct the full historical block chain for stalking or spying purposes--they would first need to sift through many nodes to get all the data (lacking the index to do so quickly) and then they would need to decrypt the result to obtain usable information.
The privacy protections could, in principle, be thwarted if some independent operator with a large computer decided on his own to archive a full, unencrypted copy of the chain. There is no way to prevent this, but such unofficial copies would have no operational connection to the system, and discovering them (if they exist) might be no trivial task for the would-be cyberstalker.
Assuming a hard-capped currency, at launch the full limit of coins would reside in something called the uncreated balance (this is a bookkeeping abstraction, not an actual address with real currency in it.) Every month, coins equal to some percentage of the uncreated balance would be generated and distributed by an algorithm equally to every active address (more anon about what that is.) How large the percentage is depends on how much one wishes to favor early adopters; I leave that debate to others. The induction period lasts until almost all of the original uncreated balance has been converted to actual coins in circulation. Although I am not wild about the idea of transaction fees, some small such fee is probably needed to discourage transaction spamming. Collected transaction fees would be extinguished and their eqivalent value credited back to the uncreated balance. (If a soft-capped currency is desired, it can be achieved by allowing the uncreated balance to increase according to the algorithm of choice.)
To deal with the issues of lost and found coins, addresses would be divided into active and dormant categories. An active address would be defined as any address which, in the past five years, has either participated in any transaction or has had a node active which possesses its private key, even in the absence of a transaction. After five years of no activity, an address would be reflagged as dormant. A dormant address would be ineligible to receive distributions and would be subject to a 10% annual dormancy fee. After ten years of no activity, an address would be presumed dead and be expunged from the ledger, its remaining balance extinguished. Dormancy fees and funds extinguished from dead addresses would be credited back to the uncreated balance. Note that anyone wanting to keep an address flagged as active must merely do something, however trivial, with that address every five years. If activity should be detected at a dormant address, that address would be reflagged as active. While no system can infallibly differentiate a dead address from one merely not in current use, this would be a reasonable solution in practice; few holders would intentionally let the status of an address lapse if it is so easy not to do so, and there would be little risk from the sudden resurrection of fossil addresses with large balances as they would rarely exist. As an additional measure, I would recommend that anyone controlling an address with zero balance be given the authority to manually expunge said address from the ledger if desired for privacy and security reasons.
The volatility issue is a more difficult issue to confront, as it involves the human judgment of the value of a unit of currency, something that is subjective, extrinsic, and invisible to the system itself. There is no way that the mathematical algorithms running the system can directly know how many of its units are considered equivalent to a dollar, a euro, or a loaf of bread at any given time (and allowing humans to communicate this information manually is a non-starter, as it invites meddling.) A hard-capped currency, furthermore, has no credible tools to deal with valuation issues even value could be reliably communicated to the system (proposals of adjusting the mining difficulty of mined currencies are almost certainly futile, as most speculators are not miners and would be unaffected.) A soft-capped currency might offer more hope in this respect, given the right kind of algorithm. Although unit value itself cannot be directly quantitated within the system, there are definitely patterns of behavior associated with rapidly rising and falling value. For example, a pattern of many new addresses being created and mainly receiving deposits while making few or no disbursements, together with a pattern of transaction size and frequency, would be a signature of bubble conditions, and this would be detectable by the system; conversely, a wave of large transactions involving many or most addressess accompanied by a below-average address creation rate might be a fingerprint of a crash. It is possible that statistical analysis would reveal that there are unique patterns of average transaction size which, in stable times, would give a good approximation of absolute unit value (generally, larger average transaction size correlates with lower unit value and vice versa.) One may speculate that such strategies might provide a soft-capped system with good enough information to implement a flexible monetary policy which would have the ability to flood the system with extra currency units (by increasing the uncreated balance and/or the percentage disbursed per month) when bubble conditions were detected and to withdraw units (by suspending distributions or reducing the uncreated balance) if a crash is detected. Long-term algorithms could still nudge the system toward either constant money supply (a parameter directly known by the system,) or toward constant inferred unit value when the system is not responding to a strong short-term challenge. If any version of these strategies is feasible, it could be a step towards a real "smart coin."
In conclusion, a next-generation cryptocurrency would be one which preserves as many of the desirable attributes of FGCs as possible, while avoiding some of the pitfalls inherent in current systems. Since the full historical block chain is no longer actively kept on every node, the system is more scalable without forced centralization, and there are fewer privacy issues. Since there is no mining and thus there are no miners, there is less parasitic computational overhead, and the entire issue of ever-more-costly mining hardware is moot. Since the contents of dead addresses are recycled, there is no issue with lost and found coins. If soft-capped, it might be a "smart coin" as described above, and we might also assume a block creation rate somewhat higher than common today, though the 20-second goal might not be feasible with current technology.
