Does the Core Client perhaps need the blockchain? Or does it open the old wallet without it?
It's not useful to open the wallet without having access to the blockchain and the network. Without those, transactions cannot be received or sent. |
|
|
|
Hi people. I got years trying to restore my wallet.dat file. I think it has 0.02 btc or something like that.
I tryed intallis bitcoin core 25 (actual version) but it tellsme that the wallet restoring file is from another chain.
Either your wallet is incorrect, or your wallet is indeed for a different chain. The error is unlikely to be wrong. Tons of altcoins begin by forking Bitcoin Core. They will all have wallets named wallet.dat. It's possible that your wallet is for such an altcoin. |
|
|
|
Yeah but I want to know what to do when Bitcoin Core stops wanting to open good ol 2013 wallets. Do I just run these 2 by then and we are good?
There will never be a point where Bitcoin Core refuses to open an older wallet without any additional information. The plan for removing support for legacy wallets includes a migration step that will still work even after the removal has been completed. This migration will remain in Bitcoin Core probably for the rest of time, so if you have an old wallet and open it in a future version, you would get a message informing you to perform the migration so that it can open the wallet. |
|
|
|
ok clear, will try things out.
i guess i need to save the xpriv from the `listdescriptors` command, right?
You need to save everything, not just the private key. Otherwise you are throwing away information that is necessary for restoration. If you do not save the entire descriptor, you lose the derivation path information and the address types and will have to guess those in the future. Backups are much better when they contain all of the information necessary in order to rediscover your funds. if i may take advantage of your generosity, can you explain this (i take my previous points):
- i sent some sats to some address that were in the dumpfile, *bc1..abcd*
- if i do 'getaddressinfo' of the *bc1..abcd* address i sent money to it tells me 'ismine: false'
That address is derived from the master private key that itself is derived from the seed. Since you have not done sethdseed but rather just imported the seed as a normal private key, these derivation steps have not been done. The wallet does not know that the private key you imported is actually a seed and that it needs to do derivation on it. So all addresses that are derived from it are not known by your wallet. i don't have a full node to test this at the moment:
- is the money gone?
- or will it have the ability to 'see' that address balance if i run a node?
It is not gone. However you need to make the wallet aware of the fact that you have a seed and not just a single private key. |
|
|
|
If you had a wallet.dat that was never updated to the new format, and wanted to move to the 25.0 version, does it require any special steps or anything?
The last version I used was around 23.0. I haven't updated since then. I reckon at some point there was some sort of an update on the wallet format that was performed automatically and you didn't have to do anything, not sure if around 0.15 era when segwit was introduced, so im assuming that was applied on the wallet file, but now with the descriptors thing, I've seen some people discussing doing some additional steps. Im old fashioned and I haven't even locked at what the ordinals thing are yet. I use legacy addresses, but had to update because some people request bech32 addresses. As far as I can use Coin Control and generate legacy and bech32 addresses, I would be ok, but im assuming it's best to update for security reasons as bugs get updated. I just don't want to screw up an old wallet in the process. Of course I have backups before any of this is done, but I would like to know if any additional steps are required and why.
If it is a non-HD wallet, upgrade it with -upgradewallet (introduced in 0.17+, I believe). Then use -migratewallet in 0.25 to upgrade to the descriptor wallet. So could someone confirm that this is all one has to do? I would prefer to avoid mistake here. Im going to keep using the old wallet for as long as possible until I know exactly what im doing. I've never had any problems, and I make backups all the time, so the lack of HD was never an issue (because of the limit o addresses being saved thing). Im also not going to be using any features beside simple transactions. And I do not want to move any funds, so sending tx's to myself in other addresses isn't an option. Recent versions of Bitcoin Core maintain backwards compatibility, you can just open the wallet with them and it should all work. There are a few background upgrades that will occur but these are all backwards compatible (you'd be able to downgrade with no ill effect). If you do not use upgradewallet or migratewallet, then no backwards incompatible upgrades will occur. Otherwise, your wallet should still open and work as you expect it to. |
|
|
|
so would that mean that a paper wallet can't be done anymore?
Bitcoin Core has never supported paper wallets. In any case, single key paper wallets will work with descriptor wallets since they are single private keys. A HD seed is not that. what are other solutions that do not imply saving a file?
Exporting and storing the descriptors of a descriptor wallet. plus, i read the legacy wallet option is going to be removed from the bitcoin core, so that wouldn't be a long term solution.
Yes, it will be. However there are plans to reintroduce sethdseed in some form so you could still store just the seed. But that's still not exactly sufficient as you don't have information about derivation paths and scripts. Descriptors contain all of that information, so I recommend you store those. consider i want to do something that would last forever. what would you do?
Nothing is guaranteed to last forever, but something that follows published standards is certainly more likely. The legacy wallet's HD seed stuff most certainly does not follow the existing standards. I would suggest using a descriptor wallet and writing down the descriptors. While it's a lot more verbose, it is also much more complete and will not rely on guesswork in the future. You could also just do a standard BIP 39 mnemonic, but keep in mind that these do not contain derivation path or script information, and they are not (currently) supported by Bitcoin Core. |
|
|
|
The HD seed cannot be used in a descriptor as a seed. Using it in a descriptor as you have results in an address with the seed as the private key, not the seed as a seed and then doing derivation on it. If you want to use the seed in a descriptor wallet, then you will need to compute the BIP 32 master key from it, then specify the derivation paths for deriving the child keys from that master key. Note that the seed is a BIP 32 seed ( S in this diagram: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#user-content-Master_key_generation), not a BIP 39 seed phrase or mnemonic. In general, Bitcoin Core does not intend the seeds that it produces to be handled by people directly since they are incomplete information for restoring a wallet. You should instead be backing up entire wallet files and restoring them when you need to restore backups, rather than trying to find an individual component of the wallet. If you insist on using the seed, you need to create a legacy wallet and use the sethdseed command. Then you will get the addresses that you expect. Then you should migrate that to a descriptor wallet. However, after migration, the seed will not be used by the wallet anymore. New descriptors are generated which essentially replace that seed. |
|
|
|
|
Your options are to either choose different inputs that do not have so many ancestors, or wait for some ancestors to become confirmed.
As the error says, there are too many unconfirmed ancestors, and the limit is 25. This is the default that most nodes have, so your transaction is unlikely to propagate even if blockcypher accepts your transaction. You need to reduce the number of ancestors, either by removing the inputs that have unconfirmed ancestors such that the number of unconfirmed ancestors is below the limit, or wait for some of those unconfirmed ancestors to confirm.
|
|
|
|
After syncing the headers it has just started downloading all blocks from the beginning  Could it not be recognising the blocks folder at all if it seen as corrupt? Why do you assume that it is downloading all blocks? When it is reindexing, it will say something about syncing, but there won't be any network activity. You should be able to disable networking (either OS, or in Bitcoin Core) and it will still continue to be "downloading". |
|
|
|
|
Yes. Bitcoin Core uses features that are not available in older compiler versions, notably C++17 and C++20.
|
|
|
|
What version of MacOS are you using? Possibly the same issue as https://github.com/bitcoin/bitcoin/issues/28552Is there any way of recovering the block database without downloading the entire thing from scratch?
Rebuilding the block database doesn't redownload anything. It is reading all of the blocks from disk and building the block index, so the software gives the same progress bar as syncing, but no downloading happens until it reaches the end of what's on disk. |
|
|
|
This content still holds true for a older version of Electrum wallet and it might be needed by Users of older versions of Electrum.
However, the new Version now supports an Automatic RBF inclusion for every transaction made so there's always a chance to replace or simply Bump transaction fee if the need arises for all Electrum Wallet Users
Updated to say that opt in RBF is always on. Can my name please be removed from the OP? I have not been able to help with stuck transactions for years and still receive messages asking for help
Done. Updated that section in general to point to the services rather than to specific people. |
|
|
|
|
I've unlocked that thread. If you have any suggestions for how to update it, please post there.
|
|
|
|
I created with ord command-line
Then you need to look at ord's documentation, and probably be using it to send as well. The private keys are not in Bitcoin Core so there's nothing that you can do with it directly to send. |
|
|
|
|
How did you create this wallet? It does not have private keys enabled, so you will be unable to sign any transactions.
|
|
|
|
|
Are you certain that all of the inputs that you have specified belong to the wallet? You have the correct vout values? When you used listunspent, did it say that those utxos are spendable?
Can you also post the output of getwalletinfo?
|
|
|
|
|
Please provide the debug.log file.
|
|
|
|
If not, suppose I send out a transaction that's time-locked to 1 day/month/year/decade into the future. To what degree of certainty will my transaction be eventually be included in a block?
Your transaction is basically guaranteed to never be included in a block if all you did was broadcast it before the locktime was reached. Nodes do not accept or relay transactions which cannot be included in the next block. If you broadcast a transaction with a future locktime, basically all nodes would drop it. Besides that, nodes will also evict transactions that have been unconfirmed for too long (typically 2 weeks as that is the default in Bitcoin Core). If you had a transaction with a timelock greater than 2 weeks in the future, and it was somehow accepted into some node's mempool, it would be dropped before the timelock was reached. |
|
|
|
Bitcoin Core doesn't know how to sign non-standard scripts. Script is not easy to analyze, so Bitcoin Core sticks to specific templates and patterns that it can analyze. Your script does not follow any of those patterns, so it is unable to produce any valid signatures. Furthermore, since it doesn't recognize the script, it will not place it in the witness. Thus the transaction you get after using signrawtransactionwithwallet is completely unsigned, and in fact, identical to what you passed in. Thanks, noted. Does this mean every unlocking script in a P2WSH transaction is non-standard? If yes, does this mean P2WSH redeem scripts are not broadcasted by every client that only broadcasts standard transactions? No, nodes do not inspect the contents of redeem or witness scripts for standardness checks. Perhaps a better term would be "well known script template". |
|
|
|
|
Show Posts
