01:50:41 <selsta> hyc: monero-lws is a separate program from monerod
02:01:55 <selsta> now obviously monero-lws could have a vulnerabilities too but it's a smaller attack vector compared to the full daemon and you can configure it to only accept connections with a SSL cert
02:17:06 <gingeropolous> yeah, throwing your viewkey at some random remote node seems... odd.
02:24:04 <gingeropolous> nvm. seemed to have misread
04:28:57 <plowsof[m]> <hyc> "I just tried it out a few..." <- hyc: binaryFate_ binaryFate 
04:32:00 <plowsof[m]> <hyc> "I just tried it out a few..." <- Thank you for confirming! My K I S S proof of concept works then... Download the view only file with rsync (passwordless ssh login) to your device with the spend keys.. my poc uses monerujo and termux for rsync on android https://github.com/plowsof/monero-wallet-rsync
04:58:19 <luigi1111w> .merges
04:58:19 -xmr-pr- 8055 8056 8065 8070 8071 8072 8075 8083 8084 8085
05:49:29 <luigi1111w> .merges
05:49:29 <xmr-pr> Merge queue empty
06:42:40 <moneromooo> That seems very complicated. AFAICT this can be done by adding a "not decoded yet" flag to outputs (if it's not already there), and when the wallet sees an incoming output, it doesn't ask for password to decode, it just stores the raw output and continues. A second pass comes later once the password is entered, to go through the new transfers and decode them.
06:43:04 <moneromooo> Unless there's another complication that needs another db ?
07:30:02 <hyc> nah, if you know a simpler way to do it, that's great
07:34:17 <hyc> uh can #7910 go into this release?
07:34:33 <hyc> it'll make it easier for people to do gitian builds
07:34:51 <hyc> #7977 is the r17 branch
15:08:40 <woodser[m]> is it possible to specify different unlock heights for individual outputs in a transaction?
15:10:23 <UkoeHB> woodser[m]: no, there is one unlock height for all outputs
16:38:25 <selsta> .merge+ 7910 7977
16:38:25 <xmr-pr> Added
17:31:36 <hyc> thanks selsta
17:43:38 <Rucknium[m]> I have a draft proposal, I suppose, about node-level enforcement of a simple decoy selection rule here, for consideration:
17:43:39 <Rucknium[m]> https://github.com/monero-project/meta/issues/630#issuecomment-980752098
17:48:50 <sech1> Searching for duplicates will either have to scan through all previous rings (slow), or store some hash per ring and look up that hash in O(1) time (bloat)
17:52:01 <Rucknium[m]> sech1: Are you saying it cannot/won't be done? What about scanning recent transactions, like in the past two weeks?
17:53:14 <Rucknium[m]> As of now, in effect, the ring size enforcement that we (or at least I) thought had been done is not being done. The transactions that isthmus and neptune found have effective ring size of one.
17:54:28 <Rucknium[m]> Are we going to let this slide or are we going to figure out how to fix it?
17:57:51 <ErCiccione> Better bring it up also at tomorrow's meeting. To make sure the issue has as much attention as possible
17:59:13 <sech1> It can be done at the cost of 32 bytes per ring, maybe 8 bytes per ring will be enough if we declare hash collisions effectively "same rings" for this check
17:59:15 <Rucknium[m]> I intend to. I wanted to bring it up prior to the meeting so that people have time to think about it.
17:59:45 <sech1> how many rings are in Monero blockchain today? Probably more than transactions, around ~100 million I guess?
18:00:01 <sech1> so 8 bytes should be enough
18:00:29 <sech1> even if there's an occasional hash collision once in a year, wallet would just create another ring
18:01:31 <Rucknium[m]> Isn't it a little more complicated than that, since we need to check if M-1 ring members are identical, not just the full set of size M? Maybe I don't fully understand your proposal, sech1 
18:02:16 <Rucknium[m]> sech1: Right. Re-rolling the dice for new ring members would not be a big deal.
18:02:50 <sech1> M-1/M match checking is worse in terms of storage
18:03:30 <sech1> and it will probably require 16 bytes hashes
18:04:59 <sech1> and what prevents whoever created these tx to adjust their selection to circumvent this check?
18:06:58 <Rucknium[m]> I don't know. Enforcement of a ring member selection algorithm is still in the very early stages of research.
18:08:18 <sech1> 100K rings with size 1 out of 100M total rings is not even a blip on a radar. It's better to concentrate on a consensus ring selection rules
18:08:48 <sech1> any partial workarounds don't prevent malicious ring construction
18:09:10 <sech1> well, it is a blip on a radar considering it was noticed and being discussed :D
18:09:42 <Rucknium[m]> Is this malicious or just services being lazy?
18:10:14 <sech1> maybe just a bug
19:28:26 <IanNiculescu[m]> how do you guys generate wallets client side, because i'm trying to use a java library to do this but the instructions are way above my head.
19:33:24 <moneromooo> "monero-wallet-cli". It will ask you whether to create one and ask for a name. Easiest there is.
19:34:03 <moneromooo> monero-wallet-cli --testnet if you're testing on testnet, similar for stagenet.
19:49:26 <IanNiculescu[m]> I mean being able to generate like 1000 wallets, and the CLI uses the daemon to make a remote procedure call from what i read, does it means that the wallet mnemonic seed is not generated locally ?
19:54:06 <moneromooo> Then you want RPC. The daemon is used to get current height, so setup the wallet to scan only what's needed. The seed is not sent to the daemon.
20:00:50 <IanNiculescu[m]> ok thank you for the support
20:01:58 <moneromooo> Also, you can look at tests/functional_tests, this creates wallets using RPC.
20:04:26 <IanNiculescu[m]> where can you give me a link
20:05:57 <moneromooo> It's from the root of the monero tree.
20:11:53 <IanNiculescu[m]> ah ok thank you
20:53:45 <tevador> github down?
20:59:00 <selsta> seems so githubstatus.com
20:59:27 <sech1> down for me
21:20:29 <jimmyt[m]> Down for me as well
21:21:52 <js> Well, why would it matter that GitHub is down? Git is decentral! 😉
21:22:10 <Canadiantaku[m]> heh
21:30:58 <dEBRUYNE> tevador: How much work has to be done to plug your seed scheme into simplewallet.cpp?
21:53:51 <tevador> dEBRUYNE: first it needs to be implemented in wallet2 and it requires some changes in account_keys, which seems to be the best place to put the seed since it's equivalent to a private key
22:15:53 <BusyBoredom[m]> Does anyone know if p2pool has an http api I can use to determine whether a p2pool node is syncing? I see there's a stratum server API that gives hashrate and a few other numbers, but that's not really what I'm looking for.
22:19:07 <tevador> BusyBoredom[m]: #monero-pools or #p2pool-log
22:21:16 <BusyBoredom[m]> Ah nice, thank you
23:14:59 <IanNiculescu[m]> woodser: hello my friend