When the request includes block_ids, the daemon uses
find_blockchain_supplement to identify the highest block hash
passed in block_ids that the daemon also knows about, and then
serves subsequent blocks contiguous to that block.
When block_ids_skip_exclusive is false (default current
behavior), the daemon includes the highest block requested in the
response, in addition to contiguous blocks after it.
When block_ids_skip_exclusive is true (new param), the daemon
serves blocks starting from the block 1 higher than the highest
known block included in block_ids. Thus, the daemon skips the
common block known to the client and daemon. Clients can make sure
the daemon is serving expected contiguous blocks to its highest
known block by checking the first block's prev_id included in the
response, and making sure it is equivalent to the block the client
already knows about that was included in block_ids. This avoids
the daemon serving 1 extra block it does not need to serve to the
client, since the client should already know about that block.
bl
Related to https://github.com/monero-project/research-lab/issues/78
Added a relay rule that enforces the `unlock_time` field is equal to 0 for non-coinbase transactions.
UIs changed:
* Removed `locked_transfer` and `locked_sweep_all` commands from `monero-wallet-cli`
APIs changed:
* Removed `unlock_time` parameters from `wallet2` transfer methods
* Wallet RPC transfer endpoints send error codes when requested unlock time is not 0
* Removed `unlock_time` parameters from `construct_tx*` cryptonote core functions
- New flag in NOTIFY_NEW_TRANSACTION to indicate stem mode
- Stem loops detected in tx_pool.cpp
- Embargo timeout for a blackhole attack during stem phase
- Finding handling function in ZMQ JSON-RPC now uses binary search
- Temporary `std::vector`s in JSON output now use `epee::span` to
prevent allocations.
- Binary -> hex in JSON output no longer allocates temporary buffer
- C++ structs -> JSON skips intermediate DOM creation, and instead
write directly to an output stream.
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
- Support for ".onion" in --add-exclusive-node and --add-peer
- Add --anonymizing-proxy for outbound Tor connections
- Add --anonymous-inbounds for inbound Tor connections
- Support for sharing ".onion" addresses over Tor connections
- Support for broadcasting transactions received over RPC exclusively
over Tor (else broadcast over public IP when Tor not enabled).
j-berman