[PULL] add parameter [from] to listtransactions (JSON-RPC)

[CAFxX]

I wrote a patch (already on github) that adds the [from=0] parameter to the listtransaction rpc command. Right now this command returns the most recent transactions in the range [0, count). With my patch it returns the most recent transactions in the range [from, from+count). Since from defaults to 0 if it is not supplied, this change should be backward compatible.
The rationale for the change is that in this way a frontend/UI doesn't have to store locally the whole list of transactions, but can query directly the range that needs to be displayed.

Pull request: https://github.com/bitcoin/bitcoin/pull/160

[1713930762]

1713930762

[CAFxX]

bump   

[xf2_org]

1) This breaks the API, which makes it unlikely to be accepted as-is.

2) It is such a small amount of information, I do not see the difficulty in querying up to max-count.

[CAFxX]

1) This breaks the API, which makes it unlikely to be accepted as-is.

No it doesn't. Existing queries will keep on working (as explained in the first post).

2) It is such a small amount of information, I do not see the difficulty in querying up to max-count.

As it is today if i have thousands of transactions and want to view the oldest one I have to get (and store) all the transactions. Think what might happen if my wallet wasn't stored locally... it would mean getting MBs (potentially over slow connections) every single time!

[xf2_org]

1) This breaks the API, which makes it unlikely to be accepted as-is.

No it doesn't. Existing queries will keep on working (as explained in the first post).

It is not 100% backwards compatible.

2) It is such a small amount of information, I do not see the difficulty in querying up to max-count.

As it is today if i have thousands of transactions and want to view the oldest one I have to get (and store) all the transactions. Think what might happen if my wallet wasn't stored locally... it would mean getting MBs (potentially over slow connections) every single time!
[/quote]

Even with thousands of transactions, that is not many bytes, certainly not "MBs."

[CAFxX]

1) This breaks the API, which makes it unlikely to be accepted as-is.

No it doesn't. Existing queries will keep on working (as explained in the first post).

It is not 100% backwards compatible.

The only case this could "break compatibility" is if someone had been passing a third numeric parameter to listtransactions. Sorry to say but avoiding breaking API misuse doesn't count as backwards compatibility.

2) It is such a small amount of information, I do not see the difficulty in querying up to max-count.

As it is today if i have thousands of transactions and want to view the oldest one I have to get (and store) all the transactions. Think what might happen if my wallet wasn't stored locally... it would mean getting MBs (potentially over slow connections) every single time!

Even with thousands of transactions, that is not many bytes, certainly not "MBs."

From what I can see in the source code in rpc.cpp each transaction is likely using more than 100 bytes. Let's assume conservatively it's just 100 bytes: then it would be 1MB per 10k transactions.

[CAFxX]

From what I can see in the source code in rpc.cpp each transaction is likely using more than 100 bytes. Let's assume conservatively it's just 100 bytes: then it would be 1MB per 10k transactions.

Better yet: this page shows example listtransactions outputs. They're about 250 bytes long (this figure excludes the comments). This means 1MB roughly every 4000 transactions. This figure is way lower if comments are included in transactions. So, as I said, "MBs".

[Gavin Andresen]

It always bothered me that the MySQL's SELECT... LIMIT statement could skip records if the database was changing between calls, but that doesn't seem to bother anybody else.

This patch is very much like MySQL LIMIT, is needed for the same reason (paging through results efficiently in a GUI), is backwards compatible, and looks good to me.

[xf2_org]

I stand corrected -- no backwards compat issues.