07:45:25 <esai[m]> Hello everyone. I hope you are doing very well
07:45:26 <esai[m]> I am a full stack web and blockchain developer.
07:45:26 <esai[m]> I am finding a project or work now.
07:45:26 <esai[m]> Please let me know if you have an idea or a project. thank you.
07:51:13 <grumblemobile> Hi. I usually suggest using the software, finding something that you're interested in improving or fixing, and doing this.
07:51:52 <grumblemobile> It gets you started with a (usually) small enough task that gets you visible improvement.
07:52:04 <grumblemobile> And you get to learn what's where along the way.
07:52:29 <grumblemobile> By "blockchain developer", do you mean... computer programmer ?
07:52:43 <grumblemobile> If so, monero's C/C++, mostly.
07:53:18 <esai[m]> right. I am a programmer
07:53:28 <grumblemobile> There are other related projects like Havano (java/javascript, a p2p exchange), p2pool (also C/C++ IIRC), mymonero related projcets (JS).
07:53:57 <grumblemobile> Various other related projects on github.com/monero-ecosystem if it's still there.
07:54:21 <esai[m]> grumblemobile: thank you.
07:54:25 <grumblemobile> If you want to help with monero itseld, you can also look at the github issues list and pick something you like.
07:55:28 <grumblemobile> 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.
07:56:15 <esai[m]> I can do. test, bug fixing, rewriting...
07:57:20 <esai[m]> grumblemobile: so, could you explain the project more detail?
07:57:48 <grumblemobile> I'm not sure what you're asking here. Can you rephrase ?
07:58:03 <grumblemobile> Are you asking "what is monero ?" ?
07:58:30 <esai[m]> sure, i don't know menero
07:58:35 <grumblemobile> Oh.
07:58:48 <grumblemobile> You said "blockchain developer" above ?
07:59:11 <grumblemobile> Anyway, monero is a cryptocurrency that fixes bitcoin's "naked to observers" problem.
07:59:23 <grumblemobile> It also fixes a few other things, but that's the one I'm interested in :D
07:59:28 <esai[m]> right. but my main fields that I work with are Ethereum, Solana, Bitcoin...
07:59:52 <grumblemobile> It's very similar to Bitcoin. PoW, output based. Just with the privacy breach fixed.
08:00:29 <esai[m]> If so, I can do it
08:00:39 <esai[m]> I am familiar with bitcoin.
08:00:45 <grumblemobile> Other improvements are variable block size, variable fees, egalitarian mining.
08:00:53 <grumblemobile> OTOH, it's heavier to verify that Bitcoin.
08:01:34 <rbrunner> Did you contribute to the Bitcoin codebase? Or the Ethereum code? Writing smart contracts?
08:01:40 <esai[m]> I see. 
08:01:49 <esai[m]> I checked the git you provided me. 
08:04:48 <rbrunner> The Haveno project that builds on Monero is in actual need of more developers, the project lead just mentioned that lately on Reddit: https://haveno.exchange/
08:05:46 <esai[m]> rbrunner: I have 2 years of experience with smart contract development and 1 year for the bitcoin
08:06:24 <rbrunner> Sounds good.
08:06:48 <esai[m]> I am looking for a project that I can do now.
08:06:55 <rbrunner> No smart contracts with Monero, but we have complicated multisig to make that up :)
08:07:25 <esai[m]> ok
08:08:15 <rbrunner> 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.
08:08:41 <rbrunner> Things usually run on donations, and people more freely donate to known people, with a track record, if you know what I mean.
08:09:15 <esai[m]> I understand.
08:09:28 <esai[m]> if so, when can I get paid?
08:10:16 <rbrunner> Well, one "vehicle" for paid dev work is this: https://ccs.getmonero.org/
08:10:39 <rbrunner> And a second one this: https://magicgrants.org/funds/monero/
08:12:00 <rbrunner> 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.
08:12:43 <rbrunner> It helps to be dedicated and passionate about privacy ...
08:13:40 <esai[m]> I see. so you mean if I show my ability, and then I can get paid right?
08:14:08 <rbrunner> Basically, yes.
08:15:08 <esai[m]> Generally, how much does it pay for the excellent dev?
08:16:06 <rbrunner> 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.
08:17:03 <rbrunner> 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
08:17:52 <esai[m]> got it.
08:18:27 <rbrunner> Still might be exactly your thing in the future, don't want necessarily discourage you :)
08:19:30 <esai[m]> ok, btw, what is your name? how can I call you?
08:20:44 <rbrunner> With "call" you mean make a phone call? I wouldn't be available for that ... but anyway, I am this guy: https://www.dreamshare.ch/
08:21:06 <esai[m]> what is your name?
08:29:50 <esai[m]> <rbrunner> "With "call" you mean make a..." <- ??
10:02:17 <netrik182> thanks selsta 
14:57:37 <UkoeHB> Has any progress been made with deciding the serialization replacement implementation? rbrunner and I have been discussing seraphis serialization https://github.com/seraphis-migration/wallet3/issues/10#issuecomment-1250324466
15:01:13 <grumblemobile> Is it buggy, or have bad behaviour (after the patches from anon) ?
15:02:55 <UkoeHB> we have: https://github.com/monero-project/monero/pull/7999 https://github.com/vtnerd/monero/tree/replace_p2p_serialization https://github.com/monero-project/monero/pull/8557
15:04:15 <UkoeHB> I think the goal is speedups to mitigate DDOS
15:12:30 <grumblemobile> Ah, I thought anon's had already been merged for some reason.
15:13:07 <grumblemobile> (perfect-daemon's)
15:34:14 <selsta> the connection patch was merged, the serialization rewrite was not
15:40:08 <rbrunner> Looking at those 3 serialization solutions, and the effort needed to get one into production, I inevitably ask myself 2 things:
15:40:40 <rbrunner> 1: Is the current epee system really so "broken" as to merit this?
15:41:02 <rbrunner> 2: Should we really put this on top of the move to Seraphis?
15:42:42 <selsta> 17:40 <rbrunner> 1: Is the current epee system really so "broken" as to merit this? <-- yes
15:43:44 <selsta> I don't see the connection to Seraphis, we have multiple patches, just needs a review and merge.
15:45:15 <rbrunner> 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.
15:46:32 <rbrunner> 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?
15:47:17 <rbrunner> Or more problems with memory consumption in general will crop up
15:47:21 <selsta> it did not get fixed, some band aid sanity checks were added
15:48:14 <rbrunner> Ok, that does not sound too good ...
15:49:24 <selsta> I have been running 7999 for close to a year now, only found one bug in regards to bootstrap mode
15:49:31 <rbrunner> 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 :)
15:49:42 <selsta> the other two patches still need more work, tests don't pass yet
15:50:35 <rbrunner> 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?
15:51:04 <selsta> this is for p2p serialization
15:51:10 <selsta> not blockchain or wallet caches
15:51:34 <rbrunner> Ah, surprise.
15:52:11 <rbrunner> The new Seraphis wallet would probably be more on the "blockchain and wallet caches" side of those issues.
15:52:30 <selsta> that's why I don't think Seraphis is related to this
15:53:12 <rbrunner> So does anybody currently propose some replacement for the system that is used for the blockchain, wallet cache, MMS file etc?
15:54:32 <rbrunner> Maybe I shouldn't be so lazy and actually read into those proposals ...
15:57:16 <jeffro256[m]> The way vtnerd and my proposals are structured should allow for integration of Boost serialization in the future 
15:57:27 <jeffro256[m]> 7999 not so much
15:57:39 <grumblemobile> Is there a need for boost serialization ?
15:59:45 <jeffro256[m]> Not as much, since there's a much smaller range of valid packets that can be deserialized by the boost code 
16:00:18 <jeffro256[m]> We (meaning not attackers) mainly control the data serialized in Boost format: blockchain files, wallet caches etc
16:01:58 <grumblemobile> There should not be anything using boost format in the blockchain AFAIK. Most new wallet stuff is also not boost.
16:02:13 <jeffro256[m]> 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 
16:03:27 <jeffro256[m]> > There should not be anything using boost format in the blockchain AFAIK. Most new wallet stuff is also not boost.
16:03:27 <jeffro256[m]> And if that were the case, then Boost serialization would be needed even less so
16:03:39 <jeffro256[m]> I mean, an overhaul of that code
16:03:42 <grumblemobile> I do not understand that. Are you suggesting blocks can be deserialized by boost, though they usually aren't ?
16:05:08 <jeffro256[m]> 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
16:05:18 <jeffro256[m]> I could be wrong on that one 
16:05:45 <grumblemobile> Block data is not serialized with boost before being stored in the db.
16:06:28 <grumblemobile> 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.
16:07:26 <grumblemobile> 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.
16:08:12 <grumblemobile> 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.
16:10:17 <jeffro256[m]> 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)
16:10:36 <grumblemobile> OK.
16:10:41 <jeffro256[m]> AFAIK Boost portable archives don't use a DOM so that's good 
16:11:17 <grumblemobile> The epee serialization also doesn't. Only the KV serialization does.
16:11:20 <jeffro256[m]> > 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.
16:11:20 <jeffro256[m]> Do you know of any attempts to fix this so far?
16:12:01 <grumblemobile> 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.
16:12:22 <jeffro256[m]> > The epee serialization also doesn't. Only the KV serialization does.
16:12:22 <jeffro256[m]> 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
16:12:32 <grumblemobile> And, as you said, it's mostly out of an attacker's reach, so not super urgent.
16:13:20 <grumblemobile> Sorry, by epee serialization, I meant the binary_archive stuff that's used for blocks, txes, etc.
16:13:35 <grumblemobile> That doesn't use KV stuff.
16:13:38 <jeffro256[m]> Yeah I think that's why it hasn't been prioritzed like p2p serialization: our own code mostly controls the contents 
16:13:43 <grumblemobile> (and is solid AFAIK)
16:15:07 <rbrunner> So maybe with this info I can ask a more precise question: Does anybody currenty aspire to offer a replacement for epee binary_archive?
16:15:24 <rbrunner> Or some compatible drop-in replacement?
16:15:32 <jeffro256[m]> binary_archive is Boost yeah?
16:15:52 <rbrunner> No, epee, if I am not gravely mistaken.
16:15:54 <grumblemobile> No. You're thinking of portable_archive maybe.
16:16:33 <jeffro256[m]> > So maybe with this info I can ask a more precise question: Does anybody currenty aspire to offer a replacement for epee binary_archive?
16:16:33 <jeffro256[m]> Not that I know o
16:16:37 <jeffro256[m]> know of
16:17:14 <jeffro256[m]> I would double check with vtnerd, but I don't think he's focused on that rn
16:17:26 <rbrunner> 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
16:19:49 <jeffro256[m]> No choices, no brain have to thinky
16:20:33 <rbrunner> Boost serialization has *one* nice property: You can cleanly separate class declarations and serialization code.
16:20:56 <rbrunner> Which, in the case of Seraphis, would allow to keep the Seraphis library "pure"
16:21:13 <jeffro256[m]> Yes ^ that's true. Both mine and vtnerd's PRs allow that for
16:21:35 <rbrunner> And handle *all* serialize/deserialize stuff in the new Seraphis core wallet, the `wallet2` replacement
16:21:41 <jeffro256[m]> For those who didn't know the fancy word for it its "ADL functions"
16:22:08 <jeffro256[m]> > Which, in the case of Seraphis, would allow to keep the Seraphis library "pure"
16:22:08 <jeffro256[m]> Big W
16:22:45 <rbrunner> ADL standing for?
16:28:58 <jeffro256[m]> Argument Dependent Lookup. 
16:30:03 <jeffro256[m]> That's why you can use unqualified names for functions if one of the arguments is in the namespace as the target function
16:30:10 <moneromooo> IIRC it's just Koenig lookup with a new name. Or pretty much it.
16:35:06 <jeffro256[m]> Is that what it was originally called in c++?
16:35:58 <selsta> I only remember ADL causing compilation issues here https://github.com/monero-project/monero/pull/8016
16:36:04 <moneromooo> 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.
16:36:35 <moneromooo> er, scratch "if the type of a is in a namespace that's in scope" really.
16:37:36 <jeffro256[m]> Yeah just as long as you know the namespaces of the arguments and the operator/function is in a related namespace 
16:40:41 <jeffro256[m]> > I only remember ADL causing compilation issues here https://github.com/monero-project/monero/pull/8016
16:40:41 <jeffro256[m]> 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
17:33:00 <jeffro256[m]> rbrunner Just to double check over a different medium, you are aware of https://github.com/monero-project/monero/pull/8571?
17:34:57 <rbrunner> Yes, that's me!
17:35:32 <jeffro256[m]> Great! the commit signature checks out!
17:36:07 <rbrunner> Good. I had to learn quite a bit about all that key stuff before I could extend validity and install the key at GitHub