Ultra Mega Super Stacks 2.1 Thread

[jcnelson]

SUPERSEDED

Hey folks, please see this discussion instead for a much more detailed breakdown of what's going into 2.1: stacks-network/stacks-core#3096

The text below is preserved for informational purposes, but the above discussion supersedes it.

---

Hey everyone,

We're trying to figure out what exactly should go into Stacks 2.1. We're not at the point where we feel like we can open fine-grained issues and implementation proposals (except for bugfixes, under the "Stacks 2.1" tag in the Stacks blockchain repository), but we have noticed some general themes:

Stacking Improvements

While the blockchain is implemented consistent with SIP-007, there are some user experiences that could be better. Specific improvements include:

• Continuous Stacking. There needs to be some way for Stackers to avoid missing a reward cycle in-between Stacking their STX.

• Fine-grained bidding. Once you Stack your tokens for an upcoming reward cycle, you can increase the amount of STX you Stack in 50k increments. This threshold could be lower.

• Unlock unused STX automatically. STX that get committed for Stacking should not get locked if they do not clinch a reward address slot.

Way back in August 2020 I had a proposal that addressed all three of these here. Other proposals are of course welcome.

Regardless of which proposal eventually gets merged to Stacks 2.1, it needs to be incentive-compatible with honest Stacking while fixing the above issues. That is, the strategy for Stacking in Stacks 2.1 that has the highest payout must be a strategy that permits users to be able to Stack (and pool) however much STX they want at any time, for whatever future reward cycles they desire (within reason). There shouldn't be any way to "game" Stacking.

Better In-band Upgrades

By design, there are numerous ways to soft-fork the Stacks blockchain. However, there are few areas where it could be improved:

• Voting to stop the network. Stacks 2.1 is a pre-planned network upgrade (not to be confused with a hard fork). The Stacks 2.0 blockchain will die at Bitcoin block 700,000. However, I doubt that this is the last time the users will want to make backwards-incompatible changes to the network. So, I think there needs to be a way for miners and STX holders to vote on a "stop date" for the current version of the blockchain, such that developers have ample time to release an upgraded version of the blockchain with the new changes. So if there is ever a Stacks 2.2 release, it will only happen if STX holders and miners vote for it. This differs from voting for a hard fork, because if the vote passes, the current chain will die at a pre-determined block height (so there is no risk of an unforced chain split). Any new chain will simply pick up where the old chain left off.

• Voting to extend the PoX sunset date. PoX does not (and cannot) last forever, because it is not incentive-compatible with mining in the long term. In case this leads to problems, the chain already supports Stackers voting to disable PoX in order to keep the chain alive. However, there is no mechanism to vote to extend PoX, should PoX prove more resilient than we anticipated. I think it may be worthwhile to make it so STX holders can vote to continue PoX past its targeted sunset date.

• Voting on which contract is the PoX contract. I very much doubt that whatever happens in Stacks 2.1 is going to be perfect for all of eternity. I think there needs to be a way for miners and STX holders to be able to decide which contract gets used to execute PoX. That contract must conform to the PoX contract's interface (because the node needs to be able to do some bookkeeping internally whenever methods like stack-stx are called), but as long as a contract can be implemented with that trait, the users of the system can upgrade it.

Better Clarity APIs

Clarity has native access to Bitcoin state, but its current APIs for reading with it are somewhat rudimentary. I think there's a lot of room for improvement here (most of which could be written in Clarity itself!), but there's a few things that would need to be done through a network upgrade. These include:

• Expose PoX reward set info. The PoX contract could represent each reward cycle's list of Bitcoin reward addresses as a list, and keep track of whether or not the Bitcoin address has been up for payment by miners (and how much BTC has been received). I believe this would enable Clarity developers to write much more interesting and complex financial derivatives built on top of Stacking.

• Handle PoX STX locking in Clarity. Right now, the node itself manages locking up STX internally. I think this should be moved into the PoX contract itself, so that (1) the locked/unlocked balances can be exposed to contracts, and (2) the lockup semantics can potentially be changed if we can make it so miners and users can vote to change the PoX contract.

• Native Merkle proof verification. There should be a Clarity API that (1) defines a canonical representation for a Merkle proof that links a burnchain transaction to a burnchain block header hash, and (2) verifies that a given proof links a given transaction to the burnchain (I intentionally say "burnchain" because this could be Bitcoin, or another instance of the Stacks chain). This could potentially be written in Clarity, but I don't believe anyone has tried doing this yet. There needs to be a case study on how hard this would be to do, so we can figure out if there's anything missing from Clarity that would prevent someone from doing this.

  • More get-block-info? information. At a minimum, the get-block-info? function should let Clarity code look up a Bitcoin or Stacks block hash from a Bitcoin or Stacks block height. I think this is all but required in order to implement Merkle proof verifications above.

• More Clarity Built-ins. There's no end of new things to add to Clarity to make it better. I think we should take advantage of the Stacks 2.1 upgrade to add a few of these. For example, there is already code written to add support for a tx-sponsor keyword (indicating the principle who sponsored the transaction; this is not always tx-sender) and a stx-transfer? variant that includes a memo (which improves exchange integration).

Reliability Improvements

There are a couple of things that could make mining and Stacking more reliable, but would require a network upgrade to achieve. These include:

• Fix mean-of-min-and-median sortition logic. The sortition weight a miner gets when mining STX is a function of how continuously they mine. This is intentional, because it raises the barrier to entry for discount-mining -- a behavior whereby a miner Stacks their STX in order to reduce the amount of BTC they need to spend to mine. Making it so a miner's sortition weight is a function of many block-commits increases the number of STX they must Stack in order to do this reliably. Right now, there is a bug in the way the mean-of-min-and-median is calculated, which causes a missed sortition to over-penalize a miner by reducing their commitment weight to the minimum amount. This should be fixed in 2.1.

• Better tolerance for flash blocks in the prepare phase. A Bitcoin behavior we did not anticipate was the presence of flash blocks -- two or more Bitcoin blocks that arrive so quickly that Stacks miners don't have a chance to mine in them. If these happen in the PoX prepare phase, they reduce the quantity F * w, which is used to determine how much agreement exists between miners about the PoX reward set. If this value is less than 80%, then PoX is disabled for the subsequent reward cycle (see SIP-007 for details). I believe that flash blocks unfairly penalize the network's measurement of F * w -- I think that the first 10-ish flash blocks shouldn't count towards the F * w calculation. This would make it far less likely that a flurry of Bitcoin mining activity doesn't accidentally shut down PoX, even though all Stacks miners are reliable.

• Order-independent multisig signing and verification. Right now, the Stacks transaction wire format implicitly requires signers to sign in the given public key order. This could be fixed so that the signing order does not matter, but it would be a breaking change.

EDIT:

• Adjusted runtime costs. Right now, the built-in runtime costs are very pessimistic, which makes it tricky to implement smart contracts that deal with lots of iteration over lists and buffers. In general, runtime costs for "fast" computations should be brought down, but we will need to study the relative performance of each Clarity built-in to get a better sense of what the cost functions should be.

---

I think all of the above could be written as a set of SIPs that describe the Stacks 2.1 blockchain (perhaps one per theme?). Please let us know what you'd like to see. Also, don't be afraid to add new ideas or suggestions for backwards-incompatible changes you'd like to see!

Best,
Jude

[hstove]

What an amazing post, I'm so excited for things to come. Does your point around "Fine-grained bidding" essentially also cover #8? I am mainly thinking about smart contracts that stack. In addition to adding more to your stack, an ideal scenario would be to allow a stacker to unlock some of their stack, but not all.

Native Merkle proof verification.

This would be an amazing primitive. I haven't actually begun writing Clarity code, but I've been looking into the work required. At the moment I don't have reason to believe it's not possible today in Clarity, but I can see that a native primitive might be more robust. If I was going to write a verifier, I'd probably start with a few happy paths that cover obvious use cases, but a verifier for all burnchain transactions is probably better done in Rust. Having read a few other verification implementations, there is usually some looping involved. Still, probably not non-deterministic, but I don't really know.

I also have some other random thoughts around potential Clarity improvements. Is the best place for a suggestion the stacks-blockchain repo (tagged as 2.1), or the Clarity repo?

[hstove]

A simple version - using a constant to reference a static contract identifier

(use-trait ft-trait 'ST3J2GVMMM2R07ZFBJDWTYEYAR8FZH5WKDTFJ9AHA.ft-trait.ft-trait)

(define-constant TOKEN 'ST3J2GVMMM2R07ZFBJDWTYEYAR8FZH5WKDTFJ9AHA.cat-token)

(define-public (get-name)
  (contract-call? TOKEN get-name)
)

Returns Error (line 6, column 3): use of undeclared trait <TOKEN>.

Storing traits:

(define-map contracts-by-name { name: (string-ascii 32) } { contract: <ft-trait> })

Gives ASTError(ParseError { err: TraitReferenceNotAllowed, pre_expressions: None, diagnostic: Diagnostic { level: Error, message: "trait references can not be stored", spans: [], suggestion: None } })

Storing principals obviously can't be used in contract-call, but the error is weird:

(define-map contracts-by-name { name: (string-ascii 32) } { contract: principal })

(map-insert contracts-by-name { name: "Cat" } { contract: 'ST3J2GVMMM2R07ZFBJDWTYEYAR8FZH5WKDTFJ9AHA.cat-token })

(define-public (get-name)
  (contract-call? (get contract (map-get? contracts-by-name { name: "Cat" })) get-name)
)

Gives missing contract name for call.

Even if you "trick" the parser by loading a principal that is static, you get the same error:

(define-constant contract (list 'ST3J2GVMMM2R07ZFBJDWTYEYAR8FZH5WKDTFJ9AHA.cat-token))
(define-public (get-name)
  (contract-call? (unwrap-panic (element-at contract u0)) get-name)
)

Gives missing contract name for call..

There are workarounds - you either hard-code the contract identifier (if it's static) into every contract-call?, or you only allow dynamic contract calls via trait arguments to a function. Hard-coding results in less readable code (also easier to make mistakes). Only using trait arguments works too, and almost all scenarios (like a registry that only allows certain contracts) can work by checking (contract-of <ft-trait>) against a stored contract principal. Maybe there are perfectly valid reasons for this, but it's kind of a head-scratcher to how I'd usually write code.

[jcnelson]

Ah.

The reason this isn't done today is because the Clarity VM needs to be able to determine the whole set of traits it's going to need before it attempts to actually execute any code. This is because the analysis step itself needs to type-check the whole contract first, which includes verifying that any contract implementations referenced conform to a given trait definition.

If we didn't do this, then type-checking would actually be impossible. Consider this example:

;; Suppose you deployed both the FT and NFT traits already.
;; Suppose that ft-trait has a function `get-name` that returns a (string-ascii 128)
;; Suppose that nft-trait has a function `get-name` that returns a uint
(use-trait ft-trait 'ST3J2GVMMM2R07ZFBJDWTYEYAR8FZH5WKDTFJ9AHA.ft-trait.ft-trait)
(use-trait nft-trait 'ST3J2GVMMM2R07ZFBJDWTYEYAR8FZH5WKDTFJ9AHA.nft-trait.nft-trait)

(define-constant LIST_OF_ALL_1_BYTE_BUFS (list 0x00 0x01 0x02
  ;; omitted for brevity
  0xfe 0xff))
  
(define-private (get-vrf-random-byte)
  (index-of LIST_OF_ALL_1_BYTE_BUFS (get-block-info? vrf-seed block-height))
)

(define-private (pick-random-trait-definition)
   (if (is-eq (mod (get-vrf-random-uint) u2) u0)
     ft-trait
     nft-trait
   )
)

(define-public (get-name)
   (contract-call? (pick-random-trait-definition) get-name)
)

Now, what type does get-name have? Depending on pick-random-trait-definition, it could be a (string-ascii 128) or a uint. You won't know until the transaction gets mined. So not only do we not know what type get-name has, but also we don't know what type anything that calls get-name has. This isn't desirable behavior -- full type analysis of Clarity contracts before they execute is a design goal of Clarity, and this would prevent us from having it.

Now, I could imagine that we could add an analysis pass that inlined all define-constants, but with the constraint that only literal expressions will be considered. This probably needs a new keyword for this (define-literal-constant or something). This is because in general, you can't inline define-constant since the following code is also legal in Clarity:

;; suppose LIST_OF_ALL_1_BYTE_BUFS is given as a literal (list 0x00 0x01 0x02 ... 0xfe 0xff) here
(define-constant RANDOM_TRAIT
   (if (is-eq
      u0
      (mod (index-of LIST_OF_ALL_1_BYTE_BUFS
         (element-at u0 (get-block-info? vrf-seed block-height))) u2))
      nft-trait
      ft-trait))

RANDOM_TRAIT gets set to whatever the VRF seed allows it to evaluate to at instantiation time, and then it gets inlined everywhere in the AST.

[hstove]

Hm, first of all, what is the return type of the trait reference itself? I'm surprised that (ok ft-trait) is valid clarity. Is that a principal?

I suppose I'd prefer a new type, like a type meaning "principal that is a contract that conforms to this trait". Then, you couldn't have a function that can return a principal of two different traits.

But we can table this discussion, there are more interesting things being discussed here, and my example is not a big problem.

[jcnelson]

I don't think (ok ft-trait) is valid Clarity. Can you give me an example? Here's what I'm using:

$ cat /tmp/trait-ref.clar 
(define-trait test (
    (get-name () (response uint uint))
))
$ clarity-cli launch ST3J2GVMMM2R07ZFBJDWTYEYAR8FZH5WKDTFJ9AHA.test /tmp/trait-ref.clar /tmp/test-traits.db
Contract initialized!
$ cat /tmp/trait-ref-impl.clar 
(use-trait test 'ST3J2GVMMM2R07ZFBJDWTYEYAR8FZH5WKDTFJ9AHA.test.test)
(define-public (get-name)
    (ok u0))

(ok test)
$ clarity-cli check /tmp/trait-ref-impl.clar /tmp/test-traits.db/ --contract_id ST3J2GVMMM2R07ZFBJDWTYEYAR8FZH5WKDTFJ9AHA.test
Error (line 5, column 4): use of unresolved variable 'test'.

[hstove]

My example came from your code in the comment above:

(use-trait ft-trait 'ST3J2GVMMM2R07ZFBJDWTYEYAR8FZH5WKDTFJ9AHA.ft-trait.ft-trait)
(use-trait nft-trait 'ST3J2GVMMM2R07ZFBJDWTYEYAR8FZH5WKDTFJ9AHA.nft-trait.nft-trait)

(define-private (pick-random-trait-definition)
   (if (is-eq (mod (get-vrf-random-uint) u2) u0)
     ft-trait
     nft-trait
   )
)

But, yeah, makes sense that it's not valid.

[kantai]

These proposed changes look great to me -- I just want to add here what the priorities for 2.1 are from Hiro's perspective:

Stacking / PoX Contract

1. Extending a lockup without altering amount: this enables continuous stacking.
2. Incremental adjustments up of locking amount: similar to item 1. If implemented correctly, these can be in arbitrarily small increments.
3. Unlock if threshold not met: give people who get priced out of a cycle the ability to unlock. This wouldn't necessarily be automatic, because it isn't a "cheap" operation, and we want to be careful not to force nodes to do too much work at the start of a reward cycle. This could include allowing an address to "reduce" their commitment before a cycle starts.
4. Using PoX as Foundation for other protocols using STX as burn : This is perhaps more of a question of publishing documentation or a SIP outlining a design for this.

BNS

1. Address renewal issue: Pretty straight forward -- renewal doesn't work as we'd want, and we should fix that in 2.1.

Clarity

1. Burnchain Supports: Like you mentioned in your list, there's many things that could make Clarity contracts that interact with burnchain data much easier. I think this means starting with a case study contract, and seeing where the pain points are.
2. Various nice-to-haves: Native buff -> uint conversions, decoding Clarity serialized values.
3. Some fixes: A fixed (principal-of?), perhaps some utility functions for testnet/mainnet address detection.

[kantai]

One thing I would add regarding PoX -- if we can figure out a good way to make the whole contract upgradable in 2.1 via on-chain mechanisms, that'd be great, but I think that should be secondary to implementing the improvements to PoX. Upgradability would be very nice going forward, but most ways I can think of implementing it would require some potentially dangerous features to be exposed (i.e., moving locking/unlocking logic into Clarity), and I'd be worried that over-indexing on upgradability could prevent us from making improvements to Stacking that address the most pressing pain points.

[jcnelson]

That makes sense to me. I think adding a Stop the chain at height XXX voting procedure would be 90% as effective as making it so the PoX contract could be changed in-band, and 10% of the effort (or less).

[jcnelson]

Like you mentioned in your list, there's many things that could make Clarity contracts that interact with burnchain data much easier. I think this means starting with a case study contract, and seeing where the pain points are.

I've started taking a crack at a Bitcoin transaction parser, and I can definitely say that having some kind of slice built-in for sequences would make my life a lot easier. Also a chomp method, to take the first n bytes of a sequence.

[hstove]

Burnchain Supports: Like you mentioned in your list, there's many things that could make Clarity contracts that interact with burnchain data much easier. I think this means starting with a case study contract, and seeing where the pain points are.

How can I help with coming up with examples? The number one thing I think of is an easy way to prove "This txid sent XX sats to Y output". A simple example is accepting BTC payment for an NFT. The Stacks contract would store the payment BTC address and maybe a minimum amount. Anyone who can prove they sent the minimum BTC to that address can claim the NFT by giving that payment info to a Stacks contract.

Even with that relatively simple example, you get some complications. How do you know the claimer isn't front-running the proof of someone else's payment? Perhaps the NFT contract could say "The second output of the tx is the recipient of the NFT" - kinda like making a PoX stack-stx tx on BTC. In that case, you probably also need a helper for getting a principal from the Nth output of a tx. Or a similar way would be to get the principal of the Nth input of the tx. Of course, this only works for inputs/outputs that can map to a Stacks principal.

Beyond this, the only other use case I can imagine is "prove that Y address received X PoX rewards in this block". This is going to be a common use case for delegated stacking scenarios. This can be done via simple BTC tx proofs, but then you need to make a Stacks tx for every PoX reward tx. If there aren't issues with creating a helper method like "return the amount of BTC given as reward tx's in a block to Y BTC address", then I imagine it would be very helpful. Another reason for scoping this is because the contract author might want to limit things to just valid PoX reward transactions, instead of all BTC tx's, at which point you have to verify the OP RETURN

[jcnelson]

To avoid front-running, you'd probably want to look at the public key(s) in the Bitcoin transaction input scriptSigs. You could use (principal-of?) to convert them into Stacks addresses, and use those address(es) to determine where to send the NFT. Then it doesn't matter if someone else calls your contract's "claim" interface -- the only things that could happen are either (1) it fails and no NFT gets minted, or (2) the NFT gets minted to an address that was already stipulated in the Bitcoin transaction. You're not restricted to using just scriptSigs, btw -- you could instead put the NFT owner's public key into an OP_RETURN, and then use (principal-of?) to convert it into the NFT's recipient principal. Trouble is, (prinicpal-of?) is broken on mainnet right now :( -- it only works on testnet.

Another reason for scoping this is because the contract author might want to limit things to just valid PoX reward transactions, instead of all BTC tx's, at which point you have to verify the OP RETURN

I think we'd want to expand the PoX contract to return the list of reward addresses in Clarity -- including whether or not they've been paid out to. I think we'd also want to offer ways to convert a (version, hash160) to and from a principal type, so you could convert between Bitcoin and Stacks addresses. But, both of these things need to wait until 2.1.

[LNow]

I think that the first 10-ish flash blocks shouldn't count towards the F * w calculation.

We can't predict if nor when flash blocks appear, and we can't eliminate them, so maybe we could set up a boundary below which we would consider block as being "flash" and like you proposed don't count them in calculation.

For example, if the time between mining of two blocks N and N+1 is less than 10 seconds, then block N+1 does not participate in calculation or its influence is reduced.

That way if suddenly we'll have a technological breakthrough and hashpower skyrocket, we'll survive until next BTC difficulty adjustment.

[jcnelson]

so maybe we could set up a boundary below which we would consider block as being "flash" and like you proposed don't count them in calculation.

This generally isn't possible :/ Bitcoin block timestamps aren't tightly synchronized -- a Bitcoin block can both be a valid block and a "flash block" even if its timestamp is 2 hours greater than its parent block. Moreover, there's no way to know when all Bitcoin nodes actually receive their blocks, so there's no way to deterministically identify a Bitcoin block as a "flash block."

The closest we can get here is to allow up to 10 (or whatever) blocks in the prepare phase to simply not have a sortition before causing F * w to decrease. It's not important as to why exactly there was no sortition, since the F * w calculation is only meant to measure network health. I'm proposing that this calculation reflects something more refined than it does now: "80% of non-empty sortitions confirmed the same anchor block, and 80% of Bitcoin blocks had a non-empty sortition".

[friedger]

Continuous Stacking. There needs to be some way for Stackers to avoid missing a reward cycle in-between Stacking their STX.

Why is that? What is the purpose of Stacking? Does stacking for more than once cycle helps the network? Should one long stacking period by one user rewarded more than several short stacking period by another user?

Stacking distributes block rewards between stackers and miners. Stacking also let stackers indirectly vote on chaintips. It would expect stackers to have a more meaningful role in the consensus than optimize for APY.

[jcnelson]

These are excellent points. You're absolutely right that Stacking for 1-cycle intervals is more helpful to the network than Stacking once for a 12-cycle interval. However, the system today unfairly penalizes users for Stacking in 1-cycle intervals (by adding a cool-down cycle), even though they're helping the network more. Adding continuous Stacking takes this unfair penalty away -- with continuous Stacking, the only financial downside for Stacking for 12 1-cycle intervals would be that the user needs to pay 12 transaction fees.

Even though there could be higher transaction fees, Stacking for 12 1-cycle intervals is a lot less risky than Stacking for one 12-cycle interval. This is because PoX is not guaranteed to activate in each reward cycle -- the miners must have 80% or higher agreement on the reward set during the prepare phase, or else the reward cycle falls back to PoB. Someone who Stacks for a 12-cycle reward interval runs the risk of having their STX locked but not earning BTC for multiple reward cycles, whereas someone who Stacks for a 12 1-cycle intervals has the chance to do other things with their STX if the network is too unstable for PoX.

We're generally open to making other changes to PoX in order to make Stacking more helpful to the network, if you have other ideas.

[jcnelson]

Regarding in-band signaling, it would be best to try and implement them as part of the prepare-phase (so miners must burn, and the decisions are all visible regardless of Stacks block availability). Also, we could add a SIP for just signaling support for various upgrades -- possibly off-chain.

[philiphacks]

Great summary Jude! I don't have much to add beyond the comments already given. I would love to see continuous stacking & multiple stacking commitments for one principal (already discussed & confirmed here: #8).

I don't know if the following is technically feasible, but another wish would be access to bitcoin without having to use wrapped bitcoin. E.g. through a timelock with multisig it would be possible to be one of the signers of a bitcoin transaction, and this would give control over the bitcoin or allows a smart contract to check whether bitcoin is locked or not. This way (e.g. in Arkadiko), you could create a stablecoin collateralised by bitcoin without it leaving the bitcoin blockchain. I imagine there are lots of other use cases with this. Thinking out loud here, so not sure if this logic makes sense.

Ultimately, bitcoiners don't necessarily want their bitcoin to leave the bitcoin blockchain, even if it's a sidechain like Stacks. A trustless wrapped bitcoin would be a good alternative tho.

[jasperjansz]

+1 a two-way peg where the peg out is done as part of the Bitcoin protocol (so no federation, no overcollateralization in STX) would enable many defi apps. I'm aware of the likes of Drivechain but I wonder if PoX unlocks some new methods.

[jcnelson]

Ultimately, bitcoiners don't necessarily want their bitcoin to leave the bitcoin blockchain, even if it's a sidechain like Stacks. A trustless wrapped bitcoin would be a good alternative tho.

We're not a side-chain :) Unlike sidechains/drivechains, Bitcoin miners aren't aware of Stacks' existence and do not take any part in validating Stacks transactions. This makes Stacks a wholly-separate blockchain in its own right. This is intentional -- for reasons discussed in Muneeb's PhD thesis, trying to get Bitcoin miners to help validate other chains' states has proven to be dangerous in practice. This is because doing so requires a significant majority of validation participation from Bitcoin miners, which not only is a tall order because Bitcoin miners act autonomously, but also would severely limit the scalability of the system.

That said, the fact that Bitcoin miners don't (and won't) validate Stacks state means that it's basically impossible for Clarity programs to directly control a particular locked BTC on-chain -- any system that could facilitate this necessarily depends on Bitcoin miners coordinating with Stacks miners, which in turn requires Bitcoin miners to validate Stacks chain state.

But, I don't think you need to wait for Stacks 2.1 for wrapped BTC -- you can implement wrapped BTC without over-collaterialization or federation today. Now, there are many ways to instantiate wrapped BTC on the Stacks chain, so I won't bore you with that. The hard part is converting wrapped BTC back into BTC. There are many ways to do this with federation and/or over-collateralization, but I think there's a third way that doesn't require either.

To do so, you'd need to create an escrow contract that holds wrapped BTC, and gives it out to wrapped BTC buyers if and only if the buyer submits a Bitcoin transaction and a Merkle proof that they had sent the equivalent amount of BTC to the wrapped BTC seller. For example, suppose Alice has 1.0 wrapped BTC she wants to sell. Alice puts her wrapped BTC into this escrow contract, as well as a Bitcoin address, a memo, and a STX transfer fee to be paid to the buyer upon delivery of the real BTC (the STX transfer fee gets used to prioritize transfers -- it basically pays for the buyer's Bitcoin transaction fee, plus a "tip" to ensure prompt service). The memo would need to be globally-unique and one-time use -- it would be used to prevent replay attacks on the contract (i.e. to ensure that a buyer can purchase at most once with a given Bitcoin transaction).

Suppose Bob wants to buy 0.2 wrapped BTC. He'd do so by sending a Bitcoin transaction that pays to Alice's Bitcoin address, and includes Alice's memo in an OP_RETURN output. Bob can then submit the raw Bitcoin transaction and a Merkle proof of its inclusion to the escrow contract, and in doing so, claim 0.2 of Alice's wrapped BTC plus Alice's service fee. The act of Bob submitting his proof would also update the nonce the next seller needs to use, by e.g. hashing it with itself (thereby ensuring it's unique w.h.p.). Because the memo keeps changing, Bob can only claim 0.2 wrapped BTC -- he can't re-submit the same transaction over and over. Alice would set the STX service fee to be high enough that Bob can earn a STX profit doing this. Also, Bob can simply Stack his STX to get more BTC to sell.

All you'd need to have to achieve this is a way to parse Bitcoin transactions in Clarity, and a way to verify Merkle proofs. I'm confident you can write this right now -- I'm working on a library that does this in my spare time.

[philiphacks]

thanks for the elaborate feedback, I'll have to go through to understand it completely, but makes sense :)

[Zk2u]

Could we get support for accessing the Bitcoin blockchain from smart contracts? I think it's pretty important since we are bringing smart contracts to Bitcoin, it should be able to interact with the native chain.

[jcnelson]

Oh, my mistake -- I misread your question.

current bitcoin block

So, there's (get-block-info? burnchain-header-hash burn-block-height), which gives you the highest confirmed Bitcoin block header hash. From there, if a transaction gave you a Bitcoin block header, you could use this to authenticate the header. Using the authenticated header, a transaction could then submit and authenticate Merkle proofs that proved that a transaction was included in the Bitcoin chain.

getting bitcoin supply

You can calculate this in a contract from the Bitcoin block height (exposed to Clarity as the burn-block-height variable), since we know in advance at which heights the halvenings happen and what the emission rate is at each block in-between two halvenings.

getting transactions for an address
getting a bitcoin address' balance

Generally speaking, we'd like to avoid having to do either of these because they vastly increase the amount of resources required to run a Stacks node. You'd basically need to implement a full Bitcoin block explorer inside the Stacks node. Moreover, it would be a consensus-critical block explorer, because Stacks transaction validation would depend on its behavior.

Is there a particular problem you're trying to solve which cannot be solved without one or both of these?

[Zk2u]

for metaverse pool:

currently, we have to verify a bitcoin contribution to the mining pool outside of the contract. we have to identify this contribution as being from a stacks address (the bitcoin may have come from a different bitcoin address). it would be really useful if we could do this with a smart contract, so the contract could verify that a contribution by a certain address happened and not rely on a separate API service to call it.

though it's worth saying this isn't essential right now, and it does work without doing this. it just takes a bit more trust out of our hands.

[cryptopanter]

Thanks Jude for your explanation..
Actually we are working on a trustless bitcoin mining platform and it needs to have read/write access to Bitcoin ledger...
We need to check some given Btc addresses balance & transactions and take feedback from then then sending some reward distribution into other given Btc addresses...
Since Stacks is natively connected to Bitcoin ledger, we decided to choose its advantage to implement the idea... Also Muneeb said reading feature is available now but writing feature will be enabled in the future.... Below is our Idea explanation and we know it's a big one and for the first time in crypto space. And we have found good synergy with Metaverse team to have their support to develop the idea.
Now do you think Stacks could give us any advantage in building it or we still need to stick to cross-chain networks?

A bit about the idea:
Bitcontrol is a project to solve the decentralization of Bitcoin mining and distribute more fair opportunities among small investors or individuals that don't have access to special facilities needed for Bitcoin mining... So that miners raise fund through renting their hashrates to any individual/group around the world.. Therefore, their fund and finance will be based upon those who really believe in Bitcoin ecosystem and meanwhile other users & participants can also gain mining rewards... The more mining ecosystem is distributed among crypto crowd, the more decentralized it becomes... In this regard, Bitcontrol remove the need to any credentials or trust among both miners and investors and provide a trustless decentralized platform to quickly connect miners to any-scale investors

[jcnelson]

currently, we have to verify a bitcoin contribution to the mining pool outside of the contract. we have to identify this contribution as being from a stacks address (the bitcoin may have come from a different bitcoin address). it would be really useful if we could do this with a smart contract, so the contract could verify that a contribution by a certain address happened and not rely on a separate API service to call it.

Correct me if I'm wrong, but I think you can do this right now, using the approach described here?
#16 (reply in thread) You'd require that the person who sent the Bitcoin transaction would simply mirror that transaction to the Clarity contract, as well as a Merkle proof that shows it was mined in the Bitcoin chain. Then, you could parse it and verify it sent BTC to a particular address. This is far safer than trying to build a consensus-critical block explorer within the Stacks node, and you could do this today.

You can further require that the Bitcoin transaction was sent by a particular Stacks principal by a 2-phase commit process:

1. The STX holder registers a hash of a secret value in your smart contract
2. The STX holder puts the secret value in an OP_RETURN in the Bitcoin transaction
3. The smart contract, when it accepts the Bitcoin transaction, verifies that the hash of the secret stored by tx-sender in step 1 is equal to the contents of the OP_RETURN of the transaction.

[Zk2u]

@jcnelson i will investigate this and get back to you. have not seen this yet 😄

[friedger]

Better BNS: make names SIP-009 compliant.

[Zk2u]

what do you mean by this? SIP-009 is for NFTs?

edit: wrong sip

[314159265359879]

what do you mean by this? SIP-009 is for Fungible Tokens?

SIP-009 is for the Non fungible token standard (funglible tokens is SIP 010) https://github.com/stacksgov/sips

I think what Friedger means is that the NFT's that are used for the namespaces and BNS names should be compliant to the SIP.

[jcnelson]

As promised, I did a study on how hard it would be to build a Clarity library that could:

• Parse Bitcoin transactions
• Verify that a Bitcoin transaction was mined on the Bitcoin chain, using a Merkle proof
• Parse Bitcoin block headers

TL;DR You can totally do this today! Code: https://github.com/jcnelson/clarity-bitcoin

Lessons Learned

• Reading a slice from a buffer is painful. A chomp! and a slice method would have been useful.
• Converting buffs into uints -- both big-endian and little-endian -- had to be done in Clarity. This is also painful.
• I had to roll my own bitwise-and function. We could add bitwise operations to Clarity (we only have xor right now).
• It gets painful to have to type out a long, complex tuple type signature. But I don't think there's a way we can really add type aliases without really breaking things :(

EDIT: Watching other efforts, let's add the following:

• Converting buffs to ASCII strings and UTF-8 strings, and back

[Zk2u]

awesome job! i'm gonna look through it later.

[Zk2u]

what about native segwit support?

[friedger]

Lower barrier of entry for STX mining

The current part of the protocol for mining has an incentive to reduce btc tx fees. This leads to less miner nodes because the higher your commits per tx, the smaller your extra costs for your bids.

Proposal: Use equally distributed fees as part of the sortition for each miner
In a formula: probability to win = (commit + (sum of fees / number of current miner)) / (sum of commit and fees)

Example A:

commit	fees	probability 2.0	probability 2.1
700k	50k	78%	75%
200k	50k	22%	25 %

Example B:

commit	fees	probability 2.0	probability 2.1
325k	50k	38%	37.5%
325k	50k	38%	37.5%
200k	50k	23%	25 %

Advantage
In example A, the first miner invested 750k, in example B, the first miner has two nodes and invested 750k. In Stacks 2.0, the first miner should prefer Example A, while in 2.1 both examples result in the same probability to win.

Disadvantage
In example A, stackers receive 900k, while in example B, stackers receive only 850k.

[psq]

Disadvantage
In example A, stackers receive 900k, while in example B, stackers receive only 850k.

your disadvantage could be a lot worse. Here's a third example.

Scenario C:
16 miners each commit 12.5k and pay the 50k fee, so total spent is the same 1000k as example B, each miner has a 6.25% chance of winning, but stackers will receive 12.5k * 16 (200k) => the yield gets divided by 4.5. In practice, this could be even worse as the fee today needs to be much higher than 50k per miner.

So, this could destroy the stacking yield, and I doubt we want to risk that...

[friedger]

So the discussion comes down to "number of miners" vs "stacks yield"?

[psq]

not quite how I'm looking at it, I'd think it is more about making the pie bigger by making Stacks more valuable (especially relative to bitcoin), which should allow more miners naturally.

On a more tactical level, reducing the transaction size, and therefore the fee would also help (possibly using segwit, or maybe even taproot)

[Zk2u]

can we get BLAKE3 support in Clarity?