Steem: All that you Need to Know about the Pool Transactions. Bitcoin

parlament (2)in #bitcoin • 8 years ago (edited)

All that you need to know about the pool transactions!

As you probably know, before the transaction gets to Miner nodes rebroadcast it to each other, as long as it does not spread across the network. Transactions that have not yet been processed and confirmed Miner stored in the storage nodes in the pool (mempool). After reviewing the transaction pool, a node can decide whether to relay the received new transaction.

Pools on the network as much as nodes. Since #bitcoin network is distributed, not all nodes receive specific transactions at the same time, so some nodes store more transactions than others. In addition, software components running on different equipment with different amounts of RAM. For these reasons, the state of the pool on each unique site.

As transactions fall into the pool

Before you put the transaction in its pool, the node should perform the following steps.

Check the correct syntax of the #transaction.
Make sure that the list of inputs and outputs of the transaction are not empty.
Make sure that the transaction size in bytes is less than the maximum block size.
Make sure all the exits and their amount are valid monetary values.
Make sure that the transaction is not coinbase-transaction.
Make sure that the value does not exceed the maximum nLockTime integer (INT_MAX), that the transaction size is a minimum of 100 bytes and the number of operands signatures is less than or equal to 2.
Reject the transaction, or if the algorithm scriptSig scriptPubKey it performs any custom actions.
Reject the transaction if the transaction is already in the pool or main branch block.
Reject the transaction, if any of its inputs to the output referenced in another transaction pool.
Find transactions for each entry in the main branch block transaction pool or the corresponding output. If any of its inputs is not, add the transaction to the group "transactions of orphans."
For each entry, if the transaction with the appropriate remedy is to coinbase-transaction, make sure it has at least 100 (COINBASE_MATURITY) evidence, otherwise reject the transaction.
For each entry, if the appropriate input output does not exist, reject the transaction.
Using transactions with related outputs, make sure that each entry and the amount of cash values are valid.
If the sum of the inputs is less than the sum of outputs, to reject the transaction.
If the commission per transaction (defined as the difference between the sum of the sum of the inputs and outputs) is too small to enable the transaction to an empty block, reject the transaction.
Check #scriptPubKey correct algorithm for each input, and if any of the checks fails, reject the transaction.
Add a transaction in the pool.
If the transaction is addressed to the node, add it in the wallet.
Relay transaction other nodes.
For each transaction, orphans, in which the current transaction is used as one of the inputs, recursively perform all steps described 20.

If the transaction passes all these tests, it is placed in a pool and the node begins to retransmit it. If not, the transaction is not relayed.

How to obtain a new block influences the state of the pool

When a node receives a new valid block, it removes from the #pool of all the transactions contained in the received block, as well as transactions with conflicting inputs. As a result, the pool size is greatly reduced:

Transactions that do not exist in the new block, remain in the pool and re-assembly is not relayed, t. E. The node relays the transaction only when it is added to the pool. If the transaction is not confirmed within a few blocks, the responsibility for it lies with the retransmission of the purse.

What happens if there's no memory unit

Unlike mining, no financial motivation to maintain the work site users do not have. Because of this, most of the units run on low-powered hardware, and the pool is often exhausting all available memory. In older versions of #bitcoind node while simply crashes and restarts with an empty pool.

In later versions bitcoind (0.12+) while approaching the size of the pool of available memory volume unit sets the minimum commission. Transactions in which the Commission on 1 KB of data does not reach this threshold, are immediately removed from the pool, then the pool is only permitted transactions of sufficient Commission.

Over time, the unit reduces the threshold fee, gradually returning it to minrelayfee value. For the Commission of the threshold can be monitored via getmempoolinfo #RPC-team. The following is an example of changing the minimum fee pool for random time interval.