5 ms·

So your definition for "valid action" is just that the eth network lets them do it? They clearly didn't want to burn £500k, and that is now irrecoverable, alon

by zkldi 5y ago

So your definition for "valid action" is just that the eth network lets them do it? They clearly didn't want to burn £500k, and that is now irrecoverable, alongside 260 other people who made the same mistake, on a smart contract that forgoes validation for gas fees. How is this not invalid?

TimJRobinson 5y ago
`rm -rf /` is a perfectly valid action, but lots of people still get burnt accidentally running it.
capableweb 5y ago
> So your definition for "valid action" is just that the eth network lets them do it? Yes, this is indeed the definition for "valid", that the protocol allows them to do it. It was a valid action, but not the action the user actually wanted to perform. There are two ways of avoiding these scenarios: A) use UIs and don't interact with the protocol without safeguards, as the UI will prevent you from making mistakes (this user interacted directly with the contract, not via a UI) and B) when doing something involving a lot of money, do it once first with a small percentage, so you can verify it's correct (this user didn't do this either). For example, I know that IBAN has checksum built into the "address" and that the bank could revert transfers, but if I make transfers above a certain sum, I always send a small amount first, make the recipient confirm how much they received (I send a small random sum) and only then do I perform the larger transfer. As I mentioned elsewhere in the comments on this submission (https://news.ycombinator.com/item?id=30136941 https://news.ycombinator.com/item?id=30136941), it's impossible to know if someone actually has access to an address or not, so why would the wallet stop them from sending it?
- leokennis 5y ago
  You know what happens when you transfer money to a non-existent/incorrect IBAN? Most likely your bank will reject the transaction and not even defund your account - as you mentioned, the IBAN itself is already designed to prevent human error. If by chance you “crafted” a technically MOD-97 valid but not existing IBAN and the money goes out to the other bank (PACS.008), the other bank cannot book it (as the account doesn’t exist) and should automatically return it to you (PACS.004). If by chance the other bank is incompliant and does not return the money, you can have your bank send a recall message (CAMT.056) to try and retrieve the funds. The other bank is then compelled to either refund the money (PACS.004 again) or at the least officially communicate they’re keeping your money (CAMT.029). At that point, there’s still law and legal avenues to pursue. One thing that does not and can not happen though, is for the money to vanish into a black hole and be removed from the economy. That is what a stable, standardized and reasonably regulated industry with some centralization does for you.
  - capableweb 5y ago
    You know what happens when you send Ether to a incorrect Ethereum address? The wallet will reject sending it. If you bypass the wallet and rewrite your own wallet to send it anyways, the validators reading from the mempool will reject it. If you rewrite your own validator to accept it anyways, no other validator will accept it and the transfer will never go through. What happened here is more like you used IBAN to send to the correct account, the correct bank and everything was correct, but no one actually has access to the account but the bank doesn't know this. Nothing has vanished or been removed.
- giaour 5y ago
  As far as I can tell, no one has argued that transaction validation for this specific smart contract should be built into wallets. You're arguing with a straw man. The point I see made instead is that the smart contract should not be coded to behave as it does. If a financial product at a retail bank set a pile of cash on fire when you used it incorrectly, regulators would swoop in and make the industry add some safety features, even if that safety came at the cost of convenience.
  - capableweb 5y ago
    It's very hard to draw parallels from cryptocurrencies to other things as it's not like other things we have today. Some sort of analogy could be margin calls/puts. Imagine someone who doesn't know how margin trading works used it, and lost half a million dollars. Who's at fault here? The bank for allowing it, the financial system for having the feature or the user for not educating themselves enough to understand how it works?
    - giaour 5y ago
      > Some sort of analogy could be margin calls/puts. That is not a comparable situation. The ETH/WETH trader misused a negotiable instrument, and 500K disappeared forever. Someone who loses 500K gambling on margin was gambling and lost. If they somehow mistakenly placed an order on margin, there's probably a process to reverse the transaction and get your funds returned within a specific time window (that's just a guess on my part, though, and it probably depends on the brokerage used). > It's very hard to draw parallels from cryptocurrencies to other things as it's not like other things we have today. I don't think this is true; cryptocurrency in this situation is very similar to cash. You can get mugged while holding 500K in a briefcase, and the funds are unrecoverable absent legal restitution. But that's why banks make you sign a waiver of liability when you withdraw large sums in cash.
- ClumsyPilot 5y ago
  "It was a valid action, but not the action the user actually wanted to perform." It's an action noone ever has ever wanted or ever will want to perform. In the same way putting your finger inside a power socket is an invalid action, and people who designed sockets were smart enough to make it impossible.
  - GaylordTuring 5y ago
    "It's an action noone ever has ever wanted or ever will want to perform." That's not entirely true. Just look at one of the many burn addresses that people willingly send money to all the time, for example: https://etherscan.io/address/0x0000000000000000000000000000000000000000 https://etherscan.io/address/0x00000000000000000000000000000... For example, some holder (maybe a founder) of a certain coin can burn a certain amount of their tokens, making it more rare. This is a quite common practice. If I were to burn a certain amount of tokens, I think the most natural thing to use as a burn address would be the contract address itself.
  - capableweb 5y ago
    The only thing you're showcasing here is the lack of understanding of what happened. This transfer was a transfer from one address to another. No one has ever wanted to do that? It's the entire point of cryptocurrencies!
    - SantalBlush 5y ago
      You are intentionally misrepresenting the parent comment. The point is not that nobody should be able to transfer from one address to another, and pretending otherwise is pretty dishonest.
      - capableweb 5y ago
        But then please share with me what the argument is? The user made a transfer that shouldn't have been done in the first place, and somehow people are saying that the protocol should have safe-guards against doing transfers to the wrong address, but how is the protocol supposed to know what address is right/wrong? There is literally no distinction between them, so therefore you need to allow any transfer, or no transfer.
- UncleMeat 5y ago
  > Yes, this is indeed the definition for "valid", that the protocol allows them to do it. I believe that this, right here, is the core disagreement surrounding the utility of cryptocurrencies. There are two orientations to think about software. One is the software orientation and one is the human or problem orientation. "It did what the software says" is a defense often used by crypto advocates who point out, rightly, that there are very strong guarantees that cryptocurrencies provide and other things that they completely do not guarantee. Other people point to the mismatch between the guarantees that cryptocurrencies provide and the actual failure modes that are very common in the real world and complain that advocates seem to be completely ignoring these issues. I think a relevant comparison is security vulnerabilities in traditional software. If you've got a program that is exploitable through a buffer overrun that enables arbitrary code execution, the program is behaving precisely as programmed. From the perspective of the program and the computer, there is no difference between ordinary operation and the exploit. But from a human perspective one of these behaviors is expected and one is both unexpected and undesirable. And the "well, just don't fuck up your C program" argument is basically failed at this point, for good reason. I would expect to see the same in the crypto space.

by zkldi 5y ago

TimJRobinson 5y ago

`rm -rf /` is a perfectly valid action, but lots of people still get burnt accidentally running it.

capableweb 5y ago

> So your definition for "valid action" is just that the eth network lets them do it? Yes, this is indeed the definition for "valid", that the protocol allows them to do it. It was a valid action, but not the action the user actually wanted to perform. There are two ways of avoiding these scenarios: A) use UIs and don't interact with the protocol without safeguards, as the UI will prevent you from making mistakes (this user interacted directly with the contract, not via a UI) and B) when doing something involving a lot of money, do it once first with a small percentage, so you can verify it's correct (this user didn't do this either). For example, I know that IBAN has checksum built into the "address" and that the bank could revert transfers, but if I make transfers above a certain sum, I always send a small amount first, make the recipient confirm how much they received (I send a small random sum) and only then do I perform the larger transfer. As I mentioned elsewhere in the comments on this submission (https://news.ycombinator.com/item?id=30136941 https://news.ycombinator.com/item?id=30136941), it's impossible to know if someone actually has access to an address or not, so why would the wallet stop them from sending it?

leokennis 5y ago
You know what happens when you transfer money to a non-existent/incorrect IBAN? Most likely your bank will reject the transaction and not even defund your account - as you mentioned, the IBAN itself is already designed to prevent human error. If by chance you “crafted” a technically MOD-97 valid but not existing IBAN and the money goes out to the other bank (PACS.008), the other bank cannot book it (as the account doesn’t exist) and should automatically return it to you (PACS.004). If by chance the other bank is incompliant and does not return the money, you can have your bank send a recall message (CAMT.056) to try and retrieve the funds. The other bank is then compelled to either refund the money (PACS.004 again) or at the least officially communicate they’re keeping your money (CAMT.029). At that point, there’s still law and legal avenues to pursue. One thing that does not and can not happen though, is for the money to vanish into a black hole and be removed from the economy. That is what a stable, standardized and reasonably regulated industry with some centralization does for you.
- capableweb 5y ago
  You know what happens when you send Ether to a incorrect Ethereum address? The wallet will reject sending it. If you bypass the wallet and rewrite your own wallet to send it anyways, the validators reading from the mempool will reject it. If you rewrite your own validator to accept it anyways, no other validator will accept it and the transfer will never go through. What happened here is more like you used IBAN to send to the correct account, the correct bank and everything was correct, but no one actually has access to the account but the bank doesn't know this. Nothing has vanished or been removed.
giaour 5y ago
As far as I can tell, no one has argued that transaction validation for this specific smart contract should be built into wallets. You're arguing with a straw man. The point I see made instead is that the smart contract should not be coded to behave as it does. If a financial product at a retail bank set a pile of cash on fire when you used it incorrectly, regulators would swoop in and make the industry add some safety features, even if that safety came at the cost of convenience.
- capableweb 5y ago
  It's very hard to draw parallels from cryptocurrencies to other things as it's not like other things we have today. Some sort of analogy could be margin calls/puts. Imagine someone who doesn't know how margin trading works used it, and lost half a million dollars. Who's at fault here? The bank for allowing it, the financial system for having the feature or the user for not educating themselves enough to understand how it works?
  - giaour 5y ago
    > Some sort of analogy could be margin calls/puts. That is not a comparable situation. The ETH/WETH trader misused a negotiable instrument, and 500K disappeared forever. Someone who loses 500K gambling on margin was gambling and lost. If they somehow mistakenly placed an order on margin, there's probably a process to reverse the transaction and get your funds returned within a specific time window (that's just a guess on my part, though, and it probably depends on the brokerage used). > It's very hard to draw parallels from cryptocurrencies to other things as it's not like other things we have today. I don't think this is true; cryptocurrency in this situation is very similar to cash. You can get mugged while holding 500K in a briefcase, and the funds are unrecoverable absent legal restitution. But that's why banks make you sign a waiver of liability when you withdraw large sums in cash.
ClumsyPilot 5y ago
"It was a valid action, but not the action the user actually wanted to perform." It's an action noone ever has ever wanted or ever will want to perform. In the same way putting your finger inside a power socket is an invalid action, and people who designed sockets were smart enough to make it impossible.
- GaylordTuring 5y ago
  "It's an action noone ever has ever wanted or ever will want to perform." That's not entirely true. Just look at one of the many burn addresses that people willingly send money to all the time, for example: https://etherscan.io/address/0x0000000000000000000000000000000000000000 https://etherscan.io/address/0x00000000000000000000000000000... For example, some holder (maybe a founder) of a certain coin can burn a certain amount of their tokens, making it more rare. This is a quite common practice. If I were to burn a certain amount of tokens, I think the most natural thing to use as a burn address would be the contract address itself.
- capableweb 5y ago
  The only thing you're showcasing here is the lack of understanding of what happened. This transfer was a transfer from one address to another. No one has ever wanted to do that? It's the entire point of cryptocurrencies!
  - SantalBlush 5y ago
    You are intentionally misrepresenting the parent comment. The point is not that nobody should be able to transfer from one address to another, and pretending otherwise is pretty dishonest.
    - capableweb 5y ago
      But then please share with me what the argument is? The user made a transfer that shouldn't have been done in the first place, and somehow people are saying that the protocol should have safe-guards against doing transfers to the wrong address, but how is the protocol supposed to know what address is right/wrong? There is literally no distinction between them, so therefore you need to allow any transfer, or no transfer.
UncleMeat 5y ago
> Yes, this is indeed the definition for "valid", that the protocol allows them to do it. I believe that this, right here, is the core disagreement surrounding the utility of cryptocurrencies. There are two orientations to think about software. One is the software orientation and one is the human or problem orientation. "It did what the software says" is a defense often used by crypto advocates who point out, rightly, that there are very strong guarantees that cryptocurrencies provide and other things that they completely do not guarantee. Other people point to the mismatch between the guarantees that cryptocurrencies provide and the actual failure modes that are very common in the real world and complain that advocates seem to be completely ignoring these issues. I think a relevant comparison is security vulnerabilities in traditional software. If you've got a program that is exploitable through a buffer overrun that enables arbitrary code execution, the program is behaving precisely as programmed. From the perspective of the program and the computer, there is no difference between ordinary operation and the exploit. But from a human perspective one of these behaviors is expected and one is both unexpected and undesirable. And the "well, just don't fuck up your C program" argument is basically failed at this point, for good reason. I would expect to see the same in the crypto space.