As part of the v11.0.0 protocol change, we switched to a new transaction data encoding method using the CBOR standard for Sweep, Enhanced Send, Fairminter, Fairmint, Issuance and Broadcast transaction types. (To be activated with block 902,000.) CBOR is a technically superior serialization scheme, very standard, and widely adopted. It helped a lot with implementing Taproot Envelope support #3054 which will significantly decrease fees for larger transaction sizes (> 64 bytes).
This decision was not widely discussed—it was considered to be a relatively small, technical change with clear advantages. However there are two consequences that weren't considered:
-
It does necessitate updating libraries / tools that construct Counterparty transactions client-side (rather than with the API), which is something to be encouraged (!). The change is super easy and quick, of course. (See above.)
-
In some cases, CBOR (because it's not custom) uses an additional two bytes of space for encoding the data. This means that if you're using a client-side library to manually construct OP_RETURN transactions, you can fit a tiny bit less data in the 80-byte space. In general this shouldn't be an issue, because above like 64 bytes, it's cheaper to use Taproot Envelope encoding anyway (which the API will do automatically).
This change was already released as of v11.0.0, but it hasn't been activated yet. If it is indeed controversial, then it can be undone.
As part of the v11.0.0 protocol change, we switched to a new transaction data encoding method using the CBOR standard for Sweep, Enhanced Send, Fairminter, Fairmint, Issuance and Broadcast transaction types. (To be activated with block 902,000.) CBOR is a technically superior serialization scheme, very standard, and widely adopted. It helped a lot with implementing Taproot Envelope support #3054 which will significantly decrease fees for larger transaction sizes (> 64 bytes).
This decision was not widely discussed—it was considered to be a relatively small, technical change with clear advantages. However there are two consequences that weren't considered:
It does necessitate updating libraries / tools that construct Counterparty transactions client-side (rather than with the API), which is something to be encouraged (!). The change is super easy and quick, of course. (See above.)
In some cases, CBOR (because it's not custom) uses an additional two bytes of space for encoding the data. This means that if you're using a client-side library to manually construct
OP_RETURNtransactions, you can fit a tiny bit less data in the 80-byte space. In general this shouldn't be an issue, because above like 64 bytes, it's cheaper to use Taproot Envelope encoding anyway (which the API will do automatically).This change was already released as of v11.0.0, but it hasn't been activated yet. If it is indeed controversial, then it can be undone.