Bitcoin Forum
October 22, 2021, 06:59:45 PM *
News: Latest Bitcoin Core release: 22.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 [68] 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 ... 200 »
  Print  
Author Topic: [SKY] Skycoin Launch Announcement  (Read 381231 times)
skycoin
Hero Member
*****
Offline Offline

Activity: 498
Merit: 500


View Profile WWW
October 03, 2014, 07:04:01 PM
 #1341

Update

Blockchain is still syncing It is on block 304,608. 36,000 blocks to go, before we can check Bitcoin address balances.

The wiki is getting filled in. We are putting tutorials here and technical documentation for components that need implementation (bounties). https://github.com/skycoin/skycoin/wiki

1634929185
Hero Member
*
Offline Offline

Posts: 1634929185

View Profile Personal Message (Offline)

Ignore
1634929185
Reply with quote  #2

1634929185
Report to moderator
1634929185
Hero Member
*
Offline Offline

Posts: 1634929185

View Profile Personal Message (Offline)

Ignore
1634929185
Reply with quote  #2

1634929185
Report to moderator
"Bitcoin: the cutting edge of begging technology." -- Giraffe.BTC
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1634929185
Hero Member
*
Offline Offline

Posts: 1634929185

View Profile Personal Message (Offline)

Ignore
1634929185
Reply with quote  #2

1634929185
Report to moderator
1634929185
Hero Member
*
Offline Offline

Posts: 1634929185

View Profile Personal Message (Offline)

Ignore
1634929185
Reply with quote  #2

1634929185
Report to moderator
nonlinearboy
Hero Member
*****
Offline Offline

Activity: 705
Merit: 500



View Profile
October 06, 2014, 02:01:49 AM
 #1342

Update

Blockchain is still syncing It is on block 304,608. 36,000 blocks to go, before we can check Bitcoin address balances.

The wiki is getting filled in. We are putting tutorials here and technical documentation for components that need implementation (bounties). https://github.com/skycoin/skycoin/wiki

we will wait for the update.
michaelb87
Sr. Member
****
Offline Offline

Activity: 364
Merit: 250


View Profile
October 06, 2014, 01:55:03 PM
 #1343

Is the IPO starting anytime soon or what? It's been a while now, waiting for an update.
check07
Member
**
Offline Offline

Activity: 78
Merit: 10


View Profile
October 06, 2014, 03:11:48 PM
 #1344

Is the IPO starting anytime soon or what? It's been a while now, waiting for an update.


When will run IPO?
LemonAndFries
Sr. Member
****
Offline Offline

Activity: 462
Merit: 250


View Profile
October 06, 2014, 04:36:11 PM
 #1345

Details on how to join IPO would be good
nonlinearboy
Hero Member
*****
Offline Offline

Activity: 705
Merit: 500



View Profile
October 09, 2014, 10:38:23 AM
 #1346

Details on how to join IPO would be good
still no details for the IPO?
constary
Sr. Member
****
Offline Offline

Activity: 308
Merit: 250


View Profile
October 09, 2014, 01:32:25 PM
 #1347

Details on how to join IPO would be good
still no details for the IPO?
NO
Corleone1918
Sr. Member
****
Offline Offline

Activity: 248
Merit: 250


View Profile
October 10, 2014, 10:10:54 AM
 #1348

wait for ipo  Grin
gs02xzz
Full Member
***
Offline Offline

Activity: 221
Merit: 100


View Profile
October 13, 2014, 01:59:00 PM
 #1349

Interesting article - http://blogs.wsj.com/accelerators/2014/10/10/weekend-read-the-imminent-decentralized-computing-revolution/
skycoin
Hero Member
*****
Offline Offline

Activity: 498
Merit: 500


View Profile WWW
October 17, 2014, 09:53:49 AM
Last edit: October 17, 2014, 06:12:10 PM by skycoin
 #1350

Update:

Consensus Simulation:

Here is basic python simulation of the Skycoin consensus process http://pastebin.com/5DJ9d29D

We dont have much time for academic details until its done, but found that Ben-Or's consensus process could be modeled used a mathematical model called a "spin glass". https://en.wikipedia.org/wiki/Spin_glass

Each node has a state. Each node is subscribed to a subset of nodes in the network. There is a local function (a function of the node's state and the state of the nodes it is subscribed to) that can be called "energy". The "energy" of the network is the sum of the energy of each node. The network has achieved consensus (all nodes are in the same state), when the energy is minimized. A node changes its state at each round, to minimize its energy function. Through local energy minimization, it can be proved that the global energy reaches a minimum within a finite time bound for a particular type of network topology and update rule.

Spin glass are mathematically equivalent to 2-SAT/3-SAT optimization problems and several messaging passing algorithms on graphs have been proposed with known scaling laws and performance guarantees. This leads into analogies of Belief Propagation and Survey Propagation, where nodes pass more powerful state information to each other and the network can reach a convergent state faster. Normally, it can require exponential time for a network to reach the ground state if the energy function is too complicated (3-SAT). However, in Skycoin type consensus network the energy function is a 2-SAT problem at worse and actually more trivial than that (convergence through local hill climbing). Worse case network topology for 2-SAT makes number of rounds to convergence linear in the number of nodes (linear time in number of rounds for distributed process of N nodes, but quadratic time big O runtime for a centralized process). For "average" random graph the problem appears to be trivial and the system reaches the minimum through message passing, extremely quickly for even most basic stochastic local hill climbing update rule.

We do not have a proof yet, but the time to consensus seems to scales no worse than the square root of the number of nodes for a random graph at worse, but is usually logarithmic in the number of nodes in the network for most update rules. For a graph with a power law connection rule with preferential attachment, the convergence time appears very good in simulation. It does not change noticeably with graph size.

We have found that almost all the update rules for message passing result in network convergence. However, some rules are not "robust" in the sense that a relatively small number of colluding nodes are able to prevent network convergence and delay convergence indefinitely. In the real world, this may not matter because the required tie condition occurs rarely (worse case) and nodes blocking convergence would be detected and people would remove them from their trust lists. Some rule sets result in faster convergence, but may make it easier for malicious nodes to influence the network.

There are suggestions that there exist messages with augmented state information that would allow faster convergence and allow a node to partition the nodes they are following into two sets and apply meta-rules for adding/removing node relationships, expelling "bad" nodes to a disconnected/disjoint sub-graph.

There will be many changes after launch. This is a whole new area that needs work.

Measuring the Influence of Nodes

In Bitcoin, the two largest mining pools completely control the network. Together they control 51% of the hash rate and could attack the network, exchanges and gambling sites if they chose to. Mining has led to a severe concentration of power in the hands of a small group. The number of people who must collude to attack the network is much smaller than Satoshi intended.

In Skycoin the objective is to keep network control decentralized enough that a successful attack requires collusion of at-least a few hundred highly respected and trusted people (an unlikely conspiracy) and then minimizing the scope of damage that could result even then.

We need a measure of power or influence, in the Skycoin network, that allows us to compute whether a sub-graph of nodes has enough influence to carry out an attack in collusion. We would also like a visible measure of power of individual nodes, so that people can re-balance their node subscriptions to prevent any node in the network from obtaining too much influence.

We believe the influence of a node in the simple consensus system, can be approximated well using a page rank type algorithm. The link adjacency matrix is constructed, such that A_ij equals 1 if node i subscribes to node j and is zero otherwise. We normalize each row to 1 to get the modified link adjacency matrix. The "page rank" or power rating of the ith node is the ith entry of the dominate eigenvector of the modified adjacency matrix for the network graph.

The dominant eigenvector of the modified link adjacency matrix A, can be quickly computed by choosing a random vector, applying A to it by multiplication, normalizing the result and repeating successively with the resulting vector as the new input, until convergence.
Example x <- A*x / ||A*x||, while || x - (A*x / ||A*x||) || < ε  (multiply A*x, normalize result, feed it back in)

This simple metric gives an approximate ordering of the most trusted and influential nodes in the network.

Development News

I am not sure what is left until the IPO. I think the Python scripts are done.
- python scripts
- verify that loading deterministic wallet loading is working in the GUI
- start IPO?

There is a split between the active development branch and the IPO branch because of a networking library golang dependency. The IPO branch daemon wont compile with the updated networking library and the new Daemon is not ready to replace the Daemon implementation in the IPO branch. However, this should not affect the IPO as the existing client should still compile and run. Doing a huge refactor instead of a series of very small refactors that kept the software working was a major mistake and setback.

The darknet prototype is now running over Tox. Tox allows communication via public key, has UDP hole-punch working and has good binary data performance and latency. Using Tox as start point will allow us to get a prototype working faster and defer implementing public key to IP address DHT look-up. It also allows back-communication to distributed service servers over the darknet, before the asynchronous messaging implementation is done (which was a major problem/hurdle for implementing darknet application servers).

In a typical darknet application, you have a website with static pages. The public key owning the pages signs the data with their private key and the data is replicated peer-to-peer between the subscribers to the application. This is good for publishing static content and files. However, sometimes you need to make an API call to the application server (such as updating a wiki page). It was possible to subscribe, but not to communicate back to the public key controlling the server. Now the application can give a Tox public key that can be used as a communication end-point for API calls on the application server.

Skycoin distributed applications previously used Ether, then Aether but now uses Merkle-DAG as the standard format. Implementation documentation and the Merkle-DAG spec is being written up now.

Merkle-DAG is Skycoin's distributed file system. Merkle-DAG is like Bitorrent, but lets you make updates to files after publication. You generate a public key, then sign updates with your private key. The updates are replicated peer-to-peer between subscribers. Merkle-DAG replaces the ad-hoc replication that was previously used for publishing personal block-chains and distributed applications.

Coinmin
Sr. Member
****
Offline Offline

Activity: 483
Merit: 250


View Profile
October 17, 2014, 11:24:46 PM
 #1351

Very and very innovative coin. I am in!
coin@coin
Legendary
*
Offline Offline

Activity: 1722
Merit: 1000



View Profile
October 18, 2014, 03:03:33 AM
 #1352

Appreciate the update!
Not in a rush for the IPO, I like the fact the project keeps moving.
At every update we seem to get closer and closer to launch.
Keep up the good work! Smiley Wink

 
Wit22
Member
**
Offline Offline

Activity: 103
Merit: 10


View Profile
October 19, 2014, 04:26:18 AM
 #1353

Been following this for months.
I think it looks very promising.
Well done on all of your hard work.
kingscrown
Hero Member
*****
Offline Offline

Activity: 672
Merit: 500


http://fuk.io - check it out!


View Profile WWW
October 22, 2014, 01:08:09 AM
 #1354

i doubt it will ever launch heh

PurpleTentacle
Sr. Member
****
Offline Offline

Activity: 384
Merit: 250



View Profile
October 22, 2014, 05:42:32 AM
 #1355

i doubt it will ever launch heh

yeah, but if it launches, it's gonna go to pluto...

Corleone1918
Sr. Member
****
Offline Offline

Activity: 248
Merit: 250


View Profile
October 28, 2014, 04:15:17 AM
 #1356

i doubt it will ever launch heh

 Huh Huh Huh
-Greed-
Hero Member
*****
Offline Offline

Activity: 910
Merit: 1000


Decentralized Jihad


View Profile
October 28, 2014, 03:30:38 PM
 #1357

i doubt it will ever launch heh

yeah, but if it launches, it's gonna go to pluto...
No, not in these times. The time has run out.

Corleone1918
Sr. Member
****
Offline Offline

Activity: 248
Merit: 250


View Profile
October 30, 2014, 03:36:00 PM
 #1358


yes , this project is deading.
coin@coin
Legendary
*
Offline Offline

Activity: 1722
Merit: 1000



View Profile
October 31, 2014, 03:43:28 AM
 #1359

I believe the project is kicking and well alive. Consider that this is not just a QT Wallet for a coin, this is a whole new ecosystem of apps and protocols that will eventually work in unison. Certainly not something that can be done overnight. I'm not trying to compare here but as an example look at Maidsafe, they raised money and nothing much I've heard of since.

Before they even announce the IPO (I'm not a fan of them but they are needed to raise funds for development) better be sure the basics are working and set for a smooth start. For a project of this nature to scale up and get support from the community, it needs very solid foundations.

This is only my opinion. I followed this thread since the start and would love to see the project coming to fruition. I much prefer a dev team working quietly, without distractions, that launches with something concrete and functional.
skycoin
Hero Member
*****
Offline Offline

Activity: 498
Merit: 500


View Profile WWW
October 31, 2014, 07:27:33 AM
 #1360

Project Update:

Everything is going very rapidly. We will be out of new things to code within a finite amount of time on the current trajectory. All the project goals will have been achieved and then we need to figure out what happens next.

1> We must finish the developer documentation and tutorials.
2> We must do the IPO.

When we started development, Golang was experimental and frustrating. Build reproducability was difficult, developers were stepping on each others toes and debugging goroutines was impossible. The Golang tool chain is maturing rapidly. Many problems we had a year ago are solved.

For organization, we found the best thing is to put everything on github. Use the github wiki, use the github issue tracker for bounties. The project is being split up into coherent logical blocks. We did not know the best way to split up the components of the project until everything was implemented.

Reflections on Consensus:

In the last year there has more formal research into Skycoin type consensus algorithms. We are confident that mining will soon no longer be a requirement for blockchain security or consensus. There is on going explosion of formal research (see: SybilLimit https://www.comp.nus.edu.sg/~yuhf/yuh-sybillimit.pdf ).

As we developed and refined the consensus algorithm, it went from simple to complex and then back to simple. One of the requirements is that it worked and was only a few thousand lines of code (so that it could be audited) and edge cases and flow paths were minimized. As the algorithm was examined through different facets, we found the core and were able to determine what class of attacks were acceptable and which attacks were existential and unacceptable (primarily attacks resulting in financial loses). The elegance of implementation is only possible because the implementation rests upon several layers of libraries for implementing new cryptographic and networking constructs.

The last of these primitives are designed and implementation is proceeding. Documentation is becoming important as Skycoin is not the only application that requires these components.

Reflections on Requirements for Distributed Applications:

There have been advances in containerization and sandboxed runtime environments (Docker, pNaCl). Recent application sandboxes are coming close to meeting Skycoin project security requirements. Many things that we believed we would need to write ourselves, have begun appearing.

The basic requirement for the Skycoin distributed application and "personal cloud" infrastructure were
- ability to run sandboxed services (processes identified by a public-key)
- separation between configuration and data storage for services
- sandboxed networking (networking only through execution environment API)
- sandboxed disc access (each process occupies its own encapsilated disc environment, shared storage by remote application exposing the disc as a service over the network)
- ability to run process in full emulation (for untrusted code), with option to compile down to native code for performance
- sound, video and other privileged services exposed by services (processes) over network
- LLVM intermediate representation for deterministic builds for C, C++, Golang (platform independent when builds are run within emulated build environment through bootstrapping process).

Tools such as emscripten allow us to achieve this easily in a javascript emulation environment for C,C++, Golang and Python. A full tool-chain may be possible with a simple emulator and single LLVM backend from LLVM intermediate form to the emulator language. The emulator language itself will be stripped down version of LLVM intermediate form.

The existing sandbox executes javascript with Google's V8 interpreter and does not have disc or network access.  Distributed applications are still waiting on implementation of infrastructure components required to build a useful application.

Reflections on Skycoin Communication Infrastructure:

Tox has solved many of problems we are facing, for messaging nodes by public-key. Tox was forced to use the Kadmellia type DHT and leaks metadata and timing information, which is undesirable. We have a document for new DHT infrastructure that would alleviate many of these problems.

As Tox is working and duplicates functionality required by Skywire, we are using it for prototyping the darknet. Tox does not protect IP identities of the public key. However, the functionality for finding and messaging nodes by public key is working which is the important thing.

We may introduce a "Connection" interface class to allow new connection types in the future, deprecate TCP/IP and move all existing Skycoin/Skywire communications over Tox. The dependencies are minimal and it appears that Tox can be built by the golang built tool.

The Tox project is very close to what we will end up with, however with a few changes.
Tox uses NaCl, Curve25519, Salsa20, SHA512.
- We would recommend Secp256k1,ChaCha20, SHA256
-- for standardization with Skycoin primitives.
-- for 32 bit performance
-- secp256k1 acts as a "coal mine canary". When algorithm becomes broken, Bitcoins will be stolen.
- We would recommend implementation of new type of DHT to replace existing peer look-up system
-- value is not Hash(key) but where the key is 20 byte hash of secp256k1 public key and the value is {KEY}, { POW, SEQ, EXPIRE, DATAHASH, SIGNATURE}, {DATA}.  (There is Key, Header, Value).
--- POW is a 20 byte proof of work (anti-spam)
--- SEQ is 32 bit number that is incremented on update (DHT nodes replicate value with highest SEQ number for the key. SEQ may be unix time at publication)
--- EXPIRE is the expiration date in unix time
--- DATAHASH is SHA256 of binary data in the key-value entry.
--- DATA is the 32 bit length prefixed contents of the key -> value
-- DHT nodes replicate tuples peer-to-peer. Invalid headers are discarded.
-- The public key is extracted from the sigature. The public key is hashed. The key must be hash of public key.
- The signature is set to zero and serialization hashed with SHA256. Alternatively a subset of the fields is hashed (insuring immutability, inability of 3rd parties to modify data without invalidating the signature/hash). The signature must be a valid signature for the extracted pubkey and for the resulting hash.
- Tuple Serialization / Network Format:
-- For serialization of structs/headers, for future proofing and cross platform implementation, { KEY, POW, SEQ, EXPIRE, HEADERHASH, SIGNATURE, DATA } is serialized as a map. [(int16,int16,data), (int16,int16,data), ...].  Each element has int (ex. KEY = 1, POW = 2, SEQ = 3, EXPIRE = 4, DATAHASE = 5, SIGNATURE = 6), length prefix for binary data, then binary data follows as bytes.
-- New fields may be added or removed as protocol evolves, without breaking compatibility / serialization.
- Cryptography Serialization
-- Signatures are 64+1 bytes (compressed secp256k1 signature plus recovery byte. Only non-malleable signatures are valid)
-- Pubkey Keys are 33 bytes (compressed secpk256k1 pubkeys. Compression is required.)
-- Pubkey hashes (Addresses) are 20 bytes. Address = {ripmd160(SHA256(SHA256(Pubkey)), VersionByte}. A one byte version byte is post-fixed to end of address (for upgrading curve in future). Default version byte value is 0.
-- Address serialization is base64. The 21 byte address serializes to 28 characters. ex. LS0tIFBPVyBpcyBhIDIwIGJ5dGU
- Peer Discovery Through DHT
-- This system allows contents of the DHT entry to be updated (unlike Kadmelia DHT). However it requires a new protcol to be throughout for friend requests. This needs to be worked out
- DHT Replication
-- Each DHT node should fully replicate every DHT entry in network (full replication, not Kademlia)
-- privacy (currently sybil attack appears successful at determining nodes making queries for particular pubkeys)
-- simpler replication, reduced complexity from Kadmelia. Increased bandwidth/storage usage.
-- DHT replication can now run "within TOX" through TOX network, without external UDP queries leaking metadata
-- There may be optional "Selector" in DHT
--- some nodes may choose to only replicate portion of network, when cost of full replication becomes too great (support single application DHT key sets). Alternatively, nodes may start dropping the entry with lowest POW.
-- Format supports multiple types of DHT and evolving DHT implementations as required.

This new DHT system is very similar to Bitmessage. However, instead of sending messages it gives each public key an area it can write to and update. You could call it a bitmessage-DNS system. This system supports the case where you want only people who know your pubkey to know things and when you want to publish something publicly to everyone (such as route information).

We will end up reimplementing something with same functionality as Tox, but slightly different. However for now, we can prototype the higher layers on top of Tox and save time.

We intially thought there were two layers to the darknet routing network. However, the lowest layer ended up being nodes with public keys which are identified with published IP addresses and accept connections from the public. Then there are nodes that are only privately peered. The network topology is mostly public for the purpose of finding routes, but there is no correspondence between the public keys of the node and an IP address.

This produces a new kind of pseudonyous networking. There are two kind of pseudonymity.
- There is no relationship between IP addresses and node public keys (unless the node is publicly advertising and peering with the public).
- A node passing traffic can only identify the previous and next hop for the traffic, not the origin or the destination for the traffic.

However this type of pseudonymity creates three problems
1. Resource exhaustion attacks, route exhaustion (one node creating 10,000 routes cannot be differentiated from 10,000 nodes creating 1 route)
2. in a pseudonymous network, nothing stops leaching so the performance will be bad without a financial incentive
3. Nodes may lie about performance or route information. Bots may lie.

#1 is difficult. The attack requires as much resources for the attacker as the person being attacked. IP/TCP/UDP suffers from a similar attack. If a router can switch 10 Gb/s to a particular port and you send 10 Gb/s to an IP with destination on that port, it will cause packets to drop. The failure case for stateful networking is not dropped packets, but is that attempts to create new routes through that node will fail. However, many of these attacks only affect nodes with public peering.
#2 can be solved through coin incentives. This is relatively easy. Leachers will end up competing with other leachers for bandwidth in the leacher pool, but leachers wont be competing with the non-leachers for bandwidth.
#3 is difficult. You need one or more trusted source of 3rd party route and performance information. There is no "trust-less" way of doing this. It might be as simple as having bunch of people crawl the network and publishing data. A solution to this will develop over time. It will be incremental.

Once implementation is done, we have to deal with other problems. It is not clear why Tor is more successful than I2P. Tor has about 2 million users a day, so its still niche. Just getting the network working and ensuring it is well designed is not enough. We have to ensure that there are applications that will drive adaption.

Pages: « 1 ... 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 [68] 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 ... 200 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!