3 ms·

You can't really mitigate this entirely as you can't really write software without bugs. There will always be a need for this eventual "please roll back or blo

You can't really mitigate this entirely as you can't really write software without bugs. There will always be a need for this eventual "please roll back or block the bad actors". And more money you put into the game more it will be demanded when someone gets hurt. I don't like crypto but this way of fixing things is pretty normal and standard in software and orher industries also. You simply can run into situations which weren't planned. So i don't think there is a problem with these fixes

lmm 5y ago
> I don't like crypto but this way of fixing things is pretty normal and standard in software and orher industries also. You simply can run into situations which weren't planned. So i don't think there is a problem with these fixes It's normal in most industries, but it also defeats the main selling point of crypto - "code is law" doesn't actually work, you always end up in a world of humans and politics.
- masa331 5y ago
  Yes i agree and i don't think there is actually a problem with that. We are humans and we should be able to solve problems like this. I try to view it just as another way of bug fixing technique. Sometimes you can just explain that you messed up and others will understand
throwaway6734 5y ago
Relying on an external authority to control the allocation of money seems to completely undermine the purpose of crypto. What's to stop these actions being taken for reasons other than theft?
- masa331 5y ago
  You always need to rely on some external authority. You can't crypto/decentralize everything. And relying on external authorities is a good thing actually. Because it's way way more effective than software solutions. Now of course the external authority can compromise sometimes but for this we also already have solutions for like thousands of years - diversification. If people just would learn not to put all their eggs into pne basket and expect eventual compromise that wouldn't be a problem. I think some 101 finances and practical real world problem solutions classes or something like this would get us way further than decentralisig everything with software
moss2 5y ago
When was the last time banking software got hacked?
hoseja 5y ago
Sounds to me like there's a decentralized, trustless incentive to make sure your software is secure. Yelping NO FAIR! and central-bank-style rolling back the oopsie does not seem very radical and libertarian and crypto.
ed_elliott_asc 5y ago
“You can’t really write software without bugs” - which is why crypto will never be for me
- G3rn0ti 5y ago
  This is plain silly. Even centralized payment settlement systems do depend on thousands of lines of closed source code that contain bugs. Banking backends have bugs. Cars have bugs. Even buildings may have fuck ups that need to be dealt with after construction. If you think it through you simply can not rely 100% on anything humans build. But still societies as a whole thrive and human progress is real. DeFi is no exception. It’s designed to make banking cheaper. But it’s new technology and will take some time to mature. Personally, I believe banks won’t exist in the traditional sense anymore 20 years in the future if you like it or don’t. I mean, I love steam locomotives but I don’t expect them to be a common means of transportation ever again. ;-)
  - carlgreene 5y ago
    Centralized payment settlement systems are mutable. That’s the difference and the whole argument. A bug in a DeFi contract? Sorry nothing we can do! Bug in Wells Fargo account settlement code? Ah we’re sorry, let’s roll that back for ya!
    - G3rn0ti 5y ago
      Ethereum contracts are not 100% immutable. They need to maintain state like a token‘s balance. That’s why Ethereum‘s VM supports contract variables. You can also use variables to store addresses to other contracts and call external methods indirectly using these pointer like structures. If I understood the bug correctly, the hacker was able to modify such a pointer and redirect all transactions to a wallet contract she controlled. So this is how you can upgrade contracts: There is the „implementation contract“ pattern. Basically, you define a user-facing proxy contract defining the interface but all it does is delegate user calls to the actual implementation contract by maintaining a variable pointing to it. Using a privileged call you can update that address even after deploying the proxy.
dqpb 5y ago
> you can't really write software without bugs Formal verification

lmm 5y ago

> I don't like crypto but this way of fixing things is pretty normal and standard in software and orher industries also. You simply can run into situations which weren't planned. So i don't think there is a problem with these fixes It's normal in most industries, but it also defeats the main selling point of crypto - "code is law" doesn't actually work, you always end up in a world of humans and politics.

masa331 5y ago
Yes i agree and i don't think there is actually a problem with that. We are humans and we should be able to solve problems like this. I try to view it just as another way of bug fixing technique. Sometimes you can just explain that you messed up and others will understand

throwaway6734 5y ago

Relying on an external authority to control the allocation of money seems to completely undermine the purpose of crypto. What's to stop these actions being taken for reasons other than theft?

masa331 5y ago
You always need to rely on some external authority. You can't crypto/decentralize everything. And relying on external authorities is a good thing actually. Because it's way way more effective than software solutions. Now of course the external authority can compromise sometimes but for this we also already have solutions for like thousands of years - diversification. If people just would learn not to put all their eggs into pne basket and expect eventual compromise that wouldn't be a problem. I think some 101 finances and practical real world problem solutions classes or something like this would get us way further than decentralisig everything with software

moss2 5y ago

When was the last time banking software got hacked?

hoseja 5y ago

Sounds to me like there's a decentralized, trustless incentive to make sure your software is secure. Yelping NO FAIR! and central-bank-style rolling back the oopsie does not seem very radical and libertarian and crypto.

ed_elliott_asc 5y ago

“You can’t really write software without bugs” - which is why crypto will never be for me

G3rn0ti 5y ago
This is plain silly. Even centralized payment settlement systems do depend on thousands of lines of closed source code that contain bugs. Banking backends have bugs. Cars have bugs. Even buildings may have fuck ups that need to be dealt with after construction. If you think it through you simply can not rely 100% on anything humans build. But still societies as a whole thrive and human progress is real. DeFi is no exception. It’s designed to make banking cheaper. But it’s new technology and will take some time to mature. Personally, I believe banks won’t exist in the traditional sense anymore 20 years in the future if you like it or don’t. I mean, I love steam locomotives but I don’t expect them to be a common means of transportation ever again. ;-)
- carlgreene 5y ago
  Centralized payment settlement systems are mutable. That’s the difference and the whole argument. A bug in a DeFi contract? Sorry nothing we can do! Bug in Wells Fargo account settlement code? Ah we’re sorry, let’s roll that back for ya!
  - G3rn0ti 5y ago
    Ethereum contracts are not 100% immutable. They need to maintain state like a token‘s balance. That’s why Ethereum‘s VM supports contract variables. You can also use variables to store addresses to other contracts and call external methods indirectly using these pointer like structures. If I understood the bug correctly, the hacker was able to modify such a pointer and redirect all transactions to a wallet contract she controlled. So this is how you can upgrade contracts: There is the „implementation contract“ pattern. Basically, you define a user-facing proxy contract defining the interface but all it does is delegate user calls to the actual implementation contract by maintaining a variable pointing to it. Using a privileged call you can update that address even after deploying the proxy.

dqpb 5y ago

> you can't really write software without bugs Formal verification