Payment¶

Terms.

parcel: the payment transaction and the payload transaction packed together. The unit of data that node expects from the client to perform approval.

payload: the client's transaction he or she needs to approve with the Universa

payment: the client's transaction that spends one or more TU to pay for the payload processing.

cost: payload processing cost in TU, positive integer.

payment: transaction in TU contracts owned by the client reducing its remainig value by some value, or this value.

Transaction Units (TU)¶

is performed using special type of the contract, TU (TestTU on testnet). The TU contract has a data.transaction_units field which owners has a right to decrease. By decreasing this field client pays for the transaction processing, see quantization. The client buys TUs using URS service and using the main web interface. See example of template of the TU in attached files.

Preparing the payment.¶

1. The client obtains some TU contract to the key it will use to authenticate self as a universa client (the key used to authenticate API call to the Network).

2. The client estimates the cost of the transaction he is going to perform (with client API), otherwise the client software calculates it automatically.

3. The client creates new TU contract revision and decreases data.transaction_units to the corresponding number if units by the payment. Payment must be greater or equal to the cost. Having payment greater than the cost only increases the priority of the transaction processing and has no effect unless the network is busy.

4. The client software sends to the network the parcel containing_two_ transactions packed together : [TU(n) -> TU((n-payment)] and the actual transaction

node processing the paid transaction from the client¶

1. The node receives a parcel and checks that there is a payment transaction, signed by the same user that has authenticated, and the payment should be >= 1. Otherwise the parcel is discarded.

2. The TU contract is checked to have valid issuer key (one of preset URS keys) and name/type fields combination. If the check is failed, the whole transaction is ignored with error message reported. Important that the node must not check the signatures validness, only the values, without any RSA/EC processing. If the check fails, the parcel is discarded.

3. The payment transaction is checked against the ledger - it should be APPROVED. This check must precede the signature verifications with RSA/EC/whatever other siganture checks. If the payment transaction is missing or has any other state, the parcel is discarded.

4. Node checks the payment contract locally spending as much as 1 quantum to check. If the check fails for any reason. At this point the node performs standard check, which includes RSA/EC signature verification and so on. If the local check fails, the parcel is discarded.

5. this is a simplified procedure!. The node starts voting on the payment contract. If the solution is negative, the parcel is discarded.

6. As soon as the network approves the payment, the node sets payload max processing cost to the payment, and process it as usual with the sole addition that it transmits accross the network the source parcel not the payload contract.

7. The payment is therefore accepted and not refunded whatever will be the network solution.

node processing the paid transaction from another node¶

1. Node checks that the payment contract is APPROVED or at least has PENDING_POSITIVE¹ state, otherwise it postpones the parcel (keeps it in short-time cache to not to download it again).

1.1. If the node receives notification from another node concerning such a postponed parcel, it rechecks its payment state, and resumes its processing if it is APPROVED or PENDING_POSITIVE.

1.2. Therefore the payload having unapproved payment will be ignored and will not get negative consensus which is important (we should not DECLINE a potentially valid transaction only for the reason its payment is malformed or erroneous). The originating node soon will trash it as it will gent negative on the payment contract.

1. If/when the payment contract is OK, it processes payload contract setting maximum processing cost to the payment, as usual.

Conclusion¶

Some important notes to underline:

• The payment contract is checked with as little effort as possible, trying to minimise effort on the bad payment contracts detection. For example, we do not verify the signatures until we found everything else is locally OK.

• The system does not refunds payments.

• There should be a rough sanity check, e.g. payment should not be more than, say total number of new and revoking contracts in te payload multiplied by 5, and less than this total number divided by 10, or something like. Such parcels should be discarded without accepting the payment as it is almost always an error. We could reconsider it later.