Bitcoin Forum
December 09, 2016, 02:05:46 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Poll
Question: Should these details be added?
No - 1 (33.3%)
Yes - 2 (66.7%)
Total Voters: 3

Pages: [1]
  Print  
Author Topic: Adding more details to JSON-RPC method output  (Read 877 times)
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
October 05, 2011, 04:08:42 PM
 #1

Link to pull request

These changes are 100% backward compatible.

Adds to "getinfo" output: "pooledtx" (number of transactions in memory pool), "currentblocktx" (number of txns in the last block created), and "currentblocksize"

Adds to "listtransactions" and similar output: "block_hash" and "block_index"

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

Posts: 1481249146

View Profile Personal Message (Offline)

Ignore
1481249146
Reply with quote  #2

1481249146
Report to moderator
1481249146
Hero Member
*
Offline Offline

Posts: 1481249146

View Profile Personal Message (Offline)

Ignore
1481249146
Reply with quote  #2

1481249146
Report to moderator
1481249146
Hero Member
*
Offline Offline

Posts: 1481249146

View Profile Personal Message (Offline)

Ignore
1481249146
Reply with quote  #2

1481249146
Report to moderator
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
October 30, 2011, 11:43:42 PM
 #2

Bump.

John Tobey
Hero Member
*****
Offline Offline

Activity: 481



View Profile WWW
October 31, 2011, 03:37:00 AM
 #3

Luke-Jr, thanks for the patch.

Assuming it is bug free (which I'm not sure... does it mutex the reads of shared data like nPooledTx?) my concern is code bloat for a feature with a dozen(?) potential users.  Not to say the code base isn't currently bloated, Grin but now seems a good time to mention refactoring options.

Imagine compile-time options similar to -DUSE_UPNP and -DGUI controlling inclusion of esoteric features.  (I note that optional features should in no way affect the validation rules, since we want everyone to agree on those.)  Luke's features, and probably over half the existing RPC cruft, could go in a separate file, ideally behind a module interface such as VinceD's hooks.  Imagine "extensions.cpp" defining CExtension extensions[], each element's existence controlled by an #ifdef, and each CExtension implementing a bunch of hooks, one of which the RPC table constructor would call and allow to insert methods.

Anyone?

Can a change to the best-chain criteria protect against 51% to 90+% attacks without a hard fork?
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
October 31, 2011, 03:52:10 AM
 #4

This shouldn't add any overhead, and I'm assuming mere integer read/set doesn't need a mutex to be safe-- you either see the value before or after the change.

John Tobey
Hero Member
*****
Offline Offline

Activity: 481



View Profile WWW
October 31, 2011, 04:12:18 AM
 #5

This shouldn't add any overhead
Oh, the runtime CPU and memory cost would be tiny, I'm sure.  But now, as a code reader, I must scan past three new globals to see the meatier parts such as pindexBest right above them.  It's not that I don't like the feature, or even (maybe) enabling it by default, but adding things in this way gradually makes the program harder to understand.

I'm assuming mere integer read/set doesn't need a mutex to be safe-- you either see the value before or after the change.
Even for uint64 on 32-bit systems?  And what if parts of the same getinfo result reflect changes that other parts don't reflect?

Can a change to the best-chain criteria protect against 51% to 90+% attacks without a hard fork?
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!