Assuming Alice (Maker) and Bob (Taker) want to engage in an exchange of red (R-Token) and blue (B-Token). Alice is offering three R-Token in exchange for three B-Token. Both have a direct channel within the Red Token Network and a Blue Token Network and they deposited their respective amount of token into the their channels.
Furthermore it exists a Commitment Service which is also listening to incoming offers and comes into play at contract signing (Commitment Phase).
Commitment Service #CS
1) Offer Spawn
Alice broadcasts the offer which is a description of a receiving trasnfer and an outgoing transfer to the public chatroom. Commitment Service as well as traders are listening to that chatroom.
[(orderID/R/3/B/3/#CS)sigA]
id
sell_token
sell_amount
buy_token
buy_amount
signature
orderhash
Red
3
Blue
3
sigA
Bob wants to accept this offer and contacts the CS. Commitment Service accepts to be the chosen CS.
Bob sends an offer acceptance to #CS with orderID.
2) Offer match
CS has found the match and will initiate the trade by starting the Commitment Phase
2.1) #CS initiates trade. Sends commitment request to both. Initiates time out.
CS sends commitment request to Alice and to Bob.
[(orderID/address[opponent])sigCS]
To Alice
id
opponent
secrethash
signature
orderhash
address[bob]
secrethash
sigCS
To Bob
id
opponent
secrethash
signature
orderhash
address[Alice]
secrethash
sigCS
3.2) Alice's and Bob's Raiden Nodes create a commitment by generating the balance proof containing this locked payment for the oppenent and pass it back to their Raidex Node which pass it back to #CS.
Also they send validating data in order to make #CS able to validate the opponents BP. Both BPs contain lockedTransfer with hash of #CS
If the taker does not respond in time it invalidates the commitment phase and proceed step 3.1 with the next candidate.
3) #CS collects BPs. It verifies the correctness of the given state, It creates the commitment message. It signs the commitment message and send it to both parties.
[(BP_A, BP_B, secret)sigCS]
4) Settlement
After receiving the message Alice and Bob can safely unlock . The blocked amount gets reliefed.
Alice sends unlocked payment of 3 R-Token.
Bob sends unlocked payment of 3 B-Token.
Commitment Service acts as or cooperates with Monitoring service to guarantee binding.
Misbehavior:
If one of the parties do not come after their commitment the other one will go on chain.
Lets assume Bob misbehaves and does not pay alice.
Alice will register the secret.
Alice will close the B-Token Channel with Bob.
~~Two Options occur:
1) Bob never sent anything again to Alice after the commitment was made. The Nonce will be the same as in the commitment message. The Token Network Contract makes the commitment effective.
2) Other payments got routed through from Bob to Alice. Alice only accepts BP's which have the commitment hash in the message. The BP with a higher nonce has therefore the commitment hash. The Token Network Contract will acknowledge that there is an unfulfilled commitment looks into the registry and makes the commitment effective.
Assuming Alice (Maker) and Bob (Taker) want to engage in an exchange of red (R-Token) and blue (B-Token). Alice is offering three R-Token in exchange for three B-Token. Both have a direct channel within the Red Token Network and a Blue Token Network and they deposited their respective amount of token into the their channels.
Furthermore it exists a Commitment Service which is also listening to incoming offers and comes into play at contract signing (Commitment Phase).
Commitment Service #CS
1) Offer Spawn
Alice broadcasts the offer which is a description of a receiving trasnfer and an outgoing transfer to the public chatroom. Commitment Service as well as traders are listening to that chatroom.
[(orderID/R/3/B/3/#CS)sigA]
Bob wants to accept this offer and contacts the CS. Commitment Service accepts to be the chosen CS. Bob sends an offer acceptance to #CS with orderID.
2) Offer match
CS has found the match and will initiate the trade by starting the Commitment Phase
2.1) #CS initiates trade. Sends commitment request to both. Initiates time out.
CS sends commitment request to Alice and to Bob.
[(orderID/address[opponent])sigCS]
To Alice
To Bob
3.2) Alice's and Bob's Raiden Nodes create a commitment by generating the balance proof containing this locked payment for the oppenent and pass it back to their Raidex Node which pass it back to #CS. Also they send validating data in order to make #CS able to validate the opponents BP. Both BPs contain lockedTransfer with hash of #CS
[(BalanceProof_A)sigA, validating_data] [(BalanceProof_B)sigB, validating_data]
Misbehavior:
If the taker does not respond in time it invalidates the commitment phase and proceed step 3.1 with the next candidate.
3) #CS collects BPs. It verifies the correctness of the given state, It creates the commitment message. It signs the commitment message and send it to both parties.
[(BP_A, BP_B, secret)sigCS]
4) Settlement
After receiving the message Alice and Bob can safely unlock . The blocked amount gets reliefed.
Alice sends unlocked payment of 3 R-Token. Bob sends unlocked payment of 3 B-Token.
Commitment Service acts as or cooperates with Monitoring service to guarantee binding.
Misbehavior:
If one of the parties do not come after their commitment the other one will go on chain. Lets assume Bob misbehaves and does not pay alice.
Alice will register the secret. Alice will close the B-Token Channel with Bob.
~~Two Options occur: 1) Bob never sent anything again to Alice after the commitment was made. The Nonce will be the same as in the commitment message. The Token Network Contract makes the commitment effective.
2) Other payments got routed through from Bob to Alice. Alice only accepts BP's which have the commitment hash in the message. The BP with a higher nonce has therefore the commitment hash. The Token Network Contract will acknowledge that there is an unfulfilled commitment looks into the registry and makes the commitment effective.
Open Questions:
Commitment Deposit for Commitment Phase
Taker commits directly
~~