So it can be fully "air gapped"... it'll be for scanning QR Codes etc... aside from the SDCard there is no other way for it to be able to read data in... it doesn't have BT or USB.

Theoretically... that attack could be implemented on almost any HD wallet... I don't see how this would be limited to just hardware wallets? You would simply need to create a clone of "OpenSourceHDWallet"™ that generates keys from incredibly large indexes...

Although, if you can trick someone into downloading your malware, it's probably just easier to steal their Bitcoins directly with fake keys/seeds or sending to your own address rather than attempting to go down the ransomware route.



Also, I don't believe that the instance of coin loss in your 3rd reference is related to something like this given the evidence I found...

And in the 2nd reference... it looks like the "missing" coins might have eventually moved in this transaction (some 2 months after the original transaction): https://www.blockchain.com/btc/tx/b89f1fd84eb1c64dd77acbe05625c91438585ecb696cb3debf7033a88995a412

Not sure if that was the original owner or a thief/hacker tho! Or if that was the UTXO from the "bad transaction" as the OP seems to have removed TransactionIDs from and/or deleted posts and hasn't logged in since March... would be interesting to know if it was the OP... and if so, did they figure out where the coins went and how they recovered them??!?

I'm fairly sure I've seen NFC capable "hardware wallets"... as in, you hold the card next to your phone to be able to sign transactions etc.

Coolwallet.io is possibly the one I'm thinking of... but I also found nfcwalletcard, but I don't think that is what I was thinking of.

The technology is certainly available, so I'm sure someone is "working on it"

Probably the result of a typo... as, logically, given the pattern the dev was using, it should have been "tx3" being serialized.


I believe that the reason this code actually works is the way Python deals with mutable object references and they way they are passed into/out of functions... In essence, tx2 and tx3 are actually just references to the original "tx" object (although I'm not a Python expert, so feel free to correct me if I'm wrong!)...

So, when the code is passing "tx2" and "tx3" to the sign() function... we're actually using the original "tx" object. So when the (accidental?) serialisation of "tx" happens at the end, it all works out.

I concur with ETFbitcoin, if you're wanting to delve into the "technical" side of Bitcoin, then starting with Mastering Bitcoin is a good idea.

I'd also recommend firing up testnet (or regtest) and getting yourself some "free" coins and then simply try experimenting. Try the basics of sending/receiving... try handcrafting transactions... try multisig... try P2SH... try using the PSBT stuff... experiment with different wallets (again, on testnet/regtest) if you can.

And if you get stuck somewhere, or don't understand something, ask for help... There are plenty of knowledgeable folks around here

I have to say, I'm not an overly huge fan of the "new" receive tab in Electrum, to be honest... Seems overly complicated to just get a receiving address

Forcing users to create a "request" that has a description, amount and an "expiry date" seems somewhat convoluted and potentially confusing for something as simple as trying to provide an address to another party... and yes, I realise that you don't actually have to enter any of that information to create the "request"... but if you put all those boxes on the screen it seems to imply that you do.

Just to confirm for you what the others have indicated... Direct from Bitcoin Core in their Segwit Wallet Developers guide:


There is also a lot of other really useful information in that guide relating to Segwit.

And what error(s) or info is shown in "C:\Users\LE\Pictures\vcpkg-master\buildtrees\bzip2\msys-pacman-x86-windows-err.log"?

Anything useful that might give a clue as to why the bash.exe command failed?

In addition, you can also use https://jochen-hoenicke.de/queue/#0,24h to get some graphical presentations of the network "congestion"... by hovering over the right hand edge of the bottom graph, you can also get a rough idea of what a "good" fee rate might be...

If you aim around the 0.5MB mark, you'll "normally" get next block or 2... however there are caveats on that.

For instance, if the next block takes an hour to find, then you might find that your transaction has been pushed down the stack by the time the block is found, so you might have to wait some more. Also, this assumes that there aren't any prior unconfirmed transactions that your current transaction is relying on (such as in your case).

To prevent a similar situation in the future, it might also be worth seeing if there is a setting in your wallet that will prevent it from attempting to spend "unconfirmed coins".

I concur with Dave, Abdussamad and the others. The most likely scenario is that this wallet.dat is from some "Bitcoin compatible" altcoin.

If you load an altcoin wallet.dat in Bitcoin Core, it will show a Bitcoin address generated from the altcoin public key... You should be able to open (a copy of) the wallet.dat in a text editor and search for "name" (or use Pywallet etc)... that should show you the actual coin address and you might be able to figure out from the address prefix what the coin actually is.

Something like this: https://bitcoin.stackexchange.com/questions/19589/how-to-determine-what-type-of-coins-a-wallet-dat-contains

Oh... well in that case, I'd agree that it doesn't seem right. Are you still able to see the details (like the deposits, private keys etc) of the "old" session, once you have destroyed it and then been given the same token?

Oh, Yeah... true.

Hmmm, I had vague recollections that it would actually create raw unsigned transactions for you... I must be getting it confused with another website.

In my defence, it was "years ago" that all the fork craziness happened.

Glad that you managed to get it all sorted... and thanks for updating us on the result... I like happy endings and it's nice to know that we were able to help out.

Also, very happy to hear that Atomic have fixed this issue in their wallet!

It says on the initial page where the session token is issued (and all subsequent pages):
So, I suspect that the persistent session code is "by design"... Are you reconnecting within the 7 day period? Or are you still getting the same session token after the 7 days have expired?

I wouldn't mind finding out the answers to those questions myself... I suspect we'll never know... but I suspect that it is probably related in some part to Atomic being a multicurrency wallet and it's need to be able to generate different coin addresses from the same private keys etc.

Still, that's still some very very very VERY poor (as in non-existent) address validation

Don't forget you'll need room for the OS and applications etc... go 1TB+ if you can

Not actually necessary. You can store the bitcoin blocks wherever you want... you just need to configure Armory appropriately. For instance, I have my Bitcoin Core blocks folder in a "non-standard" location... but by setting the paths appropriately in Armory (using "in app" settings or .conf files), Armory is able to find them just fine

VERY important!


Also a very good idea.


I have tested it on ubuntu 18.04 LTS and it works OK.

I think I have worked out what they have done... and, if you can get the private key for the DOGE address, I think the BTC could be recoverable!


If we take the DOGE address and Base58Check Decode it:

and if we take the "mystery" BTC address and do the same:


Essentially, Atomic seems to have simply converted the DOGE address from Base58Check to HEX, then stripped off the DOGE "address prefix" (0x1e == "D") and the "checksum bytes", added the BTC address prefix (0x00 == "1") and then recalculated and appended the checksum and then converted from HEX back to Base58Check to end up with a BTC address...

Basically, if you can get the HEX Doge PK, you can get to the BTC address:

(Using Mikeywith's example)

DOGE PK:
QRw8xX9VAw67f9db8hqbN4EAWrj3Cwu1jZHDgoR6hg2nKBaKc7gD

--> HEX PK (using "wallet details" tab on DOGE paperwallet generator (TIP: click "skip" ):
6308E894B22395F94EF2E935762ADB9A4D5DCAAB672FAEDD51908FD24C6E2902



--> BTC (compressed) addy (using bitaddress.org):
14wUesWb7SgutWeem7YjSgZQEmSpUWKPm1



So, if OP can get the DOGE website to extract the DOGE private key, they'll be able to recover the full amount of BTC

If you just want the raw private key/address data... the "Bulk Wallet" tab is "cleaner". Functionally, it is identical to the paper wallet tab, just without the pretty pictures


As for the method of securing it by cutting and scrambling... I'm always a bit skeptical when people come up with their own unique systems for achieving this. It's hard to determine the actual level of security it gives without knowing the full process.

Can confirm... I had a similar issue until I updated to Electrs 0.8.5... it was the "fee return" error patched here: https://github.com/romanz/electrs/commit/e55381fa6643661c0dad2c454415ed997084a13d

Without it, the client just keeps disconnecting/reconnecting. Once you update and restart electrs, it should start working properly again.

THIS^^

So, you're likely to have more success using BIP39 seeds to do what you're trying to achieve... although that comes with the caveat that Electrum make no guarantees that they will always support BIP39 (although I don't see any reason they'd drop the support at this point in time).

As others have mentioned, it seems like you're trying to memorise your seed... while that is admirable, it is a risky strategy for securing your seed mnemonic and not recommended.