Feedback over protocol

[NicolasDorier]

• I think the way outcome and payouts are expressed is not really mapping to the mental concept of somebody making a bet. Right now we have outcome + payout in contract info. But from a gambler perspective, a PnL (Profit and Loss) makes more sense (outcome => Profit/Loss)
• If we used such PnL representation, we can get rid of the "TotalCollateral" in both the accept and offer message, while making it more intuitive to people to understan.
• The ContractInfo should contains the preimage of the sha256, else how the acceptor is supposed to verify that the PnL is what he expects??

The concept of PnL allow better modeling for non discrete outcomes.

Also the collateral of the accepter, even in the current protocol, is not needed.
This can be determined by the highest payout of the offer and the collateral of the offerer.

[Tibo-lg]

I think the way outcome and payouts are expressed is not really mapping to the mental concept of somebody making a bet. Right now we have outcome + payout in contract info. But from a gambler perspective, a PnL (Profit and Loss) makes more sense (outcome => Profit/Loss)

I think this is an application level concern, it should be pretty easy to display one or the other regardless of the representation that is used at the protocol level.

If we used such PnL representation, we can get rid of the "TotalCollateral" in both the accept and offer message, while making it more intuitive to people to understand.

The rational for having it in both messages was discussed here. Depending on how we define contract information it is possible that it will change though.

The ContractInfo should contains the preimage of the sha256, else how the acceptor is supposed to verify that the PnL is what he expects??

ContractInfo is not really specified yet. Personally I think that each user should just get this kind of info from the oracle directly instead of receiving it from a counter party (if the info is signed by the oracle it might be ok, but still it seems like making the protocol heavier).

The concept of PnL allow better modeling for non discrete outcomes.

What do you mean by "non-discrete outcomes"? And how does the PnL representation make it easier?

Also the collateral of the accepter, even in the current protocol, is not needed.
This can be determined by the highest payout of the offer and the collateral of the offerer.

Again you can see @nkohen explanation here.

Personally I think at the protocol level it is easier to specify payouts as they will appear in the transaction outputs as it makes it easier to implement, but I'm open to being convinced otherwise :).

[NicolasDorier]

I think this is an application level concern, it should be pretty easy to display one or the other regardless of the representation that is used at the protocol level.

Yes, but there is no reason to have a different model in the application from the protocol, this make things harder to implement. That said it is the approach I took for my implementation (NDLC).

Also, most implementation will likely follow the model of the protocol to present things to the user (except if my implementation becomes the most used), making it the standard, and hard to reason about.

What do you mean by "non-discrete outcomes"? And how does the PnL representation make it easier?

I don't know if I used the right term, but the concept of payoff function is quite used in game theory or even in finance, where the vertical axis is the reward, and the horizontal axis the price of the instrument at the expiry day.

In our Trump bet, our payoff function is discrete, but in finance this is represented as a curve. (set by a few parameter)

I think I should not call it PnL representation but payoff function .
The current representation as Contract Info is not really representative of anything people are familiar with.

[Tibo-lg]

Yes, but there is no reason to have a different model in the application from the protocol, this make things harder to implement. That said it is the approach I took for my implementation (NDLC).

You can have a single model, but present it in different ways. In the p2pderivatives app we show the PnL (only after contract is terminated though), which is easily computed from the collateral and output value.

I don't know if I used the right term, but the concept of payoff function is quite used in game theory or even in finance, where the vertical axis is the reward, and the horizontal axis the price of the instrument at the expiry day.

In our Trump bet, our payoff function is discrete, but in finance this is represented as a curve. (set by a few parameter)

I think I should not call it PnL representation but payoff function .
The current representation as Contract Info is not really representative of anything people are familiar with.

I agree with having a payout function (see #81 (comment)), but I'm not sure about having a continuous function to describe discrete outcomes (or maybe I misunderstood what you mean by payout curve?). Also I also feel we shouldn't go to close to specific use cases like financial contracts at the specification levels. Again I feel this can "easily" be done at the application level. For example, some people at CG worked on a tool to generate outcomes for financial contracts: https://docs.google.com/spreadsheets/d/1nzeD2F908BEbrh6a-CsnCHKBP3PDIDO0-Djysot3RHc/edit