If I got it right, @loon3 explained in the chat that a send transaction can be fully encoded inside an op_return message.
Currently the Counterparty protocol requires a dust amount of BTC to be sent to the recipient. Encoded in the op_return are only which asset to send and the amount.
Looney’s insight is that there is sufficient free space in the op_return that also the recipient address can be included there. Thus no need to send the dust amount of BTC.
Enabling this will make it cheaper to send assets. The tx size should also be smaller. Maybe it’s also faster for a Counterparty server to process?
The only potential negative effect of this may be more spam??? If it’s cheaper to send an asset, some people will use tokens as coupons etc. However, it’s probably not an issue since the BTC tx fee will likely only go higher. Also on the wallet side, it is easy to add a spam filer, sort of like email inboxes have them. For Counterparty servers, I wonder, how many daily txs will it take to make spam a concern?
this is a good idea imo.
I don’t think there’s any reason why we’d want to artificially increase the TX size unnecessarily, bitcoin fees are high enough to prevent any spam.
codewise I’m not sure if it is a very easy to make the change though.
parsing transactions is a 2 stage process atm where;
it first determines the source, destination and data and stores that in transactions.
and then based on the first byte of the data determines which type of message it is (a send in this case) and lets the relevant parse function handle the rest (counterpartylib.lib.messages.versions.send1.parse)
which then executes all the “side effects” of the message (such as checking if there’s enough balance and then attributing a credit/debit to the source/destination) and if it’s invalid marks the TX as “invalid”.
I suppose the send.parse could modify the transactions entry after parsing the data and set the correct destination, however:
I don’t think we’ve done this before, modifying the transactions after the first step, we’d have to look carefully what possible side effects are in the codebase.
one side effect I spotted when quickly browsing through the code is that there’s a (small amount) of code handling destination being a bare multisig for example which sits between the first step of parsing and the 2nd step of parsing.
Tbh the parsing code could probably use a refactoring, it’s not very flexible to make changes to and I think a change we should eventually consider is adding “change” to transactions for the sake of at least achieving equal privacy levels as bitcoin (when combined with a HD wallet).
A transaction output is about 34 bytes. We can embed the destination bitcoin address (without the checksum) using 20 bytes. That saves 14 bytes in a typical send transaction.
I agree that a new transaction type makes sense. We definitely want to leave the legacy counterparty send format untouched as not to break current applications.
