capulo= spravim 20 uctov s x5650 a hotovo
Increase advertising, marketing, and Public Relations effort
+we need reduce number of children sponsored
Topic: BiblePay | 10% to Orphan-Charity | RANDOMX MINING | Sanctuaries (Masternodes) - page 372. (Read 243454 times)
August 29, 2018, 04:23:56 PM
August 29, 2018, 04:22:08 PM
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 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
) August 29, 2018, 04:21:14 PM
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
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
August 29, 2018, 04:19:29 PM
Better sell all your BBP coins quick Slovakia! Before they crash in value even more!
August 29, 2018, 04:12:51 PM
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.
bye bye orphans next month and may be BBP toomore 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.
August 29, 2018, 03:02:27 PM
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
https://forum.biblepay.org/index.php?topic=246.msg4142#msg4142
August 29, 2018, 02:33:01 PM
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).
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).
August 29, 2018, 11:54:32 AM
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.
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.
August 29, 2018, 11:40:35 AM
zthomas that guidelines is horrible 
and im terrified that still exists
exists step by step easy 1 minutes tutorial for MN
and im terrified that still existsexists step by step easy 1 minutes tutorial for MN
August 29, 2018, 11:36:38 AM
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!
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!
August 29, 2018, 11:20:32 AM
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.
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.
August 29, 2018, 10:48:47 AM
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
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
August 29, 2018, 07:44:43 AM
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
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
Quote
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."
"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)
August 29, 2018, 04:15:36 AM
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!
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.
August 29, 2018, 03:20:54 AM
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!
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!
August 29, 2018, 01:59:24 AM
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... August 29, 2018, 01:51:38 AM
Technical info on how DASH "Blockchain Users" work (DIP 5):
https://github.com/dashpay/dips/blob/master/dip-0005.md
DASH Devs:
https://twitter.com/seiglerj/status/1034553070921822209
https://twitter.com/chuckwilliams37/status/1034583125370724352
https://github.com/dashpay/dips/blob/master/dip-0005.md
DASH Devs:
https://twitter.com/seiglerj/status/1034553070921822209
https://twitter.com/chuckwilliams37/status/1034583125370724352
August 28, 2018, 10:40:45 PM
On Google Chrome, biblepaycore.exe download was unsuccessful. I tried again, it didn't get the message. Strange.
https://support.google.com/chrome/answer/2898334?hl=en&rd=2#virus
Strangely enough, biblepaycore32.exe downloaded okay (1.1.4.7)
When I ran it, I got this message:
Can "Publisher" information become known to Microsoft somehow to help mitigate these warnings?
Quote
Says Failed - Virus scan failed.
https://support.google.com/chrome/answer/2898334?hl=en&rd=2#virus
Strangely enough, biblepaycore32.exe downloaded okay (1.1.4.7)
When I ran it, I got this message:
Quote
Windows protected your PC
Windows Defender SmartScreen prevented an unrecognized app from starting. Running this app might put your PC at risk.
More info
App: biblepaycore32.exe
Publisher: Unknown publisher
Windows Defender SmartScreen prevented an unrecognized app from starting. Running this app might put your PC at risk.
More info
App: biblepaycore32.exe
Publisher: Unknown publisher
Can "Publisher" information become known to Microsoft somehow to help mitigate these warnings?
Trying windows 64 on chrome, it does Not say "Virus scan failed".
August 28, 2018, 10:36:30 PM
post was too long to have both logs in the same post.
valgrind output:
==14110== Memcheck, a memory error detector
==14110== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==14110== Using Valgrup, boost::optional >, boost::signals2::slot1 >, boost::signals2::mutex> > > (result_type_wrapper.hpp:53)
==14111== by 0x335180: operator() (signal_template.hpp:246)
==14111== by 0x335180: operator() (signal_template.hpp:718)
==14111== by 0x335180: ThreadMessageHandler() (net.cpp:1790)
valgrind output:
Code:
==14110== Memcheck, a memory error detector
==14110== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==14110== Using Valgrup, boost::optional
==14111== by 0x335180: operator() (signal_template.hpp:246)
==14111== by 0x335180: operator() (signal_template.hpp:718)
==14111== by 0x335180: ThreadMessageHandler() (net.cpp:1790)
Thanks for the logs!
Unfortunately valgrind has to be run on the actual source file (./biblepay-qt) with the cpp files present on the drive in order for us to see the line # in the report. The log above (debug.log) didnt have the very last shutdown section in it. But please try 1.1.4.7 and see if it solves the problem. We removed the condition that happened this morning for two users.
August 28, 2018, 08:16:15 PM
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 .
Ubuntu 16.0.4 LTS or 18?
Jump to: