Messages

1771

TestNet Discussion Archive / Re: BIBLEPAY - RANDOMX INTEGRATION

« on: February 24, 2020, 09:55:23 AM »

Monero is really big and so far as i know Bbp is the only coin that has this feature, being able to dual mine with xmr..
Although in testnet, but for sure it seems like a superb idea, when i saw it posted in reddit i was like finally, this is groundbreaking..

Aswell as that Bbp is not just another blockchain with the same features, what i feel is puts Bbp in another bracket is the charity aspect of it.

Christians or not christians people will jump aboard, we could do a post on lets say reddit/moneromining   and so forth to get some more people when we are getting closer to launch.

Aswell as you did the mining altcoins section i saw.  Intresting times ahead indeed.

And you know I'd almost like to say we may be the first bitcoin fork with randomx, because you know Monero is a Bytecoin branch.
So this is very unique in that we might have something novel here.  (Whats nice about the bitcoin branch is QT, imho.  QT empowers the user with the transactionlist and coin control tab).  And of course we have the GSCs - so in the future large companies can make scheduled payments through the wallet  - or use governance.

I've also been thinking lately of something that I feel God wants in the ecosystem:  A Christian dashboard that makes us a useful tool for Christians - for our next website.
I was thinking one problem I have when I pray for people is sort of the CRM problem - you need to remember where they are in their walk etc, so we could have a dashboard that lets you manage your Christian relationships (IE John is agnostic, a summary, last contact with him, what we shared last, etc).  Something that makes Christians realize BiblePay is a useful CRM type tool.  I already realize we need a better prayer blog with more of an interactive feel.

Im going to recreate our roadmap and try to capture a new updated vision now. 

1772

TestNet Discussion Archive / Re: BIBLEPAY - RANDOMX INTEGRATION

« on: February 23, 2020, 12:13:33 PM »

In the NOMP rx test getting started section, under example  you could add lets say.


to add .your_worker_name after monero adress for per cpu information.

Perhaps its self explanable but its never wrong to make things easy for people that are new to this  kind of stuff.

Yes, good idea, I will post when its ready.

1773

TestNet Discussion Archive / Re: BIBLEPAY - RANDOMX INTEGRATION

« on: February 21, 2020, 07:43:14 PM »

Thanks a lot!
So trying to reproduce the 'latency' display, Im running 5.6.1 for windows:  I can see the Diff, (solved diff) then the latency.

For XMR I see 121 ms in parentheses and for BBP 120 ms in parentheses.

EDIT: OK - I see what you mean on XMR-Charity, yes, something is wrong in there, I will look at this!

The latency is fixed for the next release for XMR-Charity.  Thanks.

1774

TestNet Discussion Archive / Re: BIBLEPAY - RANDOMX INTEGRATION

« on: February 21, 2020, 06:40:15 PM »

Thank you.

1. Firstly as you realized that I have not been able to recreate my sancs as somehow none of wallets were able to sync past 28010 and those that did at the correct hash as you published were empty.

2. Hence I would appreciate it if you could kindly send sufficent tBBP to be able to recreate the number of sancs that you would require me to setup in testnet. Address: yfAMxhGyQUXSAaPeV7d7YfhmQnY9o6utwA. Thank you.

3, I have been dual mining XMR + BBP at the moment (without synced BBP wallets). This innovative strategy is great, I really like the pace of innovation at BBP, though it can be challenging to keep up at times! I like the idea but have no idea how it will affect the long term economics. One needs to calculate the optimal ABN such that it manages to sustain the price of BBP assuming a large percentage of new XMR+BBP miners liquidate their BBP.

Thank you.

On #1, let me see if you got past 28010 with the erasechain=1 and 1.5.0.3?

On #2, do you still need some more after Earlz's?

On #3,  Yes, thanks for the compliment and lets talk about the long term ramifications.  Although, I cannot say this with certainty, the good news is our DSS (decision support study) of the cryptoeconomic model that we ran a couple months ago did shed what I believe to be a little more light on the subject (as compared to what I knew before running it).  So, I stress, I cannot predict the future nor say with certainty.  But these are the elements I take away from that DSS:  It appears to be a pro to *not* limit our coin emissions for POW to miners (through ABN, or limiting schemes) as long as there is no 51% attack risk, another words, we seem to believe that a high miner distribution (vs a small miner distribution) gives us a wider investor ratio and a lot of free PR.  (In the case of randomx - these addl miners do provide more security to bbp as the influx makes a 51% even less - then we add on chainlocks also).  The larger coins that are successful have 50,000+ distinct miners widely receiving tiny amounts into distinct wallets, but we generally see 1-5% of those miners become investors who buy the currency.  A lot just hold on to the coins in hope that some day they go to $1 and never sell them.  So thats one point.  The other point is trying to increase the value per unit, due to the extreme difficulty of mining one currency unit.  Let us speculate that 5,000 new miners come on board- what this does is it makes it extremely hard to mine one bbp.  One bbp that used to be worth .002 cents starts being worth potentially .20 cents, because no miners want to sell it below their cost.  I realize this is hard to believe, but the effect takes a long time and its a basic energy:cost-per-unit arbitrage that lets the free market eventually drive the BBP price per unit up to the electric cost.  So what we would ideally want to see is a year down the road, 10,000 miners with a cost per bbp at .25 cents, etc.  That would allow us to support 1,000 orphans per month (without sell pressure).  This is similar to what you see in BTC, Dash and Doge - those coins per unit are selling for the electric cost, etc.

1775

TestNet Discussion Archive / Re: BIBLEPAY - RANDOMX INTEGRATION

« on: February 21, 2020, 06:29:40 PM »

From my perspective i was really hyped for the monero changing alghorithm from cryptonight to randomx because i already  had a bunch of cpus, and i think monero has a bright future so i want to support them.

Same time i really liked the idea of Bbp, giving to charity and all.
So then it was like shall i mine xmr or bbp cant do both on my cpus.. well dilemmas were rising.
 
Now  i think you might have hit the  jackpot, i mean xmr preety stable in price and all.  Also hopefully alot more help for those in need.  I belive alot of people are intrested in dual mining aswell. In the end i support monero network , bpp aswell and also can help some people in need. Cant ask for much more.

Thanks, that makes me feel a lot better; I think a lot of miners will share the same thoughts!

And I think miners will be more compassionate than we think, especially if they can earn two coins that might be worth more in the future.

The other nice thing this clears up is the issue where we view mining as an expense (like I originally did in the early days).  I feel with the charity aspect in the mix, this makes the miners more of the 'heroes'.  Another words, I look at a miner as 'helping' our cause now, as they are paying for the orphans and donating precious electricity to sponsor orphans.  So they become the heroes in this case, which I think is huge for the total team morale; another words in the early days, it was sort of a union vs. company mantra, the miners are spending the money but providing security.  In this system its more of the miners are donating compassionately , and are not an expense, but the co-mvp's for success, etc.

1776

TestNet Discussion Archive / Re: BIBLEPAY - RANDOMX INTEGRATION

« on: February 21, 2020, 06:22:17 PM »

Could you also kindly post the updated binaries for linux_x86. For some reason, the wallet is not able to start when using the downloaded binaries:

Code: [Select]

.error: couldn't connect to server: unknown (code -1)
(make sure server is running and you are connecting to the correct RPC port)

My larger servers can compile 1.5.0.3+ from source code and the wallets sync to the published height and hash but my smaller machines are unable to complete the task.

Code: [Select]

>cli -version
BiblePay Core RPC client version 1.5.0.3

>block
30211

>cli getblockhash 30211
82a5ef56631f932affee373ec8151f42e4472d0081969ceddc720d2ab305afda

Thank you.

1) Thanks, thats great on the hash btw, ours match.

2) On the binary, could you please tell me, on the downloaded linux binary, tell me the version in your getinfo?  It should be 1503 (or from the RPC tab).  Btw, you can try re-syncing with -erasechain=1 first.  (If you are running 1503).  If its not 1503 we need to make a release, which I dont mind making if its not 1503.  But it could be you have a bad block in the file from 1502, as we had a bug in 1502.  Once you resync your old funds should reappear as we did not veer off the big time original 300 million we made when we created the sancs.  Just let me know on the version and ill be glad to add a compile step to keep pressure from asking MIP.

1777

TestNet Discussion Archive / Re: BIBLEPAY - RANDOMX INTEGRATION

« on: February 21, 2020, 06:18:02 PM »

Btw Rob i noticed diff seems ok on output in xmrig now, just wondering all Xmr charity chares always show 0 ms for me.

Shouldnt it be mixed like normal xmr shares like some show 60 ms, others 77 ms and so on..

Anyways great job on latest release!

Thanks a lot!
So trying to reproduce the 'latency' display, Im running 5.6.1 for windows:  I can see the Diff, (solved diff) then the latency.

For XMR I see 121 ms in parentheses and for BBP 120 ms in parentheses.

EDIT: OK - I see what you mean on XMR-Charity, yes, something is wrong in there, I will look at this!

1778

TestNet Discussion Archive / Re: BIBLEPAY - RANDOMX INTEGRATION

« on: February 21, 2020, 10:08:02 AM »

Do you guys feel optimistic about this idea?  IE have we come up wtih something good for orphan charity?
Imo, I think its a pretty good pool/system, in that you get two reward streams.  If I was a monero miner I think Id do this , even without helping charity.  Adding orphans on for me is a huge plus on top of that even.

I feel this is an underestimated idea.  As if it should attract a few thousands miners in one year.  I see there are 50,000 connections to minexmr, so we have plenty to pull in if they get wind of this.

We will probably need to run multiple pools to handle the load; probably one pool per 1000 users, etc.  But we can do that, given that our price should rise for each 1000 miners.

1779

TestNet Discussion Archive / Re: BIBLEPAY - RANDOMX INTEGRATION

« on: February 21, 2020, 10:06:01 AM »

So it looks like all the testnet versions have been compiled.  Once you all upgrade can we please do a hash test?  Here is my hash test:


10:04:55

getblockhash 30197


10:04:55

2275f97ab020e94e4c4298798f55290764941daa92ef49a07b5fbef31adc2d4a


Once I know the entire network agrees then we can move on to testing that sancs still work properly.

Feel free to recreate your sancs.

Btw, they all say ENABLED in testnet because when chainlocks is off, they don't get ddosed.  So please ignore the status until we turn on chainlocks again.

Another words, they are all most likely down actually and they actually need revived.

1780

TestNet Discussion Archive / Re: BIBLEPAY - RANDOMX INTEGRATION

« on: February 21, 2020, 09:03:08 AM »

ill be trying out 5.6.1 out later tonight on both windows and linux over the weekend.
Been running 5.6.0 on linux for 18h and it seems real stable for me,  not many rejects at all. accepted 1776/22 this with  Bbp 10 difficulty.

Thats great!

Yeah, I think the issues were on my end due to hardware.

1781

TestNet Discussion Archive / Re: BIBLEPAY - RANDOMX INTEGRATION

« on: February 20, 2020, 09:21:09 PM »

XMRIG - 5.6.1-Leisure Upgrade for TestNet


- Pass actual share difficulty through to miner as first solved
parameter, and Solved share difficulty as second param (in brackets) for
each solved share, and add network latency to each solved share
- Modify code to be more compatible with future xmrig changes

1782

TestNet Discussion Archive / Re: BIBLEPAY - RANDOMX INTEGRATION

« on: February 20, 2020, 07:36:04 PM »

1.5.0.3-Mandatory Upgrade for TestNet

- Ensure with chainlocks disabled, we can still sync from 0
- Ensure RX performance does not impact initial sync performance
- Add mutex around multithreaded rx queries, and solve initial singlethreaded lock issue
- Merge Marcus Antonios language translations from https://forum.biblepay.org/index.php?topic=494.new#new
- Ensure VersionMessage is handled properly in this branch

** All versions are ready **

1783

TestNet Discussion Archive / Re: BIBLEPAY - RANDOMX INTEGRATION

« on: February 20, 2020, 11:31:26 AM »

Never mind, it looks like we will need a core wallet release anyway for a couple more reasons.

Ill try to get this ready within 24 hours.

1784

TestNet Discussion Archive / Re: BIBLEPAY - RANDOMX INTEGRATION

« on: February 20, 2020, 11:20:55 AM »

Please all, lets remember to test English, Russian and Ukraine during the next release:

https://forum.biblepay.org/index.php?topic=494.new#new

Just ensure the English behavior of the wallet is OK, for one (IE all menus are still captioned).  And if we have any Russian speaking testers, we can use your help testing Ukraine and Russian also.

1785

TestNet Discussion Archive / Re: BIBLEPAY - RANDOMX INTEGRATION

« on: February 19, 2020, 08:37:00 PM »

Pinning this for the future in case anyone else has this issue (a silent exit by the miner after a random amount of time, especially on ryzen 1700s):
https://www.reddit.com/r/MoneroMining/comments/e4k7cq/xmrig_ryzen_7_1700_fix/f9e676q/

So there is a workaround, (Im experiencing this myself), we can make a loop in a batch file like this (pretend this is miner5.bat):

:miningloop
xmrig.exe --params
goto miningloop

I will probably be doing this myself.

And just to give a little background on the problem, first of all there is a CPU setting on some motherboards called 'opcache' that might fix the underlying issue.
But the reason we aren't trying to handle this inside the program is since the JIT machine language is generated on the fly, the actual error signal is a segfault, but in a machine language area that can't have an error catch around it - and - segfaults cause program instability if you try to program around them.  Another words the only safe way to handle this is to let the process die and restart the process at the OS level.

Hopefully not many of our users will have to do this - but I appear to be one in this category with my early version of the 1700, etc. 

I havent tried the bios change yet but Ill post if it works later.