Bitcoin is not particularly much down in price, but the token of this project has fallen quite strongly and this indicates the attitude of developers to the project. I hope the developers do not think about it.
Do your research right and don't just drop a templated one-line post. All masternode coins (not "tokens" by the way) accumulate a 75-90% fall on average. Biblepay only a 50%. MIP, he is spamming to get his signature advertisement into the thread... |
|
|
|
|
I didn't see a response, anyone else miss out on an unbanked payment last superblock?
Not a huge deal but if there is an issue i'd like to correct it
|
|
|
|
|
Strange this superblock it seems like I missed the unbanked payment..
Anyone else see something similar?
|
|
|
|
Thanks, that brings up a good point also. My regular wallets (3) were on the right chain but 30% of my sanctuaries were on the wrong chain so I rebuilt the blocks on those and resynced properly. Its something to consider that todays problem was due to sanc rules. It is interesting to note that the Sancs re-memorize the PODC data once every 4 hours right before doing the internal 'exec dcc' command (that is where they try to come to a podc quorum). But I still am seriously considering a feature that erases the chainstate and blocks and resyncs if a node is out of sync for more than an hour (which can be disabled if a user doesnt want it on).
My clients thought they were still current.. so not sure how that rule would help As for the delete/rebuild interesting idea. There is still the oddity of when you do that, the PODC key seems to get lost until you re-start the client. I'm guessing the scanning routine isn't looking for/updating the key info when it gets to that part of the blockchain. (just a guess, since I have not looked into it really) I've done it several times and gotten the unable to sign cpid error. |
|
|
|
Everyone, please check your POW difficulty. If its less than 1000, you may be on a fork.
If so, please delete your blocks and chainstate folder and restart.
Curious what caused it |
|
|
|
BiblePay
1.1.4.4 - Leisure Upgrade
- Implemented faster boot time (90% faster on Linux, 40% faster on windows); Note that the first cold boot will be approx. 50% faster, then successive cold boots 90% faster on linux.
- Ensure PODC updates transmit for both Rosetta and WCG automatically
- Added checkpoint at block 63000
- Checked in MIPs Mac Build Configuration
The download from biblepay.org still seems to be 1.1.3.8 Oddly last night a few of my miners ended up on different forks at block 63828 8c53f3d28f18180a78d8fde6ce2fcb2ecee4f57ac7d3a31297848915f8d1938e 846572421ddf51d629b236f79e6f6af8c8a079baf5e45625c70646ec12d85ba3 Anyone else see this? |
|
|
|
I got my payments on PODC and I am happy  , now i have two questions: 1) Rosseta seems to take a lot of network traffic and space. Question: Do I have to be "boinc"ing at least one station on Rosseta, or can I move all my boinc stations to WCG ? 2) West said in the past that we could use WCG RAC to receive payment from GByte coin. Today GByte coin asks to change WCG user name to be something else. Question: If i would change WCG user name, will it be effecting Biblepay PODC payment ? 1. Rac can be all WCG 2. Username change doesn't matter as long as CPID is the same. gbyte lets you change your userid after association as well |
|
|
|
We've been looking at coinexchange.io for 8 months now, their volume has been showing to be 40% higher than c-cex (back when both were active on coinmarketcap). We don't have other offers... All the junk people are posting here over 24 hours is just spam. It takes time to receive a hard offer from an exchange and verify the offer is not a scam. Remember we got scammed at yobit for .10 recently in the same way. I applied at bitfinex yesterday and we have a ticket inside the bitfinex portal. Znffal is the one who has the master exchange spreadsheet and has been contacting our exchanges. As far as closing quick, we've been replying to them for 4 months and explaining we have been saving up, but they gave us a deadline for the deep discount offer. I see Linda is doing $8100 a day there, thats not bad and not far off of our project. Doge $60,000 a day. Yes I agree on the praying and taking time. I think in this case we were praying they didn't remove the offer as its our only good offer, and our main exchange is always on vacation and we have no other liquidity. Our perspective in the e-mails was that 'coinexchange' was a pretty good exchange. Yours seems to be as if this offer just appeared  , so I think we have a different perspective on this one. No worries, just thought i'd throw my 2c out there. I see what you mean about volume over c-cex. I don't mind discussion on things like this pros/con's help people make an educated decision |
|
|
|
|
a few things concern me about coinexchange.io listing.
Pro: "Terra Nova Coin" appears to be another "charity" coin. But the transaction history appear pump and dump nature ... (giant doji up and all the way back down a few times)
Con: their "highest volume" coin (700k USD) appears to no longer be listed(and no longer exists)
I'm not a sanctuary so I cannot vote.. but this exchange seems desperate for relevancy. I don't see the value in paying 2 BTC for them.
Edit:
I'm a firm believer in taking time and praying before a big decision... The fact that they want to close quick concerns me.
|
|
|
|
Im floating the idea as a lower bar of entry for the 50,000 boinc accounts out there who may want to be compensated for researching but have a strong affinity to the current team. People like the US Navy, Oracle, overclocking forums, etc. <- One downside to doing this is then we lose all sense of organization in our reports for our team (IE the team report becomes pretty worthless) and all statistics become worthless.
Can we pull BOINC user stats by CPID to generate the reports ourselves (and if so, do we have a good reason to do so)? This is related to my post earlier. I'm looking for a good way to pull this data from the client to report out. We can, I just don't seem to have much time to work on anything as of late.. heh |
|
|
|
Im floating the idea as a lower bar of entry for the 50,000 boinc accounts out there who may want to be compensated for researching but have a strong affinity to the current team. People like the US Navy, Oracle, overclocking forums, etc. <- One downside to doing this is then we lose all sense of organization in our reports for our team (IE the team report becomes pretty worthless) and all statistics become worthless.
If Biblepay-central was updated, it could be a good secondary source of data. As it is I would love to get some of the data exports from the RPC to start loading historical charts... |
|
|
|
I see no variation between ours and Dash's... I have isolated the loop that takes the time, I don't see a clear way to optimize it more.
Something of note I placed a counter to capture blocks it processes: blocks processed = 63286
This is 358 blocks more than the chain has currently. I suspect these are "orphan" chains/blocks that need to be accounted for and routed through before settling on the current active.
I will keep digging to see if we can isolate these from the loop and see if it would speed up the process
THANK YOU very much! Looks like we need to go in with a more advanced test harness and see if it has something to do with our block.vtx[n].sTxOutMessage. Those messages are limited to 3000 bytes each, so I didn't expect those to be the issue, but if they are being hashed, it could be part of the delay. Hmm... so revisiting my test showed an error. Apparently the microseconds timestamp is not returning microseconds but milliseconds. This accounts for the odd times of 0ms then a batch of "catchup" time. it seems to process a range of 300-700 blocks per milli-second. will continue testing. The area that is taking 30sec is the boost foreach loop in "bool static LoadBlockIndexDB()" |
|
|
|
biggest traders+buyers is on biggest exchanges .. howgh ..
CB+CCEX+South= fleas in da world
the big trader will never use such an exchange like CB,CCEX,South
Bigger trader wont touch this coin with no liquidity... chicken/egg issue I agree we need to get the word out, we need people actively promoting the coin.. however the current environment is not helping any of the alt's.... people are afraid of the market as a whole, so getting people to invest is going to remain difficult |
|
|
|
Thanks for the stats!
Ive always considered a wallet that is plug and play, like an iphone. We can consider building a plug & play biblepay PODC client.
Cant't help it spent way too much time doing data analytics As for the iPhone comment.. hmm that sounds familiar heh |
|
|
|
THANK YOU very much!
Looks like we need to go in with a more advanced test harness and see if it has something to do with our block.vtx[n].sTxOutMessage. Those messages are limited to 3000 bytes each, so I didn't expect those to be the issue, but if they are being hashed, it could be part of the delay.
I've spent some time isolating the blocks it seems most process in 0 microseconds, but several are 500-1000microseconds. Oddly it doesn't appear to be the same blocks. (2 runs 2 totally separate #'s) ... Will keep digging |
|
|
|
With the recent slump in price, I'm starting to look at ways of popularizing BiblePay.
I'm thinking it might be to our benefit to make it easier to get started as a researcher (for cancer mining) and easier to mine BiblePay.
We could consider removing the team requirement (IE you do not have to be in Team BiblePay for PODC payments); that would potentially open us up to the entire boinc network of World Community Grid and Rosetta researchers who are apprehensive about changing their team. They would still of course need to associate their CPID with our wallet, but they would receive PODC payments without being on our team.
The other idea is making us easier to heat mine. We could potentially allow heat mining for any CPID that is successfully associated with a public key (IE the researcher has successfully sent a burn transaction and is associated with one public key address already). This would make it easier to heat mine as then only one step is required and the user does not need to wait until being in a superblock. It would also make it easier on some people financially to get started.
We may also consider voting for a lower BBP-per-rac requirement, but in my opinion its a little early for that.
Heat mining is owned by a few players currently. CPID: 6d3cf73125be19efe95f073575990d70 count: 24(11% of total) Reward: 11720 Avg Time: 6.2611111111111 CPID: 684b644e09134455f34639d65bea3851 count: 18(8% of total) Reward: 8753 Avg Time: 7.9842592592593 CPID: 8aee6972dd6958234c4d813978e2ee20 count: 13(6% of total) Reward: 6403 Avg Time: 4.6294871794872 CPID: 373e215c0c0d3df1908ebf607a966cb8 count: 12(5% of total) Reward: 5849 Avg Time: 13.330555555556 CPID: e37d18242f0467a0694bb4fe98a7377c count: 12(5% of total) Reward: 5781 Avg Time: 13.245833333333 CPID: 1df2bd274f38f6e1956445a928180443 count: 11(5% of total) Reward: 5286 Avg Time: 7.7757575757576 CPID: bdaea08ab3f1971aacb9ba4bc2171953 count: 11(5% of total) Reward: 5380 Avg Time: 4.7 #1 cycles up and down the list a bit, he had 25/12% earlier today Also pools seem to be out of favor: Pool Results PurePool : 38 (18%) 18525 BBP Pool : 22 (10%) 10756 Solo Mining : 148 (71%) 72037 (these stats are from the last 207 blocks) I like the idea of opening things up a bit. The question is which path, and realizing the dilution of the current rewards further. Though Ideally the price would go up with adoption to help offset it. |
|
|
|
TheSnat, I believe your txlist filter worked, but we still have relatively slow "LoadBlockIndex" times during the initial wallet load for only 60,000 blocks.
I'll take care of looking into optimizing the later phase of "Memorizing Prayers" myself, but one thing you may be able to help on is take a look at LoadBlockIndexGuts and see if there is something in there slowing down the load time. Its taking about 30 seconds to perform the LoadBlockIndex phase itself, before moving on to memorizeprayers, so I think maybe you can put a test harness on that piece and see what piece of data inside that function is actually slowing down each loop.
To my knowledge we havent veered from Dash's load block index guts - except we have our transaction.vout[n].sTxOutMessage on each transaction (which stores our prayers and podc information).
I see no variation between ours and Dash's... I have isolated the loop that takes the time, I don't see a clear way to optimize it more. Something of note I placed a counter to capture blocks it processes: blocks processed = 63286 This is 358 blocks more than the chain has currently. I suspect these are "orphan" chains/blocks that need to be accounted for and routed through before settling on the current active. I will keep digging to see if we can isolate these from the loop and see if it would speed up the process |
|
|
|
Bitcoin is in a bear market. As a trader, you wouldn't want to have too much exposure in a BTC bear. It's dragging down the Alts. C-Cex re-opening at the end of August should help some.
The other thing to do, which I have said, is to go directly to the churches and tell them that by buying BBP they are supporting orphans. The buyers are the ones who support the orphans. Whenever I have mentioned going directly to the churches everyone is just not into that idea. But if you want a consistent bid under BBP, I think that is the way to go.
It's obvious the volume from the latest superblock hasn't come through the exchanges in a big way; cumulative volume has barely been over 1M.
Agreed the current market is not helping us any.. Strange though DOGE can keep its price fairly stable, but BBP is declining steadily. Hope this trend reverses soon |
|
|
|
Thanks for reply! hers the boinc info. 
{
"Command": "getboincinfo",
"CPID": "f960331937adb4c3b47d4b8e147e3f8d",
"Address": "BBFfgmZhTdNXPYzk7hZnYA9j27mCSZVYB1",
"CPIDS": "f960331937adb4c3b47d4b8e147e3f8d;",
"CPID-Age (hours)": 425903,
"NextSuperblockHeight": 62330,
"NextSuperblockBudget": 1110119,
"f960331937adb4c3b47d4b8e147e3f8d_ADDRESS": "BBFfgmZhTdNXPYzk7hZnYA9j27mCSZVYB1",
"f960331937adb4c3b47d4b8e147e3f8d_RAC": 1216.02,
"f960331937adb4c3b47d4b8e147e3f8d_TEAM": 15044,
"f960331937adb4c3b47d4b8e147e3f8d_WCGRAC": 0,
"f960331937adb4c3b47d4b8e147e3f8d_TaskWeight": 100,
"f960331937adb4c3b47d4b8e147e3f8d_UTXOWeight": 2998,
"Total_RAC": 1216.02,
"Total Payments (One Day)": 0,
"Total Payments (One Week)": 0,
"Total Budget (One Day)": 1110119,
"Total Budget (One Week)": 7821551,
"Superblock Count (One Week)": 8,
"Superblock Hit Count (One Week)": 8,
"Superblock List": "62125,61920,61715,61510,61305,61100,60895,60690",
"Last Superblock Height": 62125,
"Last Superblock Budget": 1110119,
"Last Superblock Payment": 0,
"Magnitude (One-Day)": 0,
"Magnitude (One-Week)": 0
}
No problem. Looks like you have RAC, and stake, I would slow down your PODC until you get more BBP stake, right now you're at the 20% bucket. if you go higher than 3700 RAC you will be too low for a payment with that stake. You have 4 podcupdate's, so if things continue you should be in tomorrows superblock, then able to help in POBH mining. |
|
|
|
So i have installed Biblepay and boinc/rosetta@home on one of my computers, pointed at purepool. Not sure why i cant get it to work, as far as i can tell i have followed all the steps in the mining guide. Any help would be appreciated Until you have RAC, and BBP Stake, and have been in a superblock payment you will get the illegal cpid error post the results of "exec getboincinfo" and we can guide you a bit better |
|
|
|
|
Show Posts
