Zero trust Bitcoin “accounts”
Edit: I removed the original proposal after reading hashcoin's suggestion: https://bitcointalksearch.org/topic/instant-tx-for-established-business-relationships-need-replacementsnlocktime-25786
In the event that blockchain transactions are prohibitively expensive/time consuming for some use and you might think a bitcoin account on a website is necessary, think again. With hashcoin's idea described in the link you can have instantaneous, free transactions, without trust, with a single person, all using only Bitcoin's internal transaction scripts.
I figure native the UX would be as follows: clients would allow you to create accounts with people where you optionally enter their addresses if you expect to be receiving transactions as well as sending them, and when you fund it, you'd have to enter a lifetime after which your unspent balance is returned to you, as well as "activate" the funding via some direct communication channel with the person. I imagine the UX would simplify greatly when dealing with a website, since your browser then provides a convenient direct communication channel. Any ideas on how this might all look to the user?
Topic: Eliminating the need to trust in the Bitcoin economy - page 2. (Read 3062 times)
Exchanges that can’t lose or run off with your coins
Edit: I changed some things in this proposal after reading hashcoin's suggestions below
The idea here is for exchanges to be relegated merely to issuers of national currency-backed digital currencies. These digital currencies could then be traded for bitcoins directly, through any escrow (necessary due to Bitcoin's delayed finality of settlement). Hashcoin's idea here https://bitcointalksearch.org/topic/instant-tx-for-established-business-relationships-need-replacementsnlocktime-25786 could then be used to allow the bitcoin seller to avoid the need to trust the escrow.
If necessary, the digital currency issuers can avoid AML/KYC requirements by limiting redemption amounts or comply with them by requiring ID, and limiting the anonymity in the digital currency’s architecture via e.g. anonymity revoking trustees. Irrevocability must be cryptographically ensured, but fraud can be compensated for by charging appropriate fees. I imagine that these fees could be per user, and based on some kind of reputation/cosigning scheme, so as to reduce the "fraud tax" paid by those that are clearly trustworthy. This would also result in much greater liquidity, and allow for easier exploitation of arbitrage opportunities.
The UX would be such that you must manage your own keys to your digital currencies. But I see no reason why the same model that WebCoin will use can’t be used here, so that you only have to keep one key safe that is never updated and rarely used.
Open-Transactions (https://github.com/FellowTraveler/Open-Transactions/wiki) can be used here for issuing the digital currency, but needs further work in order to incorporate backdoors for KYC requirements.
Edit: I changed some things in this proposal after reading hashcoin's suggestions below
The idea here is for exchanges to be relegated merely to issuers of national currency-backed digital currencies. These digital currencies could then be traded for bitcoins directly, through any escrow (necessary due to Bitcoin's delayed finality of settlement). Hashcoin's idea here https://bitcointalksearch.org/topic/instant-tx-for-established-business-relationships-need-replacementsnlocktime-25786 could then be used to allow the bitcoin seller to avoid the need to trust the escrow.
If necessary, the digital currency issuers can avoid AML/KYC requirements by limiting redemption amounts or comply with them by requiring ID, and limiting the anonymity in the digital currency’s architecture via e.g. anonymity revoking trustees. Irrevocability must be cryptographically ensured, but fraud can be compensated for by charging appropriate fees. I imagine that these fees could be per user, and based on some kind of reputation/cosigning scheme, so as to reduce the "fraud tax" paid by those that are clearly trustworthy. This would also result in much greater liquidity, and allow for easier exploitation of arbitrage opportunities.
The UX would be such that you must manage your own keys to your digital currencies. But I see no reason why the same model that WebCoin will use can’t be used here, so that you only have to keep one key safe that is never updated and rarely used.
Open-Transactions (https://github.com/FellowTraveler/Open-Transactions/wiki) can be used here for issuing the digital currency, but needs further work in order to incorporate backdoors for KYC requirements.
Web based wallet that can’t lose or run off with your coins
WebCoin (http://bitcoinjs.org/) seems to have the right model here: They split the private keys between your device(s) and their server, and require you to enter a PIN to access theirs. The keys are recombined only during transactions, thereby minimizing the time they face the Internet. If you enter the PIN wrong too many times they lock it, and to unlock it you have to provide a master key that you securely store offline. All of your keys are derived from this master key, so it provides a backup that’s valid in perpetuity. You also use this master key to activate other devices.
The UX should be dead simple with Webcoin – safely store one single key that’s never updated, and rarely used, and enter a short PIN when you want to make a transaction.
You do give their server access to your public keys, though, so you end up trusting them with your transaction history.
Edit: This seems relevant:
That's the most common argument leveraged against LastPass, and it's indeed valid (see below). The solution, so far not implemented anywhere, is to sign a hash of the JS snippet in question and have that verified by the client. When the code needs an update it has to be vetted before clients approve a new hash or signature.
I believe this is on its way into the HTML specifications but I haven't looked for some time. If we control the client implementation (Android, PCs) it's however implementable already today.
In the LastPass case, they are considered trusted (reputation, company) and the architecture is meant to protect against hacking instead. They take great care to make sure their systems serving up the JS in question aren't easily manipulated, and if a hacker were to extract their databases they still cannot do anything with them since everything is encrypted and only the end users have the corresponding keys.
WebCoin (http://bitcoinjs.org/) seems to have the right model here: They split the private keys between your device(s) and their server, and require you to enter a PIN to access theirs. The keys are recombined only during transactions, thereby minimizing the time they face the Internet. If you enter the PIN wrong too many times they lock it, and to unlock it you have to provide a master key that you securely store offline. All of your keys are derived from this master key, so it provides a backup that’s valid in perpetuity. You also use this master key to activate other devices.
The UX should be dead simple with Webcoin – safely store one single key that’s never updated, and rarely used, and enter a short PIN when you want to make a transaction.
You do give their server access to your public keys, though, so you end up trusting them with your transaction history.
Edit: This seems relevant:
Not giving you my private keys for storage, but using the data stored with you together with my local secret every time a key is needed.
But how would you see that work with a web service? You could implement a large part of the Bitcoin protocol in JS, but if it is served from the wallet provider, it could steal any key that you enter by injecting a keylogger into the JS as well.That's the most common argument leveraged against LastPass, and it's indeed valid (see below). The solution, so far not implemented anywhere, is to sign a hash of the JS snippet in question and have that verified by the client. When the code needs an update it has to be vetted before clients approve a new hash or signature.
I believe this is on its way into the HTML specifications but I haven't looked for some time. If we control the client implementation (Android, PCs) it's however implementable already today.
In the LastPass case, they are considered trusted (reputation, company) and the architecture is meant to protect against hacking instead. They take great care to make sure their systems serving up the JS in question aren't easily manipulated, and if a hacker were to extract their databases they still cannot do anything with them since everything is encrypted and only the end users have the corresponding keys.
tl;dr = Open-Transactions' digital cash, Bitcoin's transaction scripts, and Webcoin's key management scheme can be combined in various ways to solve all the trust issues plaguing the Bitcoin economy, without compromising convenience.
Over-reliance on trust within the Bitcoin economy has obviously failed horribly. I believe it’s largely unnecessary, so I’m starting this thread to try to converge on some better standards that bitcoiners could reasonably expect from their service providers.
I'll start with a few ideas mostly borrowed from elsewhere:
Over-reliance on trust within the Bitcoin economy has obviously failed horribly. I believe it’s largely unnecessary, so I’m starting this thread to try to converge on some better standards that bitcoiners could reasonably expect from their service providers.
I'll start with a few ideas mostly borrowed from elsewhere:
Jump to: