2500 Skycoin per Bitcoin. Which is about $0.10 / Skycoin. Bitcoin to USD is too volatile so just set it to that.

I am going through the bitmessage requests by hand.

I think we started getting bitmessage requests for IPO in about two months ago and are just sending out coins now. However, there have been a lot of changes and fixes since then, so steady progress. We have to fix two more API calls and then can have Skycoin exchange traded.

For IPO. I am trying to do 2 to 24 hour max turn around time. between receiving bitcoin and sending out coins. I wrote a digital cryptographically signed receipt system, but am not using it. I am realizing that money is just monkeys trading sea shells and shiny pieces of metal they found on the ground. I probably should not be using elliptic curves for this.

There are about fifty people in the IPO so far. The average amount is $2000. About half the coins in the allotment are already accounted for. Very good so far.

New Bugs:

- If you try to send and the send fails because of insufficient coins, it did not give a popup and only printed error in terminal. That is fixed now.
- There was a bug discovered yesterday, where you can do multiple transactions from the same inputs (only one of the transactions will succeed). So if you do two sends form same wallet and transaction propagation is not successful, then some of the transactions wont go through. Fixing this now.
- transaction sync on connect may not be working. It works sometimes, but I think problem was somewhere else. I think network was experiencing a netsplit. Connecting to random nodes does not guarantee a robust network topology. We need to allow user to create persistent list of nodes you should always try to connect to. To ensure the core-nodes are fully connected.
- Two people reported disappearing and reappearing coins. there may be a bug in coin balance calculation. The coins never moved, but it is just bug in GUI, looking into this.

Network Status:

We will be out of things to code soon and then it will just be debugging and polish.

There are cyber warfare drills and border gateway protocol redirect attacks in middle east that are deteriorating VPN service and dropping people from IRC in Europe. I think we were seeing internet kill switch tests yesterday. We were seeing protocol specific deterioration of VPS traffic between hosts, only for traffic passing between particular countries and only for VPN but not for HTTPS or SSH traffic. Skycoin block and transaction peer-to-peer propagation seem to be holding up and were only intermediately affected for a few hours, even through the vpn was out.

We still have a lot to do in order to harden the network.

Once Skywire is working, we might want to put in some networking instrumentation for transaction/block/consensus propagation and node connectivity and then have nodes publish/aggregate that. Quantitative data on block propagation and network state could be helpful. Then we can verify Sybil attacks, diagnose outages, detect net-splits and identify disruptive nodes, instead of just guessing.

One of our site installations was using a consumer wifi router. The router was hacked and the DNS on the router was changed, so that it inserts popup ads into webpages. It could also hijack your computer if you downloaded an exe or and pdf, or potentially steal Bitcoin or other nasty things. We recommend routers with open source firmware like openwrt. Ubiquity hardware tends to be very and the security is much better than Linksys or other consumer routers.

It is worth $80 to get a router and networking equipment, that is not going to get hijacked and get your stuff stolen. If a website has 3rd party http tracking stuff in it and the router dns hijacks the page, I think they can keylog whatever you type through javascript even if the webpage is https.

Diagnostics:

This is the crypto-logic level data. This is canonical and is more reliable than the gui.

http://skycoin-chompyz.c9.io/blockchain/blocks?start=0&end=500
http://skycoin-chompyz.c9.io/outputs
http://skycoin-chompyz.c9.io/blockchain

This is
- the blockchain (the ledger of transactions and blocks)
- the unspent output set (the current account balances)
- the state of the client (the head block the client has)

If you are running a local skycoin client you can access these locally using

http://127.0.0.1:6420/blockchain/blocks?start=0&end=500
http://127.0.0.1:6420/outputs
http://127.0.0.1:6420/blockchain

This is very clean. This is what I think a second gen interface should look like.

The second generation is just cleaning up Bitcoin and making it usable. The third generation is where we begin to go beyond Bitcoin.

Update:

Fixed a lot of bugs.

The top levels, the gui and json are not as polished as lower levels (blockchain/crypto). I have not even looked at some of this code and discovering new things. There were things implemented, I didnt know we had working and things that needed to be cleaned up.

- there was a coinhour calculate bug that prevented transactions in strange cases. I hardcoded coinhour fee for transactions to 1, to get it working, but then after receiving coins, some people were unable to send them out.
- there was bug where sometimes send failed if balance for wallet was split among multiple inputs. Should be fixed now.
- I am removing code, simplifying the top level. We are at point for several months, where most of work is removing code, simplifying.
- Most users are behind firewall, they can connect out but not in. Two servers are running with open ports. We need more servers with open ports, running the client
- we need indicator for how many clients you are connected to, what block number is and time since last new block
- we need button for connecting to server by hand
- we need better configuration for how many outgoing connections to maintain, how many incoming connections and a list of server that you should always be connected to. Once Skywire is working, you will be able to just put in address/pubkey hash and then have authenticated communication to end point and that will speed up network a lot. Right now, it is possible to flood network with dead nodes or bad nodes and prevent honest nodes from connecting.
- we need json function for returning the pending unconfirmed transactions. This is six or twelve lines of code and almost done. (see below)
- we need the pending transactions for your wallet (incoming and outgoing) to show in the interface
- we need the unspent output set at http://127.0.0.1:6420/outputs to be sorted, either by time, block # or output id. We store a metadata uint64, that indexes each output, so you can say "output 15" created by "transaction 3" and each output and transactions will have a unique sequentially numbered int, for a given chain. However this value is not in the hash and may change if the transactions are migrated to another ledger, but the transactions/output hash will be same.
- If there are N-transactions from same wallet, we need to freeze later transactions (return error) or queue up transactions. The outputs from the wallet will be spend, so if the first transaction clears the second will be invalid (it needs to use outputs of the wallets after transaction 1 clears, not outputs that existed at time transaction was created).
- Base58 encodes addresses as integers. Some private keys generate addresses that decode to less than length of what addresses should be. I tested 128,000 random addresses during testing and decoding never failed for any of them. If someone has a private key, where people are unable to send to that address, because it is invalid please go into http://127.0.0.1:6420/wallets and send me the wallet seed to BM-2cXFat4fHmeRe8EFJjY3Dzo6RoifcgiKgp . No one will have coins in this address, because send fails because address is invalid, but it seems to happen to a few person. I cannot tell if people are copy/pasting addresses incorrectly or if its a base58 issue
- When a new block is minted, if you are connected to three people, you will request block as soon as you get notification. So you will end up making 3 download requests and getting block three times. This speeds up block propagation, so may not be a bug.
- Skycoin still kills someone's wifi for unknown reasons (one user has reported). This may be DHT (which is same as bitorrent uses). The issue is probably the router firmware.  
- PEX may need to be modified, so that it only keeps list of clients that allow incoming connections. If you cannot connect to the peer, knowing about them does not help the client.

People have reported that port 6000 is X11. Skycoin to prevent blocking by ISPs is not bound to particular port. DHT assumes port 6000. So disable DHT and then make sure you have people in your peer list, or manually connect to server. Once you are finding peers through PEX, you dont need DHT and port does not matter.

Other:

There are API commands I did not know about, that I just found in the code. Someone should document the API/json urls

You can test these on http://skycoin-chompyz.c9.io/blockchain/block?seq=5

Get blockchain head, header
- http://127.0.0.1:6420/blockchain
Get block as JSON
- http://127.0.0.1:6420/blockchain/block?seq=5
Get range of blocks as JSON
- http://127.0.0.1:6420/blockchain/blocks?start=2&end=30

Unspent Outputs:
http://127.0.0.1:6420/outputs

Get Network Connections:
http://127.0.0.1:6420/network/connections (renamed from /api/network/connections )

Make a network connection to peer:
http://127.0.0.1:6420/network/connection?addr=127.0.0.1:6000 (renamed from /api/network/connections )

Blockchain Progress:
http://127.0.0.1:6420/blockchain/progress

This is the highest block you know about. If you are not connected to anyone it will be zero, I think. There appears to be off by one error.

Documentation:

https://github.com/skycoin/skycoin/blob/master/src/gui/wallet.go

In /src/gui/wallet.go there is a URL handler that returns the JSON serialization of the unspent output set. Let us look at how that is implemented.

We define a function, that handles the URL request. Grabs the outputs from Visor and then returns the JSON or 404 error.

// Returns the outputs for a wallet
func getOutputsHandler(gateway *daemon.Gateway) http.HandlerFunc {
   return func(w http.ResponseWriter, r *http.Request) {
      ret := gateway.Visor.GetUnspentOutputReadables(gateway.V)
      SendOr404(w, ret)
   }
}

Then we add the handler to
func RegisterWalletHandlers(mux *http.ServeMux, gateway *daemon.Gateway) {}...

//get set of unspent outputs
mux.HandleFunc("/outputs", getOutputsHandler(gateway))

So it is about 7 lines of code, to expose the outputs as JSON. The "readable" for converting internal Skycoin objects to json is in /src/visor/readable.go https://github.com/skycoin/skycoin/blob/master/src/visor/readable.go

Looking at the godoc for Visor, we can see the functions it exposes

https://godoc.org/github.com/skycoin/skycoin/src/visor#Visor

Visor is one of the dirty libraries that need to be refactored and cleaned up. However it is very clean already. Some cleanup steps could be
- moving blocks into a blockstore library that visor pulls in and removing block serialization/saving to disc from visor
- removing the remaining functions in "spend.go" and moving into wallet handler
- fixing the unit tests
- exposing the full blockchain client API over network with Golang/RPC (partially implemented?)
- moving the readable to its own library or subfolder
- deleting json_rpc.go (which is empty)
- decide if the JSON api web server should be in visor, instead of gui or if it should be its own library or should stay where it is
- move the functionality out of /src/daemon into /src/visor and deprecate the existing daemon for the skywire daemon, making visor top level instead of daemon being top level

There is no transaction history. You can look at the blocks and the transactions using json API. You can check balances by looking for your address in the unspent output set ( http://skycoin-chompyz.c9.io/outputs ).

The coin history and Skycoin blockchain exporer, should
- go through block by block, creating index of addresses, transactions, blocks
- be its own library
- should run in the skycoin web wallet, locally, not on third party site
- should have a JSON api

IPO misc

You can now do Skycoin transactions. Some people are having trouble getting peer connections however. The network will be spotty while we clean things up. We recomend updating the client to latest version every two days.

Some test coins have been sent out.
- You have to find someone who has them
- If you put in request on bitmessage, check your wallet and you may have test coins. These are still being sent out.

Some people are having trouble connecting/syncing blockchain. Most users running client cannot receive incoming connections, so connecting to first peer on network is difficult. We need more people to run skycoin client on vps server, that has open port.

It should be possible to blocksync over HTTPS also. We should be added for reliability and for countries with protocol level censorship.

The blockchain and coin balances are being backed up daily, in multiple locations. This ensures coin ownership is maintained if there is an unforseen emergency or attack situation. If a coin has been in a output for over 24 hours, we can ensure with 100% certainty, that ownership stakes will be rolled over regardless of future events. The current chain of transactions/balance is being preserved, even if they are migrated to a new ledger in future upgrades.

Warning: the send function is a bit buggy. If you send, make sure that the balance in wallet has changed before doing another send. Sometimes the transaction does not proprogate. This is because the client is not connected to any peers or because half the nodes on network are using an older version of the client with a bug. Working on this. Adding pending transaction queue and intergrating it into the gui and other measures to make transaction injection fail safe.

IPO:

Processing the IPO receipts over bitmessage has started.

Your can check transactions here
http://skycoin-chompyz.c9.io/blockchain/blocks?start=0&end=500

Can check balances here
http://skycoin-chompyz.c9.io/outputs

Update:

The network is running. Fixed a bunch of bugs.

Structure of Skycoin Networking:

This is overview of wire protocol.

https://github.com/skycoin/skycoin/blob/master/src/daemon/messages.go#L40

NewMessageConfig("INTR", IntroductionMessage{}),
NewMessageConfig("GETP", GetPeersMessage{}),
NewMessageConfig("GIVP", GivePeersMessage{}),
NewMessageConfig("PING", PingMessage{}),
NewMessageConfig("PONG", PongMessage{}),
NewMessageConfig("GETB", GetBlocksMessage{}),
NewMessageConfig("GIVB", GiveBlocksMessage{}),
NewMessageConfig("ANNB", AnnounceBlocksMessage{}),
NewMessageConfig("GETT", GetTxnsMessage{}),
NewMessageConfig("GIVT", GiveTxnsMessage{}),
NewMessageConfig("ANNT", AnnounceTxnsMessage{}),


- Each message is a struct.
- You put values in struct, then do a "Send" and say who you want to send it to
- It packs up the struct in canonical binary format
- the struct has a .Handle() method. When the data is received, this method gets called on the receiver. The struct is already filled in, with its values


PEX: Peer Exchange

This is "give me peers" and "request peers". This is for finding other peers running skycoin (and later skywire). These get saved into  ~/.skycoin/peers.txt . Once you have enough peers, you can disable dht with -disable-dht flag.


NewMessageConfig("GETP", GetPeersMessage{}),
NewMessageConfig("GIVP", GivePeersMessage{}),

This is good example

type GetPeersMessage struct {
   c *gnet.MessageContext `enc:"-"`
}

// Notifies the Pex instance that peers were requested
func (self *GetPeersMessage) Process(d *Daemon) {
   if d.Peers.Config.Disabled {
      return
   }
   peers := d.Peers.Peers.Peerlist.RandomPublic(d.Peers.Config.ReplyCount)
   if len(peers) == 0 {
      logger.Debug("We have no peers to send in reply")
      return
   }
   m := NewGivePeersMessage(peers)
   d.Pool.Pool.SendMessage(self.c.Conn, m)
}


Transactions:

This is how transactions are replicated peer to peer. This is before transactions are placed into blocks.

NewMessageConfig("GETT", GetTxnsMessage{}),
NewMessageConfig("GIVT", GiveTxnsMessage{}),
NewMessageConfig("ANNT", AnnounceTxnsMessage{}),

When you connect to someone:
- you request list of hashes for the transactions they have.
- if they have something you dont have, you request the data for it

Gossip Protocol: When you learn about a new transaction
- when you get a new transaction, you broadcast the hash to everyone you are connected to
- if they dont have the transaction already, they request it from you

Blocks:

Very similar to transactions

NewMessageConfig("GETB", GetBlocksMessage{}),
NewMessageConfig("GIVB", GiveBlocksMessage{}),

Overview:

This is much cleaner than Bitcoin's wire protocol. There are no bloom filters. There is minimum of code.

Skycoin uses a paradigm of source independent networking, similar to urbit. It is also similar to rsync.

- You have a list of objects in your local store
- each object is "named" by the hash of its binary serialization
- You connect to remote peer
- You check list of hashes for objects you have, against list of hashes for objects they have
- you do exchange, so you get any objects they have which you dont
- you apply a filter (discarding invalid transactions or executed transactions from your store or whatever policy is)

So if person A injects a new transaction to the network, it will spread throughout the network. Eventually a block minting server will shove it into a block and it will executed.

In Skycoin there are three type of data channels. These are peer-to-peer exchanges required for network operation
- transactions (things that users create to spend coins, that replicate between nodes and then are inserted into blocks)
- blocks (lists of transactions, with some header information, such as hash of previous block in the chain)
- consensus information. This is how a server decides, which chain of multiple competing chains is valid.

Skycoin Survivability

It is very important that this information is implemented/replicated peer-to-peer.

In a war scenario, Russia, China, Brazil and even the United States will balkanize the internet. There will be communication restrictions. You will not be able to connect in the global namespace, from a server in Brazil to a server in China.

As long as there is a single satellite phone link, or clandestine cross-border radio link between countries, the peer-to-peer replication will succeed. Data replicates independently within the balkanized zones. So the cross border bandwidth may only need to be a few KB/s.

We are designing, specifically for a balkinized internet, with intermediate node connectivity. Especially in war scenario where global communications is sporadic and the electromagnetic environment is unreliable or hostile.

The internet came out of DoD ARPANET. Tor came out of Navy being able to access their secure network web-mail email servers from a public network without NSA snooping in (secure access over public networks). Skywire came out of research on store-and-forward networks for disruption-tolerant networking, mobile ad-hoc networking and diversity routing in mesh networks.



Store and forward is useful for emergency communication networks. In theory it can tolerate minutes, hours or day of latency as long as the protocol is designed to minimize round trips. It is already used for downloading files and data from space craft, where there are sporadic communication windows.

Current drones require constant network connectivity or are fully autonomous. Future drones with be semi-autonomous and roam between network access points, uploading telemetry data and receiving commands, while operating autonomously when communication networks are unavailable. Store and forward, source independent networking works very well for this application. There are similar applications for asynchronous sensor networks, where a drone or vehicle may drive by a site and connect locally to the sensors and download the data in batches, without requirement for real time network access. Sensor and vehicle networks that have been cut off from global internet can continue to function in the local network without interruption and exchange data when possible.

A drone may have satellite uplink, but is also able to use stationary ground links it encounters. This allows continued operation if the satellite is jammed or shot down or equipment becomes damaged (redundancy). A drone may wander drifting between sources of power and communication and opportunistically uploading/exchanging data about resource locations with other elements of the sensor/vehicle swarm.

Meshnets, emergency communication networks, sensor/vehicle swarms require a new type of networking technology. TCP/IP end-to-end re-transmission no longer works when you have 10 hops and even 5% loss on each hop. The source independent networking and store-and-forward method is "scale invariant" in that it handles latencies of milliseconds the same as latencies of hours and days. However, it is a complete redefinition of the existing network stack.

It is ironic that the network of the future, is going back to Unix-to-Unix Copy.

Consensus Data

In Bitcoin, PoW is baked into the block headers. You cannot change Bitcoin consensus method without invalidating the whole blockchain. In Skycoin, consensus is flexible, can be changed later. Skycoin will use an open network of nodes, but a bank may fork it and decide to run customer account balances in Euro on a Skycoin chain, but will only use a closed set of bank servers for the consensus process.

Outputs/Transactions are designed to be independent of the blockchain. This means that a ledger of transactions can be migrated from one ledger, to a new ledger when needed. This is to ensure that Skycoin ownership and balances are preserved, while enabling upgrades in the future.

Here to download wallet client: http://128.199.188.22/

Update:

Block replication worked. It just fixed itself. Transaction replication needs to be fixed.

I just want to get IPO over... get back to writing new code instead of debugging.

Security Link:

In the long term, we need open source CPUs.

Some of the CPUs have microcode backdoors that do not have any authentication on the microcode patches. The most recent ones use an RSA key, but anyone with the RSA key can exploit the CPU. There also appear to be buffer overflow attacks on the microcode update process itself. The security appears to be horrible. The Intel Processors were easier to exploit than AMD. There are more microcode example.

It is impossible to read out the ram of the microcode on the processor, impossible to audit and impossible to verify. CPUs can be clandestinely backdoored before export and it would not be detected.
 
https://www.dcddcc.com/pubs/paper_microcode.pdf

Intel vPro is very worrisome.

Update:

Can someone pull and run some servers.

Open ports 5999 and 6000 (preferably VPN server) for UDP/TCP

Then run
git pull
go run ./cmd/skycoin/skycoin.go

It should work now. Except all of the servers in network are behind firewalls, VPN and cannot get incoming connections.

Update:

Unit tests work for networking. It works locally. It works with multiple clients on the internal virtual private network for testing. It is 100% working. However, on public internet cannot connect to anything and there are strange errors. The peers/connection list is empty.

[skycoin.daemon:DEBUG] Removing 89.110.41.155:23547 because failed to connect: dial tcp 89.110.41.155:23547: i/o timeout
[skycoin.daemon:DEBUG] Removing 122.31.215.119:9721 because failed to connect: dial tcp 122.31.215.119:9721: no route to host
[skycoin.daemon:INFO] Removing 124.11.192.188:10167 for not sending a version
[gnet:DEBUG] Failed to read from 124.11.192.188:10167: read tcp 124.11.192.188:10167: use of closed network connection
[skycoin.daemon:INFO] 124.11.192.188:10167 disconnected because: Version timeout
[skycoin.daemon:DEBUG] Sending introduction message to 111.250.149.229:23790
[gnet:DEBUG] Failed to read from 111.250.149.229:23790: EOF
[skycoin.daemon:INFO] 111.250.149.229:23790 disconnected because: Read failed

to see list of connections do:
http://skycoin-chompyz.c9.io/api/network/connections
http://127.0.0.1:6420/api/network/connections

We are getting
- "no route to host"
- "i/o timeout"
- connection opens and version (first packet) is never sent
- EOF when trying to read from socket

Line 424, func (self *ConnectionPool) connectionReadLoop(conn *Connection) {

That is the read loop
https://github.com/skycoin/gnet/blob/master/pool.go

TCP/ip has bizarre error conditions. It is also forced in golang. We have
- a listening go routine for each pool of sockets
- a go routine for accepting new connections
- two go routines per socket. a goroutine for reading from socket and a goroutine for sending over socket, with queues for messages
- a goroutine for checking the messages and processing them, that came from the goroutines

We have a full refactor and rewrite of daemon and networking, but cant use it because of other major refactoring, which is a bit exhausting. There is no way to do the refactor incrementally without introducing circular imports, which prevents compilation. I think I want to deprecate TCP/ip completely because it is too frustrating.

Also, we have other issues
- running skycoin is disconnecting some people's VPN
- skycoin appears to disconnecting some people's wifi connections

Skycoin is using the Bitorrent kadmelia DHT, so it might be mistaken for a bitorrent client and could be seeing some type of purposeful disruption. I have no idea why the client appears to work on local host and on the internal VPN for testing, but does not work on the public internet.

Skycoin is using DHT with UDP on port 5798 for Bitorrent DHT and listening with TCP on port 5798 for incoming connections. It is possible that this condition causes crashes or confusing behavior on some operating systems, virtual private network implementations and may crash some poorly implemented routers.

This may be some weird NAT traversal and VPN problem.

I will try to fix the port number, to something else and hardcode it, then see if it works.

Update:

This is security vulnerability in 2-factor auth for coin base

http://qntra.net/2015/03/security-as-a-coffin/

More OpenSSL problems. This is why we are not using OpenSSL.

"A vulnerability existed in previous versions of OpenSSL related to the
processing of base64 encoded data. Any code path that reads base64 data from an
untrusted source could be affected (such as the PEM processing routines).
Maliciously crafted base 64 data could trigger a segmenation fault or memory
corruption."

"Reusing a structure in ASN.1 parsing may allow an attacker to cause
memory corruption via an invalid write. Such reuse is and has been
strongly discouraged and is believed to be rare."

"A malicious client can trigger an OPENSSL_assert (i.e., an abort) in
servers that both support SSLv2 and enable export cipher suites by sending
a specially crafted SSLv2 CLIENT-MASTER-KEY message."

http://qntra.net/2015/03/march-19th-openssl-vulnerabilities-overview/

There is a heart bleed bug every six months. I am very worried about the fact that Bitcoin is still using OpenSSL.

IPO Update:

The network is running. Transactions are working. However, connecting to other clients and block replication appears to be experiencing problems.

There appears to be an issue with servers connecting peer to peer. Something may have broken in the refactor. There is an EOF error on socket read and not sure what cause is and have to check that the keep alive packet for connections is working. Clients from another application may be connecting because of the kadmelia DHT requests, but not sure.

The developer who wrote this part of the code has been traveling on vacation for a few months and different person refactored it and I have no idea where the unit testing suite for networking went (but we had tool for this before refactor, but cannot find it). So will just do it by hand with printf. There may not even be problem and it may be that http://127.0.0.1:6420/api/network/connections is broken.

As soon as the existing networking is fixed, then another refactor begins to replace it with skywire and move rest to functions out of /src/daemon into other modules.

Getting the coin to "perfect" will take years. The crypto and blockchain are almost in a perfect state right now. The rest could use refactoring, cleanup and simplification. However that can be done over years and should not be rushed. The priority is to get core coin checked off and then move onto more important libraries (like skywire). There are still a few thousand lines of code that can be refactored out and simplification.

I think we fixed too many of the bugs before launching. We should have done it cowboy style.

Someone has also reported that using Skycoin behind a VPN breaks the VPN connection. I have no idea. I am not experiencing that issue.

Here, this is web-wallet and client, exposed publicly
http://skycoin-chompyz.c9.io/
http://skycoin-chompyz.c9.io/api/network/connections

This list should not be empty. There should be three or four servers it connects to, but we are not seeing them and its not clear why its not connecting to network.

Links:


IPFS Demo:

This is IPFS. This is the successor to Bitorrent.

https://www.youtube.com/watch?v=8CMxDNuuAiQ

Skycoin Merkle-dag system is based upon this.
- A directory is a list of nodes. The id of the node is the hash of its serialization
- Each node is either a folder or a file.
- The contents of files are hashes
- The owner signs the root hash with their private key
- The node metadata and files are replicated peer-to-peer
- the directory is referenced by a

Users can update the files after they upload them. If you have a javascript file, instead of rerequesting the file from the server, everytime the page is loaded, the file is named by its hash. If the hash is in the local cache, it does not need to redownload it.

This will speed up blockchain downloads, but has other applications. The Skycoin version is
- a stripped down version of IPFS using skycoin cryptography primitives
- runs over Skywire

Cuba Meshnet:

This is a good article on the Cuba meshnet

http://www.detroitnews.com/story/business/2015/01/26/cuban-youth-computer-network/22367037/

This article shows several things
- it is pathetic that people in most parts of the world need to beg their governments for permission to have internet
- government regulation is designed to control and enslave people, not for their benefit. The meshnet cannot be connected to the real internet, because it would compete with the government telecom monopoly
- if people in the middle of the network can see the traffic and protocols you are running, they will be compelled to block pornography or other arbitrary content. They are forced by terror into erecting an NSA police state, even on a network of 9000 nodes, to keep the government from putting them in a black van and disappearing them.
- the state monopoly and control of communications is the primary way that oppressive dictatorships remain in power.
- oppressive governments are funded by resource and service monopolies. The Cuban government anti-freedom thugs are funded by raping citizens with an oppressive telecom monopoly. The corrupt Brazilian government is funded by the state oil company and by state electricity and distribution monopolies. The Venezuelan government is funded by state oil monopolies. Governments put in place monopolies, rape citizens with high costs and then use the money to high thugs to stay in power.
- It is absolutely pathetic, how citizens have to beg and pleat like slaves begging to their masters, for even the scraps of freedom they have. People should not live under terror and total domination by the state. This is slavery.

Meshnet Hardware: 1 Gb/second over IR laser over 100 meter range

This is one of the second generation RONJA projects.



"KORUZA system enables 1Gbps networking connectivity for locations up to 100m apart, by using an eye-safe infrared light beam. It is an open-source open-hardware ultrafast networking technology, innovating use of free-space optical networks. Mass produced electro-optical modules are combined with 3D printing technology to simplify the design and create a system significantly more affordable then current solutions."

https://dev.wlan-si.net/wiki/KORUZAbut
https://dev.wlan-si.net/wiki/KORUZA/Prototype

The hardware for gigabit freespace communication, multi gigabit wifi, SDR and other technologies for meshnet are in development and will be commodity within a few years. We are are dropping all direct involvement in the hardware side and focusing only on the software and encryption side now.

The collective progress that has been made in the open source community on the hardware side of the meshnet in the last six months is just incredible.

Yes. Keep your wallets! This only affects the blockchain.

If you know your wallet seed, you will be fine. You can open up the wallets with text editor and grab the seed. As long as you have this value, your wallet can never be lost. You can also just copy and paste the wallet directory.

Eventually, I want to change the wallet deterministic generation function to SHA3/Keccak sponge function based instead of SHA256, but it is too late for this. It is best to not make major changes like this at beginning. In a year or so, there may be a major overhaul of the wallet.

There is a huge backlog of refactoring and improvements with
- wallets
- wire protocol
- networking
- block storage
- etc

Getting architecture "perfect" is a lot of work and can only be done incrementally and over months and years. We already delayed over a year for launch, so will just get this over will and make incremental improvements over time (even if the balances need to be moved to a new ledger). For Skycoin, improvements mean that the libraries are smaller, modular, simpler, more specific, have fewer edge cases and have less code. We are not adding things, but simplifying things.

The crypto library is almost perfect, but this will have another iteration of improvement too. The new library will be pure go, to allow cross compilation, wallet encryption and will have support for external key storage devices. The blockchain library is very good too and cannot be improved much. These are the two areas with security implications and where attention and testing has been exhaustive.

As you go from the crypto/blockchain, to networking and then to javascript/GUI you get more errors and more areas that need polish and can be made more elegant.

Skycoin has an onion structure
- the inner parts of the onion are almost perfect (crypto, blockchain, address/hash utilities)
- the mid layers are working but could be improved (visor, daemon, networking, blockchain storage, json API, consensus)
- the outer libraries are still being implemented (next gen DHT, skywire, merkle-dag block storage for bitorrent like block downloads in parallel, darknet application framework, communication addresses, distributed exchange)

The team for the inner layers and mid layers is done. There are a very large number of outer layer projects that rely upon the inner layers. These are independent and can be worked on by multiple teams and developers. Each project is designed to be short, limited scope, something that a single developer can get working quickly (lightning project).

The inner parts have to be exhaustively tested and cannot permit failures or error. A failure here is a lose of coins or major error (such as Ethereum integer overflow allowing you to send negative balances from your account to another person and steal their coins). This increases development effort, attention requirement and code review by 10x to 20x over normal code. These layers can only be worked on by very small group of people and require specialized skills and heavy testing (fuzzing, 100% coverage unit testing, failure analysis).

The outer layers can tolerate failure and can be developed cowboy style and duct taped back together if it falls apart. These are the easiest part to develop. The fastest and easiest.

Libraries and interfaces that are used by other applications, have to be high quality and clean, requiring about 8x the time/effort as code that is functional but not intended for reuse. The crypto library, address generation library and JSON interface are intended for use by other applications and hence development time requirement, attention and elegance requirements are higher. Where as the web-wallet is something that merely needs to work and function as intended ("throwaway code") and can tolerate cowboy development.

Then there are open ended research problems and infrastructure projects. These are things like personal blockchains, merkle-DAG, project ARA, SDR hardware, languages, compiler toolchains/environments for deterministic builds and next-generation infrastructure that gives us new capacities. Once things in this category are figured out, enough to break them into a finite scoped project, then we can push that on queue.

After the coin is launched and working 100%, it will be extremely boring. You will be able to check balances and to send coins. The coin only does two things. The functionality of a cryptocoin is underwhelming. The external functionality is simple and trivial, but the internals (the crypto, blockchain, networking) are precision components. The engineering has a similar analogy to a jet-engine or pocket watch.

There are watches that have micron machined titanium components, a minimum of components, ruby bearings, sapphire watch face, illumination by tritium. The difference from a $5 watch is only on the edge cases.
- the $5 watch stops functioning after 15 years because it has an oil bearing that drys up, while the dry ruby bearing watch keeps functioning. See: http://en.wikipedia.org/wiki/Jewel_bearing
- the $5 watch does not work in the dark, while the watch illuminated works. (the tritium is produced in the Russian fast breeder reactors that are used to produce materials for thermonuclear nuclear weapons)
- the $5 watch stops working and "freezes" after Hiroshima or Nagasaki because the EMP blast from the nuclear weapon magnetized the watch internals, while the titanium watch continues to function
- the $5 watch is machined on commodity hardware, while the titanium watch assembly required years in investment for the design of a new type of CNC machine specialized to the components and materials in the assembly
- the $5 watch cracks easily and its face scratches, while the sapphire watch face can only be scratched by diamond and can withstand pressures that will easily kill the owner
- A watch with twice as many components is more likely to break if subjected to a 50 g shock, than a simpler watch. Every component adds more surfaces for wear, more things that can break and more things that need to be replaced.

Each design choice, each material has a very specific reason. Some of the materials are extremely exotic. The owner probably does not understand the neutron irradiation process for breeding tritium, the design of the fast neutron reactor, the tritium extraction process or how  radioluminescence and tritium beta decay can be used for illumination. See: https://en.wikipedia.org/wiki/Tritium_illumination






The owner of the watch will never open it. They will never see the inside. They will never know the material it was made from. They will never see the bearings or have any idea that there is tritium in the watch or where it came from. Yet that level of engineering and the use of the best materials and engineering for each respective function is what defines luxury. Luxury is quality, purposeful design and the best in each aspect.

Faux luxury is advertising. A multitude of features, buzz words, hype, endorsement and marketing over substance. Bling and branding.
- The most accurate watch (Marine chronometers) has seven jeweled bearing. Jeweled bearings are better than normal bearings, so more becomes associated with "better" in the minds of consumers. 15 Jeweled bearing become "better" than 11 Jeweled bearings and soon there is a Jewel marketing arms race and watches are manufactured with 150 Jewels, even through 136 of them are non-functional. See: http://en.wikipedia.org/wiki/Mechanical_watch#.27Jewel_inflation.27
- watches proliferate that are full of bling and branding at the cost of quality. "Quality" becomes associated with the number of buzz words. There is a proliferation of features. Watches begin to sacrifice elegance to show you the time in three different time zones, the day of the week, the month and to remind you of your birthday. Until the watch is heavy, prone to failure and impossible to repair or understand.
- Marketers create a slew of new buzz words for products to compete on and to be thrown around. They try to create a meaningless standard metrics. In watches, the number of jeweled bearings. In CPUs, the number of megahertz, until the CPUs are so fast that frequent cache misses stalls the CPU for 30 clock cycles. In altcoins hashing functions, blocktimes and increasingly esoteric and useless contracts and features. In CMOS cameras the sensor size. The easily marketed attributes are oversold, beyond any gain in performance or quality.
- Faux luxury is taking a product that is essentially corn processed in a chemical plant and injecting it with some oil and then advertising the fact that it has 200 mg of Omega-3 in it and stamping a paid endorsement form the American Medical Association on the box.

False luxury is the belief that a $2 shirt is "worth" $120 because of a "luxury" brand on it, that advertises the price you paid. It is the belief that value of a $2 shirt is twice as much if you pay $120 for it than if you pay $60. Where as true luxury comes from the quality, design, beauty, elegance and materials and hides the brand behind the artifact.

Normally, you would take existing materials and create a best of breed design. Satoshi took visual studios, SVN, openssl, berkleyDB and the software libraries that were available at the time and cobbled together Bitcoin. You can still see the effects of these libraries, long after they have been deprecated and removed. Such as the weird endianess flips in the calculation of block hashes.

When the Skycoin project started, we took the best tools available and began there. I believed the project was going to be finite, that we would fix Bitcoin, change the hashing function and a few things and the launch. That turned into
- writing a new cryptography library
- new consensus algorithm
- new programming language (golang instead of C++)
- new deterministic wallet generation function
- new bipartite transaction graph structure instead of a multigraph
- local webwallet
- new blocksync algorithms
- new networking primitives
- etc...

Most of these things were driven by external events and became requirements for any new coin, rather than "features" . The amount of new things that need to be designed and implemented, left me feeling like an insane watch maker who was forced to invent a nuclear reactor to get tritium, just to build the perfect watch. The existing materials and libraries were everywhere insufficient. The scope of the project is becoming clear and its is very large. We are finally getting a clear perspective of everything that needs to be done.

I want to get the IPO over will and then break this up into smaller, finite projects and get more developers working on the pieces.

IPO Update:

We are doing exhaustive tests and code review. There was a frustrating bug that set us back a week. 10e6 is actually 10 million in golang, not 1 million. 1 million is 1e6. This is trivial, but caused error in the coin locking system. The 100 million coins are being sent, 1 million coins to each of 100 addresses with multiparty lock system to prevent theft. There is also a time capsule lock on the private keys. The addresses are

var AddrList []string = []string{
   "R6aHqKWSQfvpdo2fGSrq4F1RYXkBWR9HHJ",
   "2EYM4WFHe4Dgz6kjAdUkM6Etep7ruz2ia6h",
   "25aGyzypSA3T9K6rgPUv1ouR13efNPtWP5m",
   "ix44h3cojvN6nqGcdpy62X7Rw6Ahnr3Thk",
   "AYV8KEBEAPCg8a59cHgqHMqYHP9nVgQDyW",
   "2Nu5Jv5Wp3RYGJU1EkjWFFHnebxMx1GjfkF",
   "2THDupTBEo7UqB6dsVizkYUvkKq82Qn4gjf",
   "tWZ11Nvor9parjg4FkwxNVcby59WVTw2iL",
   "m2joQiJRZnj3jN6NsoKNxaxzUTijkdRoSR",
   "8yf8PAQqU2cDj8Yzgz3LgBEyDqjvCh2xR7",
   "sgB3n11ZPUYHToju6TWMpUZTUcKvQnoFMJ",
   "2UYPbDBnHUEc67e7qD4eXtQQ6zfU2cyvAvk",
   "wybwGC9rhm8ZssBuzpy5goXrAdE31MPdsj",
   "JbM25o7kY7hqJZt3WGYu9pHZFCpA9TCR6t",
   "2efrft5Lnwjtk7F1p9d7BnPd72zko2hQWNi",
   "Syzmb3MiMoiNVpqFdQ38hWgffHg86D2J4e",
   "2g3GUmTQooLrNHaRDhKtLU8rWLz36Beow7F",
   "D3phtGr9iv6238b3zYXq6VgwrzwvfRzWZQ",
   "gpqsFSuMCZmsjPc6Rtgy1FmLx424tH86My",
   "2EUF3GPEUmfocnUc1w6YPtqXVCy3UZA4rAq",
   "TtAaxB3qGz5zEAhhiGkBY9VPV7cekhvRYS",
   "2fM5gVpi7XaiMPm4i29zddTNkmrKe6TzhVZ",
   "ix3NDKgxfYYANKAb5kbmwBYXPrkAsha7uG",
   "2RkPshpFFrkuaP98GprLtgHFTGvPY5e6wCK",
   "Ak1qCDNudRxZVvcW6YDAdD9jpYNNStAVqm",
   "2eZYSbzBKJ7QCL4kd5LSqV478rJQGb4UNkf",
   "KPfqM6S96WtRLMuSy4XLfVwymVqivdcDoM",
   "5B98bU1nsedGJBdRD5wLtq7Z8t8ZXio8u5",
   "2iZWk5tmBynWxj2PpAFyiZzEws9qSnG3a6n",
   "XUGdPaVnMh7jtzPe3zkrf9FKh5nztFnQU5",
   "hSNgHgewJme8uaHrEuKubHYtYSDckD6hpf",
   "2DeK765jLgnMweYrMp1NaYHfzxumfR1PaQN",
   "orrAssY5V2HuQAbW9K6WktFrGieq2m23pr",
   "4Ebf4PkG9QEnQTm4MVvaZvJV6Y9av3jhgb",
   "7Uf5xJ3GkiEKaLxC2WmJ1t6SeekJeBdJfu",
   "oz4ytDKbCqpgjW3LPc52pW2CaK2gxCcWmL",
   "2ex5Z7TufQ5Z8xv5mXe53fSQRfUr35SSo7Q",
   "WV2ap7ZubTxeDdmEZ1Xo7ufGMkekLWikJu",
   "ckCTV4r1pNuz6j2VBRHhaJN9HsCLY7muLV",
   "MXJx96ZJVSjktgeYZpVK8vn1H3xWP8ooq5",
   "wyQVmno9aBJZmQ99nDSLoYWwp7YDJCWsrH",
   "2cc9wKxCsFNRkoAQDAoHke3ZoyL1mSV14cj",
   "29k9g3F5AYfVaa1joE1PpZjBED6hQXes8Mm",
   "2XPLzz4ZLf1A9ykyTCjW5gEmVjnWa8CuatH",
   "iH7DqqojTgUn2JxmY9hgFp165Nk7wKfan9",
   "RJzzwUs3c9C8Y7NFYzNfFoqiUKeBhBfPki",
   "2W2cGyiCRM4nwmmiGPgMuGaPGeBzEm7VZPn",
   "ALJVNKYL7WGxFBSriiZuwZKWD4b7fbV1od",
   "tBaeg9zE2sgmw5ZQENaPPYd6jfwpVpGTzS",
   "2hdTw5Hk3rsgpZjvk8TyKcCZoRVXU5QVrUt",
   "A1QU6jKq8YgTP79M8fwZNHUZc7hConFKmy",
   "q9RkXoty3X1fuaypDDRUi78rWgJWYJMmpJ",
   "2Xvm6is5cAPA85xnSYXDuAqiRyoXiky5RaD",
   "4CW2CPJEzxhn2PS4JoSLoWGL5QQ7dL2eji",
   "24EG6uTzL7DHNzcwsygYGRR1nfu5kco7AZ1",
   "KghGnWw5fppTrqHSERXZf61yf7GkuQdCnV",
   "2WojewRA3LbpyXTP9ANy8CZqJMgmyNm3MDr",
   "2BsMfywmGV3M2CoDA112Rs7ZBkiMHfy9X11",
   "kK1Q4gPyYfVVMzQtAPRzL8qXMqJ67Y7tKs",
   "28J4mx8xfUtM92DbQ6i2Jmqw5J7dNivfroN",
   "gQvgyG1djgtftoCVrSZmsRxr7okD4LheKw",
   "3iFGBKapAWWzbiGFSr5ScbhrEPm6Esyvia",
   "NFW2akQH2vu7AqkQXxFz2P5vkXTWkSqrSm",
   "2MQJjLnWRp9eHh6MpCwpiUeshhtmri12mci",
   "2QjRQUMyL6iodtHP9zKmxCNYZ7k3jxtk49C",
   "USdfKy7B6oFNoauHWMmoCA7ND9rHqYw2Mf",
   "cA49et9WtptYHf6wA1F8qqVgH3kS5jJ9vK",
   "qaJT9TjcMi46sTKcgwRQU8o5Lw2Ea1gC4N",
   "22pyn5RyhqtTQu4obYjuWYRNNw4i54L8xVr",
   "22dkmukC6iH4FFLBmHne6modJZZQ3MC9BAT",
   "z6CJZfYLvmd41GRVE8HASjRcy5hqbpHZvE",
   "GEBWJ2KpRQDBTCCtvnaAJV2cYurgXS8pta",
   "oS8fbEm82cprmAeineBeDkaKd7QownDZQh",
   "rQpAs1LVQdphyj9ipEAuukAoj9kNpSP8cM",
   "6NSJKsPxmqipGAfFFhUKbkopjrvEESTX3j",
   "cuC68ycVXmD2EBzYFNYQ6akhKGrh3FGjSf",
   "bw4wtYU8toepomrhWP2p8UFYfHBbvEV425",
   "HvgNmDz5jD39Gwmi9VfDY1iYMhZUpZ8GKz",
   "SbApuZAYquWP3Q6iD51BcMBQjuApYEkRVf",
   "2Ugii5yxJgLzC59jV1vF8GK7UBZdvxwobeJ",
   "21N2iJ1qnQRiJWcEqNRxXwfNp8QcmiyhtPy",
   "9TC4RGs6AtFUsbcVWnSoCdoCpSfM66ALAc",
   "oQzn55UWG4iMcY9bTNb27aTnRdfiGHAwbD",
   "2GCdwsRpQhcf8SQcynFrMVDM26Bbj6sgv9M",
   "2NRFe7REtSmaM2qAgZeG45hC8EtVGV2QjeB",
   "25RGnhN7VojHUTvQBJA9nBT5y1qTQGULMzR",
   "26uCBDfF8E2PJU2Dzz2ysgKwv9m4BhodTz9",
   "Wkvima5cF7DDFdmJQqcdq8Syaq9DuAJJRD",
   "286hSoJYxvENFSHwG51ZbmKaochLJyq4ERQ",
   "FEGxF3HPoM2HCWHn82tyeh9o7vEQq5ySGE",
   "h38DxNxGhWGTq9p5tJnN5r4Fwnn85Krrb6",
   "2c1UU8J6Y3kL4cmQh21Tj8wkzidCiZxwdwd",
   "2bJ32KuGmjmwKyAtzWdLFpXNM6t83CCPLq5",
   "2fi8oLC9zfVVGnzzQtu3Y3rffS65Hiz6QHo",
   "TKD93RxFr2Am44TntLiJQus4qcEwTtvEEQ",
   "zMDywYdGEDtTSvWnCyc3qsYHWwj9ogws74",
   "25NbotTka7TwtbXUpSCQD8RMgHKspyDubXJ",
   "2ayCELBERubQWH5QxUr3cTxrYpidvUAzsSw",
   "RMTCwLiYDKEAiJu5ekHL1NQ8UKHi5ozCPg",
   "ejJjiCwp86ykmFr5iTJ8LxQXJ2wJPTYmkm",
}

When you run the skycoin client, you can see the following output in the console


If you are in Linux/OS X, then {YOU_SKYCOIN_DIR} should be "~/.skycoin",
if you are in windows, then {YOU_SKYCOIN_DIR} should be some other directory like "C:\Users\{YOUR_USER_NAME}\.skycoin" if you are using windows 7 with english locale.

Open the {YOU_SKYCOIN_DIR} directory with your file manager, and delete all files with name beginning with "blockchain".

Development Update:

You have to nuke the blockchain files in .skycoin again. "rm ~/.skycoin/blockchain*"

Skycoin Transaction Format:

There is an output

[
    {
        "hash": "043836eb6f29aaeb8b9bfce847e07c159c72b25ae17d291f32125e7f1912e2a0",
        "src_tx": "0000000000000000000000000000000000000000000000000000000000000000",
        "address": "2jBbGxZRGoQG1mqhPBnXnLTxK6oxsTf8os6",
        "coins": 100000000000000,
        "hours": 100000000000000
    }
]

An output has
- a balance of coins
- a balance of coinhours
- an address that "owns" the outputs. the person with the private key, whose public key hashes to the address can spend the output

1,000,000 base units = 1 coin. I think the base unit is called a "drop". So each coin is divisible to 6 decimal places. 1 million coins is 1% of total. So there will only be at most ~6 digits before the decimal and 6 digits after the decimal to keep it manageable. Anything more than 6 digits before/after decimal place becomes difficult to count.

A transaction is:

 {
  "hash": "96943281a3fd298bf05c848300d173ab9bf586b4024b080d1ca3aad03a458b9c",
  "inner_hash": "ca67e004b932137f8469d72e1e4147621f890cfc23f6d2f70e38eeb08da85aba",
  "sigs": [
    "5610209b061ff472766f9d36e70834c605a8911aa63dc64538bdf5d83339c8da10522810623a6e8 70865eab6ccdbe61741e27e7a21afd537e11768e90fbf96d900"
  ],
  "in": [
    "043836eb6f29aaeb8b9bfce847e07c159c72b25ae17d291f32125e7f1912e2a0"
  ],
  "out": [
    {
      "hash": "c09d5afa78684e14a676b13961a756e6fa9b2c5bebb7be71cf2dc143b4f633cc",
      "src_tx": "ca67e004b932137f8469d72e1e4147621f890cfc23f6d2f70e38eeb08da85aba",
      "address": "2jBbGxZRGoQG1mqhPBnXnLTxK6oxsTf8os6",
      "coins": 99999990000000,
      "hours": 66666666666665
    },
    {
      "hash": "d5651588726225707c0b3fd97a9325b0863580f5b70d8a081035cb2aabaa8c53",
      "src_tx": "ca67e004b932137f8469d72e1e4147621f890cfc23f6d2f70e38eeb08da85aba",
      "address": "D2S9qZ1x2uiET7zXCdTDcPbbibfRuJdg3U",
      "coins": 10000000,
      "hours": 1
    }
  ]
}

When executed this will spend output
- 043836eb6f29aaeb8b9bfce847e07c159c72b25ae17d291f32125e7f1912e2a0
and will create outputs
- c09d5afa78684e14a676b13961a756e6fa9b2c5bebb7be71cf2dc143b4f633cc
- d5651588726225707c0b3fd97a9325b0863580f5b70d8a081035cb2aabaa8c53

This transaction takes an output, spends it and creates two new outputs.

A transaction is
- a list of outputs being spent (outputs destroyed)
- a list of new outputs created (new outputs)
- a list of signatures, one per output being spent
- There is an "inner hash" which is the hash of the list of outputs being spend and outputs being created
- You take the hash of the output being spent, compute the SHA256 of the inner hash, with the hash of the output. Then you sign this hash with your public key

A transaction may not create or destroy coins. A transaction must create outputs with exactly as many coins as are consumed in the inputs.

If you have 20 coins in an output, to send 5 coins to someone, you send 5 coins to them and 15 coins back to an address you own. The transaction consumes one output and creates two new outputs.

Serialization Format:

Skycoin uses a 4 byte length prefix serialization.
- A byte array is serialized by 4 bytes for the length of the array, followed by the bytes.
- An array of 12, 48 byte structs is serialized as a 12*48 in 4 byte prefix, followed by the elements
- structs are serialized similarly

To protect against transaction mutability, the inner hash of a transaction is the "id" of the transaction. The "hash" field is the the hash of the binary serialization of the full transaction.

Struct Data:

An output is defined as

type UxOut struct {
   Head UxHead
   Body UxBody //hashed part
   //Meta UxMeta
}

// Metadata (not hashed)
type UxHead struct {
   Time  uint64 //time of block it was created in
   BkSeq uint64 //block it was created in
   // SpSeq uint64 //block it was spent in
}

type UxBody struct {
   SrcTransaction cipher.SHA256  // Inner Hash of Transaction
   Address        cipher.Address // Address of receiver
   Coins          uint64         // Number of coins
   Hours          uint64         // Coin hours
}

Only the body matters for hashing. The UxHead is metadata, but is used for coinhour computation. Coin hours are intended as "soft constraints". A coin hour constraint may experience a soft violated when moving transactions and balance to a new ledger (ledger migration), but is enforced in general.

A transaction is

type Transaction struct {
   Length    uint32        //length prefix
   Type      uint8         //transaction type
   InnerHash cipher.SHA256 //inner hash SHA256 of In[],Out[]

   Sigs []cipher.Sig        //list of signatures, 64+1 bytes each
   In   []cipher.SHA256     //ouputs being spent
   Out  []TransactionOutput //ouputs being created
}

//hash output/name is function of Hash
type TransactionOutput struct {
   Address cipher.Address //address to send to
   Coins   uint64         //amount to be sent in coins
   Hours   uint64         //amount to be sent in coin hours
}

The inner hash is the SHA256 hash of the serialization of the In Array and Out array appended together.

CoinJoin Transactions

In Bitcoin,
- if two addresses are used as input in the same transaction, they belong to the same wallet
- This allows most addresses in a wallet to be linked as belonging to a single wallet with high probability from the public transaction history

A CoinJoin transaction is a transaction that mixes multiple outputs, from different wallets in a single transaction.
- Even a modest rate of coin mixing through CoinJoin (5% of transaction volume) introduces enough diffusion into network to severely frustrate association of specific addresses to individual wallets or users from public data. Especially for high volume services that end up processing most of the transactions on the network.
- If the third party CoinJoin server is trusted, this has the same level of privacy as ZeroCoin and quantum zero knowledge proof schemes, but with a much simpler protocol.

- In Bitcoin, you can tell CoinJoin transactions apart from normal transactions.
- in Skycoin, there is no difference between a normal transaction and a CoinJoin transaction.

The protocol is simple:
- you send inputs and outputs to a 3rd party CoinJoin server
- they take inputs/outputs from multiple users, randomize order, send back transaction
- each user signs their outputs and sends signature back to the server
- the server injects the transaction into the network

The 3rd party server is unable to steal your coins. If the transaction fails (someone did not send back signatures), you just try again until it succeeds. This is mixing, with no risk of theft of the coins.

There are three axises that information is leaked in Bitcoin
1. addresses from single wallet are colocated in transactions
2. multiple input addresses, single output adddress + change (vs multiple input with sender's coins going into multiple outputs addresses)
3. coin balances vs change addresses are identifiable. If you have 15.328942343 coins and send someone 1.0 coins, then you will have 1.0000 coins in one output and 14.328942343 in the change output. In practice this makes it easy to identify the output address.

Skycoin addresses #1 with CoinJoin for spatial diffusion
Skycoin can address #2 with higher level messaging protocol for receipts exchanging multiple addresses for transactions, off the blockchain, when possible. Also darkwallet type address generation from receiver public key. This also eliminates address reuse automatically.
Skycoin can address #3 by capping coins to integer values and distributing outputs in wallet to a known distribution in combination with #2

Once those three things are done, there is effectively zero bits of information in the public ledger about the receiver or recipient or owners. The outputs, addresses, balances become meaningless pseudo-random numbers that contain no information. They cannot be used to infer the hidden variables from the public record. Nothing can be determined from the public blockchain alone.

With discrete random variable A and random variable B, where A is public and B is unknown, we can ask "How many bits of information does A tells us about B". For transactions these three conditions correspond to P(B | A) = P(B) where A is the public visible variable and B is the unobserved variable that someone ones to infer from the hidden variable.

#2 requires "communication addresses". This is a hash of a public key, that is used to look up data in a DHT (distributed DNS system), to obtain a communication address and receive a list of unused virgin addresses to split the receiving of coins over. The infrastructure for this is almost done, but is a long term project.

Practical CoinJoin, may just be you and the CoinJoin server. The server would maintain a pool of outputs and mix them in with your outputs and never reuses addresses. The CoinJoin server may itself, mix its pool of outputs over other CoinJoin servers. This achieves a high level diffusion at a practical level of cost and implementation complexity.

Temporal diffusion, means that the payment into the N-output addresses occurs over multiple transactions instead of being localized with every input and output in a single transaction. The send is split up over multiple transactions.

Example:
- you have a wallet with outputs with coin balances of [1, 3, 5, 7, 11, 17]
- You want to send 12 coins to someone
- You use their communication address to ask for a list of virgin unused addresses for receipt of coins
- You send the output with 5 coins in one coinjoin transactions to address 1 (with multiple other wallets in the transaction); N inputs M outputs
- You send the output with 7 coins in another transaction to address 2
- They now have 12 coins

If the coins are stored with balances sampled from a known statistical distribution (as as uniform distribution of prime numbers less than N) then this does not leak any information

Similarly you could do coinjoin transaction and spent the 17 output, into four outputs
- input [17]
- output [1, 5, 11]
- The outputs all go to never used addresses
- the output of 1 and 11 goes to the recipient
- the outputs of 5, goes to a never used change address

Misc/ Bitcoin Thought Experiment: Perfect Pseudo Anonymity

Off topic but

To make a Bitcoin variant that leaks no information about wallets or owners from the blockchain, consider the following
- each output can only contain 1 coin
- each transaction can only spend 1 output and create 1 output
- addresses cannot be reused. An address that has received a coin in the past cannot receive another coin.

In this system, to send 10 coins, you have to do 10 transactions. The transactions each transfer a coin from a never used address to a never used address. This is the simplest system that leaks no knowledge about wallets/destinations/recipients.

You could also relax this to allow N inputs and M outputs, but keeping the single coin per output requirement.
- If each send transaction is implemented over a single transaction with N inputs and N outputs,  then the input addresses become "linked" and its no longer anonymous. If two addresses appear as inputs to a transaction you know they belong to the same wallet.
- If the send transaction is implemented with N inputs and N outputs, with CoinJoin, then information is still leaked, but it is fractional bits of information. If two addresses appear as the input to a transaction, the probability they belong to the same wallet is increased.
- If the send transaction is implemented as N inputs and N outputs, as CoinJoin but only 1 address/output from each wallet can be used as input, then no information is leaked. This is back to the 1 input, 1 output case. There is also diffusion. You know that each input will go to one of the outputs, but you dont know which. If you have N inputs and N outputs, there are N factorial ways of assigning the input coins to the output coins.

For a practical system instead of only storing a single coin per output (meaning 150 outputs or transactions to send 150 coins), you fix a probability distribution over the natural numbers and then ensure the inputs output balances conform to that statistical distribution.

Example:
Choose uniform distribution over the prime numbers less than 23
{2, 3, 5, 7, 11, 13, 17, 19}

- A wallet is a set of addresses.
- We store outputs associated with the addresses.
- The outputs have balances.
- We never use an address twice (deterministic address generation for infinite sequence of addresses).
- We store our wallet balance over multiple outputs, sampled from a statistical distribution chosen ahead of time

So we have 150 coins in a wallet stored over a number of outputs.
- We will send 50 coins to someone
- We will send 100 coins back to ourselves
- We pick numbers out of the statistical distribution until we get a set that adds up to 150 (our input balance)
- We split the setup into  a subset that sums to 50 and a subset that sums to 100 (if you cant do this, reroll)
- Each number in the subset that sums to 50, becomes an output that is sent to a separate unused address of the recipient
- Each number in the subset that sums to 100, becomes an output that is sent to a separate unused address, back to your wallet
- In practice, you would not spend all the outputs in the wallet

If you have N coins and are sending M coins. You want to sample uniformly from the set of arrays sampled from the distribution, who elements add to N and which can be split into two subsets that each add to N and N-M. There is a proper way of doing this, but its complicated (similar to proper way to shuffle an array, using permutation instead of random substitution for each element of array).

The key here, is that all information about which subset of the outputs is change and without are being sent to someone else, is eliminated. The distribution of outputs no longer depends upon user choice. However, if a user later spends two outputs from addresses in their wallet, in the same transaction, then we can link them as belonging to same wallet (which allows us to go back and gives information about the partition of outputs into the change addresses and the addresses of the recipient after the fact).

Therefore a practical system seems to require a CoinJoin type mixing at each stage and requires that the send is split over multiple transactions rather than all inputs and outputs created in a single transaction.

Summary:
- fix the distribution of output balance to a known probability distribution (eliminate information about which addresses are change)
- to do a send, send from N addresses to M addresses. N addresses to 1 address + change, like Bitcoin leaks information
- dont reuse addresses
- CoinJoin with mixing of addresses from multiple wallets as inputs for each transaction is required. Unless each transaction is 1 input and 1 output. Otherwise information is leaked that associates two addresses to the same wallet, by the fact those addresses appear as the owner of the inputs of the same transaction.

It is theoretically possible, if you work through the above, to get perfect level of privacy that cannot be improved, but in practice the requirements are too tedious. "Good enough" privacy means
- all the mixers form a single large mixer network (they mix together over each other over time) and that users have the option of mixing (default support for CoinJoin transactions)
- multiple input and multiple output addresses (unlike Bitcoin's single output address type sends)
- eliminating address reuse for default for transactions (working on this, similar to the above)

IPO Update

It done when its done. Fixing bugs.

- There was bug where OSX/linux treat files differently depending on whether the file name has uppercase/lower case letters that was affecting the webgui.
- Fixes to GUI/web wallet
- web wallet GUI did not report or show error on failure of send transaction
- There was bug where if you create a wallet, then close client and create another wallet, then close and reopen the second wallet will disappear (but only if you did this in the same day according to unix time), because the second wallet will have the same name as the first wallet because an uninitialized pseudorandom number generator was used to generate the random part of the wallet filename that is appended to the date. The wallet seed always used the secure random number generator, so did not affect security, but disappearing wallet bug was very disturbing.
- changed transaction hashes from double SHA256 to single SHA256 to be consistent with identifiers of other data objects
- JSON serialization/deserialization of transactions and outputs
- a couple of other things

I want to move on from coin debugging and get DHT implemented so the darknet and consensus algorithm running. Debugging and re-factoring is 10x slower than getting new code working.

I think the client is ready to start distributing coins. Running final checks and code review.

Update:

I reset the genesis block, so if you had a copy of the old blockchain and run it, you get error after updating. You have to delete the old blockchain. I forgot to mention this.

Pull repo

In "~/.skycoin" there are files

blockchain.bin <-- delete
blockchain.sigs <-- delete
blockchain.bin.bak <-- delete
blockchain.sigs.bak  <-- delete
peers.txt
blacklisted_peers.txt
wallets <-- this is where your wallets are

"rm blockchain*"

Delete the blockchain related files. Then run client and you will have new genesis block.

!!! Make sure to keep the "wallets" folder. Maybe back that up first

In the future, I think different blockchains will be in different sub directories by hash, but that is not implemented yet.

Development Update

Debugging makes me feel like Jesus dragging the crucifix through the desert.

Two days were wasted fixing a bug with where "req.ParseMultipartForm()" needed to be called instead of "req.ParseForm()" because URL get/post parameters were not showing up correctly in logs. The url was working in unit tests, but was broken in wallet gui and still trying to determine reason. As soon as this is fixed, will begin sending out test coins.

Then the transaction "readable" for human readable transaction format is broken. I had to spend four hours writing function for serializing binary transaction format to human readable JSON transaction format, so that a transaction can be converted to JSON and then back, without changing the SHA256 hash of the binary serialization of the transaction.

This is very important, because users of Bitcoin do not understand what a transaction is. They have never seen a Bitcoin transaction. Bitcoin transactions are not human readable. They are in some Forth like stack language that makes most C programmers wince. Skycoin transactions are simple enough that most users will be able to understand what they are and what they do. You can look at the transaction and visually see that it is correct. I think the average user will be able to create Skycoin transactions by hand if they need to and that it will help them understand what a balance actually is and what a transaction actually does.

The JSON serialization is important for tool, that generates transactions offline so they could be moved in human readable form from a cold computer to active node for "injection".  When we tried to move the genesis transaction for the IPO, we found out that the wallet readable serialization was completely broken... You cannot convert from a wallet readable back into a binary transaction with the same SHA256 hash as the original transaction. The function for injecting transactions into network from GET/POST request was also missing. That is in place now.

We did not realize this was not working, until we tried to move the genesis transaction from the cold computer.

The JSON serialization is also required for doing cron job to backup the transactions and balances in human readable format every hour, so they can be rolled over to a new chain or ledger if required. ASICminers was listed on three different stock exchanges and each exchange went under one after another. They were able to track ownership stakes through multiple shutdowns of the exchanges and contact investors and pay dividends. By having cron job and doing hourly backups of the transactions and balances, we can have contingency in place ensure that the balances are preserved if the coins need to be rolled over to a new ledger.

There is only one planned rollover in the future, but we want to be prepared if there is a severe attack that requires changes to the binary format of the blockchain that would require an emergency rollover. The transactions are exported from one ledger as JSON, imported into the new ledger and balances are same. The problem without the JSON format for transactions is that modifying the binary format of the blockchain breaks the block serialization format, so the old blocks cannot be loaded from disc. So the JSON standard makes it human readable, easy to run scripts on, future proofs it for import. This is part of emergency/contingency planning.

We also had to write bash scripts and generate a wallet deterministically using the Skycoin deterministic address/private key generator, insert the private keys into bitcoind, lock the wallet and then move that from cold store. SX was broken, which is what we were using before. Two days after bitcoind was working, we found out that SX is not longer being maintained was replaced by BX and that BX works.

bx tool from the lib-bitcoin/darkwallet team
- http://chimera.labs.oreilly.com/books/1234000001802/apd.html

SX was one of the inspirations for the Skycoin command line and JSON interface. Except that our interface is designed to be usable and instead of trying to do everything. BX is revolutionary because it allows you to do things that you cannot do with bitcoind, such as checking the balance of a bitcoin address without having the address private key in your wallet.

That is the state that Bitcoin is five years after launch. It is still impossible to query the balance of an address without a third party utility, using blockchain.net or having the address in your wallet.

Bitmessage Problems:

Some users are reporting that Bitmessage is not syncing and they are not getting message confirmations. We had the same problem in testing. We attempted to connect to Bitmessage and it depended on which country we connected to network from. If you connected to Bitmessage through server exiting in particular countries from clean state, we were later unable to sync all the messages, unless we deleted the node/peer lists from the bitmessage data directory. Without deleting the peer list in the data directory, message syncing failed even if connecting through another country.

This could be a bit of unluck or could indicate something else (sybil attack? slow nodes?).

We think Bitmessage is working good enough (we tried everything else and its worse), but that will affect some users.

IPO Update:

I have not sent out receipts or test coins yet.

The messages are being processed by hand. If instructions were too long, just
- install Bitmessage
- send message to BM-2cU8XJp3GPVQG75ZwMjiyzdDEa9eD4B7iM
- include how many Skycoin you want. At 10 cents per Skycoin. You will get receipt back.
- send contact information and a bitcoin address in case we need to return coins
- send us a Skycoin address where you want the coins

You will receive receipt
- There should be some test coins in your address
- send bitcoin for receipt and rest of coins will show up



You should include email or bitcoin talks, qq-chat or other identity information in case we have to contact you. You must send us a Bitcoin address we can send bitcoin back to if we need to.

Preferred Format:

```
contact: bitcointalks:rockhill
bitcoin_addr:113n1hdJFN7R61fMncQr14TmnbcVQ7cBgP
skycoin_addr: ZWhZtjwXMS46cpDxfRwQyxxKPhqwsQu8oN
coins_requested: 9600

good luck!
```

This is an example message that is good. You can include a message below the IPO request.

Good Article on Bitcoin:

This is the Council on Foreign Relations publication. It generally predicts five to twenty years out institutional changes and what is on the horizon before it happens. The topics addressed are issues of concern to the CFR and not necessarily reflect official position or consensus among the elite, but .

http://www.foreignaffairs.com/articles/143162/paul-vigna-and-michael-j-casey/bitcoin-for-the-unbanked

There is a clear split. The central banks dont like Bitcoin, the tax authorities are neutral because it is so heavily centralized on Coinbase and Bitpay that it can be taxed automatically. The income is "matchable" if it goes through bitpay/coinbase.

The upper tiers support Bitcoin and vaguely hope it may be able to reign in the FED or generally believe it will promote justice in the world. They see banks seizing houses they dont own and selling them without even pretense. They understand the FED and financial sector group is too powerful to be restrained by law. During the "financial crisis" they grabbed a company with 100 billion dollars in assets and forced into insolvency using a government regulator, on a rumor they caused and then "sold" the company to themselves for 2 billion dollars. This is literally "You dont own that" and they grab your property and give it to themselves. They cannot be restrained by law or government. They are government, it is the same group of people under different badges and titles. Or they grab trillion of dollars from county and give it to themselves, creating a debt that needs to be tax farmed from the public.

There is a sincere intention that technologies like Bitcoin may get the poor or anyone with a cell phone onto the global financial system. Many people will have Bitcoin, cell phones and internet before they get electricity or running water. The real politik is that Bitcoin may evolve into something that can impose some discipline on governments and reign in the FED.

There is a split between the interests. The people at the top want to continue the current system at the international level and the people below it want it abolished or dont understand it. The top level banks have determined that Bitcoin is immature and that is not viable and does not pose a threat to their powers. It doesnt allow the slaves to escape the plantation. They believe Bitcoin should be studied carefully but is not significant in its implications to their current operations.

Bitcoin is really a war of the 1% against the 0.00001%.

Research Update:


Homomorphic secret sharing

I think we now have homomorphic secret sharing for for secp256k1. This means that Skycoin can do multisig transactions without having an explicit multisig transaction. Multisig transactions happen outside of the blockchain are not a different transaction type than non-multisig transactions. There is no way to tell them apart on the blockchain.

Background
- there is a basepoint b on the curve
- there is a group operation that takes two points on the curve and generates a new point on the curve
- you apply the base point to itself N times as the operation (exponention of the base point in the curve)
- You choose a random 256 bit integer, N. This is your private key. Your public key is the base point raised to the power of N

You have two people
- one generates a private key N and public key P
- the other generates a private key M and public key Q
- They exchange public keys. Each other raises the other's public key to the power of their private key
- They both arrive at the same public key
- They hash the public key to generate an address

This is implemented in the cipher module as cipher.ECDH(seckey, pubkey)

That is the multisig address. The coins at that address can only be spent if one of the parties obtains both the private keys.

So for A to send coins to B, then A discloses the private key N to B. Now B can spend the coins but A cannot. So B owns the coins. The coins have been transferred, without the "transaction" being on the blockchain or the address even have been changed. B can now move those coins.

The question is whether one of the parties can choose a "weak" private key that allows exploitation (faking a signature or allows the private key of the other party to be easily calculated). It has to be proven, that if a weak key can be found that allows signatures to be faked or the private key recovered, that it allows the solution to the discrete logarithm problem on the curve.

For instance, if someone chooses a small private key, then they can recover the other persons key if it is possible to do square roots over the elliptic curve operation. However, the square root operation appears to be equivalent to solving the discrete logarithm problem (however, not certain).

Continuous Settlement and Clearing

We still need explicit multi-sig with timeout eventually, for exchange infrastructure and settlement. This allows an infinite steam of micropayments of potentially millions of payments, with only a single transaction appearing on the blockchain.
- A puts coins in multisig output with signatures from A and B required to spend
- the output becomes spendable by A alone after a week (to prevent coins from being held hostage)
- A and B settle every minute (millionths of a coin) and create a valid multisig transaction with the updated balance, paid from the coins A put into the output. However, the transaction is not published to the blockchain until very end
- If B disappears, then A will get their coins back after the lockup period. B cannot steal the coins without signature or private key from A.
- A cannot double spend the coins to another address without B
- we may need to place a "max time" property or ensure that earlier transactions do not settle before the largest transaction if the whole transaction stream is published.
- B loses coins if an earlier transaction from the stream is published, so A will be attacker. If there is a max time that each transaction can be published and is valid, theft is limited, but A can get their coins back if they knock B off network so window expires. Then B will be unable to execute the spend transaction. There are a series of problems here that make this not simple.

This allows continuous settlement and clearing between peers, without going through blockchain at all, until the transaction is finally published and executed. This is the cornerstone a decentralized exchange infrastructure.

Skycoin settles in a second anyways, so this is more useful for Bitcoin. It is technical curiosity and I am not sure how useful it will be. It is definitely useful for Bitcoin because of longer block time, but does not seem to add anything to Skycoin and only increases the technical complexity.

Minimalist Protocol

The simplest protocol, uses the 2 of 2 homomorphic ECC multi-sig in the first part, with a timeout that allows an output to be spendable without a signature, but only to a specific address. This is a standard transaction with a timeout, that allows it to be spendable to particular address after certain time, if it has not otherwise been spent.

On balance, I still have not found a use-case where the complexity, security and attack problems from a scripting language are balanced out with something more than 1% of users will ever use.

I would like to remind everyone, that the wallet seed "steal my coins" generates address "tBagH6WKM1o9MVhw9pvNhnbP1h1gAfbigf". So if you would like your vanity address to be tBag, use that wallet seed and the private key is "3ed08cdafcabfcf1b3d335311a38fe671987bd54f8b5c5d9ead5108f721a8770"



A small server with 100 AMD GPUs can brute force 1 trillion passwords per second.
- 16 bits of entropy = 0.0000006 seconds to steal all coins secured with a password with 16 bits of entropy
- 32 bits of entropy = 0.0042949 seconds to steal all coins secured with 32 bits of entropy
- 48 bits of entropy = 281 seconds to steal all coins secured with 48 bits of entropy
- 64 bits of entropy  = 18,000,000 seconds to steal all coins secured with 64 bits of entropy
- 128 bits of entropy = 34,000,000,000,000,000,000 years to brute force at 1 trillion hashes/second
- 256 bits of entropy = 34,000,000,000,000,000,000 years squared, to brute force at 1 trillion hashes/second

Wallet seed security guidelines:

numbers only password
-3.3 bits per character
 
lower case letters and numbers
- 5.2 bits per character

lower and upper case letters and numbers
- 5.9 bits per character

lower,upper case letters, numbers and symbols
- 6.2 bits per character

So a 10 digit number will have 3.3*10 bits = 33 bits of entropy. That password will be cracked in 0.0004 seconds and your coins will be looted.

You think your wallet password is secure. Someone has a GPU cluster than can break that password. So once they get the wallet file, its over. If they are able to get your wallet file, it probably means you have key logger on your computer, so they just have to wait anyways.

We are assuming worst case. This is for using md5 for hashing. The Skycoin deterministic wallet generation function uses SHA256 and elliptic curve multiplication operations, so is ten thousand to 1 million times slower. A top end Intel i7 can do about 1,000 to 8,000 passwords/second. So instead of taking 281 seconds, it actually takes atleast 281 thousand seconds to steal coins if your seed has 48 bits of entropy.

64 bits is minimum that is secure. 128 is minimum recommended. Skycoin uses 256 bit by default.

Human generated passwords are not secure either. They are not random. The theoretical entropy is higher than the actual entropy achieved in practice.

We will switch to word based 128 bit pass phrases from word, that are machine generated, like Electrum uses. It is dangerous to allow users to choose their own passwords, but we allow this. Just make sure not to shoot yourself in the foot. It is safer to let the machine generate the seed for you.

However, if you copy the seed into a clipboard then it can be stolen by trojan on computer. If you type the seed, it can be stolen by key logger or by radio emissions from your keyboard. Using an onscreen keyboard is safer.

Hardware Key Storage Device:

For generating and loading keys on to a hardware key storage devices, we will need to fund open source hardware keypad. Could be $10 to $30.  A hardware key storage device can be as simple as a $1 ARM processor on a PCB board.

This is a $1 ARM processor, 32 bit, 50 Mhz, 16 Kb of flash memory. Just enough for a program and a few private keys. The cost is $1.15 to manufacture. The PCB board is $0.10, the other components are less than a penny each and total unit will cost $0.30 within two years and the 500 Mhz ARM processors will be $1 soon.



If you want to add an LCD screen, then it costs $4. If you want an LCD screen, a key pad and ability to connect to internet over GSM using a SIM card, then its $12. This is what we will be carrying our coins around on 48 months from now.

The level of security this provides is absolute. Coins cannot be stolen, even if your operating system is infected on every level.

Obama Coins:

If you cannot protect your coins "You dont own that".

We need to work towards good default security. Coins can be a pass-phrase on a piece of paper in a wallet, a string of words that can be memorized. They can be transmitted across borders in a few bits in seconds. They cannot be seized. No one can even prove they exist. They can be sub-divided infinitely and used as easily to buy a candy bar as a multi-million dollar business transaction.

They offer a level of security and convenience not possible with gold
- gold can be physically seized during war, civil unrest or by broke governments
- 10 tons of gold bars are heavy. You find out your house was built on a swamp and your neighbors notice your house is sinking into ground unevenly from the weight.
- moving 10 tons of gold bars across the border is frustrating
- selling 10 tons of gold is problematic
- selling 10 tons of gold discretely will require taking a haircut. You risk seizure or theft even attempting this.
- even if gold is stored securely overseas, it can be stolen by the custodian without the owner having legal recourse. The thefts in offshore centers make MtGox and Madoff look insignificant.  
- 12.4 kg gold bars are difficult to sub-divide for small transactions
- gold is heavly tracked and the government knows whose door to knock down when it is having budget problems
- Gold shows up as a completely black, dense, blackhole on xray scanners. Broke countries are setting up xray scanners at all travel choke points, airports, border crossing, scanning every shipping container in order to grab any gold leaving or entering the country. America is even developing vans with xray machines, which are useless for detecting cash or drugs and can only be used to to detect people transporting either guns or gold. We are already seeing governments seizing properly left and right and selling it without trial or legal pretense.
- DARPA is developing drone and vehicle mounted radar technology with radar that penetrates concrete, rock, walls and can look into home locate gold to enable seizure by broke governments. The same technology being developed to locate guns and disarm insurgencies overseas will be turned against citizens when the budget crisis hits.
- no one knows how much gold exists or if future technological advances will increase supply in future

Crypto-Coins
- weigh nothing
- cannot be seized if proper security is take
- can be taken across borders as a memorized phrase or incantations on a piece of paper
- are infinitely divisible from millions of dollars down to grocery shopping
- can move across borders with greater speed and lower fees than wire transfers
- can effortlessly move across borders
- do not show up on FEMA xray vans
- the total number of coins is fixed by mathematics and cannot increase in the future

So I think crypto-coins will clearly replace gold and other assets in the future. The advantages are one sided.

That wont happen until the default (the easiest way) is immune to having coins stolen. We need to make holding coins more secure than hoarding gold in a basement. We are 70% of the way there.

Yes. We are also concerned about "Default Security". For average user.

Here is an example. Many people want "vanity addresses". Third party services generate the addresses, then you import the private key. They store the private key, wait until you have a bunch of coins and then steal some of them! Users think it was trojan or they dont even know how the coins were stolen. To protect against that, we have to make sure vanity address gen is client side and integrated into the skycoin wallet. We have to make sure that the default way is the easiest way and that it is secure, for every single action that can result in coins being stolen or lost.

Normally, when a vanity address theft happens, they only steal a fraction of the coins. The user wonder why they stole only a few and not every coin. If they had a trojan, why would someone steal a few coins when they could steal them all? The user is confused. It is because if they did transactions, then some of the coins are in the vanity address and some of the coins are in change addresses. The thief is the 3-rd party who generated the vanity address and they only have the private key for that address (which only has fraction of the keys in the wallet).

A theft of a few coins, but not whole wallet can also occur when private keys are generated with a weak random number generator. Bitcoin was using OpenSSL and we are finding many many bugs in OpenSSL and many system random number generators are being discovered to be weak. So we are not using OpenSSL and we made sure Skycoin salts the key generation wont be compromised even if the random number generator is faulty. We are improving that even further in future with using SHA3 to accumulate entropy every random number call.

I could write a 200 page book about every way that Bitcoin has been lost or stolen. We have to make hundreds of small, incremental changes over time.

We have multiple wallets in Skycoin, because we have seen people delete wallets with bitcoin in them, because we had to swap out wallets. Its easy to overwrite a wallet with coins in it and panic. So we tried to make it easy to have multiple wallets loaded in Skycoin and make it easy to backup the wallets (a simple seed or pass phrase).

We have deterministic wallets and only deterministic wallets as the default, because we have seen people lose coins unexpectedly by loading a wallet from backup after making transactions, because backups do not contain the newly generated change addresses! Bitcoind generates new change addresses after every transaction, which bitcoin are sent to. So if you restore a wallet from backup, you may be missing coins. This also means in Bitcoin, if you have two thumb drives with the same wallet on them and do transactions on each, they will end up with difference coin balances! Each wallet will have different change addresses after being used for a while!  

Skycoin doesn't do this at all, because it would mean unexpected behavior and people would lose coins. We made sure that the default behavior is exactly what users expect and that the defaults dont result in people losing coins.

There are so many ways to lose coins in Bitcoin, that addressing every situation is overwhelming. We need to hire contractors to work on each little detail (vanity gen in wallet, locking/unlocking wallets, default on screen keyboard), because we will go mad otherwise. I think we have covered 90% of the causes of coin theft than the user could not control.

We will add a password feature on wallet, but it is a false sense of security. It will stop someone from passively grabbing the wallet, but if they have a key logger, they will get the password. It does make it more difficult (grab file + keylogger). If you use an on-screen keyboard, then it makes it painful. It would put wallet theft beyond skill level of most script kiddies.

The average user will lose more coins from unexpected behavior, than security. We have almost eliminated unexpected behavior. Exchanges are where we need enough software and hardware security to protect against government level infosec/hacker firms.

>Wallet Seed Security

We recommend creating a new wallet from scratch and using a strong password. Anything less than 12 characters will get brute forced. Some GPUs can brute force 2,600,000,000 passwords per second and anything less than 12 characters will get broken eventually (but is safe for small balances). Hackers combine very fast hash rates (trillions of passwords per second) with rainbow tables. So generally, most passwords comely used can be brute forced.

Lowercase 10 letters/numbers: 51.7 BoE (bits of entropy)
5 common words (2000 word dictionary): 54.8 BoE
Mixed case 10 letters/numbers: 59.5 BoE
6 common words (2000 word dictionary): 65.8 BoE
Lower case 13 letters/numbers: 67.2 BoE
Mixed case 13 letters/numbers: 77.4 BoE
12 common words +120 BoE

Brute forcing all wallets with 64 bits of entropy is doable in four years. Electrum pass phrases are 128 bits of entropy and this is minimum. Skycoin should adapt the electrum pass phrase model with 8 to 12 random words from dictionary. This is easier to write down than the hex. It is harder to screw up.

If you need security, we recommend using a SHA256 hash as the seed. Or take a decent password, then add your phone number after it or birthdate. Something you will remember and that an attacker wont know usually.

>How to get wallet seed

This is a very good question!

Look at the interface, see "import from seed button". This lets you type in a need seed/passphrase and generate a wallet



New Wallet: creates a new wallet, with a random pass phrase (also called a seed)

Import Wallet From Seed: Lets you generate a wallet from a pass phrase you choose (Which becomes the seed that generates the wallet)

In the web-wallet, add /wallets to the URL and you can see your wallets and copy down the seed.

Remote Wallet Example:

This is a remote wallet. Its public, so dont inport your wallet seed here. This is for publicly checking balances and demonstration.

http://skycoin-chompyz.c9.io/

These are the "outputs". This is where coins are stored. You can check balance here.

http://skycoin-chompyz.c9.io/outputs

If you open your wallet through the web interface and do "/wallet", you get the list of wallets. As long as you have written down "seed", then you cannot lose your coins.

http://skycoin-chompyz.c9.io/wallets

Try creating a wallet with a seed (import wallet from seed), then close the client, delete the wallet, then go and reimport the wallet from the seed. Make sure you get the same address and private key the second time.

IPO Status

We have not started sending out confirmation receipts yet. We finished the remote server, so people can check balances.

http://skycoin-chompyz.c9.io/outputs

We also triple tested deterministic bitcoin privatekey and address generation from Skycoin. We are sure this is working now. So we can generate a unique address for each receipt in the IPO.

We will have a bitcoin wrapper over sx, when the darkwallet team makes that stable and then can store bitcoin in Skycoin wallets. Also allows libraries for making it easier to deal with a good library without having to go through bitcoind. This will make developers happy.

> OSX issue:

There is a problem with the wget flags in the gvm script. It appears to affect mingw and some versions of OSX. You may need to look up the gvm instructions for installing go, do that (and maybe fix script and do pull request). We tested it on OSX and it worked for us.

>Even if I delete them now or store them in TrueCrypt or USB-Stick, it could be already stolen.

I think we might change the Skycoin wallet storage directory, to be subfolder of the exe. So it is easier to find. Then you can just put skycoin exe and wallets on a USB stick. In Bitcoin, many users cannot find their wallets at all and it can be difficult.

IPO START

Chinese new year is done. I think everyone is back from vacation now. So we can start IPO.

IPO Instructions:

Install Bitmessage:

Send message to: BM-2cU8XJp3GPVQG75ZwMjiyzdDEa9eD4B7iM

with

===
{
   contact: "bitcointalks: username, github:username, email:user@domain.com",
  
   bitcoin_addr: "bitcoin_address",
   skycoin_addr: "skycoin address or seed",
   coins_requested: "1000"
}
===

Then you can put note or any text below that. You can put anything in the name field. You can leave it empty. You can put email, bitmessage or bitcointalks username.

example "github:myaccount, twitter:myaccount"

This is for contacting you if there is a problem.

The bitcoin_addr, should be an address that goes to your wallet. This is for returning bitcoins if there is a problem with the IPO. This is where bitcoin will be sent back to if there is a problem.

skycoin_addr is a skycoin address. If you put in a string like "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08". Then that will be the deterministic key for generating the wallet. Otherwise we will send them to skycoin address given. Make sure you write this down! Only use ASCII characters.For security if you give us a seed, we are converting it to a wallet address and nuking the passphrase, so the private key cannot be recovered in future.

coins_requested is number of skycoin your are asking for.
- We will send test coins to make sure you receiving address works. Do not send Bitcoin unless you have confirmed address works
- We will try to run web-server so you can see balances
- The IPO price will be 0.10 USD per Skycoin, at a fixed Bitcoin price of 240 USD/BTC. So 2400 SKY per BTC.
- We will start with 1 million SKY (1% of total) and then release more over time (between 2% and 10%), once we are sure everything is working.

You will receive a receipt in the form of

===
{
  bitcoin_send_address:"<bitcoin_addr>
  bitcoin_amount": <number>

  bitcoin_return_address:"<bitcoin_addr>,
  skycoin_addr:"<skycoin_addr>,
  skycoin_amount: "<number>",
}
===
{
  hash: "<hash of receipt>,
  pubkey: "03f13f397a0a8d8840525c1b5c70eb21c8d49acb63cfa0d7225e57075ff4ec9e8a",
  signature: "<signature>.
}
===

The receipt tells you where to send the Bitcoin. SAVE THE RECEIPT. If there is a problem, you can publish the receipt and any third party can verify that we we sent the coins and can publicly verify how many skycoin were sent to the address, how many bitcoin were sent and returned. Anyone can validate the signature to know that it came from our server.

IPO Tranches

2% of coins (2 million SKY, out of 100 million SKY. ~800 BTC ) will be sold on a first come first serve basis through Bitmessage.

1% of coins (1 million SKY, out of 100 million SKY. ~400 BTC) will be reserved at the IPO price for pool of Bitcoin usernames who have posted on this thread before this post.
- If there are 1000 users who posted to thread then, each account will be eligible to buy up to 1000 SKY each at IPO price
- window will be ~3 months

We will pay someone on odesk to scrape the forum, grab user names on this thread, put them into spreadsheet, generate code/coupon for each user. Then they message us for coupon, or we can send out the coupons en-mass.

Trading Bot:

Skycoin wallets can now generate Bitcoin addresses. This means that we can have a BTC/SKY tox trading bot
- the bot will not hold any long term coin balances, but the coins will stay in your wallet instead of being stored on a remote server until they are stolen
- this bot may be illegal for you to use if you live in New York. You should apply for Bitlicense approval, hire a lawyer and contact your politician before using any exchange service. Only Coinbase coins are legal coins. We are not responsible for government seizure of illegal coins that have not been registered with government. This is direction the wind blows
- exchange service will be run by trusted third party who meets security requirements
- Bots for LTC and Doge and other other secp256k1 coins can be added later
- Bot will be open source

With Skycoin we want to move away from central exchanges and thefts and move the private keys to the user's computer. Exchanges can be useful for buying/selling, but they should not be holding long term balances.

This bot is the first step towards a distributed exchange architecture and towards distributed systems for smoothing price volatility.

Generating Addresses

Generating Skycoin Addresses:



Generating Bitcoin Addresses, add -b to command line



We want a linux environment that windows users can just double click and run Skycoin from source. That does not exist yet, but something we will work towards. Usermode linux is coming close. This would also create an isolated virtual machine, that prevents people from stealing coins or bitcoin wallets outside of the virtual machine.

IPO technical note: State of Computing in 2015

We tried to use TOX. Had problems with NaCl library missing from debian, so toxcore would not work within docker container in VM. Spent six hours on this. Not spending more time on it.  Bitmessage was under attack with 10 GB/s spam attack last time and was not working. Bitmessage appears to be working again, so we will use that.

We had difficulty syncing Bitmessage and the network may be under attack. If Bitmessage is not working, then we will need to find another communication method. Based on our experience, every system for secure communication that exists is being actively targeted for disruption of service.

Software barely works in 2015. Key crypto packages like NaCl and toxcore have had deb packages for a year but are still not in debian and do not have alternative repositories. Golang dependency and path management is nowhere as easy or reproducible as it is in python right now. Debian packages do not have deterministic builds, so we cannot be assured there are not back doors in the package binaries that are not present in the source.

The state of computer security right now is very bad. This is a bug in PHP. If you send a server a timestamp or date field, it parses it and takes over the server. Or allows private keys to be read out.
- https://github.com/80vul/phpcodz/blob/master/research/pch-020.md

This bug was released yesterday. This is very similar to the types of exploits that would be used to attack Silk Road and identify the services. There are hundreds of bugs like this. Some of them are intentional. Many of these exploits are in the wild for a decade before they are found. These bugs allow bitcoin exchanges and servers running websites like Silk Road to be hacked.

Skycoin is using Golang instead of PHP (MtGox) or C++ (like Bitcoin), so we can guarantee that there are no buffer overflows that will allow computer to be hijacked from the Skycoin client (unlike Bitcoin). At best, an attacker will be able to crash the Skycoin client.

There is no guarantee that there is not an unknown exploit in the Bitcoin client or library dependencies that would allow remote hijacking of the client and theft of Bitcoin from all active Bitcoin clients. The recent vulnerability in the glibc library that allows remote code execution from DNS resolutions, that escaped all protections on remote code execution is evidence that all the standard libraries are backdoored (intentionally or unintentionally) and that achieving security will require fundamental changes to toolchains, compilers and operating systems and not just the patching of individual exploits.

The vulnerabilities found, just in glibc are very worrying.
- http://www.intelligentexploit.com/search-results.html?search=GLib

Bitcoin uses OpenSSL which has daily security exploits. Skycoin has its own cryptography library that wraps a small C library by sipa. The Skycoin cryptography library is on the 3rd generation and the 4th generation library has been commissioned. For 4th generation we want to get cryptography completely into Golang  for cross compilation and have a common cryptography core across all the major coins (Bitcoin, Dogecoin, Litecoin, Skycoin). The 5th generation will focus on native support for open source key storage and signing devices.

In Bitcoin the node and the wallet are a single piece of software that cannot be separated out. If the node is successfully attacked over the network, then the wallet private keys will be gone and all coins will be lost. In Skycoin, the node is designed to be separated out and communicate with the node over a JSON interface fire-walling the public network from private key storage.

We cant protect against web-browsers, Java or security vulnerabilities in the operating system. There was recently an exploit in firefox, that would allow your computer to be hijacked through javascript. You merely needed to click a link and a buffer overflow exploit was triggered in an XML parsing library that Firefox used as a dependency.

Skycoin uses a web-browser (local web-client). By default Google Chome saves everything you type into fields and sends it to a remote server to be saved (form autocomplete). So we had to package our own version of Chrome and V8 into the Skycoin repo. This is working, but is only so-so. That is what the ./gui.sh script is.

I think in future will we will see private contracts that do 90% of NSA hacking, looting random computers for coins with the thousand upon thousands of security vulnerabilities. They will do this just because it makes money. As coin adaption increases and becomes serious money, the level of hacking will accelerate beyond anything we have seen before. The attacks we have seen so far are amateur level.

Fixing every bug in every piece of software used is impossible. The best we can do is
- standardizing a subset of LLVM IR as a CIL and achieving platform independent deterministic builds at the compilation unit
- compilers that enforce memory safety  (to rule out buffer read overruns and remote code execution attacks)
- CPU architectures and compilers that enforce memory safety
- compartmentalizing the applications
- funding low cost open source hardware wallets and doing computations on external CPUs connected over USB
- ARA like hardware and standardization of hardware specifications to achieve security.
- pushing as much of kernel and standards library into user space as possible.
- pushing the network, graphics and sound stack into user space
- pushing POSIX and the gnu standard library into user space. See: http://www.intelligentexploit.com/search-results.html?search=GLib

CoreOS, Docker and LLVM are bringing us much closer to these goals. We will not need to implement everything from scratch. It will however be a very expensive process, taking years. We are realistically look at a cost $4 to $15 million dollars over five years and seven dozen small, high intensity six month projects that can be completely by one to three developers.

This is an open-source computer on a USB thumb stick. USB Armory. 800 Mhz Arm processor, 512 MB of ram



https://www.crowdsupply.com/inverse-path/usb-armory

We may be able to get this down to $10 and then move all the cryptographic and key storage operations to this. Locking down the coins and making cryptocoins safe for average user will be a long journey.

Research Note

I do not want to announce anything prematurely, but it may be possible to use VerSum to lock out 51% attacks completely at overkill level. http://people.csail.mit.edu/nickolai/papers/vandenhooff-versum.pdf

Previously we had designed a check pointing system and it appeared to not introduce any edge cases that were exploitable. Instead of doing distributed checkpoints on the program state every few hours or ten thousand blocks, this pushes the check points down to incremental block by block level.

This means some hashes we were intending to put in the block header are redundant and should be pushed to the block wrapper. There are several possible uses for VerSum type block by block incremental checkpoints.

Skycoin recovers from an attack on the network by identification of the attacking nodes and users collectively kicking them off or marginalizing the influence of the attacking nodes. The kicking of bad nodes off the network can be done by hand or it can be automated if it can be done safety. This incremental checkpointing system even if it is not used to prevent attacks that would revert previously executed transactions, may be useful for automatically identifying the bad nodes.

This has to be worked through very carefully to ensure that it would not introduce any edge cases, so will be something we look at for the second generation consensus algorithm implementation. I dont think there is time to fit into this iteration.

I think the existing Skycoin consensus design is 51% attack proof, because the number of nodes required for performing the attack is much larger than the number of mining pools that need to collude and if it occurred, the chain would just fork and run both chains until they were pruned by hand and the bad nodes are kicked off by hand. So it is not clear what the economic incentive for a 51% attack in Skycoin, or why anyone would attempt it. Its more annoying than anything else.

The most important property is that the network quickly recovers and survives. In Bitcoin if someone attacks the network once, they still have enough hashing power to repeatedly attack the network over and over and over again. In Skycoin, the attacker spends a large amount of time building up the trust relationships, then they attack (which may succeed or may fail) then they get their ass kicked off network.

The number of nodes that need to collude to successfully attack is at least the top 2% of the nodes (absolute worst case). With 10,000 nodes in the network, that means 200 people need to collude to merely attempt an attack. In Bitcoin, only the top two or three mining pools need to collude to attack the network.

In Skycoin, even if they succeed in attacking the network, one approach merely forks the network into two concurrent branches and it is resolved by hand, by individual node operators. Attackers branch just gets pruned. This is one technique we are evaluating for second generation Skycoin consensus. The network should never get to the point where this needs to be used.

The ability to survive the very worst attack and keep the ledger running, is very important. We call this "survivability". In Bitcoin a successful attack, would send price down and mining equipment would be shutoff and the next attack would require even less hashing power. So a 51% attack could be a death spiral for Bitcoin, like it has been for other altcoins based upon Bitcoin. In Skycoin the network security does not depend on the coin price and the network quickly continues operation after an attack that would destroy any existing PoW coin.

The second generation Skycoin consensus implementation will not be a change to the consensus algorithm itself, but automating the detection of bad node behavior and trust revocation, to marginalize the bad nodes automatically. I can see a use for the continuous distributed check-pointing system for this purpose. What is also interesting, is that some of these defense and detection systems are independent and can be layered on top of each other.

If the continuous check pointing system works, the number of nodes for a secure network could be reduced to 10 or 15 for an open network that anyone can join. For a closed network, for a central bank running a private ledger on secure hardware we think 3 to 5 nodes in a fully connected topology is sufficient for a secure network, with a sufficient level of redundancy.

Consensus/Ledger Topologies: bank control vs public control

There are different topologies and they have different use cases and security concerns
- single server, with no replication (centralized, SQL database)
- master server, with peer-to-peer slave replication (where we are now)
- peer-to-peer consensus in closed network, with peer-to-peer slave replication (central bank, bank running assets on a private ledger for internal or for customer use. Ripple. Skycoin ledger running on closed network)
- peer-to-peer consensus in open network, with peer-to-peer replication (Bitcoin, where we will be at version 1.0)

The danger is that if we dont solve the last problem, that we will have Bitcoin like systems, but they will be controlled by the banks and not the public. The third topology is a special case of the forth and the security problems are easier. If we have last problem solved, then we we end up with a hybrid system inter-operable of closed an open consensus networks on the same code base.

If the solutions are only extended to the third case, then the banks control the ledgers and can still impose transactions fees as gate keepers and can still charge merchants chargeback fees involuntarily and can still add involuntary debits and fees to customer accounts, such as overdraft fees. That is where the industry is being herded right now and why the consensus problem in open networks needs to be solved. Bitcoin in its current form will be obsolete as soon as those systems are in place, but the system will have been recentralized with banks as the gate keeper.

You might have a banks with ten branches and they each branch runs two servers and all the servers on are a closed consensus network and use the ledger for clearing between the branches and for customers to move digitized assets. So you have a network where there are twenty computers (bank computers) that can create new blocks and determine network consensus. All blocks and transactions are replicated peer-to-peer and there may be 200 computers, but most of them are slaves that replicate transactions/blocks over same system and network and have same internals but are not influencing the network consensus at all.

There are hybrid topologies between the full crypto with peer-to-peer replication and the legacy SQL finantial ledgers. For instance, where the block introduction servers are "closed" and there might be five servers and one of them is a master and there is paxos for fall over and leadership election, but the blockchain/ledger is also replicated peer-to-peer to nodes outside of the closed network (slaves instances, maybe on customer premise).

Then there are fully peer-to-peer systems like Open Transactions, that do not have a central ledger or need replication. We believe that the Bitcoin triple entry accounting has won and that the SQL-master-slave double entry model will die out in mainstream use.

So Skycoin is only concerned with that case. It is also the most difficult case. The Bitlicense requirements put heavy tolls on the decentralized variants like Bitcoin, while exempting gift cards and all use of blockchain technology outside of the walled garden. So blockchain traded gift cards will be completely unregulated, blockchain traded bank products with be completely unregulated, but Bitcoin and other coins will be completely locked down. Coinbase will be required by law to seize coins that are "tainted" because they were sent from an address not registered under the KYC standards.

This is really a question about whether we end up with the Bitcoin technology in a walled garden, with gate keepers or whether it remains decentralized.

You Websters dictionary is obsolete. Protocol federalization has nothing to do with government federation.

Protocols can be
- centralized (single privileged entity; AIM, Facebook Chat)
- federated (choice of privileged entities; XMPP, Email)
- decentralized (no privileged peers; tox, bitmessage)

Decentralization is not always superior to federation.

- Bitorrent has decentralization at the download/swarm level, but meta-data and search (torrent file) is federated (Piratebay, Demonoid).
- Kazaa had decentralized download/swarm, but decentralized search/metadata and was inferior to bitorrent because it lacked curation
- Napster had centralized download/swarm and centralized search/metadata and so was not survivable against legal threats.

- FTP has centralized metadata and has centralized download but federated servers (federated service identity, where as napster and kazaa had centralized service identity).
- DC++ had federated service identity (Hubs instead of a single global network) with a mixture of federation, decentralization and centralization within the hub

When developing Skywire, I examined every internet and communication protocol that has existed since the beginning of human history and defined the attribute matrices on every relevant attribute pair, that defines the set of attributes of all possible protocols that do not require the creation of new protocol attribute types. My communication protocol attribute ontology is almost machine readable.

There is only a very small set of protocols used and they fall into a very small set. Storage, communication, computation and identifiers. Bitorrent is storage and communication. Email is communication.  Ethereum has aspects of storage and computation.

There is a rough, undefined category for "transaction" where data is distributed across multiple points and you need to know if you have the latest data and to control access and modification of data where there are multiple conflicting writes. Bitcoin, NoSql, Paxos, all database and distributed systems are primitive, complicated and barely working attempts at a solution to this problem. The problem of Bitcoin and avoiding double spending, is the same problem as determining if another database node has written over a piece of data and determining if you have the latest version. It is the same problem.

You can build databases on Bitcoin like systems, where the transactions operate on the state of the database. They are functions that map the database from its existing state to a new state. Centralized ledgers slow it down and destroy advantages of decentralization so you get rid of that and each node only had local information or a subset of the data on the network.

All of these protocols are just part of or implementations of a more general abstract, mathematical system. There is a lisp or mathematical kernel for distributed computing. Bitcoin and NoSql was just a stepping stone, a dissatisfaction with the existing technology, moving us towards a more perfect system with greater power and elegance and less complexity.

There are several systems moving in that direction
- Skycoin
- Urbit
- Ver (programs and data as hashes)
- Docker, CoreOS (containization)
- Ara (granularity, modularity, fungibility at the physical hardware level)
- Etheurem (ledger+computation as a service)
- Cloud computing (computation as a service)
- StoreJ, Dropbox (storage as a service)
- Skywire (communication as a service)
- NoSql distributed database based databases based upon Bitcoin, but without a global blockchain. Transactions become atomic operations on the state of the database. Double-spending becomes resolving two writes to the same people of data by two different nodes in the distributed system.

All of these systems will be unified. I can already see that. There is no natural border between the technology stacks. Everything that exists will be replaced. However, there is no way to make money on this as a corporation trying to own the stack, anymore than Microsoft can monetize people open files and saving them to disc. People will make a ridiculous amount of money in this ecosystem, but it wont be on a feudal corporate model, like we are seeing with Bitcoin today (Coinbase, Bitpay, ...).The infrastructure will be open source and most of money will be going to the service operators.

> decentralized consensus is impossible

And yes, you are correct. "decentralized consensus" is impossible. You can prove it mathematically. There is no way to do it that is no sybil attack proof or resource intensive. Federation is superior than decentralization for a secure protocol, for the simple fact that a secure decentralized protocol that is not resource intensive is mathematically impossible. If you relax the requirement for global consensus then this might not be true anymore, but for Bitcoin like currencies with a global ledger it is a mathematical certainty that no such algorithm exists.

PoS is a type of federation, where consensus is delegated according to ownership stakes of the assets being transacted on the ledger consensus is being performed on. PoS still has the same communication attack service vulnerabilities as Bitcoin.

Four years ago, we started with an attempt at ad-hoc consensus protocols, similar to Ripple. That failed. Then we tried to enumerate the set of all possible consensus protocols by defining the attributes of consensus protocols. Then we eliminated broad classes of protocols that could be proven to not meet requirements (resource intensive or subject to sybil attack). The result is a very small set and with a choice of attributes, that does not give you much choice. You end up with Skycoin type consensus no matter what you do, the only difference to me appears to be implementation details like using directed vs non-directed graphs and other details.

If you remove the requirement for global consensus and a global ledger, then you end up with more options and I believe this is direction that consensus research will move. If you choose global consensus with a global ledger and do not want sybil attacks or resource intensity, then you only have the choice of Skycoin type consensus or securing the asset against something else (PoS or sidechains on another digital asset).

You can also show that Bitcoin type digital assets systems are in insecure, unless information about the global and local state of the communications network they are running on is available. The local and global convergence of the consensus process, critically depends on the communication process between the nodes. The linguistic pragmatics of information about consensus, depends upon the communication process itself and the state of the network over which that communication process occurs. For instance a Bitcoin node has no way of knowing if there blocks on longer chains than their current head. It has no way of knowing that it is not captured in a sub-network that completely controls communication into and out of the node and which controls and manipulates its view of the network. Skywire was developed to solve that issue.