The Wallet object used to have a guarenteed lifetime longer than the App
singleton, but then we started allowing people to delete their wallet
(argh!).
Also "external" modules, especially living outside of the main tree,
would be much more stable if they can avoid using raw pointers for core
concepts like the Wallet.
This is purely a future-proofing measure, don't accept transactions that
are likely to be handled differently than todays transactions.
Since the May 2023 upgrade versions other than 1 or two are not allowed
on-chain, but before that some version 4 transactions were mined (and some
negative numbered ones longer ago).
Talks about a version 10 transaction has started, so make sure this software,
if it is still running at someone's machine, will already reject higher
version transactions because we can't know if they are compatible or not.
In our wallet we very rarely end up in a situation where we have to ask
the same transactions twice from a peer due to us having generated a
bunch of new keys from a HD wallet in the middle of a series we asked
that peer. Making the filter we sent at the start of the series be
outdated halfway through.
This is now handled properly.
This adds a unit test which tests that we now reach the right balance
and can add the same block multiple times without it failing.
Fixes: #12
For the 'fullyEncrypted' option we now simply fully
encrypt the entire blob of both the secrets file as well
as the wallet.dat (which transactions we own).
As transactions are found on the blockchain we remember the signature
type used in order to avoid one private key to be used for both types of
signatures, which can cause compromised keys.
When a transaction is received by the p2pnet layer via a simple INV/
GetData we now process this and properly lock the outputs it spent to
avoid creating double spending transactions.
One task is left: properly recognize when a mined transaction
invalidates another transaction (like an unconfirmed one) and update the
datastructures.
The code to re-org all transactions in a block so transactions that
depend on others are processed after those they depend on had a silly
bug (missing line), fixed that but also made it unit-testable to
demonstrate the bug.
tomFlowee
TomZ