|
Can't the initial download be handled in a torrent-like way? What we have to do is hardcode data that's usually included in a .torrent file in the client. Instead of downloading the blocks from the clients and manually verifying every transaction, why not hash the blocks and check those hashes against the hashes hardcoded in the client? If they match, there's no need to manually verify every single transaction again. Only blocks created after the last block of which the hash was included in the client have to be checked the regular way. We could even create new ".torrent" like files, only a few kb in size, which include newer blocks. That way, if the client hasn't been updated in a while, we can still easily and quickly catch up with the chain by downloading that small file and opening it with the client. Thoughts/comments?
|
|
|
|
when I need a new BC, I usually create a ram disk of 3 or so gigabyte, and let bitcoind download the blockchain there. This way I get the entire chain in something below an hour, and once it's there, I simply shutdown bitcoind, and move the blockchain out. seems the best way to do it, until the devs here figure that initial blockchain download is a serious reason hindering new people from getting into bitcoin.
Yes, but this proves that it's entirely possible to speed up the process by leaps and bounds. It should automatically be cached to RAM, instead having to do it manually with a RAM-disk. |
|
|
|
|
I was wondering why synchronizing with the blockchain is bottlenecked so badly by I/O requests? There's plenty of free RAM, and the entire blockchain could easily fit in there, yet the client is "only" using 160MB of RAM at the moment, less than 3% average CPU time and some minor network usage spikes well below my maximum throughput with a well connected client (36 active connections at the moment). Disk usage is constantly pegged to 100% usage, and the harddisk activity is easily heard. With a good internet connection, it should be entirely possible to move the bottleneck to the CPU, resulting in much better synchronizing speeds. Are there any plans on improving caching mechanics?
Alternative clients aren't very well known yet, and people wanting to try out Bitcoin could easily be put off by the bad synchronizing speeds. People wanting to give bitcoin a try would in 99% of the cases use the regular client. People wanting to give it a shot out of curiosity won't like having to wait for literally hours before it catches up, leaving them with a relatively unusable computer in the meantime, as the disk activity makes the computer respond really slow compared to having 1 core pegged to 100% CPU usage.
I really think this is an important area to improve the client in. Thoughts/comments?
|
|
|
|
|
No problems for me. 104 is kinda small, but still readable.
|
|
|
|
Ah that makes sense, thanks for the explanation  |
|
|
|
ElectricMucus, your last post is kinda opposite of what you said in another thread: There is something in-between these options, and my bet is that is what's gonna happen, I'm not entirely certain but that's as good a guess as any.
So we will race up again, but with limited potential, though most likely above the classical bull trap.
|
|
|
|
This is the strongest spike since the beginning of the rally from 2.5. You are wrong.
How do you define strongest? We've had bigger spikes in volume, absolute price increase and relative price increase since the beginning of the rally from 2.5. |
|
|
|
|
It's 15BTC for a 6 month premium subscription, correct?
|
|
|
|
Wait...so a 'few hundred' just turned into 2500-3000? For god's sake, man, keep your story straight if you want to operate as a professional liar.
He's quoting 2500-3000 as a possible price for selling the arbitrage bot. |
|
|
|
New feature - recent sales: - range from 1 to 60 minutes since last trade - to change time range use "sales range" slider - bold line will show you where oldest sales end - to see sales in specific time range just drag'n'drop as usual on trades line And little info about MtGox live api status. Today just after big up all connection was gone. Then all back to life after hour. And to this time number of connections is getting lower. Currently 30% peoples got mtgox live connection, all other use my socket "echo" service. I hope this don't drop to 0  Also after big up Mr. Power-of-two was messing today with orderbook (this time ask side). BTCCharts is still refreshing from http api every minute so his effort is quite useless MtGox is still is saying there's no problem. edit: ok, and mtgox live api connection is back for everyone Omg, omg, omg! This is perfect! Thank you so very much for this ! A button to reset the settings to default and this thing's complete IMO |
|
|
|
It is entirely possible to see another dip first. At the same time, it is important to note that we are in a longterm BITBULL market.
[...]
if people decided to go long, there is rally potential. You can also make the counter argument as there are enough BTC in the order book to drive price down. voila .
The forecast has fully materialzed.  He called this Rally in his subscription mail. |
|
|
|
dear OP that cant be implemented and it wont be implemented until the daily volume on the marker will reach millions of USD
What has that got to do with volume? I just want to protect my stops with a limit, and it should be really easy to implement. yes but i(anyone) can exploit that because the market is to damn small Exploit how? The current stop orders are way easier to exploit, since they turn into market orders once your stop price is hit. |
|
|
|
I agree. I tried to use stop orders, but could not. The same happened to me. The thing is that the price spikes and your stop order becomes market order. But before the system is able to process it, the price moves back/forth/whatever, usually to your loss. I blame the spread for this.
Actually, a Limit stop order would not be any good, since when it should be executed, you'd get nothing, since the price probably moved just above your order. This is the way stuff happens with such high spread.
You probably want to place order "buy if prices goes above 5.0, but not for more that 5.1". I would like that too, but then it'd be more like programming a bot.
The last thing you mentioned is exactly what a Stop Limit Order is  You fill in your stop, upon which the order automatically becomes a limit order for the Limit price set, which is separate from the Stop price. |
|
|
|
dear OP that cant be implemented and it wont be implemented until the daily volume on the marker will reach millions of USD
What has that got to do with volume? I just want to protect my stops with a limit, and it should be really easy to implement. |
|
|
|
when is a rally(crash) there are tons of ppl (about 400) on mtgox live atm there are only 203, so no rally for you
Famous last words  |
|
|
|
Hey Zhoutong, Thanks again for your great service! I was wondering if there are any plans to implement Stop Limit Orders? As far as I know, they shouldn't be too hard to implement, and it will prevent stupid base prices when a spike soars far past my trigger point. Thanks! |
|
|
|
basic email for today's was just sent -March 13 update (includes charts: 91, 93) Did not receive that one  Could you check into it for me, please? Thanks ! I just sent it out again hopefully this time it reaches all you guys Nope. Still nuthin.  this is why I hate hushmail Create a gmail account for just this subscription service? Sure, privacy isn't a really high priority for them, but then again, I don't think it matters for this service |
|
|
|
I can confirm. Still nothing |
|
|
|
|
Show Posts
