The general reason for this feature request is building an fair and secure token exchange which is able to use raiden as the network of transfering the value (respectively the assets or tokens) to each other. Decentralized exchanges where the exchange happens peer-to-peer must have built the security, fairness and all other properties to create a fraudless exchange into the underlying protocol. These protocols are calls Fair Exchange Protocols.
To guarantee fair exchange, the fundament of a working decentralized exchange, three properties have to be fulfilled
fairness
timeliness
effectiveness
To create a protocol fulfilling all properties changes need to be made on both layers of the raiden protocol (smart contract, client)
Effectiveness
As described in #82 and Effectiveness issue, to enable the property effectiveness for fair exchange commitments to an exchange order must be enforcable on the smart contract (SC) level. Since the SC level is the single point of control of the funds it can only be enforceable there.
Commitment - two way payment binding
The idea is to introduce a multisigned commitment. The commitment hast two important functions:
each party makes a promise to make a raiden payment in the future
the commitment contains two of these promises and binds them together
The commitment has the following characteristics:
It is only valid if both parties signed the commitment
The commitment makes two payments effective
The commitment makes two payments be bound together (it is not possible to only claim one of the payments).
Easier described: It can be imagined as a promise two single balance proofs of a future payment bound together so that only both are valid at the same time.
A commitment must contain the following information:
first payment
-- nonce of when the commitment was signed
-- initiator
-- token network address
-- channel id
-- amount
second payment
-- nonce of when the commitment was signed
-- initiator
-- token network address
-- channel id
-- amount
signature initiator 1
signature target 1
signature initiator 2
signature target 2
signature commitment service (optional)
Motivation
The motivation is to commit people to an exchange so that they are not able to not fulfill the payment after signing the commitment (promise). This commitment has to be as fast as possible with reasonable predictability of time duration. The fastest way possible is to sign one message - the commitment message.
Also the binding of the payments is cruical to give the involved participants the certainty and therefore starting a payment on their own to fulfill the commitment.
Specification
Smart Contract
The smart contract (Token Network Contract) must be able to make the commitment effective in the last instance in case anything goes wrong. Since a two payment commitment involves two token network contracts it must be able to see upon closing a channel that this channel is part of an unsolved promise and therefore make the promise effective.
summary:
Commitment must be act as effective payments
Contract has to know if the commitment of its channel was resolved as a valid BP in the past
If not, redistribute Tokens as made in the promise
both signatures of the channel participants must be given to be a valid commitment
Please see: Smart Contract Issue
Raiden Client
The Raiden Client needs to take into account that a promise was made. On the receiving side (target) it must respect that the initiator promised to pay him some token. Until this promise was resolved into an actual raiden payment it must take care that the opposite party is not emptying its channel. It would have to block the promised amount and ignore any payments which exceed the TmpCapacity TmpCapacity = Capacity - commitment amount.
Emptying a channel before the promise was resolved could either happen by:
the initiator making API payments to the target
the respective channel being part of a mediated transfer
Please see: Raiden Client Issue
Why not use a Raiden payment as this kind of promise/Commitment?
I want to answer the question why a locked transfer with the corresponding secret is not suitable as the commitment itself. The reason is the unpredictabiliy of the raiden network itself. One can never assure that the message was received by the other party. Only the opponent can verify that one has committed creating ambiguity about the state of the own commitment. The new introduced commitment / promise takes the commitment creation out of the client into a different protocol. It is only valid with both signatures. A third party can synchronize the signing process and limit it by well predefined timeouts. Less uncertainty is given since only one signed message is needed to be send from the participant to the third party. This enables any participant to commit to a future trade just by himself without the need of the opponent's verification.
Backwards Compatibility
The transfer message send to each other will be increased by another option. This could affect the backwards compatibility. Although if a participant would not have to use this feature if he does not want to, an empty field for the commitment notice would have to be passed to each transfer message. Im unsure if it affects BC what are the others thoughts about it?
Abstract
The general reason for this feature request is building an fair and secure token exchange which is able to use raiden as the network of transfering the value (respectively the assets or tokens) to each other. Decentralized exchanges where the exchange happens peer-to-peer must have built the security, fairness and all other properties to create a fraudless exchange into the underlying protocol. These protocols are calls Fair Exchange Protocols. To guarantee fair exchange, the fundament of a working decentralized exchange, three properties have to be fulfilled
To create a protocol fulfilling all properties changes need to be made on both layers of the raiden protocol (smart contract, client)
Effectiveness
As described in #82 and Effectiveness issue, to enable the property effectiveness for fair exchange commitments to an exchange order must be enforcable on the smart contract (SC) level. Since the SC level is the single point of control of the funds it can only be enforceable there.
Commitment - two way payment binding
The idea is to introduce a multisigned commitment. The commitment hast two important functions:
The commitment has the following characteristics:
Easier described: It can be imagined as a promise two single balance proofs of a future payment bound together so that only both are valid at the same time.A commitment must contain the following information:
Motivation
The motivation is to commit people to an exchange so that they are not able to not fulfill the payment after signing the commitment (promise). This commitment has to be as fast as possible with reasonable predictability of time duration. The fastest way possible is to sign one message - the commitment message. Also the binding of the payments is cruical to give the involved participants the certainty and therefore starting a payment on their own to fulfill the commitment.
Specification
Smart Contract
The smart contract (Token Network Contract) must be able to make the commitment effective in the last instance in case anything goes wrong. Since a two payment commitment involves two token network contracts it must be able to see upon closing a channel that this channel is part of an unsolved promise and therefore make the promise effective.
summary:
Please see: Smart Contract Issue
Raiden Client
The Raiden Client needs to take into account that a promise was made. On the receiving side (target) it must respect that the initiator promised to pay him some token. Until this promise was resolved into an actual raiden payment it must take care that the opposite party is not emptying its channel. It would have to block the promised amount and ignore any payments which exceed the TmpCapacity
TmpCapacity = Capacity - commitment amount.Emptying a channel before the promise was resolved could either happen by:
Please see: Raiden Client Issue
Why not use a Raiden payment as this kind of promise/Commitment?
I want to answer the question why a locked transfer with the corresponding secret is not suitable as the commitment itself. The reason is the unpredictabiliy of the raiden network itself. One can never assure that the message was received by the other party. Only the opponent can verify that one has committed creating ambiguity about the state of the own commitment. The new introduced commitment / promise takes the commitment creation out of the client into a different protocol. It is only valid with both signatures. A third party can synchronize the signing process and limit it by well predefined timeouts. Less uncertainty is given since only one signed message is needed to be send from the participant to the third party. This enables any participant to commit to a future trade just by himself without the need of the opponent's verification.
Backwards Compatibility
The transfer message send to each other will be increased by another option. This could affect the backwards compatibility. Although if a participant would not have to use this feature if he does not want to, an empty field for the commitment notice would have to be passed to each transfer message. Im unsure if it affects BC what are the others thoughts about it?