4 ms·

A CryptoCubic Protocol for Hacker-Proof Off-Chain Bitcoin Transactions [pdf]

29 points by the_decider 12y ago

the_decider 12y ago
We'll execute an open-source version of the Protocol during the YC Hackathon this weekend.
Ivanushka 12y ago
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 12y ago
  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 12y ago
    Cool! Can I actually get some code to play with?
    - the_decider 12y ago
      Initial code will be available on GitHub Sunday evening.
eximius 12y ago
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 12y ago
  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?
  - eximius 12y ago
    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.
  - bencxr 12y ago
    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 12y ago
      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)
roganartu 12y ago
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.pdf http://vanish.cs.washington.edu/pubs/usenixsec09-geambasu.pd... [2] http://wpcontent.answcdn.com/wikipedia/commons/thumb/b/bd/Motherboard_diagram.svg/600px-Motherboard_diagram.svg.png http://wpcontent.answcdn.com/wikipedia/commons/thumb/b/bd/Mo...
- eximius 12y ago
  time based leads to logistical problems. 'Oops, we deleted your money! Sorry!'
  - roganartu 12y ago
    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).
deleted 12y ago
[deleted]
pontifier 12y ago
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...

29 points by the_decider 12y ago

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

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 12y ago
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 12y ago
  Cool! Can I actually get some code to play with?
  - the_decider 12y ago
    Initial code will be available on GitHub Sunday evening.

eximius 12y ago

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 12y ago
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?
- eximius 12y ago
  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.
- bencxr 12y ago
  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 12y ago
    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)

roganartu 12y ago

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.pdf http://vanish.cs.washington.edu/pubs/usenixsec09-geambasu.pd... [2] http://wpcontent.answcdn.com/wikipedia/commons/thumb/b/bd/Motherboard_diagram.svg/600px-Motherboard_diagram.svg.png http://wpcontent.answcdn.com/wikipedia/commons/thumb/b/bd/Mo...

eximius 12y ago
time based leads to logistical problems. 'Oops, we deleted your money! Sorry!'
- roganartu 12y ago
  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).

deleted 12y ago

[deleted]

pontifier 12y ago

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