On (in)ability to embed data into Schnorr

In a detailed exploration of the intricacies involved in publishing data on the Bitcoin blockchain, particularly through the use of taproot transactions, several key points emerge. The analysis begins by considering the efficiency and cost implications of embedding data in UTXOs (Unspent Transaction Outputs), with a specific focus on taproot-to-taproot transactions. It is noted that the most economical approach for such transactions involves around 192 bytes for the script path plus an additional 64 bytes for the (R,s) in the output, totaling a data embedding rate of approximately 12.5%. This figure slightly varies when considering key path spending due to the absence of a control block, though the difference is deemed minimal.

The conversation further delves into the potential strategies for repeatedly publishing data while minimizing costs and the associated technical challenges. One significant constraint highlighted is the inability to re-spend from the same output if one were to follow a methodology that involves leaking a single key, as this would result in losing control over the output. This segues into the discussion of an "explicit multisig" scenario, which, while theoretically possible, is characterized as impractical, especially if it were to involve updating legacy scripts to accommodate new rules requiring the signing of public keys.

Moreover, the dialogue touches upon the theoretical considerations of using legacy scripts for publishing data versus taproot scripts, noting that taproot's design—which conceals the script until the output is spent—offers a different paradigm for data embedding that wasn't initially considered in the assessment ("data in UTXO set"). Alternatives like hash locks are mentioned as potentially more efficient mechanisms under certain conditions.

Ultimately, the exchange underscores a critical conclusion: while attaching signatures to transactions (a sig-attaching system) was not advocated, it's imperative to acknowledge that embedding data in the witness part of a transaction remains a more space-efficient and economical method. This technique significantly surpasses the potential embedding rates in outputs, which could range between 8% to 15%, depending on various hypothetical scenarios. Additionally, attempting to increase the amount of data embedded in outputs could severely compromise Bitcoin’s functionality, highlighting a trade-off between embedding efficiency and maintaining the network's operational integrity.