03:47:29 <jtgrassie> xmrpow: yes
13:31:59 <rbrunner> I think I remember from the dev meeting that an issue about naming the new release should go up. Will this be here? https://github.com/monero-project/meta/issues
13:48:12 <selsta> Nitrogen... ?
13:50:33 <moneromooo> Nitwit
14:01:04 <hyc> nitrogen nebula?
14:13:23 <rbrunner> Nitrogen Nemesis, after the asteroid: https://en.wikipedia.org/wiki/128_Nemesis    We will revenge any attempt to deanonymize :)
14:17:01 <selsta> Will make a meta issue later
14:17:07 <rbrunner> Alright :)
14:45:59 <binaryFate> when opening a wallet and entering wrong password, wasn't it before saying "wrong password"? Maybe I misremember
14:46:48 <binaryFate> now it's "Error: failed to load wallet: std::exception"
14:47:46 <selsta> binaryFate: fixed in latest master
14:47:58 <binaryFate> coolio :)
15:43:17 <azy> With a viewkey can I prove a integrated address/subaddr belongs to the associated public address? Preferably via an explorer or such a website
15:46:15 <rbrunner> Don't think so. The viewkey allows to see and decode incoming transactions. If you have no transaction to the subaddress you want to prove ownership off, I would say you are out of luck
15:46:46 <selsta> azy: integrated address can always be converted to normal address.
15:47:38 <selsta> without any view key
15:48:30 <azy> How so?
15:50:52 <selsta> type `integrated_address address` into CLI
16:01:45 <azy> Ty both
16:26:08 <dEBRUYNE> moneromooo: You mentioned testing dandelion++, how does one verify whether it is actually working properly?
16:33:46 <moneromooo> One could check logs (net.p2p.msg:INFO would do it) to check that txes go to one (or two ?) peers only if they're in stem phase.
16:34:11 <moneromooo> Send a tx, check it's received on another node not connected to the first one.
16:34:22 <moneromooo> vtnerd might have better ways.
16:35:14 <moneromooo> On the real network, a tx marked as stem will be seen as a normla tx, so you won't get long stem paths, most likely one hop from your node.
16:36:03 <moneromooo> Would be interesting also to modify a node to drop all dandelion txes, to check the first node hits the timeout and fluffs it.
16:37:31 <dEBRUYNE> Thanks
16:42:41 <sarang> moneromooo: the black hole attack?
16:42:48 <sarang> it would
16:44:56 <moneromooo> Context ?
16:53:26 <sarang> You mean simulating a malicious node that tries to block propagation by ignoring stems
16:53:42 <sarang> and ensuring that the transaction eventually gets fluffed despite this "black-hole" node
16:53:49 <sarang> (the paper calls this a black hole attack)
16:56:01 <moneromooo> Yes.
16:57:44 <sarang> roger
16:58:07 <sarang> Yes, that's an important test, since D++ is supposed to fall back to fluffing in the worst-case scenario
17:44:30 <fluffypony> fluffing ;)
18:04:39 <netrik182[m]> luigi1111w: when you have time, could you please take a look on ccs servers? The funding required page has not been updated since you merged my proposal
19:16:59 <rehrar> netrik182[m]: I left you a comment on your proposal.
19:17:17 <rehrar> Can you please remake your proposal. Something funky happened and it didn't work.
19:17:40 <rehrar> Please pay super attention to formatting and look at other proposals that got it correct. If you need help message me (on Matrix as I see you have it).
19:17:50 <rehrar> @rehrar:matrix.org
19:19:17 <netrik182[m]> Doing it right nowrehrar:
19:20:45 <rehrar> Epic. Thanks.
20:02:09 <fort3hlulz> Testing 0.16, the only weird thing is that monero-wallet-cli says this everytime you send to a normal 4* address: "NOTE: this transaction uses an encrypted payment ID: consider using subaddresses instead"
20:02:30 <fort3hlulz> I'm not specifying a payment ID, isn't that just the one that's added to all Tx now?
20:03:04 <moneromooo> That ought to have been fixed. Can you detail what you're doing exactly ?
20:03:30 <fort3hlulz> I noticed that message with most outputs when syncing wallet from 0, and then I get it everytime I send to my own normal address
20:03:39 <fort3hlulz> Let me grab exact command
20:04:35 <fort3hlulz> oops wallet autolocked, thats quick 0.0
20:04:40 <fort3hlulz> Lost the command history
20:04:45 <fort3hlulz> I'll retry what I think caused it before
20:05:49 <fort3hlulz> The message is displayed when the output I send from "sweep_all <default wallet address" is received by the wallet with the next block
20:08:03 <fort3hlulz> well, didn't happen this time
20:08:17 <fort3hlulz> Maybe I just had an input in the first sweep it didn't like?
20:08:22 <fort3hlulz> I'll keep trying to reproduce.
20:27:58 <fort3hlulz> moneromooo reproduced it.
20:28:10 <fort3hlulz> Sending using "donate 0.1" gives this output once the Tx confirms:
20:28:17 <fort3hlulz> NOTE: this transaction uses an encrypted payment ID: consider using subaddresses instead
20:28:39 <fort3hlulz> But it doesn't appear that the "donate" command actually specifies a payment ID (idk why it would)
20:36:20 <moneromooo> OK, I'll try to see/fix.
20:36:30 <fort3hlulz> Want me to open an issue for it?
20:38:00 <moneromooo> Might as well.
20:38:07 <fort3hlulz> Ok!
20:39:51 <moneromooo> Ah, it triggers on change.
20:40:06 <fort3hlulz> https://github.com/monero-project/monero/issues/6523
20:51:18 <fort3hlulz> Verified sending to another 4-addr with the same issue
20:55:12 <moneromooo> https://github.com/moneromooo-monero/bitmonero/commit/a90e9bf4cfed3e126751e0c6ec65deacda065d41 should fix it. Won't get built for a while, two VMs building atm.
20:57:22 <fort3hlulz> That's a quick turnaround 0.0
20:57:36 <fort3hlulz> Nice work, I'll rebuild with that later tonight
20:58:12 <moneromooo> Again, it's not even built yet.