Update documentation with secure examples

[nkavian]

Problem

When reading this documentation, it causally uses PrivateKeys as if that's what's required.

For example, I've already had to explain to my team they can't copy and paste that example verbatim, and they need to use public keys.

Solution

First, the documentation should explicitly have a comment to tell developers that they should not have the privateKeys themselves, and this example is just for illustrative purposes to create and and use publicKeys.

Second, right after creating the privateKeys, create the publicKeys explicitly and show people they can use the publicKeys to create a threshold wallet.

Lastly, please help close this discussion (if it's untrue) or dramatically update your GitHub and GitBook (this and this) documentation (if it's true). That discussion creates some really frustrating stress if it's true.

Alternatives

No response

[mehcode]

I do agree that we should make it explicitly use a list of public keys when making the account with a threshold key.

cc @Sean-Tedrow-LB

---

I must admit I don't understand the reference to the documentation in your "lastly,..." comment there.

Currently a user can take a generated keypair and share the public key with another user who can create an account on their behalf, most importantly, without having to have access to the corresponding secret key. Unfortunately, it is not possible to set up an account using a threshold or multisig key as the current SDKs require you to provide a valid signature for the key (i.e. a 3/5 threshold key requires 3 signatures, 2/2 multisig requires both signatures).

This is true. And the linked documentation and example seems to reflect that truth from what I'm reading.

What specific part of this are you hoping is false so we could help you work through that use case?

---

I converted your issue to a discussion as its not directly a bug or feature request.

[Sean-Tedrow-LB]

execute(client) will implicitly freeze the transaction and sign it with the client's operator if the transaction is not already frozen and signed.

[mehcode]

@nkavian, @Sean-Tedrow-LB is correct.

The setOperator invocation (used by all the examples) adds an implicit signatory. Note that there is a setOperatorWith method that can be used to load secrets on-demand and not keep them in memory.

TransactionResponse transactionResponse = new AccountCreateTransaction()
    .setKey(transactionKey)
    .setInitialBalance(new Hbar(10))
    .freezeWith(client) // implicit in execute(client)
    .sign(operatorPrivateKey) // implicit in execute(client)
    .execute(client);

Maybe that will make it more clear.

The automatic signature here is for payment of the transaction fees only. It's not intended to be for any other purpose.

Note that I don't believe you need any kind of signature to create an account, even if its a threshold key. The examples do seem to indicate you do but the documentation says otherwise. I'll circle back after testing it internally.

[nkavian]

Thanks @mehcode for commenting that just an operator is sufficient. Will wait for final confirmation after your test.

[janaakhterov]

Just ran the modified create-account example as

    const key1 = PrivateKey.generate();
    const key2 = PrivateKey.generate();

    const list = new KeyList([
        key1.publicKey,
        key2.publicKey,
    ], 1);

    const response = await new AccountCreateTransaction()
        .setInitialBalance(new Hbar(10)) // 10 h
        .setKey(list)
        .execute(client);

    const receipt = await response.getReceipt(client);

    console.log(`account id = ${receipt.accountId}`);

And got the output of

account id = 0.0.2084150-druqc

Can confirm you can create an account without signing the transaction with any of the keys in the list.

[nkavian]

Thank you! I've left a comment in the other discussion so that others don't become confused as I did.

hashgraph/hedera-improvement-proposal#77