I remember it's mentioned somewhere that account id is used in transaction on blockchain instead of address. Suppose you're using a lightweight wallet and you want to transfer money to someone account. If the server cheats you by giving wrong account id, your money can go to somewhere else. In bitcoin (or BTS1.0), if I'm using address as transfer target, the worst the server can cheat is not broadcasting and I'm relatively safe. I think it's better to use address on blockchain and for perfomance reason hash the address to an id for memory and code to use. This way it's still safe and with high performance. I know if you're using account name, we need to trust the server for getting the account id or public key and it's similar with BTS 1.0. And account id as target has the benefit that changing active/owner key will not impact account's balance. But at least we should have an option to specify address as target in a transaction on blockchain.

to withdraw a balance, only check account IDto deposit a balance, need to check both account name and account ID, even address.I think this is the best way, and can avoid to sent to a wrong receiver even if he have update the public key.sever can't cheap client with a wrong ID, or wrong address.

I don't see why it's different, why can't the server replace the address in the same way as the id? It's simply a unique identifier, in this case it will be an easier one to verify visually as well since you won't need to double-check a huge bitcoin-style address.

Users should share the ID as the primary identifier. The name is a check.

In some sense names are less necessary and should not be used on their own.

Sent from my iPhone using Tapatalk

Well, in my case, I always use account name and don't even care what the account id is. Actually I fear typo a lot and always copy the name instead of typing. In this sense, it's not different than an address and address has even additional hash check for typo.

I don't see why it's different, why can't the server replace the address in the same way as the id? It's simply a unique identifier, in this case it will be an easier one to verify visually as well since you won't need to double-check a huge bitcoin-style address.

I think the difference is that there's one more step to get account id from a name from a trusted server. In bitcoin, you only need address (which is somewhat equivalent to id).

OP is a bad example because the server could spoof a name->address map just as easily. The real problem has to do with chain reorganization and replay attacks. Seems the solution is that DPOS achieves consensus too quickly for that or something

Logged

Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

OP is a bad example because the server could spoof a name->address map just as easily. The real problem has to do with chain reorganization and replay attacks. Seems the solution is that DPOS achieves consensus too quickly for that or something

Yes, reorg and replay is another issue and I still think we need an option to transfer to a bitcoin like address.

I don't see why it's different, why can't the server replace the address in the same way as the id? It's simply a unique identifier, in this case it will be an easier one to verify visually as well since you won't need to double-check a huge bitcoin-style address.

I think the difference is that there's one more step to get account id from a name from a trusted server. In bitcoin, you only need address (which is somewhat equivalent to id).

OK I see what you mean here and how this could be an issue. At least in our web wallet though the id's will be displayed as well as the names, so when you attempt to make a transfer you can verify the name and the id, even looking it up on an external site like Bitsharesblocks if you want to.

There are two password for us to pay, using a centralized service.Usually, we login with a long password, and input a short password to confirm the pay.The short password can be reset, just to make the owner be serious to pay money.

OP is a bad example because the server could spoof a name->address map just as easily. The real problem has to do with chain reorganization and replay attacks. Seems the solution is that DPOS achieves consensus too quickly for that or something

TaPoS prevents that in DPOS 2. By referencing a particular recent block hash you implicitly reference all allocated IDs. If the chain reorganizes then your transfer becomes invalid.

The user interface is going to display the ID as the "checksum" for the account name. The security paranoid will manually verify account IDs as they add accounts to their address book.

Light nodes should check with multiple servers via a secure channel to prevent man in the middle.

Logged

For the latest updates checkout my blog: http://bytemaster.bitshares.orgAnything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else. These are merely my opinions and I reserve the right to change them at any time.