This corrects an off-by-one error in decoy selection that would never
select immediately-spendable outputs, and so immediately spending an
output would reveal the true output in question.
From Monero, PR 8794.
The infinite loop quoted here is *also* something that I encountered,
though only in regression testing (which uses a fake, sparse chain).
The timestamp in the file didn't match the comment or the block height
(this doesn't break anything; the timestamp is only used for future
block arrival estimates).
Lokinet and SS are actually sending `pubkey_ed25519` for the parameter,
but oxen-core is expecting `ed25519_pubkey`. Fixes oxen-core to match
what lokinet/ss are actually sending.
If installed on the system curl will try linking to it dynamically,
which we definitely don't want. If not installed, nghttp2 support would
get disabled, which is now always the case with this commit.
This adds a new table to the batching schema to copy the accrued
balances every so often. This means that we can jump back to a
previous point without popping blocks.
The archiving is triggered in sql every 100 blocks and added to the
archive table, then pruned from the archive table at a later time to
ensure the size is kept small. Rebuilding 100 blocks is pretty
reasonable and should be less than 10s.
For longer distance pop_blocks and blockchain detached every 10k blocks
is kept in the archiving table. This takes longer to rebuild but is
better than rebuilding from scratch.
The blockchain detached function is also added to our regular blockchain
detached hooks so that it gets called every time the blockchain
detaches. Which appears to have caused some issues previously when some
of the modules would detach but batching would be stuck in an advanced
state.
This lets lokinet or SS signal to oxend that something is known to be
wrong, and so oxend should not send a proof so that, hopefully, the
problem gets noticed and fixed.
Currently we're putting the last-uptime-received data in the service
node list info, even when we have more updated info that hasn't yet been
accepted by the network.
This causes problems for lokinet, in particular, because it ignores any
SNs in the list without ed25519 pubkeys, including itself, which can
result in lokinet thinking it is deregistered for a while after the SN
becomes registered.
This updates `get_service_nodes` to always include current info (rather
than latest proof info) for itself when querying a service node.
- 10.2.0 oxend version
- keep lokinet at 0.9.9
- require storage server 2.4.0
- schedule 10.2.0 mandatory date as 14 September 00:00 UTC (10am in
Australia Eastern Time; 8pm (on the 13th) in US Eastern time.
This modifies the current behaviour from only creating the hwdev.txt
file, when a new wallet is created if content is specified as an
argument to always creating the file. This file is used by the GUI
wallet to detect if the device is a hardware device and the CLI wallet
behaviour is kept the same to keep behavious consistent between CLI and
RPC wallets.
The checking if the service node contributers are small miscalculated
atomic oxen. This brings in the correct figure for HF20 and in the
interim brings measures into the wallet and blink to prevent small
contributors from being to unlock in HF19.
This was nasty.
Remove --block-rate-notify entirely; it's nearly useless on Oxen.
block and reorg notify remain, but now use a post-block hook rather than
shoving toxic Notify crap into cryptonote_core headers.
Add hooks that are called *after* a block is successfully added to the
blockchain.
This also fixes a race condition with OMQ notify.block subscriptions:
because the notification was firing during (instead of after) block
addition, the lokinet/storage server receiving the notify would race to
fetch the block info, but that request could happen *before* the block
addition is finished, ending up with lokinet/SS sometimes getting a
stale block.
This hook *isn't* called after a block is added, but rather it is part
of the block addition process and can abort the whole thing by raising
an exception (or returning false, prior to this PR).
This is unintuitive and causes bugs if using it as a "block has been
added" hook.
bool returns suck in general, but in most cases here they are also a
pain in the ass because *each* place that returns false is also issuing
a log statement. If only there were a way to return error information
to the common caller to have the common caller handle it... oh wait,
there is!
- Instead of inheriting from a pure virtual base class, we know just use
lambdas for hook callbacks.
- The signature of hooks also changes to take an info struct rather than
a list of parameters, so that you don't have to change everything to
ignore unwanted parameters if someone adds something to a hook.
