The released versions of Bitcoin Core currently do not support bech32 addresses nor do they have full Segwit wallet support (not just GUI, but support in the wallet itself). The next major release of Bitcoin Core will have all of this available. Thanks for your reply BillyBobZorton. Someone told me it was going to be supported in 0.15.1 so I'll just put that down to misinformation and wait for the next version. Cheers.
It was originally planned for 0.15.1 but that was pushed back because 0.15.1 was used for some Segwit2x fork handling things. |
|
|
|
The site is not open. Is there any other site that we can use instead of this forum? a few site suggestions, but they are not working either.
Theymos recently implemented a new DDoS protection system which appears to be blocking the crawler that the site uses to pull data from Bitcointalk. This appears to have caused the server to crash or error. Unfortunately there is no way around this system and I may just leave the site down indefinitely.
|
|
|
|
|
Yes, you can. Electrum and Electron Cash use different data directories so they do not conflict with each other.
|
|
|
|
How to start Bitcoin Core with the -salvagewallet option?
If you are using Windows, right click the shortcut that you are using the start Bitcoin Core and choose Properties. Then in the box labeled Target. Move the cursor to the end and add a space after what is already there. Then add -salvagewallet. In Macs and Linux, just use the terminal. |
|
|
|
Can't connect to the website  Awesome website tho  website is down ? when will be up ?
is website maintenance ? or down for a while ?
Theymos recently implemented a new DDoS protection system which appears to be blocking the crawler that the site uses to pull data from Bitcointalk. This appears to have caused the server to crash or error. Unfortunately there is no way around this system and I may just leave the site down indefinitely. |
|
|
|
One question: How to enable HD mode?
In Bitcoin Core 0.13.0+, HD wallets are enabled by default and created by default. If your wallet was created in a version of Bitcoin Core 0.13.0+ and you did not start Bitcoin Core with -usehd=0, then your wallet is a HD wallet. And another one: what do you mean by this: "older backups will not know about those witness addresses (the scripts themselves must be added to the wallet) and addwitnessaddress will need to be called again on every single address generated." So, if my wallet.dat has funds on a single witnessaddress and I move the wallet.dat to another node, I won't see there the witness address? If so, do I have to remember the non witness address I used to generate a specific witness address?
No, the addresses will follow the wallet file, not the software. Suppose you make a backup, then generate a new address and use addwitnessaddress on it, and then receive coins at both the witness address and the regular address. If you were to restore the backup, you will see the coins that were sent to the regular address, but not the ones sent to the witness address. Furthermore, you wouldn't see the witness address in your wallet and would have to call addwitnessaddress again to add it to your wallet. Then you may also need to rescan. This should be fixed when full segwit wallet support is completed in Bitcoin Core. |
|
|
|
|
Your wallet is corrupted. First make a backup of your wallet. Then start Bitcoin Core with the -salvagewallet option.
Please also post the entirety of the debug.log file.
|
|
|
|
|
Case 0 (0x00) is the standard Pay to pubkey hash scriptPubKey type.
Case 1 is the standard Pay to Script Hash scriptPubKey type.
Cases 2 and 3 are for Pay to Pubkey scriptPubKey types with compressed pubkeys. Compressed pubkeys begin with a 2 or a 3, hence there are two types here.
Cases 4 and 5 are for Pay to Pubkey scriptPubKey types with uncompressed pubkeys. Uncompressed pubkeys begin with a 4. Because uncompressed pubkeys are compressed for storage, they need to be decompressed for the script. 4 means that the Y coordinate of the public key was even so the even one is calculated and used. 5 means that the Y coordinate was odd so the odd one is calculated and used.
|
|
|
|
|
What are the addresses 3ATq4854DnkFoAMhKP5FTUCeJeHXgvWjYK and 3DhDTgW6G5CFaqbtK2UFGBJFkQk6sGkC63 for? Whatever they are, your coins are associated with those addresses. If those are addresses from an exchange, then go to their respective exchanges and your coins will be there.
|
|
|
|
Im trying to find this command in the wiki and it doesn't exist it seems:
The wiki is outdated (it is always outdated). Use the help command to get help. If you do help importmulti, it will show you the help for importmulti. In this wallet, I need all of my addresses as watch only. Im not sure if I should need to add the sending addresses too, but I think I should, if for example I want to deposit on Poloniex and I want to use 1xxxxxxxxxxxxxxxxxxxx4 one I think I will need it.
There are no such things as sending addresses. What Bitcoin Core calls sending addresses should really be called "Address book". You do not want to import those. So please, how would the importmulti command look if I wanted to add these 5 addresses with their respective labels and to be sorted properly in "Receiving addresses" window and "Sending addresses" but everything watchonly to guarantee no private keys are saved? I just want a "read only" 1:1 copy of my wallet.dat to keep track of balances and keep my sending addresses list too in case I need to sign a transaction there.
Your command should look something like this: importmulti '[{"scriptPubKey":{ "address":"1xxxxxxxxxxxxxxxxxxxx1"},"label":"Poloniex withdraw"},{"scriptPubKey":{ "address":"1xxxxxxxxxxxxxxxxxxxx2"},"label":"Donations"},{"scriptPubKey":{ "address":"1xxxxxxxxxxxxxxxxxxxx3"},"label":"Signature campaign"}]'
|
|
|
|
I thought I would do the super secure thing and make a brainwallet!
Brainwallets are really not that secure, especially if you thought of the password yourself (versus letting a computer generate one for you). So I made the brainwallet with a passphrase, and sent all my bitcoins there. I then wrote down my passphrase and off I went.
A few days later I went to check my wallet and I couldn't get the right private key. I was so mad, and I tried a few other people but nobody was able to help me get my coins back.
Anyway, now that BTC has hit 10k, I am really hoping I can get my hands on my wallet. I found some older threads about using some Ruby program or bitcoind or something to find your wallet, but I am a complete programming noob, and have no idea where to begin. Could anyone possibly help me out?
And yes, I know I am stupid for using a brainwallet and I deserve for my coins to be lost, but it was a long time ago and I had no idea what I was really doing.
There is no standard for generating brainwallets, so it entirely depends upon how you created the brainwallet in the first place. What website or software did you use? How much of the password do you remember? Do you know potential candidates for the password? Was the brainwallet salted? If so, what was the salt? There are a lot of things that you need to know that you may not know before you can even start trying to guess the password, and if you don't know or don't remember those things, then you probably will not be able to get your coins. |
|
|
|
Pre-mining is frowned upon though is it not?
..
I am working on a project that we will take ICO
It is, and so is making an ICO. Say you wanted to create a Crypto currency that was totally mined and not pre-mined would the coin be more popular or does it make no difference?
It makes no difference because it will just be another ICO token among millions of other ICO tokens that no one has ever heard of or cares about. The time it would take to mine X number of coins of a yet to be created altcoin is entirely dependent on the parameters you set for that altcoin. It will depend on the difficulty (the Proof of Work target parameter that you begin with), the target block rate, the hash algorithm, etc. |
|
|
|
|
What exchanges have dinosaur names?
They are probably named whatever they are named because the creators thought it sounded cool.
|
|
|
|
Can I use Electrum from mobile?
Electrum has a mobile wallet but it may not have the same features as the desktop version. If you are making a lot of large recipient transactions, I suggest that you do so on a computer and not on mobile as it will be easier to not make mistakes. |
|
|
|
So if I understand well I have two ways to get back my btc:
- download 150 gigabyte date
- export the keys from Armory and receive btc on another client like etherum
Yes. |
|
|
|
If I have an encrypted wallet.dat file under bitcoin core, and I frequently use the getnewaddress and addwitnessaddress commands, how often should I backup the wallet.dat file?
If you are using the latest Bitcoin Core, then you should make a new backup every 1000 addresses. That is the default keypool size and you should make a new backup whenever the keypool runs out. This should be done regardless of HD or non-HD wallet, and even more so because you are using addwitnessaddress. Also, you will need to unlock your wallet every 1000 addresses so that the keypool can be refreshed. This was the case with the old format, as far as I know, since bip32 was introduced (I think this is the bip for the current HD format) then you no longer need to be making backups each time, but I don't know how this would be the case to be honest.
Even if HD mode is enabled, and you make receive a transaction with a newly generated key, how can a former HD enabled wallet.dat know that this transaction was received, if the key was never generated? same goes for sent coins. This confuses me a great deal. I think it has something to do with pre-generated addresses that you don't see but already are there or something along the lines... it's weird to think for a non coder. I would like achow101 to explain this in laymans.
My advice is that even if you are using HD mode, you keep making backups and don't delete previous backups, just rename them.
You should keep making backups regularly. What HD wallets do is that you can still use old backups and still generate the private keys that are not in the keypool at the time of backup. The wallet contains a field which has the latest block height that the wallet is synced up to (as in it has the transactions for the wallet up to that block height). So when restoring, Bitcoin Core will know where it should begin rescanning the blockchain to get any new transactions. Because OP is also using addwitnessaddress, older backups will not know about those witness addresses (the scripts themselves must be added to the wallet) and addwitnessaddress will need to be called again on every single address generated. |
|
|
|
|
Use the importmulti command. It lets you import multiple addresses or private keys in the same command. Just craft the command in a text editor and copy and paste it when entering.
|
|
|
|
|
The name "Bitcoin Pay" is incredibly generic. From a quick google search, it seems like just another payment processor, not any particular approach to making Bitcoin transactions faster through layer 2 solutions or consensus rule changes. Can you perhaps provide a link to what you were looking at?
|
|
|
|
Fair enough. But if I want to sift through the data using my own software, how would I go about that? Is it possible?
It certainly is possible. You would do that by reading through the block files byte by byte. Each block is preceded by the network magic bytes and then a compact size unsigned integer representing the number of bytes of the block. Then the block itself in the network serialization format. |
|
|
|
Could someone please clarify this statement from above? "We are planning on moving to BIP 32 which will thus deprecate the currently used stuff. However the legacy wallet systems will likely still be kept for backwards compatibility."
Does this mean that at some point the older paper backups will not be restorable into the newer clients?
Yes. Has this happened yet?
No. We have not moved to BIP 32 yet. Once we do, it will still be a few versions before the legacy wallets are phased out entirely. I also have some questions of compatibility around bitcoin core and Armory.
Currently, I have Bitcoin core 15.1 installed and finishing the sync of the blockchain. My main reason for updating was to take advantage of the big initial sync performance improvements. I'm now not 100% sure which versions of Armory support this.
For example, 96.0 says it supports 14.0+, does this mean 14.x only or does it include 15.x?
0.15.x is greater than 0.14, so it is supported. However you should use the latest version of Armory anyways, 0.96.3 or 0.96.4 RC1. I'm running OSX and have Armory 95.1 installed, it seems 96.1 is the latest that has OSX support, is that correct?
0.96.3 has OSX binaries that I forgot to list on the website. You can get them from here: https://github.com/goatpig/BitcoinArmory/releases/tag/v0.96.3. You could also use 0.96.4 RC 1 which has a few bug fixes, available from here: https://github.com/goatpig/BitcoinArmory/releases/tag/v0.96.3.99Lastly, is there any danger in restoring into a slightly older version of Armory. E.g, if I restore into 95.1, is this ok?
It should be fine, but the older versions have a variety of bugs and performance issues that were fixed in the new versions. |
|
|
|
|
Show Posts
