This is potentially a problem. What version of Bitcoin Core are you using?

That's a very old, outdated version of Armory... it won't work properly with newer versions of Bitcoin Core. I would suggest you go here, get 0.96.5 and update your Armory, then try again: https://btcarmory.com/

0.96.5 is on the releases page: https://btcarmory.com/releases/


Honestly not sure... for some reason your Bitcoin Core client didn't accept it. It is possibly related to the old Armory version doing something that Bitcoin Core isn't liking

At this point, all I can suggest is to update Armory and try again. If it still isn't working after updating... post the updated log files.

Yeah, what nc50lc said... The earlier versions of the restore process required 4 lines of input... only the 1.35c version is two lines of root key (+ secureprint code, if any).

Either, your memory isn't quite correct and your wallet isn't from as long ago as you think... or older roots are also compatible with 1.35c and will work without the chaincode. I don't know if this is actually possible, as like I said, I don't have an older paper backup version to test.

paging @goatpig

armorycpplog.txt may not show anything of great interest... I'd check out armorylog.txt and dbLog.txt in the first instance.

If you want more assistance, you'd need to post the contents of those log files (in full) to pastebin.com and then link the generated pastebin URL here so we can view the logs.

If you don't see any obvious errors in the log files, then you might want to use the "Rebuild and Rescan Databases" option in Armory's "Help" menu and see if that helps.

It's fine if you want to use Bitcoin only... I can understand that, as I'm not a huge fan of altcoins either. Unfortunately, they're not going to go away... the values on coinmarketcap make that plainly obvious. The top 90+ coins all have marketcaps over $1 Billion dollars.

People are going to want to use these coins. So, as a commercial operator, your choices are:

1. Offer support (and hopefully put dev resources into making them secure as opposed to coding up unnecessary games) and potentially gain a customer.
or
2. Don't offer support and potentially lose a customer to your competitor.

Also, I suspect that the vast majority of altcoins supported are actually just ERC20 tokens anyway.


It's entirely plausible that a glitch in the game code (such as entering a specific key combo or achieving a high enough score to cause an overflow etc) could result in an attacker achieving something equivalent to "root" access on the device.

Is this actually possible... who knows? The point is, that adding "fun" hidden easter eggs like this, is not necessary... the dev effort would be much better spent ensuring that the "necessary" code is secure.

Kleopatra does support .pem files. I believe the issue is that the public key that Ledger Live are using, is an OpenSSL public key... and not a PGP/GPG public key.

As Kleopatra is GPG based, it fails. Kinda like trying to use an ETH address in a BTC client


The OpenSSL Wiki actually has a list with a number of sites for getting Windows Binaries: https://wiki.openssl.org/index.php/Binaries

I just used the curl.se one because it was one I had stumbled across previously and knew that it worked

You either created a completely different wallet in Electrum and then sent the funds to it from Blockchain.com or it's possible you swept the funds or imported the private keys. If you sent or swept the funds, there should be a transaction in blockchain.com showing the coins going to your Electrum wallet... and then the inbound transaction on coinfloor should show the coins coming from somewhere other than your blockchain.com wallet.

If you imported the keys to Electrum, you would have been effectively "cloning" the blockchain.com wallet, so there should be a transaction showing in Blockchain.com that shows the funds going directly from there to coinfloor.


I don't see why you can't sell the coins in your coinfloor account... as far as I can tell, it is a custodial service, but as long as you meet their minimum amount requirements, there is no reason you shouldn't be able to sell them.


Theoretically yes... but if you already imported the keys elsewhere (like Electrum), then it's possible that it is also linked to other wallets.

Note that you didn't "create" the seed phrase this evening. It has always been the seed phrase for your wallet since the wallet was first created. It's also entirely possible you already viewed that seed phrase and imported it to Electrum when you were first "moving" coins from blockchain.com to Electrum to coinfloor.

Without having access to transaction histories and addresses etc it is kind of difficult to really say for sure exactly what you have done, and how... So most of this is "guesswork" based on your description of what has happened.

Did you include the 2nd line of text with the derivation path? If so, what derivation path did you use?

Note that the one in the example (m/23/23'/33) is NOT a "standard" Bitcoin derivation path (which would tend to be something like m/44'/0'/0' or m/49'/0'/0' or m/84'/0'/0' etc)


It says in the coldcard docs linked above that it will default to the master key of "m" if a valid derivation path is not supplied. This would probably explain why it doesn't show in Electrum... it probably wouldn't show in any wallet.

This won't work with newer versions of Bitcoin Core... make sure you have version 0.96.5 from here: https://btcarmory.com/0.96.5-release/


Otherwise, it is kinda difficult to work out what is actually happening, as you seem to be trying to run multiple versions of things from multiple locations

The "socket error", that was showing in one of the logs, could indicate that there is a "ghost" process running hidden in the background... you might need to try ending tasks from task manager or rebooting the PC to clear them out.

Also... running ArmoryQt from the commandline, you shouldn't be using "datadir"... it should be "satoshi-datadir" to specify the Bitcoin Blocks folder... and "dbdir" to specify the Armory database dir...

ArmoryDB uses "datadir" (for Armory data directory), "satoshi-datadir" for blocks folder and "dbdir" for it's database directory.

All this is explained here: https://btcarmory.com/docs/pathing

Oldest version I can find is here: https://github.com/goatpig/BitcoinArmory/releases?after=v0.85-beta

As for getting different root keys... it's possible that the root key you have, is for an old wallet format... and the new root key you're getting is the version 1.35c version. Unfortunately, I don't have an old version root key to test my theory with.

But looking at the restore process, it only offers 1.35, 1.35a and 1.35c... and only 1.35c is 2 lines soooo


Unfortunately, It's difficult to be sure of anything given the history and circumstances of how you retrieved your root key. It's entirely possible that your memory is incorrect or incomplete.

Hopefully goatpig might be able to offer some insights.

Sounds like Armory may not be communicating with bitcoind properly... can you please post your Armory logs?

I would suggest you paste them to pastebin.com and then post the pastebin URL here to avoid creating a super long post (or having it cut off due to max character limit).

The database files are, by default, kept in your "AppData" directory on Windows. This will be something like:

There you should see the "databases" directory and you can remove the contents in there... Note that "AppData" is a "hidden" directory by default, so you may need to read this: https://support.microsoft.com/en-us/windows/view-hidden-files-and-folders-in-windows-97fbc472-c603-9d90-91d0-1166d1d9f4b5


Another option is to simply use the "Rebuild and Rescan Databases" option in Armory:


Or the "factory reset" (but that will blow away everything! and you'll need to reconfigure from scratch).

These messages are showing that you don't appear to have what you think you have (ie. private keys)... It seems that all you have are addresses. If you don't have the private keys, you won't be able to spend any of the coins.

Your addresses will look something like:
1xBitcoinAddress
or
3xBitcoinAddress
or
bc1qBitcoinAddress

ie. they'll start with a 1, 3 or bc1... Your BitcoinCash address might start with a "bitcoincash:" prefix.


Whereas your private keys in WIF format will look something like
5KCYdMUyh8hBHxw8mmcZeK4tzSLQEhryP6ppcFRRE4ioKFb8bYW
or
KxCY5wByvumhAa2E6cyTuuTUUXq4xNvTR4vcx9G5UgsB9aKsxvZD
or
L3KxbTQVE8xLRsswJbuy5gkCUWpdZVMZrYi58aemvfRVRCq5MTAi

ie. they'll start with a 5, K or L.


If you want to spend coins, you'll need to import the private keys... importing the address will create, as you've discovered, a "Watching-only" wallet which only allows you to view the transaction history and balance etc... but you can't sign transactions (you don't have the private keys!).


Do as mentioned above and get either the 12 word recovery phrase from blockchain.com wallet... or if the addresses you're trying to export were originally "imported" to blockchain.com, then you will need to click the gear icon in the top right corner and select "wallets and addresses":


That should give you options to view "imported" addresses in blockchain.com and if you select "manage" to the right of those addresses, you should get the option to view the private keys:



NOTE: you cannot see the individual private keys for addresses in your blockchain.com wallet that are part of the HD wallet (ie. generated from the 12 word recovery phrase), without using the 12 word recovery phrase and external tools. You can only see the individual private keys for imported addresses.

I concur... you cannot argue the fact that adding unnecessary code means that you are adding unnecessary risk.

Sure, hide snake in your graphical calculator or the control panel on your fridge or something... but a device that is meant to be a security device should really include only the bare minimum required to perform the desired tasks.

I don't see how hidden games enable one to manage their crypto holdings securely

As far as I can tell... the .pem file from Ledger (which is their public key), is not importable into Kleopatra.

I just get a "BER Error" when attempting to import this public key:



As far as I can tell, it's just not compatible with GPG... seems they're using openssl, and not GPG.


So, for windows, I downloaded the "precompiled openssl binaries"^[1] from here: https://curl.se/windows/
Then I extracted the contents of that archive to C:\OpenSSL (to make life easier)... and then put the .pem, the .sha512sum and the .sig file in there as well.

Then used the openssl commandline as per the Ledger website:



As you can see, I got the "Verified OK" message.

---

As mentioned, WSL (Windows Subsystem for Linux) is available on Windows 10 and gives you the ability to install several linux distros and open up a linux terminal. (sidenote: WSL2 on Windows 11 even has support for running Linux GUI apps! )

So, that's also an option.


[1] I don't currently have access to my dev machine, otherwise I would have downloaded and compiled the source myself.

When you say "downloaded electrum etc"... do you mean that you downloaded Electrum and then several of the Electrum clones (Electron Cash, ElectrumG, ElectrumSV etc) to be able to claim the fork coins? Or did you just download Electrum and you're trying to access other coins in it?

Electrum, as stated above, is BTC only... to get the fork coins, you need to download the Electrum clone specific to each Fork. You can generally find links to these clones from the forkcoin's homepage.


What exactly do you have from blockchain.com... the 12 word seed? or individual private keys in WIF format?

The main reason I can think of is some sort of service or custodial wallet that wishes to promote "instant" withdrawals... User clicks "confirm" on a withdrawal, they want to instantly see a transaction has been created and broadcast.

This is "fine" when the network isn't grossly overloaded and fees are ridiculous and/or the service actually creates transactions with "decent" fees so the transactions don't get stuck.

However, when the first big "flood" happened back in 2017... there were scores and scores of users creating "HELP! stuck transaction!"-type posts where their transaction was like #30 in a chain of unconfirmed transactions, because there were a number of services/wallets using really bad fee estimation (or none at all) and they were just creating enormous chains of unconfirmed transactions with low fees.

It seems that most of the very large sites seem to "batch" withdrawals now... and users seem to accept a "Pending" status for a while, while a number of withdrawals are collated and sent in one outgoing transaction... Although, I'm sure you'll now be able to find chains of unconfirmed "batched" transactions!

The link to the "paper" was mentioned in an earlier post:

---

This seems fundamentally flawed... the Genesis block is just a data block... it's not a "code".

So, it seems their entire premise rests on this really bad interpretation of what a "genesis" block is?

Yeah. There is certainly something extremely suss about this whole thing.

part of the "danger" of "pre-printed" physical coins I guess... At some point, some one other than the coin holder has had the private key... which means the coin holder has to trust that no records were ever kept.

Yeah... I haven't really seen any full hardware "hybrid" drives for a while... The were a thing when SSD's were a lot more expensive, but as SSDs slowly came down in price, it seemed hybrid drives just kinda disappeared before they really became a thing.

A "reindex" won't prevent this from happening... something in your setup is causing data corruption and that corrupt data is being written on your disk.

It shouldn't be an invalid block being received from another node, that should be automatically invalidated and discarded by your node when it is received... so it is most likely something at your end (bad drive cable, bad hardware, bad power unit, faulty memory, faulty disk, bad chipset etc).

I would wager that this will continue to happen from time to time unless you substantially change your setup and replace hardware (the difficult part is that it will be very difficult to track down which specific bit of hardware is causing the error )...

Until then, you're going to need to continue using reconsiderblock whenever this happens.