[warbiscuit]

1) No counterparty risk. Everyone can get hacked, but coinbase being hacked shouldn't every, under any circumstances result in me loosing any bitcoin they hold on my behalf.

This point may prove to be very sticky.

It might be solvable with smart contracts... consider ethereum's https://www.etherdelta.com, which operates as an auditable smart contract. Your money literally can't be stolen without your private key; even when it's held in escrow by the contract. (Of course, a bug in the contract code could let someone get through; but that's all out in the open, so easier to check for).

I could see something like that being done, with the individual trade data being signed, but held off-chain until the user wanted to make a transfer (then ALL signed movements related to them could be consolidated on the chain).

---

Short of that, a centralized exchange is gonna run into the fundamental issue that cryptocurrencies have value because of a few properties; Chief among them being that they can be moved atomically, and with non-repudiation. Those two alone make theft a LOT easier to get away with once achieved.

Being able to walk back such thefts would require general consensus of the network. For most coins, the majority of participants would see that as a fatal weakening of the protocol's guarantees, and drop out. The highest profile rollback I can think of was ETH's june 2017 DAO incident. Even that proved rather controversial: though the market voted in favor in the end, it was a messy out-of-band solution, which may not work again.

---

Conversely, some lesser coins such as NAV actually formalized "consensus voting" on such out-of-band issues as part of their network protocol. I could potentially see that being used as a final band-aid, though "tyranny of the majority" issues would seriously need solving. NAV uses proof-of-stake, though, which certainly helps keep their voting in the "put your money where your mouth is" territory.

All in all, I think there are potentially some trustless and "semi-trustless consensus" methods that could solve this issue in revolutionary ways. But none of them are tested... Coinbase may just have to get themselves massively insured using traditional methods, at least for a few more years as the tech expands.

[nybble41]

>> 1) No counterparty risk. Everyone can get hacked, but coinbase being hacked shouldn't every, under any circumstances result in me loosing any bitcoin they hold on my behalf. > This point may prove to be very sticky. It might be solvable with smart contracts...

Shouldn't be that hard, even using just the features available in Bitcoin today. You'd need a 2-of-2 multisignature wallet for each account holder, with one key held by Coinbase and the other by the user. When the user wants to spend some coins, he or she signs a transaction which Coinbase prepares and counter-signs; neither the user nor Coinbase—or an attacker with access to Coinbase's keys—can transfer the funds unilaterally.

The only thing missing is a convenient UI.

[warbiscuit]

That's pretty much exactly how the EtherDelta smart contract works. The contract can only move coins you've signed an order for, and only when it's properly paired with a matching counter-order.

I think the mainly catch would be scaling the speed (etherdelta is limited to the ETH network block rate). I don't know too much about lightning's details, but given that they've demonstrated atomic cross-chain swaps, I bet it's set up to handle something exactly like what's needed.

Which is quite exciting... I just always moderate my enthusiasm because for all complex software projects, the devil (and 80% of the work) is in the details :)

[empath75]

This is what insurance is for.

If they can’t insure deposits, then that shows a fundamental weakness in the security model.

[warbiscuit]

That is one reason why I'm actually kinda wild about distributed exchange like etherdelta (as proof of concept, at least). The security model is such that it literally doesn't exist in any country, anywhere in the world; doesn't have servers that can be hacked, etc.

(Admittedly the website is housed somewhere, but it's little more than a GUI shell for signing procedure calls, you could run it locally or interact directly).

I think the big issue hindering that model is that they need something allowing users to pipe into traditional currencies. So far all the solutions to that have been IOU tokens like USDT tethers; which end up generating governance headaches of their own, as their value desyncs from their base currency due to arbitrage & supply issues.

[empath75]

do you honestly think that smart contracts can't be hacked?

[warbiscuit]

Oh, I definitely think they can. Didn't mean to imply otherwise!

I do think the surface area for attack is much more limited, since the code is innately public (unlike centralized trading houses).

That (in theory) should make them more secure, particularly if considered in terms of the transparency provided. I also think theorem proving, and languages amenable to it, can greatly reduce the surface area even further; reducing it down to a matter of reviewing what assertions the theorem prover was handed, along with trusting the VM's implementation itself. (The later is also helped by having multiple independant implementations).

But I don't think the tech is there yet. The languages currently being used aren't the greatest for theorem proving; no one's actually done much of that in practice anyways; there aren't "best practices" for upgrading your smart contract when a bug is found; and there's ALWAYS an assertion someone forgot to add to the test suite.

But I do think smart contracts could remove "server compromise" and "unauditable code" from the list of main dangers of an exchange, which does seem quite useful in the long term (once the ecosystem fleshes out a bit).

[warbiscuit]

Followup just to clarify: The reason smart contracts drastically mitigate "server compromise" is that compromising / altering the operation of the VM (and not merely exploiting a bug) requires a 51% attack on the entire network. That should generally be a MUCH more expensive undertaking than the value of any given smart contract (under the assumption that the network will be valued at least 2x more than any of it's participating apps).

[empath75]

You don't need to implement a 51% attack to hack a smart track, as evidenced by the dozens of smart contracts that have been emptied out on ethereum.

[d10r]

I looked at the Etherdelta code and I believe that's in a class of complexity which can indeed be made unhackable.

[notyourday]

There's no insurance company that would write a blanked insurance policy for BTC. It is the other side of the "We are BTC! We are special! Rules of finance do not apply to us!" coin.