[XMR] Monero - A secure, private, untraceable cryptocurrency - page 1315.

smooth

legendary

Activity: 2968

Merit: 1198

Quote from: jwinterm on October 27, 2014, 09:02:59 AM

I think what I might do is just get rid of the network hashrate all together, and report a large pool pie chart with the sum of their hashrates and a small pool pie chart with the sum of their hashrates, and if they don't all sum up to the network hashrate...ohwells. That way everything is self-consistent at least.

It'll be less accurate than coming up with a better estimate of network hashrate because of private pools (or pools you just don't know about) and solo mining but it would be less misleading that the current estimate I think.

smooth

legendary

Activity: 2968

Merit: 1198

Quote from: bitcoinrocks on October 27, 2014, 09:15:51 AM

Are there any serious contenders for decentralized anonymous transactions besides the other Cryptonotes?

Not yet. Zerocash maybe in the future, but we will have to see how that is received once it exists. Also, a Cryptonote-like BTC side chain might exist someday.

bitcoinrocks

legendary

Activity: 1372

Merit: 1000

Are there any serious contenders for decentralized anonymous transactions besides the other Cryptonotes?

jwinterm

legendary

Activity: 3136

Merit: 1116

Quote from: smooth on October 27, 2014, 07:49:37 AM

Quote from: jwinterm on October 27, 2014, 07:26:19 AM

Quote from: smooth on October 27, 2014, 07:12:26 AM

Quote from: jwinterm on October 27, 2014, 07:09:17 AM

I think the easiest and least confusing thing to do is just drop the percentages from the pie slices.

The sizes of the pie slices don't look right either, assuming the numbers are right. But who knows which is correct at this point.

It's definitely related to the poor estimation of network hashrate from the diff (calculated either as diff/60e6 or diff/(60*1024*1024), in this case the latter). The sum of the pools queried comes out to be greater than the calculated network hashrate; here are the two numbers from a test I just ran:

Quote

Network hashrate 17.314610274632773
Sum of pools 19.461517835617066

where network hashrate is calculated from diff and sum of pools is just the sum of all the pools self-reported hashrates. I'm not sure what the best way to fix this is. Just report the total network hashrate as the sum of all reporting pools? Figure out a more accurate way to calculate network hashrate from the diff? I'd be glad to hear any suggestions.

I see.

The self-reported hash rate is probably calculated over a different time window than the network difficulty (likely shorter, since the network difficulty uses 12 hours and that is pretty long for monitoring a pool). You'd likely have to figure out the time window used by the pool software and make your own estimate of the network hash rate based on the sum of block difficulties on the network during that time window.

I think what I might do is just get rid of the network hashrate all together, and report a large pool pie chart with the sum of their hashrates and a small pool pie chart with the sum of their hashrates, and if they don't all sum up to the network hashrate...ohwells. That way everything is self-consistent at least.

primer-

legendary

Activity: 1092

Merit: 1000

Devs release the GUI wallet and blockchain db pruning!

Quicken

sr. member

Activity: 280

Merit: 250

Quote from: silencesilence on October 27, 2014, 07:28:08 AM

everybody wants to buy at a low price .... but this only worsens the situation ..... miners refuse, and this leads to a rather weak network, less confidence and many people will turn to other coins. And when attention be transferred to other coin ..... all is lost

than 3 days I stopped mining because I'm at a loss

I'm not going to buy because of the promise of a bright future for XMR is not live, I'll keep what I've mining
maybe sell them after 2-3 years who knows if I will not ... I will lost electricity for four months for my rig

I am a little excited by these ridiculous monero prices

PS
vicious circle is as follows

difficulty falling and falling the price, because other people get more coins at the lower difficulty and they still sell at low price

You seem a little jittery. Try not to panic. Monero is going through a transition phase from its initial fast emission, and should settle down over the next 6 months.

Remember that the emission rate is constantly dropping, and the monthly increase as a percentage of the current total supply is dropping even faster. To give you an idea, there were over 25k XMR/day being produced early on and that has now dropped to under 20k. In another 6 months it will be down to 15k and a year after that below 10k/day.
Hope that help, Q

bloodyboy

full member

Activity: 199

Merit: 100

why monero fall so hard lately? Huh

alloffmyhate

sr. member

Activity: 280

Merit: 250

It's Never End

Quote from: silencesilence on October 27, 2014, 08:20:27 AM

moneropool.com 12.41 MH/s Huh

it's BOTNET ??

i think yeah, but why this admin pool just silent .__. not see the pool get more than 51% network hash .-.

alloffmyhate

sr. member

Activity: 280

Merit: 250

It's Never End

i hate the price .___.

silencesilence

legendary

Activity: 1120

Merit: 1000

moneropool.com 12.41 MH/s Huh

it's BOTNET ??

smooth

legendary

Activity: 2968

Merit: 1198

Quote from: jwinterm on October 27, 2014, 07:26:19 AM

Quote from: smooth on October 27, 2014, 07:12:26 AM

Quote from: jwinterm on October 27, 2014, 07:09:17 AM

I think the easiest and least confusing thing to do is just drop the percentages from the pie slices.

The sizes of the pie slices don't look right either, assuming the numbers are right. But who knows which is correct at this point.

It's definitely related to the poor estimation of network hashrate from the diff (calculated either as diff/60e6 or diff/(60*1024*1024), in this case the latter). The sum of the pools queried comes out to be greater than the calculated network hashrate; here are the two numbers from a test I just ran:

Quote

Network hashrate 17.314610274632773
Sum of pools 19.461517835617066

where network hashrate is calculated from diff and sum of pools is just the sum of all the pools self-reported hashrates. I'm not sure what the best way to fix this is. Just report the total network hashrate as the sum of all reporting pools? Figure out a more accurate way to calculate network hashrate from the diff? I'd be glad to hear any suggestions.

I see.

The self-reported hash rate is probably calculated over a different time window than the network difficulty (likely shorter, since the network difficulty uses 12 hours and that is pretty long for monitoring a pool). You'd likely have to figure out the time window used by the pool software and make your own estimate of the network hash rate based on the sum of block difficulties on the network during that time window.

silencesilence

legendary

Activity: 1120

Merit: 1000

everybody wants to buy at a low price .... but this only worsens the situation ..... miners refuse, and this leads to a rather weak network, less confidence and many people will turn to other coins. And when attention be transferred to other coin ..... all is lost

than 3 days I stopped mining because I'm at a loss

I'm not going to buy because of the promise of a bright future for XMR is not live, I'll keep what I've mining
maybe sell them after 2-3 years who knows if I will not ... I will lost electricity for four months for my rig

I am a little excited by these ridiculous monero prices

PS
vicious circle is as follows

difficulty falling and falling the price, because other people get more coins at the lower difficulty and they still sell at low price

jwinterm

legendary

Activity: 3136

Merit: 1116

Quote from: smooth on October 27, 2014, 07:12:26 AM

Quote from: jwinterm on October 27, 2014, 07:09:17 AM

I think the easiest and least confusing thing to do is just drop the percentages from the pie slices.

The sizes of the pie slices don't look right either, assuming the numbers are right. But who knows which is correct at this point.

It's definitely related to the poor estimation of network hashrate from the diff (calculated either as diff/60e6 or diff/(60*1024*1024), in this case the latter). The sum of the pools queried comes out to be greater than the calculated network hashrate; here are the two numbers from a test I just ran:

Quote

Network hashrate 17.314610274632773
Sum of pools 19.461517835617066

where network hashrate is calculated from diff and sum of pools is just the sum of all the pools self-reported hashrates. I'm not sure what the best way to fix this is. Just report the total network hashrate as the sum of all reporting pools? Figure out a more accurate way to calculate network hashrate from the diff? I'd be glad to hear any suggestions.

smooth

legendary

Activity: 2968

Merit: 1198

Quote from: jwinterm on October 27, 2014, 07:09:17 AM

I think the easiest and least confusing thing to do is just drop the percentages from the pie slices.

The sizes of the pie slices don't look right either, assuming the numbers are right. But who knows which is correct at this point.

jwinterm

legendary

Activity: 3136

Merit: 1116

Quote from: smooth on October 27, 2014, 06:14:35 AM

WTF?!

How does a simple percentage calculation like that get so messed up?

I think it's a combination of two things. One, the percent is calculated automatically by matplotlib and represents the pools % of hash among the large pools shown on that graph, not in relation to the total network hashrate (Edit: nevermind, this should be total network hashrate, I need some coffee, and will think about it more later...). The other thing is that for some reason the node-js pool software uses 1024 instead of 1000 to convert to kilo/mega hash, byte units instead of SI units? I didn't even know this was a thing.

I think the easiest and least confusing thing to do is just drop the percentages from the pie slices.

Edit2: It seems to be mostly related to a poor estimation of the network hashrate based on the diff. I've been calculation the network hashrate as diff/60e6, and this ends up where the sum of the sum of the pools is greater than this calculated number for network hashrate...

Shrikez

sr. member

Activity: 400

Merit: 263

I am happily mining at http://cryptonotepool.org.uk/. Very stable, never misses a beat and donates 100% of the 1% Fee to the Monero devs.

jwinterm

legendary

Activity: 3136

Merit: 1116

Quote from: sammy007 on October 27, 2014, 06:13:12 AM

You have to fix charts, 10MH is not 46% of 17.

This is a good point Huh

I'll try and look at it today or tomorrow and then bug xnbya and PCFil if/when I figure it out...

I think maybe it has to do with inaccurate network hash calculated from last pool queried reported diff. Anyway, it still gives a relative idea of where you should/should not send your hashes I think.

smooth

legendary

Activity: 2968

Merit: 1198

Quote from: sammy007 on October 27, 2014, 06:13:12 AM

Quote from: jwinterm on October 27, 2014, 06:09:28 AM

You can always check pool hash distribution here ( http://minexmr.com/pools.html ) and here ( http://xmr.poolto.be/#alternative ). Here is a sample of the big pool distribution from the last 30 min (I think this image should stay up-to-date):

Please support one of these pools or another pool who you think is helping to support the network, not just the pool with the easiest to remember/type domain name Wink

You have to fix charts, 10MH is not 46% of 17.

WTF?!

How does a simple percentage calculation like that get so messed up?

sammy007

legendary

Activity: 1904

Merit: 1003

Quote from: jwinterm on October 27, 2014, 06:09:28 AM

You can always check pool hash distribution here ( http://minexmr.com/pools.html ) and here ( http://xmr.poolto.be/#alternative ). Here is a sample of the big pool distribution from the last 30 min (I think this image should stay up-to-date):

Please support one of these pools or another pool who you think is helping to support the network, not just the pool with the easiest to remember/type domain name Wink

You have to fix charts, 10MH is not 46% of 17.

FYI, if you are using nethash reported by daemon it's right value. Open source pools reporting incorrect hashrate using weird division by 1024 instead of 1000 to report Kilo, and Mega units.

jwinterm

legendary

Activity: 3136

Merit: 1116

You can always check pool hash distribution here ( http://minexmr.com/pools.html ) and here ( http://xmr.poolto.be/#alternative ). Here is a sample of the big pool distribution from the last 30 min (I think this image should stay up-to-date):

Please support one of these pools (minexmr.com or xmr.poolto.be) or another pool who you think is helping to support the network, not just the pool with the easiest to remember/type domain name Wink

Topic: [XMR] Monero - A secure, private, untraceable cryptocurrency - page 1315. (Read 4670643 times)