Bitcoin Forum
September 27, 2016, 08:41:17 AM *
News: Due to DDoS attacks, there may be periodic downtime.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: CLI bitcoin generation  (Read 2667 times)
molybdenum
Newbie
*
Offline Offline

Activity: 7


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)?
1474965677
Hero Member
*
Offline Offline

Posts: 1474965677

View Profile Personal Message (Offline)

Ignore
1474965677
Reply with quote  #2

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

Posts: 1474965677

View Profile Personal Message (Offline)

Ignore
1474965677
Reply with quote  #2

1474965677
Report to moderator
1474965677
Hero Member
*
Offline Offline

Posts: 1474965677

View Profile Personal Message (Offline)

Ignore
1474965677
Reply with quote  #2

1474965677
Report to moderator
1474965677
Hero Member
*
Offline Offline

Posts: 1474965677

View Profile Personal Message (Offline)

Ignore
1474965677
Reply with quote  #2

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

Activity: 364


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
Newbie
*
Offline Offline

Activity: 7


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


View Profile
June 04, 2010, 05:50:37 AM
 #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:  

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!