search

lukechampine / user

A CLI renter for Sia
MIT License
12 stars 2 forks source link

Suggestion: Better cost controls #2

Open lukechampine opened 5 years ago

lukechampine commented 5 years ago

Thanks to metrics logging, it's possible to determine exactly how many coins you spent on a particular operation. However, this currently isn't very user-friendly: you need to process the logs yourself. It would be much better to have a flag like --print-receipt that would cause user to print something like Total cost: 10 mS after an upload/download finishes. (Or update the cost in real-time, like the progress bar does with bytes.)

Going further, I would really like to add the ability to estimate the cost of an operation in advance. Ideally, you could add an --estimate-cost flag to any command, and instead of actually performing the upload/download, user would just print Estimated cost: 6 mS. Unfortunately, implementing this is would take quite a bit of work: I would need to duplicate the upload/download functions and strip out the actual transfer logic, which means both adding code bloat and risking desynchronization between the cost-calculation logic and the actual logic. (Perhaps with some really aggressive mocking, the existing logic could be reused, with the I/O bits changed to no-ops... but that would be quite a hack.)

Anyway, this would then enable a much-needed feature: the ability to restrict the cost of a particular operation, aborting if the cost exceeds the limit at any point. One of the known issues with Sia is that hosts can raise their prices after you form contracts with them, tricking you into overpaying. With this feature, you could detect when a host tries to sneakily raise their prices, and immediately blacklist them. (The cost estimation feature also helps with this, but it's annoying to estimate costs before every operation, and hosts can still cheat by waiting to raise their prices until after the operation begins.)

Price-raising attacks are unfortunately unavoidable in Sia, because hosts must be free to vary their prices in response to fluctuations in the cost of storage and the exchange rate of siacoins. However, such attacks are possible in the real world as well: a supplier can agree to a low price initially, and then demand a higher price when the delivery date. Even if they signed a contract, suing the supplier takes time -- often too much time, if you're on a tight schedule -- so in many cases the only option is to pay. Sia is actually an improvement in this regard, because storing redundantly means no single "supplier" can hold your data hostage. You can simply refuse to pay the higher price and blacklist the scammer forever. And since hosts must sign their requested price, you can share the signatures publicly, allowing others to verify the malicious price increase and add the scammer to their own blacklist too.

vargrant commented 5 years ago

It's a very good idea. We need try to re-upload or data in the case if host have a changed prices for download/upload. More inportant when host changed procice to download - becuase upload price is important only on stage uploading data, but downloading price will be important in future. But in any case for define a moment to re-upload data to other host we need calculate a sense for this action - we must be sure that after this action we will save our money. Like data source we can use time for end contract and calculate how much volume planned to be downloaded for this period. Also we must calculate a cost for reupload this data to other hosts. If in result we will have some economy then we need to do this, but in other case we need to keep this data on current host. Cost of planning to download this data for time range to the end time of contract can be calculated by 2 ways - we can use our settings in configuration file with forecast targets or we can use our real data statistics for this host. I dont know which way is better - in this case we can provide decision for end user via option in command line or option in file of configuration.