Author

Topic: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes) - page 840. (Read 243376 times)

member
Activity: 98
Merit: 10
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 Sad

Is anyone else seeing anything like that in their debug.log file?
full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
Saw there was a new linux update. What for?

Its just for TestNet.

sr. member
Activity: 430
Merit: 250
Saw there was a new linux update. What for?
member
Activity: 98
Merit: 10
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.
full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
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.
member
Activity: 98
Merit: 10
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.



full member
Activity: 1260
Merit: 115
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/
full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
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:

Quote
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 Sad.

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.

member
Activity: 98
Merit: 10
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:

Quote
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 Sad.

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
full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
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:

Quote
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?


member
Activity: 98
Merit: 10
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:

Quote
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?
full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
Our new logo is Up at c-cex:

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

Must hit ctrl-f5 to refresh it.

full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
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:

Quote
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!


member
Activity: 98
Merit: 10
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:

Quote
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?
full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
I just googled it and I was wondering if it could be that instead since 17.10 is using OpenSSL 1.1?

Quote
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 Smiley


full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
Biblepay is moving forward but & nice logo... just curious about few things:

1) Latin terms in logo? Any special reason for that... is that a Roman Catholic or Vatican project or what's the reason for that?

2) You're using (probably unintentionally) false statement about money supply: BiblePay is not deflationary currency like it's stated but it's actually highly inflationary crypto with quite rapidly decreasing inflation rate in time. Just to be accurate!  There are some non-inflationary - and theoretically deflationary cryptos (like NEM or ).



We have absolutely no ties to Roman catholicism or the Vatican.  As a matter of fact, Im particularly ANTI Roman-Catholicism myself, primarily because I believe in pure Christianity, with the bible exactly static and Jesus the sole soul arbiter (https://www.jesus-is-lord.com/cath.htm).  The Latin logo phrase was chosen to be a universal truth.

All right, we are at the same page here and language you've chosen is completely up to you, I was just quite surprised because Latin church circles were most of the history strongly against the original Bible text and they either persecuted Bible holders or at least tried to modify the Word so it looks bit weird to me to see Latin verses together with Bible, that's all.

Quote
On #2, Oh I pray this can end here.  If this gets out of hand or disrespectful, this conversation will end, but the truth will stay.

I will clarify that we have a Deflationary Emission Schedule per Block.  According to your definition of inflation (an expanding money supply), you obviously believe bitcoin is inflationary (because their money supply is expanding still) even though, they halve the reward every 4 years and have already printed 95% of their supply into existence.  The problem is, I dont think the exact quant definition of inflation describes us well or that moving 5.2 billion coins of money supply into the genesis block magically makes us deflationary either.  I think we just need to exactly say that we have a deflationary emission schedule from Block #1, Every Month, therefore we are deflationary.  And Bitcoin is deflationary, because they halve the reward every 4 years.  And the Default Deflationary reference is to the decreasing supply component, not to the total money supply.  And relatively speaking, BBP compared to Global G5 central bank money supply, we are highly deflationary, in the sense that global dollars are inflating at a 15% rate per year, while our emission schedule is deflating at a rate of 19.5% per year.  So you are arguing since NEM was completely premined up front, its more deflationary.  But technically I could argue that as NEM releases coins into the market with their algorithm, (from the premine cache), that component is inflationary.  

    To be accurate we have to define what constitutes the inflation component: releasing coins in the coinbase, or releasing coins from the algorithm (both), or an expanding total money supply.  The rate of coin release is more relevant than an expanding total money supply on inflation.  

And for the average blue collar person, it IS useful to know that holding Crypto-XYZ relative to G5 is deflationary.  I would say holding Bitcoin relative to G5 is deflationary, but obviously constitutes market risk.  Holding Biblepay relative to G5 is deflationary.  Our deflation argument must define deflation as Deflationary per Block emitted, not Deflationary relative to decreasing total money supply.  (I have a strong reasoning other than this, to back this up, stronger than the textbook definitions, as textbook definitions dont take into account the niches in crypto: In crypto there are also more components involved that are very real:  Lost coins constitute an approx. 20% decrease in total money supply per year, human population increasing at 75MM per year, and Nielsens law - internet use is up by 50% in 3rd world countries per year, among others, etc).

  Besides, people in the real world have no clue how many total dollars in m1 & m2 are actually circulating.  They care about the purchasing power of each dollar.


Your arguments are mostly reasonable and regardless what you've written, calling the Bible Pay as simply deflationary is just incorrect. Bible Pay is not deflationary neither in terms of purchasing power (you cannot assure purchasing value/price level of BiblePay in time) nor in total coin supply in time (at least for many years). I would expect you as a christian to use correct terms. No offense and rather pray for more precision than for the end of discussion.



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.

member
Activity: 98
Merit: 10
I just googled it and I was wondering if it could be that instead since 17.10 is using OpenSSL 1.1?

Quote
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.
member
Activity: 98
Merit: 10
I just googled it and I was wondering if it could be that instead since 17.10 is using OpenSSL 1.1?

Quote
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?
full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
Heres an idea:

With two goals in mind: Spreading the Gospel (IE fulfilling your responsibility as a Christian), and Knowing Jesus (Judgement day: I never knew you):

The above two topics were originally designed to get you thinking, how can we integrate a feature into Biblepay that strengthens peoples faith in these two areas?

One possibility is creating a BiblePay University subdomain, with the ability to create multiple-choice Tests on a theological topic, and the ability to take the tests as a user, with a reward at the end of the test based on your score.  So another words, we have people adapting theological tests into our test format (IE Test question Body, Test question multiple choice answers, Actual answer), publishing the test, and for the user, a reward for taking the test in BBP rewarded from the "P2P" budget (in relationship to how well you did, reasoning that the better you did the more effort you put into the test).   So in effect would be a reverse university, in the sense that we pay You to strengthen your faith from our BBP budget.

We would have to set it up in a way that each answer is shuffled and a nonce is included to make it a unique test per user to prevent replay attacks.

Other ideas are welcome also, if you can think of a novel way that BiblePay will allow geeks to spread the gospel, or move a user closer to knowing that they know Jesus.



Jump to: