複数のウォレット、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 ファイルを持つよりも、こちらの方向に進む方がはるかに良いと思う。少なくとも、何千もの顧客のウォレットファイルをバックアップするのは非効率的でエラーが起きやすく、常にそれらを切り替えるのも非常に非効率的だ。
「ラベル」メカニズム（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 ブロック承認でこれらの取引を信頼でき、アカウント/ラベルの整合性を保つことができ、全体の残高の優れた検証となる。何か代替案を思いつくだろうか？
ジャックポットを蓄積するための個別の「アカウント」（ラベル付きアドレス）が正しいアイデアだ。ユーザーがチケットを購入し、ビットコインが適切なジャックポットアカウントに移される。ジャックポットが当選すると、そのアカウントから当選者に取引が送られる。
ジャックポットを蓄積するための個別の「アカウント」（ラベル付きアドレス）が正しいアイデアだ。ユーザーがチケットを購入し、ビットコインが適切なジャックポットアカウントに移される。ジャックポットが当選すると、そのアカウントから当選者に取引が送られる。
ああ、それは十分明白だ。過度な最適化強迫症に苦しんでいる 😊 データがアプリケーション内でのみ流れるのであれば、取引を登録してシステムに「余分な負荷」をかける必要はないと感じるが、正直なところ、余分な負荷は完全に無視できるレベルで、取引があることですべてが整理される。この件について何かする予定はあるか？ 自分でやる方法は見つけられると思うが、時間がかかるだけで、作業を重複させたくない。
このようなものの始まりを作っている。ギャビンが説明したものとほとんど同じだ。
追加の RPC インターフェース：
move move はこれに最適な名前だろうか？transfer はトランザクションの送信と混同しそうなので避けた。
getnewaddress をオーバーロードする代わりに、新しい関数 getaccountaddress を考えている：
getaccountaddress
これらのコマンドがあれば、シンプルなケースでは独自のデータベースなしにウェブサイトを実装できるだろうか？
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 プロセスがブロックチェーンの完全なコピーを持つことになる…
確かに。それは考えていなかった。それにポートマッピングの問題もあるだろう。