送金サンプルJSを作成しました。

Takanobu ()
LightWalletを参考に、送金の動作確認をするためのサンプルプログラムを作成しました。
JSに不慣れな方もいるかと思うので、必要最低限の実装にとどめています。

使い方:
1.以下のGitHub URLからmijin-SimpleTransferをダウンロードしてzip解凍してください。
https://github.com/mediaprogramer/mijin-SimpleTransfer

やったことないGitHub使ってみました。使い方間違えてたらごめんなさい。
1つのhtml ファイルと 3つのjsファイルが出てきます。送金に最低限必要なファイル構成です。

2.simple_transfer.html をテキストエディタで開き、各自設定値を修正します。
修正が必要なパラメータは、
送信元秘密鍵、送信先アドレス、送信先公開鍵、transaction announce URLの4つです。
送金金額等はjs に固定値(10)で埋めているので、仕組みが分かってきたら適当に修正するなどして影響範囲を確認してくだ さい。

3.simple_transfer.html をブラウザより実行してください。
nginexなどのサーバ起動の必要はありません。別途サーバを準備してHTMLファイルをアップする必要 もありません。
実行の仕方がよく解らない方は、html ファイルをブラウザにドラッグ&ドロップしてください。
(chrome ブラウザで検証済みです)

4.送信ボタンが表示されるので、ボタンをクリックします。
見た目には何も起こりません。chrome の場合はF12でコンソールを開いておけば、送信時のjsonテキストが出力されます。
LightWallet で送金元アカウントを別タブなどで開いておけば、送金される様子が見れるでしょう。
また、account/get コマンドなどで送信前、送信後のbalance を確認するのもよいでしょう。



takao ()
ありがとうございます!

LHJ ()
感謝致します。テストをしてみたところ、"FAILURE_SIGNATURE_NOT_VERIFIAB LE"と応答メッセージが届いて送金できず、当方の検証環境依存かな?と調査してみます。他は問題ない と当 方も考えます。Chrome , Firefox 同じ挙動で、最初は署名(シグネチャ)の SHA3-256/512 のところからな?とアタリはつけたもののシンプルで綺麗なコードですね(にっこり)

Lightwallet との違いは以下のとおりでした。(F12とFirefoxアドオン「RESTClient」を駆使)

Lightwallet は
 POSTの際、要求ヘッダがContent-Length: 486
貴殿作成の JS は 
 POSTの際、要求ヘッダがContent-Length: 386

引き続き自己調査致します。重ね重ねありがとうございました。

takao ()
素晴らしい!

matsuou1 ()
以下に、トランザクションのPOSTの仕方について流れを書きました。
http://qiita.com/matsuou1/items/cf0b5641c7a3d419d49c

上記の送金サンプルJSと合わせて見ていただけると、理解が深まるかと思います。
間違い等あれば、ご指摘して頂ければと。

Takanobu ()
送金サンプルJSの修正を行いました。

生成されたprivateKey の種類によっては 送金がうまいこといきません。
頭に00 などがついているprivateKeyなど

transfer.js にて fixPrivateKey を追加しました。 LightWallet にはそもそも存在していたものです。

ご報告まで。

https://github.com/mediaprogramer/mijin-SimpleTransfer

Takanobu ()
送金サンプルJSを使って手数料を変えて送金実験してみました。

totalFee で計算された通りの手数料で送金:送金成功
totalFee で計算されたよりも少ない手数料で送金:送金失敗! "FAILURE_INSUFFICIENT_FEE"
totalFee で計算されたよりも多い手数料で送金:送金成功 お釣りは返ってきません

パラメータを変更による影響を一つずつ確認しながらの作業が続きそうです。。。
ご参考まで。

Takanobu ()
お待たせしました。続編です。
mijin-SimpleMosaicCreator を作成しました。LightWallet を使用せずにNamespace , mosaic を作成できます。

https://github.com/mediaprogramer/mijin-SimpleMosaicCreator

前回同様、設定の必要なパラメータはhtml ファイルにまとめております。
今回は少しだけ複雑です。

SENDER_PRIVATE_KEY 作成元アカウントの秘密鍵
SENDER_PUBLIC_KEY 作成元アカウントの公開鍵

is_top_level_namespece_creating ネームスペースを作成する場合、トップレベルかどうかの区分(true = トップレベルにネームスペースを作成)
PARENT_NAMESPACE 親ネームスペース名(トップレベルに作成したい場合はnull)
NEW_NAMESPACE 作成したいネームスペース名
NEW_MOSAIC 作成したいモザイク名
MOSAIC_DEF_IN モザイクを作成したいネームスペース名
MOSAIC_PROPERTIES モザイク作成時に必要なパラメータ

となります。
なお levy の定義、手数料送信先、備考など行いたい場合は namespace_mosaic.js を各自修正してください。

テスト時は自己責任でお願いします。
不明な点などありましたら、このスレッドまで。

Takanobu ()
連投すみません。
MOSAICのテスト送信プログラムも作成しました。

https://github.com/mediaprogramer/mi...MosaicTransfer

コメントは後日します。土日頑張る方はどうぞ。
あと、手数料は多く払い込んでも戻ってこないので、自己責任でお願いします。

(追記)注意:このソースコードはバグが含まれます。
以下の新しいプログラムをご利用ください。

https://github.com/mediaprogramer/mijin-SimpleMosaicTransfer2

古いプログラムは、ほどなく削除します。

Takanobu ()
こんばんは。金曜日です。
土日頑張る人のために、またしてもぶん投げ退社です。

今回は、matsuou1 さんに感謝。というか、修正部分はほとんどmatsuou1さんの箇所のみです。
いよいよマルチシグに対応です。作成したアカウントをマルチシグアカウントに変換できます!

でも注意してください。miijin無料期間中に与えていただいたアカウントをマルチシグにしてしまうと、
その署名者からしか送金ができなくなります。そして、そのサンプルプログラムはまだ作成していません。

つまり凍結です。凍結してしまいます。ご注意ください。

事前に捨てアカウントを準備して試してみてくださいね。

mijin-SimpleMultisigConverter
https://github.com/mediaprogramer/mijin-SimpleMultisigConverter


次はいよいよ中ボス、マルチシグでの署名にチャレンジ。
これができれは、おおよそいろんなアイデアの実装ができるのではないでしょうか?

私もいくつかアイデア浮かんでますが、その公開はまた別の機会に。
乞うご期待!

LHJ ()
解析結果しばしお待ちください。(なぜか Markdown 取り消しがない)

マルチシグ成功可否の判断は添付図でOKでしょうか?
図でイメージすると良いかなと思いました!

Takanobu ()
うぁあああああ、きょうFINOLABでイベントあったんですね。
http://peatix.com/event/155795

数か月に一度ぐらいの東京出張でのんきに日本橋あたりを歩いてました。

Takanobu ()
マルチシグにConvert で失敗する件、いろいろと試しておりますが、未だ原因をつかめておりません。
失敗する場合必ず、
”FAILURE_SIGNATURE_NOT_VERIFIABLE”
のメッセージが表示されます。

1 of 1 のマルチシグConvertは比較的高確率で成功します。
それ以外のパターンになると、ほとんど成功しませんが、ごくまれに成功します。

一時、privatekey が 66桁のアカウントの場合のみConvertに成功するのかと思いましたが、気のせいでした。
似たような経験された方、いらっしゃいませんでしょうか?

Takanobu ()
マルチシグにConvert で失敗する件、謎が深まるばかりです。

13:30 ごろまで調子よく、どんなアカウント(使用済みのもの、手数料をまだ送金していないもの)に対しても、それなりのエラーメッセージが出ていたのですが
つまり、サーバ側で暗号を復号化して中身が読めていたということ、
13:40 あたりから再び”FAILURE_SIGNATURE_NOT_VERIFIABLE”のメッセージ一点張りになってしまいました。

うーん。

Takanobu ()
なんとなく、状況が見えてきました。
transactionの時間はあまり関係なかったです。
もちろんprivatekey の桁数も関係なしです。

こんなところで悩んでいるひともいないかと思いますので、
もし、同じところで詰まったー、という方がいらっしゃいましたらご相談ください。
たぶんそのうち修正 or 改善されると思います。

Takanobu ()
Is there a JS SDK for NEM?
https://forum.nem.io/t/is-there-a-js-sdk-for-nem/2068

NEMフォーラムの方で、JSライブラリについての議論がありますね。
LightWalletはangular.jsに依存してるとか。

送金サンプルJSは他のライブラリに依存せずに、mijinやNEMへのアクセスを忠実に検証できるライブラリです。
最近、メンテしてませんが。。。複数アセットの同時送金とか、マルチシグ送金とか、もう出来てるのでおいおい公開していきます。


日本勢、かなり先行ってますよ~。

Takanobu ()
LightWallet で算出される手数料について。

現在、アプリサーバ(mijin にとってはクライアント) にてnem.coreをベースにして手数料計算をしていますが、
やはり、LightWallet の手数料計算は少し雑なようです。
2.0xem で十分なはずの手数料ですが、2.5xem振り込んでました。

LightWallet使ってる人の中で、どれぐらいの人がこの事実を把握してるのでしょうか。
(手数料を多くしておけば、トランザクションが多発した場合に優先的に処理されるようですが)

Takanobu ()
light wallet にも使用されている nacl-fast.js にiOS safari では使用できないバグが見つかりました。後日修正しますが、取り急ぎ。

Takanobu ()
nacl-fast.js の動作不具合について修正しました。

問題点はUint8Array型の配列について iOS safari 上での slice関数で落ちてしまうようです。

ですので、sliceを使わず、以下の記述のところを

// hasher.update(privHash.slice(32));
直接ループを回して作成することにしました。
var slicedPrivHash = new Uint8Array(32); for (var i = 32; i < privHash.length; i++) { slicedPrivHash[ i - 32 ] = privHash[i]; } hasher.update(slicedPrivHash);

Takanobu ()
お待たせしました。リクエストがありましたので、Multisig Transfer のサンプル版を公開します!

https://github.com/mediaprogramer/mijin-SimpleMultisigTransfer

今回は少々設定項目が多めです。
実際にMosaicを所有しているアカウント(Aliceと言えば早いですかね)のアドレス、公開鍵、
署名したいアカウントの秘密鍵、公開鍵が必要です。

そんなものなくてもマルチシグ送信できる!という方は教えてください。
こんかいのサンプルは2段階のマルチシグを検証しています。1段階だと単純すぎるのと、3段階は以下同様なので2段階にしました。

これで、私の出せるサンプルjsは以上となります。
現在はjavaでの開発に移行しており、今後カタパルトの動向次第でc++に行くかもしれません。

LHJ ()
こんにちは、ド素人の LHJ さんです。
以下について 本 POST で意見交換させていただければ幸いです。

現在の nem / mijin API は、作成した namespace や mosaic を削除することができません。具体的には DELETE がないのです。
恥ずかしながら namespace を多段階層で作成してしまい、6月末も近づき、整理整頓しないとなと思いまして放置プレイです。

仮に、DELETE で namespace を削除できた場合、発行されていた mosaic(独自トークン)はどうなるのか?の謎もあります。
このあたりに挑戦された方、こうなるんだろう?と予想されている方は何卒、ご意見いただきたくお願い申し上 げます。

※ ブロックチェーンの衝撃 購読済みだと思われるので、ページ数なども使いながらでも OK としましょうかw

Takanobu ()
久しぶりに本トピックへの投稿です。

mijinで開発していると、残高の確認って結構面倒くさいですよね。
API叩くとjson で読みづらいですし、LightWalletもnginx 起動したりして、なんかゴミ残ったりすると再起動するまでちゃんと動かなかったり。。。
というわけで、ブラウザでかんたんにトランザクション情報の見れるプログラムを作成しました。

https://github.com/mediaprogramer/mijin-SimpleViewer

まず、最初にファイル中のURLパラメータをご自身のIPアドレスに変更してください。
そして、ブラウザで以下のように実行します。

file:///C:/work/…/simple_viewer.html?address=MANODEFTDLFG….

ローカル起動でも問題なしです。chrome で動作確認してます。
今のところ、API: /account/transfers/all のみ対応しています。
気が向いたらGET系のAPIに対応していきます。

よろしくお願いします。

Takanobu ()
続報です。

SimpleViewerを大幅に修正しました。
特定アドレスの
/account/transfers/all
/account/get
/account/mosaic/owned
/account/unconfirmedTransactions

が一括で閲覧できます。これがローカルファイルで動くなんて革命的に便利です!w
もちろんマルチシグ対応です。otherTransがundefinedでなければレコード内を改行して同パ ラメータ値を出力します。
出力しているパラメータは私が現在必要としているものを中心に選んでいますので、各自変更して試してみてく ださい。

https://github.com/mediaprogramer/mijin-SimpleViewer

annating ()
spam

Takanobu ()
すいません、私も原因がつかめていませんが、
確かにContent-Length: 386 で送信していますが、無事送金できています。

あと、もう一か所ハードコーディングしている場所があって、
transfer.js の92行目あたり、
CURRENT_NETWORK_ID = 96
という箇所があります。

ここは、
http://xx.xxx.xxx.xxx:7895/node/extended-info
で取得できるjson の networkId を入れとうまく動くようです。
何度試しても96 だったので、ハードコーディングしましたが、
環境によって異なるようでしたら、プログラム修正します。

よろしくお願いします。

matsuou1 ()
お疲れ様です。
私もテストしてみたところ、同じく&quot;FAILURE_SIGNATURE_NOT_VERIFIABLE&quot;で送金できませんでした。

色々試した結果、RECIPIENT_PUBLIC_KEYに送信元の公開鍵を指定したところ無事送金できました。

transfer.jsのdata.signerに指定する公開鍵は、送信先の公開鍵ではなく、送信元の公開鍵ですね。
lightwalletの実装見ても、senderPublicKeyが指定されています。

※ ちょうど似たようなものを作ろうと思ってたので、非常に助かりました!

Takanobu ()
すいません、すいません!間違ってました。
GitHubの方も修正しました。ご指摘ありがとうございます。

ちなみに、nacl-fast.js はそのまま再利用。KeyPair.js は require.js に依存している部分を少々修正しました。
transfer.js の中にconvert.js の一部と services/Transactions.js の一部を実装しています。

nacl-fast が実装されていない言語への移植は少々手間かもしれませんね。

LHJ ()
おはようございます。

> GitHubの方も修正しました。ご指摘ありがとうございます。
修正版で送金できること確認致しました。

Thank you so much, everyone !

takao ()
せっかくなので是非とも本フォーラムに投稿をば。

takao ()
すばらしい!!!

LHJ ()
すばらっ!

Takanobu ()
先週金曜日にぶん投げ投稿失礼しました。

さてさて、いよいよ肝心のMOSAIC送信ですが、(みなさんついてきてますかー?それとも置いてけぼり?)
今回もHTMLに変更パラメータをまとめております。

MOSAIC_INFO 送りたいモザイクを namespaceId: ネームスペース名、name : モザイク名 で指定します。
Ligtht wallet では、何種類も指定可能ですが、Sample 版では1種類のみです。

MOSAIC_SUPPLY モザイクを定義したときに準備した供給量を指定します。そっちが知ってるでしょ?っていう気もしますが。
MOSAIC_DIVISIBILITY モザイク定義時に小数何桁まで定義したかを指定します。エコ仕様として0にしてます。別スレッド参照。
SEND_QUANTITY 送りたいモザイクの量ですね。Sample 版では1度に送信できるモザイクは1種類のみですので、
SEND_MULTIPLIER と掛け合わせたものが、最終的に送信される量となります。

実際の処理ですが、 xem の transfer とそれほど違いはありません。
大きく異なるのは、手数料計算です。

まず、calcXemEquivalent function で 手数料候補を計算するようです。

8999999999 / MOSAIC_SUPPLY * SEND_QUANTITY * SEND_MULTIPLIER/ Math.pow(10, MOSAIC_DIVISIBILITY + 6);

何を意味するのか全くわかりませんね。xemの供給量、mosaic の供給量と送りたい量が関係するようですね。
次に以下の3つからどれが最大になるかを計算します。

10 - 先ほど計算した値
2
Math.floor(Math.atan(先ほど計算した値 / 150000.0) * 3 * 33

送信量が多いと、ボリュームディスカウントでatan で丸め込まれるようです。
送信量が少ないと、ミニマムチャージで2 が選択されます。
上記以外は、 (10-先ほど計算した値)になる感じでしょうか。

そして最後に選ばれた最大値から 5/4 が計算されます。
何でしょう  こ れ は ??

おそらく、計算機の小数点の誤差でぴったりfee を送金すると失敗するかも、
と考えて敢えて5/4 を送っているのかもしれませんね。想像ですが。

というわけで、なるべ くLight Walletに忠実な形でfee 計算しておりますが、
万が一バグで膨大な手数料を支払うことになってしまっても、返ってきませんので、
サンプルプログラムの実行は自己責任でお願いします。

takao ()
実際には、内部XEM送金よりこちらのMOSAIC送金の方が重要ですので。
貢献に感謝です。

Takanobu ()
takaoさん

こちらこそ、素敵な環境ありがとうございます。
関西在住ですので、情報交換の機会などありましたらぜひぜひ参加したいと思います。

よろしくお願いします。

Takanobu ()
添付画像の箇所は確認しておりませんでした。
ただ、マルチシグが成功すると Light Wallet のXem 送金画面に新しいタブができます。(承認者の方です)
これで承認を受けたアカウントの送金が自由にできます。(秘密鍵を知らないのに!)

複数人でマルチシグを行うと、
1人目は上記方法で送金処理を行います。
2人目からはunconfirmed transaction に溜まったままになり、その枠内にボタンがあらたに表示されるので、
そこから承認。
必要人数が全員そろうとそこで送金発生、となります。

取り急ぎ。

LHJ ()
Takanobu さん、早速のレスポンスありがとうございます!

どうやら当方は失敗しているそうですので調べてみます。間違いなく当方の環境のせいです。
また、成功可否はここでも確認できるのではないかと思いました。POST #11 に添付ファイル(capture_02.png)

# XEM が少なくなってきているのは秘密です。

Takanobu ()
LHJさん

これが不思議なことですが、私も失敗することがあります。
忙しくて書き込めていませんでした。すみません。

その場合、以下をお試しください。
サンプルプログラムでは承認者2名ですが、承認者を1人にしてみる。
(relativeChange も 1にしてくださいね)
これで上手くいくことがあります。

その後承認者を2名にして、別アカウントで実行してみるとうまくいく場合があります。
しばらくすると、また上手くいかなくなります。

検証が進んでいないため、状況報告まで。
再現した場合、エラーメッセージなど載せていきます。

LHJ ()
Takanobu さん、ありがとうございます。

お時間がある時に十分でございます。当方もいろいろ平行作業ですのでご安心くださいませ!

LHJ ()
マルチシグ成功時のトランザクション図を差し替えました。
本POST #11 の添付ファイル(capture_01.png)をご参照くださいませ。

Takanobu ()
LHJさん、マルチシグ成功したようですね!
添付画像ありがとうございます。

LHJ ()
Takanobu さん、お疲れ様です。
結論から言うとマルチシグ化は 1対1でしか成功しておりません。

mijin をよく知るためにXEMを実際に取引所から購入しました。
JPY -> BTC -> XEM とExchangeを行い、NEM公式のWallet(NCC)にXEMを納め、NEM公式のWallet(NCC)でマルチシグ化しました。
その結果、つまりトランザクションを皆様が使っておられるLightwalletで表示させたのが添付画像です。
複数のアカウント(2以上)ですとマルチシグはなぜかできません。あくまで1対1ですとマルチシグ化できました。

ですので、APIを叩いたプログラムでマルチシグが成功したわけではなく、あくまでNEM公式のWalletで検証を行ってみた結果です。
mijinはモザイクが基軸ですのでXEMにこだわるのは良策ではないと思います。しかし、エンジニア魂がそうさせない気持ちよくわかりますw

NEM公式のWallet(NCC)のスクリーンショットでしたら、ご要望の箇所を添付することは可能です。
ほか、Raspberry Pi でNCC、NIS、Lightwalletを走らすことはできました。しかし、「動いた」程度です。
とにかくわからないことだらけで、一つ一つチケットを発行しながら、膨大なチケット数に埋もれておりますw

Takanobu さんはモザイクの自動送金処理(ループ)を先にTRYするのが良いのかもしれません。
Namespace生成はクリアしているので、あとは mijin パワーを存分にお使いください!

LHJさんは遠回りしているかな?と自分でも反省しておりますが、エンジニア魂がそれを許さないようです(にっこり)

LHJ ()
マルチシグ成功後、モザイク送金時のLightwallet図を追加しました。
本POST #11 の添付ファイル(capture_02.png)をご参照くださいませ。

LHJ ()
本イベントですが、ざきやま(山崎大輔) 様が記事にしております。この場を借りて、ざきやま様、ありがとうございます。

ブロックチェーン最前線:テックビューロ主催イベントで新鋭4社がサービス開発の裏側を本音でトーク
http://btcnews.jp/techbreau-blockchain-event/

Takanobu ()
報告ありがとうございます!mijinの方向性が確認できて参考になりました。

LHJ ()
Takanobuさん、こんにちは

手数料について、もう1度整理するので少々お待ちください。
以下は、LHJさんが NEM で送金等を行った際の「最小」手数料です。

xem を送金する場合の手数料 :2.0 xem
mosaicを送金する場合の手数料: 2.5 xem
マルチシグ作成時の手数料  : 22.0 xem

Takanobu ()
おはようございます!

手数料をあれこれ考えても、mijinの場合はあんまり意味ないかもですが、
実証実験中はどうしても気になってしまいますね。

手数料についての過去の考察リンクを張っておきます。

http://mijin.io/forums/forum/日本語/243-mijin-用語集&参考書?p=290#post290
http://mijin.io/forums/forum/日本語/200-送金サンプルjsを作成しました。?p=298#post298


そして最後に選ばれた最大値から 5/4 が計算されます。
何でしょう  こ れ は ??

LHJ ()
Takanobu さん、ありがとうございます。これは素晴らしい!!!

Takanobu ()
おそらくですが、追加はロールバックできても削除はロールバックできない、ようなデータの持ち方をしてるのではないでしょうか?

例えばブロック追加の情報はノード間の伝播中にキャンセルされても消せば済む話ですが、ブロック削除の情報はノード間伝播中にキャンセルされてしまうともはや復活できない。といった感じだと思います。

LHJ ()
Takanobu さん、こんばんは。
お忙しいところありがとうございます。

やはり、一度追加した mosaic は削除できないですよね。ゆえに namespace 名はしっかり検討する必要がありますね。
namespace で多段階層できるので、最上段の namespace 名(DNSでいうトップレベルドメイン)だけ考えれば良いかなと理解しています。

ロールバックについても、LHJさんはまだまだ知識がなく、運用フェーズを考えると調べないといけませんね。

Takanobu ()
LHJさん、こんばんは。

これも私の推測の域を出ませんが、ブロックチェーン、特にプライベート版は「サーバ代どうせ安いんだから、パンパンになったら乗り換えたらいいんじゃない?」的なノリではないでしょうか?
最初はいろんなゴミを出していきますが、移行時に使っているものだけをエクスポートすれば、最終的には削除するのと同じ効果が得られるのではないかと。
ダウンタイムは発生しますけど、実験開始当初、「C++版も開発しており、乗り換えの仕方は別途ご案内します」的な内容のメールがあったかと思うのでそう感じました。

Takanobu ()
NEM APIに少し気になる記述があったので報告しておきます。

6.1. Namespaces

Root namespaces can be rented by accounts for the duration of one year. One month before the root namespace expires the rental contract can be renewed for another year. If a root namespace rental contract is renewed, all sub-namespaces are valid for another year as well. If the root namespace is not renewed, it exires together with all sub-namespaces. One month after a root namespace expires, another account is able to rent that root namespace.

残念ながら英語に弱い私ですが、
ルートnamespace は1年間レンタルすることができる。(誰から?)
ルートnamespaceの期限が切れる1ヶ月前から翌1年間の契約更新ができる。
ルートnamespaceの期限が切れた後1ヶ月間、他のアカウントでレンタルすることができる。
と、書いているように読めます。
これらの期限が切れた後、namespaceはどうなるのでしょうか?
そして、契約更新の方法はいかに?