Badr bellaj bellaj

Having seen @pirapira's sketch of Bamboo ( https://github.com/pirapira/bamboo/ ), which proposed to add better control about the "smart contract program flow", even across calls, I thought that this should certainly be added to Solidity, and actually, it might even be possible now to a certain degree using inline assembly.

The problem is that with many functions in a contract, it is not always clear which can be called at which stage in the contract's lifetime. Certain smart contracts would be easier to understand if written as follows:

THIS DOCUMENT

IS OUT OF

DATE

See https://github.com/lefticus/cppbestpractices/blob/master/00-Table_of_Contents.md Instead!

C++ Coding Standards Part 0: Automated Code Analysis

Automated analysis is the main advantage to working with a modern statically typed compiled language like C++. Code analysis tools can inform us when we have implemented an operator overload with a non-canonical form, when we should have made a method const, or when the scope of a variable can be reduced.

	/* demonstrating uint overflow and underflow in ethereum solidity
	this is why you need guards like:
	if (balances[_to] + _amount < balances[_to]) throw;
	*/
	contract C {
	// (2**256 - 1) + 1 = 0
	function overflow() returns (uint256 _overflow) {
	uint256 max = 2**256 - 1;
	return max + 1;
	}

	//
	// The new assembly support in Solidity makes writing helpers easy.
	// Many have complained how complex it is to use `ecrecover`, especially in conjunction
	// with the `eth_sign` RPC call. Here is a helper, which makes that a matter of a single call.
	//
	// Sample input parameters:
	// (with v=0)
	// "0x47173285a8d7341e5e972fc677286384f802f8ef42a5ec5f03bbfa254cb01fad",
	// "0xaca7da997ad177f040240cdccf6905b71ab16b74434388c3a72f34fd25d6439346b2bac274ff29b48b3ea6e2d04c1336eaceafda3c53ab483fc3ff12fac3ebf200",
	// "0x0e5cb767cce09a7f3ca594df118aa519be5e2b5a"

	# The Witness Algorithm: Privacy Protection in a Fully Transparent System
	By Vlad Gluhovsky and Gavin Wood

	# Introduction

	Being based upon a quasi-Turing-complete (quasi because it's actually bounded) virtual machine, Ethereum is an extremely versatile system. However one of its greatest strengths---universal auditability---seems to lead to a fatal flaw, namely an inescapable lack of privacy. Here we demonstrate an algorithm in order to prove that this is not the case.

	The algorithm could be used to make an Ethereum contract which, given two sets of addresses sources, `src`, and destinations, `dest`, will guarantee exactly one of two possible eventualities:

	- For each address in `src`, the controller of that address controls a corresponding address in `dest` (though the two cannot be related a priori).