On (in)ability to embed data into Schnorr

The discussion among the programmers revolves around innovative methods for leveraging Bitcoin's scriptPubKeys and utxo set for purposes beyond simple value transfers, specifically focusing on data embedding and the potential challenges and solutions associated with it. One proposed method involves using scriptPubKeys with conditions akin to HTLC/atomic swaps, allowing for conditional execution based on either the revelation of a private key or the passing of a specified block height. This approach, however, is critiqued for potentially encouraging undesirable practices like key reuse or complicating the process for certain transactions, such as requiring cold key signatures for fund requests.

A particular scheme is detailed for embedding data within the blockchain in a cryptographically secure manner that minimizes the risk of lost funds. The process entails splitting data into blocks, calculating a series of hashes and nonces from secret keys, and signing a chain of transactions that ultimately reveal the embedded data without compromising the security of the involved private keys. This method relies on the unique hashing of each nonce and the final revelation of a specific public nonce to recover the data. Moreover, this technique suggests modifications to avoid pubkey reuse and proposes utilizing multisig transactions for more efficient data embedding.

Additionally, the discourse touches on the detectability and efficiency of this data embedding approach compared to other methods, such as OP_RETURN outputs or inscriptions. The suggested scheme aims for lower detectability and relatively higher efficiency under certain constraints, offering a novel way to incorporate additional bytes of data per block at a cost that, while not as low as other methods, presents a viable alternative for specific applications. The conversation implies a broader exploration of blockchain capabilities, pushing the boundaries of what can be achieved within the existing framework and standardness constraints of Bitcoin transactions.