When creating a new HD wallet (to send the funds to from your paper wallet) you are supposed to generate a new seed (backed up by 12 word mnemonic code).
Anyone with access to these words has access to your BTC. So keep it safe and secure.

Did you receive a private key (on a paper wallet) as a gift ? Or is there are mnemnoic code (12/18/24 words) on the paper wallet (which would be quite unusual and should not be used as a wallet) ?
What does 'the same seed key' refer to ?

Just because everything can be run on a blockchain (note: blockchain is just a data structure; a form of arranging data) it does not mean that everything should run on a blockchain.

Many people seem to misunderstand the real purpose of a blockchain. If you just want to add 'blockchain' as a tag for something, you are not making it better in any way.
The problems you are trying to fix can not be fixed by the use of a blockchain.

But.. feel free to outline. How would you fight ad fraud with 'a blockchain' ?

So.. you want the currency which was created out of the crumbling trust into the financial policy to serve as a kind of governmental treasure ?

How would this improve the current state of all currencies waiting to implode? Governmental regulation of a currency has proven to not work out in the long run.
If you now want the government to basically 'control' bitcoin with all of their money you are just taking the same failure onto another level.


The only reason, i can think of,  for someone to want this is to make a quick buck.
The imagination of massive demand appearing which thrives the price to new highs within no time is compelling, but this was never the purpose of bitcoin.

This probably depends on what you define as 'near future'.

IMO it is unrealistic to expect a 'recovery' to prices around ATH within the next months or year.

I am confident BTC will reach a new ATH. But it probably won't happen before the next halvening. Bitcoin needs adoption right now, to increase the dollar-value.
I am expecting the next big pump/run when a technological milestone has been reached (e.g. lightning network fully tested and functional). Because only the development of bitcoin is really increasing the value.

With the development going on (LN, schnorr, etc.. ) it is just a matter of time until adoption will increase at a rapid pace. And with increasing adoption the overall presence is also going to increase.
This will lead to an upwards movement of the BTC/USD price through all of the new demand.

It would be way more easier for us to find your mistake if you would share the relevant code.

Can't tell much without looking at it. But generally speaking, you seem to have built the transaction wrong.

Which wallet/client/library are you using to create the transaction ?
Are you trying to manually sign it ?

For manually signing transactions (and a small python code snippet), look here: https://bitcoin.stackexchange.com/questions/36440/signing-a-raw-transaction-with-python-ecdsa-or-openssl

You first need to copy the encrypted file somewhere into your ubuntu home directory.
The first file after the -in command option, named 'bitcoin-wallet-backup-testnet-2014-11-01' in your example, is the encrypted file you want to decrypt.

Navigate into the folder you have copied the file to and execute the command:



Note that you might have to replace aes-256-cbc if the forked client does use a different encryption algorithm.

BIP39 seeds will be supported way longer than 2 years. Not necessarily by electrum, but by enough other wallets to regenerate all private keys.
BIP39 has been adopted by many wallets/services. You'll find a lot of tools regarding BIP39 <-> private key conversion.

The risk of not being able to reproduce private keys out of a bip39 phrase is very small. But the chance of not being able to access the private keys with a 2 year old wallet file is way bigger.

A copy of the wallet file can be handy, but does NOT replace a 'traditional' hand-written backup in form of a 12/18/24 word bip39 phrase.

IMO this definitely is a better alternatives since most malware made for windows does not look through different file systems (would be still possible though).
A compromised windows would not automatically lead to the linux system being compromised. You can't say that about a VM.




Usually you always can access all partitions on a disk, regardless on which partition the OS is installed on.

To effectively lock out the access from windows to the linux partition(s), you would need to encrypt the /home and /root partition (which probably is the best approach),
or at least only mount them as readable only inside windows, but not as rw.

This is completely unrelated to the post you were quoting.
A transaction with a calculated fee (the fee is just an estimation of getting a confirmation after X minutes) does not have to confirm within this timeframe. This is depending on multiple factors.
The amount of transactions inside the mempool could increase, making your fee which currently was totally fine to get a confirmation the next block now isn't enough to get it confirmed within 10 blocks.
Or no blocks are being found at the moment. The difficulty still stays the same. And so does the average block time of 10 minutes. But 2 hours without a block isn't that unusual. But 3 Blocks within 10 minutes aren't that unusual either.

All these calculations of a fee are just a estimation. If you want to better estimate the fee, take a look at https://jochen-hoenicke.de/queue/#1,8h. You will be able to guess the fee to use pretty clearly.

According to your edit, you changed that part of the code ?
So now, if the signature can be verified, you'll get true.
And if the signature can not be verified, you'll get false.

Now, if you make a mistake (i assume you mean that you change some characters of the necessary data?), the function has to return false, which also will give you a false as output.


This seems to be right for me. What exactly doesn't work ? Do you mean that the function ecdsa.Verify does always return the same ?

Without looking too much at it, this seems to be somehow wrong:




It may be the case, if the signature is actually correct and your code runs properly, that you are misinterpreting the output because you are printing true if it the verify function returns false and vice versa.

So if you are actually getting the output false, the signature has been verified properly.

If the exchanges provides you the same address for both currencies, you at least got the transfer credited ?



No, definitely not. It doesn't matter where your bitcoins are now. It only matters 'on which address' they were on the fork date.
You need to download a proper wallet for BCD (if such would exist) and import your seed there.

But make sure that you move ALL funds (BTC) associated with those 12 words off this wallet. Generate a new wallet (new seed, etc. ) and first move your BTC there.
Then try to redeem your forked coins. Please consider this seed as compromised since you have entered it into the forked wallet.

Did you move your BTC out of this wallet before compromising the seed by entering it into a BCD wallet ?




Did you check the block explorer for BTC and BCD ?
Were the BTC sent to the address you provided ? Or to another (random) address? You might have downloaded malware which stole your BTC.




This makes sense, since BCD is a fork of BTC and your mnemonic seed phrase does reproduce the private keys for the addresses you 'received' your forked coins to.




So, did you send BCD or BTC ?

First you have told that the BTC were sent. Now you are telling that your BCD was sent to an BTC (address) ? Please clarify.




This is quite unusual since exchanges create a new deposit address for each coin/customer.
What exchange were you using?




If the BCD wallet is buggy or malicious, yes of course.
If it is proper coded and trustworthy (which you could never say about BCD), no.




 




 
Please clarify your whole situation. There are some contradictory statements inside your story.
We will be able to help you once we understand you unambiguously.

It is probably not only due to the imperial units, but also because hundreds of forks appeared.

20+ coins do either have 'btc' or 'bitcoin' in their name. It is definitely imaginable that someone might get confused by seeing MBTC in their wallet, especially after hearing about countless scam bicoin forks.
Even though it is shown as mBTC, which should make it clear that this is a milli. But i guess for newbies this definitely can be irritating.

---

@OP
If you feel your question has been answered, feel free to lock the topic. To lock it, scroll down and click 'lock topic' and the bottom left.

Unfortunately that's just one part of securing your coins.
You still have to calculate the risk outgoing from wrong/buggy implementations, 0-day exploits, non-disclosed vulnerabilities, etc..

There are many factors which you can't influence, but do have a direct impact on your actual level of security.




Yes, either a hardware wallet (to combine safe offline storage with usability) or a dedicated offline pc (for offline storage, with bad usability).
Another way would be a paper wallet (also safe but bad usability).

These 3 forms of storage are - by far - the most secure ones (if done properly).

This is not just theoretical. If the host machine gets compromised the VM has to be regarded as compromised too.




IF all of the critical data are ONLY stored inside a vhd (which is properly encrypted!) and you do NEVER decrypt this file on your pc, chances are high you would be fine.
But some attack vectors do still exist (e.g. buggy encryption implementation, some virtualbox exploit, ...). So this is not completely safe.

However, if you are referring to the windows password with 'administrator password', then this is absolutely NOT safe. Your virtual machine definitely will be compromised as soon as the host is compromised in this case.




There are quite some attack vectors.
Any backdoor (which gives an attacker full access to your machine) will reveal any secret information once you will boot your virtual machine.
You should not assume that you will instantly be informed once your machine gets compromised.

If your AV doesn't warn you (which it definitely won't if it is a proper 'self-made' malware), you will probably never realize that your system is compromised (until maybe your funds are gone).



If you want a proper secured setup either get a dedicated pc which only runs offline using linux, or a hardware wallet.
Your private keys have to be stored isolated from the online setup (which is effectively not done on a virtualized machine).

Running your wallet on a VM is definitely more secure than running it directly on your pc. But it is by far not secure enough to store amounts you are not willing to lose.
It just adds a small layer of protection (you basically assume the attacker is plain stupid and/or a script kiddie).

ATM's often do use some embedded windows as operating system 
Anything that runs on top is (most probably) not disclosed to the public.

I wouldn't be surprised if there were a ton of vulnerabilities which could be exploited with full access to the device.



They definitely keep logs, such as timestamps, duration, withdrawal/deposit, camera, etc..

This might be the reason.
You should make sure to always keep your software up-to-date.
Not that this will only guarantee you compatibility, but newer versions also contain bugfixes and security- or performance-improvements.

Make sure to get Armory 0.96.4 (https://btcarmory.com/0.96.4-release/) and core 0.16.2 (https://bitcoin.org/en/download).

mBTC stands for milli-BTC. So 1 mBTC = 1/1000 BTC or 1 BTC = 1000 mBTC.
You can change the unit by going to 'Tools' -> 'Preferences' -> 'Appearance' -> Change Base unit from mBTC to BTC.

This is simply just the deciption of your balance inside electrum.


Since you have 'just' imported the private key, you might consider creating a new HD wallet (which gives you a 12 word seed phrase as a backup) and send your funds over there (sweeping).
This way your old private key will be worthless, and your new wallet (backed up by 12 words) will hold your balance.