Currently using up 99% CPU usage and 75Mb RAM downloading all the blocks. Good job porting it, though let us know when all the blocks are already downloaded & verified. My bet would be on somewhere next year... though probably even never  |
|
|
|
They were probably on a fork or had missed a block. I don't know why else it would happen - there might be a bug, if you spot such a thing let us know.
You mean: let you know, even more than I have been trying to let you know so far? Sorry, no - I think pushing it even more would be just rude and completely unproductive. |
|
|
|
You don't send a full locator every time a new block is mined. Nodes are supposed to send a getdata and only do a getblocks if what they get back is an orphan. Of course I don't. But I am saying that this is what I get from a bunch of nodes running the official client, often after a new block has been mined. I have no idea why they do it, but feel free to explain it to me.. Again: this wastes a hell lot of bandwidth, generating lots of traffic in the network each time a new block is mined.
No. That's not how it works. Are you saying that I am sending all these screwed up "getblocks" to myself, from all the different IPs - or are you saying that I am lying about what I see? Or maybe I'm just crazy and what I see is not real... If you do this after the last checkpoint, you're in for a surprise. Good luck. Thanks, but I don't use any checkpoints, so I don't think I'm going to need any luck here. It's very simple: 1) measure a time difference between now and when you received your last block - divide it by whatever period you like, to get a number (I use minutes) 2) then go back the chain, starting from the head, as many blocks up, as the number from point 1 was 3) pass the hash of the block you have reached in point 2 to "getblocks" - and voila. Using such a simple way, you can recover from basically any fork, as long as it isn't longer than a couple of hundreds blocks. And if a fork would happen o be longer, I will surely have enough time to develop an improvement before it's actually needed |
|
|
|
Actually, if you look at this article it even clearly advises: To create the block locator hashes, keep pushing hashes until you go back to the genesis block. After pushing 10 hashes back, the step backwards doubles every loop Yeah, you are only at block 236k+, so just keep pushing all the hashes, starting from the top, until you reach the genesis block - a brilliant idea  What's wrong with this? It sounds to me like you don't understand the purpose of the locators. Again: this wastes a hell lot of bandwidth, generating lots of traffic in the network each time a new block is mined. I believe that I understand the purpose of the locators very well - and that is why my implementation always sends only one locator... which surely does not point to a genesis block, while I am already at #236475. The only reason to send a locator pointing to a genesis block, in such a case, would be to "recover" from 4+ years long lasting fork... so whoever does that, I think he doesn't understand the purpose of the locators. |
|
|
|
Why to ask 500 blocks back?
It doesn't, as far as I know. It asks for "up 500 blocks starting at hash X", where X is the last known block. I have just checked it again, putting a debug into my getblocks handler. Each time my node receives "getblocks", there are like tens of different locator hashes, followed by a zero-filled stop. This (from what I see) always forces my node to return the maximum of 500 blocks. For instance: getblocks hashes_inside=29 => returned 500 invs / 18003 bytes and these are the locator hashes that were inside (note the genesis hash at the end): 00000000000000b1ffa04c08a1372309ee0f38d99a6ea7ac3d98c6bc76747b4d
00000000000000ebddd1d499c21ffe41a99c2fbefe809aecc1e31b7f5eb2a39d
000000000000003372bd8cb3d9cf78b86a0f64b2c30f8c0ce1f4e46f983d091c
000000000000017c700b2179c55343830a5ff07041d2155654c8ba77ef00677f
00000000000001365066267c0084347b180df7070ed112d2cac316c6565ccd2b
0000000000000013b9efa409b459baf11b4ccb43a60f853bdd8d25fb9b867ec3
00000000000000b8e0d6f2f5437cb2e03e973eac6653b1e2ee7c4bfd822ae1f5
000000000000002031feb915bfb85bfd138a0c9abaa53d3d577e022ca01ddacf
00000000000000a15f169467fbbab6bcf9ce7359fce414215e353b31aa7f17bc
00000000000000b705393b66eb3adf92e69cbbb04753357955b5b8dbaf9d273e
0000000000000127933cc0ad1e6a23a852bd391daa843e457ab40d5c226fed38
000000000000009d39a568e0bf5984fe5f3e9882813b686651b691bdfa07ea39
0000000000000142ad32a203b1627bee8126fa4bcd940b0da3f32bf1b5b07a24
000000000000001aef6e9c1ff8e5833c5f38bb1b660d3a3060169f10ba1a293f
00000000000000f5710fe34e22a0791afe7a817044f9c7da7a139295da995b06
0000000000000168cb9711469ccfa6704398c82fca5dd42bb700f11970946be1
00000000000000d9955f9fe2161524121f0e21f3e2b1a57f97578c98dc31d636
000000000000011f76c57b0f941acf03da10cce12cb989ed5c4b7b6722b89cc4
00000000000000d8c733f7bc4295a8af6e0b95f2bafc901076444505572353c1
000000000000009be2ca7e5f878c2235ac7b2ebf653d77c9d4d57b359e071ca2
000000000000014158e599c40a2e3fef433cf70cc1caedd9099c21028e4d97f7
00000000000000f8cc33dbc8c3c37f88598f33373fbb03b96a1eaf6426da7898
0000000000000008c3e7b684e2aa56bebba3beb267a8d932fb84217becc0406b
0000000000000057c46a1306febe518cdb6c1fc882d856bea07e5927a5f15dc3
0000000000000381683c0b95b17233f8683fb89060d6e4eb0d70f96bd51a539f
0000000000000201892dd6ed76236eb8f42e93bf0dad2606cc5aaa246f253bf1
00000000000003d8e22ddc9a6b3b2226dfe57830d793be012720e74db28bc6be
000000000001dbc957fbe83e9d38aed40c9e083b830c36890d538726b24ae1d0
000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f Actually, if you look at this article it even clearly advises: To create the block locator hashes, keep pushing hashes until you go back to the genesis block. After pushing 10 hashes back, the step backwards doubles every loop Yeah, you are only at block 236k+, so just keep pushing all the hashes, starting from the top, until you reach the genesis block - a brilliant idea |
|
|
|
May I ask if this is a real problem for you today or just theoretical? The node I run uploaded around 2.7 gigabytes yesterday, spread out over the full 24 hours. I certainly wouldn't want to run this off my mobile connection but it's not a bank breaker for a node run in a datacenter. The problem is real - trust me. Not everyone lives in a datacenter, some people just have homes, you know. As for my measurements 2.7 GB per day seems fairly low (its 32KB/s in average), so I tend to disbelieve that you actually run your node from a datacenter. Unless you only have 8 outgoing connections, in which case that number would make more sense to me. But anyway: lets say that it is 2.7GB per day now - while the blocks are still far below the 1MB limit. But they will obviously be growing, like they have in the past. So expect 10 GB /day pretty soon. Still makes no impression? |
|
|
|
So I get that Satoshi's identity isn't known and it MAY be a group of people and whatnot. But if Satoshi revealed himself today, how would we know that it was him? How can he prove that he's the creator of the almighty Bitcoin?
All he needs to do is just spending the coinbase from the first block |
|
|
|
We've definitely looked at LevelDB and seem to alternate between being excited about it and disappointed that the Go ports aren't done enough yet. Yep, I know exactly what you mean And it's even more disappointing when you know that both; Go and LevelDB are products developed by Google. |
|
|
|
you can't just fetch individual transactions from it, as that would require the peer to have full transaction index. Exactly - and not that I did not know that... it just somehow slipped my mind |
|
|
|
But what I wanted to achieve was downloading a block's payload in fragments (from different peers in parallel), using the current protocol; "merkleblock" followed by a bunch of "getdata 1" And for a moment (or rather for the entire morning) I though that it would be possible... I explained in #28 why that is not possible: even with disjunct filters, you'll get transactions matched by both. I was assuming that all I needed would be a list of hashes returned by "merkleblock" - because this command seems to be returning all the transaction hashes for a requested block, without any filtering. BTW, the spec on the wiki is different from the actual format of this message. There is an extra var_length field between "total_transactions" and "hashes", carrying the same value as "total_transactions". |
|
|
|
But if I make a long bloom filter, then it should never match and so I should be only getting "merkleblock" not followed by any "tx"... Haven't given up yet If you don't want any transactions at all, just use getheaders. Yes, this I know, thanks. But what I wanted to achieve was downloading a block's payload in fragments (from different peers in parallel), using the current protocol; "merkleblock" followed by a bunch of "getdata 1" And for a moment (or rather for the entire morning) I though that it would be possible... |
|
|
|
Oh, I'm stupid. I forgot that "tx" only work for a not yet mined transactions, so how did I want to acquire a block's payload with them? Now I have given up |
|
|
|
I see what you mean now. I can trick the node into sending me "merkleblock" messages, but they are always followed by a bunch of "tx" messages, which completely ruins my concept of distributing requests for these "tx" among all the connected peers. But if I make a long bloom filter, then it should never match and so I should be only getting "merkleblock" not followed by any "tx"... Haven't given up yet |
|
|
|
I have been looking at BIT37 and it seems that "merkleblock" is exactly what I need in order to divide a new block's download into small chunks and then distribute the block's download among different peers, using a bunch of "getdata 1" instead of one "getdata 2". The only problem I see is that: If no filter has been set on the connection, a request for filtered blocks is ignored So I guess I will need to setup some dummy filter first, just to be able to receive this nice and useful messages. But... now I wonder: if I setup such a filter, will I still be receiving invs, for freshly mined blocks...? Or what will be other side effects... I will appreciate any advise here - I really want to implement it. Preferably today |
|
|
|
And moreover, it creates a lot of hassle, forcing you to backup your wallet after every payment.
It most certainly does not. indeed, it does not. but how is a simple user supposed to know when there was a new address generated for a change, so he should make a new backup? there is no such indication - so basically, if you don't want to loose any money, you should do a backup after every send. |
|
|
|
Launder coins by sending them through the most illegal bitcoin service about? Great idea.
There is nothing illegal in sending your bitcoins to your SR account and then withdrawing them from it. So unless you are ashamed of using SR, I don't see a problem to get advantage of their laundering system. No, that I would need it |
|
|
|
And the "block propagation" is eating up a hell lot of the poor's bitcoins users bandwidth - it might not be a problem for you, but it is a problem.
If you don't have enough bandwidth to be CPU limited, stop trying to run a node. SPV clients are just fine for any users needs unless you want to run a mining pool or maybe operate a big business. If you really want, go get a VPS server; $20-$100/month should buy a fast enough one, at least for another year or two. so your advise is: don't run a bitcoin node. ? because, you know, I would actually like to run a bitcoin node, just to support this fine network, but the current protocol is wasting my bandwidth - and that is my issue. though, I understand that an unnecessary bandwidth usage is not something that is easy to be noticed, so I am not even surprised that nobody gives a shit about it |
|
|
|
You're trying to solve a non-existant problem: block propagation is not upload bandwidth limited today so why would anyone add such a protocol feature? That's why I'm confused. You're asking for something that just wouldn't speed anything up.
Well man, if that problem is non-existant to you, then I can only envy you the internet connection that you have at home But even having such a great connection - if you want to create a software that would be able to import the entire block chain, from a scratch, within a few minutes - then I would rather suggest you looking into developing a hardware that supports elliptic curve math, because IMO that seems to be the weakest link in this process - not the network protocol. And the "block propagation" is eating up a hell lot of the poor bitcoin users' bandwidth - it might not be a problem for you, but it is a problem. |
|
|
|
No, I don't believe it does actually help anonymity. And moreover, it creates a lot of hassle, forcing you to backup your wallet after every payment. The change address belongs to the same wallet as the money that you have just spent, so a next transaction you make, will likely connect back this "anonymous" change address with some public address from your wallet, anyway. The best and the cheapest way I know to launder coins is just sending them through Silk Road. Though of course, then you end up with a question: how much can a trust a guy who runs Silk Road? |
|
|
|
We've just released the second btcd component, btcjson, the JSON-RPC library.
May I ask, why don't you just release the whole client at once? Do you have it already and testing - or not yet finished, but you think it will be finished soon? Unless it's not 'ask a question' type of topic, in which case: sorry, it will probably pop up my ignore digit we chose not to release all the code at once because it was put together rather quickly. one of the main goals with btcd is to have easy-to-understand code along with full test coverage. having full test coverage runs directly in the face of the "making it work", so we made it work first, and are now polishing the individual pieces and releasing them. i'm not sure if you have checked out the test coverage on btcwire but it exercises every single line of code in the package in the tests. this includes negative testing in order to give all the code a run-through. the btcjson package is similar in quality: 88% of the code has test coverage and that should improve to 100% in the next several days. per my earlier posts in this thread, btcd is up and running against a single local bitcoind node. it can pull the whole blockchain down but you may have noticed that it cannot handle chain forking properly yet. we expect this to be working well and release it soon. full tx verification is under development, a number of experiments are being done to determine how to make it run faster. since these experiments involve changing (sqlite) db schema, it doesn't make sense to release in such a half-baked form, especially when it means users would have to rebuild/restructure their whole db. we expect to have btcd interoperating nicely with bitcoind before June 1st. note that this will not include wallet functionality, we expect that to be ready before July 1st and likely before June 15th. since you're a developer yourself you know how timelines can slip, so be aware these are estimates. That's fair enough - thanks for explaining. I wish you all the best with the project guys, though if you do not have tx verification fully implemented yet, I think your dates might be a bit too optimistic. Also, from my own experience, I think sqlite might not be the best choice, as for a DB backend for bitcoin. I would rather advise you to look into Go ports of LevelDB. Unfortunately none of them is quite finished yet. Myself, I was trying everything; from mysql to each available port of leveldb - but at the end I decided that they all suck and created my own database engine. You're welcome to use it, if you want, though I should warn you that it has about 0% of test coverage, and a great appetite for system memory. You can order it to free the mem, but then it will be much slower when you need the data. And that's why I recently bought 8 more gigs of RAM, just so I would not need to free the mem... at least for the next couple of months |
|
|
|
|
Show Posts
