j"1LAnZuoQdcKCkpDBKQMCgziGMoPC4VQUckM8
<div class="post"><div class="quoteheader"><a href="https://bitcointalk.org/index.php?topic=665.msg14254#msg14254">Quote from: gavinandresen on September 27, 2010, 03:14:55 PM</a></div><div class="quote">The "label" mechanism (setlabel / getreceivedbylabel) is supposed to meet this need, but only solves part of the problem.<br/><br/>If the API was extended as I describe below, would it solve the same problems as having multiple wallets?<br/><br/>Proposal:<br/><br/>+ new send method: send TO a given bitcoin address specifically FROM the bitcoins sent to <label><br/> (change generated would be automatically tagged with <label>)<br/>+ add optional [label] param to getbalance.<br/>+ new method: listsentbylabel<br/> (returns array of [ "address" : "bcaddresssentto", "amount" : x.yz, "confirmations": n ]) <br/><br/>Each customer "account" would be a bitcoin <label>. Account handling would look like:<br/><br/>Create account / create new address for account:<br/> getnewaddress [account_id_label]<br/> ... tell user "fund your account by sending coins to {the address returned}"<br/><br/>Customer withdraws/spends:<br/> sendfrom [account_id_label] [address] [amount]<br/> (FAILS if balance for that account too low)<br/><br/>Show customer their balance:<br/> getbalance [account_id_label]<br/><br/>Show customer their transactions in/out<br/> listreceivedbylabel [account_id_label]<br/> listsentbylabel [account_id_label]<br/><br/>---------<br/><br/>Seems to me this would be a much better direction to go in, rather than having separate wallet.dat files for each customer. At the very least, backing up thousands of customer's wallet files would be inefficient and error-prone, and constantly switching between them would also be incredibly inefficient.<br/><br/><br/></div><br/>That is a much better approach, agreed. Assuming one label spans multiple addresses, so a client can accept transactions from an imported priv key (this being discussed on another thread), it seems to fit my needs perfectly, with only one small caveat which is internal transfers; say I use this approach for the lottery users (though that is not my use case, I actually would be more about site separation than user separation, but still):<br/>- Each account has on inbound address, annotated with the login label<br/>- Every time a user withdraws, I use the sendfrom mechanism you describe<br/>- The user hits the jackpot, but the prize is actually held in multiple users' accounts so<br/> a) I need to, when users buy tickets, move the amount to a separate address (forces external transaction, sucks)<br/> b) I leave coins where they are, and then on payout I make a normal sendtoaddress (both external transaction and breaks the label accounting logic)<br/> c) I leave coins where they are, payouts do nothing to the wallet, withdrawals do as many transactions as needed from each user account (what a nightmare!)<br/><br/>I don't see any good option here, and the best one, if I'm doing external transactions anyway, is a). I can trust these transactions with 0 blocks confirmed, because I'm both the sender and the recipient, and this would keep the accounts/labels in check, which serves as a great verification to the overall balances. Can you think of any alternative?</div> text/html
https://whatsonchain.com/tx/cb3a3e2a006fd5037d863b9f2ccdf7632946baaf45e7b01ad4f5fc30f6de2faf