01:50:41 hyc: monero-lws is a separate program from monerod 02:01:55 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 yeah, throwing your viewkey at some random remote node seems... odd. 02:24:04 nvm. seemed to have misread 04:28:57 "I just tried it out a few..." <- hyc: binaryFate_ binaryFate 04:32:00 "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 .merges 04:58:19 -xmr-pr- 8055 8056 8065 8070 8071 8072 8075 8083 8084 8085 05:49:29 .merges 05:49:29 Merge queue empty 06:42:40 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 Unless there's another complication that needs another db ? 07:30:02 nah, if you know a simpler way to do it, that's great 07:34:17 uh can #7910 go into this release? 07:34:33 it'll make it easier for people to do gitian builds 07:34:51 #7977 is the r17 branch 15:08:40 is it possible to specify different unlock heights for individual outputs in a transaction? 15:10:23 woodser[m]: no, there is one unlock height for all outputs 16:38:25 .merge+ 7910 7977 16:38:25 Added 17:31:36 thanks selsta 17:43:38 I have a draft proposal, I suppose, about node-level enforcement of a simple decoy selection rule here, for consideration: 17:43:39 https://github.com/monero-project/meta/issues/630#issuecomment-980752098 17:48:50 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 sech1: Are you saying it cannot/won't be done? What about scanning recent transactions, like in the past two weeks? 17:53:14 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 Are we going to let this slide or are we going to figure out how to fix it? 17:57:51 Better bring it up also at tomorrow's meeting. To make sure the issue has as much attention as possible 17:59:13 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 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 how many rings are in Monero blockchain today? Probably more than transactions, around ~100 million I guess? 18:00:01 so 8 bytes should be enough 18:00:29 even if there's an occasional hash collision once in a year, wallet would just create another ring 18:01:31 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 sech1: Right. Re-rolling the dice for new ring members would not be a big deal. 18:02:50 M-1/M match checking is worse in terms of storage 18:03:30 and it will probably require 16 bytes hashes 18:04:59 and what prevents whoever created these tx to adjust their selection to circumvent this check? 18:06:58 I don't know. Enforcement of a ring member selection algorithm is still in the very early stages of research. 18:08:18 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 any partial workarounds don't prevent malicious ring construction 18:09:10 well, it is a blip on a radar considering it was noticed and being discussed :D 18:09:42 Is this malicious or just services being lazy? 18:10:14 maybe just a bug 19:28:26 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 "monero-wallet-cli". It will ask you whether to create one and ask for a name. Easiest there is. 19:34:03 monero-wallet-cli --testnet if you're testing on testnet, similar for stagenet. 19:49:26 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 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 ok thank you for the support 20:01:58 Also, you can look at tests/functional_tests, this creates wallets using RPC. 20:04:26 where can you give me a link 20:05:57 It's from the root of the monero tree. 20:11:53 ah ok thank you 20:53:45 github down? 20:59:00 seems so githubstatus.com 20:59:27 down for me 21:20:29 Down for me as well 21:21:52 Well, why would it matter that GitHub is down? Git is decentral! 😉 21:22:10 heh 21:30:58 tevador: How much work has to be done to plug your seed scheme into simplewallet.cpp? 21:53:51 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 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 BusyBoredom[m]: #monero-pools or #p2pool-log 22:21:16 Ah nice, thank you 23:14:59 woodser: hello my friend