proj-oot-ootNotes19

for soft-realtime, eg audio, can't block. So ppl want to avoid garbage-collected languages [1]. One guy says Go can work, but is a pain, and that Rust would probably be better.

---

this guy's tips for soft-realtime audio:

" These mistakes basically boil down to not using slow scripting languages and making the core buffer loop run fast and undisturbed. For realtime synthesis use c or c++, optimise early, use trigonometry approximations in range -pi / pi, do not use lookup tables, they unnecessarily fill the cache, cpus are fast enough, write the core loop branchless, write for cache, use vectorisation and function pointers. Do not use anything fancy, simple int32_t, float and vector/array is enough (some filters need double precision though). Do not copy stuff, point to it. Precalculate what can be precalculated, e.g. dont do x / samplerate, do x * samplerate_inverse. Check for denormals. ... You should not use standard pow and log but approximations of these functions. These are usually faster than any lookup table that fills a good part of the cache and then you stall. But there might be some gray area, depending on the system. Or when full precision is needed. In most audio cases approximations work very well. Atleast that was what my testing showed.

edit: it might be different for a single plugin, where there isn't much need for cache, but as the core loop grows bigger, you also need the cache more. "

---

Five cooperative functions trampolining on a thread One called I/O and blocked that thread Mama called the doctor and the doctor said: "No more blocking on this thread!"

-- me

true story bruh

---

the conclusion of http://hackingdistributed.com/2016/06/18/analysis-of-the-dao-exploit/ struck a chord with me:

" I think the susceptibility of 1.1 to this attack is really interesting: even though withdrawReward for was not vulnerable by itself, and even though splitDAO was not vulnerable without withdrawRewardFor, the combination proves deadly. This is probably why this exploit was missed in review so many times by so many different people: reviewers tend to review functions one at a time, and assume that calls to secure subroutines will operate securely and as intended.

In the case of Ethereum, even secure functions that involve sending funds could render your original function as vulnerable to reentrancy. Whether they're functions from the default Solidity libraries or functions that you wrote yourself with security in mind. Special care is required in reviews of Ethereum code to make sure that any functions moving value occur after any state updates whatsoever, otherwise these state values will be necessarily vulnerable to reentrancy. "

in other words, programming with reentrancy requires a sort of red function/blue function as in 'What Color is Your Function'. Note that 'What Color is Your Function' is talking about whether or not the function is async/returns a callback, and that similar reasoning is needed esp. in Haskell for whether or not a function is pure. Here we are talking about whether a function possibly calls code provided by a user, eg code 'outside the module boundary' if theDAO is considered a 'module' (here, a trust/security boundary, eg we assume that everything inside the module boundary is correct and non-malicious, and anything outside may be incorrect and/or malicious).

So this adds evidence to the proposition that Oot should provide tools for easily labeling and tracing such things, even if the set of 'such things' is defined by an external framework rather than Oot.

---

list of ETH bugs:

https://blog.ethereum.org/2016/06/19/thinking-smart-contract-security/

in my view the way to deal with these is not (primarily) to change the EVM bytecode, but instead of have an awesome HLL like Oot that allows the creation of frameworks that provide more safety to the programmer.

Daian also says in a comment on the above post "What this implies is that the attack in the DAO goes beyond a simple exploit in the DAO's contract code itself, as some have been suggesting, and is actually a result of deeply flawed language constructs in Solidity."

---

a blog post on the Eth language Solidity:

" Some misfeatures are:

    A good language for writing state machines would ensure that there are no states from which it is impossible to recover.
    A good language for writing state machines would make it painfully clear when state transitions can and cannot happen.
    A good language for maintaining state machines would provide features for upgrading the security of a live contract.
    A good language for writing secure code would make it clear that there are no implicit actions, that code executes plainly, as read." -- [2]

---

these Synereo guys claim they have a system of formally typechecking what they call 'social graces' which appear to be properties of smart contracts:

http://blog.synereo.com/2015/03/06/on-social-contracts-part-ii/

on the difference b/t Synereo and former work on business process modeling languages:

" created Mar '15 last reply Mar '15 6 replies 517 views 5 users 8 likes 4 links 3

EdEykholt? Mar '15

Great post. I'm excited to learn more. I'm familiar with sequence diagrams, but am just now becoming more familiar with techniques for formal process specification applicable for decentralized protocols. Is Synereo's language for social contracts essentially a domain-specific language that extends pi-calculus in a consistent way? Are existing process modeling languages like BPDM, BPEL, BPML, or XLang not expressive enough or not domain-specific enough to be a good fit to specify social contracts? mathemagician Mar '15 1

EdEykholt? - Thank you for this question! Great to see you here in this forum. There is a close connection between the language of social contracts and the languages used in business process modeling. BPML and BPEL essentially owe their origins to XLang which in turn owes its origins to the π-calculus. i know because i invented XLang and the whole field of using process calculi to model business processes. You can check that with the US Patent Office wink.

There are three improvements in the language of social contracts. The first is to introduce structure into names. How much structure? That's such an interesting question. i explored the limits of this in my papers with Matthias Radestock on the rho-calculus. (See: this paper2 for example.) In the language of social contracts we actually dial it back to something that supports some practical considerations while fitting the domain requirements. The requirements have to with supporting distribution in a logical and satisfying way and is closely related to the second improvement.

The next improvement is to use a variant of the applied π-calculus where the messages exchanged are essentially prolog terms. When used in combination with the name structure improvement you get a two-fold structure for the notion of channel. There's a more heavy weight channel, fully qualified name, and then there's a lighter weight channel in the form of a pattern. Thus, for example

for( msg <- n?( c )( work( topics( [ "LivelyGig?