Eligius: 0% Fee BTC, 105% PPS NMC, No registration, CPPSRB

[bspurloc]

When exactly does an inactive get paid? I mean a few seconds is now over a week which is past the inactive 6 days aka been inactive for 12+ days.
no need for replies about oh its only a dollar, why dont u donate it etc etc, if it says it is going to pay it out then pay it out.

 The formula to determine inactive works enough to know it should be entering the queue but maybe the code to actually enter it was never added. I could just point a miner at it to hit the threshold but why when it says inactive will get paid after 6 days. It has been 12+.

Estimated Position in Payout Queue
Approximately 0.00038946 BTC remaining to enter payout queue. If you remain inactive, and the pool does not pay towards any of your shelved shares, then you will be eligible for a payout of your balance (which is less than the automatic payout threshold of 0.01048576 BTC) in a manual payout no sooner than a few seconds from now.

Note: Your minimum payout was customized to 0.01048576 BTC under 'My Eligius'.

[1714607391]

1714607391

[1714607391]

1714607391

[1714607391]

1714607391

[1714607391]

1714607391

[1714607391]

1714607391

[1714607391]

1714607391

[Lucko]

Hi wizkid057

How is distributing that 200 BTC to miners going?

https://bitcointalk.org/index.php?topic=441465.msg7282674#msg7282674

My original plan was to return the coins we have held in offline storage to the rightful owners— the miners who were submitting real work and were affected by the withholding attack— by paying towards shelved shares accrued during that time period (doing this is non-trivial due to security measures in place). This is still my intention...

Or is this changed. Might have missed it. My problem is that my address at that time was compromised. And looking all the time if something is there is a bit stressful... So knowing when this will happen would help... Changing address that I had would also help...

[ProfMac]

Hi wizkid057

How is distributing that 200 BTC to miners going?

https://bitcointalk.org/index.php?topic=441465.msg7282674#msg7282674

My original plan was to return the coins we have held in offline storage to the rightful owners— the miners who were submitting real work and were affected by the withholding attack— by paying towards shelved shares accrued during that time period (doing this is non-trivial due to security measures in place). This is still my intention...

Or is this changed. Might have missed it. My problem is that my address at that time was compromised. And looking all the time if something is there is a bit stressful... So knowing when this will happen would help... Changing address that I had would also help...

I think you and wizkid could do the following to recover your funds without doing too much damage to the security measures in place.

1.  wizkid creates a transaction but does not submit it.  He sends you the details so that you can make another transaction that spends your funds. 
2.  you create your transaction and submit it to the network, and notify wizkid.
3.  wizkid, or either of you then submit wizkid's transaction to the network.
4.  your funds can't be hijacked by the compromiser because of double spend protections.
5.  of course, you would also pay wizkid a tip in your transaction.
6.  I don't know if eligius will, or can, mine a transaction that is not submitted to the rest of the network, but this would give additional protection.

[amaclin]

2. you create your transaction and submit it to the network, and notify wizkid.

a) It is difficult (but possible) to send orphan transaction but...
b) ... Bitcoin nodes do not relay orphan transactions.

4.  your funds can't be hijacked by the compromiser because of double spend protections.

wrong

[ProfMac]

4.  your funds can't be hijacked by the compromiser because of double spend protections.
wrong

Please give a hijack scenario when the two legitimate transactions are submitted together.

[amaclin]

Please give a hijack scenario when the two legitimate transactions are submitted together.

You can do it youself.
Create a transaction which sends small amount ( e.g. 0.0005 ) to 1JwSSubhmg6iPtRjtyqhUYYH7bZg3Lfy1T
( this is "correct horse battery staple" well known compromised key address )

And try to get back your funds, sending tx1 (to) and tx2 (from) in different order, to different nodes, etc...
I am sure you will fail.
Hijacker (one of many) will be faster.

[ProfMac]

Please give a hijack scenario when the two legitimate transactions are submitted together.

You can do it youself.
Create a transaction which sends small amount ( e.g. 0.0005 ) to 1JwSSubhmg6iPtRjtyqhUYYH7bZg3Lfy1T
( this is "correct horse battery staple" well known compromised key address )

And try to get back your funds, sending tx1 (to) and tx2 (from) in different order, to different nodes, etc...
I am sure you will fail.
Hijacker (one of many) will be faster.

Thanks,

That is public, very similar to the problem at hand, and can be tested.

[bspurloc]

When exactly does an inactive get paid? I mean a few seconds is now over a week which is past the inactive 6 days aka been inactive for 12+ days.
no need for replies about oh its only a dollar, why dont u donate it etc etc, if it says it is going to pay it out then pay it out.

 The formula to determine inactive works enough to know it should be entering the queue but maybe the code to actually enter it was never added. I could just point a miner at it to hit the threshold but why when it says inactive will get paid after 6 days. It has been 12+.

Estimated Position in Payout Queue
Approximately 0.00038946 BTC remaining to enter payout queue. If you remain inactive, and the pool does not pay towards any of your shelved shares, then you will be eligible for a payout of your balance (which is less than the automatic payout threshold of 0.01048576 BTC) in a manual payout no sooner than a few seconds from now.

Note: Your minimum payout was customized to 0.01048576 BTC under 'My Eligius'.

and 6 more days later....
I guess the answer is, Inactive addresses never get paid out it is just consistently lying about it. no no a few second...

Estimated Position in Payout Queue
Approximately 0.00038946 BTC remaining to enter payout queue. If you remain inactive, and the pool does not pay towards any of your shelved shares, then you will be eligible for a payout of your balance (which is less than the automatic payout threshold of 0.01048576 BTC) in a manual payout no sooner than a few seconds from now.

[baddw]

When exactly does an inactive get paid? I mean a few seconds is now over a week which is past the inactive 6 days aka been inactive for 12+ days.
no need for replies about oh its only a dollar, why dont u donate it etc etc, if it says it is going to pay it out then pay it out.

 The formula to determine inactive works enough to know it should be entering the queue but maybe the code to actually enter it was never added. I could just point a miner at it to hit the threshold but why when it says inactive will get paid after 6 days. It has been 12+.

Estimated Position in Payout Queue
Approximately 0.00038946 BTC remaining to enter payout queue. If you remain inactive, and the pool does not pay towards any of your shelved shares, then you will be eligible for a payout of your balance (which is less than the automatic payout threshold of 0.01048576 BTC) in a manual payout no sooner than a few seconds from now.

Note: Your minimum payout was customized to 0.01048576 BTC under 'My Eligius'.

and 6 more days later....
I guess the answer is, Inactive addresses never get paid out it is just consistently lying about it. no no a few second...

Estimated Position in Payout Queue
Approximately 0.00038946 BTC remaining to enter payout queue. If you remain inactive, and the pool does not pay towards any of your shelved shares, then you will be eligible for a payout of your balance (which is less than the automatic payout threshold of 0.01048576 BTC) in a manual payout no sooner than a few seconds from now.

Do you understand the meaning of "no sooner than"?  That means that the soonest it could possibly happen is a few seconds from now.  It could happen later.  It will happen whenever wizkid does a manual payout.

[techman05]

Hi , just wondering if the first few posts being solved is why its showing 21G as next difficulty is happening because of cleaning house. It sounds to good to be true but I'd love some easy bitcoin for a few days. EclipseMC is on day 3 of a coin and I can't get payed anywhere till that difficulty balances out.

[mdude77]

Hi , just wondering if the first few posts being solved is why its showing 21G as next difficulty is happening because of cleaning house. It sounds to good to be true but I'd love some easy bitcoin for a few days. EclipseMC is on day 3 of a coin and I can't get payed anywhere till that difficulty balances out.

If you're looking at an app, such as my Pool Monitor app, that calculates next difficulty based on the number of blocks solved since the last diff change, that explains it all.  Difficulty did just switch, and I think it decreased almost 1%.

The estimated next difficulty in my app projects what the next change will be IF the blocks/time solved since last diff change remain constant.  Right after a difficulty change, that number is a bit erratic due to luck.  It'll swing wildly all over the place, and then after about 6 hours, I'd guess, it'll get more realistic.  And the closer it gets to the next change, the more accurate it'll be.

Note this is contrary to what most other difficulty prediction sites (that I've seen) at least do.  They make assumptions based on prior increases, SWAGs, and crystal balls, none of which are entirely accurate.

Lastly, I think it's unlikely that it'll drop 35%.  With the SP20 sales for black Friday weekend, I'd imagine difficulty will increase at least a little.  But only time will tell, as there really is no accurate way to predict immediately after a difficulty change what the next change will be.

M

[baddw]

Hi , just wondering if the first few posts being solved is why its showing 21G as next difficulty is happening because of cleaning house. It sounds to good to be true but I'd love some easy bitcoin for a few days. EclipseMC is on day 3 of a coin and I can't get payed anywhere till that difficulty balances out.

If you're looking at an app, such as my Pool Monitor app, that calculates next difficulty based on the number of blocks solved since the last diff change, that explains it all.  Difficulty did just switch, and I think it decreased almost 1%.

The estimated next difficulty in my app projects what the next change will be IF the blocks/time solved since last diff change remain constant.  Right after a difficulty change, that number is a bit erratic due to luck.  It'll swing wildly all over the place, and then after about 6 hours, I'd guess, it'll get more realistic.  And the closer it gets to the next change, the more accurate it'll be.

Note this is contrary to what most other difficulty prediction sites (that I've seen) at least do.  They make assumptions based on prior increases, SWAGs, and crystal balls, none of which are entirely accurate.

Lastly, I think it's unlikely that it'll drop 35%.  With the SP20 sales for black Friday weekend, I'd imagine difficulty will increase at least a little.  But only time will tell, as there really is no accurate way to predict immediately after a difficulty change what the next change will be.

M

I find the BitcoinWisdom predictor to be fairly reliable.  It doesn't swing too much.  I don't know what algorithm they use, but it's resistant to at least some of the flaws that I've seen with others.  I think it must use some kind of upward bias where it more heavily weights the most recently seen high-point for hashrate.  This works on an intuitive level because while new mining hardware might be turned on for testing then taken offline while it's shipped out to customers, after a week or two it will tend to turn on and stay on permanently.  So if the network hits a hashrate peak and then drops down, it's a safe bet that it will soon hit that level again.

https://bitcoinwisdom.com/bitcoin/difficulty

[mdude77]

I find the BitcoinWisdom predictor to be fairly reliable.  It doesn't swing too much.  I don't know what algorithm they use, but it's resistant to at least some of the flaws that I've seen with others.  I think it must use some kind of upward bias where it more heavily weights the most recently seen high-point for hashrate.  This works on an intuitive level because while new mining hardware might be turned on for testing then taken offline while it's shipped out to customers, after a week or two it will tend to turn on and stay on permanently.  So if the network hits a hashrate peak and then drops down, it's a safe bet that it will soon hit that level again.

https://bitcoinwisdom.com/bitcoin/difficulty

Thanks.  I don't like bitcoinwisdom at all.  I always find it to be wrong.

M

[praeluceo]

I find the BitcoinWisdom predictor to be fairly reliable.  It doesn't swing too much.  I don't know what algorithm they use, but it's resistant to at least some of the flaws that I've seen with others.  I think it must use some kind of upward bias where it more heavily weights the most recently seen high-point for hashrate.  This works on an intuitive level because while new mining hardware might be turned on for testing then taken offline while it's shipped out to customers, after a week or two it will tend to turn on and stay on permanently.  So if the network hits a hashrate peak and then drops down, it's a safe bet that it will soon hit that level again.

https://bitcoinwisdom.com/bitcoin/difficulty

Thanks.  I don't like bitcoinwisdom at all.  I always find it to be wrong.

M

Do you have any citation for that? I use BitcoinWisdom exclusively because it's the only forecast I've seen that doesn't swing wildly (like baddw said), and as it gets closer to the change, it's rarely off by more than 0.1%. For this last change, near the last few blocks it forecast that difficulty would go down 0.88%, but it only dropped 0.73%, so they were only off by 0.15%, not too terribly bad if you ask me. All forecasts are "wrong" in the sense that it's the future, so it's unknowable, but BitcoinWisdom seems to do a really decent job at providing a reliable number that more closely matches how difficulty actually changes, unlike many other mining forecast sites.

[mdude77]

I find the BitcoinWisdom predictor to be fairly reliable.  It doesn't swing too much.  I don't know what algorithm they use, but it's resistant to at least some of the flaws that I've seen with others.  I think it must use some kind of upward bias where it more heavily weights the most recently seen high-point for hashrate.  This works on an intuitive level because while new mining hardware might be turned on for testing then taken offline while it's shipped out to customers, after a week or two it will tend to turn on and stay on permanently.  So if the network hits a hashrate peak and then drops down, it's a safe bet that it will soon hit that level again.

https://bitcoinwisdom.com/bitcoin/difficulty

Thanks.  I don't like bitcoinwisdom at all.  I always find it to be wrong.

M

Do you have any citation for that? I use BitcoinWisdom exclusively because it's the only forecast I've seen that doesn't swing wildly (like baddw said), and as it gets closer to the change, it's rarely off by more than 0.1%. For this last change, near the last few blocks it forecast that difficulty would go down 0.88%, but it only dropped 0.73%, so they were only off by 0.15%, not too terribly bad if you ask me. All forecasts are "wrong" in the sense that it's the future, so it's unknowable, but BitcoinWisdom seems to do a really decent job at providing a reliable number that more closely matches how difficulty actually changes, unlike many other mining forecast sites.

I don't look at it often.  Every time I have, it was quite different from what reality turned out to be.  Maybe it's changed since the last time I looked at it?  My app's calculation is based upon number of blocks solved since last change, so as it gets closer to the next change, it gets more accurate.

I really don't know how else you could calculate it and be even reasonably close.

M

[baddw]

I find the BitcoinWisdom predictor to be fairly reliable.  It doesn't swing too much.  I don't know what algorithm they use, but it's resistant to at least some of the flaws that I've seen with others.  I think it must use some kind of upward bias where it more heavily weights the most recently seen high-point for hashrate.  This works on an intuitive level because while new mining hardware might be turned on for testing then taken offline while it's shipped out to customers, after a week or two it will tend to turn on and stay on permanently.  So if the network hits a hashrate peak and then drops down, it's a safe bet that it will soon hit that level again.

https://bitcoinwisdom.com/bitcoin/difficulty

Thanks.  I don't like bitcoinwisdom at all.  I always find it to be wrong.

M

I don't think it's perfect, but it is better than any others that I have seen.  The problem that I can see with this method:

The estimated next difficulty in my app projects what the next change will be IF the blocks/time solved since last diff change remain constant.

is that in a time of hashrate being added to the network (which has been nearly constant over the last several years) the blocks/time solved since last diff change will decidedly NOT remain constant, but will drop.  Perhaps Bitcoinwisdom has over-built this idea into their algorithm, so in times like the present where hashrate seems to be leveling off, it is more inaccurate than during times of rising hashrate.  As praeluceo said, any predictor is inherently wrong because the future is unknowable, but I have found Bitcoinwisdom to be a better predictor than all others that I've seen.  It certainly converges to the true value as the blocks lead up to the difficulty change.

[mdude77]

The estimated next difficulty in my app projects what the next change will be IF the blocks/time solved since last diff change remain constant.

is that in a time of hashrate being added to the network (which has been nearly constant over the last several years) the blocks/time solved since last diff change will decidedly NOT remain constant, but will drop.  Perhaps Bitcoinwisdom has over-built this idea into their algorithm, so in times like the present where hashrate seems to be leveling off, it is more inaccurate than during times of rising hashrate.  As praeluceo said, any predictor is inherently wrong because the future is unknowable, but I have found Bitcoinwisdom to be a better predictor than all others that I've seen.  It certainly converges to the true value as the blocks lead up to the difficulty change.

I'm not talking about using the overall blocks/time to project next change, I'm talking about only the blocks/time since last change.

In other words, we know the target is 6 blocks an hour, or one every 10 minutes.  We know how many blocks have been solved since the last change, and we know when the last change was.  With those values we can surmise that we're currently solving one every X minutes ... and that value compared to 10 will tell us what the next change will be, assuming we stay at that solve rate.

The downside to this is immediately after the difficulty change the number of blocks solved is so small it makes the estimate vary quite a bit.  On the flip side, of course, the closer we get to the next change, the more accurate it is.

That's what I do, and it must be what Bitcoinwisdom is now doing.  (I think we're saying the same thing..)

M

[baddw]

The estimated next difficulty in my app projects what the next change will be IF the blocks/time solved since last diff change remain constant.

is that in a time of hashrate being added to the network (which has been nearly constant over the last several years) the blocks/time solved since last diff change will decidedly NOT remain constant, but will drop.  Perhaps Bitcoinwisdom has over-built this idea into their algorithm, so in times like the present where hashrate seems to be leveling off, it is more inaccurate than during times of rising hashrate.  As praeluceo said, any predictor is inherently wrong because the future is unknowable, but I have found Bitcoinwisdom to be a better predictor than all others that I've seen.  It certainly converges to the true value as the blocks lead up to the difficulty change.

I'm not talking about using the overall blocks/time to project next change, I'm talking about only the blocks/time since last change.

In other words, we know the target is 6 blocks an hour, or one every 10 minutes.  We know how many blocks have been solved since the last change, and we know when the last change was.  With those values we can surmise that we're currently solving one every X minutes ... and that value compared to 10 will tell us what the next change will be, assuming we stay at that solve rate.

The downside to this is immediately after the difficulty change the number of blocks solved is so small it makes the estimate vary quite a bit.  On the flip side, of course, the closer we get to the next change, the more accurate it is.

That's what I do, and it must be what Bitcoinwisdom is now doing.  (I think we're saying the same thing..)

M

(sorry for going so far off-topic in the Eligius thread)

1) Average over how many blocks?  The graphs at Bitcoinwisdom show averages over the last 2016, 1008, and 504 blocks, as well as the last 16 blocks on a different graph.... of course the average over 2016 blocks varies less (and is ultimately what determines the difficulty increase), but the average over 1008 or 504 blocks might be more reflective of trends in hashrate.  If you are averaging ONLY over the blocks since the last difficulty increase, you're throwing out useful information, because....

2) Taking the average time to solve (however you determine that average), and doing some math with the current difficulty level, lets you back into an estimate of network hashrate.  This is the more stable number since of course the time to solve will change at every difficulty reset.  (In other words, the hashpower is more stable versus the block time.... in the real world, the block time is determined by the network hashpower, but since we have no way of knowing the true hashpower of the network due to its decentralization, we have to work backwards mathematically, and derive the hashpower from the block time.)  The bitcoinwisdom graphs show that the network has reached roughly 300,000 TH/s several times on both the 504-block and 1008-block lines, and come close on the 2016-block line.

So the upshot is that you can and should use the block times prior to the latest difficulty reset. By doing calculations based on the difficulty at that earlier time, you can estimate the network hashrate, which has a tendency to monotonically increase (i.e., it may go up or stay flat, but it will rarely go down for any sustained period).

[mdude77]

(sorry for going so far off-topic in the Eligius thread)

1) Average over how many blocks?  The graphs at Bitcoinwisdom show averages over the last 2016, 1008, and 504 blocks, as well as the last 16 blocks on a different graph.... of course the average over 2016 blocks varies less (and is ultimately what determines the difficulty increase), but the average over 1008 or 504 blocks might be more reflective of trends in hashrate.  If you are averaging ONLY over the blocks since the last difficulty increase, you're throwing out useful information, because....

2) Taking the average time to solve (however you determine that average), and doing some math with the current difficulty level, lets you back into an estimate of network hashrate.  This is the more stable number since of course the time to solve will change at every difficulty reset.  (In other words, the hashpower is more stable versus the block time.... in the real world, the block time is determined by the network hashpower, but since we have no way of knowing the true hashpower of the network due to its decentralization, we have to work backwards mathematically, and derive the hashpower from the block time.)  The bitcoinwisdom graphs show that the network has reached roughly 300,000 TH/s several times on both the 504-block and 1008-block lines, and come close on the 2016-block line.

So the upshot is that you can and should use the block times prior to the latest difficulty reset. By doing calculations based on the difficulty at that earlier time, you can estimate the network hashrate, which has a tendency to monotonically increase (i.e., it may go up or stay flat, but it will rarely go down for any sustained period).

I'm not sure I agree.  All the Bitcoin protocol cares about when re-targeting the difficulty is how close we were to 10 minutes per block since the last difficulty change.  Anything before that is really irrelevant.

If you did want to try to include prior data, how would you determine where to draw the line?  Since the beginning of time?  Last month?  Last 3 difficulty changes?  All are arbitrary, and really have no influence on the next change.  One may be able to argue that since a bunch of new hardware was just sent out that it'll increase ... however the price/BTC is also an unknown variable that influences difficulty.  If it drops, older hardware will be turned off.  If it increases, older hardware may be turned on. 

M

[baddw]

All the Bitcoin protocol cares about when re-targeting the difficulty is how close we were to 10 minutes per block since the last difficulty change.  Anything before that is really irrelevant.

Irrelevant at the most technical level, sure.  But irrelevant on a fundamental level?  Hardly.  You could say that the worldwide number of barrels of oil produced today has no relationship with the number of barrels oil produced yesterday.  Technically, this is correct; the events are independent.  But ignoring today while trying to predict tomorrow is foolish.  The network hashrate has increased unimpeded over the past several years.  It may be in a period of slowdown as ASIC makers hit the smallest transistor node sizes available at a decent price, but it would take some kind of miracle for the hashrate to show a significant decrease.  And to repeat myself, the network hashrate is what determines the average block time, not the other way around.  The hashrate represents real-world resource usage, while the block time is simply a byproduct of those resources.  To ignore recent hashrate trends when you're trying to predict future difficulty is to ignore a lot of meaningful data.

To give one example, there is a fairly common thing that has happened with the hashrate, which is that it increases to a peak, then drops, then a week or so later, it rises to the previous peak.  This is due to the test-then-ship-then-install procedure followed by ASIC manufacturers.  It often takes a week or so for the ASICs to ship to customers and be installed.  In this case, a peak is telling you what is soon to come.... perhaps before the next difficulty adjustment.  I encourage you to study the charts at Bitcoinwisdom, and to do so on a daily basis.  They can tell you a lot more than a single difficulty prediction number can.

If you did want to try to include prior data, how would you determine where to draw the line?  Since the beginning of time?  Last month?  Last 3 difficulty changes?  All are arbitrary, and really have no influence on the next change.  One may be able to argue that since a bunch of new hardware was just sent out that it'll increase ... however the price/BTC is also an unknown variable that influences difficulty.  If it drops, older hardware will be turned off.  If it increases, older hardware may be turned on.

Let's say the difficulty has just changed 10 blocks ago.... less than 2 hours.  Your app can rely on either the last 9 blocks, or you can rely on a larger dataset telling you that the network hashrate has averaged 280,000-290,000 TH/s during the last month.  Which do you think is going to give you a better estimate?  If your answer is just "there will be wild swings during the first few blocks after a difficulty re-target" then your app should simply not provide an estimate during that time rather than look like a fool giving an answer based on a tiny sample size.  What if the first block is found 10 seconds after the difficulty adjustment, and your app shows a 5000% projected increase?  You've got to at least have some sanity checks in there.

Certainly a difficulty estimator could include the fiat price of BTC in its calculations, but only on the margins, and only for extreme swings.  Since I stopped mining in March, the hashrate has increased nearly 10-fold.  The September 25 difficulty increase represented the addition of an equivalent hashrate to the total network hashrate that existed when I stopped mining in March.  (roughly 30,000 TH/s)  Obviously all of the hardware that existed in March represents the "older hardware" pretty closely.  If we assume that all of that existing older hardware has been turned off since March (unlikely -- but maybe half of it has), but BTC/USD doubles tomorrow and all those old machines are turned back on, it will represent a 10% increase in hashrate.  So it would have an effect, but not a huge one.  An ideal predictor would have all kinds of information built into it, such as ASIC manufacturer announcements and ship dates.

(Again, apologies for the thread derail... I hope that discussions of difficulty change predictions are interesting enough to earn forbearance.)