Simplify Pay semantics

[nau]

One of Phil's suggestion was to simplify Pay semantics by removing timeout and continuation from it.
We can do this by Eval input and tracking evaluated payments in contract's state.

So, for example, if we have a contract:

Pay id1 alice bob (Value 100) (timeout 1000) (RedeemCC id2)

We could instead have this:

Both (Pay id1 alice bob (Value 100)) (RedeemCC id2)

we could allow any party to do an Eval input transaction to execute payment and save it in state to allow claiming payed money at any point later in time.

One of the issues is was to do in this case:

CommitCash id1 alice (Value 50) 
    (Both (Pay id2 alice bob (Value 100))  (Pay id3 alice charlie (Value 200)))
    Null

There are insufficient funds in Alice's account, and the question is how to handle it.
One way is to split available amount between receivers proportional to payed amount.
Say, Bob gets 16, Charlie gets 32, and left 2 go into contract deposit.

[palas]

It seems there are several issues relating to Pay, and this is an attempt to distill them a bit:

1. Pay has 2 continuations, arguably it should have none (since we hardly ever want to know when a payment has been claimed).

• I did argue for not having continuations in Pay or Redeem, but we decided to keep them for consistency with the rest of constructs. It may as well be that we want to make an exception because they are not useful. We could also argue we don't need continuations for Commit either. Actually, it is often the case that we want to wait for two or more Commits instead of one, and we may want both Commits to be available simultaneously. In those cases continuations are useless.

2. Pay has timeout, arguably it should not have.

• As long as Pay is not executed instantly (and it cannot be done, see below) and Commits have timeouts (Remove second timeout from CommitCC #8), having Pay without timeout would translate into almost every contract risking issuing a FailedPay, since Pay would potentially be waiting until it is to late for the payment to be made (because it expired).

3. Pay takes a payer (in addition to a payee), arguably this should not be needed since it is the contract that owns the money (see issue Stop tracking to whom belongs the money committed #10).

• This is linked to Commits belonging to someone. In Semantics 2.0, we specify the origin Commit instead of the payee.
• Arguably, Commits should not belong to anybody, but all money committed should belong to the contract. I think the whole idea of having ownership for Commits is to ensure that money doesn't get locked in the contract. We could allow the change of ownership of Commits, as we have discussed in the past, that would still preserve the safety features, and maybe we can use that to replace Pay altogether.

4. Pay waits for a participant to claim it, arguably payment should happen instantly.

• This is not possible because of pull model, see below.

5. Pay has to be claimed by the payee, arguably anybody should be able to trigger it or should be triggered automatically.

• We could allow anybody to trigger it, this is a small change to the semantics. Do we want this? Is it fair? Why not?

6. Pay value is determined at the moment of claim, arguably it should be fixed instantly when it is activated.

• The problem is that determining the value cannot be done instantly either. But we can allow anybody to trigger the determination of the value and then allow the recipient to claim the payment. I think this would be more elegant than 5.

7. Another alternative to 5 is to have the claim of Pay to be part of the eval procedure (or reduction in the Semantics 2.0). This has the problems outlined in Alex's post, it is difficult to think of a way of symmetrically and fairly distributing the money atomically, and I think it would not offer any real advantage over 5 or 6.

In general, some of these points that are interleaved. In particular, if Pay was triggered instantly, then many of the other points would become irrelevant. But since nothing can be triggered instantly because extended UTXO is a pull model, that is impossible. On the other hand, acting like it was triggered and accumulating the computation until it is actually triggered, is possible and promising, but it seems a very unstable model and could translate into very unpredictable/unfair fees.