Tokens destination

[irenegia]

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)? ~

[irenegia]

cc @lucaniz @kubuxu @anorth

[anorth]

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.

[irenegia]

@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). So I believe we are in the scenario "protocol that retains collateral in treasury and that is preferred by owner".

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 appeal fee).

cc @nicola

[0xjona]

It is not very expensive (both in terms of @turinglabsorg effort and gas) to upgrade the dynamics of transfer of value

[anorth]

the collateral goes into the smart contract account and the contract's owner can manage it

That sounds much better

[nicola]

What are the risks in giving collateral money to the user?

[irenegia]

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)

[nicola]

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. Plus, there if user is an ETH token holder they already benefit from the slashed ETH collateral (in a very small way, but they do)

[irenegia]

Well, invoking the committee has a cost (we can play with that)

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). If we give the collateral (even just part of it to clients), then we have to increase the appeal and I believe this is (1) unfair for good clients, (2) not appealing for the product.

Moreover, in filecoin, when we slash for missing a windowPoSt, there is no payment for the clients, why do we want something different here?

[irenegia]

Plus, there if user is an ETH token holder they already benefit from the slashed ETH collateral (in a very small way, but they do)

what do you mean?

[0xjona]

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

[nicola]

@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.

[nicola]

Moreover, in filecoin, when we slash for missing a windowPoSt, there is no payment for the clients, why do we want something different here?

When people make mistakes, the network "earns" for the same reason that I described above.

[irenegia]

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.

[irenegia]

Closing this issue for now, but adding the label "future" since we may want to re-open this for an upgrade after launch

[nicola]

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.

[0xjona]

at the moment we have

• total refund policy if provider is slashed
• whole collateral goes into smartcontract vault if provider is slashed
• _referees network get payed 0.2*dealvalue per appeal, and max appeal number is 5

these are parameters that each referee networks can set once joining the protocol, playing with terms of agreement we are exploring multi-referee networks in next release (can't quote an issue now) @irenegia