

A CryptoCubic Protocol for Hacker-Proof Off-Chain Bitcoin Transactions [pdf] - the_decider
http://www.bincoin.com/cryptocubic.pdf

======
roganartu
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.

[1]
[http://vanish.cs.washington.edu/pubs/usenixsec09-geambasu.pd...](http://vanish.cs.washington.edu/pubs/usenixsec09-geambasu.pdf)

[2]
[http://wpcontent.answcdn.com/wikipedia/commons/thumb/b/bd/Mo...](http://wpcontent.answcdn.com/wikipedia/commons/thumb/b/bd/Motherboard_diagram.svg/600px-
Motherboard_diagram.svg.png)

~~~
eximius
time based leads to logistical problems. 'Oops, we deleted your money! Sorry!'

~~~
roganartu
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).

------
eximius
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.

~~~
the_decider
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?

~~~
bencxr
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.

~~~
the_decider
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)

------
pontifier
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...

------
the_decider
We'll execute an open-source version of the Protocol during the YC Hackathon
this weekend.

------
Ivanushka
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.

~~~
the_decider
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.

~~~
Ivanushka
Cool! Can I actually get some code to play with?

~~~
the_decider
Initial code will be available on GitHub Sunday evening.

