Call it knee-jerk but I personally dislike systems that refer to themselves as hacker proof. I can't help but feel that the people who make that claim misunderstand the fundamentals of information security.
You only have to look at password handling procedures to see recent examples of things once thought hacker-proof that are no longer. MD5 used to be widely used for hashing passwords but it is now considered cryptographically weak and there are many more examples like it throughout the industry. Most (all?) of these hacker-proof like things tend to be based on computational infeasibility or perfect implementation of certain features. In this case, the protocol seems to rely heavily on two things:
- self-destructing database records - Self destructing data is a hard problem that is more likely to be solved using a time-based destruction rather than a read-based destruction (how can you ensure with 100% atomicity that the data will be 100% deleted when it is read?). A good example of a time-based self-destruction is Vanish [1].
- dynamic procedure that is not accessible from memory - The CPU cannot communicate directly with anything but memory/internal caches [2] so the only way I can think that you'd solve this is by having a custom piece of hardware that does all the computation internally and only returns the result. This is also not an easy problem as it introduces hardware level complexities.
I understand that the author may have just been trying to make it sound more interesting but there are better words that don't leave such a bad taste in the readers mouth ("Secure" is a very commonly used one for example). This is especially important when trying to be taken seriously by the security community who are the most likely to take an irrational dislike to something claiming to be hacker-proof.
I agree. When I see "hacker proof", I usually assume it's a corporation that's paid some mid-rate contractor to create a system that's "hacker proof" per their specification (which probably uses those exact words).
I've not seen many serious projects use this term.
This may well be an exception -- it's possible that the authors are not native-English speakers and fail to appreciate the term's nuances. All in all, it looks like a very interesting project, but I'd urge the author to use more different terminology to describe their system.
I didn't mean to imply that time-based was a better solution here, simply that there exists a functional proof of it. I haven't seen a working read-based self-destruction proof (if someone knows of one I'd love to see it).
That being said, I like the idea in general I'm just skeptical of protocols/ideas that rely on things that don't yet exist (unless they go into detail on how they plan to implement them of course).
Really interesting and great work, but it by no means solves the 'coffee customer' problem.
A basic presupposition of this protocol assumes that there exists an address in your control with the exact amount of funds you wish to send. If there isn't, that money has to still come from somewhere, which is the On-block transaction we wanted to avoid.
So, we can transfer pre-existing funds Off-chain very quickly, but quickly setting up new addresses with funds is still fundamentally not possible. This protocol has uses but it doesn't solve the big problem it claims it does.
Ideally, one would combine the protocol with some sort of address exchange criteria. You hold an address with $100 worth of bitcoins. The coffee costs $2. The coffee shop holds an address with $98 worth of bitcoins. You initiate the transaction, effectively swapping the addresses and paying for the coffee. Of course, this presupposes a preset group of prepaid addresses. But what is to stop ys from generating hundreds of prepaid addresses (other than the required finances of course), each ranging from say $50 to $120, and promoting their their general circulation, for the purposes of easier exchange?
mainly the finances. also you'd be copying the structure of current monetary denominations. which may or may not be a bad thing, but I don't see it catching on.
a more likely scenario is said server acting as an payment processor by making a promise to the vendor that 'this address WILL have $x.yz monies in it'. the customer would then either have to prepay the 3rd party or give them information for traditional debt collection purposes.
So, this could be good for paymemt processing. maybe. i havent thought about it for long.
you could also "make change" by exchanging ownership of the $100 address for 5 $20 addresses, and change those down into 10 $2 addresses each. there's very little cost of executing this algorithm several times over for a "single" purchase.
There are problems possessing 10 $2 bitcoins, due to the minimal transaction fee (approximately $.20). Reclaiming the value (putting back On-Blockchain) of $20 worth of $2 dollar addresses will cost you 10%. Then again, %10 is how much Coinstar charges to turn loose change back into dollars. Still, a better alternative is this; replace Bitcoin with a lower-denomination Altcoin (Dogecoin?) to cover preset currency addresses below a certain amount. Dogecoin's transaction fee is negligible, so the reclaiming cost is no longer an issue. Though Dogecoin's fluctuations demand some level of, the lower-denomination restriction makes these fluctuations negligible (By which I mean this; A quarter is more likely to fall out of your pocket than a $10 dollar bill out of your wallet. However, the quarter's ease of use is more important than its potential loss of value, which is relatively negligible when compared to the $10 bill)
Honestly, are people worried about waiting for 6 confirmations for paying for a cup of coffee? In my experience once a transaction has hit the network, and nodes are passing it around, that's good enough for me. I wouldn't be worried about the person standing in front of me doing a double spend...
Interesting...this basically lets me transfer control of my Bitcoin address to some other user, but in a totally safe way! Would not have thought this was possible.
Yep! And without having to rely on the standard, boring, dangerous, database-driven PayPal-esque style schema employed by Coinbase and other third-party sources.
You only have to look at password handling procedures to see recent examples of things once thought hacker-proof that are no longer. MD5 used to be widely used for hashing passwords but it is now considered cryptographically weak and there are many more examples like it throughout the industry. Most (all?) of these hacker-proof like things tend to be based on computational infeasibility or perfect implementation of certain features. In this case, the protocol seems to rely heavily on two things:
- self-destructing database records - Self destructing data is a hard problem that is more likely to be solved using a time-based destruction rather than a read-based destruction (how can you ensure with 100% atomicity that the data will be 100% deleted when it is read?). A good example of a time-based self-destruction is Vanish [1].
- dynamic procedure that is not accessible from memory - The CPU cannot communicate directly with anything but memory/internal caches [2] so the only way I can think that you'd solve this is by having a custom piece of hardware that does all the computation internally and only returns the result. This is also not an easy problem as it introduces hardware level complexities.
I understand that the author may have just been trying to make it sound more interesting but there are better words that don't leave such a bad taste in the readers mouth ("Secure" is a very commonly used one for example). This is especially important when trying to be taken seriously by the security community who are the most likely to take an irrational dislike to something claiming to be hacker-proof.
[1] http://vanish.cs.washington.edu/pubs/usenixsec09-geambasu.pd...
[2] http://wpcontent.answcdn.com/wikipedia/commons/thumb/b/bd/Mo...