BiblePay Unchained

From BiblePay Wiki
Jump to: navigation, search

BiblePay Unchained adds many new groundbreaking features that we believe will give BiblePay a chance to break into one of the worlds top currencies.

    The following use cases are being considered:
  • Offchain instant wallet to wallet transactions (with sanctuary insurance for the recipient of the funds). For example, sending offchain funds to a coffee shop ensures that the txid will not be reversed for the funds received by the coffee shop.
  • A minimum of 1,000 TPS (transactions per second) for off-chain wallet to wallet transactions, and, for simple value changes (such as using BiblePay as a database or key value store).
  • Invoice signing requests - this means the ability for a web purchase to send a signing request back to the offchain wallet and after a pop-up is authorized to sign the funds, the funds will be sent.
  • A dynamic speed sidechain that stores offchain transactions, settled once per minute (or slower, if there is no activity).
  • The ability to store Files offchain (on a decentralized network, publically). The metadata pointing to the file will be stored in the sidechain. The file segments will be stored around the world.
  • Files will be available from standard HTTPS URLs, but, will be set up with durability across multiple geographic regions, with the intent that even with massive internet outages the files should be available. The files will be redundant, so they will self heal. (See Decentralized File Storage below). We are serious about the availability and reliability of this service, so it will come with an SLA with over 99.5% uptime.
  • Offchain transactions will include: Add a file, Send Money (wallet to wallet) with insurance, Sync Blocks, Update a Value (Update a database or key value store value).
  • Pay-to-Tweet (Tweet to All): In the spirit of anti-censorship, Biblepay will develop a Pay-to-Tweet feature that will allow a Prayer or Tweet to be sent network wide. Recipients will be able to block unwanted tweets. There are two reasons for this: One it will be important for Christians to stay in touch in the end times. Two: For marketing purposes, tweets received will earn you 1 bbp. In the current ecosystem, mass email campaigns are simply considered spam and impossible to send. Advertising services are expensive, and charge for every single delivery. We can make it so our recipient list is always growing, and allow an advertiser to send to the entire group for a small fee (for example, 1 bbp per recipient). The person receiving the tweet receives the bbp *if* the tweet is read. Metrics are sent back to the sender. This may offer a groundbreaking advertising network cheaper than existing offers, and allow biblepay to keep up with communication amongst each other in the end times.
  • E-mail client: We may offer an email client that has the ability to download offchain files, and larger e-mails (TBD). This will be handy if the user wants to archive very important off chain content (such as end-times critical information) and tweets that are important.

Unchained Document Storage

The primary difference with our document storage offer and other storage systems such as (AWS S3, StorJ and SIA), is our document storage is intended to be public. A person would not want to store their personal documents or system backup in our document storage, but, instead, they would want to store information that is valuable to be shared with the world, or, to store a publically facing web site (a set of assets).

One use case for this is anti-censorship. Lately, results from search engines regarding Covid-19, and conspiracy theories seem to be pruned and filtered and ordered in a way that attempts to alter the public thinking mindset. We at BiblePay feel this is a disservice to human rights, and therefore everyone should have the freedom to post valuable information into the cloud for anyone to see. The biblepay network allows you to host data that is widely available across geographic regions publically, and set up to have a durability of a minimum of 2.7* or greater. The data will also be stored on more than one decentralized service at a time, so that it can self-heal if a node goes down.

In the spirit of partnering with the brightest minds (people who have already invested years in this), BiblePay is going to partner with StorJ, to utilize their network of over 5,000 decentralized nodes (across 79 countries) to store the actual data. We will also partner with Vultr and VultrObjects, for their multi-city S3 compatible objects storage database. The idea is that BiblePay will pre-pay for a minimum of five years of service (so that if one of our key developers dies, the rest of the team has time to re-engage and ensure satellites, uplink, and backfill still works into the future). We will transmit each publically available file into the StorJ network, and simultaneously into the VultrObjects database. We will provide Proof-of-storage for the StorJ side and an HTTPS link for the file. We will purchase a large amount of storage in 2020 to get this project started.

In this way BiblePay will be able to offer the durability and availability of the existing cloud storage providers, with a higher content delivery speed for publically facing requests over HTTPS than one service alone can provide.

Key Value Store Changes

Using Biblepay as a database for key value changes means sending a transaction offchain (which is picked up in our sidechain) that contains a key-value pair value change. This value change is reflected in a block on the sidechain that is persisted in the decentralized unchained storage (above). Meaning that the value is permanent. This can be used to write features such as pay-to-tweet and tweet-read confirmations, and e-mail read confirmations.

Real World Examples

    I will now provide real world examples of Unchained anticipating gawks from the real world:
  • John Doe sends 1000 BBP to Jane Doe instantly, off-chain. Jane Does off-chain wallet reflects a higher balance, seconds later.
  • Umberto writes a demo program transferring 1 BBP to Roberto 1,000 times per second for 10 seconds. The web page reflects the actual TPS and balances for demo purposes. This is a demo for BiblePay being a Top 10 coin.
  • John Doe reads 3 PDFs that appear to be valuable for humanity, and saves them to the local hard drive. Next John uploads these 3 PDFs (one at a time) to our Web Portal, receiving TXIDs and URLs for each PDF. He records the URLs in notepad. Next, he composes a Tweet to ALL, paying up to 500 BBP total to reach 500 recipients. He pastes "Hi All, You must see this information:" and pastes the three URLs of the PDFs in. When he clicks Send, everyone systemwide receives a notification of a new Tweet in the address-bar, and as they open the tweets each will receive 1 bbp for reading it. The historical tweets will stay available until deleted.
  • Akimir is writing a new e-mail client for Cryptocurrencies. He decides to use BiblePay, because of our sidechain. In this e-mail client, Akimir decides to offer the ability for recipients to pay each other off-chain.
  • Web Tipping: Off-chain web tipping allows transactions to be signed offline.
  • BiblePay Advertising: BiblePay sends out a system-wide tweet, paying each recipient up to 5bbp to read the tweet.

These are just some of the exciting possibilities. Note that with offchain document storage, the document will never dissapear from the web until the lease expires. We will create the ability to renew leases for objects that need renewed.


Q: Will the offchain storage of documents be stored on sanctuaries, and will these bloat the drive space of the sanctuary?

A: The docs will not be stored on sanctuaries, so this service will not impact our sanctuaries. The docs will be stored on the StorJ network who has over 5,000 nodes and who maintain a high SLA of over 99.5% availability. We will also write the documents into Vultr Object Storage (as a second copy, giving us technically over 3.7* redundancy) so that these have a high performance web URL available (for video streaming and high speed use cases). Object Storage is also stored redudantly inside Vultr, and is capable of self-healing.

Q: Will the file be available if half of the internet is down and we have a tsunami on the East coast?

A: StorJ stores with 2.7* redundancy in 79 countries, so there will be a > 99% chance the underlying data will self heal on that side. Head systems engineer for Vultr said he believes a tsunami will not take out object storage. Since the data is in multiple geographical locations, we believe the liklihood is > 99% the data will be available or it will self heal within 24 hours. If it is not available from the URL, BiblePay will expose multiple endpoints to make the data available (for example, if we are entering the Tribulation).