On (in)ability to embed data into Schnorr

The discussion initiates with an exploration of a cryptographic system utilizing four 32-byte values: s, r, p, and m. It is highlighted that the verification equation inherently determines one of these values, effectively reducing the independent variables to three. Further constraints on the selection of m reduce this number to two, and the requirement for the receiver to be privy to one of the secrets for reverse calculation further reduces this to a single variable. However, it's mentioned that through a process known as grinding, this can marginally increase.

The conversation then transitions to the consequences of transmitting all but one of these values (m), which is predetermined by the setup, requiring the transmission of 96 bytes of data. The underlying concern expressed is the potential misuse of this system to bloat the Bitcoin Unspent Transaction Output (UTXO) set intentionally, which could be seen as an attack on Bitcoin’s efficiency and scalability. The author suggests that if avoiding such bloat was not a primary objective, alternative methods for data encoding would be preferable due to their lower cost and complexity.

Further elaboration is provided on the potential application of the (P,R,s) outputs within a non-programmable system designed solely for payment processing, akin to replacing traditional financial transaction systems like FEDwire or SWIFT, without the capabilities for creating vaults or using lightning networks. This system would be more compatible with privacy-focused protocols like Mimblewimble, and could incorporate elements of Know Your Customer (KYC) or Central Bank Digital Currency (CBDC) systems through the use of operator signatures.

The prospect of reintroducing programmability to such a system is discussed, suggesting the use of the graftroot approach, where P signs a script instead of a direct payment. This would allow for the embedding of data within transactions, presenting a trade-off between the rate of data encoding and the ease with which such transactions can be identified.

Lastly, the communication touches upon the concept of standardness constraints, noting that while they are not limitations today, they reflect the current form of transactions. By mimicking these forms, transactions embedded with data via the discussed scheme would be challenging to distinguish from standard transactions, thus circumventing potential censorship or filtering.

This dialogue underscores the technical and ethical considerations in designing blockchain systems, particularly concerning efficiency, privacy, and the potential for system abuse.