is openalias still a thing? ie do people use it etc, is it worth considering for new projects

the copyright line in the official site says 2014-2015 .. if it's still used, could use some updating :p

copyright statements should only be updated when some content changes. I doubt the openalias spec has needed any changes in recent years.

^ kayront

is there a bug in the /getinfo rpc endpoint? the incoming connections count seems to display 0 at all times.

Are you running with restricted RPC ?

ah, yeah. that's probably it.

moneromooo: ok that makes a lot of sense actually. is there a way for me to get information like that while keeping the rpc restricted?

Change the code in core_rpc_server.cpp.

You can also run servers on two different ports, one restricted and one not. See --help for options.

I mean, two RPC servers from the same process.

oh that's great. now i feel a bit silly for not checking first. yeah, that's exactly what i want so i can just block it from public on network level but still get the statistics, great! thanks :)

another thing i was wondering is that are there plans to enable mining for rpc payments by default in cli/gui wallet if the node requires payment? i looked around the gui wallet and i didn't even see an option for that.

There's a setting in monero-wallet-cli for a credits/second threshold where it'll auto mine if the node gives more. Off by default. No support in the GUI.

(AFAIK)

yeah that's what i figured aswell.

moneromooo: might be a good idea to also allow binding restricted rpc to different ip aswel

I'd OK such a patch.

Not sure how intrusive it'd be off the top of my head.

Meeting in ten minutes?

hyc: fair enough, though it gives the impression that the site is abandoned too. so I take it that it's still a thing?

been reading about the mms, seems legit, but i can't find any wallet rpc calls for it?

yes OpenAlias is still a thing the spec just didn’t need any updates

kayront: Well, there aren't. Check the history of this here: monero-project/monero #6180 especially my closing comment

There are RPC calls in a github patch. But given it's a user friendliness layer over it, RPC doesn't make much sense.

got it selsta. and from an implementation standpoint, does monero-wallet-rpc end up receiving the address in the end, or does it resolve the openalias address itself?

Except maybe for hte bitmessage part, but it doesn't really belong in monero-wallet-cli really. Shrug.

Shrug indeed :)

btw, when printing accounts in simplewallet, it'll say Tag's description: <blank> when there is no description, could that line be omitted perhaps when there is no description?

will read rbrunner

rbrunner: " I am the first one to admit that this not a good solution, but I did not find a better alternative so far." --> curious, why is bitmessage not a good solution?

Basically, because third-party. One more moving part, one more thing that can have bugs that we would not have control over, one more thing to install and babysit, along those lines

Technically, it works wonderfully. Especially, imagine, message with *zero* meta info left.

well, I agree it would be ideal if somehow the functionality could be native

We can wish it into existence :)

but seems the mms is designed to account for future alternatives anyway

Yes, more or less

We wanna do a quick check up meeting? :)

i2p-zero would probably be a good starting point, but also probably itself not yet the complete solution

i'm still reading the comments, but I think I get the idea. maybe it doesn't belong in the api, it should be possible to make a lib around the idea that ends up calling the wallet_rpc multisig methods instead, right?

I, unfortunately, haven't gotten to putting up that meta discussion. I was working on the latest Revuo periodical issue, which got released yesterday.

Yeah, much is possible

very cool

not sure if there is much to talk about rehrar

aight, no biggie

are the meetings here usually?

Yes, a long time ago ... :)

There were

there are still meetings before hardforks :D

Now everything running so smoothly, nobody has to put any fires out

Well, maybe we could speak about a concerted effort to really test Dandelion++ on testnet

with more nodes than today

I am speaking about this here: monero-project/monero #6314

and we can maybe talk about how to advance with monero-project/supercop #3

supercop?

lol

Yeah, some more vtnerd programming wizardry

but don’t know who can review ASM

Way over my head to review. Maybe recruit some, er, guy from uk?

Last time I looked, it seemed ok. Mostly adding bases in insns. A lot of them though.

maybe you can add a comment mooo?

last time this supercop thing got stuck for over a year

Oh wait, not the same I saw.

Maybe monermooo can make normal ops slower, to introduce artificial pressure for a speedup, to make people cry for supercop

Ah, it was PR 2, which is now merged. I'll look at 3... at some indeterminate time in the future.

ok coo

cool :D

I wonder anyway how to really test that Dandelion++. I did not see an easy way to have it log what it does. Maybe I overlooked something.

not to interrupt, but just throwing it out there, I was going to write about it on github soon™ but since I appear to have crashed right into a dev meeting.. who else thinks it would be cool to add 2FA support to monero-wallet-cli ? i'm playing around with the api and it's very cool to be able to spend moneroj with a single command, but that could potentially be very dangerous too, imagine for example a backend server that was compromised.

. now it doesn't matter that it's using a fancy password and SSL to talk to monero-wallet-rpc (on another server, presumably), moneroj gonna be running

E.g. a log message when a daemon does not broadcast a tx but pass it on, dandelion style.

seems to me that adding that optional support in monero-wallet-rpc itself could improve security a lot, because then (barring some catastrophic bug with wallet-rpc itself) the end user, rather than just the server contacting the api, has to participate to spend

spend/sign

I think it makes sense to add it to monero-wallet-rpc, optionally (ie, a setting in the wallet keys file).

sorry, yes, I meant monero-wallet-rpc in the beginning

For monero-wallet-cli, it doesn't really.

If it was easier probably a case for multisig, or do I misunderstand? As many "factors" as you want

AIUI, it's to guard against the user desktop/phone being pwned, but it not running monero-wallet-rpc itself, but connecting to one running a (presumably secure) server.

2fa like in github (& elsewhere), t/otp I believe it's called

indeed

So useless if the monero-wallet-rpc user is some merchant website, but useful for light wallet type users.

So, simplified, double-login into the RPC server?

We do not have light wallets using monero-wallet-rpc though I think :)

Yet.

Yes, you can see it like that.

rbrunner, imagine there is some nice software that lets you run a mini monero bank (for example) .. your family creates accounts there

users -> server -> monero-wallet-rpc

the server has the wallets

server gets pwned -> all moneros fly away

if monero-wallet-rpc verified something that the users themselves own (a 2fa token), then no problem, unless big bug in monero-wallet-rpc, in which case probably all bets are off anyway

Hmm, looks like another scenario. Moo was talking about users getting pwned ...

Or maybe not

Server gets pwned == monero fly away with or without 2fa.

here server and monero-wallet-rpc are two different servers

The light client being pwned is what this defends against.

but yes, I guess you are right, because the server could sneakily modify the transfer parameters too

so it guards against the user being owned

that's what you meant right? interesting angle I hadn't considered

Yes.

Maybe depends whether there is any way for the user's system to connect directly to monero-wallet-rpc as well, bypassing the server

it would be a basic security precaution to firewall monero-wallet-rpc off to only the server

Wait, there are three computers now ?

(omitting eve)

they're all happy vms, let's say

minus the user, presumably

:D

Containers, not vms.

rbrunner: does all this mm stuff work with hardware wallets?

one less seed to memorize is always a good thing

if possible

Not sure. Don't have one, never tried. Not even sure hardware wallets support basic / non-MMS Monero multisig. I somehow doubt it.

also, it wasn't clear (could've missed it) from the docs, are tx notes, account labels, address labels etc, synchronized also? less of a mms question and more about what export_multisig_info exports I suppose

No, the MMS cares only about the info about the signers

Don't think anybody syncs labels. It would surprise to find that info in the exported multisig info

How long would it take an average computer to verify just PoW on all the blocks?

~ $((2.4e6 / hash rate)) seconds.

Or am I missing something ?

(the 2.4 is to overstimate the number of blocks since monerod is a bit less fast than a pool miner I think)

Less than an hour? Seems too fast, thought someone mentioned it would take longer

it's more complicated than that because there are 5 algorithms with different hashrates, and RandomX needs to reinitialize every 2048 blocks

Ah forgot about this, it'll be less than than then since random x is faster now.

Someone claims to have created an integrated address out of a subaddress: monero-project/monero-gui #2633

It was deemed not not useful enough. That won't get merged.

right but they used some website to create the integrated address and now the funds are lost?

o_O

Who uses some random site to create their addresses...

He'll be lucky it it wasn't some phishing site.

There's a fair chance the monero is retrievable. Someone comfortable with hte crypto will know.

maybe luigi1111 can take a look

I am amazed the lengths people go to do something wrong.

why would the funds be lost?

or did he use an integrated tag but subaddress keys?

They entered an subaddress here: dustinlemos.com/integrated-address-demo and send funds to the resulting address.

(if I understand the issue correctly)

It's possible he just needs to get the subaddy spend private key, turn it into a normal address seed, then scan with that

Oh he's just saying the GUI doesn't work

explain?

I thought the funds were lost

like I said maybe I didn’t understand the issue

> So to start off, when I go into the wallet-cli it will show an incorrect balance because that xmr transaction is not included

so it does not look like a GUI issue

Ah my brain is fuzzy. It would help if the tx id was there

Subaddresses and standard addresses use a different crypto scheme.

So the address was created by some website that does whatever with the address (assuming it doesn't substitute its own address). And it the tx was likely sent by custom software since monero doesn't support integrated subaddresses. I'll check htat last part though, it might parse them...

No, it won't parse one that's both.

`843W5VwRvu9gpLvoWFCSj2ihp4KstjFLn89y6QUHfVS13iuRuQz6m65SvU1sjZ2MJXayyXJzEuKUgM65mZkmTxeTDMgVUyc` results in `4Cv2kw75wkFgpLvoWFCSj2ihp4KstjFLn89y6QUHfVS13iuRuQz6m65SvU1sjZ2MJXayyXJzEuKUgM65mZkmTxeTKF38eY1mMG9HBF7dyk` on this website.

I suppose it the site was honest, it might have generated integrated "standard".

Then stock monero can parse that and sends as a normal address.

That looks similar. So I guess it's not a phishing site :D

it claims to use luigi’s code

ok looks like it's pretending the subaddress is a normal address

can you generate a wallet out of private view and spend keys?

Yes. --generate-from-keys IIRC. Or from json.

he uses Ledger which makes things more complicated

Not sure you can get a subaddress keys without changing the source though.

if he knows the basic view and spend keys he can calculate the subaddy keys

oh maybe I should check that

easily recoverable though

oh wait I don't have anything to convert addresses like that

anyway just need his subaddy index and regular private keys to recover

hi, trying to trace out the 'ordering' of outputs from a multisig tx. In a normal tx it is randomized when shuffle() gets called in construct_tx_with_tx_key(), but there is a flag 'shuffle_outs' that *sometimes* gets activated for multisig, and I THINK *sometimes* is not activated. In transfer_selected_rct() there is a construct_tx_and_get_tx_key() that is always called the same way (multisig or not), so shuffle()

definitely gets used. Then, there is a section of 'bonus' multisig tx that are created when the available signers are more than the minimum necessary (each sub-group is given a tx to sign, to increase the chances of a tx succeeding). In that bonus section construct_tx_with_tx_key() is called for each bonus tx, but this time 'shuffle_outs' == false. SO, my question is, when 'destinations' are passed to the original

construct_tx_and_get_tx_key(), and shuffled, is this a 'pass by reference' so the base array gets shuffled, and then that shuffled array makes its way into the bonus tx, ensuring that all multisig tx have a shuffled output list?

I don't know what a bonus tx is, but the party making the tx shuffles. Others don't.

(since they have to sign the same one)

the section after 'std::vector<tools::wallet2::multisig_sig> multisig_sigs;'

does splitted_dsts 'save' the shuffle, so those other tx get the shuffled list?

IIRC yes

ok good news! despite the code complexity it really has few if any fundamental problems, which is quite amazing

splitted_dsts seems to be saved in the constuction_data after back from construct_tx_.

well I think as long as it's passed by reference then 'shuffle' actually affects the original array