CLI bitcoin generation
2010 May 22
See all posts
CLI bitcoin generation @ Satoshi Nakamoto
- Author
-
Satoshi Nakamoto
- Email
-
satoshinakamotonetwork@proton.me
- Site
-
https://satoshinakamoto.network
molybdenum
CLI bitcoin generation
May 22, 2010, 06:44:20 PM
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)?
Satoshi Nakamoto
May 26, 2010, 08:09:34 PM
Quote from: molybdenum on May 22, 2010, 06:44:20 PM
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.
CLI bitcoin generation
2010 May 22 See all postsSatoshi Nakamoto
satoshinakamotonetwork@proton.me
https://satoshinakamoto.network
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 (
getallreceived1 for current behavior, or justgetallreceived,getallreceived5 for the paranoid,getallreceived0 for instant confirms)?Yeah, that actually is what it is.
getallreceived0 should do what you want. (now it's renamed tolistreceivedbyaddress0) 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
listreceivedbylabelif 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.