Send to "Virtual Address" feature

[bytemaster]

Many exchanges and individuals have expressed concern that asking a user to enter account name and memo is error prone, especially if they are depending upon automatic processing of memo contents. They really like the "address" approach, but there is no need for the "address" to be related in any way to a public key so long as they can generate a unique address and typos cannot screw it up.

struct virtual_address
{
    asset                   amount;
    account_id_type to;
    string                   memo;
};

auto bin_address = fc::raw::pack( virtual_address() )
auto checked_address = bin_address + sha256(bin_address)[0..4]
auto string_address = "BTS" + tobase58(checked_address)

With this approach exchanges can generate as many addresses as they would like and users can copy/paste a single item into the "send" field and have it automatically fill in the memo/etc with no errors.

[bytemaster]

In the GUI make sure to disable editing of the memo, amount, to, and asset_id when sending to a virtual address.

This can be viewed as an Invoice ID as well.

[theoreticalbts]

Do we have to disable account names that start with this prefix then?

[jcalfee]

@theoreticalbts account names must all be lowercase... @bytemaster probably a good idea for the GUI to display these fields and provide a lookup on the account_id_type...

[arhag]

In the GUI make sure to disable editing of the memo, amount, to, and asset_id when sending to a virtual address.

How about adding a bool to virtual_address that determines whether the GUI should lock the amount and memo or not. If it is true, then all fields are read-only. If it is false, then only the editing of the to field is disabled while the amount and memo are merely suggestions to the user that the user is allowed to replace.

It might even make sense to have another flag that locks the to field and the the asset type and sets a minimum on the asset value (and perhaps it even requires some prefix for the memo). The user would be able to edit the amount to anything that is not less than the specified minimum and they could also edit the memo field (assuming it isn't locked by the other flag and within the constraints of any specified prefix). This could be useful in scenarios where the user wants to pay a tip. The virtual address can be communicated to the user's device (say through a QR code) which would make their client fill in everything so that it is ready to go. But the user can then increase the amount as they wish to pay a tip and even leave a small note in the memo without the risk of accidentally paying the wrong account or messing up the receiver's order processing methods or wasting a transaction that doesn't pay enough to satisfy the customer's obligation.

[theoreticalbts]

I believe after some discussion, what we really want is something like Bitcoin's payment protocol. I think we should shelve this until we figure out exactly what the use cases are, and what Bitcoin and other cryptos do to address those use cases.

Furthermore, it seems like this is a wallet-only feature that does not require additional core support, so if we want to do it later, we needn't hardfork to get it in.

[theoreticalbts]

Could this be done with a proposed transaction?

[theoreticalbts]

Would it might make sense to have an account flag which disables transfer to the account without the account's signature? That would get rid of the "someone sent me BTS, but I don't know what exchange account to credit it to" problem -- if someone tries to send the exchange BTS, the exchange can refuse the transfer if the memo's wrong. It complicates the wallet on the client side though.

[valzav]

So any decision made on this issue? Please close the issue if the decision is not to allow to send to virtual addresses.

[theoreticalbts]

I think this is probably a wallet-level feature. E.g. specify a standard way to add a separator character not valid for account names, plus checksum, to an account name, then a wallet-level flag which will only allow processing of accounts when the checksum is present and valid.

[theoreticalbts]

As there has been no discussion on this issue for a long time, I'm going to close it. We can re-open it open a new issue once we have a clearer idea of the requirements for a payment protocol.