Tx pool

Logic

As Safex logic adds advanced txs with unique entities(Safex account username, offer ID, price peg ID) and purchase of limited resources, additional restrictions must be added to the blockchain and to the tx pool. Tx pool restrictions are rejecting txs that will be invalid if the txs that are previously added to the pool pass to the blockchain. This includes the same Safex account username creation, purchase of a product that doesn have enough quantity for all purchases in the pool,... Similar to rejecting double-spend if tx is sent to multiple nodes, txs that are rejected can be accepted on some other node. After mining and adding txs to the blockchain, the accepted txs that are now not minable, will be rejected after some time(1 hour on mainnet).

After initial checks of the tx in the pool, Safex restrictions are checked (have_tx_safex_restricted function). Restrictions that are set in this functions:

Safex Account

For every safex account creation or edit, m_safex_accounts_in_use vector stores the username of the account that is used in the tx pool for create and edit account txs. If the Safex account with that username is already in the pool, tx is rejected. Possible scenarios are 2 account registrations with the same username, or multiple account edits during the same block.

Safe offer

Similar to safex account, offer IDs are stored in m_safex_offers_in_use vector. Also like Safex account logic, this is preventing editing offer on the same block height multiple times

Safex purchase

For Safex purchase, function checks 2 scenarios: The offer that the user wants to purchase is updated right now. Tx is rejected Somebody is also trying to purchase the item. If the quantity of the product is larger than the quantity of purchases in the pool + the quantity of the purchase that is being checked, the tx is added and the quantity of item purchases in the pool is updated. If the number is smaller, tx is rejected.

Of course, all this logic is preventing only “normal” scenarios when all nodes are unmodified. If modified node mines block with these restrictions changed, the block will be rejected (blockchain.cpp: line 5050). Problematic tx that created conflict is not returned to the pool and all changes in the blockchain are reverted. Rejected scenarios are same as before, but, this time it is possible to include, for example, edit offer and purchase of that offer if order of txs in the block are purchase-offer or if changes to the offer do not affect purchase logic (quantity is not changed to something smaller or price is not bigger than it was before). This way, we enable as many txs as possible without jeopardizing the user experience.

Block template fill

When doing mining selection of txs from the pool, every offer or price peg update is added to the vector. When checking if purchase tx can be added in the block, (file tx_pool.cpp) is_purchase_possible function is checking if purchase quantity will be bigger than quantity available, if the offer that is purchased is being updated or if the price peg that is used by that offer is updated. If any of these checks is true, tx is not added to the block for mining.