複数のウォレット、1台のコンピューター（複数アカウント）
個別の残高を持つ複数の「アカウント」を持ち、アカウントごとにコインの送受信を行いたい。複数のウォレットを同時に実行するのと同等の機能である。
各「受信アドレス」ごとの残高を一覧表示し、コイン送信時に「送信元」アドレスを指定できるようにするだけでも助かるだろう。
「ラベル」メカニズム（setlabel / getreceivedbylabel）はこのニーズに対応するはずだが、問題の一部しか解決しない。
以下に説明するようにAPIを拡張すれば、複数のウォレットを持つのと同じ問題を解決できるか？
提案：
+ 新しい送信メソッド：指定した Bitcoin アドレスに、<label>に送られた Bitcoin から具体的に FROM として送信
（生成されたおつりには自動的に<label>がタグ付けされる）
+ getbalance にオプションの [label]パラメーターを追加
+ 新しいメソッド：listsentbylabel
（[ "address" : "送信先 BC アドレス", "amount" : x.yz, "confirmations": n ]の配列を返す）各顧客の「アカウント」がBitcoinの<label>になる。アカウント処理はこのようになる：
アカウント作成 / アカウント用の新しいアドレス作成：
getnewaddress [account_id_label]
… ユーザーに「{返されたアドレス}にコインを送信してアカウントに資金を入れてください」と伝える
顧客の引き出し/支出：
sendfrom [account_id_label] [address] [amount]
（そのアカウントの残高が不足している場合は失敗）
顧客に残高を表示：
getbalance [account_id_label]
顧客に入出金トランザクションを表示：
listreceivedbylabel [account_id_label]
listsentbylabel [account_id_label]各顧客のために別々のwallet.datファイルを持つよりも、こちらの方向に進む方がはるかに良いと思う。少なくとも、何千もの顧客のウォレットファイルをバックアップするのは非効率的でエラーが起きやすく、常にそれらを切り替えるのも非常に非効率的だ。
「ラベル」メカニズム（setlabel / getreceivedbylabel）はこのニーズに対応するはずだが、問題の一部しか解決しない。
以下に説明するようにAPIを拡張すれば、複数のウォレットを持つのと同じ問題を解決できるか？
提案：
- 新しい送信メソッド：指定したBitcoinアドレスに、<label>に送られたBitcoinから具体的にFROMとして送信 （生成されたおつりには自動的に<label>がタグ付けされる）
- getbalanceにオプションの [label]パラメーターを追加
- 新しいメソッド：listsentbylabel（[ “address” : “送信先BCアドレス”, “amount” : x.yz, “confirmations”: n ]の配列を返す）
各顧客の「アカウント」がBitcoinの<label>になる。アカウント処理はこのようになる：
アカウント作成 / アカウント用の新しいアドレス作成：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ブロック承認でこれらの取引を信頼でき、アカウント/ラベルの整合性を保つことができ、全体の残高の優れた検証となる。何か代替案を思いつくだろうか？
ジャックポットを蓄積するための個別の「アカウント」（ラベル付きアドレス）が正しいアイデアだ。ユーザーがチケットを購入し、ビットコインが適切なジャックポットアカウントに移される。ジャックポットが当選すると、そのアカウントから当選者に取引が送られる。
ジャックポットを蓄積するための個別の「アカウント」（ラベル付きアドレス）が正しいアイデアだ。ユーザーがチケットを購入し、ビットコインが適切なジャックポットアカウントに移される。ジャックポットが当選すると、そのアカウントから当選者に取引が送られる。
ああ、それは十分明白だ。過度な最適化強迫症に苦しんでいる 😊 データがアプリケーション内でのみ流れるのであれば、取引を登録してシステムに「余分な負荷」をかける必要はないと感じるが、正直なところ、余分な負荷は完全に無視できるレベルで、取引があることですべてが整理される。この件について何かする予定はあるか？ 自分でやる方法は見つけられると思うが、時間がかかるだけで、作業を重複させたくない。
このようなものの始まりを作っている。ギャビンが説明したものとほとんど同じだ。
追加のRPCインターフェース：
move <fromaccount> <toaccount> <amount>
内部アカウント間の移動。空のアカウント名（""）がデフォルトアカウントになると思う。ユーザーに何かを販売した場合、move “theiraccount” "" 123.45とできる。moveはこれに最適な名前だろうか？transferはトランザクションの送信と混同しそうなので避けた。
getnewaddressをオーバーロードする代わりに、新しい関数getaccountaddressを考えている：
getaccountaddress <account> getnewaddress <account>から割り当てられたアドレスを返す。そのアドレスで何かが受信されるまで同じアドレスを返し続け、受信されると新しいアドレスを割り当てる。（以前投稿したサンプルコードが行っていたことを自動的に行う）
これらのコマンドがあれば、シンプルなケースでは独自のデータベースなしにウェブサイトを実装できるだろうか？
Bitcoinの複数のインスタンスを実行でき、それぞれが特定のwallet.datファイルで動くようにする方がはるかに簡単ではないか？
つまり、クライアント/サーバーアプリに—walletロングオプションを追加するだけだ。アカウント名はウォレットファイル名になる。
個別の残高を持つ複数の「アカウント」を持ち、アカウントごとにコインの送受信を行いたい。複数のウォレットを同時に実行するのと同等の機能である。
各「受信アドレス」ごとの残高を一覧表示し、コイン送信時に「送信元」アドレスを指定できるようにするだけでも助かるだろう。
-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)
なぜそこまで頑張ってbitcoinの複数インスタンスの起動を防ごうとするのか？
SElinuxのMAC保護を使ってユーザーごとにbitcoinプロセスを分けるというのは正当なユースケースだ。これは共有のユーザープロセスにコーディングできるどんなものよりもはるかに強力な保護だ。
mybitcoinやmtgoxのように、顧客がアカウント内にビットコインを保管できるサイトを運営しているなら、「顧客1人につきbitcoinプロセス1つ」という方式はおよそ現実的ではない。まず第一に、すべてのbitcoinプロセスがブロックチェーンの完全なコピーを持つことになる…
mybitcoinやmtgoxのように、顧客がアカウント内にビットコインを保管できるサイトを運営しているなら、「顧客1人につきbitcoinプロセス1つ」という方式はおよそ現実的ではない。まず第一に、すべてのbitcoinプロセスがブロックチェーンの完全なコピーを持つことになる…
確かに。それは考えていなかった。それにポートマッピングの問題もあるだろう。