The Chinese exchanges are slamming Bitcoin, sending the price up and down $35 in five minutes. That is 10% of the price.

The whole Bitcoin network is controlled by four mining pools. MtGox went down, as hackers bribed or hacked employees of MtGox, to gain control over servers. 850,000 Bitcoins were stolen. A person infiltrating merely three or four mining pools can perform a double spending attack on massive scale and there is a very significant financial incentive to do so. The operators of some of the largest pools are known scammers.

Bitcoin is still growing rapidly and gaining momentum, but we need realistic worst case security analysis. None of the altcoins are "competing" with each other. Its going to be a mix of coins going into the future. Dogecoin moved a mass of people into cryotocurrencies that were not interested in Bitcoin and each additional coin will expand the audience and market.

This is the third cycle. The price goes up to new heights, then there is a long, decline and hashing rate falls, miners get shaken out. Price falls as miners are selling mined coins to pay electricity bills and eventually miners start to shut off hashing power. Then the price shoots up and the media goes into a frenzy, the public gets interested because everyone else is getting rich and they are jealous, the price continues to climb, hits a hysterical peak and the settles significantly above where it was before.

Bitcoin could hit $5,000 or $10,000 in the next cycle. However the peaks and bottoms have been leveling out. The ratio of peak to bottom for first media cycle was over 150x if I remember. Then second was 35x, then 15x. The recent one was $1200 to $300, so was 4x difference between the peak and bottom. As the price goes up, each peak requires more and more money to drive.

There are scammers out there with 850,000 coins from the gox raid and they will want to cash out. That is more coins than the miners are getting and the price heavily depends on how fast they try to cash their coins out.

This is an amplitude modulated software defined radio for the whitespace band. 100 Mhz to 700 Mhz carrier. This is the most simple type of radio possible. Its pretty trivial.

Can you hook up an FPGA, maybe one on an ARM development board to an CPLD. We need to take a 600 Mhz to 700 Mhz carrier and amplitude modulate it (multiply the amplitude of the carrier by a value, which changes and can be set). The CPLD needs to implement a Digital to Analog (DAC) converter and then amplitude modulate the carrier. Then this gets amplified and is connected to antenna.

Then we need a Analog to Digital (ADC) implemented on the CPLD for receiving radio on other end. Changing the ADC/DAC 20 million times per second with a 4 to 8 bit ADC/DAC resolution is sufficient for now. A fulll 300 Mhz is ideal, but may not be possible without skillful pipelining.

For example. On beagleboard black, there are ADC/DAC units on the real time units. We can set output to "8" and then voltage level 8 comes out, we feed that into the gate on the amplifier. Then a ~50 Mhz HAM frequency carrier comes in to amplifier and is amplified an amount depending on voltage of gate. Then we change the 8 to a 40. With the real time unit, we can do that ~1 million times per second. Then the value gets amplified, fed into antenna and we are transmitting a sin wave with height 8. We have an array of bytes, one byte is read in a at a time and sets the output  value of the DAC, which updates 1 million symbols/second. So we are signaling with radio. This is same thing, except we want the ADC/DAC in the CLPD, so we can do hundreds of MHz and later modulation of the carrier twice per Hz, with changes applied at the zero crossing.

Eventually we want modulation at two symbols per Hz, so 1.4 billion times per second for 700 Mhz carrier (one output for positive part of sin phase and one for the negative phase) with 8 bit resolution for DAC output and +8 bit for ADC reception (or whatever is feasible). The value change for the analog output should occur at the zero crossing of the carrier, to prevent snapping. This will probably require moving the CPLD to ASIC to operate at this baud rate.

At 700 Mhz, with two 8-bit symbols per Hz we are at 11.2 Gb/s for maximum rate (two 8 bit symbols, 700 million times per second). That is the data rate for CPLD to the FPGA. Because of noise, antenna ringing and requirement for forward error correction (100 bits may have to be sent for each received bit), the data throughput may be significantly less than the symbol baud rate. The ASIC version may need a hardware IO protocol (PCIe or other) to interface between the CLPC/ASIC and FPGA at this rate. At those data rates the forwards error correction will need to be implemented in the FPGA, but CLPC prototype may be low enough baud rate for this to be performed in software. We are assuming that directional antennas are used and that the target signal is the loudest signal received, which significantly reduces the resolution requirements on the ADC for reception. Very simple circuit. We are not sure if phase locking or ability to set phase offset is a requirement.

Eventually the FPGA and CPLD, frequency generation and amplifier should be on a single PCB. The FPGA should implement Unipro so we can plug it in into an ARA baseboard. This is the end-target, but prototyping with ARM+FPGA dev board may be easier, or you may have better solution. Alternatively, the first device could be an CLPD + FPGA with a USB interface. Whatever is easier, you probably have a USB FPGA core already. The control board or system should use a Debian linux.

We can provide software in C for an initial forward error correction code. This can be on CPU initially, but move to FPGA is later required to handle full data rates (which may not be hit by the CPLD).

We understand the CPLD can go to 300 Mhz, so 300 MHz modulation of the carrier wave may possible without going to ASICs. Higher frequencies may be possible by including multiple copies of the circuit, with clock skews. For instance, having one DAC for the positive phase and  one for the negative phase. A simple CPLD design should be able to achieve a symbol rate of a few dozen Mhz. The ADC needs a floor and max and adjustment to bring the signal within range. This needs to be changed seldom (assume as most 1000 times per second).

I would get it working with a 1-bit or 2-bit ADC/DAC block on the CPLD and then go from there. Alternatively, if there is a very cheap ADC/DAC chip that can handle these ranges or 3 samples per second at 1.4 Ghz, we could use that and wire it into the FPGA. I have feeling that DAC/ADCs chip rated at the required sampling rate are $100 and that getting board down to $20 will require a degree of ASIC integration in the analog frontend.

So the objective here, is to get a lower frequency prototype working in CPLD
- to reduce risk for doing MOSIS/ASIC prototype that can handle full rate and higher resolution in the ADC/DAC. The symbol baud rate for the ASIC version may require integrated hardware IO pin for interface to FPGA, but is otherwise the same.
- then if that works, get a few wafers on an older process
- to have something working early, so that we can distribute dev boards and start on software development and prototyping, antenna development

That is first generation. Second generation
- multiple DAC/ADCs for running multiple antennas
- digital delay line (same signal from each output, but with defined phase shift and amplitude change) so that we can do phased array
- low frequency control or modulation of phase shift (to allow phase locking, reduce interference between transmitters)
- two antennas can resolve or filter on direction from phase shift of signal received by two antennas at a separation.
- N antennas elements each making independent reading of same signal, helps reduce noise floor.

Yes. We have a bunch of volunteers and people helping. The development will be opened up in the next stage. Right now, we have more developers than things to do.

Right now, we have the following three priorities
- consensus needs to be finished (someone is working on this and its fairly specialized). Its phd level research, trial and error. Its ready to move into the codebase, except for a networking library prerequisite.
- the coin is ready to launch
- the software/networking for darknet needs to be finished, which is specialized. The bottleneck is the protocol design, not implementing it. Once the spec is on paper, anyone could implement it quickly. We decided to cut corners if its something we can fix later, to get it working quickly. So we are ignoring problems like designing the protocol to allow establishing a N-hop route without incurring round distance time between node. That will be something someone can figure out and add later.

Those are the three things we are focused on, with our limited resources right now. What comes afterwards, will require a larger number of developers and there will be many smaller projects that need to be done.

For instance, once you can publish data with your public key and have it peer-to-peer replicated, then you will want to do something like implementing Twitter or Blogging over that. Once the darknet works, then you will want to do instant messaging. You will want to be able to tunnel all your traffic over it and use it like a VPN. You will want improved routing service that find faster routers to target nodes. You will want to bundle multiple routes together for performance or latency. You will want to be able to publish websites or services on the network.

The overlay network will be running on software, over the normal internet. Then you will want to add mesh or physical links and that is when the hardware meshnet can start. Then there has to be antenna development, hardware development projects. We have to find people who can do hardware. This is when money helps, is for funding this.

So we are entering a phase where there will be a lot for developers to do. Right now we are only working on those three things.

There are different parts.
- the cryptography (done; this was months of work)
- the networking for blockchain/transaction replication (done; significant work)
- the design of the blockchain parser (done; this was months of work)
- the QT webwallet, with embedded HTML/QT (done; was hell to get compiling on three platforms)
- the consensus algorithm; open research project, took two years of work. Requires bench-marking, testing, validation. Almost done but not implemented or validated in full, but at stage where it could be implemented. There are several candidate algorithms that converge and are suitable and we are testing them.
- the protocol for privacy preserving connection oriented source routing. no one uses this method in networking and its a substantial research problem. There are DDoS issues, spoofing issues and hundreds of details that cannot be worked through quickly. Merely figuring out how to achieve paths in network is an open problem. Just getting it working required inventing and implementing a new type of distributed hash table algorithm.
- there is the design of the application level interface for the network. If it is as difficult to embed as tor, or poorly designed it will significantly hamper network adaption and application development.
- then there is hardware. as soon as we had prototype working, we found out limitations. We were told by engineers that meshnets would not be viable on 2.4 Ghz and ignored them, until we had to confront range problems in testing. So its easy to complain, about how long this is taking, but waiting is easier than learning Verilog and implementing direct digital synthesis on a CPLD.

Passive speculators do not add anything.

OP SEC. The coin was done in January. The only difference if we launched today would be the coin would be trading. There are a few things missing on github, so no one can compile it and launch it before us, without knowing how to program.

For 2015
- we would like to have networking working for the darknet/meshnet.
- the new consensus algorithm will be implemented
- we would like to have some written standards for what is done and tutorials for developers
- then we have to do hardware
- we are deciding the roadmap for the next phase of the project.

If you look at Bitcoin, there are less then three people working on it. I would say three people but only one person at a time. People come in, finish something and then leave when its done. It took Bitcoin about a year to implement headers only downloads. "Ok we finished Litecoin!" What do you do after you finish Litecoin, Dogecoin or Ripple or anything else? There is no programming or design left, its just marketing. Pump and dump. Every existing altcoin is a pump and dump with no long term viability.

To survive and grow, Skycoin needs to meet a higher standard than other coins. Skycoin has to be useful. It must satisfy a need. It has to breach the great firewall. It has to make meshnets viable and offer an alternative to monopolistic ISPs. It needs to be an effective response to the encroaching threats on the internet. Skycoin needs be able to survive and carry on if Bitcoin fails for internal or external reasons.

People are measuring the success of Bitcoin or Ethereum in terms of piles of cash, instead of impact. They are asking whether Bitcoin is at $300 or $1200 instead of asking what has it changed and what impact it has had. Today Bitcoin was effectively banned in Australia. Bitcoin is being taxed at purchase and double taxed at the point of sale. The tax treatment is so punitive that Bitcoin has been effectively driven underground in Australia. It took five years from launch, until the first government decided to regulate it to death. If we released everything today and the meshnet hardware and software worked perfectly and it was mature, it would still be five years before the node density was enough to threaten ISPs or cell phone companies.

Similarly, Bitcoin survived for five years but we did not know that the mining process would continually drive down the price. We did not know that if miners are spending 100 million/year on electricity and ASICs, that people must buy 100 million/year into Bitcoin to just keep the price where it is against the miners selling Bitcoin. We did not understand the security issues.

Instead of coins with longer term duration, the vast majority of coins have lasted for significantly less time than Bitcoin. We have not seen a single coin that is as solid as Bitcoin, in the last five years.

Pump and Dump.

New Bitcoin Security Problem:
http://joncave.co.uk/2014/08/bitcoin-sighash-single/

If you create transactions and then send them off to a remote server for signing before injection, coins can be stolen.


Yes. Even Ripple. Even if the devs own 98% and the community owns 2%, the devs can still benefit from pumping up price if the liquidity is thin.

What makes me the most sad, is that there are developers who bought in to Bitcoin at pennies. They made a lot of money already and very few of them gave back to the community or created something that moved the community forward. Everything is a money grab.

We have hundreds of money grab altcoins. Gimmicks. Whole cartels devoted to pump and dumps. Bitcoin is still in a penny stock and show pony, gimmick mentality. The Bitcoin ponzi fund, may stolen an eighth of the total Bitcoins in existence. Many of the early scams each individually netted over 200,000 Bitcoin, while Bitcoin was below a dollar.

An eighth to a fourth of the total Bitcoin is possessed by scammers if they didnt sell it off. The other half is lost, as the private keys were lost when early wallets were deleted.

People are launching exchanges, to manipulate altcoin prices. There is no standard for storing coins, checking balances or injecting transactions across different coins. The exchanges know the speculators are not running the wallet for the twenty coins they are speculating on. They know that only a fraction of the coins will ever be withdrawn, instead of being liquidated for Bitcoin. They know how much manipulation they can get away with.

Scammers gonna scam.

...

The Obelisk/Darkwallet team has been the only one pushing Bitcoin forward in terms of standards. They could not even raise $20,000 compared to the millions that other projects have raised. Then you have RoboCoin. Everyone was excited about the ATMs, but it becomes a money grab and they decide to centralize the system and their system ended up being inferior to the open source ATMs. Biometric palm vein readers that are so invasive its something out of a dystopian scifi novel. In 2030 you wont need Bitcoin because cash is illegal and you dont need to carry around credit cards because you just have to put you hand under the Visa™ biometric palm vein reader after Visa™ buys Robocoin.

Coinbase has done a very good job. Bitpay has done very well in building a sales force and signing up Microsoft and the New York Times. sipa has improved Bitcoin with his libraries for deprecating OpenSSL and now headers first downloading. So Bitcoin has pushed forward, but we have not really seen the community come together and address the problems facing Bitcoin. It cannot organize on the scale required. We have not seen many Satoshi level technical achievement. Satoshi was brilliant, in terms of integrating existing ideas into something new and using the tools available to get it done quickly.

Bitcoin in Perspective

So Bitcoin has pushed forward. However Satoshi is gone. There is no leadership or direction. Bitcoin is facing existential threats and the response has been underwhelming. Bitcoin as a technology works, but has some rough edges that cannot be fixed without a hard fork and therefore will not be fixed. However, the most daunting issues are social

- mining pool concentration (control of the network by half a dozen people instead of 10,000 or 100,000 people)
- continually declining price from the creation of new Bitcoin. If 100 million newly created coins are being dumped per year to pay for ASICs and electricity, the public must buy 100 million in Bitcoin per year, just to keep price where it is. The higher the price goes, the more people have to buy in per day, to keep it where it is. Bitcoin is very similar to gold, in that price increases, increase output and create a price ceiling (previously unprofitable gold mines become profitable as prices go over certain level). The Bitcoin price may continue its current decline, forever unless people can be convinced to pump more fiat into Bitcoin.
- the short term "get rich", mentality. No one is in this for the long term. As soon as Dogecoin became successful, it was colonized and destroyed by scammers. There is a level of imperialism, where projects are colonized by people who can best exploit or monetize them.
- exchanges are allowing free trades. They are offering substantial leverage and bots are driving price up and down $30 in five minutes. They drop price to attract buyers and then yank the price up to attract sellers. This is great for day traders, but frustrating for anyone serious about Bitcoin commerce. Exchanges may be manipulating price.
- I cannot tell if the teledilidonics "proof of sex coin" is real. I cannot tell the new altcoins apart from parodies anymore. There is an altcoin that makes miners input captchas every hour to prove that they are human.
- There is still significant legal and regulatory risk. Corporations play realpolitik. They will say "We support Bitcoin" while drafting legislation in secret to destroy it, that the politicians then pass off. Whenever a politician appears with a bill, it was usually written by a corporation or group of corporations in a trade association. The Bitcoin regulations are being written by Visa, Mastercard and Western Union.
- immaturity. The security oversights at MtGox were unacceptable. The drama at Ripple and disregard for fiduciary obligation to the asset holders, over a petty personal dispute (no one uses Ripple so this can be overlooked).

I think Bitcoin has a very strong appeal, because it is redecentralizing power and giving people back control that has been forcefully taken from them. It has survived on its psychological appeal. It is a political technology.

What is Money?

There are two aspects of Bitcoin. There is a idea of "technological determinism" and that it was inevitable. The idea that technology is a force of nature that shapes society and determines its rules. Then there is Bitcoin as a political ideology of liberation. The idea that Bitcoin can liberate us from the power of control, the fines, the fees of oppressive financial institutions.  Institutions which were imposed upon us and whose power over society allowed them to outlaw or marginalize alternatives.

In history there were hundreds of currencies within each nation state. As the nation state grew in power, it outlawed competing currencies. Community currencies and regional currencies have arisen very frequently, rapidly grown and then collapsed. The majority of the collapses were from the corruption within the administion of the currency. They would print and debase the currency without limit. Bitcoin was the first system, where the rate of currency creation was defined by mathematics and no longer at the whim of the administrators.

There is a technological aspect determining the properties of the asset, but there is also a sociological aspect concerning what drives adoption. Why do people adapt community currencies? Why do they arise, why do they grow, what would happen if they dont collapse for internal reasons (do they get crushed by the state)?

Then there is a question about what currency is.

Free Banking:

Currency is credit issued by a bank. If you have a dozen banks, each issues their own bank notes (fiat, cash). If a particular bank is in default or shaky, then their bank notes or deposits may trade at 80 cents on the dollar, against notes issued by another bank. If the note is redeemable, for instance, for gold, and the bank makes bad loans and cannot honor convertibility then the bank liquidates and each person may receive 20 cents on the dollar in gold.

If the note is not redeemable, for anything then it is not clear what would cause the price of the note to crash. It its not clear the note would be worth anything. There is no basis setting the value of of the notes from a particular bank. If we have one hundred banks, issuing their own currencies, we initially assume the $1 nominal unit on each bank note from each bank are equal value. However, one bank may issue a thousand times as much currency as another bank. They each have an incentive to print money. If the value of the notes of each bank were equal, then inflation would cause the currency to be worthless.

Central Banking: Single Nation

A central bank, is a nation state, that creates money. It delegates sub-banks and sets the rules these banks may create money through. The central bank may say "You may create $8 in loans, for every dollar in deposits you have". A more complex system is "You can borrow up to $8 from me for every dollar in deposits, at an interest rate I set" The bank will add 2% to that interest rate for the loans it makes. So there is some constraint on money creation. However, if you model this system you have producers, you have commodities, you have labor and wages. As labor save up money, they put it in banks and it expands the monetary base. It keeps a certain level of unemployment to keep wages down, it privileges the producers (the people who derive income from buying commodities and labor for production).

The central bank can create money, but the exponential expansion of money from the money multiplier prevents this from being effective. Every dollar the central bank prints, ends up in deposits, which then creates additional dollars through loans the sub-banks make. So instead the central bank sells bonds. The central bank has an interest rate on its bonds and people will tolerate a 2% inflation without feeling trauma, so the central bank can inflate away and continually roll over its debt (sell new bonds, to pay coupons on old bonds).

If wages are increasing faster than commodity prices, then the central bank can hike interest rates, cause inflation and drive up unemployment and drive the wages back down. Inflation increases the supply of money, so workers can buy less goods, commodities for the money they have or wages they earn, therefore demand for goods decreases, produces cut back production and lay off some workers who become unemployed. Competition between the employed and unemployed, keeps wages from rising against commodities if the policy is set right.

Without this type of central bank policy, labor is finite and a fixed factor like land, which competes for uses. Social factors like unions come in and the power of labor increases disproportionately with its scarcity, compared to a commodity which is not governed by social factors.

If there is technological progress or GDP growth, it means the price of commodities is decreasing relative to labor. The labor is producing more and more commodities each year for the same input. So the central bank keeps the wages and commodity prices in line. It creates a fixed basket of goods and calls this the CPI. The CPI is the nominal cost to buy the basket of goods. The central bank keeps the CPI to wage ratio fixed, even as wage to GDP falls and as the labor hours, capital equipment and fix factors required to produce the goods in the CPI basket falls.

More and more goods will be produced for the same labor, but wages are kept down so that a worker has to work the same number of hours for the same amount of commodity. Then the surplus is consumed by inflation (debasing the national debt). As long as the rate of productivity growth + inflation is greater than the interest on the government debt, the debt can be rolled over forever. The relationship between wages and commodities can be held at stable levels.

In this model, the government raises money through debt. The banks, government and producers (corporations or owners of cashflow) have mutually beneficial relationship as allies against the population. The banks receive privileged ability to make loans in excess of their actual capital through the government (which corporations or other entities are not permitted). The producers receive cheap docile labor and privileges, subsidies, contacts from the money created through government debt and the government receives the privileges derived from control and administration of money created through such debt. The government also taxes.

For large companies, with influence the nominal tax rate is often very less than the benefits, subsidies and revenue derived from the government. The burden falls on the workers and the smaller corporations. This is true in the nations both with the least progressive and most progressive tax schedules.

Central Banking: Multiple Nations

Multiple central banks with a one bank per country is similar to free banking, however the nations now produce exports and therefore have a reason to buy each others currencies. The currency price can now float and be set by a market.

Nations must keep wages low, so they can produce goods cheaply for export. If they nation produces goods that can be exported, then foreign nations must buy the currency to purchase the goods. If a nation's currency is too high against other currencies, a nation can devalue the currency through domestic inflation. Having a cheap currency relative to other currencies, means that a nation's labor and outputs are cheap compared to other countries. Nations may engage in competitive devaluation, to make their exports cheaper than other nations to grab larger market share in particular markets.

Nations can perform a "floating peg", by acquiring other currencies or assets and then buying/selling their own currency to maintain the price level relative to another currency or improve stability of the currency against spectators.

A country may maintain a peg against another currency, by printing money and dumping it on to the international markets, when their currency increases relative to the pegged currency. A nation may also prevent its citizens from exchanging domestic currency for foreign currency to buy imports and then hoard the foreign currency gained from exports, for other uses.

Note that a country mostly performing mineral extraction (primary sector) and creation of goods from these extracted resources (secondary sector) is isolated from changes to its foreign exchange rates. Both its costs (labor) and its commodity inputs are priced in domestic currency. A country reliant upon foreign mineral inputs or manufactured goods, has a domestic economy with input costs which are dependent on its foreign exchange rates.

Note that inflation in the value between the currencies of the central banks and inflation in the domestic economy are independent. The relationship is arbitrary, as the relationship between the price of wages/labor and commodities. If the domestic price factors are insulated from the foreign exchange rates

Brief History of Money

Before, the 1800s the dominant power center was land owners. They possessed serfs for farming land and a small military for war against other belligerent landed, freudal powers. They derived income from serfs farming land. Grain certificates served as first form of deposits and currency. Grain was perishable and could not be stored, so landed elites imposed non-perishable gold as standard, to allow wealth to be accumulated in a non-perish form. Combat was specialized, capital intensive, horses, knights and pike-man. The landed nobles were militarily significant.

The most powerful feudal lord imposed himself as a hereditary king. The king allowed feudal powers in his domain to engage war among themselves. The kind organized military excursions against foreign powers. The crossbow was developed, highly specialized knights were now vulnerable to being killed by peasants and lost their military utility relative to mass formations of peasant. Military power became a matter of population and military significance of the landed nobles declined. The king seized the power to dispose and allocate ownership of land and seized  taxation rights over the feudal estates.

Previously the king had only received income from primarily his land and estate. As the power of the state grew and the powers of taxation grew, a permanent state bureaucracy developed.  The power of the state bureaucracy grew, become absolute and was unaccountable to the people (but especially to the other power centers within the state). The French Revolution occurred and the state bureaucracy was dispossessed. This culminated in the era of Napoleon around  1795 and resulted in the development of the republic form of government and later republic democracies.

The industrial revolution occurred. A single factory in Britain could produce more textiles than could be consumed by the country. Britain developed a navy, occupied North America, Africa, India, China as colonies. Colonies exported raw materials to Britain and were restricted to buying imported goods from Britain. Britain used its military power to impose its currency and demanded payment in silver coinage for salt in India, to drain the country of wealth and precious metals. To obtain money to pay these taxes, Indians mined silver, worked as soldiers for the British occupation force or produced raw materials for export to the British mainland.

Similar, to America today, the British were not allowed access the mainland Chinese market. Chinese goods were in high demand and there was a persistent trade imbalance between Britain (importing Silk, porcelain, tea) and China which did not allow foreigners into its domestic market. Therefore the British invaded China in the Opium War and created a market for opium, to balance out the trade and drain China of its gold and silver.

The modern form of government and currency was formed in the Gilded age. The power and wealth of the landed, hereditary nobility had been dispossessed by technological progress. The factory owner and industrialist (producers, later corporations) exceeded the landed nobility in prestige, power and income and became the new dominant power center. The conflict was between the state (the political class), bankers (financial class), the producers (the economic producers) and the unions (labor class).

The economic class dominated between 1870s and 1920s. The economic class failed to retain power and a new economic class developed in collusion with the political class. The banking class gained new powers and the existing federal reserve system (single nation central bank) was put in place by 1930s, replacing free banking. The economic class defeated the labor class by 1970s, by targeting inflation rates to unemployment and taking over the labor party. The economic class moved to transnational production to evade control of political class and as leverage against labor. Domestic polices were pushed through internationally which benefited the power centers (banking, political and economic class) at expense of labor or domestic development.

Financial imperialism reigned. Privileged countries in the world system had low capital reserves requirements and could make large loans and perform domestic development and foreign investment, while lesser nations were subject to higher capital reserve requirements. Nations were made to take on debt in a foreign currency and then their exchange rate was debased (similar to Russia today). Highly leveraged, institutions from the privileged countries with access to cheap capital sweep in and buy up natural resources and revenue producing, productive assets cheaply (similar to the domestic oligarchs of the Soviet Union during the market transition). Privileged, indebted countries, with powerful militaries, large trade imbalances and few significant exports derived as much as a third of their visible corporate profits from financial imperialism.

By 2010, the domestic banking institutions became dependent upon government for survival (following policies mandated by the political class). The banking class became transnational and through crisis imposed the Basel agreements internationally, as the existing system faced collapse under persistent trade imbalances and speculative folly. The centers of power devolved and merged. The three power centers (banking, political and economic) are no longer district, nationally or internationally. There is no longer a center or power but an amorphous series of tentative and eternally shifting power relationships.

The state obtained absolute power of mass surveillance, media censorship, detainment. However enforcement is extremely selective and based up realpolitik. You are more likely to be arrested for whistle blowing, filming a factory farm (domestic terrorism), evading capital controls (domestic terrorism) or embarrassing a corporation (domestic terrorism), politician or government agency than for personal or political behavior, which does not threaten power. Any viable or even merely annoying threat to existing power or institutions will likely be labeled an unlawful terrorist threat and will be violently repressed.

There is now a unified, international banking regulatory body, which can decide in a secret meeting to merely threaten possible regulation and effectively cut Bitcoin off from every single banking institution globally (Outside of Russia, China and Brazil). This is a realistic assessment.

Europe is already banning cash. Europe cannot expand tax rates further without eliminating the possibility of untaxed underground economies. A further increase in taxation, decreases net revenue as more activity is driven underground or offshore. Bitcoin is similar to cash, but more docile and controllable. All transactions go through exchanges and can be taxed/monitored. Purchases online are taxed. When physical cash is banned in Europe over the next two decades, we will see a migration to Bitcoin but also a crack down.  Increasing government taxation over 40% of GDP, requires elimination of cash and international treaties against "tax competition". It requires that corporations are taxed for sales based upon the market rather than where the profits are realized.

Implications for Bitcoin

It is clear that money is a social construct. Money is the result of power relationships and relationships between institutions. Money is both social and is created by institutionalized power or social convention. Gold was accepted as a universal, voluntary social agreement. Government money since 1910 is backed by lead. There was a transition from coercive, extraction (the opium wars, colonialism) with voluntary adaption to both coercive definition and imposition of currency.

Bitcoin is therefore an attempt to return to the pre-1920s scarce, finite, "sound money" with voluntary exchange by social convention rather than coercive imposition.

How does Bitcoin fit in, with the history of money? What gives Bitcoin value? Will ability of people to adapt Bitcoin as a standard voluntarily, be hampered by coercion by the state, or interests within the state whose interests are threatened by Bitcoin?

In terms of strategic position, to force the hands of government, two things are necessarily
- the software has to be developed to the point, that it becomes feasible for small nation states to adapt blockchain based currencies as the national unit. This will force a uniform regulatory treatment between nation state and privately issued digital currencies.
- There need to be unified standards for interoperability between digital currencies. They need to be transparently convertible during a transaction at the current spot prices. This means any merchant or institution accepting one currency, effectively accepts all currencies. It produces a two-sided market and separates the attributes of currencies people use for payment and currency received as payment. Merchants may be required by law to quote prices in local currencies, but payments can be settled in any unit.

The original Ripple Pay (not Ripple), there was USD as the unit of currency. Banks create money through extending credit. The idea in Ripple Pay was to allow each person to extend create to each other in a peer-to-peer network. Each person acts as a bank and the bank is disintermediated (similar to Bitcoin). However, Ripple Pay was still pegged to the dollar.

Bitcoin is at one extreme, a finite, intrinsically scarce asset. The other extreme is decentralizing credit creation down to the level of a "personal currency", where each person is a node in a graph issuing credit to each other and there are floating exchange rates between the personal currencies. This is the extreme of pushing the free banking credit creation mechanism down to the individual. If you are running a coal mine or steel plant on that type of system, it would be interesting whether the price levels are stable and how it affects output level.

Ripple Pay type systems, need serious consideration as possibilities for eliminating the dependence of Bitcoin/Skycoin on the legacy banking system.

Update:

The Skycoin project is larger than "clone litecoin, change logo and call it Dogecoin". There are multiple parts and it took time from going from a single coder or small group of coders to a structure that can handle the multiple parts of the project. Then there is a larger architectural issue, about what the scope of the project is, what the long term goals are and what the objective for a second generation crypto-currency should be.

Just the coin itself is a massive undertaking. The scope and architecture of the coin has changed significantly over the last two years. Issues such as usability, what the API should look like, security issues, determinism, what the components are and how they should interact. During development we identified several hundred different aspects of the coin, which are individually very involved and each affected other components and design choices subtlety.

As an example, here is how our conception of handling the API/wallets evolved.

In Bitcoin you run a local node and it loads wallets from disc. The node authorizes transactions from the wallet it had loaded.
- this is simple, naive, it works
- it does not allow you to expose your node's API to network, to allow queries for thin clients without allowing other people access to your wallet
- it was designed for this use case, so the API is missing things, like ability to get unspent output set or balance for addresses in wallet

In Skycoin, we originally we originally intended to have ability to load multiple wallets and unload them and maybe a user system with permissions.

Then two months ago, we studied the Obelisk API. The API does not load wallets, but gives you functions for checking the unspent output set for an address, checking balances for address and injecting transactions.
- the API does not load wallets
- anyone can expose their node's API to the network and anyone can use it to check balances, get unspent outputs or inject transactions
- a client using a remote server or a local server goes through the same API

Then this creates a two layer structure. The first layer is the base API, maybe called the Node API
- check unspent output set for an address, check balances for an address
- given set of outputs, give me transaction that spends the outputs, so I can sign it with my private keys and inject it
- inject a transaction

The wallet, is at a higher level and keeps track of addresses and private keys
- the wallet queries for balances and unspent outputs
- the wallet creates transactions, uses private keys to sign the transactions
- the wallet injects the transactions through the base API

This may seem trivial. You have wallet and are checking balances and sending coins. It does the same thing. To the end-user it looks exactly the same as Bitcoin. However for developers it is a 10x improvement
- a cell phone, now only needs a json client and to be able to store and create signatures with private keys and has the capacities of a full node with a copy of the blockchain. This means people in Kenya, who cannot have the full blockchain can use it as effortlessly as someone in the first world with a local node.
- a user can have multiple wallets
- a small standard library for key storage, signing and API improves security.
- users who want to use default send can, while users who need to choose which inputs to spend and how can create custom transactions (which Bitcoind is unable to do)

This architecture is a very small change and its not immediately obvious that it is an improvement. However consider the following application and effort required to implement with the Bitcoin API, vs the revised API.

A person in Kenya with only SMS but not internet could potentially use the second API, even on phone with a 16 bit processor. A "Kenyan Wallet", might be all coins stored in single address, with SMS from a trusted gateway when a new output is received into their address. The SMS client would be notified when it receives new coins (outputs for its address), the client can say "Send 4 coins to XYZ" and then transaction and transaction hash is sent back (about 140 bytes), the client checks transaction, signs it with the private key stored on the phone and then texts it to gateway. The gateway then injects the transaction to the network. So we can do transactions in two text messages. The gateway can use the public key of the person to send the message encrypted for privacy, so no one but the user and gateway know what was sent, how much or to who. The cell phone operator cannot impersonate the gateway, without the gateway's private key. The client can verify the destination of the transaction and hash before signing it, so the gateway cannot steal coins or redirect them to another address.

With Bitcoin, implementing this application would require a full node-rewrite and then keeping it updated and merging in changes to Bitcoin. It would be a massive undertaking, just to be able to check address balances for an arbitrary address. With the second API, you have a small program that can create signatures with private keys, compute public key from private key and which stores the wallet. It may have to be ported to C to compile on the 16 bit phone but its trivial. Then you need to make the gateway check the balances with JSON query and inject transactions with a JSON query. Then the gateway, written in golang, needs a library for sending SMS messages.

Corporate Usability

Very small architectural changes have very significant impacts on the applications that will be developed. In particular, limitations of the Bitcoin API and usability considerations have driven merchants to use Bitpay. Few companies have the resources to do an independent implementation or modification of the full node, merely to accept Bitcoin payments.  A company embeds javascript, receives Bitcoin and gets paid in USD through a third party. This was not the original intention.

Similarly, most export company have multiple sales associates taking payments. They may accept Bitcoin, but right now each sale associate has to have their own node and receive payments and then funnel it into a corporate address. It is impossible to build the "user wallet" system a company needs to accept Bitcoin in an easy work flow.

The existing workflow in one export company, for accepting Bitcoin payments
- a customer contacts the sale associate and aspects for particular goods, with payment in Bitcoin
- a sales associate, receives a request for goods and creates an invoice in the company's invoice system
- then the sales associate asks a financial manager, for bitcoin address to give the customer
- then the sales associate receives the address and communicates it to the customer
- then the customer sends the Bitcoin payment for the invoice and notifies the sales associate
- then the sales associate (who doesnt know how to check if payment went through), asks the financial manager to confirm the payment
- then the financial manager communicates back to the sales associate that the Bitcoin payment cleared
- then the sales associate notifies the customer that their order is complete
- then the sales associate marks the invoice as paid, then forwards the invoice to the shipping and distribution department
- The financial manager is responsible for a certain number of sales associates, at end of week his invoices are added up and the Bitcoin balance received is calculated. Then that is transferred into a main company wallet.

This system is very complex, however it is designed so that the sales associate cannot steal the Bitcoin and so that the financial manager cannot steal the Bitcoin. There is a paper trail, showing how many Bitcoin were invoiced and should be in an account. The owner can check he is not being stolen from by employees.

Companies are eager to accept Bitcoin, but the process is frustrating. If the financial manager is sleeping, the sales associate cannot mark the invoice as paid and there are various complications. The account manager, doesnt create new addresses for each invoice, but reuses the same address for a whole week, then adds up the invoices at end of week to make sure balance adds up. If the balance doesnt add up, he has to go back through every Bitcoin transaction and there is a problem if the payment was split over multiple transactions.

Existing payment systems are very poor, but Bitcoin is still currently more frustrating. Bitcoin needs to be less frustrating, not more frustrating than legacy systems.

The company requires a way of having multiple wallets and restrictions on the wallets. They need to be able to associate individual addresses with transactions with invoices #s . The sales associate needs to be able to generate addresses for invoices and know immediately when they are paid, but should not be able to transfer coins out. Each company has their own system and integration needs to be something that can be implemented with low skill in PHP (most small companies do not have the developers required for a full node implementation). It has to be idiot proof. The company needs to know that if their server is secure and only the API is exposed, that the Bitcoin are safe and subject to certain guarantees. They will want the balance in online wallet minimized. Security has to be simple to achieve.=.

The system has to be simple enough that it is easily understood. One of the biggest failings of Bitcoin is that it is nuanced. It behaves in unexpected ways and requires too much specialized knowledge to use properly. None of the hundreds of people running Bitcoin sites, ever imagined that transaction malleability or signature malleability existed and even fewer understood what implications it could have. There was panic, fear, uncertainty. They began to be aware of how many factors were out of their control and in some sense that Bitcoin was too complex to be "knowable" without significant effort.

People expected that when they restored their wallet from backup, that the coins would be there. However, people with over 200 outgoing transactions found that coins were missing. They did not know that change addresses for transactions were going into newly generated addresses not in the wallet backups.

The requirements for usability, security are immense. The existing system of currency, transactions, commerce and accounting is being redesigned from scratch. In many ways, Skycoin is being crushed under these requirements. There are a few minor changes that may be made in future, but we believe we can now freeze out changes to the core architecture. The final coin, looks identical to the design three months ago but we are more confident that there is not a better architecture for meeting the long-term requirements.

Inflation

We have been debating whether a coin needs inflation for over a year. We believe any inflation mechanism in the coin, is a threat to survival on a geographic timescale. We are morally opposed to inflation and believe there will be temptation for future developers to increase or modify the inflation value in the future. Inflation privileges and empowers a single group, with the receipts of the money created through inflation. It creates a surface for attack. It also makes the performance of the coin dependent upon the competence of its management.

However, if 1% of currency is created each year and invested in activities that increase the value of the coin network, by more than the cost, then doing so maximizes the value for all coin holders. If $1 in investment in meshnet deployment, PR, advertising or lobbying nets $5 in coin market cap then coins which use this mechanism will out-compete coins that are unable to. The market-cap and values of coins pursuing this strategy will grow significantly faster than the alternative.

In this perspective, coins are like stocks or corporations and have issuance and redemption. A coin does not have profits or offer services directly like a corporation. The value of the coin depends on both its use as a standard, a store of value and in the skill of the managers and community in increasing the coin's long-term value (an investment instrument).

One possibility, is that there will be no universal dominant standard or store of value in the future. The relevance of gold as a standard and store of value over geographic time scales, may have been a sociological anomaly. The future may be a competing market of assets, whose prices rise and fall with changes in their relevance, utility and the power each asset has to impose itself.

For instance, gold acts as competition to state currencies. Before the federal reserve, mortgage contracts and loans were often defined against gold to protect the lender against inflation risk. In the U.S. in order to institute the federal reserve, to ensure control over interest rates it was made illegal in the early 1900s to benchmark loan interest rates against gold. The state imposed prices upon gold, determined its price and outlawed private possession.

Today, gold is just a commodity. There is physical gold and paper gold. If you own physical gold, the gains are taxed at income tax rate of 35%. Gold ETFs, gold stock and other paper gold are taxed at a lower rate of 15%. This is to punish people for holding physical gold. Paper gold is not scarce, it can be printed. There is significantly more paper gold than physical gold. Paper gold allows gold supply to expand on paper, with the expansion of currency, so that the value of gold no longer reflects the value of a scarce, finite commodity. Therefore modern gold, no longer represents a scarce, finite commodity or store of value in the full sense as its supply and demand may now contract and expand with fiat. Paper gold should trade at a discount to physical gold, to account for the risk of paper gold evaporating in a counter party default, however the tax penalty is so severe that all money is driven into paper gold rather than physical gold. Otherwise if the expansion of paper gold was too great and the discount on the paper gold was too large, people would demand physical delivery on paper gold to arbitrage and the paper market would collapse. The paper market is only stable, because holding physical gold is discouraged through a punitive tax treatment, which dwarf the spread between paper and physical gold.

There are different incentives and taxes a country can impose
- gold is inter-convertible to fiat at no tax (gold accuracy hedges against inflation, expansion of fiat)
- gains on physical gold are punitively taxed, but paper gold receives the tax treatment of other investments (paper gold supply on paper, expands and contracts with fiat and is an imperfect hedge. no longer finite or scarce relative to fiat)

In a unipolar world, where a single power can impose itself, fiat dominates and there is no standard of value or scarcity. Gold was a neutral, intrinsically scarce  standard of international trade settlement, between equal powers. Gold only dominated, in a multipolar world of international trade where no single power was able to impose itself over the world. Once in power, the alternatives were eliminated or neutered. There was no alternative to fiat.

In this view, assets are not neutral, passive stores of value but are imposed as power relationships. In countries with poorly functioning currencies, but strong states, like Argentina the currency is imposed by force. People try to escape the failing currency like the USD but dollar sniffing dogs patrol the borders waiting to confiscate gold and US dollars. Citizens in Argentina protecting their money in bank accounts abroad are charged with acts of financial terrorism.

In weak states in Africa, with failing currencies, the state cannot impose its worthless fiat and people turn to more stable currencies, such as the USD or bartering useful commodities such as tradable cell phone minutes. In the US, the fiat is imposed with incentives and structured designed so that even gold supply grows and contracts with the debasement of fiat. However, the rate is tolerable and the stability is sufficient.

This posses a difficult question for Skycoin. If assets are imposed by power relationships and no neutral, scarce "store of value exists". If value is a social construct, imposed by power then should Skycoin be a passive asset, an attempt at creating a neutral "store of value", a standard of exchange. Or should Skycoin be an active, aggressive, expansionist imperial asset which can defend and actively impose itself when conditions are favorable? This question underlies whether Skycoin, Bitcoin or any other cryptocoin can succeed.

What would an "active" currency look like

If the Bitcoin network spends $100 million on mining equipment and electricity, would Bitcoin be worth more today if instead that $100 million was spent lobbying politicians for favorable policies, on marketing, improving usability and creating software for replacement of the legacy system? The market cap of Bitcoin is over 4 Billion USD, but it can barely summon or coordinate resources on the scale of a much smaller corporation, to advocate for itself and its interests. Instead, Bitcoin sits passively as its enemies slowly redefine the legal framework under which it operates. Frameworks are made in secret, behind closed doors by the powers most threatened by Bitcoin and then imposed. Only after the rules have been written, are they shown to the community and then the consent and agreement of the community is demanded.

Bitcoin is only five years old and the majority of commerce transactions are being replaced by "Paper Bitcoin" held in Coinbase, rather than physical Bitcoin held on the owners computer. The companies accepting Bitcoin are using Bitpay and the coins are being sold immediately for fiat through a third party. It is a very small and minor step, to require merchants taking payments to clear the payment through such third parties in order to comply with KYC requirements.  Bitcoin will be allowed to exist in the first world, as long as it is irrelevant and remains restricted to a small group of the wealthy and highly technical.

Similarly, the dominance of MtGox, allowed Bitcoin prices to be run up and manipulated by paper Bitcoin and dollars that only existed in a database. An exchange with 12,000 Bitcoin can easily sell plus/minus 4000 Bitcoin and unless a run on the exchange happened, it would never be detected. An exchange with 10 million in cash deposits owed to customer can create database money and buy a few million in Bitcoin and it would never be detected, unless everyone tried to withdraw their fiat. There exist significant scope for market and price manipulation, as we saw with MtGox. Price manipulation is very profitable, either to suppress or raise prices artificially, or implement trading strategies.

These manipulations increase the volatility of Bitcoin and undermine its credibility. Altcoins and coins with lower marketcap, which are traded on fewer exchanges are even more subject to manipulation than Bitcoin. Many altcoin speculators do not run the block chain for the dozen coins they are speculating on, therefore the coins only exist as paper coins as balances an SQL database and are never withdrawn to an address. Therefore the scope of manipulation is infinite.

Requirements:
- The default wallet must be more usable than Coinbase.
- The exchange infrastructure needs to be integrated into the wallet and exchanges should not hold coin balances. The coins should be withdrawn back into the wallet automatically.
- We need digital contracts that can substitute for fiat for short time scales and has the same clearing speed as Bitcoin. For instance, a contract backed by 1 Bitcoin that can be be redeemed by a particular entity, upon execution to $100 in Bitcoin at the current spot price.
- If Bitcoin's competitors are buying a seat and representation in drafting regulation, Bitcoin needs to buy representation in the secret meetings where the legislation is being drafted.
- The reliance on the legacy banking sector and institutions must be on a roadmap for elimination

This seems obvious, but Bitcoin has been unable to summon the resources necessary to even begin baby steps towards these goals. It suggests that Bitcoin is inefficient, in that it allocates costs to miners rather than towards the issues it is facing. Another five hundred million dollars spent on ASICs will not improve Bitcoin usability or address the political threat of regulation Bitcoin is facing.

Imperial and expansionist crypto-coins

A coin can either be a passive asset, or it can allocate resources to achieve goals, long-term expansion and create a favorable environment for expansion.

Resource Sources:
- volunteers/donations
- funding from external investors
- providing services, charging a fixed percentage on each transaction
- funding all operations from IPO and sale of fixed pool of assets
- funding from the creation of new currency (inflation). Essentially redirecting money that miners would otherwise receive, to actively funding the coin development, marketing and ecosystem development.

Goals:
- usability improvements
- security
- marketing/PR/promotion
- ecosystem and application development
- expansion/growth
- buying political influence and representation in jurisdictions which stand to benefit from adapting liberal regulatory frameworks
- software integration for commerce, banking and export sectors which stand to benefit the most from adaption

In Skycoin, the meshnet and services are federated. The infrastructure is owned and operated by the community and the development organization is not in a position to extract a tax on service revenue. Therefore this is not an option for funding expansion.

We chose to finance, from IPO sales of a fixed pool of assets and the founders contribution of early Bitcoin. However, we found that this resulted in under investment. The core team is making steady progress and can complete the existing project scope (at a much lower cost than other projects at a higher quality level, Ripple, ETH but slower). The next stage of the project is expanded in scope and aggressive expansion will require a higher resource intensity and a larger number of project teams and external partners than the software development. As many as eight distinct project teams, external design firms and manufacturing partners may be involved, from design to production of just the hardware portion of the meshnet.

Factors concerning price stability: creating stable stores of value

Another aspect rendering the current model non-viable, is price stability. One of the core requirements for Skycoin is price stability. Bitcoin intraday volatility is too high. Companies adapting Bitcoin for international trade are unable to hold balances in Bitcoin, without substantial foreign exchange risks. A daily swing from $330 to $315 or monthly swings from $400 to $320 completely precludes Bitcoin for use for settling international trade. Companies cannot hold long-term Bitcoin balances and are forced to liquidate receipts, to local currencies immediately.

Skycoin introduced a method called "the capital ratchet" to lower intraday volatility and reduce speculation, using a fixed pool of Skycoin allocated at the beginning. The method works as long as Bitcoin remains stable. However, if Bitcoin fails or experiences significant volatility then the method fails and eventually exhausts the capital allocated to the strategy. Through simulation, we determined that maintaining a stable currency level and low volatility required an active and constant input of funds. Maintaining a floating peg against speculation may consume 0.2% to 0.6% per year of the market cap of the currency. Maintaining a floating peg may require an inflation mechanism to fund the acquisition of reserves to offset volatility by speculators.

The cost however is offset by the increased market cap and growth of the coin. How much more would Bitcoin be worth today, how much more adaption would it have in commerce if it had stable price levels? We believe that the relationship between volatility and market-cap is substantial.

We also determined, that Skycoin cannot be passive with respect to the exchange infrastructure. Skycoin needs to devote substantial resources to open source development and research into new cryptocurrency exchange infrastructure.  Skycoin cannot achieve the level of price stability required under the existing paper alt-coin regime.

To give an example, Russia issues rubles. Foreign banks have forex markets that buy and sell rubles. The rubles are entries in a database, paper rubles. There is nothing preventing a foreign bank from creating as many paper rubles as it wants and dumping them. They could even hedge the strategy with derivatives to minimize the cost of the manipulation and achieve significant amplification. Naked short sales covered with options/derivatives can create assets. Someone can sell you a stock that they dont own in a naked short sale and cover their position with options or derivatives. If all the banks agree to honor each others derivatives even if the counterparty is insolvent or in default, the scope for manipulation is unlimited.

This tells us that "store of value" is a social construct. It is highly dependent on who has power and upon social conventions, incentives and agreements between institutions.

Bitcoin has not developed an options or derivatives market yet. However, exchanges are able to create paper bitcoin and as demonstrated by the leaked MtGox data, non-existent fiat currency was created in MtGox's database and used to run up the price of Bitcoin before the MtGox collapse. Bitcoin will likely become subject to the same manipulations and worse.

An exchange can add a Litecoin to an account in a database and then a user can sell that Litecoin. The litecoin may not exist and the exchange may have to buy the litecoin, to cover a withdrawal. An exchange with withdrawal limits or withdrawal fees, engaged in heavy manipulation, may be solvent indefinitely. An exchange, suffering insolvency may silently and secretly haircut a fraction of users balances and there is no indication to the user that it even occurred. There is no way to prove that reports of stolen funds are real, instead of an anonymous attack on honest exchanges by dishonest competitors.

This is a subset of the problems we must address over the next twelve months. Skycoin balances and Bitcoin balances, therefore must be held in the local wallet. Exchanges must go through a common API, integrated in to the wallet and positions must be moved back into the local wallet automatically, so that the exchanges are holding no net coins. That is the first step. Until this is achieved, there is unlimited scope for price manipulation in every altcoin.

This is the only way to create absolute guarantees against the manipulations we are seeing in other altcoins. In other words, we have an exhausting amount of work to do, even after launch.

Update

This is over view of current development status and priorities

Consensus

Consensus is being worked on. The earlier algorithms are being implemented, bench-marked. Then testing them against the newer algorithms, so we have comparison. This is currently in python. Will be moved to golang and integrated as soon as its ready.

This is not required for IPO, because we can use central signing key until decentralized consensus is implemented. 

Coin

The coin is mostly done. There are only a very few changes.

Right now, visor is managing wallets and the json API daemon is inside of daemon. We want to move the wallet management and json daemon into its own library. The webwallet interfaces through JSON API daemon and the daemon hooks in to visor through function calls. We want the json API to be very close to Obelisk/Dark Wallet. We believe the Dark Wallet API is better than the Bitcoind API.

Once consensus is done, it will act as a state controller for visor.

In Bitcoin, loading wallets takes too long, because the whole blockchain needs to be loaded from scratch and the whole history scanned. Skycoin uses a leaner interface. When a wallet is loaded, the addresses are checked for unspent outputs associated with the address. So checking current balance is instant. The API will also allow you to check balances for addresses, without have the private keys loaded. There are many things you cannot do in bitcoind (like check balances for address easily) and we think Obelisk/Dark Wallet has the best API for developers and want to move away from bitcoind.

The local client and remote/thin clients will be on same API. You can run APIs for balances or injection transactions on a local or remote server just the same. So a cell phone who does not have a copy of the blockchain, but has a wallet file can query balances or inject transactions.

History is not implemented right now. It will likely be a separate library on top. It is outside of the core, needed to run the blockchain. The blockchain on disc will have the blocks and will have copy of unspent output set at interval. Then it can rewind back a month to an unspent output set, then apply the blocks in that month in order until the next checkpoint. So we can load wallet histories going from most recent transactions, going farther back in time.

This means wallets will load instantly, balances will be available instantly, coins can be sent instantly and history (when implemented) will load in background. As the Bitcoin blockchain gets longer, loading wallets will continue to slow down.

Skycoin already has multiwallet support, so you can load/unload multiple wallets in the client. Importing deterministic wallets from keys need to be added to the gui, after the wallet internals and refactor is done.

Bitcoin used Berkeley Key value store for serialization format of the wallet and there was problems. As the library was updated, only version wallets from very early Bitcoin versions, appeared empty when loaded. The old serialization format could not be loaded by the new client. So a wallet may say it is empty, but actually contain 100,000 Bitcoin. You have to manually extract the private keys with a tool and then reimport them on the command line. This caused some confusion and frustration.

Skycoin is using a JSON wallet format. All wallets are deterministic and the generation key will be in the wallet file. As long as you have the wallet seed, you can recover the private keys and coins. The internal format of the JSON wallet is something we have not had time to think through and finalize, but we can safely nuke everything in the wallet file except the wallet seed without risk of losing coins when the wallet storage format is upgraded.

In Bitcoin using unspent output set snapshots was a security risk, because there was no way to validate them without starting from the genesis block and applying every block since genesis. In Skycoin, there is a rolling hash of the operations applied to the blockchain state, so if you have two checkpoints and apply the blocks between the checkpoint to the first checkpoint, you will get the second checkpoint. This means that the blockchain can be divided into check point intervals and each interval can be validated in parallel. So you can validate backwards and can validate forwards, where as Bitcoin only lets you validate forwards.

The system is designed that way, so eventually you will not need to have the whole blockchain on every node. A node only needs a trusted copy of the unspent output set and then every block since that checkpoint. Then it can check balances and inject transactions.

We are evaluating this. We will probably have two hashes. One is the XOR of the SHA256 of each unspent output at the beginning of the block. This is weak hash, but has constant time to update. In theory, someone can add ~300 unspent outputs to the set and find a subset that generate the same same hash for this. We are not relying on this for validation, but it is good for sanity checking.

Checkpoints of the unspent output set need to have a full merkle-tree hash of the SHA256 of the serialization of each unspent output and have to be tied to a particular block header. The checkpoint needs to be signed by a public key of person who vouches for it. If check points are enabled, you would put in public key for ~8 trusted nodes (exchanges, friends, maybe dev key). It would download the 8 copies of the checkpoint hash from each person and make sure they all agree. If two different people in the trusted set have different hashes for the serialized unspent output set at a given checkpoint, then client should go into a warning/emergency mode until it is resolved by user.

The second has is a merkle tree root of the SHA256 of the serialization of the consumed/produced outputs from the block, accumulated into the hash from the previous block. This makes the block header, not only a function of the previous block input, but also a function of the "state" of the blockchain (the unspent output set) when the block was applied. There are three levels
- block header is only function of previous block header and transactions (data in the block), (Bitcoin does this)
- block header is a function of previous block header, contents of current block and subset of "state" the block is being applied against (Skycoin)

We are trying to determine if this adds anything or if it is redundant. If two clients have different internal state, such as an output being created and then having bit flipped randomly in the balance by hardware failure, this will detect the divergence in the next block if the affected data is an input (consumed) or output (created by) of the transaction. This will also detect an error, where a 32 bit system or 64 bit system output different values (rounding errors, optimization, different versions of compiler).

We can catch these errors in the next block, where as in Bitcoin they may persist many blocks until the unspent output is used and then cause a fork. For instance, this method guards against unintentionally introduce rounding errors and protects against the Block Index 0 fork, if Satoshi tried to spend the reward on block 0. We catch the non-determinism in the output set, in the next block.

If two people apply the same block against different states, the header of the accumulator hash in the next block will be different (ideally). Ideally, you would compute a hash of the full state, each block. However, we could not find a fast enough updating function for this and felt a full merkle tree hash each block would slow down block validation too much. The best compromise, is to check the full merkle-hash at the checkpoints. The full merkle-hash will also detect any single bit-errors, in any outputs that have not been spent yet.

Coin Development Priorities

IPO Requirements:
- move JSON API/wallet management into its own library, out of visor/daemon
- make the JSON API look like Obelisk/Dark Wallet, so that balance of addresses can be checked without loading wallet. Allow unspent outputs to be queried for address without loading wallet. Allow transaction injection. Allow fine grained control of which inputs are used in transaction and the outputs created.
- update webwallet to use new API, add deterministic wallet import

Longer Term:
- figure out what is in skycoin/daemon and replace the daemon with the skywire daemon. This is required for consensus integration.
- blockchain history, API for history queries?

Skywire Development Priorities

Skywire has multiple components and it was not clear how things should be structured.
- there needs to be a base interface for a physical "connection" where bytes come in through callback function and bytes can be written out. Polling should be minimized, to avoid adding 1 ms per hop.
- we assume messages are 4 byte length prefixed, so there should probably be "bare metal" layer beneath current golang abstraction.
- we need to make route setup simple, for creating route from A to B to C. Protocol needs to be worked through, finalized. Or just get it working and break it later.
- If a user receives a pubkey hash for an endpoint, they must be able to find a route to that pubkey over network. Nodes either must self-publish connectivity through DHT or service must scrape the network topography. Easiest first version is publication through DHT, with latency/performance self-report, then move towards 3rd party reports.

Skywire Advanced/Not Essential
- bonding multiple routes into a route at application layer
- meet-in-middle type "hidden services" advertised on multiple nodes. This was scrapped in version 1. Version 1 assumes a daemon has single public key and each daemon can run multiple applications, which listen. Opening port on remote node and advertising multiple endpoints is separate.
- RPC for exposing golang objects over network. This may not be used for anything. May improve services implementation?
- syndicated asynchronous messaging. not used for anything yet. based on XMPP. may be needed for short UDP like packets for some types of lookups or communication.

DHT
- need serialization format. Just list of 16 bit key, 32 bit length, bits. Is there better serialization format for entry? Just use this for now
- key is hash of public key, there is a PoW hash to prevent spam,
- assume full replication of whole DHT, between all nodes with gossip protocol.

Merkle-Dag
- this is the most important part to users, but on back-burner because it is not blocking completion of anything else right now

Goal:
- get minimum skywire working for routes
- get minimum DHT working (for ghetto routes, where each node has full table)
- use DHT to advertise routes to every other client
- get clients connecting by public key
- fix problems later

Skywire Meshnet Development Priorities

Our basic 1st generation target for the software defined radio is
- a software defined radio module, with direct amplitude modulated signal at 700 Mhz. Target 700 Mhz carrier output with with 8-bit of quantization, using amplitude modulation (positive and negative part of sin wave), for maximum of 11.2 Gb/s. This will either be a CLPD or ADC/DAC+FPGA with an ARM processor. We can fund ASICs from the FPGA or CLPD prototype to get to to full rate. The SDR module should have external antenna port and communicate over Unipro. This an ARA module.
- an antenna. This should be directional. It should be steerable electronically.

We need to be able to set the amplitude of a sin wave, for the positive and negative half of the sin wave at 700 Mhz. At 700 Mhz with 8-bit of quantization, using amplitude modulation at 700 Mhz, we can transmit 11.2 Gb/s. This is the target, but we may only be able to do 300 million values per second without upgrading to ASICs. The change of amplitude must occur at the zero crossing to avoid snapping.

There is ringing in antenna and other factors. So we will probably be using the same amplitude for positive and negative portion of the carrier at start. The amplitude value will change slowly over the cycles. Lower resolution in the DAC is acceptable for prototype, but objective is setting amplitude 1.4 billion times per second at the zero crossing and at-least 8 bits of resolution in output.

For the radio module, we need to determine
- CLPD with direct digital synthesis? What is fastest CLPD? Can CLPD do 300 Mhz ADC/DAC? What is highest clock rate and cost.
- FPGA with expensive ADC/DAC?
- CLPD for ADC/DAC direct digital synthesis, fed into FPGA? How fast can we get with a CLPD and what is speed limitation for ASIC?
- What is best cable for external antenna port?
- What are best options for ADC/DAC vs CLPD? In terms of cost and performance.

Notes:
- CLPD is our best option for getting a good open source design and validating it, before going to ASICs
- we may be able to find a cheap ADC/DAD or direct digital synthesis chip for a few dollars
- the decoding of symbols from radios, can be done in CPU at first, but must be pushed to FPGA. The higher level forward error correction code may be handled on CPU.
- we want FPGAs/CLPD that are cheap in bulk and require minimum components on PCB. They should have integrated pullup resistors and not clutter the PCB board with components. CLPDs can be $1 and FGPAs can be $5 in quantity.
- There may be way of duplexing a 350 Mhz, CLPD to achieve 700 Mhz with two 350 Mhz units and cleaver timing. We may not need ASICs.
- We will need higher end FPGA with 3 Gigasamples/second 14-bit DAC/ADC to determine antenna transfer function and determine gains from compensation in antenna transfer function and DAC resolution.
- we need to focus on module components that can be evolved, improved independently.

For the antenna
- meshnet needs directional beams to be viable at high device densities and long ranges
- we need a measurement platform for collecting data on antennas. hackrf and a 3d printed or laser cut acrylic platform with 2 degrees of freedom (servos), to rotate antenna and image the side beams
- we need electronically steerable antennas for 2.4 Ghz.
-- This could be a parabolic reflector with two $5 Chinese servos on a gimbal, controlled by an arduino
-- This could be a traditional phased array, with variable capacitors for delay lines
-- This could be a fractal antenna, cut into copper clad PCB with a laser cutter and arduino with SPI DAC chip for modifying the control elements
-- flat, electronically steerable 2.4 Ghz antenna panels are good for roof and hanging out windows and have line-of-sight
- We need electronically steerable antennas for 600 Mhz to 700 Mhz
-- traditional phased array is too large at this frequency, but possible. We have the matlab software for simulating different antenna configurations.
-- Fractal PCB trace antenna have better side lobes, smaller size. Can be laser cut from PCB
-- If antenna has N control elements (amplifiers, variables capacitors) we have the equations for beam forming, if we can measure output with control platform.
- beamforming, antenna must be under software control

The signal attenuation at 2.4 Ghz for going through a single 5" wall, is 23 dB. Every 3 dB is 50% loss of power. Every 6 dB is 50% loss of voltage.

The signal attenuation at 700 Mhz, for going straight through shopping mall sized concrete building is only 18 dB. The range can be miles and still achieve extremely high speeds. However, if a large number of devices with unidirectional antennas are deployed, with competitive transmission power, then the same congestion and noise floor problems occur as on 2.4 Ghz. However, it is slightly different because almost none of the energy between transmitter and receiver on 2.4 Ghz is on a line-of-sight path, its mostly multipath interference. Simulation shows that viable high density meshnet will need directional antennas (120 degree coverage maximum) and needs pencil beams.

Directional beams allow very important simplifying assumptions
- you can always boost the transmission power to achieve given bandwidth and exceed the noise floor at the receiver. This means lower resolution DACs can be used for same signal level.
- You can assume that the received signal is the strongest signal, regardless of whether it is the closest transmitter. In 802.11 on 2.4 Ghz, if you have a 12 bit DAC and the nearest transmitter is 24 dB louder than signal you are trying to receive, you lose 8 bits of accuracy on the DAC, effectively having a 4 bit ADC, severely reducing data rate
- competitive transmission power has minimum effect on other receivers. In 802.11 on 2.4 Ghz, attempting to make a connection over a 802.11n router, often causes it to jack up signal power, transmitting on multiple overlapping bonding channels, acting like a wideband signal jammer.

The first generation equipment will be a single output or perhaps two. It will be working out bugs and driving down cost. We chose a very modest technology and encoding, that minimizes technical risk. This should allow deployment rapidly. There is a very short lead-time between someone figuring out an opensource design and when commercial manufacturing/assembly/distribution of PCB boards.

The HackRF was built by people who had no experience in electronics. They were able to learn everything from Google and build a software defined radio that goes between 0 hz and 6 Hz, with 20 Mhz bandwidth. With no experience they were able to design a $160 SDR that is more powerful than $15,000 commercial SDRs. That is very encouraging. To bring the meshnet into the physical world, will require multiple teams working on different parts of the problem.

The AM encoding does not interfere with the users of the digital television band. The FM receivers will not even lock on to it. The gain for the directional beams is 20 dB to 30 dB on the receiver and transmitter. The interference produced is below level of spurious emissions from cell phones, computers and wireless telephones. A horizontal beam polarization yields 30 dB attenuation for digital television, receivers. The beam should be horizontally polarized whenever possible.

Second generation meshnet may have ~16 separate antenna elements on a chip for doing digital delay lines and driving phased arrays. The signal may be a directional gaussian type ultra-wideband pulse, with 700 Mhz pulse frequency. The AM modulated signal with 8-bit ADC caps out at 11.2 Gb/s. The ultra-wideband Gaussian modulation has extremely low level emissions across a very large spectrum and can reach theoretical rate that are measured in terabits/second. However, the technology is new and encoding 1024 bits per pulse, will require more complicated electronics, special antennas, novel encodings and engineering work. Even if the bandwidth rate is not improved, the technology is low probability of intercept and below the noise floor a few meters off the beam axis, which is desirable for operation in particular countries.

Update


Consensus Algorithm

We have a new member on team focused on the consensus algorithm. His work has been great and we are making a lot of progress.
 We now have a discrete event simulator in Python and have tested several candidate consensus algorithms on real world social graphs from the wikimedia admin dataset. Failure modes such as collusion, or nodes timing out have been implemented and tested.

The naive consensus algorithm, converged quickly enough for 15 second blocks. Refinements to this algorithm have been developed which have significantly faster convergence rates. I think the main consensus algorithm will be ready to be written in Golang and moved into the code base within a few months.

The single round decision context is worked out. It is much simpler than Ripple. It can be understood by a human. It can be modeled mathematically. Simulations can be performed against different attacks easily. The implementation will be only a few hundred lines of code after libraries are pulled in. Consensus occurs in public, so it can be audited for manipulation by anyone.

This system will quickly eliminate need for PoW for securing blockchains. I will leave analysis of the algorithm and its advantages till after release.

Meshnet Update

It has been two and a half years since the begining of project meshnet and OP redecentralize.

https://www.youtube.com/watch?v=1tEkyLOh-tY

In July we finished implementation of the basic meshnet/darknet. Upon testing, we discovered that Wifi is unable to provide the range or bandwidth required for a viable meshnet.

We do not believe that is feasible to build a viable meshnet with 802.11 on the 2.4 Ghz band. We determined that if every third house in city, had a meshnet node, the nodes would be unable to connect to each other. 802.11n devices are using multiple bonded overlapping channels and competitive transmission power. Attempting to connect two meshnet nodes over a house with an 802.11n device, results in the device increasing transmission power until the link connectivity fails.

The range of devices on the 2.4 Ghz band for 802.11 will never exceed 500 ft and beamforming had not resulted in significant range improvements for wifi. However, free space performance is very good. 100 Mb/s, 50 km line-of-sight links are easily possible for backhaul. Signal attenuation is less than 0.2 dB per km in free space.

There was debate over whether we should go forward with IPO, until we are certain that we are able to deliver a working meshnet.

After nearly six months of research and testing, we have found solution to the range limitations. We believe a viable meshnet is possible. However, the work required is significantly more than anticipated. We need FPGAs (later ASICs), directional antennas and to develop a software defined radio platform for operating on the 600 Mhz to 700 Mhz whitespace bands. We have a few hundred pages of notes on the radio requirements that are being edited, organized and prepared for publication.

Cryptosystems for Geographic Time Scales: Future Proofing Skycoin

Gold has retained value for thousands of years and had relatively low interest rates. Bitcoin may not survive on that time-scale because of social and technological advance. Gold may lose its scarcity if future improvements in robotics or mining technology dramatically reduce cost of gold extraction. Future advances (such as robotics) may allow mining large quantities of previously inaccessible gold veins deep in the earth, on the ocean floor or in space.

Gold may fail as a store of value, within the next hundred years. As gold prices increase, more deposits become profitable to extract from. This price dynamic puts a price ceiling on gold. If price increased 100x, then ocean floor production or marginal productivity mining sites become profitable, and supply increases, until the supply meets the demand curve.

Mathematics such as cryptography allows us to create new assets, which are scare and superior to gold in many ways. However, there is no insurance that these mathematics/software systems can be stable over hundreds of years of technological and social change.

Future Proofing Skycoin: Salted Hashes at Network Level

Bitcoin, Skycoin's hashing and cryptography algorithms will be vulnerable within twenty years. Skycoin can survive complete vulnerability and defeat of SHA256. There are two methods for this

Salted Hashes:
- Each person generates a random "salt" and the data to be hashed is salted.
- The SHA256, the salt value and salted hash is sent.
- You download the data for the hash one peer. (you want to verify the data you received is not different than the data other peers have for same hash, even if SHA256 is easily preimaged attacked)
- You have the salted hash of the data, computed by a list of user selected trusted peers and all the peers you are connected to.
- You compute the salted hash of the data received, using the salt value, for each for the trusted peers.
- If the salted hashes match, for each peer then the data is correct.
- If the data was modified, so that it has same SHA256 hash as intended data but is something else, then its easily detected.

If the internal state of the hash algorithm, between rounds is N bits and the hash salt value is M bits and its validated against n peers, then if n*M is greater than N, then it is not even possible to generate a piece of data that will pass the n salted hash checks (with probability 1).
- even if the hashing algorithm is completely weak (you could use XOR function), as long as outputs of hash are "random enough" function of the input and salt value
- even if the opponent knows the peers and salts that the hash will be validated against.
- We can prove this with Kolmorogov complexity theory.

Future Proofing Skycoin: Rolling State Hashes at Blockchain level

Salted hashes are very useful for validation at the network level, assuming the hashing algorithm is broken and weak against preimage attack. This is one way of future proofing Skycoin so that will continue to operate, regardless of future mathematical or computational advances.

Another future proofing mechanism, is that the Skycoin blockchain state is functional and has canonical binary serialization. If S is the state of the block chain and B is a block, then there is function mapping S x B -> S. The block is applied against the state and there are no side effects, in that output only depends on the two inputs.
- a block is validated transaction by transaction (to make sure they are valid)
- the transactions are validated against each other (to make sure they do not double spend the same inputs or conflict)

There is a canonical binary serialization of the outputs and the "state" of the blockchain. As operations are applied that change the blockchain state, the inputs to these operations can be rolled into a hash. Each block must have a matching hash, for the internal state which it was created to be applied against.

This means, that two clients will only arrive at the same internal state hash from the genesis block, only if they applied the same sequence of blocks. Even if SHA256 is broken completely, there is no way to generate a valid sequence of blocks that will be accepted for Skycoin. For Bitcoin, if SHA256 is broken, an adversary may be able to construct and insert a modified block between two blocks in the chain and it will be accepted.

These safety measures at the network and blockchain level were developed, after analyzing Bitcoin against "oracle attacks", where we assume a god-like computer can do arbitrary SHA256 preimage and collision attacks attacking the blockchain.

Future Proofing Skycoin: Cryptography For Geographic Timescales

Can a software system based upon cryptography operate securely for hundreds of years, despite future advances in mathematics?

secp256k1 will be broken or insecure within a few decades. The development of a quantum computer would eliminate the security of existing public key systems. RSA, secp256k1, Bitcoin and to a lesser extent Skycoin would be vulnerable to attacks.

In Bitcoin/Skycoin, if an address has never been used before, only the owner knows the public key. Therefore an adversary who can break sepk256k1 has to wait until someone uses the address in a transaction to begin attacking. If a user can break secp256k1 and generate a privatekey from a public key in 200 hours of work, they can steal coins from addresses suffering from address reuse.

If they can break secp256k1 in under 10 minutes, they can read public keys off transactions, recover the private key and inject a new transaction that spends the coins before the other person's transaction is in a block. They can have a higher reward for the transaction and Bitcoin miners will prefer the theft transaction, to the original. Miners may even orphan blocks, to collect the higher transaction fees from the theft transactions.

In Skycoin
- With blocks at 3 to 15 seconds each (maybe even 1 second depending on how testing goes), there is less time and ability to crack public keys
- address reuse is mostly being eliminated. It is still allowed, but we are moving towards options with better usability and security. If you have a users public key, you can generate new addresses for that user, that have never been used before. You have a public key and salt value and give it to user and they can generate infinite addresses for you, with ECDA. Even if the pubkey is published and private key recovered, both the pubkey and salt need to be recovered to steal the funds.
- Communication addresses allow you to request a new address for transaction. Most transactions will eventually have receipts/invoices for ecommerce (hopefully machine readable). We are streamlining usability here.
- Today, you can view your credit card invoice, but you cant click an item and see what items you bought at grocery store and spent $30 on. You cannot click an item on bill and see the tracking number for shipping or where it was mailed to. You cannot click a payment and be able to message the merchant. In Skycoin, this will eventually be integrated and receipts/invoices may even be machine readable someday. "Communication addresses" are at a level above the blockchain and eliminate address reuse. The whole purpose of asynchronous messaging infrastructure is to support this. The communication addresses are used for DHT lookup and are shorter than Bitcoin addresses, but are secure until the hashing algorithm is broken. If the hashing algorithm is broken, it can be upgraded to an unbroken hashing algorithm. If no secure hashing algorithms exist, then longer or unique communication addresses needed. This decreases usability (long strings to type in, no autocomplete), but is still secure in the event of advances that render all known hashing systems insecure.
- If an attacker can crack a public key, recover private key in under 1 second, there is also a commitment scheme. We plan to have signatures on the people introducing blocks to network. If you need secrecy, you can communicate the block directly to block creator, without public publication until it is entered into the block. If the attacker is not colluding with the block publisher, the network can continue operation securely until solution is found.

So there are different attacks
- an attack that recovers private key from public key in 200 hours (Skycoin is OK. Bitcoin address with address reuse, get coins stolen).
- an attack that recovers private keys from public keys in 5 minutes (Skycoin is OK. Bitcoins used in transactions are being stolen).
- an attack that recovers private keys from public keys in less than 1 seconds (Skycoin needs upgrade in cryptography but can still operate if the servers created blocks are not colluding with attackers)

If there is a closed set of servers, elected by the consensus network which mint the blocks and there is commitment scheme that allows a server colluding with the attacker to be identified and the individual transactions are small enough ($1000) that they are not worth detection over, then the network may be able to continue operation, for hundreds of years, even if secp256k1 is broken.

One commitment scheme
- there is finite set of elected servers who create blocks
- a person publishes their transaction to one of those elected servers, who keeps it secret
- the elected servers communicate transactions to each other as hashes
- the elected servers come to unanimous consensus about the ordering of the transactions in the next block, without any of the servers knowing what the transactions are
- the transactions are revealed after the next block is determined

A more advanced consensus scheme uses an N of M approach, which requires collusion of N servers to collude/cheat to achieve knowledge about the public key.
- a finite set of servers who creates blocks
- a person publishes their transaction to N of M of the minting servers, with secret sharing. Each server have a token identifying the transaction. The N servers need to exchange information to reconstruct the transaction.
- the servers agree on the order of transactions in the next block
- the servers exchange the secrets needed to construct the transactions
- the servers enter the block

Therefore, we believe that a system exists that can survive, even if secp256k1 and all existing public key cryptography are broken. Lamport-signatures will also still work, as long as hash preimage and collusion attacks remain difficult.

Future Proofing Skycoin: Attacks on the Address Generation

The weak part may be the relationship between the addresses and the publickey. Future 3-SAT solvers may be able to invert this relationship within sixty years for Bitcoin addresses. They would have to find a preimage of two SHA256 and an RIPMD160 compression.

The 65 byte public key (520 bits) maps into a 256-bit (32 byte) value from the SHA256 and then is compressed to 160 bits (20 byte) by RIPMD160. For each address, there are 2^96 preimage public keys. Each 32-byte, 256 bit private key maps into a 520 bit public key. Bitcoin uses DER encoding, which may allow malleability and reduce security over a canonical form, however I have not looked at implementation.

With a canonical form, there are a finite number of preimages that are valid public keys, but with DER encoding there may be an infinite number of valid preimage keys and it could be vulnerable to future length extension attack, based upon how SHA256 hashes data blocks together. Skycoin is using a canonical form without malleability. If Bitcoin accepts mutable signatures in DER, there may be an infinite number of input public keys that pass, unless Bitcoin firsts reduces the DER format into a reduced form (removing zero padding). However, there are only a finite number of valid preimages for Skycoin addresses (fixed length, canonical form).

Skycoin has 33 byte compressed pubkeys hashed to 32 bytes (double SHA256), then reduced to 20 bytes (RIPMD160). Private keys are 32 bytes and almost every privatekey corresponds to a valid pubkey. This means that the chance a valid 32 byte seckey exists, for a randomly generated 33 byte public key is better than one in 256.

This means, that if a preimage attack on y = SHA256(SHA256(RIPMD160(x))) is possible, that there are 2^96 preimages and fewer than 256 of them need to be found, before a publickey is found that has a valid seckey, that could possibly recovered. Therefore if secp256k1 and the preimage attack on SHA256(SHA256(RIPMD160(x))) become possible separately, both Bitcoin and Skycoin balances become insecure, even for addresses who public key have not been published.

An improvement to Bitcoin's address function, would be to ensure that statistically, there are a large number (2^96) preimages, to the hash, but that statistically very few (ideally only one) of them has a valid seckey for the resulting preimage of the address.

Another method, is to allow the attack, but only keep balances in 1 to 5 coin amounts per address. If it cost $5 in resources or effect to steal $1 from a random, unknown user, then the money is safe. Deterrence and frustration may ultimately be the only security possible.

The Skycoin addresses are prefixed with a version byte (currently 0), so we can upgrade later if either a preimage attack or secp256k1 is broken. Once communication addresses and asynchronous messaging are implemented, we may move away from 20 byte "human sized" addresses at blockchain level.

Update

The recent attacks on Tor and incidents with Bitcoin are putting pressure on us to release.

Changes
- Standardizing serialization formats.
- Finishing documentation.
- changes to internal organization of /src/visor (which runs the blockchain). The wallet manager is moved out of visor. Visor has golang interface based upon the Obelisk Darkwallet API, then another module will run a web-server and manage your local wallets and checks for balances and so on. This makes it more flexible for using visor as a library without running a full node.
- All the branches are on same version of networking library now. We are going to branch that off into its own repo. I think we can pull that in as dependency from the public repo and see what is left in the daemon module, then move that somewhere. Then everything should be in order.

When documentation is done, there are a small series of golang libraries that need to be developed. This is great project for anyone who knows golang.

Darknet/Distribution Application Security Concerns

The Skycoin web wallet is using Webkit renderer and Google V8. We believed that we could run darknet apps securely on top of same infrastructure, where the javascript and data was from a synced MerkleDAG store replicated locally. This would allow Dark-market type functionality and more complicated applications. Since the data is local, the page load time is zero for static content. So it would be much faster than tor and also protects the host from DDoS attacks, as the static data and updates to that data is replicated peer-to-peer rather than querying server for each page request.

We assumed that a remote service could not break out of the sandbox, regardless of input to the sandbox. The Javascript engine and rendering engine is huge and has a large number of dependencies. Google is rapidly making changes and there are bugs, crashes and zero day exploits. We cannot rule out a zero day exploit that might arise in future or be present in the version being used. The webkit window is running in separate process, which adds some security, however its not perfect.

Google intends to compile and run Blink and V8 inside of Portable Native Client (PNaCl). This would solve the security problems and ensure sandboxing regardless of exploits in V8 or Blink. However, Google is not ready with this yet and it may be a few months. V8 appears to be running in NaCl however.

Portable Native Client, PNaCl is a subset of LLVM Bitcode (the binary representation of LLVM intermediate form). It is compiled down by LLVM to a machine dependent format. There are checks to ensure that the program cannot perform operations that would escape sandbox.

PNaCl takes C/C++ (gcc toolchain) and outputs a subset of LLVM Bitcode. Then the bitcode is compiled to native code with LLVM. The compiled binary is verified and modified so that it cannot break out of sandbox if executed. The slowdown from V8 inside of NaCl sandbox is 50%, but this is acceptable for the security.

Network and file access occur through an API. The application does not have native access to network or file system. This prevents the application from being able to find the IP of the machine it is run on or other identifiable information.

This type of high security browser would be good frontend for rendering and interacting with darknet applications. It is also relevant for the Tor project, as there is less room for meta-data leaks and browser exploitation.

We know for instance, that there was a zero day in a firefox XML library that could be triggered through javascript, which has ability to hijack the process. If a hidden service is seized or compromised, that attack could have been used to identify users and install a backdoor or key logger on their computer or merely obtain their IP address.

Another concern is browser fingerprinting. A darknet application should be unable to identify a computer uniquely, by running a program on it. We are not sure if LLVM Bitcode to NaCl bitcode is deterministic. Run times for various operations will vary between different CPUs and this can be used to finger print. If the compilation from Bitcode to NaCl is not deterministic, then a specific cached compilation of a darknet app can be fingerprinted.

Interpretation of the LLVM Bitcode on an emulator type virtual machine, eliminates finger printing but slows it down. V8 uses runtime code generation which makes this approach frustrating, because it now requires implementing a secure x86 emulator rather than a simpler and more flexible emulator that implements LLVM Bitcode.

Natively compiled code may be subject to microcode exploits. V8 may even allow microcode vulnerability exploitation from javascript, given that it is doing run-time compilation to machine code. A microcode exploit may allow a computer to be rooted by clicking a link over tor/darknet, where the page runs specific javascript. However, this would only be used against a high value target. The only way to mitigate this attack is to disable javascript or compile everything down to LLVM IR, interpret the code on an interpreter for the IR.

That was our original approach, but I dont see how it will work with Blink/V8 as the frontend for the application.

What we can now works and its very secure, but in long term we have to work out these problems.

Ya. We could have done the IPO in January. I cant remember what stopped the IPO from happening.

The IPO does not mean its done, or even that it works. It just means the coin is trading publicly. If Skycoin succeeds, it will spawn fifty clone-coins before we even have the software working.

Bitcoin took the form it did (a single large, global world internet currency) because of mining. Only the coin with the most hashing power can be secure. Bitcoin ended up being radically different than the intention many people had for cryptocurrencies. Bitcoin is still a stepping stone to the next stage. Bitcoin is priming the pump. Almost all the mined coins are pump and dumps. A very few of them are very innovative however.

There are groups of people of various sizes and they want to start their own digital currencies. They have looked at Bitcoin, but they cannot afford enough mining equipment to make it work. As soon as mining is eliminated and unnecessary, the landscape will change. You will see a lot of "community currencies", towns, websites and smaller groups like American Indians on reservations issuing their own coins. Every private Bitorrent tracker will have their own coin. You may even see companies begin to issues currencies to customers and suppliers.

These coins will be more local and relevant. Most of them will fail, but a few will make it. These coins are going to be inter-operable from day one. It wont matter if a merchant accepts Dogecoin or Litecoin or Bitcoin, whatever you have in your wallet will convert over at the spot price and users will not even think about it. Merchants may choose to hold profits in one currency and users may have a completely different set of currencies they hold. It will be a two-sided market.

There will not be a "litecoin ATM" or a "Bitcoin ATM", it will just be called an ATM. As routine transactions become automated, income, debt and credit will start to creep in. Very few people right now have income in Bitcoin and the things you can buy with Bitcoin are still limited, but that will change as we go into stage two.

Stage three will probably be an attack on the idea of currency itself. Bitcoin is a small technical achievement. Regulators can handle it. Libertarians were screaming and making scary noises about how "revolutionary" and "threatening" Bitcoin was and the regulators calmed down when they realized that Bitcoin is same as cash or gold. Its just another commodity. Bitcoin is not any more "threatening" than someone trading a gold ETF back and forth between two accounts. Governments will just put some reporting requirements on it and make sure they get their tax money when you buy anything.

Stage three is already laying the technical foundation for computer mediated systems of exchange that are radically and conceptually different than anything that has existed. Look at Ripplepay and the idea that money itself is just credit and debt. In Ripplepay money transcends its origin as a commodity and becomes a system of contracts and relations in a network. The role of money as a commodity inevitably becomes separated from the role of money as a unit of account.

Technology is enabling the creation of new objects, with new properties and relations that no previous object had. To own a gold bar is to possess it. To transfer ownership you physical move the bar into the possession of someone. In Bitcoin, "ownership" was transformed from its physical form, to knowledge. The "owner" of the Bitcoin is the one who "knows" the private key to authorize transfer of the Bitcoin.

If a coin is secured by two public keys, held by two parties and one party publishes the private key for their public key, the other person and now only that person can authorize the transfer of the coins. The "ownership" has changed without the coin having even moved. Merely the state of knowledge in the world has changed, without even touching the blockchain and yet the Bitcoin has changed hands.

Bitcoin would need a 2 trillion dollar marketcap to even represent one percentage point of global wealth (the foundation of security provided by the mining process will be severely threatened before we get there) . The end game is not 2 million dollar clone-coin pump and dumps. It is systems of exchange that will represent single or double percentage points of global assets and financial wealth. The correct investment horizon is probably five to twenty years.  In the excitement of two new coins launching every day, people are forgetting how far off the end goal is and underestimate the sacrifices required to get there.

Project Update:

Everything is going very rapidly. We will be out of new things to code within a finite amount of time on the current trajectory. All the project goals will have been achieved and then we need to figure out what happens next.

1> We must finish the developer documentation and tutorials.
2> We must do the IPO.

When we started development, Golang was experimental and frustrating. Build reproducability was difficult, developers were stepping on each others toes and debugging goroutines was impossible. The Golang tool chain is maturing rapidly. Many problems we had a year ago are solved.

For organization, we found the best thing is to put everything on github. Use the github wiki, use the github issue tracker for bounties. The project is being split up into coherent logical blocks. We did not know the best way to split up the components of the project until everything was implemented.

Reflections on Consensus:

In the last year there has more formal research into Skycoin type consensus algorithms. We are confident that mining will soon no longer be a requirement for blockchain security or consensus. There is on going explosion of formal research (see: SybilLimit https://www.comp.nus.edu.sg/~yuhf/yuh-sybillimit.pdf ).

As we developed and refined the consensus algorithm, it went from simple to complex and then back to simple. One of the requirements is that it worked and was only a few thousand lines of code (so that it could be audited) and edge cases and flow paths were minimized. As the algorithm was examined through different facets, we found the core and were able to determine what class of attacks were acceptable and which attacks were existential and unacceptable (primarily attacks resulting in financial loses). The elegance of implementation is only possible because the implementation rests upon several layers of libraries for implementing new cryptographic and networking constructs.

The last of these primitives are designed and implementation is proceeding. Documentation is becoming important as Skycoin is not the only application that requires these components.

Reflections on Requirements for Distributed Applications:

There have been advances in containerization and sandboxed runtime environments (Docker, pNaCl). Recent application sandboxes are coming close to meeting Skycoin project security requirements. Many things that we believed we would need to write ourselves, have begun appearing.

The basic requirement for the Skycoin distributed application and "personal cloud" infrastructure were
- ability to run sandboxed services (processes identified by a public-key)
- separation between configuration and data storage for services
- sandboxed networking (networking only through execution environment API)
- sandboxed disc access (each process occupies its own encapsilated disc environment, shared storage by remote application exposing the disc as a service over the network)
- ability to run process in full emulation (for untrusted code), with option to compile down to native code for performance
- sound, video and other privileged services exposed by services (processes) over network
- LLVM intermediate representation for deterministic builds for C, C++, Golang (platform independent when builds are run within emulated build environment through bootstrapping process).

Tools such as emscripten allow us to achieve this easily in a javascript emulation environment for C,C++, Golang and Python. A full tool-chain may be possible with a simple emulator and single LLVM backend from LLVM intermediate form to the emulator language. The emulator language itself will be stripped down version of LLVM intermediate form.

The existing sandbox executes javascript with Google's V8 interpreter and does not have disc or network access.  Distributed applications are still waiting on implementation of infrastructure components required to build a useful application.

Reflections on Skycoin Communication Infrastructure:

Tox has solved many of problems we are facing, for messaging nodes by public-key. Tox was forced to use the Kadmellia type DHT and leaks metadata and timing information, which is undesirable. We have a document for new DHT infrastructure that would alleviate many of these problems.

As Tox is working and duplicates functionality required by Skywire, we are using it for prototyping the darknet. Tox does not protect IP identities of the public key. However, the functionality for finding and messaging nodes by public key is working which is the important thing.

We may introduce a "Connection" interface class to allow new connection types in the future, deprecate TCP/IP and move all existing Skycoin/Skywire communications over Tox. The dependencies are minimal and it appears that Tox can be built by the golang built tool.

The Tox project is very close to what we will end up with, however with a few changes.
Tox uses NaCl, Curve25519, Salsa20, SHA512.
- We would recommend Secp256k1,ChaCha20, SHA256
-- for standardization with Skycoin primitives.
-- for 32 bit performance
-- secp256k1 acts as a "coal mine canary". When algorithm becomes broken, Bitcoins will be stolen.
- We would recommend implementation of new type of DHT to replace existing peer look-up system
-- value is not Hash(key) but where the key is 20 byte hash of secp256k1 public key and the value is {KEY}, { POW, SEQ, EXPIRE, DATAHASH, SIGNATURE}, {DATA}.  (There is Key, Header, Value).
--- POW is a 20 byte proof of work (anti-spam)
--- SEQ is 32 bit number that is incremented on update (DHT nodes replicate value with highest SEQ number for the key. SEQ may be unix time at publication)
--- EXPIRE is the expiration date in unix time
--- DATAHASH is SHA256 of binary data in the key-value entry.
--- DATA is the 32 bit length prefixed contents of the key -> value
-- DHT nodes replicate tuples peer-to-peer. Invalid headers are discarded.
-- The public key is extracted from the sigature. The public key is hashed. The key must be hash of public key.
- The signature is set to zero and serialization hashed with SHA256. Alternatively a subset of the fields is hashed (insuring immutability, inability of 3rd parties to modify data without invalidating the signature/hash). The signature must be a valid signature for the extracted pubkey and for the resulting hash.
- Tuple Serialization / Network Format:
-- For serialization of structs/headers, for future proofing and cross platform implementation, { KEY, POW, SEQ, EXPIRE, HEADERHASH, SIGNATURE, DATA } is serialized as a map. [(int16,int16,data), (int16,int16,data), ...].  Each element has int (ex. KEY = 1, POW = 2, SEQ = 3, EXPIRE = 4, DATAHASE = 5, SIGNATURE = 6), length prefix for binary data, then binary data follows as bytes.
-- New fields may be added or removed as protocol evolves, without breaking compatibility / serialization.
- Cryptography Serialization
-- Signatures are 64+1 bytes (compressed secp256k1 signature plus recovery byte. Only non-malleable signatures are valid)
-- Pubkey Keys are 33 bytes (compressed secpk256k1 pubkeys. Compression is required.)
-- Pubkey hashes (Addresses) are 20 bytes. Address = {ripmd160(SHA256(SHA256(Pubkey)), VersionByte}. A one byte version byte is post-fixed to end of address (for upgrading curve in future). Default version byte value is 0.
-- Address serialization is base64. The 21 byte address serializes to 28 characters. ex. LS0tIFBPVyBpcyBhIDIwIGJ5dGU
- Peer Discovery Through DHT
-- This system allows contents of the DHT entry to be updated (unlike Kadmelia DHT). However it requires a new protcol to be throughout for friend requests. This needs to be worked out
- DHT Replication
-- Each DHT node should fully replicate every DHT entry in network (full replication, not Kademlia)
-- privacy (currently sybil attack appears successful at determining nodes making queries for particular pubkeys)
-- simpler replication, reduced complexity from Kadmelia. Increased bandwidth/storage usage.
-- DHT replication can now run "within TOX" through TOX network, without external UDP queries leaking metadata
-- There may be optional "Selector" in DHT
--- some nodes may choose to only replicate portion of network, when cost of full replication becomes too great (support single application DHT key sets). Alternatively, nodes may start dropping the entry with lowest POW.
-- Format supports multiple types of DHT and evolving DHT implementations as required.

This new DHT system is very similar to Bitmessage. However, instead of sending messages it gives each public key an area it can write to and update. You could call it a bitmessage-DNS system. This system supports the case where you want only people who know your pubkey to know things and when you want to publish something publicly to everyone (such as route information).

We will end up reimplementing something with same functionality as Tox, but slightly different. However for now, we can prototype the higher layers on top of Tox and save time.

We intially thought there were two layers to the darknet routing network. However, the lowest layer ended up being nodes with public keys which are identified with published IP addresses and accept connections from the public. Then there are nodes that are only privately peered. The network topology is mostly public for the purpose of finding routes, but there is no correspondence between the public keys of the node and an IP address.

This produces a new kind of pseudonyous networking. There are two kind of pseudonymity.
- There is no relationship between IP addresses and node public keys (unless the node is publicly advertising and peering with the public).
- A node passing traffic can only identify the previous and next hop for the traffic, not the origin or the destination for the traffic.

However this type of pseudonymity creates three problems
1. Resource exhaustion attacks, route exhaustion (one node creating 10,000 routes cannot be differentiated from 10,000 nodes creating 1 route)
2. in a pseudonymous network, nothing stops leaching so the performance will be bad without a financial incentive
3. Nodes may lie about performance or route information. Bots may lie.

#1 is difficult. The attack requires as much resources for the attacker as the person being attacked. IP/TCP/UDP suffers from a similar attack. If a router can switch 10 Gb/s to a particular port and you send 10 Gb/s to an IP with destination on that port, it will cause packets to drop. The failure case for stateful networking is not dropped packets, but is that attempts to create new routes through that node will fail. However, many of these attacks only affect nodes with public peering.
#2 can be solved through coin incentives. This is relatively easy. Leachers will end up competing with other leachers for bandwidth in the leacher pool, but leachers wont be competing with the non-leachers for bandwidth.
#3 is difficult. You need one or more trusted source of 3rd party route and performance information. There is no "trust-less" way of doing this. It might be as simple as having bunch of people crawl the network and publishing data. A solution to this will develop over time. It will be incremental.

Once implementation is done, we have to deal with other problems. It is not clear why Tor is more successful than I2P. Tor has about 2 million users a day, so its still niche. Just getting the network working and ensuring it is well designed is not enough. We have to ensure that there are applications that will drive adaption.

Update:

Consensus Simulation:

Here is basic python simulation of the Skycoin consensus process http://pastebin.com/5DJ9d29D

We dont have much time for academic details until its done, but found that Ben-Or's consensus process could be modeled used a mathematical model called a "spin glass". https://en.wikipedia.org/wiki/Spin_glass

Each node has a state. Each node is subscribed to a subset of nodes in the network. There is a local function (a function of the node's state and the state of the nodes it is subscribed to) that can be called "energy". The "energy" of the network is the sum of the energy of each node. The network has achieved consensus (all nodes are in the same state), when the energy is minimized. A node changes its state at each round, to minimize its energy function. Through local energy minimization, it can be proved that the global energy reaches a minimum within a finite time bound for a particular type of network topology and update rule.

Spin glass are mathematically equivalent to 2-SAT/3-SAT optimization problems and several messaging passing algorithms on graphs have been proposed with known scaling laws and performance guarantees. This leads into analogies of Belief Propagation and Survey Propagation, where nodes pass more powerful state information to each other and the network can reach a convergent state faster. Normally, it can require exponential time for a network to reach the ground state if the energy function is too complicated (3-SAT). However, in Skycoin type consensus network the energy function is a 2-SAT problem at worse and actually more trivial than that (convergence through local hill climbing). Worse case network topology for 2-SAT makes number of rounds to convergence linear in the number of nodes (linear time in number of rounds for distributed process of N nodes, but quadratic time big O runtime for a centralized process). For "average" random graph the problem appears to be trivial and the system reaches the minimum through message passing, extremely quickly for even most basic stochastic local hill climbing update rule.

We do not have a proof yet, but the time to consensus seems to scales no worse than the square root of the number of nodes for a random graph at worse, but is usually logarithmic in the number of nodes in the network for most update rules. For a graph with a power law connection rule with preferential attachment, the convergence time appears very good in simulation. It does not change noticeably with graph size.

We have found that almost all the update rules for message passing result in network convergence. However, some rules are not "robust" in the sense that a relatively small number of colluding nodes are able to prevent network convergence and delay convergence indefinitely. In the real world, this may not matter because the required tie condition occurs rarely (worse case) and nodes blocking convergence would be detected and people would remove them from their trust lists. Some rule sets result in faster convergence, but may make it easier for malicious nodes to influence the network.

There are suggestions that there exist messages with augmented state information that would allow faster convergence and allow a node to partition the nodes they are following into two sets and apply meta-rules for adding/removing node relationships, expelling "bad" nodes to a disconnected/disjoint sub-graph.

There will be many changes after launch. This is a whole new area that needs work.

Measuring the Influence of Nodes

In Bitcoin, the two largest mining pools completely control the network. Together they control 51% of the hash rate and could attack the network, exchanges and gambling sites if they chose to. Mining has led to a severe concentration of power in the hands of a small group. The number of people who must collude to attack the network is much smaller than Satoshi intended.

In Skycoin the objective is to keep network control decentralized enough that a successful attack requires collusion of at-least a few hundred highly respected and trusted people (an unlikely conspiracy) and then minimizing the scope of damage that could result even then.

We need a measure of power or influence, in the Skycoin network, that allows us to compute whether a sub-graph of nodes has enough influence to carry out an attack in collusion. We would also like a visible measure of power of individual nodes, so that people can re-balance their node subscriptions to prevent any node in the network from obtaining too much influence.

We believe the influence of a node in the simple consensus system, can be approximated well using a page rank type algorithm. The link adjacency matrix is constructed, such that A_ij equals 1 if node i subscribes to node j and is zero otherwise. We normalize each row to 1 to get the modified link adjacency matrix. The "page rank" or power rating of the ith node is the ith entry of the dominate eigenvector of the modified adjacency matrix for the network graph.

The dominant eigenvector of the modified link adjacency matrix A, can be quickly computed by choosing a random vector, applying A to it by multiplication, normalizing the result and repeating successively with the resulting vector as the new input, until convergence.
Example x <- A*x / ||A*x||, while || x - (A*x / ||A*x||) || < ε  (multiply A*x, normalize result, feed it back in)

This simple metric gives an approximate ordering of the most trusted and influential nodes in the network.

Development News

I am not sure what is left until the IPO. I think the Python scripts are done.
- python scripts
- verify that loading deterministic wallet loading is working in the GUI
- start IPO?

There is a split between the active development branch and the IPO branch because of a networking library golang dependency. The IPO branch daemon wont compile with the updated networking library and the new Daemon is not ready to replace the Daemon implementation in the IPO branch. However, this should not affect the IPO as the existing client should still compile and run. Doing a huge refactor instead of a series of very small refactors that kept the software working was a major mistake and setback.

The darknet prototype is now running over Tox. Tox allows communication via public key, has UDP hole-punch working and has good binary data performance and latency. Using Tox as start point will allow us to get a prototype working faster and defer implementing public key to IP address DHT look-up. It also allows back-communication to distributed service servers over the darknet, before the asynchronous messaging implementation is done (which was a major problem/hurdle for implementing darknet application servers).

In a typical darknet application, you have a website with static pages. The public key owning the pages signs the data with their private key and the data is replicated peer-to-peer between the subscribers to the application. This is good for publishing static content and files. However, sometimes you need to make an API call to the application server (such as updating a wiki page). It was possible to subscribe, but not to communicate back to the public key controlling the server. Now the application can give a Tox public key that can be used as a communication end-point for API calls on the application server.

Skycoin distributed applications previously used Ether, then Aether but now uses Merkle-DAG as the standard format. Implementation documentation and the Merkle-DAG spec is being written up now.

Merkle-DAG is Skycoin's distributed file system. Merkle-DAG is like Bitorrent, but lets you make updates to files after publication. You generate a public key, then sign updates with your private key. The updates are replicated peer-to-peer between subscribers. Merkle-DAG replaces the ad-hoc replication that was previously used for publishing personal block-chains and distributed applications.

Update

Blockchain is still syncing It is on block 304,608. 36,000 blocks to go, before we can check Bitcoin address balances.

The wiki is getting filled in. We are putting tutorials here and technical documentation for components that need implementation (bounties). https://github.com/skycoin/skycoin/wiki

Yes. It was designed explicitly to defeat existing state-full packet inspection hardware. This includes the great firewall.

There is no fixed port, no protocol headers. There is not a single byte of plain text traffic in wire protocol, which can be used for identification of the protocol type. The traffic is complete noise. Disguising the traffic to be recognized as SSL or HTTPS is very easy.

The darknet is designed to run over IPv6. If you are tunneling over clearnet, you can potentially create thousands of different IPv6 addresses for your server, have each connection use a different IP address and rotate out IP addresses. If you are only connected to a fixed set of hand chosen nodes, there is no way to trace your node public key back to an IP address.

The traffic can only be identified through a statistical analysis. Blocking the traffic effectively requires installing hardware close to the end-user and for controlling traffic within the data center at peerage and cross-connect points.  Detecting and blocking access at the edge of the network, is much more practical than blocking it at the center. However, doing this requires installing large amounts of very expensive hardware.

Blogs, twitter feeds and other static content on the darknet would be stored in Merkle-DAG format and peer-to-peer replicated. So syncing data in china only requires the data leave border once (once a copy of the data is outside of the border, its replicated peer-to-peer between the subscribers and each chunk has signature checked against public key of the publisher). A satellite uplink, or few clandestine connections to Hong Kong might be enough.

China is focused on blocking traffic entering and leaving the country (at border), which is tightly controlled. The focus is on blocking access for end-users. We have to do test to see if they are able to block traffic internal within China (which we doubt). We also think there is minimum ability to block traffic within and between data-centers within the country. Most of the blocking will be at the border between China and rest of internet and at the ISP level on the individual user.

Yes. Right now development is disorganized. Trying to get all developers in one place. Skycoin has a large number of active developers, but very few of them are working at one time, because no one knows what needs to be done. There is not enough project documentation and technical specifications.

I think there needs to be a developer chatroom. Marketing and most everything outside of the core cryptography and blockchain, will be handed over to the community after launch. After the darknet is up, communication will increase significantly.

The meshnet will be a massive coordination effort. It requires people on ground and several different hardware teams. It will probably require ASICs eventually and its an undertaking far larger than the coin implementation. Right now the focus is finishing the coin IPO, then getting the darknet working at basic level. This will enable file sharing (distributed file system), websites and communication tools. The darknet will still be useful, even if it is merely running over traditional internet.

Then we can add mesh, peer-to-peer connections to the darknet topology. Then eventually tunnel normal internet traffic over the darknet/meshnet to a peerage point and transit back to the normal internet (similar to a VPN, but running over meshnet to exit point). Just getting those simple steps working, would be a great achievement.

The good news, is that after much frustration and coding, we discovered that the meshnet/darknet implementation is actually much simpler than imagined. The internet will face palm at the power and elegance of the resulting architecture.  The implementation is simple enough, that there can be no unanswered questions about its security and the performance and privacy are beyond Tor. Tor is over 180,000 lines of code and this method is clearly superior with significantly less complexity and higher performance.

Update

We have library now, for checking the unspent outputs for addresses. We are using obelisk tool kit and it is working well. The bitcoin blockchain synchronization has been running for a week now. It is on block 285,100 of block 323,354. It is 70 GB on disc and we dont know why. It has slowed down periodically, but has not stopped completely like bitcoind has. It is downloading a block a second. Blockchain synchronization should be finished within a hundred thousand seconds in the worst case (hopefully) and then we can test to make sure the IPO software works.

A basic exchange will run over bitmessage and possibly IRC. Bitmessage will have a few problems. You have to download 20 GB of messages before the message response appears. The server will also only be able to send out a few messages per minute because of the PoW requirement on the message. Another solution, might be a web server with cloudflare and it might be enough, depending on the DDoS conditions. A tor hidden service is another option. The Skycoin darknet is not ready to host this application yet because required components have not been implemented yet.

We want to get the IPO over and get back to the darknet and encryption utilities.

Update:

Two separate people are independently working on the IPO script. Should get done soon.

Another dev is trying to fix the merge conflict and error that is appearing on the github repo.

The main dev doing the design work is disorganized and prone to burn out. We are forcing him to get an engineering project management and to write things down, so other people can do them.

Documentation and descriptions of software libraries that need to be written, will be placed on Github immediately. We are not waiting for Aether/Merkle-DAG to be completed to release documents. Document releases will be smaller, more frequent.

Tutorials for developers are going on a github wiki.

Initially we thought, the darknet would be working fairly quickly and we could run the whole client on top of it. However, now parts of the coin could not be finished because it required infrastructure that was not implemented yet. We are moving away from relying upon infrastructure that is not completed and focusing on what we can get done now

In particular
- the darknet will be in Golang, not C
- the darknet will be separate from the daemon for the coin, until its ready
- the coin will use existing modules and will not transition to Merkle-DAG for block storage, until Merkle-DAG is working

We will release a prototype consensus algorithm and run the chain on top of that, with some safe guards (developer signing key) to deal with attacks/errors that arise. This will protect against loss of coins, while allowing us to launch. The consensus mechanism will be deployed in stages, instead of trying to make it perfect and 100% implemented at launch (which may delay launch another year).

IPO Update

The IPO cannot work the way we originally intended. There is no way to cap the number of Bitcoin per person that can participate in the IPO.

Browser finger printing does not work. It cannot reliably detect which users are bots and which are not. Bot nets and even proxies still get through.

Then we were going to do IPO over Bitmessage, but with validation of Bitcoin talks username. However, there are people who have several thousands Bitcoin Talks accounts registered. These users would be able to participate in the IPO multiple times, but normal users would be unable to.

The other frustrating thing,
1> The bitmessage library for golang we were using does not actually work. We had to rewrite the IPO script into python. Ideally, we would have used JSON/HTML requests on Bitmessage and use golang, but the Bitmessage API implements XMLRPC... (There is a massive effort underway to rewrite Bitmessage on C++ and create language bindings for each language, so these problems should decrease over time)
2> When building the exchange for doing the IPO, we had to use bitcoind. There is no RPC in bitcoind to check the balance of the unspent transaction output set for an address. We originally intended to generate a list of private keys and addresses on a computer never connected to the internet and move the address list to the server running the IPO. These offline addresses were to be used for receiving IPO funds and their balance queried by the server. This would prevent bitcoin from being stolen if the IPO server was identified and hacked. However, this is impossible under the Bitcoin API, for the same reason that Bitcoin makes building mobile thin clients very frustrating. We have to do the IPO with a hot wallet and move the coins into the cold wallet over time instead of just receiving the coins into a cold wallet address. We thought there was some way to get the unspent outputs for an address with bitcoind, but this is apparently very difficult.
3> Some git accident happened and the deterministic wallet input feature in the Skycoin wallet GUI seems to have disappeared. This feature is used in the IPO for importing the wallet the addresses coins are received into.
4> The server running bitcoind for the IPO, is taking over four days to download the bitcoin blockchain. I keep deleting peers.dat and restarting it and it goes for a few hours and then stops. Slow peers are slowing down the download.

Good News

The whole project scope is being laid out in a document. It describes at implementation level, each component and what is required. This should enable project development to escape the existing bottlenecks. We are close enough now, that running out of new things to develop is on the horizon. The darknet design is substantially done. It ended up being very simple.

The consensus algorithm is has been simplified. Implementation will be 150 lines, instead of ten thousand. Everything was stripped out that was not needed for operation. If a chain fork successfully propagates (very restricted conditions), the client will replicate both chains and defer to the operator of each node to choose manually which chain to prune. All the honest nodes should end up on the same chain and the attacker nodes will split into a separate network.

Bitcoin is vulnerable to netsplit attacks, but the conditions required are difficult to achieve and have not been observed. Theoretical netsplits may not be a threat we should be focusing on at this point of development. Especially if handling this edge case was 90% of the complexity in the consensus algorithm.

IPO Timeline

The IPO script is in progress. I dont want to give a date, when it will be ready because it will probably take longer.

Update:

We are dealing with a frustrating issues. Will post an update when it is resolved.