Testnet Wallet not Functional for Last Few Days

For those still trying to work on testnet, my testnet linux wallet (2.1.0) has been having sync and disconnection issues for the last few days.
Did everything possible to remedy the issue including a fully clean install of testnet wallet, yet the issue persists, so I submitted an issue ticket.

Here is the lastest download url for testnet wallets which was update two days ago:

The link in the previous page takes you to the download page in which you can download the latest version for all three operating systems - that version is 2.1.0: https://testnets.cardano.org/en/cardano/get-started/wallet/

However, this version is the one that gives me and others still on testnet all the issues - it is likely ITN version because there is a tab there for ITN rewards which the Cardano version might not have, but I can’t find cardano testnet wallet - the download page is non-existent I think. Maybe there’s a way to clone and use it from github, but I don’t know if the cardano testnet is operational.

Anyway, if you submit a ticket for a wallet issue, you choose the product you want to send the ticket for, and they have daedalus testnet wallet 2.2.0 as a product option, but I went to latest testnet-wallet website, and the only download available there was 2.1.0, so they must have made a mistake, and no such testnet wallet exists or forgot to post latest upgrade, or it’s only available on githhub and you have to clone it.:

Like I said before, mainnnet is starting to look like a great alternative to testnet for practice, as crazy as that sounds. :confused:

Come on dude - if you have cold key signing down make sure to separate your relay/core architectures out and head on over

1 Like

Thanks for the encouragement, FROG. I genuinely appreciate it, especially coming from you.
Sometimes I’m really slow, but I don’t give up. I spent the whole day yesterday trying to ssh into a new GCE instance I created, and had no luck - very frustrating, but then after searching the net, I discovered gcloud looks for your locally created keypair in ~/.ssh, so when I was trying to ssh using ‘ssh <private.key> user@GCE.external.address’ , the whole time gcloud could not find the key I was trying to ssh with because I usually use the ~/relay dir for most things ‘cardano’.
The cool thing about the ssh command is that in the following form,
ssh-keygen -t rsa -f ~/.ssh/<key.pair.name> -C <cloud username associated with key pair> ,

you can specify the username you want to use to ssh to your instance, but if you leave the -C flag out, it defaults to your hostname, and if you don’t like your hostname you can change it to reflect the username you’ll use for ssh. If it’s something like 6475-sbia-bp-01-us-us , lol which was my actual hostname I used for my laptop bp based on my location, the name is too lengthy, so I just changed the hostname to jt@dell (my initials @ laptop brand), then the
truncated command ssh-keygen -t rsa -f ~/.ssh/<gce.key> picks up anything to the left of the ampersand as your username, so now it’s really easy to ssh into the instance:

ssh -i gce.key jt@<gce instance external IP> from any directory.

I know I can go rambling on about most things at length - it’s my style - I’m typing as I “talk” and then have to edit out all the errors, but I really find this stuff exiciting, so even though it took me a day to set up something as simple as creating a gce/google VM instance and ssh’ing to it, once all that “suffering” was over with, it was ultimately worth it, the elation makes up for the suffering :wink:

So, anyway, my plan currently is to try to build a mainnet bp on GCE farrrr away from Florida…lol, and then have another relay or two in the US on the cloud, again out of harm’s way. I already have one on AWS, so that could be one relay, but I’m also thinking about putting a relay “in front of” my bp in the same gcloud data center, but not in the same zone, so latency between at least one of my relays and bp is minimal.

It’s easy to make mistakes when calculating fees, the correct number of witnesses, etc., so to make my life easier, I changed all the steps into an ordered list of executable instructions (basic scripts with user-only rwx permissions)

1.edit.2.gen.tx.5.edit.6.gen.tx*
3.edit.4.calc.min.tx.fee*
7.edit.8.sign.tx*
9.submit.tx*

So first I edit file
1.edit.2.gen.tx.5.edit.6.gen.tx* , then execute file
1.edit.2.gen.tx.5.edit.6.gen.tx* ;i.e.,
./1.edit.2.gen.tx.5.edit.6.gen.tx*
then edit file 3.edit.4.calc.min.tx.fee* , then execute “file three” to generate min Tx fee,
./3.edit.4.calc.min.tx.fee*
…and so on, until the Tx is submitted to the network.

Step 8. works on testnet, because the cold key was on the computer I was submitting it from…I’ll have to transfer file 7.edit.8.sign.tx* (and the cold keys of course as well as pool-related keys) to an offline computer for mainnet, and add keep step 9. on the online computer. But if I were really worried about having my online computer hacked I could have all the steps except 9. transferred to offline computer.

In what can only be an implicit admission that testnet is dead or close to dead, I tried to run daedalus testnet wallet one more time this morning only to find a message to “update to 2.2.0”. I followed the link to the download site, and clicked on download 2.2.0 button/link, and a pop-up window asked me if I wanted to download daedalus 2.2.0 mainnet.

So, it’s likely not a mistake. They’ve basically neglected testnet to the point where it is no longer functional for some or many(?) people and expect them to move over to mainnet.