0009 XLS-9d: Blinded Tags

[nbougalis]

An updated version of this spec can be found here: XLS-9: Blinded Tags.

The earlier version can be found by looking at the edit history.

[movitto]

@nbougalis I gave this a read through, seems like an interesting feature. One point of confusion for me is the need for the recipient to generate a separate keypairs for use in blinding factor generation & secret extraction. Could the sender / recipient simply not just use the recipients account public / private key to accomplish the same? Or is this so that the blinding factor keypair can be revoked if compromised?

Also requiring the MessageKey to be set per recipient means each recipient using blinded tags will now require two transactions to have the same effect, one to set the MessageKey and the 2nd to perform the actual transaction. Eg if I'm sending payments to two different exchanges using BlindedTags, I'll need to issue an AccountSet setting the MessageKey of the 1st, then send the payment, then issue another AccountSet setting the MessageKey for the 2nd, then send the 2nd payment. Not impossible, but burns more in fees.

Thanks again for the neat proposal

[nbougalis]

Hey @movitto!

Could the sender / recipient simply not just use the recipients account public / private key to accomplish the same?

Sure but only if the public key of the recipient's account is known. Maybe it is, maybe it's not. Remember that an account address is the hash of the public key and the public key itself isn't known unless it's been used to sign a transaction. This is why the MessageKey field actually contains a public key and not a hash of a public key (e.g. like the RegularKey field).

Also requiring the MessageKey to be set per recipient means each recipient using blinded tags will now require two transactions to have the same effect, one to set the MessageKey and the 2nd to perform the actual transaction.

I'm not sure I follow. An account that wants to receive transactions with blinded tags needs to complete a one-time setup procedure, first setting its MessageKey and then setting either the asfRequiresBlindedTags or the asfSupportsBlindedTags flag. Note: this only needs to be done once (unless it wants to rotate keys periodically).

In your example, where you send two payments to two different exchanges, you'll need precisely two payment transactions, regardless of whether you're using blinded or "classic" tags. In the case of blinded tags, exchanges will need to perform the one-time setup described above, if they haven't already.

Thanks for the feedback and your contributions!

[mDuo13]

The interaction between the flags and the 64-bit tags is a bit confusing, but I'm not sure there's a simpler way that works with existing tag formats.

Also, a note, SourceTag is currently a common field to all transaction types, but as worded it sounds like all the new fields, including the blinded source tag field, would only be added to the transaction types that currently support destination tags?

[movitto]

Hey @movitto!

Could the sender / recipient simply not just use the recipients account public / private key to accomplish the same?

Sure but only if the public key of the recipient's account is known. Maybe it is, maybe it's not. Remember that an account address is the hash of the public key and the public key itself isn't known unless it's been used to sign a transaction. This is why the MessageKey field actually contains a public key and not a hash of a public key (e.g. like the RegularKey field).

Gotchya, so since the recipient has knowledge of their public key, they could simply using this as their MessageKey correct? Would there be any downside to doing so?

---

Also requiring the MessageKey to be set per recipient means each recipient using blinded tags will now require two transactions to have the same effect, one to set the MessageKey and the 2nd to perform the actual transaction.

I'm not sure I follow. An account that wants to receive transactions with blinded tags needs to complete a one-time setup procedure, first setting its MessageKey and then setting either the asfRequiresBlindedTags or the asfSupportsBlindedTags flag. Note: this only needs to be done once (unless it wants to rotate keys periodically).

In your example, where you send two payments to two different exchanges, you'll need precisely two payment transactions, regardless of whether you're using blinded or "classic" tags. In the case of blinded tags, exchanges will need to perform the one-time setup described above, if they haven't already.

OK, I was thrown off by this paragraph above:

The recipient must create a new secp256k1 keypair. The sender must set the public key of this keypair as the MessageKey of their account. Effectively, this means that the exchange will have associated an additional public key to their receiving wallet address.

"Sender" in this context should be "recipient" should it not?

Also with regard to the following:

If Z and the KeyIdentifier field are not the same, try to use an older keypair to determine the secret key to use. (Older keypairs are based on all MessageKey values the recipient has previously set.)

An interesting side effect of all this is that even if old keypairs are revoked / cycled out by the recipient, they will need to be kept around incase a sender uses one for a Blinded Tag transaction. Not ideal (especially if they have been compromised) but can't think of a way around this. At the very least I'd suggest prominently highlighting this in the user / developer docs pertaining to this feature.

---

Thanks for the feedback and your contributions!

👍

[mDuo13]

Is there a cryptographic reason to use 64-bit fields for the blinded tags instead of reusing the existing fields? If one were willing to use 32-bit blinded tags, it seems like you could adapt this spec to accomplish this without amending the XRP Ledger protocol.

I don't really understand secp256k1 key derivation and ECIES, but it seems to me that you could simply truncate the blinding factors to 32 bits instead of 64 bits, then use a MemoType that indicates that the transaction uses blinded tags, with MemoData containing the KeyIdentifier and RandomValue fields.

As a rule, destinations need to be the ones to provide the unblinded tags to transaction senders, because it is the destination's responsibility to interpret the destination tag and take whatever action that tag is supposed to prompt. Therefore, the destination could simply look for a memo with a MemoType indicating the transaction is using blinded tags, and de-blind the tag if it finds one.

The only part of the spec I don't think this achieves—aside from increasing the tag bitspace—is rejecting transactions at a protocol level if they don't use blinded destination tags; however, I don't think that's a major loss since fools can always send invalid tags regardless.

Incidentally, it seems to me like a destination could also implement a "blinded tags helper" that generates a new blinded tag on-demand from a web interface: such a tool would provide the blinded tag and the necessary KeyIdentifier/RandomValue fields to potential senders when prompted. (Actually, anyone could implement such a tool, and the only non-public information it would need is the tag to blind. But having the destination do it keeps the tag to the fewest possible people.) Of course, it's great if the sender knows how to generate many new blinded tags on their own from a single destination tag that remains private, but it still seems like something that could be a handy helper tool for destinations that have to tell people their tags anyway.

[lrvl]

Small typo near "de minimis"? Shouldn't that be "the minimize" or is it my own ignorance on the subject matter.

Edit: Should be read as: "Despite this, we recommend adding at least support for the use of 64-bit tags by setting..".

[intelliot]

"de minimis" is a Latin expression meaning "minimal".

[RareData]

Is there a cryptographic reason to use 64-bit fields for the blinded tags instead of reusing the existing fields? If one were willing to use 32-bit blinded tags, it seems like you could adapt this spec to accomplish this without amending the XRP Ledger protocol.

I don't really understand secp256k1 key derivation and ECIES, but it seems to me that you could simply truncate the blinding factors to 32 bits instead of 64 bits, then use a MemoType that indicates that the transaction uses blinded tags, with MemoData containing the KeyIdentifier and RandomValue fields.

I'd really like to hear your (@nbougalis) input to this. What can we accomplish using memos and what requires an amendment?

[RareData]

Could we achieve the same outcome with less complexity and less new fields, by simply having the new account flags enforce a certain memo to be present?

[WietseWind]

@RareData That's on a transaction level, where it would make sense to keep it simple and put Memo's to good use, indeed. On an account level it would make sense to advertise (eg. exchange deposit account) the possibility to deposit using blinded tags.

[RareData]

Yes, so what I'd like to discuss is the possibility to just introduce the new Account flags and then use memos on a transaction level. Minimize rippled complexity and have the clients do the heavy lifting. One reserved MemoType to indicate "Blinded Tags Extension".

[nbougalis]

Thanks for the feedback, @mDuo13, @RareData, @WietseWind.

First of, there's no cryptographic reason to go with 64-bit tags; the blinding factor for each field can just be chopped down to 32 bits and it's fine. The key property we want for the blinding factor is that, assuming a size of N bits, it should be a uniformly distributed unsigned integer in the range [0, 2^N-1], and whether we do 64- or 32-bit tags, we'd still have that property.

But I do believe that 64-bit tags are generally a better proposition and this was was a good opportunity to introduce them.

With all that said, let's talk about memos: I do agree that this (and more) could be achieved be using memos and would not have any objections is that's the route that gets more traction. I am supportive of finding uses for memos (and think that this proposal could make a good starting point for defining a "standard" to encrypt memo contents). As Wietse pointed out, what memos lose us is the ability to enforce flags like RequireDestinationTag.

Yes, so what I'd like to discuss is the possibility to just introduce the new Account flags and then use memos on a transaction level. Minimize rippled complexity and have the clients do the heavy lifting. One reserved MemoType to indicate "Blinded Tags Extension".

I don't think that having account flags that say "memo required" is a good idea. Using encrypted memos is fine and opens up more possibilities (including the ability to include a message for the recipient, which banks already allow with wire transfers, albeit not encrypted)

With that said, the existing spec has minimal complexity; the complexity basically is having new flags and new fields. Beyond that, it leaves all the heavy lifting to the clients which is, generally, a good idea.

[mvadari]

@nbougalis should this spec be moved into PR and kept in the repo or should it be closed? Note that this does not mean that the spec has been accepted/implemented/finalized.

I will move it to PR by copy-pasting the existing draft if there is no response in the next week.