Author [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] Topic: Crosschain Trading Proposals  (Read 1002 times)

0 Members and 1 Guest are viewing this topic.

Offline emski

  • Hero Member
  • *****
  • Posts: 1283
    • View Profile
    • http://lnkd.in/nPbhxG
Crosschain Trading Proposals
« on: September 18, 2014, 07:40:48 PM »

I'm back from holiday (Cyprus is excellent place to visit in September) and I managed to fulfill my promise to better describe the topics discussed in https://bitsharestalk.org/index.php?topic=8818.0 .

In the following proposals a method for cross-chain monitoring is outlined including optimizations that should minimize nodes' overhead.

1st Proposal:
It describes means for trust-less BTC-> 1 BTSX  trading. Any user owning BTC can buy 1 BTSX from any user willing to sell under specified conditions.
https://docs.google.com/document/d/1XMu0Sxhx31qY0B2iWDoMZ_Fe12rF31Eu0y2vZ_Kdgpk/edit?usp=sharing

2nd Proposal:
It describes means for trust-less BTC <-> BTSX trading similar to current bitAsset trade. Any user owning BTC AND BTSX can post/accept orders to sell/buy BTC/BTSX similarly to current bitAsset market.
https://docs.google.com/document/d/1huR6eIJ-P1BR91P0l6IDVp4DGad5tLe9L4FTefFSFDI/edit?usp=sharing

I believe bypassing exchanges (at least for cryptocurrencies for now) is huge step towards global decentralized trust-less market.

Comments are welcome.

Offline tonyk

  • Hero Member
  • *****
  • Posts: 3309
    • View Profile
Re: Crosschain Trading Proposals
« Reply #1 on: September 18, 2014, 08:02:49 PM »
I like it and more importantly I find that something of that nature is needed and beneficial.

Hope BM/toast can comment on its viability and or ease of actual implementation.
Lack of arbitrage is the problem, isn't it. And this 'should' solves it.

Offline Shentist

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 1605
    • View Profile
    • metaexchange
  • BTS: shentist
Re: Crosschain Trading Proposals
« Reply #2 on: September 18, 2014, 08:15:26 PM »
both links are the same document?

would be great to see it in the btsx blockchain or greated as a new DACs. and we could implement the most traded altcoins as well.

we can do it with a small fee so the delegates will get 1 more source of income.

 +5%

Offline emski

  • Hero Member
  • *****
  • Posts: 1283
    • View Profile
    • http://lnkd.in/nPbhxG
Re: Crosschain Trading Proposals
« Reply #3 on: September 18, 2014, 08:17:48 PM »
both links are the same document?

would be great to see it in the btsx blockchain or greated as a new DACs. and we could implement the most traded altcoins as well.

we can do it with a small fee so the delegates will get 1 more source of income.

 +5%

Different documents with similar structure.

Offline theoretical

Re: Crosschain Trading Proposals
« Reply #4 on: September 19, 2014, 08:36:32 AM »

Your proposal and my proposal are basically the same idea, but my proposal is more detailed and handles certain corner cases better.

If the buyer and seller agree to multiple transactions for the same amount, your protocol may get confused.

My proposal [1] establishes a particular txid for every user-to-user transaction, thus there is no confusion if the same users transact for the same amount again and again.

Your proposal is not atomic.  When the timeout expires, if the transaction has propagated across the Bitcoin network, but is too slow to confirm due to no fault of the buyer, the BTSX seller can end up with both the BTC and the BTSX.  In my proposal, this cannot happen.  I just added a section at the end adding detail to the mechanics of this part, which is a little harder than it needs to be due to an oddity in the BTC protocol.

[1] https://github.com/drltc/bitbond-proposal/blob/master/btc-trade.md#user-to-user-atomic-exchange
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 emski

  • Hero Member
  • *****
  • Posts: 1283
    • View Profile
    • http://lnkd.in/nPbhxG
Re: Crosschain Trading Proposals
« Reply #5 on: September 19, 2014, 08:46:54 AM »
Your proposal and my proposal are basically the same idea, but my proposal is more detailed and handles certain corner cases better.
Am I supposed to comment on this? I've discussed what I dislike in your proposal in https://bitsharestalk.org/index.php?topic=8818.0.

If the buyer and seller agree to multiple transactions for the same amount, your protocol may get confused.
Perhaps I haven't expressed the idea correctly. Such situations shouldn't happen. Could you elaborate why you think it is possible?

My proposal [1] establishes a particular txid for every user-to-user transaction, thus there is no confusion if the same users transact for the same amount again and again.
So does mine. Have you seen both proposals?

Your proposal is not atomic.  When the timeout expires, if the transaction has propagated across the Bitcoin network, but is too slow to confirm due to no fault of the buyer, the BTSX seller can end up with both the BTC and the BTSX.  In my proposal, this cannot happen.  I just added a section at the end adding detail to the mechanics of this part, which is a little harder than it needs to be due to an oddity in the BTC protocol.

You get what you ask for. However when the timeout expires the offer becomes invalid but the funds are not released until <BTC Confirmation> time has passed. In case of timeout you still need to wait 6+ BTC blocks incase the BTC buyer has send the funds.

Offline betax

  • Hero Member
  • *****
  • Posts: 803
    • View Profile
Re: Crosschain Trading Proposals
« Reply #6 on: September 19, 2014, 12:30:42 PM »
I really like that idea (and we are also debating 2 proposals). This will allow for day traders to close their position in USD, CNY, without risking leaving their FIAT on exchanges.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline tonyk

  • Hero Member
  • *****
  • Posts: 3309
    • View Profile
Re: Crosschain Trading Proposals
« Reply #7 on: September 19, 2014, 01:38:00 PM »
New day new theory from me...
The proposal with or without changes makes a lot of sense. The total silence from the dev. side probably means they have some idea on the matter and just feel too early to show their hand to the world. And this is very likely to mean it has some cool elements that they do not want to give to the competition before they themselves have the idea already implemented or almost implemented. As strange as it is coming from me, I advise for calm and patience...
Lack of arbitrage is the problem, isn't it. And this 'should' solves it.

Offline betax

  • Hero Member
  • *****
  • Posts: 803
    • View Profile
Re: Crosschain Trading Proposals
« Reply #8 on: September 19, 2014, 01:43:38 PM »
New day new theory from me...
The proposal with or without changes makes a lot of sense. The total silence from the dev. side probably means they have some idea on the matter and just feel too early to show their hand to the world. And this is very likely to mean it has some cool elements that they do not want to give to the competition before they themselves have the idea already implemented or almost implemented. As strange as it is coming from me, I advise for calm and patience...

Yes, my theory is that all will be revealed in Vegas.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline theoretical

Re: Crosschain Trading Proposals
« Reply #9 on: September 19, 2014, 06:17:22 PM »

If the buyer and seller agree to multiple transactions for the same amount, your protocol may get confused.
Perhaps I haven't expressed the idea correctly. Such situations shouldn't happen. Could you elaborate why you think it is possible?


Your proposal states "If a match occurs between Richy and Mike then Richy has to send to Mike’s address the specified amount of BTC in the specified timout (1.5) otherwise he should lose the collateral pledged.  When Richy’s transaction sending BTC to Mike is confirmed -> delegates should include the required information in the blockchain so other nodes can easily verify. And transfer required amount BTSX from Mike to Richy"

Suppose Mike has two orders each offering 14000 BTSX for 1 BTC.  Suppose both orders are matched by Richy.  Then Richy sends 1 BTC to Mike.  If the logic is "if there exists a recent transaction which sends 1 BTC from Richy to Mike, then consider the order to be filled," this condition will trigger for both orders and Richy will get 28000 BTSX even though only 1 BTC was sent.

If Mike’s transaction is canceled or timeout all the funds are not instantly released. Instead BTC transaction confirmation time should pass before the funds are released. This is to make sure Richy hasn’t already sent BTC and to allow Richy to act if his transaction is pending but not included in block by some reason.


My proposal [1] establishes a particular txid for every user-to-user transaction, thus there is no confusion if the same users transact for the same amount again and again.
So does mine. Have you seen both proposals?


I've read both, but AFAICT the network / delegates choose what txid to associate with a particular user-to-user transaction (and may get it wrong).  In my proposal, the users agree on the txid of the user-to-user transaction (but network must still check that it sends the correct amount to the correct recipient).


Your proposal is not atomic.  When the timeout expires, if the transaction has propagated across the Bitcoin network, but is too slow to confirm due to no fault of the buyer, the BTSX seller can end up with both the BTC and the BTSX.  In my proposal, this cannot happen.  I just added a section at the end adding detail to the mechanics of this part, which is a little harder than it needs to be due to an oddity in the BTC protocol.

You get what you ask for. However when the timeout expires the offer becomes invalid but the funds are not released until <BTC Confirmation> time has passed. In case of timeout you still need to wait 6+ BTC blocks incase the BTC buyer has send the funds.

The other day I had a small Bitcoin transaction take hours to verify.  Waiting for <BTC Confirmation> time is past protects you against forks and double spends, but there is no guarantee an unconfirmed transaction will be confirmed within <BTC Confirmation> for any value of <BTC Confirmation>.  (The latest addition to) my proposal gets around this by allowing Mike to use a "deadline transaction" sending Richy's BTC back to Richy if Richy doesn't deliver.  If the deadline transaction is confirmed, the delivery transaction cannot be, so it's safe to give Mike his BTSX back since we can prove the Bitcoin network will ultimately reject the delivery transaction no matter how long it takes to show up.
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 emski

  • Hero Member
  • *****
  • Posts: 1283
    • View Profile
    • http://lnkd.in/nPbhxG
Re: Crosschain Trading Proposals
« Reply #10 on: September 19, 2014, 06:49:25 PM »
Your proposal states "If a match occurs between Richy and Mike then Richy has to send to Mike’s address the specified amount of BTC in the specified timout (1.5) otherwise he should lose the collateral pledged.  When Richy’s transaction sending BTC to Mike is confirmed -> delegates should include the required information in the blockchain so other nodes can easily verify. And transfer required amount BTSX from Mike to Richy"

Suppose Mike has two orders each offering 14000 BTSX for 1 BTC.  Suppose both orders are matched by Richy.  Then Richy sends 1 BTC to Mike.  If the logic is "if there exists a recent transaction which sends 1 BTC from Richy to Mike, then consider the order to be filled," this condition will trigger for both orders and Richy will get 28000 BTSX even though only 1 BTC was sent.


That could happen only if Mike uses the same BTC address in both orders. I'll add a requirement for unique BTC address per order.


I've read both, but AFAICT the network / delegates choose what txid to associate with a particular user-to-user transaction (and may get it wrong).  In my proposal, the users agree on the txid of the user-to-user transaction (but network must still check that it sends the correct amount to the correct recipient).

If published addresses are unique for each order there could be no confusion.


Your proposal is not atomic.  When the timeout expires, if the transaction has propagated across the Bitcoin network, but is too slow to confirm due to no fault of the buyer, the BTSX seller can end up with both the BTC and the BTSX.  In my proposal, this cannot happen.  I just added a section at the end adding detail to the mechanics of this part, which is a little harder than it needs to be due to an oddity in the BTC protocol.

The other day I had a small Bitcoin transaction take hours to verify.  Waiting for <BTC Confirmation> time is past protects you against forks and double spends, but there is no guarantee an unconfirmed transaction will be confirmed within <BTC Confirmation> for any value of <BTC Confirmation>.  (The latest addition to) my proposal gets around this by allowing Mike to use a "deadline transaction" sending Richy's BTC back to Richy if Richy doesn't deliver.  If the deadline transaction is confirmed, the delivery transaction cannot be, so it's safe to give Mike his BTSX back since we can prove the Bitcoin network will ultimately reject the delivery transaction no matter how long it takes to show up.

I've seen your updated proposal. The concept of "deadline transaction" is doable in the updated document (It couldn't be implemented in the initial variant without BTC hardfork). However Alice/Mike should be able to control the transaction fee and nLockTime variable. So this should be included in the initial orders (or mandatory specified by the protocol).
I'll update the proposal with reference to your description of "deadline transaction".

Offline Shentist

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 1605
    • View Profile
    • metaexchange
  • BTS: shentist
Re: Crosschain Trading Proposals
« Reply #11 on: September 19, 2014, 07:24:11 PM »
Quote
Quote from: drltc on Today at 06:17:22 PM
Your proposal states "If a match occurs between Richy and Mike then Richy has to send to Mike’s address the specified amount of BTC in the specified timout (1.5) otherwise he should lose the collateral pledged.  When Richy’s transaction sending BTC to Mike is confirmed -> delegates should include the required information in the blockchain so other nodes can easily verify. And transfer required amount BTSX from Mike to Richy"

Suppose Mike has two orders each offering 14000 BTSX for 1 BTC.  Suppose both orders are matched by Richy.  Then Richy sends 1 BTC to Mike.  If the logic is "if there exists a recent transaction which sends 1 BTC from Richy to Mike, then consider the order to be filled," this condition will trigger for both orders and Richy will get 28000 BTSX even though only 1 BTC was sent.


That could happen only if Mike uses the same BTC address in both orders. I'll add a requirement for unique BTC address per order.


i don't get this. is here really a problem?

every ask or bid has already a unic transactionnumber. the buyer has to txid this transaction number to get matched through the delegates. it would not possible to recieve 28000 BTSX for sending only 1 BTC, because it is not the same transaction number.

it would also possible for the buyer to send the needed BTC from multiple Bitcoin accounts/wallets. It doesn't matter, because the delegate will only check the bitcoin blockchain for the sellers bitcoin address and if enough BTC with correct transaction number are recieved.

so in my opinion we have already everything needed in place.

for our side we would only need

1. place order of bid BTC for x BTSX : a) Bitcoinaddress (this transaction has already a transaction number in the BTSX Blockchain
2. the buyer accepts the offer, will shown to which Bitcoinaddress and with which transaction number he has to send the BTC (doesn't matter if he splits the transaction into pieces
3. we need a acceptable time we can gurantee 95% of all Bitcoin Transaction are prodcasted (4+ confirmations)

Offline emski

  • Hero Member
  • *****
  • Posts: 1283
    • View Profile
    • http://lnkd.in/nPbhxG
Re: Crosschain Trading Proposals
« Reply #12 on: September 19, 2014, 07:34:00 PM »
@Shenist the above-mentioned issue could arise if Mike used the same BTC address for 2 different orders. Delegates couldn't know for which order incoming BTC were for. That is why for each order there should be unique receive BTC address.

Offline theoretical

Re: Crosschain Trading Proposals
« Reply #13 on: September 21, 2014, 09:32:52 PM »
every ask or bid has already a unic transactionnumber. the buyer has to txid this transaction number to get matched through the delegates. it would not possible to recieve 28000 BTSX for sending only 1 BTC, because it is not the same transaction number.

We need to distinguish between txid's for BTSX blockchain and txid's for BTC blockchain.

The bid and ask, existing on the BTSX blockchain, necessarily have BTSX txid's.  The BTC txid of a BTC transaction depends on the receiver's address.  The BTC blockchain txid of the delivery transaction cannot be computed until the bid and ask are matched, because where you send the BTC depends on which offer you match.

So while every bid or ask does have a unique BTSX txid, it is not obvious how this BTSX txid could be used to identify a particular BTC transaction.
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 theoretical

Re: Crosschain Trading Proposals
« Reply #14 on: September 21, 2014, 09:53:56 PM »
I've seen your updated proposal. The concept of "deadline transaction" is doable in the updated document (It couldn't be implemented in the initial variant without BTC hardfork). However Alice/Mike should be able to control the transaction fee and nLockTime variable. So this should be included in the initial orders (or mandatory specified by the protocol).
I'll update the proposal with reference to your description of "deadline transaction".

Your description of the deadline transaction currently states:

Quote
7. If the “Deadline Transaction” is confirmed all the funds instantly released.
8. If the “Deadline Transaction” is rendered invalid (due to Richy’s other transactions spending some of the same inputs) -> This is the same as Richy failing to fulfill the deal => Richy’s collateral is lost.

This sounds backwards.  If the deadline transaction is confirmed, it's treated the same as Richy spending the same inputs; the deal is cancelled and Richy loses collateral.  In fact, in my protocol there is no need to scan the BTC network for the deadline transaction specifically.  Instead, you scan the BTC network for any transaction sending the BTC anywhere but Mike's address.  Upon finding such a transaction, trigger a failure-to-deliver, resulting in Richy's losing collateral, and Mike's BTSX being returned to him from escrow.  If we just let the failure-to-deliver trigger be based on the actual wall-clock time of day, we risk screwing over Richy if he's honest and the Bitcoin network is just being slow.  The point of the deadline transaction is to allow Mike to trigger the failure-to-deliver logic after some amount of time, using a trigger event that is guaranteed to return Richy's BTC.

Also, how do Mike and Richy establish that delivery will use particular inputs?  The deadline transaction requires the parties to designate specific BTC inputs as the coins to be delivered.  When and how do the parties make this designation in your protocol?
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

 

Google+