-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tokens destination #41
Comments
Burning tokens except for protocol governance tokens makes no sense. In a competitive market of such protocols, one that paid some collateral to clients would be far preferred by them, one that paid auditors would be preferred by them, and one that retained collateral in treasury would be preferred by owner (and would be able to fund itself), and its better business prospects should make it preferred by clients and auditors. Probably the sweet spot is a mix of the above. Lighting money on fire is no more rational for a decentralised entity than a real-world one. (Gov tokens are an exception because that amounts to a share buyback). Paying people for things introduces incentives, and we'll then need mechanisms to ensure those incentives don't lead to uncontrolled bad behaviour. As an aside, the built-in storage market does burn collateral. (1) I don't think this is the best design, and (2) FIL is the equity token for Filecoin network, so for a network built-in actor, it's similar to the case of burning governance tokens, where the so-called protocol revenue accrues to FIL holders. |
@anorth thanks for your feedback!! But let me explain what I mean with we burn (I think i used the wrong words there and indeed I just updated the fist message in this issue): the collateral goes into the smart contract account and the contract's owner can manage it (ie, withdraw the tokens). The question now if this is the best approach for the market fit or when want to use part of the collateral to pay the referees (note that they can the the contract owner and they already get the cc @nicola |
It is not very expensive (both in terms of @turinglabsorg effort and gas) to upgrade the dynamics of transfer of value |
That sounds much better |
What are the risks in giving collateral money to the user? |
It is an incentive to user to misbehave (eg, client appeals while a provider is down/dossed on porpuse) |
Well, invoking the committee has a cost (we can play with that) Plus, if a single client can break/doss the storage provider for cheap, then it means that it's not a good storage provider. |
We already use this to say that is not rational for a malicious client to create false appeals in the current version of the protocol (ie, with no collateral given to client). Moreover, in filecoin, when we slash for missing a windowPoSt, there is no payment for the clients, why do we want something different here? |
what do you mean? |
While we are still on testnet this is not an issue related to development; but we must consider any relevant change to be included in the smart contract before audition! I’ll ping everybody in a couple of weeks |
@irenegia if you are an ETH holdler, and you know that there is a protocol, where there are miners that could loose data and when they do, they loose ETH, what you do, you attack them, so that they loose ETH, so that the number of ETH around decreases (hence the value of your ETH increases). In other words, if we end up having $B of ETH locked, we will be a worse target than some users earning the miner collateral. |
When people make mistakes, the network "earns" for the same reason that I described above. |
For the alpha version, we can leave things are they are (see description in the first message), and we can discuss this again in the future for a future upgrade. |
Closing this issue for now, but adding the label "future" since we may want to re-open this for an upgrade after launch |
hey @irenegia I think it's ok to mark it as a future, but if you close it it will be very tricky to find it. I suggest we re-open it but we take it off the board. |
at the moment we have
these are parameters that each referee networks can set once joining the protocol, playing with terms of agreement |
The
payment
goes from client's account to provider's account (if no appeal, otherwise goes back to provider);The
appeal fee
goes from client's account to the referees accounts (split the fee, each part in an account);The
collateral
goes from provider's account to the contract account (if there is slash, otherwise back to provider);Are we fine with this policy?
Or should we use the collateral when there is slash to repay the provider/referees?
~The protocol currently burns the collateral from the provider account when a file is not retrieved.
Should we instead give the collateral to the client (all of it, only a fraction of it)? ~
The text was updated successfully, but these errors were encountered: