https://wiki.biblepay.org/api.php?action=feedcontributions&feedformat=atom&user=AdminBiblePay Wiki - User contributions [en]2026-05-21T05:24:35ZUser contributionsMediaWiki 1.31.12https://wiki.biblepay.org/index.php?title=Decentralized_Exchange&diff=6967Decentralized Exchange2025-04-19T10:57:57Z<p>Admin: </p>
<hr />
<div>'''Introduction'''<br />
<br />
<br />
The Biblepay Decentralized Exchange (DEX) was created with various goals in mind:<br />
<br />
* The ability to trade your BBP coins against another currency (such as DOGE), directly with other QT wallet users, without relying on a centralized exchange (CEX).<br />
* The ability to add other currencies, which are compatible with the base58 wallet, into the exchange. This may allow other communities to list their coins inside BBP's DEX.<br />
<br />
<br />
'''<u>Terminology</u>'''<br />
<br />
'''Native Coin''': The BBP built in currency, or a standard BBP Base58/WIF keypair and its value in the BBP wallet.<br />
<br />
'''Colored Coin''': A special coin, with a Base58 address that ends in a 4 digit alphanumeric code that designates value on another network, but stored in the wallet.<br />
<br />
Note that Colored coins cannot be sent out to native addresses (therefore preventing colored coins from going to BBP address on CEXs etc) or diluting their value.Colored coins can only be sent to other like colored addresses, using an RPC command.<br />
<br />
One example of a colored address is "COLORED-DOGE", which ends in dgzz. Another is colored "COLORED-XLM" ending in lmzz.<br />
<br />
Colored coins cannot be sent from unlike colored addresses, XLM cannot be sent to DOGE or vice versa.<br />
<br />
You cannot see colored coins in coin-control; their balances can only be queried with RPC commands.<br />
<br />
<br />
The function the colored coin provides to BBP is:<br />
* Convert Value from a foreign network native UTXO to a BBP colored UTXO<br />
* Seamlessly trade the colored coins in the DEX with other users<br />
* Convert Colored coin value back to native value<br />
<br />
<br />
<br />
'''Coin Control''': From the QT left menu, click Send | Inputs. <br />
This page allows you to pick specific coins that are used in a transaction.<br />
<br />
'''BBP Native Receive Addresses''': From the QT menu, click Window | Receiving addresses. <br />
You will see a list of BBP receive addresses.<br />
<br />
'''TRADING-PUBLIC-KEY''': This address is the only BBP native address the DEX will spend from (for security reasons).<br />
You must deposit BBP into this address in order to place trades where you Buy foreign currency.<br />
<br />
'''TRADING-ASSET-DOGE''': Your wallet will automatically mine a colored DOGE address. <br />
This is your colored BBP DOGE address that will hold native doge.<br />
<br />
'''TRADING-ASSET-XLM''': Your wallet will also mine a colored XLM address. <br />
This is the address that will hold native XLM.<br />
<br />
'''Portfolio Builder''': A satellite program that allows you to earn staking rewards for holding an equal amount of native BBP + foreign (see Extensions).<br />
<br />
'''Exchange Flags''':Exchange Room | Trading Grid | Flags: The Flag "T" means theirs, "M" means Mine. This way you can see your orders are M.<br />
<br />
<br />
<br />
<u>'''Usage'''</u><br />
<br />
<br />
To demonstrate the usage of the exchange we will go through some examples in using the exchange to buy BBP (while selling DOGE) and selling BBP (to Buy DOGE).<br />
<br />
<br />
'''Prerequisites''':<br />
<br />
<br />
If we want to sell DOGE and buy BBP we will need to fund our TRADING-PUBLIC-KEY. In this example, we will send 100,000 BBP from our core wallet to the TRADING-PUBLIC-KEY.<br />
<br />
<br />
Click on Exchange from the left menu.<br />
<br />
<br />
Copy BBP Trading Address to clipboard (that is equivalent to your "TRADING-PUBLIC-KEY" mentioned above). <br />
<br />
<br />
Go to Send.<br />
<br />
<br />
Paste the address in the TO.<br />
<br />
<br />
Send 100,000 BBP to yourself. Now the exchange has funds to trade with. <br />
In this demo we also want to sell some DOGE for BBP. Therefore we need to receive some Native DOGE into the BBP colored address.<br />
<br />
<br />
Click Exchange. Copy the Native DOGE address to the clipboard.<br />
<br />
<br />
Go to your favorite DOGE wallet, and send 10 DOGE to this native address.<br />
<br />
<br />
Wait 2 blocks on the DOGE network, then click the Get button (which means get balance). Once you see the coins exist in your DOGE native address, now they need to be wrapped, or converted to colored DOGE in order to be tradeable.<br />
<br />
<br />
Now click Wrap. Choose the amount (Lets go with 9.9 to ensure there are no transaction fee errors).<br />
<br />
<br />
Look for the result, it should say "Successfully Wrapped" etc. Now you will have .10 Native doge and 9.9 Colored Doge in the "TRADING-ASSET-DOGE" address; and you can see the balances adjust on the top right.<br />
<br />
<br />
'''Placing a SELL Trade'''<br />
<br />
<br />
First let us place a trade to Sell BBP while buying with DOGE.<br />
<br />
<br />
Populate 10000 into the Quantity box.<br />
<br />
<br />
Populate 0.00011001 into the Price box.<br />
<br />
<br />
Click SELL.<br />
<br />
<br />
This will place an order to sell 2.70 DOGE for 10,000 BBP. The order will appear in the Sell grid.<br />
<br />
<br />
Note that if your wallet is locked you will receive an error and will have to unlock the wallet for this tx to be created.<br />
<br />
<br />
<br />
<br />
'''Placing a BUY Trade'''<br />
<br />
<br />
Next let us place a trade to Buy BBP while selling DOGE.<br />
<br />
<br />
Populate 10000 into the Quantity box.<br />
<br />
<br />
Populate 0.00010999 into the Price box.<br />
<br />
<br />
Click BUY.<br />
<br />
<br />
This will place an order to buy 2.69 DOGE for 10,000 BBP. The order will appear in the Buy grid.<br />
<br />
NOTE: You cannot trade with yourself as our atomic tx rejects wash trades with duplicate keys; however you can trade with yourself as long as you use two QT wallets with different key sets.<br />
<br />
Once another buyer enters the market to place an opposing trade with the same quantity and an at or better price than yours, your order will fill atomically.<br />
<br />
<br />
<br />
<br />
'''Partial Fills'''<br />
<br />
<br />
<br />
If your order is bigger in size than their order, a partial fill will occur as long as the partial fill results in a leftover quantity greater than the room minimum.<br />
<br />
<br />
As of April 2025, the DOGE-BBP room minimum is .10 DOGE per trade.<br />
<br />
<br />
'''Atomic Matching'''<br />
<br />
<br />
The matching engine is constantly scanning for trades in the orderbook, where the quantities match and the price is at or better than the limit price; when this pair is found, an atomic transaction is created with two legs in one transaction: Colored coin going from Buyer to Seller AND Native BBP coin going from Seller to Buyer AND the network minimum transaction fee (.00100) paid in Native BBP all built in the single transaction. This means that if anything goes wrong with this transaction (not enough funds on either end, tx fee deficiency, network error, chain is out of sync, chainlocks down) etc, then this transaction will FAIL atomically. This is good, because now the trading board has not changed, and neither buyer or seller is harmed. However, if the transaction goes through, both buyer and seller are satisfied atomically. Meaning that both colored balances and both native BBP balances are instantly updated with no possibility of error on either end.<br />
<br />
<br />
'''Canceling a Trade'''<br />
<br />
<br />
To cancel a trade, simply highlight the row with the trade you placed (yours have M) and click Cancel.<br />
<br />
<br />
'''Insufficient Funds - Orders with no backing collateral'''<br />
<br />
<br />
<br />
Note that we only allow orders to enter into the orderbook, if, at the time of the trade, the user has enough collateral (IE colored coin balance and BBP balance are sufficient to place the trade).<br />
<br />
<br />
However, since we have 24 hour atomic matching while users are offline, it is possible for a user to do an offline spend of a coin that is already in the orderbook.<br />
<br />
<br />
This is not a problem because Atomic trades cannot occur (if coins are spent prior to the atomic tx being created), that part is prevented.<br />
<br />
<br />
The sanctuary thread constantly looks for trades with no backing collateral.<br />
<br />
<br />
The sanctuary will cancel these automatically causing them to disappear from the order book.<br />
<br />
<br />
<br />
<br />
'''Converting your Colored DOGE back to NATIVE DOGE'''<br />
<br />
<br />
To convert your coins back to Native, click Unwrap. Type in the amount of Native you want to convert back (IE 9 in our example above).<br />
<br />
<br />
Once this process finishes, you will see the Native DOGE balance increases back to the original amount (IE 9.99~).<br />
<br />
<br />
<br />
'''Sending DOGE from the biblepay wallet to the DOGE wallet'''<br />
<br />
<br />
<br />
Now to send DOGE out of your wallet back to your home DOGE wallet, go to the RPC console and type:<br />
<br />
<code><br />
exec senddoge doge_to_address amount<br />
</code><br />
<br />
<br />
<br />
<u>'''Technical Specs'''</u><br />
<br />
<br />
We have three types of Sancs, Altar, Sanc, and Temple. <br />
The Temple is required to stake 10* the collateral than the Sanc.<br />
<br />
The Temple runs an additional piece of software, called BMS (BiblePay Middleware System) which contains the BBP API. <br />
The Temple also runs a decentralized sidechain, which creates blocks on demand. <br />
(We are currently at block 21000 on the side chain). Side chain blocks are stored on STORJ. <br />
Each temple node syncs the BBP sidechain blocks up the the tip, automatically.<br />
<br />
When exchange trades are placed in QT, the AtomicTrade is serialized and opensource, except for the colored private key (or the BBP private key).<br />
The private key is encrypted with RSA, and included in the serialized block hex. <br />
The trade is forwarded to a temple, and the temple creates a sidechain BLOCK and stores it in STORJ. Note that the Temple cannot read the private key, because it is encrypted.<br />
<br />
When QT needs a refreshed trading screen, it queries the order book from the Temple. <br />
The Temple aggregates OPEN orders from the sidechain objects.<br />
<br />
<br />
A trading order book is a collection of AtomicTrades where Status='OPEN' and TradingPair='BBP/DOGE'. Each time the orderbook changes, this feed is sent down from the temple back to the QT client.<br />
<br />
Also, the QT client receives a PriceFeed from the Temple which contains the price of USD-DOGE, BTC-USD, BBP-DOGE, etc. The midpoint of the market is assessed by the temple based on the actual orderbook data.<br />
<br />
The Matching Engine is running on the Temple, and it is constantly scanning for trades where quantity matches and price is at or better than the ask.<br />
<br />
When the Temple needs to create an atomic transaction, it concatenates the seller with the buyer, combining it into one transaction using NBitcoin.<br />
<br />
<br />
The private keys are Not readable by the Temple in production, or in debug mode.<br />
<br />
The AtomicTX then is sent into a proprietary Signing piece of code for the Signing request. <br />
The Signer is closed source and is able to decrypt the private key for the atomic tx and place the signature in place and it returns the signed tx to the caller, which broadcasts it to the BBP network.<br />
<br />
<br />
Note that the Ingate and Outgate run on the temple.<br />
<br />
Since it is mission critical to allow a user to receive back the colored coin, we also created a BBP extension, called PortfolioBuilder, that can run on your own machine and do 100% of the Outgate transaction.<br />
<br />
<br />
This is useful for a scenario where, let us say you have $5,000 of colored coin value and our temple is down but the biblepay network is up and you receive an outgate error.<br />
<br />
<br />
We want you to *always* be able to receive your native coin.<br />
<br />
You can launch PortfolioBuilder and do your own outgate in this case.<br />
<br />
<br />
<u>'''Risks'''</u><br />
<br />
<br />
First I want to say at BiblePay, we want you to know your QT keys and your QT wallet is the highest priority and always want every key to be secure.<br />
All of the private keys *<u>'''Other than the Trading Keys'''</u>*, in your QT wallet are 100% private.<br />
<br />
However, the "TRADING-" keys (the 3 mentioned in the beginning) are being used by the DEX to create atomic transactions.<br />
<br />
Although they are RSA encrypted, there is always a small chance that something can go wrong that is unintended.<br />
<br />
So it is best to treat the DEX in a similar way that you do with other CEXs, trade with limited amounts and do not leave large amounts on the exchange.<br />
<br />
Convert the coins back to native BBP when you can. If you do this the potential damage is always limited to the amount "in play" on the exchange.<br />
<br />
<br />
<br />
<u>'''Future State'''</u><br />
<br />
<br />
The current exchange fulfills many of the desirable qualities that were originally scoped, however there are always tradeoffs with each approach.<br />
<br />
In the current approach you have:<br />
<br />
Ability to match atomic trades 24H even when users are offline (plus).<br />
<br />
Mostly Decentralized (User to user trading, requires one designated temple or temple cluster to be online, the temple API must be working, STORJ must be working).<br />
<br />
<br />
However, we may eventually want to improve the exchange making it 100% decentralized through various technological advances.<br />
<br />
For example, maybe the NBitcoin code can be moved into each online client, allowing matching to occur client side as well.<br />
<br />
The tradeoff is the node may need to be online for this to work (at the time the fill occurs).<br />
<br />
Also we may want to move the orderbook from the sidechain to the client side.<br />
<br />
We may also want to move to a market maker model, where market makers buy-sell colored coins and hold the collateral along with an equal amount of BBP.<br />
<br />
We may want to come up with a scheme to change the WIF format of all trading keys so they cannot be under any circumstance, hacked as regular keys.<br />
<br />
Another improvement is to make Portfolio Builder use newly generated private keys for staking, rather than the XLM/XRP exchange keys noted at the beginning.</div>Adminhttps://wiki.biblepay.org/index.php?title=Decentralized_Exchange&diff=6966Decentralized Exchange2025-04-19T10:46:52Z<p>Admin: </p>
<hr />
<div>'''Introduction'''<br />
<br />
<br />
The Biblepay Decentralized Exchange (DEX) was created with various goals in mind:<br />
<br />
* The ability to trade your BBP coins against another currency (such as DOGE), directly with other QT wallet users, without relying on a centralized exchange (CEX).<br />
* The ability to add other currencies, which are compatible with the base58 wallet, into the exchange. This may allow other communities to list their coins inside BBP's DEX.<br />
<br />
<br />
'''<u>Terminology</u>'''<br />
<br />
'''Native Coin''': The BBP built in currency, or a standard BBP Base58/WIF keypair and its value in the BBP wallet.<br />
<br />
'''Colored Coin''': A special coin, with a Base58 address that ends in a 4 digit alphanumeric code that designates value on another network, but stored in the wallet.<br />
<br />
Note that Colored coins cannot be sent out to native addresses (therefore preventing colored coins from going to BBP address on CEXs etc) or diluting their value.Colored coins can only be sent to other like colored addresses, using an RPC command.<br />
<br />
One example of a colored address is "COLORED-DOGE", which ends in dgzz. Another is colored "COLORED-XLM" ending in lmzz.<br />
<br />
Colored coins cannot be sent from unlike colored addresses, XLM cannot be sent to DOGE or vice versa.<br />
<br />
You cannot see colored coins in coin-control; their balances can only be queried with RPC commands.<br />
<br />
<br />
The function the colored coin provides to BBP is:<br />
* Convert Value from a foreign network native UTXO to a BBP colored UTXO<br />
* Seamlessly trade the colored coins in the DEX with other users<br />
* Convert Colored coin value back to native value<br />
<br />
<br />
<br />
'''Coin Control''': From the QT left menu, click Send | Inputs. <br />
This page allows you to pick specific coins that are used in a transaction.<br />
<br />
'''BBP Native Receive Addresses''': From the QT menu, click Window | Receiving addresses. <br />
You will see a list of BBP receive addresses.<br />
<br />
'''TRADING-PUBLIC-KEY''': This address is the only BBP native address the DEX will spend from (for security reasons).<br />
You must deposit BBP into this address in order to place trades where you Buy foreign currency.<br />
<br />
'''TRADING-ASSET-DOGE''': Your wallet will automatically mine a colored DOGE address. <br />
This is your colored BBP DOGE address that will hold native doge.<br />
<br />
'''TRADING-ASSET-XLM''': Your wallet will also mine a colored XLM address. <br />
This is the address that will hold native XLM.<br />
<br />
'''Portfolio Builder''': A satellite program that allows you to earn staking rewards for holding an equal amount of native BBP + foreign (see Extensions).<br />
<br />
'''Exchange Flags''':Exchange Room | Trading Grid | Flags: The Flag "T" means theirs, "M" means Mine. This way you can see your orders are M.<br />
<br />
<br />
<br />
<u>'''Usage'''</u><br />
<br />
<br />
To demonstrate the usage of the exchange we will go through some examples in using the exchange to buy BBP (while selling DOGE) and selling BBP (to Buy DOGE).<br />
<br />
<br />
'''Prerequisites''':<br />
<br />
<br />
If we want to sell DOGE and buy BBP we will need to fund our TRADING-PUBLIC-KEY. In this example, we will send 100,000 BBP from our core wallet to the TRADING-PUBLIC-KEY.<br />
<br />
<br />
Click on Exchange from the left menu.<br />
<br />
<br />
Copy BBP Trading Address to clipboard (that is equivalent to your "TRADING-PUBLIC-KEY" mentioned above). <br />
<br />
<br />
Go to Send.<br />
<br />
<br />
Paste the address in the TO.<br />
<br />
<br />
Send 100,000 BBP to yourself. Now the exchange has funds to trade with. <br />
In this demo we also want to sell some DOGE for BBP. Therefore we need to receive some Native DOGE into the BBP colored address.<br />
<br />
<br />
Click Exchange. Copy the Native DOGE address to the clipboard.<br />
<br />
<br />
Go to your favorite DOGE wallet, and send 10 DOGE to this native address.<br />
<br />
<br />
Wait 2 blocks on the DOGE network, then click the Get button (which means get balance). Once you see the coins exist in your DOGE native address, now they need to be wrapped, or converted to colored DOGE in order to be tradeable.<br />
<br />
<br />
Now click Wrap. Choose the amount (Lets go with 9.9 to ensure there are no transaction fee errors).<br />
<br />
<br />
Look for the result, it should say "Successfully Wrapped" etc. Now you will have .10 Native doge and 9.9 Colored Doge in the "TRADING-ASSET-DOGE" address; and you can see the balances adjust on the top right.<br />
<br />
<br />
'''Placing a SELL Trade'''<br />
<br />
<br />
First let us place a trade to Sell BBP while buying with DOGE.<br />
<br />
<br />
Populate 10000 into the Quantity box.<br />
<br />
<br />
Populate 0.00011001 into the Price box.<br />
<br />
<br />
Click SELL.<br />
<br />
<br />
This will place an order to sell 2.70 DOGE for 10,000 BBP. The order will appear in the Sell grid.<br />
<br />
<br />
Note that if your wallet is locked you will receive an error and will have to unlock the wallet for this tx to be created.<br />
<br />
<br />
<br />
<br />
'''Placing a BUY Trade'''<br />
<br />
<br />
Next let us place a trade to Buy BBP while selling DOGE.<br />
<br />
<br />
Populate 10000 into the Quantity box.<br />
<br />
<br />
Populate 0.00010999 into the Price box.<br />
<br />
<br />
Click BUY.<br />
<br />
<br />
This will place an order to buy 2.69 DOGE for 10,000 BBP. The order will appear in the Buy grid.<br />
<br />
NOTE: You cannot trade with yourself as our atomic tx rejects wash trades with duplicate keys; however you can trade with yourself as long as you use two QT wallets with different key sets.<br />
<br />
Once another buyer enters the market to place an opposing trade with the same quantity and an at or better price than yours, your order will fill atomically.<br />
<br />
<br />
<br />
<br />
'''Partial Fills'''<br />
<br />
<br />
<br />
If your order is bigger in size than their order, a partial fill will occur as long as the partial fill results in a leftover quantity greater than the room minimum.<br />
<br />
<br />
As of April 2025, the DOGE-BBP room minimum is .10 DOGE per trade.<br />
<br />
<br />
'''Atomic Matching'''<br />
<br />
<br />
The matching engine is constantly scanning for trades in the orderbook, where the quantities match and the price is at or better than the limit price; when this pair is found, an atomic transaction is created with two legs in one transaction: Colored coin going from Buyer to Seller AND Native BBP coin going from Seller to Buyer AND the network minimum transaction fee (.00100) paid in Native BBP all built in the single transaction. This means that if anything goes wrong with this transaction (not enough funds on either end, tx fee deficiency, network error, chain is out of sync, chainlocks down) etc, then this transaction will FAIL atomically. This is good, because now the trading board has not changed, and neither buyer or seller is harmed. However, if the transaction goes through, both buyer and seller are satisfied atomically. Meaning that both colored balances and both native BBP balances are instantly updated with no possibility of error on either end.<br />
<br />
<br />
'''Canceling a Trade'''<br />
<br />
<br />
To cancel a trade, simply highlight the row with the trade you placed (yours have M) and click Cancel.<br />
<br />
<br />
'''Insufficient Funds - Orders with no backing collateral'''<br />
<br />
<br />
<br />
Note that we only allow orders to enter into the orderbook, if, at the time of the trade, the user has enough collateral (IE colored coin balance and BBP balance are sufficient to place the trade).<br />
<br />
<br />
However, since we have 24 hour atomic matching while users are offline, it is possible for a user to do an offline spend of a coin that is already in the orderbook.<br />
<br />
<br />
This is not a problem because Atomic trades cannot occur (if coins are spent prior to the atomic tx being created), that part is prevented.<br />
<br />
<br />
The sanctuary thread constantly looks for trades with no backing collateral.<br />
<br />
<br />
The sanctuary will cancel these automatically causing them to disappear from the order book.<br />
<br />
<br />
<br />
<br />
'''Converting your Colored DOGE back to NATIVE DOGE'''<br />
<br />
<br />
To convert your coins back to Native, click Unwrap. Type in the amount of Native you want to convert back (IE 9 in our example above).<br />
<br />
<br />
Once this process finishes, you will see the Native DOGE balance increases back to the original amount (IE 9.99~).<br />
<br />
<br />
<br />
'''Sending DOGE from the biblepay wallet to the DOGE wallet'''<br />
<br />
<br />
<br />
Now to send DOGE out of your wallet back to your home DOGE wallet, go to the RPC console and type:<br />
<br />
<code><br />
exec senddoge doge_to_address amount<br />
</code><br />
<br />
<br />
<br />
<u>'''Technical Specs'''</u><br />
<br />
<br />
We have three types of Sancs, Altar, Sanc, and Temple. <br />
The Temple is required to stake 10* the collateral than the Sanc.<br />
<br />
The Temple runs an additional piece of software, called BMS (BiblePay Middleware System) which contains the BBP API. <br />
The Temple also runs a decentralized sidechain, which creates blocks on demand. <br />
(We are currently at block 21000 on the side chain). Side chain blocks are stored on STORJ. <br />
Each temple node syncs the BBP sidechain blocks up the the tip, automatically.<br />
<br />
When exchange trades are placed in QT, the AtomicTrade is serialized and opensource, except for the colored private key (or the BBP private key).<br />
The private key is encrypted with RSA, and included in the serialized block hex. <br />
The trade is forwarded to a temple, and the temple creates a sidechain BLOCK and stores it in STORJ. Note that the Temple cannot read the private key, because it is encrypted.<br />
<br />
When QT needs a refreshed trading screen, it queries the order book from the Temple. <br />
The Temple aggregates OPEN orders from the sidechain objects.<br />
<br />
<br />
A trading order book is a collection of AtomicTrades where Status='OPEN' and TradingPair='BBP/DOGE'. Each time the orderbook changes, this feed is sent down from the temple back to the QT client.<br />
<br />
Also, the QT client receives a PriceFeed from the Temple which contains the price of USD-DOGE, BTC-USD, BBP-DOGE, etc. The midpoint of the market is assessed by the temple based on the actual orderbook data.<br />
<br />
The Matching Engine is running on the Temple, and it is constantly scanning for trades where quantity matches and price is at or better than the ask.<br />
<br />
When the Temple needs to create an atomic transaction, it concatenates the seller with the buyer, combining it into one transaction using NBitcoin.<br />
<br />
<br />
The private keys are Not readable by the Temple in production, or in debug mode.<br />
<br />
The AtomicTX then is sent into a proprietary Signing piece of code for the Signing request. <br />
The Signer is closed source and is able to decrypt the private key for the atomic tx and place the signature in place and it returns the signed tx to the caller, which broadcasts it to the BBP network.<br />
<br />
<br />
Note that the Ingate and Outgate run on the temple.<br />
<br />
Since it is mission critical to allow a user to receive back the colored coin, we also created a BBP extension, called PortfolioBuilder, that can run on your own machine and do 100% of the Outgate transaction.<br />
<br />
<br />
This is useful for a scenario where, let us say you have $5,000 of colored coin value and our temple is down but the biblepay network is up and you receive an outgate error.<br />
<br />
<br />
We want you to *always* be able to receive your native coin.<br />
<br />
You can launch PortfolioBuilder and do your own outgate in this case.<br />
<br />
<br />
<u>'''Risks'''</u><br />
<br />
<br />
First I want to say at BiblePay, we want you to know your QT keys and your QT wallet is the highest priority and always want every key to be secure.<br />
All of the private keys *<u>'''Other than the Trading Keys'''</u>*, in your QT wallet are 100% private.<br />
<br />
However, the "TRADING-" keys (the 3 mentioned in the beginning) are being used by the DEX to create atomic transactions.<br />
<br />
Although they are RSA encrypted, there is always a small chance that something can go wrong that is unintended.<br />
<br />
So it is best to treat the DEX in a similar way that you do with other CEXs, trade with limited amounts and do not leave large amounts on the exchange.<br />
<br />
Convert the coins back to native BBP when you can. If you do this the potential damage is always limited to the amount "in play" on the exchange.<br />
<br />
<br />
<br />
<u>'''Future State'''</u><br />
<br />
<br />
The current exchange fulfills many of the desirable qualities that were originally scoped, however there are always tradeoffs with each approach.<br />
<br />
In the current approach you have:<br />
<br />
Ability to match atomic trades 24H even when users are offline (plus).<br />
<br />
Mostly Decentralized (User to user trading, requires one designated temple or temple cluster to be online, the temple API must be working, STORJ must be working).<br />
<br />
<br />
However, we may eventually want to improve the exchange making it 100% decentralized through various technological advances.<br />
<br />
For example, maybe the NBitcoin code can be moved into each online client, allowing matching to occur client side as well.<br />
<br />
The tradeoff is the node may need to be online for this to work (at the time the fill occurs).<br />
Also we may want to move the orderbook from the sidechain to the client side.<br />
<br />
We may also want to move to a market maker model, where market makers buy-sell colored coins and hold the collateral along with an equal amount of BBP.<br />
<br />
We may want to come up with a scheme to change the WIF format of all trading keys so they cannot be under any circumstance, hacked as regular keys.<br />
<br />
This way we can promote BBP core wallet as having every key, in an equal original status when BBP was released as secure. (Maybe we combine this feature with Quantum resistant keys, since quantum computers are rising in capabilities very quickly).<br />
<br />
<br />
Another improvement is to make Portfolio Builder use separate private keys, that are not intermingled with the exchange.<br />
<br />
(Currently portfolio builder uses the same XRP/XLM keys as the exchange keys at the beginning of this page, primarily because of the high starting fee required to open an XRP account - 10 XRP, hence the plus is having one account for XRP/XLM).</div>Adminhttps://wiki.biblepay.org/index.php?title=Decentralized_Exchange&diff=6965Decentralized Exchange2025-04-18T23:28:55Z<p>Admin: </p>
<hr />
<div>'''Introduction'''<br />
<br />
<br />
The Biblepay Decentralized Exchange (DEX) was created with various goals in mind:<br />
<br />
* The ability to trade your BBP coins against another currency (such as DOGE), directly with other QT wallet users, without relying on a centralized exchange (CEX).<br />
* The ability to add other currencies, which are compatible with the base58 wallet, into the exchange. This may allow other communities to list their coins inside BBP's DEX.<br />
<br />
<br />
'''<u>Terminology</u>'''<br />
<br />
'''Native Coin''': The BBP built in currency, or a standard BBP Base58/WIF keypair and its value in the BBP wallet.<br />
<br />
'''Colored Coin''': A special coin, with a Base58 address that ends in a 4 digit alphanumeric code that designates value on another network, but stored in the wallet.<br />
<br />
Note that Colored coins cannot be sent out to native addresses (therefore preventing colored coins from going to BBP address on CEXs etc) or diluting their value.Colored coins can only be sent to other like colored addresses, using an RPC command.<br />
<br />
One example of a colored address is "COLORED-DOGE", which ends in dgzz. Another is colored "COLORED-XLM" ending in lmzz.<br />
<br />
Colored coins cannot be sent from unlike colored addresses, XLM cannot be sent to DOGE or vice versa.<br />
<br />
You cannot see colored coins in coin-control; their balances can only be queried with RPC commands.<br />
<br />
<br />
The function the colored coin provides to BBP is:<br />
* Convert Value from a foreign network native UTXO to a BBP colored UTXO<br />
* Seamlessly trade the colored coins in the DEX with other users<br />
* Convert Colored coin value back to native value<br />
<br />
<br />
<br />
'''Coin Control''': From the QT left menu, click Send | Inputs. <br />
This page allows you to pick specific coins that are used in a transaction.<br />
<br />
'''BBP Native Receive Addresses''': From the QT menu, click Window | Receiving addresses. <br />
You will see a list of BBP receive addresses.<br />
<br />
'''TRADING-PUBLIC-KEY''': This address is the only BBP native address the DEX will spend from (for security reasons).<br />
You must deposit BBP into this address in order to place trades where you Buy foreign currency.<br />
<br />
'''TRADING-ASSET-DOGE''': Your wallet will automatically mine a colored DOGE address. <br />
This is your colored BBP DOGE address that will hold native doge.<br />
<br />
'''TRADING-ASSET-XLM''': Your wallet will also mine a colored XLM address. <br />
This is the address that will hold native XLM.<br />
<br />
'''Portfolio Builder''': A satellite program that allows you to earn staking rewards for holding an equal amount of native BBP + colored foreign (see Extensions).<br />
<br />
'''Exchange Flags''':Exchange Room | Trading Grid | Flags: The Flag "T" means theirs, "M" means Mine. This way you can see your orders are M.<br />
<br />
<br />
<br />
<u>'''Usage'''</u><br />
<br />
<br />
To demonstrate the usage of the exchange we will go through some examples in using the exchange to buy BBP (while selling DOGE) and selling BBP (to Buy DOGE).<br />
<br />
<br />
'''Prerequisites''':<br />
<br />
<br />
If we want to sell DOGE and buy BBP we will need to fund our TRADING-PUBLIC-KEY. In this example, we will send 100,000 BBP from our core wallet to the TRADING-PUBLIC-KEY.<br />
<br />
<br />
Click on Exchange from the left menu.<br />
<br />
<br />
Copy BBP Trading Address to clipboard (that is equivalent to your "TRADING-PUBLIC-KEY" mentioned above). <br />
<br />
<br />
Go to Send.<br />
<br />
<br />
Paste the address in the TO.<br />
<br />
<br />
Send 100,000 BBP to yourself. Now the exchange has funds to trade with.<brclass="mw_emptyline_first" />In this demo we also want to sell some DOGE for BBP. Therefore we need to receive some Native DOGE into the BBP colored address.<br />
<br />
<br />
Click Exchange. Copy the Native DOGE address to the clipboard.<br />
<br />
<br />
Go to your favorite DOGE wallet, and send 10 DOGE to this native address.<br />
<br />
<br />
Wait 2 blocks on the DOGE network, then click the Get button (which means get balance). Once you see the coins exist in your DOGE native address, now they need to be wrapped, or converted to colored DOGE in order to be tradeable.<br />
<br />
<br />
Now click Wrap. Choose the amount (Lets go with 9.9 to ensure there are no transaction fee errors).<br />
<br />
<br />
Look for the result, it should say "Successfully Wrapped" etc. Now you will have .10 Native doge and 9.9 Colored Doge in the "TRADING-ASSET-DOGE" address; and you can see the balances adjust on the top right.<br />
<br />
<br />
'''Placing a SELL Trade'''<br />
<br />
<br />
First let us place a trade to Sell BBP while buying with DOGE.<br />
<br />
<br />
Populate 10000 into the Quantity box.<br />
<br />
<br />
Populate 0.00011001 into the Price box.<br />
<br />
<br />
Click SELL.<br />
<br />
<br />
This will place an order to sell 2.70 DOGE for 10,000 BBP. The order will appear in the Sell grid.<br />
<br />
<br />
Note that if your wallet is locked you will receive an error and will have to unlock the wallet for this tx to be created.<br />
<br />
<br />
<br />
<br />
'''Placing a BUY Trade'''<br />
<br />
<br />
Next let us place a trade to Buy BBP while selling DOGE.<br />
<br />
<br />
Populate 10000 into the Quantity box.<br />
<br />
<br />
Populate 0.00010999 into the Price box.<br />
<br />
<br />
Click BUY.<br />
<br />
<br />
This will place an order to buy 2.69 DOGE for 10,000 BBP. The order will appear in the Buy grid.<brclass="mw_emptyline_first" />NOTE: You cannot trade with yourself as our atomic tx rejects wash trades with duplicate keys; however you can trade with yourself as long as you use two QT wallets with different key sets.<brclass="mw_emptyline_first" />Once another buyer enters the market to place an opposing trade with the same quantity and an at or better price than yours, your order will fill atomically.<br />
<br />
<br />
<br />
<br />
'''Partial Fills'''<br />
<br />
<br />
<br />
If your order is bigger in size than their order, a partial fill will occur as long as the partial fill results in a leftover quantity greater than the room minimum.<br />
<br />
<br />
As of April 2025, the DOGE-BBP room minimum is .10 DOGE per trade.<br />
<br />
<br />
'''Atomic Matching'''<br />
<br />
<br />
The matching engine is constantly scanning for trades in the orderbook, where the quantities match and the price is at or better than the limit price; when this pair is found, an atomic transaction is created with two legs in one transaction: Colored coin going from Buyer to Seller AND Native BBP coin going from Seller to Buyer AND the network minimum transaction fee (.00100) paid in Native BBP all built in the single transaction. This means that if anything goes wrong with this transaction (not enough funds on either end, tx fee deficiency, network error, chain is out of sync, chainlocks down) etc, then this transaction will FAIL atomically. This is good, because now the trading board has not changed, and neither buyer or seller is harmed. However, if the transaction goes through, both buyer and seller are satisfied atomically. Meaning that both colored balances and both native BBP balances are instantly updated with no possibility of error on either end.<br />
<br />
<br />
'''Canceling a Trade'''<br />
<br />
<br />
To cancel a trade, simply highlight the row with the trade you placed (yours have M) and click Cancel.<br />
<br />
<br />
'''Insufficient Funds - Orders with no backing collateral'''<br />
<br />
<br />
<br />
Note that we only allow orders to enter into the orderbook, if, at the time of the trade, the user has enough collateral (IE colored coin balance and BBP balance are sufficient to place the trade).<br />
<br />
<br />
However, since we have 24 hour atomic matching while users are offline, it is possible for a user to do an offline spend of a coin that is already in the orderbook.<br />
<br />
<br />
This is not a problem because Atomic trades cannot occur (if coins are spent prior to the atomic tx being created), that part is prevented.<br />
<br />
<br />
The sanctuary thread constantly looks for trades with no backing collateral.<br />
<br />
<br />
The sanctuary will cancel these automatically causing them to disappear from the order book.<br />
<br />
<br />
<br />
<br />
'''Converting your Colored DOGE back to NATIVE DOGE'''<br />
<br />
<br />
To convert your coins back to Native, click Unwrap. Type in the amount of Native you want to convert back (IE 9 in our example above).<br />
<br />
<br />
Once this process finishes, you will see the Native DOGE balance increases back to the original amount (IE 9.99~).<br />
<br />
<br />
<br />
'''Sending DOGE from the biblepay wallet to the DOGE wallet'''<br />
<br />
<br />
<br />
Now to send DOGE out of your wallet back to your home DOGE wallet, go to the RPC console and type:<br />
<br />
<code><br />
exec senddoge doge_to_address amount<br />
</code><br />
<br />
<br />
<br />
<u>'''Technical Specs'''</u><br />
<br />
<br />
We have three types of Sancs, Altar, Sanc, and Temple. <br />
The Temple is required to stake 10* the collateral than the Sanc.<br />
<br />
The Temple runs an additional piece of software, called BMS (BiblePay Middleware System) which contains the BBP API. <br />
The Temple also runs a decentralized sidechain, which creates blocks on demand. <br />
(We are currently at block 21000 on the side chain). Side chain blocks are stored on STORJ. <br />
Each temple node syncs the BBP sidechain blocks up the the tip, automatically.<br />
<br />
When exchange trades are placed in QT, the AtomicTrade is serialized and opensource, except for the colored private key (or the BBP private key).<br />
The private key is encrypted with RSA, and included in the serialized block hex. <br />
The trade is forwarded to a temple, and the temple creates a sidechain BLOCK and stores it in STORJ. Note that the Temple cannot read the private key, because it is encrypted.<br />
<br />
When QT needs a refreshed trading screen, it queries the order book from the Temple. <br />
The Temple aggregates OPEN orders from the sidechain objects.<br />
<br />
<br />
A trading order book is a collection of AtomicTrades where Status='OPEN' and TradingPair='BBP/DOGE'. Each time the orderbook changes, this feed is sent down from the temple back to the QT client.<br />
<br />
Also, the QT client receives a PriceFeed from the Temple which contains the price of USD-DOGE, BTC-USD, BBP-DOGE, etc. The midpoint of the market is assessed by the temple based on the actual orderbook data.<br />
<br />
The Matching Engine is running on the Temple, and it is constantly scanning for trades where quantity matches and price is at or better than the ask.<br />
<br />
When the Temple needs to create an atomic transaction, it concatenates the seller with the buyer, combining it into one transaction using NBitcoin.<br />
<br />
<br />
The private keys are Not readable by the Temple in production, or in debug mode.<br />
<br />
The AtomicTX then is sent into a proprietary Signing piece of code for the Signing request. <br />
The Signer is closed source and is able to decrypt the private key for the atomic tx and place the signature in place and it returns the signed tx to the caller, which broadcasts it to the BBP network.<br />
<br />
<br />
Note that the Ingate and Outgate run on the temple.<br />
<br />
Since it is mission critical to allow a user to receive back the colored coin, we also created a BBP extension, called PortfolioBuilder, that can run on your own machine and do 100% of the Outgate transaction.<br />
<br />
<br />
This is useful for a scenario where, let us say you have $5,000 of colored coin value and our temple is down but the biblepay network is up and you receive an outgate error.<br />
<br />
<br />
We want you to *always* be able to receive your native coin.<br />
<br />
You can launch PortfolioBuilder and do your own outgate in this case.<br />
<br />
<br />
<u>'''Risks'''</u><br />
<br />
<br />
First I want to say at BiblePay, we want you to know your QT keys and your QT wallet is the highest priority and always want every key to be secure.<br />
All of the private keys *<u>'''Other than the Trading Keys'''</u>*, in your QT wallet are 100% private.<br />
<br />
However, the "TRADING-" keys (the 3 mentioned in the beginning) are being used by the DEX to create atomic transactions.<br />
<br />
Although they are RSA encrypted, there is always a small chance that something can go wrong that is unintended.<br />
<br />
So it is best to treat the DEX in a similar way that you do with other CEXs, trade with limited amounts and do not leave large amounts on the exchange.<br />
<br />
Convert the coins back to native BBP when you can. If you do this the potential damage is always limited to the amount "in play" on the exchange.<br />
<br />
<br />
<br />
<u>'''Future State'''</u><br />
<br />
<br />
The current exchange fulfills many of the desirable qualities that were originally scoped, however there are always tradeoffs with each approach.<br />
<br />
In the current approach you have:<br />
<br />
Ability to match atomic trades 24H even when users are offline (plus).<br />
<br />
Mostly Decentralized (User to user trading, requires one designated temple or temple cluster to be online, the temple API must be working, STORJ must be working).<br />
<br />
<br />
However, we may eventually want to improve the exchange making it 100% decentralized through various technological advances.<br />
<br />
For example, maybe the NBitcoin code can be moved into each online client, allowing matching to occur client side as well.<br />
<br />
The tradeoff is the node may need to be online for this to work (at the time the fill occurs).<br />
Also we may want to move the orderbook from the sidechain to the client side.<br />
<br />
We may also want to move to a market maker model, where market makers buy-sell colored coins and hold the collateral along with an equal amount of BBP.<br />
<br />
We may want to come up with a scheme to change the WIF format of all trading keys so they cannot be under any circumstance, hacked as regular keys.<br />
<br />
This way we can promote BBP core wallet as having every key, in an equal original status when BBP was released as secure. (Maybe we combine this feature with Quantum resistant keys, since quantum computers are rising in capabilities very quickly).<br />
<br />
<br />
Another improvement is to make Portfolio Builder use separate private keys, that are not intermingled with the exchange.<br />
<br />
(Currently portfolio builder uses the same XRP/XLM keys as the exchange keys at the beginning of this page, primarily because of the high starting fee required to open an XRP account - 10 XRP, hence the plus is having one account for XRP/XLM).</div>Adminhttps://wiki.biblepay.org/index.php?title=Decentralized_Exchange&diff=6964Decentralized Exchange2025-04-18T14:06:10Z<p>Admin: </p>
<hr />
<div>'''Introduction'''<br />
<br />
<br />
The Biblepay Decentralized Exchange (DEX) was created with various goals in mind:<br />
<br />
* The ability to trade your BBP coins against another currency (such as DOGE), directly with other QT wallet users, without relying on a centralized exchange (CEX).<br />
* The ability to add other currencies, which are compatible with the base58 wallet, into the exchange. This may allow other communities to list their coins inside BBP's DEX.<br />
<br />
<br />
'''<u>Terminology</u>'''<br />
<br />
'''Native Coin''': The BBP built in currency, or a standard BBP Base58/WIF keypair and its value in the BBP wallet.<br />
<br />
'''Colored Coin''': A special coin, with a Base58 address that ends in a 4 digit alphanumeric code that designates value on another network, but stored in the wallet.<br />
<br />
Note that Colored coins cannot be sent out to native addresses (therefore preventing colored coins from going to BBP address on CEXs etc) or diluting their value.Colored coins can only be sent to other like colored addresses, using an RPC command.<br />
<br />
One example of a colored address is "COLORED-DOGE", which ends in dgzz. Another is colored "COLORED-XLM" ending in lmzz.<br />
<br />
Colored coins cannot be sent from unlike colored addresses, XLM cannot be sent to DOGE or vice versa.<br />
<br />
You cannot see colored coins in coin-control; their balances can only be queried with RPC commands.<br />
<br />
<br />
The function the colored coin provides to BBP is:<br />
* Convert Value from a foreign network native UTXO to a BBP colored UTXO<br />
* Seamlessly trade the colored coins in the DEX with other users<br />
* Convert Colored coin value back to native value<br />
<br />
<br />
<br />
'''Coin Control''': From the QT left menu, click Send | Inputs. This page allows you to pick specific coins that are used in a transaction.'''BBP Native Receive Addresses''': From the QT menu, click Window | Receiving addresses. You will see a list of BBP receive addresses.<brdata-mce-bogus="1" />'''TRADING-PUBLIC-KEY''': This address is the only BBP native address the DEX will spend from (for security reasons).You must deposit BBP into this address in order to place trades where you Buy foreign currency.'''TRADING-ASSET-DOGE''': Your wallet will automatically mine a colored DOGE address. This is your colored BBP DOGE address that will hold native doge.'''TRADING-ASSET-XLM''': Your wallet will also mine a colored XLM address. This is the address that will hold native XLM.'''Portfolio Builder''': A satellite program that allows you to earn staking rewards for holding an equal amount of native BBP + colored foreign (see Extensions).'''Exchange Flags''':Exchange Room | Trading Grid | Flags: The Flag "T" means theirs, "M" means Mine. This way you can see your orders are M.<br />
<br />
<u>'''Usage'''</u><br />
<br />
<br />
To demonstrate the usage of the exchange we will go through some examples in using the exchange to buy BBP (while selling DOGE) and selling BBP (to Buy DOGE).<br />
<br />
<br />
'''Prerequisites''':<br />
<br />
<br />
If we want to sell DOGE and buy BBP we will need to fund our TRADING-PUBLIC-KEY. In this example, we will send 100,000 BBP from our core wallet to the TRADING-PUBLIC-KEY.<br />
<br />
<br />
Click on Exchange from the left menu.<br />
<br />
<br />
Copy BBP Trading Address to clipboard (that is equivalent to your "TRADING-PUBLIC-KEY" mentioned above). <br />
<br />
<br />
Go to Send.<br />
<br />
<br />
Paste the address in the TO.<br />
<br />
<br />
Send 100,000 BBP to yourself. Now the exchange has funds to trade with.<brclass="mw_emptyline_first" />In this demo we also want to sell some DOGE for BBP. Therefore we need to receive some Native DOGE into the BBP colored address.<br />
<br />
<br />
Click Exchange. Copy the Native DOGE address to the clipboard.<br />
<br />
<br />
Go to your favorite DOGE wallet, and send 10 DOGE to this native address.<br />
<br />
<br />
Wait 2 blocks on the DOGE network, then click the Get button (which means get balance). Once you see the coins exist in your DOGE native address, now they need to be wrapped, or converted to colored DOGE in order to be tradeable.<br />
<br />
<br />
Now click Wrap. Choose the amount (Lets go with 9.9 to ensure there are no transaction fee errors).<br />
<br />
<br />
Look for the result, it should say "Successfully Wrapped" etc. Now you will have .10 Native doge and 9.9 Colored Doge in the "TRADING-ASSET-DOGE" address; and you can see the balances adjust on the top right.<br />
<br />
<br />
'''Placing a SELL Trade'''<br />
<br />
<br />
First let us place a trade to Sell BBP while buying with DOGE.<br />
<br />
<br />
Populate 10000 into the Quantity box.<br />
<br />
<br />
Populate 0.00011001 into the Price box.<br />
<br />
<br />
Click SELL.<br />
<br />
<br />
This will place an order to sell 2.70 DOGE for 10,000 BBP. The order will appear in the Sell grid.<br />
<br />
<br />
Note that if your wallet is locked you will receive an error and will have to unlock the wallet for this tx to be created.<br />
<br />
<br />
<br />
<br />
'''Placing a BUY Trade'''<br />
<br />
<br />
Next let us place a trade to Buy BBP while selling DOGE.<br />
<br />
<br />
Populate 10000 into the Quantity box.<br />
<br />
<br />
Populate 0.00010999 into the Price box.<br />
<br />
<br />
Click BUY.<br />
<br />
<br />
This will place an order to buy 2.69 DOGE for 10,000 BBP. The order will appear in the Buy grid.<brclass="mw_emptyline_first" />NOTE: You cannot trade with yourself as our atomic tx rejects wash trades with duplicate keys; however you can trade with yourself as long as you use two QT wallets with different key sets.<brclass="mw_emptyline_first" />Once another buyer enters the market to place an opposing trade with the same quantity and an at or better price than yours, your order will fill atomically.<br />
<br />
<br />
<br />
<br />
'''Partial Fills'''<br />
<br />
<br />
<br />
If your order is bigger in size than their order, a partial fill will occur as long as the partial fill results in a leftover quantity greater than the room minimum.<br />
<br />
<br />
As of April 2025, the DOGE-BBP room minimum is .10 DOGE per trade.<br />
<br />
<br />
'''Atomic Matching'''<br />
<br />
<br />
The matching engine is constantly scanning for trades in the orderbook, where the quantities match and the price is at or better than the limit price; when this pair is found, an atomic transaction is created with two legs in one transaction: Colored coin going from Buyer to Seller AND Native BBP coin going from Seller to Buyer AND the network minimum transaction fee (.00100) paid in Native BBP all built in the single transaction. This means that if anything goes wrong with this transaction (not enough funds on either end, tx fee deficiency, network error, chain is out of sync, chainlocks down) etc, then this transaction will FAIL atomically. This is good, because now the trading board has not changed, and neither buyer or seller is harmed. However, if the transaction goes through, both buyer and seller are satisfied atomically. Meaning that both colored balances and both native BBP balances are instantly updated with no possibility of error on either end.<br />
<br />
<br />
'''Canceling a Trade'''<br />
<br />
<br />
To cancel a trade, simply highlight the row with the trade you placed (yours have M) and click Cancel.<br />
<br />
<br />
'''Insufficient Funds - Orders with no backing collateral'''<br />
<br />
<br />
<br />
Note that we only allow orders to enter into the orderbook, if, at the time of the trade, the user has enough collateral (IE colored coin balance and BBP balance are sufficient to place the trade).<br />
<br />
<br />
However, since we have 24 hour atomic matching while users are offline, it is possible for a user to do an offline spend of a coin that is already in the orderbook.<br />
<br />
<br />
This is not a problem because Atomic trades cannot occur (if coins are spent prior to the atomic tx being created), that part is prevented.<br />
<br />
<br />
The sanctuary thread constantly looks for trades with no backing collateral.<br />
<br />
<br />
The sanctuary will cancel these automatically causing them to disappear from the order book.<br />
<br />
<br />
<br />
<br />
'''Converting your Colored DOGE back to NATIVE DOGE'''<br />
<br />
<br />
To convert your coins back to Native, click Unwrap. Type in the amount of Native you want to convert back (IE 9 in our example above).<br />
<br />
<br />
Once this process finishes, you will see the Native DOGE balance increases back to the original amount (IE 9.99~).<br />
<br />
<br />
<br />
'''Sending DOGE from the biblepay wallet to the DOGE wallet'''<br />
<br />
<br />
<br />
Now to send DOGE out of your wallet back to your home DOGE wallet, go to the RPC console and type:<br />
<br />
<code><br />
exec senddoge doge_to_address amount<br />
</code><br />
<br />
<br />
<br />
<u>'''Technical Specs'''</u><br />
<br />
<br />
We have three types of Sancs, Altar, Sanc, and Temple. <br />
The Temple is required to stake 10* the collateral than the Sanc.<br />
<br />
The Temple runs an additional piece of software, called BMS (BiblePay Middleware System) which contains the BBP API. <br />
The Temple also runs a decentralized sidechain, which creates blocks on demand. <br />
(We are currently at block 21000 on the side chain). Side chain blocks are stored on STORJ. <br />
Each temple node syncs the BBP sidechain blocks up the the tip, automatically.<br />
<br />
When exchange trades are placed in QT, the AtomicTrade is serialized and opensource, except for the colored private key (or the BBP private key).<br />
The private key is encrypted with RSA, and included in the serialized block hex. <br />
The trade is forwarded to a temple, and the temple creates a sidechain BLOCK and stores it in STORJ. Note that the Temple cannot read the private key, because it is encrypted.<br />
<br />
When QT needs a refreshed trading screen, it queries the order book from the Temple. <br />
The Temple aggregates OPEN orders from the sidechain objects.<br />
<br />
<br />
A trading order book is a collection of AtomicTrades where Status='OPEN' and TradingPair='BBP/DOGE'. Each time the orderbook changes, this feed is sent down from the temple back to the QT client.<br />
<br />
Also, the QT client receives a PriceFeed from the Temple which contains the price of USD-DOGE, BTC-USD, BBP-DOGE, etc. The midpoint of the market is assessed by the temple based on the actual orderbook data.<br />
<br />
The Matching Engine is running on the Temple, and it is constantly scanning for trades where quantity matches and price is at or better than the ask.<br />
<br />
When the Temple needs to create an atomic transaction, it concatenates the seller with the buyer, combining it into one transaction using NBitcoin.<br />
<br />
<br />
The private keys are Not readable by the Temple in production, or in debug mode.<br />
<br />
The AtomicTX then is sent into a proprietary Signing piece of code for the Signing request. <br />
The Signer is closed source and is able to decrypt the private key for the atomic tx and place the signature in place and it returns the signed tx to the caller, which broadcasts it to the BBP network.<br />
<br />
<br />
Note that the Ingate and Outgate run on the temple.<br />
<br />
Since it is mission critical to allow a user to receive back the colored coin, we also created a BBP extension, called PortfolioBuilder, that can run on your own machine and do 100% of the Outgate transaction.<br />
<br />
<br />
This is useful for a scenario where, let us say you have $5,000 of colored coin value and our temple is down but the biblepay network is up and you receive an outgate error.<br />
<br />
<br />
We want you to *always* be able to receive your native coin.<br />
<br />
You can launch PortfolioBuilder and do your own outgate in this case.<br />
<br />
<br />
<u>'''Risks'''</u><br />
<br />
<br />
First I want to say at BiblePay, we want you to know your QT keys and your QT wallet is the highest priority and always want every key to be secure.<br />
All of the private keys *<u>'''Other than the Trading Keys'''</u>*, in your QT wallet are 100% private.<br />
<br />
However, the "TRADING-" keys (the 3 mentioned in the beginning) are being used by the DEX to create atomic transactions.<br />
<br />
Although they are RSA encrypted, there is always a small chance that something can go wrong that is unintended.<br />
<br />
So it is best to treat the DEX in a similar way that you do with other CEXs, trade with limited amounts and do not leave large amounts on the exchange.<br />
<br />
Convert the coins back to native BBP when you can. If you do this the potential damage is always limited to the amount "in play" on the exchange.<br />
<br />
<br />
<br />
<u>'''Future State'''</u><br />
<br />
<br />
The current exchange fulfills many of the desirable qualities that were originally scoped, however there are always tradeoffs with each approach.<br />
<br />
In the current approach you have:<br />
<br />
Ability to match atomic trades 24H even when users are offline (plus).<br />
<br />
Mostly Decentralized (User to user trading, requires one designated temple or temple cluster to be online, the temple API must be working, STORJ must be working).<br />
<br />
<br />
However, we may eventually want to improve the exchange making it 100% decentralized through various technological advances.<br />
<br />
For example, maybe the NBitcoin code can be moved into each online client, allowing matching to occur client side as well.<br />
<br />
The tradeoff is the node may need to be online for this to work (at the time the fill occurs).<br />
Also we may want to move the orderbook from the sidechain to the client side.<br />
<br />
We may also want to move to a market maker model, where market makers buy-sell colored coins and hold the collateral along with an equal amount of BBP.<br />
<br />
We may want to come up with a scheme to change the WIF format of all trading keys so they cannot be under any circumstance, hacked as regular keys.<br />
<br />
This way we can promote BBP core wallet as having every key, in an equal original status when BBP was released as secure. (Maybe we combine this feature with Quantum resistant keys, since quantum computers are rising in capabilities very quickly).<br />
<br />
<br />
Another improvement is to make Portfolio Builder use separate private keys, that are not intermingled with the exchange.<br />
<br />
(Currently portfolio builder uses the same XRP/XLM keys as the exchange keys at the beginning of this page, primarily because of the high starting fee required to open an XRP account - 10 XRP, hence the plus is having one account for XRP/XLM).</div>Adminhttps://wiki.biblepay.org/index.php?title=Decentralized_Exchange&diff=6963Decentralized Exchange2025-04-18T13:54:46Z<p>Admin: </p>
<hr />
<div>'''Introduction'''<brclass="mw_emptyline_first" /><brclass="mw_emptyline" /><brclass="mw_emptyline" /><brclass="mw_emptyline" />The Biblepay Decentralized Exchange (DEX) was created with various goals in mind:<brclass="mw_emptyline_first" /><brclass="mw_emptyline" /><br />
* The ability to trade your BBP coins against another currency (such as DOGE), directly with other QT wallet users, without relying on a centralized exchange (CEX).<br />
* The ability to add other currencies, which are compatible with the base58 wallet, into the exchange. This may allow other communities to list their coins inside BBP's DEX.<br />
<br />
'''<u>Terminology</u>'''<br />
<br />
<brclass="mw_emptyline_first" />'''Native Coin''': The BBP built in currency, or a standard BBP Base58/WIF keypair and its value in the BBP wallet.<br />
<br />
<br />
'''Colored Coin''': A special coin, with a Base58 address that ends in a 4 digit alphanumeric code that designates value on another network, but stored in the wallet.<br />
<br />
<br />
Note that Colored coins cannot be sent out to native addresses (therefore preventing colored coins from going to BBP address on CEXs etc) or diluting their value.Colored coins can only be sent to other like colored addresses, using an RPC command.<br />
<br />
<br />
One example of a colored address is "COLORED-DOGE", which ends in dgzz. Another is colored "COLORED-XLM" ending in lmzz.<br />
<br />
<br />
Colored coins cannot be sent from unlike colored addresses, XLM cannot be sent to DOGE or vice versa.<br />
<br />
<br />
You cannot see colored coins in coin-control; their balances can only be queried with RPC commands.<br />
<br />
<br />
The function the colored coin provides to BBP is:<br />
* Convert Value from a foreign network native UTXO to a BBP colored UTXO<br />
* Seamlessly trade the colored coins in the DEX with other users<br />
* Convert Colored coin value back to native value<brdata-mce-bogus="1" /><br />
<brdata-mce-bogus="1" /><br />
<br />
'''Coin Control''': From the QT left menu, click Send | Inputs. This page allows you to pick specific coins that are used in a transaction.'''BBP Native Receive Addresses''': From the QT menu, click Window | Receiving addresses. You will see a list of BBP receive addresses.<brdata-mce-bogus="1" />'''TRADING-PUBLIC-KEY''': This address is the only BBP native address the DEX will spend from (for security reasons).You must deposit BBP into this address in order to place trades where you Buy foreign currency.'''TRADING-ASSET-DOGE''': Your wallet will automatically mine a colored DOGE address. This is your colored BBP DOGE address that will hold native doge.'''TRADING-ASSET-XLM''': Your wallet will also mine a colored XLM address. This is the address that will hold native XLM.'''Portfolio Builder''': A satellite program that allows you to earn staking rewards for holding an equal amount of native BBP + colored foreign (see Extensions).'''Exchange Flags''':Exchange Room | Trading Grid | Flags: The Flag "T" means theirs, "M" means Mine. This way you can see your orders are M.<brclass="mw_emptyline" /><brclass="mw_emptyline" /><u>'''Usage'''</u><br />
<br />
<br />
<brclass="mw_emptyline_first" />To demonstrate the usage of the exchange we will go through some examples in using the exchange to buy BBP (while selling DOGE) and selling BBP (to Buy DOGE).<br />
<br />
<br />
<brclass="mw_emptyline_first" />'''Prerequisites''':<br />
<br />
<br />
If we want to sell DOGE and buy BBP we will need to fund our TRADING-PUBLIC-KEY. In this example, we will send 100,000 BBP from our core wallet to the TRADING-PUBLIC-KEY.<br />
<br />
<br />
Click on Exchange from the left menu.<br />
<br />
<br />
Copy BBP Trading Address to clipboard (that is equivalent to your "TRADING-PUBLIC-KEY" mentioned above). <br />
<br />
<br />
Go to Send.<br />
<br />
<br />
Paste the address in the TO.<br />
<br />
<br />
Send 100,000 BBP to yourself. Now the exchange has funds to trade with.<brclass="mw_emptyline_first" />In this demo we also want to sell some DOGE for BBP. Therefore we need to receive some Native DOGE into the BBP colored address.<br />
<br />
<br />
Click Exchange. Copy the Native DOGE address to the clipboard.<br />
<br />
<br />
Go to your favorite DOGE wallet, and send 10 DOGE to this native address.<br />
<br />
<br />
Wait 2 blocks on the DOGE network, then click the Get button (which means get balance). Once you see the coins exist in your DOGE native address, now they need to be wrapped, or converted to colored DOGE in order to be tradeable.<br />
<br />
<br />
Now click Wrap. Choose the amount (Lets go with 9.9 to ensure there are no transaction fee errors).<br />
<br />
<br />
Look for the result, it should say "Successfully Wrapped" etc. Now you will have .10 Native doge and 9.9 Colored Doge in the "TRADING-ASSET-DOGE" address; and you can see the balances adjust on the top right.<br />
<br />
<br />
<brdata-mce-bogus="1" /><br />
<br />
<br />
'''Placing a SELL Trade'''<br />
<br />
<br />
<brclass="mw_emptyline_first" />First let us place a trade to Sell BBP while buying with DOGE.<br />
<br />
<br />
Populate 10000 into the Quantity box.<br />
<br />
<br />
Populate 0.00011001 into the Price box.<br />
<br />
<br />
Click SELL.<br />
<br />
<br />
This will place an order to sell 2.70 DOGE for 10,000 BBP. The order will appear in the Sell grid.<br />
<br />
<br />
Note that if your wallet is locked you will receive an error and will have to unlock the wallet for this tx to be created.<br />
<br />
<br />
<brdata-mce-bogus="1" /><br />
<br />
<br />
'''Placing a BUY Trade'''<br />
<br />
<br />
<brclass="mw_emptyline_first" />Next let us place a trade to Buy BBP while selling DOGE.<br />
<br />
<br />
Populate 10000 into the Quantity box.<br />
<br />
<br />
Populate 0.00010999 into the Price box.<br />
<br />
<br />
Click BUY.<br />
<br />
<br />
This will place an order to buy 2.69 DOGE for 10,000 BBP. The order will appear in the Buy grid.<brclass="mw_emptyline_first" />NOTE: You cannot trade with yourself as our atomic tx rejects wash trades with duplicate keys; however you can trade with yourself as long as you use two QT wallets with different key sets.<brclass="mw_emptyline_first" />Once another buyer enters the market to place an opposing trade with the same quantity and an at or better price than yours, your order will fill atomically.<br />
<br />
<br />
<brdata-mce-bogus="1" /><br />
<br />
<br />
'''Partial Fills'''<br />
<br />
<br />
'''<brdata-mce-bogus="1" />'''<br />
<br />
<br />
If your order is bigger in size than their order, a partial fill will occur as long as the partial fill results in a leftover quantity greater than the room minimum.<br />
<br />
<br />
As of April 2025, the DOGE-BBP room minimum is .10 DOGE per trade.<br />
<br />
<br />
<brclass="mw_emptyline_first" />'''Atomic Matching'''<br />
<br />
<br />
The matching engine is constantly scanning for trades in the orderbook, where the quantities match and the price is at or better than the limit price; when this pair is found, an atomic transaction is created with two legs in one transaction: Colored coin going from Buyer to Seller AND Native BBP coin going from Seller to Buyer AND the network minimum transaction fee (.00100) paid in Native BBP all built in the single transaction. This means that if anything goes wrong with this transaction (not enough funds on either end, tx fee deficiency, network error, chain is out of sync, chainlocks down) etc, then this transaction will FAIL atomically. This is good, because now the trading board has not changed, and neither buyer or seller is harmed. However, if the transaction goes through, both buyer and seller are satisfied atomically. Meaning that both colored balances and both native BBP balances are instantly updated with no possibility of error on either end.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />'''Canceling a Trade'''<br />
<br />
<br />
'''<brdata-mce-bogus="1" />'''<br />
<br />
<br />
To cancel a trade, simply highlight the row with the trade you placed (yours have M) and click Cancel.<br />
<br />
<br />
<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />'''Insufficient Funds - Orders with no backing collateral'''<br />
<br />
<br />
'''<brdata-mce-bogus="1" />'''<br />
<br />
<br />
Note that we only allow orders to enter into the orderbook, if, at the time of the trade, the user has enough collateral (IE colored coin balance and BBP balance are sufficient to place the trade).<br />
<br />
<br />
However, since we have 24 hour atomic matching while users are offline, it is possible for a user to do an offline spend of a coin that is already in the orderbook.<br />
<br />
<br />
This is not a problem because Atomic trades cannot occur (if coins are spent prior to the atomic tx being created), that part is prevented.<br />
<br />
<br />
The sanctuary thread constantly looks for trades with no backing collateral.<br />
<br />
<br />
The sanctuary will cancel these automatically causing them to disappear from the order book.<br />
<br />
<br />
<brclass="mw_emptyline_first" />'''Converting your Colored DOGE back to NATIVE DOGE'''<br />
<br />
<br />
<brclass="mw_emptyline_first" />To convert your coins back to Native, click Unwrap. Type in the amount of Native you want to convert back (IE 9 in our example above).<br />
<br />
<br />
Once this process finishes, you will see the Native DOGE balance increases back to the original amount (IE 9.99~).<br />
<br />
<br />
<brdata-mce-bogus="1" /><br />
<br />
<br />
'''Sending DOGE from the biblepay wallet to the DOGE wallet'''<br />
<br />
<br />
<brdata-mce-bogus="1" /><br />
<br />
<br />
Now to send DOGE out of your wallet back to your home DOGE wallet, go to the RPC console and type:<br />
<br />
<br />
exec senddoge doge_to_address amount<brclass="mw_emptyline_first" /><brclass="mw_emptyline" /><brclass="mw_emptyline" /><u>'''Technical Specs'''</u><brclass="mw_emptyline_first" /><brclass="mw_emptyline" /><brclass="mw_emptyline" />We have three types of Sancs, Altar, Sanc, and Temple. The Temple is required to stake 10* the collateral than the Sanc.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />The Temple runs an additional piece of software, called BMS (BiblePay Middleware System) which contains the BBP API. The Temple also runs a decentralized sidechain, which creates blocks on demand. (We are currently at block 21000 on the side chain). Side chain blocks are stored on STORJ. Each temple node syncs the BBP sidechain blocks up the the tip, automatically.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />When exchange trades are placed in QT, the AtomicTrade is serialized and opensource, except for the colored private key (or the BBP private key). The private key is encrypted with RSA, and included in the serialized block hex. The trade is forwarded to a temple, and the temple creates a sidechain BLOCK and stores it in STORJ. Note that the Temple cannot read the private key, because it is encrypted.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />When QT needs a refreshed trading screen, it queries the order book from the Temple. The Temple aggregates OPEN orders from the sidechain objects.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />A trading order book is a collection of AtomicTrades where Status='OPEN' and TradingPair='BBP/DOGE'. Each time the orderbook changes, this feed is sent down from the temple back to the QT client.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />Also, the QT client receives a PriceFeed from the Temple which contains the price of USD-DOGE, BTC-USD, BBP-DOGE, etc. The midpoint of the market is assessed by the temple based on the actual orderbook data.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />The Matching Engine is running on the Temple, and it is constantly scanning for trades where quantity matches and price is at or better than the ask.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />When the Temple needs to create an atomic transaction, it concatenates the seller with the buyer, combining it into one transaction using NBitcoin.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />The private keys are Not readable by the Temple in production, or in debug mode.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />The AtomicTX then is sent into a proprietary Signing piece of code for the Signing request. The Signer is closed source and is able to decrypt the private key for the atomic tx and place the signature in place and it returns the signed tx to the caller, which broadcasts it to the BBP network.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />Note that the Ingate and Outgate run on the temple.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />Since it is mission critical to allow a user to receive back the colored coin, we also created a BBP extension, called PortfolioBuilder, that can run on your own machine and do 100% of the Outgate transaction.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />This is useful for a scenario where, let us say you have $5,000 of colored coin value and our temple is down but the biblepay network is up and you receive an outgate error.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />We want you to *always* be able to receive your native coin.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />You can launch PortfolioBuilder and do your own outgate in this case.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" /><brclass="mw_emptyline" /><brclass="mw_emptyline" /><brclass="mw_emptyline" /><brclass="mw_emptyline" /><u>'''Risks'''</u><br />
<br />
<br />
<brclass="mw_emptyline_first" />First I want to say at BiblePay, we want you to know your QT keys and your QT wallet is the highest priority and always want every key to be secure.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />All of the private keys *<u>'''Other than the Trading Keys'''</u>*, in your QT wallet are 100% private.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />However, the "TRADING-" keys (the 3 mentioned in the beginning) are being used by the DEX to create atomic transactions.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />Although they are RSA encrypted, there is always a small chance that something can go wrong that is unintended.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />So it is best to treat the DEX in a similar way that you do with other CEXs, trade with limited amounts and do not leave large amounts on the exchange.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />Convert the coins back to native BBP when you can. If you do this the potential damage is always limited to the amount "in play" on the exchange.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" /><brclass="mw_emptyline" /><brclass="mw_emptyline" /><brclass="mw_emptyline" /><brclass="mw_emptyline" /><u>'''Future State'''</u><br />
<br />
<br />
<brclass="mw_emptyline_first" />The current exchange fulfills many of the desirable qualities that were originally scoped, however there are always tradeoffs with each approach.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />In the current approach you have:<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />Ability to match atomic trades 24H even when users are offline (plus).<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />Mostly Decentralized (User to user trading, requires one designated temple or temple cluster to be online, the temple API must be working, STORJ must be working).<br />
<br />
<br />
<brclass="mw_emptyline" />However, we may eventually want to improve the exchange making it 100% decentralized through various technological advances.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />For example, maybe the NBitcoin code can be moved into each online client, allowing matching to occur client side as well.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />The tradeoff is the node may need to be online for this to work (at the time the fill occurs).<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />Also we may want to move the orderbook from the sidechain to the client side.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />We may also want to move to a market maker model, where market makers buy-sell colored coins and hold the collateral along with an equal amount of BBP.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />We may want to come up with a scheme to change the WIF format of all trading keys so they cannot be under any circumstance, hacked as regular keys.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />This way we can promote BBP core wallet as having every key, in an equal original status when BBP was released as secure. (Maybe we combine this feature with Quantum resistant keys, since quantum computers are rising in capabilities very quickly).<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />Another improvement is to make Portfolio Builder use separate private keys, that are not intermingled with the exchange.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />(Currently portfolio builder uses the same XRP/XLM keys as the exchange keys at the beginning of this page, primarily because of the high starting fee required to open an XRP account - 10 XRP, hence the plus is having one account for XRP/XLM).<br />
<br />
<br />
<brdata-mce-bogus="1" /><br />
<br />
<br />
<brdata-mce-bogus="1" /></div>Adminhttps://wiki.biblepay.org/index.php?title=Decentralized_Exchange&diff=6962Decentralized Exchange2025-04-18T13:54:21Z<p>Admin: </p>
<hr />
<div>'''Introduction'''<brclass="mw_emptyline_first" /><brclass="mw_emptyline" /><brclass="mw_emptyline" /><brclass="mw_emptyline" />The Biblepay Decentralized Exchange (DEX) was created with various goals in mind:<brclass="mw_emptyline_first" /><brclass="mw_emptyline" /><br />
* The ability to trade your BBP coins against another currency (such as DOGE), directly with other QT wallet users, without relying on a centralized exchange (CEX).<br />
* The ability to add other currencies, which are compatible with the base58 wallet, into the exchange. This may allow other communities to list their coins inside BBP's DEX.<br />
<br />
<u>''''''</u><u>''''''</u><u>''''''</u><u>'''Terminology'''</u><br />
<br />
<brclass="mw_emptyline_first" />'''Native Coin''': The BBP built in currency, or a standard BBP Base58/WIF keypair and its value in the BBP wallet.<br />
<br />
<br />
'''Colored Coin''': A special coin, with a Base58 address that ends in a 4 digit alphanumeric code that designates value on another network, but stored in the wallet.<br />
<br />
<br />
Note that Colored coins cannot be sent out to native addresses (therefore preventing colored coins from going to BBP address on CEXs etc) or diluting their value.Colored coins can only be sent to other like colored addresses, using an RPC command.<br />
<br />
<br />
One example of a colored address is "COLORED-DOGE", which ends in dgzz. Another is colored "COLORED-XLM" ending in lmzz.<br />
<br />
<br />
Colored coins cannot be sent from unlike colored addresses, XLM cannot be sent to DOGE or vice versa.<br />
<br />
<br />
You cannot see colored coins in coin-control; their balances can only be queried with RPC commands.<br />
<br />
<br />
The function the colored coin provides to BBP is:<br />
* Convert Value from a foreign network native UTXO to a BBP colored UTXO<br />
* Seamlessly trade the colored coins in the DEX with other users<br />
* Convert Colored coin value back to native value<brdata-mce-bogus="1" /><br />
<brdata-mce-bogus="1" /><br />
<br />
'''Coin Control''': From the QT left menu, click Send | Inputs. This page allows you to pick specific coins that are used in a transaction.'''BBP Native Receive Addresses''': From the QT menu, click Window | Receiving addresses. You will see a list of BBP receive addresses.<brdata-mce-bogus="1" />'''TRADING-PUBLIC-KEY''': This address is the only BBP native address the DEX will spend from (for security reasons).You must deposit BBP into this address in order to place trades where you Buy foreign currency.'''TRADING-ASSET-DOGE''': Your wallet will automatically mine a colored DOGE address. This is your colored BBP DOGE address that will hold native doge.'''TRADING-ASSET-XLM''': Your wallet will also mine a colored XLM address. This is the address that will hold native XLM.'''Portfolio Builder''': A satellite program that allows you to earn staking rewards for holding an equal amount of native BBP + colored foreign (see Extensions).'''Exchange Flags''':Exchange Room | Trading Grid | Flags: The Flag "T" means theirs, "M" means Mine. This way you can see your orders are M.<brclass="mw_emptyline" /><brclass="mw_emptyline" /><u>'''Usage'''</u><br />
<br />
<br />
<brclass="mw_emptyline_first" />To demonstrate the usage of the exchange we will go through some examples in using the exchange to buy BBP (while selling DOGE) and selling BBP (to Buy DOGE).<br />
<br />
<br />
<brclass="mw_emptyline_first" />'''Prerequisites''':<br />
<br />
<br />
If we want to sell DOGE and buy BBP we will need to fund our TRADING-PUBLIC-KEY. In this example, we will send 100,000 BBP from our core wallet to the TRADING-PUBLIC-KEY.<br />
<br />
<br />
Click on Exchange from the left menu.<br />
<br />
<br />
Copy BBP Trading Address to clipboard (that is equivalent to your "TRADING-PUBLIC-KEY" mentioned above). <br />
<br />
<br />
Go to Send.<br />
<br />
<br />
Paste the address in the TO.<br />
<br />
<br />
Send 100,000 BBP to yourself. Now the exchange has funds to trade with.<brclass="mw_emptyline_first" />In this demo we also want to sell some DOGE for BBP. Therefore we need to receive some Native DOGE into the BBP colored address.<br />
<br />
<br />
Click Exchange. Copy the Native DOGE address to the clipboard.<br />
<br />
<br />
Go to your favorite DOGE wallet, and send 10 DOGE to this native address.<br />
<br />
<br />
Wait 2 blocks on the DOGE network, then click the Get button (which means get balance). Once you see the coins exist in your DOGE native address, now they need to be wrapped, or converted to colored DOGE in order to be tradeable.<br />
<br />
<br />
Now click Wrap. Choose the amount (Lets go with 9.9 to ensure there are no transaction fee errors).<br />
<br />
<br />
Look for the result, it should say "Successfully Wrapped" etc. Now you will have .10 Native doge and 9.9 Colored Doge in the "TRADING-ASSET-DOGE" address; and you can see the balances adjust on the top right.<br />
<br />
<br />
<brdata-mce-bogus="1" /><br />
<br />
<br />
'''Placing a SELL Trade'''<br />
<br />
<br />
<brclass="mw_emptyline_first" />First let us place a trade to Sell BBP while buying with DOGE.<br />
<br />
<br />
Populate 10000 into the Quantity box.<br />
<br />
<br />
Populate 0.00011001 into the Price box.<br />
<br />
<br />
Click SELL.<br />
<br />
<br />
This will place an order to sell 2.70 DOGE for 10,000 BBP. The order will appear in the Sell grid.<br />
<br />
<br />
Note that if your wallet is locked you will receive an error and will have to unlock the wallet for this tx to be created.<br />
<br />
<br />
<brdata-mce-bogus="1" /><br />
<br />
<br />
'''Placing a BUY Trade'''<br />
<br />
<br />
<brclass="mw_emptyline_first" />Next let us place a trade to Buy BBP while selling DOGE.<br />
<br />
<br />
Populate 10000 into the Quantity box.<br />
<br />
<br />
Populate 0.00010999 into the Price box.<br />
<br />
<br />
Click BUY.<br />
<br />
<br />
This will place an order to buy 2.69 DOGE for 10,000 BBP. The order will appear in the Buy grid.<brclass="mw_emptyline_first" />NOTE: You cannot trade with yourself as our atomic tx rejects wash trades with duplicate keys; however you can trade with yourself as long as you use two QT wallets with different key sets.<brclass="mw_emptyline_first" />Once another buyer enters the market to place an opposing trade with the same quantity and an at or better price than yours, your order will fill atomically.<br />
<br />
<br />
<brdata-mce-bogus="1" /><br />
<br />
<br />
'''Partial Fills'''<br />
<br />
<br />
'''<brdata-mce-bogus="1" />'''<br />
<br />
<br />
If your order is bigger in size than their order, a partial fill will occur as long as the partial fill results in a leftover quantity greater than the room minimum.<br />
<br />
<br />
As of April 2025, the DOGE-BBP room minimum is .10 DOGE per trade.<br />
<br />
<br />
<brclass="mw_emptyline_first" />'''Atomic Matching'''<br />
<br />
<br />
The matching engine is constantly scanning for trades in the orderbook, where the quantities match and the price is at or better than the limit price; when this pair is found, an atomic transaction is created with two legs in one transaction: Colored coin going from Buyer to Seller AND Native BBP coin going from Seller to Buyer AND the network minimum transaction fee (.00100) paid in Native BBP all built in the single transaction. This means that if anything goes wrong with this transaction (not enough funds on either end, tx fee deficiency, network error, chain is out of sync, chainlocks down) etc, then this transaction will FAIL atomically. This is good, because now the trading board has not changed, and neither buyer or seller is harmed. However, if the transaction goes through, both buyer and seller are satisfied atomically. Meaning that both colored balances and both native BBP balances are instantly updated with no possibility of error on either end.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />'''Canceling a Trade'''<br />
<br />
<br />
'''<brdata-mce-bogus="1" />'''<br />
<br />
<br />
To cancel a trade, simply highlight the row with the trade you placed (yours have M) and click Cancel.<br />
<br />
<br />
<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />'''Insufficient Funds - Orders with no backing collateral'''<br />
<br />
<br />
'''<brdata-mce-bogus="1" />'''<br />
<br />
<br />
Note that we only allow orders to enter into the orderbook, if, at the time of the trade, the user has enough collateral (IE colored coin balance and BBP balance are sufficient to place the trade).<br />
<br />
<br />
However, since we have 24 hour atomic matching while users are offline, it is possible for a user to do an offline spend of a coin that is already in the orderbook.<br />
<br />
<br />
This is not a problem because Atomic trades cannot occur (if coins are spent prior to the atomic tx being created), that part is prevented.<br />
<br />
<br />
The sanctuary thread constantly looks for trades with no backing collateral.<br />
<br />
<br />
The sanctuary will cancel these automatically causing them to disappear from the order book.<br />
<br />
<br />
<brclass="mw_emptyline_first" />'''Converting your Colored DOGE back to NATIVE DOGE'''<br />
<br />
<br />
<brclass="mw_emptyline_first" />To convert your coins back to Native, click Unwrap. Type in the amount of Native you want to convert back (IE 9 in our example above).<br />
<br />
<br />
Once this process finishes, you will see the Native DOGE balance increases back to the original amount (IE 9.99~).<br />
<br />
<br />
<brdata-mce-bogus="1" /><br />
<br />
<br />
'''Sending DOGE from the biblepay wallet to the DOGE wallet'''<br />
<br />
<br />
<brdata-mce-bogus="1" /><br />
<br />
<br />
Now to send DOGE out of your wallet back to your home DOGE wallet, go to the RPC console and type:<br />
<br />
<br />
exec senddoge doge_to_address amount<brclass="mw_emptyline_first" /><brclass="mw_emptyline" /><brclass="mw_emptyline" /><u>'''Technical Specs'''</u><brclass="mw_emptyline_first" /><brclass="mw_emptyline" /><brclass="mw_emptyline" />We have three types of Sancs, Altar, Sanc, and Temple. The Temple is required to stake 10* the collateral than the Sanc.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />The Temple runs an additional piece of software, called BMS (BiblePay Middleware System) which contains the BBP API. The Temple also runs a decentralized sidechain, which creates blocks on demand. (We are currently at block 21000 on the side chain). Side chain blocks are stored on STORJ. Each temple node syncs the BBP sidechain blocks up the the tip, automatically.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />When exchange trades are placed in QT, the AtomicTrade is serialized and opensource, except for the colored private key (or the BBP private key). The private key is encrypted with RSA, and included in the serialized block hex. The trade is forwarded to a temple, and the temple creates a sidechain BLOCK and stores it in STORJ. Note that the Temple cannot read the private key, because it is encrypted.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />When QT needs a refreshed trading screen, it queries the order book from the Temple. The Temple aggregates OPEN orders from the sidechain objects.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />A trading order book is a collection of AtomicTrades where Status='OPEN' and TradingPair='BBP/DOGE'. Each time the orderbook changes, this feed is sent down from the temple back to the QT client.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />Also, the QT client receives a PriceFeed from the Temple which contains the price of USD-DOGE, BTC-USD, BBP-DOGE, etc. The midpoint of the market is assessed by the temple based on the actual orderbook data.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />The Matching Engine is running on the Temple, and it is constantly scanning for trades where quantity matches and price is at or better than the ask.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />When the Temple needs to create an atomic transaction, it concatenates the seller with the buyer, combining it into one transaction using NBitcoin.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />The private keys are Not readable by the Temple in production, or in debug mode.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />The AtomicTX then is sent into a proprietary Signing piece of code for the Signing request. The Signer is closed source and is able to decrypt the private key for the atomic tx and place the signature in place and it returns the signed tx to the caller, which broadcasts it to the BBP network.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />Note that the Ingate and Outgate run on the temple.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />Since it is mission critical to allow a user to receive back the colored coin, we also created a BBP extension, called PortfolioBuilder, that can run on your own machine and do 100% of the Outgate transaction.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />This is useful for a scenario where, let us say you have $5,000 of colored coin value and our temple is down but the biblepay network is up and you receive an outgate error.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />We want you to *always* be able to receive your native coin.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />You can launch PortfolioBuilder and do your own outgate in this case.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" /><brclass="mw_emptyline" /><brclass="mw_emptyline" /><brclass="mw_emptyline" /><brclass="mw_emptyline" /><u>'''Risks'''</u><br />
<br />
<br />
<brclass="mw_emptyline_first" />First I want to say at BiblePay, we want you to know your QT keys and your QT wallet is the highest priority and always want every key to be secure.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />All of the private keys *<u>'''Other than the Trading Keys'''</u>*, in your QT wallet are 100% private.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />However, the "TRADING-" keys (the 3 mentioned in the beginning) are being used by the DEX to create atomic transactions.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />Although they are RSA encrypted, there is always a small chance that something can go wrong that is unintended.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />So it is best to treat the DEX in a similar way that you do with other CEXs, trade with limited amounts and do not leave large amounts on the exchange.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />Convert the coins back to native BBP when you can. If you do this the potential damage is always limited to the amount "in play" on the exchange.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" /><brclass="mw_emptyline" /><brclass="mw_emptyline" /><brclass="mw_emptyline" /><brclass="mw_emptyline" /><u>'''Future State'''</u><br />
<br />
<br />
<brclass="mw_emptyline_first" />The current exchange fulfills many of the desirable qualities that were originally scoped, however there are always tradeoffs with each approach.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />In the current approach you have:<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />Ability to match atomic trades 24H even when users are offline (plus).<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />Mostly Decentralized (User to user trading, requires one designated temple or temple cluster to be online, the temple API must be working, STORJ must be working).<br />
<br />
<br />
<brclass="mw_emptyline" />However, we may eventually want to improve the exchange making it 100% decentralized through various technological advances.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />For example, maybe the NBitcoin code can be moved into each online client, allowing matching to occur client side as well.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />The tradeoff is the node may need to be online for this to work (at the time the fill occurs).<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />Also we may want to move the orderbook from the sidechain to the client side.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />We may also want to move to a market maker model, where market makers buy-sell colored coins and hold the collateral along with an equal amount of BBP.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />We may want to come up with a scheme to change the WIF format of all trading keys so they cannot be under any circumstance, hacked as regular keys.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />This way we can promote BBP core wallet as having every key, in an equal original status when BBP was released as secure. (Maybe we combine this feature with Quantum resistant keys, since quantum computers are rising in capabilities very quickly).<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />Another improvement is to make Portfolio Builder use separate private keys, that are not intermingled with the exchange.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />(Currently portfolio builder uses the same XRP/XLM keys as the exchange keys at the beginning of this page, primarily because of the high starting fee required to open an XRP account - 10 XRP, hence the plus is having one account for XRP/XLM).<br />
<br />
<br />
<brdata-mce-bogus="1" /><br />
<br />
<br />
<brdata-mce-bogus="1" /></div>Adminhttps://wiki.biblepay.org/index.php?title=Decentralized_Exchange&diff=6961Decentralized Exchange2025-04-18T13:53:27Z<p>Admin: </p>
<hr />
<div>'''Introduction'''<brclass="mw_emptyline_first" /><brclass="mw_emptyline" /><brclass="mw_emptyline" /><brclass="mw_emptyline" />The Biblepay Decentralized Exchange (DEX) was created with various goals in mind:<brclass="mw_emptyline_first" /><brclass="mw_emptyline" /><br />
* The ability to trade your BBP coins against another currency (such as DOGE), directly with other QT wallet users, without relying on a centralized exchange (CEX).<br />
* The ability to add other currencies, which are compatible with the base58 wallet, into the exchange. This may allow other communities to list their coins inside BBP's DEX.<br />
<br /><u>'''Terminology'''</u><br />
<br />
<brclass="mw_emptyline_first" />'''Native Coin''': The BBP built in currency, or a standard BBP Base58/WIF keypair and its value in the BBP wallet.<br />
<br />
<br />
'''Colored Coin''': A special coin, with a Base58 address that ends in a 4 digit alphanumeric code that designates value on another network, but stored in the wallet.<br />
<br />
<br />
Note that Colored coins cannot be sent out to native addresses (therefore preventing colored coins from going to BBP address on CEXs etc) or diluting their value.Colored coins can only be sent to other like colored addresses, using an RPC command.<br />
<br />
<br />
One example of a colored address is "COLORED-DOGE", which ends in dgzz. Another is colored "COLORED-XLM" ending in lmzz.<br />
<br />
<br />
Colored coins cannot be sent from unlike colored addresses, XLM cannot be sent to DOGE or vice versa.<br />
<br />
<br />
You cannot see colored coins in coin-control; their balances can only be queried with RPC commands.<br />
<br />
<br />
The function the colored coin provides to BBP is:<br />
* Convert Value from a foreign network native UTXO to a BBP colored UTXO<br />
* Seamlessly trade the colored coins in the DEX with other users<br />
* Convert Colored coin value back to native value<brdata-mce-bogus="1" /><br />
<brdata-mce-bogus="1" /><br />
<br />
'''Coin Control''': From the QT left menu, click Send | Inputs. This page allows you to pick specific coins that are used in a transaction.'''BBP Native Receive Addresses''': From the QT menu, click Window | Receiving addresses. You will see a list of BBP receive addresses.<brdata-mce-bogus="1" />'''TRADING-PUBLIC-KEY''': This address is the only BBP native address the DEX will spend from (for security reasons).You must deposit BBP into this address in order to place trades where you Buy foreign currency.'''TRADING-ASSET-DOGE''': Your wallet will automatically mine a colored DOGE address. This is your colored BBP DOGE address that will hold native doge.'''TRADING-ASSET-XLM''': Your wallet will also mine a colored XLM address. This is the address that will hold native XLM.'''Portfolio Builder''': A satellite program that allows you to earn staking rewards for holding an equal amount of native BBP + colored foreign (see Extensions).'''Exchange Flags''':Exchange Room | Trading Grid | Flags: The Flag "T" means theirs, "M" means Mine. This way you can see your orders are M.<brclass="mw_emptyline" /><brclass="mw_emptyline" /><u>'''Usage'''</u><br />
<br />
<br />
<brclass="mw_emptyline_first" />To demonstrate the usage of the exchange we will go through some examples in using the exchange to buy BBP (while selling DOGE) and selling BBP (to Buy DOGE).<br />
<br />
<br />
<brclass="mw_emptyline_first" />'''Prerequisites''':<br />
<br />
<br />
If we want to sell DOGE and buy BBP we will need to fund our TRADING-PUBLIC-KEY. In this example, we will send 100,000 BBP from our core wallet to the TRADING-PUBLIC-KEY.<br />
<br />
<br />
Click on Exchange from the left menu.<br />
<br />
<br />
Copy BBP Trading Address to clipboard (that is equivalent to your "TRADING-PUBLIC-KEY" mentioned above). <br />
<br />
<br />
Go to Send.<br />
<br />
<br />
Paste the address in the TO.<br />
<br />
<br />
Send 100,000 BBP to yourself. Now the exchange has funds to trade with.<brclass="mw_emptyline_first" />In this demo we also want to sell some DOGE for BBP. Therefore we need to receive some Native DOGE into the BBP colored address.<br />
<br />
<br />
Click Exchange. Copy the Native DOGE address to the clipboard.<br />
<br />
<br />
Go to your favorite DOGE wallet, and send 10 DOGE to this native address.<br />
<br />
<br />
Wait 2 blocks on the DOGE network, then click the Get button (which means get balance). Once you see the coins exist in your DOGE native address, now they need to be wrapped, or converted to colored DOGE in order to be tradeable.<br />
<br />
<br />
Now click Wrap. Choose the amount (Lets go with 9.9 to ensure there are no transaction fee errors).<br />
<br />
<br />
Look for the result, it should say "Successfully Wrapped" etc. Now you will have .10 Native doge and 9.9 Colored Doge in the "TRADING-ASSET-DOGE" address; and you can see the balances adjust on the top right.<br />
<br />
<br />
<brdata-mce-bogus="1" /><br />
<br />
<br />
'''Placing a SELL Trade'''<br />
<br />
<br />
<brclass="mw_emptyline_first" />First let us place a trade to Sell BBP while buying with DOGE.<br />
<br />
<br />
Populate 10000 into the Quantity box.<br />
<br />
<br />
Populate 0.00011001 into the Price box.<br />
<br />
<br />
Click SELL.<br />
<br />
<br />
This will place an order to sell 2.70 DOGE for 10,000 BBP. The order will appear in the Sell grid.<br />
<br />
<br />
Note that if your wallet is locked you will receive an error and will have to unlock the wallet for this tx to be created.<br />
<br />
<br />
<brdata-mce-bogus="1" /><br />
<br />
<br />
'''Placing a BUY Trade'''<br />
<br />
<br />
<brclass="mw_emptyline_first" />Next let us place a trade to Buy BBP while selling DOGE.<br />
<br />
<br />
Populate 10000 into the Quantity box.<br />
<br />
<br />
Populate 0.00010999 into the Price box.<br />
<br />
<br />
Click BUY.<br />
<br />
<br />
This will place an order to buy 2.69 DOGE for 10,000 BBP. The order will appear in the Buy grid.<brclass="mw_emptyline_first" />NOTE: You cannot trade with yourself as our atomic tx rejects wash trades with duplicate keys; however you can trade with yourself as long as you use two QT wallets with different key sets.<brclass="mw_emptyline_first" />Once another buyer enters the market to place an opposing trade with the same quantity and an at or better price than yours, your order will fill atomically.<br />
<br />
<br />
<brdata-mce-bogus="1" /><br />
<br />
<br />
'''Partial Fills'''<br />
<br />
<br />
'''<brdata-mce-bogus="1" />'''<br />
<br />
<br />
If your order is bigger in size than their order, a partial fill will occur as long as the partial fill results in a leftover quantity greater than the room minimum.<br />
<br />
<br />
As of April 2025, the DOGE-BBP room minimum is .10 DOGE per trade.<br />
<br />
<br />
<brclass="mw_emptyline_first" />'''Atomic Matching'''<br />
<br />
<br />
The matching engine is constantly scanning for trades in the orderbook, where the quantities match and the price is at or better than the limit price; when this pair is found, an atomic transaction is created with two legs in one transaction: Colored coin going from Buyer to Seller AND Native BBP coin going from Seller to Buyer AND the network minimum transaction fee (.00100) paid in Native BBP all built in the single transaction. This means that if anything goes wrong with this transaction (not enough funds on either end, tx fee deficiency, network error, chain is out of sync, chainlocks down) etc, then this transaction will FAIL atomically. This is good, because now the trading board has not changed, and neither buyer or seller is harmed. However, if the transaction goes through, both buyer and seller are satisfied atomically. Meaning that both colored balances and both native BBP balances are instantly updated with no possibility of error on either end.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />'''Canceling a Trade'''<br />
<br />
<br />
'''<brdata-mce-bogus="1" />'''<br />
<br />
<br />
To cancel a trade, simply highlight the row with the trade you placed (yours have M) and click Cancel.<br />
<br />
<br />
<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />'''Insufficient Funds - Orders with no backing collateral'''<br />
<br />
<br />
'''<brdata-mce-bogus="1" />'''<br />
<br />
<br />
Note that we only allow orders to enter into the orderbook, if, at the time of the trade, the user has enough collateral (IE colored coin balance and BBP balance are sufficient to place the trade).<br />
<br />
<br />
However, since we have 24 hour atomic matching while users are offline, it is possible for a user to do an offline spend of a coin that is already in the orderbook.<br />
<br />
<br />
This is not a problem because Atomic trades cannot occur (if coins are spent prior to the atomic tx being created), that part is prevented.<br />
<br />
<br />
The sanctuary thread constantly looks for trades with no backing collateral.<br />
<br />
<br />
The sanctuary will cancel these automatically causing them to disappear from the order book.<br />
<br />
<br />
<brclass="mw_emptyline_first" />'''Converting your Colored DOGE back to NATIVE DOGE'''<br />
<br />
<br />
<brclass="mw_emptyline_first" />To convert your coins back to Native, click Unwrap. Type in the amount of Native you want to convert back (IE 9 in our example above).<br />
<br />
<br />
Once this process finishes, you will see the Native DOGE balance increases back to the original amount (IE 9.99~).<br />
<br />
<br />
<brdata-mce-bogus="1" /><br />
<br />
<br />
'''Sending DOGE from the biblepay wallet to the DOGE wallet'''<br />
<br />
<br />
<brdata-mce-bogus="1" /><br />
<br />
<br />
Now to send DOGE out of your wallet back to your home DOGE wallet, go to the RPC console and type:<br />
<br />
<br />
exec senddoge doge_to_address amount<brclass="mw_emptyline_first" /><brclass="mw_emptyline" /><brclass="mw_emptyline" /><u>'''Technical Specs'''</u><brclass="mw_emptyline_first" /><brclass="mw_emptyline" /><brclass="mw_emptyline" />We have three types of Sancs, Altar, Sanc, and Temple. The Temple is required to stake 10* the collateral than the Sanc.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />The Temple runs an additional piece of software, called BMS (BiblePay Middleware System) which contains the BBP API. The Temple also runs a decentralized sidechain, which creates blocks on demand. (We are currently at block 21000 on the side chain). Side chain blocks are stored on STORJ. Each temple node syncs the BBP sidechain blocks up the the tip, automatically.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />When exchange trades are placed in QT, the AtomicTrade is serialized and opensource, except for the colored private key (or the BBP private key). The private key is encrypted with RSA, and included in the serialized block hex. The trade is forwarded to a temple, and the temple creates a sidechain BLOCK and stores it in STORJ. Note that the Temple cannot read the private key, because it is encrypted.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />When QT needs a refreshed trading screen, it queries the order book from the Temple. The Temple aggregates OPEN orders from the sidechain objects.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />A trading order book is a collection of AtomicTrades where Status='OPEN' and TradingPair='BBP/DOGE'. Each time the orderbook changes, this feed is sent down from the temple back to the QT client.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />Also, the QT client receives a PriceFeed from the Temple which contains the price of USD-DOGE, BTC-USD, BBP-DOGE, etc. The midpoint of the market is assessed by the temple based on the actual orderbook data.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />The Matching Engine is running on the Temple, and it is constantly scanning for trades where quantity matches and price is at or better than the ask.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />When the Temple needs to create an atomic transaction, it concatenates the seller with the buyer, combining it into one transaction using NBitcoin.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />The private keys are Not readable by the Temple in production, or in debug mode.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />The AtomicTX then is sent into a proprietary Signing piece of code for the Signing request. The Signer is closed source and is able to decrypt the private key for the atomic tx and place the signature in place and it returns the signed tx to the caller, which broadcasts it to the BBP network.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />Note that the Ingate and Outgate run on the temple.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />Since it is mission critical to allow a user to receive back the colored coin, we also created a BBP extension, called PortfolioBuilder, that can run on your own machine and do 100% of the Outgate transaction.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />This is useful for a scenario where, let us say you have $5,000 of colored coin value and our temple is down but the biblepay network is up and you receive an outgate error.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />We want you to *always* be able to receive your native coin.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />You can launch PortfolioBuilder and do your own outgate in this case.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" /><brclass="mw_emptyline" /><brclass="mw_emptyline" /><brclass="mw_emptyline" /><brclass="mw_emptyline" /><u>'''Risks'''</u><br />
<br />
<br />
<brclass="mw_emptyline_first" />First I want to say at BiblePay, we want you to know your QT keys and your QT wallet is the highest priority and always want every key to be secure.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />All of the private keys *<u>'''Other than the Trading Keys'''</u>*, in your QT wallet are 100% private.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />However, the "TRADING-" keys (the 3 mentioned in the beginning) are being used by the DEX to create atomic transactions.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />Although they are RSA encrypted, there is always a small chance that something can go wrong that is unintended.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />So it is best to treat the DEX in a similar way that you do with other CEXs, trade with limited amounts and do not leave large amounts on the exchange.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />Convert the coins back to native BBP when you can. If you do this the potential damage is always limited to the amount "in play" on the exchange.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" /><brclass="mw_emptyline" /><brclass="mw_emptyline" /><brclass="mw_emptyline" /><brclass="mw_emptyline" /><u>'''Future State'''</u><br />
<br />
<br />
<brclass="mw_emptyline_first" />The current exchange fulfills many of the desirable qualities that were originally scoped, however there are always tradeoffs with each approach.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />In the current approach you have:<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />Ability to match atomic trades 24H even when users are offline (plus).<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />Mostly Decentralized (User to user trading, requires one designated temple or temple cluster to be online, the temple API must be working, STORJ must be working).<br />
<br />
<br />
<brclass="mw_emptyline" />However, we may eventually want to improve the exchange making it 100% decentralized through various technological advances.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />For example, maybe the NBitcoin code can be moved into each online client, allowing matching to occur client side as well.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />The tradeoff is the node may need to be online for this to work (at the time the fill occurs).<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />Also we may want to move the orderbook from the sidechain to the client side.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />We may also want to move to a market maker model, where market makers buy-sell colored coins and hold the collateral along with an equal amount of BBP.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />We may want to come up with a scheme to change the WIF format of all trading keys so they cannot be under any circumstance, hacked as regular keys.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />This way we can promote BBP core wallet as having every key, in an equal original status when BBP was released as secure. (Maybe we combine this feature with Quantum resistant keys, since quantum computers are rising in capabilities very quickly).<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />Another improvement is to make Portfolio Builder use separate private keys, that are not intermingled with the exchange.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />(Currently portfolio builder uses the same XRP/XLM keys as the exchange keys at the beginning of this page, primarily because of the high starting fee required to open an XRP account - 10 XRP, hence the plus is having one account for XRP/XLM).<br />
<br />
<br />
<brdata-mce-bogus="1" /><br />
<br />
<br />
<brdata-mce-bogus="1" /></div>Adminhttps://wiki.biblepay.org/index.php?title=Decentralized_Exchange&diff=6960Decentralized Exchange2025-04-18T13:53:11Z<p>Admin: </p>
<hr />
<div>'''Introduction'''<brclass="mw_emptyline_first" /><brclass="mw_emptyline" /><brclass="mw_emptyline" /><brclass="mw_emptyline" />The Biblepay Decentralized Exchange (DEX) was created with various goals in mind:<brclass="mw_emptyline_first" /><brclass="mw_emptyline" /><br />
* The ability to trade your BBP coins against another currency (such as DOGE), directly with other QT wallet users, without relying on a centralized exchange (CEX).<br />
* The ability to add other currencies, which are compatible with the base58 wallet, into the exchange. This may allow other communities to list their coins inside BBP's DEX.<br />
<br /><u>'''Terminology'''</u><br />
<br />
<br />
<brclass="mw_emptyline_first" />'''Native Coin''': The BBP built in currency, or a standard BBP Base58/WIF keypair and its value in the BBP wallet.<br />
<br />
<br />
'''Colored Coin''': A special coin, with a Base58 address that ends in a 4 digit alphanumeric code that designates value on another network, but stored in the wallet.<br />
<br />
<br />
Note that Colored coins cannot be sent out to native addresses (therefore preventing colored coins from going to BBP address on CEXs etc) or diluting their value.Colored coins can only be sent to other like colored addresses, using an RPC command.<br />
<br />
<br />
One example of a colored address is "COLORED-DOGE", which ends in dgzz. Another is colored "COLORED-XLM" ending in lmzz.<br />
<br />
<br />
Colored coins cannot be sent from unlike colored addresses, XLM cannot be sent to DOGE or vice versa.<br />
<br />
<br />
You cannot see colored coins in coin-control; their balances can only be queried with RPC commands.<br />
<br />
<br />
The function the colored coin provides to BBP is:<br />
* <span class="mw_htmlentity"></span>Convert Value from a foreign network native UTXO to a BBP colored UTXO<br />
* <span class="mw_htmlentity"></span>Seamlessly trade the colored coins in the DEX with other users<br />
* <span class="mw_htmlentity"></span>Convert Colored coin value back to native value<brdata-mce-bogus="1" /><br />
<brdata-mce-bogus="1" /><br />
<br />
<br />
'''Coin Control''': From the QT left menu, click Send | Inputs. This page allows you to pick specific coins that are used in a transaction.'''BBP Native Receive Addresses''': From the QT menu, click Window | Receiving addresses. You will see a list of BBP receive addresses.<brdata-mce-bogus="1" />'''TRADING-PUBLIC-KEY''': This address is the only BBP native address the DEX will spend from (for security reasons).You must deposit BBP into this address in order to place trades where you Buy foreign currency.'''TRADING-ASSET-DOGE''': Your wallet will automatically mine a colored DOGE address. This is your colored BBP DOGE address that will hold native doge.'''TRADING-ASSET-XLM''': Your wallet will also mine a colored XLM address. This is the address that will hold native XLM.'''Portfolio Builder''': A satellite program that allows you to earn staking rewards for holding an equal amount of native BBP + colored foreign (see Extensions).<p>'''Exchange Flags''':<span class="mw_htmlentity"></span>Exchange Room | Trading Grid | Flags: The Flag "T" means theirs, "M" means Mine. This way you can see your orders are M.<brclass="mw_emptyline" /><brclass="mw_emptyline" /><u>'''Usage'''</u><br />
<br />
<br />
<brclass="mw_emptyline_first" />To demonstrate the usage of the exchange we will go through some examples in using the exchange to buy BBP (while selling DOGE) and selling BBP (to Buy DOGE).<br />
<br />
<br />
<brclass="mw_emptyline_first" />'''Prerequisites''':<br />
<br />
<br />
If we want to sell DOGE and buy BBP we will need to fund our TRADING-PUBLIC-KEY. In this example, we will send 100,000 BBP from our core wallet to the TRADING-PUBLIC-KEY.<br />
<br />
<br />
Click on Exchange from the left menu.<br />
<br />
<br />
Copy BBP Trading Address to clipboard (that is equivalent to your "TRADING-PUBLIC-KEY" mentioned above). <br />
<br />
<br />
Go to Send.<br />
<br />
<br />
Paste the address in the TO.<br />
<br />
<br />
Send 100,000 BBP to yourself. Now the exchange has funds to trade with.<brclass="mw_emptyline_first" />In this demo we also want to sell some DOGE for BBP. Therefore we need to receive some Native DOGE into the BBP colored address.<br />
<br />
<br />
Click Exchange. Copy the Native DOGE address to the clipboard.<br />
<br />
<br />
Go to your favorite DOGE wallet, and send 10 DOGE to this native address.<br />
<br />
<br />
Wait 2 blocks on the DOGE network, then click the Get button (which means get balance). Once you see the coins exist in your DOGE native address, now they need to be wrapped, or converted to colored DOGE in order to be tradeable.<br />
<br />
<br />
Now click Wrap. Choose the amount (Lets go with 9.9 to ensure there are no transaction fee errors).<br />
<br />
<br />
Look for the result, it should say "Successfully Wrapped" etc. Now you will have .10 Native doge and 9.9 Colored Doge in the "TRADING-ASSET-DOGE" address; and you can see the balances adjust on the top right.<br />
<br />
<br />
<brdata-mce-bogus="1" /><br />
<br />
<br />
'''Placing a SELL Trade'''<br />
<br />
<br />
<brclass="mw_emptyline_first" />First let us place a trade to Sell BBP while buying with DOGE.<br />
<br />
<br />
Populate 10000 into the Quantity box.<br />
<br />
<br />
Populate 0.00011001 into the Price box.<br />
<br />
<br />
Click SELL.<br />
<br />
<br />
This will place an order to sell 2.70 DOGE for 10,000 BBP. The order will appear in the Sell grid.<br />
<br />
<br />
Note that if your wallet is locked you will receive an error and will have to unlock the wallet for this tx to be created.<br />
<br />
<br />
<brdata-mce-bogus="1" /><br />
<br />
<br />
'''Placing a BUY Trade'''<br />
<br />
<br />
<brclass="mw_emptyline_first" />Next let us place a trade to Buy BBP while selling DOGE.<br />
<br />
<br />
Populate 10000 into the Quantity box.<br />
<br />
<br />
Populate 0.00010999 into the Price box.<br />
<br />
<br />
Click BUY.<br />
<br />
<br />
This will place an order to buy 2.69 DOGE for 10,000 BBP. The order will appear in the Buy grid.<brclass="mw_emptyline_first" />NOTE: You cannot trade with yourself as our atomic tx rejects wash trades with duplicate keys; however you can trade with yourself as long as you use two QT wallets with different key sets.<brclass="mw_emptyline_first" />Once another buyer enters the market to place an opposing trade with the same quantity and an at or better price than yours, your order will fill atomically.<br />
<br />
<br />
<brdata-mce-bogus="1" /><br />
<br />
<br />
'''Partial Fills'''<br />
<br />
<br />
'''<brdata-mce-bogus="1" />'''<br />
<br />
<br />
If your order is bigger in size than their order, a partial fill will occur as long as the partial fill results in a leftover quantity greater than the room minimum.<br />
<br />
<br />
As of April 2025, the DOGE-BBP room minimum is .10 DOGE per trade.<br />
<br />
<br />
<brclass="mw_emptyline_first" />'''Atomic Matching'''<br />
<br />
<br />
The matching engine is constantly scanning for trades in the orderbook, where the quantities match and the price is at or better than the limit price; when this pair is found, an atomic transaction is created with two legs in one transaction: Colored coin going from Buyer to Seller AND Native BBP coin going from Seller to Buyer AND the network minimum transaction fee (.00100) paid in Native BBP all built in the single transaction. This means that if anything goes wrong with this transaction (not enough funds on either end, tx fee deficiency, network error, chain is out of sync, chainlocks down) etc, then this transaction will FAIL atomically. This is good, because now the trading board has not changed, and neither buyer or seller is harmed. However, if the transaction goes through, both buyer and seller are satisfied atomically. Meaning that both colored balances and both native BBP balances are instantly updated with no possibility of error on either end.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />'''Canceling a Trade'''<br />
<br />
<br />
'''<brdata-mce-bogus="1" />'''<br />
<br />
<br />
To cancel a trade, simply highlight the row with the trade you placed (yours have M) and click Cancel.<br />
<br />
<br />
<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />'''Insufficient Funds - Orders with no backing collateral'''<br />
<br />
<br />
'''<brdata-mce-bogus="1" />'''<br />
<br />
<br />
Note that we only allow orders to enter into the orderbook, if, at the time of the trade, the user has enough collateral (IE colored coin balance and BBP balance are sufficient to place the trade).<br />
<br />
<br />
However, since we have 24 hour atomic matching while users are offline, it is possible for a user to do an offline spend of a coin that is already in the orderbook.<br />
<br />
<br />
This is not a problem because Atomic trades cannot occur (if coins are spent prior to the atomic tx being created), that part is prevented.<br />
<br />
<br />
The sanctuary thread constantly looks for trades with no backing collateral.<br />
<br />
<br />
The sanctuary will cancel these automatically causing them to disappear from the order book.<br />
<br />
<br />
<brclass="mw_emptyline_first" />'''Converting your Colored DOGE back to NATIVE DOGE'''<br />
<br />
<br />
<brclass="mw_emptyline_first" />To convert your coins back to Native, click Unwrap. Type in the amount of Native you want to convert back (IE 9 in our example above).<br />
<br />
<br />
Once this process finishes, you will see the Native DOGE balance increases back to the original amount (IE 9.99~).<br />
<br />
<br />
<brdata-mce-bogus="1" /><br />
<br />
<br />
'''Sending DOGE from the biblepay wallet to the DOGE wallet'''<br />
<br />
<br />
<brdata-mce-bogus="1" /><br />
<br />
<br />
Now to send DOGE out of your wallet back to your home DOGE wallet, go to the RPC console and type:<br />
<br />
<br />
exec senddoge doge_to_address amount<brclass="mw_emptyline_first" /><brclass="mw_emptyline" /><brclass="mw_emptyline" /><u>'''Technical Specs'''</u><brclass="mw_emptyline_first" /><brclass="mw_emptyline" /><brclass="mw_emptyline" />We have three types of Sancs, Altar, Sanc, and Temple. The Temple is required to stake 10* the collateral than the Sanc.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />The Temple runs an additional piece of software, called BMS (BiblePay Middleware System) which contains the BBP API. The Temple also runs a decentralized sidechain, which creates blocks on demand. (We are currently at block 21000 on the side chain). Side chain blocks are stored on STORJ. Each temple node syncs the BBP sidechain blocks up the the tip, automatically.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />When exchange trades are placed in QT, the AtomicTrade is serialized and opensource, except for the colored private key (or the BBP private key). The private key is encrypted with RSA, and included in the serialized block hex. The trade is forwarded to a temple, and the temple creates a sidechain BLOCK and stores it in STORJ. Note that the Temple cannot read the private key, because it is encrypted.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />When QT needs a refreshed trading screen, it queries the order book from the Temple. The Temple aggregates OPEN orders from the sidechain objects.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />A trading order book is a collection of AtomicTrades where Status='OPEN' and TradingPair='BBP/DOGE'. Each time the orderbook changes, this feed is sent down from the temple back to the QT client.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />Also, the QT client receives a PriceFeed from the Temple which contains the price of USD-DOGE, BTC-USD, BBP-DOGE, etc. The midpoint of the market is assessed by the temple based on the actual orderbook data.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />The Matching Engine is running on the Temple, and it is constantly scanning for trades where quantity matches and price is at or better than the ask.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />When the Temple needs to create an atomic transaction, it concatenates the seller with the buyer, combining it into one transaction using NBitcoin.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />The private keys are Not readable by the Temple in production, or in debug mode.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />The AtomicTX then is sent into a proprietary Signing piece of code for the Signing request. The Signer is closed source and is able to decrypt the private key for the atomic tx and place the signature in place and it returns the signed tx to the caller, which broadcasts it to the BBP network.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />Note that the Ingate and Outgate run on the temple.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />Since it is mission critical to allow a user to receive back the colored coin, we also created a BBP extension, called PortfolioBuilder, that can run on your own machine and do 100% of the Outgate transaction.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />This is useful for a scenario where, let us say you have $5,000 of colored coin value and our temple is down but the biblepay network is up and you receive an outgate error.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />We want you to *always* be able to receive your native coin.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />You can launch PortfolioBuilder and do your own outgate in this case.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" /><brclass="mw_emptyline" /><brclass="mw_emptyline" /><brclass="mw_emptyline" /><brclass="mw_emptyline" /><u>'''Risks'''</u><br />
<br />
<br />
<brclass="mw_emptyline_first" />First I want to say at BiblePay, we want you to know your QT keys and your QT wallet is the highest priority and always want every key to be secure.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />All of the private keys *<u>'''Other than the Trading Keys'''</u>*, in your QT wallet are 100% private.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />However, the "TRADING-" keys (the 3 mentioned in the beginning) are being used by the DEX to create atomic transactions.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />Although they are RSA encrypted, there is always a small chance that something can go wrong that is unintended.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />So it is best to treat the DEX in a similar way that you do with other CEXs, trade with limited amounts and do not leave large amounts on the exchange.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />Convert the coins back to native BBP when you can. If you do this the potential damage is always limited to the amount "in play" on the exchange.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" /><brclass="mw_emptyline" /><brclass="mw_emptyline" /><brclass="mw_emptyline" /><brclass="mw_emptyline" /><u>'''Future State'''</u><br />
<br />
<br />
<brclass="mw_emptyline_first" />The current exchange fulfills many of the desirable qualities that were originally scoped, however there are always tradeoffs with each approach.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />In the current approach you have:<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />Ability to match atomic trades 24H even when users are offline (plus).<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />Mostly Decentralized (User to user trading, requires one designated temple or temple cluster to be online, the temple API must be working, STORJ must be working).<br />
<br />
<br />
<brclass="mw_emptyline" />However, we may eventually want to improve the exchange making it 100% decentralized through various technological advances.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />For example, maybe the NBitcoin code can be moved into each online client, allowing matching to occur client side as well.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />The tradeoff is the node may need to be online for this to work (at the time the fill occurs).<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />Also we may want to move the orderbook from the sidechain to the client side.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />We may also want to move to a market maker model, where market makers buy-sell colored coins and hold the collateral along with an equal amount of BBP.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />We may want to come up with a scheme to change the WIF format of all trading keys so they cannot be under any circumstance, hacked as regular keys.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />This way we can promote BBP core wallet as having every key, in an equal original status when BBP was released as secure.<span class="mw_htmlentity"></span> (Maybe we combine this feature with Quantum resistant keys, since quantum computers are rising in capabilities very quickly).<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />Another improvement is to make Portfolio Builder use separate private keys, that are not intermingled with the exchange.<brclass="mw_emptyline_first" /><brclass="mw_emptyline" />(Currently portfolio builder uses the same XRP/XLM keys as the exchange keys at the beginning of this page, primarily because of the high starting fee required to open an XRP account - 10 XRP, hence the plus is having one account for XRP/XLM).<br />
<br />
<br />
<brdata-mce-bogus="1" /><br />
<br />
<br />
<brdata-mce-bogus="1" /></div>Adminhttps://wiki.biblepay.org/index.php?title=Decentralized_Exchange&diff=6959Decentralized Exchange2025-04-18T13:52:45Z<p>Admin: </p>
<hr />
<div>'''Introduction'''<br />
<br />
<br />
<br />
<br />
The Biblepay Decentralized Exchange (DEX) was created with various goals in mind:<br />
<br />
<br />
* The ability to trade your BBP coins against another currency (such as DOGE), directly with other QT wallet users, without relying on a centralized exchange (CEX).<br />
* The ability to add other currencies, which are compatible with the base58 wallet, into the exchange. This may allow other communities to list their coins inside BBP's DEX.<br />
<u>'''Terminology'''</u><br />
<br />
<br />
<br />
<br />
'''Native Coin''': The BBP built in currency, or a standard BBP Base58/WIF keypair and its value in the BBP wallet.'''Colored Coin''': A special coin, with a Base58 address that ends in a 4 digit alphanumeric code that designates value on another network, but stored in the wallet.<br />
<br />
<br />
Note that Colored coins cannot be sent out to native addresses (therefore preventing colored coins from going to BBP address on CEXs etc) or diluting their value.Colored coins can only be sent to other like colored addresses, using an RPC command.<br />
<br />
<br />
One example of a colored address is "COLORED-DOGE", which ends in dgzz. Another is colored "COLORED-XLM" ending in lmzz.<br />
<br />
<br />
Colored coins cannot be sent from unlike colored addresses, XLM cannot be sent to DOGE or vice versa.<br />
<br />
<br />
You cannot see colored coins in coin-control; their balances can only be queried with RPC commands.<br />
<br />
<br />
The function the colored coin provides to BBP is:<br />
* Convert Value from a foreign network native UTXO to a BBP colored UTXO<br />
* Seamlessly trade the colored coins in the DEX with other users<br />
* Convert Colored coin value back to native value<br />
<br />
<br />
'''Coin Control''': From the QT left menu, click Send | Inputs. This page allows you to pick specific coins that are used in a transaction.'''BBP Native Receive Addresses''': From the QT menu, click Window | Receiving addresses. You will see a list of BBP receive addresses.'''TRADING-PUBLIC-KEY''': This address is the only BBP native address the DEX will spend from (for security reasons).You must deposit BBP into this address in order to place trades where you Buy foreign currency.'''TRADING-ASSET-DOGE''': Your wallet will automatically mine a colored DOGE address. This is your colored BBP DOGE address that will hold native doge.'''TRADING-ASSET-XLM''': Your wallet will also mine a colored XLM address. This is the address that will hold native XLM.'''Portfolio Builder''': A satellite program that allows you to earn staking rewards for holding an equal amount of native BBP + colored foreign (see Extensions).<p>'''Exchange Flags''':Exchange Room | Trading Grid | Flags: The Flag "T" means theirs, "M" means Mine. This way you can see your orders are M.<br />
<br />
<u>'''Usage'''</u><br />
<br />
To demonstrate the usage of the exchange we will go through some examples in using the exchange to buy BBP (while selling DOGE) and selling BBP (to Buy DOGE).<br />
<br />
'''Prerequisites''':If we want to sell DOGE and buy BBP we will need to fund our TRADING-PUBLIC-KEY. In this example, we will send 100,000 BBP from our core wallet to the TRADING-PUBLIC-KEY.<br />
<br />
<br />
Click on Exchange from the left menu.<br />
<br />
<br />
Copy BBP Trading Address to clipboard (that is equivalent to your "TRADING-PUBLIC-KEY" mentioned above). <br />
<br />
<br />
Go to Send.<br />
<br />
<br />
Paste the address in the TO.<br />
<br />
<br />
Send 100,000 BBP to yourself. Now the exchange has funds to trade with.<br />
<br />
In this demo we also want to sell some DOGE for BBP. Therefore we need to receive some Native DOGE into the BBP colored address.<br />
<br />
<br />
Click Exchange. Copy the Native DOGE address to the clipboard.<br />
<br />
<br />
Go to your favorite DOGE wallet, and send 10 DOGE to this native address.<br />
<br />
<br />
Wait 2 blocks on the DOGE network, then click the Get button (which means get balance). Once you see the coins exist in your DOGE native address, now they need to be wrapped, or converted to colored DOGE in order to be tradeable.<br />
<br />
<br />
Now click Wrap. Choose the amount (Lets go with 9.9 to ensure there are no transaction fee errors).<br />
<br />
<br />
Look for the result, it should say "Successfully Wrapped" etc. Now you will have .10 Native doge and 9.9 Colored Doge in the "TRADING-ASSET-DOGE" address; and you can see the balances adjust on the top right.<br />
<br />
<br />
<br />
<br />
'''Placing a SELL Trade'''<br />
<br />
<br />
<br />
<br />
First let us place a trade to Sell BBP while buying with DOGE.Populate 10000 into the Quantity box.<br />
<br />
<br />
Populate 0.00011001 into the Price box.<br />
<br />
<br />
Click SELL.<br />
<br />
<br />
This will place an order to sell 2.70 DOGE for 10,000 BBP. The order will appear in the Sell grid.<br />
<br />
<br />
Note that if your wallet is locked you will receive an error and will have to unlock the wallet for this tx to be created.<br />
<br />
<br />
<br />
<br />
'''Placing a BUY Trade'''<br />
<br />
<br />
<br />
<br />
Next let us place a trade to Buy BBP while selling DOGE.Populate 10000 into the Quantity box.<br />
<br />
<br />
Populate 0.00010999 into the Price box.<br />
<br />
<br />
Click BUY.<br />
<br />
<br />
This will place an order to buy 2.69 DOGE for 10,000 BBP. The order will appear in the Buy grid.<br />
<br />
NOTE: You cannot trade with yourself as our atomic tx rejects wash trades with duplicate keys; however you can trade with yourself as long as you use two QT wallets with different key sets.<br />
<br />
Once another buyer enters the market to place an opposing trade with the same quantity and an at or better price than yours, your order will fill atomically.<br />
<br />
<br />
<br />
<br />
'''Partial Fills'''<br />
<br />
<br />
''''''<br />
<br />
<br />
If your order is bigger in size than their order, a partial fill will occur as long as the partial fill results in a leftover quantity greater than the room minimum.<br />
<br />
<br />
As of April 2025, the DOGE-BBP room minimum is .10 DOGE per trade.<br />
<br />
<br />
<br />
<br />
'''Atomic Matching'''The matching engine is constantly scanning for trades in the orderbook, where the quantities match and the price is at or better than the limit price; when this pair is found, an atomic transaction is created with two legs in one transaction: Colored coin going from Buyer to Seller AND Native BBP coin going from Seller to Buyer AND the network minimum transaction fee (.00100) paid in Native BBP all built in the single transaction. This means that if anything goes wrong with this transaction (not enough funds on either end, tx fee deficiency, network error, chain is out of sync, chainlocks down) etc, then this transaction will FAIL atomically. This is good, because now the trading board has not changed, and neither buyer or seller is harmed. However, if the transaction goes through, both buyer and seller are satisfied atomically. Meaning that both colored balances and both native BBP balances are instantly updated with no possibility of error on either end.<br />
<br />
<br />
'''Canceling a Trade'''<br />
<br />
<br />
''''''<br />
<br />
<br />
To cancel a trade, simply highlight the row with the trade you placed (yours have M) and click Cancel.<br />
<br />
<br />
<br />
<br />
'''Insufficient Funds - Orders with no backing collateral'''''''''<br />
<br />
<br />
Note that we only allow orders to enter into the orderbook, if, at the time of the trade, the user has enough collateral (IE colored coin balance and BBP balance are sufficient to place the trade).<br />
<br />
<br />
However, since we have 24 hour atomic matching while users are offline, it is possible for a user to do an offline spend of a coin that is already in the orderbook.<br />
<br />
<br />
This is not a problem because Atomic trades cannot occur (if coins are spent prior to the atomic tx being created), that part is prevented.<br />
<br />
<br />
The sanctuary thread constantly looks for trades with no backing collateral.<br />
<br />
<br />
The sanctuary will cancel these automatically causing them to disappear from the order book.<br />
<br />
<br />
<br />
<br />
'''Converting your Colored DOGE back to NATIVE DOGE'''<br />
<br />
To convert your coins back to Native, click Unwrap. Type in the amount of Native you want to convert back (IE 9 in our example above).Once this process finishes, you will see the Native DOGE balance increases back to the original amount (IE 9.99~).<br />
<br />
<br />
<br />
<br />
'''Sending DOGE from the biblepay wallet to the DOGE wallet'''<br />
<br />
<br />
<br />
<br />
Now to send DOGE out of your wallet back to your home DOGE wallet, go to the RPC console and type:<br />
<br />
<br />
exec senddoge doge_to_address amount<br />
<br />
<br />
<br />
<u>'''Technical Specs'''</u><br />
<br />
<br />
<br />
We have three types of Sancs, Altar, Sanc, and Temple. The Temple is required to stake 10* the collateral than the Sanc.<br />
<br />
<br />
The Temple runs an additional piece of software, called BMS (BiblePay Middleware System) which contains the BBP API. The Temple also runs a decentralized sidechain, which creates blocks on demand. (We are currently at block 21000 on the side chain). Side chain blocks are stored on STORJ. Each temple node syncs the BBP sidechain blocks up the the tip, automatically.<br />
<br />
<br />
When exchange trades are placed in QT, the AtomicTrade is serialized and opensource, except for the colored private key (or the BBP private key). The private key is encrypted with RSA, and included in the serialized block hex. The trade is forwarded to a temple, and the temple creates a sidechain BLOCK and stores it in STORJ. Note that the Temple cannot read the private key, because it is encrypted.<br />
<br />
<br />
When QT needs a refreshed trading screen, it queries the order book from the Temple. The Temple aggregates OPEN orders from the sidechain objects.<br />
<br />
<br />
A trading order book is a collection of AtomicTrades where Status='OPEN' and TradingPair='BBP/DOGE'. Each time the orderbook changes, this feed is sent down from the temple back to the QT client.<br />
<br />
<br />
Also, the QT client receives a PriceFeed from the Temple which contains the price of USD-DOGE, BTC-USD, BBP-DOGE, etc. The midpoint of the market is assessed by the temple based on the actual orderbook data.<br />
<br />
<br />
The Matching Engine is running on the Temple, and it is constantly scanning for trades where quantity matches and price is at or better than the ask.<br />
<br />
<br />
When the Temple needs to create an atomic transaction, it concatenates the seller with the buyer, combining it into one transaction using NBitcoin.<br />
<br />
<br />
The private keys are Not readable by the Temple in production, or in debug mode.<br />
<br />
<br />
The AtomicTX then is sent into a proprietary Signing piece of code for the Signing request. The Signer is closed source and is able to decrypt the private key for the atomic tx and place the signature in place and it returns the signed tx to the caller, which broadcasts it to the BBP network.<br />
<br />
<br />
Note that the Ingate and Outgate run on the temple.<br />
<br />
<br />
Since it is mission critical to allow a user to receive back the colored coin, we also created a BBP extension, called PortfolioBuilder, that can run on your own machine and do 100% of the Outgate transaction.<br />
<br />
<br />
This is useful for a scenario where, let us say you have $5,000 of colored coin value and our temple is down but the biblepay network is up and you receive an outgate error.<br />
<br />
<br />
We want you to *always* be able to receive your native coin.<br />
<br />
<br />
You can launch PortfolioBuilder and do your own outgate in this case.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<u>'''Risks'''</u><br />
<br />
<br />
<br />
<br />
First I want to say at BiblePay, we want you to know your QT keys and your QT wallet is the highest priority and always want every key to be secure.<br />
<br />
<br />
All of the private keys *<u>'''Other than the Trading Keys'''</u>*, in your QT wallet are 100% private.<br />
<br />
<br />
However, the "TRADING-" keys (the 3 mentioned in the beginning) are being used by the DEX to create atomic transactions.<br />
<br />
<br />
Although they are RSA encrypted, there is always a small chance that something can go wrong that is unintended.<br />
<br />
<br />
So it is best to treat the DEX in a similar way that you do with other CEXs, trade with limited amounts and do not leave large amounts on the exchange.<br />
<br />
<br />
Convert the coins back to native BBP when you can. If you do this the potential damage is always limited to the amount "in play" on the exchange.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<u>'''Future State'''</u><br />
<br />
The current exchange fulfills many of the desirable qualities that were originally scoped, however there are always tradeoffs with each approach.<br />
<br />
<br />
In the current approach you have:<br />
<br />
<br />
Ability to match atomic trades 24H even when users are offline (plus).<br />
<br />
<br />
Mostly Decentralized (User to user trading, requires one designated temple or temple cluster to be online, the temple API must be working, STORJ must be working).<br />
However, we may eventually want to improve the exchange making it 100% decentralized through various technological advances.<br />
<br />
<br />
For example, maybe the NBitcoin code can be moved into each online client, allowing matching to occur client side as well.<br />
<br />
<br />
The tradeoff is the node may need to be online for this to work (at the time the fill occurs).<br />
<br />
<br />
Also we may want to move the orderbook from the sidechain to the client side.<br />
<br />
<br />
We may also want to move to a market maker model, where market makers buy-sell colored coins and hold the collateral along with an equal amount of BBP.<br />
<br />
<br />
We may want to come up with a scheme to change the WIF format of all trading keys so they cannot be under any circumstance, hacked as regular keys.<br />
<br />
<br />
This way we can promote BBP core wallet as having every key, in an equal original status when BBP was released as secure. (Maybe we combine this feature with Quantum resistant keys, since quantum computers are rising in capabilities very quickly).<br />
<br />
<br />
Another improvement is to make Portfolio Builder use separate private keys, that are not intermingled with the exchange.<br />
<br />
<br />
(Currently portfolio builder uses the same XRP/XLM keys as the exchange keys at the beginning of this page, primarily because of the high starting fee required to open an XRP account - 10 XRP, hence the plus is having one account for XRP/XLM).</div>Adminhttps://wiki.biblepay.org/index.php?title=Decentralized_Exchange&diff=6958Decentralized Exchange2025-04-18T13:16:00Z<p>Admin: </p>
<hr />
<div>'''Introduction'''<br />
<br />
<br />
<br />
<br />
The Biblepay Decentralized Exchange (DEX) was created with various goals in mind: <br />
<br />
The ability to trade your BBP coins against another currency (such as DOGE), directly with other QT wallet users, without relying on a centralized exchange (CEX).<br />
<br />
<br />
<br />
<br />
The ability to add other currencies, which are compatible with the base58 wallet, into the exchange. This may allow other communities to list their coins inside BBP's DEX.<br />
<br />
<br />
Terminology<br />
<br />
Native Coin: The BBP built in currency, or a standard BBP Base58/WIF keypair and its value in the BBP wallet.<br />
Colored Coin: A special coin, with a Base58 address that ends in a 4 digit alphanumeric code that designates value on another network, but stored in the wallet.<br />
Note that Colored coins cannot be sent out to native addresses (therefore preventing colored coins from going to BBP address on CEXs etc) or diluting their value.<br />
Colored coins can only be sent to other like colored addresses, using an RPC command.<br />
One example of a colored address is "COLORED-DOGE", which ends in dgzz. Another is colored "COLORED-XLM" ending in lmzz.<br />
Colored coins cannot be sent from unlike colored addresses, XLM cannot be sent to DOGE or vice versa.<br />
You cannot see colored coins in coin-control; their balances can only be queried with RPC commands.<br />
The function the colored coin provides to BBP is:<br />
1) Convert Value from a foreign network native UTXO to a BBP colored UTXO<br />
2) Seamlessly trade the colored coins in the DEX with other users<br />
3) Convert Colored coin value back to native value<br />
Coin Control: From the QT left menu, click Send | Inputs. This page allows you to pick specific coins that are used in a transaction.<br />
BBP Native Receive Addresses: From the QT menu, click Window | Receiving addresses. You will see a list of BBP receive addresses.<br />
TRADING-PUBLIC-KEY: This address is the only BBP native address the DEX will spend from (for security reasons).<br />
You must deposit BBP into this address in order to place trades where you Buy foreign currency.<br />
TRADING-ASSET-DOGE: Your wallet will automatically mine a colored DOGE address. This is your colored BBP DOGE address that will hold native doge.<br />
TRADING-ASSET-XLM: Your wallet will also mine a colored XLM address. This is the address that will hold native XLM.<br />
Portfolio Builder: A satellite program that allows you to earn staking rewards for holding an equal amount of native BBP + colored foreign (see Extensions).<br />
Exchange Room | Trading Grid | Flags: The Flag "T" means theirs, "M" means Mine. This way you can see your orders are M.<br />
<br />
<br />
<br />
Usage<br />
<br />
To demonstrate the usage of the exchange we will go through some examples in using the exchange to buy BBP (while selling DOGE) and selling BBP (to Buy DOGE).<br />
<br />
Prerequisites:<br />
If we want to sell DOGE and buy BBP we will need to fund our TRADING-PUBLIC-KEY. In this example, we will send 100,000 BBP from our core wallet to the TRADING-PUBLIC-KEY.<br />
Click on Exchange from the left menu.<br />
Copy BBP Trading Address to clipboard (that is equivalent to your "TRADING-PUBLIC-KEY" mentioned above). <br />
Go to Send.<br />
Paste the address in the TO.<br />
Send 100,000 BBP to yourself. Now the exchange has funds to trade with.<br />
<br />
In this demo we also want to sell some DOGE for BBP. Therefore we need to receive some Native DOGE into the BBP colored address.<br />
Click Exchange. Copy the Native DOGE address to the clipboard.<br />
Go to your favorite DOGE wallet, and send 10 DOGE to this native address.<br />
Wait 2 blocks on the DOGE network, then click the Get button (which means get balance). Once you see the coins exist in your DOGE native address, now they need to be wrapped, or converted to colored DOGE in order to be tradeable.<br />
Now click Wrap. Choose the amount (Lets go with 9.9 to ensure there are no transaction fee errors).<br />
Look for the result, it should say "Successfully Wrapped" etc. Now you will have .10 Native doge and 9.9 Colored Doge in the "TRADING-ASSET-DOGE" address; and you can see the balances adjust on the top right.<br />
<br />
First let us place a trade to Sell BBP while buying with DOGE.<br />
Populate 10000 into the Quantity box.<br />
Populate 0.00011001 into the Price box.<br />
Click SELL.<br />
This will place an order to sell 2.70 DOGE for 10,000 BBP. The order will appear in the Sell grid.<br />
Note that if your wallet is locked you will receive an error and will have to unlock the wallet for this tx to be created.<br />
<br />
Next let us place a trade to Buy BBP while selling DOGE.<br />
Populate 10000 into the Quantity box.<br />
Populate 0.00010999 into the Price box.<br />
Click BUY.<br />
This will place an order to buy 2.69 DOGE for 10,000 BBP. The order will appear in the Buy grid.<br />
<br />
NOTE: You cannot trade with yourself as our atomic tx rejects wash trades with duplicate keys; however you can trade with yourself as long as you use two QT wallets with different key sets.<br />
<br />
Once another buyer enters the market to place an opposing trade with the same quantity and an at or better price than yours, your order will fill atomically.<br />
Partial Fills<br />
If your order is bigger in size than their order, a partial fill will occur as long as the partial fill results in a leftover quantity greater than the room minimum.<br />
As of April 2025, the DOGE-BBP room minimum is .10 DOGE per trade.<br />
<br />
Atomic Matching<br />
The matching engine is constantly scanning for trades in the orderbook, where the quantities match and the price is at or better than the limit price; when this pair is found, an atomic transaction is created with two legs in one transaction: Colored coin going from Buyer to Seller AND Native BBP coin going from Seller to Buyer AND the network minimum transaction fee (.00100) paid in Native BBP all built in the single transaction. This means that if anything goes wrong with this transaction (not enough funds on either end, tx fee deficiency, network error, chain is out of sync, chainlocks down) etc, then this transaction will FAIL atomically. This is good, because now the trading board has not changed, and neither buyer or seller is harmed. However, if the transaction goes through, both buyer and seller are satisfied atomically. Meaning that both colored balances and both native BBP balances are instantly updated with no possibility of error on either end.<br />
<br />
<br />
Canceling a Trade<br />
To cancel a trade, simply highlight the row with the trade you placed (yours have M) and click Cancel.<br />
<br />
<br />
Insufficient Funds - Orders with no backing collateral<br />
Note that we only allow orders to enter into the orderbook, if, at the time of the trade, the user has enough collateral (IE colored coin balance and BBP balance are sufficient to place the trade).<br />
However, since we have 24 hour atomic matching while users are offline, it is possible for a user to do an offline spend of a coin that is already in the orderbook.<br />
First this is not a problem because Atomic trades cannot occur (if coins are spent prior to the atomic tx being created), that part is prevented.<br />
The sanctuary thread constantly looks for trades with no backing collateral.<br />
The sanctuary will cancel these automatically causing them to disappear from the order book.<br />
<br />
Converting your Colored DOGE back to NATIVE DOGE<br />
<br />
To convert your coins back to Native, click Unwrap. Type in the amount of Native you want to convert back (IE 9 in our example above).<br />
Once this process finishes, you will see the Native DOGE balance increases back to the original amount (IE 9.99~).<br />
Now to send DOGE out of your wallet back to your home DOGE wallet, go to the RPC console and type:<br />
exec senddoge doge_to_address amount<br />
<br />
<br />
<br />
Technical Specs<br />
<br />
<br />
<br />
<br />
We have three types of Sancs, Altar, Sanc, and Temple. The Temple is required to stake 10* the collateral than the Sanc.<br />
<br />
<br />
The Temple runs an additional piece of software, called BMS (BiblePay Middleware System) which contains the BBP API. The Temple also runs a decentralized sidechain, which creates blocks on demand. (We are currently at block 21000 on the side chain). Side chain blocks are stored on STORJ. Each temple node syncs the BBP sidechain blocks up the the tip, automatically.<br />
<br />
<br />
When exchange trades are placed in QT, the AtomicTrade is serialized and opensource, except for the colored private key (or the BBP private key). The private key is encrypted with RSA, and included in the serialized block hex. The trade is forwarded to a temple, and the temple creates a sidechain BLOCK and stores it in STORJ. Note that the Temple cannot read the private key, because it is encrypted.<br />
<br />
<br />
When QT needs a refreshed trading screen, it queries the order book from the Temple. The Temple aggregates that OPEN orders from the sidechain objects.<br />
<br />
<br />
A trading order book is a collection of AtomicTrades where Status='OPEN' and TradingPair='BBP/DOGE'. Each time the orderbook changes, this feed is sent down from the temple back to the QT client.<br />
<br />
<br />
Also, the QT client receives a PriceFeed from the Temple which contains the price of USD-DOGE, BTC-USD, BBP-DOGE, etc. The midpoint of the market is assessed by the temple based on the actual orderbook data.<br />
<br />
<br />
The Matching Engine is running on the Temple, and it is constantly scanning for trades where quantity matches and price is at or better than the ask.<br />
<br />
<br />
When the Temple needs to create an atomic transaction, it concatenates the seller with the buyer, combining it into one transaction using NBitcoin.<br />
<br />
<br />
The private keys are Not readable by the Temple in production, or in debug mode.<br />
<br />
<br />
The AtomicTX then is sent into a proprietary Signing piece of code for the Signing request. The Signer is closed source and is able to decrypt the private key for the atomic tx and place the signature in place and it returns the signed tx to the caller, which broadcasts it to the BBP network.<br />
<br />
<br />
Note that the Ingate and Outgate run on the temple.<br />
<br />
<br />
Since it is mission critical to allow a user to receive back the colored coin, we also created a BBP extension, called PortfolioBuilder, that can run on your own machine and do 100% of the Outgate transaction.<br />
<br />
<br />
This is useful for a scenario where, let us say you have $5,000 of colored coin value and our temple is down but the biblepay network is up and you receive an outgate error.<br />
<br />
<br />
We want you to *always* be able to receive your native coin.<br />
<br />
<br />
You can launch PortfolioBuilder and do your own outgate in this case.<br />
<br />
<br />
<br />
<br />
<br />
<br />
Risks<br />
<br />
First I want to say at BiblePay, we want you to know your QT keys and your QT wallet is the highest priority and always want every key to be secure.<br />
<br />
<br />
All of the private keys *Other than the Trading Keys*, in your QT wallet are 100% private.<br />
<br />
<br />
However, the "TRADING-" keys (the 3 mentioned in the beginning) are being used by the DEX to create atomic transactions.<br />
<br />
<br />
Although they are RSA encrypted, there is always a small chance that something can go wrong that is unintended.<br />
<br />
<br />
So it is best to treat the DEX in a similar way that you do with other CEXs, trade with limited amounts and do not leave large amounts on the exchange.<br />
<br />
<br />
Convert the coins back to native BBP when you can. If you do this the potential damage is always limited to the amount "in play" on the exchange.<br />
<br />
<br />
<br />
<br />
<br />
<br />
Future State<br />
<br />
The current exchange fulfills many of the desirable qualities that were originally scoped, however there are always tradeoffs with each approach.<br />
<br />
<br />
In the current approach you have:<br />
<br />
<br />
Ability to match atomic trades 24H even when users are offline (plus)<br />
<br />
<br />
Mostly Decentralized (User to user trading, requires one designated temple or temple cluster to be online, the temple API must be working, STORJ must be working)<br />
<br />
<br />
<br />
<br />
However, we may eventually want to improve the exchange making it 100% decentralized through various technological advances.<br />
<br />
<br />
For example, maybe the NBitcoin code can be moved into each online client, allowing matching to occur client side as well.<br />
<br />
<br />
The tradeoff is the node may need to be online for this to work (at the time the fill occurs).<br />
<br />
<br />
Also we may want to move the orderbook from the sidechain to the client side.<br />
<br />
<br />
We may also want to move to a market maker model, where market makers buy-sell colored coins and hold the collateral along with an equal amount of BBP.<br />
<br />
<br />
<br />
<br />
We may want to come up with a scheme to change the WIF format of all trading keys so they cannot be under any circumstance, hacked as regular keys.<br />
<br />
<br />
This way we can promote BBP core wallet as having every key, in an equal original status when BBP was released as secure.<br />
<br />
<br />
<br />
<br />
Another improvement is to make Portfolio Builder use separate private keys, that are not intermingled with the exchange.<br />
<br />
<br />
(Currently portfolio builders XRP/XLM keys are the same as the exchange keys, primarily because of the high starting fee required to open an XRP account - 10 XRP, therefore it remains this way for now).</div>Adminhttps://wiki.biblepay.org/index.php?title=Decentralized_Exchange&diff=6957Decentralized Exchange2025-04-18T12:47:00Z<p>Admin: Created page with "Introduction The Biblepay Decentralized Exchange (DEX) was created with various goals in mind: The ability to trade your BBP coins against another currency (such as DOGE),..."</p>
<hr />
<div>Introduction<br />
<br />
The Biblepay Decentralized Exchange (DEX) was created with various goals in mind: <br />
The ability to trade your BBP coins against another currency (such as DOGE), directly with other QT wallet users, without relying on a centralized exchange (CEX).<br />
The ability to add other currencies, which are compatible with the base58 wallet, into the exchange. This may allow other communities to list their coins inside BBP's DEX.<br />
<br />
<br />
Terminology<br />
<br />
Native Coin: The BBP built in currency, or a standard BBP Base58/WIF keypair and its value in the BBP wallet.<br />
Colored Coin: A special coin, with a Base58 address that ends in a 4 digit alphanumeric code that designates value on another network, but stored in the wallet.<br />
Note that Colored coins cannot be sent out to native addresses (therefore preventing colored coins from going to BBP address on CEXs etc) or diluting their value.<br />
Colored coins can only be sent to other like colored addresses, using an RPC command.<br />
One example of a colored address is "COLORED-DOGE", which ends in dgzz. Another is colored "COLORED-XLM" ending in lmzz.<br />
Colored coins cannot be sent from unlike colored addresses, XLM cannot be sent to DOGE or vice versa.<br />
You cannot see colored coins in coin-control; their balances can only be queried with RPC commands.<br />
The function the colored coin provides to BBP is:<br />
1) Convert Value from a foreign network native UTXO to a BBP colored UTXO<br />
2) Seamlessly trade the colored coins in the DEX with other users<br />
3) Convert Colored coin value back to native value<br />
Coin Control: From the QT left menu, click Send | Inputs. This page allows you to pick specific coins that are used in a transaction.<br />
BBP Native Receive Addresses: From the QT menu, click Window | Receiving addresses. You will see a list of BBP receive addresses.<br />
TRADING-PUBLIC-KEY: This address is the only BBP native address the DEX will spend from (for security reasons).<br />
You must deposit BBP into this address in order to place trades where you Buy foreign currency.<br />
TRADING-ASSET-DOGE: Your wallet will automatically mine a colored DOGE address. This is your colored BBP DOGE address that will hold native doge.<br />
TRADING-ASSET-XLM: Your wallet will also mine a colored XLM address. This is the address that will hold native XLM.<br />
Portfolio Builder: A satellite program that allows you to earn staking rewards for holding an equal amount of native BBP + colored foreign (see Extensions).<br />
Exchange Room | Trading Grid | Flags: The Flag "T" means theirs, "M" means Mine. This way you can see your orders are M.<br />
<br />
<br />
<br />
Usage<br />
<br />
To demonstrate the usage of the exchange we will go through some examples in using the exchange to buy BBP (while selling DOGE) and selling BBP (to Buy DOGE).<br />
<br />
Prerequisites:<br />
If we want to sell DOGE and buy BBP we will need to fund our TRADING-PUBLIC-KEY. In this example, we will send 100,000 BBP from our core wallet to the TRADING-PUBLIC-KEY.<br />
Click on Exchange from the left menu.<br />
Copy BBP Trading Address to clipboard (that is equivalent to your "TRADING-PUBLIC-KEY" mentioned above). <br />
Go to Send.<br />
Paste the address in the TO.<br />
Send 100,000 BBP to yourself. Now the exchange has funds to trade with.<br />
<br />
In this demo we also want to sell some DOGE for BBP. Therefore we need to receive some Native DOGE into the BBP colored address.<br />
Click Exchange. Copy the Native DOGE address to the clipboard.<br />
Go to your favorite DOGE wallet, and send 10 DOGE to this native address.<br />
Wait 2 blocks on the DOGE network, then click the Get button (which means get balance). Once you see the coins exist in your DOGE native address, now they need to be wrapped, or converted to colored DOGE in order to be tradeable.<br />
Now click Wrap. Choose the amount (Lets go with 9.9 to ensure there are no transaction fee errors).<br />
Look for the result, it should say "Successfully Wrapped" etc. Now you will have .10 Native doge and 9.9 Colored Doge in the "TRADING-ASSET-DOGE" address; and you can see the balances adjust on the top right.<br />
<br />
First let us place a trade to Sell BBP while buying with DOGE.<br />
Populate 10000 into the Quantity box.<br />
Populate 0.00011001 into the Price box.<br />
Click SELL.<br />
This will place an order to sell 2.70 DOGE for 10,000 BBP. The order will appear in the Sell grid.<br />
Note that if your wallet is locked you will receive an error and will have to unlock the wallet for this tx to be created.<br />
<br />
Next let us place a trade to Buy BBP while selling DOGE.<br />
Populate 10000 into the Quantity box.<br />
Populate 0.00010999 into the Price box.<br />
Click BUY.<br />
This will place an order to buy 2.69 DOGE for 10,000 BBP. The order will appear in the Buy grid.<br />
<br />
NOTE: You cannot trade with yourself as our atomic tx rejects wash trades with duplicate keys; however you can trade with yourself as long as you use two QT wallets with different key sets.<br />
<br />
Once another buyer enters the market to place an opposing trade with the same quantity and an at or better price than yours, your order will fill atomically.<br />
Partial Fills<br />
If your order is bigger in size than their order, a partial fill will occur as long as the partial fill results in a leftover quantity greater than the room minimum.<br />
As of April 2025, the DOGE-BBP room minimum is .10 DOGE per trade.<br />
<br />
Atomic Matching<br />
The matching engine is constantly scanning for trades in the orderbook, where the quantities match and the price is at or better than the limit price; when this pair is found, an atomic transaction is created with two legs in one transaction: Colored coin going from Buyer to Seller AND Native BBP coin going from Seller to Buyer AND the network minimum transaction fee (.00100) paid in Native BBP all built in the single transaction. This means that if anything goes wrong with this transaction (not enough funds on either end, tx fee deficiency, network error, chain is out of sync, chainlocks down) etc, then this transaction will FAIL atomically. This is good, because now the trading board has not changed, and neither buyer or seller is harmed. However, if the transaction goes through, both buyer and seller are satisfied atomically. Meaning that both colored balances and both native BBP balances are instantly updated with no possibility of error on either end.<br />
<br />
<br />
Canceling a Trade<br />
To cancel a trade, simply highlight the row with the trade you placed (yours have M) and click Cancel.<br />
<br />
<br />
Insufficient Funds - Orders with no backing collateral<br />
Note that we only allow orders to enter into the orderbook, if, at the time of the trade, the user has enough collateral (IE colored coin balance and BBP balance are sufficient to place the trade).<br />
However, since we have 24 hour atomic matching while users are offline, it is possible for a user to do an offline spend of a coin that is already in the orderbook.<br />
First this is not a problem because Atomic trades cannot occur (if coins are spent prior to the atomic tx being created), that part is prevented.<br />
The sanctuary thread constantly looks for trades with no backing collateral.<br />
The sanctuary will cancel these automatically causing them to disappear from the order book.<br />
<br />
Converting your Colored DOGE back to NATIVE DOGE<br />
<br />
To convert your coins back to Native, click Unwrap. Type in the amount of Native you want to convert back (IE 9 in our example above).<br />
Once this process finishes, you will see the Native DOGE balance increases back to the original amount (IE 9.99~).<br />
Now to send DOGE out of your wallet back to your home DOGE wallet, go to the RPC console and type:<br />
exec senddoge doge_to_address amount<br />
<br />
<br />
<br />
Technical Specs<br />
<br />
<br />
<br />
Risks<br />
<br />
<br />
Future State</div>Adminhttps://wiki.biblepay.org/index.php?title=RDP&diff=6956RDP2024-08-18T20:15:46Z<p>Admin: </p>
<hr />
<div>You can use the BiblePay RDP application to connect from one PC to another. This is facilitated by the BiblePay network. Your RDP traffic is encrypted and sent from PC1 to PC2 through a sanctuary.<br />
Currently, this feature is free, but after it gains popularity BBP reserves the right to charge your BIBLEPAY key for the hours used.<br />
<br />
Before beginning the tutorial let us discuss the moving parts.<br />
<br />
<br />
'''Part 1: The BiblePay Extensions Plugin Module'''<br />
<br />
BIBLEPAY Extensions is a program that extends the functionality of the core wallet. It is completely optional, meaning that you are not required to run this binary; you only need it if you want to use our enhanced features. Since many of our features are cutting edge and need upgraded regularly as they are enhanced, we have created the BIBLEPAY Extensions program to automatically upgrade your optional modules, ensuring they will work as bug fixes are released. The hierarchy of the program looks like this: Core Wallet launches Extensions. Extensions lists a bunch of extensions that are optional to use. As they are listed, the program will automatically upgrade any of them that need upgraded. To use an extension, click on the Connect button. <br />
<br />
<br />
<br />
<br />
<br />
'''How do I launch BiblePay RDP?'''<br />
<br />
Click "Extensions" from the left menu in BIBLEPAY core wallet. (This only works on PC's). Once Extensions loads, you will see a list of programs available to run. One of them is "BBPRDP". Click Connect on that entry to launch BBP RDP.<br />
<br />
<br />
<br />
<br />
<br />
<br />
'''Scenario 1, Setting up your Home machine to listen so you can connect to it from a remote PC:'''<br />
<br />
From the BBP RDP Application home page, click on Add New Computer Relationship.<br />
From the Add New Computer Relationship page, select Inbound for connection direction.<br />
Populate the BBP address field with the address of the "My BBP ADDRESS" field that is located on the *calling* machine's BBP RDP application (you will have to go to that machine and launch the BBP RDP app and copy the<br />
address to the clipboard found from the application home page).<br />
Populate a nickname.<br />
For the pin, select the 4 digit pin that you will choose to require the user to have that dials into your PC. Remember this 4 digit pin is required on the calling side.<br />
Click Save<br />
<br />
<br />
Step 2:<br />
From the calling machine, launch BBP RDP.<br />
Click Add new Computer Relationship.<br />
For direction, populate Outbound.<br />
For the BBP Address, populate the RDP address of the *server* (IE your home machine that is going to be listening for your call).<br />
Populate the nickname, and enter the correct 4 digit pin that the home pc requires for you to dial into it.<br />
Click Save.<br />
<br />
<br />
<br />
<br />
''' Now it is setup, how do I dial my home machine from my remote machine? '''<br />
<br />
It's extremely easy to use. From the home server or listening machine, launch BBP RDP. Click the radio button called "Listener" so that it goes into Listening mode.<br />
Verify the button on the screen says "Listening", otherwise something is wrong.<br />
<br />
On the remote machine launch BBP RDP. Click the Dialer radio button. <br />
From the list of available connections, click Connect on the row for your home machine.<br />
Your grid should update and say "Network Up" otherwise something is wrong.<br />
You should also receive a popup containing the RDP address for the home machine and it will automatically be loaded onto the clipboard.<br />
(In future versions, we will add a feature so that it automatically launches the RDP client but for now please continue to do this next step).<br />
From Windows, launch "mstsc" by clicking Start | mstsc. Paste the address from the clipboard into the address of the RDP client and click connect.<br />
At this point you should be connected to your home machine as if the network existed locally (the traffic is tunneling through a sanctuary, encrypted). Note that not even a sanctuary can spy on the traffic as it uses <br />
more than one encrypted key combination that is impossible to spy on.</div>Adminhttps://wiki.biblepay.org/index.php?title=RDP&diff=6955RDP2024-08-18T20:09:33Z<p>Admin: </p>
<hr />
<div>You can use the BiblePay RDP application to connect from one PC to another. This is facilitated by the BiblePay network. Your RDP traffic is encrypted and sent from PC1 to PC2 through a sanctuary.<br />
Currently, this feature is free, but after it gains popularity BBP reserves the right to charge your BIBLEPAY key for the hours used.<br />
<br />
Before beginning the tutorial let us discuss the moving parts.<br />
<br />
<br />
'''Part 1: The BiblePay Extensions Plugin Module'''<br />
<br />
BIBLEPAY Extensions is a program that extends the functionality of the core wallet. It is completely optional, meaning that you are not required to run this binary; you only need it if you want to use our enhanced features. Since many of our features are cutting edge and need upgraded regularly as they are enhanced, we have created the BIBLEPAY Extensions program to automatically upgrade your optional modules, ensuring they will work as bug fixes are released. The hierarchy of the program looks like this: Core Wallet launches Extensions. Extensions lists a bunch of extensions that are optional to use. As they are listed, the program will automatically upgrade any of them that need upgraded. To use an extension, click on the Connect button. <br />
<br />
<br />
<br />
<br />
<br />
'''How do I launch BiblePay RDP?'''<br />
<br />
Click "Extensions" from the left menu in BIBLEPAY core wallet. (This only works on PC's). Once Extensions loads, you will see a list of programs available to run. One of them is "BBPRDP". Click Connect on that entry to launch BBP RDP.<br />
<br />
<br />
<br />
<br />
<br />
<br />
'''Scenario 1, Setting up your Home machine to listen so you can connect to it from a remote PC:'''<br />
<br />
From the BBP RDP Application home page, click on Add New Computer Relationship.<br />
From the Add New Computer Relationship page, select Inbound for connection direction.<br />
Populate the BBP address field with the address of the "My BBP ADDRESS" field that is located on the *calling* machine's BBP RDP application (you will have to go to that machine and launch the BBP RDP app and copy the<br />
address to the clipboard found from the application home page).<br />
Populate a nickname.<br />
For the pin, select the 4 digit pin that you will choose to require the user to have that dials into your PC. Remember this 4 digit pin is required on the calling side.<br />
Click Save<br />
<br />
<br />
Step 2:<br />
From the calling machine, launch BBP RDP.<br />
Click Add new Computer Relationship.<br />
For direction, populate Outbound.<br />
For the BBP Address, populate the RDP address of the *server* (IE your home machine that is going to be listening for your call).<br />
Populate the nickname, and enter the correct 4 digit pin that the home pc requires for you to dial into it.<br />
Click Save.</div>Adminhttps://wiki.biblepay.org/index.php?title=RDP&diff=6954RDP2024-08-18T20:07:44Z<p>Admin: </p>
<hr />
<div>You can use the BiblePay RDP application to connect from one PC to another. This is facilitated by the BiblePay network. Your RDP traffic is encrypted and sent from PC1 to PC2 through a sanctuary.<br />
Currently, this feature is free, but after it gains popularity BBP reserves the right to charge your BIBLEPAY key for the hours used.<br />
<br />
Before beginning the tutorial let us discuss the moving parts.<br />
<br />
<br />
'''Part 1: The BiblePay Extensions Plugin Module'''<br />
<br />
BIBLEPAY Extensions is a program that extends the functionality of the core wallet. It is completely optional, meaning that you are not required to run this binary; you only need it if you want to use our enhanced features. Since many of our features are cutting edge and need upgraded regularly as they are enhanced, we have created the BIBLEPAY Extensions program to automatically upgrade your optional modules, ensuring they will work as bug fixes are released. The hierarchy of the program looks like this: Core Wallet launches Extensions. Extensions lists a bunch of extensions that are optional to use. As they are listed, the program will automatically upgrade any of them that need upgraded. To use an extension, click on the Connect button. <br />
<br />
'''How do I launch BiblePay RDP?'''<br />
<br />
Click "Extensions" from the left menu in BIBLEPAY core wallet. (This only works on PC's). Once Extensions loads, you will see a list of programs available to run. One of them is "BBPRDP". Click Connect on that entry to launch BBP RDP.<br />
<br />
<br />
<br />
<br />
<br />
'''Scenario 1, Setting up your Home machine to listen so you can connect to it from a remote PC:'''<br />
<br />
From the BBP RDP Application home page, click on Add New Computer Relationship.<br />
From the Add New Computer Relationship page, select Inbound for connection direction.<br />
Populate the BBP address field with the address of the "My BBP ADDRESS" field that is located on the *calling* machine's BBP RDP application (you will have to go to that machine and launch the BBP RDP app and copy the<br />
address to the clipboard found from the application home page).<br />
Populate a nickname.<br />
For the pin, select the 4 digit pin that you will choose to require the user to have that dials into your PC. Remember this 4 digit pin is required on the calling side.<br />
Click Save<br />
<br />
<br />
Step 2:<br />
From the calling machine, launch BBP RDP.<br />
Click Add new Computer Relationship.<br />
For direction, populate Outbound.<br />
For the BBP Address, populate the RDP address of the *server* (IE your home machine that is going to be listening for your call).<br />
Populate the nickname, and enter the correct 4 digit pin that the home pc requires for you to dial into it.<br />
Click Save.</div>Adminhttps://wiki.biblepay.org/index.php?title=RDP&diff=6953RDP2024-08-18T19:50:55Z<p>Admin: </p>
<hr />
<div>You can use the BiblePay RDP application to connect from one PC to another. This is facilitated by the BiblePay network. Your RDP traffic is encrypted and sent from PC1 to PC2 through a sanctuary.<br />
Currently, this feature is free, but after it gains popularity BBP reserves the right to charge your BIBLEPAY key for the hours used.<br />
<br />
Before beginning the tutorial let us discuss the moving parts.<br />
<br />
<br />
'''Part 1: The BiblePay Extensions Plugin Module'''<br />
<br />
BIBLEPAY Extensions is a program that extends the functionality of the core wallet. It is completely optional, meaning that you are not required to run this binary; you only need it if you want to use our enhanced features. Since many of our features are cutting edge and need upgraded regularly as they are enhanced, we have created the BIBLEPAY Extensions program to automatically upgrade your optional modules, ensuring they will work as bug fixes are released. The hierarchy of the program looks like this: Core Wallet launches Extensions. Extensions lists a bunch of extensions that are optional to use. As they are listed, the program will automatically upgrade any of them that need upgraded. To use an extension, click on the Connect button. <br />
<br />
'''How do I launch BiblePay RDP?'''<br />
<br />
Click "Extensions" from the left menu in BIBLEPAY core wallet. (This only works on PC's). Once Extensions loads, you will see a list of programs available to run. One of them is "BBPRDP". Click Connect on that entry to launch BBP RDP.<br />
<br />
<br />
<br />
<br />
'''Scenario 1, Setting up your Home machine to listen so you can connect to it from a remote PC:'''<br />
<br />
From the BBP RDP Application home page, click on Add New Computer Relationship.<br />
From the Add New Computer Relationship page, select Inbound for connection direction.<br />
Populate the BBP address field with the address of the "My BBP ADDRESS" field that is located on the *calling* machine's BBP RDP application (you will have to go to that machine and launch the BBP RDP app and copy the<br />
address to the clipboard found from the application home page).<br />
Populate a nickname.<br />
For the pin, select the 4 digit pin that you will choose to require the user to have that dials into your PC. Remember this 4 digit pin is required on the calling side.<br />
Click Save<br />
<br />
Step 2:<br />
From the calling machine, launch BBP RDP.<br />
Click Add new Computer Relationship.<br />
For direction, populate Outbound.<br />
For the BBP Address, populate the RDP address of the *server* (IE your home machine that is going to be listening for your call).<br />
Populate the nickname, and enter the correct 4 digit pin that the home pc requires for you to dial into it.<br />
Click Save.</div>Adminhttps://wiki.biblepay.org/index.php?title=RDP&diff=6952RDP2024-08-18T19:50:30Z<p>Admin: Created page with "You can use the BiblePay RDP service to connect from one PC to another. This is facilitated by the BiblePay network. Your RDP traffic is encrypted and sent from PC1 to PC2 t..."</p>
<hr />
<div>You can use the BiblePay RDP service to connect from one PC to another. This is facilitated by the BiblePay network. Your RDP traffic is encrypted and sent from PC1 to PC2 through a sanctuary.<br />
Currently, this feature is free, but after it gains popularity BBP reserves the right to charge your BIBLEPAY key for the hours used.<br />
<br />
Before beginning the tutorial let us discuss the moving parts.<br />
<br />
<br />
'''Part 1: The BiblePay Extensions Plugin Module'''<br />
<br />
BIBLEPAY Extensions is a program that extends the functionality of the core wallet. It is completely optional, meaning that you are not required to run this binary; you only need it if you want to use our enhanced features. Since many of our features are cutting edge and need upgraded regularly as they are enhanced, we have created the BIBLEPAY Extensions program to automatically upgrade your optional modules, ensuring they will work as bug fixes are released. The hierarchy of the program looks like this: Core Wallet launches Extensions. Extensions lists a bunch of extensions that are optional to use. As they are listed, the program will automatically upgrade any of them that need upgraded. To use an extension, click on the Connect button. <br />
<br />
'''How do I launch BiblePay RDP?'''<br />
<br />
Click "Extensions" from the left menu in BIBLEPAY core wallet. (This only works on PC's). Once Extensions loads, you will see a list of programs available to run. One of them is "BBPRDP". Click Connect on that entry to launch BBP RDP.<br />
<br />
<br />
<br />
<br />
'''Scenario 1, Setting up your Home machine to listen so you can connect to it from a remote PC:'''<br />
<br />
From the BBP RDP Application home page, click on Add New Computer Relationship.<br />
From the Add New Computer Relationship page, select Inbound for connection direction.<br />
Populate the BBP address field with the address of the "My BBP ADDRESS" field that is located on the *calling* machine's BBP RDP application (you will have to go to that machine and launch the BBP RDP app and copy the<br />
address to the clipboard found from the application home page).<br />
Populate a nickname.<br />
For the pin, select the 4 digit pin that you will choose to require the user to have that dials into your PC. Remember this 4 digit pin is required on the calling side.<br />
Click Save<br />
<br />
Step 2:<br />
From the calling machine, launch BBP RDP.<br />
Click Add new Computer Relationship.<br />
For direction, populate Outbound.<br />
For the BBP Address, populate the RDP address of the *server* (IE your home machine that is going to be listening for your call).<br />
Populate the nickname, and enter the correct 4 digit pin that the home pc requires for you to dial into it.<br />
Click Save.</div>Adminhttps://wiki.biblepay.org/index.php?title=BBP_Intrinsic_Value&diff=6951BBP Intrinsic Value2024-03-24T14:49:39Z<p>Admin: </p>
<hr />
<div><br />
<br />
<br />
''' What makes BIBLEPAY stand out from the other cryptocurrencies? '''<br />
<br />
<br />
* DEFLATIONARY. We decrease our emissions by 20% per year with a total cap of 5.2B, and a circulating supply of 3.6B. Block emission has decreased from 20K to 2K since inception.<br />
<br />
* HIGHER INVESTMENT LEVERAGE. BiblePay still has 4 zeroes before its BBP-USDT trading price (.0000225 as of March 2024). <br />
<br />
* TITHE 10% to ORPHAN CHARITY. This is our cornerstone and makes it easy for any crypto user to get exposure to sponsoring orphans and doing good things like building water wells. Sponsor an orphan with a BBP NFT, or hold BBP and help orphans.<br />
<br />
* SIDECHAIN. We are an L1 chain with an L2 sidechain allowing you to store files (mp4s, image links, ticket attachments, social media attachments). Display gospel videos and provide theological material.<br />
<br />
* SOCIAL MEDIA. Our site at https://unchained.biblepay.org is being enhanced every month, with more and more web3 features.<br />
<br />
* ADVANCED NFTs (v2): We have NFTs with treasure chests, autonomous settlement, orphan NFTs (soulbound), and our NFTs are versatile enough to be marketed in more than one marketplace.<br />
<br />
* INSTANT GLOBAL SETTLEMENT ON EVERY EXCHANGE: With our atomic trade, you can send any amount to any metamask user globally and have it settled in a block in a few seconds. <br />
<br />
* PHONE SYSTEM: We provide you with a real US phone number and a true long distance phone system with charges to your BBP private key.<br />
<br />
* EASY ACCESS TO WEB3: We make things easier for the user by wrapping high technology smart contracts and providing a UI for access to our ERP features.<br />
<br />
<br />
''' Future '''<br />
<br />
* Our next sidechain (v3.0) is soon to be released. This marries the blockchain with our ERP that provides grantable deterministic permissions and ERP views. <br />
<br />
* This solidifies BiblePay's total value in the crypto space.</div>Adminhttps://wiki.biblepay.org/index.php?title=BBP_Intrinsic_Value&diff=6950BBP Intrinsic Value2024-03-24T14:49:19Z<p>Admin: </p>
<hr />
<div><br />
<br />
<br />
''' What makes BIBLEPAY stand out from the other cryptocurrencies? '''<br />
<br />
<br />
* DEFLATIONARY. We decrease our emissions by 20% per year with a total cap of 5.2B, and a circulating supply of 3.6B. Block emission has decreased from 20K to 2K since inception.<br />
<br />
* HIGHER INVESTMENT LEVERAGE. BiblePay still has 4 zeroes before its BBP-USDT trading price (.0000225 as of March 2024). <br />
<br />
* TITHE 10% to ORPHAN CHARITY. This is our cornerstone and makes it easy for any crypto user to get exposure to sponsoring orphans and doing good things like building water wells. Sponsor an orphan with a BBP NFT, or hold BBP and help orphans.<br />
<br />
* SIDECHAIN. We are an L1 chain with an L2 sidechain allowing you to store files (mp4s, image links, ticket attachments, social media attachments). Display gospel videos and provide theological material.<br />
<br />
* SOCIAL MEDIA. Our site at https://unchained.biblepay.org is being enhanced every month, with more and more web3 features.<br />
<br />
* ADVANCED NFTs (v2): We have NFTs with treasure chests, autonomous settlement, orphan NFTs (soulbound), and our NFTs are versatile enough to be marketed in more than one marketplace.<br />
<br />
* INSTANT GLOBAL SETTLEMENT ON EVERY EXCHANGE: With our atomic trade, you can send any amount to any metamask use globally and have it settled in a block in a few seconds. <br />
<br />
* PHONE SYSTEM: We provide you with a real US phone number and a true long distance phone system with charges to your BBP private key.<br />
<br />
* EASY ACCESS TO WEB3: We make things easier for the user by wrapping high technology smart contracts and providing a UI for access to our ERP features.<br />
<br />
<br />
''' Future '''<br />
<br />
* Our next sidechain (v3.0) is soon to be released. This marries the blockchain with our ERP that provides grantable deterministic permissions and ERP views. <br />
<br />
* This solidifies BiblePay's total value in the crypto space.</div>Adminhttps://wiki.biblepay.org/index.php?title=BBP_Intrinsic_Value&diff=6949BBP Intrinsic Value2024-03-24T14:47:52Z<p>Admin: </p>
<hr />
<div><br />
<br />
<br />
''' What makes BIBLEPAY stand out from the other cryptocurrencies? '''<br />
<br />
<br />
* DEFLATIONARY. We decrease our emissions by 20% per year with a total cap of 5.2B, and a circulating supply of 3.6B. Block emission has decreased from 20K to 2K since inception.<br />
<br />
* HIGHER INVESTMENT LEVERAGE. BiblePay still has 4 zeroes before its BBP-USDT trading price (.0000225 as of March 2024). <br />
<br />
* TITHE 10% to ORPHAN CHARITY. This is our cornerstone and makes it easy for any crypto user to get exposure to sponsoring orphans and doing good things like building water wells. Sponsor an orphan with a BBP NFT, or hold BBP and help orphans.<br />
<br />
* SIDECHAIN. We are an L1 chain with an L2 sidechain allowing you to store files (mp4s, image links, ticket attachments, social media attachments). Display gospel videos and provide theological material.<br />
<br />
* SOCIAL MEDIA. Our site at https://unchained.biblepay.org is being enhanced every month, with more and more web3 features.<br />
<br />
* ADVANCED NFTs (v2): We have NFTs with treasure chests, autonomous settlement, orphan NFTs (soulbound) and have dual sourced SEO.<br />
<br />
* INSTANT GLOBAL SETTLEMENT ON EVERY EXCHANGE: With our atomic trade, you can send any amount to any metamask use globally and have it settled in a block in a few seconds. <br />
<br />
* PHONE SYSTEM: We provide you with a real US phone number and a true long distance phone system with charges to your BBP private key.<br />
<br />
* EASY ACCESS TO WEB3: We make things easier for the user by wrapping high technology smart contracts and providing a UI for access to our ERP features.<br />
<br />
<br />
''' Future '''<br />
<br />
* Our next sidechain (v3.0) is soon to be released. This marries the blockchain with our ERP that provides grantable deterministic permissions and ERP views. <br />
<br />
* This solidifies BiblePay's total value in the crypto space.</div>Adminhttps://wiki.biblepay.org/index.php?title=BBP_Intrinsic_Value&diff=6948BBP Intrinsic Value2024-03-24T14:44:37Z<p>Admin: </p>
<hr />
<div><br />
<br />
<br />
''' What makes BIBLEPAY stand out from the other cryptocurrencies? '''<br />
<br />
<br />
* DEFLATIONARY. We decrease our emissions by 20% per year with a total cap of 5.2B, and a circulating supply of 3.6B. Block emission has decreased from 20K to 2K since inception.<br />
<br />
* HIGHER INVESTMENT LEVERAGE. BiblePay still has 4 zeroes before its BBP-USDT trading price (.0000225 as of March 2024). <br />
<br />
* TITHE 10% to ORPHAN CHARITY. This is our cornerstone and makes it easy for any crypto user to get exposure to sponsoring orphans and doing good things like building water wells. Sponsor an orphan with a BBP NFT, or hold BBP and help orphans.<br />
<br />
* SIDECHAIN. We are an L1 chain with an L2 sidechain allowing you to store files (mp4s, image links, ticket attachments, social media attachments). Display gospel videos and provide theological material.<br />
<br />
* SOCIAL MEDIA. Our site at https://unchained.biblepay.org is being enhanced every month, with more and more web3 features.<br />
<br />
* PHONE SYSTEM: We provide you with a real US phone number and a true long distance phone system with charges to your BBP private key.<br />
<br />
* EASY ACCESS TO WEB3: We make things easier for the user by wrapping high technology smart contracts and providing a UI for access to our ERP features.<br />
<br />
<br />
''' Future '''<br />
<br />
* Our next sidechain (v3.0) is soon to be released. This marries the blockchain with our ERP that provides grantable deterministic permissions and ERP views. <br />
<br />
* This solidifies BiblePay's total value in the crypto space.</div>Adminhttps://wiki.biblepay.org/index.php?title=BBP_Intrinsic_Value&diff=6947BBP Intrinsic Value2024-03-23T14:30:25Z<p>Admin: </p>
<hr />
<div><br />
'''The Naysers'''<br />
<br />
<br />
Naysayers argue that small blockchains, like BBP are worthless because the world already has Bitcoin. Why create another blockchain when Bitcoin is available that allows you to transact large values efficiently on thousands of exchanges.<br />
<br />
<br />
''' The Argument for BBP '''<br />
<br />
However, there are certain elements in the BBP ecosystem that are novel and useful. Remember the original deflation argument that when a currency is emitting coins at a decreasing rate, versus the behavior of central banks that are printing money at an alarming rate? The argument is that the safer place is in a deflationary environment. There is no central bank that can change the emission characteristics of BBP. We have set our chain parameters in the genesis block that dictate that we will have 5.2B coins circulating in total, at a decreasing emission rate of 20% per year. We have emitted 3.6B of those 5.2B coins (starting at blocks that were 18,000 BBP and now we have blocks that are 2,000 BBP). <br />
<br />
<br />
Bitcoin has experienced 50% of its all time sensationalism. Bitcoin is awesome, as they wrote the whitepaper and established a foundation for us. There is a place for bitcoin. However investors need to place a portion of their hard earned money in chains that have large growth potential. We know with the new ETFs and halving, Bitcoin could absolutely double again. But smaller tokens like Shiba Inu and BiblePay still have 4 zeroes in front of their price, therefore have more leverage. The difference is chasing a 2* potential increase vs a 100* potential increase. But this also has to be done prudently and only in chains you believe have potential.<br />
<br />
<br />
<br />
<br />
'''Points:'''<br />
<br />
<br />
* We tithe 10% to orphan charity and have since inception. This of course is our cornerstone and makes it very easy for any crypto user to get exposure to sponsoring orphans or doing good things like building water wells. A crypto user can: Buy ARB or Doge anywhere, cross chain swap that to BBP, sponsor an orphan NFT, or simply hold BBP in a sanctuary which helps our network and pays a reward to the sanctuary.<br />
<br />
* Real world use cases: Our sidechain allows you to store large files (mp4s, image links, ticket attachments, social media attachments) and while paying small storage fees in BBP, you can use those links to mint NFTs or make social media posts. We have a feature in Unchained that displays gospel videos for channels. We provide Christian theological material in Unchained as well.<br />
<br />
* Phone system: A true long distance phone embedded in your unchained wallet that is charged to your BBP private key, with a real US phone number.<br />
<br />
* Making things easier for the user: Our features wrap the technology in a way that makes it easy for the end user. You dont need to know about the technical details to interact with smart contracts.<br />
<br />
<br />
''' Future '''<br />
<br />
* Our best technological feature, the sidechain v3.0 is soon to be released. This provides an ERP system that is bound to our L1 chain, with grantable deterministic permissions. The chain will drive the ERP views. This solidifies BiblePay's total value in the crypto space.</div>Adminhttps://wiki.biblepay.org/index.php?title=BBP_Intrinsic_Value&diff=6946BBP Intrinsic Value2024-03-23T14:29:55Z<p>Admin: </p>
<hr />
<div><br />
'''The Naysers'''<br />
<br />
<br />
Naysayers argue that small blockchains, like BBP are worthless because the world already has Bitcoin. Why create another blockchain when Bitcoin is available that allows you to transact large values efficiently on thousands of exchanges.<br />
<br />
<br />
''' The Argument for BBP '''<br />
<br />
However, there are certain elements in the BBP ecosystem that are novel and useful. Remember the original deflation argument that when a currency is emitting coins at a decreasing rate, versus the behavior of central banks that are printing money at an alarming rate? The argument is that the safer place is in a deflationary environment. There is no central bank that can change the emission characteristics of BBP. We have set our chain parameters in the genesis block that dictate that we will have 5.2B coins circulating in total, at a decreasing emission rate of 20% per year. We have emitted 3.6B of those 5.2B coins (starting at blocks that were 18,000 BBP and now we have blocks that are 2,000 BBP). <br />
<br />
<br />
Bitcoin has experienced 50% of its all time sensationalism. Bitcoin is awesome, as they wrote the whitepaper and established a foundation for us. There is a place for bitcoin. However investors need to place a portion of their hard earned money in chains that have large growth potential. We know with the new ETFs and halving, Bitcoin could absolutely double again. But smaller tokens like Shiba Inu and BiblePay still have 4 zeroes in front of their price, therefore have more leverage. The difference is chasing a 2* potential increase vs a 100* potential increase. But this also has to be done prudently and only in chains you believe have potential.<br />
<br />
<br />
<br />
<br />
'''Points:'''<br />
<br />
<br />
* We tithe 10% to orphan charity and have since inception. This of course is our cornerstone and makes it very easy for any crypto user to get exposure to sponsoring orphans or doing good things like building water wells. A crypto user can: Buy ARB or Doge anywhere, cross chain swap that to BBP, sponsor an orphan NFT, or simply hold BBP in a sanctuary which helps our network and pays a reward to the sanctuary.<br />
<br />
* Real world use cases: Our sidechain allows you to store large files (mp4s, image links, ticket attachments, social media attachments) and while paying small storage fees in BBP, you can use those links to mint NFTs or make social media posts. We have a feature in Unchained that displays gospel videos for channels. We provide Christian theological material in Unchained as well.<br />
<br />
* Phone system: A true long distance phone embedded in your unchained wallet that is charged to your BBP private key, with a real US phone number.<br />
<br />
* Making things easier for the user: Our features wrap the technology in a way that makes it easy for the end user. You dont need to know about the technical details of interactive with smart contracts.<br />
<br />
<br />
''' Future '''<br />
<br />
* Our best technological feature, the sidechain v3.0 is soon to be released. This provides an ERP system that is bound to our L1 chain, with grantable deterministic permissions. The chain will drive the ERP views. This solidifies BiblePay's total value in the crypto space.</div>Adminhttps://wiki.biblepay.org/index.php?title=BBP_Intrinsic_Value&diff=6945BBP Intrinsic Value2024-03-23T14:27:19Z<p>Admin: </p>
<hr />
<div><br />
'''The Naysers'''<br />
<br />
<br />
Naysayers argue that small blockchains, like BBP are worthless because the world already has Bitcoin. Why create another blockchain when Bitcoin is available that allows you to transact large values efficiently on thousands of exchanges.<br />
<br />
<br />
''' The Argument for BBP '''<br />
<br />
However, there are certain elements in the BBP ecosystem that are novel and useful. Remember the original deflation argument that when a currency is emitting coins at a decreasing rate, versus the behavior of central banks that are printing money at an alarming rate? The argument is that the safer place is in a deflationary environment. There is no central bank that can change the emission characteristics of BBP. We have set our chain parameters in the genesis block that dictate that we will have 5.2B coins circulating in total, at a decreasing emission rate of 20% per year. We have emitted 3.6B of those 5.2B coins (starting at blocks that were 18,000 BBP and now we have blocks that are 2,000 BBP). <br />
<br />
<br />
Bitcoin has experienced 50% of its all time sensationalism. Bitcoin is awesome, as they wrote the whitepaper and established a foundation for us. There is a place for bitcoin. However investors need to place a portion of their hard earned money in chains that have large growth potential. We know with the new ETFs and halving, Bitcoin could absolutely double again. But smaller tokens like Shiba Inu and BiblePay still have 4 zeroes in front of their price, therefore have more leverage. The difference is chasing a 2* potential increase vs a 100* potential increase. But this also has to be done prudently and only in chains you believe have potential.<br />
<br />
<br />
<br />
<br />
'''Points:'''<br />
<br />
<br />
* We tithe 10% to orphan charity and have since inception. This of course is our cornerstone and makes it very easy for any crypto user to get exposure to sponsoring orphans or doing good things like building water wells. A crypto user can: Buy ARB or Doge anywhere, cross chain swap that to BBP, sponsor an orphan NFT, or simply hold BBP in a sanctuary which helps our network and pays a reward to the sanctuary.<br />
<br />
* Real world use cases: Our sidechain allows you to store large files (mp4s, image links, ticket attachments, social media attachments) and while paying small storage fees in BBP, you can use those links to mint NFTs or make social media posts. We have a connection to Rumble that displays gospel videos. We provide gospel media in Unchained.<br />
<br />
* Phone system: A true long distance phone embedded in your unchained wallet that is charged to your BBP private key, with a real US phone number.<br />
<br />
* Making things easier for the user: Our features wrap the technology in a way that makes it easy for the end user. You dont need to know about the technical details of interactive with smart contracts.<br />
<br />
<br />
''' Future '''<br />
<br />
* Our best technological feature, the sidechain v3.0 is soon to be released. This provides an ERP system that is bound to our L1 chain, with grantable deterministic permissions. The chain will drive the ERP views. This solidifies BiblePay's total value in the crypto space.</div>Adminhttps://wiki.biblepay.org/index.php?title=BBP_Intrinsic_Value&diff=6944BBP Intrinsic Value2024-03-23T14:26:30Z<p>Admin: Created page with " '''The Naysers''' Naysayers argue that small blockchains, like BBP are worthless because the world already has Bitcoin. Why create another blockchain when Bitcoin is availa..."</p>
<hr />
<div><br />
'''The Naysers'''<br />
<br />
Naysayers argue that small blockchains, like BBP are worthless because the world already has Bitcoin. Why create another blockchain when Bitcoin is available that allows you to transact large values efficiently on thousands of exchanges.<br />
<br />
''' The Argument for BBP '''<br />
<br />
However, there are certain things in the BBP ecosystem that is novel and useful. Remember the original deflation argument that when a currency is emitting coins at a decreasing rate, versus the behavior of central banks that are printing money at an alarming rate? The argument is that the safer place is in a deflationary environment. There is no central bank that can change the emission characteristics of BBP. We have set our chain parameters in the genesis block that dictate that we will have 5.2B coins circulating in total, at a decreasing emission rate of 20% per year. We have emitted 3.6B of those 5.2B coins (starting at blocks that were 18,000 BBP and now we have blocks that are 2,000 BBP). <br />
<br />
<br />
Bitcoin has experienced 50% of its all time sensationalism. Bitcoin is awesome, as they wrote the whitepaper and established a foundation for us. There is a place for bitcoin. However investors need to place a portion of their hard earned money in chains that have large growth potential. We know with the new ETFs and halving, Bitcoin could absolutely double again. But smaller tokens like Shiba Inu and BiblePay still have 4 zeroes in front of their price, therefore have more leverage. The difference is chasing a 2* potential increase vs a 100* potential increase. But this also has to be done prudently and only in chains you believe have potential.<br />
<br />
<br />
<br />
<br />
'''Points:'''<br />
<br />
<br />
* We tithe 10% to orphan charity and have since inception. This of course is our cornerstone and makes it very easy for any crypto user to get exposure to sponsoring orphans or doing good things like building water wells. A crypto user can: Buy ARB or Doge anywhere, cross chain swap that to BBP, sponsor an orphan NFT, or simply hold BBP in a sanctuary which helps our network and pays a reward to the sanctuary.<br />
<br />
* Real world use cases: Our sidechain allows you to store large files (mp4s, image links, ticket attachments, social media attachments) and while paying small storage fees in BBP, you can use those links to mint NFTs or make social media posts. We have a connection to Rumble that displays gospel videos. We provide gospel media in Unchained.<br />
<br />
* Phone system: A true long distance phone embedded in your unchained wallet that is charged to your BBP private key, with a real US phone number.<br />
<br />
* Making things easier for the user: Our features wrap the technology in a way that makes it easy for the end user. You dont need to know about the technical details of interactive with smart contracts.<br />
<br />
<br />
''' Future '''<br />
<br />
* Our best technological feature, the sidechain v3.0 is soon to be released. This provides an ERP system that is bound to our L1 chain, with grantable deterministic permissions. The chain will drive the ERP views. This solidifies BiblePay's total value in the crypto space.</div>Adminhttps://wiki.biblepay.org/index.php?title=ERC721b&diff=6943ERC721b2024-03-17T12:00:00Z<p>Admin: </p>
<hr />
<div>'''Improving the ERC-721 Spec (ERC-721b)<br />
'''<br />
<br />
'''Reason: '''<br />
<br />
Enhancing the functionality, security, and convenience of NFTs for use on the BiblePay blockchain.<br />
<br />
<br />
'''Current limitations with ERC-721:'''<br />
<br />
<br />
<br />
* Normal NFTs do not support Orphans because they can be re-sold to successive owners (bad in the sense of having a risk of deceiving or cheating the successive user out of the original relationship, and bad morally in the sense that you are reselling a sponsored orphan that you originally committed to). The solution is a Soul Bound NFT; an NFT that cannot be resold, and has a special designation on it allowing us to characterize the NFT as an orphan in showrooms.<br />
<br />
* NFTs cannot be deleted, they live forever. This is a positive trait, however for NFTs that are botched, they will just take more and more precious space in showrooms. The ERC solution is to transfer the NFT to the 0x0DEAD address, thereby filtering it out of active results. <br />
<br />
* NFTs do not protect valuable content. The original ERC721 spec allows anyone with view access to read the json payload and therefore download the contents of every file in the json. Yes, the intrinsic value of the NFT is based on the rarity, but it would be an improvement to be able to encrypt or hide a Treasure Chest that is only revealed to the Owner (IE the purchaser receives this ability after buying). This could be used for license activations, high resolution images, longer videos, crypto rewards, keys etc that are not revealed in the promotional NFT.<br />
<br />
* NFTs require a very high level of trust to the marketplace operator. The normal flow in buying an nft goes like this: You sign the rights off of your entire collection to OpenSea when you list *any* of your NFTs in that collection; the listing price is enforced at their UI level. There is no deterministic custodial account in the ERC721 NFT that holds the funds that proves that a user paid. Instead funds flow from the buyer to OpenSea (IE custodian), then you receive an email asking you to approve the transaction, and then the funds flow from OpenSea to your ERC wallet. This is on the minor end of our problems, but begs for an alternative deterministic solution.<br />
<br />
* The ERC721 spec does not allow for a minimum buy it now price to be set and for autonomous transactions to occur (goes hand in hand with point 4).<br />
<br />
* The ERC721 spec does not allow for a switch that would make the art "marketable" vs "non marketable". This is just a nice to have that would allow the owner to take something off the market temporarily, or hide an NFT without sending it to the dead address. <br />
<br />
<br />
<br />
<br />
<br />
'''Solution (Enhancing the ERC-721 spec to ERC-721b):'''<br />
<br />
<br />
* Modify the ERC721 spec (the OpenZeppelin Solidity contract ERC721.sol) with new enhancements, naming it ERC721b. Derive a BiblePay class for BBP use of the contract, and release the contract opensource when it goes to prod.<br />
<br />
<br />
* Add a public object to the solidity contract that tracks the following objects in maps, on the chain:<br />
<br />
UserBalances<br />
TreasureChest<br />
IsDeleted<br />
IsMarketable<br />
IsSoulBound<br />
BuyItNowAmount<br />
<br />
* Make it so the owner of an NFT, or the authorized NFT operator (permission given by owner in a marketplace) can update an NFTs IsDeleted, IsMarketable, IsSoulBound, and BuyItNow status just by interacting with the contract and paying gas.<br />
<br />
* Make it so the minting platform can set the TreasureChest URL that points to the TreasureChest JSON contents in a secure way, that can only be retrieved by the Owner of the NFT.<br />
The GetTreasureChest method will be protected by the _IsApprovedOrOwner() permission of the NFT, effectively making it impossible for a non-owner to call for the contents until they become the owner.<br />
The contents of the TreasureChest will be created upon minting, obfuscated to a uint256 private URL json file, stored in the BBP sidechain as a link, and set as a private property on the NFT at mint.<br />
<br />
* Make it so that users can deposit offers into the NFT contract securely, and if they decide to not purchase, they can withdraw from the NFT thereby their native currency is safe (minus gas fees).<br />
<br />
* Make it so that if a user has deposited more than the buy it now amount and an NFT is "marketable" and the user decides to BuyItNow, the NFT contract will automatically send the BuyItNow amount to the <br />
last owner, reduce the balance of the purchaser by the buy it now amount, and transfer the NFT to the new owner in a deterministic fashion so the steps cannot fail or leave the NFT and payment in an unknown state.<br />
The new owner will have access to the TreasureChest function, and ability to Edit the BBP fields if they decide to make the nft marketable again. <br />
<br />
* Soul Bound NFTs however, cannot be made marketable again. The SoulBound designation will allow the front end to display Orphans in a friendly way (different captions and sponsor process).<br />
<br />
* If IsDeleted is set to true, the NFT will be hidden (but still exists on the blockchain).<br />
<br />
* If a random user deposits ARB to an ERC721b contract, that balance will be credited to the sending address. The balance will be withdrawable by the original sender, if they call the "Withdraw" function on the contract.<br />
This is the same facility that will allow us to deterministically offer autonomous sales in the marketplace.<br />
<br />
* The ERC721b spec is backwards compatible with ERC721, meaning these same minted NFTs can be set up for sale on OpenSea or other marketplaces.<br />
However, OpenSea will not honor the Deleted flag, or the BuyItNowAmount, or the SoulBound, it will be up to the user to set up the sale in the classic manner. This is an important consideration however, as in the SEO discussion we find it important to maintain both a native NFT showroom and a public (external marketplace) for maximum traffic. <br />
<br />
<br />
<br />
<br />
'''SEO Strategy'''<br />
<br />
<br />
* The initial strategy for release is to create 3 new NFT contracts that capture our broad categories: Christian (God focused NFTs), General (Any other NFT or product or item), Orphan (An orphan to be sponsored for an amount of time as an NFT).<br />
<br />
* The categories derived by each contract drive a 'collection', and therefore the showroom caption (Orphan,Christian, General).<br />
<br />
* The collections can be viewed on OpenSea for external traffic. Those collections can be purchased with ETH inside the opensea marketplace.<br />
<br />
* The collections can be rendered by the BiblePay gallery engine for external HTML static content that leads to Unchained, but cannot be purchased unless the user logs in to unchained.<br />
<br />
* The collections can be rendered by BiblePay gallery as a logged in user, allowing actual BuyItNow with BBP or ARB.<br />
<br />
* In summary, this gives us (2) external SEO sources that we do not have now (OpenSea and our 'marketing' domain that is not released yet that hosts static content that leads to unchained. It also provides (2) ways to purchase an NFT: OpenSea with credit card/ethereum, Or BBP with BBP/ARB.<br />
<br />
* When buying an NFT through OpenSea, the deterministic BuyItNow function will not be called, but instead they will act as custodian and complete the sale.<br />
<br />
* When buying an NFT through BBP, the deterministic BuyItNow will be called, and the NFT will transfer autonomously.</div>Adminhttps://wiki.biblepay.org/index.php?title=ERC721b&diff=6942ERC721b2024-03-17T11:58:57Z<p>Admin: </p>
<hr />
<div>'''Improving the ERC-721 Spec (ERC-721b)<br />
'''<br />
<br />
'''Reason: '''<br />
<br />
Enhancing the functionality, security, and convenience of NFTs for use on the BiblePay blockchain.<br />
<br />
<br />
'''Current limitations with ERC-721:'''<br />
<br />
<br />
<br />
* Normal NFTs do not support Orphans because they can be re-sold to successive owners (bad in the sense of having a risk of deceiving or cheating the successive user out of the original relationship, and bad morally in the sense that you are reselling a sponsored orphan that you originally committed to). The solution is a Soul Bound NFT; an NFT that cannot be resold, and has a special designation on it allowing us to characterize the NFT as an orphan in showrooms.<br />
<br />
* NFTs cannot be deleted, they live forever. This is a positive trait, however for NFTs that are botched, they will just take more and more precious space in showrooms. The ERC solution is to transfer the NFT to the 0x0DEAD address, thereby filtering it out of active results. <br />
<br />
* NFTs do not protect valuable content. The original ERC721 spec allows anyone with view access to read the json payload and therefore download the contents of every file in the json. Yes, the intrinsic value of the NFT is based on the rarity, but it would be an improvement to be able to encrypt or hide a Treasure Chest that is only revealed to the Owner (IE the purchaser receives this ability after buying). This could be used for license activations, high resolution images, longer videos, crypto rewards, keys etc that are not revealed in the promotional NFT.<br />
<br />
* NFTs require a very high level of trust to the marketplace operator. The normal flow in buying an nft goes like this: You sign the rights off of your entire collection to OpenSea when you list *any* of your NFTs in that collection; the listing price is enforced at their UI level. There is no deterministic custodial account in the ERC721 NFT that holds the funds that proves that a user paid. Instead funds flow from the buyer to OpenSea (IE custodian), then you receive an email asking you to approve the transaction, and then the funds flow from OpenSea to your ERC wallet. This is on the minor end of our problems, but begs for an alternative deterministic solution.<br />
<br />
* The ERC721 spec does not allow for a minimum buy it now price to be set and for autonomous transactions to occur (goes hand in hand with point 4).<br />
<br />
* The ERC721 spec does not allow for a switch that would make the art "marketable" vs "non marketable". This is just a nice to have that would allow the owner to take something off the market temporarily, or hide an NFT without sending it to the dead address. Maybe its something they are holding on to and deciding on.<br />
<br />
<br />
<br />
<br />
<br />
'''Solution (Enhancing the ERC-721 spec to ERC-721b):'''<br />
<br />
<br />
* Modify the ERC721 spec (the OpenZeppelin Solidity contract ERC721.sol) with new enhancements, naming it ERC721b. Derive a BiblePay class for BBP use of the contract, and release the contract opensource when it goes to prod.<br />
<br />
<br />
* Add a public object to the solidity contract that tracks the following objects in maps, on the chain:<br />
<br />
UserBalances<br />
TreasureChest<br />
IsDeleted<br />
IsMarketable<br />
IsSoulBound<br />
BuyItNowAmount<br />
<br />
* Make it so the owner of an NFT, or the authorized NFT operator (permission given by owner in a marketplace) can update an NFTs IsDeleted, IsMarketable, IsSoulBound, and BuyItNow status just by interacting with the contract and paying gas.<br />
<br />
* Make it so the minting platform can set the TreasureChest URL that points to the TreasureChest JSON contents in a secure way, that can only be retrieved by the Owner of the NFT.<br />
The GetTreasureChest method will be protected by the _IsApprovedOrOwner() permission of the NFT, effectively making it impossible for a non-owner to call for the contents until they become the owner.<br />
The contents of the TreasureChest will be created upon minting, obfuscated to a uint256 private URL json file, stored in the BBP sidechain as a link, and set as a private property on the NFT at mint.<br />
<br />
* Make it so that users can deposit offers into the NFT contract securely, and if they decide to not purchase, they can withdraw from the NFT thereby their native currency is safe (minus gas fees).<br />
<br />
* Make it so that if a user has deposited more than the buy it now amount and an NFT is "marketable" and the user decides to BuyItNow, the NFT contract will automatically send the BuyItNow amount to the <br />
last owner, reduce the balance of the purchaser by the buy it now amount, and transfer the NFT to the new owner in a deterministic fashion so the steps cannot fail or leave the NFT and payment in an unknown state.<br />
The new owner will have access to the TreasureChest function, and ability to Edit the BBP fields if they decide to make the nft marketable again. <br />
<br />
* Soul Bound NFTs however, cannot be made marketable again. The SoulBound designation will allow the front end to display Orphans in a friendly way (different captions and sponsor process).<br />
<br />
* If IsDeleted is set to true, the NFT will be hidden (but still exists on the blockchain).<br />
<br />
* If a random user deposits ARB to an ERC721b contract, that balance will be credited to the sending address. The balance will be withdrawable by the original sender, if they call the "Withdraw" function on the contract.<br />
This is the same facility that will allow us to deterministically offer autonomous sales in the marketplace.<br />
<br />
* The ERC721b spec is backwards compatible with ERC721, meaning these same minted NFTs can be set up for sale on OpenSea or other marketplaces.<br />
However, OpenSea will not honor the Deleted flag, or the BuyItNowAmount, or the SoulBound, it will be up to the user to set up the sale in the classic manner. This is an important consideration however, as in the SEO discussion we find it important to maintain both a native NFT showroom and a public (external marketplace) for maximum traffic. <br />
<br />
<br />
<br />
<br />
'''SEO Strategy'''<br />
<br />
<br />
* The initial strategy for release is to create 3 new NFT contracts that capture our broad categories: Christian (God focused NFTs), General (Any other NFT or product or item), Orphan (An orphan to be sponsored for an amount of time as an NFT).<br />
<br />
* The categories derived by each contract drive a 'collection', and therefore the showroom caption (Orphan,Christian, General).<br />
<br />
* The collections can be viewed on OpenSea for external traffic. Those collections can be purchased with ETH inside the opensea marketplace.<br />
<br />
* The collections can be rendered by the BiblePay gallery engine for external HTML static content that leads to Unchained, but cannot be purchased unless the user logs in to unchained.<br />
<br />
* The collections can be rendered by BiblePay gallery as a logged in user, allowing actual BuyItNow with BBP or ARB.<br />
<br />
* In summary, this gives us (2) external SEO sources that we do not have now (OpenSea and our 'marketing' domain that is not released yet that hosts static content that leads to unchained. It also provides (2) ways to purchase an NFT: OpenSea with credit card/ethereum, Or BBP with BBP/ARB.<br />
<br />
* When buying an NFT through OpenSea, the deterministic BuyItNow function will not be called, but instead they will act as custodian and complete the sale.<br />
<br />
* When buying an NFT through BBP, the deterministic BuyItNow will be called, and the NFT will transfer autonomously.</div>Adminhttps://wiki.biblepay.org/index.php?title=ERC721b&diff=6941ERC721b2024-03-17T11:51:59Z<p>Admin: </p>
<hr />
<div>'''Improving the ERC-721 Spec (ERC-721b)<br />
'''<br />
<br />
'''Reason: '''<br />
<br />
Enhancing the functionality, security, and convenience of NFTs for use on the BiblePay blockchain.<br />
<br />
<br />
'''Current limitations with ERC-721:'''<br />
<br />
<br />
<br />
* Normal NFTs do not support Orphans because they can be re-sold to successive owners (bad in the sense of having a risk of deceiving or cheating the successive user out of the original relationship, and bad morally in the sense that you are reselling a sponsored orphan that you originally committed to). The solution is a Soul Bound NFT; an NFT that cannot be resold, and has a special designation on it allowing us to characterize the NFT as an orphan in showrooms.<br />
<br />
* NFTs cannot be deleted, they live forever. This is a positive trait, however for NFTs that are botched, they will just take more and more precious space in showrooms. The ERC solution is to transfer the NFT to the 0x0DEAD address, thereby filtering it out of active results. <br />
<br />
* NFTs do not protect valuable content. The original ERC721 spec allows anyone with view access to read the json payload and therefore download the contents of every file in the json. Yes, the intrinsic value of the NFT is based on the rarity, but it would be an improvement to be able to encrypt or hide a Treasure Chest that is only revealed to the Owner (IE the purchaser receives this ability after buying). This could be used for license activations, high resolution images, longer videos, crypto rewards, keys etc that are not revealed in the promotional NFT.<br />
<br />
* NFTs provide require a very high level of trust to the marketplace operator. The normal flow in buying an nft goes like this: You sign the rights off of your entire collection to OpenSea when you list *any* of your NFTs in that collection; the listing price is enforced at their UI level. There is no deterministic custodial account in the ERC721 NFT that holds the funds that proves that a user paid. Instead funds flow from the buyer to OpenSea (IE custodian), then you receive an email asking you to approve the transaction, and then the funds flow from OpenSea to your ERC wallet. This is on the minor end of our problems, but begs for an alternative deterministic solution.<br />
<br />
* The ERC721 spec does not allow for a minimum buy it now price to be set and for autonomous transactions to occur (goes hand in hand with point 4).<br />
<br />
* The ERC721 spec does not allow for a switch that would make the art "marketable" vs "non marketable". This is just a nice to have that would allow the owner to take something off the market temporarily, or hide an NFT without sending it to the dead address. Maybe its something they are holding on to and deciding on.<br />
<br />
<br />
<br />
<br />
<br />
'''Solution (Enhancing the ERC-721 spec to ERC-721b):'''<br />
<br />
<br />
* Modify the ERC721 spec (the OpenZeppelin Solidity contract ERC721.sol) with new enhancements, naming it ERC721b. Derive a BiblePay class for BBP use of the contract, and release the contract opensource when it goes to prod.<br />
<br />
<br />
* Add a public object to the solidity contract that tracks the following objects in maps, on the chain:<br />
<br />
UserBalances<br />
TreasureChest<br />
IsDeleted<br />
IsMarketable<br />
IsSoulBound<br />
BuyItNowAmount<br />
<br />
* Make it so the owner of an NFT, or the authorized NFT operator (permission given by owner in a marketplace) can update an NFTs IsDeleted, IsMarketable, IsSoulBound, and BuyItNow status just by interacting with the contract and paying gas.<br />
<br />
* Make it so the minting platform can set the TreasureChest URL that points to the TreasureChest JSON contents in a secure way, that can only be retrieved by the Owner of the NFT.<br />
The GetTreasureChest method will be protected by the _IsApprovedOrOwner() permission of the NFT, effectively making it impossible for a non-owner to call for the contents until they become the owner.<br />
The contents of the TreasureChest will be created upon minting, obfuscated to a uint256 private URL json file, stored in the BBP sidechain as a link, and set as a private property on the NFT at mint.<br />
<br />
* Make it so that users can deposit offers into the NFT contract securely, and if they decide to not purchase, they can withdraw from the NFT thereby their native currency is safe (minus gas fees).<br />
<br />
* Make it so that if a user has deposited more than the buy it now amount and an NFT is "marketable" and the user decides to BuyItNow, the NFT contract will automatically send the BuyItNow amount to the <br />
last owner, reduce the balance of the purchaser by the buy it now amount, and transfer the NFT to the new owner in a deterministic fashion so the steps cannot fail or leave the NFT and payment in an unknown state.<br />
The new owner will have access to the TreasureChest function, and ability to Edit the BBP fields if they decide to make the nft marketable again. <br />
<br />
* Soul Bound NFTs however, cannot be made marketable again. The SoulBound designation will allow the front end to display Orphans in a friendly way (different captions and sponsor process).<br />
<br />
* If IsDeleted is set to true, the NFT will be hidden (but still exists on the blockchain).<br />
<br />
* If a random user deposits ARB to an ERC721b contract, that balance will be credited to the sending address. The balance will be withdrawable by the original sender, if they call the "Withdraw" function on the contract.<br />
This is the same facility that will allow us to deterministically offer autonomous sales in the marketplace.<br />
<br />
* The ERC721b spec is backwards compatible with ERC721, meaning these same minted NFTs can be set up for sale on OpenSea or other marketplaces.<br />
However, OpenSea will not honor the Deleted flag, or the BuyItNowAmount, or the SoulBound, it will be up to the user to set up the sale in the classic manner. This is an important consideration however, as in the SEO discussion we find it important to maintain both a native NFT showroom and a public (external marketplace) for maximum traffic. <br />
<br />
<br />
<br />
<br />
'''SEO Strategy'''<br />
<br />
<br />
* The initial strategy for release is to create 3 new NFT contracts that capture our broad categories: Christian (God focused NFTs), General (Any other NFT or product or item), Orphan (An orphan to be sponsored for an amount of time as an NFT).<br />
<br />
* The categories derived by each contract drive a 'collection', and therefore the showroom caption (Orphan,Christian, General).<br />
<br />
* The collections can be viewed on OpenSea for external traffic. Those collections can be purchased with ETH inside the opensea marketplace.<br />
<br />
* The collections can be rendered by the BiblePay gallery engine for external HTML static content that leads to Unchained, but cannot be purchased unless the user logs in to unchained.<br />
<br />
* The collections can be rendered by BiblePay gallery as a logged in user, allowing actual BuyItNow with BBP or ARB.<br />
<br />
* In summary, this gives us (2) external SEO sources that we do not have now (OpenSea and our 'marketing' domain that is not released yet that hosts static content that leads to unchained. It also provides (2) ways to purchase an NFT: OpenSea with credit card/ethereum, Or BBP with BBP/ARB.<br />
<br />
* When buying an NFT through OpenSea, the deterministic BuyItNow function will not be called, but instead they will act as custodian and complete the sale.<br />
<br />
* When buying an NFT through BBP, the deterministic BuyItNow will be called, and the NFT will transfer autonomously.</div>Adminhttps://wiki.biblepay.org/index.php?title=ERC721b&diff=6940ERC721b2024-03-17T11:39:24Z<p>Admin: Created page with "'''Improving the ERC-721 Spec (ERC-721b) ''' '''Reason: ''' Enhancing the functionality, security, and convenience of NFTs for use on the BiblePay blockchain. '''Current..."</p>
<hr />
<div>'''Improving the ERC-721 Spec (ERC-721b)<br />
'''<br />
<br />
'''Reason: '''<br />
<br />
Enhancing the functionality, security, and convenience of NFTs for use on the BiblePay blockchain.<br />
<br />
<br />
'''Current limitations with ERC-721:'''<br />
<br />
<br />
<br />
* Normal NFTs do not support Orphans because they can be re-sold to successive owners (bad in the sense of having a risk of deceiving or cheating the successive user out of the original relationship, and bad morally in the sense that you are reselling a sponsored orphan that you originally committed to). The solution is a Soul Bound NFT; an NFT that cannot be resold, and has a special designation on it allowing us to characterize the NFT as an orphan in showrooms.<br />
<br />
* NFTs cannot be deleted, they live forever. This is a positive trait, however for NFTs that are botched, they will just take more and more precious space in showrooms. The ERC solution is to transfer the NFT to the 0x0DEAD address, thereby filtering it out of active results. <br />
<br />
* NFTs do not protect valuable content. The original ERC721 spec allows anyone with view access to read the json payload and therefore download the contents of every file in the json. Yes, the intrinsic value of the NFT is based on the rarity, but it would be an improvement to be able to encrypt or hide a Treasure Chest that is only revealed to the Owner (IE the purchaser receives this ability after buying). This could be used for license activations, high resolution images, longer videos, crypto rewards, keys etc that are not revealed in the promotional NFT.<br />
<br />
* NFTs provide require a very high level of trust to the marketplace operator. The normal flow in buying an nft goes like this: You sign the rights off of your entire collection to OpenSea when you list *any* of your NFTs in that collection; the listing price is enforced at their UI level. There is no deterministic custodial account in the ERC721 NFT that holds the funds that proves that a user paid. Instead funds flow from the buyer to OpenSea (IE custodian), then you receive an email asking you to approve the transaction, and then the funds flow from OpenSea to your ERC wallet. This is on the minor end of our problems, but begs for an alternative deterministic solution.<br />
<br />
* The ERC721 spec does not allow for a minimum buy it now price to be set and for autonomous transactions to occur (goes hand in hand with point 4).<br />
<br />
* The ERC721 spec does not allow for a switch that would make the art "marketable" vs "non marketable". This is just a nice to have that would allow the owner to take something off the market temporarily, or hide an NFT without sending it to the dead address. Maybe its something they are holding on to and deciding on.<br />
<br />
<br />
<br />
<br />
<br />
'''Solution (Enhancing the ERC-721 spec to ERC-721b):'''<br />
<br />
<br />
* Modify the ERC721 spec (the OpenZeppelin Solidity contract ERC721.sol) with new enhancements, naming it ERC721b. Derive a BiblePay class for BBP use of the contract, <br />
and release the contract opensource when it goes to prod.<br />
<br />
<br />
* Add a public object to the solidity contract that tracks the following objects in maps, on the chain:<br />
<br />
UserBalances<br />
TreasureChest<br />
IsDeleted<br />
IsMarketable<br />
IsSoulBound<br />
BuyItNowAmount<br />
<br />
* Make it so the owner of an NFT, or the authorized NFT operator (permission given by owner in a marketplace) can update an NFTs IsDeleted, IsMarketable, IsSoulBound, and BuyItNow status just by interacting with the contract and paying gas.<br />
<br />
* Make it so the minting platform can set the TreasureChest URL that points to the TreasureChest JSON contents in a secure way, that can only be retrieved by the Owner of the NFT.<br />
The GetTreasureChest method will be protected by the _IsApprovedOrOwner() permission of the NFT, effectively making it impossible for a non-owner to call for the contents until they become the owner.<br />
The contents of the TreasureChest will be created upon minting, obfuscated to a uint256 private URL json file, stored in the BBP sidechain as a link, and set as a private property on the NFT at mint.<br />
<br />
* Make it so that users can deposit offers into the NFT contract securely, and if they decide to not purchase, they can withdraw from the NFT thereby their native currency is safe (minus gas fees).<br />
<br />
* Make it so that if a user has deposited more than the buy it now amount and an NFT is "marketable" and the user decides to BuyItNow, the NFT contract will automatically send the BuyItNow amount to the <br />
last owner, reduce the balance of the purchaser by the buy it now amount, and transfer the NFT to the new owner in a deterministic fashion so the steps cannot fail or leave the NFT and payment in an unknown state.<br />
The new owner will have access to the TreasureChest function, and ability to Edit the BBP fields if they decide to make the nft marketable again. <br />
<br />
* Soul Bound NFTs however, cannot be made marketable again. The SoulBound designation will allow the front end to display Orphans in a friendly way (different captions and sponsor process).<br />
<br />
* If IsDeleted is set to true, the NFT will be hidden (but still exists on the blockchain).<br />
<br />
* If a random user deposits ARB to an ERC721b contract, that balance will be credited to the sending address. The balance will be withdrawable by the original sender, if they call the "Withdraw" function on the contract.<br />
This is the same facility that will allow us to deterministically offer autonomous sales in the marketplace.<br />
<br />
* The ERC721b spec is backwards compatible with ERC721, meaning these same minted NFTs can be set up for sale on OpenSea or other marketplaces.<br />
However, OpenSea will not honor the Deleted flag, or the BuyItNowAmount, or the SoulBound, it will be up to the user to set up the sale in the classic manner.<br />
It is discouraged to list a single NFT in multiple places, however if the NFT is sold in one marketplace it will dissapear from ownership in another since it ties back to the same NFT object on the chain.</div>Adminhttps://wiki.biblepay.org/index.php?title=ERP&diff=6939ERP2024-01-12T00:41:32Z<p>Admin: Created page with "'''Enterprise Resource Planning System''' An ERP system is tightly integrated with a companies back end processes allowing management of core operations. These activities in..."</p>
<hr />
<div>'''Enterprise Resource Planning System'''<br />
<br />
An ERP system is tightly integrated with a companies back end processes allowing management of core operations. These activities include data maintenance pages, accounting, project management, utilities, supply chain processes, reports, compliance etc.<br />
<br />
Some of the common boilerplate functionality that needs to exist in an ERP includes: authentication, permissions to data, permissions to functions, data maintenance pages, field captions, internationalization etc.<br />
<br />
Some of the common features that enterprises demand include video teleconferncing, meetings, phone service, source code management, e-mail hosting, ticket management and collaboration features.<br />
<br />
One place where BBP proposes to enter this space is in the area of custom designed front end business system (ERP) pages.<br />
<br />
Breaking this down into succinct technical features that BBP provides:<br />
- Synchronized Sidechain hosted on our decentralized database (ChainDB)<br />
- Synchronized View per organization-table (ChainDB views)<br />
- Field captions (ChainDB field captions)<br />
- ChainDb hosted ERP pages<br />
- ERP pages hosted from Sanctuaries<br />
<br />
Use Cases:<br />
NFT 2.0 will be hosted on ChainDB. Benefits: Immutable NFTs.<br />
BBP Phone History stored on ChainDB.</div>Adminhttps://wiki.biblepay.org/index.php?title=Free_Phone_Calls_for_New_Users&diff=6938Free Phone Calls for New Users2023-07-09T17:35:14Z<p>Admin: </p>
<hr />
<div><br />
BiblePay is giving away 125,000 BBP for free phone calls to our new users!<br />
<br />
Simply follow these directions:<br />
<br />
1. Download the BiblePay Desktop Wallet from here:<br />
https://biblepay.org/biblepay-win64.exe<br />
<br />
2. Install the Wallet<br />
<br />
3. Launch the wallet and sync the block chain<br />
<br />
4. Sync the wallet (allow the blocks to sync to height 431,000+)<br />
<br />
5. Click on the Unchained button from the left menu (this launches the Unchained Application)<br />
<br />
6. Click on Softphone (this is our built in BBP softphone that allows you to call anywhere in the world!)<br />
Copy your BBP address to the clipboard<br />
<br />
7. Email rob@biblepay.org with your address and he will send you your Free BBP so that you can make long distance phone calls for free.</div>Adminhttps://wiki.biblepay.org/index.php?title=Building_A_Temple&diff=6937Building A Temple2023-07-08T19:12:55Z<p>Admin: </p>
<hr />
<div>A Temple is a collection of 10 Sanctuaries. The first 12 Temples that we Christen will be named after a Tribe of Israel and will receive a special Seal.<br />
<br />
<br />
When you run a temple you are not only helping the BiblePay network by providing a cluster of Ten Sanctuaries (helping the users sync blocks and conduct instant send transactions), but you also act as a CockroachDB database node within the BiblePay Cockroach Cluster. Your node is entrusted to hold our active Orphan Sponsorship list, orphan expenses, orphan revenue records, Gospel Articles and Content, Gospel Wiki Content, Images hosted on our web site (Unchained.biblepay.org), our Wells project, the active Proposals and Voting records, Phone call transactions, and other database transactions. <br />
<br />
<br />
Note that Temples are rewarded at the same rate as other sanctuaries so the Temple operator is not earning more rewards than the average sanctuary owner, it is more of a community service position.<br />
<br />
<br />
<br />
''' Step 1 - Build a Single BiblePay Node '''<br />
<br />
For clarity, please build your temple as the root user, and build the temple in the folder "/biblepay".<br />
<br />
Rent an Unbuntu 20 VMS from your favorite VMS provider with a minimum of 6 cores, 600gb hard drive and 16gb of ram (these requirements ensure that the temple will not slow down the cockroachdb cluster and will<br />
be able to service the ten sanctuary instances, and most importantly will allow the temple to handle future Video traffic and cache storage for our gospel videos feature and upcoming social media features such as Deliverance Rooms ) .<br />
<br />
Follow these instructions to build biblebay:<br />
https://github.com/biblepay/biblepay/blob/master/BuildBiblePay.txt<br />
<br />
If you built biblepay in the /biblepay directory, you should find your biblepayd dameon here:<br />
/biblepay/biblepay/src/biblepayd<br />
If not, you can download the binary from the biblepay web site and copy it here, this way the rest of this guide will match.<br />
<br />
''' Step 2 - Set up 10 Sanctuaries to become a Potential Temple '''<br />
<br />
To be a temple, you will need to override the biblepayd settings with special values that will allow it to write to custom data folders and read custom configuration settings.<br />
For easy maintenance, in this guide I put all of your biblepay block data in /data and all of your biblepay configurations in /configs.<br />
First create configs directories:<br />
<br />
cd /<br />
mkdir /configs<br />
mkdir /data<br />
mkdir /data/biblepay1<br />
mkdir /data/biblepay2<br />
mkdir /data/biblepay3<br />
mkdir /data/biblepay4<br />
mkdir /data/biblepay5<br />
mkdir /data/biblepay6<br />
mkdir /data/biblepay7<br />
mkdir /data/biblepay8<br />
mkdir /data/biblepay9<br />
mkdir /data/biblepay10<br />
cd /configs<br />
<br />
<br />
nano biblepay1.conf<br />
shrinkdebugfile=1<br />
datadir=/data/biblepay1<br />
masternodeblsprivkey=your_bls_privkey<br />
port=40000<br />
rpcport=20000<br />
<br />
<br />
Save the file (ctrl-x, shift-Y, enter)<br />
<br />
<br />
Copy this biblepay1.conf file 10 times to:<br />
<br />
<br />
biblepay1.conf, biblepay2.conf, biblepay3.conf ... biblepay10.conf<br />
<br />
<br />
(IE type: )<br />
<br />
cp biblepay1.conf biblepay2.conf<br />
<br />
cp biblepay1.conf biblepay3.conf<br />
<br />
cp biblepay1.conf biblepay4.conf<br />
... <br />
Stopping with<br />
cp biblepay1.conf biblepay10.conf<br />
<br />
<br />
<br />
Next, edit each file by using nano, and set the following values:<br />
<br />
<br />
For biblepay1.conf, ensure the port=40000 and the rpcport=20001<br />
<br />
For biblepay2.conf, ensure the port=10002 and the rpcport=20002<br />
<br />
... (Continue this pattern for files 3 through 9).<br />
<br />
<br />
For biblepay10.conf, ensure the port=10010 and the rpcport=20010.<br />
<br />
<br />
<br />
<br />
Edit the your_bls_privkey with the privkey of the sanctuary that you set up in "EasySanc".<br />
<br />
The general rule for the "port" is your first sanc (biblepay1) must have a port of 40000 (this allows outside nodes to find you), <br />
but, each successive sanc from sanc2-sanc10 must have a port of 10002-10010 (as other sancs will pose ban you otherwise. )<br />
<br />
The rule for "rpcport" is they should be unique, starting with 20001 and working up to 20010 (they must be unique, otherwise the node will not start).<br />
<br />
<br />
Firewall Changes:<br />
<br />
In this section simply expose :<br />
<br />
sudo ufw allow 10002<br />
sudo ufw allow 10003<br />
sudo ufw allow 10004<br />
sudo ufw allow 10005<br />
sudo ufw allow 10006<br />
sudo ufw allow 10007<br />
sudo ufw allow 10008<br />
sudo ufw allow 10009<br />
sudo ufw allow 10010<br />
sudo ufw allow 40000<br />
<br />
<br />
''' Start the Nodes and verify each one syncs and acts as a Sanctuary '''<br />
<br />
<br />
Write a script to launch your nodes so you dont need to manually launch each node in the case of a reboot etc:<br />
<br />
cd /configs<br />
<br />
nano startbiblepayd.sh<br />
<br />
/biblepay/biblepay/src/biblepayd -conf=/configs/biblepay1.conf<br />
/biblepay/biblepay/src/biblepayd -conf=/configs/biblepay2.conf<br />
/biblepay/biblepay/src/biblepayd -conf=/configs/biblepay3.conf<br />
/biblepay/biblepay/src/biblepayd -conf=/configs/biblepay4.conf<br />
/biblepay/biblepay/src/biblepayd -conf=/configs/biblepay5.conf<br />
/biblepay/biblepay/src/biblepayd -conf=/configs/biblepay6.conf<br />
/biblepay/biblepay/src/biblepayd -conf=/configs/biblepay7.conf<br />
/biblepay/biblepay/src/biblepayd -conf=/configs/biblepay8.conf<br />
/biblepay/biblepay/src/biblepayd -conf=/configs/biblepay9.conf<br />
/biblepay/biblepay/src/biblepayd -conf=/configs/biblepay10.conf<br />
<br />
<br />
ctrl-X, Shift-Y <enter> (to save the file)<br />
<br />
<br />
chmod 777 startbiblepayd.sh<br />
<br />
To start the nodes simply run the startbiblepayd.sh file by doing this:<br />
<br />
cd /configs<br />
./startbiblepayd.sh<br />
<br />
<br />
<br />
<br />
''' Check if BiblePay is synced '''<br />
<br />
cd /biblepay/biblepay/src<br />
<br />
biblepay-cli -conf=/configs/biblepay1.conf getblockchaininfo<br />
<br />
This command should respond with the synced number of blocks<br />
<br />
<br />
<br />
''' Check if each node is running as a sanctuary '''<br />
<br />
biblepay-cli -conf=/configs/biblepay1.conf masternode status<br />
<br />
This should respond with outpoint info if masternode is running.</div>Adminhttps://wiki.biblepay.org/index.php?title=Building_A_Temple&diff=6936Building A Temple2023-07-08T19:10:49Z<p>Admin: </p>
<hr />
<div>A Temple is a collection of 10 Sanctuaries. The first 12 Temples that we Christen will be named after a Tribe of Israel and will receive a special Seal.<br />
<br />
<br />
When you run a temple you are not only helping the BiblePay network by providing a cluster of Ten Sanctuaries (helping the users sync blocks and conduct instant send transactions), but you also act as a CockroachDB database node within the BiblePay Cockroach Cluster. Your node is entrusted to hold our active Orphan Sponsorship list, orphan expenses, orphan revenue records, Gospel Articles and Content, Gospel Wiki Content, Images hosted on our web site (Unchained.biblepay.org), our Wells project, the active Proposals and Voting records, Phone call transactions, and other database transactions. <br />
<br />
<br />
Note that Temples are rewarded at the same rate as other sanctuaries so the Temple operator is not earning more rewards than the average sanctuary owner, it is more of a community service position.<br />
<br />
<br />
<br />
''' Step 1 - Build a Single BiblePay Node '''<br />
<br />
For clarity, please build your temple as the root user, and build the temple in the folder "/biblepay".<br />
<br />
Rent an Unbuntu 20 VMS from your favorite VMS provider with a minimum of 6 cores, 600gb hard drive and 16gb of ram (these requirements ensure that the temple will not slow down the cockroachdb cluster and will<br />
be able to service the ten sanctuary instances, and most importantly will allow the temple to handle future Video traffic and cache storage for our gospel videos feature and upcoming social media features such as Deliverance Rooms ) .<br />
<br />
Follow these instructions to build biblebay:<br />
https://github.com/biblepay/biblepay/blob/master/BuildBiblePay.txt<br />
<br />
If you built biblepay in the /biblepay directory, you should find your biblepayd dameon here:<br />
/biblepay/biblepay/src/biblepayd<br />
If not, you can download the binary from the biblepay web site and copy it here, this way the rest of this guide will match.<br />
<br />
''' Step 2 - Set up 10 Sanctuaries to become a Potential Temple '''<br />
<br />
To be a temple, you will need to override the biblepayd settings with special values that will allow it to write to custom data folders and read custom configuration settings.<br />
For easy maintenance, in this guide I put all of your biblepay block data in /data and all of your biblepay configurations in /configs.<br />
First create configs directories:<br />
<br />
cd /<br />
mkdir /configs<br />
mkdir /data<br />
mkdir /data/biblepay1<br />
mkdir /data/biblepay2<br />
mkdir /data/biblepay3<br />
mkdir /data/biblepay4<br />
mkdir /data/biblepay5<br />
mkdir /data/biblepay6<br />
mkdir /data/biblepay7<br />
mkdir /data/biblepay8<br />
mkdir /data/biblepay9<br />
mkdir /data/biblepay10<br />
cd /configs<br />
<br />
<br />
nano biblepay1.conf<br />
shrinkdebugfile=1<br />
datadir=/data/biblepay1<br />
masternodeblsprivkey=your_bls_privkey<br />
port=40000<br />
rpcport=20000<br />
<br />
<br />
Save the file (ctrl-x, shift-Y, enter)<br />
<br />
<br />
Copy this biblepay1.conf file 10 times to:<br />
biblepay1.conf, biblepay2.conf ... biblepay10.conf<br />
(IE type:<br />
cp biblepay1.conf biblepay2.conf<br />
cp biblepay1.conf biblepay3.conf<br />
... <br />
)<br />
<br />
Edit each file by using nano, and set the following values:<br />
<br />
For biblepay1.conf, ensure the port=40000 and the rpcport=20001<br />
<br />
For biblepay2.conf, ensure the port=10002 and the rpcport=20002<br />
<br />
... (Continue this pattern for files 3 through 9).<br />
<br />
For biblepay10.conf, ensure the port=10010 and the rpcport=20010<br />
<br />
<br />
Edit the your_bls_privkey with the privkey of the sanctuary that you set up in "EasySanc".<br />
<br />
The general rule for the "port" is your first sanc (biblepay1) must have a port of 40000 (this allows outside nodes to find you), <br />
but, each successive sanc from sanc2-sanc10 must have a port of 10002-10010 (as other sancs will pose ban you otherwise. )<br />
<br />
The rule for "rpcport" is they should be unique, starting with 20001 and working up to 20010 (they must be unique, otherwise the node will not start).<br />
<br />
<br />
Firewall Changes:<br />
<br />
In this section simply expose :<br />
<br />
sudo ufw allow 10002<br />
sudo ufw allow 10003<br />
sudo ufw allow 10004<br />
sudo ufw allow 10005<br />
sudo ufw allow 10006<br />
sudo ufw allow 10007<br />
sudo ufw allow 10008<br />
sudo ufw allow 10009<br />
sudo ufw allow 10010<br />
sudo ufw allow 40000<br />
<br />
<br />
''' Start the Nodes and verify each one syncs and acts as a Sanctuary '''<br />
<br />
Write a script to launch your nodes so you dont need to manually launch each node in the case of a reboot etc:<br />
<br />
cd /configs<br />
<br />
nano startbiblepayd.sh<br />
<br />
/biblepay/biblepay/src/biblepayd -conf=/configs/biblepay1.conf<br />
/biblepay/biblepay/src/biblepayd -conf=/configs/biblepay2.conf<br />
/biblepay/biblepay/src/biblepayd -conf=/configs/biblepay3.conf<br />
/biblepay/biblepay/src/biblepayd -conf=/configs/biblepay4.conf<br />
/biblepay/biblepay/src/biblepayd -conf=/configs/biblepay5.conf<br />
/biblepay/biblepay/src/biblepayd -conf=/configs/biblepay6.conf<br />
/biblepay/biblepay/src/biblepayd -conf=/configs/biblepay7.conf<br />
/biblepay/biblepay/src/biblepayd -conf=/configs/biblepay8.conf<br />
/biblepay/biblepay/src/biblepayd -conf=/configs/biblepay9.conf<br />
/biblepay/biblepay/src/biblepayd -conf=/configs/biblepay10.conf<br />
<br />
<br />
ctrl-X, Shift-Y <enter> (to save the file)<br />
<br />
<br />
chmod 777 startbiblepayd.sh<br />
<br />
To start the nodes simply run the startbiblepayd.sh file by doing this:<br />
<br />
cd /configs<br />
./startbiblepayd.sh<br />
<br />
<br />
<br />
<br />
''' Check if BiblePay is synced '''<br />
<br />
cd /biblepay/biblepay/src<br />
<br />
biblepay-cli -conf=/configs/biblepay1.conf getblockchaininfo<br />
<br />
This command should respond with the synced number of blocks<br />
<br />
<br />
<br />
''' Check if each node is running as a sanctuary '''<br />
<br />
biblepay-cli -conf=/configs/biblepay1.conf masternode status<br />
<br />
This should respond with outpoint info if masternode is running.</div>Adminhttps://wiki.biblepay.org/index.php?title=Building_A_Temple&diff=6935Building A Temple2023-07-08T19:08:12Z<p>Admin: </p>
<hr />
<div>A Temple is a collection of 10 Sanctuaries. The first 12 Temples that we Christen will be named after a Tribe of Israel and will receive a special Seal.<br />
<br />
<br />
When you run a temple you are not only helping the BiblePay network by providing a cluster of Ten Sanctuaries (helping the users sync blocks and conduct instant send transactions), but you also act as a CockroachDB database node within the BiblePay Cockroach Cluster. Your node is entrusted to hold our active Orphan Sponsorship list, orphan expenses, orphan revenue records, Gospel Articles and Content, Gospel Wiki Content, Images hosted on our web site (Unchained.biblepay.org), our Wells project, the active Proposals and Voting records, Phone call transactions, and other database transactions. <br />
<br />
<br />
Note that Temples are rewarded at the same rate as other sanctuaries so the Temple operator is not earning more rewards than the average sanctuary owner, it is more of a community service position.<br />
<br />
<br />
<br />
''' Step 1 - Build a Single BiblePay Node '''<br />
<br />
For clarity, please build your temple as the root user, and build the temple in the folder "/biblepay".<br />
<br />
Rent an Unbuntu 20 VMS from your favorite VMS provider with a minimum of 6 cores, 600gb hard drive and 16gb of ram (these requirements ensure that the temple will not slow down the cockroachdb cluster and will<br />
be able to service the ten sanctuary instances, and most importantly will allow the temple to handle future Video traffic and cache storage for our gospel videos feature and upcoming social media features such as Deliverance Rooms ) .<br />
<br />
Follow these instructions to build biblebay:<br />
https://github.com/biblepay/biblepay/blob/master/BuildBiblePay.txt<br />
<br />
If you built biblepay in the /biblepay directory, you should find your biblepayd dameon here:<br />
/biblepay/biblepay/src/biblepayd<br />
If not, you can download the binary from the biblepay web site and copy it here, this way the rest of this guide will match.<br />
<br />
''' Step 2 - Set up 10 Sanctuaries to become a Potential Temple '''<br />
<br />
To be a temple, you will need to override the biblepayd settings with special values that will allow it to write to custom data folders and read custom configuration settings.<br />
For easy maintenance, in this guide I put all of your biblepay block data in /data and all of your biblepay configurations in /configs.<br />
First create configs directories:<br />
<br />
cd /<br />
mkdir /configs<br />
mkdir /data<br />
mkdir /data/biblepay1<br />
mkdir /data/biblepay2<br />
mkdir /data/biblepay3<br />
mkdir /data/biblepay4<br />
mkdir /data/biblepay5<br />
mkdir /data/biblepay6<br />
mkdir /data/biblepay7<br />
mkdir /data/biblepay8<br />
mkdir /data/biblepay9<br />
mkdir /data/biblepay10<br />
cd /configs<br />
<br />
<br />
nano biblepay1.conf<br />
shrinkdebugfile=1<br />
datadir=/data/biblepay1<br />
masternodeblsprivkey=your_bls_privkey<br />
port=40000<br />
rpcport=20000<br />
<br />
<br />
Save the file (ctrl-x, shift-Y, enter)<br />
<br />
<br />
Copy this biblepay1.conf file 10 times to:<br />
biblepay1.conf, biblepay2.conf ... biblepay10.conf<br />
(IE type:<br />
cp biblepay1.conf biblepay2.conf<br />
cp biblepay1.conf biblepay3.conf<br />
... <br />
)<br />
<br />
Edit each file by using nano, and set the following values:<br />
<br />
For biblepay1.conf, ensure the port=40000 and the rpcport=20001<br />
<br />
For biblepay2.conf, ensure the port=10002 and the rpcport=20002<br />
<br />
... (Continue this pattern for files 3 through 9).<br />
<br />
For biblepay10.conf, ensure the port=10010 and the rpcport=20010<br />
<br />
<br />
Edit the your_bls_privkey with the privkey of the sanctuary that you set up in "EasySanc".<br />
<br />
The general rule for the "port" is your first sanc (biblepay1) must have a port of 40000 (this allows outside nodes to find you), <br />
but, each successive sanc from sanc2-sanc10 must have a port of 10002-10010 (as other sancs will pose ban you otherwise. )<br />
<br />
The rule for "rpcport" is they should be unique, starting with 20001 and working up to 20010 (they must be unique, otherwise the node will not start).<br />
<br />
<br />
Firewall Changes:<br />
<br />
In this section simply expose :<br />
<br />
sudo ufw allow 10002<br />
sudo ufw allow 10003<br />
sudo ufw allow 10004<br />
sudo ufw allow 10005<br />
sudo ufw allow 10006<br />
sudo ufw allow 10007<br />
sudo ufw allow 10008<br />
sudo ufw allow 10009<br />
sudo ufw allow 10010<br />
sudo ufw allow 40000<br />
<br />
<br />
''' Start the Nodes and verify each one syncs and acts as a Sanctuary '''<br />
<br />
Write a script to launch your nodes so you dont need to manually launch each node in the case of a reboot etc:<br />
<br />
cd /configs<br />
nano startbiblepayd.sh<br />
<br />
/biblepay/biblepay/src/biblepayd -conf=/configs/biblepay1.conf<br />
/biblepay/biblepay/src/biblepayd -conf=/configs/biblepay2.conf<br />
/biblepay/biblepay/src/biblepayd -conf=/configs/biblepay3.conf<br />
/biblepay/biblepay/src/biblepayd -conf=/configs/biblepay4.conf<br />
/biblepay/biblepay/src/biblepayd -conf=/configs/biblepay5.conf<br />
/biblepay/biblepay/src/biblepayd -conf=/configs/biblepay6.conf<br />
/biblepay/biblepay/src/biblepayd -conf=/configs/biblepay7.conf<br />
/biblepay/biblepay/src/biblepayd -conf=/configs/biblepay8.conf<br />
/biblepay/biblepay/src/biblepayd -conf=/configs/biblepay9.conf<br />
/biblepay/biblepay/src/biblepayd -conf=/configs/biblepay10.conf<br />
<br />
ctrl-X, Shift-Y <enter><br />
chmod 777 startbiblepayd.sh<br />
<br />
<br />
''' Check if BiblePay is synced '''<br />
<br />
cd /biblepay/biblepay/src<br />
biblepay-cli -conf=/configs/biblepay1.conf getblockchaininfo<br />
<br />
This should respond with the synced number of blocks<br />
<br />
biblepay-cli -conf=/configs/biblepay1.conf masternode status<br />
<br />
This should respond with outpoint info if masternode is running.</div>Adminhttps://wiki.biblepay.org/index.php?title=Building_A_Temple&diff=6934Building A Temple2023-07-08T19:05:30Z<p>Admin: </p>
<hr />
<div>A Temple is a collection of 10 Sanctuaries. The first 12 Temples that we Christen will be named after a Tribe of Israel and will receive a special Seal.<br />
<br />
<br />
When you run a temple you are not only helping the BiblePay network by providing a cluster of Ten Sanctuaries (helping the users sync blocks and conduct instant send transactions), but you also act as a CockroachDB database node within the BiblePay Cockroach Cluster. Your node is entrusted to hold our active Orphan Sponsorship list, orphan expenses, orphan revenue records, Gospel Articles and Content, Gospel Wiki Content, Images hosted on our web site (Unchained.biblepay.org), our Wells project, the active Proposals and Voting records, Phone call transactions, and other database transactions. <br />
<br />
<br />
Note that Temples are rewarded at the same rate as other sanctuaries so the Temple operator is not earning more rewards than the average sanctuary owner, it is more of a community service position.<br />
<br />
<br />
<br />
''' Step 1 - Build a Single BiblePay Node '''<br />
<br />
For clarity, please build your temple as the root user, and build the temple in the folder "/biblepay".<br />
<br />
Rent an Unbuntu 20 VMS from your favorite VMS provider with a minimum of 6 cores, 600gb hard drive and 16gb of ram (these requirements ensure that the temple will not slow down the cockroachdb cluster and will<br />
be able to service the ten sanctuary instances, and most importantly will allow the temple to handle future Video traffic and cache storage for our gospel videos feature and upcoming social media features such as Deliverance Rooms ) .<br />
<br />
Follow these instructions to build biblebay:<br />
https://github.com/biblepay/biblepay/blob/master/BuildBiblePay.txt<br />
<br />
If you built biblepay in the /biblepay directory, you should find your biblepayd dameon here:<br />
/biblepay/biblepay/src/biblepayd<br />
If not, you can download the binary from the biblepay web site and copy it here, this way the rest of this guide will match.<br />
<br />
''' Step 2 - Set up 10 Sanctuaries to become a Potential Temple '''<br />
<br />
To be a temple, you will need to override the biblepayd settings with special values that will allow it to write to custom data folders and read custom configuration settings.<br />
For easy maintenance, in this guide I put all of your biblepay block data in /data and all of your biblepay configurations in /configs.<br />
First create configs directories:<br />
<br />
cd /<br />
mkdir /configs<br />
mkdir /data<br />
mkdir /data/biblepay1<br />
mkdir /data/biblepay2<br />
mkdir /data/biblepay3<br />
mkdir /data/biblepay4<br />
mkdir /data/biblepay5<br />
mkdir /data/biblepay6<br />
mkdir /data/biblepay7<br />
mkdir /data/biblepay8<br />
mkdir /data/biblepay9<br />
mkdir /data/biblepay10<br />
cd /configs<br />
<br />
<br />
nano biblepay1.conf<br />
shrinkdebugfile=1<br />
datadir=/data/biblepay1<br />
masternodeblsprivkey=your_bls_privkey<br />
port=40000<br />
rpcport=20000<br />
<br />
<br />
Save the file (ctrl-x, shift-Y, enter)<br />
<br />
<br />
Copy this biblepay1.conf file 10 times to:<br />
biblepay1.conf, biblepay2.conf ... biblepay10.conf<br />
(IE type:<br />
cp biblepay1.conf biblepay2.conf<br />
cp biblepay1.conf biblepay3.conf<br />
... <br />
)<br />
<br />
Edit each file by using nano, and set the following values:<br />
<br />
For biblepay1.conf, ensure the port=40000 and the rpcport=20001<br />
<br />
For biblepay2.conf, ensure the port=10002 and the rpcport=20002<br />
<br />
... (Continue this pattern for files 3 through 9).<br />
<br />
For biblepay10.conf, ensure the port=10010 and the rpcport=20010<br />
<br />
<br />
Edit the your_bls_privkey with the privkey of the sanctuary that you set up in "EasySanc".<br />
<br />
The general rule for the "port" is your first sanc (biblepay1) must have a port of 40000 (this allows outside nodes to find you), <br />
but, each successive sanc from sanc2-sanc10 must have a port of 10002-10010 (as other sancs will pose ban you otherwise. )<br />
<br />
The rule for "rpcport" is they should be unique, starting with 20001 and working up to 20010 (they must be unique, otherwise the node will not start).<br />
<br />
<br />
Firewall Changes:<br />
<br />
In this section simply expose :<br />
<br />
sudo ufw allow 10002-10010<br />
sudo ufw allow 40000<br />
<br />
<br />
''' Start the Nodes and verify each one syncs and acts as a Sanctuary '''<br />
<br />
Write a script to launch your nodes so you dont need to manually launch each node in the case of a reboot etc:<br />
<br />
cd /configs<br />
nano startbiblepayd.sh<br />
<br />
/biblepay/biblepay/src/biblepayd -conf=/configs/biblepay1.conf<br />
/biblepay/biblepay/src/biblepayd -conf=/configs/biblepay2.conf<br />
/biblepay/biblepay/src/biblepayd -conf=/configs/biblepay3.conf<br />
/biblepay/biblepay/src/biblepayd -conf=/configs/biblepay4.conf<br />
/biblepay/biblepay/src/biblepayd -conf=/configs/biblepay5.conf<br />
/biblepay/biblepay/src/biblepayd -conf=/configs/biblepay6.conf<br />
/biblepay/biblepay/src/biblepayd -conf=/configs/biblepay7.conf<br />
/biblepay/biblepay/src/biblepayd -conf=/configs/biblepay8.conf<br />
/biblepay/biblepay/src/biblepayd -conf=/configs/biblepay9.conf<br />
/biblepay/biblepay/src/biblepayd -conf=/configs/biblepay10.conf<br />
<br />
ctrl-X, Shift-Y <enter><br />
chmod 777 startbiblepayd.sh<br />
<br />
<br />
''' Check if BiblePay is synced '''<br />
<br />
cd /biblepay/biblepay/src<br />
biblepay-cli -conf=/configs/biblepay1.conf getblockchaininfo<br />
<br />
This should respond with the synced number of blocks<br />
<br />
biblepay-cli -conf=/configs/biblepay1.conf masternode status<br />
<br />
This should respond with outpoint info if masternode is running.</div>Adminhttps://wiki.biblepay.org/index.php?title=Building_A_Temple&diff=6933Building A Temple2023-07-08T18:52:32Z<p>Admin: </p>
<hr />
<div>A Temple is a collection of 10 Sanctuaries. The first 12 Temples that we Christen will be named after a Tribe of Israel and will receive a special Seal.<br />
<br />
<br />
When you run a temple you are not only helping the BiblePay network by providing a cluster of Ten Sanctuaries (helping the users sync blocks and conduct instant send transactions), but you also act as a CockroachDB database node within the BiblePay Cockroach Cluster. Your node is entrusted to hold our active Orphan Sponsorship list, orphan expenses, orphan revenue records, Gospel Articles and Content, Gospel Wiki Content, Images hosted on our web site (Unchained.biblepay.org), our Wells project, the active Proposals and Voting records, Phone call transactions, and other database transactions. <br />
<br />
<br />
Note that Temples are rewarded at the same rate as other sanctuaries so the Temple operator is not earning more rewards than the average sanctuary owner, it is more of a community service position.<br />
<br />
<br />
<br />
''' Step 1 - Build a Single BiblePay Node '''<br />
<br />
For clarity, please build your temple as the root user, and build the temple in the folder "/biblepay".<br />
<br />
Rent an Unbuntu 20 VMS from your favorite VMS provider with a minimum of 6 cores, 600gb hard drive and 16gb of ram (these requirements ensure that the temple will not slow down the cockroachdb cluster and will<br />
be able to service the ten sanctuary instances, and most importantly will allow the temple to handle future Video traffic and cache storage for our gospel videos feature and upcoming social media features such as Deliverance Rooms ) .<br />
<br />
Follow these instructions to build biblebay:<br />
https://github.com/biblepay/biblepay/blob/master/BuildBiblePay.txt<br />
<br />
If you built biblepay in the /biblepay directory, you should find your biblepayd dameon here:<br />
/biblepay/biblepay/src/biblepayd<br />
If not, you can download the binary from the biblepay web site and copy it here, this way the rest of this guide will match.<br />
<br />
''' Step 2 - Set up 10 Sanctuaries to become a Potential Temple '''<br />
<br />
To be a temple, you will need to override the biblepayd settings with special values that will allow it to write to custom data folders and read custom configuration settings.<br />
For easy maintenance, in this guide I put all of your biblepay block data in /data and all of your biblepay configurations in /configs.<br />
First create configs directories:<br />
<br />
cd /<br />
mkdir /configs<br />
mkdir /data<br />
cd /configs<br />
<br />
<br />
nano biblepay1.conf<br />
shrinkdebugfile=1<br />
datadir=/data/biblepay1<br />
masternodeblsprivkey=your_bls_privkey<br />
port=40000<br />
rpcport=20000<br />
<br />
<br />
Save the file (ctrl-x, shift-Y, enter)<br />
<br />
<br />
Copy this biblepay1.conf file 10 times to:<br />
biblepay1.conf, biblepay2.conf ... biblepay10.conf<br />
(IE type:<br />
cp biblepay1.conf biblepay2.conf<br />
cp biblepay1.conf biblepay3.conf<br />
... <br />
)<br />
<br />
Edit each file by using nano, and set the following values:<br />
<br />
For biblepay1.conf, ensure the port=40000 and the rpcport=20001<br />
<br />
For biblepay2.conf, ensure the port=10002 and the rpcport=20002<br />
<br />
... (Continue this pattern for files 3 through 9).<br />
<br />
For biblepay10.conf, ensure the port=10010 and the rpcport=20010<br />
<br />
<br />
Edit the your_bls_privkey with the privkey of the sanctuary that you set up in "EasySanc".<br />
<br />
The general rule for the "port" is your first sanc (biblepay1) must have a port of 40000 (this allows outside nodes to find you), <br />
but, each successive sanc from sanc2-sanc10 must have a port of 10002-10010 (as other sancs will pose ban you otherwise. )<br />
<br />
The rule for "rpcport" is they should be unique, starting with 20001 and working up to 20010 (they must be unique, otherwise the node will not start).<br />
<br />
<br />
Firewall Changes:<br />
<br />
In this section simply expose :<br />
<br />
sudo ufw allow 10002-10010<br />
sudo ufw allow 40000</div>Adminhttps://wiki.biblepay.org/index.php?title=Building_A_Temple&diff=6932Building A Temple2023-07-08T18:48:38Z<p>Admin: </p>
<hr />
<div>A Temple is a collection of 10 Sanctuaries. The first 12 Temples that we Christen will be named after a Tribe of Israel and will receive a special Seal.<br />
<br />
<br />
When you run a temple you are not only helping the BiblePay network by providing a cluster of Ten Sanctuaries (helping the users sync blocks and conduct instant send transactions), but you also act as a CockroachDB database node within the BiblePay Cockroach Cluster. Your node is entrusted to hold our active Orphan Sponsorship list, orphan expenses, orphan revenue records, Gospel Articles and Content, Gospel Wiki Content, Images hosted on our web site (Unchained.biblepay.org), our Wells project, the active Proposals and Voting records, Phone call transactions, and other database transactions. <br />
<br />
<br />
Note that Temples are rewarded at the same rate as other sanctuaries so the Temple operator is not earning more rewards than the average sanctuary owner, it is more of a community service position.<br />
<br />
<br />
<br />
''' Step 1 - Build a Single BiblePay Node '''<br />
<br />
For clarity, please build your temple as the root user, and build the temple in the folder "/biblepay".<br />
<br />
Rent an Unbuntu 20 VMS from your favorite VMS provider with a minimum of 6 cores, 600gb hard drive and 16gb of ram (these requirements ensure that the temple will not slow down the cockroachdb cluster and will<br />
be able to service the ten sanctuary instances, and most importantly will allow the temple to handle future Video traffic and cache storage for our gospel videos feature and upcoming social media features such as Deliverance Rooms ) .<br />
<br />
Follow these instructions to build biblebay:<br />
https://github.com/biblepay/biblepay/blob/master/BuildBiblePay.txt<br />
<br />
If you built biblepay in the /biblepay directory, you should find your biblepayd dameon here:<br />
/biblepay/biblepay/src/biblepayd<br />
If not, you can download the binary from the biblepay web site and copy it here, this way the rest of this guide will match.<br />
<br />
''' Step 2 - Set up 10 Sanctuaries to become a Potential Temple '''<br />
<br />
To be a temple, you will need to override the biblepayd settings with special values that will allow it to write to custom data folders and read custom configuration settings.<br />
For easy maintenance, in this guide I put all of your biblepay block data in /data and all of your biblepay configurations in /configs.<br />
First create a configs directory:<br />
cd /<br />
mkdir /configs<br />
mkdir /data<br />
cd /configs<br />
<br />
nano biblepay1.conf<br />
shrinkdebugfile=1<br />
datadir=/data/biblepay1<br />
masternodeblsprivkey=your_bls_privkey<br />
port=40000<br />
rpcport=20000<br />
<br />
Save the file (ctrl-x, shift-Y, enter)<br />
<br />
Copy this file 10 times to:<br />
biblepay1.conf, biblepay2.conf ... biblepay10.conf<br />
Edit each file and set the following values:<br />
For biblepay1.conf, ensure the port=40000 and the rpcport=20001<br />
For biblepay2.conf, ensure the port=10002 and the rpcport=20002<br />
...<br />
For biblepay10.conf, ensure the port=10010 and the rpcport=20010<br />
Edit the your_bls_privkey with the privkey of the sanctuary that you set up in "EasySanc".<br />
The general rule for the "port" is your first sanc (biblepay1) must have a port of 40000 (this allows outside nodes to find you), but, each successive sanc from sanc2-sanc10 must have a port of 10002-10010 (as other sancs whitelist this port, ports outside of the 100NN range are POSE banned. )<br />
The rule for "rpcport" is they should be unique, starting with 20001 and working up to 20010 (there is no rule for RPCport except that it must be unique, otherwise the node will not start).<br />
<br />
Firewall Changes:<br />
In this section simply expose <br />
sudo ufw allow 10002-10010<br />
sudo ufw allow 40000</div>Adminhttps://wiki.biblepay.org/index.php?title=Building_A_Temple&diff=6931Building A Temple2023-07-08T18:48:09Z<p>Admin: Created page with "A Temple is a collection of 10 Sanctuaries. The first 12 Temples that we Christen will be named after a Tribe of Israel and will receive a special Seal. When you run a temp..."</p>
<hr />
<div>A Temple is a collection of 10 Sanctuaries. The first 12 Temples that we Christen will be named after a Tribe of Israel and will receive a special Seal.<br />
<br />
<br />
When you run a temple you are not only helping the BiblePay network by providing a cluster of Ten Sanctuaries (helping the users sync blocks and conduct instant send transactions), but you also act as a CockroachDB database node within the BiblePay Cockroach Cluster. Your node is entrusted to hold our active Orphan Sponsorship list, orphan expenses, orphan revenue records, Gospel Articles and Content, Gospel Wiki Content, Images hosted on our web site (Unchained.biblepay.org), our Wells project, the active Proposals and Voting records, Phone call transactions, and other database transactions. <br />
<br />
<br />
Note that Temples are rewarded at the same rate as other sanctuaries so the Temple operator is not earning more rewards than the average sanctuary owner, it is more of a community service position.<br />
<br />
<br />
<br />
''' Step 1 - Build a Single BiblePay Node '''<br />
<br />
For clarity, please build your temple as the root user, and build the temple in the folder "/biblepay".<br />
<br />
Rent an Unbuntu 20 VMS from your favorite VMS provider with a minimum of 6 cores, 600gb hard drive and 16gb of ram (these requirements ensure that the temple will not slow down the cockroachdb cluster and will<br />
be able to service the ten sanctuary instances, and most importantly will allow the temple to handle future Video traffic and cache storage for our gospel videos feature and upcoming social media features such as Deliverance <br />
Rooms).<br />
<br />
Follow these instructions to build biblebay:<br />
https://github.com/biblepay/biblepay/blob/master/BuildBiblePay.txt<br />
<br />
If you built biblepay in the /biblepay directory, you should find your biblepayd dameon here:<br />
/biblepay/biblepay/src/biblepayd<br />
If not, you can download the binary from the biblepay web site and copy it here, this way the rest of this guide will match.<br />
<br />
''' Step 2 - Set up 10 Sanctuaries to become a Potential Temple '''<br />
<br />
To be a temple, you will need to override the biblepayd settings with special values that will allow it to write to custom data folders and read custom configuration settings.<br />
For easy maintenance, in this guide I put all of your biblepay block data in /data and all of your biblepay configurations in /configs.<br />
First create a configs directory:<br />
cd /<br />
mkdir /configs<br />
mkdir /data<br />
cd /configs<br />
<br />
nano biblepay1.conf<br />
shrinkdebugfile=1<br />
datadir=/data/biblepay1<br />
masternodeblsprivkey=your_bls_privkey<br />
port=40000<br />
rpcport=20000<br />
<br />
Save the file (ctrl-x, shift-Y, enter)<br />
<br />
Copy this file 10 times to:<br />
biblepay1.conf, biblepay2.conf ... biblepay10.conf<br />
Edit each file and set the following values:<br />
For biblepay1.conf, ensure the port=40000 and the rpcport=20001<br />
For biblepay2.conf, ensure the port=10002 and the rpcport=20002<br />
...<br />
For biblepay10.conf, ensure the port=10010 and the rpcport=20010<br />
Edit the your_bls_privkey with the privkey of the sanctuary that you set up in "EasySanc".<br />
The general rule for the "port" is your first sanc (biblepay1) must have a port of 40000 (this allows outside nodes to find you), but, each successive sanc from sanc2-sanc10 must have a port of 10002-10010 (as other sancs whitelist this port, ports outside of the 100NN range are POSE banned. )<br />
The rule for "rpcport" is they should be unique, starting with 20001 and working up to 20010 (there is no rule for RPCport except that it must be unique, otherwise the node will not start).<br />
<br />
Firewall Changes:<br />
In this section simply expose <br />
sudo ufw allow 10002-10010<br />
sudo ufw allow 40000</div>Adminhttps://wiki.biblepay.org/index.php?title=Free_Phone_Calls_for_New_Users&diff=6930Free Phone Calls for New Users2023-07-04T15:12:29Z<p>Admin: Created page with " BiblePay is giving away 50,000 BBP for free phone calls to our new users! Simply follow these directions: 1. Download the BiblePay Desktop Wallet from here: https://biblepa..."</p>
<hr />
<div><br />
BiblePay is giving away 50,000 BBP for free phone calls to our new users!<br />
<br />
Simply follow these directions:<br />
<br />
1. Download the BiblePay Desktop Wallet from here:<br />
https://biblepay.org/biblepay-win64.exe<br />
<br />
2. Install the Wallet<br />
<br />
3. Launch the wallet and sync the block chain<br />
<br />
4. Sync the wallet (allow the blocks to sync to height 431,000+)<br />
<br />
5. Click on the Unchained button from the left menu (this launches the Unchained Application)<br />
<br />
6. Click on Softphone (this is our built in BBP softphone that allows you to call anywhere in the world!)<br />
Copy your BBP address to the clipboard<br />
<br />
7. Email rob@biblepay.org with your address and he will send you your Free BBP so that you can make long distance phone calls for free.</div>Adminhttps://wiki.biblepay.org/index.php?title=Activate_Hardware_Phone&diff=6929Activate Hardware Phone2023-06-24T18:19:16Z<p>Admin: Created page with "''' How do I get my new telephone (hardware)? ''' Our plan is to support multiple phone models. Our first entry level phone can be purchased on Amazon here: https://www.ama..."</p>
<hr />
<div>''' How do I get my new telephone (hardware)? '''<br />
<br />
Our plan is to support multiple phone models.<br />
<br />
Our first entry level phone can be purchased on Amazon here:<br />
<br />
https://www.amazon.com/Grandstream-Business-Single-account-GXP1610/dp/B01318HLCC/<br />
<br />
<br />
Once you have the phone, unpack it, plug a cat5 network cable from the phone to your LAN jack and turn it on.<br />
<br />
Verify it boots up and obtains an IP address. It will display its IP address on the screen.<br />
<br />
<br />
<br />
<br />
''' How do I provision the phone for the BBP network? '''<br />
<br />
<br />
Navigate a web browser from your home PC to the IP address on the phone.<br />
<br />
For example, if the IP is 192.168.1.2, then go to this web address:<br />
<br />
http://192.168.1.2<br />
<br />
Once there, it will ask you the username and password.<br />
Enter admin for the username<br />
Enter admin for the password<br />
<br />
<br />
To provision the phone, open the unchained application by clicking on Unchained from the BiblePay Core wallet.<br />
<br />
This will open the Unchained app. In that app, click Phone | Hardware Settings.<br />
<br />
You can now find the answers to each of the provision questions by filling in the values presented on the screen.<br />
<br />
You must have more than 10,000 BBP in your phone account to provision your phone (there is no cost associated with this).<br />
<br />
Once you populate the answers into the phone (by filling each of the grid value answers), your phone will move to Registered and display your name.<br />
<br />
Now you can make calls. You can also take your phone with you on vacation, and your phone number will stay with you and you can make calls from any internet jack.</div>Adminhttps://wiki.biblepay.org/index.php?title=BiblePay_Email&diff=6928BiblePay Email2023-06-11T16:47:35Z<p>Admin: </p>
<hr />
<div>''' How to Create a BiblePay E-Mail Account '''<br />
<br />
From Unchained desktop, navigate to E-Mail | E-Mail Maintenance.<br />
<br />
Specify the E-Mail username you would like to use, without the @biblepay.org suffix.<br />
<br />
Click Submit.<br />
<br />
Note that you must have at least 1000 BBP in your unchained wallet.<br />
<br />
Once provisioned, you will immediately see the e-mail client settings that are used to set up the home e-mail client. Now you can set up your home e-mail client (IE Outlook, Mozilla Thunderbird) or your iPhone etc (See below).<br />
<br />
The password for your e-mail account is the private key of your Unchained wallet address (to get the password, type 'dumpprivkey unchained_pub_key' from the command line of the wallet).<br />
<br />
<br />
<br />
<br />
''' How to Set Up BiblePay E-Mail with Thunderbird '''<br />
<br />
From Thunderbird, click on Tools | Account Settings.<br />
<br />
Populate the Account Name and the "Your Name" to be your preferred human readable account names.<br />
<br />
Populate E-Mail address to be your new UserName + @biblepay.org.<br />
<br />
<html><br />
<img src='Https://seven.biblepay.org/img/Thunderbird/Thunder1.png' /><br />
</html><br />
<br />
<br />
<br />
Click Server Settings - Here is where you populate the IMAP settings:<br />
<br />
Populate Server Type = IMAP<br />
<br />
Server Name = seven.biblepay.org<br />
<br />
User Name = Your BBP username @biblepay.org<br />
<br />
Port = 993<br />
<br />
Security = SSL/TLS<br />
<br />
Auth Method = Normal<br />
<br />
<br />
<br />
<br />
<html><br />
<img src='Https://seven.biblepay.org/img/Thunderbird/Thunder2.png' /><br />
</html><br />
<br />
<br />
Click Outgoing Server - this is where you set the SMTP settings:<br />
<br />
Click Add<br />
<br />
Server Name = seven.biblepay.org<br />
<br />
User Name = Your BBP username @biblepay.org<br />
<br />
Port = 465<br />
<br />
Security = SSL/TLS<br />
<br />
Auth Method = Normal<br />
<br />
<br />
<br />
<html><br />
<img src='Https://seven.biblepay.org/img/Thunderbird/Thunder3.png' /><br />
</html><br />
<br />
<br />
<br />
<br />
''' How to Setup BiblePay E-Mail with Outlook '''<br />
<br />
<br />
<br />
<html><br />
<img src='Https://seven.biblepay.org/img/Thunderbird/Outlook1.png' /><br />
</html></div>Adminhttps://wiki.biblepay.org/index.php?title=BiblePay_Email&diff=6927BiblePay Email2023-06-11T16:17:43Z<p>Admin: </p>
<hr />
<div>''' How to Create a BiblePay E-Mail Account '''<br />
<br />
From Unchained desktop, navigate to E-Mail | E-Mail Maintenance.<br />
<br />
Specify the E-Mail username you would like to use, without the @biblepay.org suffix.<br />
<br />
Click Submit.<br />
<br />
Note that you must have at least 1000 BBP in your unchained wallet.<br />
<br />
Once provisioned, you will immediately see the e-mail client settings that are used to set up the home e-mail client. Now you can set up your home e-mail client (IE Outlook, Mozilla Thunderbird) or your iPhone etc (See below).<br />
<br />
<br />
<br />
<br />
<br />
''' How to Set Up BiblePay E-Mail with Thunderbird '''<br />
<br />
From Thunderbird, click on Tools | Account Settings.<br />
<br />
Populate the Account Name and the "Your Name" to be your preferred human readable account names.<br />
<br />
Populate E-Mail address to be your new UserName + @biblepay.org.<br />
<br />
<html><br />
<img src='Https://seven.biblepay.org/img/Thunderbird/Thunder1.png' /><br />
</html><br />
<br />
<br />
<br />
Click Server Settings - Here is where you populate the IMAP settings:<br />
<br />
Populate Server Type = IMAP<br />
<br />
Server Name = seven.biblepay.org<br />
<br />
User Name = Your BBP username @biblepay.org<br />
<br />
Port = 993<br />
<br />
Security = SSL/TLS<br />
<br />
Auth Method = Normal<br />
<br />
<br />
<br />
<br />
<html><br />
<img src='Https://seven.biblepay.org/img/Thunderbird/Thunder2.png' /><br />
</html><br />
<br />
<br />
Click Outgoing Server - this is where you set the SMTP settings:<br />
<br />
Click Add<br />
<br />
Server Name = seven.biblepay.org<br />
<br />
User Name = Your BBP username @biblepay.org<br />
<br />
Port = 465<br />
<br />
Security = SSL/TLS<br />
<br />
Auth Method = Normal<br />
<br />
<br />
<br />
<html><br />
<img src='Https://seven.biblepay.org/img/Thunderbird/Thunder3.png' /><br />
</html><br />
<br />
<br />
<br />
<br />
''' How to Setup BiblePay E-Mail with Outlook '''<br />
<br />
<br />
<br />
<html><br />
<img src='Https://seven.biblepay.org/img/Thunderbird/Outlook1.png' /><br />
</html></div>Adminhttps://wiki.biblepay.org/index.php?title=BiblePay_Email&diff=6926BiblePay Email2023-06-11T15:39:16Z<p>Admin: </p>
<hr />
<div>''' How to Create a BiblePay E-Mail Account '''<br />
<br />
From Unchained desktop, navigate to E-Mail | E-Mail Maintenance.<br />
<br />
Specify the E-Mail username you would like to use, without the @biblepay.org suffix.<br />
<br />
Click Submit.<br />
<br />
Note that you must have at least 1000 BBP in your unchained wallet.<br />
<br />
Once provisioned, you will immediately see the e-mail client settings that are used to set up the home e-mail client. Now you can set up your home e-mail client (IE Outlook, Mozilla Thunderbird) or your iPhone etc (See below).<br />
<br />
<br />
<br />
<br />
<br />
''' How to Set Up BiblePay E-Mail with Thunderbird '''<br />
<br />
From Thunderbird, click on Tools | Account Settings.<br />
<br />
Populate the Account Name and the "Your Name" to be your preferred human readable account names.<br />
<br />
Populate E-Mail address to be your new UserName + @biblepay.org.<br />
<br />
<html><br />
<img src='Https://seven.biblepay.org/img/Thunderbird/Thunder1.png' /><br />
</html><br />
<br />
<br />
<br />
Click Server Settings - Here is where you populate the IMAP settings:<br />
<br />
Populate Server Type = IMAP<br />
<br />
Server Name = seven.biblepay.org<br />
<br />
User Name = Your BBP username @biblepay.org<br />
<br />
Port = 993<br />
<br />
Security = SSL/TLS<br />
<br />
Auth Method = Normal<br />
<br />
<br />
<br />
<br />
<html><br />
<img src='Https://seven.biblepay.org/img/Thunderbird/Thunder2.png' /><br />
</html><br />
<br />
<br />
Click Outgoing Server - this is where you set the SMTP settings:<br />
<br />
Click Add<br />
<br />
Server Name = seven.biblepay.org<br />
<br />
User Name = Your BBP username @biblepay.org<br />
<br />
Port = 465<br />
<br />
Security = SSL/TLS<br />
<br />
Auth Method = Normal<br />
<br />
<br />
<br />
<html><br />
<img src='Https://seven.biblepay.org/img/Thunderbird/Thunder3.png' /><br />
</html></div>Adminhttps://wiki.biblepay.org/index.php?title=BiblePay_Email&diff=6925BiblePay Email2023-06-11T15:36:59Z<p>Admin: </p>
<hr />
<div>''' How to Create a BiblePay E-Mail Account '''<br />
<br />
From Unchained desktop, navigate to E-Mail | E-Mail Maintenance.<br />
<br />
Specify the E-Mail username you would like to use, without the @biblepay.org suffix.<br />
<br />
Click Submit.<br />
<br />
Note that you must have at least 1000 BBP in your unchained wallet.<br />
<br />
Once provisioned, you will immediately see the e-mail client settings that are used to set up the home e-mail client. Now you can set up your home e-mail client (IE Outlook, Mozilla Thunderbird) or your iPhone etc (See below).<br />
<br />
<br />
<br />
<br />
<br />
''' How to Set Up BiblePay E-Mail with Thunderbird '''<br />
<br />
From Thunderbird, click on Tools | Account Settings.<br />
<br />
Populate the Account Name and the "Your Name" to be your preferred human readable account names.<br />
<br />
Populate E-Mail address to be your new UserName + @biblepay.org.<br />
<br />
Https://seven.biblepay.org/img/Thunderbird/Thunder1.png<br />
<br />
<br />
<br />
<br />
Click Server Settings - Here is where you populate the IMAP settings:<br />
<br />
Populate Server Type = IMAP<br />
<br />
Server Name = seven.biblepay.org<br />
<br />
User Name = Your BBP username @biblepay.org<br />
<br />
Port = 993<br />
<br />
Security = SSL/TLS<br />
<br />
Auth Method = Normal<br />
<br />
<br />
<br />
<br />
Https://seven.biblepay.org/img/Thunderbird/Thunder2.png<br />
<br />
<br />
Click Outgoing Server - this is where you set the SMTP settings:<br />
<br />
Click Add<br />
<br />
Server Name = seven.biblepay.org<br />
<br />
User Name = Your BBP username @biblepay.org<br />
<br />
Port = 465<br />
<br />
Security = SSL/TLS<br />
<br />
Auth Method = Normal<br />
<br />
<br />
<br />
Https://seven.biblepay.org/img/Thunderbird/Thunder3.png</div>Adminhttps://wiki.biblepay.org/index.php?title=BiblePay_Email&diff=6924BiblePay Email2023-06-11T15:36:11Z<p>Admin: Created page with "''' How to Create a BiblePay E-Mail Account ''' From Unchained desktop, navigate to E-Mail | E-Mail Maintenance. Specify the E-Mail username you would like to use, without t..."</p>
<hr />
<div>''' How to Create a BiblePay E-Mail Account '''<br />
<br />
From Unchained desktop, navigate to E-Mail | E-Mail Maintenance.<br />
<br />
Specify the E-Mail username you would like to use, without the @biblepay.org suffix.<br />
<br />
Click Submit.<br />
<br />
Note that you must have at least 1000 BBP in your unchained wallet.<br />
<br />
Once provisioned, you will immediately see the e-mail client settings that are used to set up the home e-mail client. Now you can set up your home e-mail client (IE Outlook, Mozilla Thunderbird) or your iPhone etc (See below).<br />
<br />
<br />
<br />
<br />
<br />
''' How to Set Up BiblePay E-Mail with Thunderbird '''<br />
<br />
From Thunderbird, click on Tools | Account Settings.<br />
Populate the Account Name and the "Your Name" to be your preferred human readable account names.<br />
Populate E-Mail address to be your new UserName + @biblepay.org.<br />
<br />
Https://seven.biblepay.org/img/Thunderbird/Thunder1.png<br />
<br />
<br />
<br />
<br />
Click Server Settings - Here is where you populate the IMAP settings:<br />
<br />
Populate Server Type = IMAP<br />
Server Name = seven.biblepay.org<br />
User Name = Your BBP username @biblepay.org<br />
Port = 993<br />
Security = SSL/TLS<br />
Auth Method = Normal<br />
<br />
<br />
Https://seven.biblepay.org/img/Thunderbird/Thunder2.png<br />
<br />
Click Outgoing Server - this is where you set the SMTP settings:<br />
<br />
Click Add<br />
Server Name = seven.biblepay.org<br />
User Name = Your BBP username @biblepay.org<br />
Port = 465<br />
Security = SSL/TLS<br />
Auth Method = Normal<br />
<br />
<br />
Https://seven.biblepay.org/img/Thunderbird/Thunder3.png</div>Adminhttps://wiki.biblepay.org/index.php?title=Red_Sea_User_Guide&diff=6923Red Sea User Guide2023-06-04T17:45:19Z<p>Admin: </p>
<hr />
<div><br />
'''Introduction'''<br />
<br />
BiblePay has moved features away from the web and to the Unchained Desktop Application. The Unchained Desktop App is part of the BiblePay core wallet, however it lives in its own EXE (executable program). It is connected to the wallet through one core-wallet wallet keypair to Unchained Desktop: The key label 'Unchained'. This allows Unchained to provide features such as video tipping, NFT purchases, file storage charges, and the BiblePay Phone System.<br />
<br />
<br />
''' How to associate the Core Wallet with Unchained '''<br />
<br />
When you launch unchained for the first time, the core wallet will automatically provision the 'Unchained' key for you. You will need to send funds to that key in order to spend in Unchained.<br />
<br />
<br />
<br />
''' How To Launch Unchained '''<br />
<br />
Click the Unchained button from the left menu.<br />
<br />
<br />
''' BiblePay Phone System '''<br />
<br />
We are happy to announce the first Blockchain Phone Service. With the BiblePay Phone system, you get a real US phone number attached to your BBP keypair. Our softphone allows you to make and receive phone calls globally from real PSTN phone numbers and to real PSTN phone numbers at an extremely low rate per minute (1.9 cents per minute) for long distance. You can call any country in the world for this low rate. In version 1.0, the phone service works as a softphone where you wear your headset. In version 2.0 (coming soon) you can use a hardware phone as well.<br />
<br />
<br />
''' How do I provision my BiblePay Phone? '''<br />
<br />
1. Launch Unchained Desktop<br />
<br />
2. Verify your Balance is > 5000 BBP<br />
<br />
3. Click on Phone Service<br />
<br />
4. Choose a Phone Region and Area Code.<br />
<br />
5. BiblePay will provide a real phone number.<br />
<br />
6. Make a test call.<br />
<br />
7. Your assigned phone number will always be visible from the Phone Service page.<br />
<br />
<br />
<br />
''' Online Sancs (Active Hosted Sanctuaries/Techies) vs Offline Sancs (Investors) '''<br />
<br />
We have two modes. Online Sancs are designed for enthusiasts who want to host a sanctuary on a VM and earn the full 100% reward.<br />
These sanctuaries actively help the network by ensuring nodes are available to supply blocks, they perform Sanctuary Mining, and they take part in running our Cockroach Database and help host the phone system.<br />
<br />
Offline Sancs (Investor Sancs) are sanctuaries that are always offline. They do not participate in servicing the users, but they do help maintain our price by holding a stake in a sanctuary investment.<br />
<br />
Both types of sancs require the same collateral: 4,500,001 BBP.<br />
<br />
The Online sanc receives a 100% reward while the offline sanc receives a 50% reward.<br />
<br />
<br />
''' How to Create a Sanctuary '''<br />
<br />
Regardless whether you want an Investor sanc or an active sanc, you can follow these instructions to create a new sanc:<br />
<br />
https://wiki.biblepay.org/EasySanc<br />
<br />
Once the sanctuary is running, you will receive a full reward if it is hosted. If it falls into the INVESTOR state you will receive half of the reward.<br />
Note, investors will need to set a key in their biblepay.conf file: revivesanctuaries=1.<br />
This key will cause the biblepay wallet to revive your investor sancs once per day.<br />
You will need to leave the home controller wallet running so that biblepay can revive your sanctuaries. Also, your wallet needs to be unlocked so that BBP can send out a revival transaction.<br />
<br />
<br />
Thank you for Using BiblePay!</div>Adminhttps://wiki.biblepay.org/index.php?title=Red_Sea_User_Guide&diff=6922Red Sea User Guide2023-05-20T17:45:16Z<p>Admin: Created page with " '''Introduction''' BiblePay has moved features away from the web and to the Unchained Desktop Application. The Unchained Desktop App is part of the BiblePay core wallet, ho..."</p>
<hr />
<div><br />
'''Introduction'''<br />
<br />
BiblePay has moved features away from the web and to the Unchained Desktop Application. The Unchained Desktop App is part of the BiblePay core wallet, however it lives in its own EXE (executable program). It is connected to the wallet through one core-wallet wallet keypair to Unchained Desktop: The key label 'Unchained'. This allows Unchained to provide features such as video tipping, NFT purchases, file storage charges, and the BiblePay Phone System.<br />
<br />
<br />
''' How to associate the Core Wallet with Unchained '''<br />
<br />
When you launch unchained for the first time, the core wallet will automatically provision the 'Unchained' key for you. You will need to send funds to that key in order to spend in Unchained.<br />
<br />
<br />
<br />
''' How To Launch Unchained '''<br />
<br />
Click the Unchained button from the left menu.<br />
<br />
<br />
''' BiblePay Phone System '''<br />
<br />
We are happy to announce the first Blockchain Phone Service. With the BiblePay Phone system, you get a real US phone number attached to your BBP keypair. Our softphone allows you to make and receive phone calls globally from real PSTN phone numbers and to real PSTN phone numbers at an extremely low rate per minute (1.9 cents per minute) for long distance. You can call any country in the world for this low rate. In version 1.0, the phone service works as a softphone where you wear your headset. In version 2.0 (coming soon) you can use a hardware phone as well.<br />
<br />
<br />
''' How do I provision my BiblePay Phone? '''<br />
<br />
1. Launch Unchained Desktop<br />
<br />
2. Verify your Balance is > 5000 BBP<br />
<br />
3. Click on Phone Service<br />
<br />
4. Choose a Phone Region and Area Code.<br />
<br />
5. BiblePay will provide a real phone number.<br />
<br />
6. Make a test call.<br />
<br />
7. Your assigned phone number will always be visible from the Phone Service page.<br />
<br />
<br />
<br />
''' Online Sancs (Active Hosted Sanctuaries/Techies) vs Offline Sancs (Investors) '''<br />
<br />
We have two modes. Online Sancs are designed for enthusiasts who want to host a sanctuary on a VM and earn the full 100% reward.<br />
These sanctuaries actively help the network by ensuring nodes are available to supply blocks, they perform Sanctuary Mining, and they take part in running our Cockroach Database and help host the phone system.<br />
<br />
Offline Sancs (Investor Sancs) are sanctuaries that are always offline. They do not participate in servicing the users, but they do help maintain our price by holding a stake in a sanctuary investment.<br />
<br />
Both types of sancs require the same collateral: 4,500,001 BBP.<br />
<br />
The Online sanc receives a 100% reward while the offline sanc receives a 50% reward.</div>Adminhttps://wiki.biblepay.org/index.php?title=Red_Sea_Release&diff=6921Red Sea Release2023-05-13T13:41:39Z<p>Admin: </p>
<hr />
<div>All Glory to God.<br />
<br />
God is responsible for the Architecture of BiblePay, and all Good things come down from our Heavenly Father: the great I AM (Yahweh).<br />
<br />
<br />
Red Sea plans for a strong foundation:<br />
<br />
- The Core Wallet (C++ BiblePayd and C++/QT Wallet) stays pristine so that we can integrate upstream commits and keep the wallet pure, clean, and secure.<br />
* Security means you can always count on the core wallet to provide a secure place (your keys, your balance) for your biblepay.<br />
* Security means our web site code will never maniuplate or read your wallet keys (except one key that we designate as your BBP-Unchained Key).<br />
* Pristine means that we will not pollute the core wallet with UI pages that will break in the future when upstream commits refactor the wallet.<br />
<br />
- Unchained will move to the desktop.<br />
* This means that the cool features that we always wanted to put in the wallet (like the prayer room, BBP chat, Deliverance videoconference rooms, Social Media Timeline) will now be possible<br />
as they will live in our new Desktop Web Pages.<br />
* This opens up the exciting possibility for devs to contribute to make new UI pages without interfering with the c++ core wallet code<br />
* This means security will be improved in unchained because signing will occur on the desktop<br />
* This opens up the possibility for BBP to offer new collaboration apps (IE competition for Basecamp/Zoho)<br />
<br />
<br />
- Unchained Web will lose some features:<br />
* Turnkey Sancs will be retired in favor of Decentralized Offline Sancs<br />
a. If you fund a new sanc and keep it offline you will earn a 50% reward (this replaces portfolio builder and turnkey sancs)<br />
b. If you fund a sanc and keep it online (along with BMS), you receive a 100% reward<br />
* Portfolio Builder will be retired in favor of decentralized Offline Sancs<br />
<br />
- RandomX Mining to be retired:<br />
* RandomX pool mining is going to be retired in favor of Sanctuary Mining<br />
* Sanctuaries mine in a non competetive, deterministic way in the background (consuming low resources)<br />
* This increases the sanctuary reward<br />
* The sanctuary reward goes to both offline sancs and online sancs so we may reward both types of investors (offline sancs get half)<br />
<br />
<br />
- Extra Large Sancs (Temple) <br />
* If you own 10 or more sancs, your node will automatically run an instance of Cockroach DB (A decentralized database).<br />
* This database is used to store our orphan collage, our expenses and our revenue<br />
* In this way we fully dencetralize biblepay 100% so that no party is responsible for any back-end database<br />
* This database also stores the metadata for bio images, the forum, timeline posts, etc.<br />
<br />
<br />
- Decentralized Governance Voting improvements<br />
* It will be possible to vote on configuration changes (IE permission delegation)<br />
* This allows a responsible party to enter a historical accounting record or perform clerical duties<br />
<br />
- BiblePay will have a nice API:<br />
<br />
* The core wallet will have a button on the menu that launches Desktop Unchained<br />
* Desktop Unchained will contain all of the Extra BBP UI<br />
* A back end Biblepay.DLL will be included in our releases which give developers the capability to interface with BBP<br />
(IE upload videos, download files, send money, receive money, etc)<br />
* Our biblepay DLL will eventually become a DLL on NuGet, opening up BBP to thousands of c# developers (Scheduled for Q4 2023)<br />
<br />
- BiblePay moves away from Metamask/ERC-20 Signing Keys:<br />
<br />
* To make Unchained more accessible, we move away from Metamask so that we no longer require the plug-in<br />
* Unchained authenticates by using one Core wallet key (the Unchained Key)<br />
* You can fund your Unchained key by sending BBP to it<br />
* You can spend funds from your Unchained Key by spending it in the Desktop App (Desktop Features will be revealed during the Red Sea Release)<br />
* Because of this, all funds should be withdrawn from unchained.biblepay.org (Remove web wallet funds and remove Turnkey Sanctuaries). You can leave Portfolio Builder balances as those live in the Core Wallet.<br />
<br />
- True decentralized bandwidth is coming to the desktop:<br />
<br />
* Our video player pulls files in parallel from STORJ's 4000+ hard drives and does not use DNS. Since it works in parallel it cannot be ddossed, and it uses IP rather than DNS for the addresses.<br />
If the individual Storj miners are up, our videos are up. We no longer rely on cloudflare for DDOS/CDN.<br />
* Our video uploader will also upload in parallel directly to the STORJ network, and cannot be taken down from conventional DDOS. If StorJ miners are up, we are up.<br />
* Our file attachments also work this way<br />
* Our decentralized balances work across our sancs, not against one public web host.<br />
* Our cockroach decentralized database is up even when some BBP sancs fail. (Storage density is always 3* or more).<br />
* Our web server is truly decentralized. Every BBP user will run their own server.<br />
* Our web pages will be PRIVATE. Meaning that when you sign a transaction it will be done on your machine and not on the web hosts server!<br />
* Now we can offer the ability to write software that competes with Zoho (public collaboration software). This could be a sustainable source of revenue for BBP in the future.<br />
Our software being decentralized will run each instance on the BBP desktop.</div>Adminhttps://wiki.biblepay.org/index.php?title=Red_Sea_Release&diff=6920Red Sea Release2023-05-13T13:41:10Z<p>Admin: </p>
<hr />
<div>All Glory to God.<br />
<br />
God is responsible for the Architecture of BiblePay, and all Good things come down from our Heavenly Father: the great I AM (Yahweh).<br />
<br />
Praise be to Jesus, the Ruach Hakodesh and Yahweh.<br />
<br />
<br />
<br />
Red Sea plans for a strong foundation:<br />
<br />
- The Core Wallet (C++ BiblePayd and C++/QT Wallet) stays pristine so that we can integrate upstream commits and keep the wallet pure, clean, and secure.<br />
* Security means you can always count on the core wallet to provide a secure place (your keys, your balance) for your biblepay.<br />
* Security means our web site code will never maniuplate or read your wallet keys (except one key that we designate as your BBP-Unchained Key).<br />
* Pristine means that we will not pollute the core wallet with UI pages that will break in the future when upstream commits refactor the wallet.<br />
<br />
- Unchained will move to the desktop.<br />
* This means that the cool features that we always wanted to put in the wallet (like the prayer room, BBP chat, Deliverance videoconference rooms, Social Media Timeline) will now be possible<br />
as they will live in our new Desktop Web Pages.<br />
* This opens up the exciting possibility for devs to contribute to make new UI pages without interfering with the c++ core wallet code<br />
* This means security will be improved in unchained because signing will occur on the desktop<br />
* This opens up the possibility for BBP to offer new collaboration apps (IE competition for Basecamp/Zoho)<br />
<br />
<br />
- Unchained Web will lose some features:<br />
* Turnkey Sancs will be retired in favor of Decentralized Offline Sancs<br />
a. If you fund a new sanc and keep it offline you will earn a 50% reward (this replaces portfolio builder and turnkey sancs)<br />
b. If you fund a sanc and keep it online (along with BMS), you receive a 100% reward<br />
* Portfolio Builder will be retired in favor of decentralized Offline Sancs<br />
<br />
- RandomX Mining to be retired:<br />
* RandomX pool mining is going to be retired in favor of Sanctuary Mining<br />
* Sanctuaries mine in a non competetive, deterministic way in the background (consuming low resources)<br />
* This increases the sanctuary reward<br />
* The sanctuary reward goes to both offline sancs and online sancs so we may reward both types of investors (offline sancs get half)<br />
<br />
<br />
- Extra Large Sancs (Temple) <br />
* If you own 10 or more sancs, your node will automatically run an instance of Cockroach DB (A decentralized database).<br />
* This database is used to store our orphan collage, our expenses and our revenue<br />
* In this way we fully dencetralize biblepay 100% so that no party is responsible for any back-end database<br />
* This database also stores the metadata for bio images, the forum, timeline posts, etc.<br />
<br />
<br />
- Decentralized Governance Voting improvements<br />
* It will be possible to vote on configuration changes (IE permission delegation)<br />
* This allows a responsible party to enter a historical accounting record or perform clerical duties<br />
<br />
- BiblePay will have a nice API:<br />
<br />
* The core wallet will have a button on the menu that launches Desktop Unchained<br />
* Desktop Unchained will contain all of the Extra BBP UI<br />
* A back end Biblepay.DLL will be included in our releases which give developers the capability to interface with BBP<br />
(IE upload videos, download files, send money, receive money, etc)<br />
* Our biblepay DLL will eventually become a DLL on NuGet, opening up BBP to thousands of c# developers (Scheduled for Q4 2023)<br />
<br />
- BiblePay moves away from Metamask/ERC-20 Signing Keys:<br />
<br />
* To make Unchained more accessible, we move away from Metamask so that we no longer require the plug-in<br />
* Unchained authenticates by using one Core wallet key (the Unchained Key)<br />
* You can fund your Unchained key by sending BBP to it<br />
* You can spend funds from your Unchained Key by spending it in the Desktop App (Desktop Features will be revealed during the Red Sea Release)<br />
* Because of this, all funds should be withdrawn from unchained.biblepay.org (Remove web wallet funds and remove Turnkey Sanctuaries). You can leave Portfolio Builder balances as those live in the Core Wallet.<br />
<br />
- True decentralized bandwidth is coming to the desktop:<br />
<br />
* Our video player pulls files in parallel from STORJ's 4000+ hard drives and does not use DNS. Since it works in parallel it cannot be ddossed, and it uses IP rather than DNS for the addresses.<br />
If the individual Storj miners are up, our videos are up. We no longer rely on cloudflare for DDOS/CDN.<br />
* Our video uploader will also upload in parallel directly to the STORJ network, and cannot be taken down from conventional DDOS. If StorJ miners are up, we are up.<br />
* Our file attachments also work this way<br />
* Our decentralized balances work across our sancs, not against one public web host.<br />
* Our cockroach decentralized database is up even when some BBP sancs fail. (Storage density is always 3* or more).<br />
* Our web server is truly decentralized. Every BBP user will run their own server.<br />
* Our web pages will be PRIVATE. Meaning that when you sign a transaction it will be done on your machine and not on the web hosts server!<br />
* Now we can offer the ability to write software that competes with Zoho (public collaboration software). This could be a sustainable source of revenue for BBP in the future.<br />
Our software being decentralized will run each instance on the BBP desktop.</div>Adminhttps://wiki.biblepay.org/index.php?title=Red_Sea_Release&diff=6919Red Sea Release2023-04-02T21:03:00Z<p>Admin: </p>
<hr />
<div>All Glory to God.<br />
<br />
God is responsible for the Architecture of BiblePay, and all Good things come down from our Heavenly Father: the great I AM (Yahweh).<br />
<br />
Praise be to Jesus, the Ruach Hakodesh and Yahweh.<br />
<br />
Our goal for the Red Sea Release is to organize BiblePay into it's proper and clear and logical demarcation points so that we can maintain it and build on a strong decentralized foundation.<br />
<br />
As you know things have shifted around while we "feel out" what is best, but only truth stands, and that comes from God.<br />
<br />
Red Sea plans for a strong foundation:<br />
<br />
- The Core Wallet (C++ BiblePayd and C++/QT Wallet) stays pristine so that we can integrate upstream commits and keep the wallet pure, clean, and secure.<br />
* Security means you can always count on the core wallet to provide a secure place (your keys, your balance) for your biblepay.<br />
* Security means our web site code will never maniuplate or read your wallet keys (except one key that we designate as your BBP-Unchained Key).<br />
* Pristine means that we will not pollute the core wallet with UI pages that will break in the future when upstream commits refactor the wallet.<br />
<br />
- Unchained will move to the desktop.<br />
* This means that the cool features that we always wanted to put in the wallet (like the prayer room, BBP chat, Deliverance videoconference rooms, Social Media Timeline) will now be possible<br />
as they will live in our new Desktop Web Pages.<br />
* This opens up the exciting possibility for devs to contribute to make new UI pages without interfering with the c++ core wallet code<br />
* This means security will be improved in unchained because signing will occur on the desktop<br />
* This opens up the possibility for BBP to offer new collaboration apps (IE competition for Basecamp/Zoho)<br />
<br />
- Unchained Web will lose some features:<br />
* Turnkey Sancs will be retired in favor of Decentralized Offline Sancs<br />
a. If you fund a new sanc and keep it offline you will earn a 50% reward (this replaces portfolio builder and turnkey sancs)<br />
b. If you fund a sanc and keep it online (along with BMS), you receive a 100% reward<br />
* Portfolio Builder will be retired in favor of decentralized Offline Sancs<br />
<br />
- RandomX Mining to be retired:<br />
* RandomX pool mining is going to be retired in favor of Sanctuary Mining<br />
* Sanctuaries mine in a non competetive, deterministic way in the background (consuming low resources)<br />
* This increases the sanctuary reward<br />
* The sanctuary reward goes to both offline sancs and online sancs so we may reward both types of investors (offline sancs get half)<br />
<br />
<br />
- Extra Large Sancs (Temple) <br />
* If you own 10 or more sancs, your node will automatically run an instance of Cockroach DB (A decentralized database).<br />
* This database is used to store our orphan collage, our expenses and our revenue<br />
* In this way we fully dencetralize biblepay 100% so that no party is responsible for any back-end database<br />
* This database also stores the metadata for bio images, the forum, timeline posts, etc.<br />
<br />
- Decentralized Governance Voting improvements<br />
* It will be possible to vote on configuration changes (IE permission delegation)<br />
* This allows a responsible party to enter a historical accounting record or perform clerical duties<br />
<br />
- BiblePay will have a nice API:<br />
<br />
* The core wallet will have a button on the menu that launches Desktop Unchained<br />
* Desktop Unchained will contain all of the Extra BBP UI<br />
* A back end Biblepay.DLL will be included in our releases which give developers the capability to interface with BBP<br />
(IE upload videos, download files, send money, receive money, etc)<br />
* Our biblepay DLL will eventually become a DLL on NuGet, opening up BBP to thousands of c# developers (Scheduled for Q4 2023)<br />
<br />
- BiblePay moves away from Metamask/ERC-20 Signing Keys:<br />
<br />
* To make Unchained more accessible, we move away from Metamask so that we no longer require the plug-in<br />
* Unchained authenticates by using one Core wallet key (the Unchained Key)<br />
* You can fund your Unchained key by sending BBP to it<br />
* You can spend funds from your Unchained Key by spending it in the Desktop App (Desktop Features will be revealed during the Red Sea Release)<br />
* Because of this, all funds should be withdrawn from unchained.biblepay.org (Remove web wallet funds and remove Turnkey Sanctuaries). You can leave Portfolio Builder balances as those live in the Core Wallet.<br />
<br />
- True decentralized bandwidth is coming to the desktop:<br />
<br />
* Our video player pulls files in parallel from STORJ's 4000+ hard drives and does not use DNS. Since it works in parallel it cannot be ddossed, and it uses IP rather than DNS for the addresses.<br />
If the individual Storj miners are up, our videos are up. We no longer rely on cloudflare for DDOS/CDN.<br />
* Our video uploader will also upload in parallel directly to the STORJ network, and cannot be taken down from conventional DDOS. If StorJ miners are up, we are up.<br />
* Our file attachments also work this way!<br />
* Our decentralized balances work across our sancs, not against one public web host.<br />
* Our cockroach decentralized database is up even when some BBP sancs fail. (Storage density is always 3* or more).<br />
* Our web server is truly decentralized. Every BBP user will run their own server.<br />
* Our web pages will be PRIVATE. Meaning that when you sign a transaction it will be done on your machine and not on the web hosts server!<br />
* Now we can offer the ability to write software that competes with Zoho (public collaboration software). This could be a sustainable source of revenue for BBP in the future.<br />
Our software being decentralized will run each instance on the BBP desktop.</div>Adminhttps://wiki.biblepay.org/index.php?title=Red_Sea_Release&diff=6918Red Sea Release2023-04-02T20:47:14Z<p>Admin: </p>
<hr />
<div>All Glory to God.<br />
<br />
God is responsible for the Architecture of BiblePay, and all Good things come down from our Heavenly Father: the great I AM (Yahweh).<br />
<br />
Praise be to Jesus, the Ruach Hakodesh and Yahweh.<br />
<br />
Our goal for the Red Sea Release is to organize BiblePay into it's proper and clear and logical demarcation points so that we can maintain it and build on a strong decentralized foundation.<br />
<br />
As you know things have shifted around while we "feel out" what is best, but only truth stands, and that comes from God.<br />
<br />
Red Sea plans for a strong foundation:<br />
<br />
- The Core Wallet (C++ BiblePayd and C++/QT Wallet) stays pristine so that we can integrate upstream commits and keep the wallet pure, clean, and secure.<br />
* Security means you can always count on the core wallet to provide a secure place (your keys, your balance) for your biblepay.<br />
* Security means our web site code will never maniuplate or read your wallet keys (except one key that we designate as your BBP-Unchained Key).<br />
* Pristine means that we will not pollute the core wallet with UI pages that will break in the future when upstream commits refactor the wallet.<br />
<br />
- Unchained will move to the desktop.<br />
* This means that the cool features that we always wanted to put in the wallet (like the prayer room, BBP chat, Deliverance videoconference rooms, Social Media Timeline) will now be possible<br />
as they will live in our new Desktop Web Pages.<br />
* This opens up the exciting possibility for devs to contribute to make new UI pages without interfering with the c++ core wallet code<br />
* This means security will be improved in unchained because signing will occur on the desktop<br />
* This opens up the possibility for BBP to offer new collaboration apps (IE competition for Basecamp/Zoho)<br />
<br />
- Unchained Web will lose some features:<br />
* Turnkey Sancs will be retired in favor of Decentralized Offline Sancs<br />
a. If you fund a new sanc and keep it offline you will earn a 50% reward (this replaces portfolio builder and turnkey sancs)<br />
b. If you fund a sanc and keep it online (along with BMS), you receive a 100% reward<br />
* Portfolio Builder will be retired in favor of decentralized Offline Sancs<br />
<br />
- RandomX Mining to be retired:<br />
* RandomX pool mining is going to be retired in favor of Sanctuary Mining<br />
* Sanctuaries mine in a non competetive, deterministic way in the background (consuming low resources)<br />
* This increases the sanctuary reward<br />
* The sanctuary reward goes to both offline sancs and online sancs so we may reward both types of investors (offline sancs get half)<br />
<br />
<br />
- Extra Large Sancs (Temple) <br />
* If you own 10 or more sancs, your node will automatically run an instance of Cockroach DB (A decentralized database).<br />
* This database is used to store our orphan collage, our expenses and our revenue<br />
* In this way we fully dencetralize biblepay 100% so that no party is responsible for any back-end database<br />
* This database also stores the metadata for bio images, the forum, timeline posts, etc.<br />
<br />
- Decentralized Governance Voting improvements<br />
* It will be possible to vote on configuration changes (IE permission delegation)<br />
* This allows a responsible party to enter a historical accounting record or perform clerical duties<br />
<br />
- BiblePay will have a nice API:<br />
<br />
* The core wallet will have a button on the menu that launches Desktop Unchained<br />
* Desktop Unchained will contain all of the Extra BBP UI<br />
* A back end Biblepay.DLL will be included in our releases which give developers the capability to interface with BBP<br />
(IE upload videos, download files, send money, receive money, etc)<br />
* Our biblepay DLL will eventually become a DLL on NuGet, opening up BBP to thousands of c# developers (Scheduled for Q4 2023)<br />
<br />
- BiblePay moves away from Metamask/ERC-20 Signing Keys:<br />
<br />
* To make Unchained more accessible, we move away from Metamask so that we no longer require the plug-in<br />
* Unchained authenticates by using one Core wallet key (the Unchained Key)<br />
* You can fund your Unchained key by sending BBP to it<br />
* You can spend funds from your Unchained Key by spending it in the Desktop App (Desktop Features will be revealed during the Red Sea Release)<br />
* Because of this, all funds should be withdrawn from unchained.biblepay.org (Remove web wallet funds and remove Turnkey Sanctuaries). You can leave Portfolio Builder balances as those live in the Core Wallet.</div>Admin