The test_bitcoin binary should theoretically run without error. If something has failed, then it's possible that something in your setup/config might cause issues further down the track... it's difficult to say without further investigation. you could try: ./test_bitcoin -p -r detailed > output.txt
And then check output.txt to see if it gives a more detailed report of where and possibly why it failed. |
|
|
|
Yeah, you'll likely need to start messing about with hex/byte level stuff to see if you can locate the private key data within the wallet.dat. When you say it was an "old" wallet.dat, did you find it on an old drive/backup... or was it recovered using file recovery software (ie. a "deleted" file)?  |
|
|
|
I formatted the drive to ext4 and it still wouldn't work, but now I was able to chown /mnt/bitcoin so I finally started IBD!!
That is a very strange outcome... when you "formatted" it, did you completely remove all the partitions and start from scratch, or did you just format the existing partition? I'm guessing that the old vfat system just wasn't handling the file permissions properly... glad you at least managed to get the IBD underway!  |
|
|
|
Another question: I intend to install electrs on the Pi, should i create a different directory on the ssd for bitcoin datadir and one for electrs or just have them all together?
Personally, I would create a separate directory for the electrs data... it's just a cleaner setup and means that should you want to change to a different Electrum server solution later on, it won't mess up your Bitcoin datadir. |
|
|
|
If I have a free weekend I might actually enjoy setting all of it up manually :-) Do you know which services are available on the blitz but not on the bolt?
There isn't a definitive Blitz vs Bolt list that I have seen anywhere... I dare say that Blitz includes a number of "add-ons" or extra features that Bolt doesn't like the "stacking sats on kraken" script etc. Bolt is definitely the bare-bones DIY solution... Blitz is a bit more polished and somewhat "automated", imo |
|
|
|
It seems the issue is only for 4.1.4 because I can able to make a new wallet on an older version look below.(Luckily not yet upgraded to the latest version) https://talkimg.com/images/2023/11/14/zFWxP.pngThe button is not greyed out unlike yours. Is that screenshot from when you click the "[-]" button on the initial "Password" screen when you start the app? Or after you have already entered your wallet password and clicked on the "3 dots" -> "Wallets" menu in the app? |
|
|
|
I am running pywallet on a copy of the wallet.dat that I already attempted to -salvage.
In that case... it might be better to make another copy of the original... and then see if PyWallet is able to parse that or if you get the same error. If you still get the same error, then it's possible that the recovered wallet.dat db structure is simply too corrupted for PyWallet to be able to read properly  Recovery gets quite a bit more difficult if that is indeed the case |
|
|
|
Trezor have released the new version of their Trezor Suite: https://blog.trezor.io/trezor-suite-update-onboarding-and-rbf-by-output-reduction-f578c0ce9a1eThe onboarding updates look good, and hopefully prove useful to new users, but what piqued my interest was that they've updated the RBF feature to allow you to bump the fee by reducing the output amounts. As they note, this means that transactions that generate no change can also make sure of the RBF feature now. That's a win! Lastly... a slightly curious difference in language: Email announcement: Soon Trezor Suite will become the only portal for managing your coins securely and privately.
Blog announcement: Soon Trezor Suite will be the main portal for managing your crypto
emphasis added by me.The former seems to imply that Trezor Suite will be the only way to use your device... or were they attempting to say, somewhat poorly, that they're trying to make Trezor Suite a "one stop shop" where you can do everything (buy/sell/trade/send/receive etc) if you want? |
|
|
|
|
It should be noted... that the datadir option will, in addition to the block data, also move all your wallet and other associated application data onto the external drive. If you don't want your wallet file(s) stored on the external media, you might want to use the blocksdir option instead.
|
|
|
|
Unfortunately, I am unable to replicate this with a Mint Cinnamon 20.1 VM... even after changing the display settings etc. Are you able to manually reduce the window size by dragging the corners/sides of the program windows? If so, are you able to resize it, then shut the application down and restart it... does it automatically blow out the size again? or does it maintain the window geometry? Given that your other apps are all working OK, I'd say that it could quite likely be an issue with the Bitcoin Core code... apparently there is a -resetguisettings command line option... give that a go and see if it fixes things. If not, maybe try running an even older version of Bitcoin Core like 0.18 (again with the -regtest) and see if it is broken as well. |
|
|
|
|
RaspiBlitz is a nice solution, has been refined quite well, but the cost is a bit more if you go with the touchscreen setup... I'd also recommend RaspiBolt if you don't currently have the touchscreen hardware and want a cheaper "headless" solution.
The RaspiBolt project is also pretty solid and has pretty minimal requirements being just the Pi, powersupply, microSD + storage drive.
|
|
|
|
im using Linux Mint 20.1 Cinnamon
Ok... and did you make any changes to the display settings or workspace setup etc? Or is it all running at the "default" values from install? Just asking as I was going to quickly create a VM and see if I can replicate the issue |
|
|
|
|
I would say that you should try to avoid using the actual physical disk as much as possible. So, you should create a raw image of the drive first... then use that raw image for your data recovery activities.
As for where the software was installed would be dependent on the OS that you were using at the time.
Windows uses the %AppData%/Bitcoin location for data storage... something like C:\Users\USERNAME\AppData\Roaming\Bitcoin
In Linux it would likely be in ~\.bitcoin (ie. /home/USERNAME/.bitcoin or similar)
Of course, what you're looking for is the wallet.dat file... that's what you'll need to find to have any chance of recovering any coins, as that is where the private keys will be.
|
|
|
|
Which "Edition" of Linux Mint 20.1 are you currently using? Is it the Cinnamon, Mate or Xfce edition? I'm wondering if it is some weird conflict with the specific desktop environment you are using. |
|
|
|
|
Ahhhh so that explains it... while investigating an issue for another user on the Android Electrum, I noted that you couldn't create a new wallet until you had unlocked an existing wallet. I thought it was strange and had made a mental note to go back and investigate further thinking that it might be a bug (and then promptly forgot).
I had not realised they had moved to a unified password system. Honestly, I don't really see an issue with it... it kind of makes sense on a mobile device... and most wallet apps have a single PIN or similar to access the app etc. anyway.
|
|
|
|
The latest versions of Bitcoin Core come with a binary executable called "bitcoin-wallet" (or bitcoin-wallet.exe on Windows). It should be in the same package as bitcoin-qt, bitcoind and bitcoin-cli etc. This now contains some "wallet" functionality that was removed from the bitcoin-qt executable... one of those being the "salvage" functionality. Bitcoin Core bitcoin-wallet version v0.21.0
bitcoin-wallet is an offline tool for creating and interacting with Bitcoin Core wallet files.
By default bitcoin-wallet will act on wallets in the default mainnet wallet directory in the datadir.
To change the target wallet, use the -datadir, -wallet and -testnet/-regtest arguments.
Usage:
bitcoin-wallet [options] <command>
Options:
-?
Print this help message and exit
-datadir=<dir>
Specify data directory
-wallet=<wallet-name>
Specify wallet name
Debugging/Testing options:
-debug=<category>
Output debugging information (default: 0).
-printtoconsole
Send trace/debug info to console (default: 1 when no -debug is true, 0
otherwise).
Chain selection options:
-chain=<chain>
Use the chain <chain> (default: main). Allowed values: main, test,
signet, regtest
-signet
Use the signet chain. Equivalent to -chain=signet. Note that the network
is defined by the -signetchallenge parameter
-signetchallenge
Blocks must satisfy the given script to be considered valid (only for
signet networks; defaults to the global default signet test
network challenge)
-signetseednode
Specify a seed node for the signet network, in the hostname[:port]
format, e.g. sig.net:1234 (may be used multiple times to specify
multiple seed nodes; defaults to the global default signet test
network seed node(s))
-testnet
Use the test chain. Equivalent to -chain=test.
Commands:
create
Create new wallet file
info
Get wallet info
salvage
Attempt to recover private keys from a corrupt wallet. Warning:
'salvage' is experimental.
As always, work on copies of the wallet.dat and not the original file. |
|
|
|
If truly this wallet do not generate seed phrase, I do not think it should be a good wallet to use. Although, I saw something like in-app backup.
The wallet does use a seed phrase... but it's not shown to the end user, and there is no way in the app to get it to display. However, it is possible to decrypt a wallet backup to get hold of the seed phrase. If you create a wallet backup in the app, you can decrypt it using OpenSSL: openssl enc -d -aes-256-cbc -a -md md5 -in bitcoin-wallet-backup-YYYY-MM-DD -out decrypted
This creates a decrypted copy of the binary wallet file named 'decrypted'... I believe it is a BitcoinJ compatible wallet file format. In any case, you'll be able to see the 12 word seed in plaintext shown at the top of the file like this:  or use a text editor to view. Alternatively, you can use something like this to extract the seed: https://github.com/gurnec/decrypt_bitcoinj_seed |
|
|
|
Hi, I have some funds on an old wallet that only has legacy addresses. Unfortunately, Electrum does not accept legacy deposits.
I read that there is a way to create a legacy wallet on Electrum on the desktop.
How can I do this on the Android app?
While the Android app (like the desktop version) doesn't support creating legacy wallets by default... There is a way to force the desktop version to generate a "legacy" seed. You goto the console in the desktop app and use: make_seed(seed_type="standard")
That'll give you something like this: >>> make_seed(seed_type="standard")
"soap advice amused owner toast bacon sound giant submit must index glory"
>>>
and then you simply use the "I already have a seed" option when creating a "standard" wallet in the Android app and enter that seed. This will generate a legacy wallet full of "1-type" addresses  But, as others have noted, there is technically no reason that you can't send from ANY type of Bitcoin address to ANY other type of Bitcoin address... the limitations are generally just because the wallet devs haven't updated the wallet (be it web, desktop or mobile app etc) to support the bech32 (aka "bc1") addresses that Electrum defaults to. |
|
|
|
Or just purchase one of the current MBP's that still have a bunch of intel chips before they stop offering them?
Well... that's certainly a viable option if you're going to be happy using the older hardware... especially if you can get a good deal on them. I can't speak to what Apple are considering doing with the support of the older Intel-based systems now that they are making their own silicon... but they have usually been "pretty good" with that sort of thing. I mean, when they did the last silicon swap (PowerPC -> Intel), the support was ongoing for something like 7 years!  Additionally, the transition is scheduled to take place over 2 years or so... so it really shouldn't be an issue in the near term. |
|
|
|
|
Honestly, those numbers really do seem surprisingly "good"... I guess that is not entirely unexpected given that, while it's not explicitly stated in the BIP itself, I vaguely recall reading somewhere that they were trying to balance "cost" with "user experience".
The idea being that it would "slow" attempts to bruteforce, without making an enduser have to wait for stupid amounts of time while just trying to use the system "normally"... remembering that regardless of whether or not a user explicitly specifies a passphrase, there is still a default "passphrase" value used.
|
|
|
|
|
Show Posts
