4 ms·

Yes, I agree. Most of the security of smart contracts should be in the VM. Things like self-asserting the results and only finishing the transaction if it actua

Yes, I agree. Most of the security of smart contracts should be in the VM. Things like self-asserting the results and only finishing the transaction if it actually passes a double-check. Or set value limits to each smart-contract (so even if there's a bug it will only operate on 0.00001 BTC for example).

admax88q 5y ago
If your smart contract can only process tiny amounts of money, then it's no useful.
- raverbashing 5y ago
  That's not what I'm saying. But sure, if you think you can write smart contracts without bugs for all means don't set a limit. I'm saying you should define a ceiling for your smart contract so in case of a bug, no transactions over that ceiling go forward. So if you have a stupid bug that causes you to transfer 1BTC instead of 0.001BTC you don't lose all your money.
  - recursive 5y ago
    What's the distinction? That just means you won't be able to use smart contracts for anything useful.
jwlake 5y ago
This is mostly infeasible because the VM has no idea what's worth anything. There is no reasonable price in absolute terms for a BTC or ETH or DOGE or $DUMBCOIN. The key is that the contracts need to be minimal and analyzable, so its ~100 lines of code you can manually analyze. Documented separately all the edge cases, or ideally removed through good design so they simply don't exist. A bunch of problems I've seen in the real world of crypto are annoying edge cases that you can fix with an if statement, or ideally change the design to remove them completely. It's actually a surprisingly hard space because you're trying to make terse, complete and secure code. In normal web/systems programming you have layers of security; internal services, external services, firewalls, access controls, vpns, security by obscurity, etc etc etc. In crypto you have none of that. Everything is 100% public, the code probably should be published, or else it is trivially decompiled. If there is a problem someone will find it if there is value in finding it.
- raverbashing 5y ago
  Thanks for your comment. Yes I agree the absolute value in some coin is not a great metric. > In normal web/systems programming you have layers of security; In crypto you have none of that. Yes, that's what I mean. Why not? > The key is that the contracts need to be minimal and analyzable Agree, but even short contracts might have bugs. Betting on "self-paying bug bounts" is not a good bet. What I'm proposing is that every smart contract double-checks its expected results

admax88q 5y ago

If your smart contract can only process tiny amounts of money, then it's no useful.

raverbashing 5y ago
That's not what I'm saying. But sure, if you think you can write smart contracts without bugs for all means don't set a limit. I'm saying you should define a ceiling for your smart contract so in case of a bug, no transactions over that ceiling go forward. So if you have a stupid bug that causes you to transfer 1BTC instead of 0.001BTC you don't lose all your money.
- recursive 5y ago
  What's the distinction? That just means you won't be able to use smart contracts for anything useful.

jwlake 5y ago

This is mostly infeasible because the VM has no idea what's worth anything. There is no reasonable price in absolute terms for a BTC or ETH or DOGE or $DUMBCOIN. The key is that the contracts need to be minimal and analyzable, so its ~100 lines of code you can manually analyze. Documented separately all the edge cases, or ideally removed through good design so they simply don't exist. A bunch of problems I've seen in the real world of crypto are annoying edge cases that you can fix with an if statement, or ideally change the design to remove them completely. It's actually a surprisingly hard space because you're trying to make terse, complete and secure code. In normal web/systems programming you have layers of security; internal services, external services, firewalls, access controls, vpns, security by obscurity, etc etc etc. In crypto you have none of that. Everything is 100% public, the code probably should be published, or else it is trivially decompiled. If there is a problem someone will find it if there is value in finding it.

raverbashing 5y ago
Thanks for your comment. Yes I agree the absolute value in some coin is not a great metric. > In normal web/systems programming you have layers of security; In crypto you have none of that. Yes, that's what I mean. Why not? > The key is that the contracts need to be minimal and analyzable Agree, but even short contracts might have bugs. Betting on "self-paying bug bounts" is not a good bet. What I'm proposing is that every smart contract double-checks its expected results