651–660 of 754 posts
Just skimming through the Solidity docs, I see a lot of unwise decisions there aside from the weird visibility defaults. All state is mutable by default (this includes struct fields, array elements, and locals). Functions can mutate state by default. Both are overridable by explicit specifiers, much like C++ "const", but you have to remember to do so. Even then, the current implementation doesn't enforce this for fun…
Earlier quoted context omitted.
> Block scoping is default now in JS The default best practice, you mean? Declaring with 'var' will still get you the same lexical scoping rules as always. I believe OP meant 'inherited from pre-ES6 JS'
I thought using "var" is deprecated... If there's anyone who has the chance to use let/const but still doesn't, I'd be very curious to learn about their reasoning
Earlier quoted context omitted.
I can literally feel how Ethereum changes the law. I mean, seriously, no need for lawyers anymore. On ethereum it's is simple: You got fucked, live with it. "Bad faith? It's the code, didn't you read it?"
I realize that was probably satire or sarcasm or both, but since I've seen people actually seriously take that position I'm going to go ahead and respond as if it was serious. How do these smart contract deal with the real world? I can see how they can work for things that entirely involve activities that take place on the block chain (e.g., a smart contract that automatically pays a crowd funded project if and only…
I've not worked with smart contracts personally, so take it with a grain of salt, but...
This problem seems to be mostly solved by the information available in shipping manifests; the locations of loading and unloading, the consignee (buyer), container ids, description of goods... all there in a publicly available (at cost) record.
The real difficulty has more to do with verifying the quality - I'll admit I'm at a loss to how that's done today and I can't imagine quality assessors are at the port to verify that container #123 contains the shipment of Grade B+ cotton or map that to an API. As well, what happens when you disagree and your own independent assessor says its Grade B-? This seems like something that would remain up to legal debate; probably denoted in the contract but not verified by it such that lawyers and assessors can handle it should problems arise.
Just my two cents.
Earlier quoted context omitted.
This is because running code on Ethereum VM and storing data is hugely expensive (rightly so, as it's being done on all nodes in the world). Therefore Solidity will try to compile into a VM code that uses the least numbers of cheapest instructions and pack data into as small memory package as possible.
Most of the issues pointed out by int_19h would be handled at compile time during static analysis and wouldn't change much to the generated bytecode. I'm talking about strong typing, immutability by default, less error-prone syntax, tail calls, evaluation order etc... Even replacing 256bit ints with arbitrary precision "bigints" wouldn't add too much of a cost if it's a native type of the underlying VM (as it should…
Just skimming through the Solidity docs, I see a lot of unwise decisions there aside from the weird visibility defaults. All state is mutable by default (this includes struct fields, array elements, and locals). Functions can mutate state by default. Both are overridable by explicit specifiers, much like C++ "const", but you have to remember to do so. Even then, the current implementation doesn't enforce this for fun…
Time for the Underhanded Solidity Contest? ( http://www.underhanded-c.org/ )
Just skimming through the Solidity docs, I see a lot of unwise decisions there aside from the weird visibility defaults. All state is mutable by default (this includes struct fields, array elements, and locals). Functions can mutate state by default. Both are overridable by explicit specifiers, much like C++ "const", but you have to remember to do so. Even then, the current implementation doesn't enforce this for fun…
Time for the Underhanded Solidity Contest? ( http://www.underhanded-c.org/ )
Earlier quoted context omitted.
>How do these smart contract deal with the real world? I can see how they can work for things that entirely involve activities that take place on the block chain (e.g., a smart contract that automatically pays a crowd funded project if and only if it meets a threshold for pledges by a deadline, and refunds the donors otherwise). They can't deal with the real world by themselves, but where they have value in agreement…
>So yes you need human intervention, but only for those parts that cannot be automated. This is tautological and therefore means nothing.
Earlier quoted context omitted.
> outside of the blockchain The blockchain offers characteristics (immutability, consensus, distributed backup) that allows entities to trust each other efficiently. But when you introduce a non-trivial smart contract, there is a chance that it (a black box) has behavior that is not obvious from its source code. Since the behavior of the contract will cause immutable changes to the blockchain, and since humans can't…
> The blockchain offers characteristics (immutability, consensus, distributed backup) that allows entities to trust each other efficiently. Nope. All of these can be achieved without using proof-of-work which is terribly inefficient. The parties would have to trust each other... but well, they have to in Ethereum too :)
I agree that waste-heat-generating proof of work is inefficient, but that does not mean that no proof of work system exists where the work itself has some positive externalities.
Earlier quoted context omitted.
Downvoters, since you know how to indentify bubbles, I'm assuming you shorted ethereum on margin on GDAX when it hit 400 and made a ton? No? If not, why not, if you knew definitely it was a bubble ?
Because it's very hard to figure out where the top of a bubble is, and if you short a bubble asset too long before the peak, you go broke, even if you are correct. Don't short hopium.
Here's the root error I believe: https://github.com/paritytech/parity/blob/master/js/src/cont... The initWallet function should have been marked internal, but was instead not marked. Unmarked functions default to public in Solidity, so anyone can call that function and reinitialize the wallet to be under their control
Poking around in that project, I don't see any specific tests of the Wallet contract... would be interested to see what UTs/STs were included if anyone knows where they are -- or was it just manually tested on the testnet? It seems that a basic set of UTs for this contract should have caught this issue. It's not even in the category of weird timing attacks or complicated internal states allowing unexpected state tran…
Some projects have started sharing audit results publicly directly in their repos [1]. It's a great read to see common errors and yet unsolved issues that originate in the ERC20 token specification.
[0] https://github.com/ConsenSys/smart-contract-best-practices#i...
[1] https://github.com/status-im/status-network-token#reviewers-...