[Help] [Question] I had to erase MBP and couldn't restore from time machine. Now I need help retrieving my old wallet info?
As stated I had problems with my MBP and had to do a clean restore. I then couldn't restore it from my backup on my time machine but instead had to pull the individual files from the backup. I need help finding a way to retrieve my old wallet and I believe I have a .dat backup? I do have the Bitcoin-QT wallet and I don't want it to start up and sync till I know how to retrieve my old wallet info. Any help would be greatly appreciated. Also just in case the .dat file isn't any help is there a way to pull it from my time machine backup? [Edit] I have located the new wallet.dat file and Bitcoin folder and added the Bitcoin-QT Backup.dat file in there but haven't done anything with it yet. I am thinking about going ahead and running the Bitcoin-QT wallet and let it sync and see what happens. [Edit] (Update) After posting on here and Bitcointalk.org I had enough people come together and had different ideas to figure it all out. So my folder was hidden from plain sight and had to use the command+shift+[G] keys to see my hidden Bitcoin folder. Once I was in that folder I entered into time machine and the same exact folder came up and I went to the last backup before my computer got restored and copied those files and pasted those into the Bitcoin folder created after opening up Bitcoin-QT again to do a fresh sync. So I deleted the new files and added my old files from my backup and then opened up Bitcoin-QT and it started to process and verify blocks. Once it opened up it had to sync all my data back on and showed my account balance from what I had prior to this whole ordeal. Now I wasn't sure it was going to work so it spent all night reindexing and syncing the blockchain and finally finished this morning. Once it finished I closed the wallet down and reopened it and it came right back to my wallet. So I am thankful for all the help and appreciate the bitcoin community for this. As I am sure everyone knows it can be kind of stressful to have to deal with something like this but luckily there are files and backups that help prevent anyone from losing the wallet completely. I will now make sure I backup the wallet every month or so if not more often. This is one thing that I believe scares people from using bitcoins because it is easy to lose your wallet/BTC if you don't know what you're doing. I am looking into the Electrum wallet as well to see if I actually like that one. Thanks again for your help.
If I backup my wallet.dat can I reinstall bitcoin QT without losing BTC?
Trying to get a payment. Bitcoin QT stuck synchronizing. Last block data is from 302 days ago. Any tips welcome. [UPDATE] WHAT I DID TO SOLVE THIS PROBLEM, KIND OF, AKA, A WORKAROUND. Backstory: This was also my first bitcoin transaction ever. & I'm not even mildly a computer genius. 1 Backed up my wallet.dat to a file on my desktop so I didn't lose it. (I was fucking scared of losing it) 2 Uploaded wallet.dat to : https://blockchain.info/wallet/ --- (since this was my first transaction, it's not like I had a lot of coins in my wallet so I figured I'll upload it here, cash in what I will, and move the rest someplace more secure) 3 Made a coinbase account. 4 Linked it to bank account with instant verification. (pretty neat) 5 Copied generated on coinbase (they don't explain it but coinbase is also sort of a 'wallet') 6 Pasted that address into the field on the page for sending coins on the Blockchain Wallet Page. Hit send. HELD BREATH CUZ I SENT A BUNCH OF MONEY THROUGH SPACE. The computer made a weird noise, like a DOS-y sort of beep. 7 Refreshed my Coinbase wallet and TA-DAA, they were there!!! 8 Waited while the transaction was 'pending' for a little under hour. (This is normal) 9 Sent to bank account. =] =] =]
(1) Is it true that encrypting an *existing* bitcoin-qt wallet.dat file will "invalidate" any existing backups? (2) Can I use unicode characters - eg ♥ - in the bitcoin-qt wallet passphrase?
I have an existing bitcoin-qt wallet.dat file which I want to encrypt - using the command in the bitcoin-qt Settings menu, involving creating a passphrase. I have 2 (possibly somewhat related) questions: TL;DR (1) If you encrypt an existing wallet.dat file, will the backups of the old wallet.dat file still work? (2) Can you include unicode characters - eg ♥ - in the passphrase used to encrypt a bitcoin-qt wallet.dat file? Worst-case scenario: The answers to (1) and (2) are both "no" - and I attempt to encrypt an existing wallet using unicode, and my backups no longer work (due to a new pool of addresses somehow being created?) and the passphrase isn't what I think it is (due to the unicode characters somehow being misinterpreted?) - and then I could lose all my coins?? Details (1) The following (old, short) thread claims that after you encrypt an existing wallet, any previous backups of that wallet will no longer work: https://pay.reddit.com/Bitcoin/comments/1ccfdk/encrypting_walletdat_in_bitcoinqt/ Obviously, the the first response in that thread was slightly wrong, for saying that the "server" creates a new pool of 100 addresses to draw on. So using word "server" here was certainly incorrect - but maybe the gist of what they were saying might still be correct? (if you simply change "server" to "client"). I can actually understand that there might be reasons why encrypting a wallet.dat file could cause a new pool of 100 addresses to be generated. But it does not make sense to me that this would make any older (unencrypted) backups instantly useless. It seems to me that these older, unencrypted backups would still have their private keys intact, and could thus be used in certain (perhaps limited?) ways - such as:
"sweeping" the funds from the private keys of the old, unencrypted wallet into another wallet, or
doing a normal "spend" from the private keys of the old, unencrypted wallet (However, if the old unencrypted and the new encrypted wallets now contain different pools of addresses, then I imagine that this spend would invalidate the new, encrypted wallet - because any change from the spend would be sent to a "change address" from among those in the old, unencrypted wallet - and so this amount of change would be missing from the new encrypted wallet, right?).
(2) It seems that including a few unicode characters in the bitcoin-qt wallet passphrase would make it a lot stronger (since unicode is a much larger set of characters than ascii), so I would like to include a few. But it would be more reassuring if it could be explicitly stated that this is indeed supported. Possible catastrophic interaction between (1) and (2)? If the answers to (1) and (2) were both "no" (ie, if you encrypt an existing bitcoin-qt wallet.dat file then any existing backups will not work, and unicode characters do not work in bitcoin-qt passphrases), then I'm worried there could be some kind of catastrophic interaction between (1) and (2) where I lose all my coins, as follows: (1) I encrypt my existing wallet - making my old, unencrypted wallet.dat file now invalidated (due to something involving a new pool of addresses being generated?) and (2) I use a passphrase which includes unicode characters which bitcoin-qt appears to accept at the time of creation, but which doesn't work at the time of trying to decrypt the wallet.dat file (due to something going wring with how the supposed unicode characters are actually interpreted while being entered or copied-and-pasted?). In this possible worst-case scenario, my old backups of wallet.dat no longer work, and my newly encrypted wallet.dat has some password which I'm not able to correctly enter anymore. Sorry to be so paranoid about this! Other remarks: (a) I did do a (limited) test of unicode capability for bitcoin-qt wallet.dat passphrases: simply by creating a new (empty) wallet.dat file, and creating a passphrase for it involving unicode characters, and then attempting to change the passphrase (which requires entering the old passphrase that contained unicode characters). This did seem to work ok: it let me re-enter the old passphrase (which included unicode characters) to create a new passphrase. However, since this is an empty wallet (and since bitcoin-qt would ask for the passphrase only when attempting to actually spend from an encrypted wallet), I did not see a way to fully test whether the passphrase actually worked to decrypt a unicode-passphrase-encrypted wallet for the purpose of spending from it. (I'm still downloading the rest of the blockchain and it's going to take at least another week on my slow connection, so don't see how I could send a small amount to the new wallet to test it either. My existing wallet.dat file was originally created on an internet-connected machine a long time ago, but it's been offline ever since, so in some sense it's kinda-sorta been in somewhat "cold" storage all this time, and I would prefer to avoid putting it online on a "hot" internet-connected machine until absolutely necessary.) (b) Long-term, I am actually also in the process of setting up a proper cold storage system based on Armory, which I have installed on 2 Ubuntu machines (one offline and one online). But I have a slow internet connection, and the backups of this old wallet.dat file have been sitting around unencrypted for ages (I've been relying simply on then being physically inaccessible). Now some "things" are coming up over the next few days where I some better security right away, and it's probably going to take over a week for Armory/bitcoind to update my local copy of the blockchain. So in the meantime, I also need some basic additional security right now - so encrypting the existing bitcoin-qt wallet.dat file using a strong passphrase (and making some new backups) seems like it could be a reasonable initial approach. Thanks for any help!
How to backup blocks on Bitcoin Core Wallet (Bitcoin-QT) ?
Hi, finally I have fully synced Core, but now I want to back up blocks, I will not keep Core installed for long so what do I need exactly to back up, just folder "blocks" ? If I uninstall Core completly then install it, and replace "blocks" folder with blocks, can I simply start Core it will start verify blocks and start sync from say 25 March 2015 ?
How can I import an encrypted backup wallet.dat file to a newly installed Bitcoin-qt client on macbook??
Let's say one's macbook was to crash with all their data gone, but they have backed up their wallet into a usb. How can one import the wallet.dat file into a newly installed Bitcoin-qt client on a possibly new macbook?
Help recovering from old wallet.dat for an old friend.
Hey all, I've been in the Bitcoin space since early 2012. I have a situation that I would love to get some assistance with, I will explain the situation momentarily. Please do not message me and ask me for the wallet.dat file it's not going to happen. TL;DR I have an old wallet.dat file from late 2012 or early 2013 from a coin I sold to a friend. Tried to recover the coins in 2018 and failed, later found out that someone had access to the computer and could have easily stole them. Would the current Bitcoin Core be able to read an old wallet.dat file, and is there any way to easily view the balance of a 2012 wallet.dat file without having to load the entire blockchain? In the early days of Bitcoin as many of you OG's know, the only option to securely store your coins was to use the default Bitcoin wallet in a wallet.dat file. A friend of mine was really wanted to invest in Bitcoin but didn't know how, so I sold one to him because I didn't want him to get screwed. I installed Bitcoin QT on their home laptop, had him write down the password on a piece of paper and had him put a backup of the wallet.dat file onto a USB. Fast forward to when the price went to $20k plus, he calls me up super excited and said he wanted to sell his coin because he could use the money and I encouraged it because from my prior experience I knew the momentum was unsustainable and I had sold a few coins of my own. Anyway, I go over to his house and we huddle around his computer. He tells me that he upgraded the hard drive in his computer and gave me his old one and I went back to my house to get an external hard drive reader. I came back, booted up his old drive and remembered that we would have to let it sync up in order to get the coins out, and on his internet that wasn't going to happen anytime soon. He gave me the hard drive and I went home and left on Bitcoin QT overnight and in the morning I was shocked to see that there were no transactions on the wallet. Quick note, he had the wallet password in a file on his documents titled "Bitcoin Wallet Password.txt". smh. I started to panic, and I realized how bad this looked on me. I called him and told him that there were no coins on there and asked if he had his USB stick and he told me he had lost it years ago. I frantically looked through all of my old wallet files to find any transaction that could link to his address, to show that his coins were still in there. After a while I realized I had sent the coins from the now defunct btc-e.com, and had no way to check up on the coins. I did everything in my ability to try to recover lost data from the hard drive to no avail. I asked him if anyone else has had access to his computer, and then asked him how he replaced his hard drive because I know him well enough to know he wouldn't pull apart a laptop to replace the hard drive. He told me he took it to a shop to have it replaced a few months earlier. I suspect that I'm either trying to view the wallet incorrectly or whoever replaced his hard drive snooped on his hard drive, stole the coins and replaced the wallet.dat file and generated a new one. I have to admit, I was relieved a little bit to have an explanation to coins not being there but I could imagine he thinks I may have had something to do with it. I made a few more attempts over the years whenever I was reminded of the situation to no avail. We kind of fell out after that and haven't spoken in a while. Recently, I saw a post on his Facebook that his wife is pregnant they are having a baby, and that's why I'm here. I would love nothing more than to be able to message him and let him know that I have 11 grand waiting for him, because I'm certain the money would mean the world to him during such a stressful time. Any help or insights would be incredibly helpful and appreciated.
We are pleased to announce that after many hard months of work, Peercoin v0.9 (Codename Strider) is complete and a hard fork is planned for Monday, June 8th, 2020 at 12:00:00 UTC. You must upgrade your wallet client before then!
ability to filter out mint transactions in the QT wallet
While Peercoin v0.8 (Mantis) was largely about modernizing the codebase and improving the technical capabilities of the reference node software, the v0.9 (Strider) development cycle was about the economics of the Peercoin cryptocurrrency. Both the PoW and PoS aspects of the network have been modified. Proof-of-Work changes are rather minimal; in summary target block spacing has been set to 60 minutes, rather than having dynamic PoW block spacing target. Block spacing is currently approximately 60 minutes anyway, so this may not sound like a big change, but it stops some PoW pools from trying to game the system. By making PoW more predictable, RFC-0019 brings inflationary stability to the overall system. That change is minor when compared to the modification of the Proof-of-Stake side of the system. Some of you may have been following the discussion on RFC-0011, which was ongoing for over a year, and you may have noticed that RFC-0011 was rejected about two weeks ago and replaced with RFC-0018. In my personal opinion, RFC-0011 is a great idea, probably the best idea thrown around here in the last couple of years, but ultimately it's too complex and we could not get consensus about it. The gist of both RFC-0011 and RFC-0018 is that the Peercoin money supply inflates at a rate of 1% on paper, but we are nowhere near that in practice. In the old system, in order to have PoS inflation at 1%, a full 100% of all peercoins would have to start minting and solving blocks. This is simply impossible. In reality, over the last couple years Peercoin's PoS inflation has only been between 0.10% and 0.20%, which is far from the "promised" annual 1%. Due to the very rough history of this beautiful blockchain, namely the closure of btc-e, dozens of exchange hacks and closures, as well as a couple of de-listings, we are in a situation today where nearly half of the monetary supply has not been moved for over two years and we can consider those coins lost for all intents and purposes. The basic principle of RFC-0011 was the following: the Peercoin network promises a steady inflation of 1% on monetary supply, and if you want a cut of it: mint. In essence, if only 20% of all peercoins are minting, the effective reward for active minters would be closer to 5% per year. However, the problem with this scheme is that minters would try to game the system and only mint when minting participation is low. Thus, we came up with RFC-0018, which yields similar results, but keeps the reward calculation simple and prevents gaming of the algorithm. You can read more about the change here. Long story short, the network will reward active minters more, while keeping the overall inflation around 1%. Accompanied with an expected inflation drop from increasing PoW hashrate, overall monetary inflation will largely remain unchanged, and will be more stable. Other changes are minor and do not change the behavior of the network. RFC-0017 is just a consequence of RFC-11, and it stops minters from going offline for longer than a year and coming back to mint. We did not see this as fair, so the coinage counter is reset after a year now. Limiting coinage disincentivizes extremely long term periodic minting, thereby making continuous minting more attractive. -- Peerchemist, Peercoin Project Lead
Before installation, make sure to backup your wallet from the main menu.
The v0.9 client can be downloaded from the wallets page of peercoin.net. For users upgrading from v0.8, upgrade instructions can also be found on that page. For the minority of users that may have skipped v0.8 and are upgrading from v0.7 or earlier, please check these additional instructions from the previous v0.8 release thread as you will need to go through the additional process of rebuilding your block database. If you need help with installation, leave a comment below.
Dear Groestlers, it goes without saying that 2020 has been a difficult time for millions of people worldwide. The groestlcoin team would like to take this opportunity to wish everyone our best to everyone coping with the direct and indirect effects of COVID-19. Let it bring out the best in us all and show that collectively, we can conquer anything. The centralised banks and our national governments are facing unprecedented times with interest rates worldwide dropping to record lows in places. Rest assured that this can only strengthen the fundamentals of all decentralised cryptocurrencies and the vision that was seeded with Satoshi's Bitcoin whitepaper over 10 years ago. Despite everything that has been thrown at us this year, the show must go on and the team will still progress and advance to continue the momentum that we have developed over the past 6 years. In addition to this, we'd like to remind you all that this is Groestlcoin's 6th Birthday release! In terms of price there have been some crazy highs and lows over the years (with highs of around $2.60 and lows of $0.000077!), but in terms of value– Groestlcoin just keeps getting more valuable! In these uncertain times, one thing remains clear – Groestlcoin will keep going and keep innovating regardless. On with what has been worked on and completed over the past few months.
UPDATED - Groestlcoin Core 2.18.2
This is a major release of Groestlcoin Core with many protocol level improvements and code optimizations, featuring the technical equivalent of Bitcoin v0.18.2 but with Groestlcoin-specific patches. On a general level, most of what is new is a new 'Groestlcoin-wallet' tool which is now distributed alongside Groestlcoin Core's other executables. NOTE: The 'Account' API has been removed from this version which was typically used in some tip bots. Please ensure you check the release notes from 2.17.2 for details on replacing this functionality.
Builds are now done through Gitian
Calls to getblocktemplate will fail if the segwit rule is not specified. Calling getblocktemplate without segwit specified is almost certainly a misconfiguration since doing so results in lower rewards for the miner. Failed calls will produce an error message describing how to enable the segwit rule.
A warning is printed if an unrecognized section name is used in the configuration file. Recognized sections are [test], [main], and [regtest].
Four new options are available for configuring the maximum number of messages that ZMQ will queue in memory (the "high water mark") before dropping additional messages. The default value is 1,000, the same as was used for previous releases.
The rpcallowip option can no longer be used to automatically listen on all network interfaces. Instead, the rpcbind parameter must be used to specify the IP addresses to listen on. Listening for RPC commands over a public network connection is insecure and should be disabled, so a warning is now printed if a user selects such a configuration. If you need to expose RPC in order to use a tool like Docker, ensure you only bind RPC to your localhost, e.g. docker run [...] -p 127.0.0.1:1441:1441 (this is an extra :1441 over the normal Docker port specification).
The rpcpassword option now causes a startup error if the password set in the configuration file contains a hash character (#), as it's ambiguous whether the hash character is meant for the password or as a comment.
The whitelistforcerelay option is used to relay transactions from whitelisted peers even when not accepted to the mempool. This option now defaults to being off, so that changes in policy and disconnect/ban behavior will not cause a node that is whitelisting another to be dropped by peers.
A new short about the JSON-RPC interface describes cases where the results of anRPC might contain inconsistencies between data sourced from differentsubsystems, such as wallet state and mempool state.
A new document introduces Groestlcoin Core's BIP174 interface, which is used to allow multiple programs to collaboratively work to create, sign, and broadcast new transactions. This is useful for offline (cold storage) wallets, multisig wallets, coinjoin implementations, and many other cases where two or more programs need to interact to generate a complete transaction.
The output script descriptor (https://github.com/groestlcoin/groestlcoin/blob/mastedoc/descriptors.md) documentation has been updated with information about new features in this still-developing language for describing the output scripts that a wallet or other program wants to receive notifications for, such as which addresses it wants to know received payments. The language is currently used in multiple new and updated RPCs described in these release notes and is expected to be adapted to other RPCs and to the underlying wallet structure.
A new --disable-bip70 option may be passed to ./configure to prevent Groestlcoin-Qt from being built with support for the BIP70 payment protocol or from linking libssl. As the payment protocol has exposed Groestlcoin Core to libssl vulnerabilities in the past, builders who don't need BIP70 support are encouraged to use this option to reduce their exposure to future vulnerabilities.
The minimum required version of Qt (when building the GUI) has been increased from 5.2 to 5.5.1 (the depends system provides 5.9.7)
getnodeaddresses returns peer addresses known to this node. It may be used to find nodes to connect to without using a DNS seeder.
listwalletdir returns a list of wallets in the wallet directory (either the default wallet directory or the directory configured bythe -walletdir parameter).
getrpcinfo returns runtime details of the RPC server. Currently, it returns an array of the currently active commands and how long they've been running.
deriveaddresses returns one or more addresses corresponding to an output descriptor.
getdescriptorinfo accepts a descriptor and returns information aboutit, including its computed checksum.
joinpsbts merges multiple distinct PSBTs into a single PSBT. The multiple PSBTs must have different inputs. The resulting PSBT will contain every input and output from all the PSBTs. Any signatures provided in any of the PSBTs will be dropped.
analyzepsbt examines a PSBT and provides information about what the PSBT contains and the next steps that need to be taken in order to complete the transaction. For each input of a PSBT, analyze psbt provides information about what information is missing for that input, including whether a UTXO needs to be provided, what pubkeys still need to be provided, which scripts need to be provided, and what signatures are still needed. Every input will also list which role is needed to complete that input, and analyzepsbt will also list the next role in general needed to complete the PSBT. analyzepsbt will also provide the estimated fee rate and estimated virtual size of the completed transaction if it has enough information to do so.
utxoupdatepsbt searches the set of Unspent Transaction Outputs (UTXOs) to find the outputs being spent by the partial transaction. PSBTs need to have the UTXOs being spent to be provided because the signing algorithm requires information from the UTXO being spent. For segwit inputs, only the UTXO itself is necessary. For non-segwit outputs, the entire previous transaction is needed so that signers can be sure that they are signing the correct thing. Unfortunately, because the UTXO set only contains UTXOs and not full transactions, utxoupdatepsbt will only add the UTXO for segwit inputs.
getpeerinfo now returns an additional minfeefilter field set to the peer's BIP133 fee filter. You can use this to detect that you have peers that are willing to accept transactions below the default minimum relay fee.
The mempool RPCs, such as getrawmempool with verbose=true, now return an additional "bip125-replaceable" value indicating whether thetransaction (or its unconfirmed ancestors) opts-in to asking nodes and miners to replace it with a higher-feerate transaction spending any of the same inputs.
settxfee previously silently ignored attempts to set the fee below the allowed minimums. It now prints a warning. The special value of"0" may still be used to request the minimum value.
getaddressinfo now provides an ischange field indicating whether the wallet used the address in a change output.
importmulti has been updated to support P2WSH, P2WPKH, P2SH-P2WPKH, and P2SH-P2WSH. Requests for P2WSH and P2SH-P2WSH accept an additional witnessscript parameter.
importmulti now returns an additional warnings field for each request with an array of strings explaining when fields are being ignored or are inconsistent, if there are any.
getaddressinfo now returns an additional solvable Boolean field when Groestlcoin Core knows enough about the address's scriptPubKey, optional redeemScript, and optional witnessScript for the wallet to be able to generate an unsigned input spending funds sent to that address.
The getaddressinfo, listunspent, and scantxoutset RPCs now return an additional desc field that contains an output descriptor containing all key paths and signing information for the address (except for the private key). The desc field is only returned for getaddressinfo and listunspent when the address is solvable.
importprivkey will preserve previously-set labels for addresses or public keys corresponding to the private key being imported. For example, if you imported a watch-only address with the label "coldwallet" in earlier releases of Groestlcoin Core, subsequently importing the private key would default to resetting the address's label to the default empty-string label (""). In this release, the previous label of "cold wallet" will be retained. If you optionally specify any label besides the default when calling importprivkey, the new label will be applied to the address.
getmininginfo now omits currentblockweight and currentblocktx when a block was never assembled via RPC on this node.
The getrawtransaction RPC & REST endpoints no longer check the unspent UTXO set for a transaction. The remaining behaviors are as follows:
If a blockhash is provided, check the corresponding block.
If no blockhash is provided, check the mempool.
If no blockhash is provided but txindex is enabled, also check txindex.
unloadwallet is now synchronous, meaning it will not return until the wallet is fully unloaded.
importmulti now supports importing of addresses from descriptors. A desc parameter can be provided instead of the "scriptPubKey" in are quest, as well as an optional range for ranged descriptors to specify the start and end of the range to import. Descriptors with key origin information imported through importmulti will have their key origin information stored in the wallet for use with creating PSBTs.
listunspent has been modified so that it also returns witnessScript, the witness script in the case of a P2WSH orP2SH-P2WSH output.
createwallet now has an optional blank argument that can be used to create a blank wallet. Blank wallets do not have any keys or HDseed. They cannot be opened in software older than 2.18.2. Once a blank wallet has a HD seed set (by using sethdseed) or private keys, scripts, addresses, and other watch only things have been imported, the wallet is no longer blank and can be opened in 2.17.2. Encrypting a blank wallet will also set a HD seed for it.
signrawtransaction is removed after being deprecated and hidden behind a special configuration option in version 2.17.2.
The 'account' API is removed after being deprecated in v2.17.2 The 'label' API was introduced in v2.17.2 as a replacement for accounts. See the release notes from v2.17.2 for a full description of the changes from the 'account' API to the 'label' API.
addwitnessaddress is removed after being deprecated in version 2.16.0.
generate is deprecated and will be fully removed in a subsequent major version. This RPC is only used for testing, but its implementation reached across multiple subsystems (wallet and mining), so it is being deprecated to simplify the wallet-node interface. Projects that are using generate for testing purposes should transition to using the generatetoaddress RPC, which does not require or use the wallet component. Calling generatetoaddress with an address returned by the getnewaddress RPC gives the same functionality as the old generate RPC. To continue using generate in this version, restart groestlcoind with the -deprecatedrpc=generate configuration option.
Be reminded that parts of the validateaddress command have been deprecated and moved to getaddressinfo. The following deprecated fields have moved to getaddressinfo: ismine, iswatchonly,script, hex, pubkeys, sigsrequired, pubkey, embedded,iscompressed, label, timestamp, hdkeypath, hdmasterkeyid.
The addresses field has been removed from the validateaddressand getaddressinfo RPC methods. This field was confusing since it referred to public keys using their P2PKH address. Clients should use the embedded.address field for P2SH or P2WSH wrapped addresses, and pubkeys for inspecting multisig participants.
A new /rest/blockhashbyheight/ endpoint is added for fetching the hash of the block in the current best blockchain based on its height (how many blocks it is after the Genesis Block).
A new Window menu is added alongside the existing File, Settings, and Help menus. Several items from the other menus that opened new windows have been moved to this new Window menu.
In the Send tab, the checkbox for "pay only the required fee" has been removed. Instead, the user can simply decrease the value in the Custom Fee rate field all the way down to the node's configured minimumrelay fee.
In the Overview tab, the watch-only balance will be the only balance shown if the wallet was created using the createwallet RPC and thedisable_private_keys parameter was set to true.
The launch-on-startup option is no longer available on macOS if compiled with macosx min version greater than 10.11 (useCXXFLAGS="-mmacosx-version-min=10.11" CFLAGS="-mmacosx-version-min=10.11" for setting the deployment sdkversion)
A new groestlcoin-wallet tool is now distributed alongside Groestlcoin Core's other executables. Without needing to use any RPCs, this tool can currently create a new wallet file or display some basic information about an existing wallet, such as whether the wallet is encrypted, whether it uses an HD seed, how many transactions it contains, and how many address book entries it has.
Since version 2.16.0, Groestlcoin Core's built-in wallet has defaulted to generating P2SH-wrapped segwit addresses when users want to receive payments. These addresses are backwards compatible with all widely used software. Starting with Groestlcoin Core 2.20.1 (expected about a year after 2.18.2), Groestlcoin Core will default to native segwitaddresses (bech32) that provide additional fee savings and other benefits. Currently, many wallets and services already support sending to bech32 addresses, and if the Groestlcoin Core project sees enough additional adoption, it will instead default to bech32 receiving addresses in Groestlcoin Core 2.19.1. P2SH-wrapped segwit addresses will continue to be provided if the user requests them in the GUI or by RPC, and anyone who doesn't want the update will be able to configure their default address type. (Similarly, pioneering users who want to change their default now may set the addresstype=bech32 configuration option in any Groestlcoin Core release from 2.16.0 up.)
BIP 61 reject messages are now deprecated. Reject messages have no use case on the P2P network and are only logged for debugging by most network nodes. Furthermore, they increase bandwidth and can be harmful for privacy and security. It has been possible to disable BIP 61 messages since v2.17.2 with the -enablebip61=0 option. BIP 61 messages will be disabled by default in a future version, before being removed entirely.
The submitblock RPC previously returned the reason a rejected block was invalid the first time it processed that block but returned a generic "duplicate" rejection message on subsequent occasions it processed the same block. It now always returns the fundamental reason for rejecting an invalid block and only returns "duplicate" for valid blocks it has already accepted.
A new submitheader RPC allows submitting block headers independently from their block. This is likely only useful for testing.
The signrawtransactionwithkey and signrawtransactionwithwallet RPCs have been modified so that they also optionally accept a witnessScript, the witness script in the case of a P2WSH orP2SH-P2WSH output. This is compatible with the change to listunspent.
For the walletprocesspsbt and walletcreatefundedpsbt RPCs, if thebip32derivs parameter is set to true but the key metadata for a public key has not been updated yet, then that key will have a derivation path as if it were just an independent key (i.e. no derivation path and its master fingerprint is itself).
The -usehd configuration option was removed in version 2.16.0 From that version onwards, all new wallets created are hierarchical deterministic wallets. This release makes specifying -usehd an invalid configuration option.
This release allows peers that your node automatically disconnected for misbehaviour (e.g. sending invalid data) to reconnect to your node if you have unused incoming connection slots. If your slots fill up, a misbehaving node will be disconnected to make room for nodes without a history of problems (unless the misbehaving node helps your node in some other way, such as by connecting to a part of the Internet from which you don't have many other peers). Previously, Groestlcoin Core banned the IP addresses of misbehaving peers for a period (default of 1 day); this was easily circumvented by attackers with multiple IP addresses. If you manually ban a peer, such as by using the setban RPC, all connections from that peer will still be rejected.
The key metadata will need to be upgraded the first time that the HDseed is available. For unencrypted wallets this will occur on wallet loading. For encrypted wallets this will occur the first time the wallet is unlocked.
Newly encrypted wallets will no longer require restarting the software. Instead such wallets will be completely unloaded and reloaded to achieve the same effect.
A sub-project of Bitcoin Core now provides Hardware Wallet Interaction (HWI) scripts that allow command-line users to use several popular hardware key management devices with Groestlcoin Core. See their project page for details.
This release changes the Random Number Generator (RNG) used from OpenSSL to Groestlcoin Core's own implementation, although entropy gathered by Groestlcoin Core is fed out to OpenSSL and then read back in when the program needs strong randomness. This moves Groestlcoin Core a little closer to no longer needing to depend on OpenSSL, a dependency that has caused security issues in the past. The new implementation gathers entropy from multiple sources, including from hardware supporting the rdseed CPU instruction.
On macOS, Groestlcoin Core now opts out of application CPU throttling ("app nap") during initial blockchain download, when catching up from over 100 blocks behind the current chain tip, or when reindexing chain data. This helps prevent these operations from taking an excessively long time because the operating system is attempting to conserve power.
How to Upgrade?
Windows If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), then run the installer. OSX If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), run the dmg and drag Groestlcoin Core to Applications. Ubuntu http://groestlcoin.org/forum/index.php?topic=441.0
ALL NEW - Groestlcoin Moonshine iOS/Android Wallet
Built with React Native, Moonshine utilizes Electrum-GRS's JSON-RPC methods to interact with the Groestlcoin network. GRS Moonshine's intended use is as a hot wallet. Meaning, your keys are only as safe as the device you install this wallet on. As with any hot wallet, please ensure that you keep only a small, responsible amount of Groestlcoin on it at any given time.
Groestlcoin Mainnet & Testnet supported
Multiple wallet support
Electrum - Support for both random and custom peers
Biometric + Pin authentication
Custom fee selection
Import mnemonic phrases via manual entry or scanning
BIP39 Passphrase functionality
Support for Segwit-compatible & legacy addresses in settings
Support individual private key sweeping
UTXO blacklisting - Accessible via the Transaction Detail view, this allows users to blacklist any utxo that they do not wish to include in their list of available utxo's when sending transactions. Blacklisting a utxo excludes its amount from the wallet's total balance.
Ability to Sign & Verify Messages
Support BitID for password-free authentication
Coin Control - This can be accessed from the Send Transaction view and basically allows users to select from a list of available UTXO's to include in their transaction.
HODL GRS connects directly to the Groestlcoin network using SPV mode and doesn't rely on servers that can be hacked or disabled. HODL GRS utilizes AES hardware encryption, app sandboxing, and the latest security features to protect users from malware, browser security holes, and even physical theft. Private keys are stored only in the secure enclave of the user's phone, inaccessible to anyone other than the user. Simplicity and ease-of-use is the core design principle of HODL GRS. A simple recovery phrase (which we call a Backup Recovery Key) is all that is needed to restore the user's wallet if they ever lose or replace their device. HODL GRS is deterministic, which means the user's balance and transaction history can be recovered just from the backup recovery key.
Simplified payment verification for fast mobile performance
Groestlcoin Seed Savior is a tool for recovering BIP39 seed phrases. This tool is meant to help users with recovering a slightly incorrect Groestlcoin mnemonic phrase (AKA backup or seed). You can enter an existing BIP39 mnemonic and get derived addresses in various formats. To find out if one of the suggested addresses is the right one, you can click on the suggested address to check the address' transaction history on a block explorer.
If a word is wrong, the tool will try to suggest the closest option.
If a word is missing or unknown, please type "?" instead and the tool will find all relevant options.
NOTE: NVidia GPU or any CPU only. AMD graphics cards will not work with this address generator. VanitySearch is a command-line Segwit-capable vanity Groestlcoin address generator. Add unique flair when you tell people to send Groestlcoin. Alternatively, VanitySearch can be used to generate random addresses offline. If you're tired of the random, cryptic addresses generated by regular groestlcoin clients, then VanitySearch is the right choice for you to create a more personalized address. VanitySearch is a groestlcoin address prefix finder. If you want to generate safe private keys, use the -s option to enter your passphrase which will be used for generating a base key as for BIP38 standard (VanitySearch.exe -s "My PassPhrase" FXPref). You can also use VanitySearch.exe -ps "My PassPhrase" which will add a crypto secure seed to your passphrase. VanitySearch may not compute a good grid size for your GPU, so try different values using -g option in order to get the best performances. If you want to use GPUs and CPUs together, you may have best performances by keeping one CPU core for handling GPU(s)/CPU exchanges (use -t option to set the number of CPU threads).
Fixed size arithmetic
Fast Modular Inversion (Delayed Right Shift 62 bits)
SecpK1 Fast modular multiplication (2 steps folding 512bits to 256bits using 64 bits digits)
Use some properties of elliptic curve to generate more keys
SSE Secure Hash Algorithm SHA256 and RIPEMD160 (CPU)
Groestlcoin EasyVanity 2020 is a windows app built from the ground-up and makes it easier than ever before to create your very own bespoke bech32 address(es) when whilst not connected to the internet. If you're tired of the random, cryptic bech32 addresses generated by regular Groestlcoin clients, then Groestlcoin EasyVanity2020 is the right choice for you to create a more personalised bech32 address. This 2020 version uses the new VanitySearch to generate not only legacy addresses (F prefix) but also Bech32 addresses (grs1 prefix).
Ability to continue finding keys after first one is found
Includes warning on start-up if connected to the internet
Ability to output keys to a text file (And shows button to open that directory)
Show and hide the private key with a simple toggle switch
Show full output of commands
Ability to choose between Processor (CPU) and Graphics Card (GPU) ( NVidia ONLY! )
Features both a Light and Dark Material Design-Style Themes
Free software - MIT. Anyone can audit the code.
Written in C# - The code is short, and easy to review.
Groestlcoin WPF is an alternative full node client with optional lightweight 'thin-client' mode based on WPF. Windows Presentation Foundation (WPF) is one of Microsoft's latest approaches to a GUI framework, used with the .NET framework. Its main advantages over the original Groestlcoin client include support for exporting blockchain.dat and including a lite wallet mode. This wallet was previously deprecated but has been brought back to life with modern standards.
Works via TOR or SOCKS5 proxy
Can use bootstrap.dat format as blockchain database
Import/Export blockchain to/from bootstrap.dat
Import wallet.dat from Groestlcoin-qt wallet
Export wallet to wallet.dat
Use both groestlcoin-wpf and groestlcoin-qt with the same addresses in parallel. When you send money from one program, the transaction will automatically be visible on the other wallet.
Rescan blockchain with a simple mouse click
Works as a full node and listens to port 1331 (listening port can be changed)
Fast Block verifying, parallel processing on multi-core CPUs
Mine Groestlcoins with your CPU by a simple mouse click
All private keys are kept encrypted on your local machine (or on a USB stick)
Lite - Has a lightweight "thin client" mode which does not require a new user to download the entire Groestlcoin chain and store it
Free and decentralised - Open Source under GNU license
Fixed Import/Export to wallet.dat
Rescan wallet option
Change wallet password option
Address type and Change type options through *.conf file
Import from bootstrap.dat - It is a flat, binary file containing Groestlcoin blockchain data, from the genesis block through a recent height. All versions automatically validate and import the file "grs.bootstrap.dat" in the GRS directory. Grs.bootstrap.dat is compatible with Qt wallet. GroestlCoin-Qt can load from it.
In Full mode file %APPDATA%\Groestlcoin-WPF\GRS\GRS.bootstrap.dat is full blockchain in standard bootstrap.dat format and can be used with other clients.
Groestlcoin Electrum Personal Server aims to make using Electrum Groestlcoin wallet more secure and more private. It makes it easy to connect your Electrum-GRS wallet to your own full node. It is an implementation of the Electrum-grs server protocol which fulfils the specific need of using the Electrum-grs wallet backed by a full node, but without the heavyweight server backend, for a single user. It allows the user to benefit from all Groestlcoin Core's resource-saving features like pruning, blocks only and disabled txindex. All Electrum-GRS's feature-richness like hardware wallet integration, multi-signature wallets, offline signing, seed recovery phrases, coin control and so on can still be used, but connected only to the user's own full node. Full node wallets are important in Groestlcoin because they are a big part of what makes the system be trust-less. No longer do people have to trust a financial institution like a bank or PayPal, they can run software on their own computers. If Groestlcoin is digital gold, then a full node wallet is your own personal goldsmith who checks for you that received payments are genuine. Full node wallets are also important for privacy. Using Electrum-GRS under default configuration requires it to send (hashes of) all your Groestlcoin addresses to some server. That server can then easily spy on your transactions. Full node wallets like Groestlcoin Electrum Personal Server would download the entire blockchain and scan it for the user's own addresses, and therefore don't reveal to anyone else which Groestlcoin addresses they are interested in. Groestlcoin Electrum Personal Server can also broadcast transactions through Tor which improves privacy by resisting traffic analysis for broadcasted transactions which can link the IP address of the user to the transaction. If enabled this would happen transparently whenever the user simply clicks "Send" on a transaction in Electrum-grs wallet. Note: Currently Groestlcoin Electrum Personal Server can only accept one connection at a time.
Use your own node
Uses less CPU and RAM than ElectrumX
Used intermittently rather than needing to be always-on
Doesn't require an index of every Groestlcoin address ever used like on ElectrumX
UPDATED – Android Wallet 7.38.1 - Main Net + Test Net
The app allows you to send and receive Groestlcoin on your device using QR codes and URI links. When using this app, please back up your wallet and email them to yourself! This will save your wallet in a password protected file. Then your coins can be retrieved even if you lose your phone.
Add confidence messages, helping users to understand the confidence state of their payments.
Handle edge case when restoring via an external app.
Count devices with a memory class of 128 MB as low ram.
Introduce dark mode on Android 10 devices.
Reduce memory usage of PIN-protected wallets.
Tapping on the app's version will reveal a checksum of the APK that was installed.
Fix issue with confirmation of transactions that empty your wallet.
Groestlcoin Sentinel is a great solution for anyone who wants the convenience and utility of a hot wallet for receiving payments directly into their cold storage (or hardware wallets). Sentinel accepts XPUB's, YPUB'S, ZPUB's and individual Groestlcoin address. Once added you will be able to view balances, view transactions, and (in the case of XPUB's, YPUB's and ZPUB's) deterministically generate addresses for that wallet. Groestlcoin Sentinel is a fork of Groestlcoin Samourai Wallet with all spending and transaction building code removed.
Checking my bitcoin wallet after two years and I find that all my bitcoin is gone (0.5 bitcoin)
After checking my bitcoin account after two years, 0.00010757 of a bitcoin remains even though I explicitly remember having half a bitcoin left. My first thought someone somehow stole it. But after looking through my transaction history, it seems that there were additional transactions made alongside the transactions that were made before. Here is a link to a chart of my last three transactions made to CoinBase: https://i.stack.imgur.com/8sZIG.png The three transactions highlighted in green were the ones that were supposed to happen but I noticed that these other mysterious transactions made alongside them also had the same IDs as the intentional transactions. The three that aren't highlighted add up to the amount that I remembered that I had two years ago, appx. 0.50055605 bitcoin. I'm not sure what these random transactions are and I'm not sure why after two years, my .5 bitcoin just vanished. I thought that the matching IDs would give me some sort of clue and it seems like these random transactions are going to a different address. Were they supposed to be sent back to my own wallet or something? Here are the three IDs respectively: f034f9408736868ed5d070fb8fe6b5674881573815be16b791782fcdcec5d6e6 ebe2b9acce094d175577efedf8d5a1edc83ccbf5291e155a12af1c2dc5e6dd10 9cdd52384c465acd38141e6ead748cb85f74e8afef8781989e5c3592cb6bc493 I am also currently using the Bitcoin-Qt client. After reading about it it seems like bitcoin has this change system and I think that that is probably the culprit. I looked through my Bitcoin-Qt client and I see no additional addresses. Anyone have any ideas? Edit: I went and tried validating the three addresses that murdocsvk posted but it said that they weren't mine. Would it be worth it to try to salvagewallet? I don't have any more backups so this is the only copy I have.
Hello! I am fairly new to Bitcoin, but one year ago, I made a Bitcoin address on Bitcoin-Qt, but I stopped using it, because the whole database downloading took so much space on my disk. I have my wallet.dat file, but I don't know, where can I use it. I tried Electrum, but it seems that the wallet.dat import doesn't work there. Can you recommend me any other wallets, where I can import that file? Thank you.
I mistakenly didn't have a fee on my transaction... please help!
I sent a transaction out and realized afterwards that I put the fee on zero. I have been waiting a few days to see if anyone would pick it up and it is still lost. I checked blockexplorer and my transaction is not listed. The transaction was sent out on 8/23 and I am using Bitcoin-QT. Is there anything I can do to possibly cancel or double spend my transaction to make it go through? Edit: I ran zapwallettxes and rescan and the transaction is still showing in my recent transactions as status: 0/unconfirmed Edit2: I didn't have the latest version of bitcoin-qt installed so zapwallettxes wasn't doing anything. After downloading the latest version (v0.13.0; although any that are v0.9.0 and up will work for this), I was able to run the commands and my bitcoins were back in my wallet! Thank you to everyone who commented. Also, for any new guys who did this to themselves and are searching for a fix. To run those commands with the program, you need to go to your file location from command line (this is where bitcoin-qt actually is in your folder), when you're there the command is "bitcoin-qt -zapwallettxes=1 -rescan"
Help me recover my bitcoins from my wallet backups.
Hey guys. The history: In 2013 or 2014 I bought 1 BTC and I stored it in one wallet (don't remember which). I have a wallet.dat in my PC and an Armory wallet backup on pdf (paper). The Armory Backup was encrypted and now I can't see public addresses, but AFAIK this shouldn't be an issue because the backup was done later than the last transfer. How can I know if there are bitcoins in the paper wallet? I've had lots of problems with Armory and can't manage to sync the blockchain. On the otherhand I have a HDD from that era with Bitcoin QT installed and a wallet.dat there. The thing is that I can't access that wallet and I don't know if the funds are there. How can I tell if there are BTCs there? I checked the last public key used and still it has the money in it (checked n blockchain.info) The last option is that I transferred that 1 BTC to other wallet that I lost and never backed-up, but I think this is very unlikely. Is there anything I can do to find my missing bitcoins?
And this is Bitcoin-QT: And this is MultiBit: Step 3 – Save your backup to a flash drive. Save your exported backup on to a flash drive and keep it in a secure place. Some wallets will allow you to password protect your backup so that if someone gets a hold of the file he won’t be able to use it. Bitcoin-Qt is the so – called" official " client of the network, which is developed and promoted by Bitcoin Foundation, a non-profit organization uniting core developers and responsible for the community's contacts with corporations and governments.Bitcoin Foundation branches are opened in several dozens of countries around the world. Don't understand most of the elements that you find in your Bitcoin core wallet or your Altcoin QT wallet? Educate yourself. Make use of this guide where we've explained everything in and out about Crypto currency wallet from backup to encryption to exporting your wallet private keys. Ein Backup Ihrer Wallet, verwahrt an einem sicheren Ort, kann Sie vor Verlust durch Computerdefekte und viele menschliche Fehler schützen. Ein Backup ermöglicht es Ihnen aber auch, die Kontrolle über Ihre Wallet zurückzuerlangen, nachdem Ihr Smartphone oder Computer gestohlen wurde, falls Sie Ihre Wallet verschlüsselt haben. Legen Sie Sicherheitskopien Ihrer kompletten Wallet an. Manche ... ln -s /Volumes/Bitcoin ~/Library/Application Support/Bitcoin. Don't forget to mount your image before using Bitcoin and unmount it after quitting. Backing up just your wallet file. Follow these instructions to backup just the wallet.dat file. This results in a smaller disk image, but it's more complicated to do. Open Disk Utility
How to recover funds from a currupted bitcoin wallet
bitcoin qt bitcoin qr code bitcoin qt synchronizing with network bitcoin qt wallet location ... Live Bitcoin Trading With DeriBot on Deribit DeriBot Backup 134 watching. Live now; TEEKA'S TOP 5 ... This video is unavailable. Watch Queue Queue. Watch Queue Queue how to do bitcoin mining mining rig mining farm earn money online Roi Payouts tutorial. Category Travel & Events; Show more Show less. Loading... Autoplay When autoplay is enabled, a suggested ... Extract Private Keys from Trust Wallet - works for Bitcoin, Ethereum, Litecoin and other cryptos - Duration: 5:48. Crypto Coin Investor 3,690 views This short tutorial explains what a Bitcoin wallet backup is and how to create it on 3 different wallets: Blockchain.info, Bitcoin-QT and MultiBit. For more information and tutorials about Bitocin ...