 Show Posts
|
|
Pages: [1]
|
|
1
|
Bitcoin / Bitcoin Technical Support / Help, 'Checking all blk files' takes almost 20 minutes to start the Qt wallet.
|
on: December 19, 2017, 05:39:16 AM
|
Hi, I install the bitcoin-qt wallet in my macpro and it worked well. But it takes much more time to start the qt wallet recently. Basically the step 'Checking all blk files are present...' takes almost 20 minutes. Does someone get this? Here is some info from debug file. As you can see from these two lines, I think it would not be the normal behavior. 2017-12-19 02:52:52 Checking all blk files are present...
2017-12-19 03:11:41 LoadBlockIndexDB: transaction index enabled
Could someone give me some hints to fix it? It's annoying. 2017-12-19 02:52:47 Bitcoin version v0.15.0.1
2017-12-19 02:52:47 InitParameterInteraction: parameter interaction: -whitelistforcerelay=1 -> setting -whitelistrelay=1
2017-12-19 02:52:48 Assuming ancestors of block 0000000000000000003b9ce759c2a087d52abc4266f8f4ebd6d768b89defa50a have valid signatures.
2017-12-19 02:52:48 Using the 'standard' SHA256 implementation
2017-12-19 02:52:48 Using RdRand as an additional entropy source
2017-12-19 02:52:48 Default data directory /Users/abc/Library/Application Support/Bitcoin
2017-12-19 02:52:48 Using data directory /Users/abc/BTCtmp
2017-12-19 02:52:48 Using config file /Users/abc/BTCtmp/bitcoin.conf
2017-12-19 02:52:48 Using at most 125 automatic connections (12544 file descriptors available)
2017-12-19 02:52:48 Using 16 MiB out of 32/2 requested for signature cache, able to store 524288 elements
2017-12-19 02:52:48 Using 16 MiB out of 32/2 requested for script execution cache, able to store 524288 elements
2017-12-19 02:52:48 Using 4 threads for script verification
2017-12-19 02:52:48 scheduler thread start
2017-12-19 02:52:48 HTTP: creating work queue of depth 16
2017-12-19 02:52:48 Config options rpcuser and rpcpassword will soon be deprecated. Locally-run instances may remove rpcuser to use cookie-based auth, or may be replaced with rpcauth. Please see share/rpcuser for rpcauth auth generation.
2017-12-19 02:52:48 HTTP: starting 4 worker threads
2017-12-19 02:52:48 init message: Verifying wallet(s)...
2017-12-19 02:52:48 Using BerkeleyDB version Berkeley DB 4.8.30: (April 9, 2010)
2017-12-19 02:52:48 Using wallet wallet.dat
2017-12-19 02:52:48 CDBEnv::Open: LogDir=/Users/abc/BTCtmp/database ErrorFile=/Users/abc/BTCtmp/db.log
2017-12-19 02:52:48 Cache configuration:
2017-12-19 02:52:48 * Using 56.2MiB for block index database
2017-12-19 02:52:48 * Using 8.0MiB for chain state database
2017-12-19 02:52:48 * Using 385.8MiB for in-memory UTXO set (plus up to 286.1MiB of unused mempool space)
2017-12-19 02:52:48 init message: 正在加载区块索引...
2017-12-19 02:52:48 Opening LevelDB in /Users/abc/BTCtmp/blocks/index
2017-12-19 02:52:48 Opened LevelDB successfully
2017-12-19 02:52:48 Using obfuscation key for /Users/abc/BTCtmp/blocks/index: 0000000000000000
2017-12-19 02:52:52 LoadBlockIndexDB: last block file = 1105
2017-12-19 02:52:52 LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=59, size=59618641, heights=499597...499888, time=2017-12-16...2017-12-18)
2017-12-19 02:52:52 Checking all blk files are present...
2017-12-19 03:11:41 LoadBlockIndexDB: transaction index enabled
2017-12-19 03:11:41 Opening LevelDB in /Users/abc/BTCtmp/chainstate
2017-12-19 03:11:42 Opened LevelDB successfully
2017-12-19 03:11:42 Using obfuscation key for /Users/abc/BTCtmp/chainstate: 8c3d20bc8e5d080e
2017-12-19 03:11:44 Loaded best chain: hashBestChain=00000000000000000034f7bd2bffb12b590eada706b9b985a458b0bf135c4291 height=499888 date=2017-12-18 02:55:58 progress=0.999045
2017-12-19 03:11:44 init message: Rewinding blocks...
2017-12-19 03:11:46 init message: 正在验证区块...
2017-12-19 03:11:46 Verifying last 6 blocks at level 3
2017-12-19 03:11:46 [0%]...[16%]...[33%]...[50%]...[66%]...[83%]...[99%]...[DONE].
2017-12-19 03:17:51 No coin database inconsistencies in last 7 blocks (12759 transactions)
2017-12-19 03:17:51 block index 1502639ms
2017-12-19 03:17:51 init message: 正在加载钱包...
2017-12-19 03:17:51 nFileVersion = 150001
2017-12-19 03:17:51 Keys: 2002 plaintext, 0 encrypted, 2002 w/ metadata, 2002 total
2017-12-19 03:17:51 wallet 58ms
2017-12-19 03:17:51 setKeyPool.size() = 2000
2017-12-19 03:17:51 mapWallet.size() = 0
2017-12-19 03:17:51 mapAddressBook.size() = 1
2017-12-19 03:17:51 mapBlockIndex.size() = 499889
2017-12-19 03:17:51 nBestHeight = 499888
2017-12-19 03:17:51 torcontrol thread start
2017-12-19 03:17:51 Bound to [::]:8333
2017-12-19 03:17:51 Bound to 0.0.0.0:8333
2017-12-19 03:17:51 init message: Loading P2P addresses...
2017-12-19 03:17:51 Loaded 64067 addresses from peers.dat 272ms
2017-12-19 03:17:51 init message: 加载黑名单
2017-12-19 03:17:51 init message: 正在启动网络线程...
2017-12-19 03:17:51 net thread start
2017-12-19 03:17:51 dnsseed thread start
2017-12-19 03:17:51 addcon thread start
2017-12-19 03:17:51 opencon thread start
2017-12-19 03:17:51 init message: 加载完成
2017-12-19 03:17:51 msghand thread start
2017-12-19 03:17:51 GUI: Platform customization: "macosx"
2017-12-19 03:17:51 GUI: PaymentServer::LoadRootCAs: Loaded 161 root certificates
2017-12-19 03:17:53 receive version message: /Satoshi:0.15.1/: version 70015, blocks=500065, us=182.50.114.226:45586, peer=0
2017-12-19 03:17:54 receive version message: /Satoshi:0.14.0/: version 70015, blocks=500065, us=182.50.114.226:45558, peer=1
2017-12-19 03:18:00 receive version message: /Satoshi:0.15.1/: version 70015, blocks=500065, us=182.50.114.226:13928, peer=2
2017-12-19 03:18:02 P2P peers available. Skipped DNS seeding.
2017-12-19 03:18:02 dnsseed thread exit
2017-12-19 03:18:13 receive version message: /Satoshi:0.15.0.1/: version 70015, blocks=500065, us=182.50.114.226:14007, peer=3
2017-12-19 03:18:13 receive version message: /Satoshi:0.15.1/: version 70015, blocks=500065, us=182.50.114.226:14058, peer=4
|
|
|
|
|
2
|
Bitcoin / Pools / Re: [14000Th] Eligius: 0% Fee BTC, 105% PPS NMC, No registration, CPPSRB
|
on: November 22, 2017, 08:38:41 AM
|
Can you please let me know the best way to contact a pool administrator regarding an unpaid balance from well over a year ago? I meant to contact someone during the pool upgrade a while back, but read that all payments were going to be settled. Unfortunately, I never received my payment although my current balance is 0.01259032 BTC, and would appreciate a PM from @ wizkid057 (or any other trusted persons who are authorized to help resolve payment issues). Looking forward to hearing back soon, and appreciate your assistance regarding this matter - Thanks! Not sure where you're getting your number from, but the frozen stats pages do not represent balances as they were at the Eligius Ra->Hu transition. Every single balance due has been paid. All Eligius miners are paid in full with the minor exception for those who are/were active since the Hu transition and have balances below ~0.01 BTC. Aside from that, Eligius has no balances due to miners at present. Zero. Nada. Zip. I've wasted enough time verifying and debunking people's claims about how Eligius owes them something. I'm simply not going to put any additional effort into such claims at this point and will be ignoring them from now on. I already knew for a fact that Eligius has paid all miners due any payment, and I've reconfirmed this at least a dozen times in the past month or so when I've gotten messages from people claiming to be owed something. I was happy to investigate and show they were incorrect, but I'm not going to waste any more effort doing so in the future. I'm actually finding it kind of funny that people are coming out of the woodwork now that bitcoin/USD exchange is pretty high asking about balances from ages ago that were either already paid or not due in the first place. Some of the stories people give when trying to cheat me/Eligius out of a few bucks are pretty incredible, too. Some are pretty amusing. My favorite is one where this guy on IRC needed 0.001 BTC that Eligius "owed" him (already paid, actually, like a year ago) or else he was going to default on his mortgage, be evicted, etc... sitting on a Comcast residential internet connection. Sorry, if you can afford to sit there on the internet and try to scam me out of five bucks, you either can actually afford to pay your bills, or you need to get your priorities straight. Either way, not my problem. *sigh* --- For those wondering what the deal is with Eligius lately, it's pretty much my fault things have not been moving forward. Not that it's anyone's business here, but pretty much as soon as I got time to work on finishing the pool software things started taking a bad turn in several aspects of my life. Most notable is that I'm dealing with what is turning into an overly messy divorce, and that is taking up a great deal of my free time since my ex-wife-to-be seems to have lost her mind and is just making things as difficult as they possibly can be, even in self-defeating ways. I also had a problem with a large contract job that I completed recently, and dealing with that is taking significant time, effort, and funds to battle. Long story short, my customer is making pretty outrageous claims that are clearly and provably false. Nevertheless, going to have to battle them in court over this. (All of this is unrelated to Eligius, just to note). I have been putting time into the pool, mostly for maintenance and updates lately. But after the first couple of days of full-time effort on completing the upgrades I've not had enough of a free moment of work time to really dedicate to it. I am really trying to get things back on track here, and I do appreciate the support folks have shown through what has become a pretty ridiculous delay in upgrades here. Unfortunately, the pool hasn't found a block in over three months, and with the network difficulty where it is I'm not even sure where that would put us even if I were to complete the new interface tomorrow. I've been tossing around some ideas on how to proceed, as I'd prefer Eligius not simply die off if I don't have the time to dedicate to it as I should. One such idea would be to get Luke-Jr back on board, if he is at a point where he would have the time to work on Eligius again, at least until I get out of this rut of mine. (Do wish him well, by the way, as he is likely going to get at least some impact from Irma soon.) An alternative plan would be to hire some trusted developers to complete the work I've started, however I'm probably not in a situation where it would be sensible of me make that significant of a donation to Eligius. Overall, I'm pretty much left with just working hard to get other things out of the way so I can make time to work on this and get it done. A new block 495555 is coming. It looks like the good luck is back to you. |
|
|
|
|
4
|
Bitcoin / Bitcoin Discussion / Re: Do not support bitcoin cash
|
on: November 12, 2017, 06:30:36 AM
|
Do not support bitcoin cash! This is a planned Chinese attack on the network of bitcoins, behind which stands Bitmain, this is a huge pampa! These bastards send fake transactions to the bitcoin network.
SEGWIT2x WAS A ATTACK.
HODL BTC!
Could you help to explain what are fake transactions ? I'm just curious. Best regards. |
|
|
|
|
6
|
Bitcoin / Bitcoin Technical Support / Re: Bad Signature for the bitcoin-0.15.0.1 file
|
on: November 05, 2017, 09:27:25 AM
|
Where did you get those files? I think they are falsified! BE VERY CAREFUL and don't run it. - My name is not "Wladimir J. van der lann" but "Wladimir J. van der Laan" (and my mail is not lannwj@gmail.com either) - There is no "bitcoin-0.15.0.1-osx.dmg.asc". The only signed file in the distribution should be "SHA256SUMS.asc" which contains a list of SHA256 hashes, one for every file. I followed the following steps on the command line to manually check the correctness of the release signing signature on 0.15.0.1: $ wget https://bitcoin.org/bin/bitcoin-core-0.15.0.1/bitcoin-0.15.0.1-osx.dmg
$ wget https://bitcoin.org/bin/bitcoin-core-0.15.0.1/SHA256SUMS.asc
$ gpg < SHA256SUMS.asc | sha256sum -c --ignore-missing
gpg: Signature made Tue 19 Sep 2017 02:16:05 PM CEST
gpg: using RSA key 0x90C8019E36C2E964
gpg: Good signature from "Wladimir J. van der Laan (Bitcoin Core binary release signing key) <laanwj@gmail.com>" [ultimate]
bitcoin-0.15.0.1-osx.dmg: OK
Do not run any dmg or other binary until you get an output like this. Thanks Wladimir. I spelled incorrect name and email when I post this topic.ou I run the command in your reply and 'good signature' shows. Thanks a lot. But I'm still wondering why I failed, since normally I use the following way to check pgp, and it works for electrum and dash wallet. Would you mind to get me hints? Here is what I did to check the signature: 1. Dowload the 'bitcoin-0.15.0.1-osx.dmg' and 'SHA256SUMS.asc'. 2. 'touch bitcoin-0.15.0.1-osx.dmg.asc' file and copy the signature part from 'SHA256SUMS.asc' file. 3. run 'gpg2 --verify bitcoin-0.15.0.1-osx.dmg.asc bitcoin-0.15.0.1-osx.dmg'. |
|
|
|
|
7
|
Bitcoin / Bitcoin Technical Support / Re: Bad Signature for the bitcoin-0.15.0.1 file
|
on: November 05, 2017, 06:23:25 AM
|
Can you try doing the same for Bitcoin Core 0.14.0 and 0.15.0 just in order to see whether this issue is limited to your end or a specific version? I've sent Wladimir a message and don't have OSX myself to test on it.
I tried these versions 0.15.0, 0.14.0,0.13.0, unfortunately there is a good signature found. I also tried downloading the dmg package and verified in window pc, it also failed. Here is a asc file I used(Sorry, I don't find a way to upload file), could you help to have a look at it in case I do something wrong when I copied it from the SHA256SUMs.asc file. Here is the content of the file, and I use notpad++ to create this file: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJZwQqFAAoJEJDIAZ42wulkZQ0P/0hkk9rcBenvHjUAQ1mYeSAW T8mxFosWT24TDR5EO3vgemaNpzmr3W4hs46gIuM7cIqmKHMPcYNdt3PkYUiu7x9A nFf76AjeHjwDNclOas746I8vMMB6pry6qO4hFF2WuLKRlBYjMKJIMjYrkmm4kur6 8GUwvJX7XnfgzJxMCLkaBPLiTYCAwKqPks4hbGdn6OWEefS1EjrLY8U4Ytkt03ZU OceP0LYuFIC0NhaOMzv6EPeH83WAeIQgqmx3xZfewqPCCmj/7g/eK8VLp6ouZ6oL YSSMZerN+n6BNDYVYy42LVwF2wDqTHIyDHQy5MEd038oeVjs9aj4yXv/2snj08FB H39mum1sx7AW2GfjZPO7XvjkyfEJphB0VWGxAh/Ht01pMA6LzoH87m1MU6GZVJ8w jPHNqAmEanhINv00OFmfDBWIaY5EUpiA30T7OaH8Z8fiwpBVOoNMWS5aO02TAQtp OUhSUaY5zorgguhKhZbPjBniP5IcdSLVfIPCYBCYIuoj1hnhtDkJUaajhvSpTbZT SqPIW402aKSr0T/Dob7CwD5F2DRoq550BvbLQyE6PU0niXbX2SCIeGqRanrtT336 MExaKCnEWXOxhbSQd9tV1Se9IGLfR0ac3pFPINwtVXVum20sTN79B3rBS3OlzC3d 1T7DWnSvkb2o6glQ00SL =kBtV -----END PGP SIGNATURE----- |
|
|
|
|
8
|
Bitcoin / Bitcoin Technical Support / Bad Signature for the bitcoin-0.15.0.1 file
|
on: November 04, 2017, 09:59:07 AM
|
Hi, I try to install the latest version of bitcoin-qt. But the GPG signature is not verified, downloading the new version from github and bitcoincore.org is tried. When I try to run the command 'gpg2 --verify bitcoin-0.15.0.1-osx.dmg.asc bitcoin-0.15.0.1-osx.dmg', the following message shows: gpg: Signature made 二 9/19 20:16:05 2017 HKT gpg: using RSA key 90C8019E36C2E964 gpg: BAD signature from "Wladimir J. van der lann (Bitcoin Core binary release signing key) < lannwj@gmail.com" [unkown] Here is my asc file which is from the github. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJZwQqFAAoJEJDIAZ42wulkZQ0P/0hkk9rcBenvHjUAQ1mYeSAW T8mxFosWT24TDR5EO3vgemaNpzmr3W4hs46gIuM7cIqmKHMPcYNdt3PkYUiu7x9A nFf76AjeHjwDNclOas746I8vMMB6pry6qO4hFF2WuLKRlBYjMKJIMjYrkmm4kur6 8GUwvJX7XnfgzJxMCLkaBPLiTYCAwKqPks4hbGdn6OWEefS1EjrLY8U4Ytkt03ZU OceP0LYuFIC0NhaOMzv6EPeH83WAeIQgqmx3xZfewqPCCmj/7g/eK8VLp6ouZ6oL YSSMZerN+n6BNDYVYy42LVwF2wDqTHIyDHQy5MEd038oeVjs9aj4yXv/2snj08FB H39mum1sx7AW2GfjZPO7XvjkyfEJphB0VWGxAh/Ht01pMA6LzoH87m1MU6GZVJ8w jPHNqAmEanhINv00OFmfDBWIaY5EUpiA30T7OaH8Z8fiwpBVOoNMWS5aO02TAQtp OUhSUaY5zorgguhKhZbPjBniP5IcdSLVfIPCYBCYIuoj1hnhtDkJUaajhvSpTbZT SqPIW402aKSr0T/Dob7CwD5F2DRoq550BvbLQyE6PU0niXbX2SCIeGqRanrtT336 MExaKCnEWXOxhbSQd9tV1Se9IGLfR0ac3pFPINwtVXVum20sTN79B3rBS3OlzC3d 1T7DWnSvkb2o6glQ00SL =kBtV -----END PGP SIGNATURE----- I also try the shasum to check the md5 signature, but it works. Could someone give me some info about 'the bad pgp signature' ? |
|
|
|
|
10
|
Bitcoin / Electrum / Re: how the watch-only wallet knows new addresses generated by offline wallet?
|
on: October 29, 2017, 01:42:32 PM
|
Thanks for your answers, I get the basic idea of Electrum. But I still have some questions. OK. But how the online wallet(W2) knows whether the new address is produced by the offline one(W1). I could use the online wallet to send transactions even the address and private key are produced by another wallet, for example, BitCore-Qt wallet. Is there any calculation or algorithm behind the checking?
No, you couldn't use an address and private key from another wallet... Electrum HD wallets DO NOT allow you to import private keys. They can only ever hold the keys/addresses generated from your seed. So, both the online and offline wallet use the same identical Master Public Key. This is the "starting point" for address generation, so both wallets will generate identical lists of addresses... Forever! Let's create a scenario for it. The offline wallet(W1) and watch-only wallet(W2) have the identical addresses in the beginning and they are marked as add1, add2 .... add20 and chadd1,....chaadd5. And I got a payment from Bob(0.4BTC) and Alice(0.6BTC) and all the payments are received by the add1. Now I send 0.3BTC to Jacky which uses the input from Bob. After the transaction, I have 0.7BTC(0.6 in add1 and 0.1 in chaadd1). Q1: The add1 is used, but there is still 0.6BTC in it. Is there a new add21 produced ？ I guess the answer is yes. Q2: In the online wallet(W2), since the add1 is used, a new address is generated and the address is add21, right ? Since the new addresses is produced after the Wallet is created, and the gap limit is 20 by default. If I recover from the seed, I think only 20 addresses are produced by default. If you are correct, is that possible the new address is not in the 'address' list by default ? I have to create new addresses and wish it shows up.
The "gap limit" is simply how many consecutive "empty" addresses need to occur before the wallet stops looking for more used addresses after the wallet is restored. So, if you have used say 14 addresses, and then wipe your computer and restore your wallet... During the restore, it'll find the first 14 addresses have been used... Then it will find 20 empty ones and that triggers the "gap limit" functionally, so it'll stop generating and checking addresses... And you wallet will now have a total of 34 addresses in it. Also, each time you use an address, Electrum will automatically generate a new address out to the gap limit to maintain a pool of unused addresses. You should not need to modify the gap limit unless you're constantly generating an enormous amount of addresses and receiving payments to them "out of order"... More likely in an ecommerce setup as opposed to a cold storage scenario. I have about 80 agencies, everyday I will receive payments. So I want to generate a least 80 address. After I read the warning in the ' http://docs.electrum.org/en/latest/faq.html#how-is-the-wallet-encrypted' page, It looks like it's a better option to change the gap_limit to 80. Any better suggestion? |
|
|
|
|
11
|
Bitcoin / Electrum / Re: how the watch-only wallet knows new addresses generated by offline wallet?
|
on: October 29, 2017, 11:12:20 AM
|
Thanks a lot for your info. In response to your question.
1. A master prblic key knows the addresses the master private key (what you don't see) is going to produce. Both of these come from the seed but the master public key has no control over the bitcoins.
OK. But how the online wallet(W2) knows whether the new address is produced by the offline one(W1). I could use the online wallet to send transactions even the address and private key are produced by another wallet, for example, BitCore-Qt wallet. Is there any calculation or algorithm behind the checking? 2. Yes, you can restore everything from the seed.
Since the new addresses is produced after the Wallet is created, and the gap limit is 20 by default. If I recover from the seed, I think only 20 addresses are produced by default. If you are correct, is that possible the new address is not in the 'address' list by default ? I have to create new addresses and wish it shows up. 3. No change_gap_limit should keep generating your addresses. You'll run out of addresses if you don't do that (as an unreasonable number of change addresses will be used that your wallet don't have if offline and not setting a gap limit).
|
|
|
|
|
12
|
Bitcoin / Electrum / how the watch-only wallet knows new addresses generated by offline wallet?
|
on: October 29, 2017, 10:03:19 AM
|
Now I'm trying to use Electrum to store my BTC with the cold storage way. But there are still some questions which confuse me, could someone give me hints about that ? I searched the forum and haven't found what I want. There are two wallets and one is offline electrum wallet(W1) and the other is a online one(W2) which is generated by the master-pub key from the offline wallet. Both of them have the same addresses. After lots of transactions are done, as I learned from electrum documents, there would be new addresses generated by W1. The questions are: 1. Could W2(watch-only wallet) show the correct balance info for this address ? If Yes, How does W2 know this address is generated by W1? 2. Is it enough to restore all the balances and info from the seed without the wallet backup file after new addresses are generated? If Yes, the only one I need care about is the wallet even after lots of transaction are done, that would be awesome. 3. Does the change_gap_limit have bad effects of the cold storage or wallet restore? Thanks for helping a newbie,  ora.zhang |
|
|
|
|
