This topic has been moved to Trashcan. Duplicate |
|
|
|
Can I at least turn the computer off for a while and continue where I left at? Im worried that if I launch the client again with the -reindex-chainstate options.
Yes. When you relaunch it, be sure that you do not have --reindex or --reindex-chainstate in your command as those will cause it to restart the reindex. When you start it again without those options, it will pick up where it left off. Well, I would like to be able to run older software if I choose to. The paranoid in me feels like it's not a good idea to lose compatibility with older clients. Who knows if you ever need to go back for some reason?
Unfortunately you can't. Older versions of Bitcoin Core do not know what to do with the HD wallets, so they will refuse to start with one. |
|
|
|
|
Please post the contents of your armorylog.txt file.
|
|
|
|
|
Your difficulty would be 1/60th of Bitcoin's so it would be much easier to perform double spend attacks like Finney attacks. Increasing the block frequency means that 1 confirmation is much less secure; to have the same security of 1 confirmation on the Bitcoin blockchain, you would still have to wait 10 minutes so that the same amount of work is being performed (and longer if you are not expecting all of Bitcoin's hash rate to switch to this new coin). So sure, the first confirmation would be fast, but that confirmation is not very secure and a small mining pool operator could perform Finney attacks and double spend.
Also, not only would there be a lot of orphaned blocks, there would also be many multi-block blockchain reorganizations.
|
|
|
|
So I'm reading that this Segwit2X forking could expose BTC users to replay attacks (and maybe to other threats via segwit), but it is not clear at what conditions. To effect replay attacks would take a majority of mining power? Or what exactly?
Replay attacks don't require any hash power, or even any person. Replay can happen accidentally. Replay is that a transaction made on one chain is valid on the other, and becomes confirmed on both chains. The only way to have replay protection is to include it as part of the hard fork. |
|
|
|
|
If your wallet has received a lot of small payments, then it is possible that the value of each of those payments is too small so that the entirety of the input value is consumed by fees when you spend from them. Since you say you have collected faucet earnings, I suspect this is the case.
|
|
|
|
I don't think pushing it will help because it has unspent outputs
Unspent outputs is fine; I think you mean unconfirmed inputs. Since all of the inputs of your transaction are unconfirmed, there isn't anything you can do except wait for all of those transactions to confirm. |
|
|
|
Is this the only version working with BCH chain?
Yes. |
|
|
|
I obtained .1 bitcoin ( I believe that was the amount) back in either 2011 or 2013 ( I have BC files on my computer from both of those dates ). I wanted to get involved in using them so I downloaded the current wallet and ran the synchronization. I have what I believe are all the old files on a remote hard drive. A search reveals 89 files ( none of them dat ). They are H, RC ,QM, CPP, application, PNG, ICNS. Which of these files do I need ? Can you share, click by click, how I copy & paste or transfer these ?  Thank you ! There is a file bitcoin_da.qm and one bitcoin_da Could these be it ?
No. All of those files are unrelated. Those are for the source code. Only files that have a .dat file extension could be the wallet file. Specifically files named wallet.dat. If you do not find any such files, then the wallet is not on your machine. Side note: please stop using bold red font; it's really annoying. |
|
|
|
|
Change your units. Electrum defaults to using mBTC; 1 mBTC = 0.001 BTC.
|
|
|
|
Alright thank you for your answer. I will modify the scriptPubkey accordingly, but then do you have any idea how I should sign the transaction ?
No choice but "by hand", right ?
You could modify Core so that it knows what kind of scriptPubKey that is so it can sign for it. |
|
|
|
Thanks for your help, but I'm still a little unclear on #2. Let's say my hardware wallet has received 1000 inputs of 0.001 each, totaling to 1 BTC. I then send the 1 BTC to someone, leaving my balance to 0. I then receive another 1 BTC from someone else, totaling to 1 BTC again. At this time my hardware wallet would have received 1001 inputs. However the first 1000 inputs have been spend already. The next time I wish to send from my hardware wallet, the chip would only need to sign once? In other words, are "spent inputs" no longer needed to be signed again?
Yes. Inputs that have been spent cannot be spent again. There is no need to sign for them after they are spent. |
|
|
|
When you say master public key do you mean extended master public key or "simple" master public key without a chain code?
The extended master public key. |
|
|
|
thanks achow101, yesterday I saw diff 1, today is much much higher ( getmininginfo ) I missed the opportunity because I was trying to isolate the energy consumption of "bitcoind.exe" on CPU core ... (on Visual Studio there is a tool called "performance profiler" on debug tab .. but I'm not sure if the metrics are that precise, even Microsoft makes a note regards to it, metrics is good enough for batteries consumption thought ...
ed; typo
IIRC the mining code in Bitcoin Core has been disabled for everything but regtest, so you can't use that to CPU mine testnet. You can use other, more optimized software for CPU mining like cpuminer. |
|
|
|
Knowledge of the private key alone does not make it possible to find neither siblings, nor parent (nor other ancestors), nor children of that private key. The reason being that child key derivation function actually combines three values: private/public key, index number and key chain code. Without the knowledge of the chain code, you can't find children of compromised private key.
Knowing the master public key along with a child private key makes it possible to find the corresponding master private key. That then makes it possible for someone to figure out all of your private keys and thus steal your funds. So if you leak a child private key, you had better keep the master public key secret. This only applies to keys generated without hardening. • calculate I = HMAC-SHA512(Key = "Bitcoin seed", Data = S) => QUESTION: What's the difference between Bitcoin seed and S?
The Key is literally the string "Bitcoin Seed". S is the actual random number you just generated. |
|
|
|
So i have this idea,please tell me if this is SAFE and will work ok.
That plan is safe assuming that you don't have any malware on your system and it will work. If i do what i said in 1 ,what is better to import or sweep privet key to Electrum wallet ?
Since you are planning to move the coins immediately, it is better for you to import the key so as to not need to pay for more in transaction fees. And, if i sweep/import BTC from that paper wallet do i still have same ammount BCH there ?
Yes. Moving BTC will not effect the BCH. |
|
|
|
1) I've recently found interest in getting a Ledger Nano S or Ledger Blue. I am currently using a Trezor Wallet, is it possible for me to "restore" my account (from Trezor) to my Ledger Wallet? In other words, is the Ledger Wallet compatible with the Trezor Wallet?
Yes. 2) Let's say I received 1000 payments of 0.001BTC in my hardware wallet. If I want to send 1BTC, the chip will have to sign 1000 times. If I want to send 0.5BTC, the chip will have to sign 500 times. Now, if I withdraw 1BTC from my hardware wallet and deposit another 2BTC, how many times will the chip have to sign for my 2BTC withdrawal? Will it be 1 time or 1001 times?
If the only input is the 2 BTC input, then a 2 BTC send will only have 1 input and thus only 1 signature operation. 3) Let's say I received 1 payment of 2BTC in my hardware wallet. If I want to send 1.75BTC to someone, the chip will need to sign once, right? If I send the remaining 0.25BTC to another person, the chip will have to sign once again, is that accurate?
Yes. You will receive the 0.25 BTC as a new output which is sent back to yourself. |
|
|
|
It is then safe to copy the blocks folder without the chainstate folder? I just want to save as much time as possible.
That should work. You will need to start Bitcoin ABC with the -reindex-chainstate option. Yes, obviously for privacy reasons, sending your entire wallet into an exchange address is stupid. That's why im asking, what exchange can I use that will let me generate different deposit addresses? Poloniex has BCH for example, but it has a permanent deposit address, so I can't use that one.
I can't help you there. Just make accounts on exchanges until you find one you like. Also, can I send the BCH directly to the exchange after I move the BTC addresses to other addresses?
Yes. BCH has implemented replay protection so your BTC transactions won't be valid on the BCH chain (and thus your BCH coins won't move) and vice versa. Please Bitcoin devs, make Bitcoin more private by default.
Unfortunately that is fairly hard to do. People are working on it, but there are tradeoffs and it all requires doing a fork at some point. Once segwit activates, those things can be deployed as soft forks. The "bitcoin-0.14.6-win64.zip" one, and there's a bunch of .exe files, what one do I run?
bitcoin-qt.exe Or should I download this?
bitcoin-0.14.6-win64-setup-unsigned.exe
But it says "unsigned..."
The unsigned means that the binary was not signed by Microsoft blessed signing key. This means that windows will warn you saying that the executable comes from an unknown source. Yes. The filename next to each hash indicates which file the hash is for. To verify, hash the files you downloaded with SHA256 and compare to the hashes they provided. Of course this doesn't mean all that much, just that the files you downloaded are the ones that the website intended to distribute. You don't actually know whether those are the files that the developers actually intended to distribute as they don't provide any file with a developer's GPG signature so an attacker could have put those files there with a different version of Bitcoin ABC. I just want to be sure im not downloading any viruses.
The only way to be sure of that is to audit the code yourself (good luck, everything is hard to read) and build it from source yourself once you are sure there are no viruses there. This holds true for any open source software, not just Bitcoin ABC. If you move your BTC first to a new wallet, then your BTC will be safe even if what you downloaded will steal the coins in the wallet file. |
|
|
|
Am I right in saying that if it just says key then that is a private key. Thanks for taking the time to reply.
Yes, things that contain key at the beginning of the key-value pair are usually followed by the public key as the remainder of the key part of the key-value pair, and the value is usually the private key. However some things do contain the word key but aren't actually keys, like keymeta. For a bitcoin private key, it will have a string of characters which will either begin with a 5, a K or an L? Is this the case with what comes after the "key" in your .dat file.
No. Please don't post if you don't know what you are talking about. The Bitcoin Core wallet files do not store keys in Wallet Import Format; WIF is not the only format for private keys. It is far more efficient to store things in binary in a different format that is not human readable. |
|
|
|
Last week somebody was mining on the testnet using an S9, compared to 13 Th, the couple Gh you get with your cpu won't give you high odds of hitting a testnet block.
The difficulty resets to 1 if a block is not found in 20 minutes, so you can CPU mine then. The difficulty can also be gamed to be set to 1 for an entire retarget period, and it can only increase at most by a factor of 4, so CPU mining is viable at those times. By the way: testnet addresses start with m or n
Testnet P2SH addresses start with 2. |
|
|
|
|
Show Posts
