I switched to laptop mining... changed ryzen 7 with 3,7all core to pentium n3530(atom). HPS on pentium better but HPS2 has half of ryzen... pentium best has tdp 7,5W, ryzen around 160W...

by me nobody knows how mining working on pool HAHAHA

my 2core HPS1=26352.78   HPS2=31110.56   71 shares
my 4core HPS1=33680.53   HPS2=29021.59   66 shares
my 6core HPS1=63561.04   HPS2=31441.99   73 shares

ryzen 8core/16SMT HPS1=15228.37   HPS2=17555.01   40 shares  


very weird results ... when i jumped to minining with my 2 X CPU  10cores/20HT i got HPS1=320000   but HPS2= only 36000


where is bug?  nobody knows = i tried on ubuntu 16.04 with all ranges of cpuproclimit


2xxeon 2630v4 = 20cores/40HT must be got HPS2 over 200 000  but got only 36000?  ??

MY CONCLUSION= best results got with old shit 2core for 40€

MISHMASH MINING COIN

Well said. I'm not taking anyone's side, but this seems reasonable.

My test in 1 hour ryzen 1500x 2 thread in pool  15 biblepay.

I'm on board with 5% going to the dev and others for supporting the coin. If you spend as much time as something like this requires then you should get paid for it.

Ok I forgot that was the primary testnet thread.  Have reposted to there.

On fair use, it's unfortunately a pretty complex thing.  I used to work in the media, so I do know a bit of what I'm talking about here.  The issue would be at first, when the coin is small, there wouldn't be any problems.  Even if copyright / fair use was violated, it wouldn't be worth the time for a company to chase it down.  This would likely lead to bad habits becoming ingrained as it pertains to copyright and fair use.

The risk is lets say I word-for-word copy a news article today.  It becomes part of the block chain.  Five years from now, the DAO is bringing in $250,000 a year.  Some lawyer looks at our block chain, has the proof we violated copyright and sues the DAO (since they cannot identify the writer with ease, and ultimately, you sue who has the money).  They would likely win.  To avoid this, you'd have to have all the articles vetted.  This becomes a logistical nightmare.

Worse, if something untrue was reported, and it was done in a malicious way, the DAO could get sued for liable.  Since there would be no way to retract the article (immutable) the damages could be significant and ongoing.

The ultimate issue becomes, the block chain is immutable.  If something gets posted to a website, it can be changed, or deleted.  If the article itself is the block chain, there is no easy way to fix errors.

I don't think its crashing, but every time there is a new round the share number will reset to zero.

Hmm, just checked the testnet thread for BlockChain news and dont see any posts from you.
Could you post it in that thread?

http://forum.biblepay.org/index.php?topic=14.msg91#new


This forum is only for new users coming in from dash and bitcoin. 

The official forum is the one that handles all testnet testing now and will be equipped to handle the slack expansion.  We are going to need 10-20 topics.

The reason the testnet chain was restarted is because I needed 1 minute blocks for testing sanctuaries and that is completely unrelated to blockchain news.  Im trying to run an end-to-end sanctuary test before releasing the wiki with instructions for testing sanctuaries. 

You know I love this coin, but I reported in testnet thread two instances of when I submitted news articles.  Couldn't ever get my miner to sync after that and low and behold the next day the testnet blockchain was restarted.  Just now tried to submit an article and it crashed core (log below).  Resubmitted it and it worked and is ID cd5b3dd24423241290b25e1f72563689eea2e58755f122504dca3cb299282a9c.  Can read it but once again, I'm now out of sync with the network.  I'll let it run all day and see if it resyncs or not.

2017-10-02 12:25:53 generated 20000.00
2017-10-02 12:25:53 ERROR: ProcessBlockFound -- generated block is stale
2017-10-02 14:56:43  Original OldImg

2017-10-02 14:57:11 ADDING BLOCKCHAIN ARTICLE
 Creating TXID #0.000000, ChunkLen 920.000000, with Chunk NEWSLas Vegas, NV Shooting 2017-10-02

Breaking News October 2, 2017

Over 50 people killed and at least 400 wounded in a mass shooting in Las Vegas, Nevada.  Reports are still incomplete and the story will unfold for days yet to come.  But was is known is a gunman using multiple rifles shot thousands of rounds into a crowd gathered for a Country Music concert.  The President of the United States of America is set to speak on live television about the attask.  if the numbers hold true, it would become the deadliest mass shooting i
2017-10-02 14:57:11
 Creating TXID #920.000000, ChunkLen 33.000000, with Chunk n U.S. history.

2017-10-02 14:57:11 GUI: Qt has caught an exception thrown from an event handler. Throwing
exceptions from an event handler is not supported in Qt. You must
reimplement QApplication::notify() and catch all exceptions there.

"Bible Pay News has crashed the testnet blockchain"?  LOL, No biblepay news isnt crashing.  I dont even think its being tested.  If anyone has a crash report, we need an explanation of how you reproduce the crash and the part of the log with the crash (not a paste of the whole log).

Here is the forum for that thread:
http://forum.biblepay.org/index.php?topic=14.msg91#new

Please test blockchain news, and post any issues there. 
Yes, I still want blockchain news to be part of BiblePay, and I asked a week ago for someone to start checking on Best Practices for paraphrasing current news articles and copyright laws, and havent heard anything (just strong opinions as to why we shouldnt have it), but again, let me make a couple statements on my opinion:
- I would not have considered blockchain news if I thought it would be consuming too much size (the articles only consume 1k per page, thats miniscule)
- I would not have created a testnet thread if I thought it was a dumb idea
- I believe "old news" is still better than no-news in our blockchain
- Its immutability is fine in this case, as its a use-case for the blockchain
- We charge a storage fee to insert an article anyway, so thats a use case for burned coins, and benefits orphans
- There is only so much creativity that can be done by one person per week- so blockchain news is more of a creative effort, its not something that spams the chain (as it takes energy and effort to create an article).  Take a look at the orphan letters- we have only written half of the required letters and thats on the web- because they take effort to write.

Regarding 7 minute blocks, I deliberately set up wide block spacing with the chain to save chain size and increase loading speed.  I am against 1 min blocks.

We will have instandsend after the sanctuaries go live, so we really dont have any downsides after they go live.

I want jus say that on my ryzen hps is buged cuz bigger hash i get when i set lower genproclimits: 25k on 4 and 15k on 18.
But hps2 from pool seems to be connected to genproclimit. When i rise genproclimit my hps2 is rosing too, and it's logical and ok. The only problem is that hps have strange values compared of settings of genproclimit.

That's the thing, the daemon doesn't crash but the mining slows down considerably before regaining again.
Debug file only has something like this "2017-10-01 02:10:17".

This is what I see in the getmininginfo when it slows down. proc limit is 32. Shares on pool ~65


and this is what it shows when it almost stops. Shares ~7

this when it goes up. All in 5 mins. Shares ~40

Paste here the part of your debug.log where the crash happens.

Regardless of what the percentage is I prefer the previous suggestion several weeks ago of a 15% "fund", with by-laws saying that a minimum of 10% goes to charity and the remainder can go to development (IT) or marketing or additional charity if the previous two items aren't needed.

Before the Masternode percentage gets set in stone, the two big things to determine are Masternode cost and how well it beta tests, and if December 25 is a reasonable target still.  Then I would also include a provision in the Masternodes that grants them testcoins on the same basis.  That way new Masternode features can be tested for a few months on testnet.  Speaking of which, when are you expecting to start testing Masternodes? 

Biblepay News has crashed the testnet both times I've tried to use it, causing us to restart the testnet blockchain.  I like the utilization of the blockchain for other uses, but still don't know if news as such a temporal topic needs such immutable status.

But above all else...THANK YOU to the Dev for your tireless work with this labor of love.

So how many exchanges is Bible Coin listed on now, just wondering if this is something I need to look into.

This is something I'm trying to get an answer for with regards to the pool but couldn't.
All of my miners(workers) start on the pool at 0 shares, gradually increasing to reach their cap(say 60 shares) on the leaderboard before pretty much crashing to a single digit and then they go back to the upper limit again. This has been happening through multiple versions of biblepay and both the pools. I've reinstalled and retried configurations multiple times.

I'm not able to diagnose this, I see many other miners holding a constant share rate so I'm not sure what's wrong with mine.
@bible_pay, @inblue can you shed some light on this? Also, what's RMC and CFW?

OS: Ubuntu 16.04 and 14.04
Processor: Xeon
Proc tried: 2-40
Versions tried: 1.0.3.9 - 1.0.4.5

Totally agree. The dev team should be fairly compensated for continued growth and support for the coin.
One thing I'm curious about is the current block time and emittance, it's very sporadic and volatile leading to the masternodes. Would there even be enough supply for everyone to run the DAO instead a very few on the richlist?

@bible_pay what's your opinion on current emittance, equihash and other algos handle it pretty straightforward with constant block time and retargeted difficulties.
Also I noticed that you are experimenting with a 1 minute block time in testnet in the 1.0.4.4 commit, is that something you think will help?
Personally that looks good to me, lower blocktime and appropriate rewards with same daily emittance can be interesting.
How much would that affect the blocksize if that's implemented?

Ill check more into sliding or increasing masternode share idea, interesting, but one thing I wanted to mention on the above post:
The IT budget of 5% (its not 2.5%), is to keep the entire coin growing on the technology side.  Its not a budget sent to me as a reward, Im just one person on the team, its a budget that is voted on by sanctuaries for total IT expenses, such as developer payroll.

To lower it to 2.5% is a pretty hilarious idea, so no, I think it needs to be the full 5% as thats extremely slim already, and imo its sort of what is creating the whole ecosytem after all this is a technological investment, not a brick and mortar location.  Our particular IT dept is going to be busier than the average, with support for interfaces for orphans and a custom PobH pool, for one.  Then there is another huge unerestimation with IT:  Whenever bitcoin pushes a commit, or if a security patch is released for OpenSSL or any dependency, someone from the team has to spend 40 hours fixing it, testing it and deploying it- if they dont, the coin can die.  So it needs to be a healthy department.  

EDIT:  I catch your drift that we should have a PR fund.  I think what we can do is take our total 15% and aim for 10% through proposals, and between the superblock cycles we will throw in some campaigns and switch between charity/IT/PR, and make it work.  We wont always have a full IT full budget, etc.

Again, HashPerSec is what the client reports to the pool based on actual measured hashespersecond from the client side over time across all threads, and the pool cant pay off of that because it doesnt prove you actually solved 'hard' work (work with low hash requirements).

HashPerSec2 is what the pool calculates your rig at, based on actual shares solved in the current round.


Yes, we could remove hashespersecond eventually!  But the litmus test on that is:  Going 90 days straight without any code changes, IE stamping the pool as "stable".  Eventually yes, we can do that and simplify things.  We could move hashespersec to your user record for debugging also. 

+++++