3 ms·

It's nonsense to suggest that any two Turing-complete programming languages are equally safe or secure. C, Rust, and Haskell are all Turing-complete, and while

It's nonsense to suggest that any two Turing-complete programming languages are equally safe or secure. C, Rust, and Haskell are all Turing-complete, and while of course it's possible to write buggy code in all of them, certain classes of bugs that are possible in C are not possible in Haskell. > there is no possibility of 'higher level abstractions' that will permit only legitimate contracts to be written True, but there is the possibility of trivial changes that would prohibit some exceptionally catastrophic bugs. The language features that allowed last weeks multisig walled bug (delegation to an unknown function, public initialization code, the possibility of calling initialization code after initialization) need not be like that. A much better language could still be Turing complete but exclude such things (forcing you to write explicit code that shoots you in the foot, if you so wish).

mannykannot 9y ago
> It's nonsense to suggest that any two Turing-complete programming languages are equally safe or secure. Well, I didn't suggest it - it seems you are inventing that notion because you are obliged to agree with everything I actually wrote. The point is not the relative safety of one language against another, but whether, in absolute terms, Ethereum will become safe enough for the sort of wide-ranging uses that its promoters envisage. If the sort of examples you present here are sufficient for that, then, given that security and correctness have been prized for long before Ethereum, one has to wonder why they have not already been used to create languages that are already secure and bug-resistant enough for Ethereum. There is certainly some basic changes that could make Ethereum more secure, but past experience in this field suggests there is a whole range of hills beyond this one. And in security matters, going part-way is not much of an advance at all; such defenses can, like the Maginot line, be outflanked.
- tom_mellior 9y ago
  >> It's nonsense to suggest that any two Turing-complete programming languages are equally safe or secure. > Well, I didn't suggest it - it seems you are inventing that notion You wrote: "Writing provably-secure smart contracts is as difficult as writing provably-secure software for any other Turing-complete platform". This is not true. Writing provably-secure smart contracts in something like C would be strictly harder than in Solidity because there are more classes of possible errors, and hence more properties to be proved. There are meaningful differences in the ease of proof even among Turing-complete languages. And some things you would have to prove explicitly for programs in one language are automagically "proved" for you by other languages' compilers. So yes, you did suggest that any two Turing-complete languages are equally safe and secure. > because you are obliged to agree with everything I actually wrote Haha. No.
  - mannykannot 9y ago
    Not so - that quote suggests that there is a lower bound on the difficulty of proving security; that whatever language you choose, it is still difficult. And even if you were right, it would be a non-sequitur, on the grounds of relative versus absolute difficulty that I gave before.

mannykannot 9y ago

> It's nonsense to suggest that any two Turing-complete programming languages are equally safe or secure. Well, I didn't suggest it - it seems you are inventing that notion because you are obliged to agree with everything I actually wrote. The point is not the relative safety of one language against another, but whether, in absolute terms, Ethereum will become safe enough for the sort of wide-ranging uses that its promoters envisage. If the sort of examples you present here are sufficient for that, then, given that security and correctness have been prized for long before Ethereum, one has to wonder why they have not already been used to create languages that are already secure and bug-resistant enough for Ethereum. There is certainly some basic changes that could make Ethereum more secure, but past experience in this field suggests there is a whole range of hills beyond this one. And in security matters, going part-way is not much of an advance at all; such defenses can, like the Maginot line, be outflanked.

tom_mellior 9y ago
>> It's nonsense to suggest that any two Turing-complete programming languages are equally safe or secure. > Well, I didn't suggest it - it seems you are inventing that notion You wrote: "Writing provably-secure smart contracts is as difficult as writing provably-secure software for any other Turing-complete platform". This is not true. Writing provably-secure smart contracts in something like C would be strictly harder than in Solidity because there are more classes of possible errors, and hence more properties to be proved. There are meaningful differences in the ease of proof even among Turing-complete languages. And some things you would have to prove explicitly for programs in one language are automagically "proved" for you by other languages' compilers. So yes, you did suggest that any two Turing-complete languages are equally safe and secure. > because you are obliged to agree with everything I actually wrote Haha. No.
- mannykannot 9y ago
  Not so - that quote suggests that there is a lower bound on the difficulty of proving security; that whatever language you choose, it is still difficult. And even if you were right, it would be a non-sequitur, on the grounds of relative versus absolute difficulty that I gave before.