It is often lamented that the modern system of elections is broken, at least when one means simple universal franchise for selecting office-holders. Some of the complaints against the system are age-old, such as the observation that he who promises everything to everyone (regardless either of capacity to deliver or of any negative consequences of trying to deliver) has an unfair advantage. However, in recent times, the system has suffered increasingly from additional woes. In today's world of sound-bites, mass-media fascination, and saturated attack campaigning, it has become increasingly dysfunctional--those we choose to lead us often effectively win elections by an auction process, victory going to the highest bidder, with grotesque amounts of wealth expended on campaigns which are all about subliminal manipulation and have next to nothing to do with the actual merits of the candidates. Worse, the system often selects for individuals of sociopathic or psychopathic tendencies, and frequently maintains them in office indefinitely by means of gerrymandered voting districts--a perfect recipe for unwholesome control and domination by entrenched special interests.

Traditional alternatives, however, have not fared much better: hereditary monarchy, military dictatorship, and so on strive for the Platonic ideal of the "enlightened despot," but this proves to be a mirage; for a society to play no role at all in the selection of its leaders leads nowhere productive in the long run. For every Augustus, you get any number of Neros. Limited-franchise republics (restricting the vote to a certain class of society, such as in apartheid South  Africa or Israel) have their own issues with the creation of permanent classes of disenfranchised sub-citizens; there is a tendency for such underclasses to fall into poverty and exploitation, and a substantial portion of the population feels (correctly) that they have no stake in society as it exists. In addition to social-justice issues, this is destabilizing for a society.

There is, however, another idea out there, and quite an old one at that; some have alleged that it actually was implemented in ancient Greece, though other historians disagree with this claim. Whatever the historical reality might have been, the system as described has two stages. A candidate wishing to stand for a public office must submit first to some sort of pre-screening test. At the minimum, this must weed out those aspirants who are obviously unfit for duty due to such things as mental handicaps, illness, emotional instability, insufficient understanding of the requirements of the office, and so on. This could take the form of a written examination, or some other type. (one can also imagine variants where the stage 1 screening is more stringent to varying degrees.)

In the second stage, the winner is selected from the candidate pool by means of a lottery or equivalent random process. Since there is no way to influence the outcome of a lottery by campaigning or psychological tactics, campaigns would be pointless, and it would be far more difficult to win an office by sheer force of money spent; having a powerful party organization behind one would not ensure victory. Since the probability of one person's winning a lottery more than once is quite low. there would be no need for explicit term limits, and geographical district boundaries would also have little effect on the probability of winning. Because most persons would be eligible to stand for office, there would be broad participation and stake in the system.

This idea, of course, is not immune to potential problems of its own. For example, it does not dovetail well with the prevailing parliamentary model on which most republics are constructed, dependent as it is on dominant party factions or simple coalitions to function smoothly; nor is there any obvious equivalent to the snap elections which happen when a parliament is dissolved (a US-style congressional system might be a better match, but this paradigm is unfamiliar to most of the world.) There is also the issue of whether the impartiality of the first stage could be adequately secured; if a way is found to corrupt this stage of the process, then the system fails quickly. Yet elections themselves are often rife with corruption or error, so the question to ask is which process is easier to secure against corruption.

It is interesting to contemplate whether he system outlined above might be a better match for the political realities of the 21st century than the existing electoral system. At the very least, it would appear to be less expensive than traditional voting, and to spare us all the bombardment of obnoxious campaign advertisements that occur all too regularly.

Concern has been expressed that the transparent block chain of most first-generation cryptocurrencies ,which allows complete public analysis of every transaction ever made, presents an undesirable privacy and security risk. Systems which periodically prune the block chain, discarding old blocks no longer in active use, might mitigate the problem slightly, but only if it is assumed that no one is keeping unofficial off-line archives of the entire chain (an assumption which may not be valid.) One way to address this might be to use what I would call an opaque block chain. Such an entity would be engineered and encrypted such that:

-The private-key holder of a given address could view the contents of that address, but no one else could (or even prove that any specific address exists for which s/he does not have the key;)

-The sender and receiver of a transaction could view the transaction data and transaction ID, but no one else could (or even demonstrate that a transaction occurred;) when the block is finally pruned, the ability to view this data would vanish.

-The system as a whole might, if needed, have some internal master key giving it the ability to access all the data in the block chain, but such a key would be purely internal and no human being would know it or be able to extract it;

-Some limited statistical data such as total hashrate, total units outstanding, number of active addresses, etc. might be still publicly viewable, but no data concerning individual addresses.

In addition, if it is a concern that computers running Shor's algorithm might be able to break the encryption, a layer of encryption using a Shor-resistant protocol (such as Ntrue) might be considered.

With all the new cryptocurrencies coming out almost every day, it seems, one would hope that a few might consider these recommendations.

I notice some  stabilization in value in the last two weeks, very welcome after the roller-coaster ride since January. Could it be that many of the speculators have largely gone over to the alt-chains, hoping for an easier killing there? That would be an interesting development.

One of the most popular ideas these days is cloud storage--online storing of data, usually by central server owners such as Google, Amazon, etc. Although the idea continues to gain in popularity, concerns have been raised about the privacy and security of  data stored this way. Suppose this task were handled instead by a distributed, encrypted archive hosted in nodes analogous to those used for Bitmessage or cryptocurrencies. Suppose further, if you dare, that online utilities analogous to Google Docs, Google Presentations, etc. were co-implemented with this scheme. Is this mere fantasy, or could it actually work?

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.

I noticed something interesting during the latest BTC crash, looking at charts on btc-e. Major alts such as LTC, TRC, etc. seem to be replicating the crash almost exactly (i.e. their exchange rates versus BTC are basically flat, indicating that they are crashing in precise unison.) Only NVC shows a hint of independent behavior. I have no information about minor alts such as FRC, BQC,  or XRP; perhaps those graphs (if they exist) would tell a fuller tale. Yet these various currencies tout themselves as being different than BTC (one hopes in positive ways.) Have they succeeded in being perceived as any different, given what we have witnessed? Do they really have any independent existence in the present environment?

This may be a concern more future than present, but it would seem to be possible for blocks in a system of increasing size eventually to contain so much transaction data that many nodes can no longer download them as fast as they are created (i.e download time starts to exceed 10 min/block.) Whereas the system at present seems to depend on most nodes' being synchronized and aware of the entire block chain, this synchronization would no longer be possible under such circumstances, and that this could have adverse consequences. Nodes having the least feed bandwidth would be expected to encounter the problem first. Any thoughts?

Most of you have probably heard about the shenanigans in the Bitcoin block chain recently, where an incompatibility in client versions briefly forced an uncommanded fork in the block chain. The situation seems contained, but questions remain. Since most of the alts use a very similar block chain, and their clients are near copies of Bitcoin's, how vulnerable are they to this same problem, and what could realistically be done about it?

The last few times I have tried to use Coinbase to get BTC, I have received messages that they have "exceeded their limit for the day." What gives here?

I assume there are two ways to do this:

1) Have payer send Bitstamp (or comparable) BTC IOUs to your Ripple address; or

2) Have payer send BTC IOUs from his Ripple address to your Bitstamp address, where they actualize as real BTC.

Am I missing any possibilities? Which one of these strategies is faster or better?

I have  been noticing that there are a lot of posts about Ripple on this particular board. Just saying...

I have noticed that some QR codes presented by merchants for payment encode not only the destination address, but the amount of the transaction. This is, I am sure, meant to be a convenience for the buyer. However, it would be quite easy for an unscrupulous operator to encode some much higher amount than the legitimate price into the QR code, thus scamming an unwary customer. In a system wherein charges are difficult to reverse, and wherein many wallet programs lack a confirmation dialogue box, it would behoove all to be wary..