socrates1024

That's falsifiable though, in a way the other examples are not. You could sample the population of users after the change to the product

How big are its coffers though?

- Mit: $26.4B

- Yale: $42.3B

https://en.m.wikipedia.org/wiki/Yale_University_endowment https://news.mit.edu/2022/endowment-2022-1007

Why would this prove the necessity of regulations? This occurred within the realm of regulations, not in the wild west. FTX.US is a regulated entity in the US, and FTX Intl wasn't available to US customers. Doesn't this prove that calamity happens even despite the regulations

Write an M.L. Stine book is probably a good gpt-3 prompt

exponential in what?

pretty much what we use at zcash foundation https://github.com/ZcashFoundation/zfnd/tree/master/about

Note that the technical problems made it more complicated and messy to reproduce the build, but didn't outright prevent it. Mainly the executable binaries were reproducible, but other metadata in the disk image changed each time. https://github.com/zcash/mpc/issues/2

Another related resource (seems similar to the design of ethernaut) https://github.com/pdaian/hackthiscontract

Even more recent changes have made this better too. The research in the paper only goes up to Apr. 2017 or so. Since then, the "recent zone" has been a) reduced from 5 days to 3 days, and b) more recent zone mixins are included. We haven't quantified what improvement that makes, but it should help.

This isn't a good explanation. The result of this research is actually that even if you opted in to privacy during mid 2016 to jan 2017, you wouldn't have gotten it.

Contrary to the article, Tor is not a private non-profit. It's a publicly supported non-profit.

This is a great explanation for why theory is valuable.

The Ethereum VM is single threaded, so this isn't actually a problem

Ethereum foundation is not the custodian of the network. This is a debatable point, since it's not perfectly clear what that would mean. Ethereum Foundation doesn't own the miners or the validating nodes on the network, and can't control who joins or what software they run. Like other development teams, they can propose and try to drum up support for upgrades, which they've been successful at so far.

Detractors of Ethereum would prefer to view the Foundation as having much greater influence over the network, since that would mean it's less centralized. Proponents of Ethereum on the other hand would say Ethereum Foundation's role is similar to that of Bitcoin Core, except the divisiveness hasn't set in yet (or in the case of Ethereum Classic, opposing factions split off before it got bad).

I'd definitely recommend this book, it's great! Comes with decent video lectures and such too. (disclosure: am a coauthor)

Also, this course page has some useful links and lecture notes/slides (mostly geared towards graduate students and research) http://soc1024.ece.illinois.edu/teaching/ece598am/fall2016/

You might also try https://github.com/akosba/jsnark which is a frontend for libsnark.

An entire reimplemented alternative is Pequin (and related projects by Michael Walfish's group) https://github.com/pepper-project/pequin

Do you think it would be possible to improve the EVM by adding E's notion of concurrency? One constraint would be the need to have deterministic scheduling, since every execution would need to be run identically by all validating nodes.

[edit] Incidentally, we pointed out several lessons from the ocap community in a commissioned report from Ethereum foundation back in 2015. Few of those suggestions were adopted at the EVM level or the higher levels though. https://github.com/LeastAuthority/ethereum-analyses/blob/mas...

Turing-completeness has very little to do with this.

- The bug causing the DAO debacle did not involve loops or jumps or weird machines or other behavior associated with Turing-machine complexity, but instead had to do with confusing behavior of storage and inter-contract communication. - Ethereum is not really Turing complete, since it has bounded. It is procedural though. - Many expensive errors in the cryptocurrency world (e.g. transactions with too many fees, exchanges sending malleable transactions, transaction malleability) didn't involve the smart contract system at all - Decision-table based systems can hide bugs too. Is there any evidence that decision tables actually lead to fewer bugs, given the same amount of programmer time and attention?

Try implementing the DAO as a decision table?

For an even bigger coincidence, the new Monero project to add support for I2P is called Kovri, a prefix of your username!

Also see the complementary block explorer associated with the paper: http://monerolink.com/

We found tens of thousands of transactions that included ten or more mixins but could still be traced.

This paper is an empirical analysis. The Monero reports introduced a theoretical attack with conditions, e.g. “a critical loss in untraceability across the whole network if parameters are poorly chosen and if an attacker owns a sufficient percentage of the network.” The news is that our research confirms, for the first time, that this is actually the case, and it affects actual transactions.

In the next version we'll clarify zcash shielded transactions are optional. Fwiw it's used by 28% of tx according to https://explorer.zcha.in/statistics/network and comments above, not "rarely used"

Glad to hear these are standing the test of time :) (at least 2 years is a long time by cryptocurrency standards)

There doesn't appear to be any mining, proof-of-work, anonymous consensus, or fault-tolerant consensus of any kind in this project. I think they just threw the phrase "Nakamoto blockchain" in there as inspiration, really they are just using hashchains from 1999.

Totally. PLUM is a great team, and this work on ruby contracts from Brianna and Jeff is particularly awesome. By the way, their newest paper about the work in this github is going to be at PLDI: https://www.cs.umd.edu/~jfoster/papers/pldi16.pdf

(disclaimer: I just graduated from PLUM)

Even if they let the attacker get away with it this time, it would only be showing that Ethereum community used their discretion and chose not to in this case.

It would be a good idea for Solidity to properly support exceptions, this would probably simplify things a lot.

Right now solidity has exceptions, but no way to 'catch' them. Ordinary function calls automatically propagate exceptions when there's a problem. But, unintuitively, `send` behaves differently.

It would be trivial to modify `send` in Solidity so that it automatically throws an exception, like in Listing 3. But that's also often an anti-pattern, since it would allow the 'loser' to prevent the 'winner' from ever getting the money back. Sometimes it's important to keep on executing even if the `send` fails.

So once Solidity supports `catch`, that would help.