P2SH²

提供: tezos-wiki
移動先: 案内、 検索

P2SH2 '（また、' P2SH ^ 2 'と書かれています）は、安全に剪定できないブロックチェーンの部分にユーザが任意のデータを格納することを難しくする提案です。

問題：データをハッシュに格納する[編集]

Bitcoinでは、ユーザー（ウォレット）が公開鍵にビットコインを受け取り、公開鍵を生成した同じ秘密鍵で作成された暗号署名を提供することで、ビットコインを使用することができます。しかし、いくつかの理由から、ほとんどのウォレットは、代わりに、支払を保証するために使用されるすべての公開鍵およびその他の情報を一意に識別する「ハッシュ」と呼ばれる一連の20または32バイトのビットコインを受け取ります。 Bitcoinアドレスは、コピーと貼り付けが簡単な形式のメタデータで囲まれた、このハッシュです。

一意の識別子（ハッシュ）を生成するコードは、公開鍵やその他の情報をハッシュに変換できますが、ハッシュを公開鍵などの情報に戻すことはできません。これがハッシュと呼ばれる理由です。元のデータは細かく断片化され、混ぜ合わされ、圧縮されて元のようには見えないが、依然としてそれを識別します。

ハッシュで保護されたビットコインを使用するには、公開鍵とそのハッシュを作成するために使用されたその他の情報のコピーを提供し、暗号署名またはその他の必要な支出情報を提供するだけです。これはBitcoinトランザクションの圧倒的多数がこれまでに行ってきたことです。

しかし、Bitcoinsにアドレス（ハッシュ）を支払うと、フルノードとマイナーは、あなたや他の誰かがハッシュを生成するために使用された公開鍵やその他のデータのコピーを持っていることを確認するためのチェックは行いません。この検証の欠如は、ブロックチェーンにデータを格納するために過去に乱用されていました。

たとえば、ブロック138,725（2011年7月30日）では、<ref> Sassamanが記念されたものでしたか？、Chris Moore、Bitcoin StackExchange、7 2012年4月に検索された2018-01-05 </ ref>暗号化技術者Dan KaminskyはブロックチェーンにASCIIアートをレンダリングするために78の20バイトのハッシュのようなものを支払った0.78BTCを支払った<ref> [https://bitcointalk.org /index.php?topic=33618.0 Len "rabbi" Sassamaへの敬意、BitcoinTalk.orgディスカッションスレッド、2018-01-05 </ ref>（アートの部分再現については、このセクションの最後を参照してください）。ここで使用されているハッシュ関数の技術的特性を考えると、Kaminskyが公開鍵を使ってこれらの疑似ハッシュを生成しなかったことを確実に推測できます。代わりに、彼は擬似ハッシュのバイトを自分の望むやり方で並べ、ビットコインを支払うために必要な公開鍵（または秘密鍵）を誰も知らなかったことを知っています。

Kaminskyのような人々がBitcoinを破壊したい場合、Bitcoinのほとんどのユーザーは問題とは考えません。しかし、問題は、Bitcoinプロトコルが疑似ハッシュに費やされたビットコインが使えないと判断する方法がないため、すべてのフル・ノードはこれらの支払いを有効かつ消費可能とみなします。彼らは費用がかかるように見えるため、ノードはディスクスペースを節約するためにこれらの支払いを切り捨てることができません。これにより、完全なノードを操作するコストが上昇し、Bitcoinを分散化するのに役立ちます。また、鉱夫（特に）は、これらの支払いに関する情報を高性能データベースに格納して、支払いを行っているブロックをすばやく検証できるようにする必要があり、鉱業の固定費を上げ、規模の経済を作り出します。小規模な鉱夫に比べて大規模な鉱夫を支持する

この理由から、Bitcoinの多くのユーザーは、このタイプのハッシュ乱用を阻止しようとし、代わりにブロックチェーンにデータを格納したいユーザーは、OP_RETURN（nulldata）技術を使用して、現代のフルノードが知っているプルーニングの方法とデータベースに格納する必要はありません。

しかし、少量のデータの場合、ハッシュフィールドにデータを格納するコストは、OP_RETURN出力にデータを格納するコストとほぼ同じです。さらに悪いことに、ほとんどの現在のBitcoinウォレットはOP_RETURN出力よりも疑似ハッシュを支払う方が簡単です。一部のクライアントでは、OP_RETURN出力よりも疑似ハッシュで格納されているとブロックチェーンからデータを取得する方が簡単です。したがって、Bitcoinプロトコルがハッシュフィールドにデータを格納しないようにすることができれば、それはまだ素晴らしいことです。

以下は、カススキーハッシュを使用してブロックチェーンに格納されたKaminskyデータの一部を再現したものです。<ref> [1]ペーストビン、回収2018-01-05 </ ref> 

 ASCIIバーナンキ
:::。:::::。:::。::。：
：：。：  '：：'：
：。：_.__ '：。：
：_、^ "" ^ x、：
'x7' `4、
 XX7 4XX
 XX XX
 X1、xxx、、xxx、XX
（ '_、+ o、|、o +、 "
 4 " - ^ 'X" ^ - ' "7
 l、（））、X
 ：Xx、_、xXXXxx、_、XX
  4XXiX '-___- `XXXX'
   4XXi、_IiXX7 '
  、 '4XXXXXXXXX ^ _、
  Xx、 "" ^^^ XX7、xX
W、 "4WWx、_ _、XxWWX7"
Xwi、 "4WW7" "4WW7"、W
TXXWw、^ 7 Xk 47、WH
：TXXXWw、_ "）、、wWT：
:: TTXXWWW lXl WWT：</ pre>


P2SH²ソリューション[編集]


2013年4月、Bitcoinの開発者であるGregory Maxwellは、<ref> To txoutsの任意のデータ格納を阻止する---究極のソリューション、Bitcoin-Developmentメーリングリスト（Archive.org経由）、2013-04-10 </ ref>を思想実験として、<ref> [https：// lists。 linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015505.html Re：Bech32 andP2SH²、Gregory Maxwell、bitcoin-devメーリングリスト、2018年1月6日、2017-01-06hの検索</ ref>そのアイデアは単純です：誰かがあなたにBitcoinアドレス（ハッシュ）を与えると、それをもう一度ハッシュして、そのハッシュ（アドレスハッシュではなく）をブロックに追加するトランザクションに追加します鎖。第2（「外側」）ハッシュは、第1（「内側」）ハッシュを一意的に参照し、それ自体が公開鍵および支払いを保証する他の情報を一意的に参照する。

たとえば、次の疑似ハッシュを内側のハッシュとして送信する場合、

<pre> ASCII BERNANKE </ pre>

ブロックチェーンに追加される外部ハッシュは、

<pre>r I i E 6</ pre>

それはあなたのために表示されない場合は、任意の洗練されたASCIIアートと、住所型ハッシュのためのフィールドのブロックチェーンに任意の非ハッシュデータを追加するための他のスキームを破壊するランダムな不器用さです。

Maxwellの提案では、ノードが外部ハッシュ（トランザクションの一部として）と内部ハッシュ（別個のメタデータとして）の両方を含む場合、ノードは未確認トランザクションのみを中継し、ブロックチェーンを意図した外部ハッシュが保持されていないことを証明する内部ハッシュを操作するブルートフォースによっていくつかのデータを外部ハッシュに追加することが可能であるため、少なくともデータはあまりありません。



迂回とその緩和[編集]


中継ノードは、ディスクドライブから疑似ハッシュへの支払いを永久に払うことができず、P2SH ^ 2形式のポリシーを一般に実施する可能性があるため、補償されていない追加コストがかかりますが、[[手数料] P2SH ^ 2ポリシーを回避します。ブロックチェーンに単一の疑似ハッシュ支払いを追加することはそれほど大きな害を及ぼさないため、鉱夫が迂回のための競争力を受け入れることは一般に価値があります。その代わりに、多くの鉱夫の集計された損害のそれぞれが、長鎖のブロックチェーンに多くの擬似ハッシュ支払いを追加し、効率的に分散されたままにするために鉱山者が迅速にアクセスする必要のある支払確認データベースを遅らせる。

マクスウェル氏は、鉱夫がP2SH ^ 2を迂回しているとよく見られる場合、内部ハッシュが不明なトランザクションを多く含むブロックを受け取ったノードは、他の鉱夫によって作成された苦情ブロックを有利にするために、

これは、異なるノード、特に高稼働時間のノードとオンラインに戻ったばかりのノード（またはブロックモードや他のリレー制限機能を使用するノード）間で一時的な合意の相違につながる可能性があるため、議論の余地があります。



更新された提案[編集]


Bitcoinの現在のアドレスはすべて、すでに内部と外部のハッシュを含んでいますが、これは主に中本哲氏の初期の設計選択の遺産です。これにより、Bitcoin-DevメーリングリストのLuke Dashjr氏（Bech32とP2SH²）が、<ref name = "bech32-p2sh2"> Bech32 andP2SH²リスト2018-01-04、retrieved 2018-01-05 </ ref>を使用して、P2SH ^ 2プロポーザルのわずかな変形を既存のシステムへの強化されていないアドオンとして導入し、その後誰もが持った後に強制的なシステムに移行するアドオンを採用しました。
＃内側のハッシュのみを含む新しいアドレスタイプを導入する
＃ウォレットが新しいアドレスタイプを受け入れている場合、外側のハッシュを生成し、それを支払う
＃後で、ノードが外側のハッシュを支払うトランザクションと一緒に内部ハッシュを中継することを許可します（内部ハッシュはブロックチェーンに含まれない）
＃かなり後に、ほとんどすべてのリレーされたトランザクションが内側と外側のハッシュの両方を含んでいるとき、内側のハッシュなしでトランザクションのリレーを阻止し始めます
＃後で、内部ハッシュが以前に見られなかったトランザクションが多すぎるブロックを阻止する可能性があります



現在の状態[編集]


オリジナルのP2SH ^ 2提案は2013年の初めにさかのぼりますが、これまで議論の対象となっています。 BIPとしてまだ提案されていません。



関連情報[編集]


  • 適用された暗号化技術者Peter Toddは、Bitcoinブロックチェーンを介した公開の証明が効果的に高価になるかどうかという文脈でP2SH ^ 2について議論しました。[ref> [https://petertodd.org/2014/setting-the 2014年12月12日、ピーター・トッド（Peter Todd）PeterTodd.orgは、2017-01- 05 </ ref>
    • 

  •  Bitcoinの開発者であるLuke Dashjrは、新しいbech32アドレス形式にP2SH ^ 2のようなロジックを追加できることを示唆しています[1]注：Dashjrの提案はbech32の仕様BIP173、 「ドラフト」から「提案済み」のステータスに移行し、いくつかの財布が既にこのドラフト案を実施した後、そのような重要な変更には遅すぎる可能性があります。
    • 

  •  Gregory Maxwell氏は、P2SH ^ 2がどのように改良されたNamecoinデザインの一部であり、また、「ハッシュ値である可能性のあるペアリング暗号を使用する」スキームをどのように持っているかを説明しています。 //en.bitcoin.it/w/index.php?title=User:Gmaxwell/namecoin_that_sucks_less&oldid=44707 Namecoin that sucks less]、Gregory Maxwell、Bitcoin Wiki、2014年3月2日、検索2017-01-05 </ ref> </ IRCログ、IRCログ、Gregory Maxwell、IRC </ ref>
  1. ↑ 引用エラー: 無効な <ref> タグです。 「bech32-p2sh2」という名前の引用句に対するテキストが指定されていません
「http://tezos-wiki.jp/wiki/index.php?title=P2SH²&oldid=19732」から取得