Bible Pay

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - Rob Andrews

Pages: 1 2 3 4 [5] 6 7 8 9 10 11
61
Archived Proposals / Approve Budget Changes
« on: April 30, 2020, 09:17:07 PM »
In the first month of RandomX mining (April 2020), we raised approx. 1.90 XMR.
Due to the success levels of RX, I propose the following changes to our reward structure for each heat mined block:

- Retire POOM as of June 2020 (remove listchildren, cancelsponsorship, sponsorchild)
- Free up the daily GSC budget spent for POOM (240K per day, 35% of the GSC budget)
- Allocate this 240K per day into the heat mining reward (raising the heat mined reward from 2400BBP to ~3500bbp)
- Do not increase the Sanctuary reward (instead maximize the RX reward)

Part II (DWS - Dynamic Whale Staking):

I feel that DWS was very successful, and it was grabbed relatively quickly - even with the last adjustment.  I feel it gives us a fighting chance to allow outsiders to buy up the SX free coins.

I propose these changes:
- Double the DWS available emission level, so more burns will be available
- Increase our deflation rate to pay for the new level
Specifically, we would change the GetAnnualDwsReward level from .325 to .64, then we would increase our deflation level in GetBlockSubsidy.


62
June 2020 Release


Welcome to the Biblepay June 2020 Testnet Testing thread.


In this thread we will be testing:


- 'exec price' : XMR price has been added
- Sanctuary Voting :
     (This is the ability for a sanctuary to vote on a spork, and if the Vote outcome is a PASS, the spork will go into effect.  If it is a FAIL we need to see this spork fail to enter into the chain).

- Anti-Censorship-Feature (ACF)  - Although I went through the pain of coding this, releasing it and testing it, I have decided that (as I believe we as a community) will be better off with BiblePay unchained for this use case (as it is safer and does not risk bloating the governance system and the nodes).  So for safetey reasons, I have removed this and now am planning on releasing the design for Unchained.  (This is a sidechain that holds documents off-chain).

- Removing "BiblePay-Evolution" from the windows wallet and fixing the default program directory name (it is still Evolution).  This should go back to BiblePay.  Check to see if the windows installer wizard is correct.

- Test a VendorList change (Charity monero addresses in a semicolon delimited list) and a PoolList change (allowable RX pools).

- Remove POOM from the wallet (remove poom listchildren, poom pay).  Move POOM payment budget from GSC to Heat mined blocks.  Ensure these heat payments go to the heat side and not to the sanctuary.  I believe POOM causes the GSC budget to drop by 240K per day, and the mined block subsidy to rise by 1200~, and the sanc payment should stay the same.

- Any Dash changes that occurred between Jan 1,2020 and March 30th?  Ask MIP?  MIP has made me aware we need a little more time to move up to .15, because Dash has changed 1800 files!  So lets shoot for releasing .15 in September.

- The ability for a RandomX hash to be mined in a more RX compatible way (check to see if foundation.biblepay can receive a blakehash as Solution #1) (This is just a reminder note that may result in a code change in the core wallet if this streamlines the xmrig code to be 100% compatible with the xmrig branch), Checking this.  (This basically frees us from maintaining a special version of xmrig).

->  Great news, I tested pure merge-mining using the plain vanilla xmrig, and it worked.  The changes are in this version already.

- Test Marcus Antonios Russian and Ukrainian Bible viewer(s)


Starting Version:    1.5.1.0+


(Please ensure your version is greater than this, otherwise your testnet branch will not sync. 

We are at block  ____37650_____ as of May 1st, 2020).

BlockHash 37650:
573935383afc18055f0207355e49262a4243db5705d019506aac153eba5c503e


Testnet Download Links:


Ready:
     Windows 64-bit:      https://biblepay.org/biblepayevo64develop.exe
     MacOS QT: https://biblepay.org/biblepaycore-evo-testnet.dmg

     Linux 64 bits II (QT/biblepayd/biblepay-cli) zip:  https://biblepay.org/bbp-lin-develop-64.zip


To self compile:
https://github.com/biblepay/biblepay/blob/develop/BuildBiblePay.txt


Retiring (do not use these downloads):
     Linux PC 64bits Daemon:     https://biblepay.org/biblepayd-evo-testnet-x86_64-pc-linux-gnu.tar.gz
     Linux 64 bits QT:       https://biblepay.org/biblepay-qt-evo-testnet-x86_64-pc-linux-gnu.tar.gz






CONFIGURING FOR TESTNET:


Create a biblepaytest.conf file with the following contents:
testnet=1
debug=1

Place the file in ~/.biblepay



Start testnet by typing:
./biblepay-qt -conf=biblepaytest.conf

(Note the blocks and chainstate will sync into the ./biblepay/testnet3 folder.


NOTE: This version will also work side-by-side our production nodes,
so, you also have the option if you are short on machines, to run TestNet side by side a prod node!

To run a TestNet Sanctuary:
https://forum.biblepay.org/index.php?topic=391.msg5968#msg5968

How to create a deterministic sanc from scratch:
https://docs.dash.org/en/stable/masternodes/dip3-upgrade.html

__________________________________________________________________________________________________________________________________________________________________________________________






63
WEBSITE | GITHUB | TEAM | ROADMAP | WHITE PAPER

FORUM | TWITTER | REDDIT | DISCORD | FACEBOOK | TELEGRAM

Language Translations



RandomX merge mining provides miners with two revenue streams, while preventing GPUs and ASICs

Launched July 23rd 2017 by Rob Andrews, with no premine and no ICO, BiblePay describes itself as a decentralized autonomous cryptocurrency that gives 10% to orphan-charity (using Sanctuary (Masternode) governance).  The project is passionate about spreading the gospel of Jesus, having the entire KJV bible compiled in its core wallet.   BiblePay (BBP) is deflationary, decreasing its emissions by 19.5% per year.

The project views itself as a utility that provides an alternative method for giving to charity. With Generic Smart Contracts, the project seeks to become the go-to wallet for Christians. In the future, the team intends to lease file space on its Sanctuaries and release corporate integration features, such as C# access to the blockchain. The BiblePay platform is a derivative of Dash-Evolution. Located in Dallas, TX, the team seeks to help orphans globally. The roadmap can be viewed at: wiki.biblepay.org/Roadmap


Interview | Podcast | Youtube | Medium | Steemit | Newsletter





Accomplishments:

- $220,000+ donated to Charity!

- 30,000+ years CPU time donated to Cancer Research!

- Sponsoring 100+ Orphans every month!



Overview:           

Nutrition Information     

Dimensions     

BiblePay Evolution

New Features:

Generic Smart Contracts (GSC)

Proof of Orphan Sponsorship (POOS)





Utility:

DashPay - Instantly Buy Gift Cards with BiblePay (using Dash, InstantSend and Bitrefill)
wiki.biblepay.org/DashPay_RPC






Theology:

Left Behind Letter (for those that missed the rapture):           https://san.biblepay.org/Theology/Left%20Behind%20Letter.pdf





Download Wallet:

biblepay.org/wallet


(How to update and clean wallet?)




      

(How to verify Hash)

Windows 64 bit - biblepay.org/biblepayevo64.exe (Hash)



Mac OSX - biblepay.org/biblepaycore-evo.dmg



Linux GUI 64 bit - biblepay-qt-evo-x86_64-pc-linux-gnu.tar.gz  (Hash)

Linux CLI 64 bit - biblepayd-evo-x86_64-pc-linux-gnu.tar.gz  (Hash)




Source Code - github.com/biblepay/biblepay/blob/master/BuildBiblePay.txt



Paper - biblepaywallet.github.io



Mobile Wallet:

Android -   https://www.biblepay.org/wallet/

iOS - https://www.biblepay.org/wallet/



Mining Guides:


Proof of BibleHash
wiki.biblepay.org/POBH_Setup

Mining Pools:



MiningPoolStats
miningpoolstats.stream/biblepay



Earn Coins:

FreeFaucet.io:
freefaucet.io/claim/index.php?coin_name=biblepay&faucet_key=freefaucet18&claim=Claim

SouthXchange Faucet:
southxchange.com/Balance/Faucet

Healing Campaign (Diary Entries):
wiki.biblepay.org/BiblePay_Healing_Campaign

Bug Bounty Program:
forum.biblepay.org/index.php?topic=408.0

Request Funds from Monthly Budget Proposal System for your work:
forum.biblepay.org/index.php?board=5.0



Exchanges:

coinmarketcap.com/currencies/biblepay/markets/

coingecko.com/en/coins/biblepay/trading_exchanges#panel











Whitepaper:







Explorers:







Partners/Aggregators:






Specifications:

Launched: July 23, 2017
Algorithm: Proof of BibleHash (POBH)
Mining Strategy: CPU only (GPU/ASIC Resistant)

No Premine / No ICO

Block Target: 7 Minutes
Blocks Per Day: 205
Transaction Speed: Supports InstantSend

Max Supply: 5.2 billion BBP by year 2050

Circulation Characteristic: Deflationary
Emission Rate: -1.5% every month (19% per year compounded deflation)

Emission Schedule:
wiki.biblepay.org/Emission_Schedule

Economics:
wiki.biblepay.org/Economics



Block Reward:
https://www.biblepay.org/#Technical%20Details



Sanctuaries (Masternodes):

To reduce sell pressure on our currency, our sanctuaries now sponsor one orphan each (provably), in accordance with our POOS (proof-of-orphan-sponsorship) algorithm.

Additionally, we now liquidate raised XMR (raised through XMR-BBP merge mining) for our remaining charity expenses.



Governance & Budget System:
- Understanding Governance
                                                                   
Collateral Requirement:
4,500,001 BBP

 

Statistics:
- Masternodes.Online
- Masternodes.Pro
- MasterNodeCap
- Masternode.Live
- Masternodes Buzz
Setup:
- Step by Step Guide
- One Click Install Script
- Upgrade Deterministic
____________________________

Monitoring:
- NodeCheck.io



Charity:
**  We only partner with charities over 75% efficient, meaning over 75% reaches the beneficiary. **

 



Accountability:
- accountability.biblepay.org
- Public Investigation



Social:

Forum      - forum.biblepay.org
Twitter     - twitter.com/BiblePay
Reddit      - reddit.com/r/BiblePay
Discord    - discordapp.com/invite/yWgbKdM
Facebook  - facebook.com/BiblePay
Telegram  - t.me/biblepay_airdrop

            



CAUTION: "Although BiblePay has a deflationary emission schedule, there is no guarantee of positive investment returns against other major inflating currencies. Past returns are not indicative of future results. We are a utility and not a security. Please do not invest in BiblePay unless you know all of the risks of cryptocurrencies"



Original Announcement

2nd Announcement








White Paper Links:

Chinese White Paper - https://san.biblepay.org/Mission/BiblePay_WhitePaper_Chinese.pdf



Forum Rules:

1. Do not make assumptions or false statements - For example, if you are not 100% sure of a statement being fact, you must state "in my opinion... " or "I believe...", especially with technical posts that could mislead investors. 

2. Talk in a nice tone and manner, be polite and appreciative.  Avoid swearing.

3. Be willing to do work/research/experience, or Find someone who can, and assume other community members are busy.  This is a group effort.

4. Moderators may delete your post if you are argumentative or make mean spirited posts.

5. If you have a problem with the mod team or an official member of the dev team, you must post with an innocent until proven guilty attitude.  The devs aren't out to get you. If you do not receive a response, break the problem up into a simpler problem and post the question again with a positive attitude.

6.  Your primary purpose on this forum is to help others and make constructive posts.  If you are a net negative to the community we reserve the right to delete or report the posts to bitcointalk mods.

7.  Do not post anything that misleads investors.  Proofread your post before posting as it cannot be deleted for 24 hours.  If you are not sure, ask someone else first.

8.  Your posts may be deleted or you may be banned from this thread if you have a history of making offensive posts.

9.  After 3 offensive posts your future posts and/or your account may be banned at the sole discretion of one of our forum administrators.

64
Would it be useful for us to create the ability for a user with not enough collateral (to host an entire sanctuary (4.5MM)) - to instead, be able to invest in a fractional share of a sanctuary on foundation.biblepay.org?

The fractional share would pay dividends back to the hodler's based on the fraction invested.

The foundation would do this for a tiny fee (IE, probably barely more than the price of hosting).
The pro would be we could attract more outside investors into biblepay.

I believe BBP would also be able to maintain the sanctuaries, so this is  not only a turnkey hosting service but also a fractional share service.

I think if we do this we will add higher security to foundation.biblepay (2FA) and cold wallets, then I will feel better about hosting this, that is if we decide to schedule this in.

According to MNO an investor makes 45% for HODLING:
https://masternodes.online/currencies/BBP/

So if we can make this as easy - turnkey - as possible, this would be an avenue for HODLERS , or non techni grandmas, who want cryptocurrency exposure to invest where Dynamic Whale Staking failed to have the full resources available for them.



65
Archived Proposals / RandomX Giveaway for New RandomX Miners
« on: March 23, 2020, 02:27:03 PM »
***** New RandomX Welcome Gift to onboard new RandomX Miners - now 33,000 BBP ! *****



To claim the faucet reward:

1. Create an account here at our forum (forum.biblepay.org).
2. Change your profile picture to either an avatar or your picture.
3. Download and sync biblepay (v1.5.1.4+).  NOTE: This must be the DESKTOP version of biblepay, not the cell phone version.
4. Click Tools | Information | Console     
       From the RPC console type : faucetcode
5. Paste the faucet code in a post here in this thread, along with your country.
     (Optionally read more about biblepay and salvation at foundation.biblepay.org.)
6.  Start mining against foundation.biblepay.org with randomx, so we can see your address in the leaderboard.
**** BE SURE TO MINE FROM THE BIBLEPAY ADDRESS THAT begins with your 'faucetcode' above.
For example, if your faucetcode is:
BzXj5kV9LVUZGF4ipFCRmkzBbZu366grJt-1-41-89-52-131
then you will need to mine with randomX from address:
BzXj5kV9LVUZGF4ipFCRmkzBbZu366grJt

6b.  Here are the directions to mine with randomx:
https://wiki.biblepay.org/index.php?title=Upgrade_to_RandomX


Then, we will send you a reward of approximately (see OP post header) BBP if we deem you to be new and unique.

NOTE: You do not have to paste your reward address; the faucet code contains enough info for us to send your reward to you.

Thank you for using biblepay.




66
Pre-Proposal Discussion / Vote on your favorite future currency name:
« on: March 05, 2020, 10:00:20 PM »
Biblepay is currently designing a future feature - the ability to offer corporate whitebranding.

In the process of doing this we are also considering offering a DUAL BRAND (One channel for users that are not necessarily Christians, for a Global reach).  This other brand would be our parent company (For example, we could be known as DAC.ngo, our name being DIGITAL AUTONOMOUS CURRENCY.  This brand would still tithe 10% to orphan-charity (with the exact parameters of BiblePay and would share BiblePay's codebase and exchanges).  But we would have two tickers:  DAC & BBP pointing to the same underlying order book.  We would also have dual block explorers, dual forums, and dual branded randomx pools.

Or, you may vote for one new brand only (retiring biblepay).  This will give us an idea of the general feel as to what name feels the best, and if users generally like the idea of a dual brand.

In addition to the potential dual brand, we plan on using the new DAC identity to launch our charity-agent feature.  For example, if we become known as DAC, our DAC foundation website will host the charity agent partner pages and deals by magnitude descending, while biblepay acts as a website for gospel media and preaching and salvation, etc.  Basically the DAC arm would be more aligned with those talking about crypto while the BiblePay brand would have more gospel features and media that might turn away some types of traffic (for example hell videos, etc).  However, we could work together to make subtle inroads into the DAC side to try to save those users.

So hence one of the reasons for the dual coexisting brand.  I am also consulting with SX to seek approval for dual-exchange tickers.



67
Short Term Goals:

Expense and Revenue (Accounting reports)
Orphan collage of active orphans sponsored with clickable bios
Gospel Links / Media (Videos)
Theological articles
Prayer Blog (List of prayers that need prayed)/ Add a prayer / Prayer comments
User Account with email  - and optionally basic permissions (this is so we can notify users of a mandatory upgrade, Or, assign a user a permission-required function in the future, such as allowing a user who is responsible for adding Expenses to add an expense), but note most pages will be viewable anonymously.  User account register, edit, log in, log out.
Add blurb about mandatory upgrades to landing page/ make an actual lading page.
Site should be viewable on the mobile devices; it should also allow navigation, menus, and data entry to be possible.  Wide content and long content should not break the site.




Mid Term Goals:
Christian Dashboard:  This is a list of people you want to save.
Each person will have a status, a goal, a last step.
We will provide materials to help you achieve your goal(s) (Theological articles, illustrations, childrens cartoons, videos, etc).
We should allow each Contact to be guided through a salvation plan (IE a 10 step plan to salvation, etc).
The CRM type dashboard will summarize your ministry state, providing you a tool to become a ministry.


Long Term Goals:
Guest Pastors and Historical sermons, and pay to preach
BiblePay Charity Navigator.
This summarizes charity opportunities by magnitude descending (for our user base).  It allows outside donations to pass through to charities.
The actual design will need to be detailed in a PDF.







URL:

https://foundation.biblepay.org


NOTE: This site is still in beta, so please do not post it on our social media pages until we complete the first Prod release.


So far most of the items in "short term" have been completed - except the Christian Dashboard has not been started yet.





Test Cases for Short Term Goals (Phase 1):


- Test logging in and loggout out.  When you are logged in, you should see your e-mail address on the top right.
Note: Email addresses are not revealed to other users (they can only see your nickname).

- Test adding a prayer and viewing the prayer blog.
- Test Adding a prayer comment (IE, I'm praying for this, I feel the heartache for your family etc).  Test viewing the comments.

- Test adding an avatar to your user, and viewing the image on the blog.

- Test viewing the gospel videos, the theological articles, and the illustrations.

- Provide more landing page images, for example to replace the Lion (as ours needs replaced without the watermark etc).

- Give us any ideas to make it better.  Ideas for Christian processes are also welcome, as we want to appeal to those seeking the gospel etc.



68
TestNet Discussion Archive / BIBLEPAY - RANDOMX INTEGRATION
« on: February 07, 2020, 10:28:39 AM »
RandomX Integration


Welcome to the Biblepay-RandomX Integration Testing thread.

In this thread we will be testing:
Dash 0.14.0.5 changes (these occurred between Nov 2019 and Jan 2020).  These include: https://github.com/biblepay/biblepay-evolution/commit/34851a046392e169fcfa90a0bbcd7a01e1096090 which are ddos and chainlocks enhancements.
Test BiblePay Core RandomX hashes, RandomX solo mining, RX multithread solo mining.
Test xmrig->bbpcore mining against bbpcore using RX.
Test xmrig dual-hash mining.
Test bbp->nomp pool mining.
Stress test biblepay; verify RAM utilization and reliability in running for days.
Test BBP against sancs; regression test sanctuary abilities.
Verify how many BBP memory footprints can fit on a VM.




Starting Version:    1.5.0.2+


(Please ensure your version is greater than this, otherwise your testnet branch will not sync.  We are at block  ____28050_____________ as of February 9th, 2020).
BlockHash 28189:
c6fd*****


Testnet Download Links:


Ready:
     Windows 64-bit:      https://biblepay.org/biblepayevo64develop.exe
     Linux PC 64bits Daemon:     https://biblepay.org/biblepayd-evo-testnet-x86_64-pc-linux-gnu.tar.gz
     Linux 64 bits QT:       https://biblepay.org/biblepay-qt-evo-testnet-x86_64-pc-linux-gnu.tar.gz
     MacOS QT: https://biblepay.org/biblepaycore-evo-testnet.dmg

     Linux 64 bits II (QT/biblepayd/biblepay-cli) zip:  https://biblepay.org/bbp-lin-develop-64.zip

Not ready:
(Unknown state, probably wont run due to memory constraints in the future)
       Linux ARM64 daemon: https://biblepay.org/biblepayd-evo-testnet-aarch64-linux-gnu.tar.gz


To self compile:
https://github.com/biblepay/biblepay-evolution/blob/develop/BuildBiblePay.txt
** Note above:  The instructions have changed, see the changes for randomx.  **

The ETA for MainNet for RandomX  is   April 30th, 2020.




CONFIGURING FOR TESTNET:


Create a biblepaytest.conf file with the following contents:
testnet=1
debug=1

Place the file in ~/.biblepayevolution



Start testnet by typing:
./biblepay-qt -conf=biblepaytest.conf

(Note the blocks and chainstate will sync into the ./biblepayevolution/testnet3 folder.


NOTE: This version will also work side-by-side our production nodes,
so, you also have the option if you are short on machines, to run TestNet side by side a prod node!

To run a TestNet Sanctuary:
https://forum.biblepay.org/index.php?topic=391.msg5968#msg5968

How to create a deterministic sanc from scratch:
https://docs.dash.org/en/stable/masternodes/dip3-upgrade.html

__________________________________________________________________________________________________________________________________________________________________________________________


POOLS for TESTNET (RandomX):

http://rxtest.biblepay.org


Instructions to pool mine:

Launch xmrig.exe or xmrig with these args:

xmrig-bbp-win64.exe -o rxtest.biblepay.org:3008 -u your_biblepay_testnet_address -p your_monero_prod_address --threads nproc_count

Where your bbp receive address for testnet receives Biblepay rewards, and your monero prod address receives prod rewards.


___________________________________________________________________________________________________________________________________________________________________________________________
XMRIG - The dual-hash miner for Biblepay + XMR:

To download Xmrig - binaries are here:

linux-64-bit :  https://github.com/biblepay/xmrig/raw/master/binaries/xmrig-bbp-linux64
windows-64-bit:  https://github.com/biblepay/xmrig/raw/master/binaries/bbprig.zip
(Extract the zip file to a folder on your machine, such as c:\mining\).  Run the miner from a batch file in that subdirectory (this allows the miner to use the dependencies).

To build your own xmrig:
https://github.com/biblepay/xmrig

How to mine:
xmrig-bbp-win64.exe -o rxtest.biblepay.org:3008 -u your_biblepay_testnet_address -p your_monero_prod_address --threads nproc_count
Where your bbp receive address for testnet receives Biblepay rewards, and your monero prod address receives prod rewards.

___________________________________________________________________________________________________________________________________________________________________________________________

How to get a monero production wallet, without running the full monero client (How to get an XMR address to mine to):
Since it is not allowed to mine to SX, we need to go with the next best option.
I'm sure other SPV wallets exist, but I'm currently using this one:

https://mymonero.com/

Just install it, then create a wallet.  Then use that address for your mining reward address.
NOTE:  The XMR side of the pool has a complicated payment strategy that we will explain asap.    For now know that XMR is held until the balance gets to 1xmr, but we will explain how to lower the threshhold etc.

The BiblePay payment side works the same as usual:  After the mined block matures in the pool, all the BBP is dispersed automatically.
____________________________________________________________________________________________________________________________________________________________________________________________


What is so special about XMR+BBP dual-hash mining?  What entices me as an XMR miner to mine BiblePay+XMR?


  • You get double the hashrate.  If you mined at 5,000 HPS with XMR, you will mine at 10,000 HPS with BBP+XMR.  This translates into a potential profit of almost double (minus the 10% we give to orphan-charity).
  • If you generate 1 XMR per month with XMR mining alone, you stand to generate .90 XMR + 80,000 BBP for the same amount of work (the amount of BBP is speculative, based on current rates).

How does this work, why am I earning double what I earn in XMR alone?

The way it works is when you mine XMR alone, the solution can only go to one pool because you are solving a blockheader based on the current height and time and nonce for Monero.
However, BiblePay, with RX integrated can also be solved *at the same time*.  How?  Every randomx hash is checked against our current height and difficulty, giving you one chance to win a biblepay block for every XMR hash.


Why is biblepay interested in integrating wtih XMR?

We are interested because we want more miners, because miners give us more PR.  And we want to help more orphans.  Theoretically, the more XMR miners that dual-hash-mine, the more of our 10% tithe goes to orphan-charity.  That is a win-win for us, XMR, and the orphans!

How are the payments allocated for the work I spend mining?

For every 100,000 hashes, 90,000 go toward your personal account and 10,000 toward our orphan-charity XMR address (IE we tithe 10% to orphan charity, dispersed in XMR liquidations to our charity partners).  Out of the 90,000 that go toward your personal account, every single hash has an equal chance at winning a BBP block.  On the biblepay side, we pay out 100% of the earnings to your personal BBP address (we keep no overhead, unless a pool charges a small bit of overhead, TBD).   On the orphan-charity side that we spend from our collected revenue for our foundation, our liquidated XMR is guaranteed to go 100% to our voted charity (with no overhead kept by us).  We only partner with charities who are 75%+ efficient, such as compassion.com, Cameroon-one, Kairos, etc (therefore the maximum passes through to the children in need.  You can also see our orphan collage at https://accountability.biblepay.org).

__________________________________________________________________________________________________________________________________________________________________________________________________

Hashrate comparison chart, supplied by earlzmoade, showing a 200% increase in hashrates between xmrig plain vanilla and xmrig dual mode:

https://wiki.biblepay.org/RandomX_Hashing_Speed_Comparison










69
Archived Proposals / BiblePay Future Hash Algorithm for CPUs
« on: January 26, 2020, 10:09:36 AM »
Option 1 - POBH 3.0:  This means we would rewrite POBH (which has the 31,000 verses of the bible) in a way that would run slower in a GPU (than on a CPU) and be very unlikely to work on an ASIC in the future.  This appears to be possible by using .netcore's polymorphism, branching, and large initial required data streams.  In a nutshell it would take more work to move the inital calculated stream to a GPU than to perform the operation on the CPU.  The CPU is also the only way to execute the dotnetcore commands.

Option 2 - Math Prize:  Embed one of the worlds greatest math problems in the next algorithm, to give BBP a chance of winning the $1 mil prize, for example.  One example is the Reimann Zeta hypothesis, when calculating Zeta on the critical strip above 10 to the 30th power, these zeroes become extremely hard to calculate and elusive (the highest found is 10 to the 30th).  https://www.claymath.org/millennium-problems/riemann-hypothesis

Option 3 - Useful Work:  This option is similar to #1, in that our hash function would be in dotnetcore, but the difference is we would update the code occasionally using auto-upgrades.  And the code would perform some type of useful work; similar to what is done in boinc projects.  We would find a useful algorithm and use it until it needs upgraded (such as CFD, for instance that Togo recommended). 

Option 4 - RandomX and dual revenue streams for the miner:  The idea here is that we switch to the randomx hashing algorithm, for core wallet, pool and miner.  We add the ability to allow the miner to mine any randomX coin (we do this by querying the block-key which changes every 2048 blocks in all randomX coins, and making our hash algorithm solve for an *equation* rather than the diff level. )  This way, our miner can perform useful work that generates revenue, by mining XMR or another randomx coin, for instance.  However the difference is, every hash that is calculated in the randomX virtual machine would have a chance at solving the current BBP block also.  This would provide a dual revenue stream for the miner.  Theoretically, we would be a more enticing project for every randomx miner, simply because of the dual revenue.  This algorithm appears to not only be possible, but 95% efficient, meaning that each hash counts for both the primary randomx target (ONE only), plus BBP.  The theoretical algorithm we would use is :  X11(PrevBlockHash + CurrentRandomXHash) < DiffLevel(CurBBPBlock).  Note this is novel and unique in that our diff and block spacing can be in parallel to RandomX.  It also means the miner can mine any randomx pool or coin, and not need the Monero wallet for example (they will need the SPV wallet for the coin they mine).   


70
Archived Proposals / BiblePay as a Global Charity Agent
« on: January 14, 2020, 05:52:10 PM »
This is an idea for a real world use-case for BiblePay.  Continuing the discussion on 'dimensions of a crypto' we have established that (https://wiki.biblepay.org/Dimensions) (if given 3 dimensions: Mining,  Innovation, real-world-use-cases), we score high on Mining (PODC), high on Innovation (Dashpay etc), and low on real-world use cases.

This idea involves either being a charity broker, or a charity agent.  Similar to the way a transistor works, we would 'enable' a charitable transaction - also by providing a reward back to the donor.  This would be the reason a donor would choose BBP over going directly to the charity.

Why would BBP be favorable?  We could constantly aggregate charities providing the 'best deal' in a web resource constantly updated.  For instance, lets say Korean orphans are in desperate need, and the orphanage offers a 30% discount.  Or, if we have matching funds available.  And, with corporate matches, and partnerships we may create a partnership discount.  Also we have platform fees charged by the big leagues (9%) plus transaction fees (3%), and all of this adds up to a huge amount of overhead.  The big leagues pay serious money to vet charities.  We can leverage this by downloading charity research for vetted orgs, and keep this in the folder for the org, and only partner with vetted orgs.  This will also save BBP all of the expenses (in vetting) - if we require pre-vetted orgs vetted by third parties with recent reports.

Looking at Charity, this is a huge untapped market in global finance.  We are obviously not tapped in any way, as the American charity donations are $390 billion annually, and global cause is over a trillion $.    Therefore this is a real world endeavor, so lets set our sights higher.

Let us create use cases for this feature.

In the current scenario (POOM), we match a miner with a charity.  Currently, we spend 10% of our blockchain emissions on charity.  But, we don't attempt to negotiate any discount with our charities, we spend the retail amount ($40 per child).  And this is technically not what I'm suggesting (I do not want to slim down the profit), I simply want to create a competitive market.  What we can do is ask each new charity partner as they are vetted, to offer us a  5-10% networking fee to be approved for the account - this would end up resulting in pooled rewards for the donor  (see below) - let us call this "Discount appeal A".

Next, there are many, many examples in the corporate world of companies that match employee donations.  Sometimes 2, 3, 4 or 5* the match is available.  We need to reach out for a pilot company, and design a flow that would allow an employee to sponsor a child, and facilitate the match. 

Next, there are real world examples - constant examples of 'matched funds' available at companies such as globalgiving.  I myself have sponsored over 10 kids last year with a match (that helped 20 kids), and, once through CARE, utilized the match of a NYC donor to double my CARE contribution.  We need to locate and partner with the match.  We can use the Match funds to offer a discount on the 'available charity for donation list' page - and this will be very enticing when a user is deciding to give through us (to see a 50% match, or 50% discount on the list).

Next, there is a platform fee of roughly 8%-9% charged by companies like GlobalGiving (and also a 3% network processing fee), for every donation!  This is huge.  (https://www.globalgiving.org/aboutus/fee/) .  This means $1000 given through globalgiving actually is reduced by 12% ($120) for a net receipt to the charity of 880$!  This point is one of the biggest points here.  This means, we can appeal directly to a vetted charity, receive a network-fee discount in our negotiation of new partnership (from point A above) - to broker the transaction.

This 5-10% total discount would entice the user to give through us (instead of going through globalgiving).  Because when we list each row, we will list the BBP reward available.  Then, we give the donor a refund in BBP, at the applicable % negotiated (creating a competetitive environment for new givers).
This gives the user 3 reasons to choose us :  Donating to causes with matches, donating with programs with discounts, bbp-reward back.

Real World Example:

We partner with Cameroon-One, Compassion, and Korean-Children Institute.  Cameroon-One negotiates a 5% discount with us, Compassion 5%, and Korean 10%.  This means right off the bat, Cameroon-One drops to $38 per child (because they are looking for partnershps and quantity), while if you go directly through cameroon, you pay $40. 

Next, we locate a charitable match partner (IE the same one globalgiving uses in NY).  They usually offer a match to the 501c3 for proof of a donation.  Then we apply this to our advertising page:

Cameroon-one     $38        With Match $19.00     
Compassion           $36         With Match $18.00

Note that what would happen is an inbound donor would choose an amount of the donation, say $380, and pick Cameroon-One.
We would automatically apply the match, and donate $760 to cameroon-one.  However, cameroon-one would pay a network fee of 5% (or $38) and this would go back to the donor in the form of BBP (not fiat).  Additionally, we could also pay a percentage of our charity budget for this transaction as an additional reward (of between 1-10% see chart based on price), however this additional reward would be capped at no more than 1% per donation of our total budget (IE if we have $2000 available, only a max of $20 could be paid in this additional bonus).  So lets say the BBP price is still on the chart level where 2% is being paid for rewards, then $15.60 additional in BBP would be added.   So this donor would receive $15.60+$39=$54.60 reward in the form of BBP (our coin would not keep the profit).  A random sanctuary would facilitate the transaction (IE document it and enter it in and execute it).  This would also be tax deductible, as the payments would go directly from the donor to the charity, and BBP would extract proof-of-transaction, and save the data so we can give real world credit for this on our web site etc.


Proposed Price breaks table :
BBP Price                   Charitable Expense Amount (And Governance emission amount)
.01+                             10% to charity (100% from superblock)
.005                              7% to charity (70% of superblock)
.001                             5% to charity (50% of superblock)
.0005                           2.5% charity (25% of superblock)
.0001                           1% to charity (10% of our superblock is emitted)

This table can be refined later, but it shows that we start to limit our payroll, IT expenses, superblock payments, and charity payments down to the governed table emission level while our price is low.  So only 2.5% goes to charity while our price is .0005.  However, we give the full 10% after our price exceeds .01.

So, as a bridge for POOM if we did this, we would sign up partners well in advance, negotiate deals, test in testnet, then we would want to convert POOM back over to donor->charity individual transactions; IE children would be removed from POOM, but left in the hands of the current sponsors for individual transitioning.  The hope would be during the go live we would have at least one match available to make this transition easier (as then the price would be lower to continue those children).

Note that I feel that if we did all this we would also need a 'legacy' page for classic type orphan charity, like we had in the beginning.  For example suppose we have half of our budget available.  We could by default, allow a user to sponsor an ongoing child for N months with no hassle.  So we would have both transaction lists of agent assisted transactions and lists of sponsored orphans sourced from our overflow funds.

Im thinking we would break out the fiat / crypto into two distinct services and offer both.
Fiat transactions would work like stated above.

But we should have a "donate" process for Crypto also.
We could pilot that with our orgs that already accept crypto (as it would get very tricky to make a crypto gateway available and force a sanctuary to liquidate funds, or lose their santuary if they did not perform).

Let me show an example:

Lets assume out of 10 charities, 5 will accept BBP+BTC.  We mark these 5 as crypto enabled.
We would want the transaction to be sent from the donor directly to the charity in crypto.
Then the charity would as usual send the network fee later back to us to disperse to our user.

What I'm wondering is, will this be used by the world if we make a brand new dedicated web site for this?

I'm a little more optimistic about this than some of our previous ideas.

Additionally, this entire idea seems to completely remove sell pressure from us as a coin.
All donor payments go directly to our charities in gross dollars, they receive a fat discount back for doing it.

The donations are tax deductible because they send To 501c3 enable charities.

One interesting thing that might happen in the case of a rich donor who has $1 billion to spend, lets say Trump decides to give $1 million to Cameroon-One.
This would cause Cameroon-One to send $50,000 in BBP back to Trump.  This is interesting because they would need to buy the bbp to send it.  Our governance emission would be $20 for this tx. 



Edit:  Another element I want to add, is ensuring our emission schedule completely matches our
target schedule here:
https://wiki.biblepay.org/Emission_Schedule
So what this means is I propose we tweak our internal deflation rate target to exactly match the Dec 2020
 target emission amount.  This is not a lot, or a major change to the deflation % level, but we have emitted about 100 million extra coins as of the current date and I feel we should shore this up for our Q3 2020 mandatory - we would end up increasing the deflation from 20.04% to something like 21% for example (after running the calculation).


And finally on an unrelated note, I will need to add a different thread for this subject:  Slightly modifying the POBH internal miner.  Things are pretty good right now.  But I believe God wants it perfect (the issue I have with this is "fair weights and balances").  I dont like how we ended up with a 75% mining speed for the solo miners in the core wallet and an increase in speed in the external miner.  So, I will open a separate thread to discuss this.  I mention it because it could be hampering our heavenly backing.  So that makes it important...

And finally one more point I forgot to mention: Globalgiving.  According to their financials they are bringing in $400 million per year of donations (and charging 8% fees on those, to handle those).  What we would do is analyze the top 100 charities, create folders and vet them, and then go to make deals with them, for discounts (this is the amount in BBP the reward will be for).  Then we expose them on a new web site ranked by the deal.  Then we make Donate buttons for our donors.  Then we add the sanc facilitation process.  And the refund process.  And the matching donor partnership and deal and flow.  And in the end the hopes would be browsers from the real world would flow over to us because they stand to gain a rebate of 6% if they give through BBP, and they get to accumulate BBP (crypto exposure).




71
Archived Proposals / Nov 2019 payroll
« on: December 20, 2019, 07:02:46 PM »
Program PODC 2.0.
Program Kairos integration.
Fix bugs in new development in testnet branch.

Commits on Dec 8, 2019
BiblePay …

@biblepay
biblepay committed 12 days ago
 
Commits on Nov 30, 2019
BiblePay …

@biblepay
biblepay committed 20 days ago
 
Commits on Nov 27, 2019
1.4.8.2 - BiblePay …

@biblepay
biblepay committed 23 days ago
 
Commits on Nov 24, 2019
BiblePay - TestNet …

@biblepay
biblepay committed 26 days ago


Commits on Nov 23, 2019
BiblePay …

@biblepay
biblepay committed 27 days ago
 
Commits on Nov 21, 2019
1.4.7.8c-Mandatory Upgrade for TestNet …

@biblepay
biblepay committed 29 days ago
 
1.4.7.8b-Mandatory Upgrade for Entire TestNet …

@biblepay
biblepay committed 29 days ago
 
BiblePay …

@biblepay
biblepay committed 29 days ago
 
[v0.14.0.x] Update release notes with change log (dashpay#3213)

 
Merge pull request dashpay#3202 from codablock/pr_v14_backports …
 
Commits on Nov 20, 2019
1.4.7.7 - Mandatory Upgrade for TestNet …

@biblepay
biblepay committed on Nov 20
 
BiblePay - TestNet …

@biblepay
biblepay committed on Nov 20
 


Capping @ 3mil due to our low price.


72
Archived Proposals / Kairos Childrens Fund Recurring charges Nov 2019
« on: November 30, 2019, 07:49:50 PM »
11B   Helena NARCISO   1 - EL   $20
14B   Princess CABUGNASAN   4 - EL   $20
12B   Tajana Veroso   5 - EL   $20
13B  Pepe Gabriel   12 - SHS   $25
16B   Earl Darren Chiu   5 - EL   $20
Rowena Paladar   11 - SHS   $25
12B   Dante Balansag   10 - HS   $23
10B   Jovelyn Cadusale   11 - SHS   $25
17B   Kate Rebutazo   10 - HS   $25
      $203


Andy is requesting 1,201,283 bbp to pay 9 of our children up (out of 21) to the end of 2019.

Our total portfolio contains these children at $20-$25 per month:

Eda Mae Omotong
Shane Marie Francisco
Wendy Domik
Rhyejiam Cielo Alqiza
Brent Aaron Cresencio
John Gabriel
Jill Jangin
Ruth Alos
Jacious Amil
Kate Rebutazo
Genevieve Umba
John Rendal
HELENA-NARCISO
DANTE-BALANSAG
PEPE-GABRIEL
PRINCESS-CABUGNASAN
ROWENA-PALADAR
KENT-SUAN
ANGEL-OZOA
JOVILYN-CABUSALE
MARKKIS-UMBA


Requesting 1.201MM from the foundation to pay Andy during the non-POOM to POOM bridge era.


73
Archived Proposals / PODC TEAM REQUIREMENTS
« on: November 22, 2019, 11:51:35 AM »
I believe this poll is relatively self explanatory  :o , but please ask any questions if I missed something.

Thank you for voting!


74
Archived Proposals / Payroll Nov 2019
« on: November 19, 2019, 10:18:52 AM »

MainNet commits:

Commits on Nov 1, 2019
1.4.5.2-Leisure Upgrade …

@biblepay
biblepay committed 18 days ago
 
Commits on Oct 30, 2019
1.4.5.1c-Leisure Upgrade …

@biblepay
biblepay committed 20 days ago
 
Commits on Oct 24, 2019
1.4.5.1b-Leisure Upgrade …

@biblepay
biblepay committed 26 days ago
 
Commits on Oct 23, 2019
1.4.5.1-Leisure Upgrade …

@biblepay
biblepay committed 27 days ago
 
Commits on Oct 21, 2019
1.4.5.0d-Leisure Upgrade …

@biblepay
biblepay committed 29 days ago
 
1.4.5.0c-Leisure Upgrade …

@biblepay
biblepay committed 29 days ago
 
Commits on Oct 14, 2019
Merge pull request #22 from sunk818/patch-1 …

@biblepay
biblepay committed on Oct 14
 
Merge pull request #23 from sunk818/patch-2 …

@biblepay
biblepay committed on Oct 14
 
Commits on Oct 11, 2019
1.4.5.0b - Leisure Upgrade …

@biblepay
biblepay committed on Oct 11
 
1.4.5.0-Leisure Upgrade …

@biblepay
biblepay committed on Oct 11

Also I worked on NOMP for 60 hours this month.



Capping @ 3 mil due to budget constraints.


75
Archived Proposals / Dynamic Whale Staking
« on: November 08, 2019, 05:36:06 PM »
This is a concept to be considered:  Dynamic Whale Staking.

The problem statement:  We need more users and more investors to make biblepay more popular. 

Solution:  Make a feature in BBP that allows 'latent BBP' to be 'staked' for a whale-unit reward.  Part of the goal is to make this as easy as possible; no complicated smart contracts, no daily wallet unlocks, no leaderboard, just simply buy the BBP on the exchange, load the wallet and run the command that burns the coins.


________________________________________________________
PROPOSED CHANGES TO EMISSION SCHEDULE WIKI:
https://wiki.biblepay.org/Emission_Schedule_2020
** NOTE:  THERE ARE NO NET CHANGES TO THE EMISSION TOTAL AMOUNT OR TOTAL MONEY SUPPLY,
however, the changes included here are:  A) We allow room for DWS rewards - starting in 2020 - by increasing our deflation percent from 19.5 to 20.04%, and allocating an additional maximum of 10% (of our gross monthly block reward) towards DWS rewards (This does *not* decrease the gross block reward, the sanctuary reward, or the POBH reward or the GSC contract amount).  If the DWS rewards are not used, because the DWS stake is never burned, then the BBP is never actually spent from our emissions.  (In this case the actual total money supply in BBP would be less than 5.1 B at the end of the schedule depending on how much is never spent).
________________________________________________________

Why would someone want this:  A person who is seeking cryptocurrency exposure will be looking at coins to invest in with certain characteristics.  I feel our coin has a bright future because:  Its a feel good investment (we do tithe 10% to orphan charity, so the utility of our organization works for you), we are deflationary in emissions per year, we are a HODLing community with governance meaning we have a high % locked up in sancs, and finally - the investor will be comparing ways to get more coin-unit rewards through proof-of-work or mining etc. 

Our original money supply covenant:  We will need to ensure we don't break our covenant.  This would be accomplished by allocating a percent of our emitted coins per year toward this project - in a certain band of years, IE 2020 through 2030, and increasing our deflation rate to pay for the feature.  So we would have no net changes in our total supply, but we would modify our coin emission chart to include this feature over 10 years.  In laymans terms this means we would emit 10% more total coins for 10 years, but we would increase our deflation % per year to cover the change.

Emission Changes:  In this proposal we allocate 10% more than our current annual emission rate (which is currently 612MM per year), therefore we would spend up to 5,083,333 per month on 'dynamic whale staking' deflating at our standard deflation rate (of 19.5%).  However note, this is the absolute maximum, if the product is 100% allocated.  If the feature is not used, these coins would not be emitted for whale staking.   We will also decide how much we need to increase our deflation %.


Full Safeguards:  The DWS money supply ratio would be hardcoded in the wallet for full safeguards, to ensure the wallet cannot emit more than the designated existing total plus the DWS for that month.  So, if we currently emit 50MM in a given month, the wallet would not allow more than 55MM to be emitted in a given month, due to the hard rules.  Additionally, the recipients of each DWS would need to be approved by all the sancs (the sancs who create the daily superblock would evaluate every DWS record and add it to the superblock).  So there will be no chance of a miner adding a DWS that is unauthorized. 

The core wallet will be generating the coins for the investor from the coinbase, so solvency is guaranteed.  BBP cannot go bankrupt from DWS.

Provably identifiable DWS burns:  Since DWS uses a provable burn record, it will not be possible to fake a burn, and it will be provably demonstratable that the burn address does not have a corresponding private key.  Rob will attach the mathematical proof to this proposal that shows how to create a certifiably provable burn address for Biblepay with no corresponding private key.   

-=-=-=-=-=-=-=-=-=

EDIT:  I am attaching the source code that facilitates the generation of a non-spendable-bbp address for both testnet and Prod, based on the first public key derived from an unusable private key of {0x0} (See attached file: DynamicWhaleStaking.cs).

This code creates a BBP keypair using a blank private blank key - ie hexcode {0x0} - that is a provably unspendable private key. This routine generates this public address :  B4T5ciTCkWauSqVAcVKy88ofjcSasUkSYU (This is the first public address from the 0x0 private address that is a valid spending address).  So if you send BBP to this address it will be lost forever.

=-=-=-=-=-=

Mechnical operation:

We will allow a DWS duration of between 7 and 365 days.

The dynamic-whale-reward will be quoted on the screen in 'test' mode - and will match on every biblepay client until the quote is consumed.
It will be updated block to block.

To protect the system from hogs, we will use two moving averages, annual saturation and monthly saturation.
The monthly saturation will primarily drive the quoted dynamic-whale-reward.

Full example of a DWS whale stake in action:

getdwsquote
Amount staked: 1,000,000
Dynamic-whale-unit reward: 15
This means the user would potentially receive 150,000 bbp in reward one year after the coins are burned, if bbp returns them (they are 100% at risk, and we will explain this by posting a risk notice).

(Allowed stakes can be between 100 and 1,000,000 bbp):
dws 1000000 receive_address 365 authorize true
In this case, the whales stake will be sent to the burn address;
365 days later, the whale will receive the original 1mil back, plus 150,000 in additional coins.

The reward algorithm should stabilize at a point where the stake-reward emissions average out to be the allocated projection.

Note:  The shorter term rewards are penalized by 50% divided by the span. 
So a DWU reward of 100 will only be 50 if the duration is 1 month.

75 for 6 months.  100 for 12 months.

  This will encourage DWS whales to lock the coins for longer durations, and free up more of the DWS rewards for more distinct users (because those who choose short spans will receive less rewards).  This will be accomplished by storing the duration on the burn itself, so the actual DWU reward
 will be calculatable off of the base.

Example:
Current DWU-reward level is 50 for 365 days.
DWU-reward is  37.5 for 6 months.
DWU-reward is 25 for 1 month.

User A types  : exec dws 10,000 365.  They will receive receive 10,000 + 5,000 after 365 days.

User B types  : exec dws 10,000 180.  They will receive will receive 10,000 + 1,875 in 180 days.


Target Algorithm version 1.1:

"Two saturation levels are monitored.  The Annual saturation level is comprised of the total outstanding (owed and unpaid) DWS stakes over the next 365 days.

The Monthly saturation level is comprised of the total outstanding owed over the next 30 days."


Annual and Monthly Saturation Equation:
SE_Percent = Total_Outstanding_Coins_Owed / Maximum_DWS_Reward_Amount_For_The_Period


1.  If Annual Saturation is > 95%, drop DWU reward level to zero (for quotes).
2. If Annual Saturation <= 95%, offer the inverse of the monthly saturation level as a DWU reward.

Inverse of monthly saturation level:

IA = 1.0 - Monthly_Saturation_Level

ROI quote = IA * MAX_DWS_DWU

Example:

1.  Annual saturation level is at 25%.  Monthly Saturation is at 50%.  Since IA equals 50% (for 365 days), the quote would be .50 * MAX_DWS_ROI = 100 DWU.

2.  Annual saturation level is at 25%.  Monthly Saturation is at 90%.  Since IA equals 10% (for 365 days), the quote would be .10 * MAX_DWS_ROI =  10 DWU.

3.  Annual saturation level is at 96%.  Quote = 0 DWU.

4.  Annual saturation level is at 94%.  Monthly Saturation is at 1%.  Quote = .99 * MAX_DWS = 198 DWU.

5.  Annual saturation level is at 50%.  Monthly Saturation is at 99%.  Quote = .01 * MAX_DWS = 2 DWU.

Risk Rules:  (Rules to mitigate risk):

Each burn will be audited in the memory pool before accepted (meaning a burn can be turned down by all the nodes, if for example the burn is created fraudulently, or, if the burn will result in an overage condition for BBP).
Rule 1:  Each node will check the components of the burn, to ensure they match the quote available, the duration available, and the availability of the DWS ROI.   Check the bounds for each component also.  (Otherwise if any of this fails, reject the burn).
Rule 2:  No more than 5 mil in gross stakes per day.  This will limit our exposure for GSC contracts to never pay more than 5 mil back to whales in a given day.
Rule 3:  If the Annual Saturation level > 95%, reject the DWS.
Rule 4:  Each node will re-assess the 'total whale metrics' as each transaction occurs.

Burns rejected by the memory pool will automatically refund the funds back to the sender (actually, the transaction will be rejected, the same way a conflict or a double spend is handled).

Howey-test protection, to ensure biblepay stays a utility:

We will add a warning to the DWS burn method:

Your coins are 100% at risk if burned.  This is a self directed action by you.  Type authorize to acknowledge that burning the coins results in a potential entire loss with no future expectation of profit, and biblepay will be held as a harmless utility for this self directed action.  We do not promise you an increase in value for any
 of your coins!  We do not promise to pay you back for any burned coins, and coins are 100% at risk. 




Pages: 1 2 3 4 [5] 6 7 8 9 10 11