So I see someone created 7 pool accounts so they can write short letters to orphans and upvote their own letters, receive the reward and hurry up and withdraw the BBP. Take heed and remember this about Ananias: http://jesus-christ.us/Ananias.htmHi Rob, this problem will be sorted once sanctuaries are online, correct? Since they will approve this type of thing? Thanks Eventually, but I think at first the sancs will just be voting on the budget and new proposals, basically for the "big" superblocks. The letter writing system will still be there, with its upvote/downvote, but I can fix the problem using similar technology that the faucet uses. Sounds good! You track ip's or something? Maybe, maybe not, LOL. |
|
|
|
So I see someone created 7 pool accounts so they can write short letters to orphans and upvote their own letters, receive the reward and hurry up and withdraw the BBP. Take heed and remember this about Ananias: http://jesus-christ.us/Ananias.htmHi Rob, this problem will be sorted once sanctuaries are online, correct? Since they will approve this type of thing? Thanks Eventually, but I think at first the sancs will just be voting on the budget and new proposals, basically for the "big" superblocks. The letter writing system will still be there, with its upvote/downvote, but I can fix the problem using similar technology that the faucet uses. |
|
|
|
So I see someone created 7 pool accounts so they can write short letters to orphans and upvote their own letters, receive the reward and hurry up and withdraw the BBP. Take heed and remember this about Ananias: http://jesus-christ.us/Ananias.htm |
|
|
|
Got this from Matt @ Biblepay, mentioned to me that this charity is 97.7% efficient, and has a widow program: https://christianaidministries.org/program/support-a-widow/Dont forget our original slogan: James 1:27 Religion that is pure and undefiled before God the Father is this: to visit orphans and widows in their affliction, and to keep oneself unstained. |
|
|
|
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. 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: 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. |
|
|
|
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. |
|
|
|
No but - I replied to your PM about this, I did notify happy_merchant. He owns this BX. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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? |
|
|
|
@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. |
|
|
|
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. |
|
|
|
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_inflationMonetary 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. |
|
|
|
Saw there was a new linux update. What for?
Its just for TestNet. |
|
|
|
Well I'm still waiting to see if I see one of my miners IPs being flagged. This is what I found for the OpenSSL issue: https://blog.ivanristic.com/2013/08/compiling-apache-with-static-openssl.htmlFor example, it looks like Apache has an option in their configure file to be able to use a specific version of OpenSSL and I was wondering if you could add that in the configure file of biblepay. For testing purposes, I will just upgrade to 101t and see if it works that's not an issue. I guess it would just be more problematic for people not only mining on their computers as it could potentially break other applications if not specific to biblepay and it would be harder to get started too. Also, I'm almost 100% certain I am not the only one having that issue as I tried so many flavours of linux, etc on different providers even with different hardware and they all had that. Here are the gitian build instructions: https://github.com/biblepay/biblepay/blob/master/doc/gitian-building.mdYes, I make the builds with gitian. |
|
|
|
Ubuntu 14 with OpenSSL 1.0.1f seems to be working so far! However, I'm 100% sure it is affected by heartbleed. I even just googled it to make sure: The affected versions of OpenSSL are OpenSSL 1.0.1 through 1.0.1f (inclusive) I know I can compile it and install on my boxes but I'm afraid it could break something else so instead I would like to only use OpenSSL 1.0.1 to compile biblepay so would it be possible to have a config option to do that when compiling? Yes, thats it, I was on 101e when heartbleed came out and it affected UP TO 101f, and thats when we went to g back then. So just compile 101t on the box and use this parameter when compiling (or see if you can install a binary of 101g-t): ./config --prefix=/usr --openssldir=/usr/local/openssl shared make make install Thats great that its working! Im happy about that, because I couldnt tell if we had a hacker or a bug causing that, Great! Well what I wanted to do was to have OpenSSL 1.0.1 compiled in /opt/openssl-1.0.1 and then when compiling biblepay, being able to do something like that: ./configure LDFLAGS="-L${BDB_PREFIX}/lib/" CPPFLAGS="-I${BDB_PREFIX}/include/" --with-ssl=/opt/openssl-1.0.1 so that only biblepay would use that openssl version, would it be possible to have something like that? I found this in the openssl.mk gitian build package: --openssldir=$(host_prefix)/etc/openssl no-zlib no-shared no-dso Try changing your --with-ssl to that and see? If it works with a non-shared openSSL lib? Wouldn't that be in the configure of biblepay instead of OpenSSL? Since it's when I'm configuring biblepay for compilation that I want it to use the compiled OpenSSL in the folder I'm specifying. I shouldn't have to touch the configure options of OpenSSL to do that? Also, looked like we got happy too soon . I just got that from one of the miners: 2017-11-13 23:01:10 UpdateTip: new best=a75c328e98c5787faa8ecf990dadac60f5bab43c9a871ac38257734958878c4c height=16594 log2_work=57.727112 tx=28129 date=2017-11-13 23:01:04 progress=1.000000 cache=0.0MiB(11tx) 2017-11-13 23:01:10 ProcessNewBlock : ACCEPTED 2017-11-13 23:02:58 ERROR: CheckProofOfWork(1): BibleHash does not meet POW level, prevheight 16594.000000 pindexPrev a75c328e98c5787faa8ecf990dadac60f5bab43c9a871ac38257734958878c4c 2017-11-13 23:02:58 ERROR: CheckBlockHeader(): proof of work failed 2017-11-13 23:02:58 Misbehaving: 54.37.69.159:40000 (0 -> 30) 2017-11-13 23:02:58 ERROR: invalid header received 11adfafdd138586928f2e4655c14586c4050a63ca7a30eb7dbff9c74ed878d13 Alrighty, well see if you can figure it out with the linux guys- all you have to do is find a way to install open SSL 101t on your box- maybe googling downgrading openSSL version on specific Ubuntu version, "bitcoin". Im sure they have encountered that issue. On the other issue, biblepay is working for everyone in testnet and were not banning each other. If this problem existed for everyone the network would fracture because it DDOSes everyone else and you will lose all your connections. |
|
|
|
Ubuntu 14 with OpenSSL 1.0.1f seems to be working so far! However, I'm 100% sure it is affected by heartbleed. I even just googled it to make sure: The affected versions of OpenSSL are OpenSSL 1.0.1 through 1.0.1f (inclusive) I know I can compile it and install on my boxes but I'm afraid it could break something else so instead I would like to only use OpenSSL 1.0.1 to compile biblepay so would it be possible to have a config option to do that when compiling? Yes, thats it, I was on 101e when heartbleed came out and it affected UP TO 101f, and thats when we went to g back then. So just compile 101t on the box and use this parameter when compiling (or see if you can install a binary of 101g-t): ./config --prefix=/usr --openssldir=/usr/local/openssl shared make make install Thats great that its working! Im happy about that, because I couldnt tell if we had a hacker or a bug causing that, Great! Well what I wanted to do was to have OpenSSL 1.0.1 compiled in /opt/openssl-1.0.1 and then when compiling biblepay, being able to do something like that: ./configure LDFLAGS="-L${BDB_PREFIX}/lib/" CPPFLAGS="-I${BDB_PREFIX}/include/" --with-ssl=/opt/openssl-1.0.1 so that only biblepay would use that openssl version, would it be possible to have something like that? I found this in the openssl.mk gitian build package: --openssldir=$(host_prefix)/etc/openssl no-zlib no-shared no-dso Try changing your --with-ssl to that and see? If it works with a non-shared openSSL lib? |
|
|
|
|
Show Posts
,it was big mistake/bug in their chain
