This PR is upstreaming changes in the Seraphis lib here: https://github.com/UkoeHB/monero/pull/39. The changes to the serialization header allow clean passing
of extra arguments to field serialization in the DSL. This is used mainly to pass implied sizes of containers during deserialization to make the format more
compact. For example, if my object has two containers A & B which must be the same size, I can serialize only the size of container A. Then, during
deserialization, when I deserialize A, I can then use A's size to deserialize B.
Depends on #9286.
There is currently no compiler protection when someone tries to
do (for example) `BLOB_SERIALIZER(std::vector<int>)`. You just
get runtime allocation errors. This has already eaten up dev time
before, so this PR adds a static assertion that the type must be
trivially copyable, as defined by the C++ standard. Types can
override this if applicable if they use `BLOB_SERIALIZER_FORCED`.
Example usage for Seraphis types (in global or `sp` namespace):
```
BEGIN_SERIALIZE_OBJECT_FN(sp::SpCoinbaseEnoteCore)
FIELD_F(onetime_address)
VARINT_FIELD_F(amount)
END_SERIALIZE()
BEGIN_SERIALIZE_OBJECT_FN(sp::SpEnoteCore)
FIELD_F(onetime_address)
FIELD_F(amount_commitment)
END_SERIALIZE()
```
Some downstream code (most notably PR https://github.com/UkoeHB/monero/pull/25) wants to use the src/serialization lib
for storing information persistently. When one builds classes/machines wishing to serialize containers, they must use
the `serializable_*` container classes. In this case, this makes the Seraphis library code unnecessarily tightly coupled
with the src/serialization code since one cannot swap out their type of storage format without major refactoring of class
field types. By serializing STL containers directly, we can abstract the serialization details away, making for much
cleaner design. Also small bonus side effect of this change is that STL containers with custom Comparators, Allocators,
and Hashers are serializable. `std::multimap` is added to the list of serializable containers.
Depends upon https://github.com/monero-project/monero/pull/9069.
Implements view tags as proposed by @UkoeHB in MRL issue
https://github.com/monero-project/research-lab/issues/73
At tx construction, the sender adds a 1-byte view tag to each
output. The view tag is derived from the sender-receiver
shared secret. When scanning for outputs, the receiver can
check the view tag for a match, in order to reduce scanning
time. When the view tag does not match, the wallet avoids the
more expensive EC operations when deriving the output public
key using the shared secret.
Adds the following:
- "get_miner_data" to RPC API
- "json-miner-data" to ZeroMQ subscriber contexts
Both provide the necessary data to create a custom block template. They are used by p2pool.
Data provided:
- major fork version
- current height
- previous block id
- RandomX seed hash
- network difficulty
- median block weight
- coins mined by the network so far
- mineable mempool transactions
On Mac, size_t is a distinct type from uint64_t, and some
types (in wallet cache as well as cold/hot wallet transfer
data) use pairs/containers with size_t as fields. Mac would
save those as full size, while other platforms would save
them as varints. Might apply to other platforms where the
types are distinct.
There's a nasty hack for backward compatibility, which can
go after a couple forks.
This reduces the attack surface for data that can come from
malicious sources (exported output and key images, multisig
transactions...) since the monero serialization is already
exposed to the outside, and the boost lib we were using had
a few known crashers.
For interoperability, a new load-deprecated-formats wallet
setting is added (off by default). This allows loading boost
format data if there is no alternative. It will likely go
at some point, along with the ability to load those.
Notably, the peer lists file still uses the boost serialization
code, as the data it stores is define in epee, while the new
serialization code is in monero, and migrating it was fairly
hairy. Since this file is local and not obtained from anyone
else, the marginal risk is minimal, but it could be migrated
later if needed.
Some tests and tools also do, this will stay as is for now.
