Não consegui dados sobre essa placa em específico, ma usando informações de uma 7870, que me parece ser a melhor da série 7800, vc levaria 188679 dias, em média, pra conseguir um bitcoin. Ou cerca de 517 anos...

Tem a velha lenda do Fermi no projeto manhattan. Quando explodiram a primeira bomba de testes, ele pegou uma folha de papel, picou pequenininho e soltou no ar na hora em que ele viu a explosão. Depois mediu a distancia dele até onde os papeizinhos tinham caido e fez as contas de cabeça da energia liberada pela bomba. A diferença entre o "chute" dele e o valor medido pelos aparelhos caríssimos que tinham desenvolvido pra isso foi menor que a margem de erro dos aparelhos

For the probability of that ocurring, since you mentioned that, someone corrects me if i'm wrong, each share is independent and has an uniform probability of meeting the difficulty set, so we are talking about a binomial distribution with the following parameters:

N = number of produced shares
P = difficulty_of_shares/target_difficulty
K = number of accepted shares

Considering that you only pay for valid shares, and you say they are of difficulty 128, and that my target difficulty was 12000 most of the time, we have:

N = 784869659/128 (since you are paying for shares with difficulty 128)
P = 128/12000
K = 668995673/12000

This number is so small that it i have been unable to calculate it precisely. But i made a simulation with much smaller differences, ranging from 1% to 5% that you can see bellow.

%actual shares	N	K	Probability
99.00%	5226528	55192.13568	0.008762397104
98.00%	5226528	54634.63936	9.52E-07
97.00%	5226528	54077.14304	4.14E-13
96.00%	5226528	53519.64672	0.00E+00
95.00%	5226528	52962.1504	0.00E+00

As you can see, with a difference of only 3% the probability is already so small that you should already be suspicious if it occurred, with 4% it's already not representable by a double precision digit.

Now, we are talking of a 20% difference. Please, do not blame luck. Luck was not involved here!

That is not bad luck, that a poorly designed system that rips off it customers. I paid for something and that was not delivered.

I'm sorry. I wont fall for the bad luck explanation, that's a systematic problem that occurred for the whole of two days, and that was successfully repeated in 4 different orders. I should remind you that extraordinary claims require extraordinary evidence. You should be checking your system, not blaming "luck", or the user for that. If after that you have enough evidence to blame luck, then blame it. For now you are simply avoiding the problem.

Wait, you are saying that i'll get 20% less shares if i use a difficulty compatible with the mining speed? Thats simply unacceptable. And that is not the explanation since i use the same pool with the same setup since december and only yesterday this difference occured, so, thats not the explanation.

I m of course expecting small differences to occur, but 20% is unacceptable.

1- bitcoin. Job switching occurred on average every 5 to 10 minutes (which matches bitcoin block changes).
2- the diff started at 1024 and peaked at 12000. The full list of submited difficulties is bellow:

2.a Accepted shares

difficulty	|	count
1024.0	|	355
4096.0	|	905
1024.0	|	1082
4096.0	|	7128
1024.0	|	2393
12000.0	|	3308
1698.11320755	|	108
12000.0	|	11762
1024.0	|	569
12000.0	|	6490
1024.0	|	204
12000.0	|	13
4285.71428571	|	344
12000.0	|	21796

2.b Rejected shares

difficulty	|	count
4096.0	|	46
12000.0	|	88

If needed, full log can be provided.

Problem with submitted shares not matching what i paid for.

I verified the orders i submitted yesterday and today for the amount of shares actually submitted to the pool and they are at least 20% off. Which means i am paying 20% more for the hashrate i hired.

Has anyone else had similar problems?

Here follows my calculations:

Order	Price BTC/TH/Day	Total BTC	Unspent BTC	Limited TH/s	Expected Shares	Actual Shares (on pool)
Nicehash
#252158	0.0103	0.205702	0	100	401749338.9
#250693	0.0104	0.156702	0	250	303106382.5
Total nicehash					704855721.4	560946737
WestHash
#250694	0.0104	0.303702	0	250	587446328.5
#252159	0.0103	0.156702	0.05561814	100	197423330.5
Total Westhash					784869659	668995673

Has anyone any idea what happened? Can i get my missing shares refunded?
Thanks,
girino.

Hi again,

I am having trouble with the new version. After sometime, it simply disconnects all my workers and does not accept any new connections. Connection to the pool seems to be fine (the log is full of lines saying that a new block was detected). I tried increasing the available memory (-Xmx1024m) but it didn't help.

The logs are available here: http://girino.org/stratum-proxy/stratum-proxy.log.gz

This problem does not happen with an earlier compile i made (the one where i modified the max number of workers), only with the 6.0 build.

Avery 100 minutes it mines 2 minutes for me.

exactly, so while we use masternodes only for the same things as DRK planned them, they are still masternodes. When we come to use them for say, storing data, we can call them database nodes, or something else. For now, what they are is masternodes.

Well, X11 is a good example. You are saying that my miner and wolf0 optimized miner do not mine X11 because we coded them from the ground up? So my miner should be called G11 and his W11?

so if a build a house from the ground up i must not call it house anymore because it was build from the ground up? WTF???

Yes, he did say exactly what i said: it is an implementation from scratch of the same thing.

it IS identical to DRK MasterNodes. Its an identical masternode, coded from scratch, but still the same. And we did borrow it from them, even part of the code. So stop sweeping it under the carpet.


We will look like a scam coin if we do the same thing, with a shared code base, but a different name.

it is included in the windows build or in the source package.

Well, there is the problem. In my opinion, masternodes are NOT a product. They are a feature from the product, which is SpreadCoin. So while you're looking at naming a product, i'm looking at naming a feature. It makes simply no sense for me to rename a feature, while it makes no sense for you to NOT rename a product.

Still, i am unable to see masternodes as a product. The only product i see is "spreadcoin", and everything else are features included in it.

improving on it. 90% of SPR code is still code from bitcoin and darkcoin. It makes no sense to "rewrite" anything.

No, they don't, it's simply the ethical way to treat intellectual property:  attribute it to the people that had the idea in the first place.

If they work in the same way and perform the same tasks, with only a different implementation, then YES, they should name them masternodes. It makes no sense to rename something that performs the same functions just because you don't like, or compete with, the people who created it. It like apple calling smartphones "intelligent phones" just because blackberry where the ones who coined the term "smartphone".

Yes, that solves both the attribution and identity problems.

well, it`s then emerging technology SPR is improving upon. Doesn't really matters if it is established or not. Just that SPR is improving it, so why sweep that under the carpet? Render unto Caesar what belongs to Caesar, and masternodes is a DRK idea, let's attribute it correctly. Lets render unto SPR what is really SPR's (decentralization and instant transactions with SPR implementation)...

So, if you build from source or use the windows binary you should be getting the performance improvements. I never took the time to update the linux binaries.

How fast should it be, wolf0?