01:18:49 <selsta> sech1: is this something you could answer? https://github.com/monero-project/monero/issues/8233
01:20:08 <sech1> "sender , receiver address and amount" - Sir, this is Monero
01:22:49 <sech1> and I answered it on IRC already a couple days ago
01:25:31 <selsta> do you know which channel this was? then I can copy it into the issue
01:30:24 <sech1> it was #monero-community https://paste.debian.net/hidden/36eb0d46/
01:30:54 <selsta> thanks
05:41:27 <nollied[m]> has anyone written any code that can interface with monero locally via a python API?
05:42:19 <nollied[m]> looks like i pretty quickly found the answer to my own question: https://github.com/monero-ecosystem/monero-python
06:33:07 <nollied[m]> this might be a stupid question, but is there a way to interface with monero without using the daemon? like can it be initiated in the runtime for a more light-weight development experience? 
07:21:56 <makkiato[m]> nollied[m]: in the library you linked there is a class (/backends/offline.py) for offline creation of a wallet, private keys, secret phrase etc. 
07:22:39 <makkiato[m]> However you need a node for anything else. What else would you (even conceptually) like to do without the knowledge of the status of the blockchain? 
07:23:41 <nollied[m]> yeah but pretty much all of the functions raise exceptions
07:24:48 <moneromooo> All the functional tests do just that.
07:24:51 <nollied[m]> mak_noob[m]: i'm wondering if you can run the blockchain but not in the daemon
07:25:02 <moneromooo> (interfacing locally with monero)
07:25:58 <moneromooo> To avoid using the daemon, either (1) code everything again or (2) link with the monero libs, if that counts as "without monero" for yo.
07:26:23 <makkiato[m]> nollied[m]: no I do not thing the python library can be used to build a "minimal daemon" from scratch if that is what you are asking. I think the python library is basically a RPC interface.
07:26:35 <moneromooo> 2 is going to be a large amount of work though.
07:26:52 <nollied[m]> linking with the monero libs makes sense, but yeah that would be really hard and unnecessary
07:27:00 <moneromooo> The blockchain is just data, it does not run. The monerod daemon is what processes it.
07:27:58 <nollied[m]> is there a live testnet? why do we need to download the testnet data just to be able to develop
07:28:09 <nollied[m]> separate question
07:28:15 <moneromooo> There is. You don't.
07:28:36 <moneromooo> See for instance, again, the python tests.
07:28:41 <nollied[m]> oh, from that repo it mentioned it was necessary
07:28:59 <moneromooo> Maybe it's necessary for what they do. I meant in general.
07:29:32 <nollied[m]> https://monero-python.readthedocs.io/en/latest/quickstart.html#start-the-daemon-and-create-a-wallet
07:30:01 <nollied[m]> ok cool, is that what offline mode is?
07:30:43 <makkiato[m]> maybe you should try to read a bit the code and understand what it does. 
07:30:44 <moneromooo> Offline will not connect to other peers, and thus not try to get their chain nor try to upload yours to them.
07:30:54 <moneromooo> You can then have your own local chain, parallel to the "main" one.
07:31:02 <makkiato[m]> there is no magic: https://github.com/monero-ecosystem/monero-python/blob/master/monero/backends/offline.py
07:31:41 <moneromooo> Oh. Again, I was talking of monero, not that particular python lib. I guess I should stop talking since concepts may be different between both :)
07:31:52 <nollied[m]> mak_noob[m]: i read that. it literally raises exceptions for all functions
07:32:16 <nollied[m]> moneromooo: you answered my question very well
15:59:57 <sech1> Meeting here in 1 hour?
16:00:28 <selsta> yes
16:27:53 <MajesticBank> If I am correct Dandellion++ protects node from other nodes on the network from finding tx originating IP
16:28:18 <nikg83[m]> MajesticBank: Yes
16:29:06 <MajesticBank> what protects light wallet users from clearnet nodes correlating tx size of mempool and traffic analysis? 
16:30:18 <MajesticBank> or when attacker own both wallet / have access to exchange wallet and have ability to see traffic on that clearnet nodes
16:30:43 <nikg83[m]> MajesticBank: Light wallets use remote nodes ? 
16:30:43 <MajesticBank> it's specially dangerous when mobile wallet is using only one clearnet node for 10k/20k users
16:31:07 <MajesticBank> ya, mean mobile wallets
16:31:57 <nikg83[m]> MajesticBank: Ideally all tx broadcasts should be over tor/i2p by default, maybe someday we will have it 
16:32:21 <MajesticBank> both timing and traffic correlation attack would be very easy to perform
16:35:16 <nikg83[m]> MajesticBank: Yes if there is a mitm attack on remote nodes ? 
16:35:56 <WinslowEric[m]> nikg83[m]: what could it achieve
16:36:10 <MajesticBank> There is no need for mitm for nodes hosted in US
16:37:54 <WinslowEric[m]> By the way, how to set up my public node with TLS support
16:38:04 <WinslowEric[m]> do I need to bind it to a domain name or somethin
16:38:21 <moneromooo> Don't use strangers' nodes and then wonder why it's dangerous.
16:38:58 <nikg83[m]> moneromooo: Using Cake wallet nodes would be dangerous? 
16:39:13 <MajesticBank> moneromooo: It's by default in mobile wallets
16:39:15 <moneromooo> Are they your nodes ?
16:39:55 <moneromooo> MajesticBank: are you assuming default settings in software are the secure settings ? If so, it's incorrect in general.
16:40:04 <nikg83[m]> moneromooo: I can’t run my own node, as I am behind nat 
16:40:13 <WinslowEric[m]> nikg83[m]: use frp
16:40:15 <nikg83[m]> * > <@moneromooo:libera.chat> Are they your nodes ?
16:40:15 <nikg83[m]> I can’t run my own remote node, as I am behind nat 
16:40:18 <WinslowEric[m]> that is what i did
16:40:52 <MajesticBank> moneromooo: No, just addressing average user issue
16:40:53 <WinslowEric[m]> Run daemon on your machine then use FRP to map it to public
16:41:15 <WinslowEric[m]> WinslowEric[m]: I built xmr.winslow.cloud with that
16:41:32 <moneromooo> Most of the time, it's fine. Like when leaving a loaded handgun near your toddler.
16:45:08 <MajesticBank> Was thinking there is some solution at protocol level that could enforce it, traffic noise or making transaction look same for traffic observer
16:47:36 <onions> lol, that analogy moneromooo.
16:48:07 <moneromooo> Well, my usual one: don't use a stranger's node. You wouldn't use a stranger's dildo, would you ?
16:48:13 <merope> nikg83: you can run a node from behind nat just fine. You won't have any incoming connections, but you will be able to open outgoing ones - and data flows both ways
16:48:15 <onions> MajesticBank: maybe muse about it over in #monero-research-lab, or #monero-research-lounge? I don't know. Stackexchange, reddit?
16:48:28 <onions> moneromooo: lol ffs.
16:48:29 <moneromooo> I'd hope it'd make people pay attention, but it hasn't. Such sad.
16:49:01 <nikg83[m]> merope: Yes I mean when I am outside and need to use mobile wallet, can’t connect to my node; I might try tor setup and see if it helps 
16:49:57 <moneromooo> If your ISP prevents you from connecting to the connection you pay for, you can always complain and see if that helps.
16:50:23 <moneromooo> It might not help right away, but the more people do it, the more it helps over time.
16:50:41 <nikg83[m]> moneromooo: They don’t have public IPs, IPv6 is not common here 
16:50:54 <ErCiccione> Meeting here in 10 minutes
16:50:54 <moneromooo> Same as monero. Making privacy enabled software might not help right now, but the more exist, the likelier we end up at a critical mass at some point.
16:51:11 <moneromooo> Like voting. A vote ain't changing much. But if you don't vote...
16:52:00 <WinslowEric[m]> Yeah ask ISP for public IP address
16:52:05 <WinslowEric[m]> at least give it a shot
16:52:18 <moneromooo> You mean, the same IP address is used by many people ?
16:52:40 <moneromooo> If so, yes, that sucks, I hope you get it cheap at least.
16:52:42 <WinslowEric[m]> no exclusive one
16:52:59 <WinslowEric[m]> some might provide you free bouncy address
16:53:07 <moneromooo> If exclusive, then you should be able to connect to it or your ISP is a steaming pile of asshole.
16:53:15 <WinslowEric[m]> Some ISP here in China does that
16:53:17 <nikg83[m]> moneromooo: Yes, a billion ppl here & they can’t provide IPs to everyone 😅
16:53:56 <WinslowEric[m]> WinslowEric[m]: *Means they sometimes alter but you can monitor it with a script
16:54:11 <merope> You can get your own ipv6 /64 block for free
16:54:53 <merope> https://tunnelbroker.net/
16:54:55 <moneromooo> Oh. I think I merged two people's lines thinking they were from one.
16:54:56 <merope> For example
16:56:09 <merope> Set it up on your router, and then you will be able to reach your home network via ipv6
16:57:07 <moneromooo> How can you do that if your ISP does not support IPv6 (which I think was implied by "They don’t have public IPs, IPv6 is not common here") ?
16:57:44 <merope> Tunneled over ipv4
16:58:17 <moneromooo> If you can get to your server via ipv4, why do you then need ipv6 ?
16:58:31 <moneromooo> (I know not much of modern networking, so if I'm being dumb, tell me)
16:58:40 <merope> Because you can't reach it via ipv4, because it's behind a nat
16:59:21 <merope> Your router opens an ipv4 connection with the broker, which then routes the ipv6 packets destined for you through that tunnel
16:59:42 <moneromooo> Ah, if your router does this, then you don't need ipv6 in the first place, no ?
16:59:55 <moneromooo> ie, it's a reverse proxy.
17:00:14 <merope> But you need something on the other side for that reverse proxy
17:00:43 <merope> So either you buy your own server/vps/public ipv4 address, or you get this tunneled ipv6
17:01:10 <merope> And you get a nice massive /64 ipv6 subnet all for you
17:01:12 <ErCiccione> Ready for the meeting?
17:01:18 <ArticMine> Yes
17:01:26 <rbrunner> Hope so :)
17:01:30 <merope> Have fun!
17:01:30 <ErCiccione> let's start
17:01:37 <ErCiccione> Hello folks! This meeting, like the last one, will be focused on the next network upgrade (hard fork)
17:01:42 <ErCiccione> Logs of the past meeting: https://github.com/monero-project/meta/issues/655#issuecomment-1024960649
17:01:48 <ErCiccione> Meeting agenda: https://github.com/monero-project/meta/issues/680
17:01:54 <ErCiccione> Quick round of greetings to see who is here:
17:01:58 <ErCiccione> Hello everyone!
17:02:05 <UkoeHB> hi
17:02:06 <binaryFate> hi
17:02:12 <ArticMine> hi
17:02:12 <rbrunner> Hello
17:02:16 <jberman[m]> :waves:
17:02:18 <WinslowEric[m]> Greetings!
17:02:40 <mj-xmr[m]> Present
17:02:40 <selsta> hi
17:02:41 <sech1> hi
17:03:38 <ErCiccione> Ok, thanks for being here. I would say we can explore the status of the PRs that need to be merged and the PRs that would be good to have. After we have an idea of the situation, we can decide if makes sense to set a date.
17:03:45 <ErCiccione> rbrunner made an excellet summary of the situation the we can use as a guide: https://github.com/monero-project/meta/issues/680#issuecomment-1079924577
17:04:09 <ErCiccione> I would also like to dedicate a bit of time to discuss the status of multisig in relation to the hard fork, because in-progress projects like Haveno and RINO need multisig to be robust, before being able to launch.
17:04:37 <ErCiccione> The situation in general looks good, most PRs have already been reviewed or are ready to be merged. So, that's a good start
17:04:55 <moneromooo> Oh wow, BP+ still not merged. I did that ages ago now...
17:05:17 <UkoeHB> 8149 needs to rebase onto 8061
17:05:19 <sech1> view tags not merged as well
17:05:39 <rbrunner> Maybe a gentle ping for vtnerd, as they are involved in so many important reviews ...
17:06:20 <ErCiccione> Ok, let's start with the first one i would say, fee changes
17:06:29 <ErCiccione> that mostly only needs to be merged as far as i can tell
17:06:45 <jberman[m]> fee changes looked good to me
17:07:02 <rbrunner> Including the compromise from the last meeting, right?
17:07:15 <jberman[m]> yep
17:07:21 * moneromooo gets itchy at the mention of compromise
17:07:28 <UkoeHB> I think it can be merged
17:08:24 <ErCiccione> Good. next one is bulletproof+. What's missing?
17:08:33 <selsta> I can type that up.
17:08:34 <moneromooo> Nothing AFAIK.
17:08:58 <ErCiccione> A final approval i would say
17:08:59 <UkoeHB> it doesn't have any approvals
17:09:02 <rbrunner> The final signing off of the the review?
17:09:02 <UkoeHB> 0
17:09:16 <selsta> We have BP+ audited, so in general it should be good to merge. vtnerd reviewed it a while ago but he never approved it.
17:09:48 <selsta> I asked him for an approval but he kinda started a new review from scratch, and now he is currently unavailable and it's unclear when he will have time again.
17:10:13 <UkoeHB> maybe jberman[m] and I can do brief reviews (check hard fork mechanics, glance over crypto use)
17:10:40 <jberman[m]> can do that
17:11:08 <rbrunner> The testing on Testnet should also have some value, even if something escaped review
17:11:13 <ErCiccione> nice. Thanks. We should get word from vtnerd to make sure if we should expect a review from him or not
17:11:56 <binaryFate> he's currently unavalaible and I'm not sure how quickly we can expect that word
17:12:54 <ErCiccione> alright. Next PR is to bump ringsize to 16 https://github.com/monero-project/monero/pull/8178
17:13:21 <rbrunner> Pretty simple code, uncontroversial from that point of view
17:13:27 <ErCiccione> this one shouldn't require any further discussion and only need to be merged
17:13:35 <jberman[m]> noticed a couple small merge conflicts with tests, will resolve those asap
17:13:58 <selsta> It looks approved, maybe moneromooo wants to look quickly over it too because I think you are the most experienced with such ring size bump PRs.
17:14:16 <moneromooo> Sure.
17:14:36 <jberman[m]> jberman[m]: (sorry thought this was for view tags)
17:14:45 <jberman[m]> ty moo
17:15:33 <ErCiccione> Anything else on #8178? Otherwise we can move to the next one
17:15:45 <selsta> i'd say move on
17:16:22 <ErCiccione> Allright. View tags: https://github.com/monero-project/monero/pull/8061
17:16:35 <jberman[m]> noticed a couple small merge conflicts with tests, will resolve those asap :)
17:16:42 <sech1> I not only reviewed view tags, but also implemented it in p2pool and tested it on a private testnet. All went smooth - p2pool could mine, monero-wallet-cli could see payouts.
17:16:48 <sech1> so #8061 looks good to me
17:17:16 <rbrunner> Also testet it. Works.
17:17:21 <selsta> #8061 looks ready
17:17:22 <jberman[m]> noice
17:17:45 <rbrunner> Your chance for eternal fame
17:18:00 <ErCiccione> Nice. Seems like was reviewed and tested quite extensively. I would say only final approvals are needed after jberman's fixes and then can be merged?
17:18:27 <selsta> The order in which we should merge things is also something we have to discuss later.
17:18:47 <selsta> Largest changes first and then the smaller ones I assume.
17:19:28 <rbrunner> Merging will probably limit itself with generating conflicts
17:20:33 <jberman[m]> It will have some conflicts with multisig stuff and bp+
17:21:16 <rbrunner> And RPC versions numbers are another source of conflicts
17:21:55 <sech1> RPC version is easy to resolve since we're doing a hardfork. Just use some new higher number
17:21:57 <moneromooo> Seemed like a good idea at the time...
17:22:20 <jberman[m]> One thing we also mentioned briefly in the last MRL meeting was what the "grace period" should be where tx's with view tags and without are allowed, to allow the pool to clear (ring size bump and bp+ also have this grace period). We settled on 1 day same as in the past from what I remember, so just re-affirming that
17:23:27 <selsta> IIRC we always had 1 day
17:23:49 <jberman[m]> cool
17:24:10 <selsta> #7877 is merged so #8149 next to discuss?
17:24:12 <ErCiccione> alright. We can go back to this if needed. The next PR in the list is the fixes for multisig: https://github.com/monero-project/monero/pull/8149
17:25:09 <UkoeHB> I need to rebase that when BP+ and view tags are in
17:25:28 <rbrunner> Is the original author of that PR, perfect-daemon, still, well, missing? And does that matter in any way?
17:25:35 <selsta> it kinda was reviewed by UkoeHB and vtnerd, not only vtnerd
17:25:38 <ErCiccione> I want to stress the importance of having multisig fixed as soon as possible, so would be good to also have two more PRs merged for the hf: https://github.com/monero-project/monero/pull/8220 and https://github.com/monero-project/monero/pull/8220
17:26:14 <rbrunner> That's two times 8220? :)
17:26:26 <UkoeHB> 8203 is the other one
17:27:02 <ErCiccione> lol sorry: the other one is https://github.com/monero-project/monero/pull/8203, yes
17:27:12 <UkoeHB> I need a third pr to add force updating. So 8220 -> new PR -> 8203 to get everything in
17:27:17 <rbrunner> Yeah, but 8203 is still very much at the beginning, as far as I can see. And does it harmonize with the added control round?
17:27:36 <UkoeHB> no, I will need to rebase
17:28:06 <rbrunner> But not much change in logic or even crypto? I am a bit sceptical about that, time-wise, to be honest
17:28:41 <rbrunner> Does Haveno intend to take advantage of the improvements that this would bring?
17:29:07 <UkoeHB> not too much change, at least compared to the original PR
17:29:42 <ErCiccione> rbrunner: Haveno sponsored a good portion of the changes 🙂
17:29:59 <ErCiccione> So, at the ends looks like multisig is the PR that needs the most attention
17:31:19 <ErCiccione> Oh, reminder that RINO set a bounty as well of $10000 for merging all three PRs, so that should be a good incentive for the community
17:31:49 <binaryFate> Do we lack reviews maybe because the vulnerabilities are not really public? I know some background info has been passed to few people only
17:31:59 <rbrunner> It's 4 multisig PRs, no?
17:32:08 <selsta> binaryFate: it's all public in the patch
17:32:18 <ErCiccione> rbrunner: 1 is already merged
17:32:27 <UkoeHB> we lack people actually able and willing to review
17:32:37 <binaryFate> selsta: yes but I mean some context maybe making reviewing easier
17:32:42 <binaryFate> good if not a blocker
17:33:11 <rbrunner> I think if we aim to take 8203 in, 8220 should get merged as soon as possible, to make that "interim" PR possible
17:34:14 <ErCiccione> yeah, we should probably reach to the community asking for reviewers if finding them for those changes is an issue
17:35:13 <jberman[m]> I can review general patterns and such, but don't think I'm able to do a comprehensive crypto review to spot vulnerabilities yet (I've been studying, but not there yet)
17:35:25 <selsta> I mean if we need more security then an audit would help, but I'm not sure if we will find another review for it in the community.
17:35:48 <mj-xmr[m]> Same here as jberman[m] . Even less crypto knowledge sadly.
17:35:51 <rbrunner> Certainly not with vtnerd unavailable ..
17:36:05 <selsta> rbrunner: I mean vtnerd reviewed it, unless we are talking about a different patch now
17:36:16 <ErCiccione> could/can luigi1111 give it a shot?
17:36:45 <rbrunner> I was thinking about 8220, which has no comprehensive review, but only me testing it and moneromoo looking at the code, but not the crypto, if I understood correctly
17:37:21 <UkoeHB> 8220 doesn't have any crypto changes, just key exchange protocol changes
17:37:23 <selsta> oh ok, I was still mentally at 8149
17:37:54 <rbrunner> Yeah, that might be a problem if we think we need a second review
17:38:27 <rbrunner> I would be confident enough to merge 8220 ...
17:38:35 <ErCiccione> Ok. Then we need to find somebody able to review that PR, if you know somebody, maybe ping them on the pr to catch their attention
17:38:43 <selsta> 8203 is the one without any review currently
17:39:13 <UkoeHB> is h4sh3d around? maybe he could take a look at 8220
17:39:43 <h4sh3d> Hi!
17:40:05 <UkoeHB> 8203 is on hold anyway until I can rebase onto 8220 + 1
17:40:47 <UkoeHB> hi h4sh3d :) feeling up for more multisig review?
17:40:57 <UkoeHB> this guy: https://github.com/monero-project/monero/pull/8220
17:41:31 <rbrunner> Should not hurt too much, and the code runs :)
17:41:55 <h4sh3d> Yeah sure! Time wise it will not be possible for me in the next 2-3 weeks (family getting bigger ;p) but after that for sure! If that’s not too late for you guys?
17:42:28 <UkoeHB> would it be possible to postpone multisig stuff to a post-fork point release?
17:42:42 <rbrunner> Well, looks like timewise, it's on the critical path
17:43:29 <binaryFate> While it doesn't need to be part of a HF, I'm worried that many people using Monero but not following closely may not have seen the multisig issue announcement. So having the fix in the HF is ensuring everyone will at least use updated version after that
17:43:34 <rbrunner> That would be my proposal for 8203, frankly. I think postponing all would be unfortunate
17:44:02 <rbrunner> And the rest is really so close ...
17:44:11 <ErCiccione> I would really prefer to not postpone it. That could create huge problems for Haveno. Like having to hold off launch
17:44:48 <binaryFate> Multisig wallets would usually be used for large amounts, I'm concerned some big entity out there will get hit by the vulnerabilities unless we force them to update basically (via fix being in HF)
17:45:09 <UkoeHB> I just mean release it separate from the hf, not delay review/merging (which is happening at a snails pace anyway).
17:45:30 <binaryFate> Yes but then you lose this force-to-update effect of the HF
17:45:34 <rbrunner> Isn't that a contradiction?
17:46:30 <UkoeHB> well it's up to you guys, not much I can do to speed things up on my end
17:46:50 <rbrunner> Maybe if we ask nicely moneromooo can look a bit deeper into 8220 and approve, and we merely move 8203 into a point release
17:46:53 <ArticMine> Why not release multi sig with another HF?
17:47:30 <WinslowEric[m]> Haveno would be delayed for that
17:47:43 <onions> Two HFs? Back to back? Seems like a lot of headache...
17:48:24 <r4v3r23[m]> WinslowEric[m]: fine by me. this is a monero update, not a haveno one
17:48:42 <ArticMine> What is the timeline fro multi sig review etc?
17:49:04 <binaryFate> ArticMine: IMO too extreme to abuse the HF concept just for this desirable side effect on multisig wallet code
17:49:08 <ErCiccione> We need to find reviewers, that's the problem. Pushing to another hf seems eccessive
17:50:03 <ArticMine> Fair enough but there are problems with a partial implementation of multi sig without a HF
17:50:19 <selsta> BP+ is not approved yet, then we also have to do changes to Ledger and Trezor for BP+ (which supposedly isn't much work but someone has to look into it), that will also take time. It's not like all other stuff is 100% ready and we are only waiting on multisig.
17:50:27 <selsta> We will also need time to test everything on testnet.
17:50:38 <binaryFate> what HF timeline are we talking about?
17:50:53 <ArticMine> For multi sig
17:52:15 <rbrunner> Is the loose consensus now that we must have a second review for that heavyweight multisig PR 8149?
17:52:49 <selsta> 8149 had two reviews, I doubt we will get more without an audit.
17:52:55 <UkoeHB> we will need some kind of review when I rebase
17:52:56 <rbrunner> Because if not, 8220 is peanuts in comparison, and IMHO 8203 nice to have, but not critical. Haveno may disagree.
17:53:38 <rbrunner> Ah, yes, UkoeHB reviewed the original one.
17:53:42 <binaryFate> maybe we can make a clear announcement of what exactly needs more reviews, so that external entities out there can decide to step in to finance/organize an audit?
17:53:49 <ErCiccione> 8203 is not urgent for us iirc
17:54:27 <rbrunner> So where's the problem? :)
17:54:53 <ErCiccione> Ok so, we have 5 minutes left so to wrap it up:
17:55:08 <ErCiccione> we need somebody to approve BP+, which has been already extensively reviewed
17:55:11 <ArticMine> Do we have a timeline for the HF?
17:55:12 <UkoeHB> what about getting 8149 into the HF, then 8220 + 1 + 8203 into a point release (if necessary)?
17:55:43 <sech1> we're not discussing HF date in this meeting?
17:55:47 <UkoeHB> ErCiccione: jberman[m] and I will look at the BP+ PR (probably within 1-2 weeks)
17:56:10 <jberman[m]> UkoeHB: +1
17:56:14 <ErCiccione> sech1: if we feel like we already for it sure, but we don't have much time left
17:56:34 <UkoeHB> usually dev meetings extend past the hour, I don't mind staying
17:56:41 <ArticMine> I am ok
17:56:58 <ErCiccione> shouldn't take long anyway
17:57:00 <rbrunner> A date would be nice, even as an attempt ...
17:57:06 <selsta> The problem with timeline / setting a date is difficult when some things are unclear with how long they will take. I'd like to have BP+ merged first and then someone who can look into Ledger / Trezor changes.
17:57:38 <selsta> Last time we set a date there were a lot of things unreviewed and then the date came it it became pointless because we can't just merge things unreviewed.
17:57:46 <sech1> 2 months should be enough for everything probably
17:57:51 <sech1> we have a nice date approaching https://p2pool.io/tail.html
17:58:13 <binaryFate> :)
17:58:32 <r4v3r23[m]> as a community member, holding back on a major monero upgrade that brings BP+ and higher ring sizes for the sake of an external project doesn't look like the way to go, especially if the PRs mentioned arent critical to multisig. projects should build around monero's progress, not the other way around
17:58:41 <ErCiccione> personally i find myself in the middle. I would like to set a date, because pushes people to wrap things up, but i also don't want to get to a point where we postpone it again
17:58:54 <UkoeHB> mining software might need to double check that they won't get uint64 overflow when the total supply exceeds uint64::max; iirc moneromooo fixed Monero's implementation a couple years ago
17:58:56 <selsta> So maybe someone can do an extra overview issue on multisig, with the current status of each PR and what is remaining. rbrunner something like your comment
17:59:16 <rbrunner> Who are the candidates for Ledger and Trezor changes?
17:59:26 <selsta> well usually the companies do it themselves
17:59:45 <selsta> but last time I needed a small change from Ledger they took over a month, so I feel like we will have to do the changes ourselves.
17:59:48 <ErCiccione> selsta: That would be useful
18:00:24 <UkoeHB> selsta: I guess I can write that
18:00:25 <selsta> also Trezor only updates their firmware every couple months, that was an issue the last hardfork
18:00:54 <rbrunner> Does all not sound too happy then
18:01:04 <selsta> it always works out somehow :P
18:01:36 <sech1> "uint64 overflow when the total supply exceeds uint64::max" <- this is still a few years away. Tail emission starts before 2^64
18:01:38 <ErCiccione> alright, then i would say setting a date it's premature, but we could set a date for another meeting?
18:01:54 <ErCiccione> 1 or two weeks away?
18:01:59 <UkoeHB> selsta: ah
18:02:02 <UkoeHB> sech1: ah
18:02:26 <ArticMine> Give it two weeks and look at setting the HF date then?
18:02:38 <UkoeHB> how about 2 weeks, monerotopia is this week
18:02:45 <ErCiccione> sounds good to me
18:02:55 <rbrunner> Yeah, with 2 weeks there might be a chance to have BP+ fully reviewed until then
18:03:14 <ErCiccione> yeah and we will ahve the status of multisig more clear
18:03:16 <ErCiccione> ok then
18:03:16 <ArticMine> or at least have a good idea on the timeline
18:03:37 <ErCiccione> thanks everybody for joining. Have a good rest of the day and see you in a couple of weeks
18:03:45 <ArticMine> Thanks
18:03:53 <binaryFate> thanks everyone
18:03:54 <rbrunner> Thanks for the moderation
18:04:00 <ErCiccione> feel free to keep discussing 🙂
18:04:13 <mj-xmr[m]> Thanks!
18:11:15 <dEBRUYNE> With respect to reviewing the multisig PRs, would it be worthwhile to hire an audit firm for that?
18:11:24 <dEBRUYNE> Would definitely speed up the process
18:11:41 <dEBRUYNE> And I am certain the community would be willing to contribute to a CCS that raises funds for an audit firm
18:12:13 <dEBRUYNE> JP Aumasson has done a few audits for Monero (related) code if I recall correctly, we could try to contact him
18:12:48 <WinslowEric[m]> Agree, I'd like to send some monero for that.
18:13:09 <dEBRUYNE> cc binaryFate ErCiccione 
18:13:36 <dEBRUYNE> Would potentially be worthwhile to dedicate the RINO bounty to that, but it is of course up to RINO's discretion where to allocate the bounty
18:14:30 <binaryFate> We could put some communication out there describing scope of work, so that external entities could decide to step in and help
18:14:52 <binaryFate> Maybe some Kraken grants or something like that, exchanges must hate not having multisig
18:15:02 <rbrunner> An external audit might take quite some time
18:15:36 <dEBRUYNE> Think it would be faster than finding 'internal' reviewers to be honest
18:15:42 <dEBRUYNE> Especially if we actively reach out
23:45:48 <nahnahnah722828[> Hey debout ne
23:45:57 <nahnahnah722828[> <dEBRUYNE> "Especially if we actively..." <- Hey debruyne 
23:46:13 <nahnahnah722828[> I have a question
23:46:52 * nahnahnah722828[ uploaded an image: (107KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/IJSwLfCDyJBoDgYOxyKWKuBX/ima_09d7ba1.jpeg >
23:47:26 <nahnahnah722828[> Sethforprivacy says that an exchange could connect your monero with your id, via targeted attacks… is there some truth to what he’s saying ?
23:47:52 <nahnahnah722828[> * Sethforprivacy says that an exchange could connect your monero with your id if you kyc… True or false ?
23:52:31 <louipc> you can do anything with targetted attacks
23:52:53 <louipc> has nothing to do with monero in that case
23:53:21 <louipc> your devices can get cracked, keyloggers installed. not monero's fault
23:55:25 <nahnahnah722828[> louipc: But if you withdraw monero from coinbase to your own wallet, you can start using it as normal without them being able to see anything ?
23:55:38 <nahnahnah722828[> He’s suggesting that if you have KYC’d monero you can be tracked…
23:56:46 <louipc> if you read it again he's saying you will be safe
23:56:55 <louipc> unless you get targetted