muneeb

I'd argue the inverse.

It's easier to build more complex things on top of simpler primitives than vice versa. So a simpler base layer (say TCP/IP for the internet) opens the doors to more complex things on top (say http or JavaScript).

You don't want a Solidity bug (and there are many) to mess with the supply or ownership of Bitcoin. The limited/simple scripting language is there for a reason. It's easy to add complexity and more functionality at Bitcoin base layer: the decision to not do it is the hard (but in my view the right) choice.

Ethereum 2 is very different. It is proof of stake (PoS). This reuses the proof of work of Bitcoin (so very different properties for how hard it is to change blockchain history). Also, PoS has some bootstrapping issues where a new node cannot independently (without trusting other nodes) verify the history of blockchains.

Scalability properties are also very different. Eth2 tried the concepts of sharding between <pick a number> chains. That has issues around added complexity between the shards and contracts needing to execute on shards where other data/logic they need is already available (so gravitational pull towards a mega shard). Stacks has no shards and scales horizontally. FWIW, Eth2 seems to be doing a slow move away from the sharding concept towards layer-2 like scalability as well. They disabled code execution for shards and using them more for data availability in latest iterations.

Muneeb here, Stacks co-founder. So it does not use Bitcoin as oracle. It uses Bitcoin as a settlement layer. (Oracles like Chainlink can be, and are being, built using Clarity lang for Stacks blockchain itself.)

For using Bitcoin state on Ethereum, you'll need to implement Bitcoin SPV proofs. It's entirely possible but fairly complicated to do that given (a) Ethereum is a separate network that can fork independently from Bitcoin (Clarity contracts on Stacks fork with Bitcoin), and (b) Eth miners have no native visibility into Bitcoin state (Stacks miners have full visibility into Bitcoin state). Possible but more complicated. Further, any asset generation and transfers etc on such ERC20 asset would have nothing to with Bitcoin vs on Stacks all asset generation and transfers etc settle on Bitcoin and are secured by the Bitcoin main blockchain.

Good question!

Bitcoin has limited scripting language (Bitcoin script) for security reasons. Having a general smart contract language could open up a larger attack surface area for Bitcoin.

The transaction costs will be low initially as they're a function of network traffic. The main thing here is to decouple scaling of transaction (as miroblocks on Stacks chain) from the scalability of Bitcoin (and Bitcoin is hard/impossible to change).

The Clarity smart contracts have direct visibility into Bitcoin state and developers can write logic around it. I do not think the headline implies you are changing Bitcoin to do this (don't think at this point anyone can change Bitcoin in any significant way).

99% of Bitcoin remains passively outside of smart contracts. Only about 5B on Ethereum. This can be a fairly large market and we're in early days. More use cases don't need to take anything away from Ethereum!

We received some push back for Stacks 1.0 as well! And for similar reasons i.e., you don't want to put a lot of additional data into the Bitcoin blockchain (makes it much harder to scale Bitcoin that way).

This was the primary reason why for Stacks 2.0, a hard design requirement was to make absolutely no changes to Bitcoin and to not put additional data in Bitcoin.

With Stacks thousands of STX transactions result in a single hash on Bitcoin (technically on the order of active miners on Bitcoin), so Stacks transactions automatically settle on Bitcoin every block.

Muneeb here, Stacks co-founder. Great question. You are right that Clarity smart contracts have direct visibility into Bitcoin, so you can write a contract that has logic triggered by pure Bitcoin transactions.

Moving Bitcoin to Stacks is a bit more complicated and there are several ways:

a) Wrapped assets. Tokensoft + Anchorage (custodian) have a solution that they're calling xBTC where a "wrapped Bitcoin" is issued on the Stacks chain. Such wrapped assets exist on other chains like Ethereum as well with one main difference that xBTC is secured by Bitcoin itself.

b) There are more decentralized solutions similar to Keep network, where threshold signatures can be used to move the assets by a group of nodes.

c) The most decentralized way of doing this is by locking your BTC directly on BTC chain, using Clarity to monitor funds, and then having Clarity trigger release of funds on Bitcoin chain. This requires Clarity logic to trigger Bitcoin state changes. This is theoretically possible but at R&D stage currently.