Knightdk: my surprise at seeing that it still cares about 'misbehaving nodes' is due to the fact that it ISN'T downloading any new blocks at all, it has only been reindexing the ones it already has. THAT behaviour makes perfect sense to me - presumably it would have no way to validate newly downloaded blocks until it has validated, reindexed and built a chainstate for all the existing blocks. So I can't blame it for not downloading new blocks, I don't see why it *should*. But then, *given* that it's not doing that, I cannot see what use there would be in connecting to peers at all.
It is a completely independent process to connect to nodes that begins before the whole blockchain verification at startup. This runs in another thread independent of the state of the rest of the program. However I don't suppose that's all terribly important. The crucial issue is the apparently corrupted block 246159. I'd just delete the last blk00xxx.dat file, but it seems that rather than reindexing from somewhere fairly recent, it always starts reindexing from the very beginning and ignoring all those other files (even when I *don't* delete them - I've tried it that way, too).
Looked at the code. It looks like it is hard coded to start at the beginning whenever it is reindexing other than when it is reindexing while syncing. ...AND removing and reinstalling bitcoin-qt. I think that, notwithstanding how I stuck up for my computer hardware, I may have to suck it up and get a new hard drive and put it on there.
Before you do that, as 2112 said, run some diagnostic checks on your memory and hard drive. There should be an option to do this when your computer first starts up. |
|
|
|
|
Why should we buy this when there are literally thousands of guides on how to hack someone? You can find in multiple places how to use various tools that are all free, open source, and publicly available.
|
|
|
|
1) Why is there a hashMerkleRoot mismatch?
For some reason, this block, block 246159 (according to blockchain.info) is failing validation. Can't really say why. My guess would be that somehow it got corrupted in that file and it is missing some part of the block so the validation fails. This is probably where it gets hung. 2) Why is 71.93.44.219 misbehaving?
3) Why should bitcoin-qt CARE about some node misbehaving when it is allegedly NOT downloading blocks, but simply rebuilding the database on the blocks it has?
Bitcoin Core is still connected to its peers. Each peer receives a banscore based on whether the node thinks it is misbehaving. After the score reaches a certain threshold (default 100), the node should disconncect from the node. It cares whether the node is misbehaving since the misbehaviour involves spam and can eat up your bandwidth. 4) Obvious follow-on... is it, in fact, despite what you said, in *fact* redownloading those blocks after all?
It should still be downloading blocks, just not ones that it already has. The node is constantly receiving and sending data, but it should not be redownloading those blocks, only downloading blocks that it still does not have. 5) After the first 10000 times* of printing this little set of error messages, should not the client somehow grasp that what it is doing is NOT WORKING and, just perhaps, try another node? Or even give up and say "There is something wrong, I'm stopping now."?
*obvious snark - I know what computers can and cannot do. I suppose my snark is really directed at all these coders who must somehow have never seen this behaviour before and never thought to put a little 'break' in that loop.
It should, but I don't know if it actually does (probably not). Your best bet to fix this would be to just let it completely redownload and reindex the entire blockchain. I know that can be frustrating and time consuming, but it should fix the issues. If that doesn't work, try reinstalling Bitcoin Core. knightdk is just working on his required activity for the signature campaign.
At least I'm being useful to someone, unlike most people in sig campaigns. |
|
|
|
Ok Thanks guys, so let's say I use localbitcoins to purchase some coins, could I get them sent to my wallet on coinbase by the seller?
Yes. You would need to have them send the bitcoins to your deposit address on Coinbase. However, that address changes for each deposit, so be careful. Another thing, Coinbase is NOT A WALLET. I would recommend against using it as a wallet, only to buy and sell Bitcoins. I would recommend that you download a wallet such as Bitcoin Core (if you want to be a node), Multibit, or electrum to your computer instead to keep your Bitcoins safe. |
|
|
|
2) I am currently only rewarding the user that solves the riddle first (right now usually 10000 bits per riddle). I therefore have to make the riddles quite hard so they don't get solved too quickly. This is probably putting off some users. I would very much like to reward also other users even when they have not solved it first, e.g. first 10 solvers get some reward as well. -> The problem there is however, how can I prevent a user from just creating 10 accounts and getting all the rewards? (This would be a kind of sybil problem  ) Thank you for any suggestions! You could prevent users from registering from the same IP multiple times. You could also check if they are coming from an IP associated with TOR or a known proxy and prevent those users from registering. |
|
|
|
Since you are using Coinbase, I am assuming you are in the US. If you are in any of these states: AL, AR, CT, FL, GA, ID, KY, ME, MI, MN, MS, NE, NJ, ND, OR, RI, SD, and WY, AZ, CA, DE, IN, KS, MA, MO, MT, NM, NV, PA, SC, TX, UT, and WV; I believe that you should be able to use trucoin ( www.trucoin.com) to buy Bitcoins with your debit card. You could also see if there is a Bitcoin ATM in the area and buy with cash or you could try localbitcoins ( www.localbitcoins.com). There aren't many exchanges that accept Credit or Debit though since it can be charged back. |
|
|
|
I already read that wiki entry and didn't find it too enlightening. But I shall keep looking for the grittier technical details.
Anyway on to the next question in my series, "How to Eventually Reverse Engineer the Complete Bitcoin-Qt Code by Asking About Every Damn Thing that is Bugging Me"...
I suppose if you really want to get technical and if you can read code, you could check out the developer docs here: https://dev.visucore.com/bitcoin/doxygen/. These are useful as you can see paths of which method calls what. Then, if you can read code, you can look at the source code provided on the site and try to find how everything works. There are some explanations as these are developer docs, but not very many. Up until blk00070.dat, it has been rebuilding the database, and timestamping the blockfiles, at a rate of about one blockfile every two or three minutes. BUT, for the last 40 minutes or so, nothing. Why not? The blockfiles up to 00145 are all sitting there, waiting hungrily to be reindexed. What's the holdup? The "Synchronising with the network" progress bar has also halted.
I'll give it another half hour and then close and restart bitcoin-qt.
I'm not sure why this would happen. Try looking in the debug.log and see if it is giving you any error messages. Also, if you hover the mouse over the progress bar, it should say on what block it is on. If you do it again a minute later and the block number hasn't changed, it likely has hung on something, and you should restart it. |
|
|
|
So I have to stop the raspberry if I want to send coins via the windows core. ?
Yes. Because of the lock files, Bitcoin Core does not allow two different instances of the program to use the same data directory simultaneously. You may also experience some issues with the files if you do use the directory. On my computers, if I use the blockchain from my Windows PC from a Linux environment and vice versa, it always requires a reindex of the blockchain. |
|
|
|
You can find it here: http://sourceforge.net/p/bitcoin/mailman/message/34162473/I've also quoted it and bolded the part where he agrees to an 8 MB block size below: On Mon, Jun 1, 2015 at 7:20 AM, Chun Wang <1240902@...> wrote:
> I cannot believe why Gavin (who seems to have difficulty to spell my
> name correctly.) insists on his 20MB proposal regardless the
> community. BIP66 has been introduced for a long time and no one knows
> when the 95% goal can be met. This change to the block max size must
> take one year or more to be adopted. We should increase the limit and
> increase it now. 20MB is simply too big and too risky, sometimes we
> need compromise and push things forward. I agree with any solution
> lower than 10MB in its first two years.
>
>
Thanks, that's useful!
What do other people think? Would starting at a max of 8 or 4 get
consensus? Scaling up a little less than Nielsen's Law of Internet
Bandwidth predicts for the next 20 years? (I think predictability is
REALLY important).
I chose 20 because all of my testing shows it to be safe, and all of my
back-of-the-envelope calculations indicate the costs are reasonable.
If consensus is "8 because more than order-of-magnitude increases are
scary" -- ok.
--
--
Gavin Andresen
|
|
|
|
Okay thanks that makes it somewhat clearer. In that case I shall just let it rescan to its heart's content.
ETA: actually I'll ask while I'm here: what's the difference, if any, between the process you just described, and the process of 'reindexing' that you can force it to do with the '--reindex' option? I ask because I've just started it up again and the status bar at the bottom says "Synchronizing with network..." which is what made me worry it's redownloading blocks.
It should say "reindexing blocks on disk..." when it is reindexing. However, yours doesn't. Perhaps it is because you haven't downloaded to entire blockchain yet. Since it indexes the blocks as it downloads, I think that since you don't have the full blockchain on the disk yet, it will both reindex and download the blocks, and say "Synchronizing with network..." I shall scoot along to the wiki to see if I can get to grips with what all the different files are trying to do... I understand the blk00xxx.dat files themselves, but I don't yet understand the rev00xxx.dat files, the index/000xxx.ldb files (and a .log file in with them too), and the stuff in the chainstate dir. Anyway ta for the pointers.
You can read some more about the data directory on the Bitcoin Wiki here: https://en.bitcoin.it/wiki/Data_directory |
|
|
|
First off: suppose I have deleted EVERYTHING in the .bitcoin folder with the SOLE exception of the blocks/blk00xxx.dat files, of which I have the first 146.
Therein lies the problem. the blk files are just the raw data from the network dumped to the disk. What Bitcoin Core actually uses for everything are database files. These are found in blocks/index which contains data on where to find blocks, and the chainstate directory in the datadir. The chainstate directory is the most important regarding the blockchain. From the Bitcoin Wiki: chainstate subdirectory
[v0.8 and above] A LevelDB database with a compact representation of all currently unspent transaction outputs and some metadata about the transactions they are from. The data here is necessary for validating new incoming blocks and transactions. It can theoretically be rebuilt from the block data (see the -reindex command line option), but this takes a rather long time. Without it, you could still theoretically do validation indeed, but it would mean a full scan through the blocks (7 GB as of may 2013) for every output being spent. By deleting this directory, Bitcoin Core must rescan the entire blockchain from the blk files in order to rebuild these databases. It is not redownloading them either. The different timestamps that you see is because Bitcoin Core is reading through every single blk file and rescanning them to rebuild the database. |
|
|
|
|
How are you going to make something that lasts forever and is agreed on 100%? I can guarantee you that at some point in time, one of the systems supposed to last "forever" will fail. I can also guarantee you that you can't get everyone to agree. Someone will dissent, someone will try to change something to make it better and arguments will ensue. Furthermore you can't possibly address every single issue and find a solution that lasts forever. Another issue will show up that no one ever thought of and solutions thought to work will be broken.
|
|
|
|
|
Not that I know of. It isn't really a problem though.
|
|
|
|
|
So I think what is happening is the NAT (router) is getting in the way. It is port forwarding. The NAT receives the connection from the correct port. But, it forwards all of the data to the node behind it, and the data is coming from a different port. The node still records the IP address as the same since the data is being forwarded, but it does not know what port the data is from, so it uses the port that the NAT is giving the data from. This, I think, is why you are seeing different port numbers from getpeerinfo than what they actually are.
|
|
|
|
Keeping quiet about ownership of Bitcoins will almost guarantee that your neighbors or others will rob you of them
How? If people don't know that you have Bitcoin, how can they rob your Bitcoin? |
|
|
|
|
That's why you always do the trade in daylight in a public place where there are lots of witnesses. The more people around, the less likely this happens.
|
|
|
|
|
Find a bitcoin address that was posted a long time ago, at least 3 months, and use it to sign a message. In Bitcoin Core: go to File > sign message. Type a message into to big text box. Find and select the address you posted in your wallet by clicking the little book icon and selecting the address. It should show up in the text bar next to the button. Click sign message. Then post the Bitcoin address, the message, the signature and a link to the post here so that people can verify that you own the account.
|
|
|
|
In China, exchanges typically also own mining farms and wallet services, or at least have very close relationship with miners
True, so that means that both the mining and exchange operations will do the same thing. Voting is not a solution, bitcoin is invented just to avoid voting of monetary policy. To reach universal consensus is the only way, why could not Gavin take the 4MB approach and make the change gradually? I think everyone could make some compromise and reach a universal consensus. This is more like diplomatic negotiations between countries, no vote is possible
There actually is a vote, based on the number of a client run. If the super-majority (>90%) run a node that supports the new protocol, then that means a super-majority voted "yes" for increased block size. Those running older versions are voting "no" for the change. Gavin suggested the 20 MB because he thought it was a safe enough size for a long time. However, he is willing to compromise. Looking at the emails in the Bitcoin-dev mailing list, it looks like Gavin is willing to have the block size increase to 4 MB or 8 MB. More people would like this smaller jump than the big one to 20 MB. |
|
|
|
|
Show Posts
