buck54321

> I just changed the ip to 127.0.0.1 in the code. You added the IP to this line? ```Go ListenAddrs: []string{":" + cfg.Port}, ```

~~May be related, but the score meter has stopped working correctly too.~~ Nevermind. Was running release server.

@chappjc was spot on. Consolidation functionality should be invisible to the user. Forced splits are the best solution, even if the algorithm is non-trivial. This issue is more important now...

What I'd call "delegated transaction signing" would definitely be a challenge, and may be impossible without a trusted party, but all other scenarios are just your own instance of dexc...

@xaur I'd really like to deputize you for coordinating releases. Up for the job?

> that way, we can avoid another seed upgrade Why would we need any kind of upgrade for this? Should just be subbing out the two functions and one constant...

OK. I see the wider problem now. The deprecation is a recommendation against using poly1305 for encryption due to its fragility. https://github.com/golang/go/issues/36646 But we're not using it for encryption, we're...

I'm also OK just not changing anything. I made a bad choice for HMAC. I can't remember how I made that decision. But if it's not a security issue, why...

> > From the OP https://github.com/golang/go/issues/36646 > > If anyone is considering using the x/crypto/poly1305 package, they should be dissuaded and pointed towards HMAC, which acts much more like people...

We actually added a version byte https://github.com/decred/dcrdex/blob/ac979f4cb6dd47dd8f2a2f80f8c4f67ae00845ca/dex/encrypt/encrypt.go#L139 checked at https://github.com/decred/dcrdex/blob/ac979f4cb6dd47dd8f2a2f80f8c4f67ae00845ca/dex/encrypt/encrypt.go#L148-L150 So we could, in theory, just support two algos and everything new would be version 1.