Topic: [SKY] Skycoin Launch Announcement - page 143. (Read 381579 times)

Development Update

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

Changes

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

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

Future Changes:

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

Skywire: Darknet/Meshnet Switch:

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

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

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

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

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

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

Meshnet Hardware:

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

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

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

Community Handover:

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

Skycoin IPO:

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

StorJ IPO:

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

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

Crypti IPO:

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

Thanks for letting me know your opinion. I am sure you are right and the price will be hectic, but I am not really interested in short term money making with projects like Ethereum or Vericoin. I am a big supporter of Vericoin, but I think the Skycoin dev is different league than Vericoin - Skycoin is in the league of Ethereum terms of features and innovation.

If you just want to support this project, it's good, but it's not good as an investment, this project is too famous, it will attract a lot of guys to join in the IPO, so the result is like Safecoin, trade price will be below IPO price quickly.

I don't care what some hero member critics/sceptics say about this coin. It's quite clear that a lot of hard work being added into this projects and posting dev is incredible knowledgeable in the field of digital currency and smart contracts.

I put aside 10 BTC for this coin, let me know when the coin is released.

Development Updates

Skywire Repo Moved:

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

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

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

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

Project Management: Dependency Hell

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

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

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

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

Unit Testing:

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

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

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

Deterministic Build Road Map: Autonomous Corporations

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

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

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

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

Digital Autonomous Corporations: Technical Requirements

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Digital Autonomous Corporations: Functional Unspent Output State

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

B(U) -> U

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

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

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

Digital Autonomous Corporations: Mathematical Notes, Object Process Algebra

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

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

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

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

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

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

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

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

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

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

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

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

Digital Autonomous Corporations: Implementation

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

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

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

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

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

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

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

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

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

This coin is the future.

I love your responses "Skycoin" they could all be bound together in a well informative book!

Mesh Networks are a great way to decentralise everything, just need to get them to grow steadily although the infrastructure relies heavily on users' own funds and expertise. But I see the start will be over IPV4, which makes sense for the network to grow quickly. Looking forward to it.

These sort of projects take a long time, look at Ethereum, BitShares, MaidSafe, etc. There seems to be a lot of projects (including Skycoin) that are trying to solve as much as they can within their own project boundaries. There are a lot of great minds hard at work at the moment, all for different "brand/project names" with missions at times impossible to complete with their own resources. Can you imagine if one or more of the above projects would start to cooperate with each other and share code, resources, ideas and implement things together? Now that would be something!

Of course all of the current projects sound like they will be Open Source so I'm confident that many of their products/services will be able to at least interact with each other and even work in unison. I see there will eventually be the need for some sort of standard bits of code/APIs which (pardon my ignorance) will allow for multiple projects to work with each other. With too many projects with such great ambitions, how will the rest of us be able to choose which one is best or even where to start?

On another note I have a feeling that Facebook, Google, Apple, Microsoft and the likes are closely observing the Bitcoin 2.0 movement and learning about it. Open Source is like "patents for some Asian manufacturers" = copycats. So what stops the big blues above from making their own versions of some of the projects, give them a nice user friendly GUI, integrate them with their existing successful products and get instant and broad user adoption? Considering their huge development and funding resources I don't think this scenario is too far from a near future reality. Even though they may not be as privacy concerned as the Bitcoin 2.0 projects are, they may take off just because they are easy to use for the masses. Usability is something to keep well in mind when thinking of mass adoption potential.    
 
Nevertheless, I support Skycoin and everyone else who can come up with a way to better privacy, personal finance, communications, exchange of goods and services and so on. People like the above will make a difference in the near future for the rest of us. Give it time, a revolution is just beginning! Just hope for all them projects not to get exploited by the current status quo.

 

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

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

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

We have people who are just working on these problems.

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

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

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

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

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

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

Implications for Aether

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

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

Long Term Implications

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

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

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

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

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

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

Altcoin Governance

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

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

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

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

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

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

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

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

i believe in skycoin, great coin great devs

cant wait 4 start

skycoin  will to the sky

Interesting update, these challenges are the base to decentralisation:

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

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

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

Development Update:

Crypto Upgrades

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

Encryption Format:

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

Their pubkey is P, your ephemeral pubkey is Q.

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

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

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

Address Format Changes

Previously the binary address format was

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

The new format is

struct {
 uint8 version
 chat[20]  address
}

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

Data Serialization

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

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

Instead of

struct Message {
 //data
}

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

The New API will be

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

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

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

Changes to Daemon

There are major changes to the networking stack occuring.

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

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

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

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

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

Low Latency Internode Messaging:

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

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

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

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

Lessons from Skywire Networking So Far

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

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

when the launch time?

Thanks for the update!

I like this coin more and more. The project will be one of the most successful.

watching,

Please guy´s, don´t quote the whole text.

btt:
Thumbs up for dev(team) even last post was much too technically for me 

This project seems to be very interesting and you seem to be making good progress. How long till the IPO?

holy shit. i appreciate all the hard work and effort. do you guys ever rest? u need to rest and destress. this is a major update. thank you.

when can we launch a skywire node

Development Update

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

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

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

Meshnet News

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

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

Skywire Multihoming and BGP

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

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

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

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

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

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

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

IPv6 Address Space reverse compatibility  

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

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

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

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

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