monzero-core.git/src/cryptonote_protocol/cryptonote_protocol_handler.h, branch v0.15.0.1Monzero core node, command-line wallet, consensus code, and release tooling.
https://code.monzero.org/monzero-core.git/atom?h=v0.15.0.12019-10-30T19:45:23Zdaemon: always use bootstrap daemon (if set) in '--no-sync' mode2019-10-30T19:45:23Zxiphonxiphon@protonmail.com2019-10-28T21:52:19Zurn:sha1:0e3b823a15793f4ccb815d0ad183f39e14930955Merge pull request #59332019-10-14T23:07:54Zluigi1111luigi1111w@gmail.com2019-10-14T23:07:54Zurn:sha1:dc48cdc998fde44dc744711e6e5920be73f74a36
3455efa ban peers sending bad pow outright (moneromooo-monero)
monerod can now sync from pruned blocks2019-09-27T00:10:37Zmoneromooo-moneromoneromooo-monero@users.noreply.github.com2019-09-16T12:18:34Zurn:sha1:8330e772f1ed680a54833d25c4d17d09a99ab8d6
If the peer (whether pruned or not itself) supports sending pruned blocks
to syncing nodes, the pruned version will be sent along with the hash
of the pruned data and the block weight. The original tx hashes can be
reconstructed from the pruned txes and theur prunable data hash. Those
hashes and the block weights are hashes and checked against the set of
precompiled hashes, ensuring the data we received is the original data.
It is currently not possible to use this system when not using the set
of precompiled hashes, since block weights can not otherwise be checked
for validity.
This is off by default for now, and is enabled by --sync-pruned-blocks
ban peers sending bad pow outright2019-09-25T16:00:43Zmoneromooo-moneromoneromooo-monero@users.noreply.github.com2019-09-24T13:08:25Zurn:sha1:3455efafa812d646f2eea42db14b761f34975147
PoW is expensive to verify, so be strict
cryptonote_protocol: expand basic DoS protection2019-06-14T08:47:08Zmoneromooo-moneromoneromooo-monero@users.noreply.github.com2019-03-08T19:17:20Zurn:sha1:1cc61018e52893382ae110430b38d1e0bf6e5870
Count transactions as well
cryptonote_protocol_handler: prevent potential DoS2019-06-14T08:47:05Zanonimalanonimal@getmonero.org2019-03-09T09:11:44Zurn:sha1:8f66b7053a8e4521fdd68c1d74718e73345fb158
Essentially, one can send such a large amount of IDs that core exhausts
all free memory. This issue can theoretically be exploited using very
large CN blockchains, such as Monero.
This is a partial fix. Thanks and credit given to CryptoNote author
'cryptozoidberg' for collaboration and the fix. Also thanks to
'moneromooo'. Referencing HackerOne report #506595.
Merge pull request #51992019-03-19T08:58:38ZRiccardo Spagniric@spagni.net2019-03-19T08:58:38Zurn:sha1:acc7211b5b2e1da17b5d83ae98bfc461365f6601
eef164f7 cryptonote_protocol_handler: search for syncing peers in "cruise mode" (moneromooo-monero)
Merge pull request #51952019-03-19T08:57:28ZRiccardo Spagniric@spagni.net2019-03-19T08:57:28Zurn:sha1:bf0f85221b748d2825fb6b169c8914ff17f40db7
a54e81e5 daemon: add '--no-sync' arg to optionally disable blockchain sync (xiphon)
Update 2019 copyright2019-03-05T21:05:34ZbinaryFatebinaryfate@users.noreply.github.com2019-03-05T21:05:34Zurn:sha1:1f2930ce0bec07e28958c059444151ad4968e1e6cryptonote_protocol_handler: search for syncing peers in "cruise mode"2019-02-26T12:45:28Zmoneromooo-moneromoneromooo-monero@users.noreply.github.com2019-02-26T12:40:40Zurn:sha1:eef164f7cc805ecf1881812cebb972ad0ce58edb
When all our outgoing peer slots are filled, we cycle one peer at
a time looking for syncing peers until we have at least two such
peers. This brings two advantages:
- Peers without incoming connections will find more syncing peers
that before, thereby strengthening network decentralization
- Peers will have more resistance to isolation attacks, as they
are more likely to find a "good" peer than they were before