Author: Julian Fleischer <[email protected]>
Status: Proposed
Created: 2018-11-02
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.
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
Payment Transactions look completely like any other bitcoin transaction. Payment transactions can be standard as well as non-standard.
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]).
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.
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.
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).
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%.
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.
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.
This UIP is mostly informational. It should be updated with newly added transaction types.
Implemented in Unit-e
- 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