I read much marketing meaningless babble (like "the internet of blockchains"), but not much subtance or technical details...
could you please explain for one use case, from the beginning to the end, how would this work?
e.g. let's say I want to send money using SMS, a feature from XST, while I hold some other thing, let's say APEX. Coins would be automagically exchanged? how? what currency does the service provider receive? can the receiver of the SMS receive other currency than XST? how?
the xbridge api would have a method for each possible service? so it would have to be updated every time a new service is added... otherwise... how would it work?
Is the coding of the exchange and the xbridge api finished? When would this be deployed? right after the ITO?
thanks!
Hey hey
Have you checked out
the FAQ below the OP?
The XBridge is a protocol. There's only one XBridge.
The API supports a general-purpose application platform. Ultimately there aren't that many fundamental actions to code for. Their composites would specify a very wide range of potential applications. That said, no doubt the API will go through revisions from time to time, and more or less indefinitely, as technology advances.
Part of the XBridge code is done. But only part. The exchange is not done (though in reality I suspect there'll be multiple decentralised exchanges all competing to offer their services).
As for your SMS example, it would depend to a large extent on however XST code it, but here's a sketch:
Let's say you owe APEX.
And you want to SMS some APEX over to someone.
Your node would pay an XST node for the service, using APEX.
The APEX would be automatically exchanged for XST.
The XST node receive the XST and keep it as profit.
The XST node would pay the Blocknet microfee.
The XST node would take phone number you're sending the amount to.
It would send the amount in XST (because the SMS system is built on the XST blockchain).
The recipient node would receive the XST.
The recipient node would then convert the XST to APEX using the decentralised exchange.
The resulting APEX would then be sent to the recipient's APEX node.
If you're wondering how decentralised exchange works,
this speculative post could turn into an interesting discussion.
hi! thanks for your reply.
I did read the FAQ, and I did understand xbridge is the protocol. The question is if there should be one message of that protocol for each possible special service.
The concept is interesting, however I wonder how could I be sure that the node providing the service will not steal my money by not providing the service at all. Can the blocknet chain give me security about that? If so, how could it be possible without tracking every service on every chain? if it has to track everything then it's not like the internet of blockchains, it's more like a giant monster that reimplements all other blockchains.
if it can't provide trustless security then I'd rather exchange my apex to xst and then do the xst transfer without going through the blocknet and paying the blocknet fee. I mean an app could do that, there would be no need for a blocknet chain.
Valid point, and I agree: if the Blocknet reimplements all the other blockchains then it wouldn't be a Blocknet.
My (hypothetical) suggestion in the hyperlink above is to use atomic group_sig (M-of-M) transactions
Say buyer M wants XYZcoins and seller N wants ABCcoins. There would be:
- buyer M's receiving address in XYZcoin
- seller N's sending address in XYZcoin
- buyer M's sending address in ABCcoin
- seller N's receiving address in ABCcoin
ABCcoins would be sent from address M_ABC to address N_ABC
XYZcoins would be sent from address N_XYZ to address M_XYZ
ABCcoin transactions would be accounted for on the ABC chain
XYZcoin transactions would be accounted for on the XYZ chain
Both parties can publicly observe this.
The receiving nodes on each of the two blockchains would trustlessly verify that the tx's are valid and that the coins are spendable.
The decentralised exchange protocol would enable an atomic group_sig transaction on all participating addresses.
Being atomic, no party could pull out without the whole transaction failing.
And since every address has to sign the transaction, no party is able to redirect coins.
And so no coins can be stolen.
Also, in real life the transactions would be way more complicated because a bid can be part-sold into, so that multiple parties can take a single order.
Furthermore buyer M might want to trade XYZcoin for ABCcoin, but buyer N ABCcoin for QRScoin. So the multiparty transactions could get beautifully complicated.
So it's really atomic multiparty_sig, like XCurrency's mixer transactions... possibly ideal for the
ad hoc mesh tech, but now not only denominated in XC.