Yes. Preregistration generates a public key for you and then sends it to us through Bitmessage. You have to write down your private key, because you will need it later.

You also send
- your Github account name
- Bitcoin talks name
- Approximate number of Bitcoin you want to put into the IPO

Pre-registration is to gauge IPO demand and control IPO so its fair. There are 100 million Skycoin. Between 2% and 10% of the total Skycoin will be sold in the IPO. The valuation will be 10 million in the first round IPO.

Pre-registered users will be able to use their private key to participate in the IPO. The IPO is designed to be over subscribed. If you send 10 coins, only 2 of them may end up participating in the IPO and you will receive 8 coins back. This is to ensure coin scarcity and to deter speculators.

After the IPO, a spreadsheet may be published with bitcoin addresses in/out, balances and Skycoin awarded, so that fairness of the coin distribution can be publicly verified. Some information will be omitted to protect privacy.

The IPO may have tranches. The first tranche is equitable and designed to make sure everyone gets coins at the IPO valuation. Developers will get a bonus in this tranche. Then there is the whale tranche and is a free for all.

The IPO may be split into a series of smaller IPO, but it is not decided yet.

The Skycoin IPO is not a first come first serve IPO. There is no bonus for sending Bitcoin early at the beginning of the IPO period. All participants within the IPO window are treated equally. The IPO is not uncapped with unlimited amount going into the IPO.

After the IPO, there will be rolling distributions, where people can buy newly issued coins. Instead of issuing coins in a big-bang IPO, which only enriches the people involved in the IPO and deters new users (Mastercoin style IPO), Skycoin will be issuing the coins over time in a continuous process, with supply of new coins tapering and decreasing over time. The magnitude of the distributions will be chosen to support price stability. Distributions will increase if price increases too rapidly and will decrease if price declines.

We are trying to keep coin bounties, project awards and distributions as public as possible. However, everyone is very busy and no one has had time to keep the ledger updated. We want to get the majority of the coins in users hands within five years. We do not want to end up in a situation like Ripple where the developers control 98% of the coins and are threat to price stability.

Skycoin development started two years after Bitcoin was released. The Skycoin Project is almost as old as Litecoin. I cant even remember if Bitcoin had hit a dollar yet or if there were even exchanges when project started.

The first version was in python and was completely working. Then codebase was moved to C++, then moved to Golang. So it has already gone through three language changes. The longest working Skycoin blockchain was running for four months.

As soon as we release it publicly, no more major changes to the blockchain format can be made. It would require a full blockchain reset. We did not want to do a full blockchain reset every week until every issue was address to perfection.

Bitcoin was a prototype cryptocurrency. It synthesized the components required and is the foundation for everything that came after it. Bitcoin is a tremendous technical achievement, but falls short of achieving the original vision of cryptocurrencies.

Originally, many people believed that there would be a proliferation of cryptosystems, with nation states, companies and communities issuing their own. There was to be a proliferation of instruments beyond cryptocurrencies and cryptoequities, bonds, options and other instruments would be developed. Eventually traditional assets such as real estate would be owned and transferred digitally.

Instead, Bitcoin became a global single currency, with a global ledger and was restricted to merely currency transactions. Instead of being in control of the community and stake holders, Bitcoin is in control of the miners and the foundation.

When Satoshi envisioned Bitcoin, he assumed that you would have 100,000 Bitcoin users and they would run a mining application and an attack on the network would require 50,000 people to collude. Satoshi did not intend or envision for power over the network to be so concentrated that the largest two mining pools control the network.

If a town in Argentina wanted to issue its own community currency to facilitate trade and stem off hyperinflation, they couldnt. Under the Bitcoin model, they would be 51% attacked within an hour of launch. Skycoin is building the foundational infrastructure to enable cryptocurrency proliferation at the community level.

Instead of having a single ledger, there is a proliferation of ledgers. A company may issue its equity on its own ledger or may outsource the ledger to a third party cryptoequity exchange. A bank with dozens of branches on different continents may create its own ledger for securely performing internal transfers between the bank branches. A community or country may have a ledger for its currency and assets.

Distributed exchange allows instant inter-conversion between all cryptoassets. If a merchant only accepts Bitcoin and a user has Dogecoin in their wallet, then conversion happens automaticly. A user can hold any currency pair and pay in any currency pair. Digital exchange, means that if a merchant accepts any cryptocurrency, they accept all cryptocurrencies.

Launch for Skycoin is something we have to get out of the way. However, it will be underwhelming. There is still years of work to do. We are still very early. We are not even at start of second wave yet. Bitcoin is only at ten or so billion dollars. Less than 0.001% of world assets has gone digital yet. The ecosystem is still focused on penny stock pump and dumps and marketing, rather than creating useful or valuable digital assets.

If you have a good design, its invisible. People take it for granted that using it is easy and that developing new things does not take much skill or effort. If you have a bad design, its painful and you end up with fragmentation (for instance, the lack of a thin client standard for Bitcoin. the difficulty of checking an address balance and making a payment without syncing the full blockchain on your phone).

Having 20 million dollars is not going to buy you a good design. Having fifty engineers will not buy you a good a design. Trying to do everything will not result in a good design. Its difficult, time consuming and frustrating work. It takes as much as eight times the effort to make a good library as a piece of code that merely works. We have written and thrown out over 180,000 lines of code so far. Refactoring, evaluating and cleaning up code to get a good design has definitely been the most frustrating part and more time consuming than getting the functionality merely working.

Satoshi never tried to approach the global optimal. He grabbed whatever tools were at hand to get the job done. Bitcoin works, but no one would call the implementation elegant and no one who has to use the codebase would say its easy to work with.

When we are done, creating a new cryptocurrency will be easier than running a web server. Within the first second, there will be a liquid market for the new coin. If anyone is willing to buy it, with distributed exchange you will be able to spend the new coin for Bitcoin. It will speed up the pump and dump cycles until new coins are being created, pumped, dumped and abandoned by the hour.

My favorite thing recently was when NXT sold ownership shares on a painting. Now you can own a millionth of the ownership shares in a painting through a blockchain. The painting is now publicly traded! How long will it be, before someone buys a house by crowd funding the mortgage by securitizing the mortgage payments and selling them on a blockchain?

How long will it be before someone buys a pizza with a collateralized debt obligation? We still have a lot of work before that is possible. In the long term, these technologies will fundamentally change the meaning of debt, credit and currency at the level of the individual.

This technology pushes debt and money, down to the level where if you buy a pizza with your cell phone and it is $20, you might have a credit line at 10% interest for $1000, but the computer will look at multiple lenders and see if anyone wants to buy the debt for the pizza and the cell phone might find someone willing to buy the $20 debt for the pizza at a 6% interest rate. The pizzeria's computer may even decide to sell the pizza for a $20 debt obligation at 6% interest directly. The transaction is between peers and there is no credit card company to extract a $0.60 + 1.4% toll on the business.

When the technology gets pushed down to that level, Banks, Stock Exchanges, Credit Card companies no longer exist as discrete entities. Money creation is happening at the individual level, instead of through banks and the nation state.

There are multiple ways that cryptocurrencies can evolve. There are multiple competing visions for what the future will look like. Different geographic areas may have different dominate visions for cryptocurrency proliferation. The Skycoin project is aimed at building the foundational infrastructure that is required for realizing those visions.

Realistically, we should be look at a five year horizon for achieving all project goals to perfection. Good ideas are worthless if implemented poorly. Ripple, Open Transactions and even Bitcoin have been handicapped by poor implementations. Bitcoin succeeded, in spite of, not because of how easy it was for developers to use as a platform.  

UPDATE:

The registration app is compiling but not working on 64 bit OSX with golang 1.3.  We are getting a segfault in one of the dependency libraries. OSX might have a cache we are not clearing out.

The build engineer for OSX is on vacation until the 2nd. So IPO pre-registration will begin on the 4th and last two weeks.

Update: IPO

IPO pre-registration begins in a few hours. Trying to get binaries compiled and making sure this bitmessage library works.

Pre-registration will last two weeks. Until the 6th of September. Pre-registration will be required for the IPO.

During pre-registration, you run a program (or from source), it generates a private key/public key pair and sends it over Bitmessage. Then another server will send back response confirming of registration in the IPO. We are testing the bitmessage library now.

UPDATE:

The registration app is compiling but not working on 64 bit OSX with golang 1.3.  We are getting a segfault in the ECC public key generation and this should not be happening. The build engineer for OSX is on vacation until the 2nd. So IPO pre-registration will begin on the 2nd or 4th.

Update: Development

We are writing 240 pages of technical documentation. It outlines at code level, how to use the libraries, what works and what needs to be done. The technical documentation outlines at detail required for implementation.

We are now on fourth generation infrastructure. There have been so many refactor, redesign cycles. We have finally arrived at a stable design which meets requirements and has an elegant implementation. Aether has been significantly redesigned and the new design simplifies the blockchain sync and consensus process.

Way too complicated, but good job. Something simplier?





Like this. This is perfect. Except for the gradient background. White background, not too embellished or cluttered.

Bounty:

I need a chart for IPO prospectus. I need this chart in 2x2 matrix, with bitcoin and Skycoin in upper right quadrant. 400 coins for best chart, 300 coins for second best. Change captions/labels if you can think of better ones. Up to 600 pixels wide

Yes. It is actually faster than TCP/IP. ISPs do "hot potato" routing. The latency should not be worse than TCP/IP and in theory can be faster.

The privacy guarantees are
- each node only knows the previous and next hop
- transmission between nodes is encrypted
- transmission is encrypted end-to-end
- your transmission is protected against man-in-middle attacks through the use of public keys for node endpoints (network addresses are public keys on the network)
- all encryption is deniable and ephemeral
- the protocol is designed to frustrate attempts at deep packet inspection to identify users running the protocol (no fixed ports, no known plaintext in wire format, fixed node connectivity for backbone and so on)

So it is like a very low latency TOR with micropayments for bandwidth.

- It is more secure and has higher privacy than HTTPS
- it is faster than TOR and scales but there are still attacks against it.
- the code is much simpler than TOR, so there is less room for backdoors or hidden vulnerabilities. There is only one external dependency in the whole implementation.
- If you need absolute security against timing channel attacks, you should use a mixing service or run Bitmessage on top of the darknet
- all low latency networks are subject to timing channel attacks


Route Servers :

Yes route servers are a weak link. For maximum privacy you should run your own internal route server.

However, if you do use a public route server, you are connected to it through several hops, so it cannot identify you. It would still be safer to run your own.

Handling of Micropayments for Bandwidth

The way micropayments are handled, is through a third party. The node connects to a "gateway", deposits a coin with the gateway to get a credit. The node can now generate pseudonymous 64 bit "addresses" with the gateway. The gateway does not know the identity of the connecting node. It only knows the previous hop the connection came through.

So if you establish twelve connections to the gateway, they look like twelve different users to the gateway. Eventually communication to the gateway will be over an asynchronous messaging channel.

The node forwarding the bandwidth, connects to the gateway also. The two nodes can now pay each other through the gateway, without the gateway knowing the identity of either of the two nodes. When a node has enough coins in credit (a full coin), it can generate a new Skycoin address and withdrawal the coin to that address. Gateways are only handling small amounts of coins

A gateway in the Skycoin protocol is any server that holds coins or account balances on behalf of 3rd parties. Gateways are deposit institutions and they have their own protocol and API.

Eventually,
- there will be multiple gateways and cross gateway coin transfers. These transactions occur in private and do not appear on the blockchain until you withdraw the coins from the gateway.
- messaging with gateway will occur through an asynchronous communication channel (each message steam will get a new pseudonymous identity)
- part of the gateway protocol is an OT implementation, which allows you to prove if a particular gateway is stealing coins. You sign each API call to the gateway, then gateway executes and signs the output. So there is a chain of linked signatures and transactions and the gateway cannot make coins disappear without being able to forge your signature. If you deposit coins somewhere and they disappear, you can publish your transaction log and then the owner of the accused node has to produce a log showing that you authorized the coins to go somewhere. If they cannot produce a signed API call, then it proves they are lying/dishonest.
- Eventually exchanges will operate under the gateway protocol

Your suggestion of having a public blockchain for the internal balances in the gateway is interesting. I think putting the internal transactions on a public personal block chain, could keep exchanges honest while still maintaining user privacy.

Most of the developers are not working out of that repo. There are three repos. Each one is using a different version of the wire protocol and we have been trying to merge them into a single repo for four months.

The problem is that it is very difficult to move the blockchain download process into an isolated service. We tried to do it as one large refactor and it failed. After writing more code and abstracting the networking library, we finally figured out how to do the refactor as a series of small changes that individually did not break anything.

Daemon and visor are currently a tangled bundle of code and lack elegance. We want to split them off into
- library for handling/storing blocks (blockdb)
- library for downloading the blockchain, given the blockchain public key hash (a service; dependency on blockdb and skywire)
- a service for exposing the JSON RPC the local web wallet is built on
- the actual blockchain state manager (the visor)

The service is being moved into RPC. The dependency of Daemon on Visor is being severed. The visor itself exposes networking over a service on the Daemon. The networking is being changed to an RPC interface to simplify using the wire protocol. The JSON RPC is being moved out of Daemon into Visor. The block database is being abstracted into a library that  Visor pulls in.

Once that is is in place, we can launch. Its a small series of changes.

Then everything is in place for "ghetto consensus" which is a simplified form of the consensus algorithm which is easy to implement (and better than Ripple) but which is just a place holder. Ghetto consensus is being replaced with a version built on top of the Merkle-DAG system, once the library is implemented, then incremental changes made until it achieves the security properties against the known attack scenarios.

After "ghetto consensus" is working, focus will shift to distributed applications and meshnet for a while.

Yes. Please figure out some way we can streamline communication.

The original plan was to put it on Aether, however it will be months before that is working. The networking refactor was a major headache, was a massive amount of work and ended up going nowhere, but took four months. The upside is that we have a very clear architecture now.

The current plan, is that the IPO prospectus is being written. It is about 200 pages. It lays out each component in the Skycoin project, in the details required for implementation. Then coin bounties will be assigned for implementation.

Then we will focus on the meshnet/darknet implementation, put bounties on what we can and focus on the consensus mechanism implementation once the libraries we need are ready.

Skycoin is written as a series of libraries. The libraries are general and reusable. There libraries for networking/rpc, for parsing a blockchain, for replicating blocks between peers, for cryptography and so on. The problem is that writing good libraries requires significantly more design effort than writing blobs of code that merely work.

The community has to take over as much as it can and operate independently of the developers. Maybe we can use a ticket system for bounties?

We can quickly get the software working for transport and encryption working, but the meshnet development has to be on a ticket/bounty system to get all the components in place. We are scoping out the meshnet requires right now and writing up documentation/guidance.

Then there are other organizational issues. We have coordinate with the meshnet hardware groups, do testing, share results, hardware selection, ordering and coordinate local community meshes to get long distance backhaul connections setup. We need software for mapping the meshnet nodes, for reporting connection statistics and allowing node operators to optimize their deployment topologies.

For instance, we need someone to construct a platform that rotates in x/y plane and has controllable tilt. We need to put an antenna on the platform fed with standardized power level and need to put a hackrf 20 ft away and need to measure transmitted power density at the receiver, as a function of angle for different antenna configurations. This data will tell us minimum power we need to transmit with for line of sight to reach a given bandwidth over a given distance with a given noise floor for the receiver.

We need a way of locating Skywire nodes in physical space. We need a cheap active phased array element circuit for inducing phase shifts in a 2.4 Ghz signal. A system might use a GPS and two antennas and measure signal strength from a Skywire node using a HackRF as a function of the induced phase shift between the antennas. That would give us a direction. Multiple readings from multiple positions would give us a spatial position for node. Then people have to put these on their cars and collect data as they are driving around.

Data like this, would probably be uploaded to an aether store as its collected and then aggregated by other applications which expose it over APIs over which other applications can be built for visualization.

We need terrain topological maps. We need to be able to determine which mesh sites a person has line of sight to if they are in third floor on the south side of a building in a particular location. We have to identify collocation sites that are neural and can provide backhaul, so we are not reliant upon comcast and have to establish long distance links spanning out from those sites.

We need nodes to automatically report bandwidth and connectivity statistics (probably into an Aether store). We need reporting for fine grained performance statistics on noise floor, signal strength, connection reliability, throughput and latency. Then we have to aggregate and expose this data on an API for applications.

The earliest network will just be nodes peered over internet. Then a physical mesh will be built out with fixed, point to point directional antennas using commodity 802.11 wifi. Then we move into specializations of commodity 802.11 hardware and eventually a full Software Defined Radio (SDR) network.

The ideal network is going to be point-to-point with directional "pencil beams". By using multiple antennas and inducing a phase shift between the signals through each antenna, we can do active signal rejection so we are only receiving signals coming from a particular direction. Active signal rejection also enables us to triangulate node positions in physical space. We can also transmit highly directional beams that focus most of the beam power on the receiver instead of irradiating it into space.

An ideal hardware configuration, would be something like a 16x16 cm flat sheet with a 4x4 antenna array that someone can just hang out their window, place in window or put on a roof.

A six antenna 2.4 Ghz phased array setup may be as simple as a few variable capacitors a transistor and a $4 arduino or it may be significantly more complicated. Hardware manufactures are reluctant to produce chipsets for the 802.11af whitespace that just opened up because of the FCC requirements. Chinese companies have released extremely powerful $15 to $35 USB Software Defined Radio (SDR) devices that are the size of a USB stick, but which can only receive. We may need custom ASICs or to partner with company building the devices.

We are also trying to standardize on UniPro bus standard for our hardware and we need an open source UniPro bus IP core. UniPro will be able to handle everything except the communication between the ADC and FPGA block.

Then there are questions about whether we should do the Quadrature Amplitude Modulation in the Analog to Digital Converter (ADC) block or whether we should just capture the signal and handle it in the FPGA block. Then there are cost questions, such as whether we can get by with an 8-bit resolution on the ADC.

Ideally we want something going up to 900 Mhz with at least 20 MHz bandwidth around the base band and at least four antenna ports, with ability to modulate phase shifts on the antennas ports and it should be single chip, then we would feed that into an FPGA. Even with an open source design, it will cost at least $120,000 to get something like this at minimum order volumes.

So the meshnet has multiple components. Meshnet will have many more teams than the coin/software side and the requirements are much more specialized. The hardware component of the meshnet effort is going to be an absolute decentralized mess, but will workout. People will have to form their own teams and manage them. The only thing we can offer is funding and guidance.

The objective is to get the price down as low as possible, so we want multiple providers, open source hardware. We do not want to be a position like the Trezor, where you have a piece of hardware that everyone needs and its $700 when it should be $5. We are talking to several hardware vendors and offering coin subsidies to offset the large cost of minimum hardware quantities.

The software, we are confident we are on track for meeting requirements for the coin. Even if it is taking significantly longer than intended. The meshnet to be more than a toy however is going to require massive organization on the ground at community level.

== Project Org ===

We have no idea how this is going to be organized. I think
- write up project spec in detail for each component, at level required for implementation
- launch coin
- assign bounties on sub-projects. setup ticketing system for managing sub-projects
- Get aether working as a wiki and for publishing webpages
- Get aether working as discussion board
- Get messaging users by public key working, so we can have email/bitmessage type system
- Move project management in Aether/Darknet

We are about to go singularity.We have a road map to where we want to be in the long term. We split it up into small projects and libraries, then are able to delegate them. A very concrete infrastructure we can move rapidly on, is coming together.

Architecture is slow unfortunately. It is only something that becomes good through experience.

Development Update:

We are exhausted. We just finished 4th cryptography audit. Some minor issues were found and fixed. All the issue involved impossible conditions, but are fixed anyways.


Cryptography Audit/Changes:

Fixed:
- Someone with a private key from a deterministic wallet who is able to do a SHA256 preimage attack was able to derive all subsequent keys in deterministic wallet (but not the keys for addresses preceding). SHA256 preimage attacks are currently impossible but may become an issue in thirty years. The new deterministic wallet generation function has been strengthened by salting the SHA256 hash with an intractable elliptic curve inverse operation.
- Private key generation takes a 20 byte value and always succeeded in the library we are wrapping. Some very rare keys (1 in 2^255 keys), which are larger than the order of the curve but valid 20 byte integers, passed the private key generation function without generating error, but could cause an error in later operations which enforced checks on whether the integer was less than the curve order. This condition is statistically impossible, but it is now being handled correctly.
-  If a seckey generation fails for a given input, the SHA256 of the input is used instead. This is recursive until the private key generation succeeds. This allows us to guarantee success of private key generation for any 20 byte input while retaining determinism.
- Improvements to determinism of cryptographic operations on very rare edge cases

Overview:
- Everything has been fuzzed and no defects were found for statistically occurring cases
- The deterministic wallet generation function can be considered final.
- All generated wallets, addresses and private keys from now on should be forward compatible with any future changes.
- Check sums for addresses are only the base58 representation of addresses and no longer in blockchain
- We have verified that the cryptographic functions are side-effect free and do not modify their calling arguments, to the extent that we are able to enforce that in golang
- Cryptography and hashing has been move to a standard library /src/skycoin/src/cipher. This library has the standard cryptographic primitives for building distributed applications. It can also be imported by other golang programs and used independently of Skycoin.
- Cipher Library is still WIP and new functionality is in progress.

We are delayed on problems with ChaCha20. We are getting different results from two different reference implementations.

IPO Website:

Now that deterministic wallets work, we can start the IPO. Someone is working on IPO website right now.

The IPO is open for a particular period. It is not a first come first serve IPO. We may do a small token, test IPO for testing website, then a scheduled, announced IPO. This is a very small distribution and not intended to distribute huge number of coins.

We have an immense amount of work left and this does not mean the coin is anywhere close to being finished.
We will do our best to ensure that
- sending coins work
- checking balance of address works
- if we have to reset the blockchain, that address balances will be preserved in the new chain.

Project Management: !!! Bounties !!!

We are beginning to see the overall project architecture and begin breaking the long term goals of the project into a series of very small, specific libraries.

We are beginning to post several development bounties on Github. Each bounty is for implementation of a library that satisfies a particular specification. Each bounty will be worth between 10,000 and 30,000 SKY. Multiple implementations and improvements to existing implementations are encouraged.

- One of the bounties is for implementation of libraries for Skycoin's distributed file system, which is very exciting
- One of the bounties is for implementation of a golang struct serialization library (mostly done)
- One of the bounties is for implementation of a reflective RPC library using the struct serialization library
- One of the bounties is for an implementation of a simple service that performs synchronization of a Merkle encoded Directed Acyclic Graph structures.
- One of the bounties is for a golang FUSE wrapper for the distributed file system (exposing files in memory to the operating system through the FUSE library). We have some example code.
- One of the bounties is for an RFC specification for a syndicated distributed messaging system (similar to XMPP) with no reliance on DNS (probably using server public keys and DHT lookup of IP address)
- Implementation of TUN adapter for meshnet
- design/implementation in C of minimalist virtual machine for deterministic execution of LLVM IR like language
- FPGA Verilog implementation of ChaCha20 core

Address Format:

The binary representation of Skycoin addresses are

struct {
   uchar8 Version;
   uchar8[20] PubkeyHash;
} Address;

PubkeyHash is computed from a compressed secp256k1 pubkey by SHA256(SHA256(RIPMD16(pubkey))). Skycoin only uses compressed public keys.

Version is 0. In Bitcoin, Version means "main network, test network". In Skycoin, version is same across different blockchains and is reserved in case stealth addresses, group addreseses or addresses with different len must be added.

The base58 representation of a Skycoin address is the base58 representation of
<PubkeyHash> + <Version> + < 4 byte checksum >

The checksum is computed as the first 4 bytes of SHA256 of <PubkeyHash> + <Version>

Note. The reason version comes after PubkeyHash is so that vanity addresses can have arbritary prefixes. This is very important. In Bitcoin the

For reference, private keys are

struct {
   uchar8[32] Seckey //32 bytes
} Seckey;

A private key is a 256 bit integer (32 bytes). The base point is raised to the power of the Seckey in the curve to generate your public key.

A public key is a point on the curve (a pair of two 256 bit integers) and has a compressed binary representation as 33 bytes

struct {
   uchar8[33] Pubkey; //33 bytes
} Pubkey;

A Pubkey can be "multiplied" by a seckey, by raising the pubkey (a point on the curve) to the power of the seckey (an integer). This generates another pubkey. This is the basis of Elliptic Curve Diffie Hellman Key Exchange (ECDH). Skycoin will soon have a standardized encrypted message format using ECDH with ephemeral keys and ChaCha20. This functionality will be exposed as a library for application developers.

Consensus:

After doing a finite state machine diagram, we determined that the distributed time stamping system did not add any security over the node using its local clock. Therefore it is not needed for preventing 51% attacks. However the distributed time stamping system can be used to prove to third parties the publication time of a block.

The new system is much simpler. Consensus nodes will still affirm receipt of blocks by publishing the block's hash in their personal block chains in the next block after receipt. Nodes will remember the time they first learn about a block using their local clock and that will be used for negotiating consensus during chain forks.

Bitcoin
- accepts blocks up to 300 seconds into the future from system time (its a fixed window)
- sets local time by averaging in time delta from the nodes the client is connected to (nodes in bitcoin are unathenticated)

If are evaluating if there is an advantage to a stricter window and more accurate clocks.

Skycoin will use deltas from the trusted consensus nodes to set local system time and use NTP severs for verification. If the NTP servers and trusted consensus nodes go out of sync by more than a reasonable window, the client will go into warning mode and all transactions will be considered pending and unconfirmed until the issue is resolved (to protect exchanges against double spending attacks).

Valid block headers whose timestamps are too far in the future, will still propagate to allow time stamping by consensus nodes. We are still working through whether anything needs to be done about these.

Reducing Block Propagation Time:

In Skycoin, in the long term we are trying to keep the time between announcement of a block and receipt by all nodes to below 2 seconds across the global network. There are two reasons for this
- ensure timestamps with local clocks for block publication times are reasonably accurate
- enable real time transactions with confirmation times in seconds

Bitcoin is very robust and has a very low orphan rate, despite block propagation speeds because of the 10 minute block time. However, other coins with more frequent blocks have been subject to Sybil attacks. The altcoin is flooded with thousands of nodes, which forward blocks mined by one pool very quickly, while uploading blocks from other pool at the slowest rate possible. Combined with small time between blocks, this has led to several 51% attacks on smaller coins.

In Bitcoin, when a client gets a new block
- the client announces the hash of the block to each node it is connected to
- the client looks at the hash and determines whether to download the block
- the client requests the block download
- the client waits for the download to finish. The client can only download the block from one peer at a time.
- the client transmits a hash of the blocks to its peers

The fact that Bitcoin only downloads blocks from one peer at a time, means that a peer can delay propagation of a block by purposely uploading the block as slow as possible. This has not been an issue for Bitcon, but has been a significant problem for coins with faster blocks.

There are several bottlenecks for propagation.
- There is a round-trip delay between becoming aware of the block and requesting download
- There is a delay for the download and bottleneck from downloading from a single peer
- Bitcoin blocks are generally 50 KB to 500 KB, which cannot be downloaded instantly

In Skycoin, there are several things we can do to reduce these bottle necks

In Skycoin when a client gets a new block
- the client broadcasts the header of the block (~60 bytes) to all connected peers
- the client can rebroadcast the header before the body has been downloaded
- the body is downloaded through a separate mechanism
- the block body is part-file encoded, so that the body can be reconstructed from any N of M messages generated from the body, allowing download of the body in parallel from multiple peers. Each part-file encoded segment is designed to fit into fragmented maximum MTU UDP packet.
- the blocks in Skycoin are very small (micro-transactions are done off blockchain, skycoin transactions are smaller than bitcoin transactions) and more frequent (seconds instead of minutes)
- option to connect to authenticated nodes, who can speed up block propagation, but cannot slow it down. Combination of authenticated nodes and random nodes, reduces sybil attack potential for delaying block propagation. Bitcoin mining pools are already using dedicated connections between pools to minimize orphan rate and we want to make this a bit easier for users to speed up blockdowns by pointing at a fast node (by setting public key of a fast node).

If you are connected to 10 peers and each block averages 10 KB and each peer sends a 1500 byte, part-file encoded block body immediately upon receipt of the body, without round trip delay then propagation delay is significantly reduced at the cost of some extra bandwidth usage. This is the fastest possible theoretical full block propagation, at the cost of extra bandwidth.

There are delicate DDoS edge cases that need to be designed around. If we prevent block propagation from blocks so far outside of the consensus set (forks of the chain more than N blocks in the past), then it eliminates certain DDoS attacks but leads to an edge case with netsplits, but also eliminates propagation of 51% attacks.

These are some of the long term technical measures we are looking at. We dont see a technical reason why global block propagation should take more than a few seconds.

Research Update

Incredible breakthrough on consensus. We have been discussing methods for distributed consensus, creating terminology for understanding the consensus process. We think we have a good formal mathematical model now.

We drew out a finite state machine diagram for client transition states and found a new way of reasoning about state. We discovered that there are security measures that can be layered on to coins, which provably only improve the security of the coin without possibility of introducing a new attack. The coin client has a finite state machine and there is an operator that composes with the finite state machine, creating  a new finite state machine. If a mapping from the new state machine back into the original state machine, exists, which satisfies a property, then no sequence of input exists where the new state machine fails where the original state machine did not also fail with respect to a security property.

The property was originally proven using a state machine and constructing a binomial lattice type diagram of the transitions for the state machine for a single input. The result generalized to machine with arbitrary sequence of input.

We are looking at Harel Statecharts and Hierarchical Moore Machines models now, for modeling the Skycoin consensus process and proving properties. We have very good results so far. If this works we can implement the Skycoin consensus system as a formal state machine being emulated by a golang program to ensure we get the mathematical guarantees on the security properties (such as state unreachability).

Types of Double Spending Attacks:

Types of double spending attacks
- Public Chain Forks: Two different groups of miners are mining on different branches, but are publicly publishing the blocks. This is not bad, because the client can run and replicate both forks. The client knows transactions are not final until the alternatives have been reduced to one. Exchanges avoid double spending by not crediting accounts until "10 confirmations AND there is only one public candidate chain". In contrast, Bitcoin switches from one branch to another aruptly, instead of running both alternatives until resolved and one chain is abandoned. Concurrent execution may be desired to switch over for some stability. Awareness of the publicly published alternatives allows exchanges and merchants to eliminate double spending as long as their clients are aware of the fork.
- Private Chain Forks: A miner with majority hash power, mines a longer chain in secret and then publishes it. Everyone switches to the new chain and previously "confirmed" transactions and blocks are reverted. This is the real threat.

Bitcoin is susceptible to double spending from Public Chain fork attacks, where a fork is public and eventually grows to overcome the main chain. Skycoin is not. The Skycoin client tries to be aware of alternate chains and for older history its impossible to create a public chain fork from blocks past a certain number of confirmations, which can become a consensus chain. The only issue left is ruling out chains that were mined in secret and then published to network.

We have identified two types of client behavior with respect to forks
- Hard Forking: As soon as the client sees a longer blockchain, it switches over immediately (Bitcoin)
- Soft Forking: A client is aware of forks and maintains state for both chains. The client has awareness that there is not consensus among the publicly published chains. Exchanges avoid double spending by not crediting accounts or counting transactions as executed until there is a single alternative chain (or until the transaction has been executed on both candidate chains). This is how Skycoin handles forking behavior.

We show that public chain forks are benign. They cannot result in double spending with a properly designed client.

We show that timestamping can be used to eliminate the Private Chains from being accepted. This is the last challenge to eliminating economically significant double spending attacks in Bitcoin like systems. For simplicity, we examine different centralized solutions, then will discuss decentralized alternatives.

Example System for Analysis:

Example 1: Insecure Time Stamping
- Security property: 51% attack proof (a person should not be able to get client to change to a blockchain fork  once a block has reached 10 confirmations.
- In Bitcoin the longest chain is valid. A person can mine a longer chain in secret and publish the chain and each node will switch to the new chain.
- Example Attack. At block 5 a person mines a secret chain fork to block 20. The public chain is at block 15. Block 5 has 10 confirmations.  
- Attack: Each public node accepts the chain with 15 blocks as valid. The attacker publishes the secret 20 block chain. Each node sees that the chain is longer and downloads it. Each node switches to the new chain. Transactions may have been reverted (The attacker deposits Bitcoin to exchange, gets Dogecoin, then uses the chain fork to revert the deposit transaction. The attacker now has his Bitcoin back and the Dogecoin).

Here we have
- node state
- condition transition between the nodes states
- an attack success state
- a security property (reachability of the attack state)

Assume we have a trusted 3rd party time stamping server. The server signs each publicly announced block after it has received five confirmations. A client will use the time stamps to determine which chain is valid.

In this system
- an attack on the time stamp server can be used to 51% attack (by only signing blocks on a chain fork instead of signing the public consensus blocks, resulting in the clients rejecting the valid chain.)
- an attacker with majority hash rate cannot perform a 51% attack without also compromising the timestamp server. If they mine a longer chain in secret and later publish the chain, then the clients will examine the time stamps by the 3rd party, realize that the blocks which would cause a 51% attack were not published to the network and reject the chain.

This system is not stronger than hashing. It introduces a new attack state transition (compromising the timestamp server).

Diagrams

To simplify analysis, we will gloss over network state and focus on individual clients. We will also simplify issue of orphan chains. To simplify analysis and diagrams, we assume that
- the client has a consensus chain (the longest chain the client knows about)
- we ignore issues of orphans and assume blocks are either successors to consensus chain or an unpublished side chain, that is being published in a 51% attack.
- this analysis for simplicity is client level, not network level

Some of these nodes are "State nodes" which represent changes in state of the client chain. The state nodes are the symbols the model emits in each round in response to an input. Other nodes are decision nodes, where a node must make a decision. There is actually a series of "state nodes" in succession, an input comes in and then an output is emitted by the machine on certain nodes, then the machine resets and the next symbol comes in. The diagram over a sequence of inputs actually looks like a linked Markov model diagram. Each transition node itself, could be a program which looks at some state variables and outputs the transition.

The decision nodes, themselves may be state machines themselves (hierarchical state machines). The network enters the sub-machine and the submachine emits the transition the parent machine is to take, as an output.

These diagrams are simplifications of a more precise hierarchical state transition model which is still on paper. Issues such as netsplits, clients joining the network are ignored as special cases.

System1:



Rules:
- Normal Bitcoin
- Client Accepts Longest Chain accepted

States:

S1: Client accepts new block on existing chain
S2: 51% attack. Client accepts chain that forks at a block which has more than N confirmations

Transitions:
T2: Normal operation. Addition of blocks or acceptance of new chain, which does not fork at a block with more than N confirmations
T1: New chain is longer and forks at a block which has more than N confirmations

End Nodes:
S1: emits action to do nothing or extend the current consensus chain
S2: changes the consensus chain

The client reaches S2 and the 51% attack succeeds only if the new chain is longer (more hashing power).

System 2:

System two is system 1 but with a developer run timestamp server, to prevent 51% attack



Rules:
- Client accepts longest chain
- If blocks with more than N confirmations must be signed by time stamp server or are rejected

States:
S1: Normal Functioning (stop node)
S2: A new longer chain has been presented to client. The presented chain forks current consensus chain before a block that has N confirmations. The client needs to decide between the old consensus chain and newly presented chain. The client accepts the chain based upon time stamps
S3: Attacker succeeds and attack chain was accepted

Transitions
T1: Normal operation. Extension of current consensus chain. Block must extend the current chain. If addition of the new block to the chain would cause the block to go over N confirmations, then it must be timestamped by the server.
T2: New longer chain presented to client
T3: Client accepts chain which is potential 51% attack
T5: Client rejects 51% attack chain and maintains current consensus chain
T4: 51% attack without majority hash power. Attacker compromises timestamp server and client rejects the legitimate chain for the attack chain. The client will reject blocks with more than N confirmations, which do not have timestamps. The attacker simply only timestamps the attack chain, until it becomes longer than the current consensus chain.

State Nodes:
S1: emits action to do nothing or extend the current consensus chain
S3: changes the consensus chain

Decision Nodes:
S2: checks time stamping server to determine whether to reject the 51% attack chain (T5), or accept the chain (T3)

The machine starts at S1. Under normal operation (a new block extending the current consensus chain) T1 is taken and the consensus chain is extended uneventfully.

There are 4 conditions
1. normal operation (no 51% attack and working timestamp server)
2. 51% attack and non-compromised timestamp server (attack fails)
3. Attacker does not have enough hash power to create a longer chain, but compromises the timestamp server to get clients to reject the legitimize chain (attack succeeds)
4. Attack has majority hash rate and controls time stamp server (attack succeeds)

This system is interesting
- it cannot operate without the developer timestamp server. the system stops without the timestamp server
- the timestamp server has no control over transactions in blocks but can veto blocks and cause small forks which revert up to N blocks by not time stamping blocks from that chain
- with linked timestamping, signatures and peer-to-peer replication, the timestamp server cannot backdate timestamps
- there is no 51% attack. After N block, confirmation consensus cannot be reverted, regardless of hash power. Transactions are finalized
- depending on implementation the 51% attack requires compromising the timestamp server and backdating timestamps (which can trigger a STOP condition, requiring human resolution). This should be treated as a special condition which cannot be handled automatically in software and requires human judgement.

System 3:

Here we use a timestamp server to rule out chains that were mined in secret and later published. However, we only fallback or even look at the timestamps if a switch over between chains is being considered. The timestamp server can prevent a double spending attack, but cannot be used to cause one.

- System 3 is system 2 with the T4 transition removed.
- System 3 is exactly like Bitcoin normally
- A third party timestamps blocks as it sees them, signs the timestamp and publishes it
- A 3rd party block timestamps only when a client receives a chain which would cause its consensus chain to change. Otherwise timestamps are ignored.

Rules
- the timestamp server timestamps all valid published blocks as it sees them
- timestamps are only used in S2. Timestamps are only examined if an incoming blockchain is long enough to become the new consensus chain and if that chain would replace the existing chain.
- S3 state literally means "Accept new longest chain"
- S1 state literally means "remain on current chain"



End States:
S1: extend current chain by one block or do nothing
S3: accept new consensus chain (accept fork)

Decision States:
S2: Check timestamps on forked blocks and decide to accept the chain as the new consensus chain(S3) or reject the chain and keep the current chain (S1)

Transitions:
T2: A new longer chain has appeared that would change the consensus chain. Move to S2
T5: The timestamps of the new chain were examined and the new chain was determined to be a 51% attack attempt (someone mined an unpublished chain until it was longer than current public chain and then published it). The new chain was rejected.
T3: The attack chain was accepted

In this system
- Two systems, instead of one must be compromised. The attacker must control both the timestamping server and must have majority hash rate, for the attack to be successful. The previous system failed if either of two systems were compromised. The current system "composes" by replacing a state node with a a sub-machine, which is only triggered if the first security measure has failed.
- Compromising the timestamping server cannot result in a 51% attack
- It is impossible to mine blocks in secret and the publish them to network to 51% attack, if timestamping server is working


Challenges:
- A client connecting to network must ensure that it has the same head and consensus chain as the other clients before running this algorithm, or it may end up in a different state than the other clients. Discussing this edge cause would complicate discussion, but there is a resolution if you work through it.
- Clients need a notion of "network state" and need to ensure they are converged. We think we have this solved (but not within Bitcoin framework, will discuss it later). Skycoin clients have notion of "network state" which is different from client state. Each client only has local information, so sometimes network state can only be inferred probabilisticly and requires a randomized process for global convergence from local information.

Assumptions:
- blocks may come in, in different orders on different clients and state of client will be same eventually, but propagation delay has to be reasonably low. We assume that if a block is valid the client will have received it reasonably quickly. Although blocks may come in different order on different clients,  If a block exists but is not propagating, the client needs to know, or else it can end up in a divergent state from the other clients.
- The client needs way of getting to the consensus state the other clients are in, before beginning the process or it may end up in a divergent state
- Monitoring whether the node is "converged" is part of the "network state". Network state is a property of the whole network of nodes, as opposed to the individual client or node state. Local state is based upon local information, where as Network state is an estimation of a property of all nodes as a network. The most important network state attributes for ensuring convergence, are netsplit detection and determining whether blocks exist that have been published publicly but which the client is not receiving within a temporal window.
- as long as the client can accurately estimate global state variables, then the edge cases at client startup and during netsplits can be mitigated. The attacks resulting from invalid global state estimation are rare, difficult to produce and not that severe. They can be ruled out by simply cross referencing the local client's estimate of global state variables against a number of user chosen trusted clients. Global state estimation can be made arbitrarily reliable, depending on the requirements of the applications (exchanges which may be subject to double spending attacks will want higher reliability in global state variable estimation, where as normal clients will likely not care).

Implications:


By using a honest third party service which timestamps each block we can eliminate the Private Chain Fork attack. The timestamp acts as a proof of publication of the block. Blocks mined in secret and then later published will not have timestamps and therefore can be identified as 51% attack attempts.

Fair Timestamping:

The original Skycoin consensus system, gives each user a personal blockchain. The users publish blocks and subscribe to other user's blockchains. When a user becomes aware of a block, they publish the hash of the block in the next block published to their personal blockchain. Each published block is timestamped and therefore attests to the existence and publication of the block.

Alternatives:
- web of trust, distributed timestamping system (like Skycoin)
- delegated Proof-Of-Stake is used to elect five "fair" timestamping servers
- putting the timestamps in the Bitcoin blockchain
- putting timestamps or block headers in different altcoin chains and then referencing them against each other. This exploits tags like Mastercoin uses, which are not stored in the unspent outputs but which can be embedded in blockchain and querried.
- each coin can be check-pointed in the blockchain of other coins and the checkpoints countersigned. A significant 51% attack which reverts a coin back to significantly earlier block, now requires simultaneously 51% attacking a dozen other coins. This is Skycoin's distributed timestamping system, but operating on altcoins chains instead of personal chains.
- banks and financial institutions running centralized cryptocoins who do not want to incur the security costs of mining, may run their own centralized timestamping servers

Proof-of-Stake with Delegated Timestamping:

Bitcoin combines three separate things in a single entity in the block headers
- consensus, determining which chain is the correct one, "network state"
- choosing who gets to create each block
- rate limiting block creation

In Bitcoin these separate functions are combined into a single block header.
- the group of miners with the most hash power determines which chain is valid
- the miners choose what is in each block
- difficulty rate limits block creation rate

However, it does not have to be designed that way. In Skycoin these functions are separated out in a more fine grained way.

We could imagine a system where
- blocks are created by hashing through Proof-of-Stake (coinhours can be burned to reduce target or substitute for hashing).
- Proof-of-Stake is used to elect five timestamping servers (one coin one vote). Bad timestamp servers are automatically voted out.
- Each block is timestamped and signed by the public keys of each of the five elected servers. Consensus is determined by the timestamps (first block published wins. average of time the five timestamps).
- The timestamp servers will only sign blocks after they have been confirmed for five confirmations
- no block rewards for mining
- transaction costs in coinhours (no transaction costs, but rate limiting through coinhours)

In these systems the questions to ask are
- who determines what blocks are created
- how is the consensus chain determined

There can be different groups of people serving these functions

The consensus mechanism can be complex, can be outside of the blockchain and can contain multiple factors or mechanisms. Hashing is the weakest mechanism and most expensive per unit of security. Proof of stake is second mechanism but also imperfect. An ideal system would combine Proof of Stake with a second mechanism indepedent of coin ownership, where even a majority coin holder could not attack the system without also compromising the independent mechanism.

Crypti is very interesting. I like that the coin is in Javascript and that its from scratch. The Bitcoin codebase is a bit of a mess.

I wish Google would open source the Endo baseboards. Even if ARA fails, we are set on UniPro for interconnect standard. It could not be too much to produce our own modules and baseboards if absolutely necessarily. People doing UAVs, robotics, enterprise blade servers will want these baseboards. I dont think they should be pigeon holed into just being for cell phones.

With a UniPro baseboard, we can create independent modules for software defined radio and just plug multiple SDR modules into the board for antennas. China has $4 USB SDR units for digital television. They are receive only, but we know now that the units can be single chip and do not have to be expensive.

Development Update

Massive changes. Everything is now in one repository. https://github.com/skycoin/skycoin

Changes

skycoin/src/coin is the blockchain parser library
skycoin/src/cipher is the Skycoin Standard Crytographic library
skycoin/src/aether is the distributed application services library
skycoin/src/skywire is the Skycoin Meshnet/Darknet switch
skycoin/src/gui is the HTML local web wallet and infrastructure

- All of the cryptographic and hashing functions have been moved into a common library, that can be imported and used across different applications
- Skywire is now the meshnet/darknet instead of the services daemon.
- the services daemon is deprecated
- dht has been moved into its own library, skycoin/src/aether/dht
- Aether is now the name for the full distributed service stack, not just the distributed key-value store and personal blockchains
- The C implementation of the darknet relay is being pushed to skycoin/src/skywire as the code comes in

Future Changes:

- gnet is being renamed to something better. the library is getting an RPC style interface
- the new RPC interface will allow darknet services to expose machine readable interfaces
- peer lookup for distributed services (PEX) was previous in daemon. It being moved into a struct that can be associated with a distributed service through the RPC interface, instead of having a singleton in daemon for peer discovery. To use pex you will create a PEX struct for the service and then register the struct with the RPC interface.
- gnet currently handles the connection pool. Connection pool management is being switched over to the skywire darknet library. gnet will be deprecated, renamed and responsible for data serialization and the rpc module
- /src/daemon and /src/visor are undergoing heavy refactoring. These are the two modules blocking coin launch. The libraries they depend on are not stable and are rapidly changing. The new visor uses the distributed application infrastructure for blockchain sync and transaction relay.
- gnet functionality is being split up between skywire and aether and therefore the repository for gnet will be deprecated

Skywire: Darknet/Meshnet Switch:

There are four layers in the Skywire stack
- Physical layer. Physical connectivity over public internet, wifi, ethernet, fiber
- Switch layer. Handles circuits and forwarding packets between Skywire switches
- Application layer. This where route discovery, circuit bundling and native distributed application operate.
- Tunnel Layer. Simulates an IPv6 private virtual network so legacy applications can reach public internet or run over Skywire without modification.

At the physical Skywire nodes connect to each other over
- public internet (TCP, UDP)
- wifi (meshnet operation)
- private ethernet (connected by switch over ethernet or fiber)

The switch layer is very simple. A Skywire node connects to another Skywire node and then establishes a circuit. A packet inserted into a circuit is forwarded node to node until it reaches the destination.

- all traffic between Skywire nodes is encrypted
- traffic is encrypted end-to-end
- each node knows the previous hops and next hop, but does not know the source or the destination of traffic
- traffic is encrypted end-to-end
- the nodes keep track of traffic over routes exchange coins every once in a while

Skywire Switch Design
- The switch is written in C and designed to be extremely fast.
- This part of the network can be implemented in Verilog for FPGA/ASIC implementation.
- The switch communicates with a control node for reporting traffic statistics and managing coin payments
- On an ARM meshnet device with FPGA and multiple antennas, the switch would be implemented on the FPGA and the control node software in Golang runs on the ARM core.
- there is a default packet (short form header) and an extensibility flag. If the flag is set, the message will be forwarded to the CPU for processing. This allows for protocol extensions and means the protocol can be upgraded in future.

Division of Labor
- the core devs have enough time to get the switch working
- the community is responsible for the application layer and physical layer, but there are coin bounties for library writers!
- there is a golang library by falcore3000 for scanning and connecting to wifi networks in skycoin/src/aether/wifi

Meshnet Hardware:

We are standardizing on the ARA platform. ARA uses a UniPro baseboard that lets you add and remove modules.  UniPro provides power and up to 10 Gb/s of bandwidth between the components on the baseboard.

For an mesh node, you get a baseboard
- you add a dualcore 1.2 Ghz ARM cpu module with 800 MB of ram
- you add an FPGA module, to run the Skywire switch with full acceleration
- you plug in three antenna modules and wire them to directional antennas
- you plug in a gigabit power over ethernet module to power the node and provide connectivity to the other nodes
- you plug the node into a Ubiquity Power of Ethernet gigabit router

We believe this will be the best platform in the long-term. However, ARA will not be ready until January.

Community Handover:

Marketing, websites and so on will be handed over to members of community as soon as Aether is up we can coordinate it. A wiki will be created and hundreds of pages of documentation, roadmaps, milestones and infrastructure designs will be posted for discussion (and editing). There will be RFC requests for purposing solutions to problems and then process for getting solutions implemented and then integrated.

Skycoin IPO:

The IPO website is under development now. It will not be anything complicated because there is no time. The coins is launching as soon as visor is running on the new distributed applications library.

StorJ IPO:

The StorJ crowd sale has started! Their software looks great. http://storj.io/

I do not know if this is a good investment, but would definitely be worth running a node. They are using counterparty for the coin.

Crypti IPO:

Crypti is doing their crowd sale. New POS coin in Javascript with code base from scratch. Great team.

Development Updates

Skywire Repo Moved:

The Skywire repository has been merged into the main Skycoin repository. Still being integrated to replace visor and daemon.
 
Skycoin Cryptography Standard Library
 
All the cryptography, hashing and address operations have been moved into github.com/skycoin/skycoin/src/cipher

https://github.com/skycoin/skycoin/tree/master/src/cipher

The library is in progress. It will be common core for addresses, hashing and cryptography across Skycoin, distributed applications and wallets.

The new library will support
- secp256k1 public and private key generation
- secp256k1 signature, signature verification and chksig operations
- secure deterministic wallet generation operator (secp256k1 curve right multiplication with SHA256 hashing)
- secure random number generation (mixes entropy from multiple sources on top of system secure random number generator)
- SHA256 merkle tree implementation for radix 2 and 16
- ECDH (Elliptic curve Diffie-Hellman) deniable encryption with secp256k1 and ChaCha20
- SHA256, Ripmd160, ChaCha20 implementation
- Base58 encoding for Skycoin and Bitcoin Addresses
- may in future specify binary wallet file format for key storage

Project Management: Dependency Hell

Golang is a new language and dependency management is still difficult. We have different developers using different versions of different libraries in different repositories.

A typical scenario
- library A uses library B
- library B is updated and library A is broken because it uses the old interface for library B
- library B is now broken
- everything using library B is also broken

Library A and B have to updated in lockstep, but library A will not get updated to use the new interface for B until B pushes his changes and A breaks. The developer of A gets notification from someone using his library that the library is broken and will then update A.

In response we have been
- moving everything into single repo to avoid duplication of dependencies (short term solution)
- severing modules dependency chains (skywire does not import anything in coin)
- moving functionality into "base" libraries that do not import other libraries (skywire, cipher)
- reducing dependency chain depth to 2 from the base libraries

Unit Testing:

We had 100% coverage testing. The unit tests were extremely tedious and did not tell us if program was working. The complexity of the unit tests, helped simplify the program however. If something was difficult to unit test, it should probably be moved out or eliminated (such as time dependencies in the blockchain parser).

A few thousand lines have been gutted from project. Flow paths are being eliminated throughout the project. This will reduce the size of the unit tests. Features such as testnet addresses and rarely used command line options are being gutted to eliminate program flow paths.

We are moving away from 100% coverage testing and will probably focus more on functional and integration testing that can be done from outside of the module.

Deterministic Build Road Map: Autonomous Corporations

Four major security requirements for future altcoins
- deterministic builds
- program determinism
- process isolation

deterministic builds mean
- the average user should be able to compile/run the binary from source
- each user should be able to hash their binary and the hash should match the hash every other user generates
- developers cannot put back-doors in binaries. Users can verify the binaries.

program determinism means
- two users running the program with the same inputs on different hardware should get the same output
- this is necessary to prevent blockchain forks

process isolation means
- the program is sandboxed
- the program cannot access file outside of its directory (cannot steal wallets)
- the program cannot access network resources it should not need

Digital Autonomous Corporations: Technical Requirements

In the long term
- the source code for coins will be in blockchain (or a merkle hash of the source code)
- changes to the source code and client should be ratified by proof-of-stake election by the coin stakeholders

The source code is the bylaws of the corporation. The bylaws specify corporate governance (who can do what, who can change the bylaws and under what conditions).

So for instance, you may require that the source code for the coin be in the blockchain itself and that any changes to the source code require agreement of half the coin holders in a proof of stakes election. With the source code itself enforcing the vote counting and update. That is an alternative to a "foundation" controlling the source code and repository.

Bitcoin skirts the digital governance issue. Each participant in the network is allowed to choose a different implementation. Bitcoin is "decentralized" in theory, but in reality a small group of developers controls and owns the standard. Control of coins is decentralized and network operation is decentralized but control of the source code and the governance of Bitcoin is centralized.

If the implementations Bitcoin differ, the attitude of the foundation is "the majority of miners will just decide which implementation is correct. The miners control the blockchain and in theory have veto over changes to the source code, but in reality are helpless. The coin-holders (the stakeholders) have no representation in the governance.

- coinholders have no power
- the foundation developers determine all changes to the source code
- miners have theoretical veto power over decisions by the foundation, but in reality cannot exercise veto without losing mining profits. Miner interest may not be aligned with the interests of coinholders.

The veto in corporate governance over the souce code and changes should be in the hands of the coinholders (the stakeholders).

We cannot have Digital Autonomous Corporations until deterministic builds, program determism and process isolation are technically feasible.

Digital Autonomous Corporations: Seperation of Blocks Contents from Block Consensus Mechanisms

Bitcoin combines blockchain consensus and parsing of blocks (transaction). The consensus mechanism in Bitcoin is the block headers along with transaction information. From Skycoin's perspective the contents of the blocks (the transactions) should be logically separate from the mechanism used to determine consensus between blocks. Consensus determining information should wrap and be independent of the block contents.

Skycoin carefully separates out the blockchain format from how consensus is determined. This means
- stakeholder elections may elect to change the blockchain format power and how the blocks are parsed (Which may affect number of coins, types of transactions types supported and other information)
- stakeholder elections may elect to change the consensus mechanism

In Bitcoin, there are multiple competing implementation of both the blockchain parser. There is a chance a block might be valid on one implementation and not valid on another, causing a fork. Multiple concurrent version of the chain parser are in the wild, with different ideas about what constitutes a valid block.

For digital governance the blockchain parser itself is the first target for placing its source code within the blockchain itself and amendments or changes becoming subject to stakeholder elections.

In Skycoin the blockchain parser must be standard and deterministic and agreed upon by all parties, while the current consensus mechanism is currently allowed to be varied on an individual basis in the network consensus system (which may change).

Digital Autonomous Corporations: Functional Unspent Output State

In Skycoin the state of the unspent outputs is U and a block (list of transaction) is applied to that state B(U) to yield a new state.

B(U) -> U

A block is a function from an unspent output state to a new unspent output state. There are conditions that must be true of each transaction in a block and conditions that must be true of the transactions jointly.

- Skycoin uses a functional programming style, which in theory allows blocks validity checks to be independently checked in parrallel.
- Skycoin defines a formal canonical binary serialization of the current unspent output state.
- Skycoin defines a formal canonical binary serialization of each block.
- The source code defines the state of the unspent output state (the state)
- The source code defines the meaning of an application of a block (a function mapping an existing unspent output state to a new unspent output state).
- The source code determines whether a block is valid or not for a given unspent output state.
- The consensus mechanism determines which blocks are applied in which order.
- The consensus mechanism is independent of the block parsing and interpretation mechanism.

This is similar to Bitcoin, but conceptually more advanced in that it was designed to accommodate the direction crytocurrencies will take in the future.

Digital Autonomous Corporations: Mathematical Notes, Object Process Algebra

Bitcoin type systems are specific examples of very specific types of mathematical constructions. There are transactions and transactions take unspent outputs and destroy them, creating new unspent outputs. Access control is by signature, only the person whose the private key can use the object.

Outputs are objects with state, which have methods and the methods describe who can call the methods. A method might say "Only the person with the privatekey can call me".  The state of the object does not exist on the blockchain, the blockchain only records the methods or transactions which act upon the state.

Bitcoin's operator
- destroys a list of outputs
- creates a list of outputs

Each output is destroyed when used. To send $20 if you have $30 in an output, you send $20 and send $10 back to yourself (your output is destroyed by the transaction and two new outputs are created). Bitcoin objects are immutable.

Bitcoin objects are immutable because they are named by the SHA256 of their binary serialization. Modifying the object would change its hash and therefore its "identity" (which is the hash). Therefore you can only destroy, but not modify the object.

There is a more general construction than Bitcoin, which is
- object oriented (objects are named)
- objects are possibly mutable (the state of the object can still be a hash, but the object and its state only uniquely identify the same thing if the object is immutable)
- objects have methods
- the methods have their own source code in the state of the object, which describes what the method does and who can call it
- in Bitcoin methods only come from "outside". objects cannot generate messages which act upon other objects in Bitcoin
- the transactions or methods acting on the object are published in the blockchain
- the state of the object is implicit, but changed by application of methods (transactions)
- there are creation and deletion operators for the objects
- how the object state is changed by applications of methods is described by the object itself (homoiconic representation)

For instance for methods on an object you could have different program preconditions, that determine if a call on that object is valid
- anyone can call this method
- only the person who knows this public key can call the object
- this method requires signatures from these two public keys
- these are just different programs/preconditions that can be described in the object itself (the source code for the method is in the object state)

Chain Visibility:
- In Bitcoin every transaction is public and synchronized between all clients. This does not need to be.
- some chains could only be visible to group of people
- some chains could be visible to everyone but only writable by a single person
- some chains could be private or only internal within a program

The whole Bitcoin is just an instance of one of these systems, with a special singleton that takes in lists of outputs, destroys them and creates new outputs. So Bitcoin is just a singleton object with a method that has a creation/destruction operator on another type of object (which it creates and destroys).  Once you have a public ledger and you have this type of "Object Process Algebra" then Bitcoin is just 30 lines of code. There is no reason you could not have a billion Bitcoins or everyone could not have their own Bitcoin. There are systems that are apparently more general and powerful than Bitcoin, but its not clear what they do or how people will use them.

Etheurem is closing in on this idea, but choosing to do all the computation on a single chain. We have no idea what people will use these systems for, but believe people need personal blockchains.

We were thinking of scripting languages like this, but decided to keep them off the Skycoin blockchain, which should only be for coins and payments. This kind of blockchain is for something else entirely.

Of course we are going to implement this, but its not priority compared to other things. It distracts from more important and urgent development priorities. Its more like a developer toy right now.

Digital Autonomous Corporations: Implementation

The Skycoin Project is drafting a standard for a minimal virtual machine which will allow program determinism, process isolation and deterministic builds for golang and a restricted subset of C.

- a standard for producing a merkle tree hash from a directory of source files
- a abstract syntax tree representation which is to be produced by the compiler
- a minimalist, deterministic assembly language closely matching LLVM intermediate representation
- a compiler for a subset of golang, into the intermediate representation

Golang's compiler is currently written in C. Golang is getting a new compiler written in Golang. The library allows us to parse golang modules into an AST representation. We are then able to convert the golang program AST into the deterministic IR representation.

Steps:
- We compile the golang compiler into the IR using the golang runtime
- We run the Golang to IR compiler on an interpreter for the IR.
- We used the interpreted IR compiler to compile the Golang, Golang to IR compiler to IR

Result:
- The hashes of the IR outputs should match
- We have a deterministic Golang to IR mapping
- We have hash of compiled Golang to IR compiler
- For performance the IR representation can be compiled down to platform specific machine code by LLVM (this may destroy determinism at machine code level, but is ok).
- the IR representation is very close to LLVM input and is equivalent to C if bounds checking and security are disabled

The non-deterministic parts outside of the IR are the system dependent file system, networking and the interpreter (we will call this "the runtime"). However, this part is very small. Since networking and file system access go through the runtime, we are able achieve process isolation.

This is a long term goal, but something that
- we believe this is necessary for the ecosystem
- we believe two or three developers could finish in a few months.
- We will write it out in terms of subprojects
- we will fund it when developers are available.

Eventually a strict subset of C and minimalist subset of C++ could be compiled to the IR representation. This would allow migration of the Bitcoin source, after deprecation of dependencies. Bitcoin's qt-depedency, idiosyncractic wallet storage format and dependence on OpenSSL, mean that a Bitcoin port is unlikely. The C standard does not define integer overflows and other behavior required for Bitcoin to achieve determinism.

However, Dogecoin or new altcoins prepared to make radical changes to the Bitcoin source code would be able to take advantage of deterministic builds and improved security.

> Maybe starting with a website where all the info about Skycoin, Meshnet, etc is available is one place?
> I know most info is on GitHub but I think an easy to read site would be more popular and attract more views and potential interest from knowledgeable
> people/organisations that could help reaching the final goal. 

Yes. The community must take over the coin. That is why launching is important, it will speed up transition. There is too much to do for the developers to do everything.

> Hope with time the Skycoin Dev Team can find an optimal solution to them.
> Also hope that someone out there would cooperate or help in solving them.

We have people who are just working on these problems.

For routing, we will have each node report traffic statistics to central server. Then we will aggregate the statistics and publish them. Then "Route Discovery Servers" will download copies of the data, compute optimal routes. When a client wants a route, it will ask a route server and get a route. So the route discovery service is like a DNS type service.

The route discovery servers can use machine learning, big data, linear algebra, ant colony optimization, electron flow routing, whatever it needs to compute the routes. Different people will create route service implementations and benchmark them. Individual users will choose the route servers they use for their node or they can use a default server.

This is highly centralized, but it gets the ecosystem started and it gets it working very quickly.  Eventually, there will be too many nodes for the server to fit every node in memory and then system will fail and have to be replaced. We would like it to be 100% decentralized and eliminate any reliance on special "service" servers. However, it would be impossible to build the system fully decentralized at launch without pushing schedule back several months.

For mobile ad-hoc networking, we are doing breath first search. Most meshnets will have three or four hops to internet. We do not have to worry about ten hops at the start. You really have the local nodes (maybe setups with 3 directional antennas fanning out over area), then you have the "long haul" point-point directional connections. You could spend six month designing an algorithm for routing over 10 hops in an ad-hoc wifi network, but the performance and latency would be so horrible, why would you do it?

Also, at startup there will be no meshnet nodes. So the network will just be running over IPv4. You can still do things on the darknet and run applications and that is important. There will be applications people want to run on the darknet, even before a physical meshnet is built out. For those users its just "faster TOR".

We cannot solve all the problems end to end. We have to get it working and deal with each issue as they come up.

Implications for Aether

Some of the software we are building is very radical and only tangentially related to the coin. We have no idea what developers will do with the distributed application infrastructure libraries, but feel that it will enable developers to rapidly build applications on the darknet and that these applications will drive adaption. The ideas behind this software (Aether) is so new that it will take a while to understand its importance. Dark Market and half a dozen projects sprung up immediately around the same idea and we are providing it as a library and application platform, instead of building it for a specific application.

We built software for internal use and then that software was refactored into libraries and then our applications built on top of those libraries. So far we have
- standardized cryptographic and hashing primitives and key storage (private key, public key, address generation, signature generation and verification, ECDH encryption)
- standardized communication libraries (ability to connect to nodes over darknet via the node's public key)
- standardized data serialization, messaging and service oriented application framework (soon with machine readable RPC interface)
- standardized distributed document oriented datastore
- standardized functionality for generating client side application frontends using Angular.js from data in the distributed document oriented datastore

Long Term Implications

We already have exchanges such as coinedup which are altcoin only, but are still running on single server. I think we are in good position to have a multi-coin wallet and that it will be very quick for someone to develop a distributed altcoin-to-altcoin exchange on top of the Skycoin service infrastructure.

This means you will be able to have any type of coin in your wallet and be able to instantly convert between coins. So if you have Dogecoin in your wallet and a merchant takes Bitcoin, you will be able to just say "Send 0.5 BTC" and instantly convert at the spot price. People will stop thinking of the coins as being different and it wont matter too much which coins a merchant accepts.

We think a town or community might create their own community currency. An indian nation, small island nationand eventually countries or regions in Africa may adapt their own currencies. Africans are paying 15% to send money over cell phone. M-pesa has displaced the state currency in many regions and is coming under increasing government regulation and increasingly higher exchange fees and altcoins offer an attractive alternative. The only thing holding altcoins back in Africa is the complete lack of usability, security and support for mobile devices. Coins will move away from commodity pump and dumps (although they will still happen) and be more serious.

- starting a currency will be as easy as running a webserver
- there wont be mining, or transaction fees or 51% attack risk
- each coin will have a monetary policy enforced by software (who can create coins? how fast? do they need consent from the other coin holders to create new coins?)
- there will be a standardized multiwallet, a standardized API for thin clients and standard for mobile
- the software will be usable and user friendly
- coins instantly interconvertable at spot price
- the coin will be interoperable with rest of ecosystem from day one

Skycoin is targeting price stability and targeted appreciation. The other coins will fluctuate against each other and Skycoin might act as a reserve asset and deal with ecosystem standardization in this scenario.

Ethereum is positioning itself to take advantages of cryptoequities and displace the Mastercoin niche. Skycoin is aiming for a large consumer market, but if that fails will have a good position as a reserve and position with respect to coin standardization and interoperability for the community currencies.

Altcoin Governance

We are also seeing new models. Some coins are trying to generate income from services and then reinvest that back into growth. That is a more sustainable model than buying into a mined coin like PeerCoin or Dogecoin and then promoting it (essentially a pump and dump model). You have coins that will be run as businesses on an on-going basis.

Then there are issues with corporate governance that future coins must address. The Bitcoin Foundation is a complete failure. Maintaining, marketing and improving a coin requires money and requires an organization but Bitcoin does not have a mechanism for funding or managing such an organization. In a well run coin, the coins go to the people who create the most value for the coin stakeholders. I want to see something like a 1% inflation and proof of stake elections for officers/managers and allocation of funds to individual project teams.

Miners and speculators do not actually create any value for a coin. They do not do anything to increase the intrinsic worth of coins, where as people doing marketing or developers improving the coin or designers improving the usability of the coin increase the value of the coin. The current model, is buying up a mined coin, spending your own money to improve it, market it, pump the price and build momentum and then dumping it (Dogecoin, Ripple, PeerCoin, Litecoin). This is not sustainable and the incentives are not aligned for the long term success of the coin.

We need innovation in corporate governance for altcoins. We need mechanism for funding activities to improve coins and market them. We need protection for stakeholders. We need to get rid of miners. Speculators are fine, as long as they are active in promoting the coin but passive speculators do not add any value. Miners subtract value, in that they are receiving new coins, but are not contributing to the success, improvement or adaption of the coin.

Skycoin's model is not perfect, but is the best we could do with existing software. The perfect form of altcoin governance will require a lot of work to implement and is something we have to keep working at.

The Ripple model is interesting. It can work very well if the developers are not idiots and can be trusted, but it relies upon the developers not destroying the coin over a petty personal dispute or turning the coin into a get rich quick pump and dump. It requires a level of restraint not to take back room deals that undermine confidence and a level playing field.

The ideal coin would have proof-of-stake community elections, so the developers can be replaced. It would have inflation to fund marketing, development projects and pay developers. It would have mathematically enforced developer vesting (coins over time) to prevent developer pump and dumps. It would have community proof-of-stake elections of the foundation and development team, so people could be swapped out for more competent people or removed if they become corrupt.

We are heading in that direction, but requires more software and not something we can put on the roadmap yet.

Development Update:

Crypto Upgrades

We are getting a function for encrypting blocks of data with ECCDH. There will be simple function that takes a public key and encrypts to binary and a simple function that takes the recipients private key for decryption from bytes.

Encryption Format:

struct EncryptedMessage {
   Pubkey Pubkey //ephemeral pubkey Q
   Data []byte   //padded to 4096 bytes, length prefix and 32 bit checksum
}

Their pubkey is P, your ephemeral pubkey is Q.

You generate random 20 byte integer q (your private key). You raise the base point in the curve to power of q to generate your public key Q.

You raise their pubkey P to power of q to get secret S. You publish Q (your pubkey). They raise Q to power of their private key p to generate the same secret S. p*Q = q*P as p*Q = p*(q*b) and q*P = q*(p*b) and p*(q*b) = q*(p*b).

The Data is encrypted asymmetrically with ChaCha20, using key SHA256(S). A new private/public ephemeral key is generated for each and every message.

Address Format Changes

Previously the binary address format was

struct {
 char[20] address; //public key hash
 uint8 version;
 char[4] checksum; //first 4 bytes of sha256 of the
}

The new format is

struct {
 uint8 version
 chat[20]  address
}

Checksum is only in the printed, base58 string of the address and no longer in the blockchain. In the Base58 representation of an address, version comes after address, followed by the checksum. This is to allow vanity addresses with arbitrary prefixes. Version should prefix the binary representation to enable variable length address fields if changes to address generation become necessary in future.

Data Serialization

We are formalizing the struct and serialization format used for the wire protocol. This will be the standard across Skywire applications (including the Skycoin wire protocol).

The wire protocol and services protocol is switching from struct based messages with a handler function, to RPC style function signatures. This will replace the existing Bitcoin/Bitorrent style packet system with an RPC system with a cleaner machine readable interface for distributed application development.

Instead of

struct Message {
 //data
}

func HandleMessage() {
 //called when client receives message of type Message
}

The New API will be

func MessageAPI(in MessageStruct, ret *ResponseStruct {
//read in input, fill out response
}

This function will be registered with RPC interface, exposing it over network to remote hosts. Remote hosts can invoke the method and receive the returned data. The protocol will eventually allow servers to expose methods for labeled objects across the network.

The RPC and binary serialization format are extremely low overhead compared to ProtocolBuffers, Thrift and Golang's Gob. However, they are more restricted and specialized for fixed sized and variable sized binary data. The protocol is specialized for implementation of distributed applications with mostly fixed fixed sized data such as Bitcoin Wire and Bitorrent, but JSON blobs with optional fields can be treated as special case by marshaling and encoding as variable length binary data.

Changes to Daemon

There are major changes to the networking stack occuring.

Currently the application stack is
gnet -> Skywire -> Applications

gnet handles connection pools, packet serialization and the services stack
Skywire is the Daemon which services are registered with and handles service peer lookup
Applications are things like the blockchain wire protocol and distributed applications

The new networking stack has the meshnet/darknet at the lowest level. This handles connectivity and has 3 modes of physical/link layer connectivity
- TCP (darknet, peering over legacy internet)
- Wifi/802.11 (meshnet operation, peering over wifi)
- Ethernet (peering between nodes over ethernet on non-public IP address space)

The new "Skywire" is the meshnet/connection pool module. Gnet has been deprecated. Daemon has been deprecated. Services interface with Skywire directly. Most of the functionality in Daemon has been eliminated and the peer lookup itself will be moved to a library or service.

The Kadmedlia DHT peer lookup is a singleton. It takes a port and should be shared between service instances, instead of creating a new instance for each service and we have to figure out where this goes.

Low Latency Internode Messaging:

Skywire is connection oriented. Streaming video, Bitorrent, SSH, Skype, Video games, website requests and other application streams fit into the existing "route/circuit" model very well (including UDP between two hosts).

Short messages have significant overhead. Such as sending 200 bytes to a node and never contacting node again. The only application that does this is unfortinately DHT lookups.

One solution for low latency internode messaging over a connection oriented protocol, is to have supernodes.
- each node connects to one or more supernodes
- super nodes maintain connections to each other
- messages are routed over the super-node topology without client incuring route setup cost between end-points

We are looking into solutions for problem. Skywire will need some kind of telehash messaging implementation. Several applications require fast connectionless messages for pub/sub notification, connection setup, DHT lookup and other distributed application use cases.

Lessons from Skywire Networking So Far

Some of the networking problems we are facing are completely new.
- It may take several years to achieve optimal solutions (how to do completely decentralized route discovery!?).
- The best solutions will come from the community and academia, not necisarily the core development team (ex. Bitorrent DHT)
- The framework should be flexible enough to allow multiple competing implementations of each component and continious evolution of the application ecosystem
- Put in place a centralized system to get it working quickly, then swap it out with something decentralized as soon as possible
- measure and instrument performance of different solutions, so they can be compared

In particular
- how do you quickly find efficient routes when addresses are non-topological?
- how do you quickly find efficient routes in a fully decentralized manner?
- how do you set up routes between N nodes without incuring the round trip latency between each node in chain?
- how do you deal with nodes with rapidly changing multipath connectivity (mobile-ad hoc routing)

Development Update

IPv6 support is working. We were having trouble before. Many of the residential routers appear as IPv4 but actually have IPv6 public IP addresses and are IPv4 NATs.

Configuring the IPv4 DNS settings on the local host does not override the IPv6 DNS server the router is using during 4to6 translation. We have no idea what is happening.

We are not sure if IPv4 and IPv6 hosts are able to operate on the same DHT network.

Meshnet News

The meshnet design is really a darknet, that allows ethernet and peering over wifi. This has several implications and we are still working out everything this implies
 
There is an IPv6 tunnel. If two nodes are running the software
- the traffic can be routed over the darknet
- this means automatic opportunistic encryption between end points
- the traffic can take multiple paths between the endpoints, meaning increased reliability

We think the darknet can act as a simple corporate VPN replacement
- there is a plugin or service that runs a TUN adapter and authenticates with an organizations VPN
- there is a TUN adapter exposing the IPv6 address
- the VPN service identifies a correspondence between Skywire public keys (darknet addresses) and the private address space addresses
- the address space is private to an organization
- traffic over the VPN is opportunistically encrypted automatically
- the VPN can identify "gateways" that act as bridges between the public IPv6 space and the private internal address space
- non-native applications can run over the network without any software changes

Skywire Multihoming and BGP

We proved that efficient stateless multihoming is impossible. IPv6 is stateless and Skywire routing is stateful.

We accidentally noticed that Skywire can achieve IPv6 multihoming by tunneling IPv6 over Skywire.

We noticed several things
- IPv6 is not actually stateless. IPv6 is only "stateless" with respect the the address space, but the routing the routing tables still have state and are configured by BGP.
- it is not possible for a "stateless" protocol to support multihoming. That is why IPv6 multihoming standards have failed.
- the BGP tables are growing exponentially
- BGP cannot support multihoming
- BGP cannot support non-hierarchical, dense mesh like connectivity

We believe that the new darknet may be able to replace BGP for routing between domains
- it is intrinsically multi-home
- it does not suffer from route flapping
- the routing within an autonomous system is extremely simple. Much simpler than parsing IP addresses. Skywire is actually a link layer protocol
- Gateway routers can choose the full network path for different types of traffic (routing VOIP and high priority traffic over shortest hop)

Within an AS
- a server operating over IPv6 over Skywire can have multiple network adapters but a single public IPv6 address
- Skywire automatically routes over the shortest hop path for the network topology
- There is a simple rule for determining if an IPv6 address is within the route prefix for the AS
- traffic outside of the AS goes through the gateway routers
- each server must support Skywire

The tunnel is:
IPv6/IPv4 (private addresses) -> Skywire -> IPv6 (public address)

In this tunneling application Skywire acts as intermediate layer between the physical network topology and the IP address space.

IPv6 Address Space reverse compatibility  

What we are trying to figure out, is whether the darknet can be reverse compatible with legacy applications at the application layer without modification, or whether the darknet will require application such as Bitorrent to be rewritten into the Skywire address space.

A user running over the IPv6 reverse comparability adapter
- will be able to run applications within the Skywire address space without modification of the application
- only TCP/IP will be supported
- they will only be able to connect to other people in the darknet
- the traffic will be encrypted
- there will be privacy, but not at level of a native application (applications on the same "IP" will share route endpoints)

A native Skywire application
- will have increased privacy (each application connection will have independent route endpoints)
- will have application level control over routes and traffic policies  (low latency, high throughput and so on)

External Traffic off the Skywire Darknet will go through a "gateway" which is similar to a VPS provider. Your IP to public will appear as the gateway server's IP. This is like a TOR exit node. However, for quality of service, a person will probably have to subscribe to an individual gateway service provider.

Public gateways in TOR are unusable because their IPs are banned from most websites because of spamming. The IP addresses are also easier to identify than private gateways and are prime targets for monitoring. Private gateways are more difficult to identify and offer a higher quality of service.

Development Update

Its July. Meshnet was promised in July. Spec is done. Implementation in progress.

We end up writing everything five times and refactoring it before its perfect. Sorry this takes so long.

Summary of Skycoin Consensus Algorithm Research to Date

We solved adversarial byzantine generals for full connected graphs with a
- cryptographicly constructed "public broadcast channel" with fully connected nodes, but solution does not scale to 300,000 nodes.
-> global consensus must result from local consensus in practical system
-> Proved global consensus from local consensus in random graphs using probabilistic Ben-Ors consensus process

We have mathematical proof that 51% attack proof is achievable with a single trusted timestamping server.
- distributed time stamping did not meet conditions for proof
- However, distributed time stamping useful for detecting 51% attack.
- If 51% attack can be detected reliably, it can be eliminated. Practical 51% attack now require compromosing two seperate indepedent systems.

Mathematical Results:
- There is no deterministic adversarial Paxos solution for the blockchain.
- However, probability of attack success can be reduced to being exponentially small in block confirmation depth using "randomization"
- practical, miner-less 51% attack proof consensus is possible, but require trade offs

Threat Reduction Measures
- increase cost of 51% attack (increase resource cost)
- make 51% attack success probabilistic (decrease payout to attacker)
- allow identification of attacking nodes (auditing, identity)
- when detected, attacking nodes automatically lose resources needed for attack (node social trust metric as scarce resource for network consensus)
- bound time frame over which transactions can be reverted.

Current Skycoin Consensus System Design:
- Public Broadcast Channel for consensus negotiation
- BenOrs randomized consensus protocol in web of trust network
- Detect attack states, mitigate attack, identify attacking nodes
- Multiple layered detection systems that must be defeated for a successful attack.

Consensus

The formal state transition diagram for network consensus for netsplit and 51% attack prevention is coming together. We are sure that if 90% of the nodes in a random graph attempt to revert block consensus, they will fail. There are three difficult conditions that must be met in succession for a block consensus reversion attack to succeed.

There were two states for nodes. A new third state for network bifurcation has been added. This third state simplifies the state transition diagram for dealing with attacks and netsplits
- converged with network (this is determined at minimum by the "Consensus Oracle" mechanism)
- Not converged. This is state where the current node block consensus is on a different chain than rest of network and knows it.
- A new "bifurcated network state". This is the state a node goes into when it detects two or more divergent consensus chains on network subgraphs. This is the state the network is left in after a netsplit or consensus reversion attack attempt. This state begins conflict resolution.

There is a window of blocks. Nodes can remain in the converged state during the consensus process for this many blocks in the presence of blockchain forks while remaining in the converged state.
- This is the "consensus window" in which the network has to resolve choices between alternative blockchains.
- Once a block goes outside of window, it is "final" and reversion should be impossible.
- It is acceptable for the network to stop until consensus is achieved if the window would be exceeded by the additional of new blocks. Stopping or slowing down the network during an attack is preferable to introducing a 51% attack. Once attacking nodes have been identified, people can remove them from their trust lists and their influence on the network eliminated.
- The probability of forks decreases exponentially with block depth within the consensus window

Unconverged states happen when consensus process runs on and exceeds the window. This may indicate a pathological subgraph slowing down convergence or a DDoS attack. It may also reflect lose of connectivity between continents slowing down blockchain convergence.

Note: For the purposes of the finite state machine transition diagram, the unconvergence state is discrete. Block introduction is rejected or discouraged while pending consensus decisions are processed. As a practical matter, there may be transaction throttling, with block rate decreasing as a function of the size of the open decision set. This is called the "soft throttle". The "hard throttle" is when nodes begin rejecting block introduction until the current backlog of consensus decisions are globally resolved.

Bifuricated network state occurs when peers announce a chain which forks before the window and which was not previously in the consensus decision set (fork introduction). This only occurs doing a netsplit when nodes rejoin the network or during a directed attack. Most nodes in the bifurcated network state resolve automatically.

There are several detectable error states, that should not occur in normal operation but will occur. Such as local node assumes a consensus state that differs from the state suggested by the consensus oracle.

Handling Bifurication State:

This state should never be reached, except in emergencies and major coordinated attacks. An attacker must have the resources and the will to attempt to put the network into this state. This will never occur on a network of non-malicious unmodified clients running on a reliable internet.

If this network state has been reached
- There is a severe Skycoin bug that needs to be patched
- Skycoin is under attack from a powerful group with significant resources
- World World III has begin. Global internet connectivity has been severed. The colocation centers have been nuked. The undesea cables have been cut and communication satellites no longer function.

This is the state that triggers the 51% attack detection. This is being worked through. This state should not be triggered during normal operation.

- If someone manages to get enough nodes colluding to influence the consensus, they can DDoS attack the network by minting blocks with no transactions in them and preventing network from accepting valid blocks. This wont last for long. As soon as the nodes are identified, people will remove them from trust lists and its effectively a ban.
- Then there are planned measures in place, that make node consensus decision deterministic. This makes it very difficult for a large number of nodes to collude to influence voting, even if they are controlled by a single person. It turns vote manipulation into an intractable and frustrating optimization and coordination problem.
- If someone tries to 51% attack, it fails with high probability, deterring an attack
- If someone 51% attacks and succeeds, it will trigger automatic resolution, which will block most attacks based upon the block timestamps.
- If they get past the automatic resolution procedures, then it would go into manual resolution.

The network is designed to never get to this point, but if it does then there are a number of possible resolution procedures we are looking at. The network will run both branches concurrently until the split is resolved.
- manual resolution (each user setting chain by hand). The honest nodes and exchanges affected by the split, will just revert the fork and their nodes will discard the bad chain. In Bitcoin the pools participating in an attack are likely to be in on the attack and the victims are the exchanges and service operators, making it difficult to revert the chain after an attack. In Skycoin, people are unlikely to use a chain that is not the consensus chain of the large exchanges and Skycoin service providers (who are the victims and targets of the double spending attack). The incentives are therefore slightly better aligned.
- A developer emergency signing key with 2 out of 3 keys required. Instantly resolves deadlock. Should never get to this point.

Transaction Confirmation States and Block Depth:

There is a separate flowchart for transaction confirmation. Transactions will be reported by the client JSON API as
- pending: transaction relayed by network, but not entered into block yet
- confirmed: transaction entered into block in consensus chain with N confirmations.

N confirmations means the block in which the transaction was entered, has N successor blocks up to the first block which has 0 or more than one remaining candidate child blocks pending network consensus. Skycoin can have multiple child blocks and branches pending consensus, the network does not slow down to decide a single block and then the network block. Therefore each transaction has a "depth" with respect to the last block with more than two remaining parents and the transaction has a depth with respect to each of the pending consensus chains.

So for example, if a netsplit occurs at block 10. The netsplit chain is on block 20. A transaction is entered in netsplit chain in block 15. The transaction has five confirmations with respect to the head of the netsplit chain, but has 0 confirmations (pending state) because block 10 has two children (block 10 was last block when the local node was in the "converged" state).
- If the netsplit chain and mainchain merge at block 25, if the netsplit chain becomes dominant and the other chain pruned, then the transaction now has 10 confirmations
- The transaction can never go into the confirmed stated while the node is in unconverged or bifurcated state. This automatically prevents the vast majority of double spending attacks against exchanges and merchants, as most exchanges will not apply a credit to an account until the transaction has reached N confirmations.
- In Bitcoin "Confirmations" are the number of blocks since the block containing the transaction, for the longest block. In Skycoin, confirmations are the number of blocks after the transaction which have

There is a closely related concept, the "confirmation min" and the "confirmation max". If there are two chain branches open for consensus and the transaction has four confirmations on the first chain and six confirmations on the second chain, the transaction will have a minimum of 4 confirmations regardless of which chain is chosen for consensus.

Scenario
- there are two blockchain branches
- The first branch has 15 blocks
- The second branch as 12 blocks
- The branches fork at block 7 (block seven is the last block the two branches have in common)
- A transaction was entered into the first branch at block 11 and the second branch at block 10
Therefore
- the transaction has "0 confirmations" because the transaction was not entered before the chain forks on block 7
- the transaction has 4 confirmations on the first branch
- the transaction has 2 confirmations on the second branch
- regardless of which branch is chosen for consensus, the transaction will be executed (unless one forks is chosen and then another fork occurs at a block the transaction was executed in)

There is a calculus of blockchains. There is a min, a max, a join and a bottom. We need to develop good terminology for talking about the blockchain forks, diagrams and software examples.  Documentation is low priority until its working and the wiki is up. Someone will have to make a tutorial on the wiki, make python scripts for generating diagrams and come up with terminology.

Development Update:

Skywire Meshnet

The design is amazing. Skywire darknet router may be able to replace BGP and existing corporate VPN solutions. Its reverse comparable with IPv6 (IPv6 can be embedded over Skywire). Its very simple.

I dont want to talk much about this. Just have to finish implementation and get source code out there.

Skycoin Application Framework

Extremely exciting.  We have compiler for compiling Golang down to Javascript.

https://github.com/gopherjs/gopherjs

- Aether apps will be in Golang.
- The Golang will be compiled down to Javascript.
- The Javascript app will be stored in key zero in the Aether store.
- The other keys will contain data driving the application
- The app uses the AngularBinding for DOM manipulation
- Some functions will be exposed via API through DOM (DHT lookup, messaging)

This is a major step towards having iOS/Android style Darknet apps running on Skywire darknet.

Skywire Daemon Progress

Almost working. A few changes left. Changes to service introduction packet format, refactoring, removal of 2,000 lines of redundant code and other changes.

Project Management

Some things can be written down and handed by other developers. They are isolated, independent and easy to describe in detail.

Other things are very complicated design problems, where there is not a correct answer. Very difficult to outsource or delegate. These are problems, where if three developers are working on it, they each have own solution and insist it is the best solution. They cant agree at all. If they compromise the design ends up being worse than any of the individual solutions (design by committee).

We are getting through the last of the difficult problems. These design choices relating to how project components are structured, API interface and messaging formats. This is blocking the work the other developers need to do.  We are nearing end of this and can expand development effort soon.

IPO

We do not need the money from the IPO, so internal pressure to launch coin has been low.  However, we should do that immediately.

The blockchain was running in January and we should have kept it running and just made that the blockchain. Remaining changes affecting blockchain should be finalized and then coin will be "launched". However, much work ahead.