Bitcoin Forum
December 04, 2016, 06:23:59 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: svn rev 193: JSON methods listtransactions, gettransaction, move, sendfrom...  (Read 1300 times)
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
November 30, 2010, 07:52:03 PM
 #1

The "accounts" feature (to replace "labels") is done for now:  listtransactions and gettransaction are implemented, and move, sendfrom, and getbalance <account> are enabled.

This should make implementing web services much easier; you can assign each customer their own 'account' and rely on bitcoin to keep track of exactly how many bitcoins they have, have it return a list of the customer's last N transactions, etc.

This is a minimal implementation on purpose-- for example, gettransaction doesn't return every possible bit of information you might want to know about a transaction, and will only return information for transactions in your own wallet.  We are trying to think ahead and not add features that will be broken or taken away when bitcoin supports running in a 'lightweight client' mode, without access to the entire bitcoin transaction history.

I've updated the API wiki page with the new methods.

How often do you get the chance to work on a potentially world-changing project?
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480875839
Hero Member
*
Offline Offline

Posts: 1480875839

View Profile Personal Message (Offline)

Ignore
1480875839
Reply with quote  #2

1480875839
Report to moderator
davux
Sr. Member
****
Offline Offline

Activity: 289


Firstbits.com/1davux


View Profile WWW
November 30, 2010, 09:08:43 PM
 #2

This is great. However, I think accounts and labels are two separate needs. I'd like to share my own experience, in case it can help.

I'm currently working on a sort of "webservice", only via XMPP, not HTTP (a jabber-to-bitcoin gateway). It works much like myBitcoin: you let it manage a bitcoin address for you, and you send it commands (like "pay 150", sent to a JID representing a bitcoin address) to make it send the bitcoins wherever you want.

However:
 1. I'm allowing people to have more than one address.
 2. I'm letting people label each address.

This means I need to use the label as a label, and it also means I can't use it to store the account. So I'm solving this using an external database to store relationship between addresses and users.

I'm sharing this here because I think it's normal for a webservice to be willing to offer more than one address per person. If such a limitation exists, people won't use it, so having a notion of account with such a restriction seems pointless to me.

(My BTC 0.02.)

1DavuxH9tLqU4c7zvG387aTG4mA7BcRpp2
México (Oaxaca) – France - Leeds
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
December 01, 2010, 08:42:38 AM
 #3

I think accounts and labels are two separate needs.

+1 agreed

Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
davout
Legendary
*
Offline Offline

Activity: 1358


1davout


View Profile WWW
December 01, 2010, 12:04:26 PM
 #4

I think accounts and labels are two separate needs.

-1, completely disagree here.

Label functionality should be handled at application level (specific application that is).

What if I wanted to tag my addresses instead of label them, and allow multiple tags for one address ?

No, definitely, that's the application responsibility, whatever the meta-data you want to associate to an address you shouldn't rely on the bitcoin client to handle it.

Accounts, on the other hand, provide with the very important functionality of enforcing a positive balance.
Of course, that should be enforced at the application level too.

I check for data integrity at the application level, but I still define referential integrity constraints at the database level, and I think it should be the same approach when interacting with a bitcoin client.

doublec
Legendary
*
Offline Offline

Activity: 1078


View Profile
December 01, 2010, 12:19:34 PM
 #5

What happens to the existing label functionality? I have a webapp that uses a label to get an address then uses the address. Will this still work or will I have to change the app to use accounts?
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
December 01, 2010, 01:29:53 PM
 #6

1. I'm allowing people to have more than one address.
 2. I'm letting people label each address.

This means I need to use the label as a label, and it also means I can't use it to store the account. So I'm solving this using an external database to store relationship between addresses and users.

You can continue to use accounts as labels, create an each-address-gets-one-label, and map addresses-->user in your database.

However, your application will be faster and simpler if you let bitcoin do the addresses-->user mapping (one account per user), and store address-->user-specified-label in your database.

The bitcoin 'getaddressesbyaccount' method will give you the addresses-->user relationship, and all the accounting becomes much easier (listtransactions gets you all the transactions associated with a particular user, etc).

Quote from: doublec
What happens to the existing label functionality? I have a webapp that uses a label to get an address then uses the address. Will this still work or will I have to change the app to use accounts?

The label methods still work, call the corresponding account methods (e.g. call setlabel <bitcoinaddress> and it calls setaccount), but are deprecated, so they don't show up in the help and will eventually be removed.

The only 'potentially breaking change' is the sendtoaddress function, which now returns a transaction id instead of the word 'sent'.

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

Activity: 289


Firstbits.com/1davux


View Profile WWW
December 01, 2010, 05:47:00 PM
 #7

However, your application will be faster and simpler if you let bitcoin do the addresses-->user mapping (one account per user), and store address-->user-specified-label in your database.

The bitcoin 'getaddressesbyaccount' method will give you the addresses-->user relationship, and all the accounting becomes much easier (listtransactions gets you all the transactions associated with a particular user, etc).

Fair enough. I started with the orthogonal approach because back then, the API was dealing with "labels", but indeed it will be a lot easier this way. Then each address's label, if any, will be an entry in the database. (Actually, I could even drop the whole label concept, since people can give each address a name in their Jabber roster. That's another topic though.)

Thanks for the thoughts.

1DavuxH9tLqU4c7zvG387aTG4mA7BcRpp2
México (Oaxaca) – France - Leeds
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!