BiblePay - New Coin Launch - Official Thread

[noloco]

The both of the web pools actually share the same database server; so you are technically not allowed to create a user on pool2 with the same username.

Just go ahead and use it, and tell me if you see anyting wrong with your HPS2.

Everything has been fine for a solid week now, looking good.

Fixed, It seems the problem was on browser side with different cached credentials for each pool.

Version 139

"hashps": 94984.67855903519,
HPS2 1/3 of HPS with genproclimit=12 on xeon.
Close to 1:1 on non-xeon processor.

Compiled latest version (wallet_fullversion": "1.0.4.0") after xeon fix, same results or worse HPS2 after several minutes.

[1715367438]

1715367438

[1715367438]

1715367438

[1715367438]

1715367438

[emdes]

loot loot_x4 14577.78 15988.83 37 9/24/2017 8:49:29 PM <- Ryzen 1700x 1.0.4.0 64bit after 2 hours+ mining (take a look at the CPU load)

Just bumped the genproclimit to 32, now im getting 32-35% CPU load again (and probably 20-25k HPS2) just check the leaderboard in a few hours.

YES, I did some tests with lower genproclimits too, but the hashrate/shares/CPU load drops by 30-40% when using anything lower than 32.

Waiting for Oliwer's genproclimit 11 test on the 32bit wallet  

EDIT: 30 minutes after switching back to genproclimit 32-> HPS1: 24189.32 HPS2: 29913.39

[okane818]

Hello Guys,

This BiblePay is good for everyone helping each other.

We pray to have this more exchanger everywhere.
Must be added in Yobit, Polo, Coinexchange, Nova, etc.

Best regards

Okane Satoshi.

[bible_pay]

I've got plenty of BBP on the Testnet.  I'll start working on a few things in the next couple days.  One issue to consider on new is copyright.  So for now, I would suggest self contained help articles and the like should be the goal, with a bit of time to determine what exactly "fair use" can be held.  Also, since the block chain is immutable, some sort of vetting will be critical.

Sorry to be so quiet the last few days, been a rough week here.

Yeah, go ahead and find out how copyright will work, Im sure there must be a way to legally create news articles that are picked up by multiple stations.  For one we would encourage paraphrasing and original non copyrighted images.

As far as immutable, we will eventually have upvote/downvote, and we charge a fee for publishing.  If it ever becomes a problem we could potentially make an escrow requirement, and "spend" the escrow if someone posts something very negative (like walls of swear words as an article).

Hi dev and comunity, reading about this upvote/downvote feature got me thinking about the letter writing to orphans. Maybe we should prioritize integrating the process of letter writing and approving in the wallet itself? Currently it is only being done in the pool, and I think that people just never go to that section and are not even aware of this feature.
I am new to the project, so I haven't went through the code, but maybe writing letters could be implemented as a special kind of "news article" that will also go in the block chain and be voted on in the wallet itself (and then automatically sent if approved).

Even thou i like the new news article feature, frankly I think that we are kind of behind with the letter writing to the orphans we sponsor and we should probably think about how to make it easier for an average user to do it. Here, I am just giving and idea how we may reuse this new feature for this purpose. After all we are a charitable community in the first place.

All the best to fellow biblers.

Thanks for the ideas!  But the letters to the orphans dont belong in the chain, as they are temporary and potentially private in the future, and changing in format after sanctuaries go live, and require specific API integration to deliver, and require dynamic booleans depending on when they are sent to compassion, etc.

However the news is permanent and useful to be part of the chain.

(In addition, it takes hundreds of hours to code a feature in the QT wallet, as compared to tens of hours on the web site, so we have to architect each IT solution with respect to how many resources will be consumed vs the ROI).

[okane818]

I was the first mining in BiblePay, I got 200000 h/s and I saw in my debug, I saw we are only 2 miners, when after the update of the wallet and pool.biblepay it is big diff happen, It was 0.02 the diff, so fast, I didn't know, I though no changes, when I updating wallet, it gives me 14 kh/s - 17kh/s per 7 core I used. I have to units running.

Do not stop mining on CPU there will be changes to degrees hashrate.

Good luck all and regards


Okane Satoshi

[oliwer21]

loot loot_x4 14577.78 15988.83 37 9/24/2017 8:49:29 PM <- Ryzen 1700x 1.0.4.0 64bit after 2 hours+ mining (take a look at the CPU load)

Just bumped the genproclimit to 32, now im getting 32-35% CPU load again (and probably 20-25k HPS2) just check the leaderboard in a few hours.

YES, I did some tests with lower genproclimits too, but the hashrate/shares/CPU load drops by 30-40% when using anything lower than 32.

Waiting for Oliwer's genproclimit 11 test on the 32bit wallet  

EDIT: 30 minutes after switching back to genproclimit 32-> HPS1: 24189.32 HPS2: 29913.39

On 1.0.3.8 32bit genproclimit 11 i got HPS 20k and HPS2 17-18k cpu usage around 35-40%
Now testing 1.0.4.0 on genproclimit 11...

[emdes]

loot loot_x4 14577.78 15988.83 37 9/24/2017 8:49:29 PM <- Ryzen 1700x 1.0.4.0 64bit after 2 hours+ mining (take a look at the CPU load)

Just bumped the genproclimit to 32, now im getting 32-35% CPU load again (and probably 20-25k HPS2) just check the leaderboard in a few hours.

YES, I did some tests with lower genproclimits too, but the hashrate/shares/CPU load drops by 30-40% when using anything lower than 32.

Waiting for Oliwer's genproclimit 11 test on the 32bit wallet  

EDIT: 30 minutes after switching back to genproclimit 32-> HPS1: 24189.32 HPS2: 29913.39

On 1.0.3.8 32bit genproclimit 11 i got HPS 20k and HPS2 17-18k cpu usage around 35-40%
Now testing 1.0.4.0 on genproclimit 11...

1.0.4.0 64bit with genproclimit 32 - HPS 24k and HPS2 25k-ish with CPU load 32-37%. My HPS2 drops to 15k with SMT disabled btw. Did you disable it?

[sharpshot]

Hello Guys,

This BiblePay is good for everyone helping each other.

We pray to have this more exchanger everywhere.
Must be added in Yobit, Polo, Coinexchange, Nova, etc.

Best regards

Okane Satoshi.

I agree, would be great to see BiblePay on Bittrex.  Probably takes time to get on the exchanges but it adds credibility, so hopefully will happen soon.

[oliwer21]

loot loot_x4 14577.78 15988.83 37 9/24/2017 8:49:29 PM <- Ryzen 1700x 1.0.4.0 64bit after 2 hours+ mining (take a look at the CPU load)

Just bumped the genproclimit to 32, now im getting 32-35% CPU load again (and probably 20-25k HPS2) just check the leaderboard in a few hours.

YES, I did some tests with lower genproclimits too, but the hashrate/shares/CPU load drops by 30-40% when using anything lower than 32.

Waiting for Oliwer's genproclimit 11 test on the 32bit wallet  

EDIT: 30 minutes after switching back to genproclimit 32-> HPS1: 24189.32 HPS2: 29913.39

On 1.0.3.8 32bit genproclimit 11 i got HPS 20k and HPS2 17-18k cpu usage around 35-40%
Now testing 1.0.4.0 on genproclimit 11...

1.0.4.0 64bit with genproclimit 32 - HPS 24k and HPS2 25k-ish with CPU load 32-37%. My HPS2 drops to 15k with SMT disabled btw. Did you disable it?

Nope... all tests with smt on.

[bible_pay]

loot loot_x4 14577.78 15988.83 37 9/24/2017 8:49:29 PM <- Ryzen 1700x 1.0.4.0 64bit after 2 hours+ mining (take a look at the CPU load)

Just bumped the genproclimit to 32, now im getting 32-35% CPU load again (and probably 20-25k HPS2) just check the leaderboard in a few hours.

YES, I did some tests with lower genproclimits too, but the hashrate/shares/CPU load drops by 30-40% when using anything lower than 32.

Waiting for Oliwer's genproclimit 11 test on the 32bit wallet  

EDIT: 30 minutes after switching back to genproclimit 32-> HPS1: 24189.32 HPS2: 29913.39

On 1.0.3.8 32bit genproclimit 11 i got HPS 20k and HPS2 17-18k cpu usage around 35-40%
Now testing 1.0.4.0 on genproclimit 11...

1.0.4.0 64bit with genproclimit 32 - HPS 24k and HPS2 25k-ish with CPU load 32-37%. My HPS2 drops to 15k with SMT disabled btw. Did you disable it?

Thanks for the testing.  So in a nutshell you are saying the Ryzen will only use 35% of the processor no matter what proclimit is set, and both the 32 bit and 64 bit builds are essentially the same.

Ok, that sounds like a different problem than I had on the windows xeon 2 proc.  The xeon on 64 bit only used 50% of the proc, but on 32 bit I got it to use 90% of the proc and on the pool it solves roughly what the linux equiv box solves.

Additionally, non use of resources is a different problem than was discussed after f7000 went live.  The problem we looked at before was the hash rate drop on the servers compared to the laptops and the shares solved per HPS- while assuming the whole processor was being utilized.  This is more of an issue where the processor is not being utilized.

I think I will have time to take a look at making a test miner that holds a reference to two KJV bibles.

In the mean time, the other thing that no one has reported is what happens when you run two copies of BBP against two different datadirectories on the Ryzen?  If anyone can test that out and report back that would be immensely helpful also.  I think inblue was going to try that on a server at one point.

[bible_pay]

News - coming soon:
http://wiki.biblepay.org/News

[616westwarmoth]

While I really like the idea behind news on the block chain, I would ask you reconsider and maybe instead work it into the wallet.  For the same reason we don't want Orphan Letter's in the chain four years from now, we won't want most news more than 10 days from now.  Utilizing the block chain for data of temporal interest just doesn't make a lot of sense to me.  Technical documents and the like, yes, but what modestly newsworthy event happened, not so much.

That did get me thinking, if there might be a way to tweak the wallet/core so that it would have a few fields (much like the prayer request field) that would be alterable.

One would be a Pool Indicator.  Basically a text indication of if you were solo or pool mining, and ideally what pool you were on if mining.

Second would be a Pool Message.  That would enable the pool to tell users this pool will be making Core 1.0.x.x mandatory in "y" days, or that the fee structure is changing or you need to write a letter to avoid a fee.  That sort of thing.

Third would be a Coin Message.  That would enable communication to the user base without having to rely on the forums.  Things like, the newest version is 1.0.x.x, upgrade soon.

[crypto_patriot]

I've got plenty of BBP on the Testnet.  I'll start working on a few things in the next couple days.  One issue to consider on new is copyright.  So for now, I would suggest self contained help articles and the like should be the goal, with a bit of time to determine what exactly "fair use" can be held.  Also, since the block chain is immutable, some sort of vetting will be critical.

Sorry to be so quiet the last few days, been a rough week here.

This is quite an interesting and innovative use of blockchain, very old school (biblical) mixed with new school (blockchain). I'll check it out...

Regards,

c_p

[bible_pay]

While I really like the idea behind news on the block chain, I would ask you reconsider and maybe instead work it into the wallet.  For the same reason we don't want Orphan Letter's in the chain four years from now, we won't want most news more than 10 days from now.  Utilizing the block chain for data of temporal interest just doesn't make a lot of sense to me.  Technical documents and the like, yes, but what modestly newsworthy event happened, not so much.

That did get me thinking, if there might be a way to tweak the wallet/core so that it would have a few fields (much like the prayer request field) that would be alterable.

One would be a Pool Indicator.  Basically a text indication of if you were solo or pool mining, and ideally what pool you were on if mining.

Second would be a Pool Message.  That would enable the pool to tell users this pool will be making Core 1.0.x.x mandatory in "y" days, or that the fee structure is changing or you need to write a letter to avoid a fee.  That sort of thing.

Third would be a Coin Message.  That would enable communication to the user base without having to rely on the forums.  Things like, the newest version is 1.0.x.x, upgrade soon.

I think blockchain news, regardless of how old it is, is quite an awesome idea, one that adds value to BiblePay. 

Anyone who opposes the idea is more than welcome create a sanctuary vote with a full proposal on either enhancing the feature or changing the feature or even removing the feature.  Thats the beauty of sanctuaries, you will have an equal amount of weight to voice your opinion among the rest of the community.

As far as more pie in the sky features, Ill see what I can do to get this slack group jump started so you will have someone to address these issues with. 

[calxibe]

While I really like the idea behind news on the block chain, I would ask you reconsider and maybe instead work it into the wallet.  For the same reason we don't want Orphan Letter's in the chain four years from now, we won't want most news more than 10 days from now.  Utilizing the block chain for data of temporal interest just doesn't make a lot of sense to me.  Technical documents and the like, yes, but what modestly newsworthy event happened, not so much.

That did get me thinking, if there might be a way to tweak the wallet/core so that it would have a few fields (much like the prayer request field) that would be alterable.

One would be a Pool Indicator.  Basically a text indication of if you were solo or pool mining, and ideally what pool you were on if mining.

Second would be a Pool Message.  That would enable the pool to tell users this pool will be making Core 1.0.x.x mandatory in "y" days, or that the fee structure is changing or you need to write a letter to avoid a fee.  That sort of thing.

Third would be a Coin Message.  That would enable communication to the user base without having to rely on the forums.  Things like, the newest version is 1.0.x.x, upgrade soon.

I think blockchain news, regardless of how old it is, is quite an awesome idea, one that adds value to BiblePay. 

Anyone who opposes the idea is more than welcome create a sanctuary vote with a full proposal on either enhancing the feature or changing the feature or even removing the feature.  Thats the beauty of sanctuaries, you will have an equal amount of weight to voice your opinion among the rest of the community.

As far as more pie in the sky features, Ill see what I can do to get this slack group jump started so you will have someone to address these issues with. 

Just create a Telegram Group, it's done in 10seconds and it's free.

[616westwarmoth]

While I really like the idea behind news on the block chain, I would ask you reconsider and maybe instead work it into the wallet.  For the same reason we don't want Orphan Letter's in the chain four years from now, we won't want most news more than 10 days from now.  Utilizing the block chain for data of temporal interest just doesn't make a lot of sense to me.  Technical documents and the like, yes, but what modestly newsworthy event happened, not so much.

That did get me thinking, if there might be a way to tweak the wallet/core so that it would have a few fields (much like the prayer request field) that would be alterable.

One would be a Pool Indicator.  Basically a text indication of if you were solo or pool mining, and ideally what pool you were on if mining.

Second would be a Pool Message.  That would enable the pool to tell users this pool will be making Core 1.0.x.x mandatory in "y" days, or that the fee structure is changing or you need to write a letter to avoid a fee.  That sort of thing.

Third would be a Coin Message.  That would enable communication to the user base without having to rely on the forums.  Things like, the newest version is 1.0.x.x, upgrade soon.

I think blockchain news, regardless of how old it is, is quite an awesome idea, one that adds value to BiblePay. 

Anyone who opposes the idea is more than welcome create a sanctuary vote with a full proposal on either enhancing the feature or changing the feature or even removing the feature.  Thats the beauty of sanctuaries, you will have an equal amount of weight to voice your opinion among the rest of the community.

As far as more pie in the sky features, Ill see what I can do to get this slack group jump started so you will have someone to address these issues with. 

The idea is above and beyond awesome.  It's just as the news climate changes, you risk a lot of wasted space on the block chain that is basically storing news no one will care about in 4 weeks, or conversely, if it IS so newsworthy as to be valuable indefinitely, then it will be omnipresent on the web.

Instead, think about this.  Right now the KJV in English is part of the overall coin.  What if the block chain stored not only technical documents but also other public domain versions of the Bible in multiple languages.  Then, by merely downloading the block chain, a person could reach out to almost any nationality, group or language because they'd have multiple versions of the Bible in nearly every conceivable language.  While it's not quite as glamorous as "live news', the value is far more significant in an immutable block chain.

Blockchain news can still exist (and would make more sense to exist) on the main pool, accessible through a function in the Core.  One compromise would be that maybe the headlines would be stored on the block chain and the body would be on the web.  Because the sad reality is if the pool dies (and by pool I really mean more the Core functions that are in the current pool, such as Orphan reports et al.), most likely the coin dies, so losing the news off the web wouldn't be significantly different than losing it because the coin died.

[oliwer21]

Thanks for the testing.  So in a nutshell you are saying the Ryzen will only use 35% of the processor no matter what proclimit is set, and both the 32 bit and 64 bit builds are essentially the same.

Ok, that sounds like a different problem than I had on the windows xeon 2 proc.  The xeon on 64 bit only used 50% of the proc, but on 32 bit I got it to use 90% of the proc and on the pool it solves roughly what the linux equiv box solves.

Additionally, non use of resources is a different problem than was discussed after f7000 went live.  The problem we looked at before was the hash rate drop on the servers compared to the laptops and the shares solved per HPS- while assuming the whole processor was being utilized.  This is more of an issue where the processor is not being utilized.

I think I will have time to take a look at making a test miner that holds a reference to two KJV bibles.

In the mean time, the other thing that no one has reported is what happens when you run two copies of BBP against two different datadirectories on the Ryzen?  If anyone can test that out and report back that would be immensely helpful also.  I think inblue was going to try that on a server at one point.

Hmmm... same cpu as emdes and win10. Wallet 1.0.4.0 64bit
On 16 genproclimit i get 100% usage and pc reacts like he is under heavy load... but hps2 is round 19k...
I have problem with 35 cpu usage limit but not on this  version. It's a random behaviour on one walllet i got on other not. I think It's connected to setting of genproclimit. If genproc reacys like 1 is 1 thread i dont have limit... but if on 16 i got 45% so you must like emdes said 32 to get hash2 above 20k
And still get best hps on 6 genproclimit(in wallet) but hps2 is 9k.
If i rise genproclimit hps will drop and hps2 will be bigger. But my optimal is 11 genproclimit. After that hps2 is droping again... like now on 16 i got 19k

[Shoko943]

I find very interesting the idea of some sort of blockchain "time capsule" where in the future people could look back at the state of the world at one point in time.

Having said that, I don't know what the technical implications would be (such as the impact on the size of the chain, etc) and more importantly, if it still really adheres to the original vision and purpose of the coin (as it would probably become a main function and use a lot of resources by becoming part of the blockchain?).

I think the strength and differentiation of this coin right now is in its vision, target and just the fact that we're just trying to do something that could really improve the lives of a lot of people. We could really build some sort of caritative platform and focus on having a strong community around it.

I think I would really be more interested in developing the website (working on the separation of the pool and the other functions), letter functions/things around the children we're helping (adding photos, being able to send personal letters, improving the interface, etc), the in-wallet prayer requests, the overall appearance of the wallet, governance of our DAO, etc.

Now, I know it must be really exciting to program that news idea and as the dev said, it could just be implemented now and the sanctuaries could decide on its future later on.

[Ryan Dugan]

Oh man !! I really like this coin !! I just think it is legit. Nice website so well put together. I can see your purpose is just I totally am in love with the whole CPU only algo and it is a new algo that is awesome well done !! Can't wait to get mining. Great time to mine it is still new and the volume and price is low. Good job.

[bible_pay]

Thanks for the testing.  So in a nutshell you are saying the Ryzen will only use 35% of the processor no matter what proclimit is set, and both the 32 bit and 64 bit builds are essentially the same.

Ok, that sounds like a different problem than I had on the windows xeon 2 proc.  The xeon on 64 bit only used 50% of the proc, but on 32 bit I got it to use 90% of the proc and on the pool it solves roughly what the linux equiv box solves.

Additionally, non use of resources is a different problem than was discussed after f7000 went live.  The problem we looked at before was the hash rate drop on the servers compared to the laptops and the shares solved per HPS- while assuming the whole processor was being utilized.  This is more of an issue where the processor is not being utilized.

I think I will have time to take a look at making a test miner that holds a reference to two KJV bibles.

In the mean time, the other thing that no one has reported is what happens when you run two copies of BBP against two different datadirectories on the Ryzen?  If anyone can test that out and report back that would be immensely helpful also.  I think inblue was going to try that on a server at one point.

Hmmm... same cpu as emdes and win10. Wallet 1.0.4.0 64bit
On 16 genproclimit i get 100% usage and pc reacts like he is under heavy load... but hps2 is round 19k...
I have problem with 35 cpu usage limit but not on this  version. It's a random behaviour on one walllet i got on other not. I think It's connected to setting of genproclimit. If genproc reacys like 1 is 1 thread i dont have limit... but if on 16 i got 45% so you must like emdes said 32 to get hash2 above 20k
And still get best hps on 6 genproclimit(in wallet) but hps2 is 9k.
If i rise genproclimit hps will drop and hps2 will be bigger. But my optimal is 11 genproclimit. After that hps2 is droping again... like now on 16 i got 19k

I'm forking the bible miner now, testing hash speed with Dual KJV bibles in memory.