EarmarkedLibraCoin module and the a account

Consider this situation: Bob is going to create an account at address a at some point in the future.

Got lost there. How is it possible for Alice to know and define inside the module a future address that, i suppose, will be assigned randomly at creation ? Or is this a hint for nominal addresses a la DNS/ ENS ?

  // A wrapper containing a Libra coin and the address of the recipient the
  // coin is earmarked for.
  resource T {
    coin: R#LibraCoin.T,
    recipient: address

src : https://developers.libra.org/docs/move-overview

Cheers !

@sam @phoenix calling team members ! :cowboy_hat_face:

The protocol for creating a Libra blockchain address that you will be able to send transactions from is:

  • Generate a new keypair with private key K_s and public key K_v.
  • The corresponding address A for this keypair is sha3(K_v).
  • From an existing account, send a transaction that calls create_account(A).
  • You will now be able to send transactions from A by signing with K_s
  • Additionally, you can rotate the signing key for A using the scheme described in Key rotation.

In general, you can call create_account() for any address A’ that does not already contain an account. But you won’t be able to send transactions from A’ if you do not know the corresponding signing key.

Finally, getting back to the Earmarked example: the idea is that Bob can send A to Alice, yet be sure that he can spend from it in the future because he has followed the protocol above to generate A.


ok its clearer now , thanks @sam

But how will

Alice can send A to Bob,


Will she just send the keypair by e2e text message like whatsapp ?

Any ordinary communication channel should work just fine for this–A isn’t a secret.

A is not, but K_s is . Bob will need the original K_s in order to apply a key rotation on A later on i suppose, is that correct ?

edit: After some thought (and reading Key rotation post), i understand that i’m doing a direct one-to-one relationship between "knowing K_s" <> ownership of the account (as in non exchanges wallets in ETH/BTC networks). Maybe there is something missing in my rationale regarding libra network

I actually believe @sam got Alice and Bob reversed in his explanation. Since Alice sends libra to address A that Bob will later create, I think Sam meant ‘the idea is that BOB can send A to ALICE, yet be sure that HE can spend from it in the future because HE has followed the protocol above to generate A’


You are right; thanks for noticing this! I will correct my explanation above.

1 Like