CIP: 4
Title: Multi-Out Transactions
Author: PoCC/rico666 <[email protected]>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/PoC-Consortium/CIPs/wiki/Comments:CIP-0004
Status: Active
Type: Hard Fork
Created: 2018-04-26
Implemented-Since: 2.2.0
There is a scalability issue with blockchains in general and it becomes increasingly more difficult to have efficient faucets or efficient way to issue a transaction and serve several people at once. Multi-Out transactions in Burst take advantage of an attachment data field which they use for specifying a list of recipients and amounts (Multi-Out) or just recipients (Multi-Out Same) keeping overhead to a minimum.
A regular Burst transaction (Ordinary Payment) takes at least 176 bytes of space in the block chain. This header contains various necessary information like timestamp, signature, recipient, amount etc.
This ordinary transaction can have an attachment - often used for messages - for arbitrary additional data. Multi-Out transactions use this attachment to define a very compacted list of recipients requiring only 16 byte per recipient (Multi-Out) or even 8 byte (Multi-Out Same)
Effectively the space requirements per effective transaction (sending some amount from A to B) is up to 11 times smaller (multi-out) or 22 times smaller (multi-out same) than a ordinary transaction.
With combination of dynamic transaction fees and multi-out + multi-out same transactions, the maximum transaction per second (a.k.a "tps") Burst will able to achieve has jumped from 1 tps to 80 tps.
A Multi-Out transaction can define up to 64 recipients and the individual amounts they shall receive in 64 pairs of 8-byte data, where
<Id1><amountFor-Id1><Id2><amountFor-Id2>....
A Multi-Out Same transaction can define up to 128 recipients who will receive all the same amount (defined in the transaction header - same place as for an ordinary transaction) like this
<Id1><Id2><Id3>.....
The Ids are the regular numeric Ids of accounts. For both types the additional constraint applies that a minimum of 2 recipients is required and no recipient Ids can be duplicate.
This is a hard forking change, thus breaks compatibility with old fully-validating node. It should not be deployed without widespread consensus.
- maximum multi out recipients
- maximum multi same out recipients
This document is placed in the public domain.