# Three possible methods to integrate Bitcoin Runes to Rosen Bridge
For the Rosen’s Bitcoin bridge, we are utilizing the OP_RETURN field to store bridge-related data on the Bitcoin network, such as the destination chain and address. However, since the OP_RETURN field is also employed by the Runes protocol, we need alternative solutions for Runes to coexist without conflicts.
We are currently exploring three different methods to address this issue:
## Method 1: Dual Transactions — One on Ergo and One on Bitcoin
**Requirements:**
- **User Requirement**: Possession of an Ergo wallet containing a minimal amount of Erg to cover one transaction fee.
- **Rationale**: This prevents Denial of Service (DoS) attacks on the ticketing system.
- **Mitigation Strategies**:
- Development of a faucet to distribute this small amount of Erg after certain conditions are met.
— Implementing some session mechanism for handling the creation of a ticket transaction via Rosen App’s backend. This allows the creation of a ticket transaction with fees paid by Rosen services when user has a valid session. This also allows the creation of a ticket transaction by user himself as long as he has an Ergo wallet, to avoid blockage and censorship attacks.
**Process Description:**
1. A ticketing contract on Ergo stores the bridge data and generates a ticket number, acting as a sequence number for Bitcoin’s lock transaction. The user interface facilitates this operation.
2. Users must have a valid session in the Rosen App or sufficient Erg in their Ergo wallet to pay the transaction fees, preventing the misuse of free ticket creation.
3. After ticket generation on Ergo, users transfer Runes to the bridge’s lock address incorporating:
— **OP_RETURN Field**: Carries the Runes transfer information.
— **Spend-to-Self Output**: A transaction with a value of `0.00[TICKETNUMBER] BTC`, using this output to link the bridging data with the lock transfer. Up to six decimals can be used in the ticketing system.
— **Lock Address Output**: Covers transaction fees.
**Current Status**: No significant issues have been identified with this method. Modifications are needed to support two-chain scanning for monitors, but the overall structure is robust.
## Method 2: Dual Bitcoin Transactions
**Process Description:**
- User executes two separate Bitcoin transactions.
- The first transaction utilizes the OP_RETURN field for the Runes transfer.
- The second transaction’s OP_RETURN field signals the bridging data (such as the destination chain, destination address, etc).
**Analysis:**
- **Drawbacks**: Requires two Bitcoin transaction fees and the user’s experiment could be slow.
- **Advantages**: Eliminates the necessity for an Erg wallet and simplifies the design by not requiring a two-chain extractor for monitoring. This method is naive, however in some cases could be more robust than Method 3 to changes in Bitcoin nodes and Runes protocol in the near future.
## Method 3: Single Bitcoin Transaction
**Research Focus:**
- Utilize embeding bridging data in the `Taproot’s witness component` and use the `OP_RETURN` for Runes transfer.
- Enables signaling the bridging data and the Runes transfer in a single Bitcoin transaction.
- It is possible to embed arbitrary data in the witness component of Taproot transactions. The Taproot upgrade, implemented in 2021, allows for more relaxed rules regarding the amount of arbitrary data that can be placed inside a Bitcoin transaction, including within the witness component. To embed arbitrary data using Taproot transactions, one would utilize the witness data section of a transaction. The process involves creating a Taproot-compatible transaction and including the arbitrary data within the witness part of this transaction. This data can be anything from text to images or even scripts, as long as it complies with the transaction and block size limits specified by the Bitcoin protocol.
This method seems to be technically feasible, however, needs in depth investigation to ensure it suits bridging requirements and doesn’t introduce attack vectors to the bridge. Also, we need to make sure that using this method is consistent with our requirements, including but not limited to:
- censorship-resistance
- robust against possible changes in Bitcoin nodes and Runes protocol
- infrastructure requirement of this method for watchers and guards and how useful public or light-weight infrastructure are.
- possibility of using browser-based Bitcoin’s wallet to create required bitcoin transaction
- possibility of using external bitcoin wallets to create required bitcoin transacion
- overall user experience
- security and robusness of this method
- bitcoin’s transaction fee due to embeded data
**Analysis:**
- **Advantages**: Only one transaction on Bitcoin is needed and potentially added fee is not very high and still practical.
- **Current Status**:
Still determining feasibility. Initial research shows this is technically feasible but needs more in-depth investigation.
