02:05:29 .merges 02:05:29 -xmr-pr- 8041 8044 8101 02:08:45 .merge+ 8131 8130 8135 8126 8123 8117 8116 8112 02:08:45 Added 02:18:26 vtnerd: do you plan to do more multisig reviews or should we merge it now? I think the majority of your comments have been addresses on both #7877 and #8149 02:18:41 I think both PRs are in a good place now 06:33:07 jberman[m]: Thanks for the info, got it. I make an attempt today to achieve that. Had already partial success yesterday, but no breakthrough yet. As you found out already, it's tricky :) 06:54:29 would be sweet if you find a nice way to do it 06:55:50 thanks for looking into it :) 06:58:38 Did you stumble over a concrete example of software that stumbles with that particular difference in the JSON structure and would definitely need adjusting after the hardfork? 07:00:08 I am not yet sure there is a nice way to do it, might be a little hacky, but not too complicated once sorted out - hopefully :) 07:06:56 I don't think I did. I can't remember if the explorer needed finnagling because of it or not. I figure eventually it could cause needless problems/headaches, and because the view tag is just an optional thing there to make it faster to check if an output belongs to you, then it can in theory be ignored without breaking anything when reading a tx 07:12:41 I see 08:09:24 hey guys, just wanted to share my thought about the idea of banning pools by implementing mining key requirement like on Wownero fork: Low-spec machines will have no chance in solo-mining and ever increasing diff will kick out smaller miners, then medium miners, until there are only big farms left. 08:11:05 We are holding a dev meeting in a bit over a week. Feel free to add a comment suggesting the topic in the agenda if you want to. 08:11:05 Do note v15 network upgrade has a much higher relevance right now. 08:11:09 which would centralize the network hashrate in a more devastating way than what we have now with the pools, 08:11:22 https://github.com/monero-project/meta/issues/652 08:11:24 kk 08:12:35 ypavtv97lx[m]: You may want to join #monero-pow as well. Lots of PoW algorithm discussions take place in there. :) 08:12:56 Matrix room should be #monero-pow:monero.social, or something similar. 10:07:21 is there any place where I can download signed hashes.txt for older Monero releases? 10:09:35 sech1: Doesn't the list of all releases on here have each their signed hashes.txt below? https://github.com/monero-project/monero/releases 10:10:15 it has sha256 hashes in the text, but not the signed ones 10:10:23 they all link to https://getmonero.org/downloads/hashes.txt which changes with every new release 10:10:52 Let's ping binaryFate on this then. Hopefully he can chime in w/ better insight than myself. 10:13:44 sech1: Github history has it 10:15:23 https://github.com/monero-project/gitian.sigs ??? 10:16:39 that's reproducible builds from various people, not the actual hashes.txt from older releases 10:16:57 It's on monero-site, one sec 10:17:23 sech1: https://github.com/monero-project/monero-site/commits/master/downloads/hashes.txt 10:17:45 dEBRUYNE saving the day, once again. You are welcome. ;) 10:17:46 jackpot 10:17:48 thanks! 10:18:48 np :) 11:08:10 Now that spam on github seems to have quiet down, i would suggest to allow running workflows for all users except new github accounts. I see that in the GUI workflows are still locked for all new contributors, which could be quite annoying for both contributors and reviewers. See for example https://github.com/monero-project/monero-gui/pull/3829 11:18:15 thanks dEBRUYNE, that's the place :) 11:52:28 im remaking the monero coingecko info text, can i throw out the bytecoin mention? i dont think a single person reading that cares about how monero was forked off a scummy dev a decade ago, out of anyone, you guys are probably the only people who even remotely care so i would like to hear your opinion 11:52:48 obviously the text will still state monero is based on cryptonote 12:14:56 monerobull: better ask in the general room. It's off topic here 🙂 18:23:27 ErCiccione: we have the default settings in regards to workflows, that person is a new contributor 18:25:48 There are three settings, one of the three allows new contributors to run workflows. Right now the stricter one is set, which doesn't allow new contributors to run workflows at all. I was suggesting to switch to the setting that disallow only new github users from using the worklows. 18:26:03 I think github set the stricter one as a default to save resources 18:26:21 but it's actually the most unconvenient of the three for open development 18:29:22 * ErCiccione uploaded an image: (49KiB) < https://libera.ems.host/_matrix/media/r0/download/haveno.network/EssxWuBzsRVgldIIgfgnqvBm/Screenshot_20220121_182836.png > 18:30:19 the monero repos are set to the second one 18:33:48 ok luigi1112 ^^ could you set this for monero and monero-gui? 18:36:21 Are boost errors common with monerod? Is there a way to build a version of boost for monero and just link that at build time? 18:37:06 what kind of boost errors? 18:37:53 let's see. I can get the stacktrace. seems to run fine (maybe a bit slow) 18:38:52 done 18:39:13 luigi1112: ty 18:39:29 https://pastebin.com/y8fwwYKw 18:39:44 bad_weak_ptr + some other runtime errors 18:40:29 But, I noticed in the issues that several people have similar issues. 18:41:14 monerod will run essentially ok, and in the logs they all had lengthy stacktraces. I can give some issue numbers to id what I mean 18:43:53 #6696 and #8132 especially 18:44:02 8132 seems most similar 18:51:19 The weak ptr one is common, can be ignored, it's a noisy error check. 18:51:31 randomx ones can also be ignored, there are fallbacks. 18:51:45 If there are others, might be interesting. 23:17:32 .