We offer dual-hash mining with rewards in both '''BBP + XMR'''.
This is slightly different than merged mining, in that BBP's blocks are now solved with an equation that prevents pre-image attacks (http://wiki.biblepay.org/Preventing_Preimage_Attacks).

In theory, you will receive approximately '''190% more revenue''' for mining
(more specifically, 90% in XMR rewards, and 100% of your hashpower in BBP rewards),
while still contributing 10% to orphan charity.

Each RandomX hash has a full 100% chance of solving a BBP block (or a pool share),
while each RandomX hash still has an equal chance of solving an XMR share.

=== 1. Install Monero Wallet ===

a. https://mymonero.com/

b. Setup seed words and pin

c. Create receiving address ('''YOUR_MONERO_ADDRESS''')

=== 2. Install BiblePay Wallet ===

a. https://www.biblepay.org/wallet/

b. Create receiving address ('''YOUR_BIBLEPAY_ADDRESS''')

File >>> Receiving Address >>> New >>> Ok >>> Right Click >>> Copy Address

or Tools >>> Debug Console >>> Type command: getnewaddress "" >>> Click Enter

=== 3. Download XMRig zip ===

Windows (64-bit): https://github.com/biblepay/xmrig/raw/master/binaries/bbprig.zip

Linux (64-bit): https://github.com/biblepay/xmrig/raw/master/binaries/xmrig-bbp-linux64

Mac: http://www.biblepay.org/xmrig_mac.zip

Source: https://github.com/biblepay/xmrig

a. Create Folder (Example: C:\mining)

b. Copy .zip to new folder and Unzip it

c. Should see a script (batch) file and an executable rig file

=== 4. Edit the script (.bat) file ===

Windows:

./xmrig-bbp-win64.exe -o foundation.biblepay.org:3001 -u='''YOUR_BIBLEPAY_ADDRESS''' -p='''YOUR_MONERO_ADDRESS''' --threads 4

Linux:

./xmrig -o foundation.biblepay.org:3001 -u='''YOUR_BIBLEPAY_ADDRESS''' -p='''YOUR_MONERO_ADDRESS''' --threads 4

'''NOTE:''' Change number of threads to what works best for your machine

'''OPTIONAL:''' Can add '''.YOUR_WORKER_NAME''' to end of '''YOUR_MONERO_ADDRESS''', it adds your cpu information per worker to xmrig

./xmrig -o foundation.biblepay.org:3001 -u='''YOUR_BIBLEPAY_ADDRESS''' -p='''YOUR_MONERO_ADDRESS.YOUR_WORKER_NAME''' --threads 4

=== 5. Pools ===

https://miningpoolstats.stream/biblepay

==== Pool Source Code ====

https://github.com/biblepay/foundation 
https://forum.biblepay.org/index.php?topic=517.msg7288#msg7288

=== 6. Giveaway ===

https://forum.biblepay.org/index.php?topic=503

=== 7. Mining Profit Calculator ===

https://foundation.biblepay.org/MiningCalculator

=== What is RandomX? ===

https://www.publish0x.com/passive-income-crypto/what-is-randomx-monero-s-mining-algorithm-xwkdqm

=== Get Community Help / Support ===

Forum: https://forum.biblepay.org/ 
Discord: https://discordapp.com/invite/yWgbKdM 
Telegram: https://t.me/biblepay_airdrop/ 
Reddit: https://www.reddit.com/r/BiblePay/ 
Email: rob@biblepay.org 

=== References ===
https://wiki.biblepay.org/Upgrade_to_RandomX 
https://foundation.biblepay.org/GettingStarted 
https://bitcointalk.org/index.php?topic=5226080

RandomX Setup

2020-05-31T14:20:55Z

Togoshigekata: Added support links and RandomX article link

We offer dual-hash mining with rewards in both '''BBP + XMR'''.
This is slightly different than merged mining, in that BBP's blocks are now solved with an equation that prevents pre-image attacks (http://wiki.biblepay.org/Preventing_Preimage_Attacks).

In theory, you will receive approximately '''190% more revenue''' for mining
(more specifically, 90% in XMR rewards, and 100% of your hashpower in BBP rewards),
while still contributing 10% to orphan charity.

Each RandomX hash has a full 100% chance of solving a BBP block (or a pool share),
while each RandomX hash still has an equal chance of solving an XMR share.

=== 1. Install Monero Wallet ===

a. https://mymonero.com/

b. Setup seed words and pin

c. Create receiving address ('''YOUR_MONERO_ADDRESS''')

=== 2. Install BiblePay Wallet ===

a. https://www.biblepay.org/wallet/

b. Create receiving address ('''YOUR_BIBLEPAY_ADDRESS''')

File >>> Receiving Address >>> New >>> Ok >>> Right Click >>> Copy Address

or Tools >>> Debug Console >>> Type command: getnewaddress "" >>> Click Enter

=== 3. Download XMRig zip ===

Windows (64-bit): https://github.com/biblepay/xmrig/raw/master/binaries/bbprig.zip

Linux (64-bit): https://github.com/biblepay/xmrig/raw/master/binaries/xmrig-bbp-linux64

Mac: http://www.biblepay.org/xmrig_mac.zip

Source: https://github.com/biblepay/xmrig

a. Create Folder (Example: C:\mining)

b. Copy .zip to new folder and Unzip it

c. Should see a script (batch) file and an executable rig file

=== 4. Edit the script (.bat) file ===

Windows:

./xmrig-bbp-win64.exe -o foundation.biblepay.org:3001 -u='''YOUR_BIBLEPAY_ADDRESS''' -p='''YOUR_MONERO_ADDRESS''' --threads 4

Linux:

./xmrig -o foundation.biblepay.org:3001 -u='''YOUR_BIBLEPAY_ADDRESS''' -p='''YOUR_MONERO_ADDRESS''' --threads 4

'''NOTE:''' Change number of threads to what works best for your machine

'''OPTIONAL:''' Can add '''.YOUR_WORKER_NAME''' to end of '''YOUR_MONERO_ADDRESS''', it adds your cpu information per worker to xmrig

./xmrig -o foundation.biblepay.org:3001 -u='''YOUR_BIBLEPAY_ADDRESS''' -p='''YOUR_MONERO_ADDRESS.YOUR_WORKER_NAME''' --threads 4

=== 5. Pools ===

https://miningpoolstats.stream/biblepay

=== 6. Giveaway ===

https://forum.biblepay.org/index.php?topic=503

=== What is RandomX? ===

https://www.publish0x.com/passive-income-crypto/what-is-randomx-monero-s-mining-algorithm-xwkdqm

=== Get Community Help / Support ===

Forum: https://forum.biblepay.org/ 
Discord: https://discordapp.com/invite/yWgbKdM 
Telegram: https://t.me/biblepay_airdrop/ 
Reddit: https://www.reddit.com/r/BiblePay/ 
Email: rob@biblepay.org 

=== References ===
https://wiki.biblepay.org/Upgrade_to_RandomX 
https://foundation.biblepay.org/GettingStarted 
https://bitcointalk.org/index.php?topic=5226080

RandomX Setup

2020-05-31T14:08:39Z

Togoshigekata: Added pools link, giveaway link and starting description

We offer dual-hash mining with rewards in both '''BBP + XMR'''.
This is slightly different than merged mining, in that BBP's blocks are now solved with an equation that prevents pre-image attacks (http://wiki.biblepay.org/Preventing_Preimage_Attacks).

In theory, you will receive approximately '''190% more revenue''' for mining
(more specifically, 90% in XMR rewards, and 100% of your hashpower in BBP rewards),
while still contributing 10% to orphan charity.

Each RandomX hash has a full 100% chance of solving a BBP block (or a pool share),
while each RandomX hash still has an equal chance of solving an XMR share.

=== 1. Install Monero Wallet ===

a. https://mymonero.com/

b. Setup seed words and pin

c. Create receiving address ('''YOUR_MONERO_ADDRESS''')

=== 2. Install BiblePay Wallet ===

a. https://www.biblepay.org/wallet/

b. Create receiving address ('''YOUR_BIBLEPAY_ADDRESS''')

File >>> Receiving Address >>> New >>> Ok >>> Right Click >>> Copy Address

or Tools >>> Debug Console >>> Type command: getnewaddress "" >>> Click Enter

=== 3. Download XMRig zip ===

Windows (64-bit): https://github.com/biblepay/xmrig/raw/master/binaries/bbprig.zip

Linux (64-bit): https://github.com/biblepay/xmrig/raw/master/binaries/xmrig-bbp-linux64

Mac: http://www.biblepay.org/xmrig_mac.zip

Source: https://github.com/biblepay/xmrig

a. Create Folder (Example: C:\mining)

b. Copy .zip to new folder and Unzip it

c. Should see a script (batch) file and an executable rig file

=== 4. Edit the script (.bat) file ===

Windows:

./xmrig-bbp-win64.exe -o foundation.biblepay.org:3001 -u='''YOUR_BIBLEPAY_ADDRESS''' -p='''YOUR_MONERO_ADDRESS''' --threads 4

Linux:

./xmrig -o foundation.biblepay.org:3001 -u='''YOUR_BIBLEPAY_ADDRESS''' -p='''YOUR_MONERO_ADDRESS''' --threads 4

'''NOTE:''' Change number of threads to what works best for your machine

./xmrig -o foundation.biblepay.org:3001 -u='''YOUR_BIBLEPAY_ADDRESS''' -p='''YOUR_MONERO_ADDRESS.YOUR_WORKER_NAME''' --threads 4

'''OPTIONAL:''' Can add '''.YOUR_WORKER_NAME''' to end of '''YOUR_MONERO_ADDRESS''', it adds your cpu information per worker to xmrig

=== 5. Pools ===

https://miningpoolstats.stream/biblepay

=== 6. Giveaway ===

https://forum.biblepay.org/index.php?topic=503

=== References ===
https://wiki.biblepay.org/Upgrade_to_RandomX
https://foundation.biblepay.org/GettingStarted
https://bitcointalk.org/index.php?topic=5226080

RandomX Setup

2020-05-31T13:38:22Z

Togoshigekata: First draft

=== 1. Install Monero Wallet ===

a. https://mymonero.com/

b. Setup seed words and pin

c. Create receiving address ('''YOUR_MONERO_ADDRESS''')

=== 2. Install BiblePay Wallet ===

a. https://www.biblepay.org/wallet/

b. Create receiving address ('''YOUR_BIBLEPAY_ADDRESS''')

File >>> Receiving Address >>> New >>> Ok >>> Right Click >>> Copy Address

or Tools >>> Debug Console >>> Type command: getnewaddress "" >>> Click Enter

=== 3. Download XMRig zip ===

Windows (64-bit): https://github.com/biblepay/xmrig/raw/master/binaries/bbprig.zip

Linux (64-bit): https://github.com/biblepay/xmrig/raw/master/binaries/xmrig-bbp-linux64

Mac: http://www.biblepay.org/xmrig_mac.zip

Source: https://github.com/biblepay/xmrig

a. Create Folder (Example: C:\mining)

b. Copy .zip to new folder and Unzip it

c. Should see a script (batch) file and an executable rig file

=== 4. Edit the script (.bat) file ===

Windows:

./xmrig-bbp-win64.exe -o foundation.biblepay.org:3001 -u='''YOUR_BIBLEPAY_ADDRESS''' -p='''YOUR_MONERO_ADDRESS''' --threads 4

Linux:

./xmrig -o foundation.biblepay.org:3001 -u='''YOUR_BIBLEPAY_ADDRESS''' -p='''YOUR_MONERO_ADDRESS''' --threads 4

'''NOTE:''' Change number of threads to what works best for your machine

./xmrig -o foundation.biblepay.org:3001 -u='''YOUR_BIBLEPAY_ADDRESS''' -p='''YOUR_MONERO_ADDRESS.YOUR_WORKER_NAME''' --threads 4

'''OPTIONAL:''' Can add '''.YOUR_WORKER_NAME''' to end of '''YOUR_MONERO_ADDRESS''', it adds your cpu information per worker to xmrig

=== References ===
https://wiki.biblepay.org/Upgrade_to_RandomX
https://foundation.biblepay.org/GettingStarted

UnderstandingGovernance

2020-01-20T04:06:43Z

Togoshigekata: Added masternode setup guide link and masternode statistics links

=Understanding BiblePay Governance=
One of the greatest challenges of building a cryptocurrency platform is ensuring you create a decentralized system of governance to manage, fund, maintain and expand the project. This key element has been absent in every major currency to date, so the natural response is to create a not-for-profit foundation that is tasked with maintaining the core protocol and promoting the coin, but is not really connected to the coin holders in any meaningful way. This approach has a few issues that have been made evident from the experience of older crypto currency platforms.

Current crypto foundations are not related to the currency itself by any mechanism that is included in the protocol and are not designed to outlive early adopters when they lose interest. The foundation then struggles to maintain funding until it implodes and core development of the protocol is left scrambling for funding or depending on charity that can’t be counted on and does not allow for proper budgeting and planning. Donations are also unfair to donors because there are always free riders that benefit from the effort done by others without contributing. Other projects have financed themselves by premining coins or running prelaunch sales, which is not a great solution either because control of the funds is centralized and at that stage it is impossible to quantify the future needs of the project.

Through the network of full nodes and the collateral requirement, BiblePay already has a decentralized network of masternode operators that are heavily invested in the future of the currency, and that as a group can act as stewards of the core protocol development and promotion. We propose a decentralized management system based on the masternode voting mechanism. Masternode operators are not the only ones interested in the success of BiblePay, but they are the most stable ones because, unlike miners, they can’t reuse their asset for any other purpose or coin.

In the budget system, a portion of the block reward is held in escrow by the network itself, in the name of the operators, to be executed in the development and expansion of the ecosystem according to the vote of the masternodes in different budget proposals. These funds are directed to supporting development and promotion of the coin. Masternode operators vote on specific budgets and projects to be funded, thus defining the direction the coin is taking. This is done in a completely transparent way through a public portal where new initiatives are proposed and masternodes can vote on them. Functioning like a decentralized Kickstarter or Lighthouse, the budget can be used for anything that creates value within the ecosystem.

This is a 100% decentralized system powered by the masternodes, where budgets are set and paid directly from the blockchain. The blockchain hires core developers in this way and introduces a new concept of paid blockchain contractors, where people work for and are directly compensated by the network, through the decentralized votes of all masternode operators. One advantage of this model is it can survive early adopters. If early masternode operators sell their coins, the new owner can set up a masternode and with it acquire the right to vote on the budgets and projects. This guarantees there is a working system of maintenance as people come and go, making the network capable of sustaining itself on its own without depending on specific actors.

=Budgets and masternode voting=
The system works as a decentralized voting mechanism set up in the rules governing the blockchain, where budgets for specific projects are proposed, then the masternodes as a whole vote on them. Each project, if it passes, is added to the total budget and paid directly from the blockchain to the person doing the work. This allows BiblePay to hire core developers and pay them directly after approval of the work in a decentralized fashion.

A masternode votes on a proposal (technically a governance object on the blockchain) using the example command “masternode vote yes”, “masternode vote no” or “masternode vote abstain”. The votes then propagate across the network, and are tallied according to instructions followed by the network itself. Budgets under discussion and voting progress can be viewed using the example command “masternode budget show”.

A well defined decentralized system of governance allows a cryptocurrency network to endure and survive its original creators. In this way, later generations of masternode operators have a clear way to support the system as defined by the protocol itself, applying wisdom of the crowd techniques and the bond of trust established by the masternode collateral to create a decentralized management system. This creates incredible value within the currency, allowing us to be more agile and compete with other payment systems, such as Bitcoin and credit cards, on a global scale.

As the system develops, a strong team of productive contractors paid from blockchain rewards will arise and become established. This includes core developers, escrow providers, news and reporting staff, experimental development labs, partnerships with universities, marketing and PR firms and integrations with third party exchanges and payment platforms. The market recognizes the value of the stability of the network as a whole, and that the possibility of reliable and sufficient funding results in faster and more coherent implementation of the BiblePay roadmap and core BiblePay services.
=Reward schedule=
To guarantee long term sustainability of the blockchain, the network keeps a portion of the block rewards back as new blocks are created, with the masternode operators tasked to act as stewards and invest in the maintenance and expansion of the network by voting. This results in faster development and promotion, creating a virtuous cycle that benefits all actors, including miners, masternode operators, investors and users. More importantly, this gives the blockchain itself a self-preservation mechanism that is beyond the control of any individual.
{| class="wikitable"
|-
||'''Description'''
| style="text-align: right;" data-mce-style="text-align: right;"|'''Percentage'''
|-
||Mining reward for Proof-of-BibleHash
| style="text-align: right;" data-mce-style="text-align: right;"| 7.0%
|-
||Masternode reward for Proof-of-Service
| style="text-align: right;" data-mce-style="text-align: right;"|35.0%
|-
||Decentralized governance budget
| style="text-align: right;" data-mce-style="text-align: right;"|20.0%
|-
||Generic Smart Contracts
| style="text-align: right;" data-mce-style="text-align: right;"|38.0%
|}
20% of the mining reward is held back each block and is disbursed monthly by the masternode operators once the results of their votes are tallied, creating the first self-sustaining decentralized cryptocurrency platform organized as a Decentralized Autonomous Organization (DAO). The masternode operators establish a social contract with the network they benefit from and are bound to act as caretakers, dedicating their time, due diligence work and a portion of the network rewards to furthering the ecosystem. This has a ripple effect that benefits all parties involved - especially the end users.

The value generated by work done implementing proposals is expected to be greater than allocating 100% of rewards to mining because the network has needs beyond only cryptographically securing the blockchain. The expected result is greater net benefit not only for proposal winners, but also masternode operators, miners and normal users. In fact, the introduction of the decentralized governance budget itself was decided by a masternode vote, making the first distributed decision the actual creation of the system, similar to establishing a constitution.

This approach of distributing the normal block reward in a way that considers all critical elements a cryptocurrency needs for its long term viability, e.g. mining, full nodes, development and promotion, is revolutionary as it is done without changing the emission or creating any additional inflation for investors. The network simply distributes the available resources in a way that is of greater net benefit to all parties.

=Contractors and proposals=
Contractors of the blockchain can be developers, outreach professionals, team leaders, attorneys or even people appointed to do specific tasks. Proposals generally begin life as simple pre-proposal forum posts on the [http://forum.biblepay.org/index.php?board=5.0 BiblePay Forum], where feedback and suggestions are solicited from the general community. Once the proposal owner decides they have a reasonable chance of passing their proposal, it is created as a governance object on the blockchain. A fee of 2500 BiblePay is associated with this action to prevent spam and ensure only serious proposals make it to this stage. Several tools exist to allow masternode operators to comfortably review and vote on proposals. The net total of yes votes must exceed 10% of the total masternode count at the time votes are tallied in order to pass. If there are more passing proposals than the available block reward can provide for, the proposals with the most yes votes will pass first, creating a cut-off point for less popular proposals. The same process is then repeated every month, and the total amount of BiblePay available for proposals decreases by approximately 19.5% per year, together with the overall block reward.
=Proposal websites=
The community has gathered around the [http://forum.biblepay.org/index.php?board=5.0 BiblePay Forum] as a website to facilitate discussion and voting on proposals formally entered on the BiblePay blockchain. To view officially submitted proposals, open your wallet and click on the Proposals tab.

Each proposal should include a description of the proposal goals, details of what work will be done and a breakdown of the requested budget. Many proposals also link to their own website or the pre-proposal discussion, or include a video to validate the identity and sincerity of the proposal owner.

Masternode owners have the ability to cast a vote by signing a message from the masternode collateral address. Masternodes can vote at any time, and also change their vote at any time until the cutoff block is mined and voting stops. This occurs 1-3 days prior to the superblock. After voting stops, the blockchain executes a decentralized tally and validates all votes. Once consensus is reached, the results are broadcast and the budget is allocated soon after in a superblock.

Once passed, proposals are able to report back to the network on the [http://forum.biblepay.org/index.php?board=5.0 BiblePay Forum] or via published public channels and social media. Since it is possible to create proposals that pay out over several months, it is also possible to revoke funding from a project by changing the vote if development or spending of already allocated funds is unsatisfactory. This encourages proposal owners to work honestly and diligently to win the trust and approval of the network. Ongoing discussion and gradual improvement over time results in a close bond between the network and those working for the network in supporting roles.

Voting on proposals is updated in real time every 7 minutes as blocks are mined, so current winning proposals and the total allocation of the available budget are always open and visible to everyone.

=Budget allocation=
The total budget of the network can be calculated by taking 20% of the reward over the period of time between two superblocks, which occur every 6150 blocks or approximately 29.89 days. A voting cutoff occurs 1-3 days before the superblock, and the final votes are tallied at this point. A proposal must satisfy the condition (YES votes - NO votes) > (Total Number of Masternodes / 10) in order to be considered passing. Then, in the superblock, the winning proposals are awarded in the order of the margin by which they are passing until either the entire budget is allocated or no more passing proposals exist. This allows for completely trustless and decentralized allocation of the budget.

If a proposal has passed the voting threshold but insufficient funds remain to pay the full amount requested, it will not receive partial funding. Instead, any smaller proposals which have also passed the threshold that will fit in the budget will be funded, even if they have lower net approval than the larger proposal. Proposals requesting payment over multiple budget periods will remain in the treasury system for the duration of their validity if they pass the voting threshold, even if insufficient budget is available for funding as described above. Any unallocated budget is simply never created in the superblock, reducing unnecessary inflation.

Due to the decentralized nature of the masternode system, it is sometimes necessary to form funded organisations, such as committees or companies, to be responsible for some project or task. These are submitted in the same way, but the committee itself receives the funds. Another alternative is to place trusted escrow services between the budget allocation event and the actual submitter of the proposal to ensure that work is paid for in stages, as it is delivered. Some oversight over blockchain contractors is sometimes needed. Each budgeted item requires either a team manager or a committee responsible for implementation of the work. Periodically, this manager is expected to report on budget expenditure and completed work to show the value created from the allocated funds. This allows repeat proposal submitters to build up a reputation and gain trust from the community. Proposals which do not provide regular reports and cannot answer questions about their budget allocation will soon be defunded if it is part of a regular monthly proposal cycle. The result is a kind of self-policing system.

=Scaling and future uses=
As the number of blockchain contractors increases, a point is reached where masternode operators cannot be realistically expected to evaluate the volume of proposals. At this point funding organizations can be created to act as contractors for the distribution of funds to many smaller decentralized projects, according to current needs.

The existence of the decentralized budget system puts the power of determining where BiblePay goes in the future in the hands of the masternode network itself. All core development and several peripheral developers are already funded from the budget, and other projects not even conceivable at this time will likely arise in the future. This decouples the survival and value of the blockchain from the current userbase and developers, making the BiblePay blockchain designed to outlive its original users, a self sustainable decentralized cryptocurrency network that can still operate cohesively and bring added value services to end users in a consistent way.
=Conclusion=
Every masternode operator establishes a bond of trust and a social contract with the network in which she is bound to contribute to the development and maintenance of the ecosystem she benefits from. Under this model, a portion of the funds that the operator is bound to receive are in a sense allocated in custody, not in ownership, and are held in escrow by the network to be executed by the operators for the benefit of the ecosystem. Everyone contributes equally and proportionately to the benefits they are receiving and the risks they are taking, there are no privileges and no loopholes. This is complemented by the full node voting mechanism that allows for a distributed group to vote on a continuous basis on practical matters without the need to forfeit their right to decide to others, every few years, like with traditional governments or cooperative corporations.

We envision a future in which this model of transparent, unbreakable and verifiable contribution to the common good, in combination with continuous participation of the crowd through active voting, is utilized to manage organizations that are owned or operated jointly by its members, who share the benefits and responsibilities of those collectives, like governments, cooperative corporations, unions, DAOs, cryptocurrencies, etc. We call this model decentralized governance by blockchain.

=Masternode Setup Guide=

http://wiki.biblepay.org/Create_Sanctuary_2

=Masternode Statistics=

https://masternodes.online/currencies/BBP/ 
https://masternodes.pro/stats/bbp 
https://masternodecap.com/coins/BBP 
https://masternode.live/currencies/BBP/BiblePay 

=Reference=
[https://docs.dash.org/en/latest/governance/understanding.html Dash Docs]

[[Category:Sanctuary (Masternodes)]][[Category:Governance]]

UnderstandingGovernance

2020-01-19T09:07:10Z

Togoshigekata: /* Proposal websites */ Removed outdated links

=Understanding BiblePay Governance=
One of the greatest challenges of building a cryptocurrency platform is ensuring you create a decentralized system of governance to manage, fund, maintain and expand the project. This key element has been absent in every major currency to date, so the natural response is to create a not-for-profit foundation that is tasked with maintaining the core protocol and promoting the coin, but is not really connected to the coin holders in any meaningful way. This approach has a few issues that have been made evident from the experience of older crypto currency platforms.

Current crypto foundations are not related to the currency itself by any mechanism that is included in the protocol and are not designed to outlive early adopters when they lose interest. The foundation then struggles to maintain funding until it implodes and core development of the protocol is left scrambling for funding or depending on charity that can’t be counted on and does not allow for proper budgeting and planning. Donations are also unfair to donors because there are always free riders that benefit from the effort done by others without contributing. Other projects have financed themselves by premining coins or running prelaunch sales, which is not a great solution either because control of the funds is centralized and at that stage it is impossible to quantify the future needs of the project.

Through the network of full nodes and the collateral requirement, BiblePay already has a decentralized network of masternode operators that are heavily invested in the future of the currency, and that as a group can act as stewards of the core protocol development and promotion. We propose a decentralized management system based on the masternode voting mechanism. Masternode operators are not the only ones interested in the success of BiblePay, but they are the most stable ones because, unlike miners, they can’t reuse their asset for any other purpose or coin.

In the budget system, a portion of the block reward is held in escrow by the network itself, in the name of the operators, to be executed in the development and expansion of the ecosystem according to the vote of the masternodes in different budget proposals. These funds are directed to supporting development and promotion of the coin. Masternode operators vote on specific budgets and projects to be funded, thus defining the direction the coin is taking. This is done in a completely transparent way through a public portal where new initiatives are proposed and masternodes can vote on them. Functioning like a decentralized Kickstarter or Lighthouse, the budget can be used for anything that creates value within the ecosystem.

This is a 100% decentralized system powered by the masternodes, where budgets are set and paid directly from the blockchain. The blockchain hires core developers in this way and introduces a new concept of paid blockchain contractors, where people work for and are directly compensated by the network, through the decentralized votes of all masternode operators. One advantage of this model is it can survive early adopters. If early masternode operators sell their coins, the new owner can set up a masternode and with it acquire the right to vote on the budgets and projects. This guarantees there is a working system of maintenance as people come and go, making the network capable of sustaining itself on its own without depending on specific actors.

=Budgets and masternode voting=
The system works as a decentralized voting mechanism set up in the rules governing the blockchain, where budgets for specific projects are proposed, then the masternodes as a whole vote on them. Each project, if it passes, is added to the total budget and paid directly from the blockchain to the person doing the work. This allows BiblePay to hire core developers and pay them directly after approval of the work in a decentralized fashion.

A masternode votes on a proposal (technically a governance object on the blockchain) using the example command “masternode vote yes”, “masternode vote no” or “masternode vote abstain”. The votes then propagate across the network, and are tallied according to instructions followed by the network itself. Budgets under discussion and voting progress can be viewed using the example command “masternode budget show”.

A well defined decentralized system of governance allows a cryptocurrency network to endure and survive its original creators. In this way, later generations of masternode operators have a clear way to support the system as defined by the protocol itself, applying wisdom of the crowd techniques and the bond of trust established by the masternode collateral to create a decentralized management system. This creates incredible value within the currency, allowing us to be more agile and compete with other payment systems, such as Bitcoin and credit cards, on a global scale.

As the system develops, a strong team of productive contractors paid from blockchain rewards will arise and become established. This includes core developers, escrow providers, news and reporting staff, experimental development labs, partnerships with universities, marketing and PR firms and integrations with third party exchanges and payment platforms. The market recognizes the value of the stability of the network as a whole, and that the possibility of reliable and sufficient funding results in faster and more coherent implementation of the BiblePay roadmap and core BiblePay services.
=Reward schedule=
To guarantee long term sustainability of the blockchain, the network keeps a portion of the block rewards back as new blocks are created, with the masternode operators tasked to act as stewards and invest in the maintenance and expansion of the network by voting. This results in faster development and promotion, creating a virtuous cycle that benefits all actors, including miners, masternode operators, investors and users. More importantly, this gives the blockchain itself a self-preservation mechanism that is beyond the control of any individual.
{| class="wikitable"
|-
||'''Description'''
| style="text-align: right;" data-mce-style="text-align: right;"|'''Percentage'''
|-
||Mining reward for Proof-of-BibleHash
| style="text-align: right;" data-mce-style="text-align: right;"| 7.0%
|-
||Masternode reward for Proof-of-Service
| style="text-align: right;" data-mce-style="text-align: right;"|35.0%
|-
||Decentralized governance budget
| style="text-align: right;" data-mce-style="text-align: right;"|20.0%
|-
||Generic Smart Contracts
| style="text-align: right;" data-mce-style="text-align: right;"|38.0%
|}
20% of the mining reward is held back each block and is disbursed monthly by the masternode operators once the results of their votes are tallied, creating the first self-sustaining decentralized cryptocurrency platform organized as a Decentralized Autonomous Organization (DAO). The masternode operators establish a social contract with the network they benefit from and are bound to act as caretakers, dedicating their time, due diligence work and a portion of the network rewards to furthering the ecosystem. This has a ripple effect that benefits all parties involved - especially the end users.

The value generated by work done implementing proposals is expected to be greater than allocating 100% of rewards to mining because the network has needs beyond only cryptographically securing the blockchain. The expected result is greater net benefit not only for proposal winners, but also masternode operators, miners and normal users. In fact, the introduction of the decentralized governance budget itself was decided by a masternode vote, making the first distributed decision the actual creation of the system, similar to establishing a constitution.

This approach of distributing the normal block reward in a way that considers all critical elements a cryptocurrency needs for its long term viability, e.g. mining, full nodes, development and promotion, is revolutionary as it is done without changing the emission or creating any additional inflation for investors. The network simply distributes the available resources in a way that is of greater net benefit to all parties.

=Contractors and proposals=
Contractors of the blockchain can be developers, outreach professionals, team leaders, attorneys or even people appointed to do specific tasks. Proposals generally begin life as simple pre-proposal forum posts on the [http://forum.biblepay.org/index.php?board=5.0 BiblePay Forum], where feedback and suggestions are solicited from the general community. Once the proposal owner decides they have a reasonable chance of passing their proposal, it is created as a governance object on the blockchain. A fee of 2500 BiblePay is associated with this action to prevent spam and ensure only serious proposals make it to this stage. Several tools exist to allow masternode operators to comfortably review and vote on proposals. The net total of yes votes must exceed 10% of the total masternode count at the time votes are tallied in order to pass. If there are more passing proposals than the available block reward can provide for, the proposals with the most yes votes will pass first, creating a cut-off point for less popular proposals. The same process is then repeated every month, and the total amount of BiblePay available for proposals decreases by approximately 19.5% per year, together with the overall block reward.
=Proposal websites=
The community has gathered around the [http://forum.biblepay.org/index.php?board=5.0 BiblePay Forum] as a website to facilitate discussion and voting on proposals formally entered on the BiblePay blockchain. To view officially submitted proposals, open your wallet and click on the Proposals tab.

Each proposal should include a description of the proposal goals, details of what work will be done and a breakdown of the requested budget. Many proposals also link to their own website or the pre-proposal discussion, or include a video to validate the identity and sincerity of the proposal owner.

Masternode owners have the ability to cast a vote by signing a message from the masternode collateral address. Masternodes can vote at any time, and also change their vote at any time until the cutoff block is mined and voting stops. This occurs 1-3 days prior to the superblock. After voting stops, the blockchain executes a decentralized tally and validates all votes. Once consensus is reached, the results are broadcast and the budget is allocated soon after in a superblock.

Once passed, proposals are able to report back to the network on the [http://forum.biblepay.org/index.php?board=5.0 BiblePay Forum] or via published public channels and social media. Since it is possible to create proposals that pay out over several months, it is also possible to revoke funding from a project by changing the vote if development or spending of already allocated funds is unsatisfactory. This encourages proposal owners to work honestly and diligently to win the trust and approval of the network. Ongoing discussion and gradual improvement over time results in a close bond between the network and those working for the network in supporting roles.

Voting on proposals is updated in real time every 7 minutes as blocks are mined, so current winning proposals and the total allocation of the available budget are always open and visible to everyone.

=Budget allocation=
The total budget of the network can be calculated by taking 20% of the reward over the period of time between two superblocks, which occur every 6150 blocks or approximately 29.89 days. A voting cutoff occurs 1-3 days before the superblock, and the final votes are tallied at this point. A proposal must satisfy the condition (YES votes - NO votes) > (Total Number of Masternodes / 10) in order to be considered passing. Then, in the superblock, the winning proposals are awarded in the order of the margin by which they are passing until either the entire budget is allocated or no more passing proposals exist. This allows for completely trustless and decentralized allocation of the budget.

If a proposal has passed the voting threshold but insufficient funds remain to pay the full amount requested, it will not receive partial funding. Instead, any smaller proposals which have also passed the threshold that will fit in the budget will be funded, even if they have lower net approval than the larger proposal. Proposals requesting payment over multiple budget periods will remain in the treasury system for the duration of their validity if they pass the voting threshold, even if insufficient budget is available for funding as described above. Any unallocated budget is simply never created in the superblock, reducing unnecessary inflation.

Due to the decentralized nature of the masternode system, it is sometimes necessary to form funded organisations, such as committees or companies, to be responsible for some project or task. These are submitted in the same way, but the committee itself receives the funds. Another alternative is to place trusted escrow services between the budget allocation event and the actual submitter of the proposal to ensure that work is paid for in stages, as it is delivered. Some oversight over blockchain contractors is sometimes needed. Each budgeted item requires either a team manager or a committee responsible for implementation of the work. Periodically, this manager is expected to report on budget expenditure and completed work to show the value created from the allocated funds. This allows repeat proposal submitters to build up a reputation and gain trust from the community. Proposals which do not provide regular reports and cannot answer questions about their budget allocation will soon be defunded if it is part of a regular monthly proposal cycle. The result is a kind of self-policing system.

=Scaling and future uses=
As the number of blockchain contractors increases, a point is reached where masternode operators cannot be realistically expected to evaluate the volume of proposals. At this point funding organizations can be created to act as contractors for the distribution of funds to many smaller decentralized projects, according to current needs.

The existence of the decentralized budget system puts the power of determining where BiblePay goes in the future in the hands of the masternode network itself. All core development and several peripheral developers are already funded from the budget, and other projects not even conceivable at this time will likely arise in the future. This decouples the survival and value of the blockchain from the current userbase and developers, making the BiblePay blockchain designed to outlive its original users, a self sustainable decentralized cryptocurrency network that can still operate cohesively and bring added value services to end users in a consistent way.
=Conclusion=
Every masternode operator establishes a bond of trust and a social contract with the network in which she is bound to contribute to the development and maintenance of the ecosystem she benefits from. Under this model, a portion of the funds that the operator is bound to receive are in a sense allocated in custody, not in ownership, and are held in escrow by the network to be executed by the operators for the benefit of the ecosystem. Everyone contributes equally and proportionately to the benefits they are receiving and the risks they are taking, there are no privileges and no loopholes. This is complemented by the full node voting mechanism that allows for a distributed group to vote on a continuous basis on practical matters without the need to forfeit their right to decide to others, every few years, like with traditional governments or cooperative corporations.

We envision a future in which this model of transparent, unbreakable and verifiable contribution to the common good, in combination with continuous participation of the crowd through active voting, is utilized to manage organizations that are owned or operated jointly by its members, who share the benefits and responsibilities of those collectives, like governments, cooperative corporations, unions, DAOs, cryptocurrencies, etc. We call this model decentralized governance by blockchain.

----

Reference: [https://docs.dash.org/en/latest/governance/understanding.html]

[[Category:Sanctuary (Masternodes)]][[Category:Governance]]

UnderstandingGovernance

2020-01-19T09:04:27Z

Togoshigekata: /* Reward schedule */ Updated Block Reward Values

=Understanding BiblePay Governance=
One of the greatest challenges of building a cryptocurrency platform is ensuring you create a decentralized system of governance to manage, fund, maintain and expand the project. This key element has been absent in every major currency to date, so the natural response is to create a not-for-profit foundation that is tasked with maintaining the core protocol and promoting the coin, but is not really connected to the coin holders in any meaningful way. This approach has a few issues that have been made evident from the experience of older crypto currency platforms.

Current crypto foundations are not related to the currency itself by any mechanism that is included in the protocol and are not designed to outlive early adopters when they lose interest. The foundation then struggles to maintain funding until it implodes and core development of the protocol is left scrambling for funding or depending on charity that can’t be counted on and does not allow for proper budgeting and planning. Donations are also unfair to donors because there are always free riders that benefit from the effort done by others without contributing. Other projects have financed themselves by premining coins or running prelaunch sales, which is not a great solution either because control of the funds is centralized and at that stage it is impossible to quantify the future needs of the project.

Through the network of full nodes and the collateral requirement, BiblePay already has a decentralized network of masternode operators that are heavily invested in the future of the currency, and that as a group can act as stewards of the core protocol development and promotion. We propose a decentralized management system based on the masternode voting mechanism. Masternode operators are not the only ones interested in the success of BiblePay, but they are the most stable ones because, unlike miners, they can’t reuse their asset for any other purpose or coin.

In the budget system, a portion of the block reward is held in escrow by the network itself, in the name of the operators, to be executed in the development and expansion of the ecosystem according to the vote of the masternodes in different budget proposals. These funds are directed to supporting development and promotion of the coin. Masternode operators vote on specific budgets and projects to be funded, thus defining the direction the coin is taking. This is done in a completely transparent way through a public portal where new initiatives are proposed and masternodes can vote on them. Functioning like a decentralized Kickstarter or Lighthouse, the budget can be used for anything that creates value within the ecosystem.

This is a 100% decentralized system powered by the masternodes, where budgets are set and paid directly from the blockchain. The blockchain hires core developers in this way and introduces a new concept of paid blockchain contractors, where people work for and are directly compensated by the network, through the decentralized votes of all masternode operators. One advantage of this model is it can survive early adopters. If early masternode operators sell their coins, the new owner can set up a masternode and with it acquire the right to vote on the budgets and projects. This guarantees there is a working system of maintenance as people come and go, making the network capable of sustaining itself on its own without depending on specific actors.

=Budgets and masternode voting=
The system works as a decentralized voting mechanism set up in the rules governing the blockchain, where budgets for specific projects are proposed, then the masternodes as a whole vote on them. Each project, if it passes, is added to the total budget and paid directly from the blockchain to the person doing the work. This allows BiblePay to hire core developers and pay them directly after approval of the work in a decentralized fashion.

A masternode votes on a proposal (technically a governance object on the blockchain) using the example command “masternode vote yes”, “masternode vote no” or “masternode vote abstain”. The votes then propagate across the network, and are tallied according to instructions followed by the network itself. Budgets under discussion and voting progress can be viewed using the example command “masternode budget show”.

A well defined decentralized system of governance allows a cryptocurrency network to endure and survive its original creators. In this way, later generations of masternode operators have a clear way to support the system as defined by the protocol itself, applying wisdom of the crowd techniques and the bond of trust established by the masternode collateral to create a decentralized management system. This creates incredible value within the currency, allowing us to be more agile and compete with other payment systems, such as Bitcoin and credit cards, on a global scale.

As the system develops, a strong team of productive contractors paid from blockchain rewards will arise and become established. This includes core developers, escrow providers, news and reporting staff, experimental development labs, partnerships with universities, marketing and PR firms and integrations with third party exchanges and payment platforms. The market recognizes the value of the stability of the network as a whole, and that the possibility of reliable and sufficient funding results in faster and more coherent implementation of the BiblePay roadmap and core BiblePay services.
=Reward schedule=
To guarantee long term sustainability of the blockchain, the network keeps a portion of the block rewards back as new blocks are created, with the masternode operators tasked to act as stewards and invest in the maintenance and expansion of the network by voting. This results in faster development and promotion, creating a virtuous cycle that benefits all actors, including miners, masternode operators, investors and users. More importantly, this gives the blockchain itself a self-preservation mechanism that is beyond the control of any individual.
{| class="wikitable"
|-
||'''Description'''
| style="text-align: right;" data-mce-style="text-align: right;"|'''Percentage'''
|-
||Mining reward for Proof-of-BibleHash
| style="text-align: right;" data-mce-style="text-align: right;"| 7.0%
|-
||Masternode reward for Proof-of-Service
| style="text-align: right;" data-mce-style="text-align: right;"|35.0%
|-
||Decentralized governance budget
| style="text-align: right;" data-mce-style="text-align: right;"|20.0%
|-
||Generic Smart Contracts
| style="text-align: right;" data-mce-style="text-align: right;"|38.0%
|}
20% of the mining reward is held back each block and is disbursed monthly by the masternode operators once the results of their votes are tallied, creating the first self-sustaining decentralized cryptocurrency platform organized as a Decentralized Autonomous Organization (DAO). The masternode operators establish a social contract with the network they benefit from and are bound to act as caretakers, dedicating their time, due diligence work and a portion of the network rewards to furthering the ecosystem. This has a ripple effect that benefits all parties involved - especially the end users.

The value generated by work done implementing proposals is expected to be greater than allocating 100% of rewards to mining because the network has needs beyond only cryptographically securing the blockchain. The expected result is greater net benefit not only for proposal winners, but also masternode operators, miners and normal users. In fact, the introduction of the decentralized governance budget itself was decided by a masternode vote, making the first distributed decision the actual creation of the system, similar to establishing a constitution.

This approach of distributing the normal block reward in a way that considers all critical elements a cryptocurrency needs for its long term viability, e.g. mining, full nodes, development and promotion, is revolutionary as it is done without changing the emission or creating any additional inflation for investors. The network simply distributes the available resources in a way that is of greater net benefit to all parties.

=Contractors and proposals=
Contractors of the blockchain can be developers, outreach professionals, team leaders, attorneys or even people appointed to do specific tasks. Proposals generally begin life as simple pre-proposal forum posts on the [http://forum.biblepay.org/index.php?board=5.0 BiblePay Forum], where feedback and suggestions are solicited from the general community. Once the proposal owner decides they have a reasonable chance of passing their proposal, it is created as a governance object on the blockchain. A fee of 2500 BiblePay is associated with this action to prevent spam and ensure only serious proposals make it to this stage. Several tools exist to allow masternode operators to comfortably review and vote on proposals. The net total of yes votes must exceed 10% of the total masternode count at the time votes are tallied in order to pass. If there are more passing proposals than the available block reward can provide for, the proposals with the most yes votes will pass first, creating a cut-off point for less popular proposals. The same process is then repeated every month, and the total amount of BiblePay available for proposals decreases by approximately 19.5% per year, together with the overall block reward.
=Proposal websites=
The community has gathered around the [http://forum.biblepay.org/index.php?board=5.0 BiblePay Forum] as a website to facilitate discussion and voting on proposals formally entered on the BiblePay blockchain. [https://forum.biblepay.org/cc/governance BiblePay Forum Governance Tool] and [https://pool.biblepay.org/ Pool.BiblePay] >>> Governance >>> Proposal List are available to view submitted proposals.

Each proposal should include a description of the proposal goals, details of what work will be done and a breakdown of the requested budget. Many proposals also link to their own website or the pre-proposal discussion, or include a video to validate the identity and sincerity of the proposal owner.

Masternode owners have the ability to cast a vote by signing a message from the masternode collateral address. Masternodes can vote at any time, and also change their vote at any time until the cutoff block is mined and voting stops. This occurs 1-3 days prior to the superblock. After voting stops, the blockchain executes a decentralized tally and validates all votes. Once consensus is reached, the results are broadcast and the budget is allocated soon after in a superblock.

Once passed, proposals are able to report back to the network on the [http://forum.biblepay.org/index.php?board=5.0 BiblePay Forum] or via published public channels and social media. Since it is possible to create proposals that pay out over several months, it is also possible to revoke funding from a project by changing the vote if development or spending of already allocated funds is unsatisfactory. This encourages proposal owners to work honestly and diligently to win the trust and approval of the network. Ongoing discussion and gradual improvement over time results in a close bond between the network and those working for the network in supporting roles.

Voting on proposals is updated in real time every 7 minutes as blocks are mined, so current winning proposals and the total allocation of the available budget are always open and visible to everyone. [https://forum.biblepay.org/cc/governance BiblePay Forum Governance Tool] and [https://pool.biblepay.org/ Pool.BiblePay] >>> Governance >>> Proposal List are two popular sites used to view current and past proposals.

=Budget allocation=
The total budget of the network can be calculated by taking 20% of the reward over the period of time between two superblocks, which occur every 6150 blocks or approximately 29.89 days. A voting cutoff occurs 1-3 days before the superblock, and the final votes are tallied at this point. A proposal must satisfy the condition (YES votes - NO votes) > (Total Number of Masternodes / 10) in order to be considered passing. Then, in the superblock, the winning proposals are awarded in the order of the margin by which they are passing until either the entire budget is allocated or no more passing proposals exist. This allows for completely trustless and decentralized allocation of the budget.

If a proposal has passed the voting threshold but insufficient funds remain to pay the full amount requested, it will not receive partial funding. Instead, any smaller proposals which have also passed the threshold that will fit in the budget will be funded, even if they have lower net approval than the larger proposal. Proposals requesting payment over multiple budget periods will remain in the treasury system for the duration of their validity if they pass the voting threshold, even if insufficient budget is available for funding as described above. Any unallocated budget is simply never created in the superblock, reducing unnecessary inflation.

Due to the decentralized nature of the masternode system, it is sometimes necessary to form funded organisations, such as committees or companies, to be responsible for some project or task. These are submitted in the same way, but the committee itself receives the funds. Another alternative is to place trusted escrow services between the budget allocation event and the actual submitter of the proposal to ensure that work is paid for in stages, as it is delivered. Some oversight over blockchain contractors is sometimes needed. Each budgeted item requires either a team manager or a committee responsible for implementation of the work. Periodically, this manager is expected to report on budget expenditure and completed work to show the value created from the allocated funds. This allows repeat proposal submitters to build up a reputation and gain trust from the community. Proposals which do not provide regular reports and cannot answer questions about their budget allocation will soon be defunded if it is part of a regular monthly proposal cycle. The result is a kind of self-policing system.

=Scaling and future uses=
As the number of blockchain contractors increases, a point is reached where masternode operators cannot be realistically expected to evaluate the volume of proposals. At this point funding organizations can be created to act as contractors for the distribution of funds to many smaller decentralized projects, according to current needs.

The existence of the decentralized budget system puts the power of determining where BiblePay goes in the future in the hands of the masternode network itself. All core development and several peripheral developers are already funded from the budget, and other projects not even conceivable at this time will likely arise in the future. This decouples the survival and value of the blockchain from the current userbase and developers, making the BiblePay blockchain designed to outlive its original users, a self sustainable decentralized cryptocurrency network that can still operate cohesively and bring added value services to end users in a consistent way.
=Conclusion=
Every masternode operator establishes a bond of trust and a social contract with the network in which she is bound to contribute to the development and maintenance of the ecosystem she benefits from. Under this model, a portion of the funds that the operator is bound to receive are in a sense allocated in custody, not in ownership, and are held in escrow by the network to be executed by the operators for the benefit of the ecosystem. Everyone contributes equally and proportionately to the benefits they are receiving and the risks they are taking, there are no privileges and no loopholes. This is complemented by the full node voting mechanism that allows for a distributed group to vote on a continuous basis on practical matters without the need to forfeit their right to decide to others, every few years, like with traditional governments or cooperative corporations.

We envision a future in which this model of transparent, unbreakable and verifiable contribution to the common good, in combination with continuous participation of the crowd through active voting, is utilized to manage organizations that are owned or operated jointly by its members, who share the benefits and responsibilities of those collectives, like governments, cooperative corporations, unions, DAOs, cryptocurrencies, etc. We call this model decentralized governance by blockchain.

----

Reference: [https://docs.dash.org/en/latest/governance/understanding.html]

[[Category:Sanctuary (Masternodes)]][[Category:Governance]]

BiblePay Healing Campaign

2020-01-12T11:14:51Z

Togoshigekata: Added sections

The BiblePay Healing campaign is an optional campaign for Believers who want to make a big difference in the world by physically affecting others in a way that bears real Christian fruit.

 
The first goal of this campaign is for us to go out in the real world and bear fruit. That means going out and Spreading the Gospel, Healing the Sick, Casting out Demons, Conducting spiritual Warfare campaigns, or praying at loved ones request(s).

 

This guide explains how BiblePay allows you to participate in this campaign, log activity and be compensated also!
Note that at the time of this writing, the Healing campaign pays 5% of the daily GSC budget.

=== '''PART A: Create CPK''' ===

Ensure you have a Christian Public Key. This is your unique identifier that allows diary records to be credited to your account which will earn you points. If you have not created a CPK yet, do the following from the RPC console (The rpc console can be reached by clicking on Tools | Debug):
<pre>
exec cpk nickname
</pre>
Where nickname is your preferred nickname. Don't worry, if the nickname is not available, it will throw an error.

==='''PART B: Join Healing'''===

Ensure you have joined the Healing campaign. To join:
<pre>
exec join healing
</pre>

==='''PART C: Learn Spiritual Warfare '''===

Count the costs.
 
Read the wiki associated with Street Healing and [https://wiki.biblepay.org/Spiritual-Warfare-I Spiritual Warfare] before attempting this activity.
 
We do not want to see anyone hurt personally (by demonic attacks) if you are not ready.
 
NOTE: This step does not involve working with BiblePay - this is merely a summary of what you will do out on the streets:
Do what you do best. If you are a healer, pick certain days of the week, go out with a notepad, and keep notes of who you prayed for, what their name is, what affliction they had, what level of progress was made (IE level 8 to 1), and a summary.
 
If you are in a spiritual Warfare campaign, head to the prayer closet, conduct spiritual warfare, then make a note of this as a diary entry (and at what time, and what purpose).
 
If you have been called to pray for a sick family member (IE in a relatively important circumstance), make notes of this. Or if you went out and shared the gospel boldly, make a note of this.
 
If you baptized someone, this is equally important. You may log it as a Christian diary entry.
 
 

==='''PART D: Write Prayer Diary'''===
 
How to Enter this in BiblePay.
 
From the QT wallet, click Send. Click the "Add Diary Entry" checkbox.
(The amount of 1 BBP and the foundation address will auto-populate).
In the Diary Entry textbox, type in a summary of what type of activity your diary is for and what you did and when you did it.
 
For example:
 
<pre>
Thursday-Healing:We visited Walmart and encountered Jodie K, and prayed for her kneecaps (she had pain level 7). After praying 5 times, pain level dropped to 0. She hugged us.
</pre>
Or
<pre>
Thursday-Warfare: Prayed for all demonic strongholds to be broken in America for 15 mins at 7AM.
</pre>

2020-01-02T07:59:22Z

Togoshigekata:

===Categories===
https://wiki.biblepay.org/Special:UncategorizedCategories

===Help===
https://www.mediawiki.org/wiki/Help:Categories

===Adding a page to a category===

To add a page or uploaded file to a category, simply edit the page and add the following text 
(where '''''Name''''' is the name of the category you want to add it to).

<nowiki>[[</nowiki>{{ns:category}}:'''''Name''''']]

Any number of {{ns:category}} tags may be added to the page and the page will be listed in all of them.

===All Wiki Pages===
http://wiki.biblepay.org/Special:AllPages

2020-01-02T07:57:34Z

Togoshigekata:

Categories 
https://wiki.biblepay.org/Special:UncategorizedCategories

Help 
https://www.mediawiki.org/wiki/Help:Categories

Adding a page to a category 

To add a page or uploaded file to a category, simply edit the page and add the following text 
(where '''''Name''''' is the name of the category you want to add it to).

<nowiki>[[</nowiki>{{ns:category}}:'''''Name''''']]

Any number of {{ns:category}} tags may be added to the page and the page will be listed in all of them.

2020-01-02T07:52:06Z

Togoshigekata: Created page with "test"

test

BiblePay Wiki - User contributions [en]

Portfolio Builder Setup

Portfolio Builder Setup

Portfolio Builder Setup

RandomX Setup

RandomX Setup

Portfolio Builder Setup

Portfolio Builder Setup

Portfolio Builder Setup

Portfolio Builder Setup

Portfolio Builder Setup

Portfolio Builder Setup

Portfolio Builder Setup

Portfolio Builder Setup

Portfolio Builder Setup

Portfolio Builder Setup

Portfolio Builder Setup

Portfolio Builder Setup

RandomX Setup

Dash Stake Setup

Dash Stake Setup

Dash Stake Setup

Dash Stake Setup

Dash Stake Setup

September 2020 Upgrade

RandomX Setup

RandomX Setup

RandomX Setup

RandomX Setup

UnderstandingGovernance

RandomX Setup

RandomX Setup

RandomX Setup

RandomX Setup

RandomX Setup

RandomX Setup

RandomX Setup

RandomX Setup

RandomX Setup

RandomX Setup

RandomX Setup

RandomX Setup

RandomX Setup

RandomX Setup

UnderstandingGovernance

UnderstandingGovernance

UnderstandingGovernance

BiblePay Healing Campaign

Table of Contents

Table of Contents

Table of Contents