Development Assistance - Wallet Creation / Node setup / Tx's

Hello,

I’m looking into understanding the concepts for Helium in depth. I have access to the API endpoints you list in the Postman page, but would like a little more information on the general and technical concept behind wallets and transactions.

I have some specific questions that will probably bring even more questions. But to start:

I see transactions can be one of 20 different types. So far I have seen a lot of “poc_challengees_reward” “poc_witnesses_reward”. Do you know of a wallet that has many transaction types, specifically more about transferring HNT to a different wallet or similar?

In the endpoint reference it just describes creating a transaction as sending a txn parameter with the txn encoded in base64. What is this txn data we are supposed to send? Does it depend on the transaction type? Is there a basic skeleton? Also, for transactions, is there a way to estimate a fee before sending the transaction? Or at least to calculate it based on the fee of recent transactions?

I can’t seem to be able to wrap my head around the wallet creation process. Any more details on this would be helpful. I have been looking at the code for the rust implementation in Github and the documentation in the repo, but I am still lost there.

Any help on all this is greatly appreciated. Thank you!

1 Like

Have been working on the current structure and have a new question:

I was able to map how the ‘payment’ type transactions look like. I still don’t know how the txn body looks like. Is there also a way of knowing in which block is the transaction recorded in? Like a height property, block hash or something like that?

I’m sure you already know this so this is for others finding this post: The blockchain has blocks with these kinds of transactions in it. Wallets don’t have transactions, they’re just public/private key pairs that are used to sign transactions.

The typical transactions a wallet can be referenced in are any of the transactions that involve it as a owner, account, payer or payee. Those transactions include payment, add_gateway, assert_location, rewards. This list will grow, so the full list is best checked at the protobuf source

Each transaction is described by a protobuf file. So, for example for payments there’s a blockchain_txn_payment_v1.proto. Each transaction is wrapped in a top level blockchain_txn.proto.

Each transaction is signed with the private key of the wallet that is paying the fees for the transaction. You sign the transaction by creating the base txn with an empty signature field, signing that and then inserting the signature in the record. Here’s an example of how to do this in Erlang and another on how to do this in Rust

Maybe ask some more specific questions here?

Basically a wallet is a public private key pair. The long string we see in the app or dashboard is the base58-check encoded version of the public key. The check-encoding includes a coding version, checksum and the type of encoded key. The Helium blockchain supports both ED25519 and NIST-P256 keys but current wallets use ED25519 keys since there is code in most frameworks to support it.

1 Like

I hope the previous reply helps a bit with the body of the transaction?

The block height can not be known in advance since the consensus group members will include the transaction in a future block. Since technically a single wallet could have multiple payments active there is a nonce in the payment transaction. This orders the transactions and helps avoid reply attacks. The current nonce can be retrieved from the API.

In the current API, when you construct (and sign) a payment transaction you have to “guess” what the next nonce is going to be based on the nonce in the account data. This I usually pretty safe but may require retries with additional nonces if there are a lot of payment from the same account going through different ingestion points.

This is complicated, I know… we’ll have helper services available that you can host like blockchain-etl to follow and query the chain, as well as submit new transactions.

1 Like