monzero-core.git/src/cryptonote_core/tx_pool.cpp, branch v0.12.0.0Monzero core node, command-line wallet, consensus code, and release tooling.
https://code.monzero.org/monzero-core.git/atom?h=v0.12.0.02018-03-15T16:25:38ZFix typos in various files2018-03-15T16:25:38ZDimitris Apostoloudimitris.apostolou@icloud.com2018-03-01T11:36:19Zurn:sha1:57c0b1ed9f15ca27892a8737156c3b8e32a1625etxpool: Don't bail out when blob_size == tx_size_limit2018-02-16T15:27:08ZLeon Klingelegit@leonklingele.de2018-01-30T15:16:54Zurn:sha1:7c1a607c40218a9a6cee6e2107cd7d6314a1fe98
Previously, when blob_size == tx_size_limit, the "m_too_big" property was set
and the transaction was rejected. This should not have been the case.
Merge pull request #32102018-02-16T13:22:10ZRiccardo Spagniric@spagni.net2018-02-16T13:22:10Zurn:sha1:bfddb2283b711b951c1f971e77a34d73f28a729b
39992134 txpool: Properly bail out when outputs_amount == inputs_amount (Leon Klingele)
tx_pool: add a max pool size, settable with --max-txpool-size2018-02-07T13:42:12Zmoneromooo-moneromoneromooo-monero@users.noreply.github.com2018-01-29T21:20:24Zurn:sha1:bc61ae69bfb20d2bdfa3d3716691e316bdbb6cb5txpool: Properly bail out when outputs_amount == inputs_amount2018-01-31T23:48:45ZLeon Klingelegit@leonklingele.de2018-01-30T15:16:20Zurn:sha1:399921347fd5b4ceaecd52484fb8f470cdb9ef03
Previously, when outputs_amount == inputs_amount, the "m_overspend" property
was set, whereas "m_fee_too_low" would have been the correct property to set.
This is unlikely to ever occur and just something I've noticed while reading
through the code.
Update 2018 copyright2018-01-26T15:03:20Zxmr-ericeric@moneroeric.com2018-01-07T05:05:16Zurn:sha1:18216f19dd479466cb7fd38f52d23bddfcfd4880Fix exceptions not finding txpool txes when relaying2017-12-20T13:02:53Zmoneromooo-moneromoneromooo-monero@users.noreply.github.com2017-12-14T17:09:30Zurn:sha1:ae8602303a0285abd28c044309a8456c748b34a3remove "using namespace std" from headers2017-11-14T16:56:10Zmoneromooo-moneromoneromooo-monero@users.noreply.github.com2017-10-10T14:47:08Zurn:sha1:383ff4f68943c5d998fba8caa20aee481583f214
It's nasty, and actually breaks on Solaris, where if.h fails to
build due to:
struct map *if_memmap;
Merge pull request #26152017-11-14T12:53:10ZRiccardo Spagniric@spagni.net2017-11-14T12:53:10Zurn: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 answers2017-11-08T12:07:07ZbinaryFatebinaryfate@users.noreply.github.com2017-11-08T12:06:41Zurn: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.