Increase default minconf

wakiyamap commented

2019-05-04 08:49:02 +00:00

(Migrated from github.com)

BTCのdefaultの承認数6をMONAも引き継いで今までやってきていますが、
取引所やサービス等では去年のBWH攻撃を受け承認数を増やしている傾向が見られます。

ちょうど0.17を考え始める時期でもあり、6承認と言うdefaultを変えるのにもちょうど良い時期ではないでしょうか？

個々のサービスについてもgetbalanceのminconfで現在制御していることが多いと思われますのでそこまで影響は出ないかとは思います。

とりあえず承認数を何処まで引き上げるか？そもそも承認数の引き上げは必要なのか考えたいです。

関連： https://github.com/monacoinproject/monacoin/pull/39 BTCのdefaultの承認数6をMONAも引き継いで今までやってきていますが、取引所やサービス等では去年のBWH攻撃を受け承認数を増やしている傾向が見られます。ちょうど0.17を考え始める時期でもあり、6承認と言うdefaultを変えるのにもちょうど良い時期ではないでしょうか？個々のサービスについてもgetbalanceのminconfで現在制御していることが多いと思われますのでそこまで影響は出ないかとは思います。とりあえず承認数を何処まで引き上げるか？そもそも承認数の引き上げは必要なのか考えたいです。

👍 2

mikihamura commented

2019-05-04 22:34:26 +00:00

(Migrated from github.com)

minconfの引き上げには反対です。
運用上、1confと急ぐ場合に困る事があると思うからです。
defaultの6confも強制的にcoind側で引き上げるのは筋が悪い気がします。
そこはネットリテラシーに照らし合わせ、個々の判断でフレキシブルに設定できる現状維持を望みます。

minconfの引き上げには反対です。運用上、1confと急ぐ場合に困る事があると思うからです。 defaultの6confも強制的にcoind側で引き上げるのは筋が悪い気がします。そこはネットリテラシーに照らし合わせ、個々の判断でフレキシブルに設定できる現状維持を望みます。

👍 1

cryptcoin-junkey commented

2019-05-05 04:35:55 +00:00

(Migrated from github.com)

AFAIK, there is no magic number 6 in the code of monacoind. My opinion is similar to @mikihamura 's.

AFAIK, there is no magic number `6` in the code of `monacoind`. My opinion is similar to @mikihamura 's.

mikihamura commented

2019-05-05 04:49:47 +00:00

(Migrated from github.com)

マジックナンバー6はハードコードされていないのですね。
でも、やけに6confが崇め奉られすぎている気はします。
monacoinに置ける6confは案外脆いと考えますが、それをcoind側で強制的にハードコードしてしまったりするのは中央集権的でmonacoinらしいとは思えないです。
実際には、1時間程度confにかけるのが現実的かと思います（100程度？）
ただ、性急に脳死してハードコードするのではなく、フレキシブルにできるよう、confファイルで設定するのを強く願います。

マジックナンバー6はハードコードされていないのですね。でも、やけに6confが崇め奉られすぎている気はします。 monacoinに置ける6confは案外脆いと考えますが、それをcoind側で強制的にハードコードしてしまったりするのは中央集権的でmonacoinらしいとは思えないです。実際には、1時間程度confにかけるのが現実的かと思います（100程度？）ただ、性急に脳死してハードコードするのではなく、フレキシブルにできるよう、confファイルで設定するのを強く願います。

cryptcoin-junkey commented

2019-05-05 05:47:45 +00:00

(Migrated from github.com)

I think the best confirmation value depends on their applications. It might be a good idea that wallet provides an UI to increase their confirmation value. And monacoind has already provided API that can call with minconf. So I have less motivation to increase the default minconf value now.

I think the best confirmation value depends on their applications. It might be a good idea that wallet provides an UI to increase their confirmation value. And `monacoind` has already provided API that can call with `minconf`. So I have less motivation to increase the default `minconf` value now.

mikihamura commented

2019-05-05 05:51:23 +00:00

(Migrated from github.com)

@cryptcoin-junkey 非常にniceな考えだと思います。
smartでコード変更も少なくて済むと考えます。（もしかして：コード変更無し？）

@cryptcoin-junkey 非常にniceな考えだと思います。 smartでコード変更も少なくて済むと考えます。（もしかして：コード変更無し？）

cryptcoin-junkey commented

2019-05-05 05:52:12 +00:00

(Migrated from github.com)

（もしかして：コード変更無し？）

Yes :-)

> （もしかして：コード変更無し？） Yes :-)

mikihamura commented

2019-05-05 05:52:35 +00:00

(Migrated from github.com)

LMAO

wakiyamap commented

2019-05-05 06:00:15 +00:00

(Migrated from github.com)

サービス提供者を見ている限り、取引所は100confirm、サービス系は40confirm辺りが多いように見られます。
Qt上だとこういう表現もあったりしますが、普通に使っている分にはおそらく問題ないとは思われます。

サービス、取引所が決めると言うので問題ないとは思いますが、どのくらいがちょうどいいのでしょうかね？

サービス提供者を見ている限り、取引所は``100confirm``、サービス系は``40confirm``辺りが多いように見られます。 Qt上だとこういう表現もあったりしますが、普通に使っている分にはおそらく問題ないとは思われます。 ![image](https://user-images.githubusercontent.com/7189933/57189184-26bfab00-6f46-11e9-91a8-35974b6e4991.png) サービス、取引所が決めると言うので問題ないとは思いますが、どのくらいがちょうどいいのでしょうかね？

namuyan commented

2019-05-05 11:12:46 +00:00

(Migrated from github.com)

minconfの引き上げ（というよりコードの変更）に反対です。
理由としては既に出ている事も踏まえて、

これからもBitcoinより変更をMargeするので直接コードは触らない方が良さそう
minconfは送金額と価格に依存すると思われるので定数にできないのではないか？
影響を受けるのは一般ユーザー(取引所などは独自の機構だろう)なので広報で済ませたい

BlockchainにはReorgにより取引が巻き戻る事があります。これは人為的に起こされる現象であり取引のConfirmationsが増えれば不可能に近くなります。現在Confirmationsは６に設定されていますが金額が大きい場合は１２などに増やす事でリスクを下げる事が出来ます。

これをQtの注意書きに加えるなどの対処を提案します。何か行動を起こすなら、これが（CoreDev側とユーザー側の）労力とリスクのバランスが良さそうです。

minconfの引き上げ（というよりコードの変更）に反対です。理由としては既に出ている事も踏まえて、 * これからもBitcoinより変更をMargeするので直接コードは触らない方が良さそう * minconfは送金額と価格に依存すると思われるので定数にできないのではないか？ * 影響を受けるのは一般ユーザー(取引所などは独自の機構だろう)なので広報で済ませたい > BlockchainにはReorgにより取引が巻き戻る事があります。これは人為的に起こされる現象であり取引のConfirmationsが増えれば不可能に近くなります。現在Confirmationsは６に設定されていますが金額が大きい場合は１２などに増やす事でリスクを下げる事が出来ます。これをQtの注意書きに加えるなどの対処を提案します。何か行動を起こすなら、これが（CoreDev側とユーザー側の）労力とリスクのバランスが良さそうです。

cryptcoin-junkey commented

2019-05-05 22:04:42 +00:00

(Migrated from github.com)

@wakiyamap In case the sender's wallet, I believe it's enough even 0-conf. Of course 1 or more conf is better. In the viewpoint of probability, it can be lost the transaction from mempool even if >= 1 conf. But it will be too rare case to discuss.

The another side, receivers. The best confirmation count will be totally "application dependent". 100 or more confirmations will be required if the app stores huge balances in external DB.
At the same, it may be enough 1 or 0 conf for small merchants. Who tries a high-cost double spend attack for $1 lollipop?

Users can't determine? Then. I suggest 6 to such users.

Surely 6 is a magic number that is less supported by Mathematics, but it might be an empirically valid. Because the Monacoin network have never re-orged more than 6 conf except attacks in last year, AFAIK.

@wakiyamap In case the sender's wallet, I believe it's enough even 0-conf. Of course 1 or more conf is better. In the viewpoint of probability, it can be lost the transaction from mempool even if >= 1 conf. But it will be too rare case to discuss. The another side, receivers. The best confirmation count will be totally "application dependent". 100 or more confirmations will be required if the app stores huge balances in external DB. At the same, it may be enough 1 or 0 conf for small merchants. Who tries a high-cost double spend attack for $1 lollipop? Users can't determine? Then. I suggest `6` to such users. Surely `6` is a magic number that is less supported by Mathematics, but it might be an empirically valid. Because the Monacoin network have never re-orged more than 6 conf except attacks in last year, AFAIK.

tcejorpniocanom commented

2019-05-16 04:20:37 +00:00

(Migrated from github.com)

サービス側の対応になってしましますが、入金額に応じて確認ブロック数を変動させれば良いのかなと。
クラウドマイニングの能力やコストにもよるので、一概に何mona以上なら何ブロックとは言えませんが、少額送金なら数ブロックの確認で通るようにはできると思います。

サービス側の対応になってしましますが、入金額に応じて確認ブロック数を変動させれば良いのかなと。クラウドマイニングの能力やコストにもよるので、一概に何mona以上なら何ブロックとは言えませんが、少額送金なら数ブロックの確認で通るようにはできると思います。

tcejorpniocanom commented

2019-05-16 04:32:28 +00:00

(Migrated from github.com)

そういえば昔"6"の根拠は？と調べてた時に出てきたもの。
https://bitcoil.co.il/Doublespend.pdf

そういえば昔"6"の根拠は？と調べてた時に出てきたもの。 https://bitcoil.co.il/Doublespend.pdf

👍 1

darekasann commented

2019-05-18 13:57:16 +00:00

(Migrated from github.com)

まず最初に、デフォルトの承認数の引き上げに関しては自分としてはどちらでもよいかと。
取引所やサービス等は攻撃の可能性を考慮して独自の承認数による運営をしており、ElectrumやMonacoin-coreで独自に保管するエンドユーザーは"分かっている人"が多いとは思います。

ただし、実際の運用上では6よりも多い承認数を必要とするべきではあるでしょう。
Monacoinでの6承認は9分であり、BTCの1承認(10分)よりも短い時間で6承認に到達する(短い時間で巻き戻せる)こと、およびクラウドマイニングによって推定ネットハッシュレートの4割程度のハッシュレートを投入することができ、6承認の巻き戻しは難しくないでしょう。
ASIC以外での採掘が事実上行えない現状、今までよりは攻撃はしづらくなったものの、6承認なら多分大丈夫だとはあまり言える状態ではないと考えております。

また、少額送金なら少ない承認数でも良いというのは、場合によるかなと。
というのも、本人確認が不要な取引所では複数のアカウントを容易に作成でき、複数のアカウントに分散して送金を行った場合、攻撃が容易になってしまうためです。
なので、オンラインサービスではある程度厳しくした方が良いかなと考えます。

ただし、実店舗の場合は、上記の複数アカウントのようなことを行うのは非常に難しく時間的制約が大きい故、実店舗の少額決済のみは少ない承認数でもよいかなと、自分はそのように考えております。

まず最初に、デフォルトの承認数の引き上げに関しては自分としてはどちらでもよいかと。取引所やサービス等は攻撃の可能性を考慮して独自の承認数による運営をしており、ElectrumやMonacoin-coreで独自に保管するエンドユーザーは"分かっている人"が多いとは思います。ただし、実際の運用上では6よりも多い承認数を必要とするべきではあるでしょう。 Monacoinでの6承認は9分であり、BTCの1承認(10分)よりも短い時間で6承認に到達する(短い時間で巻き戻せる)こと、およびクラウドマイニングによって推定ネットハッシュレートの4割程度のハッシュレートを投入することができ、6承認の巻き戻しは難しくないでしょう。 ASIC以外での採掘が事実上行えない現状、今までよりは攻撃はしづらくなったものの、6承認なら多分大丈夫だとはあまり言える状態ではないと考えております。また、少額送金なら少ない承認数でも良いというのは、場合によるかなと。というのも、本人確認が不要な取引所では複数のアカウントを容易に作成でき、複数のアカウントに分散して送金を行った場合、攻撃が容易になってしまうためです。なので、オンラインサービスではある程度厳しくした方が良いかなと考えます。ただし、実店舗の場合は、上記の複数アカウントのようなことを行うのは非常に難しく時間的制約が大きい故、実店舗の少額決済のみは少ない承認数でもよいかなと、自分はそのように考えております。

tcejorpniocanom commented

2019-05-18 19:31:26 +00:00

(Migrated from github.com)

攻撃に対する解決を目指すなら、確認ブロック数ではなく別の方法を議論すべきです。

wakiyamap commented

2019-05-18 20:13:11 +00:00

(Migrated from github.com)

@cryptcoin-junkey Mostly I agree. However, I think 6conf is dangerous as long as there is nicehash. I also think that it is dangerous for the source code changes that accompany it, so it is my opinion to say that it is better to keep a certain conf (40-100conf) on the service side.

現状40-100confが主だったサービスで使われているため、6conf近辺のReorgでの経済的利益を得るのは難しそうに思います。

懸念点があるとすればですが、現状現れていませんが @darekasann の書いているように受入額でconf数を変更している場合です。そういうサービスは今のところ現れていないように見えますが、もし発見次第注意はしたほうがいいかなとは考える次第です。

@cryptcoin-junkey Mostly I agree. However, I think 6conf is dangerous as long as there is nicehash. I also think that it is dangerous for the source code changes that accompany it, so it is my opinion to say that it is better to keep a certain conf (40-100conf) on the service side. 現状40-100confが主だったサービスで使われているため、6conf近辺のReorgでの経済的利益を得るのは難しそうに思います。懸念点があるとすればですが、現状現れていませんが @darekasann の書いているように受入額でconf数を変更している場合です。そういうサービスは今のところ現れていないように見えますが、もし発見次第注意はしたほうがいいかなとは考える次第です。

cryptcoin-junkey commented

2019-05-31 23:45:03 +00:00

(Migrated from github.com)