IPO

None of the developers want to deal with issues for windows builds. 2000 coin bounty.

Someone with linux, read this, then document steps to cross compile on debian for windows with mingw, for 32 and 64 bit
- http://www.limitlessfx.com/cross-compile-golang-app-for-windows-from-linux.html

Then put command line steps here.
https://github.com/skycoin/skycoin/issues/24

Otherwise, we will start IPO without windows builds. 

This is my perspective.

Stellar has a 16 million dollar market cap. They have released 2.6% of the coins.

There is little risk a coin goes below the IPO price. There is a risk of a bubble. We dont want people buying in and then losing money because the price fell. There are whales who can buy in, set a high price, grab more money than they put in from new investors (hype) and then pull out, sending price crashing. The reason the altcoins are so volatile is there are people slamming 1500 Bitcoin buy/sell orders for fun.

If the height is 10x IPO, it will not be too bad. There were people who bought Bitcoin at $30 and were upset that it fell to $2. If you held long enough, you made money at any price you entered. For the first two or three years, Bitcoin was not even at a penny. I still remember it breaking a dollar. "Bitcoin worth more than USD" was big news.

If you were in the first 0.1% or the first 1% of Bitcoin users, you did well. You are up a million x. If you are in the first 1% and it succeeds, you will be fine. Even the first 10% and the first 30%. Everyone here now is extremely early.

If the price goes to 100 million, we might give out 200k to 600k in coins across a few test cities as subsidies for hardware, to test software on and figure out what problems deployments have.



We are only doing 200k. This less than individual investors have tried to give us. For first year budget, we are unable to spend more than 2 million. There are three very highly focused milestone we are working towards. We dont want to hire everyone and try to do everything at once, just because we have the money to, if it means losing focus on the core priorities (consensus implementation, skywire). After those two things are done, then we can support more groups working on independent projects. However, we do need more developers and help from community.

We have some very good developers who could not work full time on skycoin until after the IPO because they didnt buy Bitcoin early enough.

When you watch people moving million dollars into and out of Bitcoin in minutes, you realize that this project is very small. Another issue, is that money or having a large market cap does not help the project achieve its goals very much. Bitcointalks probably has at least ten million dollars in Bitcoin from early donations, but that money has not made the forum better than it was four years ago.

Money can be corrupting too. When Bitcoin hit $100, everyone was obsessed with buying condos and partying. They lost sight of what Bitcoin was suppose to achieve and how much work was left. The coin price is a result, but it its not the goal, its just a side effect.

IPO Update:

I am glad people have been able to get the client working!

Two things left, the IPO
- finishing up refactor. wallet state is now in /src/gui and visor/daemon are independent of wallet now. more work on this, but after IPO
- The tox bot is in python, it needs to be in golang to use some functions.

How IPO will work:

There will be a bot on TOX. Install Tox, make sure it works.
- you will message it with Skycoin address
- it will message you with Bitcoin address
- You send bitcoin, it will look on address for outputs and send skycoin

IPO Price

The IPO price will be 10 cents per Skycoin. At whatever the Bitcoin price is. Adjusted daily or hourly.

2 million (of 100 million Skycoin) will be sold in the IPO.
- if the coins sells out too quickly, then up to a total of 10 million coins will be released (so that everyone can get a chance)
- we want to keep the coins scarce

A pool of coins will be set aside for developers and people helping project. They will be able to buy in at the IPO price later, regardless of what the price is. This should encourage work on fixing bugs, build scripts and cleaning up codebase.

Distribution Over Time

- 40% to 60% of the coins will be distributed in the next five years.
- The undistributed coins will be locked in 100 blocks of 1 million coins and publicly verifiable.

The rational for the Skycoin Distribution is as follows:
- A slower distribution over time, will reduce volatility compared to distributing them all at once
- The distribution will be N coins per day. The rate will taper and decline over time, like Bitcoin
- If the price gets bubbly or goes up too fast, we will increase the distribution rate
- If the price goes down too far, the distribution rate will decrease to take downward pressure off the price.
- If the price falls down too far, we may buy coins back to stabilize and put in a price floor

Distributing coins over time, with a taper, (like Bitcoin) still encourages early adapters who come in after the IPO. It keeps the price low and allows a stable and gradual appreciation over time.

Instead of raising 30 million dollars at once, it is better if coins are sold off to pay on-going expenses. The expenses will increase as we hire more developers and hit milestones.

A large fraction of the coins will be distributed as bounties for development, to key contributors and subsidies for hardware.

Negative Things

I feel horrible writing this, but its true.

Mistakes we are trying to avoid:
- In NXT the IPO was closed early. We have no idea if two people own 95% of the coins and could dumping at any time.
- In Mastercoin, all the coins were created in the IPO and there was no incentive for people to come in after the IPO. So the valuation was high but the liquidity was very poor.
- In Etherum. I dont know what I bought. I do not believe there was a valuation on the IPO. It was open ended.
- In Ripple, the user base ended up with 0.1% of the total coins. There were 100 billion coins. 100,000,000,000 and users received 20,000 coins. The distribution was so unfair, that multiple insiders each have their fingers on the keys to a market suicide machine. People received coins at below market valuation in back room deals. We are not doing this. There are mandatory investor lockup periods to prevent investors from dumping and crashing the market. We are not doing this.
- The MtGox theft resulted in a loss to users of 744,408 Bitcoin. The scammers are cashing out these coins and it is putting downward pressure on Bitcoins price. This theft was so large, that it could depress Bitcoin's price below the trendline for the next two or three years, regardless of exponential growth in adaption. We need to be vigilant.
- I think Stellar did a good job on the IPO. The ownership became more diversified than Ripple. They gave out about 3% of the coin. Then the valuation is at 15 million.

IMPORTANT

There will be a blockchain reset soon. There are some minor last minute changes to block header and I dont want to delay IPO further to fix this.

Skycoin is designed so that we can
- export the transactions in JSON from the current blockchain
- reimport the transactions in the new blockchain

This means that balances will be preserved. Bitcoin had a lot of bugs that could not be fixed because they would change hashes and break the blockchain going forward. In Skycoin we plan to fix these errors and then roll over the transactions. The balances should always be the same at the end and there should be tools to verify this.

Note:
- The emergency alert system is not implemented yet. When its implemented it will give exchanges and users warnings about resets and required upgrades. Exchanges will get a field returned in JSON to signal human attention. Users will get an HTML banner in the client upon startup or the receipt of the message.

There are several scheduled changed that will change binary format and require blockchain resets:
- we are adding merkle hashes of the outputs spent and the outputs created by all transactions in a block. This will guarantee bit for bit agreement between all clients about operations applied to the blockchain. If a cosmic ray hits your RAM and flips a bit, this will detect that before it causes problems. If two different CPUs, compiler versions or optimization flags produce different values, this will detect that. This change will happen soon.
- We have a new merkle construction that allows proof that a block header exists in a series of N blocks given the genesis header and header for the blockchain head and log(N) blockchain headers. This needs to be worked out before it is implemented
- We want a merkle-tree of the unspent output set in the headers. However, removing N0 outputs and adding N1 outputs to a tree with N2 outputs would require too much hashing, if we simply took the whole set and reconstructed the merkle tree each block. If there are 1 million unspent output, that is 500,000 hashes minimum, every block for verification. A modern CPU does 50,000 hashes/second. If we have 1 second blocks, we cannot have block verifications that take longer than the block times, or a client downloadings the blocks will never catch up. One solution is to have a list and only allow appending to the list and zeroing elements in list. Then store this run-length encoded. Then the merkle tree can be updated, with N0 new outputs created and N1 outputs zeroed, with (N0+N1)*log2(N2) hashes, where N2 is the number of outputs spent to date. This means the depth increases forever in number of outputs that have ever been created. Another method zeros the spend outputs and keeps a sorted list of the zeros and adds new outputs hashes to the zeroed slots. It is unknown, when we will have this worked out and tested.
- We want to upgrade the hash function from SHA256 to something better. The new "sponge" functions look very good. They are faster and offer better security, but are not ready yet. A sponge function has an internal state of 1024 bits, and you push 256 bits in and the state is updated. Then you squeeze 256 bits out. SHA-3 Keccak is slightly faster than SHA-256 and in hardware or FPGA the speed very good. We are waiting on this, until there is time to evaluate it.
- We may add a turing complete scripting language, which is severely restricted. There will be a deterministic LLVM type virtual machine with restricted type system and minimum number of operands. A piece of code (a function) will hash to H. A transaction using H will prefix the transaction with 256 bit hash H and then the parameters will follow. This would allow new transaction types to be added (multi-sig transactions) and old transaction types to be deprecated, without breaking earlier blocks. Blockchain parsing becomes independent of the golang code or compiler. Skycoin transaction types would be severely restricted to a minimum set, but personal blockchains would have access to arbitrarily powerful contracts. This is deferred indefinitely.

Meshnet Update:

We have a new group working on meshnet hardware.

Most hardware today is OEM and off the self. Apple gets sames from dozens of companies, tests them and then chooses best one for the price. Then they put the hardware into a nice looking case. We are now looking for off the shelf modules or chips for 5 Ghz and 24 Ghz that give us control over the beam direction or other options. This is being handled by separate people, so wont slow down software development anymore.

We are talking to contracting firms who can source chips, do prototypes or keep us informed of new hardware. There are two groups in San Francisco with same hardware requirements as us, working on a similar project, so we work with them.

5 Ghz is 6 cm band. It is line of sight. It is blocked by leaves, but bandwidth is 150 Mb/s to over 1 Gb/s. There are single chip radios implementing the 5 Ghz band 802.11n/802.11ac protocol with beam forming or a raw 5 Ghz radio with 40 Mhz channels and 4 antennas outputs. We can attach an FPGA to this and a trace antenna or commercial antenna and test it. This is line of sight, so it might have to be placed a pole, on a roof or out the window. However, the antenna direction can be re-positioned electronically and potentially connect to multiple others.

For point-to-point and backhaul, Ubiquity has 24 Ghz hardware. "AirFiber". It has two antennas, one with horizontal and one with vertical polarization. The latency per hop is 1 ms. It is full duplex, so the latency does not increase if other side is transmitting. The cost is $150 per unit. The speed is 150 Mb/s to over 1 Gb/s. However, it requires installation on a pole. The antenna requires alignment to within eight degrees and it is point-to-point only. Wind can knock the antenna out of alignment. However, it also runs linux.

There is another version used for WISP (wireless internet service providers). It can connect four to twelve users at 150 Mb/s. A directional panel beam, with beam forming.

The meshnet is viable now. The technology is here for small scale meshnets, over some geographies. The equipment available is advancing rapidly. Our initial assessment was significantly more pessimistic than reality.

- WiMAX failed because of licensing fees and spectrum costs. Hardware costs never went down to wifi levels. All technologies going forward will be open access (unlicensed spectrum, wifi style licensing).
- 700 Mhz hardware is becoming available. 20 Mb/s radios are available now. This has mile range and penetrates concrete. Will work in urban areas. Latency is poor. Will work for text messages and basic internet.
- 24 Ghz and 5 Ghz are now usable for unlicensed operation. These are high bandwidth and line of sight.
- the 50 Mhz to 700 Mhz television whitespace bands are opening up (802.11af). This will fail miserably because of channel width and restrictions, but could improve in future.
- freespace optics is becoming viable. DIY and professional hardware exists commercially.
- cell phone providers are allowing customers to run femto cells on premise. If customers are running stations on premise then we may have an unlicensed LTE band. We may be able to run meshnet over LTE.

The hardware for meshnet mass adaption will be ready commercially within five years. It will only improve from there.
- point-to-point and backhaul is ready now. Wireless Internet Service Providers (WISPs) are proliferating
- meshnets will not be easy for the first decade. It will not be like plugging in a wifi device. You will have to climb a roof or get someone to do it for you. You may have to install panels on side of house at an elevation. You will need line-of-sight. The wind will blow the antenna out of alignment until hardware improves (beam steering or mechanical gimble, second generation). This is more dangerous than Bitcoin mining.
- The first areas to get deployments will be rural areas or areas where existing internet is slow, not available or expensive.  We have the hardware for this right now,
- Dense urban areas are edge-case. Need SDR, custom equipment.

We looked at the athens meshnet. We determined that the barrier is currently software, not the hardware side. Commercial Wireless Internet Service Providers (WISPs) are essentially commercial meshnets. There is a growing market for hardware aimed at WISPs and the first meshnets will be using this hardware.

Their networks are structured hierarchically. The depth max is three. There is a large microwave uplink to a location they have roof or tower access. Then they beam point-to-point 1.5 Gb/s connection to another roof. then they have directional antenna covering a 60 degree to 120 degree arc that services four to sixteen customers at up to 150 Mb/s each. The network fans in, to fatter and fatter pipes. These are small companies, with usually less than 1000 premises (50k/month revenue).

What Skywire provides WISPs is two things
- non-hierarchical routing (in a non-hierarchical namespace). This means load balancing and potentially redundancy.
- inter-operability between WISPs. This means ability to bridge network across customer premises, third parties and other WISPs.

For testing:
- We need to get Skywire prototyped and working as darknet as internet overlay (in progress)
- we need option to disable link encryption so it can run at line-speed on the ubiquity hardware used by the WISPs. (new requirement)
- the routing needs to work (designed but not implemented)
- load balancing may need to work (more difficult, possible but open problem)
- we need to find people who operate a WISP and determine what their requirements are.

After the prototype for Skywire is done, the meshnet part and the internet part will split and need to be staffed by separate development teams.

IPO Update:

We have a tox bot now. You send it your Skycoin address and it sends back a Bitcoin address. You also have to set a refund address, so that we can send coins back to you, if there is a problem.



- I am setting up system for offline generation of the bitcoin addresses on an airgapped computer, to prevent the Bitcoins from being stolen if the sever is hacked.
- There is one more bug in the Skycoin client, where wallet IDs are not working and it claims balance is zero for wallet when its not. I may end up rewriting the whole wallet module.
- The API function for adding deterministic wallet by seed, is implemented. It needs to be added to the interface.
- We need to produce windows builds.

Consensus Algorithm Update:

Whitepaper Draft: http://128.199.188.22:1337/consensus.pdf
Graphs: http://128.199.188.22:1337/



This is a histogram of convergence times. The x-axis is "rounds" the network takes to reach consensus (all nodes in the same state) for a single round consensus process.  The top algorithm is hill climbing, the middle algorithm is simulated annealing and the bottom algorithm is changing randomly between hill climbing and simulated annealing.

There is a network of nodes. Each node follows a number of other nodes. Each node has a state 0 or 1. Each node sets its state based upon randomness and the state of the nodes it is following. The process is simulated in a python discrete event simulator and includes network latency.

The network of the graph used in simulation is a real world social network, taken from the Stanford Wikipedia admin dataset.

We see that the top graph (hill climbing) converges within 10 rounds and usually in less than 5 rounds. However, there is a probability that consensus is not achieved within 45 rounds (The bar on the right on the first graph). The network reaches a local minimum and gets stuck there and never convergences, but only rarely.

One round for a network of global servers, is about 250 ms (the network latency latency between Canada and Australia).  Convergence in 5 rounds, means block times of 1 second.

For the second graph (simulated annealing), we see that there is a constant probability of convergence. This is because of "Symmetry Breaking". The simulated annealing process is driven by the "Delta" at each node. The network starts with half the nodes as 0s and half as 1s and so the delta is small. As the network becomes biased, the network converges exponentially quickly to one state or the other state. The symmetry breaking process is a random walk and can take arbitrarily long.

In the third graph (each node switches random between simulated annealing and hill climbing). The hill climbing breaks the symmetry and the simulated annealing prevents the network from getting stuck in a local minimum.

This is a graph of the commutative convergence probability function for each algorithm. Even with a real world social network graph, the probability of convergence for algorithm 3 is 1 for 20 rounds. This corresponds to 4 second blocks. The majority of blocks will achieve consensus within one second. This is competitive with credit card transactions. Bitcoin transaction confirmation times are 10 minutes.



There is an even faster one round consensus algorithm, based upon the method of 1-Replica Symmetry Breaking and the cavity method for spin glass systems in statistical mechanics. The existing algorithm is fast enough for now.

Consensus is the idea that the network reaches a ground state. There is a global energy function of all nodes. There is a local energy function for each individual node, which depends on the state of its neighbors in the graph. The network has minimum energy and is in the ground state when all nodes are in the same state (consensus). Each node has a local view of the network and acting independently achieve global consensus.

In Bitcoin the blockchain which required the most hashing to produce is the consensus chain. When consensus changes a fork becomes the longest blockchain in the tree of blockchains. A reorganization happens and transactions may be invalidated (double spending).

In Skycoin, malicious nodes can slow down or manipulate the consensus process but cannot revoke consensus of previous blocks (under most circumstances). A large enough group of influential and colluding nodes can completely control which blocks are accepted or rejected. The attacking nodes, however cannot revocate previous consensus decisions.

The consensus algorithm is based upon Ben-Ors randomized decision process over a Web of Trust (WoT) network. The nodes each node is subscribed to, represents the friends (personal contacts), peers and institutions (merchants, exchanges, websites, services) the user believes are trustworthy and reliable. Instead of spreading consensus across two or three mining pools which control 51% of the hash rate (three institutions), consensus is distributed across several dozen or several hundred of high influence nodes with network centrality which must be individually subverted or collude to influence the network.

In Skycoin, nocd trust relationships can be modified to marginalize nodes which have been shown to be involved in attacks of the network. Therefore, control of the network can be reclaimed if it falls into the control of a malicious faction. Nodes lose the influence required for a successful attack, once they have acted maliciously, as people will remove those nodes from their trust list as a result of an attack. In Bitcoin, hashing power cannot be removed from people who exploit majority control of the network.

Bitcoin has no mechanism to recover once a 51% attack occurs. Once a 51% attack occurs it will lower the price of Bitcoin, hash rate will decrease as unprofitable miners shut off equipment and the cost of subsequent attacks will be reduced. Bitcoin may suffer death spiral under a successful attack. This has not occurred with Bitcoin yet, although has occurred in several alt-coins.

The primitives in Skycoin's consensus process relay heavily on "randomization. It is impossible to guarantee consensus within a finite amount of time or guarantee the absence of blockchain forks (randomization), but the probability approaches zero exponentially quickly in time.

The final implementation will have multiple tiers of transaction and consensus mutability.
- There is a small probability of a revocation for a transaction in a 0-confirmation block.
- The probability of a revocation of a block decreases exponentially in the number of confirmations
- After N-confirmations the block cannot be revoked in the consensus process without introducing a fork (consensus diversity). The network will stop and wait rather than continuing if alternative candidates remain which have unresolved fork candidates to block depth N/2.
- Even if a fork occurs, it will not affect the majority of transactions or outputs. Most transactions and outputs will exist on both forks and there is minimal ability of an active attacker to modify the validity of transaction chains they were not involved in.
- There is a federated mutability check-point every M blocks, once the block has reached sufficient depth. This includes a hash of the full blockchain state and unspent output set. A node issuing a checkpoint should subscribe to several thousands nodes in the network (possibly all nodes) and certify global consensus. These will probably be run by developers and exchanges. An individual node should compare the output of several independent checkpoint issuing nodes. I am having trouble imaging an attack that could result retroactively introduce a fork that occurs before the last check-point. If 80% of the nodes in the network disappear because of a netsplit or nuclear war, it becomes more important to avoid issuing a checkpoint which misrepresents confidence in the network state.

Federation vs Decentralization

Skycoin's architecture relies heavily on "federalization", which is a form of decentralization but different than Bitcoin's form of decentralization, Examples:

Banking:
- centralized: a global central bank that issues money and clears all transactions through hierarchical sub-banks
- federated: each bank issues their own notes, redeemable against gold (free banking)
- federation to the user level: every user issues their own notes and credit to other users, every user is a bank (Ripple-pay (not ripple))

Communications:
- centralized: AIM/QQ, a centralized entity which forwards all communications between users
- federated: Email, a network of email servers where each server is run by a different person, each of which support multiple users as clients. users@domain.com . Users have a choice of servers and can run their own server if they do not trust any existing server.
- federation to user level: Tox, each user communicates directly with their peers

"decentralized" and "peer to peer" are vague. A protocol can be federated but have peer-to-peer replication. A protocol can both be centralized on one level, federated on another level and peer-to-peer on another level. Decentralization or federation at the user level is not always superior to decentralization either.

File Sharing:
- centralized: FTP server (which is actually federated, as a protocol, but is not federated as a source of a particular file!)
- federated: Torrents. Federation of torrent file distribution (no global centralized index of torrent files, but anyone can host an index of torrent files. Choice of multiple directories of torrent files), but peer-to-peer replication of files within an individual torrent
- peer-to-peer: Kazaa. Decentralized index, decentralized searching, decentralized downloading from peers. Notice that Kazaa is completely "decentralized" but is not as robust, useful or survivable as Torrents, because it did not have a mechanism for curation. Here, decentralization of everything was inferior to federation, because the completely decentralized service (Kazaa) was flooded with junk files, while the federated service (Torrent Trackers) was able to maintain high quality files, without creating a single point of failure which could destroy the network. Kazaa was quickly destroyed, but even destroying a single directory such as Piratebay or Demonoid has been frustrating and resource intensive. What.cd replaced its predecessor within hours of the original being taken down.

In Skycoin federation means that there are privileged servers that the client must trust (such as the mutability checkpoint servers). However, each client has a choice of which servers to trust. You can run your own server or if you are running an exchange or bank, you should be running your own checkpoint server and you should also be checking against external servers. You should only accept the consensus if there is unanimous and uncontested agreement.

This is similar to N of M signatures. You choose a list of N people and you only accept something if all N agree. With 10 servers a successful attack on 9 servers will fail as the client will detect a discrepancy. For a bank or exchange, this would mean freezing transactions until issue is resolved by a human. This represents escalation from algorithmic resolution to human judgement.

Federation enters into the design of Skycoins in several places. If you have a common protocol for exchanges and each exchange is a public key, you put a list of five public keys (exchanges) on the list of exchanges you "trust". Then you look for the best Dogecoin/Bitcoin exchange rate across all five exchanges and can execute at the best quote across the five exchanges.

In Skywire, public keys replace IP addresses. This is a cryptographic version of DNS. A public key uniquely identifies a service, server, entity or communication end-point. The protocol is immune to man-in-middle attacks and no one can impersonate a service without obtaining the private-key for the service.

Multi-round consensus

We are now working on research of the multi-round "tree consensus" algorithm. Tree consensus algorithm is the multi-block consensus process and will be the algorithm implemented for Skycoin. The tree-consensus algorithm supports consensus process concurrency (consensus debate on multiple chains concurrently) and consensus diversity (there may be one or more "consensus" chains. A  rare and severe netsplit condition or successful attack may introduce forks where the preferred consensus candidate should be resolved by hand by each individual node operator. If a transaction has been executed on all consensus chains, then it has been executed for all purposes).

Consensus diversity means that if there are five forks open for consensus and your transaction has been executed on all five forks, you can safely spend the outputs of the transaction without risk of it being invalidated and the output made retroactively unspendable on any of the forks. This is a notion of "blockchain fork forward security". Forks can be introduced in future, but not retroactively. This is enforced by all honest nodes in the network through use of local timestamping (later distributed time stamping) of block publication time and strong insistence against accepting a block into the census set which could not have existed at the block publication time.

Security of local time stamping relies on several assumptions. The most important assumption is that each node has at-least one node it is connected to, that is not a Sybil attack node. If a node is connected to 10 nodes and 9 of the nodes are Sybil attack nodes that may arbitrarily delay block propagation. as long as 1 node is not in the Sybil set then the timestamps will be reasonably accurate.

Road Map

1. paper on single round consensus
2. research on multi-round tree consensus and python simulation
3. some aspects of skywire, moving Visor on top of skywire
4. implement tree consensus in go and integrate into Skycoin
5. misc. infrastructure. Check-pointing, network monitoring, emergency alert system, merkle-DAG for parallel block downloads

#1 is in progress. #2 and #3 are happening concurrency. #5 will have to be handled by the community because we dont have time.

Yes. Good eye. I am glad that works.

Wallet format is defined in /src/wallet/wallet.go

Wallets are in "interface". So you can implement different wallets.
- There is a deterministic wallet that implements the interface (default)
- there is a "simple wallet" which just stores private keys like Bitcoin's wallet
- If you are company you might have N wallets, one per employee and with only receiving and not sending (implement interface)
- If you are an exchange, you might want a wallet that keeps customers funds separated by customer instead of mixing (implement interface)

The problem is, the existing wallet interface is horrible. Its better than Bitcoin's but it can be improved.
- look at /src/wallet/wallet.go
- look at /src/wallet/deterministic.go

For the wallet format. I think that there should just be a map, with optional fields
- "name" : "user chosen wallet name"
- "seed" : "actually a string, but hex SHA256 works too"

Then there should be an array. The array should be
- "Address : Privatekey" or "Address Publickey Privatekey"

We do not want people giving out private key by confusing it with public key

Maybe an array of maps
{
 "address" "..."
 "seckey" : "...",
 "pubkey" : "...",
}

Also, "ID" I am not sure if ID should be in the wallet itself. Seed should be at the top of the wallet. The wallet format needs to be improved, cleaned up, simplified.

JSON API

Now that you found the wallet files, try this

go run ./cmd/skycoin/skycoin.go -web-interface=true
http://127.0.0.1:6420

Now look in
/src/gui/wallet.go

See Bottom


These functions you can call in browser
http://127.0.0.1:6420/wallets

You get an array of your wallets


I am adding functions for
- getting all unspent outputs
- there should be function for getting block depth and other information (its probably in daemon)
- getting outputs for an address
- injecting transactions

If you add enough json functions, you can build the blockchain explorer inside of the wallet. You can check balances locally, instead of having to scrape blockchain.org like people do in Bitcoin.

Adding wallet from seed:

There was one function that did three things
- create wallet
- get wallet
- update wallet

I split the functions. So they are separate. There is not a seed parameter on the wallet creation.

You can now add a deterministic wallet by seed. There will be gui button for this eventually.
http://127.0.0.1:6420/wallet/create?seed=yourseed

Overview:

Overall, the architecture is very good. However, the details need polish. This involves removing code and simplifying, removing unnecessary things. I dont feel like the Bitcoin API has changed in five years. You still cannot check balances and get outputs for an address not in your wallet, in Bitcoin. So in some sense, the Skycoin API has evolved faster than in two days than Bitcoin did since launch.

We are using JSON format, so people will not lose wallets like in Bitcoin where a new client cannot load an old wallet serialized with older version of the key-value store library. There are people who has 20,000 Bitcoin and deleted wallet because it said it has zero coins, (old wallet format, with new bitcoin client) when Bitcoind loaded wallet with silent error. You have to know there are coins in wallet and then export the privatekeys by hand, then import them by hand on command line to even know if there are coins in the wallet.

Also, JSON is good, because you can pull out a single private key or address by hand. You have to do this on command line with Bitcoin.

The seed value is good, because as long as you have that, you wont lose the coins.

Multiple wallets in client is good (will be able to switch wallets from dropdown). Most people keep a small wallet (for mobile phone) and a larger wallet. People often delete wallets with coins in them by accident, because they have to rename, move wallets in bitcoind and restart client. Skycoin will have a button from creating a wallet from seed in the web wallet gui.

There are a number of polish issues. Such as if you write a wallet to disc, but the power goes out. The write will "finish but the hard drive didnt write the data to disc and your wallet is gone. So we can't overwrite the wallet, we write a new wallet, then we flush the disc cache by hand, then we rename the first wallet and then rename written wallet to first wallet, then we write random data over the old wallet, then delete it.  You have to make sure all of those steps occur.

If you dont overwrite the old wallet with random data before deleting it, then it can be recovered from disc. If every transaction generates a new address and writes a new wallet to disc, you might have 200 copies of the wallet seed written to disc after a few hundred transactions. Someone could scan the empty space on disc and possibly steal the seed value, even if the wallet is "deleted". So you have overwrite the wallet with random data before deleting it.

I want to get it working, then get skywire prototyped and come back to polish it to that level later.

Pre-IPO Update:

Here is todo list. Help appreciated. https://piratepad.ca/p/skycoin_todo

We will try to write more todo lists.



There is a major problem. All of the coins are in the genesis address and I cannot spend them for an unknown reason. The output is not being found. I working on this.
- the unit tests, test for this and the genesis spend test passes and the later spends work. This should not be occuring.
- the problem may be in the wallet code I changed yesterday
- More functions are being added to troubleshoot. The whole blockchain explorer can run inside of the local webclient if enough API functions are added.
- The balance function may have broken.

The software is evolving and becoming smaller, simpler and more elegant. At great cost of suffering and refactoring. I tried to make very large changes and refactoring was too frustrating. Now I am making small incisions and making sure it compiles and runs. This avoids being stuck in an impossible refactoring situation for weeks. However, the process of refactoring is now several hundred small changes.

The modules are becoming more single purpose and the dependencies they import are being minimized. Daemon is at the top level, but Visor will eventually be at top level and Visor will pull in the networking library (Visor becomes a Skywire application, with Skywire replacing Daemon).

This requires moving
- almost everything out of Daemon not related to networking
- severing the Daemon -> Gui -> Daemon -> Visor -> Wallet call chain and having Gui access wallet directly with Gui -> Wallet
- removing wallet dependencies from Daemon and eventually from Skywire
- moving the JSON RPC server from Daemon to Visor
- moving balance checking and spending functions to the /src/gui or maybe /src/wallet.
- Visor will only export a thin client API for querying address outputs and injecting transactions and then the API will build on this
- Javascript may stop us from running the visor API on another port and then querying it from the GUI if the gui server is running on separate port because of javascript cross scripting. We may need to have a hook in or export the visor web-server to

Then there are several other improvements that can be done
- improvements to block storage (a slotted structure that accommodates the outer wrapper)
- a dedicated module that handles block storage and allows you to get blocks by header hash (blockdb?)
- a blockchain explorer and history module that interfaces with the block storage module

Thanks. We have cross compilation scripts. We should be able to compile for OSX, Linux and Windows from linux.

We will have support for this eventually. I think we still have a cgo dependency
- gobuild.io

Pre-IPO Update

We had a productive day yesterday. Some people were able to get builds working immediately. Other people had problems with golang and path issues we are working through.

We launched the blockchain after a few hours of work. Fixed half a dozen bugs.
- several changes to build script
- updated gvm curl build flags
- updated to go1.4
- fixed bug with genesis block timestamp not accepting configuration setting
- documentation here: https://piratepad.ca/p/skycoin
- improved transaction malleability (more on this later)
- fixed fprintf formatting bug in wallet names

Now
- I am refactoring /src/gui
- the wallet format on disc is JSON. This avoids the dependency issues in Bitcoin's wallet storage format. However, it is not pretty printing the JSON, so fixing that.
- adding function for querying outputs for arbitrary addresses
- /src/gui calls to /src/daemon which calls to /src/visor for wallet operations, which calls to /src/wallet. I am refactoring so that /src/gui calls to /src/wallet directly. This will remove 1,500 lines of code without reducing functionality. This is something I have been trying to do for months.
- then I will call in the GUI/web wallet dev to update the wallet HTML/javascript/angular.js
- then test coins will be transacting across the network

Then we will live code the trading bot, test it with Bitcoin. Then start trading for real!

Skycoin: Transaction Malleability

A crypt-coin does two things
- check balance
- send

So as an application, a coin is very boring by itself.
- Ethereum tries to make it more exciting by adding new features and infrastructure.
- Dogecoin tries to make it more exciting through marketing, memes and emphasis on the user community
- Ripple tries to be something that is optimized to be purchased and controlled by Visa (all the consensus nodes controlled by banks and so on)
- BitShares X (Bytemaster) adds new types of assets and asset pegs, creating USD and gold equivalents which are collateralized by Bitcoin
- StoreJ adds a service offering to drive capital inflows into the coin

Skycoin has combinations of these
- a service offering
- an application infrastructure and set of libraries. Ethereum is at one extreme of putting everything inside of the blockchain (a full turing complete language on the ledger). Skycoin is at that other extreme of putting nothing in the blockchain except coins and transactions (pushing contracts onto personal blockchain and off the main ledger).

More fundamental, the majority of the work and design in Skycoin so far has been on the extremely boring fundamentals of
- check balance
- send

This may seem trivial but it is actually done poor by every existing coin
- Bitcoin's default client is unusable. People have coins stolen daily because they are forced to use insecure web-wallets over usability concerns.
- Bitcoin is not easy to understand and people often lose coins because of differences between what it does and what they think it does (such as losing coins when loading a wallet from backup after 200 transactions).
- Bitcoin's long term survival is not a matter of mathematics, but a matter of social institutions and the honesty of a small number of mining pools.
- Mining pools selling off 500k/day of Bitcoin are pushing the price down and this might not good for the long term.
- There are severe issues in Bitcoin that cannot be fixed. Only a small number of experts care about these edge cases but they become important in a crisis.

The inner details of Skycoin's blockchain design and it differs from Bitcoin only interest a very small number of developers. The improvements Skycoin makes in these areas are not visible, like improvements to the wallet GUI. They only become apparent or important in a crisis.

Transactions:

Overview of Skycoin/Bitcoin. Most people do not understand what a "transaction" is in Bitcoin.
- There are unspent outputs. they contain coins.
- A transaction consumes outputs
- A transaction produces new outputs

You must spend a whole output. If there are 10 coins, the whole output is consumed. You cannot partially spend the output. So to send 5 coins to someone, you send them 5 coins and send 5 coins back to yourself.

- you have 5 coins in an output and want to send 2 coins to someone.
- You create a transaction that spends the output, creating two new outputs
- one of the outputs sends 3 coins back to yourself (change)
- one of the outputs sends 2 coins to the recipient

- Outputs are tied to addresses.
- To authorize the spending of an output, you need the secret key for the address the output is tied to.
- You dont "own" Bitcoin in the same way you own gold (by possessing it). Instead of "owning" 10 bitcoin, someone "knows 10 bitcoin".
- They know the secret that allows them to authorize transactions with the Bitcoin in those addresses.  
- "Ownership" of bitcoin is about "knowing" rather than "controlling".
- The Bitcoin do not exist on your computer, but only the secret key needed to authorize valid transactions from an address.
- The balance of the address is the number of coins in "unspent outputs" for that address

Outputs are named by hashes. In Bitcoin a transaction might be identified as
590f7f552aedb219ff814331201a97c3467b08d590016991c4d31dfdcd4b88ce

The transaction may have three outputs.
590f7f552aedb219ff814331201a97c3467b08d590016991c4d31dfdcd4b88ce:0
590f7f552aedb219ff814331201a97c3467b08d590016991c4d31dfdcd4b88ce:1
590f7f552aedb219ff814331201a97c3467b08d590016991c4d31dfdcd4b88ce:2

In Skycoin, there is an explicit output set. Outputs are actual data objects and part of the blockchain "state". Transactions are functions that act upon the blockchain state. Transactions consume outputs in the state and create new outputs.

Malleability

Malleability means that someone can take a transaction and modify it, so that it is still valid but the hash is changed.
- in Bitcoin, the output is named by the transaction hash
- in Bitcoin, anyone can take a transaction and modify it, so that it is still valid but has a different hash. Even if they do not know the secret keys for any address for any of the inputs used in the transaction. This is non-intuitive and subtle but has implications in a crisis, such as a blockchain fork.

If there is a chain of transactions
T1
T2
T3
And each transaction spends, outputs created by an earlier transaction. Then if the hash of T2 is modified, transaction T3 becomes invalid. T3 is trying to spend an output that does not exist. This only becomes a problem in a blockchain fork or 51% attack scenario.

There are three levels transaction malleability
- anyone can modify anyone else's transaction output hashes, without being a party to the transaction. This is the level Bitcoin is at.
- any party to the transaction can modify the output hashes. At least one private key for an output address spent in the transaction is required.
- The transaction outputs are mutable. A new transaction can be created, but the outputs cannot be changed by anyone. This is level enforced by Skycoin.

In the event of a major attack or blockchain fork on Bitcoin
- anyone can modify anyone else's bitcoin transactions when copying them to the fork of the chain. This will invalidate swaths of later transactions, which depend on the hashes of the now modified transactions. The scope for damages is unlimited and everyone performing transactions over the interval of the attack, will have unpredictable coin balances after the attack.

Effect of Signature Malleability on Loss Ratio in Crisis Scenario

A transaction invalidation attack, is any attack where a previously executed transaction is revocated and some of the outputs spend by the transaction are spent into different outputs. This only happens during blockchain reorgs, forks or other crisis scenarios.

In Skycoin
- if the chain forks or an attack occurs (which should be impossible, but may occur anyways), then your transactions can always be copied from the old chain and executed on the new chain and the resulting balances will always be the same, as long as certain conditions are met.
- Only chains of transactions that involve a malicious party, who specifically and intentionally spends a particular output to a different address on fork A than occurred on fork B affect final balances. If you did not transact with the malicious party and your outputs did not originate through a transaction chain involving the malicious party, your balances cannot be affected. The private key for spending at-least one input for a transaction is required to effect an attack on a particular transaction (which may affect later transactions).
- A user can only perform this attack on transactions involving outputs whose addresses they control the private key for
- This means that a 51% attack or fork has limited scope for damages for most users and especially users who take precautions. The damages in Skycoin are limited and controllable, where as they are potentially unlimited in Bitcoin (potentially all transactions are affected as anyone can change the output hashes when copying the transactions between the blockchains). Services such as exchanges, which are performing high volume transactions with large numbers of users will be hit the hardest by this crisis scenario.
- If there are weekly checkpoints that are immutable, then an absolute guarantee against loss is possible. Example: A large transaction is received and is not moved until the next checkpoint. No attack is possible that would now redirect that balance to a different address or invalidate the transaction creating it.
- Skycoin loss ratios are computable. It is possible to to calculate the worse case loss of coins in the event of a blockchain invalidation or fork, from a transaction invalidation.
- Segregation of funds can reduce loss ratios. Funds received from random users at high risk malicious behavior can be segregated from transactions and funds of trusted counterparties (banks, exchanges, peers).
- Funds from each user can be segregated. If thousands of users have deposits in an exchange and receive addresses are segregated, then loss of funds from a transaction invalidation attack, may be recovered from individual users whose transaction chains were affected (participants in the attack), rather than from the whole pool of users.
- If an exchange mixes outputs from 1000 users and the private keys of 5 users are involved in the attack, then the impact of transaction invalidation is greater if the outputs received from each user are mixed, rather than segregated by user.
- The beneficiaries of the attack can be clearly identified and are district from honest users.
- The malicious branch of the chain tree where outputs have been retroactively modified can often be clearly identified as an attempt at an attack. Especially when the chain contains a large number of coinjoin transactions.
- The "quality" and "risk" of each received coin output can be calculated. An output generated from outputs, which are older or past the last immutability checkpoint, have significantly lower risk of invalidation in an attack than outputs which are dependent on large chains of transactions since the last checkpoint. Exchanges may require longer holding periods before releasing full balance for coins at higher risk.

This is extremely important. In a crisis, the number of users affected is limited
- users which did not transaction during the crisis did not have their balances affected
- only a minority of users are affected or have changed balances, limiting scope for damage
- the impact on the price of the coin is limited
- controllable risk is better than uncontrollable risk

Survival of Crisis

Transaction malleability has effects

In Skycoin, if an attack succeeds at introducing a fork then there are several remedies
- the differing outputs between the chains will be limited
- cold store will be unaffected
- personal transactions between people or companies not involved in the attack will be unaffected
- high volume, automated transaction processors will be affected the most
- dont choose between chains. Run both chains. A transaction is only considered executed if its in both chains
- coins in outputs that differ between the chains should be frozen. Blocks that have transactions which attempt to spend contentious outputs should be rejected in the consensus process  
- have users figure out which branch is the attack branch and then prune it. This has to be done by hand and through human choice, instead of algorithm.
- we may not have to resolve forks algorithmic at all
- the nodes involved in the attack need to be identified and flagged. People should prune connections to these nodes from their subscriptions

There are several steps to prevent it from getting this far, such as local timestamps, distributed timestamps.

In Bitcoin, if there is a fork
- every transaction is up for revocation because of multiple forms of malleability. The victims will be random and potentially every transaction on the time interval of the attack.
- cold store will be unaffected
- personal transactions between people or companies will be affected if they spend the outputs (transaction malleability)
- high volume, automated transaction processors will be affected the most
- Bitcoin price will drop as people panic sell
- Mining difficulty will drop as price drops as miners turn off equipment
- A person who rents, already owns or acquires at firesale prices 20% of mining capacity can now 51% attack the network repeatedly if hash rate drops to 20%
- a 51% attack over less than 8 blocks from the head, can be made irrelevant if clients are patched to not make transactions that spend outputs that do not have atleast 8 confirmations.
- an attack spanning over a day or more of transactions would cause problems for high volume services.
- Bitcoin would be patched and probably survive, but volatility would be increased.

Bitcoin has a simple failure case, but when it does fail it is very difficult to "fix". There is not an effective response or remedy to an attack and there is only limited scope for preventing similar future attacks.

After six hours of work, blockchain is running. We are troubling shooting changes to installation script for gvm and go1.4 that are causing problems for some users. About to test transactions. Then will distribute some test coins and live code a trader bot.

IPO Update

We are starting a mock IPO right now. To verify that everything works and make sure everyone can get it working.
- not everything is ready, so we are live coding it as we go
- we distribute a bunch of fake coins, so people can do transactions, make sure everything works
- so people can can learn to do transactions by hand and as tutorial on public key cryptography
- will make sure bitcoin functions work and live code trading bot
- blockchain will be reset (all Skycoins coins wiped out), then can start real IPO

The real IPO will be like "N coins per hour". It wont be a huge one shot IPO, but will drag on for weeks, with number of new coins decreasing over time. There might be a large block of coins for the early people near the start.

There are still changes being made to the blockchain that will break binary compatibility. We found a new merkle tree construction that allows proof that a particular block is part of a chain of blocks, using log(N) block headers containing the root hash of the merkle tree. Its not ready yetWe want want to add this later, but it will change the hash of the blockheaders and so require blockchain reset.

Skycoin transaction and output hashes are designed to be independent of the blockchain they are embedded in. This means that we can export the transactions from one chain as json, then import them to the new chain. So all the balances will be preserved if we need to fix a bug that would change blockheader hashes. However, we do not have a mechanism in place yet to notify people to update their clients.

IPO checklist

Get pastebin, piratepad, google docs or notes ready to help other people
We are in cryptocat channel "Skycoin" right now

We wanted to use TOX group chat, but it is not ready. The usability is horrible.
We tried using freenode IRC, but frustrating because does not work with TOR and other issues people had.
Cryptocat works, but there is no software for running a bot. So we cant have a trading bot in cryptocat
We are moving on to XMPP

We are starting the blockchain, then will distribute a bunch of fake coins for testing. Then once everyone has problems sorted out, will reset blockchain and do it again for real.

- you need to be able to generate a skycoin public key, so we can send you coins
- we need a little webapp that runs locally, that lets you generate keys, addresses, encrypt messages. We will live code this.
- get it working in the command line, then work way up to web app in golang
- we need to make sure the JSON interface has the functions required for IPO and that they are working.
- someone should live code a JSON thin client, that lets you get outputs, create/sign transactions and inject them, using a public Skycoin node someone else is running. This just requires importing Skycoin Cipher module, then opening TCP connection to the node. Then you can query outputs for an address, inject transactions.

Is there a program that lets people on windows open up an emulated linux environment? We could cross compile a thin client and cross compile the full Skycoin node binary.

In this mock IPO you will learn to create skycoin public keys and addresses by hand, query address outputs by hand and construct transactions manually, sign them and inject them into network.

cryptocat channel "Skycoin" right now

Its ready to go. I am just procrastinating. I was going to start IPO but ended up spending 8 hours writing rant about economic models for coin valuation.

Changes
- the unit tests are fixed
- the refactoring is still not done, but getting closer
- the json output formater for transactions is fixed/pretty printer.
- the way transactions are signed has been modified. Instead of signing the hash of the transaction, with the private key for the output being spent. You now sign the hash of the SHA256 sum of the output being spent with the transaction hash. This has subtle implications. Before you could spend all outputs for an address with one signature in one transaction. This means you could spend 200 outputs with one signature, reducing leakage of private key information if there is an attack on secp256k1 (but addresses should not be reused anyways). However, during coin join transactions a malicious server could spend outputs you didnt intend if your client did not validate the transaction. I decided the validation code was inelegant and so changed the way the hash was constructed, so each input now requires a unique signature. I am conflicted about this. Its like choice between painting shed red or blue, so I should ignore it.
- transactions have two hashes, an "inner hash" of the inputs/outputs excluding signatures and an "outer hash" which is the binary serialization of the transaction. Transactions only have malleability if you have the private key for one of the inputs for the transactions, where as all Bitcoin transactions have malleability. This means, in a Bitcoin 51% attack anyone can invalidate a chain of transactions by using malleability to change the hash of the transaction (even if they were not a party to the transaction). In Skycoin, there is no way to retroactively modify a transaction hash or change an output hash unless you have a private key for an address used as input in the transaction chain.
- I am trying to decide if there is an advantage or difference of using the inner hash vs outer hash as the "ID" of the transaction. I resolved this in favor of using the outer hash, because it allows you to verify the binary network serialization. You hash the canonical binary serializatoin and get an ID uniquely verifying the hash.
- I would prefer to use the new SHA3 Keccak sponge function instead of SHA256, to add security margin but do not have time to study it in depth required. This is a decision that will require months of reflection and the benefit is marginal. When Kazaa was launched MD5 was state-of-the-art, but a few years later the network came under attack and the RIAA was successfully creating hash collisions in order to corrupt MP3s. The hash was used to validate files and RIAA found some attack to find collisions, allowing them to pass data that validated but was corrupt. Bitcoin has edge cases where you can create hash collisions (duplicate coin outputs) and does not check for collisions, requiring monkey patching. Skycoin will be extremely frustrating to attack, even for someone with an oracle for SHA256 collisions and second preimage attacks.
- The security margin of secp256k1 is excessive. RSA-512 can be broken, but if you stored a maximum of 5 coins per address the cost of doing so would make the attack unprofitable. RSA-1024 is still unbroken. By the time secp256k1 is in danger, there will be a need for a blockchain reset (rolling over balance).
- Skycoin has one transaction type. I was worried that I would have to add inflation, in order to fund on-going acquisition of foreign currency reserves to maintain a currency peg. This would require multiple transaction types. Adding multiple transaction types would pollute the code and destroy its elegance. At the last minute, a solution for funding the currency peg was found that did not require inflation. So there are no remaining cases where inflation is desirable or necessary. The coin number can be hard constraint, with no future increase (under the current assumptions).
- Transactions now have a type and length prefix just in case more transaction types have to be added later.

Skycoin Transactions are
- 97 bytes per input +  37 bytes per output + 37 bytes
Bitcoin Transactions are
- 180 bytes per input + 34 bytes per output + 10 bytes

- The merkle tree is always padded to power of 2 and zero padded.  This was originally a radix-16 merkle tree, but Ripple uses a radix-16 merkle tree so I looked at it more carefully and decided that radix-2 was better. If there are 2^N transactions, there will be N levels in the merkle tree and it will require 32*N bytes to describe a path from the root of the merkle tree to the leaf (to prove that a hash is an element of the merkle tree). For radix 16 with 256 bit hashes, it requires 16 32 byte hash even for a one level merkle tree. For radix 16 the size of the descriptor for a tree of depth 1 is same size as radix-2 for depth 4.  So its 32*ceil(log2(N)) for radix-2 vs 16*32*ceil(log16(N)). So radix-16 increases hash speed marginally, but explodes the proof lengths for typical cases. Ripple also uses SHA512 and discards the last 256 bits, which feels ad-hoc. The proof length is more important than the hashing speed (which is already very fast).

I noticed something interesting.

The key for the first 16 rounds in SHA256 are the 16 message blocks in order. A compressed pubkey is 33 bytes. SHA256 takes input, breaks it into 512 bit blocks, adds a 64 bit length to end and then pads with 1 followed by zeros. The padding is fixed after the 33 bytes. Most of the bits in the input are fixed. The compression function takes in two 256 bit blocks and compresses to a 256 bit output. However, almost half of the inputs are determined. For SHA256(SHA256(x)) for 256 bit x and for SHA256(pubkey) for 33 byte compressed pubkey.

The key schedule for 0 to 16, is just the two 256 bit input blocks block up into 32 bit segments, in order
    for i from 0 to 15
        w = w
The key schedule from 16 to 63 is
    for i from 16 to 63
        s0 := (w[i-15] rightrotate 7) xor (w[i-15] rightrotate 18) xor (w[i-15] rightshift 3)
        s1 := (w[i-2] rightrotate 17) xor (w[i-2] rightrotate 19) xor (w[i-2] rightshift 10)
        w := w[i-16] + s0 + w[i-7] + s1

w[8] to w[15] are fixed. 1 followed by zero padding.  For any 256 bit input to SHA256 this is true. For compressed secp256k1 pubkey of 33 bytes, the w[9] to w[15] are known. The padding that fills w[8] to w[15] is only a function of the length of the input, where input length is less than or equal to 256 bits.
- for bitcoin mining, most of the fields/bits are fixed for the problem. Everything except nonce bits.
- for hashing a compressed pubkey to address of the 64 bytes of input to the compression function forming the key input, 33 bytes are fixed/known.
- 3-SAT can invert 20 rounds assuming 512 bits of entropy in input and naive SHA256 encoding. If half the bits in the key schedule are already known, may be exponentially easier than solving for a 512 unknown bits in key schedule. If you modify SHA256 to take out the mixing and feedback in the key schedule, then this appears insecure against 3-SAT attack. The first 16 rounds fall quickly, but only 4 rounds can be broken after the key schedule mixing starts in round 16.
- for Bitcoin mining, only ~32 bits in the key schedule appear undetermined which are unknown
- w[0] to w[15] are just the two 512 bit input blocks.
- there is optimized SHA256 encoding using carry-save adders, used for mining that is simpler to work on and may be faster
- If you can find preimage for SHA256(x) for 256 bit x (x is expanded to 512 bit block but the last 256 bits are padding knows bits are known in advance), you can can find preimage for SHA256(SHA256(x))
- Ripemd160 is a similar Merkle–Damgård compression function. If you can break SHA256 with that attack its likely to break Ripemd160
- If you can preimage Ripemd160, you get random SHA256(x) for 256 bit x (and 256 bits of known padding bits in key schedule) which you then preimage to get a random compressed secp256k1 pubkey
- If the probability that a random secp256k1 pubkey is weak, is 1 in 1024, then you have to do this on average 1024 times, before you get a pubkey that is valid for the address, which you can recover the private key for. If almost all randomly generated public keys are strong, then attack fails.
- We know that almost all randomly generated secret keys produce strong public keys (public keys we cannot recover the private key for). The secret key is 32 bytes and the compressed public key is 33 bytes.
- Recovering the private key from a random public key is the discrete logarithm problem on an elliptic curve. I dont know what percentage of random points on the curve, have easily recoverable exponents. It is probably close to zero.
- The majority of headers do not have a 32 bit nonce that puts the output hash below the current difficulty target. Trying to use 3-SAT for mining would be more interesting and practical with a 64 bit nonce. I think in benchmarks it beat CPU mining with brute force trial and error SHA256 hashing, then brute force became more competitive as difficulty increased. Its not clear why. Now, brute force SHA256 miners commonly run through the nonce without generating a block below the target, so its futile even if there was fast algorithm.

Update:

Ubiquiti has  802.11N 2×2 MIMO on 900 Mhz.
http://www.muniwireless.com/2010/11/02/who-needs-white-space/

This is good background on meshnet routing problem
http://www.freedomlayer.org/articles_index.html
http://www.freedomlayer.org/articles/exp_virtual_dht_routing.html
http://www.freedomlayer.org/articles/sqrt_n_routing.html
http://www.freedomlayer.org/articles/landmarks_navigation_rw.html

Update:

The tutorial on Cipher is done. Now eight year olds can do public key cryptography.

https://github.com/skycoin/skycoin/wiki/cipher

This library handles address generation, deterministic wallets, signing transactions with private keys and encrypting data to a public key. It is the core of the Skycoin Project. The coin and everything else is built on top of this.

Roadmap

In Bitcoin a public key has an address that you can send coins to. In Skycoin at the coin level it is exactly the same.

At the networking level, however public keys can represent servers, devices, darknet nodes or processes. They are communication end-points. So if all the light bulbs in your house had CPUs and were running Skywire, they would have public keys and you would be able to connect to them from a hash of the public key and turn the lights on and off from the internet. For some end-points knowledge of a private-key might represent access, ownership, or ability to control.

The cryptography layer is done. It does everything we need and its a solid foundation.

The coin layer is done and completely implemented, but is undergoing a few updates. It just needs to be launched publicly. Some parts of consensus are still in development and will be added when they are ready (they need the next layer to operate).

The next layer is a networking layer. That is where the new development is shifting. The coin has components which will be rebuilt on top of this layer. The network layer is focused on public keys as communication end-points. The darknet router overlays the internet or other networking infrastructure. It provides transit between nodes and has some privacy properties. This is similar to a VPN. This is the layer that file storage, processes and user applications interface with. This is the foundation for "Distributed Applications" (no one knows what a distributed application is yet because they dont exist, but they will defined as whatever can be built on top of these platforms).

This is part of the effort to "build the new internet". Which came out of OP Redecentralize. There are hundreds of projects working towards this goal, but they are currently, fragmented, non-interoperable and a small piece of a much larger mosaic that is emerging. We are trying to set the standards for the base layers.

Then the meshnet is just a physical extension of the lower layer. It is just a physical connectivity between darknet nodes, that transits locally in dedicated point-to-point manner instead of over the legacy internet. The legacy internet can in-turn be tunneled over the meshnet, just as a VPN tunnels traffic. As soon as the networking layer is done, the physical meshnet is plug-and-play in a few hundred lines of code. This is part of the transition towards community ownership of the networking infrastructure and escaping centralized corporate control of communications.

The ideological roots of Bitcoin originated in agoric computing. Bitcoin is neither inevitable, nor apolitical but rather was a vision of the future. It took thirty years until each pieces of the solution, until each each component was developed to enable the realization of that future. Satoshi assembled the pieces and we have sat back for six years in reflection of what Bitcoin means in historical context and what it means for the direction society is heading. In the past year, there has been frantic land grab as people staked out key positions in the ecosystem, staking claims to wealth, but also a lack of direction, lack of purpose, an aimlessness, coupled with a feeling of banality. Disillusionment with the level of impact Bitcoin has had. Greed, theft and betrayal as all the scammers in the world flock to the GoxCoins.

As soon as components of the networking stage are finished, the project development will need to branch out and begin pursuing multiple sub-projects to achieve relevance. This is the stage focused on user acquisition and being useful, rather than being a marketing gimmick. There is a very non-linear relationship between work and output here. There are dozens of things we could build or do that people would say "thats cool" but have no impact and there are things that are trivial and have a potentially very high impact.

We perceive a huge gap between the visionary, future sounding unproven "revolutionary features" of smart contracts and distributed widgets that send investors and marketers in to a frenzy and the very banal demands of usability, security and other requirements for mainstream adaption that still need to be addressed.

Update

Everyone should watch Boiler Room. This is the altcoin movie.

https://www.youtube.com/watch?v=6VoXMvNrQro

Thank you for these links.

Versum is very innovative. I have not see this before. This is very similar to Urbit.

IPFS was the inspiration for Skywire's merkle-dag distributed file system. We might end up using ipfs. It is not clear if we should use ipfs or roll our own. We wanted a cohesive, integrated stack, with a standardization across encryption (SHA256, secp256k1, chacha20), networking. We implemented a system called Ether, which was like ipfs but a key-value store, with rsync like replication between stores and cryptographic signing up updates.. Then when we learned about merkle-DAG from ipfs and decided that this was the data structure we wanted.

STM32f2 is a good chipset. Five buttons is perfect. You need anodized aluminum cases. The plastic trezor case does not have a quality feel.

This is a proposal for a graphical representation of 256 bit deterministic wallet seeds, in a form that can be committed to memory more easily than a 64 character hex string. It is designed to be easy to write down on paper, with human checkable error correction coding to reduce transcription errors.

https://github.com/skycoin/skycoin/wiki/Brain-Wallet-Sigils

Have you seen our brain wallet sigil spec? This is a graphical representation of deterministic wallet seeds, that has an elegant hardware implementation.

We think this is better than Trezor. Its very simple too. A OLED display ($5), a $2 32 bit arm processor and five buttons. We want a hardware wallet implementing this standard.

https://github.com/skycoin/skycoin/wiki/Brain-Wallet-Sigils

There is a square with 4 quadrant. Each quadrant has a 3x3 grid, with 16 states per element. The advantage is that the format can be written on paper, can be inputted onto hardware device or can be remembered easily compared to a 64 bit hex string. There is also built-in human check-able error correction to prevent transcription errors.

update

I pushed a few fixes. The wallet is still buggy but looks great.



Refactoring is not as easy as I would like. If you split two modules in golang, that have minor depedencies, it will not compile because of circular dependencies. Golang can handle circular dependencies, but the language developers force this constraint upon the developer. This makes refactoring some things, drawn out. I cannot do a series of small, incremental refactors, but am forced to refactor five things at once. It is like untangling a ball of yarn.

Working on migration to new API now.

The new wallet API will separate out checking balances, getting unspent outputs and injection transactions.
- the node is physically separated by an API layer from the private keys
- this makes hardware wallets easier
- this makes it easier to add Bitcoin, Dogecoin and Litecoin into the Skycoin wallet. Every coin can go through a common API interface.
- this means wallets can be like blockchain.info, but completely local. There is no risk of javascript injection or anyone stealing wallet through web-browser.
- nodes are able to query balances, create/sign transactions and inject transactions without running full blockchain. They can use remote nodes through same interface as local nodes.
- dark wallets will not work without a full transaction history. There is no way to do darkwallets in Skycoin with a thin client. Generating a shared address with recipient public key requires a full copy of the blockchain.

In celebration of the first year anniversary of the launch announcement, we are launching coin!

I will update when everything is on github.

I tried to launch it ten hours ago, but every time I open the directory I notice more things that can be simplified, removed, or refactored.
- I decided that micro-optimizing the block header size is pointless. I am doing 160 byte blockheaders instead of 105 bytes. Even with 1 block per second, the difference is 0.1 KB/s vs 0.2 KB/s. The overhead is less than single transaction.
- I never finished ripping out the wallet code from visor. Visor will agnostic over which transactions/addresses/wallets are yours. It just injects transactions and allows queries on the blockchain state.
- I am updating the blockchain serialization format, so its future proof.
- I am simplifying the command line options. There are too many useless command line options.
- the address checksum is now in the written version, but not the version on blockchain (which is redundant)
- the 100% coverage unit tests are broken, but I was never satisfied with them. They feel verbose and still miss most of the conditions I wanted to test for. I want functional and integration tests.
- I am cutting out flow paths in the coin core and moving out as much out as possible
- minimum coinhour fees for transactions will be soft enforced at consensus level, instead of hard failure checks in blockchain. If the parameter is wrong, then it can be changed without invalidating previous blocks. The network may need to dynamically adjust the rate if spamming becomes a problem.
- I found a memory leak, but it does not matter until the blockchain is a few hundred megabytes, so fixing it is not extremely urgent.
- Since the existing daemon works, I will not force upgrading the networking to the new library while it is still undergoing changes. We had people experiencing problems that depended on the date they fetched the libraries. Its better to get it working and use that, develop the new version and then swap it out once its done, rather than using a constantly changing library in dev that breaks builds.

I will try to do a soft launch, get it working with command line tools, so that it can launch and the the GUI wallet can be fixed later. I think the initial distribution of coins will be over tox group chat and there will be a google spreadsheet. There may be a trader bot to automate it later.

Ideally you should build client and run the client to generate addresses for receiving coins. However, we can always send coins to deterministic wallet and maybe add a bot for querying balances, getting addresses and doing sends from the wallet. We do not recommend this from a security perspective, but for small balances, should be fine. We do not trust TLS/HTTPS and feel the tox bot is more secure. Remotely hosted web wallets over HTTPS are becoming high-value targets.

We have hardened linux, behind a firewall with physically secure hardware, with all incoming ports firewalled, with a proxied public IP address. So should be secure enough for running a webwallet bot over tox.

If the build scripts are working, we will try to put binaries up. However, you should build from source if you are able to.