Consensus Cleanup BIP draft

In the discussion about concerns related to 64-byte transactions within Bitcoin bridges, a compelling argument is presented against the necessity of worrying about such transactions for most practical purposes. The argument hinges on the nature of transactions moving value either off of or back to Bitcoin. When value is transferred off Bitcoin, the bridge will invariably require that the funds be secured in an output, which necessitates more than the bare minimum of 4 bytes. Similarly, transactions moving value back to Bitcoin typically involve at least two outputs: one for the amount being transferred and another for change. This setup ensures that the transaction size exceeds 64 bytes since recipients of funds will want their assets to be securely held.

Furthermore, the only scenario where a 64-byte transaction might be relevant is if a bridge supports the burning of funds—either entirely or as network fees—without any change being given. In such cases, the requirement can be circumvented by mandating that the output utilizes an op_return operation, pushing three or more bytes of data, effectively increasing the transaction size beyond 64 bytes. Another aspect discussed is how bridges handle transaction fees. If the fees are managed out of band through a p2a output rather than with bridged funds directly, this approach also ensures that transactions do not fall into the 64-byte category.

The email also touches upon considerations relevant to Simplified Payment Verification (SPV) wallets, emphasizing the difficulty of deceiving someone into believing they have received funds with a 64-byte transaction. For a successful deception, a transaction needs to include an output matching the target wallet, which requires more than 4 bytes, thus surpassing the 64-byte threshold. Moreover, misleading someone into thinking they have burnt funds would necessitate a "64-bit transaction" that matches a txid/vout pair of one of their UTXOs—a feat that would be equivalent to achieving a 256-bit collision and thus cryptographically challenging to accomplish.