Um... OP... "self proclaimed"... is actually a BAD thing.


My theory is UNFALSIFIABLE!

So that's:

* ASICminer
* ASICminer
* ASICminer bagholders
* ASICminer

 

(I say all this as an ASICminer bagholder myself, albeit one who hasn't made threats to anyone. And I have to  by now, I'm long since past the    and the )

Not yet.

When there are plenty of Bitcoin-accepting grocers, so I can buy fava beans...
and plenty of online wine merchants, so I can buy a nice Chianti...

THEN...

You need to remember all of the bytearrays are little-endian. Or big-endian, I can never remember which is which. Point is you need to reverse the byte order for each field.

So header_hex starts with "11000000...". The next part will be the byte-reversed previous block hash - so it starts with "b6ae55" and ends with the string of zeroes.
Similarly for all the remaining fields.

ETA I see from your "hash[::-1]" construction that you know about the endianness. Well that applies to each field rather than the entire block header. At least "[::-1]" gives you a very efficient way to do it.

Yeah, me too.

So, I send them as many bitcoins as I wish, and in about a month they'll absolutely definitely guaranteed send me back all the bitcoins and 50% more.

Yeeerrrrrs.

There was a time, two and a bit years ago, when I actually fell for that. BTCJam, they called it. Of course back then bitcoins were worth maybe ten quid each. So the lesson was well worth it really.

Ah, male prison rape. The funny kind.

Well there's a crucial distinction to be made between
a) Sudden, completely unexpected hard forks due to bugs/unexpected behaviour in the code (bitcoin itself, or ancillary stuff such as database management), and
b) Hard forks predicted and planned several months in advance, due to perceived need to improve weaknesses in the protocol or code or both, and implemented by a consensus-of-miners-switchover

The bazillion-btc and broken-db hardforks that happened in 2010 and 2013 are examples of the former. Increasing the blocksize to 20MB, 8MB or whatever is an example of the latter. In the former everyone could see that the 'new' fork had highly undesirable behaviour and so it was straightforward for the devs to tell everyone to roll back - no one thought the 'new' chain was somehow The One True Bitcoin. In the latter, there is a difference of opinion as to the 'brokenness' of each subsequent chain.

(I know the OP probably wasn't 'going there', but with all the angst at the moment, I think it *needs* to be said.)
(In any case I was mostly responding to pereira4's last sentence.)

2112: Now that's a MUCH better response!

Yes, it looks like hardware faults is where it's at. I will try a new hard drive (actually have one lying around) and test the memory.

Re scams: I'm sure you're right about their existence. I don't read that many threads. But their frequency? Surely the ratio of genuine tech problems to mutual-scammer-backscratching must be quite high here? We're not talking about my granny trying to read MS Word documents in Firefox here.

And I may not be that tech savvy, but TeamViewer... come on, dude.  

Knightdk: will do.

Thanks all.

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.

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).

I've also tried removing everything and redownloading the blockchain from scratch...

...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.

What is at work here is an attempt to learn why my bitcoin-qt client appears not to function correctly, and in doing so, learn more about what exactly it is doing under the hood. If I snark a little sometimes it is because I am frustrated. I'm sure you can figure out who in this thread is helping and who is... well, not.

But please *do* tell me more about my "hidden ulterior motive". I just love hearing strangers explaining mine to me. You can also explain how I am "the perfect mark for an enterprising scammer". While you're at it, have another swipe at knightdk for no discernible reason.

I doubt my hardware is broken if absolutely every program on it apart from bitcoin-qt works fine.

My "I know what computers can and can't do" remark was a flippant way of acknowledging that if I see a computer going through an endless loop it is pointless to expect it to change.

I am torturing myself, but no one else, you don't have to read this! Well, maybe I'm torturing knightdk but it seems to be consensual! (And I must repeat I am grateful to knightdk for their help so far)

Thanks for your reply, obviously I've just been spending a bit too much time seething and updating my previous post! I will check out the developer-docs link you gave, and in the meantime delete debug.log, and restart bitcoin-qt, probably I'll point it at grue's node.

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"...

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.

ETA: EEEEEK! I've just looked at debug.log to see what it's doing. So... 70MB of cruft in there. Now some of it is, I understand, perfectly OK. Fr'instance stuff like this:

2015-06-06 21:06:52 UpdateTip: new best=0000000000000103b325ddcc16512a6754e710c387d069a17e217169f293447c  height=233167  log2_work=69.868797  tx=16765534  date=2013-04-26 01:02:19 progress=0.102582  cache=109732

And this:

2015-06-06 21:06:52 Pre-allocating up to position 0xa00000 in rev00056.dat

... though even then I must question why it's storing so damn MUCH of it. From block 226924 to block 246158! I know debug.log is supposed to be 'flushed' at intervals but couldn't we make those intervals a little more... timely?

Anyway I don't mind, but THEN I see this:

2015-06-06 21:38:50 ERROR: CheckBlock() : hashMerkleRoot mismatch
2015-06-06 21:38:50 Misbehaving: 71.93.44.219:8333 (0 -> 100) BAN THRESHOLD EXCEEDED
2015-06-06 21:38:50 ERROR: ConnectTip() : ConnectBlock 000000000000004bbd569ecddf773e8f2d92345fb7027ead5c89221196cf9ec3 failed
2015-06-06 21:38:50 ERROR: CheckBlock() : hashMerkleRoot mismatch
2015-06-06 21:38:50 Misbehaving: 71.93.44.219:8333 (100 -> 200)
2015-06-06 21:38:50 ERROR: ConnectTip() : ConnectBlock 000000000000004bbd569ecddf773e8f2d92345fb7027ead5c89221196cf9ec3 failed
2015-06-06 21:38:50 ERROR: CheckBlock() : hashMerkleRoot mismatch
2015-06-06 21:38:50 Misbehaving: 71.93.44.219:8333 (200 -> 300)
2015-06-06 21:38:50 ERROR: ConnectTip() : ConnectBlock 000000000000004bbd569ecddf773e8f2d92345fb7027ead5c89221196cf9ec3 failed
2015-06-06 21:38:50 ERROR: CheckBlock() : hashMerkleRoot mismatch

... and so on, for the vast bulk of the file, with the timestamp up front increasing by the seconds... for about 40 minutes until I stop it!

Okay... WHY???

1) Why is there a hashMerkleRoot mismatch?
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?
4) Obvious follow-on... is it, in fact, despite what you said, in *fact* redownloading those blocks after all?
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.

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.

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.

Okay I'm at my wit's end here.

Please, if somebody could talk me through this I'd be grateful. Apologies for the vitriol in this post. Please be assured it is directed at the general nature of computers, not at you.

Let's be clear, I'm NOT expecting anybody to get me to a fully synced up chain here. My goals are far, FAR more modest.

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. That's some 16GB of data that I'm really, really hoping bitcoin-qt isn't TOO STUPID TO SEE. No, Mr. Bitcoin, you do NOT need to start downloading the blocks all over again, they are RIGHT FUCKING HERE.
How do I translate that previous sentence into something Mr. Bitcoin can understand?

The problem is I started it again and thought well I'll let it dl them for a bit, I now have blk00000 and 00001.dat that are timestamped AFTER the blk00002-00146.dat.
Surely that can't be a problem? Surely Mr. Bitcoin can't decide he's going to ignore the subsequent block files because of their timestamp? Please tell me the code can't be designed THAT badly?

The advantage over other cryptocurrencies is that it is the first, and as a result its codebase is the most tested and established, it is the most well known and by far the most valuable in terms of fiat exchange price. The importance of the latter is frequently dismissed by people who must somehow not require food, clothing, housing, utilities and so on.

All those advantages could change over time if an altcoin shows clear technical superiority and as a result gains a following and then media attention. But three points make that difficult:
1) Greed. Most altcoin creators and promoters seem to just want to make a quick buck by pumping-and-dumping
2) Innovation. Bitcoin solved some very deep problems compared to national fiat money. An altcoin successor must recognise *genuine* problems with Bitcoin and provide *genuine* solutions. Changing a line in the code to cutt block generation time to 1 minute won't cut it.
3) Adaptability. If the bitcoin community sees a clear improvement has been made with an altcoin, those features can be incorporated into bitcoin. Not easily to be sure - it almost certainly requires a hard-fork and a prior year or two gathering consensus. But it can be done.

I find your argument not entirely convincing, sir. 

You *have* actually read Gavin's proposals, haven't you? You *are* aware that raising the blocksize limit doesn't happen until there's an overwhelming consensus, aren't you?

Nothing at all wrong with any of that, except that it's exactly what we've had for decades with fiat. If you're happy with fiat why use bitcoin at all?

Bitcoin is ABOUT not having to trust any third party. Whilst it is inevitable that certain trust-requiring algorithms/institutions will be built on top of the core blockchain tech, it is important that everyone who wishes to continue using bitcoin in a trustless fashion, can do so.

Hi all, just to keep you updated... I still haven't managed to sync up the blockchain completely. The client does seem to keep crashing out sometimes. Half the time it says 'a fatal internal error occurred' and shuts down nicely, the other half it just quits and I see a core dump.

Removing the last, incomplete blk00xxx.dat at least allows it to restart, but I notice it always insists on reindexing from the beginning, even when I leave all the rev00xxx.dats alone. But at least I don't have to keep redownloading the blockchain-so-far so that's something.

Anyway I seem to be okay up to blk00133.dat, apparently that's up to "2 years and 24 weeks behind" so we shall see. But it's still in the process of reindexing all that.