06:50:33 <moneromooo> jwinterm: looks like you never got any blocks from a peer just yet.
08:44:33 <selsta> .merges
08:44:33 -xmr-pr- 8296 8356 8357 8358
08:54:24 <sech1> when 0.18 release?
08:54:51 <sech1> still on track for June 16th?
08:56:18 <selsta> ledger will be the problem
08:57:46 <sech1> is anyone in contact with them?
08:59:09 <selsta> i'm in their discord but i don't have any info myself
08:59:20 <selsta> they said "ok" over a month ago and then nothing
09:00:23 <sech1> They still have until July 16th to update their stuff
09:00:39 <sech1> v0.18.1 (day 1 patch, lol) can have proper ledger support
09:01:14 <selsta> yes, that's the plan but i would like some confirmation that someone is working on it
09:02:49 <sech1> there's also GUI that needs to update p2pool hashes to v2.1 to support the fork. But it will be a quick patch from me.
09:06:13 <selsta> yea, GUI won't be a problem, main issue I'm currently seeing is Ledger
09:06:31 <selsta> Last time it took them 1 month to release a simple version bump with 0 changes
09:08:34 <selsta> both previous employees that were responsible for monero either quit or moved to a different position
09:16:07 <ErCiccione> They were the problem last hard fork too and they were helped greatly by monero devs. Seems to me that they don't care much about their Monero customers
10:54:19 <woodser[m]> are integrated subaddresses permissible and supportable? monero-wallet-rpc does not support it. one can manually call the same utilities to create integrated subaddresses, but there seems to be a problem when sending funds to self with one of these
10:55:24 <moneromooo> No.
10:56:03 <moneromooo> Subaddresses were made to avoid having the two part addresses, which confused users as they had two addresses that looked different but sent to the same address.
10:56:30 <moneromooo> Well, that's one reason at least.
11:03:47 <woodser[m]> ok, thanks
12:12:38 <r4v3r23[m]> <r4v3r23[m]> "is there a way to set a password..." <- would this be at all possible to add in the wallet current structure?
12:12:53 <r4v3r23[m]> s/wallet/wallets/
12:14:53 <moneromooo> Passwords for what ?
12:15:22 <r4v3r23[m]> for specific accounts within the wallet
12:16:09 <r4v3r23[m]> so different accounts would open up depending on what password you enter
12:16:17 <moneromooo> It seems possible. Not worth the bother though, unless you can come up with a good reason.
12:16:53 <r4v3r23[m]> decoy wallets is the first use case that comes to mind
12:17:03 <moneromooo> For sending, at lesat. For receiving, it seems not too easy.
12:17:12 <moneromooo> What is a decoy wallet ?
12:17:48 <r4v3r23[m]> also a way to separate funds within the wallet without having to have different seeds
12:18:05 <moneromooo> You can do that currently. It does not require passwords.
12:18:28 <r4v3r23[m]> moneromooo: a wallet that has a minimal amount of money that would be used in case you are ever forced to open your wallet
12:18:50 <moneromooo> Why would you ever want to do that in the same wallet ?
12:18:53 <r4v3r23[m]> moneromooo: yes, but all accounts are visible once the wallet is opened
12:19:30 <r4v3r23[m]> moneromooo: well the password would only open account #2 for example, with 0.1234 XMR in it
12:20:04 <moneromooo> I assume you'd want it so you cannot tell if an account is "open" or not, then, right ? Otherwise it's self defeating.
12:20:51 <r4v3r23[m]> basically, main wallet password = opens main wallet with access to all accounts
12:21:18 <r4v3r23[m]> then account specific password = only open that account without seeing the rest of the wallets funds
12:21:32 <moneromooo> What you are asking for is:
12:21:36 <r4v3r23[m]> so, a wallet within a wallet
12:21:55 <moneromooo> - much more dangerous (bug wise and info leak wise) than just using a seed offset
12:22:18 <r4v3r23[m]> why is it more dangerous?
12:22:32 <moneromooo> - self defeating, as someone who wants to steal your stuff can likely tell (if they know where to look) that thre is some encrypted stuff left
12:22:42 <moneromooo> - not worth the work 
12:23:19 <moneromooo> It is more dangerous because it requires adding a non trivial amount of code, which has to be all correct (or mostly correct). 
12:23:38 <r4v3r23[m]> ok, is it possible today for a wallet dev to implement that, or would that require change to the monero wallet code?
12:24:03 <moneromooo> It is possible for wallet dev to implement that, and it would require cahnges to the monero wallet code.
12:28:38 <r4v3r23[m]> ok, thanks for the indo
12:28:41 <r4v3r23[m]> s/indo/info/
12:43:04 <wernervasquez[m]> r4v3r23: regarding a decoy wallet, I have thought the truecrypt hidden volume method would be the way to go
12:44:37 <wernervasquez[m]> Where if you enter a decoy password it decrypts the decoy wallet info from the same file that contains the real wallet.
12:45:17 <wernervasquez[m]> It is source available and discontinued. But I believe it had a pretty sterling record testified by court cases. Could be worth a look.
12:48:41 <moneromooo> In any case, placing a decoy wallet right near the real one is a bad idea, *unless* the existence of that particular wallet is known already. Te closer they are, the more likely it is for hte real wallet to be found or suspected, which defeats the purpose.
12:49:20 <moneromooo> If you have to do this, an offset is much simpler, cleaner, and safer.
12:50:28 <wernervasquez[m]> moneromooo: If you have an offset, wouldnt the wallet have that data stored somewhere once it was synced?
12:52:38 <moneromooo> Hmm. I suppose it might not be wiped from memory, but it won't be stored anywhere on disk (beyond swap if unlucky).
12:53:15 <r4v3r23[m]> <wernervasquez[m]> "r4v3r23: regarding a decoy..." <- im talking in a hypothetical robbery/shakedown
12:54:13 <r4v3r23[m]> i know there are better way to store funds, and the best security is not having them on you in the first place
12:54:35 <wernervasquez[m]> moneromooo: doesnt the  wallet store known transations when it syncs?
12:54:55 <r4v3r23[m]> it was more of a technical question, if the wallet could support more than 1 password that would open specific accounts within the same wallet
12:56:19 <moneromooo> It does. You're not expected to save the cache when using an offset as a hidden wallet though.
12:57:31 <moneromooo> Whereas if you had a one-password-per-account patch and were to save the cache for the main wallet, your secret stuff would be included.
12:57:34 <r4v3r23[m]> moneromooo: by hidden wallet you mean the second seed thats generated when adding a passphrase?
12:57:45 <moneromooo> The one you don't want known by others.
12:58:08 <moneromooo> And yes.
12:58:59 <r4v3r23[m]> moneromooo: that doesnt really help in a situation where youre being forced to open your wallet. its more about saving the seed in a safer way in case some one else finds it
12:59:08 <wernervasquez[m]> moneromooo: can you clarify what is in the cache?
12:59:09 <HenryHollingwort> can't you just achieve that by storing N wallets in a single file (concat w/ boundary) then the wallet program makes it look like those are 1 thing but underneath it is N wallets... ultimately that is what you'd be doing anyway
13:00:02 <moneromooo> Many things. Block hashes. Which outputs you received. Record of received/sent txes. Address labels. Settings. Subaddresses.
13:00:40 <moneromooo> HenryHollingwort: you could, but it seems obvious if you look at file length, no ?
13:00:50 <wernervasquez[m]> moneromooo: what if you have an offline wallet?
13:01:08 <moneromooo> Refine this question.
13:01:13 <wernervasquez[m]> moneromooo: I think truecrypt solved that issue
13:03:21 <wernervasquez[m]> moneromooo: If you have an offline wallet, the data would likely be saved. Right? Unless the user is expected to recreate an offline wallet every time they use it?
13:03:35 <moneromooo> (mistake, settings are in the keys file actually, not the cache)
13:04:17 <moneromooo> I don't understand what you're saying here. Whether your wallet is offline or not does not affect whether a cache is saved.
13:05:09 <moneromooo> It affects some of the data in the cache (ie, if you mean cold/hot, only one of the pair will have stuff like tx secret keys).
13:05:16 <wernervasquez[m]> moneromooo: I am imagining the case where an average person of average means wants a decoy. Average joe doesnt want to recreate a wallet everytime they buy a pizza. So the transaction history is going to be saved to disk by the average user for their daily wallet.
13:07:17 <moneromooo> If the question is "is my statement correct", then yes. I agree with it.
13:09:21 <moneromooo> To be clear, I meant you do not save the cache to the *hidden* wallet, not the other one.
13:13:47 <r4v3r23[m]> moneromooo: how is an encrypted seed wallet hidden? if its loaded on your phone or computer, its obvious. and if you have the unencrypted "decoy" seed/wallet there too, the you've got 2 wallets that you can be forced to open
13:14:08 <r4v3r23[m]> the point of the decoy is giving the illusion that you are giving some one access to your wallet when you really arent
13:14:42 <moneromooo> Well, I was assuming you would not store them separately. If you do, then yes, it is not hidden.
13:15:22 <moneromooo> And if it is loaded when your phone/computer is taken, then it is not hidden.
13:15:52 <moneromooo> If you want to defend against *that*... you'd need a proximity beacon that auto kills the process when not in proximity.
13:16:10 <moneromooo> (and probably enables screen lock, etc)
13:17:08 <r4v3r23[m]> so you can see how multiple passwords per wallet would be useful in that situation
13:20:31 <moneromooo> I'll stop here since it's getting circular, but I never claimed it was not useful, just less useful and more dangerous than a seed offset.
13:21:26 <moneromooo> The one thing I can see going for it is a way to get an extra safety when spending from a "reserve" account.
13:22:05 <r4v3r23[m]> moneromooo: yes thats another use case. its just a way to seal off accounts from each other within the same wallet
15:08:58 <jwinterm> moneromooo: I switched and stagenet got stuck on like block 500k or so in the same way so we are just going to test on mainnet lol
15:38:59 <moneromooo> How much time did you wait after restart for the log you posted ?
15:39:15 <moneromooo> It might take a bit to find another peer.
15:39:44 <moneromooo> Alternatively, it's possible they're kicking you as you connect if you sent bad data.
15:40:27 <moneromooo> Though I'd expect bad data to be around the recent fork... I'll try to sync to see if anything goes wonky.
16:17:22 <rbrunner> Is there anything to prepare for the eventuality that we don't get the multisig fixes in #8149 into the hardfork release?
16:17:57 <rbrunner> I think if we apply the usual principles we can't merge that until a final review happens, as there were quite some changes after the reviews that happened
16:18:14 <rbrunner> And that review may not happen in time for the release, seems to me
16:19:03 <rbrunner> Does the "old" multisig signing code even continue to work after the hardfork, regardless of problems with potential vulnerabilities?
16:19:42 <moneromooo> AFAIK it would still work.
16:19:51 <rbrunner> And do we see that new "enable multisig experimental" covering the case that we just continue with the old code?
16:21:42 <UkoeHB> the existing code should be disabled
16:22:13 <UkoeHB> the patch should be marked experimental until/if there is enough confidence in it
16:23:02 <rbrunner> So only people able to use git and compile their own version of Monero would be able to do multisig?
16:23:08 <UkoeHB> correct
16:23:32 <rbrunner> Well, that's one way to solve the problem ...
17:00:27 <rbrunner> So, to "prepare for that eventuality", if we go down that route, this would mean at least a mini-PR that disables the current code
17:00:49 <rbrunner> For good, unlike that switch we recently merged
17:01:04 <UkoeHB> that's my opinion, yes
17:02:30 <rbrunner> Let's see whether we get people to chime in later and voice their opinion here. I am a bit disappointed we don't have somebody shouting bloody murder yet about that idea.
17:03:00 <rbrunner> I mean, a Monero release without working multisig, for maybe a month or two, until we have the first after-hardfork point release ...
17:36:30 <moneromooo> UkoeHB: the current code's just fine for M/N if at most N-1 are untrusted, right ?
17:36:58 <moneromooo> M-1
17:39:25 <UkoeHB> moneromooo: only if you only interact with trusted parties
17:40:14 <moneromooo> I asked for a blurb about this for enabling multisig. Not sure if I got that. Kinda forgot.
17:40:32 <moneromooo> Anyway, I think multisig should be enable-able by this setting even if 8149 doesn't get in.
17:40:55 <moneromooo> Otherwise, people who use multisig now are fucked, even if it's themselves only, from two machines or something.
17:41:47 <moneromooo> I suspect an exchange might be a typical user of multisig between itself and itself.
17:49:13 <rbrunner> Or maybe making an exception from our usual principles and merging 8149 even without final review would be evil, but the lesser evil than the old code
17:49:31 <rbrunner> Or no multisig at all for "normal" people for months
17:49:51 <moneromooo> set i-am-not-a-normal-person 1
17:50:00 <moneromooo> Multisig now enabled.
17:50:51 <ooo123ooo1234567> moneromooo: `set i-am-ready-to-loss-everything 1`
17:50:53 <ooo123ooo1234567> s/loss/lose/
17:52:19 <rbrunner> Well, the message for the `enable-multisig-experimental` switch more or less tells you that already ...
17:54:19 <rbrunner> ooo123ooo1234567, how about winning some karma points, reviewing UkoeHB's latest changes to 8149 and save the day?
17:54:41 <jeffro256[m]> > Or maybe making an exception from our usual principles and merging 8149 even without final review would be evil, but the lesser evil than the old code
17:54:41 <jeffro256[m]> Might be worse because then people think its an improvement and BAM new vulnerability 
17:55:17 <rbrunner> That's the trouble with lesser evils, often it's damned hard to decide which one is it
18:09:29 <jwinterm> moneromooo: maybe 5-10 min, not too long but not instant close either - anyway, mainnet syncs ok so just gonna sacrifice 0.05 xmr to gods of development
18:09:56 <jwinterm> fees cheap enough now it doesn't really cost anything 
18:16:14 <ooo123ooo1234567> <rbrunner> "ooo123ooo1234567, how about..." <- One of the reasons that prev researchers aren't here is that you all don't see difference between important and unimportant changes. I'm 100% sure even bigger number of karma points will be sent to the next scammer with beautiful stories, but without actual solutions.
18:16:38 <moneromooo> I started testnet on a new data dir. It took 9 minutes to find a peer. Just anecdata for sure.
18:18:33 <rbrunner> Is that a "No" stretched over 3 lines in my IRC window? It's a bit hard to parse.
18:19:05 <moneromooo> Which lines ? :S
18:19:36 <moneromooo> I was talking to jwinterm 
18:19:42 <moneromooo> Who was tlaking to me
18:20:24 <rbrunner> Well, I don't know whether you see ooo123ooo1234567's ... reaction ... to my idea of them giving final review to 8149.
18:20:43 <moneromooo> Oh. Ignore me then.
18:20:53 <selsta> what would the security risks be when `--zmq-pub` is by default set to `tcp://127.0.0.1:18083` ?
18:21:19 <hyc> set to localhost? should be none
18:21:24 <hyc> no risk, I mean
18:21:43 <selsta> ok, any downside?
18:21:45 <moneromooo> A lot more attack surface. Also depends on whether it implements the restricted RPC checks. If not, then you can possbibly start mining etc.
18:21:54 <hyc> it's not http, so browsers can't surreptitiously connect to it
18:22:32 <moneromooo> Oh. loopback. Nevermind.
18:22:57 <moneromooo> I agree with "not much" then.
18:24:02 <sech1> also, zmq-pub is not an RPC
18:24:12 <selsta> sech1: https://github.com/monero-project/monero-gui/pull/3936/files
18:24:19 <selsta> this feels hacky, but i don't know what the best solution here is
18:24:38 <sech1> zmq-pub only allows to subscribe to a few notifications, it's a read-only interface
18:24:42 <sech1> in monerod
18:24:42 <hyc> ah, zmq-pub just broadcasts
18:24:47 <sech1> zmq-rpc is an RPC
18:24:52 <sech1> but it's half-implemented
18:24:57 <sech1> or less than half
18:25:46 <hyc> so basically, no security impact. it's just relaying info that was already public on p2p
18:27:03 <moneromooo> That's just the notifications, without the requests ?
18:27:21 <moneromooo> Oh, you said it. Well, ignore me then -_-
18:46:49 <jwinterm> good to know re: 9 min
19:48:11 <arnuschky[m]> <rbrunner> "Let's see whether we get..." <- We are :) And the Haveno guys too, I assume
20:00:39 <arnuschky[m]> > Anyway, I think multisig should be enable-able by this setting even if 8149 doesn't get in.... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/d46ad4020f094327375a33b6e8ee132331a8f8d7)
20:01:13 <arnuschky[m]> s/be/me,/
20:11:49 <arnuschky[m]> UkoeHB: what are the unreviewed changes? AFAIK it's only https://github.com/monero-project/monero/pull/8149/commits/f5e33479d656bc95001d2f135651e9fe9194681a right?
20:12:45 <UkoeHB> arnuschky[m]: mainly that, plus a bunch of rebases and some code quality improvements
20:21:14 <arnuschky[m]> ah I see. I thought it was only that last commit, as the previous one was about moneromooo's suggested changes
20:22:56 <UkoeHB> arnuschky[m]: moneromooo did not do a full review, he just checked some stuff that got rolled back for a future PR
20:29:29 <arnuschky[m]> ok I see. kayabanerve's was complete, as well as vtnerd's but that one is very old. Is that correct?
20:34:04 <kayabanerve[m]> Mine was notable, yet focused on the cryptography. I have a complete review pending, only partially done, and have discussed it further over time with koe though 
20:35:07 <kayabanerve[m]> > <@arnuschky:matrix.org> > Anyway, I think multisig should be enable-able by this setting even if 8149 doesn't get in.... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/0fdf166fcd9d174614b410f022eb1d68719cd8bd)
20:37:42 <UkoeHB> kayabanerve[m]: I can squash any time
20:41:08 <kayabanerve[m]> Expected so