Bitcoin Forum
December 10, 2016, 05:26:06 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: [PULL] add parameter [from] to listtransactions (JSON-RPC)  (Read 1369 times)
CAFxX
Jr. Member
*
Offline Offline

Activity: 30


View Profile WWW
April 15, 2011, 05:34:05 PM
 #1

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

1Pes7NpYkvYojYutZgJJ2NpChRxhmburfo
1481347566
Hero Member
*
Offline Offline

Posts: 1481347566

View Profile Personal Message (Offline)

Ignore
1481347566
Reply with quote  #2

1481347566
Report to moderator
1481347566
Hero Member
*
Offline Offline

Posts: 1481347566

View Profile Personal Message (Offline)

Ignore
1481347566
Reply with quote  #2

1481347566
Report to moderator
1481347566
Hero Member
*
Offline Offline

Posts: 1481347566

View Profile Personal Message (Offline)

Ignore
1481347566
Reply with quote  #2

1481347566
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481347566
Hero Member
*
Offline Offline

Posts: 1481347566

View Profile Personal Message (Offline)

Ignore
1481347566
Reply with quote  #2

1481347566
Report to moderator
CAFxX
Jr. Member
*
Offline Offline

Activity: 30


View Profile WWW
April 16, 2011, 02:53:05 PM
 #2

bump   Undecided

1Pes7NpYkvYojYutZgJJ2NpChRxhmburfo
xf2_org
Member
**
Offline Offline

Activity: 70


View Profile
April 16, 2011, 04:39:33 PM
 #3


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
Jr. Member
*
Offline Offline

Activity: 30


View Profile WWW
April 16, 2011, 04:45:05 PM
 #4

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).

Quote
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!

1Pes7NpYkvYojYutZgJJ2NpChRxhmburfo
xf2_org
Member
**
Offline Offline

Activity: 70


View Profile
April 16, 2011, 04:57:35 PM
 #5

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.

Quote
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
Jr. Member
*
Offline Offline

Activity: 30


View Profile WWW
April 16, 2011, 05:25:03 PM
 #6

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.

Quote
Quote
Quote
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.

1Pes7NpYkvYojYutZgJJ2NpChRxhmburfo
CAFxX
Jr. Member
*
Offline Offline

Activity: 30


View Profile WWW
April 16, 2011, 05:35:34 PM
 #7

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".

1Pes7NpYkvYojYutZgJJ2NpChRxhmburfo
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
April 17, 2011, 02:09:14 PM
 #8

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.


How often do you get the chance to work on a potentially world-changing project?
xf2_org
Member
**
Offline Offline

Activity: 70


View Profile
April 18, 2011, 08:05:13 PM
 #9

I stand corrected -- no backwards compat issues.
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!