|
It's complicated.
The version number is stored as a signed integer. However, in every single place that it is being used, including in consensus code, it is being cast to an unsigned integer. So the RPC also does that since it's only ever actually interpreted as an unsigned int.
It probably should just be changed to an unsigned integer, but I think there was some discussion about that and there were fears that there may be some unintended side effects. Since it is consensus critical code, it could lead to consensus failure if something was overlooked.
|
|
|
|
|
There are tests, and those are passing, so it does work. Either you got the wrong block hash, or your node was missing the block, possibly because it pruned it. Do you know if pruning was enabled? You should be able to discover this by looking at your debug.log. Note that txindex=1 doesn't work with pruning, so your node is no longer pruned if it was in the past.
|
|
|
|
|
Does Bitcoin Core have the block whose hash you provide? Can you getblock it?
|
|
|
|
|
It's kinda hard to write a decoder that can tell you what went wrong. That generally requires being able to do analyses and identifying patterns - things that are a lot easier for humans to do. There's also the aspect that you know what you intended on doing and so can spot what is wrong, whereas a decoder probably doesn't know what you were trying to do. Usually I just decode by hand for these kinds of problems.
|
|
|
|
but there are multiple wallet addresses in wallet.dat
When encrypting wallet.dat, shouldn't we think only on a file basis? For example, if a wallet.dat has 5 wallet addresses, we cannot say that we only apply AES.256.CBC for one wallet address and do not encrypt the remaining 4. so the operation with password applies to the entire file. not for the address.
Each private key is encrypted individually. The wallet file is not encrypted as a whole. |
|
|
|
|
It uses the first 16 bytes of the double sha256 of the public key as the IV.
|
|
|
|
|
So DNS is probably working, but it seems like it isn't actually able to connect to anything.
Are you able to reach other tor hidden services with that machine? I've also tried to connect to your node from mine but it is unable to reach it.
|
|
|
|
Here's dig's output:
dig for a particular domain is more interesting, e.g. dig seed.bitcoin.sipa.beEdit: Just stopped again: 2024-01-13T19:37:11Z UpdateTip: new best=0000000000000000000240f175b8c1d2be32786af8fcad523989f39733c8ec91 height=825246 version=0x20400000 log2_work=94.658582 tx=950438404 date='2024-01-11T05:27:27Z' progress=0.999320 cache=217.7MiB(1461058txo)
2024-01-13T20:08:41Z Potential stale tip detected, will try using extra outbound peer (last tip update: 1890 seconds ago)
2024-01-13T20:19:11Z Potential stale tip detected, will try using extra outbound peer (last tip update: 2520 seconds ago)
2024-01-13T20:29:41Z Potential stale tip detected, will try using extra outbound peer (last tip update: 3150 seconds ago)
2024-01-13T20:40:11Z Potential stale tip detected, will try using extra outbound peer (last tip update: 3780 seconds ago)
2024-01-13T20:50:41Z Potential stale tip detected, will try using extra outbound peer (last tip update: 4410 seconds ago)
There were some improvements made to stalling detection behavior made in the last year. Can you try using 25.1 or 26.0? |
|
|
|
|
It looks like the DNS server you are using isn't returning any responses for the DNS seeds. Have you specified any particular DNS server? What response do you get if you get DNS records from the DNS seeds with dig?
|
|
|
|
and also when we consider that both RegTest and SigNet exist and both used to have the fRequireStandard set to true Yes, I agree, this change is quite strange. Because now, when I have regtest with non-standard transactions, then they are not relayed anymore, which means, that if you spin two regtest nodes, then they will synchronize only block headers. How to reproduce: 1. Start this version of Bitcoin Core, 26.0. 2. Connect two regtest nodes with default settings. 3. Use 'generatetodescriptor 1000 "raw(51)#8lvh9jxk"' to generate blocks, sending coins into OP_TRUE. 4. If you apply acceptnonstdtxn=1, then everything is synced, but if you apply acceptnonstdtxn=0, then only block headers are. As far as I checked, the same happens on master, because one of my clients is running 26.0, and I have 26.99 client compiled locally. acceptnonstdtxn should only affect transaction relay, not block relay. Blocks can always include non-standard tranasctions. |
|
|
|
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". |
|
|
|
|
Show Posts
