#Pending transactions

17 messages · Page 1 of 1 (latest)

coarse ermine
#

How can I get inner transactions of pending transactions? When I retrieve pending transactions using client.PendingTransactions() there is no transaction id so I cannot call client.PendingTransactionInformation(txnId)

stark kiteBOT
#

Hi @coarse ermine. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:

#

To get inner transactions of pending transactions in Algorand, you need to understand how pending transactions work and how to access their information.

When you call pendingTransactionsInformation() (or PendingTransactions() in some SDKs), you get a list of pending transactions in the pool. While this method doesn't directly provide transaction IDs, each transaction in the response should contain the transaction object itself, which you can use to derive the transaction ID.

Once you have the transaction ID, you can call pendingTransactionInformation(txid) to get detailed information about a specific pending transaction, including any inner transactions:

// First get pending transactions
const pendingTxns = await algodClient.pendingTransactionsInformation().do();

// For each transaction in the top-transactions array
for (const tx of pendingTxns.topTransactions) {
    // Get the transaction ID (you may need to compute this from the transaction)
    const txid = /* compute or extract txid from tx */;
    
    // Get detailed information including inner transactions
    const txInfo = await algodClient.pendingTransactionInformation(txid).do();
    
    // Access inner transactions if they exist
    if (txInfo.innerTxns) {
        console.log(txInfo.innerTxns);
    }
}

According to the documentation, the PendingTransactionResponse object includes an inner-txns field which contains "Inner transactions produced by application execution" PendingTransactionResponse.

When you call pendingTransactionInformation(txid), the response will include inner transactions in the innerTxns property if they exist PendingTransactionResponse.

#

Note that to see all pending transactions in the network (not just those submitted to your node), you may need to configure your node with ForceFetchTransactions set to True in the algod configuration settings Technical FAQ.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@coarse ermine Kapa.ai is still learning and improving, please let me know how I did by reacting below.

coarse ermine
#

@stark kite Using go-algorand sdk, how do I calculate transaction id from SignedTransaction?

stark kiteBOT
#

Let me check the knowledge base for you again. One moment! :books:

#

To calculate a transaction ID from a SignedTransaction using the Go Algorand SDK, you can use the crypto.SignTransaction function which returns the transaction ID along with the signed transaction.

When you sign a transaction using the Go SDK, the function returns three values: the transaction ID, the signed transaction, and any error:

txid, stx, err := crypto.SignTransaction(acct.PrivateKey, txn)
if err != nil {
    fmt.Printf("Failed to sign transaction: %s\n", err)
    return
}

As shown in the example above, the txid variable contains the transaction ID of the signed transaction. This is the most direct way to get the transaction ID when signing a transaction.

This pattern is consistently used across various transaction types in the Go SDK, as seen in these examples:

If you already have a signed transaction and need to get its ID, you can use the transaction ID returned when you signed it, or when you submit it to the network:

pendingTxID, err := algodClient.SendRawTransaction(stxn).Do(context.Background())

The transaction ID is a deterministic hash of the transaction data, so it will be the same whether you calculate it at signing time or when submitting the transaction.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@coarse ermine Kapa.ai is still learning and improving, please let me know how I did by reacting below.

coarse ermine
#

@stark kite I need to calculate the transaction ID from a Transaction that has already been sent and I do not have its ID

stark kiteBOT
#

Let me check the knowledge base for you again. One moment! :books:

#

Based on the knowledge sources provided, there isn't a direct method shown for calculating a transaction ID from a transaction that has already been sent when you don't have its ID.

When using the Algorand SDKs, the transaction ID is typically returned when:

  1. Signing a transaction:
txid, stx, err := crypto.SignTransaction(acct.PrivateKey, txn)
  1. Sending a transaction to the network:
pendingTxID, err := algodClient.SendRawTransaction(stxn).Do(context.Background())

If you've already sent the transaction but didn't store the transaction ID, you have a few options:

  1. If you have the transaction object or signed transaction bytes, you might be able to recalculate the ID (though the specific method isn't shown in the provided knowledge sources).

  2. If the transaction has been confirmed, you could query the Algorand blockchain using an explorer like Lora or Pera Explorer with other identifying information about your transaction (like sender address, time period, amount, etc.) to locate it.

  3. You could also use the Indexer API to search for transactions with specific parameters that match your transaction.

Unfortunately, the provided knowledge sources don't contain specific information about retroactively calculating a transaction ID from a transaction that has already been sent without having its ID. This would require additional information about how transaction IDs are calculated in Algorand.

I'd recommend storing the transaction ID when signing or sending transactions in the future, as shown in the code examples from the knowledge sources.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@coarse ermine Kapa.ai is still learning and improving, please let me know how I did by reacting below.

coarse ermine
#

@stark kite what does the "GossipFanout" is in node config? Is it connected to "PriorityPeers" in any way?

stark kiteBOT
#

Let me check the knowledge base for you again. One moment! :books:

#

Based on the knowledge sources provided, I can explain what GossipFanout is in Algorand node configuration and its relationship to PriorityPeers.

GossipFanout

GossipFanout is a configuration parameter that sets the maximum number of peers the node will connect to with outgoing connections. According to the documentation:

"GossipFanout sets the maximum number of peers the node will connect to with outgoing connections. If the list of peers is less than this setting, fewer connections will be made. The node will not connect to the same peer multiple times (with outgoing connections)."

The default value for GossipFanout is 4, meaning that by default, an Algorand node will establish outgoing connections to a maximum of 4 peers Nodes > Reference.

PriorityPeers

PriorityPeers is a separate configuration parameter that:

"PriorityPeers specifies peer IP addresses that should always get outgoing broadcast messages from this node."

This setting has no default value specified in the documentation Nodes > Reference.

Relationship Between GossipFanout and PriorityPeers

While the documentation doesn't explicitly state a direct relationship between GossipFanout and PriorityPeers, they are related in how they affect the node's network communication:

  1. GossipFanout controls the maximum number of outgoing connections your node will establish.

  2. PriorityPeers specifies which peers should always receive broadcast messages from your node.

The relationship appears to be that PriorityPeers would be a subset of the peers your node connects to (as determined by GossipFanout), ensuring that specific peers always receive your broadcast messages.

#

This is further supported by the BroadcastConnectionsLimit parameter, which specifies:

"BroadcastConnectionsLimit specifies the number of connections that will receive broadcast (gossip) messages from this node. If the node has more connections than this number, it will send broadcasts to the top connections by priority (outgoing connections first, then by money held by peers based on their participation key)."

This indicates that outgoing connections (controlled by GossipFanout) have priority for broadcasts, and PriorityPeers would be specifically designated to always receive these broadcasts.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: