複数のウォレット、1台のコンピュータ
個別の残高を持つ複数の「アカウント」を持ち、アカウントごとにコインの送受信を行いたい。複数のウォレットを同時に実行するのと同等の機能である。
各「受信アドレス」ごとの残高を一覧表示し、コイン送信時に「送信元」アドレスを指定できるようにするだけでも助かるだろう。
「ラベル」メカニズム（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ファイルを持つよりも、こちらの方向に進む方がはるかに良いと思う。少なくとも、何千もの顧客のウォレットファイルをバックアップするのは非効率的でエラーが起きやすく、常にそれらを切り替えるのも非常に非効率的だ。
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ブロック承認でこれらの取引を信頼でき、アカウント/ラベルの整合性を保つことができ、全体の残高の優れた検証となる。何か代替案を思いつくだろうか？
ジャックポットを蓄積するための個別の「アカウント」（ラベル付きアドレス）が正しいアイデアだ。ユーザーがチケットを購入し、ビットコインが適切なジャックポットアカウントに移される。ジャックポットが当選すると、そのアカウントから当選者に取引が送られる。
Quote from: gavinandresen on September 27, 2010, 05:10:33 PM
ジャックポットを蓄積するための個別の「アカウント」（ラベル付きアドレス）が正しいアイデアだ。ユーザーがチケットを購入し、ビットコインが適切なジャックポットアカウントに移される。ジャックポットが当選すると、そのアカウントから当選者に取引が送られる。
ああ、それは十分明白だ。過度な最適化強迫症に苦しんでいる Smiley データがアプリケーション内でのみ流れるのであれば、取引を登録してシステムに「余分な負荷」をかける必要はないと感じるが、正直なところ、余分な負荷は完全に無視できるレベルで、取引があることですべてが整理される。この件について何かする予定はあるか？ 自分でやる方法は見つけられると思うが、時間がかかるだけで、作業を重複させたくない。
このようなものの始まりを作っている。Gavinが説明したものとほとんど同じだ。
追加のRPCインターフェース：
move
getnewaddressをオーバーロードする代わりに、新しい関数getaccountaddressを考えている：
getaccountaddress
これらのコマンドがあれば、シンプルなケースでは独自のデータベースなしにウェブサイトを実装できるだろうか？
Bitcoinの複数のインスタンスを実行でき、それぞれが特定の「wallet.dat」ファイルで動くようにする方がはるかに簡単ではないか？
つまり、クライアント/サーバーアプリに—walletロングオプションを追加するだけだ。アカウント名はウォレットファイル名になる。
Quote from: bytemaster on August 01, 2010, 08:14:29 PM
個別の残高を持つ複数の「アカウント」を持ち、アカウントごとにコインの送受信を行いたい。複数のウォレットを同時に実行するのと同等の機能である。
各「受信アドレス」ごとの残高を一覧表示し、コイン送信時に「送信元」アドレスを指定できるようにするだけでも助かるだろう。
-datadirを使い、ソースコードでポートを変更し、Bitcoinインスタンスごとに異なるディレクトリとポートを使えばいい。
アカウントベースのコマンドの使い方の擬似コードだ。ウェブサイト統合がとても簡単になる。
print "send to " + getaccountaddress(username) + " to fund your account"
print "balance: " + getbalance(username, 0)
print "available balance: " + getbalance(username, 6)// 販売したら、そのアカウントからお金を移動する
move(username, "", amount, 6)// 出金 sendfrom(username, bitcoinaddress, amount, 6)