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.
Sorry, I'm not familiar with any blockchain layer model. Do you have a reference to the model this "layer-2" comes from? Clearly we're not talking about the OSI network model.
Layer 2 protocols are just those that operate "on top of" a base protocol, such as Lightning Network (on top of Bitcoin), roll_up (on top of Ethereum), or POA Network (also Ethereum).
(I would argue that the terms are imprecise though -- some protocols are described as operating "on top of Ethereum", but have their own consensus etc. which can function without Eth, so they could also be viewed as layer 1s with a bridge.)
The design can be thought of similar to a side chain but it's not really a side chain. It uses a new type of consensus, called Proof of Transfer (PoX). Stacks miners have visibility into both the Bitcoin chain and the Stacks chain. Leader election happens on Bitcoin and winning leader writes blocks on the Stacks chain. Details: https://blockstack.org/pox.pdf
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.
People are asking you why this counts as "on Bitcoin", and you've been saying throughout this thread it's because it has access to the Bitcoin ledger data. My point is that it pretty much sounds like you're using BTC as an "oracle" (and of course, you're using BTC as settlement, but that's a given, and also doesn't qualify as being "on bitcoin"). Stacks is a separate ledger that pegs itself to Bitcoin, not "on". "Smart contracts on Bitcoin" would be something that's entirely built on the Bitcoin ledger and every smart contract transaction is a Bitcoin transaction that settles.
What you are describing is similar to what Stacks 1.0 was i.e., directly on top of the Bitcoin chain -- a virtualchain. Every Stacks 1.0 transaction was a Bitcoin transaction.
The lessons we learned from that deployment for 2+ years is that (a) it doesn't scale that well and (b) it's very hard to modify Bitcoin and get new changes accepted (for good reason), so you end up with very limited scripting.
To fix the two limitations of Stacks 1.0, we worked on Stacks 2.0 which has a separate blockchain (so scalability independent of Bitcoin) where settlements still happen on Bitcoin and, more importantly, a full smart contract language without modifying Bitcoin itself: https://clarity-lang.org
When I read "Smart contacts on Bitcoin", I though you have somehow encoded smart contract logic in a novel Bitcoin output script, and that this contract script is thus executed by the Bitcoin miners. If you just use the Bitcoin output scripts to store some data, I would make a better name for your product.
(No disrespect to your project) I’m a technical person, built lots of software myself over the years, run a large product team now...and I have absolutely no idea how to parse almost anything you said here. May as well be in Greek, the density of buzzwords is wild.
Everything in cryptocurrency is so obtuse and unapproachable for even otherwise-technical people, it’s pretty incredible given it’s been around over a decade now.
I mean if you spent decades running a large product team that develops accounting web apps, would you expect to be able to read and interpret a description of product related to bio-informatics, or neurotechnology?
If you spent decades working on video game graphics, would it surprise you that someone describing algorithms for sophisticated quantitative finance or high frequency trading use terminology you're not familiar with, including an abundance of words literally borrowed from the Greek language?
Information technology is an absolutely massive field that is finding more and more use cases every year, it shouldn't be a surprise that there are areas of it that you're not familiar with and would need to devote a substantial amount of time to become well versed.
As someone who has spent a decent amount of time understanding cryptocurrencies, it's not really all that much different from learning any other field. You can start with some Youtube videos, read a few blog posts, heck you can even spend a couple of weekends writing your first smart contract and deploy it to Ethereum to see how it works. My first side project on Ethereum was writing a decentralized poker game, I wrote a series of smart contracts based on the theory of Mental Poker [1] and deployed it to the test net, and then wrote a web front end for it that waited for a new block to get published, parsed it and displayed it. It was pretty cool, once you deploy your smart contract to the blockchain, it's kind of magical seeing a completely decentralized system of computers bring that code to life. Like once you deploy your code, that's it, it's entirely out of your hands from that point forward and there's this engine that takes it and keeps it chugging literally for as long as there are miners willing to operate the Ethereum network.
Everything is a mystery until you take the time to learn it.
I sort of understand what's being said in this thread and I wouldn't say it's deliberately obtuse. A lot of ideas have been invented over the last decade and it's good that precise terminology exists to describe it. If you want to get into the minutiae of blockchain there's no shortcut.
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!
In the following order of nuance, the 99% of Bitcoiners:
Don’t know about this
Don’t like the idea of any other distributed ledger attracting capital away from Bitcoin purchases
Don’t know the Ethereum platform is different than any other “altcoin”
Don’t like Ethereum based on valid or fictional criticism
Don’t like WBTC
Don’t like renBTC in its current state
Know about all of this, don't mind it, are not interested in complex transactions, are not interested in turning their bitcoin into an interest bearing asset
The growth to the 1% has been pretty good and fast! Billions of $ of BTC on this stuff over just the last two quarters. Isn’t that how every startup pitch starts? “If we just get 1% of this market ....”
WBTC is essentially custodial. A couple partners hold some multisig keys on all Bitcoin that is deposited to be minted on Ethereum as WBTC. It is mainly BitGo, Kyber Network and Republic Protocol (Ren, the same people behind renBTC). WBTC requires KYC with BitGo to mint and redeem. Centralized, custodial, a few distributed key holders. Feature complete, so its not changing. Institutions like that actually, so it is pretty popular.
renBTC is by Republic Protocol, through their main product RenVM. RenVM allows holders of the REN token to stake 100,000 REN to create a "Darknode", which process all the minting, burning and storage of assets that go between chains. renBTC is Bitcoin to erc20 Ethereum. There are various other assets the Darknode holders process and earn. The amount Darknode holders earn in dollars has been increasing around 20% per month. The issues with RenVM and renBTC is that is actually hasn't reached that state. The darknodes do earn, but the current state does not use the darknodes for the decentralized storage of assets, instead, the Ren team has 12 keys stored around the world and requires collusion between the people on the Ren team to compromise. Now, some people call this is criticism, but this is still better than exchange cold storage which people already trust with billions of dollars of assets. For example, Gemini Exchange (Winklevoss Twins) brag about how their cold storage is 3 keys stored around the globe. lol, only three. People's concern is that while in this current state, the Ren protocol's geographically distributed team can be compromised by a government. Doubtful because nobody in one country has all the keys, and they are quickly speeding towards upgrading away to putting all processing on the darknodes. Anyway, for earning fees as a darknode its current state is quite unique, for users it is a stopgap solution (and not unique enough for BTC on Ethereum) as their bridge simply has more assets and doesn't require KYC or impose any limitations. Both the current and future iteration is using MPC cryptography for security. And again, their team is part of the mastermind behind WBTC. Darknode holders evangelize renAssets and get them into various other DeFi projects, which causes more people to want to mint and burn RenAssets, mostly renBTC so they can earn interest on their bitcoin. As you can see by this thread, many times renBTC is not mentioned at all. But it is the second largest Bitcoin on Ethereum. RenVM is not limited to minting assets onto Ethereum, they have or will be rolling out bridges to other chains as well, to Darknode holders delight.
there are competitors to renBTC such as tBTC, which aims to chisel at just the trustless BTC hegemony and not much else. Its growing decently.
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.
So stacks is a separate network with its own consensus layer where a random miner from the bitcoin main chain is selected to write the next block, have i got that right?
What happens when they write something the rest of the stacks network disagrees with?
Bitcoin miners have no role here. Anyone can sign up to be a Stack-miner by bringing in their own BTC into this network. That amount (in BTC) is distributed to those who have staked their Stack-tokens. A pRNG process (based on VDF or VRF) selects one of these miners at random to create the next block
It means that Clarity smart contracts always have all the data they need to validate Bitcoin transactions. Unlike wBTC and friends, there's no need to copy header hashes from Bitcoin into the Stacks chain. By extension, this means there's no need to worry about catastrophic corner cases, such as the copied data being missing or invalid, the copied data not being mined in the canonical fork, or the copied data corresponding to a minority Bitcoin fork.
Interesting. If you don't mind, what's an example of a practical application where it would be useful to validate a bitcoin transaction without the ability for a smart contract to custody it?
Just asking because, again, the value proposition in practical terms is a little unclear to me.
Well, the intended use-case is to make it so the act of transferring BTC to a particular address will cause xBTC tokens to be minted in a Clarity contract by the principal that sent the transaction. From there, you can move the xBTC tokens around in Stacks.
This would be paired with a STX-collateralized service that would ultimately let you trade your xBTC back for BTC. The service would put STX up as collateral, which would be depleted if the service quality degrades. The Clarity contract for the collateral would track the service's xBTC to BTC transfers, and would allow the service to post the BTC transactions it sends as proof of good service quality (thereby staving off depletion).
Other ideas come to mind:
* Proof of (attempted) mining a STX block. A Blockstack app could use a Clarity contract to determine if a user was also a miner, and offer them in-app perks for helping to secure the network.
* Backwards-compatibility with BNS 1.0. Stacks 1.0 implemented a naming service (BNS) on Bitcoin, and Clarity's access to Bitcoin state can be leveraged to allow users to prove that they are OGs -- i.e. that they registered a BNS name before Stacks 2.0 went live (or did something specific with it, like updated it to have a particular owner or have a particular content hash).
* Proof of payment to a particular address. Many organizations, including open-source projects, take BTC for donations. A Clarity contract could be written to identify Stacks users who donated to a particular organization earlier.
* Proof of payment channel. You could demonstrate to a Clarity contract that you have opened a payment channel with a particular amount to a particular address, and post collateral that will be slashed if your payment channel closed before a particular Bitcoin block height.
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.
Bitcoin to Stacks is supposed to be the easy part...
The question was about how you move Stacks to Bitcoin.
I take from this handwaving answer that it isn't actually possible.
Or let's rephrase the question in Bitcoin terms: While the BTC are locked up on the Bitcoin blockchain, which key is necessary to unlock them? Surely one controlled by Blockstack, no?
You'd need a STX-collateralized relay service that would trade your xBTC for real BTC. The collateral would be burnt over time if the service misbehaved, such as by not doing outstanding trades in a timely manner. The collateral itself would live in a Clarity contact so it could validate proofs that the service sent BTC to xBTC sellers.
> Do you mean that Stacks writes out its own block hashes to the Bitcoin blockchain, or something?
Yes; the entire history of attempts of mining Stacks blocks, as well as the entire history cryptographic sortitions that select Stacks blocks (including forks), is written to the Bitcoin chain. See SIP-001 for details: https://github.com/stacksgov/sips/blob/main/sips/sip-001/sip...
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.