listtransactions in stable order? | Bitcointalksearch.org

theymos

administrator

Activity: 5222

Merit: 13032

I believe listtransactions is always stable unless you manually mess with your wallet.dat or use -zapwallettxes.

Quote from: deepceleron on October 02, 2014, 08:02:59 AM

Reviewing the code, there is no sorting or post-processing in the listtransactions function (rpcwallet.cpp ~line 1200).

No, it is ordered. The listtransactions function gets transactions like this:

Code:

CWallet::TxItems txOrdered = pwalletMain->OrderedTxItems(acentries, strAccount);

OrderedTxItems returns a list of all wallet transactions for account strAccount ordered by the transaction's nOrderPos. nOrderPos is set in a way that ensures that all newly-seen transactions are listed later than ones seen earlier, even if the transaction seen later probably came earlier chronologically. I'm not 100% sure that this rule is followed when rescanning, but I think so.

Note that listtransactions internally loops through every wallet transaction each time you call it to ensure the correct ordering, even if you use an offset. This might make it slow for large wallets.

notme

legendary

Activity: 1904

Merit: 1002

Thanks, that was helpful. I had one thing a little backwards. The offset is how far away from current you are looking rather than how far from the first transaction. So I believe I just need to walk from 0 forward until I see a transaction I already know.

deepceleron

legendary

Activity: 1512

Merit: 1036

Quote from: bitcoind help listtransactions

listtransactions ( "account" count from )

Returns up to 'count' most recent transactions skipping the first 'from' transactions for account 'account'.

Arguments:
1. "account" (string, optional) The account name. If not included, it will list all transactions for all accounts.
   If "" is set, it will list transactions for the default account.
2. count (numeric, optional, default=10) The number of transactions to return
3. from (numeric, optional, default=0) The number of transactions to skip

Result:
[
  {
   "account":"accountname", (string) The account name associated with the transaction.
   It will be "" for the default account.
   "address":"bitcoinaddress", (string) The bitcoin address of the transaction. Not present for
   move transactions (category = move).
   "category":"send|receive|move", (string) The transaction category. 'move' is a local (off blockchain)
   transaction between accounts, and not associated with an address,
   transaction id or block. 'send' and 'receive' transactions are
   associated with an address, transaction id and block details
   "amount": x.xxx, (numeric) The amount in btc. This is negative for the 'send' category, and for the
   'move' category for moves outbound. It is positive for the 'receive' category,
   and for the 'move' category for inbound funds.
   "fee": x.xxx, (numeric) The amount of the fee in btc. This is negative and only available for the
   'send' category of transactions.
   "confirmations": n, (numeric) The number of confirmations for the transaction. Available for 'send' and
   'receive' category of transactions.
   "blockhash": "hashvalue", (string) The block hash containing the transaction. Available for 'send' and 'receive'
   category of transactions.
   "blockindex": n, (numeric) The block index containing the transaction. Available for 'send' and 'receive'
   category of transactions.
   "txid": "transactionid", (string) The transaction id. Available for 'send' and 'receive' category of transactions.
   "time": xxx, (numeric) The transaction time in seconds since epoch (midnight Jan 1 1970 GMT).
   "timereceived": xxx, (numeric) The time received in seconds since epoch (midnight Jan 1 1970 GMT). Available
   for 'send' and 'receive' category of transactions.
   "comment": "...", (string) If a comment is associated with the transaction.
   "otheraccount": "accountname", (string) For the 'move' category of transactions, the account the funds came
   from (for receiving funds, positive amounts), or went to (for sending funds,
   negative amounts).
  }
]

Examples:

List the most recent 10 transactions in the systems
> bitcoin-cli listtransactions

List the most recent 10 transactions for the tabby account
> bitcoin-cli listtransactions "tabby"

List transactions 100 to 120 from the tabby account
> bitcoin-cli listtransactions "tabby" 20 100

As a json rpc call
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "listtransactions", "params": ["tabby", 20, 100] }' -H 'content-type: text
/plain;' http://127.0.0.1:8332/

The transaction list comes out of the wallet. It is your own record of the order transactions happened and is the order that transactions were added to the wallet database. It follows that it would return data in the order it appears or was added to the wallet.

BTW, notable in use of the command is that specifying no parameters will show the most recent 10 transactions for all accounts. Undocumented is that if you want to count and skip parameter, you cannot omit the (account) parameter - to show all accounts you use "*" (asterisk) as the indicator for "all accounts".

This could be tested. In a blank wallet, import a privkey that has recent payments and let it reindex. Then import a privkey that received payments in earlier blocks and reindex. I would expect the result of the RPC command to not be in chronological order after importing keys with prior payments.

Reviewing the code, there is no sorting or post-processing in the listtransactions function (rpcwallet.cpp ~line 1200). If correct chronological order is mandatory, I would recommend getting all transactions and sorting yourself based on time value (or blocktime or timereceived specifically for generates or incoming transactions). This still may have issues as block timestamps could be out-of-order.

notme

legendary

Activity: 1904

Merit: 1002

The listtransactions API call allows you to specify an offset of how many transactions are skipped. My question is this: is the ordering of this list stable such that you can simply track how many transactions you've already recorded and rely on a new call to give you any new information. Specifically, if I import a private key that has a transaction that happened well in the past, will that transaction show up on my next listtransactions call, or will it be buried underneath causing my call to return a transaction I've already seen previously?

Topic: listtransactions in stable order? (Read 1229 times)