Live data from Hacker News

The collapse of the IRON stable coin

irony-97882.medium.com

431–440 of 502 posts

Re: The collapse of the IRON stable coin

#431
post #5

This has always been the problem with smart contracts. They are infact dumb contacts. To program one you need to think about all the edge cases. The programmers here likely did want >0 here. The possibility that the thing feeding price data return zero incorrectly was higher than the price legitimately being zero in their minds. There is no court or lawyer who can interpret the spirit of the contract.

> There is no court or lawyer who can interpret the spirit of the contract. That's obviously the point, though. You are trading one set of risks for a completely different set of risks that might suit your use case much better; your counterparty being able to contest a contract in court could very well be a "bad" thing for you.

Anyone interested in codified risk should read about rai stones.

Re: The collapse of the IRON stable coin

#432

Earlier quoted context omitted.

From the article: "[EDIT: I’ve since learned that the developer(s?) behind this are already the laughing stock of the DeFi community, having wrecked each of their 3 previous projects (now 4) — though this might be their biggest hit yet]"

In other words: find a way to short their fifth project.

That seems like a poor idea when the collapse of this project was preceded by their failing token doubling in price before falling to zero. You’d need an unknown amount of collateral for an unknown period of time.

Re: The collapse of the IRON stable coin

#433
post #279

Earlier quoted context omitted.

So, as a thought experiment, because of the nature of the bug that $272M is locked until such time as TITAN becomes worth > 0. And TITAN is printed by the system itself, whenever IRON is Outside of abusing the oracle, that seems like a pretty pickle.

Yep. It's a self collapsing system.

A self licking ice cream cone, without the ice cream.

https://en.wikipedia.org/wiki/Self-licking_ice_cream_cone

Re: The collapse of the IRON stable coin

#434
post #5

This has always been the problem with smart contracts. They are infact dumb contacts. To program one you need to think about all the edge cases. The programmers here likely did want >0 here. The possibility that the thing feeding price data return zero incorrectly was higher than the price legitimately being zero in their minds. There is no court or lawyer who can interpret the spirit of the contract.

Smart contracts is a horrible name. The better analogy (which has been around for years) is that they are the digital equivalent of (snack and beverage) vending machines. As with vending machines, they have their use cases, but they aren't lawyer "smart" and they certainly aren't legal contracts. I'm not sure how much trouble a better name would have saved everyone, but it might have done a better job of setting expe…

The vending machine analogy is exactly how smart contracts were first introduced by Nick Szabo and Vitalik Buterin.

https://bitcoinmagazine.com/technical/daos-scary-part-1-self...

Re: The collapse of the IRON stable coin

#435

Earlier quoted context omitted.

I am against smart contracts because we do not know how to write software in that way. I like how they sparked a formal verification Renaissance of sorts but that did not help much either unfortunately (if the premise is wrong, no amount of proof will save you anyway). However, if you let all parties review the smart contract (the source is on the chain, you can check it) and agree with it's workings and sign a 'huma…

> but we are adults here: if you agree to put money in smart contracts, you should have verified the code. And if you think the code is flawed, do not put money: otherwise do not complain afterwards. It is not that hard. That's not how it works. Courts generally operate by ambiguous standard of what reasonable people and reasonable experts can actually do given the state of technology. No reasonable software engineer…

Sure, that will depend on the courts and specific case, as it seems it works exactly like this mostly. But if you inspected the code yourself and you put your money in anyway and it is gone, you might find that the court will not do anything at all. And who can you shout at then, the moon? I am saying that smart contracts are a special case: they are small pieces of code, if they have a bug, it usually causes major damage and, if they run on the eth chain etc and no one took public responsibility for deploying it, there is no one to sue. We have no way to write this type of bombs without flaws as you rightly say and because of the irrevocable damage and the lack of defendant in most cases, these contracts should not be used at all.

There are already (many) cases like this, but if I write some software and put it in github, someone else deploys it and people die; that is simply not my fault: it is the deploying person. In normal situations, this is easy to find the defendant here: but on the chain, you won't be able to: anyone can deploy anything and you won't know who it was. So unless you to end open source software, you have no case against anyone.

Re: The collapse of the IRON stable coin

#436
post #72

I found this article interesting, but the HN title ("Off-by-one error...") doesn't match the article's, or its conclusion? The article mentions a boundary condition ("_share_price > 0"), not an off-by-one error.

The off by one error is that the condition should have been >= 0

[deleted]

Re: The collapse of the IRON stable coin

#437

Earlier quoted context omitted.

> There is no court or lawyer who can interpret the spirit of the contract. That's obviously the point, though. You are trading one set of risks for a completely different set of risks that might suit your use case much better; your counterparty being able to contest a contract in court could very well be a "bad" thing for you.

> That's obviously the point, though. You are trading one set of risks for a completely different set of risks. But that's exactly the point. People are not able to interpret "smart" contracts. For normal contracts most people can understand the contract and if there is a dispute you have laws and courts who can interpret in every case. In case of "smart" contracts even the contract developers more often than not see…

People use a lot of things in everyday life that they don't understand. I don't have to understand how a car works to use it, for example.

Re: The collapse of the IRON stable coin

#438

Earlier quoted context omitted.

> Trusting any smart contract of sufficient complexity is like trusting that a code base has absolutely zero bugs and zero unanticipated edge cases. I just don't see that as realistic. You can do this to some extent using formal verification. Most code doesn't get formally verified because it's kind of a pain to do, and you can usually fix bugs later, but smart contracts are the perfect candidate for it since they ar…

>You can write perfect code if you have the right tools and do it carefully. Obviously you are not a programmer.

Is there something about formal verification of systems that I don't understand?

Re: The collapse of the IRON stable coin

#439

Earlier quoted context omitted.

> Trusting any smart contract of sufficient complexity is like trusting that a code base has absolutely zero bugs and zero unanticipated edge cases. I just don't see that as realistic. You can do this to some extent using formal verification. Most code doesn't get formally verified because it's kind of a pain to do, and you can usually fix bugs later, but smart contracts are the perfect candidate for it since they ar…

Formal verification doesn’t help with bad assumptions that went into the design of the program.

That is absolutely true, but even legal contracts can't help you with bad assumptions that underpin the entire contract itself.

Re: The collapse of the IRON stable coin

#440

Earlier quoted context omitted.

>You can write perfect code if you have the right tools and do it carefully. Obviously you are not a programmer.

Is there something about formal verification of systems that I don't understand?

People make mistakes in their verification code the same way they make mistakes in their actual code.
Post reply on HN