BTC->BTSX Proposal

[tonyk]

bump!

[emski]

My understanding is your proposal was to divide nodes into two groups:

- Delegate nodes determine whether delivery was completed by examining the BTC blockchain
- Non-delegate nodes determine whether delivery was completed by checking if delegate nodes published a signed statement saying delivery was completed

Where from , you manage to derive this nonsense?

It might have been a poor choice of words.  I was referring to when emski said:

There should be no need for anyone except delegates to download bitcoin blockchain.

So by "two groups," I meant that in emski's proposal:

- Group 1:  Delegates download the Bitcoin blockchain and run some algorithm, to determine whether the BTC were delivered.
- Group 2:  Non-delegates do not download the Bitcoin blockchain, so they must use a different algorithm to determine whether the BTC were delivered.

I think it is safer to have every node run the same algorithm and check the BTC blockchain to determine whether the BTC were delivered.  (It is more resource intensive on all nodes, too, but I believe the security of users' funds is more important.)

Does that clear things up?

As well as , how did you come with the rest of your baseless conclusions, in other thread on this forum?

I've been posting a lot lately, in many different threads.  I have no idea what discussion you are referring to.

nodes other than delegates are irrelevant. They could as well monitor btc blockchain but that doesn't matter.

[emski]

btsx becomes spendable on transaction cancel or completion + possible dispute time 1-6 hours for example or depending on currency ONLY if we care that much for 51 delegate conspiration.

The other day I had a Bitcoin transaction take ~3 hours to be confirmed.  I wasn't doing anything weird, it was a totally normal payment to a single address (plus change address) generated by the Bitcoin core client.

If that happens, what does your proposal do?

My proposal requires the Bitcoin to be provably unconfirmable (based on the Bitcoin transaction's expiration time) before the BTSX blockchain is allowed to conclude it will not show up.

I call this tweakable detail that might impact only confirmation time....

[tonyk]

I've been posting a lot lately, in many different threads.  I have no idea what discussion you are referring to.

Chose, the one you feel most combatable defending...

[theoretical]

My understanding is your proposal was to divide nodes into two groups:

- Delegate nodes determine whether delivery was completed by examining the BTC blockchain
- Non-delegate nodes determine whether delivery was completed by checking if delegate nodes published a signed statement saying delivery was completed

Where from , you manage to derive this nonsense?

It might have been a poor choice of words.  I was referring to when emski said:

There should be no need for anyone except delegates to download bitcoin blockchain.

So by "two groups," I meant that in emski's proposal:

- Group 1:  Delegates download the Bitcoin blockchain and run some algorithm, to determine whether the BTC were delivered.
- Group 2:  Non-delegates do not download the Bitcoin blockchain, so they must use a different algorithm to determine whether the BTC were delivered.

I think it is safer to have every node run the same algorithm and check the BTC blockchain to determine whether the BTC were delivered.  (It is more resource intensive on all nodes, too, but I believe the security of users' funds is more important.)

Does that clear things up?

As well as , how did you come with the rest of your baseless conclusions, in other thread on this forum?

I've been posting a lot lately, in many different threads.  I have no idea what discussion you are referring to.

[theoretical]

btsx becomes spendable on transaction cancel or completion + possible dispute time 1-6 hours for example or depending on currency ONLY if we care that much for 51 delegate conspiration.

The other day I had a Bitcoin transaction take ~3 hours to be confirmed.  I wasn't doing anything weird, it was a totally normal payment to a single address (plus change address) generated by the Bitcoin core client.

If that happens, what does your proposal do?

My proposal requires the Bitcoin to be provably unconfirmable (based on the Bitcoin transaction's expiration time) before the BTSX blockchain is allowed to conclude it will not show up.

[tonyk]

btsx are unspendable in my proposal until transaction is canceled or completed

My understanding is your proposal was to divide nodes into two groups:

- Delegate nodes determine whether delivery was completed by examining the BTC blockchain
- Non-delegate nodes determine whether delivery was completed by checking if delegate nodes published a signed statement saying delivery was completed

Now if the delegates lie and say delivery was completed, when in fact it was not -- then the BTSX become spendable because all non-delegate nodes only validate the delegates' statement about what happened to the BTC, not what actually happened to the BTC.

In effect, you're making the delegates the final gatekeepers to those BTSX.  Currently, even if delegates collude and lie, they still cannot give your funds to anybody else unless you have signed a transaction authorizing it [1].  Your proposal opens the door to that being possible, and I am not comfortable with it.

[1] In the case of transactions in the currently implemented markets, the delegates cannot give your funds to a matching order without also giving you the consideration you demanded in your offer.  I.e. if you place an order to buy BitUSD with your BTSX, the only way the network can give your BTSX to someone else is if you get BitUSD in return, in the proportion you asked for.

Where from , you manage to derive this nonsense?
As well as , how did you come with the rest of your baseless conclusions, in other thread on this forum?

[emski]

There is no division of nodes in my proposal. It is the same situation as it is now. Only delegates matter.

btsx becomes spendable on transaction cancel or completion + possible dispute time 1-6 hours for example or depending on currency ONLY if we care that much for 51 delegate conspiration.

[theoretical]

btsx are unspendable in my proposal until transaction is canceled or completed

My understanding is your proposal was to divide nodes into two groups:

- Delegate nodes determine whether delivery was completed by examining the BTC blockchain
- Non-delegate nodes determine whether delivery was completed by checking if delegate nodes published a signed statement saying delivery was completed

Now if the delegates lie and say delivery was completed, when in fact it was not -- then the BTSX become spendable because all non-delegate nodes only validate the delegates' statement about what happened to the BTC, not what actually happened to the BTC.

In effect, you're making the delegates the final gatekeepers to those BTSX.  Currently, even if delegates collude and lie, they still cannot give your funds to anybody else unless you have signed a transaction authorizing it [1].  Your proposal opens the door to that being possible, and I am not comfortable with it.

[1] In the case of transactions in the currently implemented markets, the delegates cannot give your funds to a matching order without also giving you the consideration you demanded in your offer.  I.e. if you place an order to buy BitUSD with your BTSX, the only way the network can give your BTSX to someone else is if you get BitUSD in return, in the proportion you asked for.

[tonyk]

I am not sure I understood what is different in your proposal compared to mine

Not much, the money (BTC) go directly to the buyers account (If I understood they do not go there in yours (but in some delegate/escrow fund), might be a misunderstanding on my part).

In updated proposal btc go directly to buyer. No need for escrow. Just a fee goes to delegate on posting a bid.

And the first delegate to 'see' the BTC transfer on BTC blockchain just confirms includes the BTC/BTSX transaction on the BTSX  chain? Sounds good to me. (I have no opinion on the BTC forks issues, but I am sure you guys can figure it out)

[emski]

I am not sure I understood what is different in your proposal compared to mine

Not much, the money (BTC) go directly to the buyers account (If I understood they do not go there in yours (but in some delegate/escrow fund), might be a misunderstanding on my part).

In updated proposal btc go directly to buyer. No need for escrow. Just a fee goes to delegate on posting a bid.

[tonyk]

I am not sure I understood what is different in your proposal compared to mine

Not much, the money (BTC) go directly to the buyers account (If I understood they do not go there in yours (but in some delegate/escrow fund), might be a misunderstanding on my part).

[emski]

I am not sure I understood what is different in your proposal compared to mine

[tonyk]

As for the case when 51 delegates conspire - this is lack of consensus and require hard fork (just as any other type of misbehavior.  Nothing is different).

Such misbehavior is easy to prove and it is easily reversible - new delegates honoring the contract.

This is true in the current implementation, where the worst thing a 51 delegate attack can do is selectively deny service to some transactions.

Alice gets bitcoins from Eve.  Delegates claim Alice received BTC, so Eve gets Alice's BTSX.

Eve immediately cashes out the BTSX on BTER for Dogecoins.  BTER spreads the BTSX around to many other traders.

A few hours later, Alice is stirring up a storm on the forums and people evaluate the evidence, realize the delegates are untrustworthy, and an immediate hard fork is implemented.

A hardfork with a new group of delegates can't take anything away from Eve, her BTSX are long gone.  Returning the stolen BTSX descended from the illegal transaction would hurt the innocent third parties who unknowingly bought the stolen coins on an exchange.  Printing new BTSX to make Alice whole would simply be spreading the hit from the theft out to all BTSX holders through dilution.  Reverting the chain to the state before the theft would hurt merchants who delivered physical goods or other cryptocurrency in exchange for BTSX / BitAssets, only to see their balance evaporate when the chain reverted.

btsx are unspendable in my proposal until transaction is canceled or completed

In mine too.
Now, what don't you like in my changes. Why I am the only one spared? 

[emski]

As for the case when 51 delegates conspire - this is lack of consensus and require hard fork (just as any other type of misbehavior.  Nothing is different).

Such misbehavior is easy to prove and it is easily reversible - new delegates honoring the contract.

This is true in the current implementation, where the worst thing a 51 delegate attack can do is selectively deny service to some transactions.

Alice gets bitcoins from Eve.  Delegates claim Alice received BTC, so Eve gets Alice's BTSX.

Eve immediately cashes out the BTSX on BTER for Dogecoins.  BTER spreads the BTSX around to many other traders.

A few hours later, Alice is stirring up a storm on the forums and people evaluate the evidence, realize the delegates are untrustworthy, and an immediate hard fork is implemented.

A hardfork with a new group of delegates can't take anything away from Eve, her BTSX are long gone.  Returning the stolen BTSX descended from the illegal transaction would hurt the innocent third parties who unknowingly bought the stolen coins on an exchange.  Printing new BTSX to make Alice whole would simply be spreading the hit from the theft out to all BTSX holders through dilution.  Reverting the chain to the state before the theft would hurt merchants who delivered physical goods or other cryptocurrency in exchange for BTSX / BitAssets, only to see their balance evaporate when the chain reverted.

btsx are unspendable in my proposal until transaction is canceled or completed

[tonyk]

As for the case when 51 delegates conspire - this is lack of consensus and require hard fork (just as any other type of misbehavior.  Nothing is different).

Such misbehavior is easy to prove and it is easily reversible - new delegates honoring the contract.

This is true in the current implementation, where the worst thing a 51 delegate attack can do is selectively deny service to some transactions.

Alice gets bitcoins from Eve.  Delegates claim Alice received BTC, so Eve gets Alice's BTSX.

Eve immediately cashes out the BTSX on BTER for Dogecoins.  BTER spreads the BTSX around to many other traders.

A few hours later, Alice is stirring up a storm on the forums and people evaluate the evidence, realize the delegates are untrustworthy, and an immediate hard fork is implemented.

A hardfork with a new group of delegates can't take anything away from Eve, her BTSX are long gone.  Returning the stolen BTSX descended from the illegal transaction would hurt the innocent third parties who unknowingly bought the stolen coins on an exchange.  Printing new BTSX to make Alice whole would simply be spreading the hit from the theft out to all BTSX holders through dilution.  Reverting the chain to the state before the theft would hurt merchants who delivered physical goods or other cryptocurrency in exchange for BTSX / BitAssets, only to see their balance evaporate when the chain reverted.

Oooo come one, get real.

If some Evil bought the whole BTSX system,OK 51%, you are really screwed.... 

And your solutions is???

[theoretical]

As for the case when 51 delegates conspire - this is lack of consensus and require hard fork (just as any other type of misbehavior.  Nothing is different).

Such misbehavior is easy to prove and it is easily reversible - new delegates honoring the contract.

This is true in the current implementation, where the worst thing a 51 delegate attack can do is selectively deny service to some transactions.

Alice gets bitcoins from Eve.  Delegates claim Alice received BTC, so Eve gets Alice's BTSX.

Eve immediately cashes out the BTSX on BTER for Dogecoins.  BTER spreads the BTSX around to many other traders.

A few hours later, Alice is stirring up a storm on the forums and people evaluate the evidence, realize the delegates are untrustworthy, and an immediate hard fork is implemented.

A hardfork with a new group of delegates can't take anything away from Eve, her BTSX are long gone.  Returning the stolen BTSX descended from the illegal transaction would hurt the innocent third parties who unknowingly bought the stolen coins on an exchange.  Printing new BTSX to make Alice whole would simply be spreading the hit from the theft out to all BTSX holders through dilution.  Reverting the chain to the state before the theft would hurt merchants who delivered physical goods or other cryptocurrency in exchange for BTSX / BitAssets, only to see their balance evaporate when the chain reverted.

[emski]

So what if we had a system where you only pay the huge fee temporarily, then get it refunded when you actually deliver, so the only one who actually pays the fee is someone whose BTC never shows up?

It sounds pretty good...in fact, that's exactly what I proposed in the first place

Yeah, makes sense to me.

the question here is who will keep the deposit. In my case it is a fee paid in advance. Misbehaviour can be diminished with higher fees or shorter time periods.

[emski]

I also think that supporting as much as possible cryptocurrencies is better option than BTC only. The only heavyllifting will be done by delegates and they should decide how much alts should be supported.

I think that part of your proposal gives too much power to delegates.  As it is, even the largest collusion of delegates can only do denial-of-service on the network, right now they cannot e.g. give Alice's BitBTC to Eve -- even if all 101 delegates agree that should happen, it will not unless there's a signed transaction from Alice.  But if only delegates validate the BTC blockchain, then a majority of delegates can collude to claim Eve delivered BTC in fulfillment of Alice's order, when in fact Eve did no such thing.

All nodes should validate any transactions that cause funds to change hands instead of just trusting the delegates.  Since the whole "delegate" thing is itself very new, we should be conservative in what we allow delegates to do.

I agree that supporting more cryptocurrencies will add benefit, but storing and validating another blockchain will also impose costs on all nodes that validate BTC transactions.  Having all nodes validate makes this cost burden greater, but I think the security of the network is more important than reducing nodes' costs.  Which logically leads to the conclusion that we should only allow the most limited set of cryptocurrencies -- perhaps only one.  And if we only support one, that one should obviously be BTC.

Curently dpos rely only on delegates. No other validation matters. My proposal does not require full btc node. The only requirement is to know if specific transaction is in btc blockchain. No need to validate the whole btc blockchain. Furthermore there are enough reliable sources for that.

For the same reason validation of alt blockchains shouldn't have huge overhead.

As for the case when 51 delegates conspire - this is lack of consensus and require hard fork (just as any other type of misbehavior.  Nothing is different).

Such misbehavior is easy to prove and it is easily reversible - new delegates honoring the contract.

I'll reiterate the end  goal:
Regardles of technical implementation under the hood - the end user should be able to trade btc for bitassets the same way he currently does bitasset trading.

[theoretical]

sounds like a nice idea. But it seems more like an implementation detail right now, as nobody has started implementing this yet..

It's a lot easier to change the design of a system to take possible attack vectors into account BEFORE the code is written.

And once the code is written, people are going to say "Let's launch right now and damn the consequences," especially with the looming launch of what I think will be a major competitor (Ethereum).  We've already been through this once -- I gather that some key people wanted to hold off launching for a while to polish things in dry runs, but dacsunlimited went ahead and launched BTSX anyway.  (We can't really know which side of that argument was right, because we can't know with certainty what would have happened the hypothetical world in which the BitShares launch was delayed a couple months.)

But I still think it's good to figure out as much as possible before launch.

[yellowecho]

So what if we had a system where you only pay the huge fee temporarily, then get it refunded when you actually deliver, so the only one who actually pays the fee is someone whose BTC never shows up?

It sounds pretty good...in fact, that's exactly what I proposed in the first place

Yeah, makes sense to me.

[tonyk]

- What would happen if Eve makes a Bid order (or many Bid orders from different addresses) that offers 1,000,000 BTC and matches the whole Ask book (which Eve has no intention of paying)?

I think Eve losses his transaction fees after 5 BTC blocks - i.e. no problem except for about one hour.

So anyone would be able to shut down the whole market indefinitely, at a cost of one transaction fee per hour.  That sounds secure... [/sarcasm]

Unless we make tx fees huge.  Then fiduciary exchanges like BTER or MtGox take all the customers because they can offer way smaller fees.

So what if we had a system where you only pay the huge fee temporarily, then get it refunded when you actually deliver, so the only one who actually pays the fee is someone whose BTC never shows up?

It sounds pretty good...in fact, that's exactly what I proposed in the first place

sounds like a nice idea. But it seems more like an implementation detail right now, as nobody has started implementing this yet..

[theoretical]

- What would happen if Eve makes a Bid order (or many Bid orders from different addresses) that offers 1,000,000 BTC and matches the whole Ask book (which Eve has no intention of paying)?

I think Eve losses his transaction fees after 5 BTC blocks - i.e. no problem except for about one hour.

So anyone would be able to shut down the whole market indefinitely, at a cost of one transaction fee per hour.  That sounds secure... [/sarcasm]

Unless we make tx fees huge.  Then fiduciary exchanges like BTER or MtGox take all the customers because they can offer way smaller fees.

So what if we had a system where you only pay the huge fee temporarily, then get it refunded when you actually deliver, so the only one who actually pays the fee is someone whose BTC never shows up?

It sounds pretty good...in fact, that's exactly what I proposed in the first place

[tonyk]

Couldn't the delegates just monitor if the BTC has arrived in the BTSX seller account (BTC address) directly:

- If no(at least unconfirmed) after say 5 BTC blocks - free-up the BTSX held (in kind of collateral if you would like), and re-activate the buy BTC order.

- If yes //BTC - sign the transaction sending the BTSX to the BTC seller.

I think you're mixing up "buy" and "sell".  I think your proposal is basically equivalent to what I propose.

But consider:

- What would happen if Eve makes a Bid order (or many Bid orders from different addresses) that offers 1,000,000 BTC and matches the whole Ask book (which Eve has no intention of paying)?

- What would happen if there is a BTC fork which ultimately results in transferring Bob's BTC to Alice, after the delegates have decided Bob won't deliver and free up Alice's order to go to someone else?

This is why I say the buyer must be bonded, and the order must remain matched until you can prove delivery can never happen (barring a BTC fork longer than REQUIRED_CONFIRMATION_COUNT blocks).

I rarely mix buy and sell orders (It has happened in practice, mainly because it is not standardize which goes on left and which on right). Not in this case though....  

- What would happen if Eve makes a Bid order (or many Bid orders from different addresses) that offers 1,000,000 BTC and matches the whole Ask book (which Eve has no intention of paying)?

I think Eve losses his transaction fees after 5 BTC blocks - i.e. no problem except for about one hour.

- What would happen if there is a BTC fork which ultimately results in transferring Bob's BTC to Alice, after the delegates have decided Bob won't deliver and free up Alice's order to go to someone else?


Now, that I do not know - on blocks/forks and other IT/crypto aspects I am in the low 2% of expertize, as this forum goes.

[theoretical]

I prefer not to use trading in increments in the form you proposed. I think that the better option is market solution where the willingnes for an exchange (BTC->BTSX) is expressed in BitsharesX blockchain. Then market fees/bonds paid in both blockchains. Then BTC holder makes payment. And then delegates ensure contract fulfillment on BitsharesX blockchain.

The problem is that, if the bond is in BTC, then the BTSX blockchain has no way to enforce moving the bond on non-delivery (unless you want to create fiduciaries, which goes against everything BitShares stands for).  If the bond is paid in BitBTC, this is no problem.  But the whole point of a post earlier in this thread is that a buyer with BTC and only BTC should be a supported use case.  Such a buyer cannot post a bond or pay a fee in BitBTC, because they have no BitBTC!

My proposal then is to have them pay a BTC fee directly to the seller.  If evil, the seller can then non-deliver BitBTC, I get around this by forcing the fee to be tiny (0.001 BTC so you only lose ~$0.50 worth of BTC if seller is dishonest) and only dealing with sellers on a trusted list (you can get on the list by being a delegate, having convinced the list maintainers that you are a known honest community member, others have told the list maintainers that they have completed successful past transactions with you, etc.)

You don't have to trade in those quantized amounts if you have BitBTC.  If you do not have BitBTC, then:

- Use an unbonded transaction to get a tiny amount of BitBTC if you have none (sellers will likely impose a very high fee and strict limit on the amount because it's unbonded, I'm thinking ~0.010 BitBTC would be a reasonable default limit)
- Use your BTC to buy as many BitBTC as possible in a bonded transaction, using your tiny BitBTC balance as your bond
- Repeat the previous step until "as many BTC is possible" makes you overshoot the amount you actually want, then in that case just buy as many as you need to round out the amount you want.

This can all be implemented in a client-side script that automates the transactions, the user just says "I want to convert 7.654 BTC to BitBTC", presses the "Go" button, and waits for the script to do its thing.

The only reason the amounts are quantized is because I'm thinking 0.010 would be a standard "entry level" amount of BitBTC, and 10% is (in my proposal) the maximum bond which will allow all sellers to be matched.  Thus if you only want say, 0.030 BitBTC, then once you have your initial 0.010 BitBTC you are free to use 0.002 BitBTC as your bond and offer to buy 0.020 BitBTC (this will give you a total of 0.030 BitBTC once you deliver and get your bond back.)  You're free to use 0.010 as a 1% bond to buy up to 1 BTC, but you will get less favorable price for this since you can only match the part of the Ask book willing to accept 1% bond.

[theoretical]

Couldn't the delegates just monitor if the BTC has arrived in the BTSX seller account (BTC address) directly:

- If no(at least unconfirmed) after say 5 BTC blocks - free-up the BTSX held (in kind of collateral if you would like), and re-activate the buy BTC order.

- If yes //BTC - sign the transaction sending the BTSX to the BTC seller.

I think you're mixing up "buy" and "sell".  I think your proposal is basically equivalent to what I propose.

But consider:

- What would happen if Eve makes a Bid order (or many Bid orders from different addresses) that offers 1,000,000 BTC and matches the whole Ask book (which Eve has no intention of paying)?

- What would happen if there is a BTC fork which ultimately results in transferring Bob's BTC to Alice, after the delegates have decided Bob won't deliver and free up Alice's order to go to someone else?

This is why I say the buyer must be bonded, and the order must remain matched until you can prove delivery can never happen (barring a BTC fork longer than REQUIRED_CONFIRMATION_COUNT blocks).

[theoretical]

I also think that supporting as much as possible cryptocurrencies is better option than BTC only. The only heavyllifting will be done by delegates and they should decide how much alts should be supported.

I think that part of your proposal gives too much power to delegates.  As it is, even the largest collusion of delegates can only do denial-of-service on the network, right now they cannot e.g. give Alice's BitBTC to Eve -- even if all 101 delegates agree that should happen, it will not unless there's a signed transaction from Alice.  But if only delegates validate the BTC blockchain, then a majority of delegates can collude to claim Eve delivered BTC in fulfillment of Alice's order, when in fact Eve did no such thing.

All nodes should validate any transactions that cause funds to change hands instead of just trusting the delegates.  Since the whole "delegate" thing is itself very new, we should be conservative in what we allow delegates to do.

I agree that supporting more cryptocurrencies will add benefit, but storing and validating another blockchain will also impose costs on all nodes that validate BTC transactions.  Having all nodes validate makes this cost burden greater, but I think the security of the network is more important than reducing nodes' costs.  Which logically leads to the conclusion that we should only allow the most limited set of cryptocurrencies -- perhaps only one.  And if we only support one, that one should obviously be BTC.

[tonyk]

BTC address need to be included in any buy BTC order.( alternatively can be associated with each BTSX account, if this is easier to do)

After matching BTC bid and asks (payable in BTSX in the BTSX exchange).

Couldn't the delegates just monitor if the BTC has arrived in the BTSX seller account (BTC address) directly:

- If no(at least unconfirmed) after say 5 BTC blocks - free-up the BTSX held (in kind of collateral if you would like), and re-activate the buy BTC order.

- If yes //BTC - sign the transaction sending the BTSX to the BTC seller.


 

[emski]

I slightly disagree with your ONLY BTC->bitBTC policy.
There could be "speed trading", when the BTC transaction should be made within 10 minutes and confirmed in about an hour. So the price fluctuations are not that important. Furthermore even 1h is better than an exchange as the exchange need to first confirm your BTC and then send you bitBTC. However I see no reason to enable only BTC->BTSX. BTC->bitBTC could be allowed too. (infact it doesn't matter which pair BTC->BTSX or BTC->bitBTC is enabled as long as we have such ability.)

I also think that supporting as much as possible cryptocurrencies is better option than BTC only. The only heavyllifting will be done by delegates and they should decide how much alts should be supported.

I prefer not to use trading in increments in the form you proposed. I think that the better option is market solution where the willingnes for an exchange (BTC->BTSX) is expressed in BitsharesX blockchain. Then market fees/bonds paid in both blockchains. Then BTC holder makes payment. And then delegates ensure contract fulfillment on BitsharesX blockchain.

The best user experience in my opinion should be:
A client that can monitor multiple blockchains.
A market on BTSX blockhain that supports any of the proposed cross-chain trading market solutions.
The whole procedure being as simple as trading of market-issued assets for the end user.
I believe this is doable and will be beneficial for the BitsharesX.

[grizmin]

Not that I don't like lazy people, in fact I even admire them. How much time did you spent  thinking  of this concept

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

[cryptillionaire]

So what, burn btc for btsx?

[emski]

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