I tried to run it with -salvagewallet option, but client window just closes after launch and in db.log there is a message "path/to/wallet/wallet.dat: unsupported btree version: 10".
How old is this wallet.dat file? What's the creation date? A long time ago, the wallet.dat format was changed so very old wallets are not compatible with modern versions of Bitcoin Core. I suspect that is what you are running into here. |
|
|
|
|
wallet.dat is the wallet file for wallets based on Bitcoin Core. Typically it refers to a Bitcoin Core wallet, but other coins that have clients based on Bitcoin Core will also create wallet.dat files. There's a good chance that it is for Bitcoin Core.
If the wallet cannot be opened in Bitcoin Core, it may be corrupted as is indicated by Bitcoin Core. You can try starting Bitcoin Core with the -salvagewallet option in order to attempt a wallet recovery. You should of course make a backup of the file before actually doing that.
|
|
|
|
Now suddenly bitcoin folder's size become over 2 giga, almost take all the empty capacity (total 20giga hdd inside virtualbox), system become unstable, even all apps does not appear, can't run terminal itself.
By "bitcoin folder" do you mean the folder containing the source code or do you mean the datadir? |
|
|
|
1.I disagree as soon as the blockspace is increased it changes the pricing structure. it's a simple mathematical statement. I don't understand how you can deny it logically. What ever the modification to the max txs per block will have an impact on the fee. So if txs more to segwit it means less for blockspace or what ever the system off chain (and true I didn't read the bip). I mean it isn't on chain, on the block chain as intented by satoshi and us when we joined. I mean it was clearly all txs in a block every 10 min, the block 1mb, no one can change that blah blah... then saturation.
I never said that it wouldn't effect fees. I said it does not effect fee calculation. Segwit transactions are still on chain and fees are still basically calculated in the same way (some constants change). It does not suddenly become impossible to estimate fees are to estimate income for miners. All segwit transactions are in blocks; all data in segwit transactions are in block. Nothing about that has changed. I do highly suggest that you read up on how segwit actually works before jumping to conclusions and trying to have a discussion about it. 2. Wrong a 500GB SSD cost 150$ !!! It is such a lie about difficulty for people. What the fuck all interconnected system are super complex to setup and the DIY about banking is quite risky and can WAY more expansive than decades of banking fees... At one point the market will bash all narratives that you try to construct here. even more brutal will be your fall if you believe them. Safety cost don't increase with the size of the blockchain.
I said there's more to it than just disk space. Can you read? You also need a computer, one with a CPU and RAM that can handle the load of processing the blocks that are being received. You also need to have enough network bandwidth in order to be able to receive and relay blocks and transactions. Furthermore, blocks could be constructed to be malicious and cause DoS attacks, and larger blocks make those worse. So there's way more to larger blocks than just disk space, or even network bandwidth requirements. your all argument is so flawed, it's brutal... never written a line of code in your life I guess? mostly pr and cr?
Yes, I totally have never written a single line of code in my life. That's why I have a Github account with several repositories (many of which are my own) where I have made several commits. It's also why I have 52 commits in Bitcoin Core and several Pull Requests. It's also why my name is in the release notes at the beginning of this thread.
I think I'm being trolled. I'll probably ignore you now. |
|
|
|
That was a quick response.  Thanks for everything. So it doesn't make much of a difference if I wait for the chain to finish loading before switching the wallet.dat, since it won't take long to sync after I switch them? Yes. Rescanning is not the same as syncing. |
|
|
|
- breach the on chain system, the fees and all ways to estimates income from miners.
- I fear that segwit txs will take over the blocks and or that txs can be blocked from segwit. I know those 2 comments are uninformed but I think that the more segwit scale, the more it will have a larger imbedded fee, which will raise the fee for the on chain users. Is it wrong? Then I fear that segwit may be able to ban certain txs. is it true?
These are completely untrue. You are conflating segwit with the lightning network. They are two completely and absolutely different things. Segwit does not do anything to how fees are calculated nor does it have a "larger imbedded fee" nor does it do anything to raise fees for on chain users. Segwit cannot ban anything. It is a technology, not a system. i suggest that you actually read up on how segwit works (as in read the BIPs) and not just people's blog posts. 3. btcash I like the idea of on chain scaling. I think it is the cleanest way forward. However it doesn't change the hardware mining cartel. best fabs, best layout, best everything is very capital intensive. Hardware isn't really open sourceable, yet. Then more practically looking at the wallet options, it is way less clear than with core. At least with core I know one main wallet that works, is continually improved and safe. Here I have no idea which one to download, not even a torrent...
One of the biggest issues with on chain scaling is that it becomes more difficult for people who want to run nodes to actually be able to run nodes. The cost required to run a node (which includes more than just bandwidth and disk space) increases dramatically by increasing block sizes, so much so that the idea of decentralized nodes just completely goes out the window. |
|
|
|
So you're saying I will only need to swap out the wallet.dat file and then restart the client without rescan?
Yes, it will actually perform the rescan itself if it needs to. You don't actually need to force a rescan. I tried to switch out the wallet.dat file before downloading the blockchain, but since this is a fresh installation there was no new wallet.dat.
You can stop it now and swap out the wallet.dat file. It may actually be better to do that to avoid a longer rescan later. The sync will pick up where it left off. Once the chain is synced, I simply swap the wallet.dat files, restart Bitcoin-qt normally, and my coins should be restored with no need for dumping the key or rescan?
A rescan is still required, but it will be started automatically by the software. Will it have to rescan the entire chain (a week) all over again or will it take around 30 minutes or so?
Rescanning is not the same as downloading the blockchain or reindexing the blockchain. It will be much, much, much faster. On the order of tens of minutes rather than days. |
|
|
|
|
First of all, ECDSA is not an encryption algorithm. Nothing is being encrypted with ECDSA. ECDSA is a signature algorithm (it's in the name!).
ECDSA was likely chosen because it is secure with shorter key lengths. An ECDSA private key of 256 bits has the roughly the same security of a RSA key with 3072 bits. This is a massive space saving measure.
|
|
|
|
Honestly, I think that high members ranks are more eligible for the merit source than lower ranks, they have more merit points to award. The right question is:" Why merit sources are mostly given merit points to high ranks members, instead, to give more merit points to low ranks members who deserve that?"
This may happen because those high ranking members have made/make high quality posts so users will merit them. I personally have a policy of not giving out merit to anyone that is Legendary or eligible for Legendary (although that has been violated a few times by accident and during the first few days of the merit system).
The main issue is likely an issue with bubbles. For example, I only really frequent the Dev & Tech and Technical Support boards because those are ones that I moderate and find interesting. Thus the people I will merit are going to be people who post in those boards. This means that there are going to be lots of people who I don't give merit to because I don't every see their posts. So some merit sources may simply not be giving merits to high quality posts because they don't even see them. Furthermore, there are some threads which may contain high quality posts but the thread itself is garbage and just shitposting threads. I tend to ignore these threads, and even if I were to see a high quality post in such a thread, I won't merit it because it is in what is effectively a shitposting thread (this has happened a few times as there are some shitposting threads in Dev & Tech). Merit sources may behave in a similar way. |
|
|
|
I looked at my client again, getinfo still produces data but with the deprecated warning as part of the array now. So why the code I'm using thats not working but was about a yr ago is now not working. I don't know but would like to find out.
The node I run is of no real signifigance, so if I end up having to keep an older client for the use of getinfo is fine with me.
The data type of getinfo is a JSON object, but your script expects a JSON array. It must have changed data types since your script was written. |
|
|
|
Can anyone tell me what "txtfile_keysfile_path.txt" means?
The dumpwallet command takes a path to a file. It writes the wallet's key data to that file. So "txtfile_keysfile_path.txt" is a string which is the path to the file where you want the key data to go. So you might do something like bitcoin-cli dumpwallet C:\Users\user\Documents\wallet_data.txt
Another method I've seen involves a similar swap out of the wallet.dat file but the instructions are to then: After swapping out wallet.dat
Go to the Windows command prompt and enter
C:\Program Files\Bitcoin>bitcoin-qt.exe -rescan
From what I gathered this would rescan the wallet.dat and my coin would then be restored.
Can anyone elaborate on these methods and tell me if I have the right idea or not? Right now I'm about half done syncing the blockchain.
Really appreciate your help.
The only actual restoring is the second thing with starting Bitcoin Core with -rescan. But you don't actually have to use -rescan if you are syncing from scratch. If you are syncing from scratch, you can just put your wallet.dat file in the data directory and start Bitcoin Core. It will automatically scan the blockchain for your transactions as it syncs. The first option with dumpwallet is only if you want to import your private keys into another wallet. |
|
|
|
|
The getinfo RPC command which your script relies on has been removed from Bitcoin Core. You should be able to replace it with the getblockchaininfo command.
|
|
|
|
|
It's the hash of the genesis block. The genesis blocks parameters can be found in chainparams.cpp. It is then serialized and hashed.
|
|
|
|
Oh gee that's a good idea. And that just applies to the RPC call, right? So it wouldn't interfere with broadcasting the transaction if/when the block is mined..??
Yes, it should only applies to the RPC call. Of course you should test that for yourself before actually using it. Assuming that's the case, that's exactly what I'm looking for, thanks! One quick question, is that code you highlighted also responsible for using sendrawtransaction via the bitcoin-cli program, or do I need to find and commend out code somewhere else for doing it via the cli? Either way, it's no trouble to use the RPC interface, so you've definitely given me a working solution. Thanks!
You can use bitcoin-cli. bitcoin-cli is just a tool to interact with the RPC interface. |
|
|
|
There is a time window for that? A bug could be there but just not found by users, so for how long developers wait before they consider RC4 as a stable version?
If no new bugs are found within a week of an RC's release, it will become the final version. |
|
|
|
Good to know it's planned for 0.17. How come, even though it was useful to have also years ago, multi-wallet was never on the radar but started now getting more attention?
The way that the wallet implementation was before made it very difficult to implement multi wallet. In order to properly implement multiwallet, a lot of stuff had to first be done to decouple the wallet stuff from the rest of the software, and that requires a lot of changes and a lot of review. Only then were we able to get proper multiwallet support. |
|
|
|
Can anyone suggest an effective way to interact with multiple wallets?
Use the bitcoin-cli utility and use the JSON-RPC interface. The GUI only allows interacting with the first wallet, and as far as I know there's no way to switch the primary wallet without restarting.
GUI support for multiwallet will hopefully be in 0.17.0. |
|
|
|
|
There are a number of old forum threads that explain how to create an altcoin from Bitcoin using older versions of Bitcoin Core. Many of the things that are mentioned there are the same things, just not in the same places. You can use grep to find where those variables are located now and change them as you want.
|
|
|
|
If you created your wallet in an old version (< 0.13, i think) and upgraded it, yes.
No, there is currently no way to upgrade a non-HD wallet to a HD wallet. Upgrading requires generating a completely new wallet and moving your coins there or importing all of your private keys. So, first, when my keypool empty - I cannot generate new bitcoin addresses = Payment system not working
Second - I have to enter password for wallet. On online computer. It's bad.
That is correct, you cannot generate new addresses to refill the keypool without unlocking your wallet. This is for security reasons. The private key needs to be stored somewhere once it has been generated. It cannot be stored unencrypted as that would be a security violation. The only way to store it encrypted is to provide the password so that the private key can be encrypted. |
|
|
|
|
Show Posts
