|
|
| (4人の利用者による、間の6版が非表示) |
| 1行目: |
1行目: |
| − | {{bip}}
| + | BIPドラフト - 即時部分確認 |
| | | | |
| | + | このページではBIP（Bitcoin Improvement Proposal）について説明します。 |
| | + | BIPの詳細と作成方法については、[https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki BIP 2]を参照してください。<br> |
| | + | wikiページを作成するだけではありません。 |
| | <pre> | | <pre> |
| − | BIP: Draft
| + | タイトル：即時部分確認（IPC） |
| − | Title: Instant Partial Confirmation (IPC)
| + | 著者：Mike Caldwell <casascius@mc2cs.com> |
| − | Author: Mike Caldwell <casascius@mc2cs.com>
| + | ステータス：下書き |
| − | Status: Draft
| + | タイプ：標準トラック |
| − | Type: Standards Track
| + | 作成日：2012-07-31 |
| − | Created: 2012-07-31
| |
| | </pre> | | </pre> |
| | | | |
| − | ==Abstract== | + | ==1要約== |
| − | This BIP proposes a scheme to enable parties to a transaction to receive a reliable confirmation of their transaction from miners in a deterministic predictable timeframe, and compensates miners financially for providing this service.
| + | BIPは、取引当事者が決定的な予測可能な期間内に鉱夫から取引の信頼性の高い確認を受け取り、サービスを提供するために報酬を支払うことを可能にするスキームを提案する。 |
| | + | このBIPで説明されているサービスでは、1回の確認で平均10分間待機するのではなく、取引者は発行後10秒以内に0.51以上の確認を受け取る可能性があります（ネットワーク上のマイニングパワーの51％を表します）。トランザクションがゼロ確認トランザクションと比較して確認されるはるかに高いレベルの信頼性。 |
| | | | |
| − | With the service described by this BIP, instead of waiting an average of 10 minutes for 1 confirmation, a transactor could potentially receive 0.51 or more confirmations within 10 seconds of issuing it (representing 51% of the mining power on the network), and have a much higher level of confidence that the transaction will be confirmed as compared to a zero-confirmation transaction.
| + | ==2モチベーション== |
| | + | Bitcoinで最も頻繁に議論される問題の1つは、取引がネットワークによって確認されるまで取引が二重支出の対象となるという事実であり、そのような確認を受け取るために必要な時間はあまりにも大きく、小売り環境で実用には予測できません。現在のコンセンサスは、商人が小規模な取引の詐欺のリスクを想定するか、商人の損失のリスクが軽微なものを単純に想定し、詐欺行為の費用が信じられている取引の確認のみを主張することがベストプラクティスであるそのような詐欺の予想される利益よりも大きくなるようにしてください。 |
| | + | そのようなコンセンサスには実用的なメリットがありますが、商人が必要とされる信仰のレベルに不快で、リスクを軽減するための技術的な解決策を喜んで支払う人がいることは間違いありません。 |
| | | | |
| − | ==Motivation==
| + | 一方、Bitcoinで頻繁に議論されるもう1つの問題は、取引手数料の総額がブロック報酬よりもはるかに小さいという観測です。現在、鉱夫は個々のBitcoinユーザーにサービスを提供せず、むしろネットワーク全体にサービスを提供しています。この提案はBitcoin鉱夫が鉱山者が解決しようとする顧客に貴重なサービスを提供し、潜在的に鉱夫によって解決された新しいブロックに集められた取引手数料の総量を大幅に増強することを意味する。 |
| − | One of the most frequently discussed issues with Bitcoin is the fact that transactions are subject to double-spending until confirmed by the network, and the time needed to receive such confirmations is too great and too unpredictable to be of practical use in a retail setting. The present consensus is that the best practice is for merchants to simply assume the risk of fraud for small transactions or those where the risk of loss to the merchant is trivial, and to only insist on confirmations for transactions where the cost of committing fraud is believed to be greater than the anticipated benefit from such a fraud.
| |
| | | | |
| − | While such a consensus has practical merit, there will undoubtedly be situations where merchants are uncomfortable with the level of faith required, and who would gladly pay for a technically-based solution to mitigate their risk.
| + | ==3仕様== |
| | + | この提案は簡単に言えば、トランザクションの当事者は、ベストエフォート型のデータグラムプロトコル（具体的にはUDP）を使用して多数の鉱夫に直接連絡し、トランザクションを送信し、その代わりにデジタル署名されたトランザクションの非公式な承認。デジタル署名は、約束の信憑性を証明するための2つの目的、約束の受取人がコミットメントに「分数確認」の単位を割り当てることを可能にする2つの目的を果たします。 |
| | | | |
| − | Meanwhile, another frequently discussed issue with Bitcoin is the observation that the total volume of transaction fees is orders of magnitude smaller than the block reward. Presently, miners provide no services to individual Bitcoin users, rather, they provide services to the network as a whole. This proposal represents an opportunity for Bitcoin miners to offer a valuable service to customers willing to pay for it, potentially providing a significant enhancement to the total volume of transaction fees collected into new blocks solved by miners.
| + | Bitcoinのトランザクション確認は、通常、整数でカウントされます。今日知られているBitcoinのパラダイムでは、新しい取引は「未確認」とみなされ、0の確認から始まります。それがブロックで最初に見られるとき、それは1つの確認を有する。これに対して、即時部分確認では、トランザクションは0回の確認で開始されますが、個々のコミットメントが受信され、最近のものに基づいて可能性のある既知のハッシュ・パワーと相関されると、ゼロより大きいが1より小さい分数確認カウントがすぐに累積し始めますブロック。 |
| | | | |
| − | ==Specification==
| + | 仕様自体は、次のように3つの異なるプロングに基づいています。 |
| − | This proposal, in a nutshell, is that the parties to a transaction are invited to directly contact a large number of miners using a best-effort datagram protocol (specifically, UDP), send them their transaction, and in return, receive a digitally signed informal acknowledgment of the transaction. The digital signature serves two purposes: one, to establish the authenticity of the promise, and two, to allow the recipient of the promise to assign a weight to the commitments in units of "fractional confirmations".
| |
| | | | |
| − | Bitcoin transaction confirmations are normally counted with integers. In the paradigm of Bitcoin as known today, a brand new transaction is considered "unconfirmed" and starts out with 0 confirmations. When it is first seen in a block, it has 1 confirmation. In contrast, with Instant Partial Confirmation, a transaction starts out with 0 confirmations, but immediately starts to accumulate a fractional confirmation count - greater than zero but less than one - as individual commitments are received and correlated with their likely known hash power based on recent blocks.
| + | ==3.1コインベースの提供== |
| | + | 鉱山者はコインベース取引の表記で即時部分確認（IPC）サービスを提供する意欲を宣伝しなければならない（SHOULD）。表記基準はIPCをサポートし、IPアドレス（IPv4 / IPv6）とUDPポート番号で構成される連絡先情報を含みます。 |
| | | | |
| − | The specification itself rests on three distinct prongs described as follows:
| + | ==3.2 IPCサービスの要求== |
| | + | IPCサービスを要求するため、トランザクションの当事者は、最新の2016ブロックを採掘した鉱夫にUDPメッセージを送信します。複数のブロックに同一の連絡先情報が含まれている場合は、1つのメッセージのみが必要です。メッセージには、部分的に確認されるトランザクション全体、応答のリターンパス（IPおよびUDPポート）、およびリクエスタがトランザクションの当事者であることの証明が含まれます。 |
| | | | |
| − | # Miners SHOULD advertise their willingness to provide the Instant Partial Confirmation (IPC) service with a notation in their coinbase transactions. The notation references support for IPC, and includes contact information consisting of an IP address (IPv4/IPv6) and a UDP port number.
| + | ==3.3 IPC要求に対する応答== |
| − | # In order to request IPC services, a party to a transaction send a UDP message to the miners who mined the most recent 2016 blocks. Only one message is needed whenever more than one block contains identical contact information. The message shall contain the entire transaction to be partially confirmed, a return path (IP and UDP port) for the response, and proof that the requester is a party to the transaction.
| + | 鉱夫は、応答するかどうかを選択することができます。鉱夫が部分的な確認を認める場合、応答は署名されなければなりません（通常、コインベース取引に対応する秘密鍵によって）。マイナーからの部分的な確認応答は、そのトランザクションをブロックに含めるコミットメントと、通常は新しいトランザクションが拒否されるような事前のトランザクションが受信されていないという主張です。鉱山者の視点から、新しい取引が有効でないか、以前の取引と競合している場合 |
| − | # Miners may choose whether to respond. If a miner grants the partial confirmation, the response MUST be signed (typically by the private key corresponding to the coinbase transaction). A partial confirmation response from a miner is a commitment to include that transaction into a block, as well as an assertion that no prior transactions have been received that would ordinarily cause the new transaction to be rejected. If, from the view of the miner, the new transaction is not valid or conflicts with a previously received transaction, the miner MUST NOT offer a partial confirmation. If the miner believes that a double spend is in progress, the miner MAY send a signed message to that effect, indicating a negative confirmation.
| |
| | | | |
| − | Users wishing to use the service must include a transaction fee in their outgoing transactions that satisfies a market-defined threshold established by the miners. By "transaction fee", this proposal refers to the usual and customary transaction fee already offered in transactions, which are denoted by a sum of transaction outputs that is less than the sum of transaction inputs.
| + | ==4下位互換性== |
| − | | |
| − | The fee is not paid to any individual miner or provider of the IPC service, rather, it is entirely possible that the IPC fee may be earned by a miner who does not provide IPC services, simply by being the next one to solve a block shortly after the IPC service is used. During an initial implementation of IPC, the majority of the revenue generated by the few miners supporting IPC will be earned by miners not supporting it. However, the IPC service is likely to impose negligible costs on miners, in terms of computing resources and bandwidth. As all miners stand to benefit from IPC fees, all miners have an indirect incentive to support the IPC service, because as the fractional confirmation anticipated by customers approaches 1.0, the more likely they are to pay to use the service.
| |
| − | | |
| − | Each miner is free to establish his/her own minimum price for providing the service. Miners do not respond to IPC requests when the transaction fee is less than the minimum amount they demand. The higher the fee paid, the more miners will respond to the IPC request, directly influencing the total fractional confirmation that will be achieved in the seconds following the broadcast.
| |
| − | | |
| − | ===Coinbase offer=== | |
| − | Draft: to be refined.
| |
| − | | |
| − | Miners offer the IPC service by including a message in their coinbase. The message MUST contain all of the following:
| |
| − | * the string "IPC"
| |
| − | * an IP address (IPv4, IPv6, or both) and port number
| |
| − | The message MAY also contain:
| |
| − | * The hash of a public key so the client can securely associate a response with recently mined blocks in order to establish hashing power. If this field is absent, the first public key in the coinbase transaction is assumed to be acceptable for signing the message. If the field is present, clients MUST NOT accept coinbase output keys as an acceptable signature.
| |
| − | | |
| − | | |
| − | ===Request for IPC services===
| |
| − | Draft: to be refined.
| |
| − | | |
| − | Parties to a transaction may request the IPC service by sending a UDP datagram to the IP and port listed in the most recent 2016 blocks.
| |
| − | | |
| − | The datagram MUST contain the following:
| |
| − | * The entire transaction to be confirmed (as the miner may not yet have received it via the peer-to-peer network). Miners SHOULD treat an incoming valid transaction arriving as a datagram over the IPC port the same way they would treat an incoming transaction from a peer, including adding it to the in-memory transaction pool and broadcasting it to peers who haven't received it.
| |
| − | * A signature proving that the requestor is one of the parties to the transaction (either the sender or the receiver).
| |
| − | | |
| − | ===Response to IPC request===
| |
| − | Draft: to be refined.
| |
| − | | |
| − | Miners receiving an IPC request MAY respond with a datagram containing the following:
| |
| − | | |
| − | * The transaction identifier in question.
| |
| − | * One of the following status codes:
| |
| − | ** CONFIRMED: The miner considers the transaction valid and commits to include it in the next block.
| |
| − | ** VALID: The miner chooses to acknowledge the transaction is valid from its perspective, but offers no commitment.
| |
| − | ** UNKNOWN: The miner cannot attest to the transaction's validity. Reasons could include that the transaction spends unconfirmed funds, particularly an unconfirmed transaction that the miner hasn't heard about yet. The reason could also be that the transaction fee isn't high enough. (In lieu of responding UNKNOWN, the miner could simply not respond at all.)
| |
| − | ** REJECT: The miner asserts that the transaction is not valid. This is how a double-spend should be signaled.
| |
| − | * A digital signature allowing the client to determine that the response came from the same party that mined recent blocks.
| |
| − | Miners MAY include:
| |
| − | * A field describing the minimum transaction fee that would entice the miner to provide a CONFIRMED response when possible.
| |
| − | | |
| − | ==Backwards compatibility==
| |
| − | This proposal contemplates adding new data to coinbase transactions, which has already been shown quite clearly to be possible without any ill effects on existing clients. The new data is completely optional.
| |
| − | | |
| − | This proposal contemplates providing services completely through out-of-band communication (with respect to the Bitcoin peer-to-peer protocol). No compatibility issues are expected. Nodes are free to disregard any message received through such out-of-band communication without consequence (other than perhaps, of course, a lower fractional confirmation value for the party requesting it).
| |
BIPドラフト - 即時部分確認
このページではBIP（Bitcoin Improvement Proposal）について説明します。
BIPの詳細と作成方法については、BIP 2を参照してください。
wikiページを作成するだけではありません。
タイトル：即時部分確認（IPC）
著者：Mike Caldwell <casascius@mc2cs.com>
ステータス：下書き
タイプ：標準トラック
作成日：2012-07-31
1要約[編集]
BIPは、取引当事者が決定的な予測可能な期間内に鉱夫から取引の信頼性の高い確認を受け取り、サービスを提供するために報酬を支払うことを可能にするスキームを提案する。
このBIPで説明されているサービスでは、1回の確認で平均10分間待機するのではなく、取引者は発行後10秒以内に0.51以上の確認を受け取る可能性があります（ネットワーク上のマイニングパワーの51％を表します）。トランザクションがゼロ確認トランザクションと比較して確認されるはるかに高いレベルの信頼性。
2モチベーション[編集]
Bitcoinで最も頻繁に議論される問題の1つは、取引がネットワークによって確認されるまで取引が二重支出の対象となるという事実であり、そのような確認を受け取るために必要な時間はあまりにも大きく、小売り環境で実用には予測できません。現在のコンセンサスは、商人が小規模な取引の詐欺のリスクを想定するか、商人の損失のリスクが軽微なものを単純に想定し、詐欺行為の費用が信じられている取引の確認のみを主張することがベストプラクティスであるそのような詐欺の予想される利益よりも大きくなるようにしてください。
そのようなコンセンサスには実用的なメリットがありますが、商人が必要とされる信仰のレベルに不快で、リスクを軽減するための技術的な解決策を喜んで支払う人がいることは間違いありません。
一方、Bitcoinで頻繁に議論されるもう1つの問題は、取引手数料の総額がブロック報酬よりもはるかに小さいという観測です。現在、鉱夫は個々のBitcoinユーザーにサービスを提供せず、むしろネットワーク全体にサービスを提供しています。この提案はBitcoin鉱夫が鉱山者が解決しようとする顧客に貴重なサービスを提供し、潜在的に鉱夫によって解決された新しいブロックに集められた取引手数料の総量を大幅に増強することを意味する。
3仕様[編集]
この提案は簡単に言えば、トランザクションの当事者は、ベストエフォート型のデータグラムプロトコル（具体的にはUDP）を使用して多数の鉱夫に直接連絡し、トランザクションを送信し、その代わりにデジタル署名されたトランザクションの非公式な承認。デジタル署名は、約束の信憑性を証明するための2つの目的、約束の受取人がコミットメントに「分数確認」の単位を割り当てることを可能にする2つの目的を果たします。
Bitcoinのトランザクション確認は、通常、整数でカウントされます。今日知られているBitcoinのパラダイムでは、新しい取引は「未確認」とみなされ、0の確認から始まります。それがブロックで最初に見られるとき、それは1つの確認を有する。これに対して、即時部分確認では、トランザクションは0回の確認で開始されますが、個々のコミットメントが受信され、最近のものに基づいて可能性のある既知のハッシュ・パワーと相関されると、ゼロより大きいが1より小さい分数確認カウントがすぐに累積し始めますブロック。
仕様自体は、次のように3つの異なるプロングに基づいています。
3.1コインベースの提供[編集]
鉱山者はコインベース取引の表記で即時部分確認（IPC）サービスを提供する意欲を宣伝しなければならない（SHOULD）。表記基準はIPCをサポートし、IPアドレス（IPv4 / IPv6）とUDPポート番号で構成される連絡先情報を含みます。
3.2 IPCサービスの要求[編集]
IPCサービスを要求するため、トランザクションの当事者は、最新の2016ブロックを採掘した鉱夫にUDPメッセージを送信します。複数のブロックに同一の連絡先情報が含まれている場合は、1つのメッセージのみが必要です。メッセージには、部分的に確認されるトランザクション全体、応答のリターンパス（IPおよびUDPポート）、およびリクエスタがトランザクションの当事者であることの証明が含まれます。
3.3 IPC要求に対する応答[編集]
鉱夫は、応答するかどうかを選択することができます。鉱夫が部分的な確認を認める場合、応答は署名されなければなりません（通常、コインベース取引に対応する秘密鍵によって）。マイナーからの部分的な確認応答は、そのトランザクションをブロックに含めるコミットメントと、通常は新しいトランザクションが拒否されるような事前のトランザクションが受信されていないという主張です。鉱山者の視点から、新しい取引が有効でないか、以前の取引と競合している場合
4下位互換性[編集]
