Author Topic: Atomic Cross Chain Trading  (Read 6912 times)

0 Members and 1 Guest are viewing this topic.

Offline vikram

Its implemented in the blockchain protocol ... no client api there yet .. sadly

This is not true--please see: https://bitsharestalk.org/index.php?topic=12813.msg170505#msg170505

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
Its implemented in the blockchain protocol ... no client api there yet .. sadly

Offline bernard

  • Newbie
  • *
  • Posts: 17
    • View Profile
I just fired up the gui client and could not find the "withdraw_password_type" in the console screen.

Where can I find it?

Offline crispweed

  • Newbie
  • *
  • Posts: 1
    • View Profile
Looks like the same design crispweed over on BTT came up with (and implemented) back in May: https://bitcointalk.org/index.php?topic=628547.0

So is this "withdraw_password_type" tx already in BitShares and working? Theoretically we could do a BTSX to SwapBill trade as a test?

Hi there!

Yes, this is the same algorithm as is used for cross chain exchange in SwapBill.

You can find some more discussion about this on this blog post:
http://upcoder.com/11/atomic-cross-chain-exchange/

The key point, I think, is to try and standardise on a good secret hashing function.

SwapBill is currently *live* on the bitcoin and litecoin testnets, and yes, it would be very cool if you want to try out exchanges against this.

Just shout if you need some help setting this up..

Offline bluebit

  • Sr. Member
  • ****
  • Posts: 271
    • View Profile
Anything I forgot to describe? Anything unclear?

I have a better idea:

Both Alice and Bob have their transactions ready to send, in whatever currency or asset. They send their transactions to a "node", node checks to makes sure both transactions are of equal value and if not node sends back the transactions to Alice and Bob. If both transactions are correct, both transactions are green lit and broadcast on the network.
BTSX TipMe: bluebit

Offline bernard

  • Newbie
  • *
  • Posts: 17
    • View Profile
Looks like the same design crispweed over on BTT came up with (and implemented) back in May: https://bitcointalk.org/index.php?topic=628547.0

So is this "withdraw_password_type" tx already in BitShares and working? Theoretically we could do a BTSX to SwapBill trade as a test?

Offline jsidhu

  • Hero Member
  • *****
  • Posts: 1335
    • View Profile
For those that did not attend the latest dev hangout, BM briefly explained how cross-chain trading would work.

Is this explanation somewhere online?

Anything I forgot to describe? Anything unclear?

The form of AXCT you describe requires both chains to implement the withdraw_password_type operation.  Thus it is only practical between two BitShares Toolkit chains.  A potential AXCT implementation would have more value if it supported coins such as BTC, LTC, DOGE, etc. (without requiring a hardfork in those non-BitShares Toolkit chains).

Another minor nitpick:  The described protocol is not truly atomic.  If Bob is offline between Alice revealing the password and the expiry of Alice's transaction, Alice may end up with both BTSX and DNS.  You can reduce (but not eliminate) this possibility by lengthening the time Bob would need to be offline for this to happen.

I have proposed a protocol which fixes the above deficiencies.  (emski independently developed an identical protocol.)  However my / our protocol imposes an additional requirement:  It requires a way for the network to "know" whether the delivery of the "foreign" currency occurred.  I.e. we (the BTSX network) need to know what happened on the foreign chain (the BTC network).

One way to satisfy this requirement is having delegates to monitor the foreign chain.  This is less than ideal:  (1) Supporting N altcoins would require the delegates to run N different clients; (2) You have the political problem of choosing which altcoins to support, (3) Fully auditing delegates' good behavior also requires N foreign clients, so you have the problem of either (4) Less thorough delegate auditing, or (5) Running N different clients on all nodes.

I've come up with a less centralized way to meet the requirement without too much burden; a way to make the network "know" what happened on the foreign chain.  However, I haven't written it up yet.  I think AXCT between BTSX and BTC would have some value.  It would make it easier to leverage existing BTC infrastructure.  For example, it would be fairly simple for a third party to use AXCT to build a translation app which allows using BitUSD to pay a specified number of Bitcoins to a specified Bitcoin address, e.g. paying a BitPay invoice [1] [2].

Also, if we have AXCT for DOGE <-> BTSX and BTSX <-> BTC, then essentially we can allow users to trade DOGE <-> BTC without trusting any fiduciary.  Making the "MtGox problem" a thing of the past.

In addition, I suspect a working, live implementation would get us a lot of attention; basically free marketing.

[1] With AXCT support for BitUSD -> BTC, this app would not require any fiduciary trust from the user.  Without AXCT, this app is still possible, but either the app must have API access to the user's account at bter or a similar fiduciary exchange, or the app maintainers must have fiduciary control of user funds.

[2] This app would provide value by (from the user's point of view) enabling every merchant who accepts BTC to also accept BitUSD, without any action on the part of the merchant.

This sounds like an approach using oracles or n of m signers... I suggest to look at Automated Transactions or AT (http://ciyam.org/at)

atomic cross-chain transfers(network based) are possible across any block chain that implements the API.. also it is turing complete using a load/store style machine.
Hired by blockchain | Developer
delegate: dev.sidhujag

Offline Shentist

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 1601
    • View Profile
    • metaexchange
  • BitShares: shentist
@drltc

i read you are a C++ coder?
do you think you can programm it?
i am interested to fund it if so.

maybe we could team up with emski to give it a shot?

Offline theoretical

For those that did not attend the latest dev hangout, BM briefly explained how cross-chain trading would work.

Is this explanation somewhere online?

Anything I forgot to describe? Anything unclear?

The form of AXCT you describe requires both chains to implement the withdraw_password_type operation.  Thus it is only practical between two BitShares Toolkit chains.  A potential AXCT implementation would have more value if it supported coins such as BTC, LTC, DOGE, etc. (without requiring a hardfork in those non-BitShares Toolkit chains).

Another minor nitpick:  The described protocol is not truly atomic.  If Bob is offline between Alice revealing the password and the expiry of Alice's transaction, Alice may end up with both BTSX and DNS.  You can reduce (but not eliminate) this possibility by lengthening the time Bob would need to be offline for this to happen.

I have proposed a protocol which fixes the above deficiencies.  (emski independently developed an identical protocol.)  However my / our protocol imposes an additional requirement:  It requires a way for the network to "know" whether the delivery of the "foreign" currency occurred.  I.e. we (the BTSX network) need to know what happened on the foreign chain (the BTC network).

One way to satisfy this requirement is having delegates to monitor the foreign chain.  This is less than ideal:  (1) Supporting N altcoins would require the delegates to run N different clients; (2) You have the political problem of choosing which altcoins to support, (3) Fully auditing delegates' good behavior also requires N foreign clients, so you have the problem of either (4) Less thorough delegate auditing, or (5) Running N different clients on all nodes.

I've come up with a less centralized way to meet the requirement without too much burden; a way to make the network "know" what happened on the foreign chain.  However, I haven't written it up yet.  I think AXCT between BTSX and BTC would have some value.  It would make it easier to leverage existing BTC infrastructure.  For example, it would be fairly simple for a third party to use AXCT to build a translation app which allows using BitUSD to pay a specified number of Bitcoins to a specified Bitcoin address, e.g. paying a BitPay invoice [1] [2].

Also, if we have AXCT for DOGE <-> BTSX and BTSX <-> BTC, then essentially we can allow users to trade DOGE <-> BTC without trusting any fiduciary.  Making the "MtGox problem" a thing of the past.

In addition, I suspect a working, live implementation would get us a lot of attention; basically free marketing.

[1] With AXCT support for BitUSD -> BTC, this app would not require any fiduciary trust from the user.  Without AXCT, this app is still possible, but either the app must have API access to the user's account at bter or a similar fiduciary exchange, or the app maintainers must have fiduciary control of user funds.

[2] This app would provide value by (from the user's point of view) enabling every merchant who accepts BTC to also accept BitUSD, without any action on the part of the merchant.
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

Offline jsidhu

  • Hero Member
  • *****
  • Posts: 1335
    • View Profile
Is this wat BM mentioned was going to be Turing complete so for example if you have an AUCTION Dac you can encode rules in the script to function as a auction with buy it now as a turing complete implementation using ACCT (auctions are represented in bitUSD)
Hired by blockchain | Developer
delegate: dev.sidhujag

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
So,it's technically impossible to spend BTSX-BitUSD on vote directly?
These are TWO different chains .. there is no such thing as a BTSX-bitUSD in the vote chain ..

Offline bytemaster

You don't understand the issues involved.  Acct is not viable for anything but real time trades of bit usd between two chains
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline CoinHoarder

  • Hero Member
  • *****
  • Posts: 660
  • In Cryptocoins I Trust
    • View Profile
Why is this a low priority? You've now seen people's reactions that bitUSD will be implemented in Bitshares Vote.. BTSX is down 5% since that announcement was made and it could get much worse. One usually big time Bitshares supporter stated he dumped his BTSX because of it..

IMO it is important to keep bitUSD in BTSX but utilize it in Bitshares vote using atomic cross chain transactions. This way BTSX DAC shareholders don't feel robbed of their biggest feature. It is important that each DAC retain its value by not implementing DAC-specific features in each DAC, but still link them together for the same functionality.
« Last Edit: October 18, 2014, 02:59:13 pm by CoinHoarder »
https://www.decentralized.tech/ -> Market Data, Portfolios, Information, Links, Reviews, Forums, Blogs, Etc.
https://www.cryptohun.ch/ -> Tradable Blockchain Asset PvP Card Game

Offline emski

  • Hero Member
  • *****
  • Posts: 1282
    • View Profile
    • http://lnkd.in/nPbhxG
I was just going to write about the double spend option in BTC. Miners will not include both transactions. Only the first one.
Thought so ..
If I find some time I will read through:
https://en.bitcoin.it/wiki/Atomic_cross-chain_trading
But it contains exchanging of signed and unsigned transactions .. (ugly, not user friendly)

Quote
Have you seen this thread:
https://bitsharestalk.org/index.php?topic=9075.0 ?
Thx, I will read through it ..
However, from what I can see .. the delegates are involved and you are trading BTSX<->BTC on two chains ..
maybe we should start out with something easier and go for bitBTC <-> BTC first ... not having an exchange ratio

bitBTC <-> BTC or BTSX <-> BTC doesn't matter. That should be the same. And the ratio -> you still should have some kind of ratio even for BTC <-> bitBTC .

Update: Infact there is no incentive for anyone holding BTC to exchange that for bitBTC even at 1:1 unless he wants to trade against other assets on BTSX blockchain. And BTSX is better suited for that.
« Last Edit: October 18, 2014, 01:18:40 pm by emski »

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
I was just going to write about the double spend option in BTC. Miners will not include both transactions. Only the first one.
Thought so ..
If I find some time I will read through:
https://en.bitcoin.it/wiki/Atomic_cross-chain_trading
But it contains exchanging of signed and unsigned transactions .. (ugly, not user friendly)

Quote
Have you seen this thread:
https://bitsharestalk.org/index.php?topic=9075.0 ?
Thx, I will read through it ..
However, from what I can see .. the delegates are involved and you are trading BTSX<->BTC on two chains ..
maybe we should start out with something easier and go for bitBTC <-> BTC first ... not having an exchange ratio