[Blueprint] "Requestor does not pay for computation" use case in Concent API

[rwrzesien]

Settings

New settings:

• PAYMENT_DUE_TIME
• PAYMENT_GRACE_PERIOD

For the purpose of the examples below let's assume the following setting values:

• FORCE_ACCEPTANCE_TIME = 4 hours
• SUBTASK_VERIFICATION_TIME = 4 hours
• CONCENT_MESSAGING_TIME = 1 hour
• PAYMENT_DUE_TIME = 12 hours
• PAYMENT_GRACE_PERIOD = 0,5 hour

Step 1: Provider forces getting payment via Concent.

Provider sends ForcePayment to Concent.

Request example

• Endpoint: POST http://concent.golem.network/send/

• Request headers:

  Header	Value
  Content-Type	application/octet-stream
  Concent-Client-Public-Key	cHJvdmlkZXIgcHVibGljIGtleSAxMjM0NTY=

• Request body: ForcePayment:

  {
      'timestamp':            1510401120,     # 2017-11-11 14:52
      'subtask_results_accepted_list': [      # SubtaskResultsAccepted
          {
              'timestamp':           1510401000,     # 2017-11-11 14:50
              'subtask_id':          "xxyyzz",
              'payment_ts':          1510401060,     # 2017-11-11 14:51
              'task_to_compute':   {               # TaskToCompute
                  'timestamp': 1510390800,    # 2017-11-11 10:00
                  'compute_task_def': {
                      'task_id':   '2',
                      'deadline':  1510394400,    # 2017-11-11 11:00
                  },
              },
          },
          ...
      ],
  }

Response example

See various cases in step 2.

Step 2A: Concent rejects provider's request immediately if all passed SubtaskResultAccepted messages from subtask_results_accepted_list are not signed by the same requestor or not related to the same Ethereum account.

Provider receives ServiceRefused from Concent.

Conditions:

• Not all passed SubtaskResultAccepted messages from subtask_results_accepted_list are signed by the same requestor.
• Not all passed SubtaskResultAccepted messages from subtask_results_accepted_list are related to the same Ethereum account.

The message is returned in the HTTP response to the same request that has submitted ForcePayment.

Request example

See step 1.

Response example

• Status code: 200 OK

• Response headers:

  Header	Value
  Content-Type	application/octet-stream

• Response body: ServiceRefused:

  {
      'timestamp': 1510401120,  # 2017-11-11 14:52
      'reason':    "INVALID_REQUEST",
  }

Step 2B: Concent rejects provider's request immediately if any passed SubtaskResultAccepted messages from subtask_results_accepted_list are not beyond payment time.

Concent defines time T0 equal to oldest payment_ts from passed SubtaskResultAccepted messages from subtask_results_accepted_list. Concent gets list of transactions from payment API where timestamp >= T0. Concent defines time T1 equal to youngest timestamp from list of transactions. Concent checks if all passed SubtaskResultAccepted messages from subtask_results_accepted_list have payment_ts < T1. Concent gets list of list of forced payments from payment API where T0 <= payment_ts + PAYMENT_DUE_TIME + PAYMENT_GRACE_PERIOD. Provider receives ForcePaymentRejected from Concent.

Conditions:

• Any of the items from list of overdue acceptances matches condition current_time < payment_ts + PAYMENT_DUE_TIME + PAYMENT_GRACE_PERIOD.
• All passed SubtaskResultAccepted messages from `subtask_results_accepted_list are signed by the same reqestor.
• All passed SubtaskResultAccepted messages from subtask_results_accepted_list are related to the same Ethereum account.

The message is returned in the HTTP response to the same request that has submitted ForcePayment.

Request example

See step 1.

Response example

• Status code: 200 OK

• Response headers:

  Header	Value
  Content-Type	application/octet-stream

• Response body: ForcePaymentRejected:

  {
      'timestamp': 1510401120,  # 2017-11-11 14:52
      'reason':    "TIMESTAMP_ERROR",
  }

Step 2C: Concent rejects provider's request immediately if there is no value to be paid.

Concent defines value V equal to sum of payment values from passed SubtaskResultAccepted messages from subtask_results_accepted_list minus added sum of values from list of transactions and sum of values from list of forced payments. Provider receives ForcePaymentRejected from Concent.

Conditions:

• V <= 0.
• All of the items from list of overdue acceptances matches condition current_time < payment_ts + PAYMENT_DUE_TIME + PAYMENT_GRACE_PERIOD.
• All passed SubtaskResultAccepted messages from subtask_results_accepted_list are signed by the same requestor.
• All passed SubtaskResultAccepted messages from subtask_results_accepted_list are related to the same Ethereum account.

The message is returned in the HTTP response to the same request that has submitted ForcePayment.

Request example

See step 1.

Response example

• Status code: 200 OK

• Response headers:

  Header	Value
  Content-Type	application/octet-stream

• Response body: ForcePaymentRejected:

  {
      'timestamp': 1510401120,  # 2017-11-11 14:52
      'reason':    "NO_UNSETTLED_TASKS_FOUND",
  }

Step 2D: Concent forces payment.

Concent defines time T2 (end time) equal to youngest payment_ts from passed SubtaskResultAccepted messages from subtask_results_accepted_list. Concent makes transaction from requestor's deposit to provider's account on amount V with payment_ts set to T2. If there is less then V on requestor's deposit, Concent transfers as much as possible. Provider receives ForcePaymentCommitted with payment_ts set to T2 from Concent. Requestor receives ForcePaymentCommitted with payment_ts set to T2 from Concent out of band.

Conditions:

• V > 0.
• All of the items from list of overdue acceptances matches condition current_time > payment_ts + PAYMENT_DUE_TIME + PAYMENT_GRACE_PERIOD.
• All passed SubtaskResultAccepted messages from subtask_results_accepted_list are signed by the same requestor.
• All passed SubtaskResultAccepted messages from subtask_results_accepted_list are related to the same Ethereum account.

The message ForcePaymentCommittedis returned in the HTTP response to the same request that has submittedForcePayment`.

Request 1 example

See step 1.

Response 1 example

• Status code: 200 OK

• Response 1 headers:

  Header	Value
  Content-Type	application/octet-stream

• Response 1 body: ForcePaymentCommitted:

  {
      'timestamp':              1510401120,  # 2017-11-11 14:52
      'payment_ts':             1510401180,  # 2017-11-11 14:53
      'task_owner_key':         "12345",
      'provider_eth_account':   "54321",
      'amount_paid':            10.99,
      'amount_pending':         0.01,
      'recipient_type':         "PROVIDER",
  }

Request 2 example

• Endpoint: POST http://concent.golem.network/receive-out-of-band/

• Request 2 headers:

  Header	Value
  Content-Type	application/octet-stream
  Concent-Client-Public-Key	cmVxdWVzdG9yIHB1YmxpYyBrZXkgMTIzNDU2=

Response 2 example

• Status code: 200 OK

• Response 2 headers:

  Header	Value
  Content-Type	application/octet-stream

• Response 2 body: ForcePaymentCommitted:

  {
      'timestamp':              1510401120,  # 2017-11-11 14:52
      'payment_ts':             1510401180,  # 2017-11-11 14:53
      'task_owner_key':         "12345",
      'provider_eth_account':   "54321",
      'amount_paid':            10.99,
      'amount_pending':         0.01,
      'recipient_type':         "REQUESTOR",
  }

[cameel]

1) Step 2C

Any of the items from list of overdue acceptances matches condition current_time > payment_ts + - PAYMENT_DUE_TIME + PAYMENT_GRACE_PERIOD.

It's supposed to be `payment_ts +` or `payment_ts -`?

BTW, you're missing the backticks on a lot of variable names and they kinda get lost among the text.

2) Step 2C

Any of the items from list of overdue acceptances matches condition current_time > payment_ts + - PAYMENT_DUE_TIME + PAYMENT_GRACE_PERIOD.

Shouldn't it be the opposite? When this condition is satisfied, the payment **is** beyond payment time so it should not fall into this case according to the title.

3) Step 2C and step 2D seem the same to me. 2C says "not beyond payment time" which means the same thing as "not overdue" in 2D.

4) Step 2D

• V <= 0.
• All of the items from list of overdue acceptances matches condition current_time < payment_ts + PAYMENT_DUE_TIME + PAYMENT_GRACE_PERIOD.

I think it should be either one or the other. The way you wrote it it looks like both need to be satisfied at the same time.

5) Step 2B. Same here. It should be one or the other.

6) Step 2E

All of the items from list of overdue acceptances matches condition current_time < payment_ts + PAYMENT_DUE_TIME + PAYMENT_GRACE_PERIOD

I think it should be the opposite. Your condition currently says that no payment is overdue.

7) Step 1

> - At least one obligation from requestor to provider defined in SubtaskResultAccepted is overdue.
> - Requestor committed a batch payment but the payment is incomplete thus provider has unsatisfied payment obligation.

`ForcePayment` message should be processed even if these conditions are not satisfied. The second step take care of it.

8) Step 2E

The message is returned in the HTTP response to the same request that has submitted ForcePayment.

There are two messages. Which one is returned in the HTTP response to the same request?

9) There is no case that says what happens if the requestor does not have enough deposit to pay for his computations. There's 2A but it only mentions communication fees. Communication fee is the small payment that the client must pay before Concent will even respond. It's not the same as payment for computation.

[rwrzesien]

@cameel Ad 1). Updated (but off course some backticks might be still missing, if I find any I will update). Ad 2). Right, it should be opposite, I was probably thinking how to write a correct path, forgetting that I am describing negative scenario first. Ad 3) I have updated 2D description. Ad 4) I used to write one after another, which means that each next step has satisfied condition from previous one. This way somebody looking on step X doesn't need to check conditions from previous ones. But if my explanation is not convincing I will change, please let me know. Ad 5) Same here. Ad 6) Correct. Ad 7) Right, I was trying to show it from client point of view, why he is starting communication, but it should no matter to Concent. Ad 8) Updated. Ad 9) There is If there is less then V on requestor's deposit, Concent transfers as much as possible.

[rwrzesien]

Removed 2A and updated conditions.