8

I understand that the payment ID is stored in the tx-extra field. Only one payment ID can be specified when sending, even when sending to multiple addresses, because it's specified on a per-tx basis.

I'm assuming that it was made this way to preserve space. Specifying it on a per-output basis would mean it being repeated many times for each denomination even for the simplest transaction to one address. Was this the only reason?

With ringCT, would it make sense to consider enabling payment ID on a per-output basis? Was this considered, and if it was, what would be the main pros/cons. I take it that with ringCT, we would have to repeat the pID 2 times (output+change) if we want to prevent leaking which output is which.

Improve this question
2
  • How about posting this to the GitHub repo as a feature request?
    – kenshi84
    Jan 5, 2017 at 3:05
  • 1
    Will do, it'd be nice to have this with your disposable address scheme.
    – JollyMort
    Jan 5, 2017 at 20:08

2 Answers 2

Reset to default
2

From my understanding, the payment ID is not associated with a specific output. It is included in a different portion of the transaction, near the transaction hash and public key.

There is no practical reason to use more than one payment ID. Its only purpose is for merchants and exchanges to verify which person sent the funds to them. There is a direct harm to the network with the substantial additional transaction size if a per-output method was chosen.

I do not believe that there is any risk of leaking which inputs and outputs are the "real" ones when using a payment ID. It should be computed separately. Even if it is not, I would suggest adding 1 to the default mixin, which would provide the same security improvement with less additional bloat.

Improve this answer
1
  • Maybe you want to send to multiple addresses in one transaction - you'd have to make a separate TX for each. And each TX would lock some change output for 10 blocks... so it'd be a 'nice to have' feature. For normal users maybe not important, but business to business use cases could be helped by this. Per-output would mean per-group-of-outputs actually, and if you're sending to one address and don't write PID to change as well, it would be clear which is the destination and which the change, so there's a privacy loss with this and mixin can't help because it hides the origin and not the dest.
    – JollyMort
    Jan 5, 2017 at 20:16
1

Why would having multiple payment ID's per TX be any better? The simplest answer is because it's intuitive and it works.

Improve this answer
1
  • Because maybe you want to send to multiple addresses in one transaction. Currently, they would all share the same payment ID, and you'd have to make a separate TX for each. And each TX would lock some change output for 10 blocks... so it'd be a 'nice to have' feature. For normal users maybe not important, but business to business use cases could be helped by this.
    – JollyMort
    Jan 5, 2017 at 20:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.