Send Payment ID Field CIP - Discussion

Development
1

I would like to propose the addition of a payment ID field to the Counterparty protocol specification. A payment ID field is a field of a currently undefined (potentially variable) size, where arbitrary data can be attached by the transaction creator.

Immediate utility: This would reduce exchange fees for Counterparty deposits by up to 50%, if the exchange allows for ‘Payment IDs’. A Payment ID is a number attached to the payment ID field, which allows multiple depositors to be differentiated between when they send to the same address. This bypasses the need for an exchange to maintain a separate deposit address per-customer, which means no ‘priming’ is necessary. I believe this would clear up a large number of headaches for exchange integration / maintenance, and ultimately improve adoption of the protocol.

Concerns: This would require adoption by the major Counterparty wallets and exchanges. If Payment IDs were adopted by exchanges, they could not be fully integrated until most major wallets added the ability to attach a memo.

I would like to open a dialogue as to whether you all see a payment ID field as a beneficial addition to Counterparty, other potential uses for payment IDs, and to nail down the spec for how large a payment ID can be (and where in a tx they are stored).

1 Like
2

I think there is merit in this idea. I’ve never been on the operations team of an exchange but I can imagine it would help them with XCP and XCP assets a TON.

The team behind XCP (and I can only guess here) seems intent on utilizing the DEX as much as possible. In theory, we have no need for exchanges beyond people getting their hands on bitcoin. But the reality is that exchanges hugely widen the onramp. The other reality is they widen the off ramp too.

For the same reason, traditional banks arent big bitcoin fans. I imagine crypto exchanges arent big counterparty fans. Im not sure making XCP more exchange friendly will turn them into XCP fans but it couldnt hurt. Not to mention the memo field would likely be utilized in some form or fashion by existing DEX fans.

3

I think this is a great idea! A memo field on send transactions would have many use-cases, including allowing merchants/exchanges to receive many payments to a single address while still being able to tie each payment to a specific order/customer.

I bump up against an issue with the vending machine service I run at CoinDaddy. All the payments for a vending machine are sent directly to the vending machine operator’s single address. The only way I am able to identify which payments are for which orders is by collecting the address that the customer is sending the payment from, and then matching the from address and amount up with the order. This is less than ideal because customers don’t always send from the address they say they are going to, and if they send from the wrong address, they need someone to manually mark the payment as received so that the order is released.

Adding this memo field would improve the overall ordering experience because I can stop collecting the customers payment address info and instead just say something like “please put ‘a8f7s0af6’ in the memo line of the payment.” Once they send the payment I can easily tie ‘a8f7s0af6’ to a specific customer order.

My thoughts on the max length is that there should definitely be one (since we need to store the memo data in the CP database). Perhaps max it out at 64-characters? This would allow for someone to reference another transaction in the memo line, which could be useful in some applications.

What are your thoughts on the characters allowed for this memo field?

4

which means no ‘priming’ is necessary. I believe this would clear up a large number of headaches for exchange integration / maintenance, and ultimately improve adoption of the protocol.

I’m not sure what you mean with ‘priming’, so please clarify on that part because I’d love to know if there’s fixable things :wink:

The team behind XCP (and I can only guess here) seems intent on utilizing the DEX as much as possible. In theory, we have no need for exchanges beyond people getting their hands on bitcoin. But the reality is that exchanges hugely widen the onramp. The other reality is they widen the off ramp too.

Ofc we love the DEX but rest assured there’s no bias or hostility towards exchanges and if exchange operators would be more vocal about certain CP protocol things being a (technical) problem for them we could try to help.

I feel your pain considering the lack of “change” outputs and it currently too hard to use Counterparty without address reuse, this seems like a decent quick-fix though I’d prefer a proper fix for the root problem instead of a monkeypatch…

A public memo field is also not a horrible idea for various use-cases, but there 2 problems that I see;

  1. it might cause many SENDs to no longer fit in OP_RETURN

  2. it’s a great way to spam people, just send tiny amounts of XCP or random assets to people and attach a memo with “Get 10% of your Dominos Pizza if you order with coupon code IJUSTGOTSPAMMED”.
    I’m sure there’s people who would pay $0.30 tx fees to get a message delivered to their target audience

I don’t think there’s much reason for a max length beyond some sanity limit, if you wanna fill up counterparty nodes with data we have the broadcast message to put crap into that nobody will ever read but is being stored xD
we could make it fairly short to try and keep SENDs within OP_RETURN bounds, but then we’d also need to probably save some space for any future additions to SEND…

5

Great idea!

Just two questions;

  1. Ideally you’d want to include the memo in OP_RETURN. How many bytes are available for a memo?
  2. The spam concern is real, but me as a user wouldn’t mind the BTC dust that comes along (and I expect wallets to implement a filter too, so not all assets need to be visible). Whether node operators (who will need to handle this extra burden) are fine with it, I don’t know. (?)
6

Priming == Exchanges having to setup a special deposit address for each customer to make deposits and then “priming” the address (ie, sending some BTC) so that when the CP asset deposit hits the customers deposit address, it is automatically moved from the customers deposit address to the exchange hot-wallet… Adding a note field to a send would enable exchanges to allow their customers to deposit directly to the hot-wallet address without having to waste additional BTC fees moving assets to the hotwallet every time a customer makes a deposit .

1 Like
7

Here’s a good resource that shows what a send tx actually looks like stored in OP_RETURN.

1 Like
8

To keep the transaction within an 80 byte OP_RETURN there are 52 bytes available in a send transaction.

9

What would be some different competing approaches to a “memo” in OP_RETURN?

10

Including the memo data as part of the transaction is the only feasible way to attach a memo.

All Counterparty transactions are encoded in OP_RETURN if they are no more than 80 bytes. That is because OP_RETURN is the most efficient way of encoding a transaction.

11

Yeah, I meant besides “in” the transaction. Could always add another component to CP stack.

I like the idea of adding small messages. Agree with J-Dog that 64-70 character would be ideal. CIP4 + memos… might be a pita to handle and prevent some common memo usages which could be problematic.

12

To keep the transaction within an 80 byte OP_RETURN there are 52 bytes available in a send transaction

Also keep in mind the proposal to include the recipient address in OP_RETURN. That would take another 20 bytes, leaving 32 bytes for a memo.

13

True.

I doubt we would make the OP_RETURN destination would be required. So, if you wanted more than 32 bytes for a memo, then you could use a standard send with a destination address.

And fitting within an OP_RETURN is not required. It is just the cheapest way to encode data.

14

@needmoney90 - Would you like to be the CIP author and champion for this feature?

15

I can take on putting a CIP together that combines both features

1 Like
16

They feel like 2 completely separate features to me. But I can see them being implemented at the same time since they both modify the send transaction type.

17

It’s certainly two features. I’m thinking we can call it something along the lines of “Enhanced Send”

18

Sometimes I do want to intentionally send some bitcoin dust along with the asset. If we combine them into a new transaction type, can we still use the memo field along with the old-style destination?

19

I don’t see any reason why not. Can use a DIP switch type byte immediately following the message type that signifies old style or new style recipient address encoding.

20

Thx for explaining the priming @jdogresorg, though there’s more elegant solutions to that…, you could use an input from another address to pay the fee for example so you wouldn’t have to prefill it with BTC.
However in the current state of CP it still would require the hassle to gather the assets into 1 main address etc. to make it easier to spend so I understand the concern completely.

Back on topic of this feature in isolation;

Apart from the exchange problem I think this is a very niche feature, you generally don’t send someone assets without any side-channel communication (about a deal, purchase or gift) and even if you do it’s not very sane to include a message in public writing.

I can think of arguments against letting users stuff public arbitrary notes into transactions,

  • some might not realize it’s public (oops my phone number is in the blockchain),
  • others might use it to dox or attack people,
  • it could be used to advertise,

But you could easily use asset names and descriptions (and broadcasts) already for the last 2,
and the first one … should be more of a UI thing for a wallet than a protocol decision.

So I can’t really object to this feature when considered in isolation.

Now as for keeping send within opreturn bounds, this is an entirely different subject;

Most users probably won’t care enough about the UTXO pollution to make the choice not to when they’re given this choice, they’d at most consider the increase in fee.

But should we force send within opreturn because the other 2 encodings hurt the bitcoin network and send is by far the largest part of CP messages?

If we’d want to force send to remain within opreturn bounds then;

my #1 desire for adjusting send (or even #1 desire for CP overall) would be to add a change address and allow spending from multiple addresses in 1 TX just as with bitcoin transactions, so we have the posibility to move away from address reuse.

I’d prefer discussing that in depth before “giving away” space in the opreturn to things like an address or a memo and then not having enough space left to do so (though this new send could also be send2 and apply new restrictions to the memo field.

Considering current fee rates dust outputs are way below economically spendable my priority would be change output + multi input > no dust output > memo

I need a bit of time to think about all this myself,
I don’t enjoy the thought of taking part of something that is polluting the bitcoin UTXO set (and thus slowly - though only mildly - hurting the bitcoin network),
and being able to completely fix this (by removing pubkeyhash and multisig encoding at some point) would be my dream come true.

Doing a “best effort” thing of at least forcing send to remain within bounds of opreturn is somewhat comforting…

Down the line when segwit has activated and P2SH encoding has been released we could remove pubkeyhash encoding and bare multisig encoding in favor of P2SH encoding, P2SH encoding doesn’t hurt the bitcoin network in any way.
This change would then enable send beyond opreturn bounds and it would just be a choice of the user if he’s willing to pay the extra fee for his memo to be included, the memo could be of arbitrary length then.

PS. 100% sure 2 CIPs, could be implemented 2gether though.

2 Likes