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: BTC->BTSX Proposal  (Read 1491 times)

0 Members and 1 Guest are viewing this topic.

Offline emski

  • Hero Member
  • *****
  • Posts: 1283
    • View Profile
    • http://lnkd.in/nPbhxG
BTC->BTSX Proposal
« on: September 12, 2014, 09:20:43 AM »

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 »

Offline cryptillionaire

  • Full Member
  • ***
  • Posts: 155
    • View Profile
Re: BTC->BTSX Proposal
« Reply #1 on: September 12, 2014, 10:08:19 AM »
So what, burn btc for btsx?

Offline emski

  • Hero Member
  • *****
  • Posts: 1283
    • View Profile
    • http://lnkd.in/nPbhxG
Re: BTC->BTSX Proposal
« Reply #2 on: September 12, 2014, 10:18:39 AM »
So what, burn btc for btsx?
Nothing is burned.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12307
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BTS: xeroc
  • GitHub: xeroc
Re: BTC->BTSX Proposal
« Reply #3 on: September 12, 2014, 11:04:29 AM »
Give BitShares a try! Use the http://testnet.bitshares.eu provided by http://bitshares.eu powered by ChainSquad GmbH

Offline emski

  • Hero Member
  • *****
  • Posts: 1283
    • View Profile
    • http://lnkd.in/nPbhxG
Re: BTC->BTSX Proposal
« Reply #4 on: September 12, 2014, 11:10:13 AM »
VERY related
crosspost:
https://bitsharestalk.org/index.php?topic=8762.0

I've read that. However it requires trust. My proposal requires some additional coding but there is no trust involved (apart from relying on 50% + 1 delegates to do their job, they can always be replaced anyway).

Offline theoretical

Re: BTC->BTSX Proposal
« Reply #5 on: September 12, 2014, 05:21:26 PM »

I've actually been thinking about a similar scheme.  The problem with your scheme is it turns the delegates into fiduciaries, they are responsible for manually sending the bidder's BTC.  This may subject delegates to regulatory scrutiny.

I would be most comfortable with having the bond be paid in BTSX or some BitAsset.  In that case we can just add logic to the BitSharesX blockchain to compensate the Ask order if the BTC's don't show up.  Thus we no longer place responsibility on a single delegate -- it is enforced at the same level as a blockchain as a whole.  However, this would mean that someone with only BTC can't enter the ecosystem, and you point out that this is an important use case.

Because any of this would require all nodes to run a Bitcoin daemon as well (or otherwise talk to the Bitcoin blockchain) in order to validate the delegates' actions, I am thinking this should probably be a new BTSX child blockchain (BitShares Y perhaps?)
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: BTC->BTSX Proposal
« Reply #6 on: September 12, 2014, 05:32:05 PM »

I've actually been thinking about a similar scheme.  The problem with your scheme is it turns the delegates into fiduciaries, they are responsible for manually sending the bidder's BTC.  This may subject delegates to regulatory scrutiny.

I would be most comfortable with having the bond be paid in BTSX or some BitAsset.  In that case we can just add logic to the BitSharesX blockchain to compensate the Ask order if the BTC's don't show up.  Thus we no longer place responsibility on a single delegate -- it is enforced at the same level as a blockchain as a whole.  However, this would mean that someone with only BTC can't enter the ecosystem, and you point out that this is an important use case.

Because any of this would require all nodes to run a Bitcoin daemon as well (or otherwise talk to the Bitcoin blockchain) in order to validate the delegates' actions, I am thinking this should probably be a new BTSX child blockchain (BitShares Y perhaps?)

The original proposal was updated. There should be no need for anyone except delegates to download bitcoin blockchain. Whatever a delegate does is recorded in both blockchain. Anyone can audit anything. As for holding a small amount (bond from BTC holder) this shouldn't be an issue due to the small amount (it could be avoided entirely if the BTC holder is able to directly send to BTCAsker but this should be done almost instantly).

Offline emski

  • Hero Member
  • *****
  • Posts: 1283
    • View Profile
    • http://lnkd.in/nPbhxG
Re: BTC->BTSX Proposal
« Reply #7 on: September 12, 2014, 11:01:28 PM »
Am I the only one who think this should be implemented?

Offline GaltReport

Re: BTC->BTSX Proposal
« Reply #8 on: September 12, 2014, 11:21:15 PM »
I'm sure most would agree with the objective.  How to accomplish the objective is the big question.  Questions that come to my mind are:

1. What is the best technical approach ?
2. Are there any potential legal risks for delegates ?
3. How does this fit or not fit with what BM has planned?

Does anyone know what BM thinks about this?

Offline donkeypong

  • Hero Member
  • *****
  • Posts: 2331
    • View Profile
Re: BTC->BTSX Proposal
« Reply #9 on: September 13, 2014, 04:19:19 AM »
It sounds like something that a third party provider could create. Why not give it a try? Pretty soon, BitShares itself won't be able to cover all these bases at once with limited programming support. People will realize that legitimate business opportunities (not just DACs) exist in these outside niches, and meeting demand in these areas still can benefit the overall BitShares ecosystem.

Offline emski

  • Hero Member
  • *****
  • Posts: 1283
    • View Profile
    • http://lnkd.in/nPbhxG
Re: BTC->BTSX Proposal
« Reply #10 on: September 13, 2014, 04:36:28 AM »
It sounds like something that a third party provider could create. Why not give it a try? Pretty soon, BitShares itself won't be able to cover all these bases at once with limited programming support. People will realize that legitimate business opportunities (not just DACs) exist in these outside niches, and meeting demand in these areas still can benefit the overall BitShares ecosystem.

It cant be done by third party. It needs to be integrated into the code. This essentially makes contract for BTC->BTSX exchange, waits for BTC to be transferred and then forces the exchange of BTSX (of course in the agreed limits). This can be done only with delegate consensus.

This is pretty interesting topic for me. I'd like to do it myself (I feel capable of implementing it, even though someone with more knowledge about the implementation could do it much faster and possibly better).  However I still need my real/dayjob income which prevents me to dedicate to this task. And with my pet projects I'm unable to implement it in my free time...
« Last Edit: September 13, 2014, 04:56:14 AM by emski »

Offline emski

  • Hero Member
  • *****
  • Posts: 1283
    • View Profile
    • http://lnkd.in/nPbhxG
Re: BTC->BTSX Proposal
« Reply #11 on: September 13, 2014, 04:49:44 AM »
I'm sure most would agree with the objective.  How to accomplish the objective is the big question.  Questions that come to my mind are:

1. What is the best technical approach ?
2. Are there any potential legal risks for delegates ?
3. How does this fit or not fit with what BM has planned?

Does anyone know what BM thinks about this?

1 I dont see anything unusual about the technical approach. What is required is already implemented functionality with a bit of custom logic on top of it.
2 There shouldn't be any risk, as in the latest proposal they do not even hold the transferred amount at any time. Delegates just continue to do whatever they do now - keep the consensus, producing and signing blocks.
3 I'd lvery much like ike to see his comments on this.

Currently I see only benefits in such implementation (apart from some work required to implement it initially). Given the fact this shouldn't increase the blockchain or blockchain processing time significantly it shouldn't impact the end user. Delegates however need to be a bit beefy as they need to monitor all cryptocurrencies blockchains (We dont want to stay only with BTC but to get the whole package). However for this delegates could obtain % of the transfers as fees.

Offline luckybit

Re: BTC->BTSX Proposal
« Reply #12 on: September 13, 2014, 07:42:19 AM »
I think we should use Gateways. Push IOUs to the Gateways. You can use delegates if delegates would like to deal with whatever possible licensing then it will be fine. Nothing stops a delegate from being a money exchange company.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline Shentist

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 1605
    • View Profile
    • metaexchange
  • BTS: shentist
Re: BTC->BTSX Proposal
« Reply #13 on: September 13, 2014, 08:15:19 AM »
@emski

i like the idea, but it looks to complicated

what about something like this

we need a bitAsset buyBTSXwithBTC or something

1. BTSX holders can publish to which price they are willing to buy BTC and to which address the transaction has to be made (maybe connect it with a pricefeed form BTER)
- like something i am willing to sell 100.000 BTSX for 0.00008022 recieved from BTER (the latest price not a static price but maybe rescan every 30 sec)
2. Richy only needs to buy my offer on the BTSX exchange
3. now the exchanges waits for an transfer within 3 hours of his BTC to my  BTC address i attached with my order placement - the networks blocks my BTSX (takes it as a colleteral)
4. after the BTSX networks confirms the transfer in the bitcoin network it will release the collateralised BTSX

so we would need "only"

1. a bitAsset you could only buy but not sell
2. a service who is checking the bitcoinblockchain for this kind of transfer

what do you think? hope i explained it undestandable
in my opinion it is much easier and simpler and could be implimented via I3 .

and the best

you could do it with every coin traded with a liquid market on a tradeable exchange
« Last Edit: September 13, 2014, 08:24:51 AM by Shentist »

Offline emski

  • Hero Member
  • *****
  • Posts: 1283
    • View Profile
    • http://lnkd.in/nPbhxG
Re: BTC->BTSX Proposal
« Reply #14 on: September 13, 2014, 08:20:21 AM »
I think we should use Gateways. Push IOUs to the Gateways. You can use delegates if delegates would like to deal with whatever possible licensing then it will be fine. Nothing stops a delegate from being a money exchange company.

In my proposal there should be no additional licensing for delegates. They do not transfer funds at all. They only add transactions into blocks and sign the blocks.

 

Google+