Runes on Rosen: Serialized Bridging Data Across Multiple UTxOs

The team at Rosen Bridge has been exploring different design patterns for Bridging Runes. We developed three potential design patterns for bridging data upon the first pass.

The first pass options can be found here.

https://curiaregiscrypto.medium.com/exploring-bitcoin-runes-to-rosen-bridge-92af06176e8c

Rosen was awarded a catalyst grant from the Cardano blockchain to explore and integrate a solution that would make Runes available for bridging.

Each method had its potential benefits and tradeoffs, which, upon further discussion, led us to option 4.

Option 4 is built around simplicity, as it requires a single transaction and encodes data within Bitcoin itself across multiple UTxOS.

This probably will offend Bitcoin purists, but we decided to take the path of the Wizard and hack around on Bitcoin.

So what do you do when you run out of space… You use another UTxO. In theory, you can chunk data across as many UTxOs as you need, building something off-chain to scan for your design pattern and magic. The BTC blockchain can serialize our data.

BTC purists will see this as a spam machine. Which is funny.

Demmurage fixes those concerns, and we have that in Ergo.
https://docs.ergoplatform.com/mining/rent/

Option 4 Serialized Bridging Data Across Multiple UTxOs

Key Details: Efficient Use of Bitcoin Transactions for Bridging Runes

1. Embedding Bridging Data and Using OP_RETURN

Utilize address script bytes to embed bridging data directly into the UTxO address. This technique leverages the Bitcoin scripting language to include essential bridging data in the address script bytes of a UTxO. Additionally:

• OP_RETURN for Runes Transfer: Use the OP_RETURN field to handle the Runes transfer. The OP_RETURN is a special Bitcoin script opcode that allows for embedding up to 80 bytes of data in a transaction without affecting its spendability. This ensures that the Runes transfer and associated data are efficiently included in the transaction.

2. Streamlined Transaction Process

This method enables the bridging data and Runes transfer to be signaled in a single Bitcoin transaction, eliminating the need for multiple transactions. This is a significant improvement compared to other methods, such as Method 3, which requires a separate taproot commit transaction.

• Single Transaction Efficiency: By combining the bridging data and Runes transfer into one transaction, this approach reduces complexity and transaction costs. Unlike methods that require additional transactions for commitment or data handling, this streamlined approach consolidates everything into a single, efficient transaction.

Key Detail: Converting Bridging Data to Bitcoin Addresses

It is crucial to understand that bridging data can be converted into multiple Bitcoin addresses to handle and manage larger amounts of data efficiently. Here’s how this works:

Data Size Limitations:

• Bridging Data: The total data you need to bridge is at most 80 bytes. Since Bitcoin addresses (specifically native-segwit addresses) are limited in size, this data needs to be split up.
• Address Size: A standard Bitcoin native-segwit address can hold 80 bytes of data, 20 of which is derived from the hash of the owner’s public key. So we have a size limitation issue.

Chunking the Data:

• To accommodate the 80 bytes of bridging data, it is split into smaller chunks that fit within the limit of a native-segwit address.
• Address Generation: Each chunk is encoded into its own Bitcoin address. This means you’ll create multiple addresses, each containing a part of the bridging data.

UTxOs Creation:

• Additional Outputs: This process results in the generation of additional UTxOs (Unspent Transaction Outputs). Specifically, 4 more outputs are created, each associated with a chunk of the bridging data.
• Minimum Value: Each of these UTxOs needs to have a minimum value of 294 satoshis. This value is necessary to ensure that each output adheres to the Bitcoin protocol’s minimum UTxO value for native-segwit addresses.

In summary, converting bridging data into multiple Bitcoin addresses allows for the efficient management of larger datasets within the constraints of Bitcoin’s address and transaction size limits. This approach not only helps in managing the data effectively but also ensures compliance with Bitcoin’s minimum UTxO value requirements.

Important Consideration: Transaction Size and Efficiency

Although the transaction may appear large (comprising 7 UTxOs in total: 1 for bridged assets, 1 for OP_RETURN data, 4 for bridging data chunks, and 1 for change), it is still a more efficient solution compared to performing two separate Bitcoin transactions. Here’s why:

Consolidated Transaction:

• Single Transaction Advantage: Despite involving multiple UTxOs, this approach consolidates all necessary elements into one transaction. This is more efficient than executing two transactions, which would incur additional fees and complexity.

Chunked Bridging Data:

• Data Splitting: The bridging data is divided into 4 chunks of 20 bytes each to fit within Bitcoin’s address constraints. Each chunk is encoded into a separate Bitcoin address by prepending ‘0014’ to the chunk data.
• Incremental Satoshi Values: To handle the data splitting and ensure all UTxOs are valid, the amount of satoshi allocated to each address is increased sequentially based on the chunk index. This ensures compliance with Bitcoin’s minimum UTxO value requirements.

In summary, while the transaction involves multiple UTxOs and may seem large, it effectively streamlines the bridging process by embedding everything into one transaction. This method reduces overall transaction complexity and costs, making it a practical choice compared to executing multiple transactions.

Detailed Example of Data Chunking and UTxO Creation

Here’s a step-by-step breakdown of how serialized bridging data is processed and converted into Bitcoin addresses, resulting in multiple UTxOs:

Step-by-Step Process

1. Serialized Bridging Data

• Example Data: 00000000007554fc820000000000962f582103f999da8e6e42660e4464d17d29e63bc006734a6710a24eb489b466323d3a9339
• This is the complete bridging data that needs to be transferred.

2. Splitting the Data

• The serialized bridging data is too large to fit into a single Bitcoin address. Therefore, it is split into smaller chunks that can be managed within Bitcoin’s constraints. For this example, we split the data into 3 chunks:
  Chunk 1:
• Script: 001400000000007554fc820000000000962f582103f9
• Bitcoin Address: bc1qqqqqqqqqw420eqsqqqqqqqyk9avzzqlewpctgk
• Chunk 2:
• Script: 001499da8e6e42660e4464d17d29e63bc006734a6710
• Bitcoin Address: bc1qn8dgumjzvc8ygex30557vw7qqee55ecsvavkfg
• Chunk 3:
• Script: 0014a24eb489b466323d3a9339000000000000000000
• Bitcoin Address: bc1q5f8tfzd5vcer6w5n8yqqqqqqqqqqqqqqmcs2uu

3. Generating UTxOs

• Each chunk of the bridging data is encoded into a Bitcoin address, and each address becomes a separate UTxO with a specific amount of satoshis. Here’s how the UTxOs are created:
  UTxO 1:
• Address: bc1qqqqqqqqqw420eqsqqqqqqqyk9avzzqlewpctgk
• Value: 294 satoshis
• UTxO 2:
• Address: bc1qn8dgumjzvc8ygex30557vw7qqee55ecsvavkfg
• Value: 295 satoshis
• UTxO 3:
• Address: bc1q5f8tfzd5vcer6w5n8yqqqqqqqqqqqqqqmcs2uu
• Value: 296 satoshis

4. Transaction Summary

• Total UTxOs Generated: 3
• 1 UTxO for the OP_RETURN data, which stores part of the bridging information.
• 1 UTxO for the bridged assets (Runes).
• 3 UTxOs for the chunked bridging data.
• 1 UTxO for any change (leftover Bitcoin).

Emphasized Points:

• Efficient Data Management: The process of splitting bridging data into smaller chunks and encoding them into separate Bitcoin addresses ensures that the data fits within Bitcoin’s address constraints and maintains manageability.
• Single Transaction Efficiency: Despite the appearance of complexity due to multiple UTxOs, this method is more efficient than handling multiple transactions. It consolidates the entire bridging process into one transaction, simplifying the transfer of assets and associated data.

This detailed example illustrates how serialized bridging data is systematically split and managed within Bitcoin transactions, providing clarity on the process and its efficiency.