from mintnodes: "The wallet is not locking masternode VIN transaction coins. So when a withdraw is made the masternode VIN could get destroyed. We are working on a solution for this in the near future but it will not be a shared masternode but full masternode hosting."
I've asked for more details, and/or an account we can track for this. It may be related to how they build the nodes, I thought masternode coins were locked from the client? Well, as far as locking coins, we are the same as every other coin - we have a primarily cold setup. Mintnodes only uses cold but they require the keys - so there is a level of trust similar to a centralized exchange required to use mintnodes. I e-mailed Steve. I offered a long detailed explanation, and I even apologized for some of the rough characters we have that he might have encountered. I haven't heard back yet. Hopefully he will consider reinstating BiblePay. (Let's see if he gives us any clarification on if it's related to : mandatory, IPFS, watchman, or something character related). |
|
|
|
from mintnodes:
"The wallet is not locking masternode VIN transaction coins. So when a withdraw is made the masternode VIN could get destroyed. We are working on a solution for this in the near future but it will not be a shared masternode but full masternode hosting."
I've asked for more details, and/or an account we can track for this.
It may be related to how they build the nodes, I thought masternode coins were locked from the client?
This is only documentation I have on unlocking masternode collateral: http://wiki.biblepay.org/Create_Sanctuary_2#HOW_TO_UNLOCK_FUNDSAlso, btw, if you go into coin-control on QT, you can right click a masternode locked fund entry, click UNLOCK, then you can spend it. |
|
|
|
I'm trying to engage them, so far no response.
Refer them to masternode install script we prepared. It takes care of everything and avoids the legwork. Regarding forks, I don’t know of any non-PoBH mining node (like a MN) affected. I didn't know we had the random fork this week, I thought we have been pretty solid for 45 days or so. But on the positive side, this is with the old codebase running (the upgraded block sync code does not start til 77000) - hopefully God willing this new start extends our current stability from 45 days to more like 365 days without forced reboots or reindexes. Fork was mentioned here ( https://bitcointalk.org/index.php?topic=2388064.msg46723000#msg46723000) and social media multiples times... I was going to e-mail you about the fork, but since you explicitly told me not to email you directly anymore, I didn't bother. I figured one of your team members would let you know. Two miners mining on a fork isn't a "fork". A fork is when more than 20% of our network believes that an alternate chain exists with enough work on it to cause a percentage of nodes to go off and mine on that chain. Usually when that happens, a certain percent of our masternodes drop (they say WATCHDOG_EXPIRED) because they are on a fork. I didn't see that happen over the last 40 days. So please be more cognizent of saying "we had a fork" when we did not have any trace of a fork. A fork is bad for everyone and signifies that we have a weak network which there is no evidence of. It makes partners want to shy away from sticking with BBP. So we had two miners who had to reindex in reality. |
|
|
|
Just speculation but, I'm curious if there is another coin that is bigger and requires port 40000 for masternodes, I could see this being considered a "technical issue"
The idea of a shared MN service like this using one server for 10+ different coin masternodes is great until there is a port conflict
There is no other crypto that uses 40,000 (as of the date we launched), that is one thing I'm responsible for checking during initial development. Its up to the lead dev to launch a coin with a certain port. I used 40,000 based on a few factors (I wanted non-ephemeral but above 32767), these ports are not blocked as commonly by networks since they are used for some existing services. However I wasnt aware of safetynet. But I don't think thats a problem for a few reasons. First, the communication protocol handshake would just hang up on us or us on them. Next, I have heard of instances of coins launching and stomping (or sharing) another coins ports and technically, the bitcoin protocol has the ability to overcome this (the version message will negotiate to our network only) and it will only store our peers in peers.dat (ones whose version matches). So even if another coin launched with 40,000 we would be OK. It would result in more inefficiency for them and hopefully cause them to switch to a free port before they get too far along in life. |
|
|
|
I'm trying to engage them, so far no response.
Refer them to masternode install script we prepared. It takes care of everything and avoids the legwork. Regarding forks, I don’t know of any non-PoBH mining node (like a MN) affected. I didn't know we had the random fork this week, I thought we have been pretty solid for 45 days or so. But on the positive side, this is with the old codebase running (the upgraded block sync code does not start til 77000) - hopefully God willing this new start extends our current stability from 45 days to more like 365 days without forced reboots or reindexes. |
|
|
|
Thanks everyone for all of your hard work on BBP recently. With the stock market turning down this week, it seems financial instability is on the rise, and it is comforting that Biblepay exists as a fallback system. All the hard work has made this happen, and the work in progress gives confidence in its future.
Just to mention a technical topic on my mind, I usually keep my wallet computer off, and turn it on each day and send a "exec podcupdate true" PODC update manually. However, sometimes the wallet sends an update on its own at the same time, and one PODCupdate goes out with only the remainder of coins staked. This would reduce my daily payment unless I wait 6 confirmations and send out a new one. Is there anyway to have it not send 2 updates in this case? Not sure how many people update like this, but I thought I'd ask the question.
Best to all,
bbptoshi
Thank you for the compliments; they go a long way in the desert we are currently in  . As far as the wallet re-sending another UTXO (back to back), we actually have a line of code in the wallet designed to prevent a re-send (its basically checking to see if one was sent within the last 4 hours), however, it relies on the tx being more than 1 mature - which probably was not the case. I'll look at this issue. |
|
|
|
|
Status update on the latest mandatory version:
The version that has been available for download - 1.1.5.7+ is fine for all intents and purposes, but we are adding some 'nice to have leisure' features now.
Currently I'm migrating our orphans individual bio records into IPFS so we can display them in the core wallet.
We will also have a bug fix in business objects that allows quicker navigation.
MIP has committed to adding a Church Tithe button to the mobile wallet! This should be really awesome, and I'm very excited about that.
MIP and I are also working through the Apple policies to get the Apple version of BiblePay mobile wallet released.
I'll be starting on in-wallet letter writing next - I believe we are going to go all the way with BiblePay core, and start moving things from the pool into the core wallet. We will provide the ability to write orphan letters, list the letters, upvote the letters, etc. The content-economy discussion will be a whole separate issue (having to do with content creation, uploading Christian videos, IPFS rewards, voting rewards etc).
|
|
|
|
I have joined Team Biblepay on wcg (Team ID 35006) before 4 Days.
On Rosetta the same weeks before.
On both i had set my Userdata from "hide" to "display"
I DONT have the same CPID on Rosetta and wcg.
Is that my fault? Can I Change that?
Thanks.
Morka
The easiest way to get CPID to sync is to have at least one of your hosts attached to both projects. Typically within a day or two the CPID will become the same. If you do not want to run work at both projects, just set one to "No New Tasks". However stay attached. Yes, to set up WCG, you must make your WCG e-mail the same as rosetta - this will cause your WCG cpid to eventually be the same as your Rosetta CPID (usually only takes 24 hours). You currently *do* have to be in the WCG BiblePay Team to receive credit. Of course in a couple days after block 77000 things are changing (we invite all of BOINC RAH & WCG in at that point). The easiest way to know if WCG is working with biblepay: view the pool.biblepay.org superblock view report, look for the WCG RAC column. Note: To view your WCG rac from boinc: install the boinc gui, and view the WCG project row- look for RAC. |
|
|
|
I'm not sure that everything's normal... biblepay.org pool shows this : Magnitude: 0 UTXO Weight: 0 Task Weight: 0 RAC: 1064 Unbanked: 0 getboincinfo give me this: "Command": "getboincinfo", "CPID": "myCPid-deleted for security purpose", "Address": "BSATbruuKuvStDgm3uZJ5AtJMNq1ywqzQT", "CPIDS": "myCPids-deleted for security purpose;", "CPID-Age (hours)": 427548, "NextSuperblockHeight": 76270, "NextSuperblockBudget": 1077065, "71ab02bc9802055cff99a9cc03f5562e_ADDRESS": "BSATbruuKuvStDgm3uZJ5AtJMNq1ywqzQT", "71ab02bc9802055cff99a9cc03f5562e_RAC": 1063.71, "71ab02bc9802055cff99a9cc03f5562e_TEAM": 15044, "71ab02bc9802055cff99a9cc03f5562e_WCGRAC": 6303.8, "71ab02bc9802055cff99a9cc03f5562e_TaskWeight": 100, "71ab02bc9802055cff99a9cc03f5562e_UTXOWeight": 123224, "Total_RAC": 7367.51, "Total Payments (One Day)": 0, "Total Payments (One Week)": 3255, "Total Budget (One Day)": 1077065, "Total Budget (One Week)": 7539455, "Superblock Count (One Week)": 8, "Superblock Hit Count (One Week)": 8, "Superblock List": "76065,75860,75655,75450,75245,75040,74835,74630", "Last Superblock Height": 76065, "Last Superblock Budget": 1077065, "Last Superblock Payment": 0, "Magnitude (One-Day)": 0, "Magnitude (One-Week)": 0.431728818594978 please note that my balance has increased in an insane way since those 2/3 days... I usually get approx 500 bbp per day, and I got approx 30 000 bbp in 3 days! Doesn't seem so realistic, to me, unless lots of unknown friends are suddenly computing on my behalf  Thanks for your help! Hi ! biblepay-central.org gives me "next payment estimated : 0.0000" And I can't see any PODC update since 07th October... I've been computing with BBP for a few months now. Is everything alright there? Thanks for the info It appears you have been mining on a fork for a few days - I dont see your UTXO on the main chain (exec utxoreport 71ab02bc9802055cff99a9cc03f5562e). That explains the massive rewards (you are mining alone So yes please re-sync your chain and then send a new utxo (exec podcupdate true). After your next reward, pool.biblepay.org should show your correct stats. |
|
|
|
I reached out to mintnodes, seems they were unaware of the fork and said they would update right away.
Good proactivity, thanks. I think Togo had them on his list but a confirmation is better. I created a ticket at CCEX for an upgrade. SX and CX already upgraded. QIEX confirmed the upgrade will happen. |
|
|
|
** POOL.BIBLEPAY.ORG DOWN FOR MAINTENANCE **
We should be back up in approx one hour. We will keep you posted.
POOL.BIBLEPAY.ORG is back up. Please, let us know if anyone has any problem mining or withdrawing funds now. |
|
|
|
|
** POOL.BIBLEPAY.ORG DOWN FOR MAINTENANCE **
We should be back up in approx one hour. We will keep you posted.
|
|
|
|
Does anyone else have a problem with withdrawing from the main pool? It doesn't work for me since yesterday. I get the confirmation mail, the link says "transaction verified" but it never works and my funds are unchanged ...
Is this a manual withdrawl? Did you try that? I could never get auto withdrawls to work. It was a few months ago, I just used manual withdrawl. Yes, it's a manual withdrawl. Both (manual and auto) worked perfectly for me the last couple of months (until yesterday).  Ok, I see that we do have an issue preventing a user to make a normal pool withdrawal. It looks like the database needs a tad bit of maintenance. The pool will be down for one hour for database maintenance - please bear with us. |
|
|
|
Does anyone else have a problem with withdrawing from the main pool? It doesn't work for me since yesterday. I get the confirmation mail, the link says "transaction verified" but it never works and my funds are unchanged ...
I'll check into it... |
|
|
|
I love this idea! I'll try to reach out to Chan Zhao now. |
|
|
|
|
BiblePay - 1.1.5.9
Leisure Upgrade for Users
Mandatory Upgrade for Sanctuaries
- Fix bug in unbanked magnitude assimilation process
|
|
|
|
Anyone missing unbanked ARM payment for 10/5 and 10/6? Last two days I have not been paid for PoDC work.
Are you sure you were crunching Rosetta tasks actively? What is your CPID? Rosetta has not had ARM tasks in a while, it looks like ~1000 tasks were assigned recently but its very "luck of the draw". That wouldn't explain it because RAC has a half life. If I'm getting no payments sequentially day after day that would make sense because RAC is 0. But payments are intermittent... I'm included in one super daily block, but not the next. pool.biblepay.org is showing 0 RAC for Rosetta, 54.24 under ARMRAC. On the Rosetta@Home account, it shows I have a RAC of 44.54 Total credit 42,837 Recent average credit 44.54 Cross-project ID: 12adc617474710035a0be614454e7251 Don't change anything; I'm tracing your CPID now. I see you in the pool in the Rosetta team but not in todays superblock- let me check into this in detail. Ok, I found the problem. Some of the unbanked CPIDs are not being included in the superblock, despite having a RAC > 1, being unbanked and associated properly, and everything else lining up for them to be paid. The problem is highly technical, and only affects some of the unbanked CPIDs. The release requires all the sancs to upgrade. We can't do it as a mandatory - for various reasons, but we can do it as a leisure and as soon as the supermajority of the sancs upgrade, the payments will become regular again. I just tested the fix and confirm it worked, so first, let me create a release and upgrade the pool and sanc1 (this will fix the superblock view report). Then I'll announce a release here later this evening. Sorry about the hassle this has caused you. This most likely explains the intermittent issue we had reported prior to this report, but didn't affect Jaap in the same way. |
|
|
|
Anyone missing unbanked ARM payment for 10/5 and 10/6? Last two days I have not been paid for PoDC work.
Are you sure you were crunching Rosetta tasks actively? What is your CPID? Rosetta has not had ARM tasks in a while, it looks like ~1000 tasks were assigned recently but its very "luck of the draw". That wouldn't explain it because RAC has a half life. If I'm getting no payments sequentially day after day that would make sense because RAC is 0. But payments are intermittent... I'm included in one super daily block, but not the next. pool.biblepay.org is showing 0 RAC for Rosetta, 54.24 under ARMRAC. On the Rosetta@Home account, it shows I have a RAC of 44.54 Total credit 42,837 Recent average credit 44.54 Cross-project ID: 12adc617474710035a0be614454e7251 Don't change anything; I'm tracing your CPID now. I see you in the pool in the Rosetta team but not in todays superblock- let me check into this in detail. |
|
|
|
BiblePay
1.1.5.8-Leisure Upgrade
- Added Theymos Report (exec theymos). This report reconciles our money
supply to our charity % and BBP sold quantity, and reports on key
metrics for accountability.
- Added support for Revenue and Expense business objects, and added a
grand total.
The Theymos report is being released!
Let's test these new features in Prod next!
Please let me know after we have a few interested parties upgraded.
Instructions to use our new in-wallet accountability system. (Note: In the future we will look into making custom menus and screens for certain types of business objects). EXPENSES: Click Business Objects | Right click Expenses | Click List. You can then see the expense details (all expenses since we started - and these reconcile to the pool up to the date of the cutover). You can see a grand total (matching accountability.biblepay.org). You can also navigate to a PDF by right clicking the row and click "Navigate to..." REVENUE: Click Business Objects | Right click Revenue | Click List. You can then see the revenue details (all liquidated BBP since inception - these reconcile to accountability.biblepay.org up to the date of the cutover). You can see a grand total (matching our total converted fiat on all exchanges). Theymos Report: From the RPC, type 'exec theymos'. "Command": "theymos",
"Theymos Report": "10-07-2018 12:11:28",
"Total Coinbase Emission (Money Supply)": 998579970,
"Total Charity Budget": 99857997,
"Total BBP Sold on Exchanges": 92232375,
"Total BTC Raised": 20.55,
"Avg BTC Price": 7170.321212121213,
"Avg BBP Price": 0.001746964663980517,
"Total Revenue in USD": 161126.7,
"Total Expenses in USD": 161483.18
This report reconciles our entire blockchain money supply to what we actually spent on charity. So in section 1, we have a money supply of 998.5MM. Since our Emission wiki states that we give 10% to charity, our Charity Budget portion is shown in actual live figures of: 99.85MM. Our actual BBP sold on exchanges: 92.23MM. (The reason BBP sold is a little less than our target charity, is because we are 30 days behind - with governance and liquidations). So this shows the actual amount liquidated reconciles back to the stated amount we spend in our mission and to our total money supply. Next, we show that we raised 20.55 BTC and sold it at an average price of .00174 USD per BBP with an average of 7170 per BTC. Next, we show our USD expenses (actual totals) derived from our actual live-in-wallet business objects to be $161,483 - in contrast to our revenue of $161,126. The expenses were slightly higher than the revenue (due to me slightly overpaying compassion each time I pay an invoice). Note that the actual details of each invoice and revenue record are now stored in IPFS, and going forward we will start using IPFS to store these records, meaning this report will be automatically updated in real time. We will truly be realizing our vision as a DAO, with decentralized accountability records in IPFS. |
|
|
|
|
BiblePay
1.1.5.8-Leisure Upgrade
- Added Theymos Report (exec theymos). This report reconciles our money
supply to our charity % and BBP sold quantity, and reports on key
metrics for accountability.
- Added support for Revenue and Expense business objects, and added a
grand total.
The Theymos report is being released!
Let's test these new features in Prod next!
Please let me know after we have a few interested parties upgraded.
|
|
|
|
|
Show Posts
