This is not true at all, and a strange statement to make from someone who identifies with the technical side of cryptocurrencies.
Ethereum made two important departures from the Bitcoin design. One is to have accounts instead of unspent transactions (UTXOs). We don't know if Satoshi considered an account based design first, but it is not unlikely since it is a design one is likely to think of first. We can however make an educated guess as to why the UTXO model was chosen instead. It enables SPV wallets which is mentioned as early as in the whitepaper.
Ethereum can not have thin and trustless wallets by design. SPV wallets wasn't really as straightforward as people thought them to be, and one design isn't necessarily "better" than the other, but one is not a subset of the other.
The other important change was bytecode to support compiling from popular languages, such as javascript, instead of specialized bytecodes to support the low level operations of the protocol. This is a different design that requires changes to other aspects of the protocol, including the fee model to a price on execution time. Bitcoin programs are supposed to anchor to the chain, not completely live on it.
If crypto kittens were written for Bitcoin instead of Ethereum, they would need to have certain logic off chain but track things like ownership on chain. (Compare for exampel with the Lighthouse model.) This is a different model, which is only semi on-chain and would therefore scale better.
Doing the same operations to the contract requires more transactions and produces more data in the Ethereum model. So Bitcoin would likely continue to function where Ethereum struggles (to the point where big exchanges just turn off their Ethereum processing when large events such as big ICOs happens).
> the uncompressed "archival" version of Ethereum is at 300gb but the standard compressed version only requires about 15gb
It is not interesting how big the chain is but how fast it grows. Transaction throughput is capacity, not scaling. Scaling is a measure of change.
And Etherum growth is concerning to the developers. Have you tried running a full node? I have. Even a beefy machine with SSD takes weeks to bootstrap, and the load is getting worse over time, not better. It's not clear for how long this can be kept up.
Sure, you can trust a third party to deliver you the blockchain. But someone must independently audit the blockchain, otherwise we would be much better off by running audited Postgres nodes at trusted institutions (like the global DNS infrastructure works) than just trusting a Foundation.
The "compressed" Bitcoin blockchain, by comparison, is as small as 1 GB and just as functional. But the comparison is uninteresting, because any application that can make do with such a heavily pruned blockchain would probably be better off with an SPV architecture.
Please don't read this is some sort of comparison or defense of Bitcoin's architecture. One is not "better" than the other. Ethereum changed a few fundamental design decisions and the result is different, therefore the use cases are different. One is certainly not a subset of the other.
You could implement the Bitcoin protocol in Ethereum, and the Ethereum protocol, practically speaking, does everything the Bitcoin protocol does plus a bunch of other things. That's what I mean when I say "subset".
What does that mean, exactly? You clearly couldn't implement Bitcoin the software since there's no way to speak the protocol or even utilize the data structures involved, let alone the absurd amounts of data that needs to be moved. It's like saying you could implement MySQL in Ethereum, which at least has no canonical global data store to it.
You could parse scripts and verify transactions, and that might be useful inside the Ethereum world. But it wouldn't be useful outside of it. It would still scale like Ethereum and you would need to process the entirety of the Ethereum blockchain and the Bitcoin blockchain to do useful operations.
This is not true at all, and a strange statement to make from someone who identifies with the technical side of cryptocurrencies.
Ethereum made two important departures from the Bitcoin design. One is to have accounts instead of unspent transactions (UTXOs). We don't know if Satoshi considered an account based design first, but it is not unlikely since it is a design one is likely to think of first. We can however make an educated guess as to why the UTXO model was chosen instead. It enables SPV wallets which is mentioned as early as in the whitepaper.
Ethereum can not have thin and trustless wallets by design. SPV wallets wasn't really as straightforward as people thought them to be, and one design isn't necessarily "better" than the other, but one is not a subset of the other.
The other important change was bytecode to support compiling from popular languages, such as javascript, instead of specialized bytecodes to support the low level operations of the protocol. This is a different design that requires changes to other aspects of the protocol, including the fee model to a price on execution time. Bitcoin programs are supposed to anchor to the chain, not completely live on it.
If crypto kittens were written for Bitcoin instead of Ethereum, they would need to have certain logic off chain but track things like ownership on chain. (Compare for exampel with the Lighthouse model.) This is a different model, which is only semi on-chain and would therefore scale better.
Doing the same operations to the contract requires more transactions and produces more data in the Ethereum model. So Bitcoin would likely continue to function where Ethereum struggles (to the point where big exchanges just turn off their Ethereum processing when large events such as big ICOs happens).
> the uncompressed "archival" version of Ethereum is at 300gb but the standard compressed version only requires about 15gb
It is not interesting how big the chain is but how fast it grows. Transaction throughput is capacity, not scaling. Scaling is a measure of change.
And Etherum growth is concerning to the developers. Have you tried running a full node? I have. Even a beefy machine with SSD takes weeks to bootstrap, and the load is getting worse over time, not better. It's not clear for how long this can be kept up.
Sure, you can trust a third party to deliver you the blockchain. But someone must independently audit the blockchain, otherwise we would be much better off by running audited Postgres nodes at trusted institutions (like the global DNS infrastructure works) than just trusting a Foundation.
The "compressed" Bitcoin blockchain, by comparison, is as small as 1 GB and just as functional. But the comparison is uninteresting, because any application that can make do with such a heavily pruned blockchain would probably be better off with an SPV architecture.
Please don't read this is some sort of comparison or defense of Bitcoin's architecture. One is not "better" than the other. Ethereum changed a few fundamental design decisions and the result is different, therefore the use cases are different. One is certainly not a subset of the other.