Ok I understand better but how come that I've announced my host with a domain but this is indeed the IP that is displayed on siapulse instead of the domain? And how come that siac hostdb does not mention my host?
After some more reading I got more confused about the collateral calculation. Does the locked collateral depend on contract duration? Per "siac host config -h" output it should not, as the setting is in currency/TB. However, in API.md I found that "'collateral' is the number of hastings per byte per block" so the locked collateral does depend on the contract duration.
The more I try to understand the collateral and revenue calculations, the more I think that there should be some model contract example with coin transfer/lock/unlock amounts calculated and explained. I might write it myself to be corrected in what I misunderstand. But that's when (if?) I get a little more clarity.
I have wrote down the passphase of my first wallet on my office computer. Then I install Sia on my notebook, and create a new wallet, and paste seed, I input the passphase, click load seed, and input the passphase too in wallet password, the system display"error to calling/wallet/seed: the encryption key provided is incorrect!" Why?
Veber is right, this is caused by the gateway saving the node list to disk in the RelayNode RPC. This error was more likely to occur during high i/o ativity. The RelayNode RPC has been removed for other reasons, so this particular error cannot occur in newer versions. I'll look into reducing the gateway's i/o as a similar error could occur if you try to connect to many peers at once.
Hmm, maybe consensus file is corrupted? There has been reports that PCs recovering from hibernation/standby have had their consensus DB corrupted. Could be your issue too. It is simple enough to remove the consensus file (from /consensus/ folder). The Sia daemon will then resync next time you start it (might take up to a day, probably more like 4-5 hours on a good connection).
oh, there is no way to pay another host. Sia is designed to have hosts go offline, you will not get inbetween people and their files by leaving, as long as at least half of the network sticks around for longer. There is high redundancy.
One idea might be to set the logging level as a parameter, so it is a host setting.
But I have done some more testing, and it seems it is the requests from the renters, that are DDOS'ing my router. Are there anything special about the requests made from the renters ? or is it just normal RPC-calls?
I have had other P2P running, so I am suspecting either that the request are creating some shortage in the router making it boot after a while.
What I have seen is the following
no siad running - my router is happy
siad running but not as a host - all is still fine
siad running as a host - 18 minutes approx. router boot
siad as been running for a while, but I terminates it but still letting it be registered as a host - router might work for 1-2 hours, probably because there are still some tries of connecting
siad has ben running but is deregistered as a host for contracts, router seems to be working fne
As I understand it there are different type of calls made, but I suspect the scanning of hosts might be the problem.
I can see that in Sia / modules / renter / hostdb / scan.go the host is added to the pool, but as GO is a new language for me, I still havent figured out where the actual call to the host is made (And thus not found where I need to log the request on the host side).
I think it might be a request that is not passed thru the router, so even logging on the host might not help me.
The guide will cover some of this. There's a pretty simple algorithm you can follow right now. If you aren't getting enough contracts, lower the price. If you are getting too many contracts, raise the price.
The methods for picking the best hosting constants are going to evolve as the renter gets smarter at picking hosts. Today it is almost exclusively looking at price, but in the future there will be a huge reliability component, as well as a proof-of-burn component.