Destination tags should be 64-bit about stellar-protocol

[andrewchambers]

64 bit is a massive improvement on the current system, and there are alot of libraries for dealing with 64 bit precision in javascript.

if disk size was the issue, they could be stored on disk as variable width encoded values.

"Bumping the destination tags up to 64-bit obviously makes this attack impossible."

Could you elaborate on this attack?

To prove ownership of an account, you suggest sending an amount of currency to an address with a unique destination tag from the address to be verified. If I understand correctly, you're proposing a brute force attack that would submit transactions to that address using all possible destination tags; thus, proving ownership of an address you do not control.

Even if you did succeed in guessing the unique destination tag, the transaction still would have originated from the attackers address and not the address for which they are trying to prove ownership. The only way this could falsely prove ownership is if the originating address wasn't checked to make sure it was the address needing verified.

I'm not against using another datatype, I just don't see an exploitable situation (related to a 32 bit int) in the attack you proposed. Additionally, I think using the private-key to sign something would be a much better way to verify an address, but that isn't relevant to your proposed scenario.

[lilyball]

@NathanCVoss Well, it's an attack on a slightly different system, one where the payment itself is both proof of ownership and declaration of which address is owned. I'll grant you that it's unlikely that someone will set up their system like this in the first place, typically they'd require you to tell them the address and then pay them from that address. I admit I kind of ignored the difference there, and it does make that particular argument less compelling.

Additionally, I think using the private-key to sign something would be a much better way to verify an address

Agreed, but that requires client support.

Thanks for the clarification, and I definitely agree having the ability to easily sign something with your key is an important feature.

To your first point I also have a question. You suggest that someone may wish to use use a single address for incoming payments and could identify particular transactions via the destination tag instead.

In this scenario, wouldn't they have to supply the sender the destination tag to include in the transaction, and if so, would it not be just as easy to supply them a unique address instead?

[lilyball]

@NathanCVoss No. Stellar is not like Bitcoin, you can't just create new addresses willy-nilly. Specifically, every address needs to hold a 50STR reserve, which means creating a new address for each sender costs you 50STR.

@kballard That is something I had forgotten. If this field must be used as an alternative to multiple addresses then the data type should indeed be changed. If these address constrains were removed, I would consider it far less of a concern.

[irisli]

I agree that the destination tag should be extended to 64 bits. It would drastically reduce the amount of destination tag number collisions so that they can't be guessed easily (2^32 or ~4 billion times harder to guess). Useful for many applications since so many essential ones on the Stellar system use destination tags.

Why workarounds aren't effective

If an application wanted to increase the space of available destination tags they can use, they can create more accounts but that would only increase their space linearly based on the amount of accounts they create. Increasing the destination tag limit would increase their dt space by ~4 billion without any stellard consumer (e.g. gateways and Stellar services) workarounds.

Disk size

One counter argument would be that it would increase ledger bloat by 4byte per transaction. Paypal says that they process 9.3 million payments everyday (source) meaning that it would add 37.2MB per day and 13GB a year from this increase in destination tag size alone. However, looking 10 years into the future, >10TB hard drives will become common.

Computational performance cost

As for the performance cost, changing a 4 byte int to a 8 byte int would hardly affect computational performance. It would only require more disk space and marginally larger disk io's.

[johansten]

1. Payments.

You don't need to have one unique destination tag for each individual payment. You just need one unique destination tag for the payments that are due right now. After a payment is settled, you can safely reuse tags.

2. Proving ownership is most probably better done using some other mechanism.
   We have signing already, so why not just sign a message with your private key?

[lilyball]

1. only works if you're expecting the payment already. If you need to be able to receive payments associated with an account on an ongoing basis the. You can't re-use the tag.

2. sure, signing a message is better for actually proving ownership, but there may still be a Know Your Customer concern with receiving payments at potentially-guessable addresses.

[jedmccaleb]

this is done now. The memo you can attach to transactions is much more flexible

[hethm999]

بالتأكيد انا هنا لاساعدكم انا اسمي هيثم مطور شبكة بلوكشين ومصدر الرموزات المميزة كونو مطمئنين دعونا نتعاون معأ لدي الملكية الفكرية في جميع البروتوكولات التي قمت بزيراتها لذالك دعونا نحط يدا علا يد ونمضي قدما