Ordinals use taprott to store large amounts of data very efficiently. This is something Counterparty should use? I.e. is it better than XCP’s current encoding schemes?
This would be such a fundamental change of the protocol that I would only consider it as a full reboot of the project (take the opportunity to fix/improve other aspects).
But what I believe is more relevant, is why jump into an unproven technology so soon? Who knows what can happen in future Bitcoin Core releases which could limit the data inscription capability, or change / remove Taproot for no-yet-discovered vulnerabilities.
Using Taproot means that Counterparty nodes will require newer versions of Bitcoin Core. And I believe one of the biggest values of Counterparty is its history. Being able to run it in old nodes is part of it, and honoring this could be what continues to make this platform unique.
My 2 sats.
A fundamental purpose of Counterparty is to encode data inside Bitcoin transactions. When a more efficient encoding standard is made possible, the protocol should be upgraded.
For instance, op_return encoding was added after the bitcoin’s limit was raised from 40 to 80 bytes. In the beginning some other methods were used. I think these were called pay-to-pubkey-hash and pay-to-multi-pubkey-hash.
Btw, op_return is ideal for data up to 80 bytes. For longer messages either mutlisig og segwit is used.
Multisig is a hack, inefficient and expensive. The data is encoded inside two of three addresses. The third can be used to redeem the dust but there is currently no working script to do so.
Segwit was added a few years ago. It is very efficient at the margin. Near 100% and can even get a fee discount, if I’m not mistaken. The downside with segwit encoding is that it requires a chain of two transactions. This leads to a big overhead so it’s not very suitable for messages slightly >80 bytes.
If taproot encoding works better, I think adding it is a natural upgrade to Counterparty.
2 Likes