Skip to content

TransactionRequest

  • from User, Solver

Purpose

A user or solver requests that a transaction candidate be ordered and executed.

Structure

Field Type Description
tx TransactionCandidate the actual transaction to be ordered
resubmission TxFingerprint option reference to the previous occurrence

The resubmission indicates if there was a previous occurrence of the very same transaction candidate which either has failed or a needs to be executed again, e.g., because it is a recurring payment.

This is the "bare-bone" version for V1. Additional user preferences can be supplied in future versions concerning - how the response will be given - how long duplicate checks are to be performed - etc.

Effects

  • The receiving worker is obliged to store the new transaction (until after execution) unless it is out of storage. (Suitable fee mechanisms may be introduced to ensure that the probability of sufficient storage is relatively high, which involves a trade-off against cheap fees.)
  • The received transaction request might complete the current batch.
  • The worker assigns a batch number (the number of the current batch) and a transaction number (before the closing of the batch) such that this transaction candidate can be referenced via the corresponding TxFingerprint—unless the worker already has received a request for the same transaction candidate after the resubmission time stamp. If the exact same transaction candidate has already been ordered, the request is disregarded; optional messages may be sent to the sender of the request.

Triggers

Todo

move this as a response to EPID message

(Wiki) links on this page