Bitcoin Forum
December 16, 2017, 05:42:39 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 [5] 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 »
  Print  
Author Topic: BiblePay - New Coin Launch - Official Thread  (Read 23236 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
bible_pay
Full Member
***
Offline Offline

Activity: 154


View Profile WWW
November 13, 2017, 01:35:30 PM
 #81

@Rob I'm still testing the new version both in testnet and mainnet.

I was wondering if you ever managed to reproduce my issue?
Hi Alex, so the last thing I did was added a patch to check that condition and verified it could mine a block in testnet, and checked in 1058.
Could you please tell me if 1058 has the same problem or something different?  I didnt see any new message after that (that was midnight last night).


As far as reproducing the issue, not exactly.  I was able to confirm the issue was there, because I had it happen, but on my end it only happened twice in the entire 29 meg log, so I havent been able to make it happen quite as easily, which is actually very baffling.  Makes me wonder if its a dependency different causing a math rounding error. 

▄     B I B L E P A Y    ▄     The Cryptocurrency for Christians   ▄      B I B L E P A Y      ▄
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
1513446159
Hero Member
*
Offline Offline

Posts: 1513446159

View Profile Personal Message (Offline)

Ignore
1513446159
Reply with quote  #2

1513446159
Report to moderator
1513446159
Hero Member
*
Offline Offline

Posts: 1513446159

View Profile Personal Message (Offline)

Ignore
1513446159
Reply with quote  #2

1513446159
Report to moderator
1513446159
Hero Member
*
Offline Offline

Posts: 1513446159

View Profile Personal Message (Offline)

Ignore
1513446159
Reply with quote  #2

1513446159
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1513446159
Hero Member
*
Offline Offline

Posts: 1513446159

View Profile Personal Message (Offline)

Ignore
1513446159
Reply with quote  #2

1513446159
Report to moderator
Alex873434
Jr. Member
*
Offline Offline

Activity: 40


View Profile
November 13, 2017, 01:46:30 PM
 #82

@Rob I'm still testing the new version both in testnet and mainnet.

I was wondering if you ever managed to reproduce my issue?
Hi Alex, so the last thing I did was added a patch to check that condition and verified it could mine a block in testnet, and checked in 1058.
Could you please tell me if 1058 has the same problem or something different?  I didnt see any new message after that (that was midnight last night).


Hi Rob, I did post a message this afternoon (for me) but decided to delete it as I wanted to be 100% sure and not waste your time.

--

My nodes on mainnet still sees errors such as this (happened a few seconds ago):

2017-11-13 13:35:06 ERROR: CheckProofOfWork(1): BibleHash does not meet POW level, prevheight 16535.000000 pindexPrev a7ea3485fc32c1b9f9a44ecf1b704f46077c25a76af9a75e299d9878c439eaa0
2017-11-13 13:35:06 ERROR: CheckBlockHeader(): proof of work failed
2017-11-13 13:35:06 Misbehaving: 192.169.156.212:40000 (0 -> 1)
2017-11-13 13:35:06 ERROR: invalid header received 8d11169decf05a59707838c1b9f23310045c817e3ec2eeb549645a3f29144568

I'm still trying to see if I can see one of my updated miners being flagged on mainnet.

Edit: Just saw one of my updated miners being flagged.

--

I also have two nodes on testnet and I saw the exact same message above flagging one node from the other node but only once.

One of my nodes is however having messages such as this, I'm not sure if it's the same issue:

2017-11-13 12:55:33 ERROR: CheckProofOfWork(1): BibleHash does not meet POW level, prevheight 38218.000000 pindexPrev b9835678d35862d1cd982eb2bb83368bf64fa2f0b5accb4dc9f6e74191e7f79a
2017-11-13 12:55:33 ERROR: CheckBlockHeader(): proof of work failed
2017-11-13 12:55:33 ERROR: ProcessNewBlock: AcceptBlock FAILED
2017-11-13 12:55:33 ERROR: ProcessBlockFound -- ProcessNewBlock() failed, block not accepted

I was also wondering if it was normal for my hashrate to be 10k on testnet vs 250k on mainnet.

--

Finally (changing the subject totally), I tried to compile biblepay for Ubuntu 17.10 and I'm getting a compile error:

rpcblockchain.cpp: In function ‘void StartTradingThread()’:
rpcblockchain.cpp:2290:73: error: use of deleted function ‘void boost::cref(const T&&) [with T = int]’
  tradingThreads->create_thread(boost::bind(&TradingThread, boost::cref(0)));

I'm guessing it's a version issue?



seasonw
Sr. Member
****
Offline Offline

Activity: 448


AGw8H3S73qpR6fecRUr5dYUpwvcvMeQfbL


View Profile
November 13, 2017, 01:54:26 PM
 #83

@Rob, I just realized that block explorer - http://biblepay.inspect.network/ stopped update on block 16174... I was checking it two days ago but wallet did not update with latest transfer from pool, then I thought it was delay, then I checked again just now and found that latest block is still 16174 which is two days ago.

Thanks, I saw multiple messages from Coinpimp claiming we did that on purpose or something lol, yeah, Happy_Merchant runs it.  I can PM him and see if he wakes up, will do now, Thanks!


No rush actually, I just wanted to inform about the issue only... Coinpimp posted a lot of non-sense, I did not really read through all his messages, haha~~



 █████  ██      ████████  ██████  ██████  ███    ███ ███    ███ ██    ██ ███    ██ ██ ████████ ██    ██      ██████  ██████  ██ ███    ██
██   ██ ██         ██    ██      ██    ██ ████  ████ ████  ████ ██    ██ ████   ██ ██    ██     ██  ██      ██      ██    ██ ██ ████   ██
███████ ██         ██    ██      ██    ██ ██ ████ ██ ██ ████ ██ ██    ██ ██ ██  ██ ██    ██      ████       ██      ██    ██ ██ ██ ██  ██
██   ██ ██         ██    ██      ██    ██ ██  ██  ██ ██  ██  ██ ██    ██ ██  ██ ██ ██    ██       ██        ██      ██    ██ ██ ██  ██ ██
██   ██ ███████    ██     ██████  ██████  ██      ██ ██      ██  ██████  ██   ████ ██    ██       ██         ██████  ██████  ██ ██   ████

   ▄█████▄▄      ▄▄█▄▄      ▄▄█████▄   
 ▄██████████▄  █████████  ▄██████████▄
█████████████▄ █████████ ▄█████████████
 ████████████  █████████  ████████████
  ▀████████▀  ███████████  ▀████████▀   
 ▄  ▀▀▀▀▀▀   █████████████   ▀▀▀▀▀▀  ▄ 
 ██▄▄▄▄▄▄▄▄████████████████▄▄▄▄▄▄▄▄▄██ 
▄██████████████████ ██████████████████▄
██████████████████   ██████████████████
█████████████████     █████████████████
███████████████         ███████████████
 ████████████             ████████████
 ███████████               ███████████
  █████████▀               ▀█████████ 
   ████████                 ████████   
     █████▀                 ▀█████     
      ▀███                   ███▀       
         █                   █           


██     ██ ███████     ██████  ███████  ██████ ██ ██████  ███████     ████████ ██   ██ ███████     ███████ ██    ██ ████████ ██    ██ ██████  ███████
██     ██ ██          ██   ██ ██      ██      ██ ██   ██ ██             ██    ██   ██ ██          ██      ██    ██    ██    ██    ██ ██   ██ ██     
██  █  ██ █████       ██   ██ █████   ██      ██ ██   ██ █████          ██    ███████ █████       █████   ██    ██    ██    ██    ██ ██████  █████   
██ ███ ██ ██          ██   ██ ██      ██      ██ ██   ██ ██             ██    ██   ██ ██          ██      ██    ██    ██    ██    ██ ██   ██ ██     
 ███ ███  ███████     ██████  ███████  ██████ ██ ██████  ███████        ██    ██   ██ ███████     ██       ██████     ██     ██████  ██   ██ ███████
 ANN  BOUNTY  SONOHUB  eSPORTS  WEBWALLET 
bible_pay
Full Member
***
Offline Offline

Activity: 154


View Profile WWW
November 13, 2017, 02:31:20 PM
 #84


One of my nodes is however having messages such as this, I'm not sure if it's the same issue:

2017-11-13 12:55:33 ERROR: CheckProofOfWork(1): BibleHash does not meet POW level, prevheight 38218.000000 pindexPrev b9835678d35862d1cd982eb2bb83368bf64fa2f0b5accb4dc9f6e74191e7f79a
2017-11-13 12:55:33 ERROR: CheckBlockHeader(): proof of work failed
2017-11-13 12:55:33 ERROR: ProcessNewBlock: AcceptBlock FAILED
2017-11-13 12:55:33 ERROR: ProcessBlockFound -- ProcessNewBlock() failed, block not accepted

I was also wondering if it was normal for my hashrate to be 10k on testnet vs 250k on mainnet.

--

Finally (changing the subject totally), I tried to compile biblepay for Ubuntu 17.10 and I'm getting a compile error:

rpcblockchain.cpp: In function ‘void StartTradingThread()’:
rpcblockchain.cpp:2290:73: error: use of deleted function ‘void boost::cref(const T&&) [with T = int]’
  tradingThreads->create_thread(boost::bind(&TradingThread, boost::cref(0)));

I'm guessing it's a version issue?


My oh my weve got our hands full all of a sudden.  Yes, it looks like all of the checkblockheader errors can be lumped together into the same issue (BibleHash does not meet POW level) for both testnet and mainnet.  Yeah, I see the last night fix did not fix that nuisance.

So let me take a quick attempt at the compilation issue first.  The compilation problem on the ubuntu 17.1 box is due to a new feature for retirement trading.  I just chcked in 1.0.5.8b, could you please see if that compiles on Ubuntu 17.1?

In the mean time, I switched all my linux boxes over to debian, to make it easier to gitian-build biblepay, but Ill provision a new Ubuntu now in order to look at #1.



PS:  I forgot to answer your question about HPS:  Yes, thats normal, f8000 in TestNet is slower than f7000 in mainnet.



▄     B I B L E P A Y    ▄     The Cryptocurrency for Christians   ▄      B I B L E P A Y      ▄
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
Alex873434
Jr. Member
*
Offline Offline

Activity: 40


View Profile
November 13, 2017, 02:42:13 PM
 #85

Tried to compile the new version and this is what I'm getting:

wallet/crypter.cpp: In function ‘bool BibleEncrypt(std::vector<unsigned char>, std::vector<unsigned char>&)’:
wallet/crypter.cpp:226:20: error: aggregate ‘EVP_CIPHER_CTX ctx’ has incomplete type and cannot be defined
     EVP_CIPHER_CTX ctx;
                    ^~~
wallet/crypter.cpp: In function ‘bool BibleDecrypt(const std::vector<unsigned char>&, std::vector<unsigned char>&)’:
wallet/crypter.cpp:244:20: error: aggregate ‘EVP_CIPHER_CTX ctx’ has incomplete type and cannot be defined
     EVP_CIPHER_CTX ctx;

PS: Just saw your reply to the hashrate question. Thanks!
bible_pay
Full Member
***
Offline Offline

Activity: 154


View Profile WWW
November 13, 2017, 02:43:45 PM
 #86

Tried to compile the new version and this is what I'm getting:

wallet/crypter.cpp: In function ‘bool BibleEncrypt(std::vector<unsigned char>, std::vector<unsigned char>&)’:
wallet/crypter.cpp:226:20: error: aggregate ‘EVP_CIPHER_CTX ctx’ has incomplete type and cannot be defined
     EVP_CIPHER_CTX ctx;
                    ^~~
wallet/crypter.cpp: In function ‘bool BibleDecrypt(const std::vector<unsigned char>&, std::vector<unsigned char>&)’:
wallet/crypter.cpp:244:20: error: aggregate ‘EVP_CIPHER_CTX ctx’ has incomplete type and cannot be defined
     EVP_CIPHER_CTX ctx;

Thats something missing on the ubuntu box, try googling that particular error and it should show a dependency missing most likely.

▄     B I B L E P A Y    ▄     The Cryptocurrency for Christians   ▄      B I B L E P A Y      ▄
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
Alex873434
Jr. Member
*
Offline Offline

Activity: 40


View Profile
November 13, 2017, 02:49:26 PM
 #87

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.
kensaii
Member
**
Offline Offline

Activity: 70


View Profile
November 13, 2017, 02:57:08 PM
 #88

Tried to compile the new version and this is what I'm getting:

wallet/crypter.cpp: In function ‘bool BibleEncrypt(std::vector<unsigned char>, std::vector<unsigned char>&)’:
wallet/crypter.cpp:226:20: error: aggregate ‘EVP_CIPHER_CTX ctx’ has incomplete type and cannot be defined
     EVP_CIPHER_CTX ctx;
                    ^~~
wallet/crypter.cpp: In function ‘bool BibleDecrypt(const std::vector<unsigned char>&, std::vector<unsigned char>&)’:
wallet/crypter.cpp:244:20: error: aggregate ‘EVP_CIPHER_CTX ctx’ has incomplete type and cannot be defined
     EVP_CIPHER_CTX ctx;

Thats something missing on the ubuntu box, try googling that particular error and it should show a dependency missing most likely.

Could you post the full list of dependencies for Bible?

bible_pay
Full Member
***
Offline Offline

Activity: 154


View Profile WWW
November 13, 2017, 04:11:01 PM
 #89

Tried to compile the new version and this is what I'm getting:

wallet/crypter.cpp: In function ‘bool BibleEncrypt(std::vector<unsigned char>, std::vector<unsigned char>&)’:
wallet/crypter.cpp:226:20: error: aggregate ‘EVP_CIPHER_CTX ctx’ has incomplete type and cannot be defined
     EVP_CIPHER_CTX ctx;
                    ^~~
wallet/crypter.cpp: In function ‘bool BibleDecrypt(const std::vector<unsigned char>&, std::vector<unsigned char>&)’:
wallet/crypter.cpp:244:20: error: aggregate ‘EVP_CIPHER_CTX ctx’ has incomplete type and cannot be defined
     EVP_CIPHER_CTX ctx;

Thats something missing on the ubuntu box, try googling that particular error and it should show a dependency missing most likely.

Could you post the full list of dependencies for Bible?

They are in the github Building Biblepay documents already.


▄     B I B L E P A Y    ▄     The Cryptocurrency for Christians   ▄      B I B L E P A Y      ▄
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
bible_pay
Full Member
***
Offline Offline

Activity: 154


View Profile WWW
November 13, 2017, 04:12:01 PM
 #90

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.


▄     B I B L E P A Y    ▄     The Cryptocurrency for Christians   ▄      B I B L E P A Y      ▄
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
bible_pay
Full Member
***
Offline Offline

Activity: 154


View Profile WWW
November 13, 2017, 04:22:29 PM
 #91

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 believe its 101k.  You could get away with 101g, h, i, j also.

I think weve just discovered the whole problem.  Its not ubuntu 64, its Open SSL and its relationship to the biblehash it creates.

Alex, I think your other machines are using a certain version of openssl that is producing slightly different biblehashes in some cases.

Can you please try pulling 101k and building on one specific machine and restarting in testnet?  See if that fixes the blockheader bug.

In the mean time, Ill add the OPENSSL Version to the core, and once we know if that fixes it, Ill add enforcement into the version message etc.


▄     B I B L E P A Y    ▄     The Cryptocurrency for Christians   ▄      B I B L E P A Y      ▄
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
bible_pay
Full Member
***
Offline Offline

Activity: 154


View Profile WWW
November 13, 2017, 05:12:05 PM
 #92

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.


▄     B I B L E P A Y    ▄     The Cryptocurrency for Christians   ▄      B I B L E P A Y      ▄
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
coinpimp321
Newbie
*
Offline Offline

Activity: 28


View Profile
November 13, 2017, 05:37:44 PM
 #93

'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





bible_pay
Full Member
***
Offline Offline

Activity: 154


View Profile WWW
November 13, 2017, 05:53:40 PM
 #94

'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

Dont be misguided.  I didnt create BiblePay to get rich.  I created it primarily to be a better alternative to a greed based inefficient system.  POW miners waste heat because they are all solving a single blockhash and clustering blackboxes in greedy rat race.  We require full nodes, providing POSE (proof of service) and help orphans at the same time, and we are more efficient because you cant run the algo on an ASIC.  Once people say "its better over here", then they may also financially benefit over the long term.  The deflationary aspect should bear out to be true over the long term, for each dollar invested for the orphans.  The highest benefit we provide is the pass through to compassion.  If we end up in the top 100, then we will be helping thousands of orphans per month.  That is the True end goal.

You are definitely misguided on the economy.  The central banks print money to fund wars and to get themselves out of hot water, as they have bills due, budgets to pay, and since they have the authority to print as much as they want, they never have to ask the general public if its OK.  We otoh, are confined to a budget and to a deflating reward.  We actually cant print money from thin air.  That means we are part of the solution and not the problem.

Finally I really am a true Christian.  I would never allow anything related to the mark of the beast in the code.

Ill be creating a topic soon on spreading the Gospel, as this community could really make a difference if we can quantify that part of Christianity.

Geeks spreading the gospel through the blockchain.



▄     B I B L E P A Y    ▄     The Cryptocurrency for Christians   ▄      B I B L E P A Y      ▄
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
bible_pay
Full Member
***
Offline Offline

Activity: 154


View Profile WWW
November 13, 2017, 06:40:36 PM
 #95

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.




▄     B I B L E P A Y    ▄     The Cryptocurrency for Christians   ▄      B I B L E P A Y      ▄
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
Alex873434
Jr. Member
*
Offline Offline

Activity: 40


View Profile
November 13, 2017, 08:52:54 PM
 #96

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?
Alex873434
Jr. Member
*
Offline Offline

Activity: 40


View Profile
November 13, 2017, 10:28:56 PM
 #97

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.
bible_pay
Full Member
***
Offline Offline

Activity: 154


View Profile WWW
November 13, 2017, 10:50:57 PM
 #98

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.


▄     B I B L E P A Y    ▄     The Cryptocurrency for Christians   ▄      B I B L E P A Y      ▄
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
bible_pay
Full Member
***
Offline Offline

Activity: 154


View Profile WWW
November 13, 2017, 11:02:32 PM
 #99

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



▄     B I B L E P A Y    ▄     The Cryptocurrency for Christians   ▄      B I B L E P A Y      ▄
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
Alex873434
Jr. Member
*
Offline Offline

Activity: 40


View Profile
November 13, 2017, 11:07:12 PM
 #100

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?
Pages: « 1 2 3 4 [5] 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!