Marmara CC Validation Rules

Marmara Antara (CC) Module Validation Rules

This is a specification for rules enforced for Marmara cc transactions in Marmara module validation code.
Doc Version: 0.2.0

What's new

in 0.2.0
many updates in validation

in 0.1.5

• rule added: for issue/transfer tx disable spending activated coins with global pk
• rule added: for issue/transfer tx, for previous lcl vouts compare opret pubkeys with the validated tx pubkeys
• rules added: disable creation of tx with funcids 'A','K' and 'C' (this is special kinds of tx)
  

in 0.1.4

• removed rule 'coins from normal inputs are allowed only to the same cc vout pubkey'
• changed rule: 'check the available settled amount more or equal the loop amount in opret'
  

in 0.1.3:

• added issue tx check rule for settlement tx validation
  

in 0.1.2:

• added new check that the tx referred by the baton is a cc tx (to prevent fake issue or transfer txns)
• added new check stake tx is not spent with marmara global pk
  

in 0.1.1:

• specified how check 'Activation coin is always to self' is performed
  

---

Rules for tx creating activated coins (funcid='A')

• coins from normal inputs are allowed only for transactions creating activated coins.
  This kind of tx is funded from normal inputs, so we could only validate such txns when they are being spent. If such a tx is considered as invalid we cannot remove them from the chain and should always ignore them. To correctly calculate the amount of activated coin (ignoring possible invalid 'A' tx outputs) we will use both in the validation and rpc code a unified function IsMarmaraActivatedVout() that will check previous txns funding activated addresses and selecting only valid vouts.

Rules for locked-in-loop coins

There are two kinds of request txns: 'Create Loop' tx (funcid='B') and 'Request Credit' tx (funcid='R')

These txns do not have cc inputs so they will be checked only when they are being spent by a Issue or Transfer tx.
The checks for validity of txns of these kinds are:

• check that the funcid matches issue/transfer tx kind ('B' -> 'I', 'R' -> 'T')
• check 'Request credit for self' rule: check that the pubkey in the opret matches the pubkey in the normal vins
• check issuer/endorser pubkey equals the pubkey in the tx opret (that is, the credit is issued by the pubkey which was requested in request tx)
• check the baton vin presence
• check that the tx referred by the baton is a cc tx (to prevent fake issue or transfer txns)
  

Rules for 'Issue Credit' (funcid='I') and 'Transfer Credit' (funcid='T') txns

For 'Issue Credit' tx:

• Validate 'Create Loop' tx
  

For 'Transfer Credit' tx

• Validate 'Request Credit' tx
  

For both tx kinds check:

• validate the request tx is not in mempool
• check that cc opret is parseable
• check mature height in create tx is more than current height
• check receiver pk != issuer pk (cannot issue credit to self)
• check the pubkey in opret matches endorser/issuer pubkey in cc vout (cc vout is reconstructible with the pubkey)
• check new issuer/endorser activated amount equals amount in endorser/issuer cc vout
• check the baton spending
• disable spending the settlement marker
  

Only for 'Issue Credit' tx:

• the loop amount is taken from the new endorser activated address and goes to 1of2 loop address
• check for the settlement marker presence
• check createtxid in opret matches previous txid
  

Only for 'Transfer Credit' tx:

• check locked-in-loop fund redistribution:
  • 1/N of the loop amount is taken from the new endorser activated address and goes to 1of2 loop address
  • 1/N fund is returned to the previous endorsers normal addresses
• check createtxid in opret matches the createtxid in previous tx opret
• check max endorsers in a loop (currently 64)
  

For both tx types:

• for activated coins vins - disable spending with marmara global pk
• for locked-in-loop vins - get the previous txns, collect their opret pubkeys and compare with the pubkeys in the validated tx vouts (except the latest pubkey). For 'I' previous pks should be empty
• disable unknown cc vins
• identify all cc vouts and check fixed cc balance (including markers)
• check for loop createtxid for LCL vouts

Rules for successful settlement tx (funcid='S') or partial settlement tx (funcid='D')

• check the current chain height > mature height
• check the settlement open/close marker (referring the issue tx) spending
• check the issue tx is valid
  

For funcids 'S' and 'D':

• check the all the available LCL amount goes to the credit holder normal outputs
  

For 'S':

• check the settled amount more or equal the loop amount in opret
  (allowance for '>' is needed because a miner could settle and might add change to the settlement tx)

For 'D':

• check the settled amount less than the loop amount in opret

For both funcids:

• disable unknown cc vouts. Actually no cc vouts allowed for settlement tx. The if amount on the loop is more than the amount in the opret cc change is not created as it is unclear where to send it. All avalabale amount will go to the holder (other validation rules and IsMaramaraLockedAmount should prevent adding and using strange amounts in the loop)
• check for loop createtxid for LCL vouts to prevent spending other loop vouts
  

NOTE: the baton remains unspent in the loop on the holder because now any miner might close the loop (now there is an additional OPENCLOSE marker which is spent)!

Rules for tx with 'C' (coinbase), 'A' (activated coins) and 'K' (lcl coins) funcids:

• check such vouts are spent only to self (with possible aggregation when several utxo spent to one utxo)

Rules for Marmara stake tx validation:

A 'stake tx' is the last tx of a PoS block that spends staking utxo to self.
A 'staking utxo' is an activated coin utxo that participates in PoS algorithm.
These rules are invoked by komodod PoS code (not by the Marmara module validation code):

• check cc opret is present in cc vout
• check vout size = 1
• check stake tx opret matches staking utxo opret
• check stake tx is not spent with marmara global pk
• check stake multiplier is correct for funcid
• check for activated 3x multiplier == 3 if loop is not settled yet
  

There are other stake tx checks by the PoS algorithm.

Rules for Marmara coinbase tx validation

These rules for checking Marmara coinbase are invoked by the consensus code (not by the Marmara module validation code):

• check cc opret is present in cc vout and could be decoded
• for even blocks check opret spent to the address of the stake tx vout
• for even blocks check opret pk == stake tx pk
• check marmara coinbase allowed funcids (checked when opret is decoded)
  

There are other coinbase tx checks by the basic consensus code.