March 18, 2014

Counterparty is a ‘metacoin‘ protocol and currency built on top of Bitcoin by hiding message data in Bitcoin transactions. Counterparty provides functionality for a distributed exchange, user-created assets, contracts for difference, betting, and other powerful financial tools.

Counterparty’s goal is to add functionality to Bitcoin while having as little impact as possible on the Bitcoin network itself. Consequently, we are eager to use `OP_RETURN` to embed our message data in Bitcoin, as that is by far the cleanest and most elegant way to accomplish our goals. Indeed, we already have full support for this feature, which we have used extensively on testnet. Unfortunately, a 40 byte limit (in place of the 80 bytes originally planned) makes OP_RETURN unusable for Counterparty’s purposes.

Counterparty currently supports two methods for encoding data in Bitcoin transactions. The first method puts the data in `OP_RETURN` outputs directly. The second method puts the data in the second public key in multiple one-of-two multisig outputs, where the first public key corresponds to the address of the sender, so that these outputs are all redeemable and, eventually, prunable. This latter method, while perfectly workable, is ugly and hackish, and somewhat worse for the Bitcoin blockchain than the `OP_RETURN` method, at least in the short term. If the data cap is left at 40 bytes, we will be forced to use such awkward constructions to accomplish our goals. Moreover, keeping the limit at 40 bytes will not prevent other projects from using that space for broadcasting ‘graffiti’ and other undesirable information, or from having any other negative effects on Bitcoin.

Counterparty, and similar projects, with their sizable feature-sets, have the potential to be useful to users of Bitcoin and to add great value to Bitcoin itself. This should be taken into account when determining the maximum amount of miscellaneous data that should be able to be stored in a Bitcoin transaction. In our opinion, more is better, for as long as Bitcoin transaction fees are being paid, then the network is being adequately compensated for whatever load it bears. If this is not the case, then the incentive mechanisms must be changed, in accordance with the important principle of Bitcoin that good behavior should come with financial incentives.

Of course, Counterparty depends on Bitcoin entirely, and we want to work with the Bitcoin developers to further our shared goals wherever possible. Let us know how best we may do so.