xiphon I don't think so. If you look at the images they link to github.com/bitcoin-fast-miner

minergate lol

"CMD ["-u", "maxim1⊙ec", "-xmr"]"

at least it's not the entrypoint

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

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)?

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.

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

How feasible is this?

I've been in communication with developers on both teams

They've both completed development, but allowing extra time to test could be useful to avoid unexpected problems that arise

Surely they can set a fork height to whatever they like without having to ask us,

src/hardforks/hardforks.cpp IIRC. Add a line in the table, at the end.

IIRC the CLSAG code is set to enable at v13.

Fair enough

That sounds a lot like a setup to "it;s broken because I could not test".

It does look like they'll be ready for the upgrade whenever it's decided that it should take place

Sounds like having testnet was just more of a convenience

I'm trying to be as proactive as possible to avoid delays with that

Well, it's a one line change. In case htey did not know, feel free to paste hte above.

For sure

Maybe it's worth revisiting the discussion of when to upgrade, since now I know the status of both Trezor and Ledger development

And pay attention to add the line to the right table I guess (mainnet, testnet, stagenet).

yeah

Once the branch is rebased, I'll let them know

In case anything ends up behaving oddly between that branch and current master

I tried a (very quick) rebase locally that broke, but I need to see if I did something silly by mistake

I thought I was going to do that, without time constraint.

Is there a time constraint now ?

There is not; I had simply tried it for fun, out of curiosity

Since I was rebasing some other unrelated branches

(I needed CI, which had broken)

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?

There's an inherent advantage to upgrade earlier, if only because of the spacetime savings with CLSAG that accumulate over time

I'm not advocating upgrading early if there's a good reason to wait, of course

One of the Ledger devs has just asked what the maximum time would be between setting an upgrade height and the upgrade

I asked the ideal time (given their deployment workflow) and they said 4 weeks

Thoughts?

Typically around 4 to 6 weeks I think

OK, any complaints against 4 weeks?

sarang: I think we forgot an element here

Last HF we released basically one month in advance of the release

The code should be done before that

So then you get to 8 weeks in advance of the HF height

Well, getting the height set will be important for their deployment

Testing can presumably be done pretty independently of this

We usually do 4 weeks afaik. About the date of the upgrade, we called a meeting on sunday to decide that, no?

But their concern was getting the Ledger app into the deployment workflow

aye

Just mentioning here since we now know where the big hardware devices are in their tielines

*timelines

Weekly meeting in #monero-research-lab starts in just a few minutes