User owns a key protected by his password and your server never knows it. Another key is stored unencrypted on the web server (like in "hot" wallet). Third key is stored with your staff, encrypted by their personal password (like in "cold" wallet).
Normal withdrawal: user key and web server's key sign the transaction and it's instantly available.
1. User forgot their password: he contacts staff that uses their key + web server's key to move funds to new destination.
2. Hackers have taken the web server: they see the key, but it's not enough to move anyone's funds.
3. Staff lost their keys: users still can access their funds if they still remember their passwords.
4. Hackers stole user's computer: they may instantly withdraw some amount up to an arbitrary daily limit. (Withdrawal can also be protected by 2-factor authentication.)
5. Hackers stole staff's keys (e.g. from a personal computer): they still need to break into web server. When staff realizes that keys are compromised, all funds must be moved immediately to new keys.
In other words, users have a hard proof of ownership of specific coins. All coins, no exception, are protected by two differently stored keys. So no need for hot/cold wallet difference.
If you want to block some BTC for trading, webserver will implement that easily: when you withdraw coins, it will move blocked portion to someone else's address.
I view a project as a whole: its face, its code, its features. If people can criticize elegance or efficiency of the code, why can't they criticize elegance or efficiency of its brand? Rails, for instance, is an example of a project where people did not just "do code", but also promoted best practices, designed a nice website, created a blog etc. That inspired Ruby & RubyGems to ultimately have nice websites and logos, contributed for free by professional designers.
Any open source project will help more people if it has a friendly face: well-documented code, nice logo, well-written articles explaining motivation behind technical decisions and so on. All of this contributes to the project's overall utility.
There's a product/market fit thing going on here. Rails is the kind of project that caters to the kind of people who value and can contribute "nice websites and logos" because that is what a lot of them do for a living with Rails.
Add a startup-like website to the GNU binutils project and it's going to look pretty dumb to the no-nonsense crowd that needs assemblers. A "nice website" website is not going to extend the appeal of cross-assembling ARM microcontroller code on a x86-64 one bit.
When I was a student at university in 2003-2008, I loved, loved, loved Mathematica language, Mathematica uncluttered cell-based editor and rich interactive documentation. You could execute and edit examples right in the doc! I did so many things: nicely formatted pages (much easier to type in complex formulas than in LaTeX), computing simulations, crazy charts etc. I never could understand how people can use Matlab or Maple when there is Mathematica.
Yeah I liked it as well; the notebook execution especially. Makes me sad to see how primitive iPython/iHaskell now are compared to the Mathematica editor almost 20 years ago. I hoped it would be the about same experience or better, but it's far from. Especially the web version for iHaskell (I assume the iPython web version is the same?) is horrible, absolutely horrible. But the idea is great and it is possible to make it work well as Wolfram has shown.
Well this is how it is now I'm afraid. There are "data scientists" using IPython convinced that they themselves and the tools they use are on the cutting edge. Like there are database people who think MongoDB is advanced. Or web guys using their favourite "framework" kidding themselves they're doing anything more complicated than Perl CGIs did in 1994.
It's like an Amiga owner being shown a "multimedia" PC in 1995 and thinking, I was doing all this 10 years ago.
Amiga example works; took me definitely over 10 years to stop saying that after I was forced to move to PCs. And then I had it with Unix (SparcStation 5s which never crashed and never had to be rebooted against our uni's 100s of PCs which were mandatory rebooted during the night otherwise they were unusable during the day, and still were actually), luckily everyone listened and we're all using that now. Well no, but at least you CAN now without being hopelessly crippled.
Thing is ; these notebook interfaces COULD be really brilliant, but they suck and I don't know why. Maybe just not enough people working on them?
How much do the people working on them get paid to work on them?
What many users of open source don't seem to understand is that actually, honest-to-goodness open source development is a major undertaking and imposition on a person's time. And quality software takes actual teams of actual people with experience and commitment and a basic peace-of-mind about paying their mortgage and putting food on the table.
No, it's more subtle than that. If you have paying customers and hence money, you can pay for experts in domain X to sit down with your programmers and finesse the product. If you don't, then what you have is a wishlist of features but no real, deep understanding of what users use them for. That's why the GIMP is the GIMP, every feature under the sun, in a horrible mishmash interface and for more of its life unusable for professional work because the one feature it really needed, 16-bit colour, wasn't prioritized because none of the devs realized they needed to.
You are right and I do understand that actually. So instead of whining I'll go help improve it. Not the web version for now though; the everything web thing is not working for me as at least my i7/16gb/ssd system is far too slow for productive work in that kind of context.
I wish Mathematica had vi editing mode. As it is now editing the command line is stupid slow for someone who has lived in vim for 20 years now.
This is why I love IPython on the command line. Language is nicer too and editing is a breeze. Of course Python and available libraries are not much of a symbolic computing environment, but for the kinds of problems I deal with its faster to get things done than in Mathematica.
As the author of IHaskell, I'd love to know what you find lacking! (I agree that there's still a lot of room for improvement) The front-end is entirely IPython, so there's probably not much I can do other than contribute to ipython, but would love to hear concrete suggestions (feel free to use github issues).
Sorry if I came on a bit strong ; it was serious disappointment on my side as Haskell hacker and user of Mathematica for my Master almost 20 years ago. Of course yourr work is valued by me and many others and I will try to to work on the iPython interface myself as well as writing the above I thought; why not.
I would definitely say that the smoothness of the Mathematica interface, the way it works and interacts currently would be a great thing for programming languages like Haskell. It's just clumsy the way it is now and this is not something you can help but it needs fixing. Let's discuss further somewhere!
Very good arguments, thanks. I'll try to refute all of them.
1. Contract in a programming language does not leave room for misinterpretation. If there are N conditions to unlock money, they are all well-defined (unless there's a bug in the entire system, of course). Since there's no room for interpretation, lawyers do not need to "cover many cases" (like they do today so their opponents don't find a loophole). Compare Bitcoin itself (a bunch of C and C++ code) with the current financial system and all the laws and regulations. Bitcoin's code may be shitty, but it's much more strict, consistent and well-defined than all these thousands of pages of law. Law is never consistent even with itself, not only with law of other countries or particular decisions of courts.
In other words, you transform an informal problem "this guys agrees to do some ill-defined work" into a formal problem "we both lock up insurance deposit which makes both of us interested in resolving all uncertainties to mutual satisfaction". It does not need to work for everyone, but it's potentially a much better insurance against misinterpretation of contracts than the need to go to an awfully expensive court+lawyers. Some people will find it useful for them, others will stick to some other means.
3. You can encode exception-handling as an optional third party arbiter right in the contract. Only bigger risk takers will start using cryptocontracts and assume all the risks due to bugs or surprising social issues. As time goes by, bugs will be weeded out, worst solutions thrown away and replaced by better solutions. Your mom will use this stuff after million iterations with a low risk of something go wrong. Also, cryptocontracts don't encode life or death. They only encode movement of limited amount of funds. If you don't put all your life's savings in one contract, you don't risk losing all your life savings.
4. Very disagree about cost. Programmatic contracts will be used voluntarily and only because they are cheaper than going to a lawyer or risking going to a court. Or paying a fee to some 3rd party. Also, in many cases the cost of using orthodox legal system is infinite - for some contracts, or in some countries, or in some businesses (extreme example - black market), legal system is simply unavailable. There are many-many people who cannot afford lawyers or non-corrupt judges to solve their problems. Cryptocontracts are low-cost solution for them.
You can build arbitration into contracts right now, and they're largely enforceable. Bitcoin just reduces the enforcement cost. The challenge for arbitration, programmatic or otherwise, is deciding who the arbitrator will be. One of the problems is that arbitrators have their own perverse incentive to decide things in the favor of "repeat players" rather than on a truly objective basis.
gamblor956 17 minutes ago | link
The problem is, and always will be, constructing the
contract in such a way that it is comprehensive and
comprehensible. We have yet to master that in languages
that have existed for thousands of years; it is highly
unlikely we'll master that within the limited framework
of a a programming language which by its nature can't
address unanticipated situations.
The fact that something hasn't happened doesn't mean that it will never happen, nor does the age of a language imply its usefulness for any particular purpose (and no language spoken on Earth has remained unchanged for hundreds, let alone thousands of years).
The formal notations introduced by mathematicians allowed for an explosion of knowledge and discovery that wasn't possible using plain language, while improving simplicity. Consider which is more understandable: a² + b² = c², or the sum of the squares of the two sides is equal to the sum of the squares of the hypotenuse.
Similarly, I expect that some day, given the right innovation in language, technology, or procedure, we could produce an equivalent leap forward in the way we think of laws, contracts, politics, and governments.
The paper only discusses blind signature algorithm: how to prepare a "blinded" public key and then produce a matching signature, also blinded from the signer. The primary motivation is to use such blinded public keys in the standard Bitcoin multisignature transactions. That is, transactions, using N public keys and requiring M signatures (M <= N). "Multiparty computation" with "threshold system" here are provided by Bitcoin automatically, paper does not discuss that. But it shows how such multiparty signing can be done absolutely privately, when neither party (except for initiator and holder of funds) can learn which transaction they allowed to spend.
"The paper only discusses blind signature algorithm"
No, it seems to discuss something else. It starts out talking about blind signatures, then veers off with claims like this:
"The novelty of the scheme is that unlike the original Chaum blind signature scheme, this one does
not allow anyone to prove that the signing party signed a particular message"
I am not actually sure what you are trying to say there. Does it mean that I can only narrow down the possible signers to some group? Does it mean that the signature key is ephemeral, yet somehow meaningful?
To put it another way, what differentiates your proposal from this:
Yeah confused. If you can't tell who signed a particular message, then what are signatures for? I thought they were for authentication, which means the message was not modified, and, I know who sent it.
Good question. I answered it in the paper (just 8 pages) which you obviously haven't read before asking.
Keybase is a single point of failure. Or your machine that will do KDF. M-of-N multisig transactions are way safer because to sign a specific transaction you never need to have all secret material at once on a single machine. If my PC is compromised, I can still independently verify specific transaction I want to sign and send it out to my friends to sign. All their private keys are stored on independent machines which normally aren't compromised altogether by the same attacker.
On specific problem with brainwallets - low entropy. One specific problem with web apps: no code signing. Even if your SSL pubkey is pinned (which is not supported by any browser yet), the code you receive from the server is never remembered and pinned (like with installed apps). If their server is silently compromised tomorrow, someone may humbly hijack keys of 1% of the users and go undetected for quite some time.
Sorry, but the question was quite disrespectful. We are presenting a high-security solution to an important problem and the ignorant observer proposes to use something extremely unsafe and insecure as an alternative without even trying to understand the problem.
Here's the motivation, right on the first page:
"This can be viewed as an ultimate solution for secure storage of bitcoins as no individual computer system can be fully trusted (e.g. even RNG may leak information about private keys through ECDSA signatures ). By spreading the trust between several independently operating computers the risk is significantly reduced. The attacker not only has to compromise several computers instead of just one, but beforehand they must find out which computers are involved (which is made much harder when blind signatures are being exchanged). Therefore the scheme enables safer Bitcoin storage on conventional personal computers and smartphones without need for specialized hardware or compromising privacy."
To my excuse, I only allowed myself to be a bit arrogant while providing a respectful answer anyway. This both answers the question and signals that something can be improved in the discussion.
The scheme allows never holding all secret pieces in one place to make a transaction. Otherwise, if your machine is compromised, someone can send your money elsewhere. I don't quite understand your proposal, but it requires having all chunks in one place to make a transaction.
The multisig vault makes sense for relatively large stash which would take a lot of $50 transactions to brake down into. Also, as you ask your friends to sign off $50 redeeming txs, they'd see how much did you have previously. Not ideal.
In my paper I propose using sequential generation of parameters so you can break down your funds into multiple transactions, but it's only for convenience, your privacy vis-a-vis your friends is still absolute.
Consider that people freely decided to keep money in MtGox. The whole currency is unaffected. But when your central bank decides something (e.g. to issue more currency or do a haircut), then suddenly all banks and all holders are affected. Example of MtGox is an example why Bitcoin is important and actually works as promised: one company misbehaves, others not affected.