I am proud to announce my new website – counterparty.com. It is still under construction but I aim to have an explorer, useful tools and resources up shortly. An important goal of the website is to provide feedback on new developments.
As you might know, a new version of Counterparty is around the corner. It will activate on block 902,000 (around 20 June).
What’s New in v11
❤️ Bech32 (P2WSH and P2TR) address formats
❤️ Taproot data encoding (much cheaper for large messages)
😕 Ordinal inscriptions, aka Counterscriptions
❤️ CIP reactivated
❤️ Lots of bug fixes, minor changes to Fairminter, etc
P2WSH and P2TR addresses
These are the most up-to-date Bitcoin multisig address formats. Counterparty support is a very welcome improvement!
The actual implementation stirred up some drama though. Read the full story below.
Taproot Encoding
Putting more than 80 bytes of Counterparty data has always been very expensive. This was due to inefficient encoding schemes. Taproot is a gamechanger, especially for very large messages above a kilobyte. This opens up for a ton of creativity!
A cost comparison indicates that taproot is cheaper than op_return even for short 80 byte messages. Although this is true for legacy addresses, the table fails to mention that for a bech32 address, a transaction with an 80 byte op_return message is 200 vBytes. This is way cheaper than taproot at 256 vBytes. But this is a minor detail. Taproot encoding is for larger messages.
Counterscriptions
With v11 you can mint Ordinals and Counterparty tokens at once! One Bitcoin transaction, two mints! This is very creative, extremely Counterparty’ish!
In a way it is not too different from CIP33, adopted by STAMPs and branded OLGA. While OLGA stores the image in Bitcoin outputs, Counterscriptions are encoded in a taproot envelope.
Conceptually, of course, there are major differences. OLGA STAMPs are encoded in unspendable UTXOs. Bitcoins are crafted into the most permanent art possible. Counterscriptions are geared toward cost efficiency, at the expense of being easy for Bitcoin nodes to prune.
Unfortunately, there is one thing I don’t like about Counterscriptions. Counterparty consensus code had to change. I believe this could have been implemented in a more elegant way outside of the core code, just like CIP33/OLGA was. Since the CIP process had been abolished and this all was brought to the community’s attention very late, I feel it would be too disruptive to argue about this now – especially since it’s an optional feature.
CIPs Reactivated
The Counterparty Improvement Process is back! This should improve transparency and make it easier to discuss changes ahead of time! Had this been the case for v11, I would have commented on Counterperscriptions at a much earlier stage.
v11 Hash Drama
When bech32 (bc1q addresses) was introduced to Bitcoin in 2017, Counterparty only followed halfway. The most common short address format was supported. The longer multisig variety was not. As a consequence, a horrible bug appeared whenever the long format interacted with Counterparty – these addresses were truncated. In other words, Counterparty interpreted blockchain data in an illogical way.
The proposed solution for v11 was to to interpret these past transactions correctly – and retroactively! The key assumption was that only frozen balances were affected. No one would lose by retrieving these balances. A side effect was that Counterparty’s block hashes would not match back to 2017 (they started diverging already in December 2014 though).
Another side effect was that PEPOLGA would magically get a new issuance address from v10 to v11 . A property set in stone … or not?
This is actually the first token with the encoding later endorsed by Stamps and labeled “OLGA STAMPs”. All stamps minted from my service would similarly see their issuer address changed on v11. To me this little quirk was a fun feature, yet I’d hate to see it changed. That said, practically speaking the change would only be cosmetic. The issuer would be one burn address replaced with another.
However, I warned that there might have been cases where people actually used this trick to send to a fake address that Counterparty would interpret as a real address. A weird thing to do, sure, but this is the essence of Counterparty! We love playing around with such things. (Don’t tell me Counterscriptions are less weird than this LOL)
If someone has ever done this, then fixing this “bug” could cause divergences. Like if someone in 2018 transferred 0.5 XCP, then issued some tokens, then sold these, then these were traded again for other tokens, etc, etc. All of these valid v10 transactions would not be valid in v11. A potential disaster!
When they later tested balances on v11 against v10, they concluded that no disparities existed. The test failed to discover transactions I made to show exactly what I warned about. This proves how dangerous it is to re-interpret old transactions.
I believe they failed to spot it because they assumed this was a dispenser issue. I had issuance and classic send in mind. Classic send is the original way of sending a token and is rarely used anymore. It looks at a Bitcoin dust output to determine the recipient. I drafted a transaction such that Bitcoin was sent to bc1qcpnews0493hkswn4vw8d5vaq6e6g59n5tanx7untv4e8qctjw3usdlw5kh. Because of the bug Counterparty v10 would credit the truncated bc1qcpnews0493hkswn4vw8d5vaq6e6g59n5qyvjpq instead. I then distributed XCP to several active addresses. I then noticed how balance imbalances propagated. As a result it became impossible to launch v11 with the retroactive fix. The updates v11 matches v10 all the way up to the activation block of 902,000. YAY!
Another essential reason why old balances should never be touched, even if assumed burned, is that you never know – maybe people burned supply this way? A trading card supply might have gone from 1000 to 10 through this bug (feature) – who knows? The simple solution is to think of block hashes as an untouchable property. Never change these in retrospect. Only allow a new version to diverge from a set future block!
CBOR Encoding
CBOR was introduced to make Counterparty compatible with Ordinals (or collide with Ordinals, however you see it). This was a major change that, on Github, I can only see briefly mentioned – until it triggered a bug:
The issuance of TOOFUNNYPEPE failed on v10 but not on v11. It turned out that artist LFGCRYPTOART used Horizon Wallet that already was on v11. I noticed that two bytes snuck in but I was unaware it was caused by CBOR. I knew this would cause some wallets to fail, but thankfully the community discussed the problem and Adam released a fix. From the activation block 902,000, CBOR will be optional and all wallets will continue working as before.
Categories: Uncategorized