http://forum.sia.tech/topic/1037/host-profit-maximization-thread

^ A guide about how to set your host prices, and overall about how to be a good/profitable host

We found the issue, and a fix is in the works. In the meantime, you can do this operation:

1. Close Sia, If you are in the UI, start by going to the terminal tab and run the command 'stop'. Then close the gui.
2. Restart Sia. Do not unlock the wallet.
3. Go to the terminal tab and run the command 'wallet init-seed --force'. You will be asked for a seed, provide your seed. It will then rescan the blockchain, which takes like 40 minutes on an SSD and several hours on an HDD.
4. You should get your coins back at that point.

We have a fix coming, including:

+ rescan times cut to about 15% of what they currently are
+ 'load seed' will find your balance instead of reporting zero

Should be out in the next few weeks. Sorry for the inconvenience.

When you send siafunds the whole balance in the 'siacoin claims' gets drained into your wallet, but it doesn't show up for 144 blocks, it's like mining (block rewards aren't spendable for 144 blocks either)

lead dev here. We have 3 full time devs working on the project. Most of our work over the past two weeks has been on the staging branch, as we're preparing a massive upgrade for the wallet and the host: https://github.com/NebulousLabs/Sia/tree/staging

Should be ready next week or the following

Best place to get in touch with the Sia team is on our slack, which is a lot more active than here. https://slackin.sia.tech

We also have a public roadmap available here: https://trello.com/b/Io1dDyuI/sia-public-roadmap

Your config.json for some reason is pointing to the wrong location. I believe it's going to be in the same folder as the 'Sia-UI' executable.

I stopped logging into Bitcointalk quite some time ago. I've mostly been active on forum.sia.tech and on our slack (slackin.sia.tech for an invite). Definitely been around though. Someone recently added a bot that posts the bitcointalk posts to our slack, which is what made me realize that people still post here frequently. I can't promise that I'll be super active or answer every question, but if you do want more attention from the broader community you'll find a lot of support on the forum and in our slack.

Definitely. If you download the most  recent release (http://sia.tech/apps/) you can become a host on the graphical app. You'll need to have 50k SC to get started with hosting.

Big performance upgrade for uploading coming out in the next few days.

Big release, lots of bug fixes. Still some rough patches, but you should find after the upgrade that things move a lot smoother now.

More on the official Sia forum: http://forum.sia.tech/topic/331/sia-v1-0-1-released

The attacker is able to continue stealing because they were able to get your wallet seed. The only way to protect your coins is to create a new wallet with a new seed and to transfer all of your old coins to that wallet.


You are using the old GUI, which has a few bugs with regards to the way it displays the transaction. I'm not sure why it distinguishes them that way, as the person who wrote our GUI is gone. My best advice is that you shouldn't use v0.5.2 GUI and instead stick to the command line. The v1.0.0 GUI will be out sometime tomorrow barring some major incident.

----------------------------

I cannot verify that your internal connection is secure. I know that miners using only localhost have not been having problems. If the attacker is able to get past your firewall in any way, that may be enough for them to get access to your wallet api. I am not sure. If you exposing your api port over anything other than localhost, you are putting yourself at risk. Some people know enough about network security to do this safely, but if you can't say with certainty that you know how to expose your api in a secure way, you should not be doing it.

We're looking at ways to make things more secure out-of-the-box, but security is very difficult and it's not something we can clean up in just a few days. There are a few things we can do but a sufficiently good attacker has a lot of tools to break into an exposed api. Simply adding a password may not be sufficient, and there are some significant issues with implementing TLS into the api - namely, you need a way to give both sides a key, and simply using Diffie-Helman isn't good enough because you have to distinguish between an attacker and your own client. Websites don't have this issue because they have user accounts.

On the bright side, a few miners have reported that the weird transactions listed in the v0.5.2 GUI were not actually stolen transactions. On the less bright side, miners who are CLI-only have reported stolen coins. Yours might be in the former category.

Check your ports. What software are you using? If you are not using the official miner binaries, there may be malware. But more likely, the attacker has somehow gotten past your firewall some other way and is able to query your network. We've only had reports of miners getting their coins stolen. Most up until this point have later confessed that they were serving the API over the public internet with their wallet unlocked. (Wallet does need to be unlocked to mine - this is something we can address, but it will take time).

The first reports of theft were only a few weeks ago. It's a new set of attacks, but largely the problem seems to be miners doing insecure practices.

I want to work with you to figure out how the attacker is getting access to your wallet. You need to know though, that after the attacker has stolen coins once, he will be able to steal them again as many times as he wants without access to your API, because the attacker will have the wallet seed. Once the attacks start, the only protection is to get a completely new wallet and hope you can transfer your coins to it before the attacker takes them.

Can you tell me more about the attack though? How many coins are getting stolen? Are you using the v0.5.2 GUI, because that has some bugs in the way it talks to the wallet, and sometimes reports transactions as 'negative' erroneously. The best way to know your balance and know the status of the miner is to use `siac`.

Hey, developer here.

The best I can tell, most miners who are having blocks stolen from them are exposing their API over the public Internet. If you run `siad -a ipaddress:port`, anyone on the internet can see your API and take your coins. Some attacker is scanning the nodes on the network and looking for miners who have improperly configured their siad.

That's not a security vulnerability as much as it is a usability problem. You are essentially giving the attacker your seed, password, and full access to your wallet, your files, and your whole Sia identity when you this.

The person doing the downloading is the one paying for the bandwidth, you pay for them in the same network connection. Downloading a file does not take funds from the renter, otherwise the host could just lie about who had downloaded the file (or download from themselves repeatedly from a cheap local connection). No DoS attack here.


You are misunderstanding how the Sybil defense mechanism works. Having multiple VMs, or even multiple full machines on different IP addresses, is not sufficient. You also have to have a history of burning coins, and there's a linear relationship between how many coins you've burned and how likely a renter is to select you. If you want to be as likely to be selected as a 10,000TB host, you need to burn enough coins to keep up, and they are (per the siafund fee) burning approximately 10% of their income.

And if you actually have 10,000TB, you haven't performed a Sybil attack at all you're outright a legitimate node on the network.

You can leverage identity to manage the Sybil attack as well, but right now the only real solutions to identification that we have are all centralized in some way. Burning coins is decentralized.

I think that you are bringing up a couple of separate concerns, and that they cannot be collapsed into a single concern.

For example, a host or a renter might be subject to a DDOS attack (especially a host) that makes business difficult. But it's much easier to DDOS a single host than it is to DDOS an entire file, because you need to know all of the hosts that have that file (not always public knowledge), and you need to have enough resources to DDOS a large enough number of hosts to make the file inaccessible, and that number could be dozens of different hosts, which is a different level of attack than DDOSing a single host. As far as I am aware, there's not a whole lot that you can do about DDOS attacks (other than work with a service like CloudFlare) - if someone wants to send you network traffic, there's usually a way for them to do it.

The Sybil attack, or 'not really redundant storage' is a different concern. When uploading files to the network, you want to upload to many different hosts (as a part of the security model), and you want to be sure that these different 'hosts' aren't all putting your data on the same physical disk. There are two components to this. We can solve one of the problems pretty easily by encrypting the redundant pieces using different keys. So, we can force the network to store the full redundancy of the file, though this technique is not enough for guaranteeing that the data is not on multiple separate physical drives.

You can introduce a monetary component to make Sybil attacks expensive. On the Sia network, for example, all money transferred between renters and hosts is measured on the blockchain and includes a component of proof-of-burn (in the form of siafund fees). The proof-of-burn component means that this activity is expensive to spoof, mitigating simple Sybil attacks and forcing attackers to spend significant monetary resources executing an attack.

Depending on how much you trust something like an IP address, you can use IP addresses to get a sense of the actual physical location of the data. But you can also do better than that if you've got multiple servers spread over a large geographic area. You can do ping-time challenges to the hosts that are storing your data. If a host claims your data is in China, and another host claims your data is in America, and you've got a server in each, you can do challenges that require the host to respond in under X milliseconds. The laws regarding the speed of light give you a way to be absolutely certain that your data is being stored in both China and America, because the ping time on the challenges from your server in China to the host in China will be very small, and the ping time on the challenges between your server in America to the host in America will also be small.

So, if you are willing to use a more elaborate setup, you can definitely get proofs (based on the fact that data cannot travel faster than the speed of light) that your data is in two different geographic locations. And depending on your trust model, you can outsource these challenges to the network (have someone else do the challenges on your data and trust their results).

The really nice thing about both DDOS and Sybil attack prevention is that it's not a consensus layer problem. Consensus protocols are notoriously difficult to upgrade, and even more difficult to get right, but we don't have to worry about maintaining consensus. We can update nodes and improve techniques in ways that don't require the whole ecosystem to upgrade simultaneously, so as we continue to think of better ways to handle DDOS and Sybil attacks, we can incrementally push them out to the network.

Oh ye of little faith 

Even though you missed the boat, it's been great to see your threads and have your support. The votes of confidence that we get from key players in the cryptocurrency space keep us motivated.  We're glad to have gotten so much working already, and excited for what's coming in the next month.

Our goal is to get as many long term users as possible. I think that one of Nxt's biggest shortcomings was that most of their code catered to short term uses. For example, the original Sia crowdfund was actually performed on Nxt, we used it for a short period of time and then we withdrew - our needs for Nxt were temporary.

At the moment our marketing focus is more on getting press hits and organic word-of-mouth growth. The user experience is still choppy, and until we've tuned that up I don't think it makes sense to chase mainstream users - they will get turned away as soon as they download.

On the other hand, we are making attempts at getting press coverage in places like CoinDesk, CoinTelegraph, etc.

We're definitely working hard to grow the ecosystem.

I also want to mention that the new RC is out: https://github.com/NebulousLabs/Sia/releases/tag/v0.5.2-rc3

0.5.2-rc3 features a single change - some miners were reporting errors when mining, and I believe it was due to the way that the miner was calculating the height. I've added some extra logging, so we'll have more information even if it does not seem like I've fixed the problem, though I believe that the fix is now in place.

Yeah, once you make a seed, all of your new addresses come from that seed. You may still have old money in the old addresses though, so you'll need to keep all of your seeds unless you send all of your money to yourself. After you import the siakey, you'll only lose the siafunds from the siakey if you move them around or claim siacoins out of them. If you are using your siafunds, they will eventually be transferred to the seed that the wallet is using.

Sorry for the poor UX in the wallet, we're going to be actively working on it at some point in the near future, but have our hands full with the host and the renter, and with improving test coverage across the project. Thanks for being patient.

You want to aim for less than 5% downtime, which is actually quite a lot of downtime. 10 minutes once every few days is not going to hurt your usefulness as a host. Is the crashing due  to Sia, or due to other system instability? If Sia is crashing, I would like to see the outputs + logs so we can give it better stability.