Skip to content

Latest commit

 

History

History
171 lines (98 loc) · 8.17 KB

cip-0013.md

File metadata and controls

171 lines (98 loc) · 8.17 KB
Raw
CIP: 13-tentative
Title: Multiparty Counterparty Aggregate Transaction (MCAT)
Authors: Devon Weller
Status: Draft
Type: Standards Track
Created: 2017-06-08
Discussions-To: https://counterpartytalk.org/t/cip-propsal-13-mcat-multiparty-counterparty-aggregate-transaction/3151

Abstract

Allow multiple transactions from multiple addresses to be grouped together in one transaction.

  • Groups multiple counterparty transactions into a single Bitcoin transaction
  • Supports multiple sources, multiple destinations, multiple assets and multiple recipients in one transaction
  • Uses lookup tables to save space
  • Public MCAT servers can group 3rd party transactions together into a single transaction

Motivation

As bitcoin fees rise, it is increasingly more important to lower the size used when sending Counterparty assets. In order to save space and lower fee costs, multiple parties can group multiple Counterparty transactions into a single Bitcoin transaction.

Consider this simple example:

Alice wants to send Bob 5 XCP and Charlie wants to send Bob 20 XCP. To save on transaction fees, Alice sends a signed message to the MCAT server. Charlie also sends a signed message to the MCAT server. The MCAT server is able to make a more space-efficient transaction by including Bob's address only once in the MCAT. The MCAT server publishes the transaction to the blockchain and both transactions are executed.

Rationale

Public MCAT Servers

Third party MCAT servers can provide a service to users wanting to send assets at a discounted rate.

A server can gain a significant space savings by combining several transactions with the same asset name or the same recipient address. Because of this, a server can send a group of transactions at a lower fee than an individual can send by themselves. The MCAT server is paying the bitcoin fee. In return for this service, the sender of each asset pays a fee in any Counterparty asset to the MCAT server's address.

MCAT servers may choose to include multiple sends in a single large transaction based on the fee offered by the sender. Because the MCAT server can save space by combining multiple transactions, it can potentially spend less bitcoin in transaction fees than it receives in asset fees and operate at a profit.

Expiration Rules

Each signed MCAT message has expiration block associated with it.

Specification

MCAT Overview

The Overall MCAT structure looks like this

destinationAddressLookupTable + assetNameLookupTable 
+ transactionSequence [+ transactionSequence [+ transactionSequence]]...

The destination address lookup table looks like this

numberOfEntries 
+ 21 byte public key [[+ 21 byte public key] + 21 byte public key]...

The asset name lookup table looks like this

numberOfEntries 
+ 8 byte asset ID [[+ 8 byte asset ID] + 8 byte asset ID]...

Note that XCP is assumed to be index 0 and does not need to be defined to the asset name lookup table. The first asset in the lookup table will be referred to as asset index number 1.

The transactionSequence looks like this

numberOfTransactionsInSequence 
[destinationAddressIndex + assetIndex + quantity] * numberOfTransactionsInSequence 
feeAssetIndex 
feeQuantity 
expiryBlock 
ECDSASignature

Definitions

  • numberOfTransactionsInSequence is the number of transactions sent in this sequence. All of these transactions are sent from a single source address.

  • destinationAddressIndex is the index of the destination address in the destinationAddressLookupTable.

  • assetIndex is the index of the asset from the assetNameLookupTable.

  • quantity is the quantity of the asset to be sent.

  • feeAssetIndex is the index of the asset from the assetNameLookupTable that defines what asset the fee is paid in.

  • feeQuantity is the fee that the sourceAddress will pay to the address that broadcasts the MCAT. If sourceAddress does hold sufficient quantity of feeAsset, then this this transaction sequence is ignored.

  • expiryBlock is a block height in which this transaction expires. If this transaction is included in a block greater than the expiryBlock, then this transactionSequence is ignored.

  • ECDSASignature is an ECDSA sep256k1 DER-encoded signature covering a sha256 hash of the entire transactionSequence. If the signature is empty, then the sender is assumed to be the publisher's address.

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. By using this property we can recover the public key and therefore reconstruct the sender's address.

The transaction sequence fee

The address broadcasting the transaction to the blockchain may be different than the sender of the asset. To pay for the fee, the sender includes a fee amount and fee asset to be paid to the broadcaster's address. If this amount is greater than 0, then this fee will be deducted from the sender's address and applied to the publisher's address. Note that the fee may be paid in any asset.

If the sender's addresss does not have sufficient quantity of the fee asset at the time that the transaction is published to the blockchain, then the transaction sequence is not processed.

Example

Alice wants to send 16 XCP to Bob and 20 PEPECASH to Charlie.

The transaction would look like this:

Transaction Segment Data
destinationAddressLookupTable 0 => addressOfBob, 1 => addressOfCharlie
assetNameLookupTable 1 => x0000001c61620c4b (PEPECASH)
transactionSequence [2 (count)] + [0 (destination) + 0 (asset) + 16 (quantity)] + [1 (destination) + 0 (asset) + 20 (quantity)] + [0 (feeAsset)] + [0.1 (fee)] + [500000 (expiry)]
signature signature from Alice covering transactionSequence

Here is a byte level example.

x marks a string of bytes. b marks a string of bits.

Bits/Bytes Explanation
x0002 Size of the destination address lookup table (2)
x00f3a6b6e4a093e5a5b9da76977a5270fd4d62553e 21 byte public key, LUT index 0 (Bob's address)
x009bde9d244e7abd061b0dcc1dfa8c0d880cd7da21 21 byte public key, LUT index 1 (Charlie's address)
x0001 Size of the asset name lookup table (1)
x0000001c61620c4b asset name, LUT index 1 (PEPECASH)
x02 Number of destinations in sequence (2)
b0 send 1: use destination 0 (Bob)
b0 send 1: use asset 0 (XCP is always asset 0)
x000000005f5e1000 send 1: quantity (16)
b1 send 2: use destination 1 (Charlie)
b1 send 2: use asset 1 (PEPECASH)
x0000000077359400 send 2: quantity (20)
b0 feeAssetIndex (XCP)
x0000000000989680 fee quantity (0.1)
x0000000000086470 expiryBlock (550000)
x30450220657912a7...578f28590d651c6e ECDSA signature (71 bytes from Alice's private key)

Limits

To prevent abuse of the message, the following limits are enforced:

  • A transactionSequence must not contain duplicates of the same asset/destination combination
  • A transactionSequence may contain no more than 255 sends

Credits

This is an extension of CIP10 by John Villar and Javier Varona. Much of the message packing ideas from that CIP are used here.

Backwards Compatibility

The MCAT type will be a consensus change that will activate at a specific block to be determined after implementation. All parsing servers will need to upgrade before this block to maintain consensus.

Implementation

Pending

Copyright

This document is placed in the public domain.