4 ms·

Correct. As long as you have Turing Complete machines you made theoretical hack possible. This was nicely illustrated by the problem that Ethereum had a while a

Correct. As long as you have Turing Complete machines you made theoretical hack possible. This was nicely illustrated by the problem that Ethereum had a while ago while it would not be possible on Turing incomplete-Bitcoin.

Phithagoras 10y ago
Could you post that Ethereum problem as a story and/or comment? Curious to read it
- hueving 10y ago
  I'm guessing op is just referring to the DAO disaster.
  - sebastianconcpt 10y ago
    Yes I was referring to the DAO disaster. Here are some interesting discussions about it https://www.reddit.com/r/btc/comments/4p0gq3/why_turingcomplete_smart_contracts_are_doomed/ https://www.reddit.com/r/btc/comments/4p0gq3/why_turingcompl...
    - schoen 10y ago
      It would be safer in many of these ways to prefer non-Turing-complete smart contracts -- and non-Turing-complete software environments in general for many tasks -- but I think formal undecidability is something of a red herring here because not all programs' behavior is undecidable. My previous comments on this issue in this context: https://news.ycombinator.com/item?id=11942015 https://news.ycombinator.com/item?id=11942015
- feklar 10y ago
  This also explained it well, predicting contracts would be full of problems http://vessenes.com/ethereum-contracts-are-going-to-be-candy-for-hackers/ http://vessenes.com/ethereum-contracts-are-going-to-be-candy...
mynameislegion 10y ago
That's not the problem; the problem is a lack of awareness about object-capability theory. zooko nailed it: https://twitter.com/zooko/status/748683889934163969 https://twitter.com/zooko/status/748683889934163969 If you have time, read up on the basics: http://www.erights.org/talks/promises/paper/tgc05-submitted.pdf http://www.erights.org/talks/promises/paper/tgc05-submitted....
drdeca 10y ago
I don't follow. Suppose you have a Turing complete machine, with network connection, programmed to respond to 1 particular message with a particular message, and ignore all other messages. It seems clear that this should be possible to make secure against attackers who cannot do physical attacks? I am not sure what you mean.
- sebastianconcpt 10y ago
  That machine you have, because can do general computations (Turing Complete) can be attacked on that message until its stack dumps and you have access to perform general computations on the underlying system where that program was running.
  - drdeca 10y ago
    Its stack? Just because it is Turing complete does not imply that it uses a stack. Consider: look_for := "some string"; n := len(look_for); send_out := "other string"; i := 0; while(true){ c=getInputChar(); if(c==None){ i=0; continue; } if(c==look_for[i]) { i+=1; continue; } if(i==n){ output(send_out); i=0; continue; } //else i=0; continue; } (Pseudo code. No specific language intended.) I see no reason that the above would require a stack (provided that the input and output features are hardware built ins rather than function calls. Just reading or writing from/to a pair of registers.) I see no way that such a program could be exploited (short of flaws in the machine). Causing the stack to dump wouldn't work, as it has no stack. It just cycles through a small number of states based on input. Now, some other program which is much more complicated could be written for the same machine, as the machine is Turing complete, but this particular program would not be vulnerable.
    - sokoloff 10y ago
      If I send that code "some some string" or "ssome string", it fails to respond with "other string" due to a bug. If I send it "sssome string", it does work. (depending on how you interpret the // before the else; if that comments out the else, then brute forcing the input by cycling all characters on the input will eventually cause output.) So, there's a bug and now a maintainer has to go in and patch the bug, which may introduce a security flaw (either in the coding or the release deployment process). You also have the exposure of whatever getInputChar() and output() do internally. I'm not arguing there is an exploit just because of using Turing complete system, but observing that even simple systems tend to have bugs and get maintenance over time.
witty_username 10y ago
> As long as you have Turing Complete machines you made theoretical hack possible. This is false theoretically.
- sebastianconcpt 10y ago
  Why? Can you elaborate on demonstrating that is false?
  - alasdair_ 10y ago
    It's possible to write a program that is provably correct, so simply because a turing machine exists, doesn't mean that the Turing machine itself makes something hackable.
  - witty_username 10y ago
    Hacks occur to due bugs in software. Theoretically, one could write bug-free software. Practically, this is very hard for any non-trivial software. For example, a while loop code in a Turing Machine is unhackable; the state repeats forever.

Phithagoras 10y ago

Could you post that Ethereum problem as a story and/or comment? Curious to read it

hueving 10y ago
I'm guessing op is just referring to the DAO disaster.
- sebastianconcpt 10y ago
  Yes I was referring to the DAO disaster. Here are some interesting discussions about it https://www.reddit.com/r/btc/comments/4p0gq3/why_turingcomplete_smart_contracts_are_doomed/ https://www.reddit.com/r/btc/comments/4p0gq3/why_turingcompl...
  - schoen 10y ago
    It would be safer in many of these ways to prefer non-Turing-complete smart contracts -- and non-Turing-complete software environments in general for many tasks -- but I think formal undecidability is something of a red herring here because not all programs' behavior is undecidable. My previous comments on this issue in this context: https://news.ycombinator.com/item?id=11942015 https://news.ycombinator.com/item?id=11942015
feklar 10y ago
This also explained it well, predicting contracts would be full of problems http://vessenes.com/ethereum-contracts-are-going-to-be-candy-for-hackers/ http://vessenes.com/ethereum-contracts-are-going-to-be-candy...

mynameislegion 10y ago

That's not the problem; the problem is a lack of awareness about object-capability theory. zooko nailed it: https://twitter.com/zooko/status/748683889934163969 https://twitter.com/zooko/status/748683889934163969 If you have time, read up on the basics: http://www.erights.org/talks/promises/paper/tgc05-submitted.pdf http://www.erights.org/talks/promises/paper/tgc05-submitted....

drdeca 10y ago

I don't follow. Suppose you have a Turing complete machine, with network connection, programmed to respond to 1 particular message with a particular message, and ignore all other messages. It seems clear that this should be possible to make secure against attackers who cannot do physical attacks? I am not sure what you mean.

sebastianconcpt 10y ago
That machine you have, because can do general computations (Turing Complete) can be attacked on that message until its stack dumps and you have access to perform general computations on the underlying system where that program was running.
- drdeca 10y ago
  Its stack? Just because it is Turing complete does not imply that it uses a stack. Consider: look_for := "some string"; n := len(look_for); send_out := "other string"; i := 0; while(true){ c=getInputChar(); if(c==None){ i=0; continue; } if(c==look_for[i]) { i+=1; continue; } if(i==n){ output(send_out); i=0; continue; } //else i=0; continue; } (Pseudo code. No specific language intended.) I see no reason that the above would require a stack (provided that the input and output features are hardware built ins rather than function calls. Just reading or writing from/to a pair of registers.) I see no way that such a program could be exploited (short of flaws in the machine). Causing the stack to dump wouldn't work, as it has no stack. It just cycles through a small number of states based on input. Now, some other program which is much more complicated could be written for the same machine, as the machine is Turing complete, but this particular program would not be vulnerable.
  - sokoloff 10y ago
    If I send that code "some some string" or "ssome string", it fails to respond with "other string" due to a bug. If I send it "sssome string", it does work. (depending on how you interpret the // before the else; if that comments out the else, then brute forcing the input by cycling all characters on the input will eventually cause output.) So, there's a bug and now a maintainer has to go in and patch the bug, which may introduce a security flaw (either in the coding or the release deployment process). You also have the exposure of whatever getInputChar() and output() do internally. I'm not arguing there is an exploit just because of using Turing complete system, but observing that even simple systems tend to have bugs and get maintenance over time.

witty_username 10y ago

> As long as you have Turing Complete machines you made theoretical hack possible. This is false theoretically.

sebastianconcpt 10y ago
Why? Can you elaborate on demonstrating that is false?
- alasdair_ 10y ago
  It's possible to write a program that is provably correct, so simply because a turing machine exists, doesn't mean that the Turing machine itself makes something hackable.
- witty_username 10y ago
  Hacks occur to due bugs in software. Theoretically, one could write bug-free software. Practically, this is very hard for any non-trivial software. For example, a while loop code in a Turing Machine is unhackable; the state repeats forever.