Quote from: gavinandresen on September 27, 2010, 03:14:55 PM
「ラベル」メカニズム（setlabel / getreceivedbylabel）はこのニーズに対応するはずだが、問題の一部しか解決しない。
以下に説明するようにAPIを拡張すれば、複数のウォレットを持つのと同じ問題を解決できるか？
提案：
- 新しい送信メソッド：指定したBitcoinアドレスに、
- getbalanceにオプションの[label]パラメータを追加
- 新しいメソッド：listsentbylabel （[ “address” : “送信先BCアドレス”, “amount” : x.yz, “confirmations”: n ]の配列を返す）
各顧客の「アカウント」がBitcoinの
アカウント作成 / アカウント用の新しいアドレス作成： getnewaddress [account_id_label] … ユーザーに「{返されたアドレス}にコインを送信してアカウントに資金を入れてください」と伝える
顧客の引き出し/支出： sendfrom [account_id_label] [address] [amount] （そのアカウントの残高が不足している場合は失敗）
顧客に残高を表示： getbalance [account_id_label]
顧客に入出金トランザクションを表示： listreceivedbylabel [account_id_label] listsentbylabel [account_id_label]
各顧客のために別々のwallet.datファイルを持つよりも、こちらの方向に進む方がはるかに良いと思う。少なくとも、何千もの顧客のウォレットファイルをバックアップするのは非効率的でエラーが起きやすく、常にそれらを切り替えるのも非常に非効率的だ。
はるかに良いアプローチだ、同意する。一つのラベルが複数のアドレスにまたがると仮定すると、クライアントがインポートされた秘密鍵からの取引を受け入れることができ（別のスレッドで議論されている）、自分のニーズにぴったり合うようだ。ただし一つだけ小さな注意点があり、それは内部送金だ。例えばこのアプローチを宝くじのユーザーに使うとする（それが自分のユースケースではないが、実際にはユーザー分離よりもサイト分離に関するものだが、それでも）：
- 各アカウントにはログインラベルが付けられた受信アドレスがある
- ユーザーが引き出すたびに、説明されたsendfromメカニズムを使う
- ユーザーがジャックポットに当選するが、賞金は実際には複数のユーザーのアカウントに保持されているので a) ユーザーがチケットを購入するとき、金額を別のアドレスに移す必要がある（外部取引を強制、良くない） b) コインをそのままにして、配当時に通常のsendtoaddressを行う（外部取引であり、ラベル会計ロジックを壊す） c) コインをそのままにして、配当はウォレットに何もせず、引き出し時に各ユーザーアカウントから必要な数の取引を行う（なんという悪夢！）
良い選択肢が見当たらず、外部取引をどうせ行うなら最善はa)だ。送信者も受信者も自分なので、0ブロック承認でこれらの取引を信頼でき、アカウント/ラベルの整合性を保つことができ、全体の残高の優れた検証となる。何か代替案を思いつくだろうか？