07:25:43 <kayront> is openalias still a thing? ie do people use it etc, is it worth considering for new projects
07:26:23 <kayront> the copyright line in the official site says 2014-2015 .. if it's still used, could use some updating :p
12:06:46 <hyc> copyright statements should only be updated when some content changes. I doubt the openalias spec has needed any changes in recent years.
12:07:29 <hyc> ^ kayront
13:47:29 <plebsersoze> is there a bug in the /getinfo rpc endpoint? the incoming connections count seems to display 0 at all times.
13:48:58 <moneromooo> Are you running with restricted RPC ?
13:49:19 <plebsersoze> ah, yeah. that's probably it.
13:52:08 <plebsersoze> 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?
13:52:40 <moneromooo> Change the code in core_rpc_server.cpp.
13:53:18 <moneromooo> You can also run servers on two different ports, one restricted and one not. See --help for options.
13:53:58 <moneromooo> I mean, two RPC servers from the same process.
13:55:07 <plebsersoze> 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 :)
13:57:23 <plebsersoze> 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.
13:58:49 <moneromooo> 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.
13:59:13 <moneromooo> (AFAIK)
13:59:33 <plebsersoze> yeah that's what i figured aswell.
14:11:56 <plebsersoze> moneromooo: might be a good idea to also allow binding restricted rpc to different ip aswel
14:12:40 <moneromooo> I'd OK such a patch.
14:13:07 <moneromooo> Not sure how intrusive it'd be off the top of my head.
16:48:02 <rehrar> Meeting in ten minutes?
16:52:30 <kayront> hyc: fair enough, though it gives the impression that the site is abandoned too. so I take it that it's still a thing?
16:53:16 <kayront> been reading about the mms, seems legit, but i can't find any wallet rpc calls for it?
16:54:31 <selsta> yes OpenAlias is still a thing the spec just didn’t need any updates
16:55:09 <rbrunner> kayront: Well, there aren't. Check the history of this here: https://github.com/monero-project/monero/pull/6180 especially my closing comment
16:55:17 <moneromooo> There are RPC calls in a github patch. But given it's a user friendliness layer over it, RPC doesn't make much sense.
16:55:38 <kayront> 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?
16:55:44 <moneromooo> Except maybe for hte bitmessage part, but it doesn't really belong in monero-wallet-cli really. Shrug.
16:55:56 <rbrunner> Shrug indeed :)
16:56:33 <kayront> 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?
16:56:38 <kayront> will read rbrunner
16:58:56 <kayront> 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?
16:59:41 <rbrunner> 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
17:00:26 <rbrunner> Technically, it works wonderfully. Especially, imagine, message with *zero* meta info left.
17:00:37 <kayront> well, I agree it would be ideal if somehow the functionality could be native
17:00:54 <rbrunner> We can wish it into existence :)
17:00:54 <kayront> but seems the mms is designed to account for future alternatives anyway
17:01:02 <rbrunner> Yes, more or less
17:02:24 <rehrar> We wanna do a quick check up meeting? :)
17:02:24 <rbrunner> i2p-zero would probably be a good starting point, but also probably itself not yet the complete solution
17:02:42 <kayront> 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?
17:02:59 <rehrar> I, unfortunately, haven't gotten to putting up that meta discussion. I was working on the latest Revuo periodical issue, which got released yesterday.
17:03:09 <rbrunner> Yeah, much is possible
17:03:16 <kayront> very cool
17:04:00 <selsta> not sure if there is much to talk about rehrar
17:04:05 <rehrar> aight, no biggie
17:04:58 <kayront> are the meetings here usually?
17:05:09 <rbrunner> Yes, a long time ago ... :)
17:05:18 <rbrunner> There were
17:05:29 <selsta> there are still meetings before hardforks :D
17:05:41 <rbrunner> Now everything running so smoothly, nobody has to put any fires out
17:06:14 <rbrunner> Well, maybe we could speak about a concerted effort to really test Dandelion++ on testnet
17:06:24 <rbrunner> with more nodes than today
17:07:19 <rbrunner> I am speaking about this here: https://github.com/monero-project/monero/pull/6314
17:07:37 <selsta> and we can maybe talk about how to advance with https://github.com/monero-project/supercop/pull/3
17:07:49 <kayront> supercop?
17:07:50 <kayront> lol
17:07:53 * kayront runs
17:08:06 <rbrunner> Yeah, some more vtnerd programming wizardry
17:08:59 <selsta> but don’t know who can review ASM
17:09:25 <rbrunner> Way over my head to review. Maybe recruit some, er, guy from uk?
17:09:28 <moneromooo> Last time I looked, it seemed ok. Mostly adding bases in insns. A lot of them though.
17:09:56 <selsta> maybe you can add a comment mooo?
17:10:07 <selsta> last time this supercop thing got stuck for over a year
17:10:23 <moneromooo> Oh wait, not the same I saw.
17:10:53 <rbrunner> Maybe monermooo can make normal ops slower, to introduce artificial pressure for a speedup, to make people cry for supercop
17:11:07 <moneromooo> Ah, it was PR 2, which is now merged. I'll look at 3... at some indeterminate time in the future.
17:11:23 <selsta> ok coo
17:11:26 <selsta> cool :D
17:12:32 <rbrunner> 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.
17:13:35 <kayront> 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.
17:13:35 <kayront> . 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
17:13:39 <rbrunner> E.g. a log message when a daemon does not broadcast a tx but pass it on, dandelion style.
17:14:35 <kayront> 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
17:15:38 <kayront> spend/sign
17:15:40 <moneromooo> I think it makes sense to add it to monero-wallet-rpc, optionally (ie, a setting in the wallet keys file).
17:16:04 <kayront> sorry, yes, I meant monero-wallet-rpc in the beginning
17:16:05 <moneromooo> For monero-wallet-cli, it doesn't really.
17:16:45 <rbrunner> If it was easier probably a case for multisig, or do I misunderstand? As many "factors" as you want
17:18:30 <moneromooo> 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.
17:18:36 <kayront> 2fa like in github (& elsewhere), t/otp I believe it's called
17:18:47 <kayront> indeed
17:19:13 <moneromooo> So useless if the monero-wallet-rpc user is some merchant website, but useful for light wallet type users.
17:19:27 <rbrunner> So, simplified, double-login into the RPC server?
17:19:34 <moneromooo> We do not have light wallets using monero-wallet-rpc though I think :)
17:19:38 <moneromooo> Yet.
17:19:53 <moneromooo> Yes, you can see it like that.
17:20:07 <kayront> rbrunner, imagine there is some nice software that lets you run a mini monero bank (for example) .. your family creates accounts there
17:20:13 <kayront> users -> server -> monero-wallet-rpc
17:20:19 <kayront> the server has the wallets
17:20:26 <kayront> server gets pwned -> all moneros fly away
17:20:51 <kayront> 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
17:21:08 <rbrunner> Hmm, looks like another scenario. Moo was talking about users getting pwned ...
17:21:25 <rbrunner> Or maybe not
17:21:26 <moneromooo> Server gets pwned == monero fly away with or without 2fa.
17:21:40 <kayront> here server and monero-wallet-rpc are two different servers
17:21:40 <moneromooo> The light client being pwned is what this defends against.
17:22:07 <kayront> but yes, I guess you are right, because the server could sneakily modify the transfer parameters too
17:22:12 <kayront> so it guards against the user being owned
17:22:50 <kayront> that's what you meant right? interesting angle I hadn't considered
17:23:29 <moneromooo> Yes.
17:23:39 <rbrunner> Maybe depends whether there is any way for the user's system to connect directly to monero-wallet-rpc as well, bypassing the server
17:24:08 <kayront> it would be a basic security precaution to firewall monero-wallet-rpc off to only the server
17:24:08 <moneromooo> Wait, there are three computers now ?
17:24:29 <moneromooo> (omitting eve)
17:24:36 <kayront> they're all happy vms, let's say
17:24:50 <kayront> minus the user, presumably
17:24:50 * moneromooo doesn't care about details here
17:24:50 <kayront> :D
17:24:58 <rbrunner> Containers, not vms.
17:34:29 <kayront> rbrunner: does all this mm stuff work with hardware wallets?
17:34:38 <kayront> one less seed to memorize is always a good thing
17:34:41 <kayront> if possible
17:35:42 <rbrunner> Not sure. Don't have one, never tried. Not even sure hardware wallets support basic / non-MMS Monero multisig. I somehow doubt it.
17:35:57 <kayront> 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
17:36:21 <rbrunner> No, the MMS cares only about the info about the signers
17:37:02 <rbrunner> Don't think anybody syncs labels. It would surprise to find that info in the exported multisig info
18:53:14 <UkoeHB_> How long would it take an average computer to verify just PoW on all the blocks?
19:01:32 <moneromooo> ~ $((2.4e6 / hash rate)) seconds.
19:02:00 <moneromooo> Or am I missing something ?
19:02:30 <moneromooo> (the 2.4 is to overstimate the number of blocks since monerod is a bit less fast than a pool miner I think)
19:16:26 <UkoeHB_> Less than an hour? Seems too fast, thought someone mentioned it would take longer
19:17:01 <tevador> it's more complicated than that because there are 5 algorithms with different hashrates, and RandomX needs to reinitialize every 2048 blocks
19:26:23 <moneromooo> Ah forgot about this, it'll be less than than then since random x is faster now.
19:28:20 <selsta> Someone claims to have created an integrated address out of a subaddress: https://github.com/monero-project/monero-gui/issues/2633
19:29:11 <moneromooo> It was deemed not not useful enough. That won't get merged.
19:29:31 <selsta> right but they used some website to create the integrated address and now the funds are lost?
19:29:53 <moneromooo> o_O
19:29:55 * moneromooo looks
19:32:30 <moneromooo> Who uses some random site to create their addresses...
19:32:50 <moneromooo> He'll be lucky it it wasn't some phishing site.
19:33:35 <moneromooo> There's a fair chance the monero is retrievable. Someone comfortable with hte crypto will know.
19:33:58 <selsta> maybe luigi1111 can take a look
19:34:47 <moneromooo> I am amazed the lengths people go to do something wrong.
19:35:00 <luigi1111> why would the funds be lost?
19:35:14 <luigi1111> or did he use an integrated tag but subaddress keys?
19:35:59 <selsta> They entered an subaddress here: https://dustinlemos.com/integrated-address-demo/ and send funds to the resulting address.
19:36:21 <selsta> (if I understand the issue correctly)
19:39:36 <UkoeHB_> It's possible he just needs to get the subaddy spend private key, turn it into a normal address seed, then scan with that
19:42:15 <UkoeHB_> Oh he's just saying the GUI doesn't work
19:42:41 <selsta> explain?
19:42:52 <UkoeHB_> I thought the funds were lost
19:43:24 <selsta> like I said maybe I didn’t understand the issue
19:45:19 <selsta> > So to start off, when I go into the wallet-cli it will show an incorrect balance because that xmr transaction is not included
19:45:27 <selsta> so it does not look like a GUI issue
19:46:04 <UkoeHB_> Ah my brain is fuzzy. It would help if the tx id was there
19:46:08 <moneromooo> Subaddresses and standard addresses use a different crypto scheme.
19:47:44 <moneromooo> 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...
19:49:09 <moneromooo> No, it won't parse one that's both.
19:49:26 <selsta> `843W5VwRvu9gpLvoWFCSj2ihp4KstjFLn89y6QUHfVS13iuRuQz6m65SvU1sjZ2MJXayyXJzEuKUgM65mZkmTxeTDMgVUyc` results in `4Cv2kw75wkFgpLvoWFCSj2ihp4KstjFLn89y6QUHfVS13iuRuQz6m65SvU1sjZ2MJXayyXJzEuKUgM65mZkmTxeTKF38eY1mMG9HBF7dyk` on this website.
19:49:45 <moneromooo> I suppose it the site was honest, it might have generated integrated "standard".
19:50:00 <moneromooo> Then stock monero can parse that and sends as a normal address.
19:50:34 <moneromooo> That looks similar. So I guess it's not a phishing site :D
19:52:01 <selsta> it claims to use luigi’s code
20:02:34 <UkoeHB_> ok looks like it's pretending the subaddress is a normal address
20:03:10 <UkoeHB_> can you generate a wallet out of private view and spend keys?
20:09:08 <moneromooo> Yes. --generate-from-keys IIRC. Or from json.
20:09:28 <selsta> he uses Ledger which makes things more complicated
20:09:33 <moneromooo> Not sure you can get a subaddress keys without changing the source though.
20:09:59 <UkoeHB_> if he knows the basic view and spend keys he can calculate the subaddy keys
20:55:37 <luigi1111> oh maybe I should check that
20:56:03 <luigi1111> easily recoverable though
20:58:44 <luigi1111> oh wait I don't have anything to convert addresses like that
20:59:16 <luigi1111> anyway just need his subaddy index and regular private keys to recover
22:07:00 <UkoeHB_> 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()
22:07:00 <UkoeHB_> 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
22:07:00 <UkoeHB_> 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?
22:09:56 <moneromooo> I don't know what a bonus tx is, but the party making the tx shuffles. Others don't.
22:10:16 <moneromooo> (since they have to sign the same one)
22:10:31 <UkoeHB_> the section after 'std::vector<tools::wallet2::multisig_sig> multisig_sigs;'
22:12:11 <UkoeHB_> does splitted_dsts 'save' the shuffle, so those other tx get the shuffled list?
22:17:42 <moneromooo> IIRC yes
22:20:36 <UkoeHB_> ok good news! despite the code complexity it really has few if any fundamental problems, which is quite amazing
22:27:21 <moneromooo> splitted_dsts seems to be saved in the constuction_data after back from construct_tx_.
22:30:08 <UkoeHB_> well I think as long as it's passed by reference then 'shuffle' actually affects the original array