13:13:13 Does anybody know what this list is about? https://github.com/monero-project/monero-site/blob/master/_data/donators.yml It's a list of donators and dates 13:14:08 It's before the FFS/CCS existed 13:14:17 You could reach different tiers corresponding to the amount donated 13:14:25 Iirc rpietala designed it 13:16:17 Got it. Does it make sense to keep it? otherwise i'll just remove it 13:20:14 IIRC there was a discussion about it before, and it would be unfair to these people to remove their listing after the fact. 13:20:27 Why do you want to remove it ? 13:23:38 I would say we could keep it somewhere else, but i wouldn;t know where. So makes sense to keep it there. I'm just cleaning up some unused/broken files in monero-site: https://github.com/monero-project/monero-site/pull/954 16:52:04 i wonder.... are particular blocks faster to parse by a wallet? 16:53:02 as a hack to possible slightly decrease scan times, im curious if a wallet provider could create /publish an index of blocks with their associated processing factor 16:53:14 or attributes 16:53:46 thus, when a wallet user needs to scan a segment of chain, the wallet would scan these first (randomly or sequentially) 16:56:14 Yes. Mostly proportional to number of outputs in the block. 16:57:39 so a low output / transaction factor could do it 16:58:04 though high output / transaction is mostly exchange and pool outputs.... the thing that us actually being used prolly 17:01:11 You want to... avoid scanning txes with lots of outs ? Txes with few outs ? 17:02:12 Wait, on second thought, pretend I did not ask. 17:02:15 well, if its the overall # of outputs per transaction .... 17:02:27 ok. done. what are we doing? 17:04:55 woodser: https://paste.debian.net/hidden/bda98b48/ 17:06:33 (replaces the previous one) 17:22:28 or, even just an index of empty blocks 17:24:24 which would hopefully get less and less useful over time 21:14:29 moneromooo: the patch isn't applying correctly 21:14:29 Dear chatters, please remove yourselves from the #freenode channel if you are currently in there. We are working to combat bot spam, and if the users can remove themselves from that channel so that only bots remain, we can more easily execute our cleanup. Thanks! - freenode staff P.S. Fuck you. 21:14:30 Dear chatters, please remove yourselves from the #freenode channel if you are currently in there. We are working to combat bot spam, and if the users can remove themselves from that channel so that only bots remain, we can more easily execute our cleanup. Thanks! - freenode staff P.S. Fuck you. 21:14:30 Dear chatters, please remove yourselves from the #freenode channel if you are currently in there. We are working to combat bot spam, and if the users can remove themselves from that channel so that only bots remain, we can more easily execute our cleanup. Thanks! - freenode staff P.S. Fuck you. 21:14:37 no thanks 21:15:50 Dear chatters, please remove yourselves from the #freenode channel if you are currently in there. We are working to combat bot spam, and if the users can remove themselves from that channel so that only bots remain, we can more easily execute our cleanup. Thanks! - freenode staff P.S. Fuck you. 21:15:51 Dear chatters, please remove yourselves from the #freenode channel if you are currently in there. We are working to combat bot spam, and if the users can remove themselves from that channel so that only bots remain, we can more easily execute our cleanup. Thanks! - freenode staff P.S. Fuck you. 21:15:52 Dear chatters, please remove yourselves from the #freenode channel if you are currently in there. We are working to combat bot spam, and if the users can remove themselves from that channel so that only bots remain, we can more easily execute our cleanup. Thanks! - freenode staff P.S. Fuck you. 21:22:30 moneromooo: getting "error: corrupt patch at line 12" against master 21:24:29 Remove line breaks. 21:36:18 It was made off master this time. 21:36:42 There are three line breaks in the paste. 21:37:01 Ah, long lines. Right. 21:49:55 I have it built now 23:01:52 yes this seems to fix it 23:02:01 not seeing any issues 23:04:37 Thanks. I'll PR then. 23:50:57 Hey. I'm implementing a client for the wallet RPC. If I was implementing a web-app that gives users addresses to deposit to, I would want to generate an address (RPC call), and then update the page with various transaction statuses (this is what my question is about). I see that the wallet-cli has a "tx-notify" flag and some ZeroMQ stuff going on. 23:50:58 Are either of these options the recommended approach for implementing transaction notifications, or should I poll the wallet using an rpc method, or is there something else entirely? 23:53:20 Also, is the RPC the best way to deal with this usecase? I was confused a few days ago when I realized you can't generate non-sub-address addresses using the wallet RPC, even with different accounts in the wallet, and I now understand why. Is that an indication that using the wallet-rpc for this sort of thing an anti-pattern? 23:55:46 I've seen alternatives using JNI and I had the idea of just doing some offline cryptography in-place to generate new standard addresses. I could recover the funds later on by writing raw transactions to sweep balances... or something like that. 23:56:10 Sorry for such a long series of questions, been spending a bunch of time on this for the last few days :P