BTC->BTSX Proposal

[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