0e7ad2e2 Wallet API: generalize 'bool testnet' to 'NetworkType nettype' (stoffu)
af773211 Stagenet (stoffu)
cc9a0bee command_line: allow args to depend on more than one args (stoffu)
55f8d917 command_line::get_arg: remove 'required' for dependent args as they're always optional (stoffu)
450306a0 command line: allow has_arg to handle arg_descriptor<bool,false,true> #3318 (stoffu)
9f9e095a Use `genesis_tx` parameter in `generate_genesis_block`. #3261 (Jean Pierre Dudey)
This is safer, as we don't risk break expectations (eg, requesting
block hashes and then receiving a late set of blocks). Dropping a
connection means another will be attempted in a fresh state.
Also bump the kick timeout to 5 minutes, to ensure we only kick
really idle peers.
The last known hash was calculated incorrectly, causing
further chain hash downloads to restart from the current
chain. When the block queue has close to 10k blocks waiting,
this causes frequent downloads of 10k more hashes, but
with only the last few hashes actually being useful.
It is unused, as it was apparently a future optimization,
and it leaks some information (though since pools publish
thei blocks they find, that amount seems small).
c867357a cryptonote_protocol: error handling on cleanup_handle_incoming_blocks (moneromooo-monero)
ce901fcb Fix blockchain_import wedge on exception in cleanup_handle_incoming_blocks (moneromooo-monero)
84fa015e core: guard against exceptions in handle_incoming_{block,tx} (moneromooo-monero)
Fix sync wedge corner case:
It could happen if a connection went into standby mode, while
it was the one which had requested the next span, and that span
was still waiting for the data, and that peer is not on the
main chain. Other peers can then start asking for that data
again and again, but never get it as only that forked peer does.
And various other fixes
If monerod is started with default sync mode, set it to SAFE after
synchronization completes. Set it back to FAST if synchronization
restarts (e.g. because another peer has a longer blockchain).
If monerod is started with an explicit sync mode, none of this
automation takes effect.
This was broken by the reorg fix, since we now have to add blocks
regardless of their starting height. We now check whether we know
the parent for the first block in the next span, or whether it was
requested. If neither, it's an orphan. If it is not known, but was
requested, we wait to get that block.
Add get_fork_version and add_ideal_fork_version to core so
cryptonote_protocol does not have to need the Blockchain
class directly, as it's not in its dependencies, and add
those to the fake core classes in tests too.
When a node is dropped, we stop considering its claimed blockchain
height as a factor in the target height calculation. This prevents
a runaway chain from being still thought to be the target even if
the nodes carrying it are dropped.
We won't even talk to a peer which claims a wrong version
for its top block. This will avoid syncing to known bad
peers in the first place.
Also add IP fails when failing to verify a block.
Connections can be dropped by the net_node layer,
unbeknownst to cryptonote_protocol, which would then
not flush any spans scheduled to that connection,
which would cause it to be only downloaded again
once it becomes the next span (possibly after a small
delay if it had been requested less than 5 seconds
ago).
A block queue is now placed between block download and
block processing. Blocks are now requested only from one
peer (unless starved).
Includes a new sync_info coommand.
All code which was using ip and port now uses a new IPv4 object,
subclass of a new network_address class. This will allow easy
addition of I2P addresses later (and also IPv6, etc).
Both old style and new style peer lists are now sent in the P2P
protocol, which is inefficient but allows peers using both
codebases to talk to each other. This will be removed in the
future. No other subclasses than IPv4 exist yet.
- only pause mining once we've got the lock (in practice, it'll
already be paused by another thread if we can't get the lock
at once though)
- do not call prepare_handle_incoming_blocks when we dismissed
all the blocks, it only causes cleanup_handle_incoming_blocks
to complain afterwards
8bdc86be protocol: speed up sync by minimizing duplicate work (moneromooo-monero)
61dfa310 epee: fix some log macros not printing context nicely (moneromooo-monero)
In particular, the prepare_handle_incoming_blocks call
is pretty lengthy, and entirely pointless in the common
case where several different connections will prepare
the exact same blocks.
- fix wrong block being used when a new block is received between
a node elaying a fluffy block and sending a new fluffy block
with txes a peer did not have
- misc a neverending ping pong requesting the same missing txids
when a new block is received in the meantime, causing the top
block to not be the one we need
- send the original fluffy block message block height when sending
a new fluffy block, not the current top height, which might
have been updated since
- avoid sending back the whole block blob when asking for txes,
send only the hash instead
- plus misc cleanup and additional debugging logs
