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

[bible_pay]

I just googled it and I was wondering if it could be that instead since 17.10 is using OpenSSL 1.1?

One of the primary differences between master (OpenSSL 1.1.0) and the 1.0.2 version is that many types have been made opaque, i.e. applications are no longer allowed to look inside the internals of the structures. The biggest impact on applications is that:

You cannot instantiate these structures directly on the stack. So instead of:

Code:

EVP_CIPHER_CTX ctx;

you must instead do:

Code:

EVP_CIPHER_CTX *ctx = EVP_CIPHER_CTX_new();
....
EVP_CIPHER_CTX_free(ctx);

You must only use the provided accessor functions to access the internals of the structure.

You have to use the version of OpenSSL in the build instructions.

I'm not sure if this will help you get on the compatible OpenSSL version, but I just checked in 1058c if you want to grab it.  In this version we log the openSSL version in the initialization sequence of the log, I added the OpenSSL field to the Gui in Tools | Information, and I added an rpc command: exec getversion, that also shows the SSL version.

Im using openssl 1.0.1t on my machines. I think the primary issue is staying between 101f and 101z for this software, as moving to 102 breaks compatibility.  Please try that.

Ah, it makes sense.

I will try to do that but it might be an issue for people using linux as openssl 1.0.1 is really old and there's no package for it anymore so you would have to build it from the sources. Ubuntu 16.04 is using OpenSSL 1.0.2 and I believe that's the oldest version you would find with all the mainstream distributions.

Update: Found that Ubuntu 14 is using OpenSSL 1.0.1f. I wouldn't recommend to anyone using that version unless it's strictly a miner since that version is not supported anymore and I believe 1.0.1 still has the heartbleed bug if you use it for something else.

Now that I think about it, it's probably why everything has been upgraded to 1.0.2, because of the heartbleed bug in OpenSSL 1.0.1.

I'm trying to compile it using a static version of OpenSSL 1.0.1f I just compiled and will come back to you with the results.

Update: I guess there's no options to use a specific OpenSSL library. Would it possible to add a --with-ssl argument to be able to use a static openssl library?

Testing with Ubuntu 14 for now since it has OpenSSL 1.0.1f.

Its definitely not subject to heartbleed, I was around when that happened, when it hit litecoin and some others, and we were on 1.0.1e.  We had to upgrade above 101e.  Then  101k became very popular for a long time.

Its possible to downgrade your openssl on the box and make a script to compile biblepay using it:
If you self compile openssl 1.0.1t for example and place it in /usr/local/openssl you can tell config to use it before you compile with this switch:

./config --prefix=/usr --openssldir=/usr/local/openssl shared
make
make install


Hopefully that Ubuntu 14 works then we can move forward

[Alex873434]

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?

[bible_pay]

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!

[bible_pay]

Our new logo is Up at c-cex:

https://c-cex.com/?p=bbp-btc

Must hit ctrl-f5 to refresh it.

[Alex873434]

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?

[bible_pay]

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?

[Alex873434]

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

[bible_pay]

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.

[togoshigekata]

Our new logo is Up at c-cex:

https://c-cex.com/?p=bbp-btc

Must hit ctrl-f5 to refresh it.

Yay!

Also, New Logo and Twitter on CoinMarketCap!

https://coinmarketcap.com/currencies/biblepay/

[Alex873434]

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.html

For 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.

[bible_pay]

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.html

For 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.md

Yes, I make the builds with gitian.

[Alex873434]

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.html

For 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.md

Yes, I make the builds with gitian.

Hata thanks, I deleted my previous message hoping no one would see it since I found these right after! I guess building using gitian is the only really reliable way to build anything so I will do that! Everyone building on linux should probably do that too.

[YourMom420]

Saw there was a new linux update. What for?

[bible_pay]

Saw there was a new linux update. What for?

Its just for TestNet.

[bible_pay]

Mattel announces Islamic barbie doll with Hijab:

http://buzz.blog.ajc.com/2017/11/13/mattel-announces-ibtihaj-muhammad-doll-first-barbie-to-wear-a-hijab/

[Alex873434]

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?

[616westwarmoth]

Our new logo is Up at c-cex:

https://c-cex.com/?p=bbp-btc

Must hit ctrl-f5 to refresh it.

Good job   ... It's nice

Glad to see it propagating through the system!  It's a winner!

[smbbm]

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.

[sharpshot]

'Rob'

nephews came over this weekend. they saw on my computer the pool page and pictures of kids. i explained to them what the project was about..trying to explain how bitcoins / crypto are 'funny fake money' and have no real value other than what people believe. (yeah, you can imagine how far i got with that economics lesson)

anyway, they asked about the kids and i said that every time the computer made some funny money it helps those kids. they got excited about that

so, im calling a truce (if there ever was a 'war'). the project may do some good in the short term. ive given the warnings and its fallen on deaf ears. the majority want to make money money money

mid term, 'Rob', crytpos are causing hyperinflation of the real economies. the poor and working class will be decimated if they dont get into it. that is the whole devilish design of this and the road forward to 666. 'cant buy and sell without blockchain' will be reality very soon.

you should know that you are a part of this bigger plan even if you dont intend it. dont be blinded by money, ego, profit. try to make the project a REAL sanctuary for people

I don't think your warnings fell on deaf ears, I just dissagreed with most of them and thought you were desperately trying to find faults that weren't there.  A lot of the poor and working class are getting decimated with fiat money.  I really don't see how cryptocurrency can make things worse?  Some of the countries with the poorest people are now turning to cryptocurrency, because their governments have lost control of their fiat currency. We will have to wait and see how this all pans out, the entire cryptocurrency market cap is similar to just one bank at the moment, so it's impossible to make accurate predictions.  There's still a good chance that it wont grow as much as us early adopters think it will.  There's a lot of greed with cryptocurrency but I think there's also more opportunity to spread wealth and have less of a gap between the richest and poorest than we do with fiat currency.  I became interested in Electroneum when I saw that people could make money with a $20 mobile phone, as long as they can get free access to the internet.

[Alex873434]

@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.