[WIP] Feature Commitment Transfer Binding: Token Network Contract

[fredo]

I'd like to start the discussion here about the implementation proposal on smart contract level of the introduced feature request Commitment Transfer Binding.

Abstract

As stated in feature request issue a commitment of an exchange must be enforcable on smart contract level to remove the free option problem. Due to the invariants of the commitment the token network contract must understand this commitment in order to resolve the conflict (make the committed payment effective).

Commitment Registry

Commitments and secrets are very similar (secrets make a locked transfer effective -> commitments make two payments effective). Therefor the approach is to adapt mechanisms how to resolve these. The idea is same as there exists a Secret Registry there will be a Commitment Registry. The commitment registry contains details about the two agreed transfers as well as the current nonce when the commitment was made.

Content of Commitment Registry

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)
some block expiry (optional)

Balance Proof Content

I noted this also in Client issue but as a short notice: The balance proof contains the hash of any open commitment which affects the corresponding channel. This enables the TNC to know if to watch out for a commitment or not. It still has to check wether there is a commitment containing the nonce of the submitted BP upon closing

Token Network Contract

The Token Network Contract must take into account that upon closing a channel there might be a commitment of a payment which was not executed yet. There are two options how the TNC figures out if there is an open commitment:

1) the nonce of the submitted balance proof equals the nonce of the commitment
-> This means the opponent did commit but never resolved the commitment by a payment
2) the submitted balance proof contains the hash of the commitment message.
-> This means the oppenent initiated payments after the commitment was made. Neither of these payments were the comitted payment i.e. mediated transfers.

If one of these two conditions apply:

-> Make the commitment effective by redistributing the tokens according to the commitment

[hackaugusto]

I have a few questions:

• When are these commitments registered on-chain? When a channel in the swap is closed?
• Could also clarify why do HTL is not sufficient?

A proposed solution:

• We eventually want to have smart locks in the network. My idea to fix that apply here, since this effectively proposes a new type of lock, a swap commitment lock. It would work as follows: We define a smart contract interface, used to check if a lock has been unlocked at a given block on-chain, then, instead of hard coding the secret registry in the TNC each lock would have its corresponding smart lock address, during the call to unlock the TNC would forward the query was_unlocked to this smart contract address with the lock itself.

The above works, we just need a whitelist in the client, and it allows for arbitrary commitments