Is there any way to run it on a Cheap VPS? 200GB is much...
You can certainly run Bitcoin Core without using 200 GB of disk space. However Bitcoin Core will likely need more computing power than a cheap VPS can provide. I dont want to ruin my 40/2 connection. Is there Any way to throttle the outgoing internet for this node on a rasp PI?
Yes, read https://bitcoin.org/en/full-node#reduce-traffic |
|
|
|
Agree. The "<blockHash> OP_BLOCKHASHEXIST" prefix should be part of
scriptPubKey of the newly created transaction. That is:
For new transaction that consumes P2PK, P2PKH or P2SH pre-hard fork output
Blockchain1x: scriptPubKey = <usual stuff> <blockHash1x> OP_BLOCKHASHEXIST
Blockchain2x: scriptPubKey = <usual stuff> <blockHash2x> OP_BLOCKHASHEXIST
While this would work to make the transaction that spends these outputs to be replay protected, the transaction containing these outputs themselves are not replay protected. The output scripts of a transaction are not executed until they are spent from because output scripts are only partial scripts. So a transaction that creates such outputs could be replayed and such replay would cause loss of funds because the output would be unspendable on one chain. |
|
|
|
If you want to reuse your blockchain data in a fork (for example, to access the Bitcoin Gold coins after the fork), do I need to put both blocks and chainstate folder, or chainstate will not be compatible even if both Bitcoin Core and Bitcoin Gold Core (or whatever is called) are basically the same? (let's say it's an 0.15 fork, which I still don't know) or should I only use the blocks folder because the chainstate folder can never be compatible with a fork?
The chainstate folder can be compatible in a fork. However if the chainstate folder is for a blockchain that is synced past the fork, it may not necessarily work when switching to the other fork of the blockchain. |
|
|
|
First of all, BIPs should be submitted to the bitcoin-dev mailing list and must be in the BIP format as specified in BIPs 1 and 2Secondly, your proposal is flawed and does not provide replay protection. Scriptsig's are not protected by the digital signature so the data in a scriptsig other than the signature and public key can be modified without invalidating the transaction. So one could simply change the value for pushed after OP_BLOCKHASHEXIST to be the block for the other chain and the transaction would still be valid. Sure the txid would change, but it would still result in transaction replay in that essentially the same transaction is broadcast on both chains and results in the same spends on both chains. Also, the block hash should be pushed to the stack before OP_BLOCKHASHEXIST is called. Otherwise OP_BLOCKHASHEXIST cannot consume anything in its operation as the thing it is supposed to check comes after it is executed. |
|
|
|
does bitcoin-core version has to be same ? on my both machines ?
It is advisable to have the same Bitcoin Core version because sometimes database formats will change between major versions (the UTXO database in the chainstate folder changed from 0.14.x to 0.15.x). |
|
|
|
|
All you need are the blocks and the chainstate folders.
|
|
|
|
|
There is something wrong with the wallet.dat file. On all of the systems where you have been seeing a problem, have you been copying the same wallet.dat file to each of them and trying to load it there?
|
|
|
|
|
That is correct, the timestamp's maximum time is in 2106. After that, a lot of things could break. However this is a known problem and it is known almost a century in advance, so we have a lot of time to plan something to do. A hard fork could be done to expand the field to 64 bits or to some other scheme that does not have a maximum. I believe a soft fork could also be done to handle this.
|
|
|
|
I am was using Bitcoin-Qt v0.8-5-beta then I updated to Bitcoin Core 0.15.0 and they both keep crashing at start up
What have you tried so far? Please post the entire debug.log file. |
|
|
|
|
There will be one, but Bitcoin Gold has not officially launched yet so such a client has not been release. They only have the snapshot of the blockchain/UTXO set so far.
|
|
|
|
Thank you. However, although this won't save the password to history, even with -stdin, the password gets displayed without any encryption on the screen. Is there a workaround to this?
Once you get the data you need, you can do clear a bunch of times. And one more thing. I noticed that the newest version of bitcoin core has support for multiple wallets. How do I set this up to have for example 5 different wallets but all using the same blockchain, so basically I do not want to download the entire blockchain again and store the blockchain 5 times, I only need the bitcoin-cli or the RPC to view / spend bitcoins from any wallet I want. Are there specific bitcoin-cli commands that are useful for selecting the wallet file I want to use?
Start Bitcoin Core with as many -wallet=<wallet name> arguments (or add them to your bitcoin.conf file) as you want wallets to use. When you use bitcoin-cli with any wallet related command, you will need to use the -rpcwallet=<walet name> argument to specify the wallet that you want to use. For example, you might do $ bitcoind -daemon -wallet=wallet1 -wallet=wallet2
To start Bitcoin Core with two wallets, wallet1 and wallet2. If you want to do stuff with wallet1, you would do $ bitcoin-cli -rpcwallet=wallet1 getwalletinfo
|
|
|
|
|
Can you post full the debug.log file for Bitcoin Core?
|
|
|
|
|
What software are you using? What version number (don't just say latest)?
|
|
|
|
Depending on the fork, and whether it has replay protection or not, it is possible that the transaction could become confirmed on BOTH forks. In either case, the most recent confirmed transaction on a given fork will determine which address has control of the coins on that fork.
Is this something that has been "implemented"/fixed in bitcoingold already? Various articles i've read over the past week tells me they don't have such a thing, but i'm wondering with what they are going to replace that, if they're not adding it. https://support.bittrex.com/hc/en-us/articles/115002320451-Statement-on-Bitcoin-Gold-BTG-Seems to me that they really don't think that it is such a big deal..? Replay protection is supposed to be implemented for Bitcoin Gold but they have not done so yet. |
|
|
|
So Bitcoin Gold forked with minimal fireworks...
It technically hasn't even launched yet. They just now have the UTXO/blockchain snapshot that they want. Coinbase also announced that segwit2x will be call B2X on thier platform. Does the segwit2x update create a new coin?? Why is Coinbase labeling it at B2X?
Segwit2x is a hard fork, so it will create an altcoin. |
|
|
|
|
What you want to know is whether you have the address in your wallet. I'm not sure that a search function is necessarily the way to go, you don't want to search for it since you already have it, you just want to know if it is in your wallet. You can do that right now using the debug console with the validateaddress command. Just do validateaddress <address> and in the output you will see something that says ismine. If the address is yours and you have the private key, that field will say true.
|
|
|
|
Is there a safer way to not post the password directly on command line?
This command is also stored on bash history, and it would require removing the history file every time you decrypt your wallet for a short period of time.
Use bitcoin-cli with the -stdin parameter. The parameters will then be entered on stdin after you enter the command, one on each line. This keeps it out of the bash history. So you would do something like $ bitcoin-cli -stdin walletpassphrase
<passphrase>
<timeout> and complete the command with Ctrl + D to signal EOF. Then the command will be sent and you will get a response. |
|
|
|
I sent it to a Multibit Wallet on the stolen laptop. I’ve seen Multibit has since stopped being supported. Will it be possible to recover this wallet? I’ve got the private key and a code word phase about 17 or 18 words long.
I’ve tried to restore through electrum wallet but think perhaps it might pre-date the BIP 32 seeds it asks for as I set up the original wallet in 2014.
No, you are just restoring it incorrectly. First of all, what you have is a BIP 39 mnemonic, not a BIP 32 seed. However Electrum does not use BIP 39 by default. To tell it to use BIP 39, you must click the Options button and choose the BIP 39 checkbox. Then it should work. |
|
|
|
currently this account was worth 0.02, unbelievable. i think OP should change how the calculating work based on bitcoin price nowadays
It's open source software. Pull requests welcome. |
|
|
|
I'm back and trying to get this going again. I just tried -salvagewallet for the first time (this on dogecoin.app, not bitcoin yet).
This is on a new machine with new versions of the apps, freshly synced to their respective blockchains (which took about 2 months for bitcoin).
So I ran -salvagewallet on my dogecoin wallet. It did something that didn't take very long at all. Then after a minute or so, it quit and left me with wallet.242340234.back and wallet.dat. So I fired up dogecoin core.app and once it rescanned everything, I had..... an empty wallet. Which kind of makes sense since the .bak wallet was 12 MB and the new one, presumably the restored one, was a few KB.
Am I doing something wrong here? There's almost no instructions on the web for how to use the -salvagewallet feature, beyond "just use -salvagewellet".
Don't use -salvagewallet in Bitcoin Core. It is broken and will likely corrupt your wallet further (these are known issues for which we are trying to fix, but salvaging corrupted wallets is a dangerous process in general). Anyways, I don't think your wallet is corrupted here. Have you tried reindexing the blockchain? Or completely resyncing the blockchain? |
|
|
|
|
Show Posts
