トランザクション スクリプトの質問
22 Res. 65.61255254 MONA 4 Fav.
1 ：Monant.Gox四段：2014/06/29 01:02:50 (9年前) 0MONA/0人
https://docs.google.com/document/d/1D_gi_7Sf9sOyAHG25cMpOO4xtLq3iJUtjRwcZXFLv1E/edit
こちらの資料でトランザクションスクリプトの勉強をしています。
質問ですが
「Simple Transaction」の項目で以下のスクリプトが書かれています。
<signature> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
１．まず <pubkey>をハッシュしたものを<pubkeyHash>と比較して同じであればよい
２．その後<pubkey>で<signature>を検証
疑問ですが、わざわざトランザクションのスクリプトに<pubKey>と<pubKeyHash>を入れている理由がピンときません。署名の検証に必要なのでpubkeyだけだし、pubkeyから計算できるhashを比較しているのはなんのためでしょうか？
良い回答に20mona差し上げます
2 ：藤原華幽院村正五段：2014/06/29 04:37:47 (9年前) 20MONA/1人
この項の内容は、署名の検証の説明ではなく、トランザクション生成に関する説明です。
Inputのトランザクション(一つ前のトランザクション)に、<pubKeyHash>=公開鍵のハッシュ値が入っています。
次のトランザクションを生成するためには、<pubKeyHash>から<pubKey>を知る必要があります。
もし、<pubKey>を知ることが出来れば、その<pubKey>を使用して署名できるので、次のトランザクションが生成できます。
ってな感じの、miningで<pubKey>を掘り当てた場合のお話しが書いてあります。
<pubKeyHash>(ハッシュ値)から<pubKey>(ハッシュ化される前の値)を見つけるのが困難という特性を利用した、
bitcoinの根幹を簡略に説明しています。
3 ：Monant.Gox四段：2014/06/29 17:48:53 (9年前) 0MONA/0人
>>2
ありがとうございます。
hashはinput TXの方にあらかじめ書かれているのですね。
マイニングがpubkeyを当てる行為というのが、知りませんでした。
（nonceをいろいろためして、00000000****となるハッシュ値を得たらマイニング成功なんですよね？）
その時に、<pubkeyhash>の元となるpubkeyも明らかになるということでしょうか？
4 ：Monant.Gox四段：2014/06/29 17:52:05 (9年前) 0MONA/0人
もう少し細かく書いてあるドキュメントは、bitcoin wikiなんでしょうかね。
5 ：タロ無し六段：2014/06/29 19:21:51 (9年前) 3.9MONA/1人
何か間違った状態で納得しそうになっちゃってるので突っ込み入れます。
>>2さんも間違って覚えてしまっていますよ。
具体的に、「pubkeyhashからpubkeyを知る必要～」あたりから正しくないです。
6 ：Monant.Gox四段：2014/06/29 22:11:09 (9年前) 0MONA/0人
>>5 さん
正確な理解を解説お願いします
mona払いますんでｗｗ
7 ：藤原華幽院村正五段：2014/06/30 02:43:48 (9年前) 0MONA/0人
>>5
突っ込みありがとうございます。嘘を書いていました。
資料をパッと見で適当なことを書きましたw
勉強して来ましたので、訂正します。。
>>2 の内容は忘れてください。
miningでは、公開鍵の秘密鍵を見つける作業を行っており、
秘密鍵を最初に見つけた人が行っているのが、「Simple Transaction」の内容です。
この資料の「Generation Transaction」は、
トランザクション生成は<signature>、<pubKey>があれば出来ますよということを説明していて、
「Simple Transaction」では、実際のトランザクション生成を簡易な例で示しています。
トランザクション生成における、スクリプトの動作説明とでも言えばいいでしょうか。
8 ：藤原華幽院村正五段：2014/06/30 02:44:12 (9年前) 0MONA/0人
>>7 続き
で、質問の「<pubKey>と<pubKeyHash>を入れている理由」についてですが、
確かに、<signature>を<pubKey>で開くことで、<signature>を検証することができます。
Input TX にある、<pubKeyHash>とは、送信者のアドレスです。
このとき、<pubKeyHash>(アドレス) が<signature>を行った人のものであることも確認する必要があります。
bitcoinアドレスには、以下の特徴があります。
・公開鍵はアドレスから特定することができる
・アドレスは公開鍵から作成することができる
特定した<pubKey>(公開鍵)で、<pubKeyHash2>(アドレス)を作成し、<pubKeyHash>と<pubKeyHash2>が同じであれば、
<pubKeyHash>は<pubKey>で作成されたことが分かります。
その後、<pubKey>で<signature>が検証できれば、
<signature>を行った人の<pubKeyHash>アドレスからコインを送信したと言えます。
9 ：Monant.Gox四段：2014/06/30 04:58:01 (9年前) 0MONA/0人
>>7 「マイニングで秘密鍵を見つける」というのはおかしくないですか？秘密鍵が見つかってしまえばその人の残高がすべて奪われてしまうように思うのですが。
私の理解ですと、マイニングではトランザクションとnonceのハッシュを総当たりで計算して一定のハッシュ値の列（0がいくつも続く列）を得たら成功、という認識なので、秘密鍵を見つけるというのはどういう意味でしょうか？
10 ：タロ無し六段：2014/06/30 09:34:17 (9年前) 0MONA/0人
うーん、どこから説明したものかと考え込んでしまっていました。
ちょうど2chに貼られていたのですが、この資料はどうでしょうか。
Bitcoinを技術的に理解する
http://www.slideshare.net/kenjiurushima/20140602-bitcoin1-201406031222
富士ゼロックスで電子署名関連の仕事をしている方が、日本ネットワークセキュリティ協会の
Bitcoin勉強会で発表したスライドらしいです。
11 ：Monant.Gox四段：2014/06/30 14:58:58 (9年前) 0MONA/0人
>>10 一応そちらも今ちらちらみてますが、結構わかりにくいので、シンプルなドキュメントのほうを先に読もうかなーと思ってました。
そっちを勉強したほうがいいですかね
12 ：藤原華幽院村正五段：2014/06/30 15:31:54 (9年前) 5MONA/1人
>>10 資料ありがとうございます。
>>1 のgoogledoc と https://en.bitcoin.it/wiki/Transactions のみを参照していたので、
出たとこ勝負をやってるので、おかしな事を書いています。申し訳ない。。
>>9 マイニングについては、スライドの65より、その認識であっていそうです。
スライドの16,17から、秘密鍵が分からなくてもいいですね。
寧ろ、秘密鍵が見つかってしまうと、残高が奪われてしまいますね。
スライドを読む前の私の妄想だと、difficultyによって秘密鍵を定義して、
それをマイニングで見つけていると思っていましたが、違っていたようです。それだと仕組みが破綻してます。
>>10 この資料の元となっている情報をご存知ないですか？
私が妄想していた仕組みよりショボかったので。。
13 ：びりある五段：2014/06/30 17:00:33 (9年前) 20.00114114MONA/2人
支払い時に入力するアドレスは、<pubKeyHash>に一対一に対応しているため、
「アドレス=pubKeyHashへの支払いです」とトランザクションに書き込んでいる(scriptPubKey)だけです。
pay-to-pubkeyといって公開鍵に対して支払うようなトランザクションもあります。
（ほとんど使われていませんが）
https://en.bitcoin.it/wiki/Script
も参照してください。
14 ：Monant.Gox四段：2014/06/30 19:25:00 (9年前) 3.9MONA/1人
>>12 色々ご尽力ありがとうございました。
おそらく
>>13 のもなとれさんの解説で合っている（私は納得）と思います
pay-to-pubkeyではpubkeyだけで支払ができていますね。つまりそれでも可能だけど、一応確認のためにハッシュ値と確認している？のでしょうか
「今は使われていない方法」だというのは、ミスが入ってしまう可能性があるからなのですかね？（どんなミスかよくわからないのですが）
リンクにあった説明の
「The disadvantage of this transaction form is that the whole public key needs to be known in advance, implying longer payment addresses, and that it provides less protection in the event of a break in the ECDSA signature algorithm.」
が関係してきそうですね
15 ：藤原華幽院村正五段：2014/06/30 20:58:07 (9年前) 0MONA/0人
なるほど、
<pubKeyHash>を入れないと、事前に全ての公開鍵とアドレスを知っておく必要があって、
さらに、ECDSA署名アルゴリズムが破られると脆弱性を生じると。。
16 ：Takenaka五段：2014/07/01 09:41:28 (9年前) 8.9MONA/1人
ちょっと情報が混乱しているようなのでまとめてみます。
太郎さんはBobからもらったコインを花子さんへ送金するとします。
トランザクション1: Bob→太郎
トランザクション2: 太郎→花子
トランザクション2を検証する時に実行されるスクリプトは下記のAとBをつなげたものです。
A. トランザクション2(太郎→花子)のscriptSig(太郎のもの):
<sig> <pubKey>
B. トランザクション1(Bob→太郎)のscriptPubKey(太郎のpubKeyHash):
OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
outputにハッシュ値を使うのは単に短く済むからです。less protection云々のくだりは同じアドレスを何度も使用している現状ではあまり意味がありません(pubKeyが判明しているため)。
17 ：Monant.Gox四段：2014/07/01 09:59:59 (9年前) 0MONA/0人
>>16 最終的には公開鍵で秘密鍵の検証をしていますね。
公開鍵ハッシュの比較をまず最初にするのは、わざわざいきなり公開鍵と秘密鍵のverify検証(長い時間と手間がかかる）するのをスキップできるから、と考えて間違いないでしょうか？
18 ：Monant.Gox四段：2014/07/01 10:32:03 (9年前) 0MONA/0人
というか、データが大きくならないためですかね
19 ：Takenaka五段：2014/07/01 10:40:27 (9年前) 0MONA/0人
>>17
どちらからやっても結果は変わりませんが軽い処理から行ったほうがいいでしょうね。
20 ：ブチャラティ初段：2014/07/02 00:01:40 (9年前) 0.0114114MONA/1人
今日専門の人に聞いて理解しました
output(AさんBへの支払）：コインをBに渡すときに Bの<pubkeyhash>を計算してトランザクションデータに含める
input（Bの受け取り）: コインを受け取る時に、自分のpubkeyとそれから計算pubkeyhashが、output中のものと等しいことを確認して、それが自分のものになる
ハッシュ値はかぶらず、ハッシュ値からpubkeyを求めることもできないため。Bが受け取れることになる。
以上の理解です
21 ：Takenaka五段：2014/07/02 09:37:38 (9年前) 3.9MONA/1人
詳細を議論する前にトランザクションの概要を確認してみましょう。
太郎さんのアドレスAから花子さんのアドレスBへ送金するトランザクションについて考えます。
アドレスがハッシュ値かどうかは本質的ではないため「アドレス=公開鍵」とします。
1. トランザクション作成(送金):
太郎さんは公開鍵Aの秘密鍵を使いトランザクションに署名します。
2. トランザクション確認:
公開鍵Aを使いトランザクションの署名を確認します。
確認できたトランザクションはブロックチェーンに取り込まれます。
3. 受け取り:
花子さんはブロックチェーンに該当するトランザクションを見つける事で
太郎さんからコインを受け取った事を確認します。
1,2では送金先Bについて書式以外はなにも確認しません。持ち主がいないアドレスにも送金できます。いろいろ省いていますがこんな感じです。
22 ：Monant.Gox四段：2014/07/08 04:01:45 (9年前) 0MONA/0人
そういえば「Anyone can spend」のトランザクションが、個人の信用や基金に使えるとか書いてあったんですがよくわからなかったです。
https://en.bitcoin.it/wiki/Script#Provably_Unspendable.2FPrunable_Outputs
Anyone-Can-Spend Outputs
Conversely a transaction can be made spendable by anyone at all:
scriptPubKey: (empty)
scriptSig: OP_TRUE
With some software changes such transactions can be used as a way to donate funds to miners in addition to transaction fees: any miner who mines such a transaction can also include an additional one after it sending the funds to an address they control. This mechanism may be used in the future for fidelity bonds to sacrifice funds in a provable way.
お気に入り
新規登録してMONAをもらえた
本サイトはAsk Mona 3.0に移行しましたが、登録すると昔のAsk Monaで遊ぶことができます。