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
