Development Update:

Aether is coming along well. Soon development discussion will be moved into Aether. Coin bounties will be assigned for developing communication tools on Aether.

For instance
- user creates private/public key pair
- user publishes stream of tweets (as JSON) into blockchain and signs each block with their private key
- user subscribes to another person's feed
-- user takes hash (address) of person they want to subscribe to
-- user looks up peers replicating the chain via DHT
-- user connects to the peers and downloads the chain (which is replicated P2P)
- web server on local hosts, allows person to see feeds of people they are pulling in

Most of this is two lines of code in Skywire, so the work is creating a service in Golang and then taking the JSON and creating an HTML interface from it. This is a sort of "App" on top of Aether/Skycoin. Aether also implements a key-value store, which is probably more useful than blockchain for these types of apps.

Twitter is easiest to implement. It is not more difficult to implement a twitter clone on top of Aether than it is to implement one with Redis. Twitter is easiest to implement, because in distributed twitter, each user controls their own feed data.

We also want
- a distributed forum
- a distributed reddit
- messaging (email replacement. most difficult)
- a distributed wiki

These will be used for coordinating development and building up the user community.

For a forum, the forum data would be controlled by a single public key. A user submitting something to forum, would message the forum with a signed message, then it would trigger API and forum server would update the forum data.

For a wiki, each key/value stores a page. The wiki data is controlled by a single public key. Users submit messages to the wiki server, the wiki server updates the data for the page. The updates are replicated peer-to-peer between subscribers to the Aether store. One key has AngularJS for generating the HTML website from the data in Aether.

For application distribution we have three options
1. make people pull the service/app from github
2. have key value store and put Javascript in key 0 (using AngularJS), that gives information for how to render the page and APIs. This means an "app" is javascript that generates the HTML locally and can call a limited number of APIs
3. Have a sandboxed, minimal virtual machine which apps are compiled down into. This is the best long-term solution, but we will use AngularJS until we can get this developed and it meets our security/quality standards.

Development Update:

The darknet repo has been removed and moved into Skywire and Whitepaper.

Two thousand lines of coin have been removed from Skywire. It does the same thing, is much cleaner now. The daemon almost works. Will have some development documentation and sample apps soon.

The remaining issues for the meshnet/darknet have been worked out, specifically
- preventing circular routes (denial of service)
- allowing multi-hop routes to be established quickly without incurring round trip latency for each hop
- binary wire protocol format

There is architectural issue, about the relationship between gnet, Skywire and the relay service. It was not clear whether these should be merged into a single library or whether the darknet router should be a service in Skywire or if Skywire should sit on top of the darknet. There are several constraints
- the lowest level router must be something that can be implemented in C and has small ASIC foot print
- there has to be separation between the Golang layer and C layer
- some components such as DHT, operate both on the darknet and over UDP over IP

The darknet router service was originally going to be a service in Skywire, but it will now be an independent implementation with Skywire connectivity being built over the darknet.

The darknet router has to handle several cases
- connectivity between nodes over public IP
- connectivity between nodes over private ethernet segment (nodes connected over IP but not necessarily connected over public internet)
- nodes which are connected and peered over wifi
- nodes which are connected over darknet through routes over the darknet, but where there is not not necessarily direct connectivity

This is complicated by there being different types of connectivity
- a node could be directly connected to another node over TCP/ip
- a node could advertise connectivity from multiple 3rd party nodes (TOR hidden service type operation). For instance, an application creates routes to four nodes and then advertise that you can connect to the application from routes to any of those four nodes. The person connecting only knows the intermediate, advertised nodes.  The advertised nodes only each know the previous hop in route for node connecting to them, but does not know the origin node identity.

This was confusing, until we figured out that there are actually two identities and pubkeys
- one pubkey is for the router. Only one computer is allowed to run with each pubkey. The pubkey identifies a unique router and each router has a particular connection topology to the other routers. The connection topography is public. These represent the physical routing topography of the network.
- one pubkey is for the application or service. An application or service can establish connectivity to a router and advertise connectivity to the service, from that router. To connect to an application, you need to know a router that is advertising the application and you need the application pubkey.

In other words, router addresses are not necessarily the terminal point for routes. This is not intuitive at all, but there are several reasons to separate out the topology for physically routing messages and the 0addresses for communication end-points (addresses that receive messages). In IP we take it for granted that routers and communication end-points are in the same address space, but this assumption complicates the design of the darknet. This also means that communication end-points on the network are intrinsically multi-home.

The majority of distribution will go to developers, people involved in marketing and people buying and operating a mesh network nodes. We will distribute between $100 and $150 dollars per meshnet node deployment. If a user spends $200 to deploy a node and receives $150 in Skycoin, this distribution is unlikely to negatively impact price because of Proof of Burn. Distribution an exchange or airdrop, in contrast is likely to drive down price and should be minimized.

The problem with Maidsafe is that it does not have users and does not have volume. To succeed, Skycoin must have a large and rapidly growing userbase and there must be a reason for people to be buying and using Skycoin.

Coins that no one uses and which have no user base are purely speculative. Many people have made money from speculative investments, but there is no rational basis for the price to increase over time. Dogecoin and Bitcoin should experience appreciation because of increasing adaption and a growing userbase. If the Bitcoin userbase doubles and Bitcoin transaction volumes doubles, we would expect Bitcoin price to approximately double, or at least increase.

It is very difficult to understand why Maidsafe would increase from the IPO, without a growing userbase.

Yes.

Skycoin has a blockchain. The blockchain is in skycoin/src/coin. That parses the blocks and deals with unspent outputs and transactions.

Skywire is the daemon and has a "service architecture". It can run services, such as blockchain syncing service and other things. The meshnet is currently being implemented as a service on top of Skywire (although this may need to change).

The consensus mechanism is outside of the blockchain. Obelisk nodes (probably will be implemented as a Skywire service) have a blockchain. Each node has a public key. The public key identifies the Obelisk node. Each Obelisk node has its own blockchain (there are no coins in this chain). The node creates a new block and signs it with its private key. The Obelisk blockchains are used to negotiate consensus (determining the head block in the Skycoin blockchain). Obelisk uses Ben-Ors for randomized consensus. Each Obelisk node has a list of other nodes it subscribes to. Those nodes influence consensus and voting decisions for the local node. For non-pathological network topologies, the local consensus provably converges in to a global consensus.

Each node votes on the next block in the chain. A node purposes the next block and the nodes vote on the successor. The votes are published in the blocks in the Obelisk blockchain for each node. Your node votes randomly between the alternative and flips its vote every once in a while. Once 40% of your peers (the nodes you are subscribed to) have reached a consensus, you switch to that candidate. The network can vote on multiple forks at once, it does not slow down waiting for a consensus. The forks are pruned to a single chain over time. Splits of two or three block are normal, but after a few confirmations the probability of the block being reverted decreases exponentially to zero. If a transaction has been executed on all candidate  chains, then it essentially executed, even if the particular consensus chain has not been decided yet.

That is binary Ben-Ors and Skycoin will use something slightly more advanced, that is faster when there are multiple successor blocks to choose from in the consensus set. Randomization is important to keep sub-graphs of the network from getting stuck. The voting process is a form of "annealing" where each node will arrive at the global consensus independently, only from its local information.

The consensus process happens in public. A node publishes blocks, signs them with private key and the blocks are replicated peer-to-peer between subscribers of the chain. Then there are "consensus oracles" which are nodes that are used to verify consensus but do not influence consensus. So you might choose the public keys of a few exchanges and a few trusted community members and your node will use those to detect if something is wrong. This is used to detect netsplits. This also protects against an attack, where a hacker controls your router and can control the peers you are able to connect to.

If a node shows up to network and tries to get the network to accept a different chain (51% attack, reverting transactions), it usually gets ignored. Most 51% attacks require node behavior which is automaticly detected and results in subscriber node  removing the node from their trust list. The easiest 51% attack strategy is easy to detect and prove with mathematical certainty that it was intended as an attempt to revert transactions, because it require backdating block consensus decisions. It requires publishing two signed blocks with the same sequence number, so we just made this an automatically bannable offence for a node.

We are trying to eliminate the last possible 51% attack, which is when a subnetwork of nodes goes offline (netsplit attack) and then rejoins the network with a different blockchain consensus and tries to force this on the network to revert transactions. Most of these attacks will fail, because the subnetwork will not have enough influence and will accept the main network consensus.

This attack is still very difficult to pull off. One solution is when there is a successful 51% attack is to freeze the network and let each node/user individually which chain is the valid one and let people ban the attacking nodes by hand. The consensus oracle allow each node with high probability to know if the state is synced and if global consensus has been reached or if they are part of a netsplit subgraph. We think its possible for each node to know with high probability of correctness from local information, whether a node was offline during a consensus decision and then just ignore nodes that were offline who suddenly appear and try to force a chain fork on the network.

In Bitcoin, if you have the most hashing power, you can revert transactions whenever you want.

In Skycoin, to revert transactions
- you much control a large number of nodes
- the nodes you control must be "influential" and trusted within the network topology
- your nodes need to exhibit extremely blatant pathological attack behavior without the behavior being detected, because detection would result in losing the trust relationships you need to attack the network.
- your nodes need to be in a pathological attack topology, without it being detected (most bot nodes will be trusted by few humans and be very obvious)
- you must be able get the nodes you control to collude in a way that results in a successful attack (this is actually not very straightforward)
- if the attack succeeds, you must prevent the network from reverting the attack by hand (very difficult if people lost coins or money because of the attack)

To prove its 51% attack proof, you have to write down the assumptions you are making and then create a simple mathematical model and then prove the conditions under which things can and cannot happen in the model. Once you know the conditions that an attack is possible under, you try to eliminate them and if you cant eliminate them, you make them as difficult as possible. You increase the cost of an attack and you reduce the probability that a specific attack will succeed. Then you reduce the payoff and incentives for the attack.

The consensus process is simple and easy to model, but non-intuitive without seeing it. There will be a javascript site eventually that has an animated consensus process you can play with.

Just an idea at this stage. Found an improvement. Each Obelisk node, has a public key. We hash the public key into an address and then it stores 10 coins in an output owned by that address.

It does not add a cost. It just proves that you own 10 coins. It proves you know the private key, for a public key, whose address has 10 coins in it. You can still spend the coins.

The idea is that it upper bounds the number of nodes. If 10 coins must be held and there are 100 million coins, then it upper bounds the network at 10 million nodes. The upper bound does not appear to be mathematically useful right now, but is something we should keep in mind.

When a new Obelisk node is run, it will "trust" some random peers. The user can also add a few nodes by hand that it trusts (exchanges or trusted community members). A node is identified by its public key hash and found by DHT. Its not like Bitcoin where nodes are IP:port pairs. You can move your computer around and the identity of the node does not depend on its IP address.

We want the network to be secure with random nodes being chosen. We dont want a situation like Ripple, where the three developers nodes control the network. However, we wanted to prevent a situation, where someone runs 200,000 nodes and tries to collect the trust relationships from new users. These Sybil attacks nodes, still cannot 51% attack generally, but anything that increases the cost of the attack is still useful.

Maybe, we restrict it so that new user will only randomly trust nodes that have a coin balance. Trust relationships wont be severed if the node does not have a coin balance, but they just wont get new random users.

The connectivity graph for trust relationships, is supposed to be a fully connected random graph. A few nodes (trusted community members, exchanges, websites, organizations) will have more trust relationships and that helps the convergence time for block consensus a bit. It reduces the network diameter a bit.  Some nodes will be used to verify consensus (you choose a bunch of exchanges or different public keys), these nodes do not affect consensus decisions, but are "consensus oracles" to check if your node has converged with network.

If two large exchanges have different consensus for a particular, block, that is a problem. It could indicate a netsplit or an attack on the network. Exchanges may want to suspend trading until the issue is resolved.

Development Update:

We figured out way of preventing Sybil attack using a hybrid Proof of Stake system.

To create a node, you must prove you have coins. Say 10 coins. You send 10 coins to address A. Then you send the 10 coins from address A to address B. Then you add a signature using the public key in address A to sign a message in your Obelisk blockchain.

Alternatively, you could publish the public key for address A and then just sign a message with that public key. The node would have to publish a signature every time period, or within some number of blocks of the reserve coins being moved, in order to maintain valid trust relationships with other peers.

Alternatively, proof of burn could be required, where the coins are sent from address A to an address B that has no private key. Proof of burn conflicts with the requirement that no one should need to download the whole blockchain from the beginning to operate a full node, so is unlikely.

This system upper bounds the number of Obelisk nodes and restricts the ability to run Obelisk nodes to coin holders.  The upper bound on the number of nodes and coin requirements adds another layer of Sybil attack protection.

Its launching now. Cannot wait a year.

A full time engineering manager is being hired and full time VP of engineering is being hired. The VP of engineering will be responsible for producing reports on project implementation, setting and tracking project implementation milestones. The engineering manager will be responsible for managing contractors, developers, coordinating project implementation schedules and  release schedules.

A Google docs spreadsheet will be created, with things that need to be coded and coin bounties. People who contribute unsolicited improvements, will also receive coins. Some full time and part time developers will be put on salary.

There are six project application teams
- Core coin team (done for now)
- Meshnet team
- Wallet/Application usability team (done for now)
- Applications team
- Marketing
- Security Projects Team (unstaffed, later)

Coin Team:

Coin team is mostly done. The blockchain is done.  There is nothing for cointeam to do, until Obelisk implementation. The Skycoin blockchain parser is about 2,000 lines and have almost no dependencies. It is much simplier than Bitcoin and easier to audit.  It was designed to have nothing in it for security. This part of the code base will be frozen eventually. Only a very small number of people are allowed to make changes to this part of the codebase.

Meshnet Team:

Skycoin developers will get the meshnet working and its being handled over to the community. The meshnet will work on Debian with SOCKS5 and then others can get it working on OSX, Windows, write the TUN adapter (so that all traffic can be tunneled through the meshnet).

There are also hardware project teams that will be working on hardware devices. The existing networking stack will have to be refactored, to support a C implementation and then verilog implementation suitable for FPGA and eventually ASIC implementation.

There is an overlap between the Meshnet team and the applications teams. The GUI/usability teams are responsible for producing interfaces that are easy to use, for managing meshnet deployments and routine tasks. The meshnet team will be responsible for providing good APIs for the usability team and there will be some back and forth on requirements.

Wallet/Application Usability Team

The wallet is pretty good right now. After launch, they will start on an improved wallet design with a coinbase like vertical layout and additional features. This team works in Javascript and does a bit of golang for the JSON API.

Applications Team

Application team will be mostly external contributors and bounties.

This team is responsible for
- personal blockchains
- communication infrastructure for sending messages between addresses
- porting Bittorrent to run on the Skywire darknet
- implemented applications (such as distributed twitter over personal blockchain)
- communication infrastructure for the project

The end goal of the applications team, is to be able to move all Skycoin development and project communication into the darknet.

For instance, one application puts a wiki into a personal blockchain/key vaue store (each page is a value for some key). You view the wiki with a web browser connected to a locally running webserver. You submit changes to wikipages and the changes are communicated to the owner of the wiki (asynchronous API/RPC call, using communication between addresses/Skywire nodes). The server running the wiki, updates a page and signs the update. The updated page is then replicated peer-to-peer by all nodes subscribed to the wiki. Decentralized Message boards, wikis, blogs, Twitter like applications can be built on this technology.

All project communication and coordination should be moved into the darknet as soon as possible. This is extremely important for decentralizing the project and enabling the community to take over development.

High Priority Applications:
- Darknet DHT lookup system
- Messaging Between Addresses (secure, native, Bitmessage like functionality for Skywire Darknet)
- Darknet File System (ability to lookup file by SHA256 hash, find peers and download file)
- Native Decentralized Darknet Communications Infrastructure (message boards, wiki, person to person messaging, mailing lists, twitter, 4chan like applications)

Applications are very important for adaption. There will be several dozen or hundred developers across the different application developer groups. The objective is to decentralize as much as possible, everything that we do online and move it into IPv4 and into the darknet
- Email. Messaging
- Youtube. Streaming Video
- Torrents. File Downloading
- AIM. Messaging
- Skype. Voice Chat
- Twitter. Feeds
- 4chan. Discussion Boards
- BBS/forums. Discussion boards

Most applications are websites. The data for the website is decentralized and stored in Aether as JSON. People subscribe to the datastore by its public key. The owner of the datastore may sign updates to the datastore. Updates are replicated peer to peer between users subscribed to the datastore. A key-value paid in the datastore contains the Javascript/Angular that renders the HTML for the website, from the Aether key-value store data. The application also expose a JSON RPC. A user may communicate back to a server running a service, through the Skywire darknet messaging service. For instance, a user may request data or may submit a change to a wiki page. The webfront end, generates an encrypted message for the application server and the application server receives the message over Skywire Messaging Service. Application servers must document the API calls they accept and the required parameters for the calls. The application interface (the html GUI) is generated on a locally running webserver, from data contained in the application datastore.

Marketing Team:

The marketing team with have a wiki and discussion board. They are responsible for creating marketing messages for specific groups, doing promotion and organizing groups for meshnet deployment.

They will work with PR firm and liason with media. For instance, marketing group may coordinate with local meshnet groups, setup interviews of local meshnet group with media. The media group will organize and provide "Antenna Porn", dramatic pictures of Antenna Deployments for publication, setup interviews with local meshnet groups to get sound bites for news article and otherwise liaison with media.

Security Projects Team

Sometime in future, we will start discussion board and begin soliciting proposals for the design of the application sandbox and Skywire security related projects. Bounties will be assigned to accepted proposals will be staffed with developers.

After the NSA leaks we do not believe that existing operating systems and hardware platforms can be secured. Recent attacks have been able to compromise the Google Chrome sandbox and achieve root privileges through remotely executed Javascript. Long term Skycoin and Skywire application security will require extensive compartmentalization, code minimization and dedicated hardware devices.

The current implementation of the Skywire uses a three layer application sandbox. The bottom layer has a java-script interpreter and Webkit render, which are independent and communicate through the second layer. The second layer is in Golang and accesses resources (networking, disc) through an API on the top layer, which is also Golang. We are unable to rule out  backdoors in Google's javascript compiler, cpu microcode exploits or backdoors in the webkit render and other third party dependencies. In the long term, we want to move applications to a secure, sandboxed state machine executing a minimalist CIL like assembly language.

We are currently examining alternative sandboxes and application state machines  besides Google V8 javascript. The Asm.js is a candidate for the state machine. NaCl was found unsuitable because of its complexity, platform dependent assembly target and inability to protect against microcode exploits. The chosen sandbox state machine, should also be suitable as base language for blockchain scripting.

The security application team will work on projects such as
- make application permissions for resource access transparent and specific
- restricting applications from accessing data outside of their application folder
- restricting applications from network access if not required
- dedicated hardware device for key storage and signing, independent of the CPU
- dedicated hardware device for running Skywire Applications independent of CPU (FPGA?)
- dedicated hardware device for Skywire Networking Stack
- fuzzing of all external libraries used in sandbox stack
- ability to audit for unauthorized data ex-filtration and unauthorized resource access
- ability to detect, record and replay microcode exploit attacks
- platform based deterministic builds (detects compiler backdoors)
- automatic reporting of inputs and program state that result in crashes
- compartmentalization of application dependencies
- minimizing the amount of code (2000 lines, not 250,000 lines)
- minimizing application dependencies
- moving Debian towards good default security (fine grained application resource permissions, deterministic builds, usability for security)

Security is an infinite endless abyss that can consume infinite time and resources. Many of the improvements required will take a very long time and are out of our control. They require hardware manufacturers and Linux distributors and people maintaining dependencies to move in a particular direction. No matter how secure and minimalist the Skywire stack is, it is meaningless if the operating system it is running on has dozens of backdoors.

Some projects such as LibreSSL have started ripping out hundreds of thousands of lines of code from OpenSSL (which it turns out almost no one used). Every line is a potential backdoor. Every unnecessary extension is dangerous, as we learned from HeartBleed.

Similarly, the networking stack in the Linux Kernel could be ripped out put into user space and gutted of protocols not used. The number of kernel system calls could be reduced by a few hundred and system calls for deprecated platforms ripped out. Fine grained application permissions for resource access could be made mandatory, default and easy to modify with a gui instead of being an ad-hod, unusable extension that is only supported for select applications (AppArmor, security enhanced linux).

For instance, "ls" should not be opening TCP/Ip sockets and most applications should not be accessing your Bitcoin wallet. If applications were sandboxed to their directories and had a single application directory, then there is no way a Java app could steal your Bitcoin wallet from the web browser. We accept bad default security, even when it makes no sense.

Achieving good security and usability, will be a bitter war lasting decades. Every sane modification will be opposed tooth and nail "But if you remove that code, I wont be able to run linux on my VAX". Projects like OpenSSL will have to be forked, gutted and then developers shamed to switching over. Even simple things such as getting Empathy to support OTR, took nearly a decade.

Debian contains hundreds of packages. None of the packages can be built deterministicly from source. It is impossible to verify the binaries they distribute from the source code. It is impossible to verify that any of the hundreds of people maintaining packages, have not inserted a backdoor into the binaries they are producing. It is impossible to verify that no one has compromised their build servers and inserted a backdoor that the maintainers do not know about. Applications are not sandboxed, so even the compromise of a single irrelevant component can result in the compromise of the whole system. Merely achieving deterministic builds will require extensive changes to the architecture of linux, that will be rejected by the majority of distributions.

Bitcoin has been barely able to achieve deterministic builds and only if you accept the virtual machine image that is used to build the source (Which itself cannot be produced deterministicly from source for independent verification).

Microsoft and Apple or individual employees at these companies receive direct government orders to backdoor their software. The company being unable to report the existence of such orders. In many countries, these companies are required to hand over private keys for signing updates. The software is backdoored redundantly, at multiple levels, by multiple government agencies that are not necessarily cooperating with each other. Apple, Microsoft and Google products must be assumed to be insecure. Google has the best track record for security, but still has had incidents where wallets could have been looted through Chrome by Javascript by accessing a webpage. The number of exploits in Internet Explorer that resulted in coin theft, is absolutely immense. Hardware devices are the only way to achieve guarantees on those platforms.

Not only is the software stack insecure, but the hardware is back-doored. Many consumer NIC cards can be buffer overflowed and can directly overwrite any part of RAM and compromise a system at the kernel level. Most consumer CPUs contain microcode exploits. Most consumer routers contain backdoors and can be taken over.

We believe open source hardware devices can solve many of the worst problems (Coins being stolen on Windows). We are focused immediately on the issues that can result in coins being stolen that we can control. However, In the long run we an  organization to evaluate and push for improvements in platform security.

Projects Team

We need some kind of funding and project management mechanism.

For example, someone may start project group for open source Skycoin hardware wallet software (porting ECC signing and key storage to 8 bit arduino processors), another group may prototype hardware for the wallet and another group may manufacture and sell production runs of the hardware. Another group may implement the API interface between the software wallet and hardware wallet. Another group may prototype a different form factor for the hardware wallet and do preorders to fund it into production.

Or ability to fund a "Meshnet Map" application that allows visualization of where nodes are and who they can connect to. Or visualization of bandwidth throughput and node locations, for people running large node deployments.

We need to have project pages, describing the Skycoin related projects and giving and overview, maybe a video and then linking back to the project pages (github, discussion boards, trellos...). The number of things going on is increasing and coordination is becoming a bottleneck. Aether should improve this a bit and allow us to get project pages up.

Development Update:

Meshnet is almost done. Some loose edges, then have to finish coin.

Development Update:

The Skycoin meshnet white paper is done, Skywire

https://docs.google.com/document/d/1_rPNMTokwmBPFel1pZfLbTtTkooSWtGKrTLB3RbXIrI

We thought the new developers could learn golang in two days and its taking a bit longer, especially with getting up to date on the code base and what needs to be done and why its structured the way it is. Working on better system for coordinating the work.

Yes. We actually have two layers of proof-of-stake. There is the blockchain consensus, then within the blockchain we have coinhours, which are burned as fees. That is a form of proof-of-stake.  A forked blockchain with transactions reverted will have a lower total coinhour burn.

Quorum Proof of Stake

During development, we came up with several new algorithms.

In one algorithm, coin holders elect a quorum of servers who determine blockchain consensus. The elected pubkeys/nodes vote between blocks in a public process. Then each of them unanimously signs the hash of the consensus block. Once all the quorum members have signed the block, they cant go back and sign another block with the same sequence number (example, block 5000). If the quorum members try to sign an earlier block, that has already been decided, then it results in the quorum being invalidated and a new quorum election.

To vote, a user moves their keys from address A to address B. Then they can sign a voting message with the public key for address A. If a user has 10 coins, they have 10 vote shares. If you require each person to have 10 coins to vote and there are only 100 million coins, then the maximum number of votes is 10 million. At 200 bytes per vote, that is only 200 megabytes of votes. Its tractable.

A corrupt quorum can vote for bad blocks (blocks with no transactions) or selectively deny transactions from particular addresses. However, a bad quorum cannot 51% attack or create a new block the network would accept.

Open issues, with this are whether to have the votes on the blockchain or off-blockchain and whether quorum decisions should be on blockchain.

Skycoin has a "blob replicator" and "public broadcast channel" and the idea, is that once data has been published, its replicated peer-to-peer and cannot be unpublished. So if a quorum publishes signatures for two separate blocks with the same sequence number (tries to 51% attack), then everyone will replicate that data. The existence of the signatures cannot be hidden and it must force a new quorum election.

Hybrid Systems

Consensus in a Quorum is much faster (only ~15 nodes have to agree) than consensus for 200,000 nodes. So we might use the web-of-trust to elect the quorum and then have them do blockchain consensus.

We could require that a vote requires holding Skycoin. You have 10 coins in address A. You send the coins to a new address B. Now the public key for A can sign a vote slip and gets 10 votes. This proves you have coins and are a Skycoin holder and are not a bot.

You can combine, web-of-trust with the proof of stake/voting mechanism. You could require that changes to the Skycoin source code (for the blockchain module) require a majority of coin holders to vote to ratify the changes. You hash the files in some way and get a root hash and people vote on the hash. Then if someone gives you source files, you can hash them and get a hash and compare it to what it should be.

End Game

We think we can go beyond proof-of-stake. We believe it is possible to be 51% attack proof, even if the attacker controls the majority of the coins and the majority of hashing power. We want an absolute, mathematical guarantee and that is what we are working towards.

IPO:

Development is taking forever. Too much going on that is delaying actual work.

What we will probably do, is have a pre-IPO "order commitment". Users will Bitcoin account histories and/or Github accounts and project contributors will be allowed to commit to IPO, up to percentage of the IPO. Participation will be capped at 5 BTC and the cap will go down as the pool gets depleted.

Then the people who have been following project for a while, will get a guaranteed commitment to IPO, without worrying about timing. Then rest of IPO pool will be released after launch.

After the IPO, the rest of the coins will be allocated as salary and bounty for contributors who are working on projects which increase the value of Skycoin. Most of the coins will probably be allocated for the mesh deployment as incentives.

Economic Policy:

We have been talking to a large Bitcoin market marker about how we can prevent a repeat of the Auroacoin crash and deter speculators.

We have a data guy doing models.

This is the linear scale Bitcoin price over time



This is log scale Bitcoin price, with regression line. When Bitcoin is over the line its over priced, when its below the line its underpriced.



This is the total number of subscribers in /r/bitcoin



This is the daily growth rate of subscribers in /r/bitcoin . Notice the massive spikes of new users rushing into Bitcoin



This is subscribers on /r/bitcoin against daily rate of return of Bitcoin. Rapid increases in new users, cause price volatility, run ups and crashes.



This is subscriber growth rate in /r/bitcoin against log Bitcoin price. This is log plot, so a small price swing can be $290 to $90 or $7 to $150.

A price swing from 5 to 4 on this graph is ~3x change in price from $150 to $50 (~3x). A swing from 6 to 4 is a ~9x change in price.



What these graphs show, is that news attention to Bitcoin drives a massive influx of new users all at once. The price goes up dramaticly as new users buy into Bitcoin and crashes once the capital inflows return to the long term trend. With Bitcoin, there is a fixed supply of coins in the short term and influx of capital inflows, driving up price in short term. The price collapses back to former levels after the capital inflows end.

There is a short term increase from new capital inflows and a rebound or crash when the short term capital flows end, but a long term increase from increased adaption and user growth. By looking at the Bitstamp order book, we can separate out these two components using the net capital inflows into and out of Bitcoin.

The coin supply is fixed and new coins entering market will decline over time. The rate of new coins going onto the market will be less than the user-base growth, as a policy. Therefore we expect appreciation in value, until user base growth stops. Then the coin will be in "equilibrium" and be driven by other macro factors.

Policy Implications:

- the rate that Skycoins are released on to the market should be constant and predictable
- the number of coins on the market should not increase faster than user base growth
- the rate that coins are released on to the market should taper and decrease over time
- if a shock (news event, massive influx of new users) occurs that drives up price, more coins should be released onto market for the duration of the shock, to smooth out volatility
- if a price decrease occurs, the rate of coins going onto the market should be decreased
- if a major price decrease out of line with long term fundamentals occur, a pool of coins should be reserved to begin buying back coins and stabilize exchange rates
- tracking and publishing data better enables market makers to calculate the "fundamental value" and may reduce price volatility
- increased price stability increases the demand for Skycoin. Currency traders, merchants and speculators prefer to hold reserves in the coin with the lowest foreign exchange risk.

Development Update:

We need to close out work on the coin so we can get onto the meshnet. We are trying to do too much
- Coin
- Aether
- Meshnet
- Obelisk

Any one of these projects is an immense burden that requires a full development team.

The coin is done and we are just doing refactoring and cleanup of minor issues, but it is still requiring a lot of time. Aether and Meshnet are on track for completion. Obelisk is not scheduled. Development of Obelisk requires Aether and will be delayed until we get more development resources or until the meshnet is working and new people take over development.
 
We have people working on a applications for Aether. For instance, a user creates a key-value store. Each value is JSON data for a tweet. The first key is Angular code for rendering the feed and creating webpages from the JSON feed. A user subscribes to other feeds and pull them in. So we will have something like a distributed Facebook feed or Twitter feed where each user controls their own data.

The meshnet is designed. The implementation is pretty easy, but it wont be practical or useful until you can tunnel traffic through it and do file syncing and things like torrents. It needs to support clearnet nodes as well as physical mesh nodes, because most users will not be able to physically peer over wifi or ethernet with another Skywire node until network density is high enough. It has to be useful as a clearnet overlay for bootstrap as well as supporting wireless peering.

Once the meshnet is operating, we have developers who can come in and deal with the remaining issues and long term support and infrastructure build out. We have to get it working at a basic level.

Skywire and Skycoin repos are being merged. $GOPATH is very annoying and pulling in three repos to get it working is very frustrating. One repo makes development setup easier, but means each of the teams will be working on different git branches. Skywire is undergoing massive changes and reverse compatibility with older versions of networking will be broken constantly.

We might have to add functionality to WGET a text file from a website or some mechanism to notify clients about required updates. Ideally we should have functional tests and regression testing to ensure that minor updates are not breaking compatibility with older versions, but this is not in place yet. A number of issues with release schedule and deployment are coming up.

Aether:

Having a message board and wiki running on Aether, for coordinating development would be good. That would help the community coordinate and make development less dependent on the central developers (who are currently overburdened).

We are finishing up Aether and have a full developer working on applications. Getting code tutorials out for third party developers is an extremely high priority.

Altcoin Hell:

Massive amount of refactoring. Exhausting. Spent a full week helping new developers get repo setup and explaining stuff. $GOPATH issues from hell. Documentation. Going back and forth with big bitcoin investors and they are submitting changes to white paper and have to review and its back and forth, back and forth, endless revisions. Impossible to code and do eighty whitepaper revisions. Have to move everything to wiki, so community can help with editing.

Have to merge the Skycoin/Skywire repos and move all the crypto stuff out into its own module. Deprecating Visor. All the unit tests are broken and cant fix them, because the new refactor will break all the unit tests again. Arguments about functional tests vs 100% coverage tests.

Developers asking for Aether RPC and have to finish Aether and push it. The meshnet dev cant start until services architecture is ready and one of coin devs wont touch anything until the two monthly long massive refactor is pushed because it breaks all his code. Golang wifi controller library is done and meshnet design is done, but its not written down anywhere and the meshnet implementer needs doc so he can sit down and pound out implementation.

The faster we get some kind of communication channel and discussion board and wiki up, the more work can be distributed.

https://trello.com/b/LQd8Gz47/skycoin-development

Large refactoring going on. The block replication and transaction relay server is currently in the Skycoin repo. It is being replaced by the Skywire wire protocol.

Then the command line options are being simplified and visor is being refactored. The cryptography and address generation needs to be moved out as its own package. This means you will have to pull three repos into the gopath, the crypto library, skywire and skycoin. Skywire has block replication, transaction relay service, aether and will probably contain the meshnet as a service.

Skywire does not import Skycoin and uses callback functions when needed. Obelisk may be in Skycoin, but will be a Skywire service. We have to see how it works out. It might make sense to merge everything into a single repo.

Update:

Skycoin Trello is setup. This is for tracking urgent development goals and should help coordinate development.

Trello: https://trello.com/b/LQd8Gz47/skycoin-development

Project Update:

1. We are getting a Trello for organizing developers.
2. We are moving white papers to a wiki. Its better if the community can organize and modify them. Each wiki page can be more focused on a single topic than the white papers.
- overviews for general public
- tutorials for software developers, with code samples
- marketing documentation
- engineering documentation that describes systems at level required for implementation
3. We will launch code in a personal blockchain so it can trade while Obelisk is under development
4. The public DOES NOT CARE about the technology.  Only developers understand the implications of what we are doing. The public only cares about the coin for ideological reasons (the meshnet) and what it does for them. Public adaption will require a working meshnet and good marketing explaining it.
5. The public does not know how Bitcoin works and they probably dont care. "Its digital money". Anything that is like Bitcoin but is not Bitcoin, is "Bitcoin 2.0" to the public. 99% of the users will not become educated about the differences between the coins. We need to have very simple marketing messages.  In contrast, the document outlying the differences between Skycoin and Bitcoin is currently 40 pages long and deal with transaction malleability, signature malleability, duplicate coinbase outputs, hash collisions and the treatment of unspent outputs. We have no realistic hope of educating the public about these differences.
6. We need to build communication infrastructure for the developers to communicate.
- message board for discussion
- wiki for documentation
- wiki for organizing marketing materials to public
- code tutorials
- issue tracker/Trello for tracking immediate project objectives
- IRC for discussion and technical support
7. The foundation of any coin is the community and we need to focus on tools for building out the community. Communication tools are very important for the community development.
8. We want someone to write a wiki in  golang on top of Aether. With each page as a value in a key value store.
9. We need a Skywire Daemon service that takes an address, finds the node and sends it a message. Just has to work and will improve or swap out implementation later. This will be for submitting update requests to the wiki at first.

For a person blockchain, you generate a public key. To be valid you have to sign each block with your private key.

The details of the replication protocol are in the first two pages of the Aether whitepaper. Personal blockchains are replicated peer-to-peer, so as long as someone has subscribers, you can always get a copy of their blocks, even if they are offline.

https://github.com/skycoin/whitepapers/raw/master/whitepaper_05_Aether.pdf

There are no coins on the personal blockchains and a personal blockchain cannot trigger a transaction. So if you enter into a contract on a personal blockchain its just an agreement, you still have to execute or perform under the contract. However, if you dont perform, then its public. Or if only the contract hash was published, no one knows what the contract is, but you can publish the contract if they dont perform and everyone can see that.

The Bitcoin wire protocol only has one blockchain. The Skycoin wire protocol has to support multiple blockchains. There is the main chain that has the coin transactions for Skycoin. Then there are a number of personal blockchains you are subscribed to. The way we handle this, is that there is a Skycoin Daemon in Skywire. You create a "service" and associate it with the daemon. A particular service instance might, replicate a blockchain for a given public key. You create the service, configure it and then associate it with the Daemon. This allows multiple blockchains to be synced using a single program instance.

The Skywire daemon node has its own public key. The public key hashes to an address that identifies the node. If you know the address, you will be able to find the node, connect to it and send it messages. So there will be a bitmessage sort of functionality built in.  There will be a very simple API where you say SEND(Addr, "Hello, wuts up") and it handles finding the node and sending the message.

Inter-node messaging is very useful, because if nodes can communicate, they can generate new receiving addresses for each transaction. Merchants can send invoices and receipts and applications can communicate securely.

So basicly, Skycoin has transaction addresses where you can send coins and it has communication addresses, where you can send messages to.

This is all aimed at developers. The users wont see it until someone builds a chat or email application on top of it. Many of the initial Skycoin bounties will be for designing and developing these applications on top of the infrastructure.

Some of the things we are laying the foundations for are third gen. A working, usable coin, with a clean code base and good security, no mining, no 51% attack and a reason to use the coin is just second gen.

Digital contracts, communication and identity infrastructure lay the foundation for the third gen. We do not know what the third gen will look like, but believe that it will involve platforms and 3rd party applications.

A first gen coin is extremely easy to fork. You just change the hash function or the name and logo and then release it. The first generation was about marketing. Bitcoin and then Dogecoin were the most successful coins in the first gen. Bitcoin has a strong community, the strongest merchant adaption and ecosystem. Dogecoin has the best community, the best marketing and wide adaption among younger users.

Between the second and third gen, we are seeing features like messaging for communication between addresses and other extensions. You cant fork the coin because your fork is no longer compatible with the ecosystem of the original.

At the same time, between the second and third generation the new platforms increase interoperability between first generation coins. Any two coins become automatically convertible between each other at the spot price. You dont care if they accept Bitcoin or which basket of currencies they accept, because it is the same for the end user. They just go to their wallet and hit "pay" and select the currency to pay in and which wallet they want to pay out of.

The third gen will have more community currencies or companies issuing their own currencies as gift cards ("small tent" special purpose currencies). In the second generation, we are seeing wallstreet exchanges and banks integrating Bitcoin as a commodity, like Gold. They are trading Bitcoin as a commodity, but have not adapted to run their infrastructure on Bitcoin type systems.

In the third generation, we might see new banks and exchanges which build their whole transaction infrastructure from cryptographic primitives, receipts and contracts. A user of an offshore bank has a receipt and counter-receipts from each transaction and the counterparties. The bank cannot steal his money or change his balance. The bank cannot authorize or forge a receipt for sending money to a third party without the users cryptographic signature. All banks expose a common API.

The things in the account no longer have to be currency pairs but can be other assets. All fiat is the same. You do not have separate systems and separate database table for different types of fiat. The system handles all fiat transactions in a consistent way.

In the third generation, anyone can issue bonds and options. Previously, there was counterparty risk for options. Only large financial players could issue options on equities. A large company is less likely to default from a bad options position. In the third generation, anyone can issue options. Options are digital contracts and the performance of the option contract is guaranteed by assets in third party escrow.  Crypto-assets become accounting mechanisms for legacy assets.

Many coins such as Mastercoin, Ethereum and colored coins are trying to jump to gen three. However, we believe that gen three will emerge organically on top of infrastructure developed for gen two coins.

Bitcoin has extremely poor extensibility for standards, so you have three wallets and three different wallet implementations and no interoperability, no interoperability between exchange APIs and no roadmap which allows third party developers to drive protocol evolution. Personal blockchains in Skycoin are designed be generic and allow users to individually upgrade their nodes to support new scripting languages, types of contracts and put control of the protocol in the hands of users and third party devs. The wire protocol is extensible and allows association of new applications with the Skycoin daemon.

We had to invent personal blockchains, so that individual users and developers could experiment and extend the protocol without threatening the mainchain. Colorcoin and other coins embedded on the blockchain will never be able to achieve the functionality required for practical use, because the Bitcoin developers have been forced to disable op codes for security,  there is no mechanism in the blockchain for pulling in the required data for a practical system of financial contracts and any experimentation with new protocols requires a blockchain fork.

If the evolution of the ecosystem stops at where Bitcoin is today, the full potential of crypto currencies will never be realized.

Ether permutes space. Then we found out ether is alcohol that people snuff to get high and aether is the mystical substance that permutes space.

Its called Aether because the data does not exist on a server. It exists collectively throughout the internet (or atleast the subscribers). Once published, it cannot be destroyed. There is no central point, there is no server that can be seized. The publisher cannot be located or tracked because once the data is published, they are just a peer.

Its a perfect system. There is one type of Skycoin address and its is an endpoint for a datastore or a pubsub system. There is another type of Skycoin address and it holds coins. There is another type of Skycoin address and it is a node you can communicate with and send messages to.

You generate a pubkey hashes to an address and that is an ID. The address replaces IP addresses for identifying a device or computer if its used for communication. It names a datastore (just like a magnetic link is a hash of a torrent file and name the torrent) if its used for a datastore. If the datastore contains a filelist and a hash list for chunks in the files, then its just a torrent that people can update. If it names a Skywire node if its used for communication, like an IP address names a computer.

So if you wanted a create a distributed twitter with Aether, you create a pubkey. You publish updates to your key value store and sign them with your private key. Each key in the keyvalue store is a number incremented each tweet and the body is json for the tweet.

You give someone your pubkey hash (an address) and now they can download and replicate your feed. They can pull in the feeds of everyone they are following. They can run their own filtering algorithms locally for ranking things in the feeds they are subscribed to and choose their gui. Its a website, but its a website running on your computer  and its running from data you have a copy of.

You are not downloading the feeds you subscribed to from a server, you are downloading them from other people who are subscribed to them. Its completely decentralized. Its pubsub, its a communication channel, its a key-value store, its an RSS feed, its a document oriented database (if you are storing JSON), its an updatable torrent if you are storing file lists and chunk lists.

This innovation, this data structure is as powerful as the blockchain. Its as powerful as DHT. It is a core component for the next generation of decentralized systems.

Aether is a mystical element that permutes all of space and I think its appropriate.

In Tor, you can identify the path to a service through traffic analysis by looking at variation in latency for traffic and correlating them to latency of other traffic passing through the nodes. Requesting pages is slow because you have to go through multiple hops. Here the replication is peer to peer. There is no "center", there is no "server". The webpages are instant, because you are not requesting the data but have a full copy of the data locally. You are generating the webpage from the database.

In the internet of things, you have an LED lightbulb. You want to set the lightbulb to red. The lightbulb has an IP address and its connected wirelessly to your house. You move the light bulb and it has a new IP address, so you cant find it or send it messages. IP addresses are not "ids" for devices, they change as the object moves and accesses the network over different endpoints. Skycoin gives devices or applications "names" that are network independent. This is the function of DNS, to take a name and resolve a server or IP.

The lightbulb has a Skycoin address and you can send messages to the address. You can say "turn red" or upload a new program to the programmable LED lightbulb. Skywire automatically figures out how to find a route to the device.

Additionally, when you running a Skywire Mesh node, the node may be connected to four wireless networks and a router. The wifi node has five different IP addresses. An IP address no longer uniquely identifies the node. An IP address is merely a path to the node. The IP addresses on the router are often not even public addresses because of NAT.

The set of computers you control, your desktop, your tablet, your two laptops. They form a personal cloud. Each device has a Skywire daemon and a node address it can receive communication to. You have application servers running on your cloud. For instance you may have several storage application servers (which expose a volume of a drive as a network file system, like Dropbox). You might have application servers such as web servers or email servers.

So the idea of the mythological "Aether" reflects the vision with what we are trying to accomplish.

Update:

The Skywire Aether Whitepaper draft is done:
https://github.com/skycoin/whitepapers/raw/master/whitepaper_05_Aether.pdf

This is one of the core libraries in Skywire and what implements personal blockchains for Obelisk nodes.

Development Update:

White Paper #4 is out! Half finished, but still pretty good.

https://github.com/skycoin/whitepapers/raw/master/whitepaper_04_survey_of_systems_for_distributed_consensus.pdf