bible_pay (OP)
Full Member
Offline
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
|
|
July 09, 2018, 03:07:54 PM |
|
How long will the previous BiblePay Official thread be available?
It's a great resource, would be nice to have ongoing access to it.
I don't think it will be deleted for at least 5 years, but its up to the policies of btctalk. We will try to leave it here forever.
|
|
|
|
zthomasz
Member
Offline
Activity: 489
Merit: 12
|
|
July 09, 2018, 04:10:18 PM |
|
I'm trying to write an orphan letter at pool.biblepay.org. After clicking on "Save" a window pops up with "Record Not Updated: Sorry, you are not authorized to edit this message." Am I missing something?
|
|
|
|
jaapgvk
|
|
July 09, 2018, 04:18:07 PM |
|
I'm trying to write an orphan letter at pool.biblepay.org. After clicking on "Save" a window pops up with "Record Not Updated: Sorry, you are not authorized to edit this message." Am I missing something?
Could you try logging out and in again?
|
|
|
|
zthomasz
Member
Offline
Activity: 489
Merit: 12
|
|
July 09, 2018, 05:32:48 PM |
|
I'm trying to write an orphan letter at pool.biblepay.org. After clicking on "Save" a window pops up with "Record Not Updated: Sorry, you are not authorized to edit this message." Am I missing something?
Could you try logging out and in again? That worked, thanks Jaap!
|
|
|
|
jaapgvk
|
|
July 09, 2018, 06:07:45 PM |
|
I have a question about C-CEX: they didn't update their wallet (because of their vacation-schedule). But what happens when you try to deposit BBP after block 57700? Will the C-CEX wallet be on a fork from that block on?
|
|
|
|
bible_pay (OP)
Full Member
Offline
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
|
|
July 09, 2018, 08:27:06 PM |
|
** CCEX VACATION UPDATE **
Withdraws are open temporarily!
|
|
|
|
bible_pay (OP)
Full Member
Offline
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
|
|
July 09, 2018, 08:29:37 PM Last edit: July 09, 2018, 08:40:39 PM by bible_pay |
|
I have a question about C-CEX: they didn't update their wallet (because of their vacation-schedule). But what happens when you try to deposit BBP after block 57700? Will the C-CEX wallet be on a fork from that block on?
I did skype him the details (although they are unconfirmed), but usually what happens is he will at least put us in maintenance before that block. However since we gave the appropriate notice they might upgrade us while on vacation. If the wallet is not upgraded after 57,700 please post emergency message here and I will bombard messages to put us in maintenance (as at that point, ccex would be on a fork). Note that any user can also help by going into the trollbox and asking us to be put in maintenance. EDIT: Looks like they are on 1124. You can see the version on the top right but need to remove the 0's from the number. EDIT2: I successfully entered a ticket...
|
|
|
|
jaapgvk
|
|
July 09, 2018, 08:42:31 PM |
|
I have a question about C-CEX: they didn't update their wallet (because of their vacation-schedule). But what happens when you try to deposit BBP after block 57700? Will the C-CEX wallet be on a fork from that block on?
I did skype him the details (although they are unconfirmed), but usually what happens is he will at least put us in maintenance before that block. However since we gave the appropriate notice they might upgrade us while on vacation. If the wallet is not upgraded after 57,700 please post emergency message here and I will bombard messages to put us in maintenance (as at that point, ccex would be on a fork). Note that any user can also help by going into the trollbox and asking us to be put in maintenance. EDIT: Looks like they are on 1124. You can see the version on the top right but need to remove the 0's from the number. EDIT2: I'll start telling him now its an emergency to take us down... Thx! Yes, I noticed that they were still on 1124. That's why I was wondering what would happen if they didn't upgrade before block 57700. I hope that they react fast enough to your messages. Or else we'll have to raid the trollbox I suppose.
|
|
|
|
noxpost
Jr. Member
Offline
Activity: 235
Merit: 3
|
|
July 09, 2018, 10:00:27 PM |
|
I'm sure the C-CEX wallet issue will get resolved, but I took advantage of the open window to pull my BBP before any "weirdness" with a potential on-exchange fork. I'm looking forward to trying Crypto-Bridge out with those reserved funds!
|
|
|
|
togoshigekata
|
|
July 09, 2018, 11:01:23 PM |
|
For my Sanctuary, I added this cron job to stop and reindex every 3 hours crontab -e 0 */3 * * * /home/biblepay/src/biblepay-cli stop; /home/biblepay/src/biblepayd -reindex > /dev/null 2>&1 I was using the && symbol, but sometimes biblepay had already crashed and the stop command would fail, so I started using the ; symbol: A; B # Run A and then B, regardless of success of A A && B # Run B if and only if A succeeded A || B # Run B if and only if A failed A & # Run A in background. And I enabled shrinkdebuglog in the config: cd ~/.biblepaycore && vi biblepay.conf shrinkdebuglog=1 Not sure if reindexing every few hours is the best strategy, but I think it will work, is it bad to be reindexing all the time?, I also feel kind of bad limiting the log file, because now any bugs in the log may get erased, curious what you guys think and what strategys you guys have to make sure your sanctuary is always running
|
|
|
|
bible_pay (OP)
Full Member
Offline
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
|
|
July 10, 2018, 12:25:36 AM |
|
For my Sanctuary, I added this cron job to stop and reindex every 3 hours crontab -e 0 */3 * * * /home/biblepay/src/biblepay-cli stop; /home/biblepay/src/biblepayd -reindex > /dev/null 2>&1 I was using the && symbol, but sometimes biblepay had already crashed and the stop command would fail, so I started using the ; symbol: A; B # Run A and then B, regardless of success of A A && B # Run B if and only if A succeeded A || B # Run B if and only if A failed A & # Run A in background. And I enabled shrinkdebuglog in the config: cd ~/.biblepaycore && vi biblepay.conf shrinkdebuglog=1 Not sure if reindexing every few hours is the best strategy, but I think it will work, is it bad to be reindexing all the time?, I also feel kind of bad limiting the log file, because now any bugs in the log may get erased, curious what you guys think and what strategys you guys have to make sure your sanctuary is always running Sounds like overkill for something that happens once every few months. Its not that reindexing is bad for the disk, its something that you frankly should never need to do, unless you were forked after a mandatory. In my case I have a reboot.sh file that reboots all my sancs and an upgrade.sh (that does the git pull origin master && make). I just run the script once every few months if more than 10% of my sancs die. In general I only lose one node every 30 days or so, so that has worked for me and in my case I dont see a need to change it. I dont even restart the single nodes, they keep running without a monitor script. Im using the $5 vultr ubuntu 64 bit. Maybe you are reacting to the high logging issue once per month and treating it as a regular occurrence. On those days, I kill my debug.log while the node is hot and it keeps running without writing to the debug.log. EDIT: BTW, I run the script from my first sanc, and it SSH's the commands to the other nodes (I dont log in to my other sancs at all for upgrades or for reboots).
|
|
|
|
bible_pay (OP)
Full Member
Offline
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
|
|
July 10, 2018, 02:24:24 AM |
|
I saw two of these vehicles on the highway in central Texas yesterday: https://www.activistpost.com/2016/06/u-n-vehicles-mysterious-troop-movement-spotted-in-va-nc-w-va-ohio.htmlThey were very mysterious looking, these vehicles were brand new - painted with a flat beige - possibly a base for camo. The first thing I thought of when I saw them was Ken Peters (I saw the great tribulation) - what he said back in 1985 about these - except he described them as blue. The only difference between the UN vehicles and the ones I saw were the lights were not blue & red (they were white), and they seemed to have a place for MPs with machine guns to stand on each quadrant. I saw one per tractor trailer, there could have been more, but I had to get off the exit (but I did go out of my way to zoom up and around one and get a good look at it). What do I think these are? I have no clue - something used to round up citizens? (Fema camp roundups, martial law etc ?) But seeing these new leads me to believe these will be used just as Ken Peters said - so please... become more zealous for Jesus. BTW here is the old link for Ken Peters: http://pool.biblepay.org/Action.aspx?link=996d0be
|
|
|
|
togoshigekata
|
|
July 10, 2018, 02:57:31 AM |
|
For my Sanctuary, I added this cron job to stop and reindex every 3 hours crontab -e 0 */3 * * * /home/biblepay/src/biblepay-cli stop; /home/biblepay/src/biblepayd -reindex > /dev/null 2>&1 And I enabled shrinkdebuglog in the config: cd ~/.biblepaycore && vi biblepay.conf shrinkdebuglog=1 Not sure if reindexing every few hours is the best strategy, but I think it will work, is it bad to be reindexing all the time?, I also feel kind of bad limiting the log file, because now any bugs in the log may get erased, curious what you guys think and what strategys you guys have to make sure your sanctuary is always running Sounds like overkill for something that happens once every few months. Its not that reindexing is bad for the disk, its something that you frankly should never need to do, unless you were forked after a mandatory. In my case I have a reboot.sh file that reboots all my sancs and an upgrade.sh (that does the git pull origin master && make). I just run the script once every few months if more than 10% of my sancs die. In general I only lose one node every 30 days or so, so that has worked for me and in my case I dont see a need to change it. I dont even restart the single nodes, they keep running without a monitor script. Im using the $5 vultr ubuntu 64 bit. Maybe you are reacting to the high logging issue once per month and treating it as a regular occurrence. On those days, I kill my debug.log while the node is hot and it keeps running without writing to the debug.log. EDIT: BTW, I run the script from my first sanc, and it SSH's the commands to the other nodes (I dont log in to my other sancs at all for upgrades or for reboots). Woah your setup is awesome! That is really cool! I am such a newbie in comparison, I am manually connecting to each sanctuary with putty, with username/password, and I type or copy paste commands I was unlucky 1-2 days ago, my sanctuaries went EXPIRED, the daemons were running, but they were all stuck at the same block, and the latest block was further ahead, Sounded like others experienced it too, not sure what happened. But yeah typically some of my sanctuaries have issues every now and then. I like your SSH scripting, I am going to try and use that now!
|
|
|
|
Somz1
|
|
July 10, 2018, 03:37:55 AM |
|
Does the '10% orphans' in your title mean that 10% of the supply has been pre-mined or something like that?
|
|
|
|
znffal
|
|
July 10, 2018, 03:48:04 AM |
|
Does the '10% orphans' in your title mean that 10% of the supply has been pre-mined or something like that?
No not pre-mined.It means that every month (at least) 10% of our coins emitted that month are set aside for charity. Often it ends up being more than 10%.
|
|
|
|
jaapgvk
|
|
July 10, 2018, 04:15:23 AM |
|
Does the '10% orphans' in your title mean that 10% of the supply has been pre-mined or something like that?
No not pre-mined.It means that every month (at least) 10% of our coins emitted that month are set aside for charity. Often it ends up being more than 10%. Thinking about it. Maybe the '10% orphans' in the title could be more clear. And the 'Sanctuaries' part is probably a bit overkill (outsiders only know the term 'Masternodes'). Looking at it from the outside again, they wouldn't know that 'POHB' stands for either. Those two terms would be something they would learn about when they start finding out who we are, but it's probably not something that would attract first-time visitors. What IS interesting though, is that we are participating in R@H. First half is crypto-related, second half is about the good we do. So maybe a better title would be something like this: BiblePay | Masternodes | CPU only | Curing diseases | 10% goes to charity Or: BiblePay | Masternodes | ASIC and GPU resistant | Curing diseases | 10% goes to charity
|
|
|
|
jaapgvk
|
|
July 10, 2018, 04:19:49 AM |
|
A few months ago I critiqued the front page of the Biblepay website.
I am very pleased with the recent update. It looks incredible and very professional.
The values of the community are expressed well.
Good job team.
Thank you! It's great to hear from others that our efforts paid off If you have any feedback, just let me know!
|
|
|
|
sunk818
|
|
July 10, 2018, 04:26:49 AM |
|
Does the '10% orphans' in your title mean that 10% of the supply has been pre-mined or something like that?
There is no premine. http://wiki.biblepay.org/Main_Page100% of the BLOCK REWARD IS Distributed the following way:
10% TO CHARITY 10% TO P2P/IT/PR 40% TO MASTERNODES 40% TO MINERS
|
|
|
|
togoshigekata
|
|
July 10, 2018, 04:32:03 AM |
|
Potential Title: ✝ BiblePay|Masternode|CPU Mining|ASIC Resistant|No Premine|10% Charity ✝ I originally found BiblePay searching for the keyword CPU
|
|
|
|
sunk818
|
|
July 10, 2018, 04:43:15 AM |
|
Thinking about it. Maybe the '10% orphans' in the title could be more clear. And the 'Sanctuaries' part is probably a bit overkill (outsiders only know the term 'Masternodes'). Looking at it from the outside again, they wouldn't know that 'POHB' stands for either. Those two terms would be something they would learn about when they start finding out who we are, but it's probably not something that would attract first-time visitors. What IS interesting though, is that we are participating in R@H. First half is crypto-related, second half is about the good we do. So maybe a better title would be something like this: BiblePay | Masternodes | CPU only | Curing diseases | 10% goes to charity Or: BiblePay | Masternodes | ASIC and GPU resistant | Curing diseases | 10% goes to charity Orphan is misleading because Compassion International's current mission is to help poor children. Originally, they helped orphans during the Korean War, but their mission is more broad now. Changing the word orphan to charity is more accurate and allows for sponsoring different kinds of charities in the future. My post title would look something like this: BiblePay | 10% to charity | Masternodes | CPU mining only (PoW, BOINC) I want to emphasize the giving aspect of BiblePay first. We are helping the lives of poor children by giving 10% of the mined BBP block. The technology is also interesting, but should be secondary to helping the poor.
|
|
|
|
|