jberman On your CSS proposal, you said that you were going to look into #7999 about serialization/storage? I'm working on a PR which addresses the same issue as #7999. I just wanted to let you know that that is in the works and wanted to know if you have written any code regarding said problem

selsta: done

jeffro256: I haven't started digging into the PR at all yet. vtnerd has a clean looking alternative here that I also anticipated reviewing: github.com/monero-project/monero/co…rd:monero:replace_p2p_serialization

jeffro256[m]: what are you working on exactly? since we already have 2 rewrites a third one might not make sense

is the burnt amount provided or handled anywhere else besides the overall balance and on_money_received() notification? for example, can a monero-wallet-rpc client check for burnt funds in a tx, without receiving the native output notification?

Only the former AFAIK.

Though technically you could get incoming_transfers and sum/compare yourself, so you *can* get at the info in theory.

> jeffro256: I haven't started digging into the PR at all yet. vtnerd has a clean looking alternative here that I also anticipated reviewing: github.com/monero-project/monero/co…rd:monero:replace_p2p_serialization

Interesting, I didn't see that one, I'll definitely take a look. @vtnerd is it ready to be merged now (pending review)?

> jeffro256: what are you working on exactly? since we already have 2 rewrites a third one might not make sense

It solves the same problem as #7999 (faster (de)serialization with no DOM), while being a lot cleaner and being more extensible (similar to vtnerd's monero-lws wire module) since it takes a lot of inspiration from Rust's serde framework

I would need to look more into @vtnerd's PR but unless it does more than what I think it does, my PR does the same thing in about half the lines. I'm definitely going to benchmark it though

Also my PR wouldn't need to touch the `BEGIN_SERIALIZE_MAP()`, `KV_SERIALIZE()`, `END_KV_SERIALIZE` pattern

jeffro256[m]: 7999 has some benchmarks

afungible[m]: LMDB enforces uniqueness on keys. You cannot find two identical key images in LMDB because it would return an error when trying to store the 2nd one, and monerod would indicate a double-spend attempt

hyc: Thanks for the good explanation.

stagenet forks in 3 blocks

my patch has comments + boilerplate interface which blows up the line count a little

the interface allows you to chosoe between smaller binary size or de-virtualization with a slightly fatter binary

otherwise the number of lines actually doing stuff should be relatively small

the PR is basically ready for review, but perhaps could use more testing

unfortunately there's no framework (in either PR) that tests compatability with every command

<vtnerd> "the interface allows you to..." <- Ooh choice between virtualization and devirtializion is cool

Is that what the MODE selector is ?

Also it seems like you’re trying to combine wire serialization interface with the boost serializatik interface

Heyo!

How can I help?

I don't know math or very good at programming though

go practice both and get good first ;)

oh, k

probably join #monero-community and help out there, anybody can jump right in

eternal[m]: you can also look through the issue tracker, maybe you'll find something that looks doable

selsta: on github?

yes

nope, realized all tests are writen in python but the blockchain is c++

i only know python

lol

Tests are always good to have.

Or you could try contributing to the python monero lib, probably somewhere on github.com/monero-ecosystem.

moneromooo: oooh!

jeffro256[m]: yeah its a combo of a couple different serialization libraries really

selecting between virtualization and de-virtualized is a bit manual but there might be a way to improve it

theres a macro for header and cpp that can be changed - two for generic, and then two for each format type

the fields only have to be listed once because the macro forwards to a templated function ... if the concrete type is used the compiler definitely de-virtualizes all calls due to `final` keyword on class

the style is probably closest to epee, since its replacing that functionality iwthin boost

the downside of that de-virtualization is that each format type is a template expansion, which is a unique expansion in the object-file-binary

for p2p stuff you just mark everything as `epee` format since there is no other format being used

> the fields only have to be listed once because the macro forwards to a templated function ... if the concrete type is used the compiler definitely de-virtualizes all calls due to `final` keyword on class

I definitely copied this aspect from the wire module within my version. I always put `override final` on everything applicable and trust the compiler with the rest. SO it looks like OOP architecture wise but any dumb compiler can devirtualize

.merge+ 8465 8466

Added

.merges

luigi1112: ^^^