BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes)

[znffal]

Where is the airdrop? 

I don't think there is one. There is a faucet on the pool.biblepay.org

[1714008819]

1714008819

[1714008819]

1714008819

[1714008819]

1714008819

[1714008819]

1714008819

[1714008819]

1714008819

[sharpshot]

Where is the airdrop? 

It's so easy to mine, you shouldn't need an airdrop.

[PhaseshiftUK]

FYI, the Block Explorer seems to have got stuck on Saturday 11th November, block 16174.  I've just message Rob about it.

[bible_pay]

I'm sorry that you didnt understand my reply even after I stated in detail why we ARE deflationary.  I said clearly that we have a deflationary reward, just as BITCOIN has a Deflationary Reward, and Clearly how that is a TRUE statement.  

And, I went on to explain how your single example was inaccurate because NEM injects (IE prints) money from their 100% premine cache later, which is technically inflation by your own definition (you cant have it both ways).

This project is credible, and I dont want people of questionable knowledge coming in and accusing us of posting something inaccurate.

https://en.wikipedia.org/wiki/Monetary_inflation
Monetary inflation is a sustained increase in the money supply of a country (or currency area).
The Austrian School maintains that inflation is any increase of the money supply

You're right with the fact that 100% premine (NEM) has its drawbacks and I see your point in keeping significant part of XEMs out of the market for a further release - which will cause uncontrolled inflation in the future. And yes, Bitcoin is also not deflationary despite many opposite statements (at least not until 2140). Of course compare to wildly-printed fiat, Bitcoin is still a king in preserving value and its growing value nominated in fiat proves that quite well.

To be clear, I don't question yours or the project's credibility, I'm the the one who wish to see Bible Pay to be amount TOP10 crypto and I'm very glad that there is a Christian-centric crypto project.

Thank you Smbbm, now we are talking!  I agree with you 100%, and now we can work together on the topic.  

So to clarify, the textbook quant definition of inflation states that an increasing money supply is inflation.  That puts BiblePay and Bitcoin in that camp.  

I suppose what we need to do is add some assumptions underneath an extended statement: BiblePay seeks to be a deflationary currency relative to the G5 basket, by constantly decreasing its block reward structure by 1.5% per month.  We make the assumption that with our controlled seven minute block mint rate, coins will be bought at a normalized pace in time due to the free market pricing structure.

EDIT: I added the assumption to the OP.

[bible_pay]

Hey Rob, I'm now using OpenSSL 1.0.1t but this is what I have on my miners on mainnet.

Still getting things like that:

2017-11-14 04:02:23 ERROR: CheckProofOfWork(1): BibleHash does not meet POW level, prevheight 16625.000000 pindexPrev f9fe69c5232c644d7358c59a0aa60063300c19f40f223defb10fad909fa2c04d
2017-11-14 04:02:23 ERROR: CheckBlockHeader(): proof of work failed
2017-11-14 04:02:23 Misbehaving: 195.181.247.200:40000 (0 -> 30)

Update: So it's been quite some time now and I think I'm only getting the error from the same bunch of IPs now including the one above and it doesn't seem to be super often. Could it be someone using the wrong openssl version and sending me bad blocks?

Update 2: Nvm, just saw one of my minner with 101t got flagged by another one of my miners

Is anyone else seeing anything like that in their debug.log file?

Thanks for all the effort on this, Its an interesting issue, and Ive put a considerable amount of effort in verifying the same biblehash is emitted during each call (IE for this specific issue), by adding code in the area when the miner finds a block to re-call the biblehash again, so Im confident with 101t, its not a situation where biblehash returns a different hash to the same miner.  On my external node, my logs (back when I had them) showed that it was the same rash of a few IPs, constantly trying bad POBH hashes and getting banned.  Like I said, I did see Two hashes in 24 hours, by the Local IP, which makes no sense whatsoever, the last time I checked.

So I think what we should do is see if you do find a higher degree of stability now on 101t, and see if you can pinpoint any pattern, IE is 99.9% of the problem solved, and it appears to be the same subset that is d-dossing now?  And see if your local mining issue diminishes down to 1-2 per 24 hours?  If we can isolate that then we will know what to hone in on next. 

[bible_pay]

@Rob Also, I've been trying to build binaries using gitian but I guess I haven't been successful. Also, it's referencing to https://github.com/biblepaypay/biblepay.git in a lot of placed including gitian-linux.yml, is that a typo?

If you could build binaries for linux 64 bits for me, I would gladly test that and see if I still have this issue.

Can someone who knows gitian builds please get together with Alex and work this out?  I cant get involved in any of this Alex.

[Alex873434]

I'm not sure it actually improved I decided to go on a large scale to gather more data and basically started 250 vms divided between google cloud, aws and digital ocean as well as around 10 physical servers.

They have different hardware ranging from a 20k hashpower up to 250k. I have xeon, intel core and ryzen thrown in there.

I am now running Debian Jessie as it is provided with OpenSSl 101k. (but had tested with ubuntu 14, 15, 16 and centos 6 before and I was still getting these errors -OpenSSl 1.0.2)

Each node seems to get these errors at some point or another (not all get the same error at the same time and with different frequency). I can see external ips outside of my miners throwing that error at me as well as my own miners flagging each other for misbehaving.

I just picked a random node and this is what is in the debug.log

2017-11-14 13:32:09 ERROR: CheckBlockHeader(): proof of work failed
2017-11-14 13:32:09 Misbehaving: 62.138.8.103:40000 (90 -> 120) BAN THRESHOLD EXCEEDED
2017-11-14 13:32:09 ERROR: invalid header received 3382985605d8dc0e599c613c82c3e717d34b605c46acafaa059695929d6262cd
2017-11-14 13:32:09 UpdateTip: new best=3382985605d8dc0e599c613c82c3e717d34b605c46acafaa059695929d6262cd  height=16685  log2_work=57.744679  tx=28257  date=2017-11-14 13:32:07 progress=1.000000  cache=2.3MiB(9961tx)
2017-11-14 13:32:09 ProcessNewBlock : ACCEPTED
2017-11-14 13:41:00 ERROR: CheckProofOfWork(1): BibleHash does not meet POW level, prevheight 16685.000000 pindexPrev 3382985605d8dc0e599c613c82c3e717d34b605c46acafaa059695929d6262cd
2017-11-14 13:41:00 ERROR: CheckBlockHeader(): proof of work failed
2017-11-14 13:41:00 ERROR: ProcessNewBlock: CheckBlock FAILED
2017-11-14 13:41:00 Misbehaving: 192.99.69.79:40000 (30 -> 60)
2017-11-14 13:41:01 UpdateTip: new best=ae378fc59163704592bc8cfa67e83d42ceb65126bab0584036015ab14c8b7125  height=16686  log2_work=57.744891  tx=28258  date=2017-11-14 13:40:54 progress=1.000000  cache=2.3MiB(9962tx)
2017-11-14 13:41:01 ProcessNewBlock : ACCEPTED
2017-11-14 13:47:41 ERROR: CheckProofOfWork(1): BibleHash does not meet POW level, prevheight 16686.000000 pindexPrev ae378fc59163704592bc8cfa67e83d42ceb65126bab0584036015ab14c8b7125
2017-11-14 13:47:41 ERROR: CheckBlockHeader(): proof of work failed
2017-11-14 13:47:41 Misbehaving: 35.190.148.94:40000 (0 -> 30)
2017-11-14 13:47:41 ERROR: invalid header received d25bd3000bf0034fc6098626e905c27f0edb7bfd9efecde91f35927f348fdb6f
2017-11-14 13:47:41 ERROR: CheckProofOfWork(1): BibleHash does not meet POW level, prevheight 16686.000000 pindexPrev ae378fc59163704592bc8cfa67e83d42ceb65126bab0584036015ab14c8b7125
2017-11-14 13:47:41 ERROR: CheckBlockHeader(): proof of work failed
2017-11-14 13:47:41 ERROR: ProcessNewBlock: CheckBlock FAILED
2017-11-14 13:47:41 Misbehaving: 192.99.69.79:40000 (60 -> 90)
2017-11-14 13:47:41 UpdateTip: new best=d25bd3000bf0034fc6098626e905c27f0edb7bfd9efecde91f35927f348fdb6f  height=16687  log2_work=57.745051  tx=28260  date=2017-11-14 13:47:39 progress=1.000000  cache=2.3MiB(9963tx)
2017-11-14 13:47:41 ProcessNewBlock : ACCEPTED
2017-11-14 13:49:40 ERROR: CheckProofOfWork(1): BibleHash does not meet POW level, prevheight 16687.000000 pindexPrev d25bd3000bf0034fc6098626e905c27f0edb7bfd9efecde91f35927f348fdb6f
2017-11-14 13:49:40 ERROR: CheckBlockHeader(): proof of work failed
2017-11-14 13:49:40 ERROR: ProcessNewBlock: CheckBlock FAILED
2017-11-14 13:49:40 Misbehaving: 78.48.94.80:39774 (0 -> 30)

I also tried to run on testnet and I'm not sure what changed but I basically got enough errors to ban the two others nodes that were there with me and I had no connections left. I can provide the full log in pastebin if you'd like. I'm not sure what else to do as my knowledge is kind of limited in that space

[bible_pay]

I'm not sure it actually improved I decided to go on a large scale to gather more data and basically started 250 vms divided between google cloud, aws and digital ocean as well as around 10 physical servers.

They have different hardware ranging from a 20k hashpower up to 250k. I have xeon, intel core and ryzen thrown in there.

I am now running Debian Jessie as it is provided with OpenSSl 101k. (but had tested with ubuntu 14, 15, 16 and centos 6 before and I was still getting these errors -OpenSSl 1.0.2)

Each node seems to get these errors at some point or another (not all get the same error at the same time and with different frequency). I can see external ips outside of my miners throwing that error at me as well as my own miners flagging each other for misbehaving.

I just picked a random node and this is what is in the debug.log

2017-11-14 13:32:09 ERROR: CheckBlockHeader(): proof of work failed
2017-11-14 13:32:09 Misbehaving: 62.138.8.103:40000 (90 -> 120) BAN THRESHOLD EXCEEDED
2017-11-14 13:32:09 ERROR: invalid header received 3382985605d8dc0e599c613c82c3e717d34b605c46acafaa059695929d6262cd
2017-11-14 13:32:09 UpdateTip: new best=3382985605d8dc
2017-11-14 13:49:40 ERROR: CheckBlockHeader(): proof of work failed
2017-11-14 13:49:40 ERROR: ProcessNewBlock: CheckBlock FAILED
2017-11-14 13:49:40 Misbehaving: 78.48.94.80:39774 (0 -> 30)

I also tried to run on testnet and I'm now sure what changed but I basically got enough errors to ban the two others nodes that were there with me and I had no connections left. I can provide the full log in pastebin if you'd like. I'm not sure what else to do as my knowledge is kind of limited in that space

Thats the funniest thing Ive ever seen, well you sure did put a lot of effort in this, I think we need to figure this out.

What doesn't make any sense at all to me is I just took a look at all 3 of my testnet nodes and I havent banned anyone and we are still humming along.
The 2 people who figured out testnet sanctuaries are still connected to me and us 5 say "enabled".  This is very, very strange.

One more question for you before i rent an ubuntu 64 box:  It appears that since you tried so much disparate hardware and SSL versions, that maybe this is NOT openssl.  One wildcard could be the timezone and current time.  The PoBH does change the hash after the late block threshhold.  Lets try to hone in on that next just to rule it out.  Could you try one node with your local time zone set and ensure the clock time is set and see if you get banned?

[Alex873434]

I'm not sure it actually improved I decided to go on a large scale to gather more data and basically started 250 vms divided between google cloud, aws and digital ocean as well as around 10 physical servers.

They have different hardware ranging from a 20k hashpower up to 250k. I have xeon, intel core and ryzen thrown in there.

I am now running Debian Jessie as it is provided with OpenSSl 101k. (but had tested with ubuntu 14, 15, 16 and centos 6 before and I was still getting these errors -OpenSSl 1.0.2)

Each node seems to get these errors at some point or another (not all get the same error at the same time and with different frequency). I can see external ips outside of my miners throwing that error at me as well as my own miners flagging each other for misbehaving.

I just picked a random node and this is what is in the debug.log

2017-11-14 13:32:09 ERROR: CheckBlockHeader(): proof of work failed
2017-11-14 13:32:09 Misbehaving: 62.138.8.103:40000 (90 -> 120) BAN THRESHOLD EXCEEDED
2017-11-14 13:32:09 ERROR: invalid header received 3382985605d8dc0e599c613c82c3e717d34b605c46acafaa059695929d6262cd
2017-11-14 13:32:09 UpdateTip: new best=3382985605d8dc
2017-11-14 13:49:40 ERROR: CheckBlockHeader(): proof of work failed
2017-11-14 13:49:40 ERROR: ProcessNewBlock: CheckBlock FAILED
2017-11-14 13:49:40 Misbehaving: 78.48.94.80:39774 (0 -> 30)

I also tried to run on testnet and I'm now sure what changed but I basically got enough errors to ban the two others nodes that were there with me and I had no connections left. I can provide the full log in pastebin if you'd like. I'm not sure what else to do as my knowledge is kind of limited in that space

Thats the funniest thing Ive ever seen, well you sure did put a lot of effort in this, I think we need to figure this out.

What doesn't make any sense at all to me is I just took a look at all 3 of my testnet nodes and I havent banned anyone and we are still humming along.
The 2 people who figured out testnet sanctuaries are still connected to me and us 5 say "enabled".  This is very, very strange.

One more question for you before i rent an ubuntu 64 box:  It appears that since you tried so much disparate hardware and SSL versions, that maybe this is NOT openssl.  One wildcard could be the timezone and current time.  The PoBH does change the hash after the late block threshhold.  Lets try to hone in on that next just to rule it out.  Could you try one node with your local time zone set and ensure the clock time is set and see if you get banned?

I will try that. I usually have my boxes configured with UTC times as it is easier for me. Would you like me to change that to a different timezone?

I think they all should have the correct time but I will configure a ntp service to make sure of that. Hopefully we're on the right track!

[bible_pay]

I'm not sure it actually improved I decided to go on a large scale to gather more data and basically started 250 vms divided between google cloud, aws and digital ocean as well as around 10 physical servers.

They have different hardware ranging from a 20k hashpower up to 250k. I have xeon, intel core and ryzen thrown in there.

I am now running Debian Jessie as it is provided with OpenSSl 101k. (but had tested with ubuntu 14, 15, 16 and centos 6 before and I was still getting these errors -OpenSSl 1.0.2)

Each node seems to get these errors at some point or another (not all get the same error at the same time and with different frequency). I can see external ips outside of my miners throwing that error at me as well as my own miners flagging each other for misbehaving.

I just picked a random node and this is what is in the debug.log

2017-11-14 13:32:09 ERROR: CheckBlockHeader(): proof of work failed
2017-11-14 13:32:09 Misbehaving: 62.138.8.103:40000 (90 -> 120) BAN THRESHOLD EXCEEDED
2017-11-14 13:32:09 ERROR: invalid header received 3382985605d8dc0e599c613c82c3e717d34b605c46acafaa059695929d6262cd
2017-11-14 13:32:09 UpdateTip: new best=3382985605d8dc
2017-11-14 13:49:40 ERROR: CheckBlockHeader(): proof of work failed
2017-11-14 13:49:40 ERROR: ProcessNewBlock: CheckBlock FAILED
2017-11-14 13:49:40 Misbehaving: 78.48.94.80:39774 (0 -> 30)

I also tried to run on testnet and I'm now sure what changed but I basically got enough errors to ban the two others nodes that were there with me and I had no connections left. I can provide the full log in pastebin if you'd like. I'm not sure what else to do as my knowledge is kind of limited in that space

Thats the funniest thing Ive ever seen, well you sure did put a lot of effort in this, I think we need to figure this out.

What doesn't make any sense at all to me is I just took a look at all 3 of my testnet nodes and I havent banned anyone and we are still humming along.
The 2 people who figured out testnet sanctuaries are still connected to me and us 5 say "enabled".  This is very, very strange.

One more question for you before i rent an ubuntu 64 box:  It appears that since you tried so much disparate hardware and SSL versions, that maybe this is NOT openssl.  One wildcard could be the timezone and current time.  The PoBH does change the hash after the late block threshhold.  Lets try to hone in on that next just to rule it out.  Could you try one node with your local time zone set and ensure the clock time is set and see if you get banned?

I will try that. I usually have my boxes configured with UTC times as it is easier for me. Would you like me to change that to a different timezone?

I think they all should have the correct time but I will configure a ntp service to make sure of that. Hopefully we're on the right track!

Well we have a large fudge factor in there, the code converts the server back to UTC, and allows 3-4 min variances, in GetAdjustedTime(), but its still worth trying, I would try your local timezone and just ensure the clock is within a minute or so of actual local time, Im using CST here if you feel like trying that. 

Im poring over the chain of events now to see what this could possibly be; without OpenSSL, its even stranger.

[Alex873434]

I'm not sure it actually improved I decided to go on a large scale to gather more data and basically started 250 vms divided between google cloud, aws and digital ocean as well as around 10 physical servers.

They have different hardware ranging from a 20k hashpower up to 250k. I have xeon, intel core and ryzen thrown in there.

I am now running Debian Jessie as it is provided with OpenSSl 101k. (but had tested with ubuntu 14, 15, 16 and centos 6 before and I was still getting these errors -OpenSSl 1.0.2)

Each node seems to get these errors at some point or another (not all get the same error at the same time and with different frequency). I can see external ips outside of my miners throwing that error at me as well as my own miners flagging each other for misbehaving.

I just picked a random node and this is what is in the debug.log

2017-11-14 13:32:09 ERROR: CheckBlockHeader(): proof of work failed
2017-11-14 13:32:09 Misbehaving: 62.138.8.103:40000 (90 -> 120) BAN THRESHOLD EXCEEDED
2017-11-14 13:32:09 ERROR: invalid header received 3382985605d8dc0e599c613c82c3e717d34b605c46acafaa059695929d6262cd
2017-11-14 13:32:09 UpdateTip: new best=3382985605d8dc
2017-11-14 13:49:40 ERROR: CheckBlockHeader(): proof of work failed
2017-11-14 13:49:40 ERROR: ProcessNewBlock: CheckBlock FAILED
2017-11-14 13:49:40 Misbehaving: 78.48.94.80:39774 (0 -> 30)

I also tried to run on testnet and I'm now sure what changed but I basically got enough errors to ban the two others nodes that were there with me and I had no connections left. I can provide the full log in pastebin if you'd like. I'm not sure what else to do as my knowledge is kind of limited in that space

Thats the funniest thing Ive ever seen, well you sure did put a lot of effort in this, I think we need to figure this out.

What doesn't make any sense at all to me is I just took a look at all 3 of my testnet nodes and I havent banned anyone and we are still humming along.
The 2 people who figured out testnet sanctuaries are still connected to me and us 5 say "enabled".  This is very, very strange.

One more question for you before i rent an ubuntu 64 box:  It appears that since you tried so much disparate hardware and SSL versions, that maybe this is NOT openssl.  One wildcard could be the timezone and current time.  The PoBH does change the hash after the late block threshhold.  Lets try to hone in on that next just to rule it out.  Could you try one node with your local time zone set and ensure the clock time is set and see if you get banned?

I will try that. I usually have my boxes configured with UTC times as it is easier for me. Would you like me to change that to a different timezone?

I think they all should have the correct time but I will configure a ntp service to make sure of that. Hopefully we're on the right track!

Well we have a large fudge factor in there, the code converts the server back to UTC, and allows 3-4 min variances, in GetAdjustedTime(), but its still worth trying, I would try your local timezone and just ensure the clock is within a minute or so of actual local time, Im using CST here if you feel like trying that. 

Im poring over the chain of events now to see what this could possibly be; without OpenSSL, its even stranger.

Oh I see, that's interesting. The good news is that in my haste I can see that I left the dedicated servers that were crashing in testnet with the timezone provided by default, in this case CST and CET (Europe). The VMs are in configured with UTC though.

I would be surprised if they're off by more than 3 min as I just launched them this morning for me but I guess it's good practice anyway to make sure your nodes have the correct time with blockchain, more so with biblepay!

So I just installed ntp on a node and had it sync. The timezone used is CET. I deleted the previous testnet folder. I'm on testnet and I just saw that appear before having biblepayd suddenly crashing with nothing else in the logs

2017-11-14 14:44:56 ERROR: CheckProofOfWork(1): BibleHash does not meet POW level, prevheight 10088.000000 pindexPrev 4fb2be0ff52b36c61b557c9fa2e537ea7f0c737795d08c0058f38f01a989b906
2017-11-14 14:44:56 ERROR: CheckBlockHeader(): proof of work failed
2017-11-14 14:44:56 Misbehaving: 94.130.49.121:40001 (0 -> 30)
2017-11-14 14:44:56 ERROR: invalid header received d5934bf14c2ef538e1dac60bf248a7d46957d73599f88e3e9f2c951b373fe736

I'm going to change the timezone now and come back to you with the results

[Alex873434]

No luck by changing to UTC:

2017-11-14 14:54:09 ERROR: CheckProofOfWork(1): BibleHash does not meet POW level, prevheight 10077.000000 pindexPrev aedfc2dd57ebf92df4f9d38d8a60bdb1e5faea939106850eb49beef6ea19fec6
2017-11-14 14:54:09 ERROR: CheckBlockHeader(): proof of work failed
2017-11-14 14:54:09 Misbehaving: 212.159.69.141:53155 (0 -> 30)
2017-11-14 14:54:09 ERROR: invalid header received ef8685c49ae0b6475346ecea20efd798a4cc320f0f30d26dfb3c1c07cf7e8e8f

No luck with CST too:

2017-11-14 14:59:03 ERROR: CheckProofOfWork(1): BibleHash does not meet POW level, prevheight 53.000000 pindexPrev 3f4f4c0ca478872c450d7c80f6c3ffcaa810e14b44b75633a1afa2d1ba492c1e
2017-11-14 14:59:03 ERROR: CheckBlockHeader(): proof of work failed
2017-11-14 14:59:03 ERROR: ProcessNewBlock: CheckBlock FAILED
2017-11-14 14:59:03 Misbehaving: 97.99.69.33:40001 (90 -> 120) BAN THRESHOLD EXCEEDED

For reference, these are the peers I was connected to that got banned:

biblepay-cli -testnet listbanned
[
  {
    "address": "97.99.69.33/32",
    "banned_until": 1510757943,
    "ban_created": 1510671543,
    "ban_reason": "node misbehaving"
  },
  {
    "address": "217.182.67.106/32",
    "banned_until": 1510758083,
    "ban_created": 1510671683,
    "ban_reason": "node misbehaving"
  },
  {
    "address": "2a01:4f8:10a:3fe6::2/128",
    "banned_until": 1510758067,
    "ban_created": 1510671667,
    "ban_reason": "node misbehaving"
  }
]

Forgot to add that the time should be correct too:

synchronised to NTP server (129.70.132.37) at stratum 3
   time correct to within 23 ms
   polling server every 64 s

Update:

Kept trying a few times on the same node (after deleting the tesnet3 folder) and it seems to be working now. I think I might have been on a different chain before for testnet? This one is pretty big (height=39308 right now).

I guess my previous testing on testnet may not have been reliable and I guess I should have paid more attention to that. I see around 30 nodes now there.

No errors so far. It's getting late here so I will let it run overnight and see what I get!

[bible_pay]

No luck by changing to UTC:

2017-11-14 14:54:09 ERROR: CheckProofOfWork(1): BibleHash does not meet POW level, prevheight 10077.000000 pindexPrev aedfc2dd57ebf92df4f9d38d8a60bdb1e5faea939106850eb49beef6ea19fec6
2017-11-14 14:54:09 ERROR: CheckBlockHeader(): proof of work failed
2017-11-14 14:54:09 Misbehaving: 212.159.69.141:53155 (0 -> 30)
2017-11-14 14:54:09 ERROR: invalid header received ef8685c49ae0b6475346ecea20efd798a4cc320f0f30d26dfb3c1c07cf7e8e8f

No luck with CST too:

2017-11-14 14:59:03 ERROR: CheckProofOfWork(1): BibleHash does not meet POW level, prevheight 53.000000 pindexPrev 3f4f4c0ca478872c450d7c80f6c3ffcaa810e14b44b75633a1afa2d1ba492c1e
2017-11-14 14:59:03 ERROR: CheckBlockHeader(): proof of work failed
2017-11-14 14:59:03 ERROR: ProcessNewBlock: CheckBlock FAILED
2017-11-14 14:59:03 Misbehaving: 97.99.69.33:40001 (90 -> 120) BAN THRESHOLD EXCEEDED

For reference, these are the peers I was connected to that got banned:

biblepay-cli -testnet listbanned
[
  {
    "address": "97.99.69.33/32",
    "banned_until": 1510757943,
    "ban_created": 1510671543,
    "ban_reason": "node misbehaving"
  },
  {
    "address": "217.182.67.106/32",
    "banned_until": 1510758083,
    "ban_created": 1510671683,
    "ban_reason": "node misbehaving"
  },
  {
    "address": "2a01:4f8:10a:3fe6::2/128",
    "banned_until": 1510758067,
    "ban_created": 1510671667,
    "ban_reason": "node misbehaving"
  }
]

Forgot to add that the time should be correct too:

synchronised to NTP server (129.70.132.37) at stratum 3
   time correct to within 23 ms
   polling server every 64 s

Ive got an idea, since this seems to be in the CheckProofOfWork(1) function - primarily.  And btw, that 97.99.69.33 node is my debian jessie node which is running source code (In testnet mode that is), so I have access to add some elaborate logging of what I actually send you in the header.

So I think the next thing we can do is I will add some elaborate logging in CheckProofOfWork(1) with the forensics containing the parameters necessary to generate your own biblehash manually, and Ill add a command to the RPC to allow us to generate a biblehash using the parameters, and then we can run those and compare them.

I should be back within an hour.

[slovakia]

hi BIBLEPAY, can you fix this http://biblepay.inspect.network/?  thanks .. or?


sharpshot electroneum is mining with GPU  ,it was big mistake/bug in their chain

[Alex873434]

Oh just added an update at the same time you replied:

Update:

Kept trying a few times on the same node (after deleting the tesnet3 folder) and it seems to be working now. I think I might have been on a different chain before for testnet? This one is pretty big (height=39308 right now).

I guess my previous testing on testnet may not have been reliable and I guess I should have paid more attention to that. I see around 30 nodes now there.

No errors so far. It's getting late here so I will let it run overnight and see what I get!

I guess if one of the node was yours then it cancels my theory on the wrong chain.  I just checked anyway and I am connected to 97.99.69.33 so it doesn't make sense. It's almost as if it was a random issue. We can go ahead with your idea tomorrow but I'm going to be busy the next few days so it may have to wait a little bit on my side before getting my full attention again  .

[sharpshot]

hi BIBLEPAY, can you fix this http://biblepay.inspect.network/?  thanks .. or?


sharpshot electroneum is mining with GPU  ,it was big mistake/bug in their chain

If you research them, they have both GPU and a separate mining simulation for mobile phones.  The GPU miners can't get any of the coins allocated to the mobile phone mining.  They need the GPU miners to keep the blockchain going.

[bible_pay]

hi BIBLEPAY, can you fix this http://biblepay.inspect.network/?  thanks .. or?


sharpshot electroneum is mining with GPU  ,it was big mistake/bug in their chain

No but - I replied to your PM about this, I did notify happy_merchant.  He owns this BX.

[bible_pay]

Oh just added an update at the same time you replied:

Update:

Kept trying a few times on the same node (after deleting the tesnet3 folder) and it seems to be working now. I think I might have been on a different chain before for testnet? This one is pretty big (height=39308 right now).

I guess my previous testing on testnet may not have been reliable and I guess I should have paid more attention to that. I see around 30 nodes now there.

No errors so far. It's getting late here so I will let it run overnight and see what I get!

I guess if one of the node was yours then it cancels my theory on the wrong chain.  I just checked anyway and I am connected to 97.99.69.33 so it doesn't make sense. It's almost as if it was a random issue. We can go ahead with your idea tomorrow but I'm going to be busy the next few days so it may have to wait a little bit on my side before getting my full attention again  .

Yes, Its baffling on all levels, I see a deterministic hash, Im mostly ruling out OpenSSLs version, ruling out Nix-flavor, and from the limited existing logs, I see the pindexPrev is populated.  We ruled out network time.  (But you said things have improved recently but not entirely).  Either way, I did add the elaborate logging in that (1) area, so I will check it in today and when you get time to circle back around we can try again, and manually run the hash from the command line, yay .  Let me know when you want to try.

[Alex873434]

Alright, I will let you know!

I was actually wrong and testnet crashes for me every time the first time (without any testnet3 folder). I have to try to run it a second time to have a chance for it to work.

One thing I noticed is that when running for the first time, it would start generating blocks very quickly without trying to sync to anyone else first? Is that normal?
I think it could actually explain one of my issues as I would start generating blocks very quickly and it be on heigh 40 in a matter of a few seconds.

Code:

2017-11-14 16:15:07 init message: Loading wallet... (101.00 %)
2017-11-14 16:15:07 CBlock(hash=6ff4f6a30b254ef8facae6a621ec0ea6853fcb115c320aefa2a2a5c6feb4bfe3, ver=536870912, hashPrevBlock=122f423f0912850a871c58f1533dd80be62154bb0c56dfb8cb9ae2b957d1ac10, hashMerkleRoot=25d601002eb50fb6475128a7bdd8986b159e2b354c84346d43d1d82fc6101d97, nTime=1510676107, nBits=207fffff, nNonce=0, vtx=1)
  CTransaction(hash=25d601002e, ver=1, vin.size=1, vout.size=1, nLockTime=0)
    CTxIn(COutPoint(0000000000000000000000000000000000000000000000000000000000000000, 4294967295), coinbase 510101)
    CTxOut(nValue=20000.00000000, scriptPubKey=2102ababcffd56488a890ebb29eb4f)


2017-11-14 16:15:07 
ProcessBlockFound::Generated 20000.00
2017-11-14 16:15:07 Pre-allocating up to position 0x100000 in rev00000.dat
2017-11-14 16:15:07 UpdateTip: new best=6ff4f6a30b254ef8facae6a621ec0ea6853fcb115c320aefa2a2a5c6feb4bfe3  height=1  log2_work=2  tx=2  date=2017-11-14 16:15:07 progress=0.000002  cache=0.0MiB(1tx)
2017-11-14 16:15:07 AddToWallet 25d601002eb50fb6475128a7bdd8986b159e2b354c84346d43d1d82fc6101d97  new
2017-11-14 16:15:07 ProcessNewBlock : ACCEPTED
2017-11-14 16:15:07 keypool keep 2
2017-11-14 16:15:07 CBlock(hash=a1c0bdae133d9acac4f3e8fc453999b4649698b3069ae3fa130aaae531e88fd4, ver=536870912, hashPrevBlock=6ff4f6a30b254ef8facae6a621ec0ea6853fcb115c320aefa2a2a5c6feb4bfe3, hashMerkleRoot=15ca5ca5c7045eb5f0be405828f7a8f8ce9b6c2c08c73871a01ec5ca2132684c, nTime=1510676108, nBits=207fffff, nNonce=0, vtx=1)
  CTransaction(hash=15ca5ca5c7, ver=1, vin.size=1, vout.size=1, nLockTime=0)
    CTxIn(COutPoint(0000000000000000000000000000000000000000000000000000000000000000, 4294967295), coinbase 520101)
    CTxOut(nValue=20000.00000000, scriptPubKey=210293485085672a4273023a261874)

Then could it explain why it would reject blocks from other nodes at that time (after having already mined 40 blocks?). Then after 20-40s it would just crash with no explanation. I can then try to relaunch it (without deleting anything) and have it sync to the correct chain.

Sometimes it's sucessful and sometimes it crashes again and throws error such as:

Code:

Error: A fatal internal error occurred, see debug.log for details
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc

The good news is that I still have no new error on the node still connected to testnet right now.

[bible_pay]

Alright, I will let you know!

I was actually wrong and testnet crashes for me every time the first time (without any testnet3 folder). I have to try to run it a second time to have a chance for it to work.

One thing I noticed is that when running for the first time, it would start generating blocks very quickly without trying to sync to anyone else first? Is that normal?
I think it could actually explain one of my issues as I would start generating blocks very quickly and it be on heigh 40 in a matter of a few seconds.

Code:

2017-11-14 16:15:07 init message: Loading wallet... (101.00 %)
2017-11-14 16:15:07 CBlock(hash=6ff4f6a30b254ef8facae6a621ec0ea6853fcb115c320aefa2a2a5c6feb4bfe3, ver=536870912, hashPrevBlock=122f423f0912850a871c58f1533dd80be62154bb0c56dfb8cb9ae2b957d1ac10, hashMerkleRoot=25d601002eb50fb6475128a7bdd8986b159e2b354c84346d43d1d82fc6101d97, nTime=1510676107, nBits=207fffff, nNonce=0, vtx=1)
  CTransaction(hash=25d601002e, ver=1, vin.size=1, vout.size=1, nLockTime=0)
    CTxIn(COutPoint(0000000000000000000000000000000000000000000000000000000000000000, 4294967295), coinbase 510101)
    CTxOut(nValue=20000.00000000, scriptPubKey=2102ababcffd56488a890ebb29eb4f)


2017-11-14 16:15:07 
ProcessBlockFound::Generated 20000.00
2017-11-14 16:15:07 Pre-allocating up to position 0x100000 in rev00000.dat
2017-11-14 16:15:07 UpdateTip: new best=6ff4f6a30b254ef8facae6a621ec0ea6853fcb115c320aefa2a2a5c6feb4bfe3  height=1  log2_work=2  tx=2  date=2017-11-14 16:15:07 progress=0.000002  cache=0.0MiB(1tx)
2017-11-14 16:15:07 AddToWallet 25d601002eb50fb6475128a7bdd8986b159e2b354c84346d43d1d82fc6101d97  new
2017-11-14 16:15:07 ProcessNewBlock : ACCEPTED
2017-11-14 16:15:07 keypool keep 2
2017-11-14 16:15:07 CBlock(hash=a1c0bdae133d9acac4f3e8fc453999b4649698b3069ae3fa130aaae531e88fd4, ver=536870912, hashPrevBlock=6ff4f6a30b254ef8facae6a621ec0ea6853fcb115c320aefa2a2a5c6feb4bfe3, hashMerkleRoot=15ca5ca5c7045eb5f0be405828f7a8f8ce9b6c2c08c73871a01ec5ca2132684c, nTime=1510676108, nBits=207fffff, nNonce=0, vtx=1)
  CTransaction(hash=15ca5ca5c7, ver=1, vin.size=1, vout.size=1, nLockTime=0)
    CTxIn(COutPoint(0000000000000000000000000000000000000000000000000000000000000000, 4294967295), coinbase 520101)
    CTxOut(nValue=20000.00000000, scriptPubKey=210293485085672a4273023a261874)

Then could it explain why it would reject blocks from other nodes at that time (after having already mined 40 blocks?). Then after 20-40s it would just crash with no explanation. I can then try to relaunch it (without deleting anything) and have it sync to the correct chain.

Sometimes it's sucessful and sometimes it crashes again and throws error such as:

Code:

Error: A fatal internal error occurred, see debug.log for details
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc

The good news is that I still have no new error on the node still connected to testnet right now.

Its possible to mine blocks on testnet without being synced, as that is a chainparam setting.  The trick to that is if you want to sync in testnet, you set your genrpoclimit=0 and generate=false before syncing in testnet, then change it after synced. 

Hmm, I dont crash in testnet when I sync from 0, but I delete everything including chainstate, database, mncache, and blocks before I sync.

If you have time for a side project and it would really help us out here, if you would take up installing valgrind on your test harness machine and point out to me where the code dies that would be appreciated and ill be glad to fix it.

Great on syncing so far, I havent checked in the new code yet.