I just want it to fall naturally until commerce raises it again.
...but with such tiny market cap commerce probably will never come. Currently all bitcoins are less than 17 mil USD; and most of them aren't available on market at all. At this moment I cannot imagine that some real business will come to bitcoin world, unfortunately, because every single order can move a market. For example today's "huge drop" was only 150k$, which is *nothing* for real commerce! I'm talking about some specific business which I'm working on. However, with price declining, I probably need to review my ideas, because this business need much higher market prices to not be price maker itself by its usd->btc->usd conversions. |
|
|
|
Guys, will you be so kind as to fuck off with your thinly veiled, retarded and baseless accusations?
^ this |
|
|
|
The announcement in my LP broadcast indicates the pool owner, so i take note, in this case, only for blocks found by Deepbit, also the counter log each share, i make some tests analizing the logs and the result is the same, the counter works well, show the same log info. Yes i could, and i already set the preferences to UTC a few times, when i take some practice there is no diference, i cant identify all blocks...
Two comments: * No, longpolling broadcasts are not only blocks done by pool, those are all blocks from Bitcoin network. * You don't need to synchronize time or timezone at all. Everything you need is to log blockhash when it come thru LP and count submitted shares between each LP broadcasts. Not sure how you log this, but some miners prints blockhash directly to console; or it's trivial to change console output to print those hashes. So final algorithm should looks like: a) When LP broadcast come, write down blockhash of broadcast b) Start counting every submitted shares for every blockhash (don't forget you're now writing down count of submitted shares for NEXT blockhash, which will be mined in future) c) After few hours, when you'll have enough data, watch pool stats page and follow links to block explorer to see, which blocks wrote down in your logs were mined on this pool. d) Sum together all logged shares between two block which were mined by pool - and you have exact information how many shares you submitted to pool for given round without any need for exact time. Example: 13:00 Block 1234abfb... broadcasted 13:00-13:30 30 shares submitted 13:30 Block 2345bdf... broadcasted 13:30-13:35 5 shares submitted 13:35 Block 3456aaa... broadcasted Then you'll see on pool stats that only blocks 1234abfb and 3456aaa were mined by pool (those hashes are in links to block explorer). So you sum 30+5 shares and now you know that you submitted exactly 35 shares for round of block 3456aaa. Tycho, I'm sorry once again for hijacking the topic, I just wanted to make clear some mistakes probably done by patrixiorey. I hope it's clear now and no furter comment will be necessary :-). |
|
|
|
|
Btw what's dns for your node? telnet blockchain.info 8333 does not work...
|
|
|
|
The site has been up and down for the past few days which messes up the stats. It is advantageous for mining pools to be feel connect so even if they don't accept incoming connections eventually they will connect to me. It doesn't matter if they are balancers or not if deepbit's mining nodes are still behind them, which ip do you think is incorrect?
Oh, if this means that deepbit connect to you from those IPs, then it's everything perfect. I though you just guessed IPs from pinging his site :-). How can you be sure the pool is reporting the correct has rate?
Don't get hashrate from website (because very pool calculates in a slightly different way), but pick blockheaders or blocknums from their stats page. Then you can calculate rough hashrate by yourself. If pool is hiding some blocks on stats page, then it's completely different story. But I don't think it's an issue at least for biggest one. |
|
|
|
|
Oh, damn, I forgot to upload it to new server. Fixed.
|
|
|
|
|
I finally added luckmeter to stats page. one day, seven day and one month average is calculated. Keep in mind that especially one day average is very inaccurate, because is calculated only from few last blocks.
Btw 30day average shows that pool had really crippled luck, we had few 10+ mil rounds and added variance thanks to ddos and pool outage. But last 7 days looks pretty nice :-).
|
|
|
|
Also Deepbit doesn't find every block. So a round may encompass several blocks worth of hashing and those shares are paid by the one block that got solved at the end.
This can be easily verified by calculating shares for every bitcoin block (user is receiving prevhash in LP broadcast), then wait for stats on website, pick their prevhashes from block explorer, match them with own records and then just sum together own shares from blocks mined inside of deepbit rounds. Just my 2 cents, because it's interesting to thinking about how to check this. But personally I think that patrixiorey did some basic mistake and it isn't a problem of deepbit. |
|
|
|
got it! The values are after the histories.
json dictionary is unordered, so I have no control how information is serialized. But as far as you parse it with json decoder, those values will be there forever. |
|
|
|
|
ok, active_workers is back :-)
|
|
|
|
The current code parses it for "active_workers" and "ghash_ps" which are not in the json. Please let me know if this has changed from last time or I'm looking at something else.
ghash_ps is here. active_workers is away for almost half a year. But it's pretty easy to turn it back on this server. If you wait a moment, it will be in json again... |
|
|
|
Looks like Slush pool information has changed and there's only historical information. So I've removed it.
What changed? I only added few extra fields, but everything should be backward compatible. |
|
|
|
|
bulanula: Firstly, there's no obvious reason why it should do anything with price. People who want to cash out will cash out with or without gold coins offer. And I was only asking for possible demand - it does not mean I'll implement it second day, for various reason.
I still don't think that 30% of pool users will really use this payout method, because most of them don't realize how much cost of "single coin every week" will cost them.
|
|
|
|
|
Is phoenix still closing connection after LP broadcast? I see that as pretty annoying, because managing new connections after every LP broadcast are making unnecessary load on server...
|
|
|
|
... and get lucky on Slush pool for example and submit a share right after normalization...
But renormalization is just some internal maintenance, it doesn't affect anything, even variance :-). I think that relation between score renormalization and reward is yet another myth :-). I mean - absolute numbers in score are meaningless. Everything important is YOUR SCORE / POOL SCORE. And they're both renormalized in the same way. Pool renormalization is something similar like 50 / 100 == 5 / 10 => after renormalization, there are lower numbers, but nothing is affected. |
|
|
|
I think this comes from an unconscious focus on the negative. If there is a chance to sometimes earn more than expected and sometimes less, people only see the risk of sometimes earning less.
That's exactly what I see every day - majority of people have very strong aversion to any risk, that's the reason why majority of people are sticked on PPS pools, even when they're losing in long term because of higher fees. But they feel much more comfortable and safe, because they eliminated any possible risk. |
|
|
|
Just in case you didn't see slush (i'm sure you didn't, it's been some busy days)
I'm aware of this, but now I'm finishing another project. So maybe then, after some rest :-). At last, your average hashrate updates very slowly; i think it updates, and then it updates only after another 10 blocks, instead of updating at the end of a block with the older 9 before that.
Am i crazy?
Hashrate is calculated from 10 last blocks, but only twice per day. Originally I designed it for another purpose (for purpose of project which I'm finishing now), so maybe I'll make updates more often, to not confuse users... |
|
|
|
|
Hello,
Sierrachart feed is program running on your local machine, I hope that nobody else than you can start it up again for you :-).
Do you mean that data source for your market does not work? Which one? Are you using websocket for MtGox?
|
|
|
|
|
It's just my feeling or Bitcoin pools stats are completely wrong? Afaik you're detecting pools by IP, which won't work. Many pools don't have opened port 8333, for example. And your observed IPs (e.g. deepbit) are also wrong - those IPs are balancers, not mining backends and they're also subject of changes during attacks etc.
Probably only parsing website stats is a feasible way how to get sane pie chart of hashrate distribution.
|
|
|
|
|
Number of coins is limited, but number of blocks isn't. There simply won't be any block reward from blocks once all coins will be mined. Miners will live from transaction fees then.
|
|
|
|
|
Show Posts
