Hello everyone. I hope you are doing very well

I am a full stack web and blockchain developer.

I am finding a project or work now.

Please let me know if you have an idea or a project. thank you.

Hi. I usually suggest using the software, finding something that you're interested in improving or fixing, and doing this.

It gets you started with a (usually) small enough task that gets you visible improvement.

And you get to learn what's where along the way.

By "blockchain developer", do you mean... computer programmer ?

If so, monero's C/C++, mostly.

right. I am a programmer

There are other related projects like Havano (java/javascript, a p2p exchange), p2pool (also C/C++ IIRC), mymonero related projcets (JS).

Various other related projects on github.com/monero-ecosystem if it's still there.

grumblemobile: thank you.

If you want to help with monero itseld, you can also look at the github issues list and pick something you like.

Technical questions/help along the way are welcome here. Patches should be minimal within reason. No random reindent, no rewriting code for your taste. Fixing bugs is great. Adding tests is great.

I can do. test, bug fixing, rewriting...

grumblemobile: so, could you explain the project more detail?

I'm not sure what you're asking here. Can you rephrase ?

Are you asking "what is monero ?" ?

sure, i don't know menero

Oh.

You said "blockchain developer" above ?

Anyway, monero is a cryptocurrency that fixes bitcoin's "naked to observers" problem.

It also fixes a few other things, but that's the one I'm interested in :D

right. but my main fields that I work with are Ethereum, Solana, Bitcoin...

It's very similar to Bitcoin. PoW, output based. Just with the privacy breach fixed.

If so, I can do it

I am familiar with bitcoin.

Other improvements are variable block size, variable fees, egalitarian mining.

OTOH, it's heavier to verify that Bitcoin.

Did you contribute to the Bitcoin codebase? Or the Ethereum code? Writing smart contracts?

I see.

I checked the git you provided me.

The Haveno project that builds on Monero is in actual need of more developers, the project lead just mentioned that lately on Reddit: haveno.exchange

rbrunner: I have 2 years of experience with smart contract development and 1 year for the bitcoin

Sounds good.

I am looking for a project that I can do now.

No smart contracts with Monero, but we have complicated multisig to make that up :)

ok

Just a word of caution: If you usually work for pay, it might get a bit hard to get paid from the very start of your work for Monero and/or Haveno.

Things usually run on donations, and people more freely donate to known people, with a track record, if you know what I mean.

I understand.

if so, when can I get paid?

Well, one "vehicle" for paid dev work is this: ccs.getmonero.org

And a second one this: magicgrants.org/funds/monero

Monero as a project is not a company, but a pretty wild bunch of devs of all kinds, paid and volunteer. It can be a bit daunting for newcomers.

It helps to be dedicated and passionate about privacy ...

I see. so you mean if I show my ability, and then I can get paid right?

Basically, yes.

Generally, how much does it pay for the excellent dev?

I don't have an overwiew; you may check earlier projects on the CCS and Magic that I gave you. I think it varies considerably.

But as I said, as far as I see, it's next to impossible to just become an "employee" of Monero, with guaranteed and stable pay, like other crypto projects that are companies could probably offer

got it.

Still might be exactly your thing in the future, don't want necessarily discourage you :)

ok, btw, what is your name? how can I call you?

With "call" you mean make a phone call? I wouldn't be available for that ... but anyway, I am this guy: dreamshare.ch

what is your name?

<rbrunner> "With "call" you mean make a..." <- ??

thanks selsta

Has any progress been made with deciding the serialization replacement implementation? rbrunner and I have been discussing seraphis serialization seraphis-migration/wallet3 #10#issuecomment-1250324466

Is it buggy, or have bad behaviour (after the patches from anon) ?

we have: monero-project/monero #7999 github.com/vtnerd/monero/tree/replace_p2p_serialization monero-project/monero #8557

I think the goal is speedups to mitigate DDOS

Ah, I thought anon's had already been merged for some reason.

(perfect-daemon's)

the connection patch was merged, the serialization rewrite was not

Looking at those 3 serialization solutions, and the effort needed to get one into production, I inevitably ask myself 2 things:

1: Is the current epee system really so "broken" as to merit this?

2: Should we really put this on top of the move to Seraphis?

17:40 <rbrunner> 1: Is the current epee system really so "broken" as to merit this? <-- yes

I don't see the connection to Seraphis, we have multiple patches, just needs a review and merge.

Well, with Seraphis we have a large number of new things that need to serialize, and maybe it's a question what to use, and when the system to use will be available.

About the "broken-ness" of the current system: We did have some patches for exploits, right? Do we have to fear that more exploits will come then?

Or more problems with memory consumption in general will crop up

it did not get fixed, some band aid sanity checks were added

Ok, that does not sound too good ...

I have been running 7999 for close to a year now, only found one bug in regards to bootstrap mode

If the time to decide between the 3 proposals will come, I think I will make ready quite some popcorn for munching while watching the show :)

the other two patches still need more work, tests don't pass yet

I wonder a bit how you can run 7999, maybe my limited knowledge about that is wrong: Is that a "drop-in" replacement? Can it read current blockchain, current wallet caches, the lot?

this is for p2p serialization

not blockchain or wallet caches

Ah, surprise.

The new Seraphis wallet would probably be more on the "blockchain and wallet caches" side of those issues.

that's why I don't think Seraphis is related to this

So does anybody currently propose some replacement for the system that is used for the blockchain, wallet cache, MMS file etc?

Maybe I shouldn't be so lazy and actually read into those proposals ...

The way vtnerd and my proposals are structured should allow for integration of Boost serialization in the future

7999 not so much

Is there a need for boost serialization ?

Not as much, since there's a much smaller range of valid packets that can be deserialized by the boost code

We (meaning not attackers) mainly control the data serialized in Boost format: blockchain files, wallet caches etc

There should not be anything using boost format in the blockchain AFAIK. Most new wallet stuff is also not boost.

As IIUC, Boost deserialization for blocks doesn't happen at the node level unless the block fits the criteria for a mined block. In which case 99.99% of the time the block is not going to be a DoS block since that would be quite expensive. Also, I don't even know how that would be done effectively since the contents of the block need to line up with cryptonote primitives

> There should not be anything using boost format in the blockchain AFAIK. Most new wallet stuff is also not boost.

And if that were the case, then Boost serialization would be needed even less so

I mean, an overhaul of that code

I do not understand that. Are you suggesting blocks can be deserialized by boost, though they usually aren't ?

HYC or moneromoo would know off the top of their head, but I believe block data is serialized into Boost format before being stored into the LMDB

I could be wrong on that one

Block data is not serialized with boost before being stored in the db.

AFAIK boost format is used for old wallet stuff, still some current wallet stuff (but not much), and p2pstate.bin. Possibly some other stuff, but probably not much.

In particular, there is a longstanding buffer overflow bug in boost serialization, which is pretty undebuggable (at least by me), and that's possibly exploitable. That noone fixed it in years tells me we want to get away from it.

There's also another bug, an assert somewhere, probably a different bug, that'd be a DoS vector if it were to be used for blocks.

I have tried to stay away from Boost serialization so far and focus on p2p lol. But I was trying to say that theoretically, Boost serialization can be described by me and vtnerd's data model in our respective PR's and there wouldn't need to be 2 different APIs for serializing (and no DOMs necessary)

OK.

AFAIK Boost portable archives don't use a DOM so that's good

The epee serialization also doesn't. Only the KV serialization does.

> There's also another bug, an assert somewhere, probably a different bug, that'd be a DoS vector if it were to be used for blocks.

Do you know of any attempts to fix this so far?

No. I think vtnerd got a repro case at some point, but I'm not sure he had the time to ever look at it.

> The epee serialization also doesn't. Only the KV serialization does.

Right now, portable_storage is used for epee binary and JSON serialization/deserializtion. KV_SERIALIZE provides that boilerplate code for both. So they both use DOMs currently

And, as you said, it's mostly out of an attacker's reach, so not super urgent.

Sorry, by epee serialization, I meant the binary_archive stuff that's used for blocks, txes, etc.

That doesn't use KV stuff.

Yeah I think that's why it hasn't been prioritzed like p2p serialization: our own code mostly controls the contents

(and is solid AFAIK)

So maybe with this info I can ask a more precise question: Does anybody currenty aspire to offer a replacement for epee binary_archive?

Or some compatible drop-in replacement?

binary_archive is Boost yeah?

No, epee, if I am not gravely mistaken.

No. You're thinking of portable_archive maybe.

> So maybe with this info I can ask a more precise question: Does anybody currenty aspire to offer a replacement for epee binary_archive?

Not that I know o

know of

I would double check with vtnerd, but I don't think he's focused on that rn

Ok :) In a way, that's positive for me, because I don't have to make a difficult decision whether to use that or wait for something better

No choices, no brain have to thinky

Boost serialization has *one* nice property: You can cleanly separate class declarations and serialization code.

Which, in the case of Seraphis, would allow to keep the Seraphis library "pure"

Yes ^ that's true. Both mine and vtnerd's PRs allow that for

And handle *all* serialize/deserialize stuff in the new Seraphis core wallet, the `wallet2` replacement

For those who didn't know the fancy word for it its "ADL functions"

> Which, in the case of Seraphis, would allow to keep the Seraphis library "pure"

Big W

ADL standing for?

Argument Dependent Lookup.

That's why you can use unqualified names for functions if one of the arguments is in the namespace as the target function

IIRC it's just Koenig lookup with a new name. Or pretty much it.

Is that what it was originally called in c++?

I only remember ADL causing compilation issues here monero-project/monero #8016

If it's indeed the same, is the thing that makes this "a + b" work if the type of a is in a namespace that's in scope and operator+ isn't.

er, scratch "if the type of a is in a namespace that's in scope" really.

Yeah just as long as you know the namespaces of the arguments and the operator/function is in a related namespace

> I only remember ADL causing compilation issues here monero-project/monero #8016

Instead of changing it to quoted_, another solution would have been to use ::quoted when there was a conflict right? Sometimes ADL seems so hacky

rbrunner Just to double check over a different medium, you are aware of monero-project/monero #8571?

Yes, that's me!

Great! the commit signature checks out!

Good. I had to learn quite a bit about all that key stuff before I could extend validity and install the key at GitHub