sBTC Research - OP_RETURN vs OP_DROP

[AshtonStephens]

This is a discussion post meant to be edited with research pertaining to implementing OP_DROP (commit reveal) and OP_RETURN, and the potential that we support only one.

This research is around surrounding factors for implementing OP_RETURN and OP_DROP, but isn't about the implementation of either.

• Why is OP_RETURN unable to fulfill long-term requirements of SBTC?

• If the problem is that wallets can't produce OP_RETURN transactions, would it make sense have 3rd parties that would act as proxies between wallets and Bitcoin?

• Are OP_DROP and commit-reveal part of the same concept or are they two different approaches?

• How does commit-reveal solve the problems of OP_RETURN?

• Who are revealers and how do they work?

• What are the downsides of commit-reveal?

• Do we have any other options besides OP_RETURN and commit-reveal?

• Research legal implications of these approaches

• Research security implications of these approaches

• Research trust implications of these approaches

[AshtonStephens]

Currently under investigation by @stjepangolemac

[tycho1212]

@FriendsFerdinand, could you link the Github issue that introduced OP_DROP back in January/February? I think there's an important discussion there

A little bit of context: We’ve concluded on multiple occasions since January 2023 that OP_DROP is a superior peg-in method to OP_RETURN (first with Igor and Jude, then with Marten, etc). As a result, the sBTC BD team has been operating under the assumption that OP_DROP will be supported. It would be great if we can put this discussion to bed with a detailed sBTC SIP that includes OP_DROP so that we won’t have to repeat the same points.

1. OP_DROP significantly lowers sBTC integration efforts.

OP_DROP allows users to peg-in from any Bitcoin wallet, custodian, or exchange. OP_RETURN on the other hand only allows users to peg in from a wallet that supports sBTC peg-ins through OP_RETURN, which would be only the Leather Wallet and Xverse upon sBTC launch.

• Peg-ins from web wallets like Leather Wallet and Xverse are a no-go for institutional users. Funds have strict internal policies for which custodians they can use, and a web wallet isn’t one of them. Institutional users need to be able to peg in BTC from their custodian directly. Custodians don’t support OP_RETURN operations.

• Allowing peg-ins from any wallet, frees up valuable sBTC BD resources for Stacks integrations. If sBTC peg-ins would only support OP_RETURN, the sBTC BD team would have to push custodians/wallets to support OP_RETURN peg-ins and SIP-10 support alongside each other. These integrations can cost >$1m. Pushing for SIP-10 support is already stretching the resources of the Stacks ecosystem to its limits. Switching back to an sBTC design where peg-ins can only happen through OP_RETURN will create difficulties on integration bandwidth towards sBTC launch.

2. OP_DROP allows for superior UX. Stacks apps can now abstract sBTC peg-in operations away, enabling users to interact with apps with native BTC.

• On Zest Protocol, users send native BTC to a liquidity pool and get LP tokens back as a receipt of their position. Users never hold sBTC. See Zest Protocol demo video here which uses OP_DROP through Magic: [link]

• This UX allows Stacks apps to claim that they are ‘Bitcoin apps’ in the eyes of investors. This UX allowed Zest Protocol in summer 2023 to raise the largest VC funding round out of any Stacks app since the ALEX round at the peak of the 2021 bull market. We specifically made the argument to investors that we aren’t a Stacks app, but a native BTC lending protocol - allowing for a benchmark valuation against BTC mkt cap rather than Stacks TVL.

3. OP_DROP is significantly more tax efficient than OP_RETURN

• Wrapping BTC to wBTC or tBTC is considered a taxable event in multiple jurisdictions. Hence, on-shore institutional investors shy away from using BTC derivatives. Apps that leverage OP_DROP can take the peg-in operation out of the hands of users and make sure that users never hold sBTC, thereby making sure that users don’t trigger taxable events when interacting with Stacks apps.
• There is still no legal clarity in the US on whether wrapping BTC is a taxable event. Many institutional investors that we’ve spoken to take the conservative approach of considering wrapping BTC a taxable event until further clarity will be given (if ever).

[jcnelson]

1. OP_DROP significantly lowers sBTC integration efforts.

What if, instead of supporting OP_DROP, the user simply sent their BTC to a 3rd party relay service which then executed the OP_RETURN transaction for them? Assuming a trusted 3rd party relayer could be found, is there any reason why this would not work?

2. OP_DROP allows for superior UX. Stacks apps can now abstract sBTC peg-in operations away, enabling users to interact with apps with native BTC.

In the examples you gave, wouldn't the same end be achievable with the OP_RETURN system with a trusted 3rd party relayer? The OP_DROP encodes exactly the same information as the OP_RETURN.

3. OP_DROP is significantly more tax efficient than OP_RETURN

Using a 3rd party relayer could also "take the peg-in operation out of the hands of users and make sure that users never hold sBTC," right? It seems that making someone else do the wrapping/unwrapping is orthogonal to the OP_DROP vs OP_RETURN approach.

[jcnelson]

It also occurs to me that the hypothetical 3rd party OP_RETURN relayer could either be the Stackers, or could otherwise be a set of signing parties built for the purpose. The relayer implementation would be a lot like that of the Stacker -- relayers would coordinate via a StackerDB instance to execute WSTS DKG and WSTS signing rounds to consume BTC from users and emit signed OP_RETURN peg-ins.

[tycho1212]

We had a lengthy discussion about trusted 3rd party relayers with Marten, Tyler, and @jferrant in New York in August.

A trusted 3rd party relayer isn't going to be found. This party would have to be a money transmitter for non-KYC'ed BTC. A total legal nono

It also occurs to me that the hypothetical 3rd party OP_RETURN relayer could either be the Stackers, or could otherwise be a set of signing parties built for the purpose.

@FriendsFerdinand this sounds like a similar system to OP_DROP? Yet, OP_DROP would be more secure since it doesn't rely on the Stackers to process peg-ins but rather on the Clarity contract you built. A set of signing parties built for this purpose would create a problem of incentivisation (how do we make sure they are honest?) to which the only answer is to pay these signers fees, but then we start messing with the core value prop of sBTC peg-ins which is free movement between sBTC<>BTC

[stjepangolemac]

sBTC proposal: Using OP_DROP instead of OP_Return:

https://docs.google.com/document/d/1bbz4dY47qjZzafUFD2Pa2EaDOxDC_L1DIW4o0jo5Lkg/edit

A lot of discussion in this issue:

https://github.com/Trust-Machines/stacks-sbtc/pull/268

[AshtonStephens]

Another doc on commit-reveal: https://stacks-network.github.io/sbtc-docs/sbtc-operations/commit-reveal-system.html

[FriendsFerdinand]

I'm currently writing the specs in response to the fact that the signers cannot generate a reveal transaction. The previous threads were written under that assumption.

[jferrant]

Complexity concerns:

For stackers to become revealers, assuming that some API is set up with the reveal script or some stacker db instance is created to share reveal scripts with stackers, the complexity required to add commit-reveal from the stackers perspective is minimal. It will be essentially just one more type of stacker db event/peg in transaction type to handle.

However, complexity gets introduced due to the need for creating the backchannel that actually sends the necessary info required to reveal the commit to the signers. There also needs to be some API call or function that should be callable to return the resulting address to commit funds to. (See the current sBTC bridge)

Security implications:

Adding commit reveal to the stackers list of responsibilities is the exact same security concern as the sBTC / stacker system as a whole. The commited funds/DKG aggregate public key are being controlled by a set of stackers who in theory could be malicious. Minimizing the liklihood of a majority stackers (by weight) being compromised minimizes the risk for all transaction types including the commit reveal type

The only other security concern is that the means to unlock the committed funds must be secured. This reveal script must be well formed (but this is on the service that creates it to do essentially) and should have the means to be relciamed if the revealer chooses to ignore these funds.

Legal implications:
The same legal implications that exist for a single entity gaining majority control of the aggregate public key and becoming a money transmitter exist for the commit reveal system.

[FriendsFerdinand]

@jferrant Before the August New York Core Engineering retreat, the signers were expected to perform the reveal part of the scheme. Because of the complexity, after New York, it was decided that there would be a third party who would hold the funds, then play the part of the revealer by sending the funds to the Treshold wallet.

Both solutions were not acceptable, the former because it's too complex for the signers and the latter because we're giving too much trust to a 3rd party.

In response, I wrote a different implementation that I'm currently in the process documenting.

In this scheme, the user sends the Bitcoin to an address that is a taptree. In this taptree, there are 2 tapleaves just like in the OP_RETURN scheme (deposit & refund routes). The difference is that the deposit script looks like this*:

{sbtc_payload} OP_DROP {signers_pubkey} OP_CHECKSIG

Where sbtc_payload is the same data that goes after the OP_RETURN op code in the first scheme. At this point, there is no difference between this and the first implementation (before New York).

However, in the new implementation that I'm proposing, there is no need for a reveal step where the UTXO has to be spent to reveal the witness script. We can verify the existence of this commitment script in an output by making a contract call on a Clarity contract and providing the arguments required (sbtc_payload, bitcoin_inclusion_proof).

In this scenario, anyone can prove the inclusion of this commitment in a taproot v1 pubkey by providing the values required. If the existence of this Bitcoin transaction is proven through a contract call, then signers can treat this UTXO like a deposit to the threshold wallet.

So, the steps are:

1. User commits the Bitcoin by sending the Bitcoin to an address with the embedded sbtc payload
2. Anyone confirms the existence of this UTXO with a contract call in a Clarity contract.
3. At this point signers are aware of this UTXO and can treat it like any other UTXO that is sent to the signers

This new scheme has a dependency though. That is, we either need to include 256-bit integers (and its arithmetic) or a secp256k1 library (a subset of 256-bit arithmetic) to Clarity.

The example Clarity code is written here: https://github.com/FriendsFerdinand/clarity-commit-reveal/blob/commit-reveal-redo/contracts/commit-submission.clar#L9

It can run on Clarinet simnet, but has to run for multiple hours to complete. The reason it's so slow it's because I had to write the required 256-bit arithmetic in Clarity. But it runs.

[jcnelson]

To be clear on something here: in general, the smart contract cannot determine of a TXO is unspent. However, in this specific case, step (2) of your algorithm requires supplying the contract enough information to reconstruct the entire taproot tree and check that its root value is equal to the TXO's scriptPubKey. From there, the contract can deduce that the TXO is not only unspent, but also not yet registered with the peg wallet. If so, then it can complete the deposit.

We have two tree branches to consider:

• The deposit redeem script. Stackers reconstruct this with the given sBTC payload and signer public key. Stackers can determine that this TXO is not yet accounted for by checking .sbtc's internal state, which includes the set of all wallet UTXOs (as is called for by the SIP).

• The withdraw redeem script. This takes the form <unlock-block-height> OP_CHECKLOCKTIMEVERIFY OP_DROP <signature> <sender-pubkey>, which can be spent with the usual OP_DUP OP_HASH160 <signer-pubkey-hash160> OP_EQUAL OP_CHECKSIG scriptPubKey once <unlock-block-height> passes. The <sender-pubkey> and <signature> values would need to be supplied to .sbtc as arguments in order to reconstruct this script.

How does the contract authenticate the values? The <unlock-block-height> value could be authenticated by the script in the current reward cycle R -- the script could require that it's always the start block of reward cycle K + R for some constant K > 1. If the current reward cycle is less than K + R, then the contract can deduce that this branch cannot have been executed yet, so it must be a UTXO if it's not already accounted for in the .sbtc UTXO set.

What I'm currently stuck on is how <signature> is supposed to be authenticated. I suppose the contract could calculate the transaction's sighash value, but that would be prohibitively expensive in Clarity and would be very, very complex -- we'd be doing the same exact things that Bitcoin does when it authenticates transactions. Is there any way we can avoid doing this? What are the implications of only checking that <signature> is well-formed, but not that it is valid?

[jcnelson]

Adding commit reveal to the stackers list of responsibilities is the exact same security concern as the sBTC / stacker system as a whole. The commited funds/DKG aggregate public key are being controlled by a set of stackers who in theory could be malicious. Minimizing the liklihood of a majority stackers (by weight) being compromised minimizes the risk for all transaction types including the commit reveal type

A related concern is determining whether or not the Stackers can complete the peg-in at all. If the value to be pegged in is too small to cover the requisite transaction fee, or too low to guarantee a fast confirmation time, then what's the upside to Stackers for even processing these peg-ins? We can't force them to process them, because Bitcoin transaction fees and confirmation times are out of our hands. An attempt to punish Stackers for the behaviors of Bitcoin miners would lead to a prohibitively brittle system. But even if transaction fees and timely confirmations weren't a concern, Stackers could simply pretend to have not seen the peg-in transaction. They have no financial incentive to spend extra cycles and take extra risk on providing this service.

[muneeb-ali]

I need to dig in on more details here before commenting on OP_DROP vs OP_RETURN. However, I want to quickly raise one point. At the stage of implementation that we're at and the short timeline that we're operating against, introducing any additional implementation work is something we should be very careful about. If path (a) already has an implementation and significant work has happened on that path and path (b) may (or may not) have clear benefits but will add implementation overhead, then I'd give a heavy weight to the implementation overhead. Shipping the first version of sBTC is the goal here. Obviously things will evolve/change after the first release.

[tycho1212]

The OP_DROP implementation work is essentially finished by @FriendsFerdinand

[jcnelson]

So is the OP_RETURN work, and additional work would need to be done to support OP_DROP in the node.

[FriendsFerdinand]

Following the discussion in the SIP review, it was deemed necessary to include the Commit-Reveal deposit method in the hard fork because it has to be part of consensus to function.

To respond to the concerns regarding signature malleability, Commit-Reveal deposits may only be used once and their TXIDs must be recorded.

[AshtonStephens]

Adding to this; it turns out that our primary security concerns, under the new method that doesn't require either the signer or a trusted third party revealer, are no longer a concern. Additionally, the functionality of OP_DROP can be implemented without much more work than is already planned.