BTC->BTSX Proposal

[theoretical]

Here is my proposal:  https://github.com/drltc/bitbond-proposal/blob/master/btc-trade.md

TLDR version:  The BitAsset buyer must also post a bond to guarantee delivery, otherwise an attacker could do big no-show transactions to do denial-of-service against the whole market [1].  This is hard when the buyer has only BTC, my solution is to allow buying tiny amounts of BitBTC in an unbonded transaction, then "bootstrapping" into exponentially larger bonded transactions until the desired number of BitWhatever has been purchased.

This process may take a while, so I suggest only allowing BTC to be directly traded for BitBTC to minimize exchange rate worries.  If you wanted BTSX or BitUSD, then you could simply use the BitBTC in the existing on-chain markets.

The tiny unbonded transaction is a user-to-user transaction -- the buyer and seller must find each other and privately negotiate the amount and exchange rate, then participate in user-to-user atomic exchange on the chain.  (I suggest having some TITAN directory information published by the seller to facilitate this, a list of known trustworthy sellers to establish trust on the Ask side, and requiring a non-refundable 10% advance fee from the buyer to make sure the bidder is acting in good faith.  The actual negotiation will likely be done by scripts on both sides hard-coded to trade small amounts at the peg.)

The bonded transactions can be done in a full decentralized on-chain market.  Basically the market only does matching, and then the transaction proceeds as a bonded user-to-user exchange.

[1] This is still possible, but would be fantastically expensive for the attacker.  I suspect no seller will complain about having their orders delayed -- and indeed a ton of new sellers will rush in -- when a repeat no-show buyer is effectively paying interest of 1% per day or more to the whole Ask book out of their own pocket!

[emski]

@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 .

That is similar to my proposal in the achieved result. Which one is simpler is a matter of perspective I'll not argue here. What could be implemented by I3 depends on them.
In either way delegates should monitor the external (BTC) blockchain and enforce/execute/ensure the "contract" on BitsharesX blockchain when BTC party fulfills its part of the deal.
The most important thing here is bypassing external exchanges (at least for cryptocurrencies for now ... until we have "proof of fiat transfer" (: ) and providing means of trustless* currency exchange.
* You just depend on 50% + 1  BTSX delegates to do their job and assumption BTC blockchain is not compromised.

[emski]

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.

[Shentist]

@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

[luckybit]

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.

[emski]

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.

[emski]

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...

[donkeypong]

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.

[GaltReport]

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?

[emski]

Am I the only one who think this should be implemented?

[emski]

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).

[theoretical]

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

[emski]

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).

[xeroc]

VERY related
crosspost:
https://bitsharestalk.org/index.php?topic=8762.0

[emski]

So what, burn btc for btsx?

Nothing is burned.