Wallet protocol
これは、現在のJSON-RPC実装の問題に対処する新しいウォレットプロトコルをビットコントで定義するプロジェクトです。 お気軽に編集してください。あなたが何かに同意しない場合は、それを「議論」に変えてください。
目次
- 1 説明
- 2 要件
- 3 DRAFT 0
- 3.1 適合要件
- 3.2 トランスポート/セッション層
- 3.3 プレゼンテーションレイヤ
- 3.4 アプリケーション層
- 3.5 付録A.有用なアルゴリズム
- 3.6 付録B. JSON-RPC等価物
- 3.6.1 バックアップワレット
- 3.6.2 getaccount / getlabel
- 3.6.3 getaddressesbyaccount / getaccountaddress / getaddressesbylabel
- 3.6.4 ゲットバランス
- 3.6.5 getblockcount / getblocknumber
- 3.6.6 getconnectioncount
- 3.6.7 getdifficulty
- 3.6.8 getgenerate
- 3.6.9 gethashespersec
- 3.6.10 getinfo
- 3.6.11 getnewaddress
- 3.6.12 getreceivedbyaccount / getreceivedbylabel
- 3.6.13 getreceivedbyaddress / getamountreceived
- 3.6.14 gettransaction
- 3.6.15 ネットワーク
- 3.6.16 ヘルプ
- 3.6.17 listaccounts
- 3.6.18 listreceivedbyaccount / listreceivedbylabel
- 3.6.19 listreceivedbyaddress / getallreceived
- 3.6.20 リストトランザクション
- 3.6.21 移動
- 3.6.22 sendfrom
- 3.6.23 sendtoaddress
- 3.6.24 setaccount / setlabel
- 3.6.25 setgenerate
- 3.6.26 settxfee
- 3.6.27 停止
- 3.6.28 validateaddress
- 3.7 参考文献
説明[編集]
このプロトコルは、ウォレットとユーザーインターフェイス間の通信の標準となることを目指しています。 WalletとUser Interfaceが異なるベンダーや競合するベンダーによって作成されていても、リモートで、またはローカルでも、Walletにアクセスすることができます。たとえば、GoogleのAndroidユーザーインターフェイスを使用してQBitcoin Walletを管理することができます。
このプロトコルが大きな画像に収まる場所の概要については、Infrastructureページを参照してください。
要件[編集]
- 人間の書式設定されたデータを使用しないでください（たとえば、Decimal BitCoinsやTonal BitCoinsではなく、基本ビットコイン単位を使用してください。これは人間の書式設定でのみ使用してください）
- ポーリングを必要としない（新しいトランザクションのブロードキャストイベントや、現在の「仕事」への変更など）
- 協力鉱業（下記参照）
- 使用された入力をロックする（ウォレットの選択）、または送信前に無効になった場合はtxとエラーを事前に作成することで、トランザクションの予想最小料金の計算を許可する
- RPCのような使い方で、簡単なアプリケーションで使いやすい
議論[編集]
バイナリまたは平文[編集]
- バイナリは解析して作成する方が効率的です
- プレーンテキストは人間がデバッグするのが簡単であり、特定のビット数、エンディアン、または精度に依存することを回避します
- バイナリには、そのままのカスタムトランザクションを送信用に含めることができます
バイナリワイヤフォーマット[編集]
- Protobufは、すべての主要言語から効率的で使いやすいようです
プレーンテキストのワイヤフォーマット[編集]
- JSON実装はバグが多い傾向があります。
協同鉱業[編集]
プロトコルは、完了するブロックを送信することをサポートして、生成する上流プールから（ちょうど）アドレスを取得し、すべての完了したブロックをそのプールに送信して検証およびカウント（場合によってはネットワークへの提出）することができます。これは、プールの負荷を減らすことができます。
UIバンドル[編集]
通常のエンドユーザーがより安全に使用できるように、UIとウォレットは標準I / O（stdio）を介したストリームベースの通信をサポートする必要があります。これにより、ユーザーはウォレット側の認証を設定することなく、専用のウォレットをUIに簡単に実行させることができます。これにより、セキュリティ保護されたデバイス（たとえば、暗号化ハードウェア・モジュール、またはRS232またはUSBを介して接続されたウォレット・デバイスなど）にあるハードウェア・ベースのウォレットとの完全な互換性も得られます。 （提案、もしUIが子プロセスのstdioやパイプやデバイスを含むどんなストリームとも話すことができるなら、柔軟性は貴重です）
DRAFT 0[編集]
この点を越えるものは厳密にDRAFTであり、実装すべきではなく、完全に書き直されたり、変更されたりすることになります！
適合要件[編集]
この仕様のすべての図、例、および注釈は、非規範的であると明示されているすべてのセクションと同様に、非規範的です。この仕様の他のすべては規範的です。
この文書の規範的な部分のキーワード "必須"、 "必須"、 "必須"、 "しない"、 "推奨"、 "可能"、および "オプション"は、 RFC2119 [1]にあります。読みやすくするために、これらの単語は、この仕様ではすべて大文字ではありません。
アルゴリズムの一部として必須とされている要件（「先頭の空白文字を取り除く」や「偽を返してこれらのステップを中止する」など）は、キーワードの意味（ "must"、 "should"、 " may "など）を使用することができます。
トランスポート/セッション層[編集]
少なくとも信頼できるインオーダーストリームデータをサポートしている必要があります。
といった：
- stdio（自己完結型のUIバンドルに必要）
- シリアル
- TCP
プレゼンテーションレイヤ[編集]
暗号化[編集]
- TLS（推奨）
- SSH
パケット化[編集]
信頼性の高い順番のパケット化が必要です。 パケットは次のものをサポートしながら、要求指向にする必要があります。
これは以下をサポートします：
リクエストタイプ：
- オプション：全二重ストリームを確立するためのCONNECT
- GETは読み取り専用アクセスで、常に固定長の応答を返す
- メソッド呼び出しのPOST
- アップロードのためのPUT
- メタデータ用のHEAD
注：一部のプロトコル（HTTPなど）では、GET要求で複雑な構造を使用できません。これらのプロトコルを使用する実装は、GETを同じセマンティクスでPOSTにサイレントにアップグレードする必要があります。
注：論理CONNECT要求は、同じ名前のHTTPメソッドに直接マップすることはできません。現在のWebSocket仕様では、HTTP GET要求が使用されています。
MIMEフォーマット[編集]
これらのコンテンツタイプは、Content-TypeヘッダーとAcceptヘッダーで指定できます。
- application / x-www-form-urlencoded（必須）
- application / x-ripemd-160（必須）
- application / x-sha（必須）
- multipart / mixed（必須）
- text / event-stream [4]（HTTP [5]を介したイベントに必要）
- application / x-bitcoin（必要な財布側）
- application / json [9]（推奨）
- application / xml [10]
アプリケーション層[編集]
認証/セキュリティ[編集]
ウォレットは、好きなだけセキュリティをマイクロ管理できますが、次のセキュリティレベルが推奨されます。
| "鉱夫" | 新しいアドレスを生成し、仕事をし、発見されたブロックを報告することができます |
| 商人 | トランザクションを作成することができます（ 'プロポーザル'フラグでのみ）、送信できません |
| 読み取り専用 | 口座、住所、および任意の公開データ、およびそれらの組み合わせ（例えば残高）を見ることができ、 |
| 財務 | ウォレットのキーを使用して新しいトランザクションを作成できます |
| フル/管理者 | ウォレット・キーの管理（ダウンロード、破棄など） |
ウォレットは、stdioに対する要求に対してヌルパスワードでユーザ名「admin」へのフルアクセスを許可することができます（MAY）。
ウォレットは、直接（すなわち、物理的にローカルの、ブルートゥースのような）接続を介してなされた要求に対して、商人がユーザ名 '商人'にアクセスする際にヌルパスワードを与えるべきである（SHOULD）。 ユーザインタフェースは、 'proposal'フラグが設定された新しい未署名のトランザクションを監視し、ユーザに署名または削除を促すべきです（SHOULD）。
オブジェクト/クエリスキーマ[編集]
マルチパート/混合、JSON、XMLなどで提供される可能性があります...
データ[編集]
- 任意のデータは、/ data / <id>というパスでアクセスできます。
- フェッチするためにGET
- ブロックヘッダのみを取得するには、/ data / <id> / header
- 実際のコンテンツのみを取得するには（たとえば、計算値なし）、/ data / <id> / rawを使用します
- オプション：アップロードするPUT
情報[編集]
- GET /状態/ <ネットワーク> /接続
- 鉱業情報:(鉱業支援に必要）
- GET /状態/ <ネットワーク> / hashesPerSec（オプション）
- GET /状態/ <ネットワーク> / merkle
- GET / info / protocols
- サポートされているプロトコル/バージョンとそれらのURIのリストを返します
リクエスト[編集]
アドレス検証[編集]
- GET / validate / address？network = <id>＆address = <hash>
残高を計算する[編集]
- GET / balance？<query-object>
残高に含まれる取引を照合します。 支出を無視するには、マッチングを使用します。
データ検索[編集]
- GET / dataSearch？<query-object>
- POST / dataSearchにより複雑なクエリが可能
注：データそのものではなくIDを取得するには、HEADリクエストを使用してLocationヘッダーを確認します。
新しいアドレスを生成[編集]
- POST / newAddress
- オプションのパラメータ：recycle（bool） - ウォレットは使用済みの変更アドレスを再利用できます。サポートされていない場合、ウォレットは黙って無視する必要があります
- オプションのパラメータ：generate（bool） - trueの場合は、その場で新しいアドレスを作成し、既存のアドレスを使用しないでください。サポートされていない場合は、エラーをスローする
- オプションのパラメータ：account - この口座IDに新しい住所資金を関連付ける
イベントを監視[編集]
- 常にPOST
入手可能な新しいデータ[編集]
- クエリ
アカウント間の移動[編集]
- POST /会計/移動
- dest = <accountId>
- query = <query-object> OR amount = <amount>
- オプション：コメント= <文字列>
トランザクションの作成[編集]
- POST / tx / new
- send（bool） - trueの場合、すぐに署名してブロードキャストする
- 手数料（金額または範囲） - 範囲の場合、ウォレットはネットワークが受け入れることを期待する最小額を計算しようと試みます。省略された場合、自動料金の範囲は、他の要因（例えば、入力+厳密）に拘束されない限り、
- オプション：fromAccount（アカウントID）
- オプション：入力（複数のコインID、ORコインid => scriptSig）
- 出力（複数の許可：アドレス=>金額ペア、ORスクリプト=>金額）
- strict（bool） - 設定されている場合、パラメータを変更するのではなくエラーになります。
- オプション：コメント= <文字列>
トランザクションブロードキャスト[編集]
- POST / tx / send？id = <既存のtx-internal-id>
シャットダウンウォレット[編集]
- POST /シャットダウン
イベント[編集]
利用可能な新しいデータ[編集]
p2pプロトコルカプセル化[編集]
オプション：/ p2pへの全二重接続を確立して、直接P2Pプロトコルを話す
付録A.有用なアルゴリズム[編集]
確認を数える[編集]
多数の（ほとんどの）トランザクションは同じイベントで確認を変更するため、これを効率的に実行する唯一の方法は、新しいブロックイベントを監視することです。ブロックが到着すると、すでに少なくとも1つの確認が行われているすべてのトランザクションの確認カウントをインクリメントします。次に、新しいブロックの導入されたトランザクションをチェックし（0から1までインクリメント）、取り消されたトランザクション（例えば、競合チェーンから）を削除/無効化します。
付録B. JSON-RPC等価物[編集]
バックアップワレット[編集]
getaccount / getlabel[編集]
getaddressesbyaccount / getaccountaddress / getaddressesbylabel[編集]
ゲットバランス[編集]
getblockcount / getblocknumber[編集]
getconnectioncount[編集]
getdifficulty[編集]
getgenerate[編集]
gethashespersec[編集]
getinfo[編集]
getnewaddress[編集]
getreceivedbyaccount / getreceivedbylabel[編集]
getreceivedbyaddress / getamountreceived[編集]
gettransaction[編集]
ネットワーク[編集]
ヘルプ[編集]
listaccounts[編集]
listreceivedbyaccount / listreceivedbylabel[編集]
listreceivedbyaddress / getallreceived[編集]
リストトランザクション[編集]
移動[編集]
sendfrom[編集]
sendtoaddress[編集]
setaccount / setlabel[編集]
setgenerate[編集]
settxfee[編集]
停止[編集]
validateaddress[編集]
参考文献[編集]
<リファレンス> <ref name = "0MQ-RFC2"> [1]、iMatix Corporation </ ref> <ref name = "protobuf"> [2]、Google。</ ref> Freed＆Borenstein、First Virtual。<ref name = "RFC2045"> [3] <ref name = "RFC2119"> Indicate Requirement LevelsにRFCで使用するキーワード、S. Bradner IETF。</ ref> <ref name = "RFC2616"> - HTTP / 1.1、Fielding他、W3C。</ ref> <ref name = "RFC4627"> JavaScript Object Notation（JSON）のアプリケーション/ jsonメディアタイプ、D. Crockford JSON.org。</ ref> <ref name = "SSE"> Server-Sent Events、Ian Hickson、Google、Inc。</ ref> <ref name = "SPDY"> SPDY Protocol、さまざまです。 Google、Inc。</ ref> <ref name = "WebSocket"> The WebSocket protocol、Ian Hickson、Google、Inc。</ ref> Tim Bray、Jean Paoli、CM Sperberg-McQueen、Eve Malerの4つの主要な要素から構成されています。<ref name = "XML"> Extensible Markup Language（XML）1.0（Second Edition） 、W3C。</ ref> </リファレンス>
Category：技術- ↑ 引用エラー: 無効な
<ref>タグです。 「RFC2119」という名前の引用句に対するテキストが指定されていません - ↑ 引用エラー: 無効な
<ref>タグです。 「RFC2045」という名前の引用句に対するテキストが指定されていません - ↑ 3.0 3.1 引用エラー: 無効な
<ref>タグです。 「WebSocket」という名前の引用句に対するテキストが指定されていません - ↑ 4.0 4.1 引用エラー: 無効な
<ref>タグです。 「SSE」という名前の引用句に対するテキストが指定されていません - ↑ 5.0 5.1 引用エラー: 無効な
<ref>タグです。 「RFC2616」という名前の引用句に対するテキストが指定されていません - ↑ 引用エラー: 無効な
<ref>タグです。 「SPDY」という名前の引用句に対するテキストが指定されていません - ↑ 引用エラー: 無効な
<ref>タグです。 「0MQ-RFC2」という名前の引用句に対するテキストが指定されていません - ↑ 引用エラー: 無効な
<ref>タグです。 「protobuf」という名前の引用句に対するテキストが指定されていません - ↑ 引用エラー: 無効な
<ref>タグです。 「RFC4627」という名前の引用句に対するテキストが指定されていません - ↑ 引用エラー: 無効な
<ref>タグです。 「XML」という名前の引用句に対するテキストが指定されていません
