00:05:28 <hyc> would be nice to collapse blockchain_db and blockchain into a single layer, now that we'll nevr use in-memory blockchain ever again
00:05:40 <hyc> a ton of adapter layering can go away
00:50:16 <selsta> hyc: I think we talked about this but do you remember what the status of https://github.com/monero-project/monero/issues/7147 is?
00:50:30 <selsta> I don't think this issue appears anymore. Can we close it?
00:52:35 <hyc> I think we can close it, we don't have cdrkit as a dependency any more
00:52:46 <hyc> not sure why it was ever there, prob inherited from btc
00:54:18 * hyc closed it
04:38:22 <selsta> sech1: hyc: this fixes an often reported issue, could someone take a look at this patch? https://github.com/monero-project/monero/pull/7084
04:38:33 <selsta> it looks good to me but want to double check everything rx related
08:02:23 <rbrunner> Do we know who makes a lot of transactions on testnet for the last 3 weeks or so already? Right now there are even more txs on testnet than on mainnet.
08:02:31 <rbrunner> Not that this is a problem, I am just curious.
08:02:39 <rbrunner> Maybe to prepare for some statistical test?
08:04:08 <moneromooo> IIRC someone mentioned they want to see if they can trace txes, and I guess didn't realize it was trivial if you have 100% of the traffic.
08:04:19 <moneromooo> Was in -lab I believe.
08:04:39 <moneromooo> Or maube that's just a pretext to spam. Who knows.
08:06:14 <nikg83[m]> moneromooo: Or maybe testing to see what minimum % of spam can help them analyse 
08:08:30 <rbrunner> They seem to play around a lot with different fees, and throwing in transactions with gigantic fees if I read that correctly ...
08:09:04 <rbrunner> May something useful come out of this :)
08:12:10 <moneromooo> That sounds useful then :)
08:23:00 <sech1> moneromooo what was the fix for https://github.com/monero-project/monero/issues/8120 ?
08:25:16 <moneromooo> The one in the comment. I'll make a patch now.
08:26:12 <sech1> that's not a fix
08:26:21 <sech1> you still have garbage data in that variable
08:26:42 <sech1> it only fixes the symptom and hides it from UndefinedBehaviorSanitizer
08:27:45 <moneromooo> Why ?
08:28:28 <sech1> https://stackoverflow.com/questions/4518951/engineered-bool-compares-equal-to-both-true-and-false-why
08:28:46 <moneromooo> Hmm, the first one's not a load...
08:29:38 <sech1> compiler implementations are allowed to treat values outside of [0;1] range as both true and false
08:29:53 <moneromooo> Can't read, they block tor now.
08:29:54 <sech1> i.e. uninitialized variables
08:30:08 <moneromooo> That's why you !! after read.
08:31:16 <sech1> screenshots of that page: https://imgur.com/a/MKjuH6C
08:31:50 <sech1> if you add !! to uninitialized/garbage data, it doesn't make it less uninitialized/garbage
08:31:54 <sech1> this is not a fix
08:32:34 <moneromooo> Is it uninitialized ?
08:32:47 <sech1> bool can only be 0 or 1 in binary data
08:33:02 <sech1> so definitely uninitialized, or memcpy'd from a buffer without checking
08:33:36 <moneromooo> Well, feel free to patch it and maybe throw if not 0/1 instead.
08:34:11 <sech1> I'm not familiar with that code, I don't even see where it's filled in
08:34:34 <moneromooo> Stuff read from the network. So attacker controlled.
08:35:46 <sech1> actually, that variable is only directly initialized to true/false in various places
08:35:53 <sech1> so it might be a buffer overrun somewhere
08:36:41 <sech1> wait, it's a message header read from network?
08:37:08 <moneromooo> I thought it was.
08:37:19 <moneromooo> But hten I'm not familiar wiht this code either so...
08:38:15 <sech1> std::memcpy(std::addressof(m_current_head), std::addressof(temp[0]), sizeof(bucket_head2));
08:38:16 <sech1> yep
08:38:23 <sech1> comes straight from network buffer
08:39:56 <sech1> I would change "bool m_have_to_return_data;" to "uint8_t m_have_to_return_data;" and make appropriate changes in all places where it's used
08:40:07 <sech1> since it's can be any data coming from network
08:41:02 <sech1> I'll make a patch :shrug:
08:51:38 <sech1> damn, it's worse than I thought :D
08:51:56 <sech1> we use "bool" in portable_storage to load/store data and sizeof(bool) is implementation-defined
08:52:20 <sech1> a recipe for a disaster
08:53:07 <sech1> not that I know any compiler where sizeof(bool) != 1, but it can explode in the future
08:53:20 <sech1> probably need to add static_assert for this
09:22:21 <sech1> selsta moneromooo https://github.com/monero-project/monero/pull/8186
09:27:45 <moneromooo> Thanks
09:30:18 -xmr-pr- SChernykh opened pull request #8186: Undefined behaviour fixes
09:30:18 -xmr-pr- > https://github.com/monero-project/monero/pull/8186
09:30:18 -xmr-pr- kvthweatt opened issue #8185: I forked Monero, it wont stop trying to sync?
09:30:18 -xmr-pr- > https://github.com/monero-project/monero/issues/8185
09:38:32 <kwxmr[m]> Hi, do you know which of the 9 options was  selected for Jamtis? Is it still in discussion? https://github.com/monero-project/research-lab/issues/92 Thanks for help!
10:25:30 <kwxmr[m]> And on this post the author says "New wallet tier allowing fast light wallet syncing with greater privacy than existing solutions" but "Wallets will not synchronize much faster". Will Jamtis and Seraphis improve wallet synching? Thank you very much https://monero.stackexchange.com/questions/13494/pros-and-cons-of-moneros-potential-seraphis-protocol-upgrade
13:05:28 <selsta> moneromooo: 7084 conflicts, could you rebase?
13:08:46 <selsta> sech1: thanks, should we also open 8186 against release?
13:11:48 <moneromooo> Oooh, that never got merged, totally explains why I still get spam, I had assumed someone had broken it again :D
13:12:38 <moneromooo> Oh wait, I'm thinking of the net code weak pointer spam actually...
13:18:31 <moneromooo> done
13:21:03 <selsta> ty
13:21:10 <selsta> .merge+ 7084
13:21:10 <xmr-pr> Added
13:58:58 <Rucknium[m]> <rbrunner> "Do we know who makes a lot of..." <- Highly likely it is xmr-ack doing some machine learning tests.
14:04:20 <sech1> selsta are we planning a point release before v0.18 hard fork?
14:04:30 <xmr-ack[m]> Rucknium is correct, my research includes collecting a large dataset of de-anonymized transactions on test-net to research  if ring signatures are susceptible to machine learning attacks. The dataset will eventually be open sourced for peer review.
15:13:38 <kwxmr[m]> <kwxmr[m]> "Hi, do you know which of the 9..." <- After analysis it seems Jamtis uses option Janus E. And view tags make scanning  faster for new txs. But I'm not sure 100%, it would be nice if someone can confirm, thanks
15:38:55 <UkoeHB> kwxmr[m]: jamtis is Janus B. View tags will be added in the upcoming hardfork, which will speed up view scanning for new outputs. Jamtis will add some optimizations to view tags for further speedups. Jamtis also has a lot of privacy improvements for third-party scanning (eg mymonero).
15:40:04 <endogenic> fwiw UkoeHB I dont expect users to flock to the higher privacy mode
15:40:19 <endogenic> much more than they flock to client side scanning
15:41:07 <UkoeHB> endogenic: I imagine anyone using third party scanning will continue to use it
15:41:49 <UkoeHB> Anyway, the purpose wasn’t to increase/decrease the number of people using third party scanning. Just improve privacy for those that do use it.
15:42:22 <endogenic> the extra option is nice
15:42:43 <endogenic> but it still has considerable clientside overhead aiui
15:42:44 <UkoeHB> The old option will be dead, so it’s not really ‘extra’.
15:43:45 <endogenic> well, we have tiers now, with the old privacy mode(characterisrics of view key disclosure) still preserved in everything but underlying implementation structure and names, aiui, so how will it be dead?
15:43:46 <UkoeHB> The clientside overhead is downloading key images and 1/256 outputs.
15:44:00 <endogenic> yup
15:45:12 <endogenic> ?
15:45:31 <UkoeHB> For one, all old view keys (except multisig wallets) will not be used any more. The new view keys gain full-view capability (full balance on all accounts/addresses including change/self-spends), so it is strongly advised to not develop third party scanning services with those keys.
15:47:01 <UkoeHB> Full-view means recomputing key images *
15:47:05 <endogenic> why not advised any more than a current lws is advised? that's not much worse than what we have now. and some users would like that
15:47:16 <endogenic> and will there not be a mode which is more private tha that
15:47:26 <endogenic> but less private than the "improved" mode?
15:47:33 <endogenic> we could call improved mode tier 1
15:47:39 <endogenic> and client side scanning tier 0
15:47:50 <endogenic> and full view tier 3
15:48:04 <endogenic> i have to go back ans confirm
15:48:42 <endogenic> people are going to build such services as long as it provides any meaningful speed boost
15:51:11 <endogenic> as a side note i also really question how well a migration to a new keyset will go over
15:51:42 <endogenic> will "cost" a lot
15:52:19 <UkoeHB> There are only three main tiers: spend, view-balance, find-received.
15:52:29 <endogenic> there you go
15:56:16 <UkoeHB> We can’t stop people from building a view-balance service. This is a basic reality of having a view-balance key, (which is a significant improvement over the current key system). All we can do is provide a privacy-optimized third party scanning option. Adding more tiers isn’t really feasible due to increasing complexity/bloat of the system.
15:58:13 <UkoeHB> Migrating the keyset (view keys) is necessary since the new view keys have different capabilities than the old view keys. If we updated without migrating, there would be a behavior change that undermines users privacy models.
16:01:58 <endogenic> that's what I said which you said was not true a couple times then..?. it's an additional option
16:02:18 <endogenic> even if the structure is semi novel
16:02:47 <endogenic> migrating the keys is only necessary if we deem the new features necessary
16:03:18 <endogenic> i think the new tier types are cool personally
16:04:29 <endogenic> i think all options should be given to users
16:05:31 <endogenic> in an ideal world anyway with no costs or tradeoffs
16:14:10 <endogenic> so it's not dead
16:14:21 <UkoeHB> There should only be one migration path, otherwise users that accidentally follow multiple migration paths will encounter lots of issues.
16:14:40 <UkoeHB> (this is guaranteed to happen)
16:17:10 <UkoeHB> Preserving old view keys also implies supporting third party full-view scanning. At the very least, I won’t write any code that helps that happen
16:19:32 <endogenic> what multiple migration paths are you talking about...?
16:20:05 <endogenic> and idk where your last reply is coming from - you just kind of admitted your proposed system will support such tiers
16:20:46 <UkoeHB> ? A) new view-balance key derived from base spend key, B) old view key -> new view-balance key.
16:21:02 <UkoeHB> Path A is specified in the jamtis document.
16:21:11 <endogenic> oh ok gotcha
16:21:56 <endogenic> i dont want full view scanning either
16:22:01 <endogenic> i doubt users would care
16:22:07 <endogenic> bc the alternative is fast enough
16:22:19 <endogenic> but would tier 1 be fast enough? idk
16:22:28 <endogenic> fast including storage, bandwidth etc fwiw
16:26:05 <r4v3r23[m]> hi all, with everything going on in the world i just wanted to show some appreciation for all the work you do on making monero as amazing as it is 
16:26:12 <UkoeHB> Probably on par with current system, since the bulk of download time is key images.
16:26:29 <r4v3r23[m]> more and more people will be relying on it for their freedom, so thank you for your service
16:28:50 <endogenic> UkoeHB: seems like an important question to confirm
16:29:38 <rbrunner> When I look at the "full view-only wallets" that Jamtis newly offers, I don't primarily think about and see any new scanning services
16:29:39 <rbrunner> But much more that we will finally have a system for a fully-functioning voluntary balance disclosure for those cases when its needed or wanted
16:29:54 <endogenic> i agree
16:30:07 <endogenic> well
16:30:17 <endogenic> except for the no new scanning service thing Lol
16:31:06 <rbrunner> Not sure what you mean. Of course we can't prevent anybody from building those. Does not mean we must make the impossible, no?
16:31:15 <rbrunner> *them
16:31:34 <rbrunner> I can't prevent anybody either from typing their seed on a scam site ...
16:32:54 <endogenic> what are you replying to with that question?
16:33:31 <endogenic> the services would be very new
16:33:45 <endogenic> and someone's gonna have to build some tier 1, 2,.. code
16:33:57 <rbrunner> To this remark of yours: "except for the no new scanning service thing Lol" I guessed you would not like such new services. Maybe I am wrong.
16:34:15 <endogenic> no i mean "except for" your remark
16:34:25 <endogenic> as in i do think about them as new and see them
16:34:37 <endogenic> or will see them anyway, perhaps one day
16:35:12 <endogenic> i have reservations if this path is the right direction for monero right now, sure
16:35:23 <endogenic> mostly the keys stuff and some other changes
16:36:21 <rbrunner> It's good to have people taking a critical look, agreed. I don't fully understand yet those reservations of yours, however.
16:37:20 <rbrunner> Do you have doubts about those Jamtis "Full view only wallets"?
16:54:24 <endogenic> hm well i wouldnt want them to be offered by default to users
16:54:47 <endogenic> i am with koe and others who have talked to me about it
16:55:05 <endogenic> in that issue
16:55:36 <endogenic> i dont even think a lws needs to or should implement it
16:55:43 <endogenic> perhaps it can
16:55:57 <endogenic> and then have a user interactively authorize it
16:56:06 <endogenic> or othwrwise confirm
16:56:48 <endogenic> my reservations are a struggle to question what the monero community is focusing on and condoning nowadays
16:56:54 <endogenic> things have changed i think
16:56:58 <endogenic> in some ways
16:57:25 <endogenic> we have higher priorities
16:58:02 <endogenic> and i wonder if this is not only a misdirection of our talent but possibly even a step we'd find it harder to walk back if we need to - mostly around seraphis
16:58:33 <endogenic> increasing ring size is tantalizing
16:59:02 <endogenic> but may be a lure that would prevent ys from prioritizing a real solution
16:59:17 <UkoeHB> real solution?
16:59:17 <endogenic> and i worry about other points that no one is even debating here
16:59:23 <endogenic> i was told things like dont talk about it
16:59:29 <endogenic> by oddly compromised interests
16:59:51 <endogenic> i also notice a flurry of misinfo and frankly bs from those stakeholders when i brought it up in the past
16:59:59 <endogenic> not talking about koe or rbrunner fyi
17:00:11 <endogenic> that misinfo i think has convinced us to think small
17:00:24 <justverify[m]> endogenic: Hi endogenic which points are your referring to?
17:00:34 <endogenic> well i will reiterate here
17:00:48 <endogenic> i posted on github and reddit a few times rexently
17:01:00 <endogenic> hard to type it all w my thumbs again
17:01:25 <rbrunner> Maybe, as it gets less and less technical, we could move over to #monero to continue this discussion?
17:01:34 <endogenic> and i also have to sort out some life stuff rn - i have little help so i have lots of todos - i'm sure i will be painted as running away but frankly i'm exhausted about repeating myself alone
17:01:44 <endogenic> lol nice one rbrunner
17:01:47 <justverify[m]> endogenic: Uh ok no need to rewrite again here, going to check Reddit or GitHub 
17:01:58 <endogenic> research is both more and less technic
17:02:01 <endogenic> al
17:02:04 <endogenic> anywya
17:02:06 <endogenic> .bbl
17:02:09 <rbrunner> You lol already the second time about me today :)
17:02:27 <endogenic> multiply by 10
17:02:56 <rbrunner> ? twenty times? I don't think I wrote already 20 lines here today ...
17:03:26 <justverify[m]> * > <@endogenic:libera.chat> i posted on github and reddit a few times rexently
17:03:26 <justverify[m]> Uh ok I missed them, no need to rewrite again here, going to check Reddit or GitHub 
17:07:25 <rbrunner> I have a guess what endogenic means with this, based on his posts on Reddit and GitHub: "but may be a lure that would prevent ys from prioritizing a real solution"
17:07:53 <rbrunner> With the "real solution" being dropping rings altogether and use something like the Halo protocol from Zcash
17:08:12 <rbrunner> But well, if nobody steps up and develops that ...
17:08:39 <endogenic> you cant easily convince ppl to go back from 96 ring members to 16 if the existing ring sig tech lets us do a spend behavior that the higher scalability version cannot
17:08:42 <kwxmr[m]> <kwxmr[m]> "Hi, do you know which of the 9..." <- Thank you very much UkoeHB . So from what you said I assume Jamtis has selected option 9, Janus E. Right? Thanks again!
17:09:31 <endogenic> so i must step up and being halo 2 to monero? i'm trying to remind us we need to not give up on that and other spending behaviors we cannot even condone but which are now valid
17:09:35 <endogenic> i posted on gh about it
17:10:49 <rbrunner> "so i must step up and being halo 2 to monero?" Did somebody request that from you?
17:13:06 <rbrunner> For me "giving up" would mean we close shop, wait until Pirate Chain copies over Halo 2, and then all switch. Bliss, no more rings :)
17:13:48 <UkoeHB> kwxmr[m]: I said it was Janus B. The find-received tier can link outputs to your addresses (for non-change/self-spends), but can't read amounts.
17:15:25 <UkoeHB> endogenic: you seem to be implying we should be paralyzed by 'what ifs'
17:15:46 <endogenic> opposite
17:15:49 <endogenic> we already are
17:15:55 <endogenic> and it's not a what if
17:16:03 <kwxmr[m]> UkoeHB:  Ok thank you very much!
17:16:04 <UkoeHB> who is paralyzed? not me
17:16:16 <rbrunner> Now it's my turn to lol a bit ...
17:16:23 <endogenic> the community. you said "we" which is plural
17:16:41 <UkoeHB> sure, I don't see anyone who is paralyzed
17:16:47 <endogenic> so?
17:16:57 <UkoeHB> "we already are" ?
17:16:57 <endogenic> what if i said i do?
17:17:05 <endogenic> would you ignore me?
17:17:17 <endogenic> how many people have to say they see it and argue it over and over?
17:17:20 <endogenic> i'm not alone
17:17:32 <endogenic> the people who agree are highly technical
17:17:40 <endogenic> i'm out
17:17:49 <endogenic> i dont need to stress myself over this rn
17:17:59 <rbrunner> Probably not, yeah
17:18:02 <endogenic> clearly has no effect and i get laughed at by rbrunner. thanks man
17:18:08 <endogenic> i'll just keep on my work
17:18:12 <UkoeHB> why drop criticism if you aren't going to back it up... this is confusing
17:18:21 <endogenic> i do back it up
17:18:26 <endogenic> besides i'm not the proof of it
17:18:34 <endogenic> i've talked about it over and over
17:18:46 <UkoeHB> this is the first I have seen you mention halo 2 lol
17:18:56 <endogenic> well, that's bad
17:19:41 <endogenic> i'm not interested in halo 2 specifically either
17:19:49 <UkoeHB> we have a research meeting every wednesday if you want to be sure your research concerns are noticed and addressed
17:19:55 <endogenic> i have been doing so
17:19:58 <endogenic> and will keep doing so
17:19:59 <endogenic> thanks
17:20:07 <endogenic> btw i've been here since 2016
17:20:13 <endogenic> i basically helped start those meetings
17:20:17 <rbrunner> I wonder why it's so hard to get down to Earth and have a discussion with hard technical arguments. I think such arguments would have considerable impact
17:20:29 <endogenic> it's not, jerk
17:20:34 <endogenic> stop arguing so dirty
17:20:41 <endogenic> i'm out if here for now
17:20:47 <endogenic> call me avoidant. maybe i have a reason to be
17:21:15 <rbrunner> I wish you to have impact, and then I am a jerk?
17:21:27 <rbrunner> And argue dirty? 
17:23:38 * kwxmr[m] uploaded an image: (40KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/KaqawqQOOLiRXfTkTTELfdLo/Screenshot%202022-02-19%20at%2018-21-09%20jamtis%20md.png >
17:23:39 <kwxmr[m]> UkoeHB: What is a tier exactly, it is an address with corresponding rights?
17:26:12 <kwxmr[m]> So overall each address  would have the FindReceive tier, plus the 3 merchant tiers, and plus the spend tier? It means 5 levels of private keys that can be shared?
17:26:56 <kwxmr[m]> s/an/private/, s/address/key/
17:27:24 <kwxmr[m]>  * UkoeHB: What is a tier exactly, is it a private key with corresponding rights?
17:27:35 <UkoeHB> kwxmr[m]: check section 4.5
17:28:34 <UkoeHB> I used to word 'tier' originally because higher tiers have all the capabilities of lower tiers (subsets of capabilities).
17:30:12 <kwxmr[m]> UkoeHB: Thank you very much! I have all information I need
19:16:57 <duriancrepe[m]> what was the purpose of the monerod zmq interface? looks like it's incomplete?
19:18:42 <moneromooo> AFAIK, faster RPC. It's used by mymonero internally, but I'm not sure anyone uses it beyond the notifications. It's a parallel RPC so it's getting left out when new RPC get added, but still works fine for what it implements.
19:21:15 <fluffypony> yeah faster RPC
19:21:23 <fluffypony> pub/sub modes as well
19:58:38 <jeffro256[m]> Speaking of RPC, could y'all think of any security concerns for allowing public nodes to send Access-Control-Allow-Origin headers? I created a PR that allows for that: https://github.com/monero-project/monero/pull/8187 
20:00:06 <jeffro256[m]> It would enable a lot of web functionality for webextension or other browser applications, but I'm sure that there was a decent reason for requiring an RPC login 
20:00:18 -xmr-pr- jeffro256 opened pull request #8187: Fixes: Don't require --rpc-login with --rpc-access-control-origins
20:00:18 -xmr-pr- > https://github.com/monero-project/monero/pull/8187
21:30:03 <aksion[m]> Is it possible to make a comment on the transfer (transactions) to Monero? Here in banks there is a "purpose of payment" there you can write any message. This is very important and necessary
22:08:15 <jeffro256[m]> I don't think there is a currently supported way to do this. You used to be able to write unencrypted messages in the tx_extra field, but that was bad for fungibility, so the devs removed that feature. If you aren't using payment IDs you could probably cook up a way to send encrypted comments in the tx_extra field
22:12:23 <jeffro256[m]> https://web.getmonero.org/resources/moneropedia/paymentid.html
22:12:42 <jeffro256[m]> I'm stupid, I'm thinking of unencrypyed payment IDs, just look at the above link
22:14:04 <aksion[m]> a simple unencrypted message (payment comment) for the recipient
22:14:37 <jeffro256[m]> It will be encrypted between you and the recipient, so they can see it
22:15:11 <jeffro256[m]> but not anyone else
22:24:33 <aksion[m]> and how many characters are allowed there at most? How to do it?
22:30:03 <merope> Please don't bloat the chain by putting stuff in tx_extra
22:30:08 <merope> Especially messages
22:30:58 <merope> Just use one of the myriad of encrypted communication methods already available. Much more efficient, and avoids bloating the chain forever
22:32:21 <aksion[m]> I don't need an encrypted message, and I don't even need it to be stored somewhere in the blockchain. You just need to get it to the recipient of the payment with the payment and read it
22:33:22 <merope> tx_extra gets stored in the blockchain as part of the transaction data, so it's not what you're looking for then
22:33:55 <merope> You need to establish some form of communication with the recipient
22:34:13 <aksion[m]> merope: The recipient of the payment can be anonymous. How am I even going to find other means of communication with him, as you say?
22:34:57 <aksion[m]> For this, monero is anonymous
22:35:18 <merope> Same way you found their wallet address, I guess. They could leave you some additional contact information
22:39:45 <jeffro256[m]> Oh yeah if you just want an off-chain way to communicate payment details to someone, use any anonymous messenger
22:40:43 <jeffro256[m]> Also endor00, IIRC you can't "bloat" tx_extra because it's also the same size no matter whether you use it or not. 
22:43:21 <aksion[m]> I do not know the person there is no data (such a situation if). And yes, there are no anonymous messengers. Here Montero could become such on the basis of its technologies, where is the wallet (account number) this is the login in the messenger
22:45:18 -xmr-pr- Cactii1 opened issue #8188: show_transfer <txid> command doesn't work in CLI
22:45:18 -xmr-pr- > https://github.com/monero-project/monero/issues/8188
22:56:08 <monerobull[m]> https://xmrchain.net/tx/ebd166a3634ad39bf42f94957f25f092864da62373db15db14c96511acc293cc
22:56:15 <monerobull[m]> another 3 xmr fee
22:56:36 <monerobull[m]> https://www.reddit.com/r/monerosupport/comments/swkpl4/paid_3_xmr_in_fees_for_transfer_of_02_xmr/