[ANN] [Sapphire] [SFRX] [POW] sidechain [DEX] with quantum swaps 5 sec BTC

I have not posted on here in quite some time because of development. I have some exciting news as Sapphire nears a public launch about what we call QUANTUM SWAPS (internally I call it '5 second bitcoin'). First some quick background on the project in case you never heard of this before:

We over at EGEM did a fair launch ETH clone with no ICO and used that platform to add the integrated subchain called Sapphire or SFRX. SFRX was devised to be dual mineable with EGEM (ethash) using blake2s. While the original idea of Sapphire was to harness the power of a relationship with the parent chain (EGEM) on a per block basis and store data on chain, I realized fairly quickly that we needed some more immediate market appeal. All the while I knew because of a previous project that this relationship would eventually prove valuable. So, we will get back to that relationship and its use when in production and show the long-term value proposition of EGEM and Sapphire as a mate. The initial coming out of the gate benefit of this is enhanced 51% protection with the pair. EGEM also uses Pirl guard natively to protect against this type of an attack, so that is why I say "enhanced." For early adopters of EGEM I added an airdrop at block 1530000 of 2 SFRX to 1 EGEM to get some market proliferation.

I added a DEX - a TRUE Decentralized Exchange - to Sapphire. Sapphire blocks support something other chains do not... the accounts support multiple currencies native to the chain. (yes someone can ICO and even make it mineable but we can talk about that later) Therefore a transaction from one party to another party does not just contain an amount of value it also contains a ticker much like an exchange. Unlike an exchange (except maybe for platforms like bitshares) the transactions are posted on the blockchain. Well, the hurdle here was to have a one source wallet, because I agree with ease of use. Crypto is fantastic for a software engineer or technical tinker party like a gamer, but can your grandma eventually learn to use it with a private key? What about when she wants to buy 2 coins? So, I always liked the Ethereum platform basics and EGEM was built from that so I started with the EGEM (and Ethereum clone) wallet. You use this wallet for sapphire. I use the EGEM Wallet to move funds on sapphire and any EGEM (or even an ETH) account would work for this purpose. Since EGEM is supported on Trezor and Ledger hardware wallets you may use your device to unlock the account but transfer of funds at this time requires use of a Sapphire wallet in conjunction with your devices. Everything happens on the client state just like an offline transaction and you post signed transactions to the chain. This is just basic crypto stuff. In the Sapphire version of the new Opal wallet (which is called OpalGem) there is a panel for a dex. There is a panel for sapphire balances that would look like an exchange backend account, and there is a panel for EGEM on EGEM.

So, I had no problem getting funds to transfer and prove the transaction in a Patricia Merkle Trie set up like Eth does. There are still some finishing touches in this area for speed and reliability at go time. But then I started working on how to get bitcoin and other currencies onto the Sapphire platform. I began working toward the Lightning Network protocols and Hash Time Lock Contract payment channels, etc. I soon devised a bitcoin wallet that is native to your Sapphire Opal Gem wallet and allows you to use it with the EGEM account. An easy way to say this is that when you unlock the account with an EGEM private key there is a bitcoin address derived from it that you also control, in fact there are 2. I tinkered with creating an HTLC and combinations of stored unspent transaction outputs where you end up rewriting the destination or using a secret. The idea was that using this approach you could "deposit" BTC (or other similar coins) into your EGEM Sapphire derived BTC address as an HTLC and trade the unspents on the exchange with the whole redeem script idea and you guys know the Alice and Bob scenarios if you are a LN fan. Quick note: if I require the owner of the funds to be online during the trade time I could stop here because I already solved that puzzle, but we want to be able to post a trade and walk away… so thus it became a little more complex. We also control the keys for these “deposits” in such a way that if can be proven to the trustless environment during this transaction cycle. I got this to work in a creative way with a pairing of USTXO in a function that rewrote the unposted pair for a new destination over and over but keep in mind how many fees are involved and what if someone divides your bitcoin? Now you are rewriting multiple unspents…and it works but its sloppy, onerous, complex…but necessary. Inevitably we are going to end up dealing with this scenario on chain so consider the work in this part of my solution added to what I describe below. As satoshis are broken up into other transactions what we end up with is a fee being assessed to the “first withdrawal” at which time a signed transaction has to be posted to the chain. Until that moment we have the capability of producing a lot of scenarios using our confirmed funds in an address we control. For the rest of this post I am going to focus on this part of the equation, because that also became the trick – how to generate this address and control it while also keeping a level of not owning it for transfers sake in the equation. My solution to bitcoin transfers quickly became one of two things – store and trade unspents in HTLC and payment channels or trade the address and accounts that held confirmed unspents. In either scenario when a user needs to withdraw from the sapphire controlled environment there is a posting to the chain and a fee. Provided a user holds their funds in the sapphire deposit situation, even though those funds are proven and confirmed on the BTC chain, we can avoid posting unspents back to the chain and even can work with accounts like as in bitcoin core. There is, however, one other way to do this and that is to break up the deposit into several smaller receiving addresses and to use those smaller collective amounts of satoshis as a group. Remember, we are dealing with software here – this part is easy. So, as with anything the solution to this problem is to think ahead.

Now, keep in mind my end goal was not to create new nodes on another network, as we already have nodes on EGEM and Sapphire. So I already have our own "network" and we are shooting for a 4 to 6 second blocktime which has been near impossible. But it is fast. So this is where I get a "5 second bitcoin" from. Bitcoin is just the long pole in the tent. Everything transfers in "5 seconds" - or more appropriately as fast as we can make sapphire stable. The goal is 5 seconds and that keeps up in testing right now. I use bitcoin as an example because if bitcoin works then everything should work. What is the actual goal?

Deposit bitcoin onto sapphire in such a way that you hold the keys, but can trade it or send it on sapphire and the end destination can pull those BTC anywhere they want verifying that they alone now own the keys….in the standard Sapphire transfer time of “5 seconds” and while remaining decentralized trustless with proven transactions
Regardless, there is still the initial transfer to a wallet we can prove holds the funds in a decentralized trust method on Sapphire. So, the first thirty minutes is existent. It is after that where I want to either post it as a trade or send it to another sapphire recipient and for that destination to have the option on what to do with the bitcoin because they now control it and I do not and can prove that. The withdrawal can, depending upon how its done, be transaction fee free and take little time OR will take the same 30 minutes because it requires a posting to the chain. Remember we are calculating this in advance by dividing our “deposit” (which is just a transaction) into small tradeable amounts each in an address we control (but in this case in such a way that we can transfer it).
I searched long and hard for a way to post a secret on a public space (on chain) and have it be proven out somehow. Even ETH contracts do not have a private data section where this is possible. Yet I did figure out that a node can provide a secret area of memory if it is not on that node. Therefore, I devised, and then subsequently tested, a way for nodes to host “secret safes” for accounts. They have to be encrypted and formed in memory that cannot be dumped to get at the contents so that means even during the creation cycle. The key is to have those secret safes operate much like an on chain contract where you can control what’s in it and actions out of it (such as sign a transaction that proves ownership) but do not actually have the physical private ley in hand for one reason – you want to be able to transfer that ownership to someone else. Yet, having your EGEM and Sapphire BTC accounts embedded in that relationship in such a way that you can actually sign transaction with those accounts private keys that translate to a signed transaction inside the secret safe – which can then be posted publicly to the chain. The result is a signed transaction from the wallet holding the funds that proves you own the wallet. Anyone looking at the open source implementation on how this is done will see you have no way of extracting the private key to that account but that you have complete control to use it – albeit in conjunction with an on chain transaction if you so choose. They will see that account ownership is proved on chain. They will see that if you send in the right signed transaction to transfer ownership that the new owner has ben transferred control and you do not have it anymore. You can prove it. And of course, an end recipient can eventually use WIF or some other method to import that private key into their own account as a withdrawal thus avoiding an exit fee – or they can simply exit to an exchange or outside bitcoin wallet and spend a fee for that final spend as is customary on bitcoin.

Typical of any systems engineer I broke these things down into steps and made each step work before stating I could do it. As a RELATIONAL DATABSE information systems engineer, I approached crypto as a step by step procedure for getting data to be secured in my online ledger database (the chain) and procedurally update to secure my end result. I got the peer node to send me my first live bitcoin address in one of these transactions today. There is still some work left to do but I will be presenting a video evidence soon (within a week of this post I would say). What I will show is a deposit to one of those BTC addresses that then is transferred on the network and offloaded to a wallet. On testnet of course.
Please feel free to get excited, comment positively or negatively, mock me, get skeptical, or whatever. I believe I outlined all the concepts you would need to prove what I am doing above.

Some updates on the chain in general…

The sapphire chain is holding stable in my recent tests with the internal team and starting to scale. There are a couple use cases that need to be enforced on the weighted sync and hash confirmation of other peers / nodes running code. The exchange protocol works well for buy side orders placed after a sell has posted (either in the current or previous blocks) and I am currently replicating the logic from the buy side order processing. Orders process on the chain from the db. This may prove to be a weakness at scale, but it has not proven so when testing a lot of traffic in our dev shop so far. Visual design needs to catch up with functional. The mobile app worked (and I posted shots on our discord) for sending of txs from one use to another using a cellphone connected directly to a node. There are half a dozen other small items but the chain is looking beautiful and works.
I am looking for support to take this to the next level. The easiest way to participate is to get into EGEM at our EGEM discord posted on the front page (or at egem.io). I will post on the EGEM ANN the information about how we work in conjunction with EGEM and SFRX chain and the benefits of this relationship soon. That is really something not to miss.

Please don’t hold it against me if it takes me a minute to reply to a post on here… I am aggressively finishing the development of this product. You can find me on twitter or on the EGEM discord or someone will track me down to reply if you do.