monadの開発を手伝ってくれないか？
1 ：脇山Ｐ名人教士聖人(NTI)：2018/08/26 23:41:45 (6年前) 1.40255254MONA/4人
golangでmonacoindの互換クライアントを作成しています。
https://github.com/wakiyamap/monad
これを何に使うかと言いますとLightningやatomicswapに利用できます。
それでdevelop016ブランチにてmonacoind 0.16.2 に載る新しい機能の移植を行っているのですが、
皆さんの助けをお借りしたいなと思いましてトピックを立てました。
現在alert checkpoint機能の導入を目指しています。
該当のmonacoindでのコミットはこちらです。
https://github.com/monacoinproject/monacoin/commit/fc4f4b31771a7de863503faa51e44a93e6c4cdb2
https://github.com/monacoinproject/monacoin/commit/cfe4ff215077bc3bbba5e1f11131bf7e805a38fb
https://github.com/monacoinproject/monacoin/commit/f10cf9f788166d9719cafac6a09db21fa5fb30ab
2 ：脇山Ｐ名人教士聖人(---)：2018/08/26 23:41:57 (6年前) 0MONA/0人
現在迷っていることとしては、
monadには現在alertがwatanabe氏から本当に来たものか検証する機能がありません。
そのためのverify機構を先ずは実装しようかと考えているのですが、
msgalert.goのBtcDecode、349行目辺りかな……？と言う感じで自信が持てないです。
https://github.com/wakiyamap/monad/blob/develop016/wire/msgalert.go#L349
ここじゃね？とかありましたら教えていただけると幸いです。
ちなみにmonacoindだとここら辺です。
https://github.com/monacoinproject/monacoin/blob/master-0.15/src/alert.cpp#L151-#L173
導入の是非についてはトピック違いと思われますので他でお願いします。
monadの使用者にとっては現状、選択自体が出来ないのが不味いと思われます。
(まぁmonacoindをポート違いで起動させてそのcoindをwhitelistに叩き込むとかは出来ますが……)
3 ：nao20010128四段(GUJ)：2018/08/27 00:20:17 (6年前) 39.114MONA/2人
verifyの中身はBTC系伝統のECDSAなんですね
流れ的にはBTCのトランザクションと同じっぽいですね
SerializedMessageのSHA256と署名から公開鍵を導出→watanabe氏が提示した公開鍵と照合
という感じなのかな
場所はコメントから推測するに合ってると思います
https://github.com/wakiyamap/monad/blob/develop016/wire/msgalert.go#L319
4 ：脇山Ｐ名人教士聖人(NTI)：2018/08/27 01:08:28 (6年前) 0MONA/0人
>>3
思いっきりコメントに書いてありましたね（白目
見逃してました。ありがとうございます。
5 ：いまは亡き無職業者BOT八段錬士(KNI)：2018/08/27 09:44:01 (6年前) 39MONA/1人
事前知識薄いまま
リンク先をざっと1分だけ眺めた感じだと
検証は func (msg *MsgAlert) BtcDecode(r io.Reader, pver uint32, enc MessageEncoding) error
の中ではなく
これを呼び出した直後のコードに入るはずっぽい
https://github.com/wakiyamap/monad/blob/fcb1fb0f7dc628eaacdb1ab4ab025ccc5ed68072/wire/msgalert.go#L350 で
このメソッドを持つインスタンスに署名が格納されるっぽいので
それを使うっぽい #しらんけど
6 ：いまは亡き無職業者BOT八段錬士(KNI)：2018/08/27 10:09:28 (6年前) 0MONA/0人
それっぽい呼び元は
func (p *Peer) inHandler()
っぽく
中で p.cfg.Listeners.OnAlert(p, msg) を読んでいる箇所があるっぽい
現行 OnAlert は func newPeerConfig(sp *serverPeer) *peer.Config で nil 定義されているっぽいが
おそらくここが hook point #っぽい #しらんけど
7 ：脇山Ｐ名人教士聖人(NTI)：2018/08/28 05:32:02 (6年前) 0MONA/0人
>>5 >>6
ありがとうございます。
server.goの中で確かにnilになっていますね。
中継しない&ファイル名がserverと書いてあったので、
他のpeerに送信しないと言う意味で私は取っていたのですが、
自身にも中継しないという意味にも取れますね。
となるとserver.goの方でverify+dbへの登録作業を行わせる形になるのかな……
8 ：いまは亡き無職業者BOT八段錬士(EPH)：2018/08/28 06:58:09 (6年前) 11.4114MONA/1人
>>7
Alert メッセージのパーズはするけれども中身の処理はしないっぽい
> となるとserver.goの方でverify+dbへの登録作業を行わせる形になるのかな……
server.go の中でも良いっぽいし
上流への追随作業を考えると別ファイルへの切り出し検討もっぽい
9 ：脇山Ｐ名人教士聖人(DPB)：2018/08/29 05:30:29 (6年前) 0MONA/0人
>>8
別ファイルの切り出しは後で行います。
とりあえず動かしたい……
vPubAlertkeyをchaincfgで呼び出せるようにして、
server.goにhookを書いて、
sha256dっぽいのがあったのでとりあえずぶち込んでみました。
明日本当にsha256dの関数か調べたいと思います。
署名確認方法は……まぁ何とかなると信じたいところです。
https://github.com/wakiyamap/monad/commits/develop016
10 ：脇山Ｐ名人教士聖人(DPB)：2018/08/30 06:53:21 (6年前) 11.411439MONA/1人
署名確認できるようにしました。
https://github.com/wakiyamap/monad/commit/320e0928744dc772b26f82d25940f5bc52780cb8
適当にparams.goのAlertPubKeyを変更するとverify失敗になるのでまぁ多分問題ないんじゃない……っぽい。
次に進みます。
11 ：脇山Ｐ名人教士聖人(DPB)：2018/08/31 04:13:08 (6年前) 0MONA/0人
monadに追加すべきconfigについて考えています。
パッと見た感じだと以下の二つです。
-cmdcheckpoint
-alertnotify
alertnotifyはstatusbarに通知するか否かのconfigっぽいのですが、
そのstatusbar自体が存在しないので無視して行こうかと考えます。
12 ：脇山Ｐ名人教士聖人(DPB)：2018/08/31 04:33:51 (6年前) 1.1411439MONA/1人
現時点でのmonadに追加予定の残りの機能は以下の通りです。
１．cmdcheckpointでalertを無視するか否かを選別
２．alertからvolatilecheckpointDBにcheckpoint書き込み
起動時点のinitに存在しているCheckInvalidKey()については無視します。
globalAlertDBについてはセキュリティインシデント対策が現時点の俺には出来そうにないので、
保有せずにvolatilecheckpointを参照してキーが存在するか否かだけで考えるつもりです。
13 ：脇山Ｐ名人教士聖人(DPB)：2018/09/01 02:02:17 (6年前) 0MONA/0人
1のcmdcheckpointの値をmonad.confでtrue or false 変更出来るようになりました。
https://github.com/wakiyamap/monad/commit/e863fda75590f75e2a3880e068fbaae6874fcc6e
とりあえずこれで本丸の2を仕上げる材料が揃ったかと思います。
次はalertの中身を解析して、何を何処に入れるかを考えていきます。
14 ：脇山Ｐ名人教士聖人(DPB)：2018/09/01 07:23:20 (6年前) 0MONA/0人
globalAlertDBについてなのですが、
もし秘密鍵を奪われた際に、alert機能を無効化する必要があります。
その際にはalertのpayloadの中にあるIDの値が最大値の場合は
これでAlert機能を終了するという機能を用います。
該当はここら辺 https://github.com/monacoinproject/monacoin/blob/master-0.16/src/alert.cpp#L193
それを考えるとglobalAlertDBを用いない場合、再起動時にその保持したデータが消えてしまうため、
やはり何らかの形で持っておく必要がありそうです。
一応、署名の確認が終了しているもののみを保存するようにすれば安全かなとは思っています。
ですが何をDBの中に保持しておこうか・・・・・・と言う懸念が発生しています。
payload全部保持はメンドクサイにもほどがある。
checkpointにしか使わないならIDとコメントだけ持っておけばいい気もします。
15 ：脇山Ｐ名人教士聖人(DPB)：2018/09/03 02:10:18 (6年前) 0MONA/0人
とりあえず送られてくるalertの形式は確認できたのですが、
https://github.com/monacoinproject/monacoin/issues/47
find_valueに該当するものがgolangにはいらっしゃらないようなので
とりあえず正規表現でheight及びhashを持ってこようかと考えています。
https://regex101.com/r/wqcQeO/2
と言う訳でregexpに突っ込んでみたのですが、
false(引っかかってない)と返ってくるのでどうしようかね・・・・・・という状況です。
testjson := `{"height": 10000,"hash": "34139e2361b4758b9410ee6f8af047d1018eb7540ae346321e91cd0e6580ebbd"}`
r := regexp.MustCompile(testjson)
peerLog.Infof("json1 %v", (r.MatchString(`" *height *" *: *([0-9]+)`)))
16 ：脇山Ｐ名人教士聖人(DPB)：2018/09/03 05:08:45 (6年前) 0MONA/0人
regexpの扱いで検索文字列と正規表現を置く場所が逆でした。
次に進みます。
testjson := `{\n"height": 10000,\n"hash": "34139e2361b4758b9410ee6f8af047d1018eb7540ae346321e91cd0e6580ebbd"\n}`
r := regexp.MustCompile(`(?m)" *height *" *: *([0-9]+) *,.*\n? *" *hash *" *: *"([0-9a-f]+)"`)
peerLog.Infof("json1 %v", (r.Match([]byte(testjson))))
17 ：いまは亡き無職業者BOT八段錬士(CNT)：2018/09/03 06:04:18 (6年前) 3.9MONA/1人
>>14 これ monad 側の永続的な状態保持は要るのだろうか?
"URGENT:" メッセージを受けるとクライアントは常に機能無効化されるので
一定期間メッセージ配信側が継続的にメッセージを流す想定なのでは?
(これを流す自体になった際の新クライアントは公開鍵を変更するので
署名検証に失敗し過去バージョン向けの "URGENT:" メッセージは新バージョンでは無効)
ワタナベ氏に運用方針聞いたほうがよいのでは…っぽい
18 ：脇山Ｐ名人教士聖人(DPB)：2018/09/03 07:32:23 (6年前) 0MONA/0人
globalAlertDB(IDとcommentオンリー)を追加しました。
https://github.com/wakiyamap/monad/commit/62ec097f67df59cc497b42decee8e080068acf17
>>17
これを流す際の事態と言うのは下記の2つが上げられるかと思います。
1.checkpointを配信する必要がなくなった時
2.alertの秘密鍵が漏れた時
1に関してはこのままの方針で問題ないかと思いますが、
無職botさんが心配されているのは2の場合と言うことですかね？
この場合は、IDが最大数の値を記録するので変なalertを送られた際も無効化されるかと考えています。
その際にはmonacoind自体のアップデートも行われるかと思いますので、
monad(公開鍵変更後)アップグレード後に
globalAlertDB自体をいったん削除(.monad/data/<net>/globalalert_level)と言う流れで問題ないかなと
19 ：脇山Ｐ名人教士聖人(DPB)：2018/09/03 07:36:11 (6年前) 0MONA/0人
>>17
書き込み後に気づきましたが、
確かに新しいalertを発信する際には
秘密鍵が違うalertを送る可能性が十分にありますね……
ちょっと確認してきます。
20 ：いまは亡き無職業者BOT八段錬士(CNT)：2018/09/03 07:51:42 (6年前) 11.4114MONA/1人
alert.cpp の当該コードのコメントに "so an attacker can't send" とあるので
1 は考慮に無く(または副次的で)むしろ本命は 2 っぽいのではと
いずれにしても旧バージョンの新規インストールが予想されるあいだは
継続的に "URGENT:" alert が流されるでしょうし
であれば受信の事実を永続化する必要はあるのだろうかと
globalAlertDB 自身は有っても良いというか
書き終えているなら敢えて消す必要もないっぽいですが
独自実装部分が多いと
今後 btcd への追随でつらくなりはしないかなと
21 ：いまは亡き無職業者BOT八段錬士(CNT)：2018/09/03 07:53:37 (6年前) 0MONA/0人
(秘密鍵がバレていても URGENT メッセージで攻撃を無効化できるのが
この実装のミソだと思うっぽい)
22 ：テクノブレイカーＷ六段錬士(YRI)：2018/09/03 20:18:49 (6年前) 11.4114MONA/1人
久々のAskでキンチョーの夏
>>15
goでjsonを扱うときはencoding/jsonパッケージを使ってください。
たぶんこんな感じになると思います
import (
"encoding/json"
"fmt"
)
23 ：テクノブレイカーＷ六段錬士(YRI)：2018/09/03 20:19:00 (6年前) 11.4114MONA/1人
type CheckPointData struct {
Height int `json:"height"`
Hash string `json:"hash"`
}
byteComment := ([]byte)(strComment)
cpd := new(CheckPointData)
if err := json.Unmarshal(byteComment, cpd); err != nil {
return err
}
fmt.Println(cpd.Height)
fmt.Println(cpd.Hash)
24 ：テクノブレイカーＷ六段錬士(YRI)：2018/09/03 20:21:14 (6年前) 11.8014MONA/2人
globalAlertDBは今は無効なキーでしか使っていない。
他のコマンドでも使うかも的なものですが、これ以上の機能追加は権限が強くなっていくのでなるべくやらない方向で。
（時期的に「送金取り消し機能」等が望まれるとは思いますが、原則取引には介入しない）
>>20
アラートは他者から受信して初めて発動するので、再起動直後は無効にならない。
また、(nID == maxInt)のメッセージもキャンセルすることが可能。
という2点から、一度でも受信に成功していれば後のスパムでコマンドがかき消されても…と、微妙にマシになったつもりなのがInvalidateKey。
alertはもう少し弄る予定。（キーの追加を考えてます）
25 ：いまは亡き無職業者BOT八段錬士(IFX)：2018/09/03 21:20:13 (6年前) 1.14114MONA/1人
>>24
> アラートは他者から受信して初めて発動するので、再起動直後は無効にならない。
ええ、そういう想定のコードですよね。
私はそれでお漏らし対策としては十分かなという印象を今は持っています。
(想定を遥かに超える古いバージョンを使い続けたノードが負うリスクは、ノード管理者の自己責任)
とはいえ InvalidateKey のほうが意図が判りやすいとは思いますし、今後さらに良い案が出た場合には、都度節操なく改良案に賛同するとも思いますけれども。
26 ：脇山Ｐ名人教士聖人(DPB)：2018/09/04 10:37:54 (6年前) 0MONA/0人
正規表現からjsonに書き換えました。
現状、2人の会話が理解できない状態なのでプログラム自体見直す時間をください。
27 ：いまは亡き無職業者BOT八段錬士(ZPN)：2018/09/04 11:41:11 (6年前) 4MONA/2人
>>26 どうやらまだ仕様が確定していない(方針は確定している)っぽいので
手を一旦休めて
人間ドックにでも行ってくる機会にしたほうが #っぽい #健康第一
28 ：いまは亡き無職業者BOT八段錬士(ZPN)：2018/09/05 12:38:13 (6年前) 0MONA/0人
>>24
> （キーの追加
2-of-2 マルチシグネチャにした上で署名ノードを2つに分け
署名ノードへの攻撃成功率を減らすということでしょうか?
それとも (MAIN / SUB とあるので) 2つの鍵には
階層的な意味付けが今後予定されている？
29 ：脇山Ｐ名人教士聖人(DPB)：2018/09/07 04:29:53 (6年前) 0.00114114MONA/1人
とりあえず今までのクソコードを多少ましにして、
mainとsubのキーを追加しました。
https://github.com/wakiyamap/monad/commit/531be84372a9c33df1a79727d440892cee04b32a
30 ：脇山Ｐ名人教士聖人(DPB)：2018/09/16 03:31:46 (6年前) 0.00114114MONA/1人
GlobalAlertDBを除いて
https://github.com/wakiyamap/monad/commit/5eb5ffb6c4f56b6f786c1a064eedca8d6a0af48e
AlertKeyの判定だけを持っておくAlertKeyDBを追加しました。
https://github.com/wakiyamap/monad/commit/66fd667a6727b57e25d0a5e252eb779abd64ff0f
大体似た様な動きをするようになったかと思います。
あとはGlobalAlertの細かい判定を追加していきたいと思います。
31 ：脇山Ｐ名人教士聖人(DPB)：2018/09/17 02:31:24 (6年前) 0MONA/0人
判定の処理を厳格化、あとコードの整理
https://github.com/wakiyamap/monad/commit/d3bcd458f3ac37f2efdb2a5f71691593252478ee
dnsseedの書き換え(0.16.2のみ返す)
https://github.com/wakiyamap/monad/commit/3b5bf637908da031d795d3cfa9a660a4648fa75a
後は実践でテストして問題なさそうならmasterブランチにmergeして今回の対応を終わりたいと思います。
一旦の区切りと言うことで、皆さんご協力ありがとうございました。
32 ：脇山Ｐ名人教士聖人(DPB)：2018/09/17 03:41:39 (6年前) 0MONA/0人
twitterで突っ込みがあったので修正。
[]stringのlenは要素数になるので初期の値である"[]"と同値かで判断させるように変更しました。
https://github.com/wakiyamap/monad/commit/805145ce21ae8a20abb6672845c52fc783d41ca7
33 ：脇山Ｐ名人教士聖人(SFH)：2020/06/05 19:50:50 (4年前) 0MONA/0人
続きはこっちで
https://web3.askmona.org/179
お気に入り
新規登録してMONAをもらえた
本サイトはAsk Mona 3.0に移行しましたが、登録すると昔のAsk Monaで遊ぶことができます。