mizunashi ()
現在日本国内では、NEMによる決済店舗がかなり増えました。
その様子を見て、私が感じた問題点を書きます。
・Unconfirmで支払い完了と見なす店舗がある。
- マルチシグアカウントから支払いが行われ、実際には追加署名されず、支払いが行われない。
- Confirm済み迄待つと、決済に時間がかかる。
という事で、最近では、マルチシグアカウントからの決済を禁止にする店舗も出てきています。
これらの問題について、日本では、マルチシグアカウントから支払われたかどうかを知る為のソフトウェアが最近作成されました。
ここまでは、日本でも多くの人が理解してきています。
さらに問題となるのは、ブロックチェーンの仕組みの問題です。
confirmを待って決済を行なっても、それがforkチェーンの可能性があり、安全ではありません。
更に、取引所の様に10confirm待つというのは、少額決済では致命的な問題です。
現状一番良いと思うのは、支払額に応じてconfirmの数を変えるというものになると思います。
そして、同じアドレスの決済端末を2つ用意して、それぞれが異なるスーパーノードを参照し、リスクを減らす。
根本的に小額決済の利便性向上の為に、他に何かできる事はありますか？
将来的には、何か異なる方法を用意して欲しいと考えています。
よろしくお願いいたします。
https://forum.nem.io/t/about-current-condition-of-small-settlement/13361?u=mizunashi
その様子を見て、私が感じた問題点を書きます。
・Unconfirmで支払い完了と見なす店舗がある。
- マルチシグアカウントから支払いが行われ、実際には追加署名されず、支払いが行われない。
- Confirm済み迄待つと、決済に時間がかかる。
という事で、最近では、マルチシグアカウントからの決済を禁止にする店舗も出てきています。
これらの問題について、日本では、マルチシグアカウントから支払われたかどうかを知る為のソフトウェアが最近作成されました。
ここまでは、日本でも多くの人が理解してきています。
さらに問題となるのは、ブロックチェーンの仕組みの問題です。
confirmを待って決済を行なっても、それがforkチェーンの可能性があり、安全ではありません。
更に、取引所の様に10confirm待つというのは、少額決済では致命的な問題です。
現状一番良いと思うのは、支払額に応じてconfirmの数を変えるというものになると思います。
そして、同じアドレスの決済端末を2つ用意して、それぞれが異なるスーパーノードを参照し、リスクを減らす。
根本的に小額決済の利便性向上の為に、他に何かできる事はありますか？
将来的には、何か異なる方法を用意して欲しいと考えています。
よろしくお願いいたします。
https://forum.nem.io/t/about-current-condition-of-small-settlement/13361?u=mizunashi
siwong ()
現状一番良いと思うのは、支払額に応じてconfirmの数を変えるというものになると思います。
そして、同じアドレスの決済端末を2つ用意して、それぞれが異なるスーパーノードを参照し、リスクを減らす。
ここの部分に関してはソフトウェアまたはアプリを作れば多少は楽になりそうですね。
・支払額を入力すると、Confiirm数を自動算出。
・トランザクション ハッシュを指定すると複数のスーパーノードに問い合わせる。
ただ、支払額はともかくハッシュを手入力するのは現実的ではないので、入力を楽にする仕組みは必要そうですが。
（店側のアドレスを事前登録しておいて、入金があれば自動的にそれぞれの状態を表示するとか？）
あと、支払い後の待ち時間を取るのが重要なので、店舗側で出来る対応としては会計手順を変更すると言うのも考えられます。
例えば、品物を準備してから会計という流れを、会計してから品物の準備を行うと言う形にし、品物を渡す直前でConfirmを確認とか。
店舗によっては難しいケースもあるとは思いますし、準備に時間の掛からない場合もあるので必ず使える方法ではないですが。
可能なら、先払いにするのが比較的安全でしょうね。
Takanobu ()
Confirmになった段階で支払意志は確認できてるので、マルチシグ詐欺の場合よりは双方が理解できるケースと思います。
万が一の場合に備えて連絡手段を別方法で保管しておく（次回訪問時に合わせて請求）なども考えられるでしょうか。
万が一の場合に備えて連絡手段を別方法で保管しておく（次回訪問時に合わせて請求）なども考えられるでしょうか。
Takanobu ()
tipnem においてもシステム側が保存しているhashがnembex上に存在しないというケースがありました。
つまり、現状のNEMでは理論的に無視できない状況と考える必要があります。
その背景にはハーベスターの増加により、同時間でブロックが生成される確率が高まったと考えることもできま す。
ただし、ハーベスターの理論上限値は決まっているはずなので、
正しく設計、実装されれば再現が無視できる状況まで追い込めるものと思っています。
具体的には
カタパルト実現によるノードの安定化
接続が推奨されるSNのリストアップ（SN要件の厳密化）
ハーベスターの最大数調整
ブロックタイムのプラスマイナス5%の数値調整
などが考えられると思います。
つまり、現状のNEMでは理論的に無視できない状況と考える必要があります。
その背景にはハーベスターの増加により、同時間でブロックが生成される確率が高まったと考えることもできま す。
ただし、ハーベスターの理論上限値は決まっているはずなので、
正しく設計、実装されれば再現が無視できる状況まで追い込めるものと思っています。
具体的には
カタパルト実現によるノードの安定化
接続が推奨されるSNのリストアップ（SN要件の厳密化）
ハーベスターの最大数調整
ブロックタイムのプラスマイナス5%の数値調整
などが考えられると思います。
ocknamo ()
前から考えていたのですが、
1. アリス（支払者）がオフラインTXを作成しボブ（店）にQRコードで渡す。
2. ボブが自分で分岐していないことを確認した信頼できるNISにブロードキャストする。
3. 1confirm待って確認できたら支払い完了。
というような手順で行えば1confirmのみで全ての支払いをトラストレスに完了できると思うのですがどうでしょう？
1. アリス（支払者）がオフラインTXを作成しボブ（店）にQRコードで渡す。
2. ボブが自分で分岐していないことを確認した信頼できるNISにブロードキャストする。
3. 1confirm待って確認できたら支払い完了。
というような手順で行えば1confirmのみで全ての支払いをトラストレスに完了できると思うのですがどうでしょう？