Difference between revisions of "Transaction"

From Minter Wiki
(Initial English release)
m
 
Line 6: Line 6:
 
Any operation in Minter network goes through its own path, starting with the formation of a special message in the predefined form. It is then sent to a masternode and checked for honesty and admissibility. After successful check transaction will be granted an unconfirmed status. All pending transactions that are validated, but not confirmed yet are referred to a mempool (memory pool).
 
Any operation in Minter network goes through its own path, starting with the formation of a special message in the predefined form. It is then sent to a masternode and checked for honesty and admissibility. After successful check transaction will be granted an unconfirmed status. All pending transactions that are validated, but not confirmed yet are referred to a mempool (memory pool).
  
Validator takes transactions from the mempool, collects them into a block and offers to the rest of validators to confirm the resulting block. If block has been confirmed, all included transactions receive the status of confirmed transactions and become a part of Minter blockchain forever.
+
Validator takes transactions from the mempool, collects them into a block and offers to the rest of validators to confirm the resulting block. If block has been confirmed, all included transactions receive the status of confirmed transactions and become a part of Minter [[blockchain]] forever.
  
 
<gallery>
 
<gallery>
Line 14: Line 14:
  
 
==Transaction Structure==
 
==Transaction Structure==
All blockchain operations are data submissions, so in addition to the actual data (for example, "Minterscan launches the Hell’s Kitchen Project") one must specify the type of message to send, attach the appropriate data (when sending coins - specify the receiver, coin and amount; if cashing out the check - the check data and password to open, etc.), include processing fees, assign a unique voucher number, directly sign the network to which it will be sent and then digitally sign all of this.  
+
All blockchain operations are data submissions, so in addition to the actual data (for example, "Minterscan launches the Hell’s Kitchen Project") one must specify the type of message to send, attach the appropriate data (when sending coins - specify the receiver, [[Custom coin|coin]] and amount; if cashing out the check - the check data and password to open, etc.), include processing fees, assign a unique voucher number, directly sign the network to which it will be sent and then digitally sign all of this.  
  
 
The correctly generated message can already be called a transaction, but not yet sent. The overall structure of the Minter network transaction is as follows:
 
The correctly generated message can already be called a transaction, but not yet sent. The overall structure of the Minter network transaction is as follows:
Line 46: Line 46:
 
As blockchain consists of blocks, a block consists of transactions (and service information, see [[Block]] for details). By default, the Minter network block may contain between 0 and 10,000 transactions. However, the maximum number of transactions can be forcibly reduced by 30%, if a too fast validator appears on the network and takes over all operations. Once decentralization is restored, the maximum number of transactions in the block will be gradually restored by +5% increments.
 
As blockchain consists of blocks, a block consists of transactions (and service information, see [[Block]] for details). By default, the Minter network block may contain between 0 and 10,000 transactions. However, the maximum number of transactions can be forcibly reduced by 30%, if a too fast validator appears on the network and takes over all operations. Once decentralization is restored, the maximum number of transactions in the block will be gradually restored by +5% increments.
  
Transactions are collected in block in a row, regardless of [[Transaction types in Minter network|Transaction Type]] (totally 14 types in Minter network). One must pay [[Transaction Commissions|Commission]] which is 0.005 to 10 BIPs for any of them. Transaction fees and block creation awards create validators’ income.  
+
Transactions are collected in block in a row, regardless of Transaction Type (totally 14 types in Minter network). One must pay [[Minter transaction fees|Commission]] which is 0.005 to 10 BIPs for any of them. Transaction fees and block creation awards create validators’ income.  
  
 
==Double spend==
 
==Double spend==
It’s worth specifically to point out the main problem of blockchain - [[double spend]], i.e. the possibility to spend the same money twice, sending two transactions simultaneously. Processing a transaction takes time, so one having 100 BIP in wallet, can potentially send one 100 BIP transaction to Peter and another 100 BIP transaction to John. Until the transactions are processed, two different validators, not knowing about the second transaction, may try to process both, each of them on their own.  
+
It’s worth specifically to point out the main problem of blockchain - [[double spend]], i.e. the possibility to spend the same money twice, sending two transactions simultaneously. Processing a transaction takes time, so one having 100 [[BIP]] in [[:Category:Minter Wallets‏‎| wallet]], can potentially send one 100 BIP transaction to Peter and another 100 BIP transaction to John. Until the transactions are processed, two different validators, not knowing about the second transaction, may try to process both, each of them on their own.  
  
The problem is exacerbated by the fact that validators theoretically may be interested in confirming both transactions (in order to get commission for both or if they are associated with a fraud sender) by signing one block twice at the same height, but with different data. That leads to a blockchain split (fork), adding a dangerous conflict to the network. Therefore, for such behaviour in Minter, validator is imposed [[Is it possible to lose delegated funds|the fine]] by 5% of the stake and all its delegates receive a forced recall of their stakes.
+
The problem is exacerbated by the fact that validators theoretically may be interested in confirming both transactions (in order to get commission for both or if they are associated with a fraud sender) by signing one block twice at the same height, but with different data. That leads to a blockchain split (fork), adding a dangerous conflict to the network. Therefore, for such behaviour in Minter, validator is imposed [[Is it possible to lose delegated funds|the fine]] by 5% of the stake and all its delegates receive a forced recall of their [[stake]]s.
  
 
==References==
 
==References==

Latest revision as of 07:30, 12 October 2019

Tx.png

Transaction is a logically completed data exchange operation, that either gives a successful result or is cancelled entirely. Transactions in Minter network are processed by validators for a fee, known as a commission.

Transaction path

Any operation in Minter network goes through its own path, starting with the formation of a special message in the predefined form. It is then sent to a masternode and checked for honesty and admissibility. After successful check transaction will be granted an unconfirmed status. All pending transactions that are validated, but not confirmed yet are referred to a mempool (memory pool).

Validator takes transactions from the mempool, collects them into a block and offers to the rest of validators to confirm the resulting block. If block has been confirmed, all included transactions receive the status of confirmed transactions and become a part of Minter blockchain forever.

Transaction Structure

All blockchain operations are data submissions, so in addition to the actual data (for example, "Minterscan launches the Hell’s Kitchen Project") one must specify the type of message to send, attach the appropriate data (when sending coins - specify the receiver, coin and amount; if cashing out the check - the check data and password to open, etc.), include processing fees, assign a unique voucher number, directly sign the network to which it will be sent and then digitally sign all of this.

The correctly generated message can already be called a transaction, but not yet sent. The overall structure of the Minter network transaction is as follows:

Transaction {
  Nonce
  ChainID
  GasPrice
  GasCoin
  Type
  Data
  Payload
  ServiceData
  SignatureType
  SignatureData
}
  • Nonce - unique number of the outgoing transaction. Used to prevent re-execution;
  • ChainID - Network ID where transaction is sent. Is specified to exclude the possibility to repeat the testnet transaction in the mainnet. 1 - testnet, 2 – mainnet;
  • Gas Price - commission multiplier. There is a Spam Protection rule in Minter network that the transaction fee is multiplied as the number of not performed transactions increases;
  • Gas Coin — coin, in which commission is paid by;
  • Type - transaction type;
  • Data- transaction data (depends on the type);
  • Payload - user data, such a message;
  • Service Data - reserved field;
  • Signature Type – signature type: single or multiple;
  • Signature Data - transaction signature.

Blocks and commissions

As blockchain consists of blocks, a block consists of transactions (and service information, see Block for details). By default, the Minter network block may contain between 0 and 10,000 transactions. However, the maximum number of transactions can be forcibly reduced by 30%, if a too fast validator appears on the network and takes over all operations. Once decentralization is restored, the maximum number of transactions in the block will be gradually restored by +5% increments.

Transactions are collected in block in a row, regardless of Transaction Type (totally 14 types in Minter network). One must pay Commission which is 0.005 to 10 BIPs for any of them. Transaction fees and block creation awards create validators’ income.

Double spend

It’s worth specifically to point out the main problem of blockchain - double spend, i.e. the possibility to spend the same money twice, sending two transactions simultaneously. Processing a transaction takes time, so one having 100 BIP in wallet, can potentially send one 100 BIP transaction to Peter and another 100 BIP transaction to John. Until the transactions are processed, two different validators, not knowing about the second transaction, may try to process both, each of them on their own.

The problem is exacerbated by the fact that validators theoretically may be interested in confirming both transactions (in order to get commission for both or if they are associated with a fraud sender) by signing one block twice at the same height, but with different data. That leads to a blockchain split (fork), adding a dangerous conflict to the network. Therefore, for such behaviour in Minter, validator is imposed the fine by 5% of the stake and all its delegates receive a forced recall of their stakes.

References