Skip to content

Latest commit

 

History

History
116 lines (63 loc) · 4.36 KB

cip-0009.md

File metadata and controls

116 lines (63 loc) · 4.36 KB
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

Abstract

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)

Motivation

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.

Rationale

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.

Definitions

Memo

    A 34-byte sender specified field stored in an asset send message

Overview

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.

Memo

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.

Specification

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: 0x02
  • 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

Example

434e545250525459|02|000000000004fadf|000000174876e800|0026343166625c7475f01e48b5ede8c0252e051a8b|ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff

8 + 1 + 8 + 8 + 21 + 34 = 80

API Changes

create_send

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 false.
  • use_enhanced_send (boolean): If set and false, then use the old-style send with regular bitcoin dust. Defaults to true.

get_sends

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

Implementation

In development...

Milestones

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)

1C7WDBi9rBqLNG6wAJbri8bP6jroTj7DwD

Copyright

This document is placed in the public domain.