I have checked in the alpha version of stratis-biblepayd last night. This is for developers only (unless you are an extreme power user with visual studio 2017). Please read the bottom of the front page (Biblepay section in the readme.md) for more compile info. The repo is called "biblepay\StratisBitcoinFullNode".
This version syncs biblepayd in stratis in console mode, but remember we dont have the consensus rules checked in yet, and the GUI is in pre-alpha still.
Cool, will take a look! Yeah, its a pretty major breakthrough for us. Now we have kjv.cs in a c# project producing biblehashes. Just PM me after you sync to the top if you can't get the GUI working. Had to manually download the .NET 2.1 sdk from https://www.microsoft.com/net/download/visual-studio-sdksAfter that it compiled fine. I'm assuming there is not currently a migration path for the wallet from BBPCore->Stratus at the moment? Started running the daemon, will let it sync. There is not a migration path yet, but we already enabled the HD wallet in stratis, so stratis runs side by side QT for the next couple years. And since you can send money back and forth, and we have plans for a full governance module, I don't see the need for a migration plan. The blocks are all there (we aren't in need of starting with a new blockchain). My thoughts are that we would build our superblock payments, CPID association, voting, and full compatibility, so a user would be in beta on stratis for a long time and if hiccups occur, they go back to prod using biblepaycore until we work it out. |
|
|
|
** Update on World Community Grid **
Summary: A) We need users to enable export authorization from their respective web accounts, B) We need to test this to see if it works for Biblepay
I'll take a look at testing this today.
Please look for a checkbox in your WCG account to enable publically sharing your RAC data and please enable it.
I had this on by default. I think it should not have been as I have reported european country. Yes, I have a few WCG accounts from back in the day, and I see the default is set to Show the data. So that's great from our perspective as our users wont have to change anything by default... Checking into our Sanctuary Integration in detail, it looks like we are back in business with WCG. Everything looks like its fine. I've just re-enabled WCG as our 2nd project. RAC should start being paid within 24 hours. NOTE It might be too late for tomorrow morning's 8AM superblock, but by Sunday morning we should see WCG payments going out again. The project factor is set back to 1.5 WCG points per 1 Rosetta point. Rob, could you clarify the calculation? I was looking at the superblockview and saw that the following formula seems to be at work to determine the RAC used to calculate one's share ModifiedRAC = (AvgRAC + WCGRac) * UTXOWeight 2 questions. #1: Does 1.5 WCG points per 1 Rosetta point mean that if one has 1500 WCG RAC, it's only worth 1000 Rosetta RAC? I seem to recall a debate about WCG being more difficult and perhaps its the other way around? #2: Is the WCGRAC reported in the superblock view the already "adjusted" amount? In other words, if I see WCGRAC at 1000, does that mean it was adjusted downwards from 1500? Thanks! On #1, WCG is 1.5* more difficult so we reward 1.5* the RAC on WCG's rac. (There was a discussion of some wild fluctuations at first but we seemed to hone in on 1.5, basically, when running all the WCG work mixed from the web portal). On #2, the Sancs do multiply the WCG * its project factor of 1.5 first, so when you read the pool superblock view: The "AvgRac" is the Rosetta RAC, the WCGRac is the adjusted WCGRac (you can find the original figure in your Boinc client GUI row for WCG in the running projects, under RAC, that is in your boincmanager.exe GUI (not in WCGs portal)), then the Total is the Total RAC (of those two figs) * the UTXO Level %. |
|
|
|
PurePool:
@Lichtsucher, Apart from the daily Autosend that is not working, I see in the Pool Statistics that the number of shares dropped a lot but the pool keeps founding blocks.
Update: The last block paid was 57760 and no more entries in the Transactions since July 13, 2018, 9:30 a.m. It seems that it got stuck again.
Mhh, strange problem. The Biblepayd had used a lot of ram for a short time, so the OS killed some other daemons. My background job system (which checks the solutions and do the transactions) got half of its processes killed. With that, it could not hold up with the amount of tasks. But with some tasks running, my alert system wasn't triggered. Fixed it by restarting the jobs, plus I corrected the stuck block. Payouts are already done, missing blocks are shared out right now. Some solutions got lost, but it hit everybody the same way, so in the end, it should bring the same amount of bbp in the end for everybody  I'm not sure why it is more unstable with the newer biblepay releases. It worked so well before :/ So Ive been running 1.1.3.8 on windows and linux for a few days now, looking at windows its using 265K and linux 277K. So thats the same as the prior old versions used. First of all, lets look at your ram use after running 24 hours. Try this- get process id of biblepay then type: sudo pmap -x pid Look at total RSS (resident ram consumption) See if its higher than 350K for you. If so let us know what module is hogging the ram. Next, verify you are not changing the source code before you compile. I posted a few pages back that changing the openssl declarations is not a good idea, and we should be compiled against 101k. So if you need to create a custom build you will have to compile 101k first, then use the OPENSSL_INCLUDE_PATH= and OPENSSL_LIB_PATH= to point to the specific binary to compile against. Also it would be good to create a rough baseline if you do find a memory issue, let us know the pattern. |
|
|
|
I have checked in the alpha version of stratis-biblepayd last night. This is for developers only (unless you are an extreme power user with visual studio 2017). Please read the bottom of the front page (Biblepay section in the readme.md) for more compile info. The repo is called "biblepay\StratisBitcoinFullNode".
This version syncs biblepayd in stratis in console mode, but remember we dont have the consensus rules checked in yet, and the GUI is in pre-alpha still.
Cool, will take a look! Yeah, its a pretty major breakthrough for us. Now we have kjv.cs in a c# project producing biblehashes. Just PM me after you sync to the top if you can't get the GUI working. |
|
|
|
** Update on World Community Grid **
Summary: A) We need users to enable export authorization from their respective web accounts, B) We need to test this to see if it works for Biblepay
I'll take a look at testing this today.
Please look for a checkbox in your WCG account to enable publically sharing your RAC data and please enable it.
All, I found the setting : Navigate to worldcommunitygrid.org | Log in Click Settings | My Profile | Scroll down to the middle of the page | Look for Display My Data: Choose to display or hide your data You can control whether your data is displayed or hidden. If you choose to display your data, your username and contribution statistics will be shown on our leader boards, your badges and country (if specified) will be shown in our forums and your user and device information will be included in any data export files. See our Privacy Statement for more details. Display my data Hide my data Select "Display My Data" Save - I will test with my CPID asap. I had this on by default. I think it should not have been as I have reported european country. Yes, I have a few WCG accounts from back in the day, and I see the default is set to Show the data. So that's great from our perspective as our users wont have to change anything by default... Checking into our Sanctuary Integration in detail, it looks like we are back in business with WCG. Everything looks like its fine. I've just re-enabled WCG as our 2nd project. RAC should start being paid within 24 hours. NOTE It might be too late for tomorrow morning's 8AM superblock, but by Sunday morning we should see WCG payments going out again. The project factor is set back to 1.5 WCG points per 1 Rosetta point. |
|
|
|
** Update on World Community Grid **
Summary: A) We need users to enable export authorization from their respective web accounts, B) We need to test this to see if it works for Biblepay
Hello,
We are pleased to report that access to the data export files has been re-activated and is available again. Volunteers who wish to access the data will not need to sign a Data Processing Agreement or obtain tokens.
The review concluded that if volunteers are given explicit notice of and sufficient control over how their data is used, there was no legal justification for imposing any further restrictions on the data export files. The review also concluded that we will likely need to reinforce and strengthen the consent language in a few places on our website, but that doesn't stop us from opening up access to the data exports in the meantime.
This process took significantly longer than any of us hoped or anticipated, and we understand people's frustrations while we had to disable access pending the legal review. But we felt it was important to push back aggressively on what was initially a process more appropriate to a commercial engagement than a philanthropic initiative and to persevere until we had an outcome that was both GDPR-compliant as well as volunteer-friendly.
Finally, a reminder that while access to the data exports is now unrestricted, the export files only include data of volunteers who have opted to make their information public.
Thank you for your patience, and as always, your support.
Sincerely,
World Community Grid Support Team
---------------------------------------------------------
World Community Grid
***
I'll take a look at testing this today.
Please look for a checkbox in your WCG account to enable publically sharing your RAC data and please enable it.
All, I found the setting : Navigate to worldcommunitygrid.org | Log in Click Settings | My Profile | Scroll down to the middle of the page | Look for Display My Data: Choose to display or hide your data You can control whether your data is displayed or hidden. If you choose to display your data, your username and contribution statistics will be shown on our leader boards, your badges and country (if specified) will be shown in our forums and your user and device information will be included in any data export files. See our Privacy Statement for more details. Display my data Hide my data Select "Display My Data" Save - I will test with my CPID asap. |
|
|
|
|
I have checked in the alpha version of stratis-biblepayd last night. This is for developers only (unless you are an extreme power user with visual studio 2017). Please read the bottom of the front page (Biblepay section in the readme.md) for more compile info. The repo is called "biblepay\StratisBitcoinFullNode".
This version syncs biblepayd in stratis in console mode, but remember we dont have the consensus rules checked in yet, and the GUI is in pre-alpha still.
|
|
|
|
|
** Update on World Community Grid **
Summary: A) We need users to enable export authorization from their respective web accounts, B) We need to test this to see if it works for Biblepay
Hello,
We are pleased to report that access to the data export files has been re-activated and is available again. Volunteers who wish to access the data will not need to sign a Data Processing Agreement or obtain tokens.
The review concluded that if volunteers are given explicit notice of and sufficient control over how their data is used, there was no legal justification for imposing any further restrictions on the data export files. The review also concluded that we will likely need to reinforce and strengthen the consent language in a few places on our website, but that doesn't stop us from opening up access to the data exports in the meantime.
This process took significantly longer than any of us hoped or anticipated, and we understand people's frustrations while we had to disable access pending the legal review. But we felt it was important to push back aggressively on what was initially a process more appropriate to a commercial engagement than a philanthropic initiative and to persevere until we had an outcome that was both GDPR-compliant as well as volunteer-friendly.
Finally, a reminder that while access to the data exports is now unrestricted, the export files only include data of volunteers who have opted to make their information public.
Thank you for your patience, and as always, your support.
Sincerely,
World Community Grid Support Team
---------------------------------------------------------
World Community Grid
***
I'll take a look at testing this today.
Please look for a checkbox in your WCG account to enable publically sharing your RAC data and please enable it.
|
|
|
|
And yet, I feel like I'm missing something. That level of transparency clearly isn't enough for some. Why?
What we need to do is get a third party to check once per quarter on our total contributions to each charity. Ginger will give an exact number (shes our district rep for compassion). If you have a total sent on a certain date that matches the total spent, then we are audited up to that day... So this coin is provably legit, besides you can see all the individual orphan letters coming in on a regular basis. Those kids are required to send at least one monthly letter.... Not to beat a dead horse, but does it make sense to have transparency or reporting with BBP sold on a specific exchange, the BTC it was sold for, and then the BTC sold for fiat? The complete paper trail would just make the charity contribution. I like how Kairos showed their paper work. Also, the BBP addresses involved so anyone can publically verify the transactions easily. Don't get me wrong... I'm not accusing you of anything negative. I'm just trying to reduce and/or prevent these insane criticism thrown at BBP. I know your heart is in the right place and you're doing a great work... but nothing beats Satan at his own game than documenting all the steps. What we could do is have You call Ginger and see if You can set it up so you can administer, manage and pay for a certain percentage of the children per month and do the paperwork that I require for the pool, that that would take part of the load off of what I do. Then you can keep exchange receipts showing your SSN from end-to-end. Thanks. EDIT: We already have all that in the pool. Click on Orphan Fundraisers. But yes, you should ensure you are not agreeing with criticizers, as we already have 100% accountability. There is nothing missing. |
|
|
|
Noxpost then why we using bbp from proposals 15M? We can use this coins for listing..... nobody see that coins from proposall was sell ... ask him where are all coins from proposals with proofs screens .. transfers to exchanges ...
All his answers is lies
You are talking like you have a birdbrain. Why would our sancs be based on masternodes if our users didnt get rewards for locking the funds, and the privilege to vote on important charitable governance issues? |
|
|
|
It's weird how many suspicious people continue to draw some conclusion that Biblepay = Rob and that Biblepay Money = Rob's Money.
I don't think any amount of "transparency / accountability / history/logging/whatever" discussion is going to convince people otherwise. Biblepay money is a decentralized collective, for which a decentralized governance committee (which includes some "big" players, admittedly) votes on how to spend.
Now, even if you assume that Rob has the ability to approve any proposal he wants on the basis of owning enough masternodes, that's just a "whale" situation. Is Rob a whale in BBP? I guess we might say that. Does it mean that Biblepay is therefore less than legit? You'd need to throw aside an awful lot of logic to make that leap.
If I (or anyone else) were to suddenly go from 5 masternodes to 50, for some reason, I feel like people would treat it differently. Maybe I'm wrong....but it's not like there are proposals getting passed of "I would like all the BBP for a new roof for my house" or something like that. We have the accountability page that tells us that the things we are voting to pay for are being paid. I don't need to see that it came from this wallet to that wallet to that exchange to fiat to wire transfer - just that it happened. I didn't vote for a proposal of "4M BBP to be sold on QIEX for 39 satoshi on july 17th" - I voted for "pay the orphan bill." If the orphan bill gets paid, I'm happy.
And yet, I feel like I'm missing something. That level of transparency clearly isn't enough for some. Why?
Yeah I forgot to post this the other week, although now I dont have time to make this statement suave, but someone was arguing with me about the 'provability' of our RPC command (along with Theymos). I figured out later that night that we *can* prove our contributions at checkpoints, making us 100% provably legit. What we need to do is get a third party to check once per quarter on our total contributions to each charity. Ginger will give an exact number (shes our district rep for compassion). If you have a total sent on a certain date that matches the total spent, then we are audited up to that day... So this coin is provably legit, besides you can see all the individual orphan letters coming in on a regular basis. Those kids are required to send at least one monthly letter.... |
|
|
|
Jaapgkv im checking all this things on this coin and is very untrustworthy.. dont believe this ways
Dave. Kucoin wants to fill the form only from main dev.Slovakia user wrote this 2-3 weeks ago .... so? Its dumbaaa when main dev screw on it...he is lazy for this....
Don't worry, I'm not deleting any of slavino's posts, he's not swearing. But lets follow this all the way through. I implore you to post any single thing here that is untrustworthy or a sham, or one single thing I've done to hurt another person. Unfortunately Slavino as your track record shows, you have fabricated stories in the past and you have a horrible personality. If I own sanctuaries its because I believe in the coin, does that make any stronger of a case to buy bbp than if I believe in it? Who cares if Cryptobridge is taking a couple weeks to go live. They have an integration process, that is to be expected. No one can make 'free sanc income' off of .50 bitcoins in two weeks. |
|
|
|
So there are people still trading BBP on C-CEX right now. Am I right in assuming that when the wallet is updated they will lose the BBP that was bought but keep the alts that they got when they sold BBP? And that C-CEX is going to be the one who ends up taking the hit on that? Seems a little sad. I mean, I know we gave plenty of notice, but I wouldn't want whatever is happening there to hurt our reputation.
There are still some mighty full BBP wallets on C-CEX. If somebody was to, say, sell off the 2M BBP in the top wallet then withdraw the BTC (not that they'd necessarily find buyers for all of that), it'd be a real scandal.
Well the risk is if they leave the old version up and it gets unstuck, users can deposit bbp on a fork, mined from the old version. Its not a bad problem if they send BBP from the New version, as that would get confirmed eventually when they resync the chain. You cant lose any BBP by sending on the official version as coins will either be provably in a transaction or never sent. However I agree it is a very bad precedent to set to not be able to go into maintenance. If a vacation is longer than 7 days, there should be an emergency button on the dashboard for the lead devs account to push it into maintenance. Lets hope it remains on the same block number (stuck). I have a feeling someone stopped the daemon but didnt update the status. As usually when the daemon is out of sync, it stays on the wrong chain advancing. |
|
|
|
I like the background prayer load feature also. The reason it was disabled is TheSnat had a couple instances of a 5+ minute loading time, and I got very nervous that we had a race condition so I disabled it. You have to realize the feature is not just for prayers but also for PODC data, so its critical the wallet has it all in order before the chain finishes syncing... So we will have to revisit this again and ensure there is really no race. There is a pull we need from thesnat for the transaction list which confuses the issue (as the extra-long load started at the same time we added tx list filtering And background prayers), so we need to insert one fix at a time and verify it.
It's a nice feature, hope it comes back. And I was waiting to see how long it took to get blamed for something I know your probably joking but just to clarify Im not blaming your tx list filtering for the long load time; I am saying the long load time started at the same time we merged that feature in, but background prayers 'appeared' to be working for the prior 7 days (which is a weak statement). So you have to be open minded and realize its possible that QT is processing invisible transaction data and internally slowing the boot down, but I havent had a chance to look into that yet. |
|
|
|
I am just checking the machine leadboard and find something interesting:
manasd 27315.81 7/9/2018 6:06:42 AM 3391974 89828.89 GenuineIntel Intel(R) Celeron(R) CPU G1620 @ 2.70GHz [Family 6 Model 58 Stepping 9] 1994560 2 8151.14 MB 3282.09 0.8 27.31581 1.312836
For this slow machine with 2 core, how could he achieve such a high RAC? Is there any trick we do not know?
GPU for rosetta?
[6] AMD AMD Radeon (TM) R9 380 Series (4096MB) OpenCL: 2.0 It would appear that way. edit: seems they abandoned the project https://biblepay-central.org/en/podc/user/1994560/I was wondering that quite some time ago, there were others too where the RAC didn't add up to the seemingly slow hardware. The solution however is quite simple: Rosetta (or BOINC) reads the hardware from system files. If you know where to look for it should be quite easy (especially under Linux) to edit those and write in any hardware you want. If then you copy-paste images of your whole installed operating system to your other machines it appears as if you have dozens of weak CPUs crunching a lot of RAC. However, why you would go through all that trouble is beyond me... on another note: Why was the wallet feature "memorize prayers AFTER wallet start" abandoned? I really liked that I didn't have to wait several minutes until the wallet was opened.  I like the background prayer load feature also. The reason it was disabled is TheSnat had a couple instances of a 5+ minute loading time, and I got very nervous that we had a race condition so I disabled it. You have to realize the feature is not just for prayers but also for PODC data, so its critical the wallet has it all in order before the chain finishes syncing... So we will have to revisit this again and ensure there is really no race. There is a pull we need from thesnat for the transaction list which confuses the issue (as the extra-long load started at the same time we added tx list filtering And background prayers), so we need to insert one fix at a time and verify it. |
|
|
|
I tried some time ago. 15 confirmations so far and it didn't even show up at C-CEX.
Me too - I sent 125 bbp 7 blocks ago and it did not confirm nor pop up - so it appears CCEX put us in maintenance, which is great, but I didnt receive a message. |
|
|
|
However, I am worried about C-CEX. They still haven't put us in maintenance so we are going on a fork if we cant get through to them.
The primary risk is people will try to make deposits to old BBP addresses on a fork, and we can't risk that.
I noticed that C-CEX is stuck on block 57039. Or at least this is what the show on the top-right small BBP windows. I noticed that block # is always behind, but lets see if it stays @ 57039 for hours. Maybe they put us in maintenance and we dont know it. Ill try sending some BBP now... |
|
|
|
|
Alright Im synced on Crypto-Bridge desktop windows client, anticipating the big moment.
Right now this platform looks very impressive to me, I am not seeing latency, I am seeing snappy response and blocks clicking by once every 5 seconds ( I guess they have 5 second blocks, with 28 million blocks already). This is an impressive feat to design a decentralized exchange that actually works.
It makes sense to charge for cancelled orders as that takes network work, but I see MIPs point that they could charge more for the order and zero for the cancel, but its still pretty interesting how they broke the exchanges individual activities down to small units of decentralized work.
Any update on when we are going live? I assume any day now.
|
|
|
|
Does anyone have trouble using InstantSend on 1.1.3.8c? I tried to send different amounts of 100, 1000, and even 10,000, but it keeps throwing an error saying that Instantsend only supports up to 500,000 BBP. Just noticed it after I upgraded from 1.1.2.4.
I did have a problem with it, yes - but I didn't report it as I couldn't reproduce it. I could InstantSend 50,000 and 100,000 BBP, but not 200,000 or 300,00. However, I think (not sure, but think) that the message was just misleading, and it was probably because I didn't have all of the funds sitting in the same address first. I was able to do instantsend of 100,000 -> 100,000 -> 50,000 -> 50,000 but that was the only way I could get it to work. Every other attempt threw the error you described. The message is a bit ambigious. To solve it, please go into coin control and manually select coin inputs less than 500,000, then re-send . |
|
|
|
I am just checking the machine leadboard and find something interesting:
manasd 27315.81 7/9/2018 6:06:42 AM 3391974 89828.89 GenuineIntel Intel(R) Celeron(R) CPU G1620 @ 2.70GHz [Family 6 Model 58 Stepping 9] 1994560 2 8151.14 MB 3282.09 0.8 27.31581 1.312836
For this slow machine with 2 core, how could he achieve such a high RAC? Is there any trick we do not know?
GPU for rosetta?
I firmly believe its impossible to have any GPUs out there for rosetta. One its public info to see which platforms they compile for and they dont offer a GPU option, two I read all the threads when we were working on PODC, and the users and scientists say that the code is too complicated to port to GPUs (because of the proprietary libs that dont have low level C libs available for GPUs, these are CPU libs), and three, you can see this is true by looking at the Rosetta Commons user manual, I dont have a link on hand, but it does appear to back up what they are saying in the boinc forums. On manasd, he has 18 machines and 38 procs, with a rac of 89828. To figure this out you would have to click on all his 18 machines. This one might not be representative to his full account. |
|
|
|
|
Show Posts
