Topic: [ANN] [Sapphire] [SFRX] [POW] sidechain [DEX] with quantum swaps 5 sec BTC (Read 2473 times)

From the mind of one into the hands of many. This will come

Ok, wow, thanks, that was excatly what i wanted to confirm. If this goes live this truly game changing. Thanks again for the well-written answer and im looking forward to that article and of course final product  my mind is a bit blown to be honest.

This is great, real defi solution. I don't know why market does not appreciate your works.

Wrapped BTC is not BTC but a substitute for BTC that requires you to get it from the wrapped source right?

"wBTC is a BTC-backed ERC20 token. Each wBTC in circulation is backed 1:1 by Bitcoin and is held in cold storage by BitGo, the first qualified custodian purpose-built for storing digital assets"

that is the quote from https://coinlist.co/asset/wrapped-bitcoin?gclid=Cj0KCQjw-af6BRC5ARIsAALPIlUIDv2SlDLejgxGfOnjXci3g7rjw42lPekMmmBMe3_pbLj6G0apUIgaAvbeEALw_wcB

so sure you can send it to another party as fast as the blockchain it is wrapped on, but then when you want to withdraw that BTC to your BTC wallet or the receiver wants to spend it as BTC they have to wait 30 minutes (3 confirms) for the "unwrap" of that WBTC to get their actual BTC in their BTC wallet on the BTC chain and pay a fee. (I' not even going to talk about the part where its held by a custodian of sorts)

Now let's compare and contrast that to the 5 second BTC idea. The 5 second BTC idea follows this principle in life:

"own nothing and control everything"

so what that means is you actually don't have ownership of the BTC private key but it is stored in such a way that you control it with your EGEM account. So what good is that? Well, you could sign a transaction that sends that BTC to any BTC wallet you want to and it happens because you control access to that private key even though you don't have it in your possession. Okay so great we can send some BTC using a wrapped wallet that listens to our EGEM private key. What good is that?

so the next principle in your answer is this:

"Make that control transferable in part or whole"

So, that means you have another option with your BTC is you can transfer control of that BTC to another party in whole or part. This means you can prove that you don't have access to that BTC pk any more with your egem wallet and someone else (whoever you transferred it to) does. And the whole or part means they have access to the unspent satoshis they own, because you might only be transferring half of your stash to them on BTC.  So its not even just control but specific control of the parts that make up the BTC. Using this approach a transfer is instant when its recorded so as long as you can use the next principle I am going to mention (below) you can transfer as fast as the host block chain can record that transfer which iin our case is a goal of 5 seconds. You did not have to move the bitcoin to have the new owner get real bitcoin on the real bitcoin chain in their wallet and pretty much that is immediately done. The receiver has full control over this bitcoin to send it wherever they want and they did not have to wait for any confirms on the BTC block chain, they can prove that the balance is there on the BTC block chain and that they own it, so that is a real BTC transfer of ownership in almost an immediate (in this case 5 second) event.

So then what is that last principle?

"Post and Prove it in the wide open on chain public"

This is where sapphire chain comes in because you have the ability(and the person you are trading with or transferring to has the ability) to run functions that prove publicly that you dont have the private key for the BTC you traded them and that they do not have it either but that they control it and you don't.

And, finally we do this by using native functionality to the block chain which is this: signed messages. It works since beginning of time, just ask Craig Wright about the ability to fake a signed message from a BTC address. He could not do it on bitcoin and he can't do it on a respectable block chain. So this is the accepted standard for proof of ownership.

This snippets are from an upcoming article I will eventually ffinish and post called "How to start a truly decentralized bank on EGEM" and it deals specifically with why this is the method I chose to implement transfers.

Sapphire is truly decentralized on chain experience and we are getting close. If you like what you read, please come to discord.egem.io and find the #sfrx-chat channel and stop by. We have a GPU miner starting to show in tests and the chain is getting close to an initial fielding. This is after over two years of work. We are not fly by nighters, but are going to be working on this until it goes live. You have a chance to participate in it with us at egem.io and see all the other stuff we have as part of this ecosystem including nodes and bot interaction, mining on older GPUs, a great eth core, a multi currency mobile wallet, and more.

Egem sapphire, once it is done it will make a lot of frowns, and make people think why they didn't do a real job looking for real potential projects with actual use cases

Great updates! Whats the difference from a wrapped BTC and a 5 sec BTC transfer with Egem Sapphire? Do you send a real BTC in 5 seconds?
thanks again. cheers

https://myegemwallet.com/ not works.
which wallet can i access SFRX ?

and when will the launch mainnet?

Thanks for exciting update again, 2 years of progress and even fud and still there is ethergem going forward getting better and better, thanks for the great update

This is what a tx looks like from the miner (Quarry-Miner-Alpha-0.0.1)

This is the receiver balance on Egem Opal Mobile wallet (see previous post for links)

There were three nodes up when this was done and the localhost version of the node received the tx and balance on explorer correct

will be updating this post with more...

Here is the second transaction on youtube:

https://www.youtube.com/watch?v=y43NzZPSfzg

and then mined a few blocks to get the senders address with enough funds to cover... during testing I allow credit on balances (negatives) and have small mining reward to simulate later on in life of chain

https://www.youtube.com/watch?v=4-LQxAKjqwU

From an email regarding recent releases of mobile wallet and sapphire...

Sorry for the late reply. I was working through some early bugs in my beta release wallet.

https://wiki.egem.io/egemwallet

Here is a link to the current apk which does EGEM LTC BTC BTCtestnet ETH PIRL ETHO and our own egem test trading token ETTT. It also does my internal coin sapphire but it's hidden in this release because its just starting to work.

I don't have a lot of documentation for you yet, but one of the guys did two write ups...

https://gitlab.com/ethergem/egem-mobile/-/blob/master/EGEM_wallet_back_up.docx

(if you take the backup of the slide up secrets and paste it into a file that you save locally before you use your wallet it is best)

https://gitlab.com/ethergem/egem-mobile/-/blob/master/EGEM_wallet_use.docx   

and here is the youtube channel with videos.

https://www.youtube.com/channel/UCZIw0AWMZPSbgLfjNNMS_6g?view_as=subscriber 

We are telling everyone to be careful with large funds in any of these wallets until we get some road miles on usage. You can certainly use these for creating addresses and using them, but might want to seek a more secure storage mechanism if you are holding large funds for a long period of time. I might make a more hardware wallet maker that runs locally and allows you to keep storage funds off the grid. Technically, all the wallets made in the mobile app never leave the app. However, they are stored locally in the app storage and in memory while its being used. It's as safe as anything you use on a computer. If the computer itself (your phone) gets compromised then it can be an issue - although - even with me having the ownership of my phone I cant find where the storage is as a user of the phone, so maybe its safer then I give it credit for. I can't even hack it unless I use the app itself and I don't know that there are any hackers using the compromised devices on mobile. Anyway, it passes security checks when they run, and the underlying security is from google libraries which I am pretty sure isolate themselves to the application backend (i.e. making it extremely safe). I just would like to do more proper penetration testing before going mainstream with big funds.

If you ask me, would I use these wallets myself? Yes. For larger funds I might just transfer enough into one of these wallets to get a transaction done or a trade though. For long term storage I (as well as anyone else) is extremely paranoid and that means a process that is easier to read about with some searches. But, the end idea is I am designing this wallet for everyday use and at the merchant and to exchange with various mechanisms. So, to that end, I love this wallet for usage and feel it has great potential as crypto starts to go up now in a bull market.

ETH and LTC are low cost with high potential. Both are on the mobile wallet. EGEM is extremely low cost and going up...

egem.io

Good luck and lets talk soon.

After a little bit of a rebuilding period SFRX development is back on. Some of the concepts in using crypto are advanced to even me as a developer and take some time to work though. One of the things I had issues with in the previous almost release was I tried to make my own Patricia Merkle Trie type structure without studying why it was used that way in ETH. I also couldn't figure out how to use it before in my code on two different peers and ended up giving up and creating my own blend of the concept, a KV db, and a peer hash based on checkpoints that kind of worked but not so well as I thought it would. Let's just say there is room for error in calculating hashes on patterns and especially if you use a reduced data set on that pattern in every peer evaluating the hash on the same set of transaction each block and the blocks are empty. I could have figured that part out but the filesize for this tree substitute was getting kind of heavy also. Now, ETH is a heavy ass chain (large file size) so maybe this isn't the best evaluator.

Just to close that thought from above I used the PMT in the new version of sapphire and its easier to sync now. There are other improvements for managing the peers, but let's continue talking about ETH...

I think most of ETH heaviness, though, is more related to a 15 second or less block time average and I mean look at all you can do on the block. I love using an ethereum clone as a base for sapphire. It makes it so easy to use the address and signature capabilities of legacy chains and merge them into a product. I mean, by definition, that means cross chain functionality. If the functionality on the legacy chain will also work on your chain then it works "cross chain" in some regard once you figure out the link between the chains. Embed the "link" into your own chain and you create the link. Embed the functionality from multiple other currencies and you extend that relationship to all those chains. Since at least one of them (Eth) and now even other's like BCH, give you the ability to release your own currencies in the form of tokens you have a powerhouse concept. So, this is where my brain goes on Sapphire. I don't care how long it takes me to make it, it's fun to work on.

Anyway the multi currency capability I started with is using an Ethereum address to generate a bitcoin address and then you have one private key and two chain public keys. I mean this is a "derived wallet" in a way. I only use a sub set of the Ethereum private key and I know there are some pre deterministic features of that combination (like people have names wallets that start with a combination of characters extending so far into the public key address that it gives the ability to make the name - that means some of the pk can be figured out...). The other potential weakness is I derive a bitcoin public key from the ethereum private key which makes a public ethereum address too. If you make enough of these combination of addresses and evaluate the public key discrepancies could a patter be figured out that can reverse engineer to the ethereum private key used to make a public bitcoin address? I doubt it - I think even if it was it would have to use both every time in the calculation, and also I think it violates one of the rules of a certain type of cryptographic fundamental.   That fundamental is something like if you hash two different inputs the output is different enough that there is not a pattern to identify the input.

So, I am putting some of the functions on the mobile wallet for now as I finish up sapphire. You can check it out on youtube or at our discord. The mobile wallet sends a bunch of coins with one pk and one of those coins is our own internal token set ETTT (Egem Test Trading Token) and ETT (Egem Trading Token). We are always at discord.egem.io

discord has been getting some good updates recently.

This needs to be brought to light!!

Hey guys... I've been working shoulder to shoulder with Osoese ever since we saved XBI from the previous dev exited the project and scammed everyone. In all the time I've known him, he's always been clear about Sapphire being his priority. I've seen the code and I've been testing it for almost a year now. It's over 25k lines of code that is original, something you don't usually see in crypto this days. Let that sink in for a while. Most block-chains today are a copy or a cropped derivative of an ancient technology that has been massaged and handled by thousands of developers over the past decade. That's why everyone says "We have a block-chain the way Satoshi intended it to be". Every crypto-currencies out there take what's working in the wild and make a modification to it that suits their needs, re-brands it and calls it "a brand new project that is exactly what you need!".

Well, fuck that shit. Osoese has started from scratch. SFRX is coded using a modern programming language and with an independent vision that's not only focused on end-user functionality but it is also based in a business model. That is a humongous effort! It will have bugs, for sure. Nobody is perfect. We are trying to mitigate them and audit the source code to deal with potential vulnerabilities. And of course it will be open source and everyone in this community (and others) will be able to play with it, mold it, re-shape it and re-deploy it as they please. After all, it's not every day you get a brand new original story to enter the bast repository of knowledge that is the library of Alexandria (A.K.A. this monotonous crypto-currency world we're living in, where every single project has source-code that, in one way or another, is related to Satoshi Nakamoto).

A discord user asked about bitcoin addresses on SFRX chain so here is the answer:

Mornin'
When building this I took several implementation routes to integrate other coins. The first route was to create a BTC address directly related to your EGEM address and use it in HTLC (hash time lock contracts) and with the lightning network protocol of sorts possibly combined with the BTC relay. So, yes you do have a egem address related BTC address (in fact two of them) that you can send funds to.... however that is not the magic....
As soon as I implemented that idea I went into another thought pattern where I can create a BTC address that the network has the private key in such a way that it needs multiple parties to unlock - kind of a multisig of sorts. However, the cosigner is software and as long as you meet certain conditions it automatically signs. Those conditions are that you signed a transaction with your EGEM address and posted it to the sapphire chain. And it is programmed to give you 2 options (3 if you include creating the address) 1) prove you own the BTC address and 2) transfer ownership of that address unspent transaction outputs to someone else's EGEM address (and then 3 create and address for you). So, then there is another issue....
the other issue is I cant store a bitcoin (or any other coin) private key on a public chain or else someone can just decipher the info on the chain and grab the funds right? So this became a game. There is not really a way to do it specifically on EGEM or with a contract because all that info is public. There are derived  contract addresses on Eth and some other methods, but I chose to implement my own protocol. My protocol can be summed up as "not me" and "i dont know which of them"...
this means I connect my wallet to a node any node and request a BTC address....
but wait a minute the node itself cant just encrypt stuff that would be nuts....we could dump its memory and search for the unlocker to that encryption, right?
(this is a mind fuck so hang in there)
and I researched encrypted hard drives and all that - its a waste of time there is no encrypted storage that cant be hacked at the end of the day....
but there is a little concept that created our whole industry called public private key pairs PGP
you have to remember another concept - my name OSOESE is a recursive algorithm - I wont explain the name but recursion means you do a concept one time that keeps calling itself until it gets to the solution condition then returns the solution to all those calls until it reaches back to the original call....its like climbing way way down in the rabbit hole until solution is found and leaving a string and it climbs is way back up with the solution by pulling on the string
so without too much technical detail this kind of happens on the nodes....
"not me" means I have encrypted information but where is it stored on my hard drive then he answers with "not me"
because his encrypted information is on another node
but which one?
"i dont know"
he doesnt know where it is stored (or where it was created)
so how does he get it?
he has the ability to encrypt data to a public key that was given to him y another node - with encryption that is stored on guess what - another node
and the process happens through network transactions that are encrypted to look alike
so that core concept is what happens just to encrypt the nodes and their communication....he (the node you called) may not know where the data is or where the encryption is stored but through a network call he can get it returned to him and get it unencrypted..... the parts he needs to do his job
now techicallly while this is happening you can dump the memory and catch it
but that is where the part about not knowing where it is comes in
you dont know which node to pull
and neither does the node you called
and all the nodes are first and foremost running a protocol that locks their code and proves they are up and running
so anyway - like i said its a rabbit hole.....and after all that shit we only have encrypted nodes basically
now you called the node to get a BTC address not to care about the nodes encryption process
your signed transaction is coded on the chain to create a BTC address in that encrypted node network and it is only able to be triggered by your [EGEM] signature
unless you sign one thing -> transfer of that control to another party
so if you look at my BTC proof the 5 second thing
the first step is I make an address on the BTC testnet over the node encryption - it looks easy because all that stuff :point_up: is just running and I dont need to explain it
then I send some funds to that address
then I sign a proof that my EGEM address owns that BTC address
then I transfer the ownership of the enture address to @sehidcan test EGEM address
then I log into another wallet with sehidcan address and make another signature proof that sehidcan EGEM address owns the bitcoin address
neither sehidcan or me have the bitcoin private key so we cant reneg on our deal and steal the funds
only the registered EGEM address can unlock and transfer the funds or control of the wallet
and this happens on sapphire
in fact I think the last step of my proof is that I cant sign the address any more  because I transfered ownership
so that is sapphire BTC address in a ling drawn out explanation
and thats also why it took a few months longer to make than I anticipated, because the original protocol did not have BTC transfers in this way

https://github.com/osoese/5SECPDF

Development on SFRX has taken a lot longer than I ever anticipated. I have some videos for the mobile app. We had some issues with the sync process between peers and the all balance tree to work out. The chain is going into another round of early testing now that those things have been worked out and I will be posting the progress. Here is a video or two of the mobile

https://www.youtube.com/watch?v=XI3he-ido9k

https://www.youtube.com/watch?v=CMD6ytnCpdc

I will continue to post more as it develops. We are getting very close.

Kodiak listed me as a dev without my original permission and I never did anything on the core of LMO. I have publicly stated this on twitter and ended up with a new discord for kodiak broken community. Your problems are with kodiak and not me. I also proved that the game I worked on for LMO (which was what I said I built for the coin in the dev area) worked and there is a video of it. I offered other devs to take over that project and work on it as I have time. Bottom line, I don't work for you and I did not pump the LMO shitcoin. In fact I have done everything I can to pick up the pieces for a community that trusted another (since you brought up the shitcoin ELLA) anonymous dev without knowing anything about him or the coin - I'm talking about kodiak. That falls under DO YOUR OWN RESEARCH DYOR and it is your responsibility not mine. So please don't show up on my other projects and post stuff demanding answers because they are in your mirror at home. You are welcome to come to the new LMO discord and compile the code and run your LMO and if you are successful in getting it up and running I can even get you the dev premine because unlike you I did do a little of my own research. I have contact with kodiak who is not a bad guy but hes just a college kid who got overwhelmed by apparently a bunch of pnd characters on that college project coin (LMO). Here is the new discord link for LMO https://discord.gg/kaXkRZA don't worry in advance - I probably wont be responding to much when you ask me about it other than what I said above. The reason is that SAPPHIRE is my publicly advertised baby and pet project and wher I spend my time.

now for those of you who are here to talk about sapphire here is the link to the EGEM discord:https://discord.gg/bQXDtUU and this is where you can find me working away on this chain

https://bitcointalk.org/index.php?topic=4832535.new#new

.....
The main developer of Kodiak stopped working on the coin shortly after listing on the Stex exchange. Let everyone decide for himself why this happened ... Who this Kodiak is is unclear, the bitcointalk account is made only for posts in this thread, so there are options ...
There is one developer who has never written in this thread, but is known for other coins. This is osoese (bitcointalk, twitter). He is involved in the development of several coins (EGEM, SFRX, ELLA, LMO, XBI, maybe more ...), I think we should demand an answer from him and remind about responsibility to users.
And wasn’t the LMO originally conceived as a scam to finance other projects (perhaps even more scam))) Huh
In any case, osoese said he would continue work on the LMO. Smiley
.....

There are some users in the discord.egem.io that are making a miner right now....