New Transaction Format

[adamkrellenstein]

• Multi-Transaction Packing
• Pre-Signed Transactions (for TX Relay)
• Confirmation target (for TX Relay)
• Method to ensure tx expiration or sequencing (for TX Relay)
• TX Compression
• Update the detach function to be able to detach the assets in the previous output on the same tx
• Remove ARC4 encoding #1814
• Native Address Indexes (?) #2196 (?)
• This obviates the need for MPMA.

---

• Support attach + Counterparty TX in a single Bitcoin TX

• Proposed Specification

[DerpHerpenstein]

on the same note as #2196, it may also be useful to assign a LEB128 id to issued assets. i think there are ~240k issued cpids, and this would allow for the reference in 4 bytes for the first ~260 million issued cpid's.

[DerpHerpenstein]

Bundled Transaction Standard

An Counterparty encoding format designed to minimize the amount of space used by Counterparty transactions while maximizing the number of transactions that can be packed into a single Bitcoin transaction. Currently a reasonable upper limit for for counterparty transactions in a single Bitcoin block is ~4-5k. This encoding will extend that upper limit to 30k+ transactions in a single block when using relayers

Protocol Header

The purpose of the Protocol Transaction Header is to allow for an extendable data structure to contain the Counterparty data.

Structure

["CP" 0x4350(2B)] [Flags 0b00000000 (1B)] [ [Transaction Bundle] ]
Note: total overhead = 3B
Note: may need to add a LEB128 after flags for Bundle count to make it easy to parse the tx

---

Field - CP

The first two bytes identify the protocol to distinguish it from other embedded data. are the lettersCP in ASCII. This corresponds to the hex 0x4350

---

Field - Flags

The next byte identifies the package wide configuration information Version and Data Encoding. The remaining bits are reserved in the event that more package level information is needed

Flag bits	Name	Values
b7-b6	Version	0b00 - Version 0
		0b01 - Reserved
		0b10 - Reserved
		0b11 - Reserved
b5-b4	Data Encoding	0b00 - Clear Text
		0b01 - GZIP
		0b10 - Reserved
		0b11 - Reserved
b3-b0	Reserved	Reserved

---

Note: If the Data encoding is GZIP, then everything after the flag needs to be read into a byte array and inflated before it can be used

Transaction Bundle

Transactions consist of the encoded transaction information byte packed sequentially after the Protocol Header. The goal of the Transaction Bundle is to allow for a single source to perform many transactions with as little on chain information as possible.

Structure

[ [Bundle Size xB] [ [Bundle Flags 0b00000000 (1B)] [Expiration 3b] [XCP Fee 1b] [Source (xB)] [Signature 65B] [[Transaction]] ] ]
Note: All transactions in a bundle come from a single source (multiple sources require separate bundles)

---

Field - Bundle Size

Bundle Size is a LEB128 integer that specifies the total size of all the information contained in this bundle. This makes decoding this batch of transaction simple, as the byte array can be sliced and each bundle can be passed to a decode function.

Field - Bundle Flags

The Bundle Flags are used to specify how the data in this bundle of transactions will be encoded

Flag bits	Name	Values
b7-b6	Version	0b00 - Version 0
		0b01 - Reserved
		0b10 - Reserved
		0b11 - Reserved
b5	Source Address Encoding	0b0 - Clear Text
		0b1 - Indexed Id
b4	Destination Address Encoding	0b0 - Clear Text
		0b1 - Indexed Id
b3	CPID Encoding	0b0 - Id
		0b1 - Indexed Id
b2	All Txs must be succeed	0b0 - false
		0b1 - true
b1	Embedded Signature	0b0 - false
		0b1 - true
b0	Reserved	Reserved

Note: Indexed IDs is an index in the CP database for addresses and CPID's. Using this ID with LEB128 encoding allows for addressing assets and addresses with only 3B of on chain data for each index for the foreseeable future.
Note: b2 set to false would allow the txs to be processed individually, b2 set to true would only process this bundle if all of the txs are valid, otherwise this bundle fails.
Note: b1 specifies if this bundle has an embedded signature. If false, the signature comes from the tx and the signature and source fields are not used, if true there will be a source in the source field and a signature after the transaction bundle

---

Field - Expiration

The block that this transaction bundle is valid until. This allows for the bundle to automatically expire if it isn't processed in a certain amount of time.
*note: should explore the possibility of using a multiplier and doing this with 2B, *

---

Field - XCP Fee

This the fee that the user is willing to pay to have this bundle added. To ensure a wide range of fees with a minimal on chain footprint b7-b3 would be the mantissa and b2-b0 would be the exponent. This allows for a fee range of [0-32]*[10^0-10^7]
Note: this could also easily be done with 2 bytes to ensure significantly more granularity.

---

Field - Source

This is the source of this bundle. It does not exist if embedded signature is false. If embedded signature is true and Source Address Encoding is Clear Text, this is the entire Bitcoin address. If Source Address Encoding is Indexed Id, then this field is a LEB128 integer representing the Indexed ID of the source.

---

Field - Signature

The signature of this entire bundle (if Embedded Signature is true)

Transaction

The end of the Transaction Bundle contains an array of byte packed transaction information. Each transaction contains the necessary information for its specific transaction type.

TODO: go over every compose and optimize byte level encoding of the parameters

TODO: Explore LEB128 vs fixed width ints that are adjustable by a flag. LEB128 decoding adds complexity by allowing for variable sized txs and the majority of the benefit can be achieved by just using 4B ints

[ouziel-slama]

Thanks @DerpHerpenstein.