The monetary policy is detailed in the OP. The block reward is reduced by 1 every year until the 8th year when there will be just over 49M coins and 360k new ones every year.

You need to mod the VBIOS with different memory timings and also overclock the memory. You can downclock and undervolt the core to save power as well.
Generally speaking the memory can go to 2000 - 2200 MHz depending on which ICs are used and their quality. Core can be downclocked to around 1150 MHz and undervolted to 800 - 950mV without losing hash rate. You will have to do stability testing to figure out optimal settings for your cards as each one is different.

You can use this version of PBE to do an easy timings mod:
https://github.com/jaschaknack/PolarisBiosEditor

Back up your original and flash the modded one with atiflash:
https://www.techpowerup.com/download/ati-atiflash/

You may need to disable the driver's VBIOS signature check after modding. Use this tool:
https://www.monitortests.com/forum/Thread-AMD-ATI-Pixel-Clock-Patcher

Apparently there is an XC Discord now. I guess the team doesn't plan to post on bitcointalk anymore (unless you are talking about the blocknet thread. They have time for that.) 

https://discord.gg/9EeaJGr

I've had this miner running for over a month before till I shut it down on purpose for some maintenance, and that was with modded/undervolted cards. If you have instability the miner is probably not the culprit. Once in a while I will see a card report a hashrate a few Mh/s below normal but it's very brief and will only appear on one line of reporting. If I hit 's' after or wait for the next report it's already back to normal.

I think most people just don't do proper stability testing after they start messing with clocks/volts/timings.

So are there two chains right now? Which one is novaexchange on??

What happened this time? Is there new problems since the downtime on the 14th??

what premine?

Thanks for the reply. I found a few posts about this on the discord afterwards and it seems I was under the wrong impression anyway.
I thought perhaps XCP and the other tokens would be moving to the Hush chain, but it seems that is not necessarily true. The protocols would be implemented but the tokens would remain on the BTC chain unless the curators of any particular one actively decided to switch, correct?

Was Counterparty supposed to get ported to Hush? Or am I drunk and thinking of another coin?

Sure it's 0x4ef245a8e91Dc0619865f0400403264D9d520DCf

Glad you got it worked out. 

In that case you may not have to export the private key at all. Try this guide instead but substitute 'ETC' for 'UBQ', except in step 9 I believe you need to select the ETH address you sent the UBQ to.

https://ledger.zendesk.com/hc/en-us/articles/115005200029-I-sent-ETC-on-an-ETH-address-how-can-I-recover-them-

It depends which wallet you are using for UBQ.

That's because you need to import the private key from your eth address before you will see it. If you want to verify it is there you can look up your eth address on a ubiq block explorer.

In order to recover the coins you need to export the eth wallet private key first so you can import it to your ubiq wallet. Unfortunately I don't have step by step instructions for you and it depends on which particular wallet you are using. You can probably find info in a FAQ for the wallet you are using with some searching.

For example if it is a ledger nano hardware wallet a quick search comes up with this:

https://ledger.zendesk.com/hc/en-us/articles/115005197905-Restoring-your-Ethers-ETH-or-ETC-without-a-Ledger-Nano-S

You should be able to find similar guides for mist/geth, parity, myetherwallet, jaxx, etc. with some searching. Same goes for finding a guide for the second step of how to import keys into a wallet. Google is your friend.

Well if it's unencrypted it should be even easier to export then shouldn't it?

Any idea how long the Cryptopia wallet has been down for?

You will need to export your private keys for your ETH address and import them into your UBQ wallet.

Yeah I've noticed that. I can set 950mv in each dpm state and the card will actually use 950mv in windows, but with the same BIOS in Linux it will use stock voltages of around 1150mv. To get around this I've edited the BIOS to just go ahead and use stock voltages for the higher dpm states but added a 287mv negative global offset...but for some reason dpm state 6 is still bugged. If I switch to that state I see the "AvgPwr" show as around 50W (which tells me it is using less than idle voltage) and it will crash. It should be at around 850 - 863mv in that state, just like it does for states 3, 4, 5, etc. but for some reason it doesn't.

It's a real pain in the ass and I haven't ruled that out as a cause for the instability (briefly switching to state 6 for whatever reason). I wish the driver would just do what it's supposed to according to the BIOS but nope. It does what it wants and what it wants is to be a dick.

Just to add to this now that I got it working and have some data...I've been testing 1 of my cards in Linux and it gets 28.5 (reported by Claymore's miner) using practically the same settings (-10MHz on the memory because 2060 seemed unstable), as opposed to 29.5 reported by Claymore in Windows.

GPU # 1 in this screenie:

https://i.imgur.com/pyOzP3i.png

However, the actual effective 24hr avg hash rate on the pool side (AFTER losses from stale shares and Claymore's fee) is consistently slightly higher than the reported hash rate in Windows. Meanwhile the actual effective hash rate of the Windows cards is 5% or more below the reported hash rate.

https://i.imgur.com/pB7tvSo.jpg

That said, Windows does actually seem more stable. I mined for over a month with no signs of stopping until I shut down the rig on purpose to do some maintenance. In Linux it crashes every once in a while even with a slightly lower mem clock and slightly higher power use and temps (so I'm assuming core voltage is slightly higher but I have no way to check for sure). Also no way to monitor GPU memory errors so I'm not sure if the crashes are due to memory clocks/timings or a lack of core voltage.