Author Topic: Crosschain Trading Proposals  (Read 5493 times)

0 Members and 1 Guest are viewing this topic.

Offline emski

  • Hero Member
  • *****
  • Posts: 1282
    • View Profile
    • http://lnkd.in/nPbhxG
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
.


i don't get it, maybe lacking bitcoin understanding or lacking english.

1. The Seller on the BTSX Blockchain will post in his offer his BTC address and the txt for the transaction
2. if the scanning delegate find the transaction to this address with this txt he will execute the transaction

how is it possible to do it wrong?
The seller posts the offer. The buyer posts the transaction.

Offline Shentist

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 1601
    • View Profile
    • metaexchange
  • BitShares: shentist
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
.


i don't get it, maybe lacking bitcoin understanding or lacking english.

1. The Seller on the BTSX Blockchain will post in his offer his BTC address and the txt for the transaction
2. if the scanning delegate find the transaction to this address with this txt he will execute the transaction

how is it possible to do it wrong?

Offline emski

  • Hero Member
  • *****
  • Posts: 1282
    • View Profile
    • http://lnkd.in/nPbhxG

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.

I've changed the wording to be more specific for rule 7.

Deadline transaction broadcast by Mike does not guarantee anything. The network could be slow for any transaction.
What delegates monitor in the BTC blockchain is the three rules 6, 7 and 8 . (6 being "Mike has received Richy's BTC", 7,8 being "Mike cannot receive Richy's BTC")
Whichever is confirmed in BTC blockchain takes effect instantly.

Quote
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?

Particular inputs of the deadline transaction are picked by Richy with the initial publishing of deadline transaction. This works best when Richy picks Mike's standing order. In the case where Richy's order should be standing the deadline transaction can be published by Richy whenever market match occurs. (My proposal doesn't explicitly state this).

« Last Edit: September 23, 2014, 01:18:19 pm by emski »

Offline theoretical

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

Offline theoretical

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 emski

  • Hero Member
  • *****
  • Posts: 1282
    • View Profile
    • http://lnkd.in/nPbhxG
@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 Shentist

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 1601
    • View Profile
    • metaexchange
  • BitShares: shentist
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: 1282
    • View Profile
    • http://lnkd.in/nPbhxG
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 theoretical


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 betax

  • Hero Member
  • *****
  • Posts: 808
    • View Profile
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 tonyk

  • Hero Member
  • *****
  • Posts: 3308
    • View Profile
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: 808
    • View Profile
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 emski

  • Hero Member
  • *****
  • Posts: 1282
    • View Profile
    • http://lnkd.in/nPbhxG
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 theoretical


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: 1282
    • View Profile
    • http://lnkd.in/nPbhxG
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.