Auto Account Creation

[SimiHunjan]

---

hip: 32
title: Auto Account Creation
author: Leemon Baird leemon@hedera.com
type: Standards
category: Service
needs-council-approval: Yes
status: Last Call
discussions-to: #187
last-call-date-time: 2021-12-03T07:00:00Z
created: 2021-11-01
updated: 2021-11-30

Abstract

This hip introduces a new way to create accounts on Hedera using a public key.

Motivation

If a user has an account on Hedera, it is easy to create new accounts, paying for the new accounts from the old one. But if a user has no account, then it is inconvenient to create a new account, because they need the help of someone else to pay for the creation of the account.

Rationale

A possible solution would have been to make all account creation free, but this would encourage denial of service attacks that over-use the free service. So this is not ideal.

A better solution is to allow users to create "accounts" for free that are not actually accounts on Hedera that use resources, but that convert into Hedera accounts in a way that is automatic and invisible to the user.

The Hedera API (HAPI) can be modified very slightly, so that HBAR transfers can continue to send to account IDs (such as 0.0.123), but can optionally send to an account identified only by a long-form of account ID, which is actually its initial public key. When such an account doesn't yet exist, then it will be automatically created, with the fee being subtracted from the HBAR amount being transferred.

Wallets

Wallet software can allow the user to create an "account" instantly, for free, even without an internet connection. In this case, it will not create an actual account on Hedera. Instead, it will simply create a public/private key pair for the user. The software will then display this as an "account" with a zero balance, with a "long account ID", which doesn't look like 0.0.123, but instead is an alias consisting of "0.0." (or appropaiate shard/realm) followed by a base-64 string encoding the public key.

The user can then buy HBAR on an exchange, or receive HBAR sent from a friend, or receive HBAR paid by a customer. In all those cases, they will tell the other party that their "account ID" is that long-form account ID. And the transfer will actually create an actual Hedera account, deducting the creation fee from the amount transferred.

The wallet software can then query a mainnet node (or a mirror node) for info about their "account" using the long form of the account ID, and the reply will indicate whether it exists, what its actual account ID in short format is, and what its current balance is. At that point, the wallet can start displaying the short-format account ID rather than the long format. The long form will continue to work as an alias.

That alias will continue to be associated with that account for as long as it exists. If the account is deleted and removed from Hedera, then the alias can be associated with a new account.

User stories

As a wallet provider, I would like to create free Hedera accounts for users.

Specification

Implementation for Hedera

HAPI will need to be updated so that the account ID can support aliases. It currently has 3 components (shard, realm, account), where the third component is an integer. The modification will allow the third component to be a oneof either an integer or an alias. The alias is a byte array (protobuf bytes) that is formed by serializing a protobuf Key that represents a primitive public key (not a threshold key or key list, etc.).

Each account in memory will need to store an additional field for the alias. This is a single public key. It is the one that was used to create the account, if it was automatically created. It will be set to null if that account was created normally. An account update can change this from null to a valid alias, but only if the update is signed by the private key corresponding to the public key in that alias. Only one account can exist with a given alias, so updates will fail if they try to give another account the same alias.

An automatically-created account will be created with only one public key (the one that is in its long-form account ID). It will have "received signature required" turned off. It will be created with whatever is the default expiration time at the time it is created (currently about 3 months). Its initial balance will be the amount transferred, minus the creation fee. If the amount is insufficient to pay the fee, then the transaction fails, and nothing is created.

At most one account can ever have a given alias. If a transaction auto-creates the account, any further transfers to that alias will simply be deposited in that account, without creating anything, and with no creation fee being charged.

An account created normally has no alias. It can be given an alias with an account update, but only if that alias is not currently used by any other account, and only if the update transaction is signed by the private key corresponding to the public key in the alias.

Once an account has an alias, the alias can never be changed, and can never be associated with any other account until the first account is deleted and removed from the ledger. Only then could another account be created or updated to be associated with that alias.

Hedera Services will then need to store a map from alias to the created account. This can be a rebuilt data structure, that is regenerated each time a new state is loaded from disk. It is only populated with (alias,account) pairs for existing accounts that have aliases.

When an account expires, it is frozen for a period of time, then eventually deleted. At the moment it is deleted, its alias (if any) is removed from the map. It could then be used again for a new account, by auto-creation or by account update.

The getAccountInfo query will return all the standard information, including the short account ID, and the alias, if there is one.

The receipt and record for a transaction should also be updated as appropriate.

Implementation for mirror nodes

Mirror nodes will need to record the new information, and allow queries by long-form account number, in addition to the current short-form queries.

Implementation for wallet software

The wallet software will need to support the workflow described in the summary. It should allow the creation of an "account" for free, that is purely local. For that account, it would display the long form of the account ID, and show it as having zero balance. If it ever checks the account balance and discovers that the account now exists on the ledger, it will get the short form of the account ID, and display that.

From the user's point of view, these virtual "accounts" should be indistinguishable from normal accounts, other than the fact that their "account ID" is in a long format. And that eventually, they also have a short-format account ID.

Backwards Compatibility

• This is backwards compatible
• Existing accounts have no alias, and cannot be accessed by an alias
• New accounts that are auto-created will have an alias, and can be queried and transferred to using that alias.

Security Implications

How to Teach This

• Generate a key pair offline, send hbar to the long-form account ID, and see that the account is successfully created

Reference Implementation

Rejected Ideas

Open Issues

References

Copyright/license

This document is licensed under the Apache License, Version 2.0 -- see LICENSE or (https://www.apache.org/licenses/LICENSE-2.0)

[SimiHunjan]

PR: #188

[bugbytesinc]

Public keys are re-used across multiple accounts, how will this be accommodated.

[shemnon]

The alias can exist against only one account, so if a public key is used across multiple accounts they will need to be referenced by standard notation.

Also note that not every account will have an alias, and the alias may not correspond to a public key.

[shemnon]

Can the public encoding not be base64? Font and handwriting transcription errors are common around the letters I, i, l, 0, o, and O.

Two alternatives are Base-16 (popular among smart contract chains like Ethereum and Polkadot) and Base58 (popular among Bitcoins and other UTXO chains).

[bugbytesinc]

The HAPI uses arrays of bytes on the wire for all other key representations, It would be good for the resulting protobuf to remain consistent and do the same with this address representation. Why can't wallets choose the encoding they wish (Hex as well for example)

[shemnon]

Instead of storing the public key itself, can a hash of the public key be stored instead? Perhaps even a salted hash (public key + memo creating the hash).

The downside is that the account would not have a key, just an alias and balance. An extra call would be needed to enable use of the account by the external owner. Perhaps an account update where the single public key and memo are added to the account.

This would allow one public key to "own" multiple accounts, but if the memo is lost the account becomes lost too.

[shemnon]

This would have a small privacy preserving impact as well, although some attacks could be made by looking for all possible memos for all known public keys. If the pattern for the memos is reasonably enumerable this can be done, but the search space is too large for all memos.

[mehcode]

Can we prevent auto-created accounts from ever updating their key, ever? I foresee a lot of anguish if this works as described by the HIP

• auto-create account Alice with public key FOO
• auto-create account Bob with public key BAR
• change account Alice's key (with account update tx) to public key BAZ
• change account Bob's key to public key FOO
• change account Alice's key to public key BAR
• now sending HBAR to public key BAR (associated to Alice) goes to Bob
• ... and sending HBAR to public key FOO (associated to Bob) goes to Alice

[bugbytesinc]

Preventing the rotation of keys would seem to be asking for even more more trouble. This is a security issue if your key is compromised, You would need to abandon the entire account... but what if you have automatic payments (say, token distributions) already tied to the account forcing you to keep the associated 1.2.3 address and that can't be changed due to smart contracts or 3rd party system implementations.

[mehcode]

I would go as far as saying that if we're doing this we shouldn't even assign account IDs to these new types of accounts. Make them only accessible by their alias key. We look a lot more like other networks this way (and are therefore compatible in the same spheres).

[bugbytesinc]

We are too far down the 0.0.0 path for that to be a viable option. Every single HAPI call would need two versions, and need to mix these two versions of accounts, this would be impractical. Per Dr. Baird's comments below, this is intended for a very narrow scope of interaction for transfers only, and while its obvious I think this whole thing is a bad idea (mostly from a human cognitive perspective) limiting this to the scope discussed below this might still provide more utility than it costs in increased efforts to maintain.

[Sean-Tedrow-LB]

Proposal: after the first TransferTransaction to a given aliasKey which causes the account to be fully created, the aliasKey can only be used to fetch info about the account using AccountInfoQuery, and the aliasKey cannot be used to refer to that account in any other query or transaction. In other words, once an account is fully created on the Hedera network, that account must always be referred to by its account ID going forward. Once the account is fully created, and we begin referring to it exclusively by its account ID and not its aliasKey, we can change the account's key without confusion.

[bugbytesinc]

This sounds like a general look-up-address-by-key feature that could be a separate HIP?

[rbair23]

I think the problem with this proposal is that it still creates friction for people from the Ethereum ecosystem, who are used to crypto transfers based on public keys instead of account IDs.

[Sean-Tedrow-LB]

rbair23, do you envision a future for this platform in which many users refer to their account by aliasKey indefinitely, and perhaps do not know about account IDs?

[Ashe-Oro]

it would be good UX for ETH-based users to have the option to use their aliasKey indefinitely.

[bugbytesinc]

What about the future when you have different shards and realms? Will the node have to search all these shards and realm to find the alias?

[bugbytesinc]

@lbaird can you chime in? none of this feels all that good.

[lbaird]

I agree it’s useful to have a standard for representing the alias. The proposal said base 64. That seems good.

Once the account is created, the alias is just an alternative way to refer to it. There’s no real harm in other accounts having keys that match that alias. Or memos that match the alias. Or files containing contents that match the alias. Because you don’t refer to accounts by their keys or memos or contents. You only refer to accounts by either their account ID or their alias. So there shouldn’t be any confusion.

The alias will be unique for a given shard and realm. Other accounts might happen to have a key or a memo or a file contents that happens to match the alias. But only one, single account will have that byte string as its alias. So it shouldn’t be confusing.

If you buy hbars from an exchange, or have them sent by a friend, and the transfer is going to create a new account, then the new account will be in the same shard and realm as the sender. So you would need to be told that. You could search all the shards, if you wanted to. But more likely, the exchange would simply tell you which shard they’re using, on the web page or app that sold you the hbars.

The alias is only really needed for one transaction type (crypto transfers) and one query type (get info for account). The former is needed to create it, and maybe to send more hbars to the same address. And the latter lets the owner discover the normal account ID after it’s created. Everywhere else throughout HAPI, it is sufficient to require that only account IDs be used, and never account aliases.

There was a comment above about looking up all the accounts that have a given key as one of their keys. That is something the mirror node supports. They also support looking up an account by its memo. And now they’ll need to support looking it up by its alias. Those 3 operations aren’t going to fail if the same string of bytes is a key on one account, an alias on another, and a memo on another. It works fine, because your query says what fields you’re searching on.

But on mainnet, none of those queries are needed, except getting info by alias or getting info by account ID.

There was also a suggestion to disallow sending hbars to an alias after the initial transfer. But if we’re already paying the memory price to store the alias, there’s no particular harm in allowing more than one transfer to it. And there are use cases where it is useful. You could buy hbars from two different exchanges, and it won’t matter which order they execute their transfers. The first transfer will create the account, and the second will send to it. Or, similarly, you could ask a friend to send to an alias to create the account. And then tomorrow, the friend wants to send some more, and happens to use the alias again. There’s no reason to punish them by making the transfer fail. It might as well go ahead and succeed.

So that would mean the alias will be usable forever, for exactly two purposes: a single transaction type, and a single query type. For every other transaction and query, the account ID is required.

[SimiHunjan]

@bugbytesinc @mehcode @Sean-Tedrow-LB @shemnon were your comments addressed by the above response?

[shemnon]

I don't think my concerns about font and handwriting transcription errors were addressed. We need to consider that these auto accounts may be handed out via physical representations or stored long term in non-digital mediums.

It's probably more of a question of how the alias is stored in the record stream. If it's stored binary then the UX can pick and choose a method untied to that format.

[Sean-Tedrow-LB]

My concern is that there will be a significant portion of users who will never learn about the existence of the account ID at all. For those users the idea that you can change your key and have your "key" stay the same will be pretty baffling. It reminds me of websites I've used where your account is identified by email, but if you change your email associated with the account, your email for logging in stays the same.

There's some talk in the HIP about how this alternative account creation method will be rendered "invisible to the user", but my suspicion is that this will actually just show up as janky, seemingly buggy behavior to the user. For example, when you "create" an account, you'll be given the illusion of having an account, but you won't be able to, for example, change settings on the account until money is transferred to it, or even fetch any other info about the account at all, including its ID. But if you create an account in the "traditional" way, you can set those settings on account creation. Why? It isn't clear to the user.

I have a feeling that users will have to be aware of this process and how it works in order to have a good experience. This aliasKey is only temporarily simpler and more intuitive to a user if that user is under the false impression that Hedera accounts work like wallets in other crypto systems. If they are aware of how this system actually works, which, again, they will need to be to have a good UX in the long term, it is purely more complicated and less intuitive.

I don't see any advantage to this account creation method that can't be achieved by simply asking your friend to pay the fee to create the account for you (which is basically what this new account creation method amounts to, only in a janky way that's prone to giving users misconceptions about the system). This can already be done trustlessly, since the user executing the AccountCreateTransaction needs only the public key for the new account, not the private one.

[bugbytesinc]

@bugbytesinc @mehcode @Sean-Tedrow-LB @shemnon were your comments addressed by the above response?

Yes it brings more insight into the reasoning behind the hip., I'm still not in the endorsing-this-idea camp however, I think the mixing of models will be too complicated to explain and will lead to confusion and delay.

[lbaird]

I agree, the UX can display it in any format. It could even print it as a barcode. So the format in the transaction isn’t terribly critical. And the public key itself should contain some checksum bits. I don’t think this long format is something you’d put on your business card. You’ll usually just have your wallet software send it electronically to the exchange or the friend who is going to be helping create your account for you. As soon as it’s created, you’d put the short address on a business card, or store the short address on paper for the long term. The long format is just a way to get started on your first account.

…

On Wed, Nov 17, 2021 at 1:12 PM Danno Ferrin ***@***.***> wrote: I don't think my concerns about font and handwriting transcription errors were addressed. We need to consider that these auto accounts may be handed out via physical representations or stored long term in non-digital mediums. It's probably more of a question of how the alias is stored in the record stream. If it's stored binary then the UX can pick and choose a method untied to that format. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#187 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABDBYW7IYUMHADIEBPD7A73UMP5BTANCNFSM5HFLVMWA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[rblinton]

Opinion: This seems to add a lot of unnecessary work to avoid a $0.05 USD customer acquisition cost. Some current wallets already create a single account for new customers, gratis. If the wallet is good/useful the vendor will easily recoup the initial cost via transaction fees

[ghost]

The problem was that this was spammed heavily (which led to the 5x increase from 1c to 5c - which just drained our account creation wallet funds 5x faster). We (Coinomi) kept refunding the account creation service wallet only to see it being drained in hours, not days, again.

Note that non-custodial wallets do not get transaction fees, they go 100% to miners/validators of each network.

Coinomi has now implemented myhbarwallet-style pay2pubkey functionality (will be live in v1.25.0 android and v1.13.0 ios pretty soon).

We believe that having every wallet and exchange changing its systems to support sending to longIDs (pubkey) will make this take some time to be fully propagated through the ecosystem, and maybe end up with segregated situation (some exchanges still dont support native segwit for BTC, for eg. and might never update to longIDs, while others will).

Wouldn't it be easier to just create the short account ID immediately, but have it "inactive" until 5c is paid into it, either by account creation tx or by normal hbar transfer? Ripple - which we absolutely don't endorse in any way, far from it - does this. You get an address but its unusable until 10 XRP (was 20) is paid into it.

If that's possible, then no change would be required by any wallet or exchange, as transfers will still be done to 0.0.xxxx short account IDs as always.

[johnda98]

yes for 100% decentralized DeFi.. with no KYC, it would be nice to not have to code the DApp to subtract the creation fee from the Users account AFTER they have deposited to enact trading.. no guarantee a User will deposit to a new account.. and yes even with Captcha and maybe keeping the IP address in lookup file of a user/spoofed or not to prevent multiple Account creations to gain fractions of HBAR surplus and withdraw OR maliciously just to cost the platform, is a pain.

When is this HIP to be implemented & released ?..in the SDKs. fortunately coding delayed to now take advantage of new EVM 'variant' ;) with now payable fallback func.. so can wait for this HIP also - would be VERY useful as this HIP would remove risk of potentially high scale losses or attacks on a DApp's operating account in that fashion.

[johnda98]

Opinion: This seems to add a lot of unnecessary work to avoid a $0.05 USD customer acquisition cost. Some current wallets already create a single account for new customers, gratis. If the wallet is good/useful the vendor will easily recoup the initial cost via transaction fees

As a DApp we dont mind paying for new Account create - it dictates that either Captcha or similar ( same ip recoginition overhead process(limited scope - would force bad actor to use unique devices) ) or other malicious human thwarting attempts to drain a DApps operating account.. regardless we employ a auto-deduction of the create fee estimate as soon as a User uses their new trading account.. IF they use that account. Otherwise the commissions from the DApp usage by the Userbase wrap any costs of malicious repeat/bot attempts in summation, as a cost of doing business .ie risk.

[lbaird]

The problem being solved is that most exchanges will not create accounts for new users. If a user has no account of their own, then they allow the user to use an account at the exchange, but will not create an account for the user to own when the user withdraws the hbars. Exchanges benefit from this, because they are able to custody the tokens longer, if its harder for the user to withdraw them. The exchange finds it easy to say that account creation isn’t a service that they will offer. But it would be more difficult for an exchange to say they refuse to send you hbars you have bought when you try to do a withdrawal using a long address. It’s not a new kind of transaction. It’s simply a withdrawal. This is why there is a need for some kind of mechanism for automatic account creation.

…

On Wed, Nov 17, 2021 at 3:27 PM Richard Bair ***@***.***> wrote: I think the problem with this proposal is that it still creates friction for people from the Ethereum ecosystem, who are used to crypto transfers based on public keys instead of account IDs. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#187 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABDBYW4FF4EGYTGVNDFGD3DUMQM45ANCNFSM5HFLVMWA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[Sean-Tedrow-LB]

Oof. So you're trying to counteract... an anti-pattern? Not sure if I'm using that term correctly.

[bugbytesinc]

Its more like the alias is a workaround for not knowing the account number, which is a workaround for not creating an account beforehand and/or using 0.0.0 format which is a workaround for an important exchange/dao/wallet maker not wanting to deal with 0.0.0 format and insists on speaking only in public key addressing.

If this is the sad reality of it, the community may have no choice but to see it implemented.

[lbaird]

The question is what is meant by “create the short account ID immediately” without paying anything. If it means you create the ID locally on the user’s computer, without communicating with the Hedera ledger, then two users might create the same short account ID for two different accounts. Which wouldn’t work. If it means sending a free transaction to Hedera that reserves that account ID for future use, then all the Hedera nodes would be required to store that information in their state, for free. And an attacker could spam the network with a flood of such free transactions, causing the state to grow without bounds. That’s why the long address format is needed.

…

On Wed, Dec 1, 2021 at 9:54 PM coinomiAngelos ***@***.***> wrote: The problem was that this was spammed heavily (which led to the 5x increase from 1c to 5c - which just drained wallet's account creation wallet funds 5x faster). We (Coinomi) kept refunding the account creation service wallet only to see it being drained in hours, not days, again. Note that non-custodial wallets do *not* get transaction fees, they go 100% to miners/validators of each network. Coinomi has now implemented myhbarwallet-style pay2pubkey functionality (will be live in v1.25.0 android and v1.13.0 ios pretty soon). We believe that having every wallet and exchange changing its systems to support sending to longIDs (pubkey) will make this take some time to be fully propagated through the ecosystem, and maybe end up with segregated situation (some exchanges still dont support native segwit for BTC, for eg. and might never update to longIDs, while others will). Wouldn't be easier to just create the short account ID immediately, but have it "inactive" until 5c is paid into it, either by account creation tx or by normal hbar transfer? Ripple - which we absolutely don't endorse in any way, far from it - does this. You get an address but its unusable until 10 XRP (was 20) is paid into it. If that's possible, then no change would be required by any wallet or exchange, as transfers will still be done to 0.0.xxxx short account IDs as always. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#187 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABDBYW7UEREICIMVQUAJ663UO3UZDANCNFSM5HFLVMWA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[bugbytesinc]

The following is the implementation you are going with:

message AccountID {
    int64 shardNum = 1;
    int64 realmNum = 2;
    oneof account {
        int64 accountNum = 3;
        Key alias = 4;
    }
}

I beg you to reconsider, are you truly intending on supporting both a <shard>.<realm>.<num> version parallel to a <shard>.<realm>.<byte array> for every single API call? Does this work for senders too? Or only Receivers? Does it work for sending NFTs? Does it work for sending FT? Can it be used for sending HCS messages? What about Contracts sending funds? How will this format be supported by the ABI for contracts, let alone the interactions with the forthcoming precompiled contract HAPI integration?

Or, maybe just maybe you could create a new HAPI crypto method “PayToAlias” or “TransferToAlias” methods that provide the needed “transfer or create” functionality and sandbox this potential pandora for a while to reduce the collateral damage?

[bugbytesinc]

github ref: https://github.com/hashgraph/hedera-protobufs-java/blob/eac6fd7f85490a54579e257ff33fa12bc97a9e50/src/main/proto/basic_types.proto#L104

[bugbytesinc]

Also, I don't think Key can work for this anyway, a HAPI Key is much more than a single public ED25519 encoded key value.

[lbaird]

Yes, the type should be “bytes” rather than “Key”. And yes, it would be supported across all of HAPI. There already exists a separate transaction for creating accounts. But exchanges generally don’t support that. They only support transfers. So the intent is to allow an optional address alias, so that the transfer will create the account. Then there’s no need for an exchange to change their workflow to create a new account for a user when the user requests it. They can simply allow withdrawal transfers to any account ID that the user requests. And the user can use the long form to cause that to create the account automatically.

[johnda98]

yes, high scale benefit for low cost implement - when available in java sdk ?. it should expand eco-system as for 100% DeFi the marketplace semantics of 'Account' are misnomered - a keypairs only mindset, moreover, when 3rd party wallet signing of non-crypto xfer transactions becomes prevalent combined with working payable fallback function in new EVM 'variant' ;) & no 1mb state store limit + API from .sol to HTS.. yes now 100% 'pure' DeFi possible, coolio.

[SimiHunjan]

The HIP was updated to reflect the latest iteration of the feature

[johnda98]

whats the status of this HIP Simi ? see java sdk channel.. its in the sdk and i tried it on testnet and as Tinkerm and i found out.. a deposit from a 2rd party wallet returns INVALID_ID when a hbar xfer to a alias is executed.. and thus yes the Account cannot be created in this fashion as of yet. Pls advise - thanks.

[SimiHunjan]

hi @johnda98 . This is live on testnet/mainnet. Can you share the code that is failing?

Here is an example:https://github.com/hashgraph/hedera-sdk-java/blob/main/examples/src/main/java/AccountAliasExample.java

Docs: https://app.gitbook.com/o/-LuC734MpqlgwA6zyhAO/s/-LsUmP_7NoX2exvbv_Ps/docs/sdks/cryptocurrency/create-an-account#create-an-account-via-an-account-alias

[johnda98]

see the java sdjkdiscord channel - Tikerm (hedera engineer of good talent) also tried it and got INVALIDID exception when sending hbar to the Alias account from a 3rd party wallet.. on testnet.

the code is fine

[SimiHunjan]

If I understand that comments in the Java SDK channel correctly it looks like @tinker-michaelj mentioned you cannot use the existing account's public key as the account alias address in a transfer transaction.

An existing account does not have the aliasKey property populated. The account alias and public key of the account are two separate properties.

• The public key corresponds to the account private key
• The aliasKey property of an existing account is empty
• The aliasKey property of an existing account can be updated to be the account's public key or another public key
• If the account public key is updated the account aliasKey is not updated
• The account aliasKey cannot be updated once set

Below you can see the public key property and alias property for an existing account. A transfer transaction that points this account's public key would fail because it is not specified as the account aliasKey.

accountAccountInfo{

accountId=0.0.29533381, 

…

key=302a300506032b65700321007499179b803ee6fdcd2af42d57e9a9f21950af32ac03ff35d2f5fe21d9b65b5b, 

balance=9.76996424 ℏ, 

…

ownedNfts=0, 

maxAutomaticTokenAssociations=0, 

aliasKey= , 

ledgerId=30783033
	
}

When you create a new account, you generate either an ECDSA or ED25519 key type and use the public key as the account aliasKey address. When the new account is created through this method, the account takes the alias public key as the account's public key to create the new account. In this scenario, the account has a public key and aliasKey that match and the aliasKey can be used in transfer transactions.

You can use the account aliasKey in transfer transactions, get account info and get account balance queries today (live on testnet/mainnet).

To enable this feature for all other transactions and queries including account updates to add the aliasKey to an existing account you can follow this issue and associated release milestone hashgraph/hedera-services#2691.

Does this help clarify your question?

[johnda98]

well, it syncs with what i already comprehend, which is good.

Soooooo... hmm.. give me a code example of you creating a Alias key and then show me what you would enter into a 3rd party wallet, so you can fund the new Account and then, yes the new AccountID and the Alias will then
exist.. which I understand , yes, i can get that via AccountInfo object. thanks in advance.

[johnda98]

??

[johnda98]

well, it syncs with what i already comprehend, which is good. Soooooo... hmm.. give me a code example of you creating a Alias key and then show me what you would enter into a 3rd party wallet, so you can fund the new Account and then, yes the new AccountID and the Alias will then exist.. which I understand , yes, i can get that via AccountInfo object. thanks in advance. *John D Allen.* *T +1 417 300 4812 ** CST | ***@***.*** ***@***.***> | https://www.leveridgesystems.com <https://www.leveridgesystems.com> | linkedin.com/in/johndallen1 <http://linkedin.com/in/johndallen1> | skype john.allen_67 * Leveridge Systems INC. Reg Missouri Charter #01082460. The information contained in this email and any attached files is confidential and intended solely for the addressee(s). The email may be legally privileged or prohibited from disclosure and unauthorized use. If you are not the named addressee you may not use, copy, or disclose this information to any other person. If you received this message in error please notify the sender immediately and permanently delete it from your system.

…

On Tue, Mar 15, 2022 at 9:25 PM SimiHunjan ***@***.***> wrote: If I understand that comments in the Java SDK channel correctly it looks like @tinker-michaelj <https://github.com/tinker-michaelj> mentioned you cannot use the existing account's public key as the account alias address in a transfer transaction. An existing account does not have the aliasKey property populated. The account alias and public key of the account are two separate properties. - The public key corresponds to the account private key - The aliasKey property of an existing account is empty - The aliasKey property of an existing account can be updated to be the account's public key or another public key - If the account public key is updated the account aliasKey is not updated - The account aliasKey cannot be updated once set Below you can see the public key property and alias property for an existing account. A transfer transaction that points this account's public key would fail because it is not specified as the account aliasKey. accountAccountInfo{ accountId=0.0.29533381, … key=302a300506032b65700321007499179b803ee6fdcd2af42d57e9a9f21950af32ac03ff35d2f5fe21d9b65b5b, balance=9.76996424 ℏ, … ownedNfts=0, maxAutomaticTokenAssociations=0, aliasKey= , ledgerId=30783033 } When you create a new account, you generate either an ECDSA or ED25519 key type and use the public key as the account aliasKey address. When the new account is created through this method, the account takes the alias public key as the account's public key to create the new account. In this scenario, the account has a public key and aliasKey that match and the aliasKey can be used in transfer transactions. You can use the account aliasKey in transfer transactions, get account info and get account balance queries today (live on testnet/mainnet). To enable this feature for all other transactions and queries including account updates to add the aliasKey to an existing account you can follow this issue and associated release milestone hashgraph/hedera-services#2691 <hashgraph/hedera-services#2691>. Does this help clarify your question? — Reply to this email directly, view it on GitHub <#187 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADGDUXNEJN33Q4YWEFYWZBLVAFBBZANCNFSM5HFLVMWA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: <hashgraph/hedera-improvement-proposal/repo-discussions/187/comments/2369311 @github.com>

[SimiHunjan]

sorry for the delay in response. Here is an example here on how to create an account from an account alias: https://github.com/hashgraph/hedera-sdk-java/blob/main/examples/src/main/java/AccountAliasExample.java.

(1) Generate a public key as the accountAlias (302a300506032b6570032100902db155d943ed89cd7a9d632e83be55291a7ac92729bb33867162607eff9d1d
(2) Convert it a Hedera account representation 0.0.accountAlias (0.0.302a300506032b6570032100902db155d943ed89cd7a9d632e83be55291a7ac92729bb33867162607eff9d1d)
(3) Use the transfer transaction to transfer to the 0.0.accountAlias address from an existing account
(4) After a successful transfer you will create the account on Hedera and have a 0.0.accountNumber as the accountId plus the aliasKey 302a300506032b6570032100902db155d943ed89cd7a9d632e83be55291a7ac92729bb33867162607eff9d1d

Does that help?

[johnda98]

sdk is fine.. for a crypto transfer to Alias.. but looks like Hashpack doesnt permit it yet.. wallet user cant type it in so has to be scannable as QR.. or i guess burden user with copy paste the alias over to wallet

just catching up with this - as new DApp for droid will try to use to create new customer accounts - saves platform spending a hbar to acquire what could be 100Ks of new users that dont do anything with their new accounts - risk to DApp

[johnda98]

https://discord.com/channels/888550498133766204/1014543880730980453/1062748151494230077