|
oh, and i think you'd find it far more likely that it's due to the blockchain being unwieldy for many ppl's machines (i think these days a lot of people dont even have desktops. imagine that)
re: use wallet service.
|
|
|
|
From the paper:
"Users: Difficult to estimate, but probably over 500,000 at this point."
How was it possible to assess this? Number of IPs? Number of addresses? Number of transactions?
Blatant guessing, based on: number of claimed mtgox users, number of peer nodes on network, number of forum users, previous data posts around here, ... Not a reliable number at all. Just trying to find a number that we could say "probably over X" many graphs around.. but when it comes to regular users in the last year only about 20k of people online daily..  using such things as user numbers / of mtgox and bitcoinchat is not a good way to assess the population. Due to scammers making alias's, 'white knight' whistle blowers not wanting their original persona posting threads, many other reasons including forgetting passwords when using temporary emails to sign up.. the user account number compared to actual people would not be the same. the chart above came from http://bitcoinstatus.rowit.co.uk/which has numerous charts to look at which should aid estimation of the population of the crypto community it also shows the downward curve of user numbers in the last year. which might explain the slowing down of confirmation speeds, as their aint as many people to confirm. guess bitcoinia and other items in the last year did scare people away well, first off, your chart shows a bottoming out in early july and growth since then. the level it shows right now is equivalent to mid-may (*just from a fast lookover, based mostly on 'other' and 'united states' nodes) second off, slowing down of confirmation speeds would be related to the # of transactions, # of people not including transaction fees, # of blocks being solved, # of transactions pools are including in blocks. the # of connectable IP addresses has a negligible effect. the only time it may factor in is if you're on a terribly slow connection which may cause your transaction to propagate a second or two slower than it would have with 15000 nodes, and in those one or two seconds, a block was solved (which also would have happened to have included your transaction) |
|
|
|
|
09/18/12 12:41:03 accepted connection 82.130.xx.xx:51434
09/18/12 12:41:03 send version message: version 60002, blocks=199384, us=5.9.xx.xx:8333, them=82.130.xx.xx:51434, peer=82.130.xx.xx:51434
09/18/12 12:41:03 receive version message: version 60001, blocks=0, us=5.9.xx.xx:8333, them=82.130.xx.xx:51196, peer=82.130.xx.xx:51434
09/18/12 12:54:45 accepted connection 82.130.xx.xx:57620
09/18/12 12:54:45 send version message: version 60002, blocks=199384, us=5.9.xx.xx:8333, them=82.130.xx.xx:57620, peer=82.130.xx.xx:57620
09/18/12 12:54:45 receive version message: version 60001, blocks=0, us=5.9.xx.xx:8333, them=82.130.xx.xx:39389, peer=82.130.xx.xx:57620
09/18/12 12:58:35 accepted connection 82.130.xx.xx:59080
09/18/12 12:58:35 send version message: version 60002, blocks=199385, us=5.9.xx.xx:8333, them=82.130.xx.xx:59080, peer=82.130.xx.xx:59080
09/18/12 12:58:35 receive version message: version 60001, blocks=0, us=5.9.xx.xx:8333, them=82.130.xx.xx:58187, peer=82.130.xx.xx:59080
09/18/12 16:29:38 disconnecting node 82.130.xx.xx:51434
09/18/12 16:29:38 disconnecting node 82.130.xx.xx:57620
09/18/12 16:29:38 disconnecting node 82.130.xx.xx:59080
I used tcpkill to drop the connections.
The log:
09/18/12 12:41:03 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 12:41:03 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 12:46:03 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 12:46:03 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 12:51:03 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 12:51:03 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 12:54:45 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 12:54:45 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 12:56:04 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 12:56:04 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 12:58:35 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 12:58:35 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 12:59:45 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 12:59:45 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 13:01:04 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 13:01:04 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 13:03:35 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 13:03:35 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 13:04:45 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 13:04:45 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 13:06:04 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 13:06:04 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 13:08:35 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 13:08:35 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 13:09:45 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 13:09:45 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 13:11:04 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 13:11:04 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 13:13:35 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 13:13:35 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 13:14:45 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 13:14:45 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 13:16:04 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 13:16:04 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 13:18:35 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 13:18:35 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 13:19:45 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 13:19:45 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 13:21:04 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 13:21:04 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 13:23:35 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 13:23:35 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 13:24:45 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 13:24:45 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 13:26:04 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 13:26:04 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 13:28:35 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 13:28:35 ProcessMessage(ping, 0 bytes) FAILED
<snip>
09/18/12 16:16:04 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 16:16:04 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 16:18:35 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 16:18:35 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 16:19:45 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 16:19:45 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 16:21:04 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 16:21:04 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 16:23:35 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 16:23:35 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 16:24:45 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 16:24:45 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 16:26:04 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 16:26:04 ProcessMessage(ping, 0 bytes) FAILED
09/18/12 16:28:35 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
09/18/12 16:28:35 ProcessMessage(ping, 0 bytes) FAILED
(they have stopped since the tcpkill)
Any particular reason for something like that?
|
|
|
|
I suspect you don't need to suspend; just unplug the network cord for the same amount of time.
When I use a single peer, disconnect cable for a few hours and reconnect it, it says I have the 1 peer but no blocks are downloaded until I restart bitcoin-qt. I doubt this is new in 0.7.
i don't understand this, why would you disconnect your internet connection? why not just restart the bitcoin client? the blockchain will download faster if you connect to a single peer using maxconnections=1, as long as you connect to the right peer (with connect=), you dont have to set maxconnections=1 if you dont allow incoming connections. but if it's just some random peer, then, yes, i would say there's a 95% chance that you will be screwed |
|
|
|
Does it make sense to write in the Bitcoind addnode with some of the superblock / Hubnodes of block chain?
These nodes have connectet> 1000 nodes, so if p2pool find a block, he wants distributet faster and the chance to orphaned is lower?
It can be good IMO, but where find those addresses? Hub Nodes - A list of the most well connected bitcoin super nodes. please don't call it "super nodes" like a Skype super node because this nodes are ordinary nodes with bitcoind running and the only difference might be that they are well connected and have a large uptime.  Super Nodes A participant in a p2p network which connects to as many other nodes as possible. they aren't ordinary nodes.. it's highly likely that they have modified the source code to allow 500+ outgoing connections |
|
|
|
I downloaded a new client Friday, it went through about 75% of the blockchain download at a decent rate.
Then it slowed down with about 20,000 blocks remaining, then eventually froze.
I restarted the client and it would go again then slow down again to a halt.
I am now at about 9,500 after restarting it off and on over the weekend and it is at the point of giving me one er second or so.
I am on a Win7 laptop 4GB Ram, quad 2.5GHZ with plenty hard drive space.
Can I just download the chain all at once, then run it through?
I am not showing anything out of the ordinary in the task manager performance.
it should be faster than that run it with addnode=<good node> maxconnections=1 until you get whole block chain downloaded |
|
|
|
|
actually, nm, it could be a memory error too
that's just FFFFFFFF
|
|
|
|
similar thing here when mining at slush's pool. 5 blocks found 64btc paid to me.  i've got 2 blocks on EMC w/ 140 paid, 13 on MaxBTC w/ 310 paid, 4 on p2pool w/ ~100-150 paid, 1 on bitcoinpool w/ 15 paid or so (and another 10-20 bitcoins from random pools.. (with no blocks i think)) |
|
|
|
I built v0.7.0rc3 from git, and have noticed on several occasions that it's very bad at catching up with the blockchain if I suspend the laptop for a few hours then resume it.
I suspended the laptop with the blockchain up to date last night. Then today when I resumed it, the block download seems stuck at "55 blocks remaining" even though I apparently have "14 active connections to the bitcoin network".
I don't know if those are really "active" connections, or if it fact they are 14 connections which were active at the time of suspension, and which have really died out in the mean time.
I get the impression that v0.6.x was better at handling suspend/resume, but that may not actually be the case. I'm suspending and resuming more recently than I used to, so perhaps I'm seeing a long-standing issue that's nothing to do with the 0.7.0 changes.
I used to have this happen on occasion... would just reload the client, get new connections, and it'd be fine. I suspect blocks are being requested from someone that is throttling their upstream or has none to begin with.. now my windows-qt shortcut just has a few addnodes, it always gets the blocks from those (presumably since they connect before any other nodes) ed: oh, i believe the default send buffer was also lowered |
|
|
|
Well it worked! Average hashrate in last 10 rounds: 2789 Mhash/s Finally up to full capacity! (Estimated at 2800Mhash/s - 400mhz per 5870) If I sell them on Ebay one day would it be ok to mention they were run outdoors?  Make sure they're REALLY clean and free of all leaves/bugs. hmm, maybe motherboard LEDs would be a good thing then? all the dead bugs would be in one big pile |
|
|
|
coins received, awaiting confirmation  The package has been delivered. Waiting on bitcoins to be transferred this is a strange deal, considering there seems to be an extra 5830, and i offered $250 for the 5830/5830/5850 I believe? so then add the 5830, around $325. 6870 + 950W PSU for $165 more (well, and maybe $5 of RAM)? why not msg me first? i would have had no issue with ebaying the 6870 and PSU, you could have kept the RAM. since 6870 by itself is worth $125-$140, i would have offered much more |
|
|
|
I'm looking to trade for 2 BFL singles.
in person in DFW? i wonder if someone in the dallas area even has 2 BFL *singles, but then you'd have to find someone willing to trade them for gpu's what is the cash equivalent of 2 BFL *singles? |
|
|
|
Drop in price bump.
hmmm, would reference heatsink + fan etc work on that? is the gpu in the same place? it looks like it would to me? i might be interested in just the card itself, then you could sell the waterblock on ebay or something. do you or maybe someone else knows for sure? |
|
|
|
|
OK, only two priv msgs so far. Anyone else? I'm thinking at this point it'd be easier just to have it immediately decomissioned
|
|
|
|
Eh?
I'm suggesting a change to bitcoind that would speed things up.
My comment included the fact that most bitcoind's have most of the transactions that they receive each time they receive a new block.
The problem is that when a node receives a new block, it gets a copy of every transaction in the block and verifies every transaction in the block.
It, however, already has most if not all but one of the transactions in the block, and I'm not sure why the transactions in the memory pool are not verified enough to match the verification applied to the txns in the block.
The network latency of sending around a block is the exact reason I've suggested this before and again here.
none of that changes the fact that it's going to be at an inherent disadvantage vs most pools, that'll have 100's of open connections. http://blockchain.info/inv/00000000000004522cf2395cfdb85d268a393b781cba2217ce25a29e2f3921c909/14/12 18:35:47 ThreadRPCServer method=submitblock 09/14/12 18:35:48 SetBestChain: new best=00000000000004522cf2 height=198785 work=479119430009406564588 date=09/14/12 18:35:28 09/14/12 18:35:48 ProcessBlock: ACCEPTED my US IP then received and processed it at 18:35:48, my kimsufi received it at 18:35:49, but didnt finish processing it until 18:35:53 my p2pool server reports http://nogleg.com:9332/static/share.html#00000000000004522cf2395cfdb85d268a393b781cba2217ce25a29e2f3921c9this was solved by someone in russia. it was relayed to me by a node in slovenia. i have 60ms ping time to this russian domain, 40ms to slovenia. hence 'addnode' (ed: i never messed with addnodes myself until i started using p2pool, pretty easy to recognize that things would propagate slower when most ppl are running bitcoind with probably 8 connections, seems to me like faster processing time would benefit the person with 500 open connections even moreso.. btcguild has weird propagation, seems slow to me. i dont think that would have had a chance vs a slush, deepbit, emc, etc block) |
|
|
|
THANKS to all of you that convoluted the explanations with BS
I think everyone just assumed that since you have 155 posts and are not posting in the "newbie" DeepBit thread that they could post explanations that required a bit more knowledge than you have. No one was trying to make you look bad. but he mines on deepbit |
|
|
|
Would anyone possibly be interested? Saves the ~41.5 € (49 € with VAT) setup fee. It isn't ready to transfer yet (I still have some stuff to move), just trying to sound out how much of that setup fee I can recoup. Trying to determine which upgrade path to use... whether or not I want to pay a ~58€ relocate fee or just upgrade without parallel operation (I'd rather not, but..).. http://www.hetzner.de/hosting/produkte_rootserver/ex4Located in DC 16, hard drives have 2185 power on hours (they were both brand new when I first got it). NIC 1 GBit OnBoard with 100 Mbps connection when using a usenet provider, e.g. giganews, I can easily download at 50MB/s +, so...... it sure isn't throttled at 100Mbps |
|
|
|
version message: version 60001, blocks=198574
Are you sure it hasn't caught up? Block 198,574 would have been about current for the time you posted. (it's always running in the background) Just checking... rule #1 with electronics and software says that when stuck, reboot. Have you tried closing the program and re-launching it? It is a shot in the dark, but who knows. Yes, but it's telling me the last block downloaded was 195775, about 18 days ago. It's connected to the network, but somehow it got stuck there and isn't downloading any more blocks. I've restarted, I've reinstalled, I've uninstalled THEN reinstalled... nothing seems to work. Just hoping 0.7.0 will come out soon, so I can try installing it and see if that jumpstarts it. EDIT: OK, so I renamed all the blkindex files, started up again and now it's downloading the chain... it'll take a few hours, but we'll see what happens when it gets to 195775. start it from command line with -maxconnections=1 -connect=5.9.24.81 then after the chain finishes downloading restart it as normal. i've always found it much faster connecting to just 1 node when downloading the blockchain (otherwise you get spammed with all kinds of junk) just not something you'd want to make as default in the client, for obvious reasons (re: server offering up bs blockchain etc) |
|
|
|
|
make sure to turn off your motherboard LEDs
unless you dont mind cleaning a pile of dead insects every few days
i keep all my systems in a single room, with some, err, foam type stuff to seal it off from the rest of the house (AC vent sealed off also).
the window in that room opens from the bottom and top though, so some industrial fan blows air in from bottom and exhausts out the top. not the best ventilation because a lot of the air just, well, traverses a few feet from top to bottom. ofc it would be better if there was a 2nd window and it was on the opposite side. still, I don't think the ambient temp in that room climbs more than 10o above outside. dropping the voltage on cards makes keeping 'em cool pretty easy. actually, my main problem came from PSU's. had a couple of those die (replaced with seasonics)
|
|
|
|
My log scale definition, pls feel free to criticize / correct / comment
Big= >=100GH/s
Medium= >=10GH/s && <Big
Small= >=1GH/s && <Medium
Tiny= >=1MH/s &&<Small
dunno, not many with 10GH+. the problem is there needs to be another category above medium. someone mining at 9gh/s isn't "small". that'd put them in the top 20 miners at a pool doing 2thash atm. more like tiny <1ghash small <3ghash medium <10ghash big <50ghash squandering enough electricity to light up small hamlet >50ghash |
|
|
|
|
Show Posts
