I’m not yet convinced that the opportunity of staking in Casper will outweigh the risk of having your ETH controlled by a hot wallet. With storage, your ETH can be secured by a cold wallet, thus is significantly lower risk.
As a user, I’ll need pretty solid returns from staking to convince me to bring my ETH out of cold storage. However, having my ETH locked up in a contract that is recoverable by my cold wallet is not really a different risk profile from storing in my cold wallet directly.
You still incur the opportunity cost of not being able to use those funds for anything as long as they’re locked up paying for storage.
The main point of my argument wasn’t that your proposed solution was bad, just that that particular piece of the argument doesn’t hold water IMO since it is yet to be seen whether or not the yield of staking even fully offsets the risk of holding your assets in a hot wallet.
In the most recent Casper FFG implementation, a compromise of your hot wallet will only cost a large portion of your funds in the case that very many other users get compromised (or attack) at the same time. So it’s a much smaller risk than actually putting all of your funds in the hot wallet.
I like the idea, as it’s simpler to make people “pay” by inflation than to actually remove some ETH.
It’s also a better incentive than gas refund as gas refund can only be used to, at best, divide the cost of a transaction by two, providing really little incentive for cleanup.
On a precedent, you can see that Augur switched from making inactive token holder loose funds, to increasing the total supply and rewarding active token holders (see: https://www.augur.net/whitepaper.pdf).
However the disadvantage of requiring a deposit, is that the capital lockup costs decreases with inflation making it tends toward 0 (but quite slowly).
Is it more like a hot key that votes on behalf of some funds instead of a key that directly controls the funds?
Yeah, that how I see it. It does not need to be implemented in casper, but people would use staking smart contracts requiring different keys for different actions.
It turns out this was a mistake and the system is very likely switching to “use-it-or-lose-it” sometime after launch. 
Ah, clever. So the contract may limit “withdraw funds” action to a cold key or multisig, while “vote for block” would be done with a hot key? And since the damage that can be done via voting wrong is limited, this limits the risk of the staker.
I’m not sure it’s a mistake, but they may increase the inflation rate (5% everytime there is a fork is really low, I think something like 50-100% when there is a fork is reasonable).
Yeah, that’s how I’d do it.
I don’t want to hijack this thread any more than I already have, but if you want to discuss this more in depth feel free to hop into Augur Discord server or DM me here (assuming DMs here are a thing)!
The point of rent is that accounts that use more storage space time need to pay more, and accounts that use less storage space time need to pay less. Simply relying on inflation for the cost would mean that accounts that have more tokens would be paying more, not accounts that use more storage. Rent also allows unused dust accounts to be cleaned up, and relying on inflation or even a deposit does not solve that.
Right; I’m not suggesting using inflation, but rather opportunity cost. Locking up funds always imposes an opportunity cost, and the ability to recover those unused funds provides an integrated incentive to free up storage.
Isn’t this basically the current model but instead of redeeming your deposit as a gas refund, you get ETH back directly?
It has a couple of important differences:
We’d need some way to set a consistent ether price for the deposit for each storage slot, however - perhaps a voting mechanism for miners along the lines of gas limit voting. We can’t allow miners to set it as they wish like with the gas price, because that would lead to miners including their own and their friends’ transactions for free.
Right, so we would need a new type of gas in a way, one used for storage related operations (SSTORE) and one for computation related operations. Could call the former crystals :D.
Would the refund go to msg.sender still? If so, it seems like this approach would be a non-breaking change. I’m not sure if it provides a bigger incentive than current model however, since with the current refund, contract owner can resell the available gas refund at arbitrary price, allowing them to control the revenue they make. I can definitely see benefits however, where public methods to free storage would be called very quickly, which is good.
I like this approach and would be happy to see some tests and incentive related analyses.
Rather than another type of gas, I think you’d just have consensus ‘slot price’. Any SSTORE to a previously empty slot would cost that much ether, and the balance would be stored against the contract’s deposit balance.
We would need to establish how this is paid for (is there a ‘storage slot limit’? Is it deducted from gas based on the current gas rate instead?)
It would, yes. It’s up to contract authors to manage deletion in a way that makes sense.
I don’t think gastoken-like contracts are a practical mechanism right now, due to the complexity and the fact they require additional upfront gas and only refund up to half the total. I certainly don’t think they affect peoples’ decision making around contract design and storage costs.
We would need to establish how this is paid for (is there a ‘storage slot limit’? Is it deducted from gas based on the current gas rate instead?)
Deduced from gas*gasPrice seems like the most UX friendly and subtle imo. What would be the rational for a ‘storage slot limit’?
Due to the complexity and the fact they require additional upfront gas and only refund up to half the total.
Even with the deposit scheme you propose, users need to pay some gas for the storage operation. If the refund was 100%, then you open the door to DDos (someone just storing and freeing storage slots). The current gas refund could be 20k, which means you would be receiving 75% of what you initially paid (accounting for the 5k gas cost of SSTORE when clearing the storage slot), which could be OK, but not sure if that’s a potential DDos vector as well.
You cannot make the storage cost depend on gas price, or miners can bloat the state at will. You could have a consensus-determined (in ether, not gas) cost per slot, then bill it as a variable amount of gas in order to use that accounting mechanism.
The alternative is to charge the sender for storage slots separately, in which case they need some way to specify the most they’re prepared to pay.
There’d still be a gas cost for the opcodes themselves, but refunds are in ether, not in gas. There’s no DoS vulnerability, because it doesn’t allow you to increase the total amount of work done in a block.
Sorry, I should’ve been clearer. This is indeed what I meant. The cost per storage slot is fixed (denominated in ETH), which could be reflected as a dynamical gas amount based on gas price. Hence, you need to provide more gas at lower gas price, but at least it would be hidden from users since easily predictable by UX.