01:45:38 -xmr-pr- tobtoht opened issue #6708: torsocks: obtaining initial peerlist often takes anywhere from 5 to 20...
01:45:38 -xmr-pr- > https://github.com/monero-project/monero/issues/6708
03:00:31 <lza_menace> xiphon I don't think so. If you look at the images they link to https://github.com/bitcoin-fast-miner
08:27:24 <fluffypony> https://hub.docker.com/r/monero/miner/dockerfile
08:27:26 <fluffypony> minergate lol
08:27:41 <fluffypony> "CMD ["-u", "maxim1⊙ec", "-xmr"]"
08:35:30 <bertptrs> at least it's not the entrypoint
10:43:33 <Snipa> Heh, way back in the day when I was authorized to mine with a bunch of DO VPS', I had a docker container that did the same thing. :D
13:21:31 <Adreik> Is there an easy way to generate outputs for testnet monero that are pre-ringct (e.g. to make sure that a custom wallet implementation would manage very old outputs generating transactions correctly)?
13:37:11 <moneromooo> Remove DB, edit fork heights to start off early (say from height 1000), run with --offline, mine, make txes before 1000, mine till after 1000.
14:27:57 <sarang> It might be nice to have testnet available early for Trezor and Ledger testing of CLSAG, even if not all other commits/features are merged
14:28:03 <sarang> How feasible is this?
14:28:18 <sarang> I've been in communication with developers on both teams
14:28:53 <sarang> They've both completed development, but allowing extra time to test could be useful to avoid unexpected problems that arise
14:29:36 <moneromooo> Surely they can set a fork height to whatever they like without having to ask us,
14:30:13 <moneromooo> src/hardforks/hardforks.cpp IIRC. Add a line in the table, at the end.
14:30:31 <moneromooo> IIRC the CLSAG code is set to enable at v13.
14:30:40 <sarang> Fair enough
14:31:15 <moneromooo> That sounds a lot like a setup to "it;s broken because I could not test".
14:31:19 <sarang> It does look like they'll be ready for the upgrade whenever it's decided that it should take place
14:31:34 <sarang> Sounds like having testnet was just more of a convenience
14:31:53 <sarang> I'm trying to be as proactive as possible to avoid delays with that
14:31:55 <moneromooo> Well, it's a one line change. In case htey did not know, feel free to paste hte above.
14:32:03 <sarang> For sure
14:32:40 <sarang> Maybe it's worth revisiting the discussion of when to upgrade, since now I know the status of both Trezor and Ledger development
14:33:07 <moneromooo> And pay attention to add the line to the right table I guess (mainnet, testnet, stagenet).
14:33:23 <sarang> yeah
14:33:46 <sarang> Once the branch is rebased, I'll let them know
14:34:03 <sarang> In case anything ends up behaving oddly between that branch and current master
14:34:43 <sarang> I tried a (very quick) rebase locally that broke, but I need to see if I did something silly by mistake
14:36:07 <moneromooo> I thought I was going to do that, without time constraint.
14:36:28 <moneromooo> Is there a time constraint now ?
14:36:49 <sarang> There is not; I had simply tried it for fun, out of curiosity
14:37:06 <sarang> Since I was rebasing some other unrelated branches
14:37:48 <sarang> (I needed CI, which had broken)
14:52:12 <sarang> There had been general talk about upgrading before the end of the year; given hardware device support is good to go basically whenever, is there a good reason to delay?
14:52:56 <sarang> There's an inherent advantage to upgrade earlier, if only because of the spacetime savings with CLSAG that accumulate over time
14:53:14 <sarang> I'm not advocating upgrading early if there's a good reason to wait, of course
15:48:09 <sarang> One of the Ledger devs has just asked what the maximum time would be between setting an upgrade height and the upgrade
15:48:29 <sarang> I asked the ideal time (given their deployment workflow) and they said 4 weeks
15:48:32 <sarang> Thoughts?
15:48:33 <dEBRUYNE> Typically around 4 to 6 weeks I think
15:49:29 <sarang> OK, any complaints against 4 weeks?
15:56:21 <dEBRUYNE> sarang: I think we forgot an element here
15:56:31 <dEBRUYNE> Last HF we released basically one month in advance of the release
15:56:36 <dEBRUYNE> The code should be done before that
15:56:49 <dEBRUYNE> So then you get to 8 weeks in advance of the HF height
15:57:51 <sarang> Well, getting the height set will be important for their deployment
15:58:03 <sarang> Testing can presumably be done pretty independently of this
15:58:14 <ErCiccione[m]> We usually do 4 weeks afaik. About the date of the upgrade, we called a meeting on sunday to decide that, no?
15:58:17 <sarang> But their concern was getting the Ledger app into the deployment workflow
15:58:24 <sarang> aye
15:59:04 <sarang> Just mentioning here since we now know where the big hardware devices are in their tielines
15:59:22 <sarang> *timelines
16:57:03 <sarang> Weekly meeting in #monero-research-lab starts in just a few minutes