monzero-core.git/src/cryptonote_core/tx_pool.h, branch v0.13.0.2 Monzero core node, command-line wallet, consensus code, and release tooling. https://code.monzero.org/monzero-core.git/atom?h=v0.13.0.2 2018-09-11T13:38:07Z v8: per byte fee, pad bulletproofs, fixed 11 ring size 2018-09-11T13:38:07Z moneromooo-monero moneromooo-monero@users.noreply.github.com 2018-07-18T21:24:53Z urn:sha1:5ffb2ff9b7c301eda5811a939c705f26627c4735 core: cache block template where possible 2018-08-16T12:44:33Z moneromooo-monero moneromooo-monero@users.noreply.github.com 2016-04-17T10:04:01Z urn:sha1:82d1b74500aa7ffab47f428f9ca26bb43cc2d8af This avoids constant rechecking of the same things each time a miner asks for the block template. The tx pool maintains a cookie to allow users to detect when the pool state changed, which means the block template needs rebuilding. Merge pull request #4047 2018-07-19T19:02:20Z luigi1111 luigi1111w@gmail.com 2018-07-19T19:02:20Z urn:sha1:5cade9418944ad63a229be210bfa43ca180b7c94 41b4bf9 tx_pool: cache check_tx_inputs results (moneromooo-monero) replace std::list with std::vector on some hot paths 2018-06-26T21:14:21Z moneromooo-monero moneromooo-monero@users.noreply.github.com 2018-04-15T23:16:02Z urn:sha1:ed2c81ed95be71bace897e62a0c241068cfde7be also use reserve where appropriate tx_pool: cache check_tx_inputs results 2018-06-24T10:22:26Z moneromooo-monero moneromooo-monero@users.noreply.github.com 2018-06-24T09:46:57Z urn:sha1:41b4bf9d6df4bfd59210133416f1a90362794789 This is called a lot when creating a block template, and does not change until the blockchain changes. This also avoids tx parsing when cached. tx_pool: hold off parsing a tx blob till we actually need it 2018-06-02T08:17:41Z moneromooo-monero moneromooo-monero@users.noreply.github.com 2018-06-01T20:50:46Z urn:sha1:2b0c632f329572b6a0d2094ba0fda6c8642b5633 tx_pool: add a max pool size, settable with --max-txpool-size 2018-02-07T13:42:12Z moneromooo-monero moneromooo-monero@users.noreply.github.com 2018-01-29T21:20:24Z urn:sha1:bc61ae69bfb20d2bdfa3d3716691e316bdbb6cb5 Update 2018 copyright 2018-01-26T15:03:20Z xmr-eric eric@moneroeric.com 2018-01-07T05:05:16Z urn:sha1:18216f19dd479466cb7fd38f52d23bddfcfd4880 Merge pull request #2615 2017-11-14T12:53:10Z Riccardo Spagni ric@spagni.net 2017-11-14T12:53:10Z urn:sha1:fd0740e5e7d53e4cf2f7c03501c111545e30836a 10013e94 Protect node privacy by proper filtering in restricted-mode RPC answers (binaryFate) Protect node privacy by proper filtering in restricted-mode RPC answers 2017-11-08T12:07:07Z binaryFate binaryfate@users.noreply.github.com 2017-11-08T12:06:41Z urn:sha1:10013e94342c0d9ca2f10c79779b08affc5209c1 This patch allows to filter out sensitive information for queries that rely on the pool state, when running in restricted mode. This filtering is only applied to data sent back to RPC queries. Results of inline commands typed locally in the daemon are not affected. In practice, when running with `--restricted-rpc`: * get_transaction_pool will list relayed transactions with the fields "last relayed time" and "received time" set to zero. * get_transaction_pool will not list transaction that have do_not_relay set to true, and will not list key images that are used only for such transactions * get_transaction_pool_hashes.bin will not list such transaction * get_transaction_pool_stats will not count such transactions in any of the aggregated values that are computed The implementation does not make filtering the default, so developers should be mindful of this if they add new RPC functionality. Fixes #2590.