CIP: 10 Title: Multi-Peer Multi-Asset sends "MPMA Sends" Authors: John Villar (chiguireitor) & Javier Varona (pataegrillo) Status: Pre-Draft Type: Standards Track Created: 2017-03-28 Discussions-To: https://counterpartytalk.org/t/cip0010-multi-peer-multi-asset-sends/2799
Establishes a new send message type geared towards batch processing to send multiple assets to multiple addresses.
- Simplify batch transactions
- Reduce transaction fees
Multiple transactions are wasteful when the sender already knows who are the recipients and how much of each asset each one needs to receive. This functionality is especially useful for sites dealing with a group of asset to asset exchanges. MPMA addresses this issue by creating a lookup table for addresses and grouping sends by type of asset sent. Amounts are compressed with a simple RLE scheme which reduces the amount of information needed to express simple amounts by a compression ratio of up to 22:1 (with a worst case scenario of 100:101 inflation for truly random sent amounts).
LUT A lookup table for addresses, used as a mean to compress information RLE Run-length Encoding, a compression technique used express multiple values grouped on a master-slave disposition. CoInt 8 byte RLE integer encoded the following way: 1 bit marker for compressed or not compressed (0 means raw 8 byte integer, 1 means RLE encoded integer). 1 byte data, 2 bits number of times data is repeated. A sample pseudocode to compress/decompresses a CoInt out of/into a full 8 byte integer can be seen on the implementation section.
The main idea is to create a lookup table for addreses so they can be expressed by simple indexes, and then compress each amount sent with simple RLE.
The message format is constructed in the following way (Where N is the number of recipients, M the number of assets, X the Log base 2 of N rounded up to the nearest integer):
|LUT size||LUT address 0||...||LUT address N||Asset Signaling bit 1||Asset SubList 0||...||Asset Signaling Bit 1||Asset Sublist M||Asset Signaling Bit 0|
|16 Bits||25 bytes||...||25 bytes||1-bit||AssetList||...||1-bit||AssetList||1-bit|
AssetList is built in the following way:
|Asset Name||# Z of recipients||LUT Idx 0||Amount Idx 0||...||LUT Idx Z||Amount Idx Z|
|CoInt||X bits||X bits||CoInt||...||X bits||CoInt|
The following example is broken into several newlines, but the data stream is continuous on the encoded TX data. Numbers are preceded by a marker, 'x' for hexadecimal numbers, 'b' for bits.
x02 LUT Size: 2 addresses, 1 bit to represent each one
x00F3A6B6E4A093E5A5B9DA76977A5270FD4D62553E3E01C530 Base58 decoded address (into hex, 25 bytes), LUT index 0
x009BDE9D244E7ABD061B0DCC1DFA8C0D880CD7DA21D3737E11 Base58 decoded address (into hex, 25 bytes), LUT index 1
b1 Bit, Valid asset after this
b1 x00 b11 x00 b10 x01 b01 23 bits XCP asset ID
b1 2 recipients
b0 Address 0 into the lookup table
b1 x00 b10 x01 b00 x00 b11 Send 1 of the current Asset (XCP)
b1 Address 1 into the lookup table
b1 x00 b10 x04 b00 x00 b11 Send 4 of the current Asset (XCP)
b0 End sending data
The whole transaction would then be encoded as (padded with 0s on the last byte):
For a total of 63 bytes to send XCP to two addresses. This is a "bad" use case for MPMA because the byte-length gains compared to standard transactions are bad, however, sending more assets to more addresses would make gains a lot more evident.
def compress(number): # TBD return def decompress(): # TBD return
This document is placed in the public domain.