アタッチについて【Discordまとめ】

この会話はDiscordの#japaneseで行われた会話です。
因みにSlackからDiscordへの完全移行が公式よりアナウンスされました。
皆様もSlackではなくDiscordにご参加ください。

IOTAコミュニティへの参加方法(Discord)

2017.09.05
fujiken – 2018年1月24日 午前8時19分
@sola コメントありがとうございます。
> 私はどうしても送りたいトランザクションは承認されるまで何度でもREATTACHしておりました
↑これなんですがWP内にも同じようなこと書いてたと思いますが理解できなくて。。そもそもREATTACHてなんでしょう?(編集済)
fujiken – 2018年1月24日 午前8時20分
そのattachが。。(ググれ)
トランザクションの発行のことですかね(編集済)
これとかを見ると、空のトランザクションを送ることをattachと呼ぶみたいですね。REATTACHはそれを繰り返すことかな?
https://iota.stackexchange.com/questions/603/what-does-the-attach-to-tangle-button-do
What does the ATTACH TO TANGLE button do?
On the Receive screen in the IOTA Wallet there’s a button labeled “Attach to Tangle”:
I thought attaching to tangle only applies to transactions, not addresses. What does this button do?
murasamelabo – 2018年1月24日 午前9時10分
attach は確かに難しい概念ですよね。。。

間違っているかもしれませんが、見ていると、本質的には新しいアドレスを生成する行為であって、ペンディングを直接的に解決する行為ではないような気がしています。

この時にも、空のトランザクションを生成して、他者を承認するので、tangle が伸びて、結果的に目的(元々の送金を含む)のトランザクションの承認と累積荷重が増加する可能性が上がるってことなのかな。

fujiken – 2018年1月24日 午前9時19分
@murasamelabo 空トランザクション生成時に、自身が発行したトランザクションを承認して自作自演で累積荷重を上げてるわけでは無いんですかね?(それやると攻撃者と同じか?w) 直接的には、承認が進むようには思えないですね。
murasamelabo – 2018年1月24日 午前9時21分
https://matthewwinstonjohnson.gitbooks.io/iota-guide-and-faq/getting-started/reattach-vs.html
アタッチ(少なくとも、ウォレットのボタンに実装されている)自体は、先ほどいったようにアドレスの生成のようですが、リアタッチは、もともとのトランザクションを再度別の tip を承認して、 tangle の別の個所にくっつける事なのかな。

Reattach: The process of reattaching a transaction is simply doing the proof of work and tip selection process to reattach the transaction to a different part of the Tangle. Reattach once every 30 minutes that a transaction remains pending, and then if still pending after 5 reattachments be sure to contact the sender to verify that the transaction wasn’t double spent.
+
Chances of confirmation are significantly increased with each reattachment

fujiken – 2018年1月24日 午前9時25分
なるほど。アタッチとリアタッチは全然違う意味合いみたいですね。
例えば、何かの拍子に人気の無いTangle部分にTXを発行したら、全然承認進まないので全く別のところに配置して承認してもらおうという事なんですね
murasamelabo – 2018年1月24日 午前9時28分
そうなるんじゃないかと思います。
詳しいだろう @ABmushi さんあたりの解説が聞きたいですがw
fujiken – 2018年1月24日 午前9時30分
WPでは、「時間内に最初の承認が起こらなかった場合,追加の空のトランザクションでトランザクションを促進するのは発行者/受領者の両者か一方かにとって良いアイデアである.」とあって、空のトランザクションを発行すれば承認進むよ的な事書かれているので、ここらへんも理解したいです
murasamelabo – 2018年1月24日 午前9時37分
https://matthewwinstonjohnson.gitbooks.io/iota-guide-and-faq/getting-started/why-is-my-transaction-pending-for-so-long.html

How can we contribute to making confirmation times speedier within the framework presented above?

We can increase the number of transactions on the Tangle by encouraging organic growth of users on the network! Adoption is the way forward here. OR we can spam the network with our full node. Spamming has been common practice by many of the early adopters in months past, but the devs have requested that we refrain from spamming so that they can get a good feel for the network without external factors like inflated TPS.

take – 2018年1月24日 午前9時37分
@murasamelabo @fujiken
狭義の意味でいえばアドレス生成自体はライブラリをつかってオフラインでできます
アタッチはオフラインで生成したアドレスを含んだトランザクションをネットワークにブロードキャストすると同時にPoWして他のtipsを承認することで、他のtipsから自身の承認を促すこととで、IOTAネットワーク上でアドレスを有効にすることを促すことかなぁと思います(編集済)
murasamelabo – 2018年1月24日 午前9時41分
@fujiken さん
spam(おそらくこれが、空のトランザクションをたくさん発行する事だと思いますが)はトランザクションを進める役に立つようですね。ただ、開発者から、(試験、計測とかのためかな) 現在は控えるようにという通達みたいですね。

@take さん
ありがとうございます。オフラインで生成しただけ(つまりアタッチされていなくても)でも、送信者は宛先として使えるのですか?(編集済)

fujiken – 2018年1月24日 午前9時45分
IOTAにはアドレス有効化の概念があるんですね。Bitcoinでは、アドレスはオフラインで生成され、マイナーによってブロックに格納された段階で取引としてある程度認められるので、有効/無効の概念が無いので対照的ですね
take – 2018年1月24日 午前9時46分
@murasamelabo @fujiken
うん?ちょっと待ってください。今、お二人のお返事で自分の言っていることが正確なのかとても不安になりました。
IOTA宇宙”という奇妙な解釈-シードとアドレスを空間軸から考える
IOTAではシードとアドレスが用いられ、送金が行われています。この原理は具体的にはどのような仕組みになっているのでしょうか。空間座標を持ちいて、わかりやすく解説します。

こちらABmushiさんの記事なのですが、参考になるかもしれません。
スナップショットの後に、GUIウォレットが更新されたとき、ひたすら新しいアドレスをTangleにアタッチすることで残高回復したと思います。
その原理は、予め財団のほうで(この記事でいう軸上の)アドレスにiotaを”配置”してくれるため、新しいアドレスをアタッチする(つまり広義でのアドレスを生成する)ことで、予めiotaが配置されたアドレスに到達し残高が回復するということらしいです。(編集済)

murasamelabo – 2018年1月24日 午前9時53分
アップデートされると、index も 0 からになるのかな
fujiken – 2018年1月24日 午前10時0分
おお!すごく分かりやすい!!3次元で考えると理解進みます
murasamelabo – 2018年1月24日 午前10時5分
本質的にはオフラインとか、オンラインとか そんな概念がないんですね。
全アドレスははじめから存在して
各ユーザー(seed) から必ず生成できるので、
そこを順番に見ていくことで、過去のトランザクションで自分に送られた物を全て統合すると、残高って感じなのかな
そして、一回、送信に使ったアドレスが使えないのは、おつりを次のアドレスに移しているからなのか。
fujiken – 2018年1月24日 午前10時10分
上のABmushiさん解説だと、各人の残高のあるアドレスは常に1個(過去のアドレスの残高は0)になってますが、自身のindex=2から自身のindex=1へ送金したり、相手の過去のindexに送金すると、それが成りたくなりますね。
take – 2018年1月24日 午前10時10分
@murasamelabo
仰る通りです。ライブラリでは、指定したシードに関連付けられたindexを0から始めてある程度のところまでインクリメントして、たくさんのindexを参照して残高を取ってきてくれます。
@fujiken
各シードに関連付けられた、残高のあるアドレスはたくさんあってもいいはずです。ちょっと記事読みなおしてきます
murasamelabo – 2018年1月24日 午前10時15分
予想ですが、残高のあるアドレスは複数あってもいいとおもいますが、ウォレットで残高を確認(attach) するたびに次ぎの (index+1) のアドレスに移したりして、全残高を確認し終えたころには、全て一か所にまとまっている とかなのかな。
そうしないと、送金の時に凄い不便な気がする
take – 2018年1月24日 午前10時17分
@murasamelabo
いえ、残高は統合されてひとつの場所(アドレス)にまとまることはありません。
なので、送金の際にひとつのアドレスの残高で足りない場合は、インプットとして複数のアドレスを指定することもあります。(編集済)
fujiken – 2018年1月24日 午前10時24分
例えば、
①アドレスA(index=1)に100i存在
②アドレスA(index=1)からアドレスB(index=1)に50i送金
③余った50iはアドレスA2(index=2)に移動
④アドレスB(index=1)からアドレスA(index=1)に20i送金
⑤余った30iはアドレスB(index=2)に移動
⑤アドレスA(index=1)に20i、アドレスA2(index=2)に50i、アドレスB(index=2)に30i存在

スナップショット実行時、アドレスA(index=1)は残高が残っているが②のトランザクションは削除されるのかな?(編集済)

take – 2018年1月24日 午前10時26分
@fujiken
相手の過去のindexに送金するなのですが、セキュリティ上の問題ですが、ご存知の通りWinternitz one-time signatureを用いているので、そのindexを用いて生成されたアドレスが秘密鍵で署名されていなければ、送金先の受け皿として機能しますが、署名がされている場合は受け皿として機能しません。前回の資金凍結はこれをユーザが守らず秘密鍵の再利用が行われたため、安全策として実施されました。
なので
④アドレスB(index=1)からアドレスA(index=1)に20i送金
は行うことができません。(編集済)
アドレスがころころ変わるのって、仕様なので仕方ないのですが、ほんとうに面倒ですよね笑
これがホントの「仕様がない」?(編集済)
(日本の気温を更に下げていく〜)
murasamelabo – 2018年1月24日 午前10時34分
受け取り専用の VR アドレスとかなんとかして用意できないものかな。

SEED と特殊なkey でハッシュしたアドレスで、そこあてに送られた送金トランザクションは自動的に、受け皿として有効ないずれかのアドレスに自動でマッピングしてくれる のような
ほかの Seed を持つ通常のアドレスと 衝突する可能性があるから駄目か。

ABmushi – 2018年1月24日 午前11時29分
@murasamelabo @fujiken @take
長くなってしまいますが補足程度にお答え致します。
> オフラインで生成しただけ(つまりアタッチされていなくても)でも、送信者は宛先として使えるのですか?
使えます!しかし、残高を計算する時、デフォルトのウォレットはindex=0から順番に+1していってTangleにアタッチされていないindexまで検索して終わりです。

検証していませんが、スナップショット(残高0でアタッチされているアドレスを削除する)の後に残高が変動するかもしれません。(index=0に100i、index=3に50i入っていたとすると、デフォルトのウォレットはindex=1が0の時点で検索を止めるので、ウォレットに表示される残高は100iになります。三回アドレスをアタッチすればindex=3にたどり着いて残高を全額回復します。)

> 全アドレスははじめから存在して各ユーザー(seed) から必ず生成できるので、そこを順番に見ていくことで、過去のトランザクションで自分に送られた物を全て統合すると、残高って感じなのかな
その通りです!アドレスは全てはじめから利用可能です。(極端な話、AAA…AAAもありです。)しかし、Seedを使ってそのアドレスに対して署名を作ることができないと、デポジットされた残高を使うことはできません。

>予想ですが、残高のあるアドレスは複数あってもいいとおもいますが、ウォレットで残高を確認(attach) するたびに次ぎの (index+1) のアドレスに移したりして、全残高を確認し終えたころには、全て一か所にまとまっている とかなのかな。
そうしないと、送金の時に凄い不便な気がする
ウォレットの送金の際には、やはりindex=0から送金額以上の額が集まるまで入力アドレスを自動で検索しています。
一箇所にまとめるためには手動でやるしかなさそうですね…

>受け取り専用アドレス
送金に使う入力アドレスですが、手動で設定できます。なので募金用アドレスを使わないようにすることもできます。(毎回やるのは不便ですが。)ただ、やや技術的に突っ込んだ話になりますが、ライブラリで入力アドレス検索はgetInputsという関数で行われています。その関数にはstartという検索開始地点を設定する引数があります。受け取り専用アドレスをindex=0と決めたならstart=1を渡すようにコードをいじれば、index=0は使わないということも実現できます。

一応getInputsです。
api.js

/**
*   Gets the inputs of a seed
*
*   @method getInputs
*   @param {string} seed
*   @param {object} options
*       @property {int} start Starting key index(開始地点のindex)
*       @property {int} end Ending key index(終了地点のindex)
*       @property {int} threshold Min balance required(探している合計金額)
*       @property {int} security secuirty level of private key / seed
*   @param {function} callback
**/
api.prototype.getInputs = function(seed, options, callback) {
    ...

アドレス厄介ですよね…
ものすごく長くなってしまいました(汗)失礼いたします。
ちなみにアドレスAAA…に5iotaありましたw
https://thetangle.org/address/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Address AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

murasamelabo – 2018年1月24日 午前11時35分
凄い返信がきたw ありがとうございます!
fujiken – 2018年1月24日 午前11時39分
@ABmushi ありがとうございます!
アタッチという行為は、次のindexのアドレスを生成する認識なんですが、何故こうしたオペレーションが必要なんでしょうか?Winternitz署名の性質上、送金アドレスは使い捨てる必要があるためでしょうか?
ABmushi – 2018年1月24日 午前11時42分
@fujiken 送金額を引き出す入力アドレスの署名を作る際にPrivate Keyが一部露出してしまうためです。
take – 2018年1月24日 午前11時43分
@ABmushi
ありがとうございます!
理解が深まりました
以前、まさに寄付用アドレスが気づかないうちにインプットに使われてて開店休業状態に陥りました笑
ABmushi – 2018年1月24日 午前11時45分
アタッチは単に次のindexのアドレス(残高=0)をTangleに存在させるだけですね。昔はスパミングの手段でしたが最近はもうアタッチ=残高復旧作業でしか使われませんねぇ。
リアタッチは孤児Tangleの一部になってしまったtxをもう一度メインTangleにアタッチし直す作業だと思います。”リアタッチは30分ごと”という基準も孤児Tangleが出来上がるまでの時間だと考えると納得がいきます。(編集済)
fujiken – 2018年1月24日 午前11時50分
@ABmushi アタッチを行なうと、
①index+1のアドレスが生成される
②①の空のtxがTangle上に生成
という動作が起きるということでしょうか。①は秘密鍵漏洩の抑止策となると②の必要性はどういったところでしょう?
ABmushi – 2018年1月24日 午前11時53分
index=0とindex=3にそれぞれ100iあったとすると、ウォレット上では残高は100iになってしまいます。アドレスがTangle上に存在しなくなるまで、オフラインでアドレス生成してTangleに検索(オンライン)かけてウォレットは残高を計算します。(編集済)
そのため、空のtxの存在意義はウォレットの仕様変更次第で無意味になるかもですね…(例えばindexをオフラインで保存するなど)(編集済)
fujiken – 2018年1月24日 午前11時57分
@ABmushi なるほど。公式ウォレットの仕様に依存しているんですね。ちょっと上の方でも話にあがりましたが、以前はスパミングの手段で用いられていたけど使われなくなったのは何故でしょうか?空のtx生成しても意味無いじゃんという結論になったとか?
ABmushi – 2018年1月24日 午前11時59分
当時のフルノードのキャパでは、処理しきれなかったとかなんとかと聞いた覚えがあります。
ABmushi – 2018年1月24日 午後12時0分
最近はどんどん個人のフルノード(しかもメガ級のスペックのものが)増えているので、いつかスパミングができるかもですね
fujiken – 2018年1月24日 午後12時1分
理論的にはスパミングで累積荷重が安定増加するけど、full nodeのスペック的にヤバそうなんで控えてねという感じなんですね(編集済)
色々理解出来ました!IOTA奥が深いです!!
ABmushi – 2018年1月24日 午後12時3分
1つのtxが2つのtxを承認しているだけの単純構造の繰り返しなのに、奥が深くて柔軟ですよね〜。ニューラルネットワークに似たものを感じざるを得ません。(編集済)
(また記事にできそうな盛り上がりですね)
tawago – 2018年1月24日 午後1時12分
補足として、送金自体はアドレスがtangleにアタッチされてなくても可能です〜。ただABmushiさんが述べているようにindexが順飛ばしされたアドレスを使用するとウォレット自体が確認しにいってくれないために、できる限り毎回アタッチしましょう。となっております。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です