61–70 of 79 posts
Or, just use a system like we use on Bitalo, where fractional reserves are impossible because of use of multi-signature Bitcoin addresses, which means funds are specifically tied to user wallets and exchange operators cannot use them without user's signing all transactions by himself.
Earlier quoted context omitted.
Unless the negative valued customer and the surrounding customers never logged in... But thats a limitation of the scheme that can't be avoided. If a user never logs in you could just steal just their balance (and correctly set it to zero). You also must make sure that all customers are seeing the same root, and that you can't do funny business like constantly update it to swap out which customers you're robbing. (e.…
You've got a point, the root of the tree could be made available to the main charting sites.. or even weekly written into the blockchain. As for the negative values, I wasn't thinking of robbing anyone, but just pretending you are solvent when really you're not. I'm not sure I see what you mean by "swap out which customers you're robbing", could you expand?
When customer A logs in you give them one root and show them their balance (and B has a balance of 0). When customer B logs in— oops balances just update— you show them a new root, and in that one B has a balance of 100.
So you need to pin the commitments strongly enough so that the prover can't swap them out at will.
Earlier quoted context omitted.
You've got a point, the root of the tree could be made available to the main charting sites.. or even weekly written into the blockchain. As for the negative values, I wasn't thinking of robbing anyone, but just pretending you are solvent when really you're not. I'm not sure I see what you mean by "swap out which customers you're robbing", could you expand?
E.g. say you have two customers with a balance of 100. You report the total is 100— so 100 BTC has gone missing. When customer A logs in you give them one root and show them their balance (and B has a balance of 0). When customer B logs in— oops balances just update— you show them a new root, and in that one B has a balance of 100. So you need to pin the commitments strongly enough so that the prover can't swap them…
Of course, if many people were connected at the same time, this would quickly become perilous gymnastics for the exchange.
Earlier quoted context omitted.
Sigh. It's a fallacy that making loans implies fractional reserves as normally understood. Banks can still make loans simply by offering certificates of deposit. This is the above-board way of loaning out people's money -- you make it absolutely clear that taking it out early has a cost, because the money is locked up in (hopefully) profitable ventures. Would that be less profitable for the banks? Not really -- they…
What you are saying is that you would replace interest bearing savings accounts with fee charging "idle money" accounts, and that if you want to earn any interest on your savings you have to lock it up for a fixed term. That doesn't really sound like a better alternative.
Or, just use a system like we use on Bitalo, where fractional reserves are impossible because of use of multi-signature Bitcoin addresses, which means funds are specifically tied to user wallets and exchange operators cannot use them without user's signing all transactions by himself.
The blockchain can't handle the transaction volume of currency exchanges; that just won't work.
What happens as businesses (overstock, etc) start accepting bitcoin? Will bitcoin never be able to handle to volume of an amazon or walmart?
Earlier quoted context omitted.
Suppose the balance sheet is: [ -1000, 1000, 2000, 2000 ] The Merkle tree is: [ -1000, 1000, 2000, 2000 ] [ 0, 4000 ] [ 4000 ] You actually owe 5000 BTC, but it seems like you owe 4000 BTC. Seems so far so good. The problem is, what happens if you try to take advantage of this opportunity. Case 1: other people withdraw first. [ -1000, 1000, 0, 0 ] [ 0, 0 ] [ 0 ] Nobody knows that anything nefarious has gone on. Howev…
Oh sure, you can sum and compare the balances under ZKP and even hide the total amount. But the problem is that as soon as you invoke a ZKP for general computation you take into the realm of barely practical moon math. ... And you still don't fix the problem that balances which are unchecked can be diverted. In the IRC log I posted I went on to suggest that a service could have a rule that _permitted_ them to take yo…
> And you still don't fix the problem that balances which are unchecked can be diverted.
Okay, I'll admit I might be missing something here; what do you mean by that? The exchange isn't storing each user's bitcoins separately; that requires one TX per user to maintain anyway. It should be storing them all under a single HD wallet and publicly releasing the MPK, so users can take the MPK and use it to verify that the exchange actually has 5000 BTC, the Merkle root says 5000 BTC, and their Merkle branch is correct. The exchange can't spend "unchecked bitcoins" or "checked bitcoins"; they're all just bitcoins under the same HD wallet, and spending any of them would trigger an alarm.
Earlier quoted context omitted.
Oh sure, you can sum and compare the balances under ZKP and even hide the total amount. But the problem is that as soon as you invoke a ZKP for general computation you take into the realm of barely practical moon math. ... And you still don't fix the problem that balances which are unchecked can be diverted. In the IRC log I posted I went on to suggest that a service could have a rule that _permitted_ them to take yo…
One way to defeat the "hide the negative balances inside a subtree of technologically clueless grandmas" attack might be to generate the tree using some easily verifiable deterministic algorithm (ie. alphabetic order of hashes of some user data), and perhaps even have several trees. It's not perfect, but it could help reduce the problems, although perhaps at the expense of some additional privacy. > And you still don…
> Okay, I'll admit I might be missing something here; what do you mean by that?
Say Alice _never_ logs in anymore and the site has noticed this. The site can just go "oh Alice, her balance in now 0" and go and gamble away those coins— sure, their holdings go down, but so do their obligations. Since Alice never logs in anyone, she's not going to protest that her coins are all gone.
Earlier quoted context omitted.
The blockchain can't handle the transaction volume of currency exchanges; that just won't work.
Wait, the blockchain can't handle the transaction volume of the trades happening today? What happens as businesses (overstock, etc) start accepting bitcoin? Will bitcoin never be able to handle to volume of an amazon or walmart?
The same applies to overstock, coinbase is doing their transaction processing and it's likely most of those are off chain as well as coinbase is a broker and has plenty of coin and dollars in house and is likely where purchasers in the US got their coin anyway as well is also likely being the users online wallet; they settle up daily with an exchange to keep their supply at necessary levels.
Bitcoin isn't ready for mass adoption yet; the infrastructure is still being put into place and the 7 transaction limit has to be removed and exceeded by quite a bit to grow the point of being able to handle large volume kind of stuff. In the meantime, and probably even after, off chain transactions will likely be how most scale is achieved.
Earlier quoted context omitted.
One way to defeat the "hide the negative balances inside a subtree of technologically clueless grandmas" attack might be to generate the tree using some easily verifiable deterministic algorithm (ie. alphabetic order of hashes of some user data), and perhaps even have several trees. It's not perfect, but it could help reduce the problems, although perhaps at the expense of some additional privacy. > And you still don…
> > And you still don't fix the problem that balances which are unchecked can be diverted. > Okay, I'll admit I might be missing something here; what do you mean by that? Say Alice _never_ logs in anymore and the site has noticed this. The site can just go "oh Alice, her balance in now 0" and go and gamble away those coins— sure, their holdings go down, but so do their obligations. Since Alice never logs in anyone, s…
Unless, of course, we finally switch over to a public/private key based login system and each user's balance sheet is composed of a set of authorized/signed deposits, trades and withdrawals (ie. a full blockchain, but centralized and "mined" only by the exchange's server). I wonder what possibilities that kind of setup would open.
Earlier quoted context omitted.
Wait, the blockchain can't handle the transaction volume of the trades happening today? What happens as businesses (overstock, etc) start accepting bitcoin? Will bitcoin never be able to handle to volume of an amazon or walmart?
Exchanges don't trade on the blockchain, only deposits and withdrawls are on chain. Off chain transactions make up the bulk of transactions as the blockchain can currenly only handle around 7 transactions a second which is about twice as much as it's actually being pushed so there's still room to breath. The same applies to overstock, coinbase is doing their transaction processing and it's likely most of those are of…