Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
173 lines (126 sloc) 6.31 KB

UIP-18: Unit-e Transaction Types

Author:  Julian Fleischer <julian@thirdhash.com>
Status:  Proposed
Created: 2018-11-02

Context

bitcoin has an int32_t field that indicates a version number. bitcoin has only one type of transactions. In unit-e there are several types of transactions. We overloaded the version field of transactions to represent the transaction version as a uint16_t as well as a transaction type.

This UIP's purpose is to clarify the different transaction types and their numeric ids in the transaction type field.

Proposal

Transaction Types

These are the transaction types and their numerical ids as distinguished so far.

0 Payment
1 Coinstake
2 Deposit
3 Vote
4 Logout
5 Slash
6 Withdraw
7 Admin

(0) Payment Transaction Type

Payment Transactions look completely like any other bitcoin transaction. Payment transactions can be standard as well as non-standard.

(1) Coinstake Transaction Type

The first (zeroth) transaction in a block is called coinbase transaction in bitcoin and coinstake transaction in unit-e. The coinstake transaction is explicitly marked as such.

The coinstake transaction looks much like a standard payment, except for the first (zeroth) input "vin[0]". The first input does not refer to any output (this is the same as in bitcoin). Thus vin[0].prevout.hash is always the hash which is all zeroes (00000000000000000000000000000000). vin[0].prevout.n is set to 0.

The scriptSig of vin[0] must contain in exactly that order:

  • the height of the block, serialized according to BIP34
  • the utxo set hash upto the previous height, as outlined in UIP-11

The coinstake transaction must have at least two inputs and exactly one output.

vin[1] is the input which refers to the stake for proposing this block. Additional inputs are not counted as stake. It is also only this input which contributes to the values of the kernel and the stake modifier (same as in particl). Additional input may be added to zap coins into the single output which can then be used as a bigger stake.

The single output is the value of the inputs combined + the reward + the fees earned from this block.

Coinstake transactions have a very strict layout. There is no notion of standard or non-standard for coinstake transactions as they are not relayed by the P2P network but created and directly included by a proposer when building a block.

There must be one and only one coinstake transaction in each block and it must be the first (vin[0]).

(2) Deposit

Deposit transactions are the mean through which validator get included in the validator set. Their purpose is to lock the validator funds so that in case of misbehaviour this can be slashed.

A deposit transaction can have at most 2 outputs: the first (vout[0]) must be a deposit output containing the so called PAYVOTESLASH script, the second, if present must be the change output. The transaction can contain fees as normal.

A PAYVOTESLASH script is composed by 3 sections where the first is a vote script that let the validator spend the transaction if they provide a valid vote. The second is a simple P2PKH script that let the validator to withdraw the funds. The last part of the script let anybody with a proof of a validator's wrongdoing to punish him effectively spending the whole deposit. For more details see the description of the other finalization related transactions below.

(3) Vote

Vote transactions are the mean through which the validator commits to a specific history of the blockchain.

The structure of this transaction is very strict:

  • it must contain one single input, spending a previous deposit, vote or logout transaction.
  • it must contain one single output with the same value of the transaction spent and the same script (a PAYVOTESLASH).
  • no fees are allowed.

(4) Logout

Logout transactions are the mean through which a validator can start the process to be excluded from the validator set and retrieve its funds.

The structure of this transaction is very strict:

  • it must contain one single input, spending a previous deposit or vote transaction.
  • it must contain one single output with the same value of the transaction spent and the same script (a PAYVOTESLASH).

(5) Slash

Logout transactions are the mean through which anybody can punish a validator who broke the protocol rules by sending illegal votes.

The structure of this transaction is very strict:

  • it must contain one single input, spending a previous deposit, vote or logout transaction and containing the proof of the misbehaviour (the two offending votes signed by the offender).
  • it must contain at least 1 output burning 96% of the current validator deposit (it might be more that the simple value of the previous transaction as this must account for possible rewards accumulated so far by the validator).
  • it can then contain various other outputs to distribute the remaining 4%.

(6) Withdraw

Logout transactions are the mean through which a validator can recover the funds it locked with the initial deposit transaction.

The structure of this transaction is very strict:

  • it must contain one single input, spending a previous logout or vote transaction.
  • it can contain a single output that contains a P2PKH script to the same address that made the initial deposit.

(7) Admin

Admin transactions are commands which can be sent while the network is in permissioned mode. They affect the validator set only. After the network is fully opened and anyone can become a validator admin commands will be rejected. The details of this mechanism and the layout of these transactions are defined in UIP-9.

Decision

This UIP is mostly informational. It should be updated with newly added transaction types.

Reference implementation

Implemented in Unit-e

Changelog

  • 2019-04-16 Added reference implementation and changed status to proposed
  • 2018-12-12 Moved to UIP repository as UIP-18
  • 2018-11-06 Accepted as ADR, covering Deposit, Vote, Logout, Slash, and Withdraw
  • 2018-11-02 Created as ADR, covering Payment, Coinstake and Admin types

Copyright

This document is dual-licensed under CC0 and MIT.

You can’t perform that action at this time.