Quote from: killerstorm on November 28, 2015, 06:54:59 PM

Quote from: Taek on November 24, 2015, 05:09:09 PM

On UI CPU usage, it's based on chromium. Does chrome use similar resources when running? If so, there's not much we can do about it. If not, we can take note. There are a number of things in the UI that are probably not very efficient. Ongoing, we are working to improve performance.

It turned out that it's so CPU-hungry only while siad is downloading the blockchain.CPU usage isn't a problem when it's fully synced. Perhaps siad sends lots of events during syncing or something like that...

Quote from: Taek on November 24, 2015, 05:09:09 PM

Also, how many minutes/hours did you wait for it to get unstuck?

So I deleted consensus.db and started over. It got stuck at 21664 again, but after some time went back to 205xx, then went further to 22040 and got stuck again for many hours (I tried restarting, reconnecting, etc).

I then tried a faster connection, and it helped: after 5 minutes or so it went further and eventually got fully synced.

To me it looks like there are several blockchain forks and siad is having a problem getting the latest one on a slowish connection.

So now I tried uploading and downloading some files. It worked, but I found several issues:

1. It's hard to figure out how much storing a file costs (or have costed, after the fact). (*)
2. I noticed it generates a bunch of transactions with wildly different sums, e.g. one is 0.02 S another is 5.4 S. Is that due to different prices or size is different too?
3. No information about redundancy.
4. Contract duration is specified in blocks, which is cryptic. I figured out that inter-block time is probably 10 minutes, then 6000 blocks is ~42 days.
5. The share box, after you opened it, it's impossible to close without restarting UI.
6. i find it strange that transaction list is not automatically updated, looks kinda confusing.
7. "Estimated competitive price" fluctuates wildly (I saw 5, 750 and some really huge number) and doesn't seem to be related to estimated cost on file tab. (E.g. estimated price is 750 S when cost is 220 S).
8. No notification after download is complete.
9. Most users will probably want to store files for a duration longer than a month, will it automatically refresh files? Can it refresh without downloading them? Do they need to be re-uploaded each time?

*: I tried to calculate it from balance changes, apparently it shows I spent 64 S so far to store 3 files 33 MB of files. This implies a cost of 1939 S / GB, which is quite a bit more than 220 S / GB estimate it shows now.

But actually there was a glitch: The first time I tried to upload these files I had to abort I had to abort it and restart siad at "processing" phase due to system thrashing on low memory, and it seems like money was spent even though upload wasn't completed... But it still doesn't explain difference in price, unless it was spending money repeatedly. Transaction list looks weird, there is a lot of small transactions, but also three spending 6.84 S (three transactions with identical values but different hash and time) and two spending 8.15 S.

Ok. You aren't the only one to report having troubles synchronizing to the network with a slow connection speed. We have some good ideas about what the problem is and how to fix it, but we are very intently focused on getting file contract renewals working. We definitely have network optimization on our todo list though, there's a lot of low-hanging fruit there (such as headers-first downloads, and hash-first flooding).

The transactions with different sums are due to the different prices of the hosts, some hosts are absurdly cheap, some are extremely absurdly cheap, and some are essentially free. That's why you see the flucuations. Also, sometimes you upload half of a file to one host, and then for some reason (cheaper prices, faster speeds, or other reasons) you switch hosts halfway through. Then you might end up with smaller amounts in the file contracts.

We're well aware that the renter doesn't provide enough information about the files, the redundancy, the availability, etc. We're prioritizing auto-renewing, but having greater transparency about the prices being paid is high on the todo list as well.

Right now we use 6000 blocks because it's just shy of 6 weeks. I'm not sure why I picked that amount, it seemed good to me at the time. We'll be switching to 30 days starting with the next version (2-3 weeks away we thing).

We appreciate all of the feedback you are giving us. It helps to keep us focused to have clear goals to work towards, and your feedback helps us keep sight of those goals.

Quote from: mishax1 on November 30, 2015, 08:43:29 PM

Can't believe I bought some at 4 sat Shocked

Over 300,000,000 siacoins were sold in the past day or two. I'm not sure where they came from, but it looks like someone major decided to dump at near-0 prices. I'm not sure what drove that decision, but maybe they switched over to Storj. I think they will, in the long run, regret that move. We'll see how the next 3-4 weeks play out, but we're doing some aggressive development right now.

Quote from: pallas on December 01, 2015, 10:48:19 AM

Quote from: dedmaroz on December 01, 2015, 10:40:10 AM

Why is any mining pool?

the protocol is specific to the coin, it requires a good amount of coding to make a pool.

I feel pretty strongly that a mining pool should not be at the top of our priorities right now. We need a storage platform that people love using, and we've got a healthy enough hashrate for the current network size and price. Sia needs a better storage platform, so that's where we are currently directing all of our energy.