BiblePay - New Coin Launch - Official Thread

[inblue]

@bible_pay Any chance of fixing the difficulty adjustment sooner, the difficulty is increasing exponentially and block rewards are at 25% now.

No, it's better that rewards are as small as possible. Because:

At this point we are harder to mine, and have less reward per block, so the exchange being a free market should take that into account and BBP may increase in value.

Definitely understand the supply vs demand side but at the same time the difficulty bug will eventually will be fixed in few months and when its back to 20k rewards, the equation will change. Current situation is good for short time gain but in order for the coin to prolong through years it has to have consistency.

You should read the dev's post here, it certainly isn't a bug but an intended feature, only it's less than the dev imagined. TLDR: He said it will be left like that and that a slight adjustment could be made sometime in the future, if necessary. So I doubt there will be 20k rewards again.

[nananaminer]

I've just taken a look at my workers for the first time today and it appears all my workers have been down for sometime. Restarting the daemon (I'm on linux) doesn't restart mining; something is wrong. I nuked one of the instances of biblepay that I have by deleting .biblepaycore (except biblepay.conf) and let the blockchain resync. Once sync'ed, it won't mine and gives "HEALTH_DOWN" when I check 'getmininginfo'.

Here's the latest extract from 'debug.log':

------
2017-09-13 06:17:27 ERROR: CheckBlockHeader(): proof of work failed
2017-09-13 06:17:27 ERROR: ProcessNewBlock: CheckBlock FAILED
2017-09-13 06:17:27 Misbehaving: 45.76.85.130:40000 (50 -> 100) BAN THRESHOLD EXCEEDED
2017-09-13 06:20:53 ERROR: ReadBlockFromDisk: OpenBlockFile failed for CBlockDiskPos(nFile=-1, nPos=0)
2017-09-13 06:20:54 89ERROR: CheckProofOfWork(): BibleHash does not meet POW level with TxIndex Lookup, prevheight 7141.000000 pindexPrev 16265e604f37754bec$
2017-09-13 06:20:54 ERROR: CheckBlockHeader(): proof of work failed
2017-09-13 06:20:54 ERROR: ProcessNewBlock: CheckBlock FAILED
2017-09-13 06:20:54 Misbehaving: 149.56.43.244:57462 (0 -> 50)
2017-09-13 06:20:54 89ERROR: CheckProofOfWork(): BibleHash does not meet POW level with TxIndex Lookup, prevheight 7142.000000 pindexPrev be3a96f7b585a3c6e3$
2017-09-13 06:20:54 ERROR: CheckBlockHeader(): proof of work failed
2017-09-13 06:20:54 ERROR: ProcessNewBlock: CheckBlock FAILED
2017-09-13 06:20:54 Misbehaving: 149.56.43.244:57462 (50 -> 100) BAN THRESHOLD EXCEEDED
------

Reading the previous posts, this isn't quite the same as what other people have reported. I 'clearbanned' like someone else mentioned, but it doesnt seem to change anything. 'Thoughts?


I have both of these problems lol. My miners constantly go off the pool and I think they are not reverting to solo mining, because it still says poolmining=true, but the pool doesn't recognize them. When I restart them, they go on the pool briefly and then drop again.

Same problem for me since yesterday. Been pulling the miners online every half hour before they go offline. Doesn't switch to solo mining either.
Dev is doing a great job but wish all the changes such as algo, difficulty adjustments etc were first tested on the testnet first before multiple mandatory fixes.
Also not sure what the pool's reward system is like right now, seems erratic.

@bible_pay Any chance of fixing the difficulty adjustment sooner, the difficulty is increasing exponentially and block rewards are at 25% now.

Yes, I agreed that fixing of block rewards should be the top priority, because it is too low now.

And I would think after this lesson, dev really have to test any changes in testnet before release it, there are too many unknown issues occurred. I don't mean to criticize and I really appreciate dev's effort, I think dev must be busy on fixing these issues now 

Glad all of us are agreeing on this.
Dev is doing a tremendous job, his openness and commitment to the project is the reason I started engaging with BiblePay in the first place.
Hope the dev finds time to get through these fixes.  

[inblue]

I just discovered a very useful command:

Code:

getchaintips

Code:

[
  {
    "height": 7403,
    "hash": "d4be35faa8907ea8ed864ae492c25c5671cc19863270fecf501fd592cada08ab",
    "difficulty": 379.9904871916831,
    "chainwork": "0000000000000000000000000000000000000000000000000001769fcb695cb4",
    "branchlen": 0,
    "status": "active"
  }, 
  {
    "height": 7277,
    "hash": "44b03913f666bf563146b63ebf2d5c3c985149128ab524d7d66f712cbe13fd33",
    "difficulty": 0.001746781667724304,
    "chainwork": "0000000000000000000000000000000000000000000000000000000b87bba393",
    "branchlen": 252,
    "status": "headers-only"
  }, 
  {
    "height": 7195,
    "hash": "fdda0190500497237aa7a02b7d7d3b0c6907a868e3e6a08e39f32b7846f4c826",
    "difficulty": 0.004355675118676943,
    "chainwork": "0000000000000000000000000000000000000000000000000000000d738715f2",
    "branchlen": 54,
    "status": "headers-only"
  }, 
  {
    "height": 7181,
    "hash": "67d46eea7155a4c112edc8d44cbeff178a2f000ebccde53f65a344355dbeb274",
    "difficulty": 35.85249517036227,
    "chainwork": "0000000000000000000000000000000000000000000000000000010ab91e7f44",
    "branchlen": 1,
    "status": "valid-headers"
  }, 
  {
    "height": 7181,
    "hash": "334491104c0108e1ef69f25e20f7ce881fd05ffe232035ca4fdbe5890b9a12df",
    "difficulty": 35.85249517036227,
    "chainwork": "0000000000000000000000000000000000000000000000000000010ab91e7f44",
    "branchlen": 1,
    "status": "valid-fork"
  }, 
  {
    "height": 7178,
    "hash": "ae1d4b1b6aac1313ed873278869cd92d68d3deab9140a0343b239ebc8d5b4621",
    "difficulty": 0.00284443264647385,
    "chainwork": "0000000000000000000000000000000000000000000000000000000d17095463",
    "branchlen": 37,
    "status": "headers-only"
  }, 
  {
    "height": 7163,
    "hash": "1f09f77b8b2d0d689effff01d1d7f181d85490b8cc6442a3f7fc92f315c4180c",
    "difficulty": 0.001591352444876824,
    "chainwork": "0000000000000000000000000000000000000000000000000000000d17ac5594",
    "branchlen": 22,
    "status": "headers-only"
  }, 
  {
    "height": 7157,
    "hash": "585b188cb78522c0c5b3a07d4cc893ed4378a8d74f987f0151e2d279f0457968",
    "difficulty": 0.6628937306548522,
    "chainwork": "0000000000000000000000000000000000000000000000000000000f7ea0fa13",
    "branchlen": 16,
    "status": "valid-fork"
  }, 
  {
    "height": 7045,
    "hash": "6c7371021d292252c030073f8b9faf69bf5ca136849202756315fff6c3a3d880",
    "difficulty": 0.001775789883045804,
    "chainwork": "0000000000000000000000000000000000000000000000000000000b7d7b39c8",
    "branchlen": 9,
    "status": "headers-only"
  }, 
  {
    "height": 6109,
    "hash": "0000055d3f5ba3c9b7fd615822555d7b4087455374da204830123f319b391d45",
    "difficulty": 0.005306311368116459,
    "chainwork": "00000000000000000000000000000000000000000000000000000008a849201f",
    "branchlen": 1,
    "status": "valid-headers"
  }, 
  {
    "height": 5680,
    "hash": "00000281a69a4f0d9c0c7ae7610736785205542a84331e035f7b97889702203f",
    "difficulty": 0.006903401966151241,
    "chainwork": "0000000000000000000000000000000000000000000000000000000792083d42",
    "branchlen": 1,
    "status": "valid-headers"
  }
]

So does anyone have an idea what do these statuses mean? We have "active" (that one is pretty obvious), "headers-only", "valid-headers" and "valid-fork".

[slovakia]

I can not synchronize my wallet. I want to re-pump the blocks. Give please the list of nodes.

for me working this
addnode=node.biblepay.org  
addnode=137.74.0.113
addnode=37.59.14.211
addnode=94.23.196.50
addnode=94.23.12.37
addnode=91.121.83.119
addnode=188.165.193.28

what is Immature Balance on POOL?

[oliwer21]

what is Immature Balance on POOL?

Its "not confirmed" it should be mature in 24h and you can payoff it.

BTW 5k coins of reward per block on pool and huge drop of hash is worth of mine for small miners...
@inblue what is your best cpu on witch you got such big hash?
My profit per block droped from 200+ to round 30... feelsbadman
Have anyone noticed that pool adress had yesterday aditional sings when was opened?

[svirusxxx2]

can you send me anybody to my wallet few coins if working....thanks....
BBpi9CkgnzHaybBFfWvzqneu74RJ78xo5Q

I just sended 100BBP from pool.biblepay.org
Transaction ID: 637acd9ad70cec68a1ceed54a3c9e5905ece615d2b25cea07a89d40f1bc25c06

Why would you send him BBP? He's the one who has been talking shit about this coin and now he is asking for free money? I also see that he is banned from some other threads...

Why not ?
I'am from Poland, so Slovakia is my neighborhood
and of course 100BBP now is about $0.07

[GeniusX]

when masternodes come out?

[slovakia]

oliwer21
svirusxxx2

thanks guys

is correct for Ryzen 1700? 8cores/16threads
Hashes Per Second  6790.98   Hashes Per Second2 21385.08

[ste1]

Somehow I got 1 040 000.00 Biblepay but now I can't syncronize?!

[bible_pay]

My linux miners show up briefly once started but eventually disappear from the pool website. These are the last few logs:

Code:

2017-09-13 05:49:40 89UpdateTip: new best=13db8243c2bdc0778c90b4570eda7ec1469daf435fa5f9da10e7ae1d9513d84$
2017-09-13 05:49:40 ProcessNewBlock : ACCEPTED
2017-09-13 05:49:46 CMasternodeSync::IsBlockchainSynced -- found enough peers on the same height as we ar$
2017-09-13 05:50:45 connection from 175.204.123.147:51971 dropped (banned)
2017-09-13 05:51:34 DGW: Height 7392.000000, NewDiff 1b54a84f     nActualTimespan 1134.000000    nTargetT$
2017-09-13 05:52:09 connection from 218.71.239.70:57766 dropped (banned)
2017-09-13 05:53:41 ERROR: CheckProofOfWork(): BibleHash does not meet POW level, prevheight 5478.000000 $
2017-09-13 05:53:41 ReadBlockFromDisk: Errors in block header at CBlockDiskPos(nFile=0, nPos=1999285)
** ProcessGetData:Cannot load block from disk.
2017-09-13 06:01:23 DGW: Height 7392.000000, NewDiff 1b54a84f     nActualTimespan 1134.000000    nTargetT$
2017-09-13 06:02:47 connection from 218.71.239.70:57994 dropped (banned)
2017-09-13 06:05:26 connection from 77.106.146.145:54432 dropped (banned)
2017-09-13 06:05:31 89UpdateTip: new best=e45940fec237f88b0ee2a6f30d89d1875764f6a4ffe4180b52cbf03560ba874$
2017-09-13 06:05:31 ProcessNewBlock : ACCEPTED
2017-09-13 06:05:37 CMasternodeSync::IsBlockchainSynced -- found enough peers on the same height as we ar$
2017-09-13 06:09:47 connection from 175.204.123.147:52249 dropped (banned)
2017-09-13 06:12:34 89ERROR: CheckProofOfWork(): BibleHash does not meet POW level, prevheight 7392.00000$
2017-09-13 06:12:34 ReadBlockFromDisk: Errors in block header at CBlockDiskPos(nFile=0, nPos=3283261)Upda$
2017-09-13 06:12:34 ProcessNewBlock : ACCEPTED
2017-09-13 06:12:40 CMasternodeSync::IsBlockchainSynced -- found enough peers on the same height as we ar$
2017-09-13 06:13:15 ERROR: CheckProofOfWork(): BibleHash does not meet POW level with TxIndex Lookup, pre$
2017-09-13 06:13:15 ERROR: CheckBlockHeader(): proof of work failed
2017-09-13 06:13:15 Misbehaving: [2001:0:9d38:6abd:30d5:3e2e:5033:846c]:11527 (0 -> 50)
2017-09-13 06:13:15 ERROR: invalid header received 1f317d504e22a10b34d0a48334babd030c96265d5150b0129c9649$
2017-09-13 06:13:15 ProcessMessages(headers, 28677 bytes) FAILED peer=75
2017-09-13 06:13:44 ERROR:
CheckProofOfWork(): hash doesn't meet X11 POW Level, Prod 1.000000, Network main, PrevHeight 0

2017-09-13 06:13:44 ERROR: CheckBlockHeader(): proof of work failed
2017-09-13 06:13:44 Misbehaving: [2001:0:9d38:6abd:30d5:3e2e:5033:846c]:11527 (50 -> 100) BAN THRESHOLD E$
2017-09-13 06:13:44 ERROR: invalid header received 9002b29834f151df58cd77f3cccb1b34e35c2e1bd1110cffa237ab$
2017-09-13 06:13:44 ProcessMessages(headers, 82 bytes) FAILED peer=75

What version r u running?  The strange thing about your log is the line with "x11 pow level" in it- that is off in f7000?

[bible_pay]

Somehow I got 1 040 000.00 Biblepay but now I can't syncronize?!

Please verify u r on 1031?

[bible_pay]

when masternodes come out?

I believe Christmas 2017.

As soon as things settle down we will head to the testnet thread on forum.biblepay.org, hopefully you can help test them.

[bible_pay]

I've just taken a look at my workers for the first time today and it appears all my workers have been down for sometime. Restarting the daemon (I'm on linux) doesn't restart mining; something is wrong. I nuked one of the instances of biblepay that I have by deleting .biblepaycore (except biblepay.conf) and let the blockchain resync. Once sync'ed, it won't mine and gives "HEALTH_DOWN" when I check 'getmininginfo'.

Here's the latest extract from 'debug.log':

------
2017-09-13 06:17:27 ERROR: CheckBlockHeader(): proof of work failed
2017-09-13 06:17:27 ERROR: ProcessNewBlock: CheckBlock FAILED
2017-09-13 06:17:27 Misbehaving: 45.76.85.130:40000 (50 -> 100) BAN THRESHOLD EXCEEDED
2017-09-13 06:20:53 ERROR: ReadBlockFromDisk: OpenBlockFile failed for CBlockDiskPos(nFile=-1, nPos=0)
2017-09-13 06:20:54 89ERROR: CheckProofOfWork(): BibleHash does not meet POW level with TxIndex Lookup, prevheight 7141.000000 pindexPrev 16265e604f37754bec$
2017-09-13 06:20:54 ERROR: CheckBlockHeader(): proof of work failed
2017-09-13 06:20:54 ERROR: ProcessNewBlock: CheckBlock FAILED
2017-09-13 06:20:54 Misbehaving: 149.56.43.244:57462 (0 -> 50)
2017-09-13 06:20:54 89ERROR: CheckProofOfWork(): BibleHash does not meet POW level with TxIndex Lookup, prevheight 7142.000000 pindexPrev be3a96f7b585a3c6e3$
2017-09-13 06:20:54 ERROR: CheckBlockHeader(): proof of work failed
2017-09-13 06:20:54 ERROR: ProcessNewBlock: CheckBlock FAILED
2017-09-13 06:20:54 Misbehaving: 149.56.43.244:57462 (50 -> 100) BAN THRESHOLD EXCEEDED
------

Reading the previous posts, this isn't quite the same as what other people have reported. I 'clearbanned' like someone else mentioned, but it doesnt seem to change anything. 'Thoughts?


I have both of these problems lol. My miners constantly go off the pool and I think they are not reverting to solo mining, because it still says poolmining=true, but the pool doesn't recognize them. When I restart them, they go on the pool briefly and then drop again.

Same problem for me since yesterday. Been pulling the miners online every half hour before they go offline. Doesn't switch to solo mining either.
Dev is doing a great job but wish all the changes such as algo, difficulty adjustments etc were first tested on the testnet first before multiple mandatory fixes.
Also not sure what the pool's reward system is like right now, seems erratic.

@bible_pay Any chance of fixing the difficulty adjustment sooner, the difficulty is increasing exponentially and block rewards are at 25% now.

Yes, I agreed that fixing of block rewards should be the top priority, because it is too low now.

And I would think after this lesson, dev really have to test any changes in testnet before release it, there are too many unknown issues occurred. I don't mean to criticize and I really appreciate dev's effort, I think dev must be busy on fixing these issues now 

Glad all of us are agreeing on this.
Dev is doing a tremendous job, his openness and commitment to the project is the reason I started engaging with BiblePay in the first place.
Hope the dev finds time to get through these fixes.  

Alright all, well Im not against sending out a mandatory upgrade that fixes these current issues - since c-cex hasnt upgraded the mandatory yet.

Regarding testing in testnet, we DID test in testnet, but these outlying conditions were not caught.  I think what we need to do is during the next testing phase, we need more volunteers (we only had a few faithful volunteers last time) and we need to have more elaborate test cases.

Moving forward, I agree, the subsidy was a big surprise and its getting worse.  The node ban problem is an issue also.

Why dont we take advantage of this period while the exchange is down and fix the 3 known issues, have a mandatory and then follow up with c-cex.  I see they are down for maintenance now, they will probably be taking BBP offline in 20 mins.

I just ran a simulation on the current diff level, and I am positive of the new value that we need compiled in to put our subsidy back around the 18000 level, so that is solved.

The banning issue in prod is solved with a high degree of certainty, I am doing some testing now regarding the root cause.
I did find an issue in the logs regarding reading blocks from the disk errors, based on the posted logs.  If I can integrate these 3 fixes into 1032, Id prefer we just go ahead and knock this out and have a mandatory in 4 hours.

Rob

[inblue]

BTW 5k coins of reward per block on pool and huge drop of hash is worth of mine for small miners...

@inblue what is your best cpu on witch you got such big hash?

Ahh... This is another topic I wanted to start, but I was too lazy. There are obviously some big changes in this new algo in ways I still don't quite understand. It seems that the algo actually favors mid-range and small miners, because stronger machines don't bring proportionally as much HPS2 (real HPS measured by pool). Now it's much better to have 10 small machines which have 8 threads each than to have 1 big machine which has 80 threads.

Here is a rough comparison of my miners:

blu1    = 16 cores, genproclimit 32, 64k HPS, 42k HPS2
blu2-3 = 24 cores, genproclimit 48, 64k HPS, 42k HPS2
blu4    = 40 cores, genproclimit 80, 55k HPS, 27k HPS2
blu5-9 =   2 cores, genproclimit   8, 17k HPS, 35k HPS2

First of all, why do blu2 and 3 have the same hashrate as blu1? In the previous algo they had about 530k while blu1 had about 350k, and these numbers are exactly proportionate to the number of cores (24 cores = 530k hps, 16 cores = 350k hps, divide them and you'll see, about 22k per core). Now both the 16 core one and the 24 core ones have the same hashrate, as if the CPU on the 24 core machines is not used to its fullest, but it is, it has 100% usage.

But the real mystery here is how in the world does a $20/mo shared VPS (blu5-9) outperform a $250/mo dedicated enterprise machine (blu4)? In the previous algo the high-spec machine was at the top of the leaderboard at around 830k hashrate and the cheap VPSs had around 70k each.

[bible_pay]

I decided to go ahead and fix these 3 known issues (including raising the subsidy back to the 18000 level - so we dont confuse investors with any uncertainty), while c-cex is down.

This next release should solve the subsidy, the pool-ban issue, and the read from disk error.  The x11/checkblock issue will be resolved based on all users running the new version.

Please be ready for a mandatory upgrade in 4 hours.

[inblue]

Please be ready for a mandatory upgrade in 4 hours.

I was born ready. Awesome work, very fast.

I see 1.0.3.2 is already on GitHub, so we can start the upgrade?

[bible_pay]

BTW 5k coins of reward per block on pool and huge drop of hash is worth of mine for small miners...

@inblue what is your best cpu on witch you got such big hash?

Ahh... This is another topic I wanted to start, but I was too lazy. There are obviously some big changes in this new algo in ways I still don't quite understand. It seems that the algo actually favors mid-range and small miners, because stronger machines don't bring proportionally as much HPS2 (real HPS measured by pool). Now it's much better to have 10 small machines which have 8 threads each than to have 1 big machine which has 80 threads.

Here is a rough comparison of my miners:

blu1    = 16 cores, genproclimit 32, 64k HPS, 42k HPS2
blu2-3 = 24 cores, genproclimit 48, 64k HPS, 42k HPS2
blu4    = 40 cores, genproclimit 80, 55k HPS, 27k HPS2
blu5-9 =   2 cores, genproclimit   8, 17k HPS, 35k HPS2

First of all, why do blu2 and 3 have the same hashrate as blu1? In the previous algo they had about 530k while blu1 had about 350k, and these numbers are exactly proportionate to the number of cores (24 cores = 530k hps, 16 cores = 350k hps, divide them and you'll see, about 22k per core). Now both the 16 core one and the 24 core ones have the same hashrate, as if the CPU on the 24 core machines is not used to its fullest, but it is, it has 100% usage.

But the real mystery here is how in the world does a $20/mo shared VPS (blu5-9) outperform a $250/mo dedicated enterprise machine (blu4)? In the previous algo the high-spec machine was at the top of the leaderboard at around 830k hashrate and the cheap VPSs had around 70k each.

I can answer Part of this, but not entirely sure where the rest of the answer lies.
So the HPS2 column should not be brought into the equation in this case, because the pool is paying per Share found per round now, and HPS2 is now based on shares found in the round (Its something like shares found * 1000 * AgeDecayFactor) .  So that column contains a bit of luck.  Every share is equal also, so the higher power machines should be finding a proportionately higher number of shares.

But moving on, you show that the $20 blu5-9 hashed at 70k in the prior algo, now at 17k, and the $250 blu4 hashed at 800k prior and now at 80k.  Meaning that before, you had received 12* the reward for the $250 server, and now you only receive 4* the reward (making the $20 equal to $80 per month, or, an extremely bad ROI).  Yes, I see what you mean, the current algo is favoring the mid to small size machines.

So unless you disagree it sounds as if we should talk about why does the new algo favor the mid to small machines, correct?

[bible_pay]

Please be ready for a mandatory upgrade in 4 hours.

I was born ready. Awesome work, very fast.

I see 1.0.3.2 is already on GitHub, so we can start the upgrade?

Lets give it a couple hours at least, so the windows users have a "chance" to come online.
This way we can all sort of get in together. 

[inblue]

BTW 5k coins of reward per block on pool and huge drop of hash is worth of mine for small miners...

@inblue what is your best cpu on witch you got such big hash?

Ahh... This is another topic I wanted to start, but I was too lazy. There are obviously some big changes in this new algo in ways I still don't quite understand. It seems that the algo actually favors mid-range and small miners, because stronger machines don't bring proportionally as much HPS2 (real HPS measured by pool). Now it's much better to have 10 small machines which have 8 threads each than to have 1 big machine which has 80 threads.

Here is a rough comparison of my miners:

blu1    = 16 cores, genproclimit 32, 64k HPS, 42k HPS2
blu2-3 = 24 cores, genproclimit 48, 64k HPS, 42k HPS2
blu4    = 40 cores, genproclimit 80, 55k HPS, 27k HPS2
blu5-9 =   2 cores, genproclimit   8, 17k HPS, 35k HPS2

First of all, why do blu2 and 3 have the same hashrate as blu1? In the previous algo they had about 530k while blu1 had about 350k, and these numbers are exactly proportionate to the number of cores (24 cores = 530k hps, 16 cores = 350k hps, divide them and you'll see, about 22k per core). Now both the 16 core one and the 24 core ones have the same hashrate, as if the CPU on the 24 core machines is not used to its fullest, but it is, it has 100% usage.

But the real mystery here is how in the world does a $20/mo shared VPS (blu5-9) outperform a $250/mo dedicated enterprise machine (blu4)? In the previous algo the high-spec machine was at the top of the leaderboard at around 830k hashrate and the cheap VPSs had around 70k each.

I can answer Part of this, but not entirely sure where the rest of the answer lies.
So the HPS2 column should not be brought into the equation in this case, because the pool is paying per Share found per round now, and HPS2 is now based on shares found in the round (Its something like shares found * 1000 * AgeDecayFactor) .  So that column contains a bit of luck.  Every share is equal also, so the higher power machines should be finding a proportionately higher number of shares.

But moving on, you show that the $20 blu5-9 hashed at 70k in the prior algo, now at 17k, and the $250 blu4 hashed at 800k prior and now at 80k.  Meaning that before, you had received 12* the reward for the $250 server, and now you only receive 4* the reward (making the $20 equal to $80 per month, or, an extremely bad ROI).  Yes, I see what you mean, the current algo is favoring the mid to small size machines.

So unless you disagree it sounds as if we should talk about why does the new algo favor the mid to small machines, correct?

Correct, exactly, you nailed it. Well, ideologically I guess it's not bad to favor the mid to small miners for high decentralization purposes, but I am still wondering from the technical side of things, is that a bug in the algo or something.

Please be ready for a mandatory upgrade in 4 hours.

I was born ready. Awesome work, very fast.

I see 1.0.3.2 is already on GitHub, so we can start the upgrade?

Lets give it a couple hours at least, so the windows users have a "chance" to come online.
This way we can all sort of get in together. 

I get it. Do you happen to have the info on how many Windows users there are, compared to the Linux users?

[tiras]

Please be ready for a mandatory upgrade in 4 hours.

I was born ready. Awesome work, very fast.

I see 1.0.3.2 is already on GitHub, so we can start the upgrade?

Lets give it a couple hours at least, so the windows users have a "chance" to come online.
This way we can all sort of get in together. 

I started linux upgrades.  they will take at least an hour anyway .  thanks Bible_pay