Bitcoin Forum
May 09, 2024, 02:54:03 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: CLI bitcoin generation  (Read 11412 times)
molybdenum (OP)
Newbie
*
Offline Offline

Activity: 7
Merit: 0


View Profile
May 22, 2010, 06:44:20 PM
 #1

So I'm poking around creating a simple web interface for simple bitcoin usage (something a little lighter and less stateful than a full-on wx/GTK GUI) and I haven't seen any way to see the status of generated blocks in progress of verification... I have seen my balance jump up by 50, but of course that doesn't show up in getallreceived.

For a headless coin generation box, being able to see my status right away would be nice, or at least, being able to know if I have 30 blocks awaiting confirmation, or am still trying to get the first... if it's purely automated and just checking-and-forwarding the balance, that's not a problem though.

Additionally, in the GUI client a transaction will appear as soon as it's seen, while getallreceived only shows a transaction after a block has gone by... yet the balance jumps up by the appropriate amount right away.

I can imagine some poor nervous customer pacing back and forth worrying about his payment going through, when that wouldn't really be needed. While this *could* be used to cheat the system if a malicious machine managed to generate the winning block and exclude its own payment, but some instant indication that something was happening would be nice none the less even if it needed a "don't accept transactions while the confirmations are still at 0" warning tag... perhaps a separate function that included 0-confirmation transactions? An optional parameter to specify the minimum number of blocks after that transaction (getallreceived 1 for current behavior, or just getallreceived, getallreceived 5 for the paranoid, getallreceived 0 for instant confirms)?
1715266443
Hero Member
*
Offline Offline

Posts: 1715266443

View Profile Personal Message (Offline)

Ignore
1715266443
Reply with quote  #2

1715266443
Report to moderator
1715266443
Hero Member
*
Offline Offline

Posts: 1715266443

View Profile Personal Message (Offline)

Ignore
1715266443
Reply with quote  #2

1715266443
Report to moderator
1715266443
Hero Member
*
Offline Offline

Posts: 1715266443

View Profile Personal Message (Offline)

Ignore
1715266443
Reply with quote  #2

1715266443
Report to moderator
The network tries to produce one block per 10 minutes. It does this by automatically adjusting how difficult it is to produce blocks.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1715266443
Hero Member
*
Offline Offline

Posts: 1715266443

View Profile Personal Message (Offline)

Ignore
1715266443
Reply with quote  #2

1715266443
Report to moderator
1715266443
Hero Member
*
Offline Offline

Posts: 1715266443

View Profile Personal Message (Offline)

Ignore
1715266443
Reply with quote  #2

1715266443
Report to moderator
satoshi
Founder
Sr. Member
*
qt
Offline Offline

Activity: 364
Merit: 6723


View Profile
May 26, 2010, 08:09:34 PM
 #2

An optional parameter to specify the minimum number of blocks after that transaction (getallreceived 1 for current behavior, or just getallreceived, getallreceived 5 for the paranoid, getallreceived 0 for instant confirms)?
Yeah, that actually is what it is.  getallreceived 0 should do what you want.  (now it's renamed to listreceivedbyaddress 0)  The default is 1 confirmation, but I think in reality most digital goods and services can be 0 confirmations.  Like you say, if you need more than 0 confirmations, you could show two numbers, unconfirmed and available balance, so they immediately see their transaction went through.

listreceivedbyaddress [minconf=1] [includeempty=false]
[minconf] is the minimum number of confirmations before payments are included.
[includeempty] whether to include addresses that haven't received any payments.
Returns an array of objects containing:
  "address" : receiving address
  "label" : the label of the receiving address
  "amount" : total amount received by the address
  "confirmations" : number of confirmations of the most recent transaction included

or listreceivedbylabel if you're labelling addresses with their username.

So far I've concentrated on functions for web merchants, not so much on stuff for remote management of headless coin generators yet.
molybdenum (OP)
Newbie
*
Offline Offline

Activity: 7
Merit: 0


View Profile
May 26, 2010, 11:04:42 PM
 #3

Heh, found this when i was cruising rpc.cpp when updating to r78... btw, it doesn't quite compile with GCC 4.3.4 from debian lenny backports, I had to change DEFAULT_PORT in net.h to a #define because the htons() wasn't allowed in the variable declaration for some reason... probably not the best solution, but it worked for the shirt term. Wink
lachesis
Full Member
***
Offline Offline

Activity: 210
Merit: 104


View Profile
June 04, 2010, 05:50:37 AM
Last edit: June 04, 2010, 02:44:41 PM by lachesis
 #4

For a headless coin generation box, being able to see my status right away would be nice, or at least, being able to know if I have 30 blocks awaiting confirmation, or am still trying to get the first... if it's purely automated and just checking-and-forwarding the balance, that's not a problem though.
+1
Is there any way to access this information?
EDIT (June 4th, 2010):
First of all, I am not a C programmer. That said, I wrote my own extremely janky, hackish JSON-RPC method "listgenerated". I basically took the code from ui.cpp that builds the transactions list and copied it to an RPC method. Then I removed parts until it would compile. I'm SURE it doesn't work right, but it shows me when I have generated a block, which is all I need. If anyone would like the patch, send me a PM. That said, you probably want to wait for a real implementation from the devs.

Bitcoin Calculator | Scallion | GPG Key | WoT Rating | 1QGacAtYA7E8V3BAiM7sgvLg7PZHk5WnYc
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!