CIP: 9 Title: Enhanced Send Authors: Joe Looney (loon3) & needmoney90 Status: Active Type: Standards Track Created: 2017-02-25 Discussions-To: https://counterpartytalk.org/t/send-payment-id-field-cip-discussion/2689/29
Establishes a new send message type with three distinct features...
- Eliminate the receiving address dust output by encoding the receiving address in the Counterparty message data
- Utilizes a single byte message ID (see CIP11)
- User specified Memo (optional)
To additional functionality to an asset send while at the same time making asset sends cheaper and more efficient.
Enhanced sends have a smaller transaction size, eliminate dust outputs, and add a memo that enables greater efficiency and lower tx fees for exchange operators.
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!
The primary use case for a memo field is to identify transactions to merchants and exchanges. This reduces the cost associated with accepting or listing XCP and Counterparty assets.
A 34-byte sender specified field stored in an asset send message
An Enhanced Asset Send adds the following two features to a traditional Asset Send transaction...
Encoding Receiving Address in Message Data
A standard Bitcoin/Counterparty Base58 receiving address can be binary encoded and stored as an element within a send message at a size of 21 bytes after removing the checksum.
The Memo is usually used to identify transactions to merchants and exchanges: when a single public address is used for incoming transactions, the Memo is especially useful to tie incoming payments with user accounts.
The enhanced send, detailed in this proposal, utilizes the existing asset send message data structure with some additional elements: a single byte message ID (see CIP11), receiving address and memo.
- New Message ID:
- Receiving Address (21 bytes): bitcoin public key hash, no checksum.
- Memo: The Memo is an arbitrary hex or text string to allow versatility for end users and developers. The encoded string must be no more than 34 bytes.
- Message Structure: CNTRPRTY + Message ID + Asset Name + Asset Qty + 21 bytes of Receiving network prefix and public key hash + Memo
- Total Message Data max size, 80 bytes
434e545250525459|02|000000000004fadf|000000174876e800|0026343166625c7475f01e48b5ede8c0252e051a8b|ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff 8 + 1 + 8 + 8 + 21 + 34 = 80
create_send adds these new parameters
- memo (string): The memo field data
- memo_is_hex (boolean): If set and true, then interpret the memo field as hexadecimal encoded data. Defaults to
- use_enhanced_send (boolean): If set and false, then use the old-style send with regular bitcoin dust. Defaults to
get_sends returns 2 additional fields
- memo_hex (string): The memo field as a hexadecimal encoded data
- memo (string): The memo field as a utf-8 encoded string
search by memo
When searching for a send in the database, you may filter by providing a
memo_hex field as a search filter. If filtering by
memo_hex, then the field value is interpreted as a hexadecimal value. If filtering by
memo, then the field value is interpreted as a utf-8 encoded string. Only exact matches are allowed when filtering by memo.
Fundraising goal = 300 XCP
Milestone #1 (80% - 240 XCP)
Implementation of enhanced asset send message type in Counterparty-lib with all necessary unit tests
Milestone #2 (20% - 60 XCP)
Implementation of enhanced asset send message type as default send message type in Counterwallet with all necessary unit tests
Bounty Address (escrow by J-Dog)
This document is placed in the public domain.