The console should not be "locked". The only things you won't be able to do without the passphrase is anything requiring the decryption of the keys (like signing transactions/messages or dumping the wallet keys etc)


Unfortunately no... even if you added a passphrase to an old copy of the unencrypted wallet.dat, it would just end up generating a different set of keys/addresses.


Correct. It will have already rescanned the wallet.


As this point, your best option would be to try and recover your wallet passphrase using something like: https://github.com/3rdIteration/btcrecover/

Or engaging the services of Dave @ wallet recovery services.
refer: https://bitcointalk.org/index.php?topic=240779
and: http://walletrecoveryservices.com/

Did you do this transaction twice?

I can see that 0.3246 BCH was originally sent to the address qpuefmag4yvpa87zssgurutt5fqwd6sg3st26cryqk in the transaction: 6a4dbcef8a9c1a97a41360cb7e814ca767423bca8fd38d3727ea673fe3017f72

This appears to be you buying $1000 worth of BCH in TrustWallet...


Shortly after, it was sent to the qpmu7mya83vtvrff8gg9gzz99pclff4us8rlx2fdp address in transaction: e6bef9af890531dfbe34d01e38f8faed6260b330903326dd6b2823e2fbd9ff55

This appears to be you trying to transfer the coins to "BitMart"

---

Then a few hours later... the address qpuefmag4yvpa87zssgurutt5fqwd6sg3st26cryqk also received 0.38670561 BCH in transaction: 1e4ab37d54e95763074a55a351e8cb21f14c1fead57edd5e678d46b0eb723298

And then that was also sent to the qpmu7mya83vtvrff8gg9gzz99pclff4us8rlx2fdp address in transaction: d74d74e9e8555b2b1eadd231c9beeaad55d2cc4efec86fb4d8950cf0baca5ba6

So, it's like the same $1000 transaction was made twice... and sent to qpmu7mya83vtvrffv8gg9gzz99pclff4us8rlx2fdp.

---

In any case, BitMart is an exchange with a custodial wallet... so you'll need to contact BitMart support and ask them why your deposits of BCH to qpmu7mya83vtvrffv8gg9gzz99pclff4us8rlx2fdp are not being reflected in your BitMart account.

I would also you double check that your BCH deposit address in BitMart is actually qpmu7mya83vtvrffv8gg9gzz99pclff4us8rlx2fdp.

---

NOTE: I found this: https://www.trustpilot.com/review/www.bitmart.com

Seems that this BitMart.com might be a scam or has very very very poor customer service. Lot's of stories of delayed deposits, delayed withdrawals and support tickets not being answered for days etc

Yeah, definitely be better off using RegTest... you don't need to change/recompile anything... it's basically an "instamine" and you can freely test whatever you want. Refer: https://developer.bitcoin.org/examples/testing.html#regtest-mode

recov_device should just be the drive letter (in windows) if you want to check an entire drive... you don't want to specify a "file"

Try:

When the wallet.dat gets encrypted... for safety reason, it resets the seed/keypool, generates a bunch of new keys/addresses and then "archives" the old keys/addresses (marks them as inactive so they don't get "used" when you generate a new address to receive or for change).

That might explain why your old (pre encryption) backup is not showing all the transactions... new keys/addresses would have been generated after the encryption was set and coins have been received on the new addresses that the old wallet.dat does not have.

However, it's interesting that you say both wallets show exactly the same transactions? But a difference balance? I could only guess that it's because you sent some coins... and the old pre-encryption wallet does not have the change address from the new post-encryption wallet... so, it thinks that both UTXOs created were going to external wallets.

You could probably confirm that by using the getaddressinfo command (on the console in Bitcoin Core) with the "change" addresses shown in the most recent send transactions on both instances of Bitcoin Core and checking the "ismine" value... it will probably say "true" on the VM (with the encrypted version of the wallet.dat)... and "false" on the old unencrypted version (as it doesn't have those keys/addresses).

Your problem really has nothing to do with the OPs original issue... it seems you have followed a tutorial for Electrum Personal Server and it has had unintended consequences for your Bitcoin Core wallet.

You should really start your own thread, rather than hijacking this thread.

It's to prevent the node from rebroadcasting in the event that Tor is disabled/not available. It's like a "safety"... it means your privacy won't be compromised if your Tor is down for whatever reason... the node won't "accidentally" broadcast any of your transactions over clearnet.


No, it should do the opposite as it just prevents the wallet part from broadcasting (or rebroadcasting) transactions...


Theoretically, you could use the RPC functionality to broadcast the transaction, as the node will still be able to send/relay transactions etc... it's just the actual wallet part of Bitcoin Core that won't "send"... or you could also try using a script like this: https://github.com/laanwj/bitcoin-submittx which seems to have been purposely designed for working with "walletbroadcast=0" configs.

Yes... the website to use is here: https://btcarmory.com/
The github is here: https://github.com/goatpig/BitcoinArmory


Yes.


Soon™

Why do you care? What does what I have or haven't done have to do with your situation?


I honestly have no idea what you're even talking about here?

BCH -> Use Electron Cash
BSV -> Use ElectrumSV
BTG -> USe ElectrumG

What exactly are you confused about? "When" you claim them really makes zero difference to the processes required... it doesn't matter if you did it the hour after the fork happened... or tomorrow.

The only difference will likely be in the value of the coins.

I don't understand it either...

The "offline" computer is nothing more than a repository for your seed/private keys and used to sign transactions that are created on your "online" machine (which will have the updated balance/transaction history).

It's like a hardware wallet. Your hardware wallet doesn't need your transaction history or current balance to be able to sign a transaction.

Why would you keep your "everyday" hardware wallet and your "backup" hardware wallet in the same place?

You're effectively putting all your eggs in one basket, so doing that will only really result in a backup from hardware failure of the first device... but likely won't help in the case of fire, flood or theft.

Also, why not just use the same PIN on both devices?

What "flavour" and version of Linux are you actually trying to run this .AppImage on? ie Is it Ubuntu 18.04? Ubuntu 20.04? Fedora? Arch?

Maybe... but I would think that the phrase is more likely used to indicate that while their Galaxy devices will have a Samsung software wallet available and that this wallet will be compatible with hardware wallets... there won't be a Samsung hardware wallet available... and you'll need to use 3rd-party devices.

Whenever the device is powered up, it will ask for a PIN.

It doesn't matter what it is connected to... it could be a USB port on pc, laptop or mobile device... it could be a USB wall charger... or even a USB power bank... as long as it is getting 5V (USB standard) it will power up.

Once it has booted it will ask for a PIN. It only "counts" PIN attempts when you click both buttons when the ✓ symbol is shown on the screen to "enter" the guess. If you disconnect and power down the device before clicking both buttons, then it isn't counted.

If you can find a shredder that will handle the box without jamming, sure... imo, fire is still the best option... but then, I'm something of a pyromaniac


Same as the box... if you're not using them, then they should probably be destroyed as well.

It isn't exactly a "3rd party" service... "SeedPicker" is simply an (open-source) tool that basically bruteforces the 24th word for a BIP39 seed phrase when you give it the first 23 words...

Like it encourages you to put 342 pieces of paper into a bag and "randomly" draw one out, then pick 1 of 6 words on the paper by rolling a die to get 23 words, then bruteforce the 24th using their tool

imo, it's still a terrible idea... 24 word seeds aren't chosen by selecting 23 words and then bruteforcing a 24th... they're created by generating 256 bits of Entropy and then encoding that using the BIP39 algorithm and wordlist.

I have no idea what the entropy of pulling pieces of paper out of a bag is... but I'm not convinced it is going to be 256bits worth!!?!


So, I concur with the OP that you'd be much better of using another hardware wallet like a Trezor or Ledger or even an airgapped BIP39 compatible wallet (Electrum on a LiveOS etc) to create the "3rd" seed/key etc:


As for this:
It's not really dependent on the quorum really... in that m-of-n will always require (a minimum of) "m" seeds and "n-m" xpubs... it doesn't really affect how many copies of each seed should be stored.

So it really depends on your personal risk tolerance, I guess... for 2-of-3, as long as you have access to at least some combination of 2 seeds and 1 xpub (where they are all from different "co-signers":

SeedA, SeedB, xpubC
SeedA, xpubB, SeedC
xpubA, SeedB, SeedC

Then you could easily recreate the wallet and sign transactions.

What is the balance showing as in your "bitcoin.com" wallet?

That address is most likely a "change" address that is controlled by your wallet... However, unfortunately, the bitcoin.com wallet (a truly terrible wallet, btw ) does not give you an easy way to "see" your change addresses.

One option would be to take the 12 word recovery phrase for your BTC wallet and import it into a wallet like Electrum (you need to use the "BIP39 seed" option in Electrum) and then check the addresses shown in Electrum. If you can see the "1JMW9B..." address listed as a "change" address, then you're fine... you can still access the coins.

Alternatively, you can just check the current balance in your bitcoin.com wallet... does it look like the full 0.008917 BTC amount was deducted from the balance BEFORE you sent the transaction? Or has your balance only reduced by 0.00185387 BTC?

Also, to learn more about "change", how and why it exists... you can refer here: https://en.bitcoin.it/wiki/Change
and here: https://en.bitcoin.it/wiki/Coin_analogy

Try reading the instructions here: https://btcrecover.readthedocs.io/en/latest/Extract_Scripts/#blockchaincom-second-passwords

You basically just run btcrecover with the --data-extract option instead of the --wallet option and specify all the other options (tokenlist, typos etc)... refer: https://btcrecover.readthedocs.io/en/latest/TUTORIAL/ for instructions on the various options you can use for trying to bruteforce the password... when prompted, input the second password "hash" that was extracted and the script will then attempt to bruteforce the password.

There is a blockchain.com specific example here: https://btcrecover.readthedocs.io/en/latest/Usage_Examples/2020-05-08_Recovering_Blockchain_Wallet_Passwords/Example_Recovering_Blockchain_Wallet_Passwords/

and a youtube tutorial here: https://www.youtube.com/watch?v=eS0VUl3w69Y&list=PL7rfJxwogDzmd1IanPrmlTg3ewAIq-BZJ&index=11

Create a new wallet in one of the Bitcoin SV wallets... or hold in on an exchange that supports Bitcoin SV.

Those are your only options.

Note that ledger apparently supports SV if you use the "Bitcoin Cash" app on the device and ElectrumSV: https://support.ledger.com/hc/en-us/articles/360012270054-Bitcoin-SV-BSV-

You just can't use Ledger Live.


Also, there are probably "replay protection" issues with BSV and BCH etc... you're on your own with that... I don't use either of these shitcoins. Try Google, there are plenty of "how to" guides.

As far as I can tell... the problem you're going to run into is that the "xprv" that you have access to in the Electrum wallet is going to be an "Account Extended Private Key" derived from your 12 word seed... and not the actual BIP32 "root key".

This means that the derivation path for this extended key will be the equivalent of the BTC derivation path of m/44'/0'/0' (or m/49'/0'/0' or m/84'/0'/0', depending on if it's using Legacy, Nested Segwit or Native Segwit respectively).

Now, according to this post by "coinbasesupport" on reddit: https://www.reddit.com/r/CoinBase/comments/i5sl3b/mods_is_coinbase_commerce_bip39_bip44_complaint/g7x6vnp/
It would seem that the ETH (and ERC20 token) payments eventually end up in the address derived at m/44'/60'/0'/0/0


As these derivation paths are all hardened, you cannot derive the m/44'/60'/0'/0/0 address starting from the m/44'/0'/0' derivation path that the extended private key stored in the Electrum wallet represents.


TLDR; There is simply no way you can get from "what you have" to "what you need"

Yes


Should move the more valuable coins first... and work down in value... not the other way around.


Check the coinmarketcap page for Bitcoin SV... click the "market" button and you'll find the exchanges that support Bitcoin SV:
https://coinmarketcap.com/currencies/bitcoin-sv/markets/


refer: https://help.coinbase.com/en/coinbase/getting-started/crypto-education/bitcoin-gold-faq

Seems like they just didn't support BTG.