Development Update:
Aether is coming along well. Soon development discussion will be moved into Aether. Coin bounties will be assigned for developing communication tools on Aether.
For instance
- user creates private/public key pair
- user publishes stream of tweets (as JSON) into blockchain and signs each block with their private key
- user subscribes to another person's feed
-- user takes hash (address) of person they want to subscribe to
-- user looks up peers replicating the chain via DHT
-- user connects to the peers and downloads the chain (which is replicated P2P)
- web server on local hosts, allows person to see feeds of people they are pulling in
Most of this is two lines of code in Skywire, so the work is creating a service in Golang and then taking the JSON and creating an HTML interface from it. This is a sort of "App" on top of Aether/Skycoin. Aether also implements a key-value store, which is probably more useful than blockchain for these types of apps.
Twitter is easiest to implement. It is not more difficult to implement a twitter clone on top of Aether than it is to implement one with Redis. Twitter is easiest to implement, because in distributed twitter, each user controls their own feed data.
We also want
- a distributed forum
- a distributed reddit
- messaging (email replacement. most difficult)
- a distributed wiki
These will be used for coordinating development and building up the user community.
For a forum, the forum data would be controlled by a single public key. A user submitting something to forum, would message the forum with a signed message, then it would trigger API and forum server would update the forum data.
For a wiki, each key/value stores a page. The wiki data is controlled by a single public key. Users submit messages to the wiki server, the wiki server updates the data for the page. The updates are replicated peer-to-peer between subscribers to the Aether store. One key has AngularJS for generating the HTML website from the data in Aether.
For application distribution we have three options
1. make people pull the service/app from github
2. have key value store and put Javascript in key 0 (using AngularJS), that gives information for how to render the page and APIs. This means an "app" is javascript that generates the HTML locally and can call a limited number of APIs
3. Have a sandboxed, minimal virtual machine which apps are compiled down into. This is the best long-term solution, but we will use AngularJS until we can get this developed and it meets our security/quality standards.
Topic: [SKY] Skycoin Launch Announcement - page 146. (Read 381579 times)
Well I've been following for a very long time as well though I haven't really posted in this thread...anyways, the meshnet is the most important part of all this so hopefully there will be some sort of working implementation soon.
2nd generation rules 
Development Update:
The darknet repo has been removed and moved into Skywire and Whitepaper.
Two thousand lines of coin have been removed from Skywire. It does the same thing, is much cleaner now. The daemon almost works. Will have some development documentation and sample apps soon.
The remaining issues for the meshnet/darknet have been worked out, specifically
- preventing circular routes (denial of service)
- allowing multi-hop routes to be established quickly without incurring round trip latency for each hop
- binary wire protocol format
There is architectural issue, about the relationship between gnet, Skywire and the relay service. It was not clear whether these should be merged into a single library or whether the darknet router should be a service in Skywire or if Skywire should sit on top of the darknet. There are several constraints
- the lowest level router must be something that can be implemented in C and has small ASIC foot print
- there has to be separation between the Golang layer and C layer
- some components such as DHT, operate both on the darknet and over UDP over IP
The darknet router service was originally going to be a service in Skywire, but it will now be an independent implementation with Skywire connectivity being built over the darknet.
The darknet router has to handle several cases
- connectivity between nodes over public IP
- connectivity between nodes over private ethernet segment (nodes connected over IP but not necessarily connected over public internet)
- nodes which are connected and peered over wifi
- nodes which are connected over darknet through routes over the darknet, but where there is not not necessarily direct connectivity
This is complicated by there being different types of connectivity
- a node could be directly connected to another node over TCP/ip
- a node could advertise connectivity from multiple 3rd party nodes (TOR hidden service type operation). For instance, an application creates routes to four nodes and then advertise that you can connect to the application from routes to any of those four nodes. The person connecting only knows the intermediate, advertised nodes. The advertised nodes only each know the previous hop in route for node connecting to them, but does not know the origin node identity.
This was confusing, until we figured out that there are actually two identities and pubkeys
- one pubkey is for the router. Only one computer is allowed to run with each pubkey. The pubkey identifies a unique router and each router has a particular connection topology to the other routers. The connection topography is public. These represent the physical routing topography of the network.
- one pubkey is for the application or service. An application or service can establish connectivity to a router and advertise connectivity to the service, from that router. To connect to an application, you need to know a router that is advertising the application and you need the application pubkey.
In other words, router addresses are not necessarily the terminal point for routes. This is not intuitive at all, but there are several reasons to separate out the topology for physically routing messages and the 0addresses for communication end-points (addresses that receive messages). In IP we take it for granted that routers and communication end-points are in the same address space, but this assumption complicates the design of the darknet. This also means that communication end-points on the network are intrinsically multi-home.
The darknet repo has been removed and moved into Skywire and Whitepaper.
Two thousand lines of coin have been removed from Skywire. It does the same thing, is much cleaner now. The daemon almost works. Will have some development documentation and sample apps soon.
The remaining issues for the meshnet/darknet have been worked out, specifically
- preventing circular routes (denial of service)
- allowing multi-hop routes to be established quickly without incurring round trip latency for each hop
- binary wire protocol format
There is architectural issue, about the relationship between gnet, Skywire and the relay service. It was not clear whether these should be merged into a single library or whether the darknet router should be a service in Skywire or if Skywire should sit on top of the darknet. There are several constraints
- the lowest level router must be something that can be implemented in C and has small ASIC foot print
- there has to be separation between the Golang layer and C layer
- some components such as DHT, operate both on the darknet and over UDP over IP
The darknet router service was originally going to be a service in Skywire, but it will now be an independent implementation with Skywire connectivity being built over the darknet.
The darknet router has to handle several cases
- connectivity between nodes over public IP
- connectivity between nodes over private ethernet segment (nodes connected over IP but not necessarily connected over public internet)
- nodes which are connected and peered over wifi
- nodes which are connected over darknet through routes over the darknet, but where there is not not necessarily direct connectivity
This is complicated by there being different types of connectivity
- a node could be directly connected to another node over TCP/ip
- a node could advertise connectivity from multiple 3rd party nodes (TOR hidden service type operation). For instance, an application creates routes to four nodes and then advertise that you can connect to the application from routes to any of those four nodes. The person connecting only knows the intermediate, advertised nodes. The advertised nodes only each know the previous hop in route for node connecting to them, but does not know the origin node identity.
This was confusing, until we figured out that there are actually two identities and pubkeys
- one pubkey is for the router. Only one computer is allowed to run with each pubkey. The pubkey identifies a unique router and each router has a particular connection topology to the other routers. The connection topography is public. These represent the physical routing topography of the network.
- one pubkey is for the application or service. An application or service can establish connectivity to a router and advertise connectivity to the service, from that router. To connect to an application, you need to know a router that is advertising the application and you need the application pubkey.
In other words, router addresses are not necessarily the terminal point for routes. This is not intuitive at all, but there are several reasons to separate out the topology for physically routing messages and the 0addresses for communication end-points (addresses that receive messages). In IP we take it for granted that routers and communication end-points are in the same address space, but this assumption complicates the design of the darknet. This also means that communication end-points on the network are intrinsically multi-home.
if it will be cheaper when it hits exchange
But seriously, I am curious about this IPO thing. I did a quick research and I came to conclusion that most people on bitcointalk believe that usually most IPO's fail to bring the investors any money. Someone mentioned that actually only few IPO's were price-wise succesful. I am trying to understand, why would I want to buy the coin in IPO if it will be cheaper when it hits exchange and it would be more beneficial to buy it then.
That is true. Smart people buy into IPOs for the long haul. Most people lose money with IPOs anyways. That's what I believe in too.
The reason is that it's so hard to pick and choose the coins/stocks that will succeed the best. This applies in the financial market as well.
http://www.amazon.com/Millionaire-Teacher-Wealth-Should-Learned/dp/0470830069
That is why most people recommend a strategy in which you use index funds, ie. you buy all the stocks.
Quote
The real question is, why do we recommend index funds to so many people here, and then, why do we recommend Vanguard's in particular?
In order to have a good shot at a secure, reasonably well funded retirement, most of us will need to have some portfolio of stocks (and bonds, but let's just talk about stocks for now; the same arguments I'm going to present for stocks apply to bonds). So how do we get those stocks?
You could pick them. That's what people did back in the day and that's what some people do now. There are various stock picking theories, and I won't go into what they are. If you're into that, great; I'm not going to discourage you from doing what you believe is the best way to achieve your financial goals. And if you beat the market, even better. But very few people will do so, and those that do will spend a great deal of time doing it (as will many that don't).
If you aren't picking stocks, you still need to have some. It's just that your best bet at that point is some sort of mutual fund (or equivalent, like an ETF, which some people seem to view as a different investment entirely, when in reality it isn't significantly different from a mutual fund. In fact, at Vanguard, the ETFs are a share class of the mutual fund). You could try to pick mutual funds that are going to beat the market within your desired asset allocation -- but given how few repeatedly do so, we're back to the same problem as picking stocks in the first place. You could find a financial advisor who will do this for you, but that selection process has the same problem. To top it off, there's all sorts of fees that are certain to eat into your total return. The odds are against you if your goal is to pick a mutual fund that will beat an index fund in terms of the return that you see (and ultimately, that's the number that matters).
Which brings us to the idea that most people here aren't going to beat the market. For the vast majority of what I'll call casual investors - people who want to set their allocation, contribute methodically, and not think about it more than a few hours a year - index funds (and the asset allocation wrappers - life style and target date funds - that use them, too) really are the key.
And since there isn't much to index funds to compare across companies, costs become the key. (I'll point out here that if you want to do stock trading, Vanguard probably isn't the right brokerage for you, although they do have some actively managed mutual funds beyond allocation ones. And once you have over a half of a million dollars in assets there, you can make very discounted trades of stocks should you be so inclined - I think it drops to like $2/trade, and at $1 million in assets, you get some number of free stock trades per year too)
So, fees. Vanguard's fees are among the lowest in the business. None of their funds charge a sales load. The expense ratios for their lowest investment minimum share class - "investor" shares - are among the lowest in the industry. And when your investment in a given index fund gets to $10,000 - a pittance in the grand scheme of things - the expense ratio drops even further as you qualify for Admiral shares (which your investor shares will get promoted to when you hit this mark).
If you're looking to diversify the portion of your stock portfolio that you want to be in domestic (U.S. company) stock, you can hardly go wrong with a total U.S. market fund. And at Admiral class, the expense ratio is 0.05%. Compared to $6.95/trade at many brokerages, you'd need less than one trade per $13,900 invested to have the same costs -- good luck not having your costs drag on your "versus index" performance there.
Note that I said "among the lowest" - there are occasionally funds with a lower expense ratio for the same product that come along. I've yet to see one that didn't feel like a loss leader, certainly not at the five-figures (or more) invested mark. On top of this, those with lower expense ratios tend to be offered by for-profit brokerages, further giving me the "loss leader" feeling as these companies lose business to Vanguard. It's only a matter of time, I feel, before the expense ratios of these creep up, or the companies offering them make up for the loss in other ways. By contrast, Vanguard runs their funds at-cost, so I know that the expense ratios I'm paying are the cost of operating the fund and that any future cost savings will go to me: they don't have shareholders (other than those who are invested in Vanguard mutual funds) who might want to claim the difference as profit.
In summary: if you aren't going to stock pick, or pick someone to pick for you, or pick someone to pick someone to pick for you, you're a good candidate for Vanguard's index mutual funds. And that's a sizable fraction of people who come here looking for advice.
In order to have a good shot at a secure, reasonably well funded retirement, most of us will need to have some portfolio of stocks (and bonds, but let's just talk about stocks for now; the same arguments I'm going to present for stocks apply to bonds). So how do we get those stocks?
You could pick them. That's what people did back in the day and that's what some people do now. There are various stock picking theories, and I won't go into what they are. If you're into that, great; I'm not going to discourage you from doing what you believe is the best way to achieve your financial goals. And if you beat the market, even better. But very few people will do so, and those that do will spend a great deal of time doing it (as will many that don't).
If you aren't picking stocks, you still need to have some. It's just that your best bet at that point is some sort of mutual fund (or equivalent, like an ETF, which some people seem to view as a different investment entirely, when in reality it isn't significantly different from a mutual fund. In fact, at Vanguard, the ETFs are a share class of the mutual fund). You could try to pick mutual funds that are going to beat the market within your desired asset allocation -- but given how few repeatedly do so, we're back to the same problem as picking stocks in the first place. You could find a financial advisor who will do this for you, but that selection process has the same problem. To top it off, there's all sorts of fees that are certain to eat into your total return. The odds are against you if your goal is to pick a mutual fund that will beat an index fund in terms of the return that you see (and ultimately, that's the number that matters).
Which brings us to the idea that most people here aren't going to beat the market. For the vast majority of what I'll call casual investors - people who want to set their allocation, contribute methodically, and not think about it more than a few hours a year - index funds (and the asset allocation wrappers - life style and target date funds - that use them, too) really are the key.
And since there isn't much to index funds to compare across companies, costs become the key. (I'll point out here that if you want to do stock trading, Vanguard probably isn't the right brokerage for you, although they do have some actively managed mutual funds beyond allocation ones. And once you have over a half of a million dollars in assets there, you can make very discounted trades of stocks should you be so inclined - I think it drops to like $2/trade, and at $1 million in assets, you get some number of free stock trades per year too)
So, fees. Vanguard's fees are among the lowest in the business. None of their funds charge a sales load. The expense ratios for their lowest investment minimum share class - "investor" shares - are among the lowest in the industry. And when your investment in a given index fund gets to $10,000 - a pittance in the grand scheme of things - the expense ratio drops even further as you qualify for Admiral shares (which your investor shares will get promoted to when you hit this mark).
If you're looking to diversify the portion of your stock portfolio that you want to be in domestic (U.S. company) stock, you can hardly go wrong with a total U.S. market fund. And at Admiral class, the expense ratio is 0.05%. Compared to $6.95/trade at many brokerages, you'd need less than one trade per $13,900 invested to have the same costs -- good luck not having your costs drag on your "versus index" performance there.
Note that I said "among the lowest" - there are occasionally funds with a lower expense ratio for the same product that come along. I've yet to see one that didn't feel like a loss leader, certainly not at the five-figures (or more) invested mark. On top of this, those with lower expense ratios tend to be offered by for-profit brokerages, further giving me the "loss leader" feeling as these companies lose business to Vanguard. It's only a matter of time, I feel, before the expense ratios of these creep up, or the companies offering them make up for the loss in other ways. By contrast, Vanguard runs their funds at-cost, so I know that the expense ratios I'm paying are the cost of operating the fund and that any future cost savings will go to me: they don't have shareholders (other than those who are invested in Vanguard mutual funds) who might want to claim the difference as profit.
In summary: if you aren't going to stock pick, or pick someone to pick for you, or pick someone to pick someone to pick for you, you're a good candidate for Vanguard's index mutual funds. And that's a sizable fraction of people who come here looking for advice.
Furthermore, you can sign up in the regulated IPO coin stock exchange. There's no guarantee with IPOs so be careful and choose wisely. Most IPOs end up losing money for investor unless you are the luckiest person ever and pick a winning coin. Just buy on exchange
Development Update:
We figured out way of preventing Sybil attack using a hybrid Proof of Stake system.
To create a node, you must prove you have coins. Say 10 coins. You send 10 coins to address A. Then you send the 10 coins from address A to address B. Then you add a signature using the public key in address A to sign a message in your Obelisk blockchain.
Alternatively, you could publish the public key for address A and then just sign a message with that public key. The node would have to publish a signature every time period, or within some number of blocks of the reserve coins being moved, in order to maintain valid trust relationships with other peers.
Alternatively, proof of burn could be required, where the coins are sent from address A to an address B that has no private key. Proof of burn conflicts with the requirement that no one should need to download the whole blockchain from the beginning to operate a full node, so is unlikely.
This system upper bounds the number of Obelisk nodes and restricts the ability to run Obelisk nodes to coin holders. The upper bound on the number of nodes and coin requirements adds another layer of Sybil attack protection.
We figured out way of preventing Sybil attack using a hybrid Proof of Stake system.
To create a node, you must prove you have coins. Say 10 coins. You send 10 coins to address A. Then you send the 10 coins from address A to address B. Then you add a signature using the public key in address A to sign a message in your Obelisk blockchain.
Alternatively, you could publish the public key for address A and then just sign a message with that public key. The node would have to publish a signature every time period, or within some number of blocks of the reserve coins being moved, in order to maintain valid trust relationships with other peers.
Alternatively, proof of burn could be required, where the coins are sent from address A to an address B that has no private key. Proof of burn conflicts with the requirement that no one should need to download the whole blockchain from the beginning to operate a full node, so is unlikely.
This system upper bounds the number of Obelisk nodes and restricts the ability to run Obelisk nodes to coin holders. The upper bound on the number of nodes and coin requirements adds another layer of Sybil attack protection.
Not sure how this prevents a Sybil attack. Are you simply adding a cost to adding a node to network and therefore a sybil attack will require a financial cost to do so?
Just an idea at this stage. Found an improvement. Each Obelisk node, has a public key. We hash the public key into an address and then it stores 10 coins in an output owned by that address.
It does not add a cost. It just proves that you own 10 coins. It proves you know the private key, for a public key, whose address has 10 coins in it. You can still spend the coins.
The idea is that it upper bounds the number of nodes. If 10 coins must be held and there are 100 million coins, then it upper bounds the network at 10 million nodes. The upper bound does not appear to be mathematically useful right now, but is something we should keep in mind.
When a new Obelisk node is run, it will "trust" some random peers. The user can also add a few nodes by hand that it trusts (exchanges or trusted community members). A node is identified by its public key hash and found by DHT. Its not like Bitcoin where nodes are IP:port pairs. You can move your computer around and the identity of the node does not depend on its IP address.
We want the network to be secure with random nodes being chosen. We dont want a situation like Ripple, where the three developers nodes control the network. However, we wanted to prevent a situation, where someone runs 200,000 nodes and tries to collect the trust relationships from new users. These Sybil attacks nodes, still cannot 51% attack generally, but anything that increases the cost of the attack is still useful.
Maybe, we restrict it so that new user will only randomly trust nodes that have a coin balance. Trust relationships wont be severed if the node does not have a coin balance, but they just wont get new random users.
The connectivity graph for trust relationships, is supposed to be a fully connected random graph. A few nodes (trusted community members, exchanges, websites, organizations) will have more trust relationships and that helps the convergence time for block consensus a bit. It reduces the network diameter a bit. Some nodes will be used to verify consensus (you choose a bunch of exchanges or different public keys), these nodes do not affect consensus decisions, but are "consensus oracles" to check if your node has converged with network.
If two large exchanges have different consensus for a particular, block, that is a problem. It could indicate a netsplit or an attack on the network. Exchanges may want to suspend trading until the issue is resolved.
The general idea of coming up with some kind of metric for trusted nodes is a good one.
The mere possession of coins probably shouldn't the only variable that contributes to trust. Maybe the age of coins would help or even the number and amount of transactions that the node has correctly processed.
how big is the wireless mesh net market?
the skycoin is to sync blockchain and make transaction, the Obelisk is to confirm the transaction by consensus, is there any benefit to run a obelisk node? you said there is no transaction fee so why people will run a obelisk node? and is there have something like ripple gateway?
the skycoin is to sync blockchain and make transaction, the Obelisk is to confirm the transaction by consensus, is there any benefit to run a obelisk node? you said there is no transaction fee so why people will run a obelisk node? and is there have something like ripple gateway?
I started to watch this thread after around 5 minutes of OP.
After a while it was clear it's not a scam (In the wake of Nxt there were like three annoncements like this a day), but also that it will be a long development. I'm okay with that.
However after the IPO announcement a few weeks ago (or months now?) I don't have any intention to buy the coin at IPO, the risk/reward ratio doesn't look good. I'm still watching because I want to see what technology it will bring, maybe buy some coints at some point, but the IPO format removed any incentive to invest in it.
the most are hate this IPO format, just like ripple, dev control too much.After a while it was clear it's not a scam (In the wake of Nxt there were like three annoncements like this a day), but also that it will be a long development. I'm okay with that.
However after the IPO announcement a few weeks ago (or months now?) I don't have any intention to buy the coin at IPO, the risk/reward ratio doesn't look good. I'm still watching because I want to see what technology it will bring, maybe buy some coints at some point, but the IPO format removed any incentive to invest in it.
Just buy it at an exchange, no one is telling you to IPO. This is not a pump and dump scheme, so if you are looking to get rich, please go away. We are trying to make a viable cryptocurrency that is an improvement on the bitcoin protocol. This ain't your Auoracoin that will benefit the early investors and then fuck everyone who buys in later.
I started to watch this thread after around 5 minutes of OP.
After a while it was clear it's not a scam (In the wake of Nxt there were like three annoncements like this a day), but also that it will be a long development. I'm okay with that.
However after the IPO announcement a few weeks ago (or months now?) I don't have any intention to buy the coin at IPO, the risk/reward ratio doesn't look good. I'm still watching because I want to see what technology it will bring, maybe buy some coints at some point, but the IPO format removed any incentive to invest in it.
the most are hate this IPO format, just like ripple, dev control too much. After a while it was clear it's not a scam (In the wake of Nxt there were like three annoncements like this a day), but also that it will be a long development. I'm okay with that.
However after the IPO announcement a few weeks ago (or months now?) I don't have any intention to buy the coin at IPO, the risk/reward ratio doesn't look good. I'm still watching because I want to see what technology it will bring, maybe buy some coints at some point, but the IPO format removed any incentive to invest in it.
I started to watch this thread after around 5 minutes of OP.
After a while it was clear it's not a scam (In the wake of Nxt there were like three annoncements like this a day), but also that it will be a long development. I'm okay with that.
However after the IPO announcement a few weeks ago (or months now?) I don't have any intention to buy the coin at IPO, the risk/reward ratio doesn't look good. I'm still watching because I want to see what technology it will bring, maybe buy some coints at some point, but the IPO format removed any incentive to invest in it.
After a while it was clear it's not a scam (In the wake of Nxt there were like three annoncements like this a day), but also that it will be a long development. I'm okay with that.
However after the IPO announcement a few weeks ago (or months now?) I don't have any intention to buy the coin at IPO, the risk/reward ratio doesn't look good. I'm still watching because I want to see what technology it will bring, maybe buy some coints at some point, but the IPO format removed any incentive to invest in it.
I think the IPO will like Safecoin, price will be down after it's on exchange, ROI is too low.
Skycoin will have a rolling IPO. The IPO will be very small, then a small number of coins will be released on to an exchange each day. If the price decreases, the number of newly issued coins will be decreased to stabilize price. If the price goes too low, the developers will begin buying back coins.
The majority of distribution will go to developers, people involved in marketing and people buying and operating a mesh network nodes. We will distribute between $100 and $150 dollars per meshnet node deployment. If a user spends $200 to deploy a node and receives $150 in Skycoin, this distribution is unlikely to negatively impact price because of Proof of Burn. Distribution an exchange or airdrop, in contrast is likely to drive down price and should be minimized.
The problem with Maidsafe is that it does not have users and does not have volume. To succeed, Skycoin must have a large and rapidly growing userbase and there must be a reason for people to be buying and using Skycoin.
Coins that no one uses and which have no user base are purely speculative. Many people have made money from speculative investments, but there is no rational basis for the price to increase over time. Dogecoin and Bitcoin should experience appreciation because of increasing adaption and a growing userbase. If the Bitcoin userbase doubles and Bitcoin transaction volumes doubles, we would expect Bitcoin price to approximately double, or at least increase.
It is very difficult to understand why Maidsafe would increase from the IPO, without a growing userbase.
I think the IPO will like Safecoin, price will be down after it's on exchange, ROI is too low.
Skycoin will have a rolling IPO. The IPO will be very small, then a small number of coins will be released on to an exchange each day. If the price decreases, the number of newly issued coins will be decreased to stabilize price. If the price goes too low, the developers will begin buying back coins.
The majority of distribution will go to developers, people involved in marketing and people buying and operating a mesh network nodes. We will distribute between $100 and $150 dollars per meshnet node deployment. If a user spends $200 to deploy a node and receives $150 in Skycoin, this distribution is unlikely to negatively impact price because of Proof of Burn. Distribution an exchange or airdrop, in contrast is likely to drive down price and should be minimized.
The problem with Maidsafe is that it does not have users and does not have volume. To succeed, Skycoin must have a large and rapidly growing userbase and there must be a reason for people to be buying and using Skycoin.
Coins that no one uses and which have no user base are purely speculative. Many people have made money from speculative investments, but there is no rational basis for the price to increase over time. Dogecoin and Bitcoin should experience appreciation because of increasing adaption and a growing userbase. If the Bitcoin userbase doubles and Bitcoin transaction volumes doubles, we would expect Bitcoin price to approximately double, or at least increase.
It is very difficult to understand why Maidsafe would increase from the IPO, without a growing userbase.
I think the IPO will like Safecoin, price will be down after it's on exchange, ROI is too low.
The majority of distribution will go to developers, people involved in marketing and people buying and operating a mesh network nodes. We will distribute between $100 and $150 dollars per meshnet node deployment. If a user spends $200 to deploy a node and receives $150 in Skycoin, this distribution is unlikely to negatively impact price because of Proof of Burn. Distribution an exchange or airdrop, in contrast is likely to drive down price and should be minimized.
The problem with Maidsafe is that it does not have users and does not have volume. To succeed, Skycoin must have a large and rapidly growing userbase and there must be a reason for people to be buying and using Skycoin.
Coins that no one uses and which have no user base are purely speculative. Many people have made money from speculative investments, but there is no rational basis for the price to increase over time. Dogecoin and Bitcoin should experience appreciation because of increasing adaption and a growing userbase. If the Bitcoin userbase doubles and Bitcoin transaction volumes doubles, we would expect Bitcoin price to approximately double, or at least increase.
It is very difficult to understand why Maidsafe would increase from the IPO, without a growing userbase.
looks fine, skycoin realized what I want. I was wonder someone to realize one coin use golang use consensus and use local web UI. skycoin had done this very well.
I think the IPO will like Safecoin, price will be down after it's on exchange, ROI is too low.
when the ipo time?
Development Update:
We figured out way of preventing Sybil attack using a hybrid Proof of Stake system.
To create a node, you must prove you have coins. Say 10 coins. You send 10 coins to address A. Then you send the 10 coins from address A to address B. Then you add a signature using the public key in address A to sign a message in your Obelisk blockchain.
Alternatively, you could publish the public key for address A and then just sign a message with that public key. The node would have to publish a signature every time period, or within some number of blocks of the reserve coins being moved, in order to maintain valid trust relationships with other peers.
Alternatively, proof of burn could be required, where the coins are sent from address A to an address B that has no private key. Proof of burn conflicts with the requirement that no one should need to download the whole blockchain from the beginning to operate a full node, so is unlikely.
This system upper bounds the number of Obelisk nodes and restricts the ability to run Obelisk nodes to coin holders. The upper bound on the number of nodes and coin requirements adds another layer of Sybil attack protection.
We figured out way of preventing Sybil attack using a hybrid Proof of Stake system.
To create a node, you must prove you have coins. Say 10 coins. You send 10 coins to address A. Then you send the 10 coins from address A to address B. Then you add a signature using the public key in address A to sign a message in your Obelisk blockchain.
Alternatively, you could publish the public key for address A and then just sign a message with that public key. The node would have to publish a signature every time period, or within some number of blocks of the reserve coins being moved, in order to maintain valid trust relationships with other peers.
Alternatively, proof of burn could be required, where the coins are sent from address A to an address B that has no private key. Proof of burn conflicts with the requirement that no one should need to download the whole blockchain from the beginning to operate a full node, so is unlikely.
This system upper bounds the number of Obelisk nodes and restricts the ability to run Obelisk nodes to coin holders. The upper bound on the number of nodes and coin requirements adds another layer of Sybil attack protection.
Not sure how this prevents a Sybil attack. Are you simply adding a cost to adding a node to network and therefore a sybil attack will require a financial cost to do so?
Just an idea at this stage. Found an improvement. Each Obelisk node, has a public key. We hash the public key into an address and then it stores 10 coins in an output owned by that address.
It does not add a cost. It just proves that you own 10 coins. It proves you know the private key, for a public key, whose address has 10 coins in it. You can still spend the coins.
The idea is that it upper bounds the number of nodes. If 10 coins must be held and there are 100 million coins, then it upper bounds the network at 10 million nodes. The upper bound does not appear to be mathematically useful right now, but is something we should keep in mind.
When a new Obelisk node is run, it will "trust" some random peers. The user can also add a few nodes by hand that it trusts (exchanges or trusted community members). A node is identified by its public key hash and found by DHT. Its not like Bitcoin where nodes are IP:port pairs. You can move your computer around and the identity of the node does not depend on its IP address.
We want the network to be secure with random nodes being chosen. We dont want a situation like Ripple, where the three developers nodes control the network. However, we wanted to prevent a situation, where someone runs 200,000 nodes and tries to collect the trust relationships from new users. These Sybil attacks nodes, still cannot 51% attack generally, but anything that increases the cost of the attack is still useful.
Maybe, we restrict it so that new user will only randomly trust nodes that have a coin balance. Trust relationships wont be severed if the node does not have a coin balance, but they just wont get new random users.
The connectivity graph for trust relationships, is supposed to be a fully connected random graph. A few nodes (trusted community members, exchanges, websites, organizations) will have more trust relationships and that helps the convergence time for block consensus a bit. It reduces the network diameter a bit. Some nodes will be used to verify consensus (you choose a bunch of exchanges or different public keys), these nodes do not affect consensus decisions, but are "consensus oracles" to check if your node has converged with network.
If two large exchanges have different consensus for a particular, block, that is a problem. It could indicate a netsplit or an attack on the network. Exchanges may want to suspend trading until the issue is resolved.
Obelisk is skycoin's distribute consensus node? I was think the skycoind is the node...
Yes.
Skycoin has a blockchain. The blockchain is in skycoin/src/coin. That parses the blocks and deals with unspent outputs and transactions.
Skywire is the daemon and has a "service architecture". It can run services, such as blockchain syncing service and other things. The meshnet is currently being implemented as a service on top of Skywire (although this may need to change).
The consensus mechanism is outside of the blockchain. Obelisk nodes (probably will be implemented as a Skywire service) have a blockchain. Each node has a public key. The public key identifies the Obelisk node. Each Obelisk node has its own blockchain (there are no coins in this chain). The node creates a new block and signs it with its private key. The Obelisk blockchains are used to negotiate consensus (determining the head block in the Skycoin blockchain). Obelisk uses Ben-Ors for randomized consensus. Each Obelisk node has a list of other nodes it subscribes to. Those nodes influence consensus and voting decisions for the local node. For non-pathological network topologies, the local consensus provably converges in to a global consensus.
Each node votes on the next block in the chain. A node purposes the next block and the nodes vote on the successor. The votes are published in the blocks in the Obelisk blockchain for each node. Your node votes randomly between the alternative and flips its vote every once in a while. Once 40% of your peers (the nodes you are subscribed to) have reached a consensus, you switch to that candidate. The network can vote on multiple forks at once, it does not slow down waiting for a consensus. The forks are pruned to a single chain over time. Splits of two or three block are normal, but after a few confirmations the probability of the block being reverted decreases exponentially to zero. If a transaction has been executed on all candidate chains, then it essentially executed, even if the particular consensus chain has not been decided yet.
That is binary Ben-Ors and Skycoin will use something slightly more advanced, that is faster when there are multiple successor blocks to choose from in the consensus set. Randomization is important to keep sub-graphs of the network from getting stuck. The voting process is a form of "annealing" where each node will arrive at the global consensus independently, only from its local information.
The consensus process happens in public. A node publishes blocks, signs them with private key and the blocks are replicated peer-to-peer between subscribers of the chain. Then there are "consensus oracles" which are nodes that are used to verify consensus but do not influence consensus. So you might choose the public keys of a few exchanges and a few trusted community members and your node will use those to detect if something is wrong. This is used to detect netsplits. This also protects against an attack, where a hacker controls your router and can control the peers you are able to connect to.
If a node shows up to network and tries to get the network to accept a different chain (51% attack, reverting transactions), it usually gets ignored. Most 51% attacks require node behavior which is automaticly detected and results in subscriber node removing the node from their trust list. The easiest 51% attack strategy is easy to detect and prove with mathematical certainty that it was intended as an attempt to revert transactions, because it require backdating block consensus decisions. It requires publishing two signed blocks with the same sequence number, so we just made this an automatically bannable offence for a node.
We are trying to eliminate the last possible 51% attack, which is when a subnetwork of nodes goes offline (netsplit attack) and then rejoins the network with a different blockchain consensus and tries to force this on the network to revert transactions. Most of these attacks will fail, because the subnetwork will not have enough influence and will accept the main network consensus.
This attack is still very difficult to pull off. One solution is when there is a successful 51% attack is to freeze the network and let each node/user individually which chain is the valid one and let people ban the attacking nodes by hand. The consensus oracle allow each node with high probability to know if the state is synced and if global consensus has been reached or if they are part of a netsplit subgraph. We think its possible for each node to know with high probability of correctness from local information, whether a node was offline during a consensus decision and then just ignore nodes that were offline who suddenly appear and try to force a chain fork on the network.
In Bitcoin, if you have the most hashing power, you can revert transactions whenever you want.
In Skycoin, to revert transactions
- you much control a large number of nodes
- the nodes you control must be "influential" and trusted within the network topology
- your nodes need to exhibit extremely blatant pathological attack behavior without the behavior being detected, because detection would result in losing the trust relationships you need to attack the network.
- your nodes need to be in a pathological attack topology, without it being detected (most bot nodes will be trusted by few humans and be very obvious)
- you must be able get the nodes you control to collude in a way that results in a successful attack (this is actually not very straightforward)
- if the attack succeeds, you must prevent the network from reverting the attack by hand (very difficult if people lost coins or money because of the attack)
To prove its 51% attack proof, you have to write down the assumptions you are making and then create a simple mathematical model and then prove the conditions under which things can and cannot happen in the model. Once you know the conditions that an attack is possible under, you try to eliminate them and if you cant eliminate them, you make them as difficult as possible. You increase the cost of an attack and you reduce the probability that a specific attack will succeed. Then you reduce the payoff and incentives for the attack.
The consensus process is simple and easy to model, but non-intuitive without seeing it. There will be a javascript site eventually that has an animated consensus process you can play with.
Development Update:
We figured out way of preventing Sybil attack using a hybrid Proof of Stake system.
To create a node, you must prove you have coins. Say 10 coins. You send 10 coins to address A. Then you send the 10 coins from address A to address B. Then you add a signature using the public key in address A to sign a message in your Obelisk blockchain.
Alternatively, you could publish the public key for address A and then just sign a message with that public key. The node would have to publish a signature every time period, or within some number of blocks of the reserve coins being moved, in order to maintain valid trust relationships with other peers.
Alternatively, proof of burn could be required, where the coins are sent from address A to an address B that has no private key. Proof of burn conflicts with the requirement that no one should need to download the whole blockchain from the beginning to operate a full node, so is unlikely.
This system upper bounds the number of Obelisk nodes and restricts the ability to run Obelisk nodes to coin holders. The upper bound on the number of nodes and coin requirements adds another layer of Sybil attack protection.
We figured out way of preventing Sybil attack using a hybrid Proof of Stake system.
To create a node, you must prove you have coins. Say 10 coins. You send 10 coins to address A. Then you send the 10 coins from address A to address B. Then you add a signature using the public key in address A to sign a message in your Obelisk blockchain.
Alternatively, you could publish the public key for address A and then just sign a message with that public key. The node would have to publish a signature every time period, or within some number of blocks of the reserve coins being moved, in order to maintain valid trust relationships with other peers.
Alternatively, proof of burn could be required, where the coins are sent from address A to an address B that has no private key. Proof of burn conflicts with the requirement that no one should need to download the whole blockchain from the beginning to operate a full node, so is unlikely.
This system upper bounds the number of Obelisk nodes and restricts the ability to run Obelisk nodes to coin holders. The upper bound on the number of nodes and coin requirements adds another layer of Sybil attack protection.
Not sure how this prevents a Sybil attack. Are you simply adding a cost to adding a node to network and therefore a sybil attack will require a financial cost to do so?
Just an idea at this stage. Found an improvement. Each Obelisk node, has a public key. We hash the public key into an address and then it stores 10 coins in an output owned by that address.
It does not add a cost. It just proves that you own 10 coins. It proves you know the private key, for a public key, whose address has 10 coins in it. You can still spend the coins.
The idea is that it upper bounds the number of nodes. If 10 coins must be held and there are 100 million coins, then it upper bounds the network at 10 million nodes. The upper bound does not appear to be mathematically useful right now, but is something we should keep in mind.
When a new Obelisk node is run, it will "trust" some random peers. The user can also add a few nodes by hand that it trusts (exchanges or trusted community members). A node is identified by its public key hash and found by DHT. Its not like Bitcoin where nodes are IP:port pairs. You can move your computer around and the identity of the node does not depend on its IP address.
We want the network to be secure with random nodes being chosen. We dont want a situation like Ripple, where the three developers nodes control the network. However, we wanted to prevent a situation, where someone runs 200,000 nodes and tries to collect the trust relationships from new users. These Sybil attacks nodes, still cannot 51% attack generally, but anything that increases the cost of the attack is still useful.
Maybe, we restrict it so that new user will only randomly trust nodes that have a coin balance. Trust relationships wont be severed if the node does not have a coin balance, but they just wont get new random users.
The connectivity graph for trust relationships, is supposed to be a fully connected random graph. A few nodes (trusted community members, exchanges, websites, organizations) will have more trust relationships and that helps the convergence time for block consensus a bit. It reduces the network diameter a bit. Some nodes will be used to verify consensus (you choose a bunch of exchanges or different public keys), these nodes do not affect consensus decisions, but are "consensus oracles" to check if your node has converged with network.
If two large exchanges have different consensus for a particular, block, that is a problem. It could indicate a netsplit or an attack on the network. Exchanges may want to suspend trading until the issue is resolved.
Obelisk is skycoin's distribute consensus node? I was think the skycoind is the node...
Development Update:
We figured out way of preventing Sybil attack using a hybrid Proof of Stake system.
To create a node, you must prove you have coins. Say 10 coins. You send 10 coins to address A. Then you send the 10 coins from address A to address B. Then you add a signature using the public key in address A to sign a message in your Obelisk blockchain.
Alternatively, you could publish the public key for address A and then just sign a message with that public key. The node would have to publish a signature every time period, or within some number of blocks of the reserve coins being moved, in order to maintain valid trust relationships with other peers.
Alternatively, proof of burn could be required, where the coins are sent from address A to an address B that has no private key. Proof of burn conflicts with the requirement that no one should need to download the whole blockchain from the beginning to operate a full node, so is unlikely.
This system upper bounds the number of Obelisk nodes and restricts the ability to run Obelisk nodes to coin holders. The upper bound on the number of nodes and coin requirements adds another layer of Sybil attack protection.
We figured out way of preventing Sybil attack using a hybrid Proof of Stake system.
To create a node, you must prove you have coins. Say 10 coins. You send 10 coins to address A. Then you send the 10 coins from address A to address B. Then you add a signature using the public key in address A to sign a message in your Obelisk blockchain.
Alternatively, you could publish the public key for address A and then just sign a message with that public key. The node would have to publish a signature every time period, or within some number of blocks of the reserve coins being moved, in order to maintain valid trust relationships with other peers.
Alternatively, proof of burn could be required, where the coins are sent from address A to an address B that has no private key. Proof of burn conflicts with the requirement that no one should need to download the whole blockchain from the beginning to operate a full node, so is unlikely.
This system upper bounds the number of Obelisk nodes and restricts the ability to run Obelisk nodes to coin holders. The upper bound on the number of nodes and coin requirements adds another layer of Sybil attack protection.
Not sure how this prevents a Sybil attack. Are you simply adding a cost to adding a node to network and therefore a sybil attack will require a financial cost to do so?
Just an idea at this stage. Found an improvement. Each Obelisk node, has a public key. We hash the public key into an address and then it stores 10 coins in an output owned by that address.
It does not add a cost. It just proves that you own 10 coins. It proves you know the private key, for a public key, whose address has 10 coins in it. You can still spend the coins.
The idea is that it upper bounds the number of nodes. If 10 coins must be held and there are 100 million coins, then it upper bounds the network at 10 million nodes. The upper bound does not appear to be mathematically useful right now, but is something we should keep in mind.
When a new Obelisk node is run, it will "trust" some random peers. The user can also add a few nodes by hand that it trusts (exchanges or trusted community members). A node is identified by its public key hash and found by DHT. Its not like Bitcoin where nodes are IP:port pairs. You can move your computer around and the identity of the node does not depend on its IP address.
We want the network to be secure with random nodes being chosen. We dont want a situation like Ripple, where the three developers nodes control the network. However, we wanted to prevent a situation, where someone runs 200,000 nodes and tries to collect the trust relationships from new users. These Sybil attacks nodes, still cannot 51% attack generally, but anything that increases the cost of the attack is still useful.
Maybe, we restrict it so that new user will only randomly trust nodes that have a coin balance. Trust relationships wont be severed if the node does not have a coin balance, but they just wont get new random users.
The connectivity graph for trust relationships, is supposed to be a fully connected random graph. A few nodes (trusted community members, exchanges, websites, organizations) will have more trust relationships and that helps the convergence time for block consensus a bit. It reduces the network diameter a bit. Some nodes will be used to verify consensus (you choose a bunch of exchanges or different public keys), these nodes do not affect consensus decisions, but are "consensus oracles" to check if your node has converged with network.
If two large exchanges have different consensus for a particular, block, that is a problem. It could indicate a netsplit or an attack on the network. Exchanges may want to suspend trading until the issue is resolved.
Jump to: