I could go on... but... just my recollection...
If you are interested, it’s worth reading the articles “what is money” and “the credit theory of money” by Alfred Mitchell-Innes. He maintained that “credit and credit alone is money” and I mostly agree with him. Another good paper to read is “money is memory”. Oh and Knut Wisksell “interest and prices” is also very good. A lot of literature has been written on pure credit economies but it is difficult to find as it wasn’t ever a popular school of thought. I’m hoping for a revival though!
This stuff always sounded like it came from people who've never hired. Unskilled labor is not all equal.
> Satoshi’s concept was to use hashcash to both secure the ledger and issue currency. This was brilliant but antithetical to the no-currency concept, and re-ignited the debate
Satoshi's most important advancement was in making a currency and using it as its own rate-limiter by paying, in it, to publish.
Bitcoin's weakness is that computation isn't priced in BTC, so scripts had to be nerfed. Vitalik applied Satoshi's rate-limiting solution to computation and Ethereum scripts can now be allowed to grow arbitrarily complex.
Smart contracts seemed to me to be another sticking point that nearly killed the whole idea. Most people were looking for a better system of simple exchange, and smart contracts made that difficult. Now transactions became difficult to understand and fraught with error. Running a node meant trusting a fairly large code base you downloaded from an insecure Internet forum, and then let strangers run code on that. Before Script came into it, anybody could look at a shell script implementation and understand what was going on with all trusted components. For a long time it looked like Bitcoin would never release, and vulnerabilities in the early versions made everybody realize that they weren’t trusting a mathematical concept; they were trusting software written by some guy on the internet. Then there was the debate inside the smart contracts community about the halting problem and how it could be used to attack the network. This is probably practically solved with transaction costs alone, but I think it was a practical software engineering compromise do scripting without looping and backward jump instructions because they made the software much more complex and vulnerable to attack. Same with the block size, maybe even block time. This was all an experiment. By the time Vitalik started pushing for improvements, the Satoshi compromises had become canon. I spoke to him and he seemed to be in agreement with upgrading the protocol through miner consensus, but, by that point, an industry of rather unsophisticated mining operations had emerged, and they were not interested in changing anything. Briefly I lived with one of the biggest miners in the world, and he would ask questions and I would explain to him how transactions work etc. So Vitalik gave up on on-chain scripting and proposed an off-chain scripting scripting layer that would use a separate gas currency just for smart contracts with settlement on the Bitcoin blockchain. This was very important to distinguish itself from the rest of the already-defunct altcoins. But practically, I don’t know how it was supposed to happen. We have this now, but it’s been a long road. Is there any reason that Bitcoin doesn’t have Turing completeness, faster blocks, oracles, etc? Not really; but a fork would have been risk without reward, whereas a new token offers the ability to premine and speculate. One of the biggest learnings was how much speculation would dominate over anything non-financial, and how hard it would be to modify the Bitcoin experiment. Still, the use cases for smart contracts are very few, and Turing completeness itself is basically unnecessary. But to more directly address the point, Bitcoin has transaction fees already, and it would be simple to assume that a similar consensus on gas price would emerge and doesn’t need to be part of the protocol. To go further, the gas price itself doesn’t solve the problem of computational complexity because only the miner that wins the block actually gets the reward, while all others downstream are expected to verify it, but they have no incentive to do so, and frankly, today, most don’t. As an example, almost nobody boots up an eth node with verification from origin, and they would be greatly in the minority if they corrected a bug. Eth nodes boot to a trusted state handed to them. Most of the early eth discussions I was involved with implied doing this in snarks or some other provable computation in the initial discussions, but that never made it into eth. So no; that problem was never solved, although we are getting closer.
Yup. And still does. There was a huge sea change circa 2013(?) when everything became about currency and speculation. Every idea had to pivot to being its own coin, or including some useless utility token (a bit later) because that was 99%+ of the value to investors.
> Is there any reason that Bitcoin doesn’t have Turing completeness, faster blocks, oracles, etc? Not really; but ...
It feels like the first implementation couldn't have gotten it right if it aimed for too much more than Satoshi did. But technically, yes, BTC is a plausible base for this as much as anything else.
> debate inside the smart contracts community about the halting problem and how it could be used to attack the network. This is probably practically solved with transaction costs alone, but I think it was a practical software engineering compromise do scripting without looping and backward jump instructions because they made the software much more complex and vulnerable to attack.
Unbounded loops are an issue, but functional constructs (foreach) have 99% of the power and little of the risk. Ideally we'd have Satoshi take three months now and make v2, which would be BTC in spirit but with the lessons of the last ten years.
> To go further, the gas price itself doesn’t solve the problem of computational complexity because only the miner that wins the block actually gets the reward, while all others downstream are expected to verify it, but they have no incentive to do so, and frankly, today, most don’t.
This seems like where we need a mechanism that allows a script to be audit-executed, and if its outputs don't match expectations a deposit can be claimed by the auditor and the script will be marked as unreliable. If the precondition of the code is that it returns the correct public key, make sure that key works. If it doesn't you can claim the QA/Security prize - which can be set at whatever amount the script author wants depending on their belief in their code.
> Most of the early eth discussions I was involved with implied doing this in snarks or some other provable computation in the initial discussions, but that never made it into eth. So no; that problem was never solved, although we are getting closer.
Is there a specific blocker for this or just that the complexity is 1000x what is currently supported?