asynchrony

I don't see how this won't result in rebuilding the current regulated banking system on top of an inefficient system bottlenecked by proof-of-work.

You’re describing a need for a standardized protocol not a blockchain.

When the price corrects back to $0.50 I predict many current zealots will change their tune.

It's perfectly decentralized.

The Ethereum Foundation is just the centralized marketing and governance organization that also lobbied the SEC not to classify it as a security because of how decentralized it is.

What happens if a trade that is illegal under the law of the country of the seller/buyer/exchange? The courts would be completely powerless to undo the transaction. Again it seems to me the main and only attraction is evading regulation.

It would be more convincing, or at least easier to take this comment in good faith, if you were to provide some part of your understanding of the innovation rather than to simply name drop a token and a link to a blog.

I think this was the original paper on the "selfish mining" strategy: https://www.cs.cornell.edu/~ie53/publications/btcProcFC.pdf

Isn’t the sieve’s eventual shape just the list of prime numbers?

Other than the sieve of Eratosthenes being a way to compute a finite list of primes I don't see the relationship here. Could you elaborate?

Do I need a ledger? Do I need to other people to trust what I write on the ledger? Do I need to trust what other people write on the ledger? Is it possible to trust what is written on the ledger in relation to what I actually care about?

I haven't heard any convincing yes answers to all of these questions outside of financial instruments.

In my mind the main contention is the difference between assets that exist entirely within the ledger (BTC, ETH, CryptoKitties) and assets that purport to reliably track some physical asset. Mathematical certainties about cryptographic security don't help reconcile the reality of meatspace with the state of the ledger.

I don't think there's that much disagreement over the effectiveness of blockchain for managing decentralized ledgers (cryptocurrencies). There's rather more contention about the applicability of blockchain to other spaces.

You could use Symbols or create a Symbol type (just an object with .toString method) to make the state IDs more manageable. It does amount to writing a memory manager similar to object pooling in a game engine. It's not that bad if the codebase has one convention for how to manage it, but if every case is adhoc it gets nasty quickly.

In general the solution would be some kind of class with .acquire and .release methods to create/recycle objects as needed. It comes up often enough that I'm a little surprised there isn't at least one or more popular libraries for it.

So what's the advantage over using git?

What if say you bribe someone with access to the private keys to append a false entry?

Personally I'm skeptical of all blockchain hype but as I have people in the industry close to me I try to keep an open mind and at least understand the technical and game theoretical aspects of the space. I can definitely agree that the aligned interests of those pressing for adoption and increasing prices has made rational debate difficult in many circles.

I found this article related to the attack in that paper https://bitcoinmagazine.com/articles/why-bitcoin-mining-pool...

While I'm not completely convinced that the countermeasure of "spy mining" completely mitigates the attack, it does appear that this is not a new vulnerability. Further, if a pool had all of the hardware under one roof, it wouldn't be possible to spy at all which would reinstate all of the problems outlined in the paper.

In my mind it's more like an acceptable upper bound on provability of immutable and eternal transactions on some distributed machine. The downside to unexpected exploits far outweighs the upside to unlimited flexibility. Bitcoin chose a non turing-complete script for its transactions, and the short history of cryptocurrency has already prove that is much more secure than the infinite-possibilities of the Ethereum VM. Time will tell, but I personally expect "shocking" exploits of Ethereum smart contracts to continue ad-infinitum.

Perhaps there remains some unexplored region in the limited yet flexible yet verifiable space of languages that was until now uninteresting.

I wasn't claiming that it is not possible to analyze a program to detect known exploits. Rather that it is extremely probable that another exploit will be found after the last one has been patched, and it is impossible to prove otherwise.

The halting problem doesn't prevent playing whack-a-mole against previous exploits, but it ensures that proving more exploits do not exist is impossible. That's why I think a turing-complete language for smart contracts is a poor choice.

I'm familiar with the proof and the story. My point is that the claim that any particular program can be fully analyzed is equivalent to saying that all programs can be analyzed.

Perhaps you're saying that it's possible to analyze any particular program for known exploits once they've been discovered?

If it's possible to do a complete analysis of any particular program, shouldn't it follow that it's possible to do a complete analysis of all programs?

If only a subset of all programs can be completely analyzed as particular programs, what are the boundaries of that set?

My understanding is more hand-wavy than formal, but would the combination of a total language and some limitation on the total number of instructions produce a provably predictable language?

Based on the halting problem, a provably complete analysis of the behavior of some (most?) programs in a turing-complete language is impossible. To put it another way, it is impossible to be sure that there isn't another vulnerability after you've patched the last one.

I don't own any crypto assets myself, but I think that using a non-turing-complete scripting language for the bitcoin blockchain was a wise decision rather than a lack of vision.

Please correct me if I'm wrong, but isn't it the nature of a turing machine (decentralized or not) to produce an endless series of "unforeseen" exploits?

I think this is the idea behind proof-of-stake. I don't see how it mitigates the fact that while the cryptography may be secure, the humans handling the keys are less so.

I have worked on factory floors before but honestly I don't see how it's relevant. Toyota and similarly competent manufacturers are are perfectly capable of using centralized databases to track the motion of parts around extremely convoluted manufacturing plants. Blockchain primarily solves the double-spend problem of a distributed spreadsheet. So some supplier can't claim to have sent the same parts to two factories on some spreadsheet. That's solving a non-problem. I expect blockchain to have a massive impact on industries primarily concerned with abstract ledgers (finance), but I have serious doubts about the utility of the technology when applied to problems involving meatspace. I would be happy to be proven wrong.

It depends on the security of supplier X's private keys. I think there's a general conflation of the security of the cryptography with the security of the system overall.

This is generally my main source of skepticism relating to blockchain solutions. The ledger is 100% trustable as long as it describes digital assets that are entirely confined within the distributed ledger, but a digital token doesn't stop men with guns from taking your house. Just like a digital signature provides no guarantees that the associated information is true.

Not inexpressible. Unprovable. There could be a set of correct programs that could never be proven correct by a type checker, for example.

I don't see what could possibly be the long term issues with a decentralized version of Windows XP handling global currency exchanges.