Author Topic: BTC->BTSX Proposal  (Read 10014 times)

0 Members and 1 Guest are viewing this topic.

Offline cryptillionaire

  • Full Member
  • ***
  • Posts: 153
    • View Profile
So what, burn btc for btsx?

Offline emski

  • Hero Member
  • *****
  • Posts: 1282
    • View Profile
    • http://lnkd.in/nPbhxG
Imagine the following usecase:
A BTC holder (RICHY) wants to buy BTSX.

What RICHY needs to do currently:
1 Deposit BTC into an exchange (paying taxes, trusting the exchange).
2 Buy BTSX from orderbook on that exchange only (paying taxes, trusting the exchange).
3 Transfer BTSX from exchange's account to own BTSX wallet (paying taxes, trusting the exchange to do that).

What is the better option for RICHY:
1 Send BTC to specified BTC addresses. (possibly paying taxes, no trust issues)
2 Receive BTSX to specified BTSX account. (trusting 50% + 1 of BTSX delegates)

How can this be implemented?

Basically in delegates there is some level of trust already. There is no technical issue for delegates to monitor BTC blockchain.
Appart from some legal issues there is no technical issue for delegates to be mediators/ESCROW agents between blockchains.
There could be BTCAsk and BTCBid transactions on BitsharesX blockchain that signify intent between parties to exchange BTSX for BTC at certain ratio.
When such transactions are matched delegates could be an ESCROW for BTC(or bitcoin blockchain) -> BTSX transfer. This requires trust in delegates to forward BTC properly. In order to force/ensure good behavior a delegate bond may be placed (in BTSX). As all the transactions are visible delegate shouldn't be able to cheat or he/she risks his/hers bond/delegate seat. As they only perform ESCROWnotYetSureWhat they will not hold any amount of bitWhatever longer than confirmation time.

Here is my proposal (It requires some coding and consensus but it is doable):
[Updated Proposal Start]
1 Unchanced from Original Proposal (see below)
2 Unchanged from Original Proposal (see below)
3 A new kind of transaction (BTCBid) is created with the following properties:
   3.1 BTC amount (this is amount of BTC on BTC blockchain that a bidder is willing to exchange for btsx)
   3.2 BTSX/BTC ratio (Bid price for BTSX in BTC, meaning how much BTSX the transaction issuer wants for each of his BTC)
   3.3 Transaction id of a BTC transaction sending 0.01 BTC (or any other amount or percentage as bond or fee) to a delegate controlled BTC address. (Or if we dont want to be matching bids/asks, BTCBider could just point matching BTCAsk transaction and transfer BTC directly there, Or the bond might be in BTSX, Anyway we could go without transferring funds to a delegate controlled addres if required)
4 Unchanged from Original Proposal (see below)
5 Unchanged from Original Proposal (see below)

6 Whenever there is a match between BTCBid and BTCAsk AND the transaction in 3.3 is confirmed in BTC blockchain => Delegates include special transaction in BitsharesX blockchain signifying the fact that specific BTCBid/BTCAsk are matched and in the next 24 hours the issuer of BTCBid should transfer the specified amount of BTC to the address of the issuer of BTCAsk transaction.
7 If 6 is completed in expected timeframe delegates should exercise their ability (5) and transfer the BTSX to the issuer of BTCBid transaction. If 6 is not completed the delegate holding the bond specified in 3.3 should transfer it (or parts of it) to the issuer of BTCAsk as reparations for the lost time.
[Updated Proposal End]

[Original Proposal Start]

List of stuff to implement:
0 OPTIONAL A delegate bond/cover might be required from delegates in case someone decides to get the BTC and hide.
1 Every BTSX account should be granted the ability to publish own BTC address ( and it should be included in the BitsharesX blockchain).
2 A new kind of transaction (BTCAsk) is created with the following properties:
   2.1 BTSX amount (this amount becomes unspendable)
   2.2 BTSX/BTC ratio (Ask price for BTSX in BTC, meaning how much BTC the transaction issuer wants for each of his BTSX)
3 A new kind of transaction (BTCBid) is created with the following properties:
   3.1 BTC amount (this is amount of BTC on BTC blockchain)
   3.2 List of transactions (in BTC blockchain) - all transactions should satisfy the rule: Total amount should be equal to <BTC amount (from 3.1)>. All the funds are sent to BTC addresses of BTSX delegates(the list of delegate(s) is selected by this transaction issuer. ). This list might need to be "appended" to the transaction at a later time (possibly with separate transaction(s)). I'll just include it here for simplicity
   3.3 BTCAsk (2.) transaction id. Indicating that the bidder wants to exchange with the asker BTC for BTSX. (In a more complex scenario these transactions could be matched in a way similar to how market works. However even if they are matched no exchange should be done until other conditions are met... see below)
4 Ability to monitor BTC blockchain should be implemented in bitshares_client enabling it to:
   4.1 bitshares_client should be able to monitor if a specified transaction is confirmed (in BTC blockchain).
   4.2 bitshares_client should be able to extract details of a BTC transaction (in BTC blockchain) these details should include: sending address, receiving address, amount.
5 A new rule (transaction) for the BitsharesX blockchain (and client) should be implemented such that:
   5.1 50% + 1 of delegates should be able to transfer BTSX from an account that has issued BTCAsk (2) transaction to an account issued BTCBid (3).

Behavior of a delegate (well it is actually another thing to implement) :

Once a matching pair of BTCAsk and BTCBid transactions are included in the BTSX blockchain delegate should:
6 Delegate monitors BTC blockchain.
7 Delegate check if transactions in BTCbid (3.2) are confirmed in BTC blockchain. This means the issuer of BTCBid on BTSX blockcian has sent BTC (in BTC blockchain) to a selected (by issuer of BTCbid) subset of delegates.
8 Here comes the trust part (This could be eliminated with rule 0). A delegate (X) checks If an address listed in BTCbid (3.2) (assuming it  is matched with BTCAsk) is his (X's) address. If a delegate X has received BTC (in BTC blockchan) he is supposed to immediately send these BTC to the address of the issuer of matching BTCAsk (2) transaction. A delegate should not keep these BTC longer than absolutely required to confirm the transaction on BTC blockchain. This way the delegates do not hold BTC for longer than few minutes. And if they fail to conform they lose their bond which might be used to cover for the loses.
9 Each delegate monitors all matched BTCAsk and BTCbid transactions and their respective BTC addresses. Once the issuer of BTCAsk transaction receives his BTC each delegate is supposed to sign a transaction (see 5) moving BTSX specified in BTCAsk (2.1) from the issuer of BTCAsk transaction to the issuer of BTCBid transaction.
[Original Proposal End]

This should effectively allow cross-chain trustless (somewhat depending on the bond and consensus) trading. Cut off all the exchanges - they are not needed. This looks pretty good to me.

Sorry if this is too long/complex/obscured. I'll try to answer questions and provide more clarity whenever possible. However I'm in vacation and my responses could be slower.

Now I'd like to see some comments....

UPDATE: One more thing: If implemented this will remove feed requirements for cryptocurrencies. And will make BitsharesX basically global free market.
UPDATE2: Perhaps it could be better if not only delegates can be ESCROW in the above-mentioned manner. There is no reason for any account that has posted a bond to be an ESCROW.
UPDATE3: Even better would be if the BTSX from BTCAsk are held as a bond and released once a transaction from BTCBider's BTC address to BTCAsker's BTC address is confirmed. So this will symplify the whole process... Perhaps I should describe this separately.
UPDATE4: I've added updated (somewhat simpler) proposal (Maybe I should've thought it through entirely before posting...)
« Last Edit: September 13, 2014, 04:54:54 am by emski »