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

Yeah I did everything in the same terminal session from start to finish.

Thanks but I was looking for build instructions.

Anyway I followed your instructions, and the final ./run.sh command produced these errors:


Anyone else? The Skycoin team perhaps?

I bought some skycoins last year. how to access my skycoin wallet now?

this sounds really great. I´m looking forward to this especially to the shapeshift version. that would make everything really easy

What I'd appreciate above all is a step-by-step guide on how to build and run the wallet on a freshly installed Linux, for example Ubuntu 16.04 on a new virtual box virtual machine.

I'm unable to manage with the different go versions and environment settings and chaotic instructions that come with the source tree myself.

Update:

We want to have everything done for the coin in three weeks
- the three white papers
- the website
- the CLI and WebRPC listing
- the blockchain explorer interface in the wallet
- exchange listing
- full consensus implementation
- easy way for people to buy and sell coins

The critical things are
- website
- CLI / WebRPC
- block chain explorer in wallet

Everyone agrees that getting listed and completion of the coin is a higher priority than finishing the apps.

There is a debate about whether we should
- start marketing before demonstration applications are ready
- start marketing after demonstration applications are ready

So the time line looks like

A:
- completion of website
- completion of CLI and WebRPC interface for exchanges
- completion of blockchain explorer (API is done, just needs front end)
- get listed on small exchange for testing API or internal exchange

B:
- add more documentation to the website (Roadmap, Infographics, technical documentation, feature list, API usage documentation)
- publish the three white papers (one paper for coin, one for meshnet and one for consensus. On top of the three white papers that have already been published with the network simulation. Then will have other white-papers about our DHT network and public broadcast channel, but can do those later)

C:
- start marketing on coin?
- more exchange listings over time (The marketing people want to do the exchange listings over time instead of all at once).

D:
- First applications (we will expand and put together application teams)
- the first app will be the meshnet node, which will not have any applications built on it yet but will let you connect to someone by public key (similar to CJDS)

E:
- the second thing will be a VPN client built on the new networking namespace
- peer-to-peer replicated, self-hosted, distributed file system (like IFPS)
- then we will implement TOX like messaging and go from there

F:
- build out user and development community (dedicated communication channels and platforms for coordination).
- supply resource to the third party developers building applications on top of the platform

G:
- planning tools for physical mesh deployment
- OEM hardware suppliers, antenna suppliers, tools for mass scale deployment, provisioning
- SDR experiments and pluggable transports for different hardware platforms

G:
- CX (our blockchain applications platform)
- we need this because we have multiple applications and need to standardize deployment provisioning, user interface, security sandboxing, standardized machine readable RPC, deterministic builds, service discovery, etc (a mesh node, a network namespace, a file system, messaging, a VPN, per customer blockchain applications, third party applications, then another level of applications building on the lower levels).
- Deployment, provisioning and analytics for large scale deployments.
- This will probably be like an app store for Skycoin golang apps initially. I think we can ship a runtime and compile apps from source on site for each platform and user. We can also enforce security sandbox on which modules and imports are allowed.

I think we will do A, then do [B,C,D] at same time and start on [E,F,G].

We need to figure out how to communicate what we are doing.

We should get a roadmap on the website.

Update:

After two years, the "out of registers" compiler bug in Golang, preventing 32 bit windows cross compilation is fixed!
- We now have automated cross compilation on all platforms!



Now someone is looking at deterministic builds.

>I think you should do a release of coins at the same price as original for the people who have been on this forum because some have been unable to accuire any and have been waiting and waiting.

Yes we reserved 2% of the coins for people on the Bitcoin talk thread, at the ICO price.

Bitmessage did not work for a lot of people. We tried to do sale over Tox bot and that failed and people had problems. Also, no wallet builds and difficult to buy. We have developers we are reserving coins for, because they have not been able to get compilation working on their platform.

We also have to distribute enough coins that there is liquidity.

We are getting our own version of shapeshift, inside the wallet for converting between Bitcoin and Skycoin (And later Ethereum). That will make it very easy.

Update:

The Skycoin Mobile wallet API is done. For Bitcoin and Skycoin. Will add Litecoin, Dogecoin and Ethereum later.
- https://github.com/skycoin/skycoin-exchange/tree/master/src/api/mobile
- The library is wrapped with gobind and can be used as a plug-in in Phonegap applications or natively by Android or iOS applications

The Skycoin blockchain history JSON API is done
- the web interface is in progress
- https://godoc.org/github.com/skycoin/skycoin/src/visor/historydb
- https://github.com/skycoin/skycoin/tree/master/src/visor/historydb

The first version of the Skycoin block storage library is done
- memory mapped file and BoltDB key value store
- https://godoc.org/github.com/skycoin/skycoin/src/visor/blockdb
- https://github.com/skycoin/skycoin/tree/master/src/visor/blockdb

The Skycoin CLI and WebRPC interface API is in progress
- this is last step required for integrating Skycoin into existing exchanges.

The first version of Skywire interface is done. It is being integrated with the JSON API now.
- You can run current version with cd skycoin; ./run-mesh.sh
- also the mesh command in skycoin/src/mesh. ( `cd skycoin/cmd; go run ./mesh/mesh.go` )



I will explain this more, as it is closer to working.

You will have a number of "Nodes" that you control (your "personal cloud" or "personal botnet" really)
- You will be able to provision additional nodes (installing node on additional computers or rent out 20 VPS instances in different geographic location, by the hour for Skycoin)
- The nodes will appear in your botnet list
- You will be able to deploy applications on the nodes and perform orchestration

For instance, for dropbox type storage
- you may attach a Raspberry Pi to a 100 TB hard disc and run a node
- You may run multiple such nodes and run a "distributed file system" service on the nodes (which will automatically sync and replicate files within your personal cloud)
- You may rent a number of VPS servers by the month with 10 GB storage and deploy the storage service across them.

This is actually a distributed multi-agent system. So when you attempt to download a file
- there will be a list of files or things to download
- the downloads will be delegated across the agents or node (the goal)
- the agent will take incremental actions towards accomplishing the goal (the file will be downloaded into your personal cloud or personal botnet. Then once inside the network, the file will be replicated within your network, to where it needs to be consumed)

If you are encoding a video file
- the network is aware of locally available nodes and compute resources
- the video will be cut up and the pieces distributed over available compute resources

If you have a computer, a tablet and two cameras
- All devices will share a global networked file system
- When you take a photo on the camera, the photo will automatically be replicated and available to any other computer in your botnet or swarm or personal cloud

If you have fifteen drones with cameras
- they will automatically form a meshnet over wifi
- they will automatically replicate peer-to-peer, saved images

For the base level network there are new primitives
- Nodes
- Transports
- Routes

Node:
- A node is a thing (identified by a pubkey) that accepts and emits length prefixed messages.
- A node has a list of transports

Transport:
- A transport is a point-to-point connection between nodes (from Pubkey A to Pubkey B), for the emission and receipt of length prefixed messages.
- Transports are pluggable (are defined by an interface, that allows multiple transport implementations)
- A transport stores and forwards length prefixed messages between nodes

Routes:
- A route is a software defined networking, rule for forwarding length prefixed messages. In I2P they are called "tunnels" (however, it is not a darknet and we do not use onion routing and it is designed to be low latency). These are a primitive from MPLS.

Then on top of that, there will be another level of primitives for implementing
- RPCs
- pubsub
- point-to-point messaging (TOX type)
- federated messaging (XMPP type)
- asynchronous messaging (Email/Bitmessage Type)
- machine readable RPCs
- service discover
- multihoming (network bridges/tunnels)
- source independent networking (concept from Urbit, used heavily in Skycoin in the consensus algorithm)
- public broadcast channels (cryptographic primitive, similar to DHT but for peer-to-peer replication of messages signed by a particular host). There are three different types of public broadcast channel primitives or types, that are useful for developers.

Then on top of that layer, there is another layer, which includes the skycoin-exchange serves, services and application servers that expose machine readable RPCs.

Ignore Below Line:

Then on top of that, there will be more experimental projects

For the multi-agent system, it requires new primitives
- behaviors
- goals
- affordances (see: https://en.wikipedia.org/wiki/Affordance )
- predicates
- etc...

This part is the furthest away, because it requires a new programming language that satisfies particular mathematical invariants and symmetries
- algebraic (programs are constructed by application of a series of operators applied to a null object)
- abstract syntax tree based (it has no representation as a text file)
- Requires a metacircular interpreter
- Is deterministic (programs accept and emit length prefixed messages and the output is a deterministic function of the input)
- has a meta-syntactic operator
- supports COLA (combined object lambda architecture) type programming
- reflection (every program and object has a canonical serialization as a byte array)
- has a "choice" operator (the interpreter or executing object is given a choice between N things)
- transitive closure under particular mathematically operations (the ability to simulate ten individual processes or a network of computers, under a single process, with those processes able to in turn simulate other processes. Genode model.)

- The language will look exactly like Golang or C.
- The memory model is identical to C and the speed should be the same.

One of the things we need to do is
- take a program or code
- serialize it into a canonical representation as a byte string
- invoke the code on a remote server, by the hash of the byte serialization of the code

So example:
- each "swarm" or "personal cloud" or "personal botnet" will have a DHT (key-value store, with SHA256 hash mapping to the data which hashes to that value)
- An orchestration server will send message "Run project H1 (hash), with input data tuple (H2, H3). Then when it is done, the result will be H4 (The result is data that serializes to []byte that hashes to H4).
- (H1) (H2, H3), (H4)
- { program: H1, Input: (H2,H3), Output: H4 }
- Any program that runs H1 on (H2,H4) will get H4 as output
- If a compiler H1 compiles its own source code H2, then it should get H1 back.

For distributed functional reactive programming
- you give a tuple a label, (LABEL A, (H2,H3))
- you define (LABEL B, (RUN H1, A) ) //B is the output of running H1 on A
- you can use B somewhere
- when A is modified (an operator modifying A is applied to a blackboard shared between the processes), then the label B will be recomputed
- then any result depending on B, will then be recomputed
- One type of "blackboard" for posting transactions (such as modifying the assignment of a label), can be a blockchain (multi-owner consensus) or a public broadcast channel (single owner).

This can occur within a single process or program (such as rendering a web-page), or on a blackboard shared between multiple processes (distributed).

This area is an algorithmic goldmine
- I found a new type of codress messaging, that is immune to traffic analysis
- There appears to be a new type of simple cryptographic ratchet, that appears to be equivalent to a method of distribution of one-time pads over a public network, where an opponent cannot distinguish the correct decryption of a message, even if they have intercepted all messages in the stream of messages between x and y AND they have a turing machine, that can be run for an infinite number of steps (infinite computation). It can be shown using a proof from Kolmogorov complexity, that if certain conditions are met, that no function exists which can select the correct plaintext for a given encryption, even if all possible states of the cryptographic ratchet are exhaustingly tried, because no function exists which can determine the decryption (equivalently the probability distribution on the plaintext is uniform over the set of plaintext, given the message stream in the ratchet, even if the state of the ratchet and potential decryption can be enumerated exhaustively).
-- the most trivial case of this reduces to the case of if there are two parties, A and B with an unknown preshared key. A generates 512 bytes of random junk, then encrypts it with AES. Then sends the message to B. Someone intercepts this message and tries to "decrypt" it by exhaustively trying all possible AES keys. There does not exist a function f, that will determine the correct decryption, so having infinite computational power and exhaustive search of all AES keys, does nothing.
-- A cryptographic ratchet, between A and B, is a stream of messages between A and B, with a shared state S. The shared state S is updated as the stream of messages between A and B proceeds (based upon the content of the messages). Each message is encrypted with a function of S and as packets are send and ACKed, both A and B update S. S is used to derive encryption keys for the messages between A and B.
-- Kolmogorov complexity shows that for a stream of messages, that compressibility is equivalent to decryptability for an adversary with infinite computational resources.
-- If I encrypt "aaaaaaaaaaaaa" (compressible message) with ChaCha20, then the correct decryption (the correct key) is usually the key that produces the most compressible plaintext output. The compressibility of the plaintext output (size in bytes of smallest turing machine program that produces the output) can be used to define a Bayesian probability distribution over the plaintext and encryption key (or cryptographic ratchet state at each step in the message exchange process), with keys producing more compressible outputs being more likely.
-- for f(plain_text, key) = cipher_text. A 256 bit plaintext, encrypted with a 256 bit key, will have ~1  valid key for each plaintext input
--- for  f(plain_text, key) = cipher_text . A 256 bit plaintext, 512 bit key, 256 bit cipher output, there will be ~2^256 keys that generate the same cipher text for a specified plaintext
-- for f(plain_text, key) = cipher_text . A 256 bit plaintext, 128 bit key, 256 bit cipher output (example; ChaCha20 default usage), there will be ~1 key that generate the same cipher text for a specified plaintext
-- for f(plain_text, key) = cipher_text . A 256 bit plaintext, 128 bit key, 512 bit cipher output ...
--  for f(plain_text, key) = cipher_text . A 256 bit plaintext, 512 bit key, 512 bit cipher output ...
-- for an opponent that has the cipher text and can exhaustively try every possible encryption key, they will have different probabilities distributions over the plaintext, for the above cases. The entropy or sum(x of X for P(X), P(x) log2(P(x)) ) of the distribution P(x) (estimate of probability of cipher x was used, based upon the contents of what was recovered from the cipher text under this key). This "entropy" is how peaked the distribution P(x) is, determines a measure of "information leakage" per message, against an opponent with infinite computational power and who had intercepted all messages in a chain of messages.
-- This metric can be useful to make a particular algorithm "maximally annoying" by selecting the parameters that will make the most work, for an opponent with infinite computational resources and omniscient ability to intercept and record messages.
-- If you send junk (random noise, uniform distribution) and have no known plaintext in the message, for an opponent with infinite computational resources and interception ability, the best probability distribution for a given plain-text being sent, for a given intercepted ciphertext output is a uniform distribution (no information).
-- So under certain conditions, a message can be sent between two parties, which gives no information to attacker with infinite computational resources and the ability to intercept all messages. However, these types of messages can be accumulated into an entropy pool in a cryptographic ratchet.
-- Using the above argument, you can show that one-time pads can be securely distributed over a network (even if all messages are intercepted), assuming there exists a one-way function that is "strong" with respect to the adversary with finite computation, but perfect interception ability. By accumulating entropy from uniform distribution messages into the ratchet state, using the secure one way function and using the same function for deriving keys from a nonce and the ratchet state, then deriving the "one time pad" from a nonce and window over the ratchet state passed through the one way function.
-- ECDH can be used, but the ratchet and one-way function is stronger (has fewer assumptions, more frustrating for attacker with state resources or infinite computational ability), then just ECDH+ChaCha20. Even if an attacker has a "quantum computer" or can solve discrete logarithm in polynomial time, it will not help them much.
-- It is better to ratchet with a one-way compressible function AND ECDH, than just using ECDH
-- including any known plaintext inside of a message or any data that is non-uniform, repeated or compressible, reduces the theoretical entropy against an attacker with infinite computational resources and interception ability. If a nonce is a uniformly distributed, random 256 bit integer, then encrypting it and sending it does not reduce theoretical entropy (for attacker with infinite computation and perfect interception). Encrypting known plaintext or compressible text (error correction codes, attributes that can be computed from message such as length prefixes, or compressible attributes or sequence numbers) does reduce theoretical entropy. This is a consideration for what should be included in the encrypted part. Leaving some data out, makes traffic analysis easier but maximizes the entropy measure. The greatest reduction is in sending know plaintext (where attacker can guess the protocol being used and where the message content is non-uniform distribution. If you have a one-way function and can send N byte messages with 2*N bytes (double bandwidth usage), then it is possible to perfectly "randomize" even a null string, with respect to the entropy metric (assuming a one-way function).
- There are other methods of "frustration" that can be maximized for a ratchet, besides the entropy metric against attacker with infinite computational resources and perfect interception ability. Another metric is circuit size for 3-SAT and memory usage.
- There are other "frustration" metrics for traffic analysis and timing channel attacks (such as numbering and funneling all operations that require private keys into an input queue and only handling output queue every 5 ms, to prevent timing channel attacks from achieving temporal resolution greater than 5 ms). Constant time operations.
- For Deep Packet Inspection, a network where every packet is exactly 512 bytes in size would be "maximally frustrating", because the histogram of packet sizes would contain zero information. Constant sized packets.
- For traffic analysis, a connection where the rate packets are being sent over a time interval, is statistically independent of the rate packets are being received. Is maximally frustrating. Constant rate channel.
- Another "maximum frustration" metric is maximizing the volume and rate of data that must be exfiltrated, to reconstruct a stream.

There are some thing I do not believe should be open sourced. It would be problematic.

It is interesting to see Open Whisper Systems and Matrix starting to implement cryptographic ratchets.

did anyone got the opportunity to buy the last few weeks?

another 2 years untill ver 1.0
Long!

Skycoin,

Please just make it easy to purchase at a reasonable price as I have been wanting to get some for years but unable.

I think you should do a release of coins at the same price as original for the people who have been on this forum because some have been unable to accuire any and have been waiting and waiting.

Please create an easy method to purchase. If you had done this already I think you would have sold many coins to people like myself.

ICO price is about 45500 BTC marketcap?! right?

How many people would have bought skycoins if you had told them that you sell for the same price 1,5 years later?

I look this way on the incident. Series a funding 1,5 years ago. OF COURSE a better price than Series b funding today.
There is just one group whch won´t agree. People want to buy skycoins cheaper.

This is only for developers and people who compiled from source. A small amount. Distribution to developers.

There is the price that it is being sold at to developers (10M to 18M market cap for total). Then there is the price per coin you get by estimated position in coin rankings and given the free float (currently ~3.4% I think).

I did some mathematical modeling of the coin price and what will happen when it hits the market and starts trading. The people buying altcoins are putting a constant amount per day (ex. buying $500 a day, everyday, across a basket), regardless of the price. So the buying behavior is inelastic. They assume they will buy a basket of 10 alt-coins and may lose money on a few of them, but they will make 50x or 200x on a few and it will more than make their money back several times over.

Their strategy is
- "Invest a constant amount of money per day across the basket, without looking at the current price". Ex $500 per day across a weighted basket of altcoins
- "When the price of a coin in the basket goes up 100%, sell off 20% of holdings of that altcoin"
- put the money in the earnings pools back into #1
- If the price goes down, do nothing, because we only care about the upside

These are the "Turtles" traders.

The other coins have mining and so miners are constantly selling off the alts, to buy Bitcoin or hoard their "home coin", that they keep their profits in long term. The miners are constantly dumping coins on the sell side. Skycoin does not have mining, so will respond in a very chaotic way to inelastic capital inflows. It has no dampening or stabilizing outflows.

If you wait long enough, you will be able to sell it at any price. Eventually it hits every price.

Psychologically, I think the market makers take the coins and rank them by how easily they can be sold and especially how much they can potentially be pumped. They are especially focused on the upside only. Then they look at the free float and think "This coin is easier to pump than #4 and #4 is 25 million market cap". Then they divide the free float into the estimated market cap from the position ranking, to get the price per coin. Since we have a small free float, that gives us a very large number compared to the ICO price.

So we have some estimate of what the price will be, after the coin floats.

So we decided that arguing about whether the price should be 2500 SKY/BTC or whether we should increase it, is arguing about whether you bought Litecoin at $0.01 or $0.05 per LTC, when the price is at $25.

I like the 2500 SKY/BTC peg, until it floats because the rule is simple. I do not have to say "I think the price is 2200 SKY/BTC today" and have a man behind the curtain making the price go up and down for no reason. This is one of the community division issues, where its impossible to get everyone to agree.

What kind of ether will you plan? Eth or Etc

>When i invested in this coin i was single
>Now im married and have 2 kids

LOL. R&D work is slow. It took us two years of research, trial and error and prototyping to figure out how to solve particular problems.

There is no longer any coherent explanation for what we are developing, that will make sense to 95% of people.

Q: "How is it different from Bitcoin?" A: "No duplicate coinbase outputs", "No miners", "No transaction malleability", "No signature malleability".

"The skycoin UXTO/TX graph is a directed bipartrate graph, while Bitcoin has a multi-graph." Explaining the different, does anyone care?

The coin is more a series of mathematical properties and constraints that the implementation must obey.
- The properties the consensus algorithm needed to have (constraints), imposed the consensus algorithm we developed
- The requirement for bounded memory usage, imposed the transaction graph structure and way things were done differently than Bitcoin
- The properties that the networking and communications between nodes (source independence, immunity to various attacks), imposed the "meshnet" (really an overlay network, that can be used to build meshnets, but has nothing to do with meshnets)
- The properties for minimizing damage during blockchain forks imposed the constraints of no signature malleability, no transaction malleability, no duplicate coinbase outputs and a functional/stateless UXTO state that did not depend on previous blocks or which block a transaction was included in. It is actually possible to do consensus over a partial ordering of transactions (directed bipartite graph). Technically do not even need a total ordering over the transactions (application to distributed database systems, because allows distributed writes without a central master or needing to lock).

It is like having to invent calculus, so that you can solve a physics problem, then complaining it took so long. Some of the things are Urbit level and they do not even have names.
- "I think I will call this crypto thing a public broadcast channel"
- "I will call this a blip blop replicator"
- "This type of software defined networking, lets call it a meshnet"
- In Bitcoin the process of creating coins, doing consensus and introducing new transactions into the ledger are the same. In Skycoin, they are separate and orthogonal and can be swapped out because they are not coupled with each other at all. If we can do consensus on the equivalence classes of the bipartite graph of UXTOs and TX, then we might not even need a blockchain at all. Any two arrays of transactions are equivalent, as long as they map to the same UXTO/TX bipartite graph. So this leads into "post-blockchain".

We are behind schedule, in clock time, but geopolitically we are on schedule. After all, only a crisis, real or imagined, produces change.

I want to close out the coin part and get it listed and have all the requirements finished. Its about time.

Update:

Brief

Going through the launch check list

Mostly check commit log:
- https://github.com/skycoin/skycoin

- block storage is done. Key/value store. boltdb. memory mapped files
- blockchain history API is done. GUI is in progress.
- first version of website is done. Second version in progress, then will be on domain. will post screenshots soon
- some consensus simulations using random mean field sampling are in the repo in the /src/ directory now. We have someone starting on the public broadcast channel implementation and then remaining integration tasks. This should not block exchange listing, but may drag on for a while.
- fifty tickets on UI and GUI bug fixes. Everything critical fixed.

Todo:
- CLI for exchanges
- WebRPC API for exchanges and documentation
- GUI for blockchain history API

Wallet:

We have +50 tickets on development tasks for wallet QA, bugs, improvements and user interface behavior.

We are transitioning towards an electrum style wallet.




Also going from mockups to implementation for the blockchain explorer (required for the exchanges to do customer service and dispute resolution).





Misc: Exchange Listing Checklist

Of the five things that were required, three of them are now done.
- block storage is done
- blockchain history API is done
- website is done

The last thing that is required is now
- CLI + WebRPC client for exchanges + documentation (required for exchange listing)
- Blockchain explorer front-end (required for exchange list. This was supposed to be done two days ago, but have not checked yet).
- documentation, info-graphics and technical information on website (this will be iterative over months)
- consensus integration (this is not blocking anything)

Our first exchange integration for testing and QA will be with a darkpool liquidity provider/market maker who sits on both sides of the order book and arbitrages from the major exchanges across multiple coins. Then will work on the large exchanges.

I think we have the APIs in place for automatic conversion between Bitcoin and Skycoin, in the wallet, so we can do something like Ethereum's "ShapeShift".

Then after launch, wallet and future improvements
- Add Shapeshift
- Add multicoin support (Skycoin, Bitcoin, Ethereum)
- Electrum style interface
- Wallet encryption

Misc

I want to say more about project management and changes and how we are dealing with this, but would be too long.

We are spawning off different project groups, with a single focus (website, marketing, coin, wallet QA, meshnet, applications, build/DevOps, consensus, exchange integration, mobile wallet team, project manager for customer facing applications for tech that was spun off or licensed to corporate clients, etc...). For development we are doing one to three developers per area and each developer has single focus or task.

"The last 10% is 90% of the work", is especially true for launching. Getting everything that needs to be in place ready, is a time sink. I think its taking six people, two months to get the requirements for listing done after the coin was "finished" and "working".

So now we are focusing on one or two top priorities at a time and then assigning resources to them, to make incremental progress. Instead of doing long term R&D and research of indefinite duration. We are also delegating or spinning off as many project groups we can and getting dedicated project managers to manage particular sub-projects. (wallet QA and wallet improvements has dedicated project manager now).

Now that's a marketing speech I haven't heard before. Did it also add more inches to your penis?

When i invested in this coin i was single

Now im married and have 2 kids