4 ms·

I get as exasperated at C++ as anyone else, but IMO there's another takeaway here, which is that smart contracts are an absolutely terrible idea. Relying on cod

by saghm 1y ago

I get as exasperated at C++ as anyone else, but IMO there's another takeaway here, which is that smart contracts are an absolutely terrible idea. Relying on code as the source of truth for a transaction just completely disregards the reality that code is always going to be buggy. For those who might not be aware, this is the same smart contract framework where someone accidentally killed $300 million of transactions because a function in a library for setting the wallet associated with a private key was defined as public instead of private: https://medium.com/cybermiles/i-accidentally-killed-it-and-evaporated-300-million-6b975dc1f76b https://medium.com/cybermiles/i-accidentally-killed-it-and-e... Yes, you can fix issues like this with a "hard fork" if you have a large enough consensus, but at that point, does the system of having smart contracts actually improve anything over the one where the software is downstream rather than the source of truth, or are you just replacing one form of "human intervention required" with a different but worse one?

usmannk 1y ago
This is about a language compiler bug. There are no takeaways about smart contracts here.
- tsujamin 1y ago
  So long as you’re writing your smart contracts with a chisel, into a stone tablet, with no compilers or assemblers in sight!
  - tkz1312 1y ago
    The bug was a simple segfault and did not result in the production of invalid or incorrect code.
    - saghm 1y ago
      Segfaults are the lucky case when you run into undefined behavior. The unlucky case is that you just get a program doing something different than what you intended without any clear indication that something went wrong.
- saghm 1y ago
  It's about a compiler bug in C++ that had downstream effects in the compiler for Solidity, which is a language for developing smart contracts. Yes, every compiler can have bugs, even ones not relating to smart contracts, but that doesn't seem like a very convincing argument that we should be using compilers for more things rather than boring regular code that isn't considered to be contractual.
charcircuit 1y ago
You can fix smart contracts without a hard fork. In fact it's common practice for them to be upgradable.
- saghm 1y ago
  Does it fix them only going forward, or does it actually update what happened in previous transactions retroactively? If the latter, does everyone involved with any transactions using the said contract have a say in whether the upgrade occurs? I'm skeptical that this would actually be a good mechanism in general given how likely it seems that some contracts might be so widely used to essentially require a hard fork in order to upgrade retroactively, but I'm open to the idea that I might be missing something here.
  - charcircuit 1y ago
    It only updates the code that will run. Fixing it going forward. To protect oneself against losses due to bugs people can use insurance smart contracts.
    - saghm 1y ago
      I guess I'm just skeptical that writing more code to try to protect against code being buggy will result in a system that works better than what we have today. Software with tests written for it still has plenty of bugs, after all.
      - charcircuit 1y ago
        Expecting code to be perfect and code complete the first time around is typically a losing bet.
        saghm 1y ago
        I completely agree, which is why I don't think that contracts should be expressed in code in the first place. You have to spend a lot of effort up front just to reach parity with contractual systems that don't rely on code, and even if you get to that point, it's not really clear to me what benefits you'd get over what we have today.
RealityVoid 1y ago
As opposed to being subject to interpretation of the truth, with the courts of varying quality. My point is... everything has error bars.
- eightysixfour 1y ago
  It must. Things that interact with the real world need slack.
- sealeck 1y ago
  > with the courts of varying quality You can usually pick the jurisdiction (e.g. many contracts are under jurisdiction of England & Wales/Switzerland/Singapore despite neither party being based there, or doing business there). I think in general judges are quite considered, and the answers you get from courts tend to make quite a lot of sense, especially if you are aware of general legal principles and precedent.
- josefx 1y ago
  You are still subject to courts if you use smart contracts, they change literally nothing about that.
- saghm 1y ago
  The reliance on context and human intervention in our current system is a feature, not a bug. That's my entire point; if you get rid of that, you're introducing a lot of issues, and if you don't, you're throwing out a system with literal centuries of stress-testing where the flaws are legitimate but well understood to switch to one with literally no evidence to suggest that it's better.

by saghm 1y ago

usmannk 1y ago

This is about a language compiler bug. There are no takeaways about smart contracts here.

tsujamin 1y ago
So long as you’re writing your smart contracts with a chisel, into a stone tablet, with no compilers or assemblers in sight!
- tkz1312 1y ago
  The bug was a simple segfault and did not result in the production of invalid or incorrect code.
  - saghm 1y ago
    Segfaults are the lucky case when you run into undefined behavior. The unlucky case is that you just get a program doing something different than what you intended without any clear indication that something went wrong.
saghm 1y ago
It's about a compiler bug in C++ that had downstream effects in the compiler for Solidity, which is a language for developing smart contracts. Yes, every compiler can have bugs, even ones not relating to smart contracts, but that doesn't seem like a very convincing argument that we should be using compilers for more things rather than boring regular code that isn't considered to be contractual.

charcircuit 1y ago

You can fix smart contracts without a hard fork. In fact it's common practice for them to be upgradable.

saghm 1y ago
Does it fix them only going forward, or does it actually update what happened in previous transactions retroactively? If the latter, does everyone involved with any transactions using the said contract have a say in whether the upgrade occurs? I'm skeptical that this would actually be a good mechanism in general given how likely it seems that some contracts might be so widely used to essentially require a hard fork in order to upgrade retroactively, but I'm open to the idea that I might be missing something here.
- charcircuit 1y ago
  It only updates the code that will run. Fixing it going forward. To protect oneself against losses due to bugs people can use insurance smart contracts.
  - saghm 1y ago
    I guess I'm just skeptical that writing more code to try to protect against code being buggy will result in a system that works better than what we have today. Software with tests written for it still has plenty of bugs, after all.
    - charcircuit 1y ago
      Expecting code to be perfect and code complete the first time around is typically a losing bet.
      - saghm 1y ago
        I completely agree, which is why I don't think that contracts should be expressed in code in the first place. You have to spend a lot of effort up front just to reach parity with contractual systems that don't rely on code, and even if you get to that point, it's not really clear to me what benefits you'd get over what we have today.

RealityVoid 1y ago

As opposed to being subject to interpretation of the truth, with the courts of varying quality. My point is... everything has error bars.

eightysixfour 1y ago
It must. Things that interact with the real world need slack.
sealeck 1y ago
> with the courts of varying quality You can usually pick the jurisdiction (e.g. many contracts are under jurisdiction of England & Wales/Switzerland/Singapore despite neither party being based there, or doing business there). I think in general judges are quite considered, and the answers you get from courts tend to make quite a lot of sense, especially if you are aware of general legal principles and precedent.
josefx 1y ago
You are still subject to courts if you use smart contracts, they change literally nothing about that.
saghm 1y ago
The reliance on context and human intervention in our current system is a feature, not a bug. That's my entire point; if you get rid of that, you're introducing a lot of issues, and if you don't, you're throwing out a system with literal centuries of stress-testing where the flaws are legitimate but well understood to switch to one with literally no evidence to suggest that it's better.