The MCAT message allow multiple transactions from multiple addresses to be grouped together in one transaction in order to save transaction space.
Please see the whole work-in-progress CIP at:
This CIP proposal builds on @chiguireitor’s work on MPMA sends. It extends the concept to public 3rd party aggregation servers.
jp:
wow! the marginal cost of adding a send can be ~16 bytes?
(destination id 4 bytes + asset id 4 bytes + quantity 8 bytes)
that’s 16 cents even at today’s fees 
(edited)
PLUS two added bonuses
This is very nice to see being thought about.
@chiguireitor suggested allowing the user to specify the asset in which MCAT servers can receive fees. So a server might opt to receive fees paid in, say, PEPECASH instead of XCP.
This would also allow a user to pay the TX fees by proxy in the asset they are using. An XCP MCAT server would allow anyone dealing with XCP use only XCP for they transactions, someone with PEPECASH only use PEPECASH on the corresponding MCAT server, etc.
EDIT: Later, a way to discover MCAT servers would be nice, so people use their more convenient approach for each transaction.
This is a good idea.
Wouldn’t it make sense for fees to be paid in BTC? This seems to be the simplest way to do it. It seems like BTC will ultimately be needed for fees by the aggregation server and it keeps things standardized.
If the reason for suggesting that fees be paid in XCP is to increase XCP demand there might be a better way to do it. Make a requirement that anyone who wants to run an MCAT server has to stake some amount of XCP for the right to do so. Transactions sent for aggregation could be allocated randomly to a server or senders could specify a server. Being able to specify a server would be attractive to active Counterparty users.
Demand for XCP could increase noticeably if the benefits of the system are effectively communicated. The rights to run a fixed number of MCAT servers could be auctioned off. Many would buy XCP to stake it in order to run an MCAT server. As Counterparty usage grows the aggregation fees would be expected to grow.
The protocol cannot escrow BTC. Therefore it’s technically impossible to use BTC for fees (beyond the miner fee). XCP exists for this very reason.
Would you need to escrow BTC to make this work though? BTC could be sent to an address associated with the MCAT directly by someone who wants to have their transaction aggregated with others for a lower fee. Their transaction gets aggregated after the BTC transaction is confirmed. So they may need to wait for the next block for their Counterparty transaction to be confirmed but they get the benefit of paying a lower fee.
I am still getting acquainted with some of the nuances of Counterparty so I apologize in advance if there is something else I am missing. Also I am assuming that it would be optional to have a transaction aggregated with others if this is implemented. If transactions are automatically aggregated I see how it would be logistically difficult to consider attempting to pay fees in BTC as it would require two transactions, one for the Counterparty transaction and one to send the BTC. For one off transactions or large transactions people might not mind the extra step.
What do you think about requiring XCP to be staked in order to run an MCAT server?
Doesn’t makes sense to have the fee paid on BTC: The very thing we’re trying to avoid is spend another TX fee, so why have BTC fees to transmit another asset?
The good thing about MCAT servers would be that the economy of an asset can be closed inside it, allowing people to use the same asset to pay TX fees and allowing MCAT servers to kinda “mine” the fee currency.
The XCP staking for MCAT servers sounds like a really good idea. Capacity of the MCAT could be determined by the amount of XCP staked, and the fees are the gains it gets.
Interesting
Makes sense, easier is better. To me the big benefit is lower fees but being able to pay fees in XCP would be valuable as well.
If this is implemented I do think that an option should still exist for users to send transactions directly, paying a higher fee in BTC to circumvent having their transactions aggregated. Some people might feel that running transactions through a server introduces counterparty risk, similar to masternodes for Dash. Sending transactions to be aggregated for a lower fee should be the default option though.
Also maybe this goes without saying but rights to run an MCAT could be a token or tokens with each server associated with a wallet address. In any case there should be some easy way to transfer rights after they are issued.
kickass!!! strong work John and Devon!
Reconstructing the sender’s bitcoin address
The sender’s address is not explicitly included in the transaction. ECDSA signatures have the property that allows recovery of the public key from the hash of the message and the signature. Using this property we can recover the public key and therefore reconstruct the sender’s address.
Not sure I get this right.
Links to literature about this?
Existing code libraries?
There will be multiple signatures. Each individual transaction will have it’s own signature.
The link to the proposal is at the top of this thread. There is no code yet.
I updated this proposal to include flexible fee assets. I also included more examples and definitions.