Enhanced Send CIP

proposal.md

    CIP: 9
    Title: Enhanced Send
    Authors: Joe Looney (loon3) & needmoney90
    Status: Draft
    Type: Standards Track
    Created: 2017-02-25

Abstract

Establishes a new send message type with two distinct features...

• Eliminate the receiving address dust output by encoding the receiving address in the Counterparty message data.
• User specified Payment ID (optional)

Motivation

Smaller transaction size (lower tx fees), eliminate dust outputs, payment ID enables greater efficiency and lower tx fees for exchange operators

Definitions

Payment ID

    A 30-byte sender specified identifier included as part of an asset send message

Overview

An Enhanced Asset Send adds the following two features to a traditional Asset Send...

Encoding Receiving Address in Message Data

An asset send transaction currently requires a P2PKH output to the receiver of an asset. This is in addition to the message data output (encoded in OP_RETURN). The additional output is an unnecessary burden that, on average, is five times more expensive to spend than it's worth (using an avg fee of 200 sat/byte and 148 bytes per tx input). At a bitcoin price of $1200, that's a cost of $0.37 (29600 sat) to spend a $0.07 (5430 sat) dust output!

Payment ID

The Payment ID is usually used to identify transactions to merchants and exchanges: when a single public address is used for incoming transactions, the Payment ID is especially useful to tie incoming payments with user accounts.

Specification

The message data output for an asset send transaction is 28 bytes. The enhanced send, detailed in this proposal, utilizes that same asset send message data but with an additional 51 bytes for the receiving address and payment ID. The total enhanced send message data size of 79 bytes can be safely stored within an OP_RETURN output.

• New Message Type (ID=2)
• Message Structure (CNTRPRTY + Message ID + Asset Name + Asset Qty + Receiving Address + Payment ID)
• Receiving Address, 21 bytes (Base58->Hex, no checksum). For converting address from Base58->Hex and vice versa, see http://lenschulwitz.com/base58
• Payment ID, 30 bytes (Hex). Payment ID to be stored as a hex string to allow versatility for end users.
• Total Message Data size, 79 bytes

Example:

434e545250525459|00000002|000000000004fadf|000000174876e800|
051a8b0026343166625c7475f01e48b5ede8c0252e|
ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff

Implementation

In development...

Copyright

This document is placed in the public domain.

Looks good.

Please add:

• Rationale Section "evidence of consensus within the community and discuss important objections or concerns raised"
• and (optionally) Discussions-To: https://counterpartytalk.org/t/send-payment-id-field-cip-discussion/2689/29 in the preamble

You may submit a pull request as CIP 9 - cip-0009.md

Oh - and please add a copyright section. Here's an example:

Copyright

This document is placed in the public domain.

Additionally, please change

An 30-byte sender specified identifier included as part of an asset send message

to

A 30-byte sender specified identifier included as part of an asset send message

for grammar