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.

  • How about posting this to the GitHub repo as a feature request? – kenshi84 Jan 5 '17 at 3:05
  • 1
    Will do, it'd be nice to have this with your disposable address scheme. – JollyMort Jan 5 '17 at 20:08
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.

  • 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 '17 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.

  • 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 '17 at 20:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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