    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

Abstract

Establishes a new send message type geared towards batch processing to send multiple assets to multiple addresses.

Motivation

Simplify batch transactions
Reduce transaction fees

Rationale

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).

Definitions

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.

Overview

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.

Specification

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

Example

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):

0200F3A6B6E4A093E5A5B9DA76977A5270FD4D62553E3E01C530009BDE9D244E7ABD061B0DCC1DFA8C0D880CD7DA21D3737E11C0300805A0100801E0102018

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.

Implementation

def compress(number):
    # TBD
    return
    
def decompress():
    # TBD
    return

Copyright

This document is placed in the public domain.

chiguireitor/cips forked from CounterpartyXCP/cips

Join GitHub today