Help:Accounts explained - Revision history

934: --Deprecated--

2015-12-29T11:22:09Z

--Deprecated--

← Older revision		Revision as of 11:22, 29 December 2015
Line 1:		Line 1:
			{{Deprecated}}

	== Introduction ==		== Introduction ==

Harding: Added Bitcoin Core documentation navbox

2015-08-17T15:58:59Z

Added Bitcoin Core documentation navbox

← Older revision		Revision as of 15:58, 17 August 2015
Line 96:		Line 96:
	[[Category:Technical]]		[[Category:Technical]]
	[[Category:Developer]]		[[Category:Developer]]

			{{Bitcoin Core documentation}}

Taras: Taras moved page Accounts explained to Help:Accounts explained

2015-07-24T00:17:47Z

Taras moved page Accounts explained to Help:Accounts explained

← Older revision		Revision as of 00:17, 24 July 2015
(No difference)

Naypam: Technically not true, moves can be done which create a negative balance, other information seemed superfluous

2014-02-15T18:16:25Z

Technically not true, moves can be done which create a negative balance, other information seemed superfluous

← Older revision		Revision as of 18:16, 15 February 2014
Line 69:		Line 69:
	== Account -> Account Transfers ==		== Account -> Account Transfers ==

	Use the ''move'' method to transfer balances from one account to another. ~~Moves from the default account to any other account always succeed; moves from any other account will fail if the account has insufficient funds.~~ Moves are not broadcast to the network, and never incur transaction fees; they just adjust account balances in the wallet.		Use the ''move'' method to transfer balances from one account to another. Moves are not broadcast to the network, and never incur transaction fees; they just adjust account balances in the wallet.

	== Account Balance and History==		== Account Balance and History==

Peapodamus: Mentioned that telling Bitcoin to "create a payment transaction using the coins received from these previously received transactions" CAN be done using the raw transactions API

2013-09-17T23:29:30Z

Mentioned that telling Bitcoin to "create a payment transaction using the coins received from these previously received transactions" CAN be done using the raw transactions API

← Older revision		Revision as of 23:29, 17 September 2013
Line 47:		Line 47:
	== Sending ==		== Sending ==

	The ''sendfrom'' method sends coins and debits the specified account. It does not change Bitcoin's algorithm for selecting which coins in the wallet are sent-- you should think of the coins in the wallet as being mixed together when they are received. There is no way to ask Bitcoin to "create a payment transaction using the coins received from these previously received transactions."		The ''sendfrom'' method sends coins and debits the specified account. It does not change Bitcoin's algorithm for selecting which coins in the wallet are sent-- you should think of the coins in the wallet as being mixed together when they are received. There is no way to ask Bitcoin to "create a payment transaction using the coins received from these previously received transactions" without using the raw transactions API(which is not part of the account system.)

	The ''sendtoaddress'' method works like ''sendfrom'', but always debits the default account.		The ''sendtoaddress'' method works like ''sendfrom'', but always debits the default account.

Gavinandresen: /* Account Weaknesses */

2013-09-12T01:09:02Z

Account Weaknesses

← Older revision		Revision as of 01:09, 12 September 2013
Line 19:		Line 19:
	* Wallet backups are an issue; if you rely on a good backup of wallet.dat then a backup must be done every time an address is associated with an account and every time the 'move' command is used.		* Wallet backups are an issue; if you rely on a good backup of wallet.dat then a backup must be done every time an address is associated with an account and every time the 'move' command is used.
	* The accounts code does not scale up to thousands of accounts with tens of thousands of transactions, because by-account (and by-account-by-time) indices are not implemented. So many operations (like computing an account balance) require accessing every wallet transaction.		* The accounts code does not scale up to thousands of accounts with tens of thousands of transactions, because by-account (and by-account-by-time) indices are not implemented. So many operations (like computing an account balance) require accessing every wallet transaction.
	* Most applications already have a customer database, implemented with MySQL or some other relational database technology. It is awkward at best to keep the bitcoin-maintained Berkely DB database and the application database backed up and synchronized at all times.		* Most applications already have a customer database, implemented with MySQL or some other relational database technology. It is awkward at best to keep the bitcoin-maintained Berkely DB wallet database and the application database backed up and synchronized at all times.

	== Account Names ==		== Account Names ==

Gavinandresen: /* Introduction */

2013-09-12T01:07:58Z

Introduction

← Older revision		Revision as of 01:07, 12 September 2013
Line 7:		Line 7:
	With the Bitcoin "accounts" feature, you are the bank. The balance you see is the total balance for all accounts, and you can create an arbitrary number of accounts.		With the Bitcoin "accounts" feature, you are the bank. The balance you see is the total balance for all accounts, and you can create an arbitrary number of accounts.

	When you receive bitcoins, they are always assigned to one of your accounts, and you can change which account is credited based on which bitcoin address receives the coins, just like you tell a bank teller which account to credit when you deposit cash in your bank. However, sending bitcoins is like withdrawing cash from the bank; the coins that are sent out are almost always not the same coins that were deposited.		When you receive bitcoins, they are always assigned to one of your accounts, and you can change which account is credited based on which bitcoin address receives the coins, just like you tell a bank teller which account to credit when you deposit cash in your bank. However, sending bitcoins is like withdrawing cash from the bank; the coins that are sent out and debited from an account are almost always not the same coins that were deposited into that account.

	== Accounts ==		== Accounts ==

Gavinandresen: Rewrote introduction with an analogy I like better, and added section on weaknesses.

2013-09-12T01:06:26Z

Rewrote introduction with an analogy I like better, and added section on weaknesses.

← Older revision		Revision as of 01:06, 12 September 2013
Line 1:		Line 1:
	== Introduction ==		== Introduction ==

	~~You can have different [[address\|addresses]] in order to receive payments.~~ Think ~~of addresses as multiple postboxes around the outside of~~ your ~~house~~. ~~Bitcoin allows accounts too. Each~~ account ~~owns a bunch of addresses. Taking our earlier analogy~~, ~~you can imagine separate accounts as different houses. You (Bitcoin user) receive all the mail (balance shown in Bitcoin). Mail goes to a postbox (address) at one~~ of ~~your houses (accounts)~~.		Think about what happens when you give a bank teller some cash and ask that it be deposited into your account. You tell them your account number, and they credit your account with that amount of money.

	The balance you see ~~displayed~~ is a total ~~from~~ all your accounts.		The money itself is mixed up with all of the other money in the bank, and is given out to other customers with other account numbers.

			With the Bitcoin "accounts" feature, you are the bank. The balance you see is the total balance for all accounts, and you can create an arbitrary number of accounts.

			When you receive bitcoins, they are always assigned to one of your accounts, and you can change which account is credited based on which bitcoin address receives the coins, just like you tell a bank teller which account to credit when you deposit cash in your bank. However, sending bitcoins is like withdrawing cash from the bank; the coins that are sent out are almost always not the same coins that were deposited.

	== Accounts ==		== Accounts ==

	Bitcoin version 0.3.18 and later implements several RPC methods to maintain separate account balances in a single Bitcoin wallet. The accounts feature makes it easy to ~~create web~~ services ~~that maintain~~ a ~~separate bitcoin~~ balance ~~for each~~ customer.		Bitcoin version 0.3.18 and later implements several RPC methods to maintain separate account balances in a single Bitcoin wallet. The accounts feature makes it easy to keep track of how much money you have received from different sources or to keep track of how much money you have spent on different things.

			== Account Weaknesses ==

			Since the accounts feature was introduced, several services have used it to keep track of customer's bitcoin balances and have had the following problems:

			* Wallet backups are an issue; if you rely on a good backup of wallet.dat then a backup must be done every time an address is associated with an account and every time the 'move' command is used.
			* The accounts code does not scale up to thousands of accounts with tens of thousands of transactions, because by-account (and by-account-by-time) indices are not implemented. So many operations (like computing an account balance) require accessing every wallet transaction.
			* Most applications already have a customer database, implemented with MySQL or some other relational database technology. It is awkward at best to keep the bitcoin-maintained Berkely DB database and the application database backed up and synchronized at all times.

	== Account Names ==		== Account Names ==

Sgornick: Add See Also section with an entry for API_Calls_list

2012-10-27T03:22:23Z

Add See Also section with an entry for API_Calls_list

← Older revision		Revision as of 03:22, 27 October 2012
Line 77:		Line 77:
	* Customer is '''charged a fee''' for use of the service: ''move "userid" "FEES" <amount>'' (using special accounts like "FEES" can make your application's logic much simpler)		* Customer is '''charged a fee''' for use of the service: ''move "userid" "FEES" <amount>'' (using special accounts like "FEES" can make your application's logic much simpler)
	* Customer '''purchases bitcoins''' from you: ''move "AVAILABLE" "userid" <amount>'' (assuming the bitcoins you are selling are kept track of in an "AVAILABLE" account)		* Customer '''purchases bitcoins''' from you: ''move "AVAILABLE" "userid" <amount>'' (assuming the bitcoins you are selling are kept track of in an "AVAILABLE" account)

			==See Also==

			* [[Original Bitcoin client/API_Calls_list\|API_Calls_list]]

	[[Category:Technical]]		[[Category:Technical]]
	[[Category:Developer]]		[[Category:Developer]]

Sgornick: Change the target bitcoin address from Faucet's old addres to FSF's address as the result of Faucet's wallet compromise.

2012-03-02T00:21:56Z

Change the target bitcoin address from Faucet's old addres to FSF's address as the result of Faucet's wallet compromise.

← Older revision		Revision as of 00:21, 2 March 2012
Line 44:		Line 44:
	server's wallet. For example, if your wallet account balances were 100 BTC in account		server's wallet. For example, if your wallet account balances were 100 BTC in account
	'foo' and 0 BTC in the default account, then the balances after ''sendtoaddress		'foo' and 0 BTC in the default account, then the balances after ''sendtoaddress
	~~15VjRaDX9zpbA8LVnbrCAFzrVzN7ixHNsC~~ 10.00'' would be 100 in account 'foo' and -10.00 in		1PC9aZC4hNX2rmmrt7uHTfYAS3hRbph4UN 10.00'' would be 100 in account 'foo' and -10.00 in
	the default account (and the overall server balance would go from 100 to 90 BTC). On		the default account (and the overall server balance would go from 100 to 90 BTC). On
	the other hand, using 'sendfrom' to send from the default account with a zero balance		the other hand, using 'sendfrom' to send from the default account with a zero balance