jwinterm: looks like you never got any blocks from a peer just yet.

.merges

when 0.18 release?

still on track for June 16th?

ledger will be the problem

is anyone in contact with them?

i'm in their discord but i don't have any info myself

they said "ok" over a month ago and then nothing

They still have until July 16th to update their stuff

v0.18.1 (day 1 patch, lol) can have proper ledger support

yes, that's the plan but i would like some confirmation that someone is working on it

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.

yea, GUI won't be a problem, main issue I'm currently seeing is Ledger

Last time it took them 1 month to release a simple version bump with 0 changes

both previous employees that were responsible for monero either quit or moved to a different position

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

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

No.

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.

Well, that's one reason at least.

ok, thanks

<r4v3r23[m]> "is there a way to set a password..." <- would this be at all possible to add in the wallet current structure?

s/wallet/wallets/

Passwords for what ?

for specific accounts within the wallet

so different accounts would open up depending on what password you enter

It seems possible. Not worth the bother though, unless you can come up with a good reason.

decoy wallets is the first use case that comes to mind

For sending, at lesat. For receiving, it seems not too easy.

What is a decoy wallet ?

also a way to separate funds within the wallet without having to have different seeds

You can do that currently. It does not require passwords.

moneromooo: a wallet that has a minimal amount of money that would be used in case you are ever forced to open your wallet

Why would you ever want to do that in the same wallet ?

moneromooo: yes, but all accounts are visible once the wallet is opened

moneromooo: well the password would only open account #2 for example, with 0.1234 XMR in it

I assume you'd want it so you cannot tell if an account is "open" or not, then, right ? Otherwise it's self defeating.

basically, main wallet password = opens main wallet with access to all accounts

then account specific password = only open that account without seeing the rest of the wallets funds

What you are asking for is:

so, a wallet within a wallet

- much more dangerous (bug wise and info leak wise) than just using a seed offset

why is it more dangerous?

- 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

- not worth the work

It is more dangerous because it requires adding a non trivial amount of code, which has to be all correct (or mostly correct).

ok, is it possible today for a wallet dev to implement that, or would that require change to the monero wallet code?

It is possible for wallet dev to implement that, and it would require cahnges to the monero wallet code.

ok, thanks for the indo

s/indo/info/

r4v3r23: regarding a decoy wallet, I have thought the truecrypt hidden volume method would be the way to go

Where if you enter a decoy password it decrypts the decoy wallet info from the same file that contains the real wallet.

It is source available and discontinued. But I believe it had a pretty sterling record testified by court cases. Could be worth a look.

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.

If you have to do this, an offset is much simpler, cleaner, and safer.

moneromooo: If you have an offset, wouldnt the wallet have that data stored somewhere once it was synced?

Hmm. I suppose it might not be wiped from memory, but it won't be stored anywhere on disk (beyond swap if unlucky).

<wernervasquez[m]> "r4v3r23: regarding a decoy..." <- im talking in a hypothetical robbery/shakedown

i know there are better way to store funds, and the best security is not having them on you in the first place

moneromooo: doesnt the wallet store known transations when it syncs?

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

It does. You're not expected to save the cache when using an offset as a hidden wallet though.

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.

moneromooo: by hidden wallet you mean the second seed thats generated when adding a passphrase?

The one you don't want known by others.

And yes.

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

moneromooo: can you clarify what is in the cache?

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

Many things. Block hashes. Which outputs you received. Record of received/sent txes. Address labels. Settings. Subaddresses.

HenryHollingwort: you could, but it seems obvious if you look at file length, no ?

moneromooo: what if you have an offline wallet?

Refine this question.

moneromooo: I think truecrypt solved that issue

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?

(mistake, settings are in the keys file actually, not the cache)

I don't understand what you're saying here. Whether your wallet is offline or not does not affect whether a cache is saved.

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).

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.

If the question is "is my statement correct", then yes. I agree with it.

To be clear, I meant you do not save the cache to the *hidden* wallet, not the other one.

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

the point of the decoy is giving the illusion that you are giving some one access to your wallet when you really arent

Well, I was assuming you would not store them separately. If you do, then yes, it is not hidden.

And if it is loaded when your phone/computer is taken, then it is not hidden.

If you want to defend against *that*... you'd need a proximity beacon that auto kills the process when not in proximity.

(and probably enables screen lock, etc)

so you can see how multiple passwords per wallet would be useful in that situation

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.

The one thing I can see going for it is a way to get an extra safety when spending from a "reserve" account.

moneromooo: yes thats another use case. its just a way to seal off accounts from each other within the same wallet

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

How much time did you wait after restart for the log you posted ?

It might take a bit to find another peer.

Alternatively, it's possible they're kicking you as you connect if you sent bad data.

Though I'd expect bad data to be around the recent fork... I'll try to sync to see if anything goes wonky.

Is there anything to prepare for the eventuality that we don't get the multisig fixes in #8149 into the hardfork release?

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

And that review may not happen in time for the release, seems to me

Does the "old" multisig signing code even continue to work after the hardfork, regardless of problems with potential vulnerabilities?

AFAIK it would still work.

And do we see that new "enable multisig experimental" covering the case that we just continue with the old code?

the existing code should be disabled

the patch should be marked experimental until/if there is enough confidence in it

So only people able to use git and compile their own version of Monero would be able to do multisig?

correct

Well, that's one way to solve the problem ...

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

For good, unlike that switch we recently merged

that's my opinion, yes

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.

I mean, a Monero release without working multisig, for maybe a month or two, until we have the first after-hardfork point release ...

UkoeHB: the current code's just fine for M/N if at most N-1 are untrusted, right ?

M-1

moneromooo: only if you only interact with trusted parties

I asked for a blurb about this for enabling multisig. Not sure if I got that. Kinda forgot.

Anyway, I think multisig should be enable-able by this setting even if 8149 doesn't get in.

Otherwise, people who use multisig now are fucked, even if it's themselves only, from two machines or something.

I suspect an exchange might be a typical user of multisig between itself and itself.

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

Or no multisig at all for "normal" people for months

set i-am-not-a-normal-person 1

Multisig now enabled.

moneromooo: `set i-am-ready-to-loss-everything 1`

s/loss/lose/

Well, the message for the `enable-multisig-experimental` switch more or less tells you that already ...

ooo123ooo1234567, how about winning some karma points, reviewing UkoeHB's latest changes to 8149 and save the day?

> 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

Might be worse because then people think its an improvement and BAM new vulnerability

That's the trouble with lesser evils, often it's damned hard to decide which one is it

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

fees cheap enough now it doesn't really cost anything

<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.

I started testnet on a new data dir. It took 9 minutes to find a peer. Just anecdata for sure.

Is that a "No" stretched over 3 lines in my IRC window? It's a bit hard to parse.

Which lines ? :S

I was talking to jwinterm

Who was tlaking to me

Well, I don't know whether you see ooo123ooo1234567's ... reaction ... to my idea of them giving final review to 8149.

Oh. Ignore me then.

what would the security risks be when `--zmq-pub` is by default set to `tcp://127.0.0.1:18083` ?

set to localhost? should be none

no risk, I mean

ok, any downside?

A lot more attack surface. Also depends on whether it implements the restricted RPC checks. If not, then you can possbibly start mining etc.

it's not http, so browsers can't surreptitiously connect to it

Oh. loopback. Nevermind.

I agree with "not much" then.

also, zmq-pub is not an RPC

sech1: monero-project/monero-gui #3936/files

this feels hacky, but i don't know what the best solution here is

zmq-pub only allows to subscribe to a few notifications, it's a read-only interface

in monerod

ah, zmq-pub just broadcasts

zmq-rpc is an RPC

but it's half-implemented

or less than half

so basically, no security impact. it's just relaying info that was already public on p2p

That's just the notifications, without the requests ?

Oh, you said it. Well, ignore me then -_-

good to know re: 9 min

<rbrunner> "Let's see whether we get..." <- We are :) And the Haveno guys too, I assume

> Anyway, I think multisig should be enable-able by this setting even if 8149 doesn't get in.... (full message at libera.ems.host/_matrix/media/r0/do…4020f094327375a33b6e8ee132331a8f8d7)

s/be/me,/

UkoeHB: what are the unreviewed changes? AFAIK it's only monero-project/monero #8149/commits/f5e33479d656bc95001d2f135651e9fe9194681a right?

arnuschky[m]: mainly that, plus a bunch of rebases and some code quality improvements

ah I see. I thought it was only that last commit, as the previous one was about moneromooo's suggested changes

arnuschky[m]: moneromooo did not do a full review, he just checked some stuff that got rolled back for a future PR

ok I see. kayabanerve's was complete, as well as vtnerd's but that one is very old. Is that correct?

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

> <@arnuschky:matrix.org> > Anyway, I think multisig should be enable-able by this setting even if 8149 doesn't get in.... (full message at libera.ems.host/_matrix/media/r0/do…66fcd9d174614b410f022eb1d68719cd8bd)

kayabanerve[m]: I can squash any time

Expected so