BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes)

[capulo]

Anyone have trouble installing Ubuntu with GUI on HP Proliants G6's? Upon boot I get a frozen purple screen. Only Ubuntu headless seems to work...Tried nomodeset but didn't seem to work .

which version? i had ubuntu 16.04 without problems, doesn't matter if G6, G7 or G8...

[tybiboune]

Hey!

I'm trying to update the core from last github update, but when I finally execute "make", the server is stuck at 'CXX    libbitcoin_server_a-kjv.o"

Is it normal to wait for ages? The server is with Ubuntu 18, with a 2 Ghz 1 cpu proc and 1.7 Go RAM. Not very powerful, but I wanted to use some spare resources..

And it worked for the previous version, but I'm not sure it took so long.

Thanks for your help!

[MIP]

Hey!

I'm trying to update the core from last github update, but when I finally execute "make", the server is stuck at 'CXX    libbitcoin_server_a-kjv.o"

Is it normal to wait for ages? The server is with Ubuntu 18, with a 2 Ghz 1 cpu proc and 1.7 Go RAM. Not very powerful, but I wanted to use some spare resources..

And it worked for the previous version, but I'm not sure it took so long.

Thanks for your help!

With less than 2GB it can take like 15 minutes or more, that's normal.

[tybiboune]

Hi!
I'm having a weird error message now, on my main server (where I installed boinc & biblepay)...

when I type boinccmd --client_version

I get an "Authorization failure: -155"

Everything was working fine till now

Ive never seen that , so it probably has something to do with invalid cached boinc credentials.
Could you try installing "boincmgr" (the boinc gui) on your box, and launching it?  It should reveal any errors and also allow you to see your RAC per project visually.

https://boinc.berkeley.edu/dev/forum_thread.php?id=12288#84632

The auth failure -155 means you need to pass the --passwd on the boinccmd command line - see Boinccmd tool:

"Otherwise you need to supply (as password) the string stored in the file gui_rpc_auth.cfg in the client's data directory. If you run boinccmd remotely you also need to configure the client to accept remote control."

Most common reason is that you changed your password and your weak-key changed.

I would first try this:

/usr/bin/boinccmd --project_attach http://boinc.bakerlab.org/rosetta/ your-weak-key
/usr/bin/boinccmd --project_attach http://www.worldcommunitygrid.org  your-weak-key

your-weak-key for Rosetta@Home: https://boinc.bakerlab.org/rosetta/weak_auth.php
your-weak-key for WCG: https://www.worldcommunitygrid.org/ms/viewMyProfile.do

I'm hoping project can re-attach with new weak-key. If that doesn't work, you may need to detach and re-attach.
this will kill your tasks in progress, so I suggested above first:

boinccmd --project http://boinc.bakerlab.org/rosetta/ detach
boinccmd --project http://www.worldcommunitygrid.org detach

above command may need to be https (secure) instead of http

Remember, there is alternative potential live help from community on discord (https://discord.gg/RK8n4xh) and telegram (https://t.me/biblepay_airdrop)

[jaapgvk]

About the OP:

I think that the exchanges can be updated. Coinsmarkets is definitely gone, so that can be removed. Coinsexchange and Cryptobridge can be added with the following links:

https://www.coinexchange.io/market/BBP/BTC
https://wallet.crypto-bridge.org/market/BRIDGE.BBP_BRIDGE.BTC

[zthomasz]

I have a few questions about the masternode guide "Create Sanctuary 2" at http://wiki.biblepay.org/Create_Sanctuary_2

1) Steps 2b and 2c (in PART E below) seem redundant. Are both steps required?

2) From where does the control wallet get the masternode outputs info in step 4.a and what could cause it NOT to generate a TRANSACTIONHASH & INDEX string?

3) Following the steps in PART E below, at what point is the 1550001 BBP locked?

4) I try to start a new masternode in MISSING status from the Win control wallet but get this Error: Could not allocate txin (TRANSACTION HASH & INDEX string) for masternode (IP:40000). Also the remote linux/vps command ./biblepay-cli masternode status returns the following:

"vin": "CTxIn(COutPoint(0000000000000000000000000000000000000000000000000000000000000000, 4294967295), coinbase )",
  "service": "51.15.224.106:40000",
  "status": "Not capable masternode: Masternode not in masternode list"

--------------------------------------------------------------------

PART E - Financing your Sanctuary (Masternode)

1. Generate private key on Sanctuary remote Linux machine

 ./biblepay-cli masternode genkey

(Store this as your SANCTUARY_PRIVATE_KEY)


2. Local Windows Controller Wallet - Show Proof of Coins

Create a unique name (SANCTUARY_NAME) for the address you will be storing your coins in
and send the required 1,550,001 coins to that address


2a. Create Masternode Coin Address with Label

Tools >> Debug Console

 getaccountaddress SANCTUARY_NAME

this creates your SANCTUARY_ADDRESS

getaccountaddress: https://chainquery.com/bitcoin-api/getaccountaddress


2b. Combine All Your Coins into One Address

File >> Receiving Addresses >> Right click Copy Address (this is your RECEIVING_ADDRESS)
Send all of your wallet coins to this one address

Tools >> Debug Console

   sendtoaddress RECEIVING_ADDRESS 1550001 "" ""

sendtoaddress: https://chainquery.com/bitcoin-api/sendtoaddress


2c. Send Required Coins to Newly Created SANCTUARY_ADDRESS from step 2a

Enable Coin Control: Settings >> Options >> Wallet >> Click "Enable coin control features" checkbox >> Ok

Send >> Inputs >> Click Checkboxes of which Address(es) to Send Coins From

Send exactly 1550001 coins

NOTE: Fees are OK as long as you dont click the checkbox to Subtract fees. Fees are stored in a different vector
NOTE: Important thing is to make the amount exactly 1550001 and dont click instant send or any other options
NOTE: Coin Control will allow you to send coins from a specific address and not move coins you already set aside in other addresses
https://www.dash.org/forum/threads/how-to-send-1000-dash-from-a-specific-address-in-the-wallet.15926/


2d. Record Transaction Hash

Open the Explorer: https://biblepay-explorer.org/
Enter in your SANCTUARY_ADDRESS
Record Latest Hash for your 1,550,001 deposit (TRANSACTIONHASH)

3. Wait for 7-8 or so confirmations (at 7 minute block rate, that will be around 1 hour)


4.a Controller Windows Wallet - Get TRANSACTIONHASH and INDEX from running this command:
Tools >> Debug Console

 masternode outputs

You will get a string that looks like this:

 {
 "06e38868bb8f9958e34d5155437d009b72dff33fc28874c87fd42e51c0f74fdb" : "0",
 }

The long string is your TRANSACTIONHASH, and the last number is the INDEX.

[togoshigekata]

BiblePay_Masternode_Guide_MN_REMIX.pdf
https://ufile.io/d03sh
written by 616west!

I think his guide is more concise and user friendly

1. Agree
The rest I have no idea haha

If you think anything needs an edit, I say go for it!
We need more people reviewing, editing and refining all our documentation and messaging!

[slovakia]

zthomas that guidelines is horrible   and im terrified that still exists
exists step by step easy 1 minutes tutorial for MN

[bible_pay]

I have a few questions about the masternode guide "Create Sanctuary 2" at http://wiki.biblepay.org/Create_Sanctuary_2

1) Steps 2b and 2c (in PART E below) seem redundant. Are both steps required?

2) From where does the control wallet get the masternode outputs info in step 4.a and what could cause it NOT to generate a TRANSACTIONHASH & INDEX string?

3) Following the steps in PART E below, at what point is the 1550001 BBP locked?

4) I try to start a new masternode in MISSING status from the Win control wallet but get this Error: Could not allocate txin (TRANSACTION HASH & INDEX string) for masternode (IP:40000). Also the remote linux/vps command ./biblepay-cli masternode status returns the following:

"vin": "CTxIn(COutPoint(0000000000000000000000000000000000000000000000000000000000000000, 4294967295), coinbase )",
  "service": "51.15.224.106:40000",
  "status": "Not capable masternode: Masternode not in masternode list"

--------------------------------------------------------------------

PART E - Financing your Sanctuary (Masternode)

1. Generate private key on Sanctuary remote Linux machine

 ./biblepay-cli masternode genkey

(Store this as your SANCTUARY_PRIVATE_KEY)


2. Local Windows Controller Wallet - Show Proof of Coins

Create a unique name (SANCTUARY_NAME) for the address you will be storing your coins in
and send the required 1,550,001 coins to that address


2a. Create Masternode Coin Address with Label

Tools >> Debug Console

 getaccountaddress SANCTUARY_NAME

this creates your SANCTUARY_ADDRESS

getaccountaddress: https://chainquery.com/bitcoin-api/getaccountaddress


2b. Combine All Your Coins into One Address

File >> Receiving Addresses >> Right click Copy Address (this is your RECEIVING_ADDRESS)
Send all of your wallet coins to this one address

Tools >> Debug Console

   sendtoaddress RECEIVING_ADDRESS 1550001 "" ""

sendtoaddress: https://chainquery.com/bitcoin-api/sendtoaddress


2c. Send Required Coins to Newly Created SANCTUARY_ADDRESS from step 2a

Enable Coin Control: Settings >> Options >> Wallet >> Click "Enable coin control features" checkbox >> Ok

Send >> Inputs >> Click Checkboxes of which Address(es) to Send Coins From

Send exactly 1550001 coins

NOTE: Fees are OK as long as you dont click the checkbox to Subtract fees. Fees are stored in a different vector
NOTE: Important thing is to make the amount exactly 1550001 and dont click instant send or any other options
NOTE: Coin Control will allow you to send coins from a specific address and not move coins you already set aside in other addresses
https://www.dash.org/forum/threads/how-to-send-1000-dash-from-a-specific-address-in-the-wallet.15926/


2d. Record Transaction Hash

Open the Explorer: https://biblepay-explorer.org/
Enter in your SANCTUARY_ADDRESS
Record Latest Hash for your 1,550,001 deposit (TRANSACTIONHASH)

3. Wait for 7-8 or so confirmations (at 7 minute block rate, that will be around 1 hour)


4.a Controller Windows Wallet - Get TRANSACTIONHASH and INDEX from running this command:
Tools >> Debug Console

 masternode outputs

You will get a string that looks like this:

 {
 "06e38868bb8f9958e34d5155437d009b72dff33fc28874c87fd42e51c0f74fdb" : "0",
 }

The long string is your TRANSACTIONHASH, and the last number is the INDEX.

This one is pretty easy if your more of IT geek:

http://wiki.biblepay.org/Create_Sanctuary


Let us know what specific issue you have while going through this one.  I think one of the pitfalls in the easy to use guide is people are confused what computer they are on.

[bible_pay]

Guys/Girls,

I have to ask everyone to entertain this idea;  I know the last time I mentioned this I encountered a little resistance (I think from a small group of miners who might be set in their ways because they have a high amount staked in PODC currently), but regardless of the political situation here at Biblepay I have to do what I think is best for our orphans.  We have 329 orphans sitting at risk currently with a questionable future.  I not only want to avoid attrition, I want to see growth! 

So heres an idea.  I really think we need to consider removing all the roadblocks inside Biblepay (IE Opening the Floodgates) for cancer mining.  We can consider doing this by:  Removing the Boinc team requirement (being the first cryptocurrency to not require a team for boinc), and making it easier to heat-mine.  (IE doing away with the last 4 block rule).  (We can leave in the signed by CPID rule as a lateral move preserving heat-mining security).

I feel with this change, we can test the theory that more miners = more adoption = higher price = more monthly orphan sponsorships.

To make this fair, what we could do is adopt this strategy for 6 months, and if it fails miserably, we can vote to come back to a Biblepay team structure.

Also, as Noxpost suggested, I dont see why we cant write our own boincstats report (as we will still have records of our Biblepay participating CPIDs, RAC, TotalRAC etc).  So we really only lose the "BiblePay BOINC Team" statistics in boincstats, but instead we have our own stats page.  Maybe that internal stats website is something T-Mike would like to take on for us?

So, as you can see I'm pretty zealous for success here, and want us to make a comeback.  Therefore I believe its in our best interests to vote on this change.

In light of this, I will create a Sanctuary vote proposal for this idea.

If it passes, we would shoot for the changes being in our next mandatory around the end of September.  However we would shoot for testing these changes in testnet in 14 days.

(On a side note, if this is passing we will take the opportunity to do some extra refactoring of the heat-mining-block-acceptor to help prevent future forks).

[bible_pay]

Please see this thread regarding Opening the BiblePay Floodgates to All BOINC Users crunching Rosetta Or WCG:

https://forum.biblepay.org/index.php?topic=246.msg4142#msg4142

[slovakia]

liquidity of BBP is 0$€   bye bye orphans next month and may be BBP too

more miners = more adoption = higher price = more monthly orphan sponsorships=    delusion




All,

  We have 329 orphans sitting at risk currently with a questionable future.  I not only want to avoid attrition, I want to see growth! 

So heres an idea.  I really think we need to consider removing all the roadblocks inside Biblepay (IE Opening the Floodgates) for cancer mining.  We can consider doing this by:  Removing the Boinc team requirement (being the first cryptocurrency to not require a team for boinc), and making it easier to heat-mine.  (IE doing away with the last 4 block rule).  (We can leave in the signed by CPID rule as a lateral move preserving heat-mining security).

I feel with this change, we can test the theory that more miners = more adoption = higher price = more monthly orphan sponsorships.

Also, as Noxpost suggested, I dont see why we cant write our own boincstats report (as we will still have records of our Biblepay participating CPIDs, RAC, TotalRAC etc).  So we really only lose the "BiblePay BOINC Team" statistics in boincstats, but instead we have our own stats page.  Maybe that internal stats website is something T-Mike would like to take on for us?

So, as you can see I'm pretty zealous for success here, and want us to make a comeback.  Therefore I believe its in our best interests to vote on this change.

Proposed Changes:

- Remove Boinc Team Requirement for users participating in BiblePay PODC (this compensates users for Rosetta or World Community Grid on ANY team)
- Refactor Heat Mining Block acceptor to help minimize the possibility of forks
- Remove the N-4 block rejection rule requiring a distinct CPID for each block (but leave in requirement to have a signed CPID in the block solution)
- Work with a team member to help create our own stats report for a website and/or the pool
- ** Remove the UTXO stake requirement for magnitudes less than ONE.  Require the existing Stake Requirement for magnitudes GREATER than ONE ** (This means that general home users with a few PCs can potentially get started for FREE with BiblePay.  Power users/abusers who have many servers still need to stake a utxo to prevent biblepay from being overrun by massive single users).

Desired Outcome:

- A new boinc user who is crunching for XYZ discovers they can be compensated for Rosetta cancer mining through Biblepay.
 The new user loads our wallet, syncs, and associates their XYZ cpid with our wallet.  (TODO: Investigate a free burn transaction so they get started for FREE; not necessarily sure if FREE is completely possible due to the minimum transaction fee but if not they can start with 1 bbp.)
- The user is inducted into the next superblock within 24 hours.
- The user is able to heat mine with the signed cpid immediately, as long as the CPID has RAC > 100.

This removes most of the strange pool errors in pool.biblepay.org and purepool.


This allows users to migrate from any boinc team who know nothing about crypto and be compensated in our superblocks, and may allow the user to start for free.

One notion is that in general, I assume BOINC users to have enough disposable income to afford expensive computers for volunteer computing, therefore I come to the conclusion they may become biblepay investors through this process.

And, to counter the theory that we are "giving away free money", consider the fact that the ones who do not become investors will sell off the coins cheap on the market and make us more rare.  So imo, this is an economic decision worth considering.

If the idea is a success, all credit to Jesus.

[togoshigekata]

Better sell all your BBP coins quick Slovakia! Before they crash in value even more!

[slovakia]

Increase advertising, marketing, and Public Relations effort

togo= our PR manager ... funnyboy from usa ... hahahaha ... you dont know nothing about PR and getting BBP for nothing ..... go away from BBP pls.....how old are you? 20-22? little boy

[capulo]

i'm in, we can try it
i just not agree for removing stake for magnitudes below 1. magnitude 1= about 10k rac now, this is far above 'some home pc'. dual x5650 (24 core) can do 13k rac. so this can end with splitting accounts into small ones and putting one powerfull pc to 1 account without staking.
and over time, more users = lower magnitude with same rac, so more powerfull pc can be included to account below 1mag. who can afford powrfull pc, can also buy bbp...
in my opinion, it should be rac, not mag. about 5000 rac is enough (some older 4c/8t i7 pc, running 24/7). this will also prevent creating many accounts with 1 pc as better PCs will needs more accounts and it will be harder to maintain (but still possible )

[slovakia]

capulo=  spravim 20 uctov s x5650 a hotovo

Increase advertising, marketing, and Public Relations effort
+we need reduce number of children sponsored

[capulo]

slovakia, ved presne o tom pisem ze to takto dopadne 1 mag je priliz vela, ak bude treba kuskova tmasinu tak sa na to radsej vyprdnem a dam tam ten stake bo sa mi s tym nebude chciet babrat

[bible_pay]

i'm in, we can try it
i just not agree for removing stake for magnitudes below 1. magnitude 1= about 10k rac now, this is far above 'some home pc'. dual x5650 (24 core) can do 13k rac. so this can end with splitting accounts into small ones and putting one powerfull pc to 1 account without staking.
and over time, more users = lower magnitude with same rac, so more powerfull pc can be included to account below 1mag. who can afford powrfull pc, can also buy bbp...
in my opinion, it should be rac, not mag. about 5000 rac is enough (some older 4c/8t i7 pc, running 24/7). this will also prevent creating many accounts with 1 pc as better PCs will needs more accounts and it will be harder to maintain (but still possible )

I like your reasoning.  I'll modify the proposal to be for a RAC threshhold instead.  We can make a network spork for 'racthreshhold'.  If the proposal passes we set it to 15000 RAC.  The main reason I like RAC better from an IT perspective is the magnitude assessment algorithm has a better idea about RAC than magnitude in the creation phase so this is a more superior solution.

If RAC < 15000, no UTXO required for our users.

[bible_pay]

Is anyone here a DASH user?

I'm considering that we tighten down requirements for sanctuaries running watchman on the wall.

Could you please run this spork in DASH prod and let us know what the value is for this:

From the rpc type:
spork show:
Paste value of : SPORK_14_REQUIRE_SENTINEL_FLAG

[togoshigekata]

Is anyone here a DASH user?

I'm considering that we tighten down requirements for sanctuaries running watchman on the wall.

Could you please run this spork in DASH prod and let us know what the value is for this:

From the rpc type:
spork show:
Paste value of : SPORK_14_REQUIRE_SENTINEL_FLAG

I have a DASH wallet

Code:

spork show

{
  "SPORK_2_INSTANTSEND_ENABLED": 0,
  "SPORK_3_INSTANTSEND_BLOCK_FILTERING": 0,
  "SPORK_5_INSTANTSEND_MAX_VALUE": 2000,
  "SPORK_6_NEW_SIGS": 4000000000,
  "SPORK_8_MASTERNODE_PAYMENT_ENFORCEMENT": 0,
  "SPORK_9_SUPERBLOCKS_ENABLED": 0,
  "SPORK_10_MASTERNODE_PAY_UPDATED_NODES": 4000000000,
  "SPORK_12_RECONSIDER_BLOCKS": 0,
  "SPORK_14_REQUIRE_SENTINEL_FLAG": 4000000000
}

Github:
https://github.com/dashpay/dash/blob/master/src/spork.cpp#L28