■次期P2Pの仕様 part6■

#次世代P2Pの仕様を話し合うスレです。

過去ログ・決まったこと？をまとめたサイト
　http://2.csx.jp/~p2p/

前スレ　Part５
　http://tmp2.2ch.net/test/read.cgi/download/1070113264/

関連
次期P2Pのクリアすべき課題を法的な観点から考察
http://tmp2.2ch.net/test/read.cgi/download/1070084504/
次期P2Pに対する要望スレ
http://tmp2.2ch.net/test/read.cgi/download/1070085137/
P2P総合
http://pc2.2ch.net/test/read.cgi/tech/1048668198/
次世代P2Pの名前を考えるスレ
http://tmp2.2ch.net/test/read.cgi/download/1069996070/

850レスを超えたら、次スレの準備をする為に、議論を一時中断して下さい。
あと、ｽﾚ住人はｷｼｭﾂに敏感なので必ずﾃﾝﾌﾟﾚ嫁

テンプレは
>>2-20
#---------------------------------------------------------#　

乙

うんこ

1, こ こ は "仕 様" を 決 め る ス レ ッ ド で す。
→ 実装 法律 に関しては、他のスレッドでお願いします。

2, 単発のアイデアは良く考えてから、カキコしてください。
十中八九、ｶﾞｲｼｭﾂとかスレ違いとかﾋﾟﾝﾄはずれと言われちゃいます。」

UDP/コネクションレス/IP偽装/コネクションハイジャック…は、既出。

3, Mac版は？　Unix / Linux / BSD 版は？
→ 次期Winnyでは一般的なプラットフォームをターゲットにしていますので
→ Unix板 Linux板 Mac板の方もアイディア・技術提供、宜しくお願い致します。

しかし、要望スレに自己主張してくれないと反映されないかも知れません。
※【神】UNIXにWinnyを移植【降臨】 　http://pc.2ch.net/test/read.cgi/unix/1065863581/
※Linny開発プロジェクト Part2 　http://pc.2ch.net/test/read.cgi/linux/1056278411/

4, 「現時点で組み始めたいんだけど」
→ まだ仕様が決まっていないので、余り先走らないで下さい。
→ しかし検証コード・テストコードを書くのは推奨しています。

5, 今回のﾀｲｰﾎは別件逮捕だと聞いたけど？
→ ガセ。Winnyが解析された可能性がある。

6, IPの偽装はできないのか？
→ 現実的ではない。

7, ソフト名を決めずに、検索エンジン等でかからなくするのが良い・ソフト名を放送禁止用語にすれ
→ モノができてから考えれ。

8, 特定のIP（ACCSとかJASRACとか）は、拒否する設定が良い
→ 一般のプロバイダが用いられた捜査に対して全く無意味。

9, 作者の身元を隠さなくていいのか？
→ 後で（公開の段階で）考えるべし。現状何もできてないので問題ない。
※今回の件から推測すると、実装し頒布した場合の作者さんは、
家 宅 捜 索 等 の 危 険 も 大 き い の で 決 し て 身 元 を 明 か さ ぬ 様 に、
書き込み・垢の取得に"充分"気を付けて下さい。

早い話、2chで「作るyo!」・「ﾃﾞｷﾀｰ!!」と言ったら、
「将来、逮捕・家宅捜索される危険がありますよ」って事。

10, K察・ACCSは使用禁止にしよう
.　 　・雑誌掲載を禁止しよう
.　 　・初心者には容易に使えないソフトが良い、
.　 　・初期設定を難しくしよう、等
→ 後で（公開の段階で）考えるべし。公開直前にでも何とかなる。
→ また現実問題、スレのＵＲＬの転載を止める手段はない。

11, 通信径路上でのデータの暗号化にはＸＸが良い
.　 　・「鍵は〜〜で流すのが良い」等 暗号関連
→ 暗号化はあくまでもプロバイダに特定されないためのもので、問題の本質ではない。
→ 例えば相手ノードが警察のＰＣだった場合などは、あらゆる暗号化は無意味。
→ どちらかというと、責任逃れの方法を考えなければならない

(･∀･)

すれたて乙

12, 「**機能付きにしる！」・「インターフェイスは**！」
→ それ専用のスレッドが御座いますので、そちらに書き込んで頂くか
→ プログラム組む時(実装時・設計時)に、再度お願いします。 項目14も参考に読む事。
※次期P2Pに対する要望スレ　http://tmp2.2ch.net/test/read.cgi/download/1070085137/

13, これ作っても違法なんじゃないの？
→ 法的な問題については専用のスレッドが御座いますので、そちらにお願いいたします。
→ そちらでは現在、法律に詳しい方を探しています。
※次期P2Pのクリアすべき課題を法的な観点から考察
　　http://tmp2.2ch.net/test/read.cgi/download/1070084504/

14, 基本部分をプラグイン・ライブラリの形で提供する事により

　・言い訳出来る。
　・開発者への負担を減らす
　・プラットホームに依存しないプログラミングが可能
　・別のソフトでも使い回せる。
　・単体での入れ替えが、より容易になる。

ぬるぽ

>>7
ｶﾞｯ

15, オープンソースにする利点、またはリスクは？

.　 クローズドにすれば匿名性が高まるのではなく、
.　 クラックが難しくなるだけで本質的な解決にはならない。

.　 47氏の件を見れば解る様に、一人の開発者に全てを頼るのは"致命的"です。

.　 オープンな規格で、オープンソースで開発する事により、

.　 ・多くの対応ソフトウェアを作成する事が可能になり
.　 ・大勢の人間がソースを手にする事が可能になり
.　 ・ソースのチェック・修正・脆弱性の対応にも役立つ

.　 ・もし暗号化/複合化部がクラックされても、仕様・規格があるので
.　 　より強力なライブラリを"別の誰かが"作成する事が可能です。
.　 　差し替えるだけなのでメンテナンス性も上がるでしょう。

.　　もし、不安なら自分でソースを持ってきてRebuildすれば
.　　信頼出来るバイナリが出来るかも知れません。

.　　※暗号化・複合化部は、一番肝になる部分ですので
.　 　　ライブラリとして,バイナリでの提供を考えています。

.　 #　14・15の部分については、突っ込み待ってます。

　　　　　　　　　 ＿＿ 　
　　　　　　　　　 〈〈〈〈　ヽ 　　　　　　　　　　　　　　,ィ⊃　　, -- ､
　　　　　　　　　　〈⊃　　}　　　　,r─-､ 　 　 　,. ' ／ 　　,/ 　 　 }
　　 ∩＿＿＿∩　 |　　 |　　　　{ 　 　　ヽ 　／ ∠ ､＿__/　　　　|
　　 | ノ　　　　　 ヽ !　　 !　　　　ヽ 　ヾ､　　'　　　 ヽ_/　ｒｭ､ ﾞ､　/
　　/　　●　　　● |　　/　　　　　＼　 l　,　_;:;::;:;）､!　　{`-'}　Y
　 |　　　　( _●_)　 ミ／　　　，,･_　　　ヽj 　,;:;:;ノ'　⊆) '⌒｀　!
　彡､　　　|∪|　　／　　　 ’,∴ ･　¨　　l　　　　　;::）-‐ｹ　　}
/　＿＿　 ヽノ　/　　　　､･∵ ’　　　　 ヽ. 　　　;:丿‐y　　/
(＿＿＿）　　　/　　　　　　　　　(ヽ､＿_,.ゝ､　　　 　~___,ノ ,-､

14, 基本部分をプラグイン・ライブラリの形で提供してはどうか

　良いアイデアだが、それは実装段階の話に近いので、要望スレで。


15, オープンソースにする利点、またはリスクは？

　リスク：オープンソースにすると言う事は、Ｋ察にもソースを公開するということ。
　Ｋ察のおとり捜査が容易になるので、
　かなり厳密な設計が必要になってくる。

　利点：ググったら腐るほど出てくるので、そちらで勉強して下さい。

　　　　　　　　　　　　 .t- ..,　
　 _ 　 　 ____　　 _, .-‐'"￣"'-ﾆｭ　
　r,.,ニニ.,,,__ "'" __　 ノ　　 　　　"''- 、　
　/,.- ─ -- 、"_,..,￣ '::.....　　 ヽ､<.　@ヽ, 　
　"　　　　　　 "　　￣^'''^￣^'' ‐‐-ニ-＝

　　　　　　　　　 　 　 　 　 　 　 　 　　　＿＿＿＿＿＿＿_
　　　　　　　　　　　　　　　　 　 　 　　 /　　＿＿＿___　　 /＼
　　　　　　　　　　　　　　　　　　　　　/　　/＼ ＿＿/ 　 /　　/
　　　　　　　　　 　 　 　 　 　 　 　　/　　/　　/　　/　　/　　/
　　　　　　　　　　　　　　　　　　　 /　　/　　/　　/　　/　　/
　　　　　　　　　　　　 　 　 　 　　/　　/　　/　　/　　/　　/
　　　　　　　　　　　　　　　　　　/　　/　　/　　/　　/　　/
　　　　　　　　　　 　 　 　 　　 /　　/　　/　　/　　/　　/
　　　　　　　　　　　　　　　　 /　　/　　/　　/　　/　　/
　　　　　　　　　 　 　 　 　　/　　/　　/　　/　　/　　/
　　　　　　　　　　　　　　　/　　/　　/　　/　　/　　/
　　　　　　　　 　 　 　 　 /　　/　　/　　/　　/　　/
　　　　　　　　　　　　　 /　　/　　/　　/　　/　　/
　　　　　　　　 　 　 　 /　　/　　/　　/　　/　　/
　　　　　　　　　　　　/　　/　　/　　/　　/　　/
　　 　 　 　 　 　 　 /　　/　　/　　/　　/　　/
　　　　　　　　　　 /　　/　　/　　/　　/　　/
　 　 　 　 　 　 　/　　/　　/　　/　　/　　/
　　　　　　　　　/‐ ､./ 　 /‐ ､./ 　 /‐ ､./
　　　　　　　　　ゝ_.ノ 　　ゝ_ ノ　　 ゝ_ ノ

これは既出ですか？
http://www.zdnet.co.jp/broadband/0311/19/lp21.html

　　,,,,........_
　/　 　 　＼
　| /ﾙﾘ∨ﾚﾘ
　|/／　 ＼|　　／￣￣￣￣￣
.(.|　・　　 ・ |)＜　・・・・・・
_..|　　　_ 　 |.._ ＼＿＿＿＿＿
　|　　　|| 　|　＼
　 ＼＿＿/ i 　 |

http://loveloveweb.hp.infoseek.co.jp/ozz/PP.txt
　いろいろ考えてみてますが…。

　

>>16 まさか設定ファイルだけ先に作って満足ですか？ おめでたい人ですね。

>>17
思いついたままに書いてる
　そこらへん気にしない方針

P2Pで無料レンタルディスクスペースを作ったらどう？
ディスクの使用権は借りてる人にあることにすれば、
貸した側の責任はそれほど問われないはず。

>>18　
ノイズになるだけだからやめれ

まとめサイト
http://s2net.s41.xrea.com/
http://2.csx.jp/~p2p/

>>18
図にまとめてうｐした方が何倍も有意義じゃない？
というか、データの流れを考えないと何時まで経っても役に立たない罠

514氏こないかね？
仕事終わったかな？

ｽﾚの進行速度が一気に落ちたな しかしあまり速すぎるのはやっぱり困る。

まったり。。いきましょうよ。
　焦って開発しても　ろくなもんができん気もするしなー。

他スレに誤爆してしまったのでアレですがこういうのはどうでしょう。
ゴミも少な目でかつ全体が無いとサイズすらわからないと思います。

次のようなブロックを何個か何十個か知らないけど作っておいて、

　　　　　　　　 　[mRNAハッシュ]
[tRNAハッシュ]-[tRNAハッシュ]-[tRNAハッシュ]
　　　　　　　　　　　　　 　|
　　　　 　　　　　　 　ブロック

・tRNAハッシュは直下のブロックから作成
・mRNAハッシュは３つのハッシュから作成

でもって、あとでこんなカンジにくっつける
… -[mRNAハッシュ]-[mRNAハッシュ]-[mRNAハッシュ]-[mRNAハッシュ]-[mRNAハッシュ]- …
… -[ tRNAハッシュ]-[ tRNAハッシュ.]-[ tRNAハッシュ]-[ tRNAハッシュ]-[ tRNAハッシュ.]- …
　　　　　　　|　　　　　　　　　　|　　　　　　　　　　|　　　　　　　　　　|　　　　　　　　　　|
… 　　ブロックＮ−２　　ブロックＮ−１　　　ブロックＮ　 　　ブロックＮ＋１　　ブロックＮ＋２　　 …

データはＣＤとかみたいにしておく。
データは適当な方法でランダム化していろんなブロックに配置。
ブロックには横と斜めのECCを持たせて斜めのECCはブロックを大きく跨ぐようにする。
ECCエラーの大きいブロックは破棄、ECCエラーの多い接続は切断。

リングになったら完全ファイルになってしまうので、
リングがあったらその中から、何個か適当なブロックを多めにプッシュしたあと
そのブロックを削除してあとちょっとで完全なブロックに戻す。

こういうのを流すのもあり。流すときは断片化にして出す。
… -[mRNAハッシュ]-[mRNAハッシュ]-[mRNAハッシュ]-[mRNAハッシュ]-[mRNAハッシュ]- …

>>26
メッセンジャーと、トランスファーですか。
アミノ酸合成ですか？

>>21のhttp://s2net.s41.xrea.com/
Wiki設置済みです。

元ネタはタンパク質合成です。
トランスファーが先になってるけど。

法的な抜け道が仕様を生むと思うんだが。。。

>>26 本当にﾜｹわかりません

＞mRNAハッシュは３つのハッシュから作成
こう書いているのに、
その下の図ではmRNAハッシュとtRNAハッシュが１対１対応になっているのはなぜ？

・そもそもハッシュが２種類あるのは何？
・ていうかRNAってなに？
・データはＣＤとかみたいにって何？


かなり舌ったらずで本当にワケわからないんだけど、
何か図にちゃんと書いたほうがいいんじゃ？

静粛に！　委員方、静粛に！

・・・戦いたがる者などおらぬ・・・

平和に、穏やかに、幸せにダウソしたい・・・我らの願いはそれだけでした

だが、その願いを無残に打ち砕いたのは誰です！？

我らは忘れない・・・

・・・あの『血の霜月』・・・『Winny2・1127』の悲劇を！

我らは戦う・・・戦うことで己を守れないのなら戦い続けるしかないのだ
そして、必ず勝利を我らの手に・・・

ジーク・ダウソ！　ジーク・ダウソ！
ジーク・ダウソ！　ジーク・ダウソ！
ジーク・ダウソ！　ジーク・ダウソ！

人に説明すらできないパっと出のアイデアはもっと熟考してから書くべき

>31
tRNA3つでmRNAを一つ作る。
１つのtRNAは３つのmRNAに関わります。
そうすると前後だけのつながりの保証ができる。

RNAには特に意味はありません。
元ネタからです。

詳しく説明するのは面倒なのでＣＤみたいにと書きました。
・データをシリアルではなくランダムに配置する
・縦と斜めのECCを使う
の２つです。

>>26
＞ECCエラー
これはどういう場合に発生する？

＞・データをシリアルではなくランダムに配置する
要するにシャッフルするって事ね？


結局、この案にはどういう利点があるの？
前スレに出てきてた懸案とかは把握してるの？

Part.5の>>972なのですが、前スレに書いたやつコピペしてもいいでしょうか？

ｲｲﾝｼﾞｬﾈｰﾉ

既出であればスマソ

kはUPしたファイル=受け取ったファイルを立証しなければならない。
それを防ぐために、分割データ転送時に、データのランダムな一部削除と
ランダムな改変をしてはどうだろう？

すみませんそれでは・・・。長いので分割 1 / 3

1.拡散

　UPするノードはまずファイルをn個の暗号化したキャッシュに分割する。
　このキャッシュにはファイル名も個々の関連も含まれない。
　各キャッシュに復号キーの断片を埋め込むが、このときに復号キーの断片を
　持つ重要なキー、「公開許可キー」を作成する。このキーには次のものが
　含まれる。

　[ファイル名|DL要求用ハッシュ|(個々のキャッシュのハッシュ)|復号キー断片]

　特徴
　キャッシュを持つノードはその中身を知ることができない。
　公開許可キーを持つノードは、そのキャッシュを持つことができない。
　DL要求用ハッシュの存在により、DLしようとするノードは個々のキャッシュの
　ハッシュを知る必要がない。

　十分にキャッシュが拡散したと判断するに至ったら、公開許可キーを放流する。
　(公開許可キーを持つノードだけがキャッシュを特定できるので拡散数を把握
　して判断する)

2 / 3

2.公開許可キー

　この公開許可キーを受け取ったノードは次のことをする。
　ファイル名とDL要求用ハッシュを抽出し、検索リンクに追加する。

　個々のキャッシュのハッシュを抽出し、このキャッシュを持つ他のノードを補助する。

　このキーとそのキャッシュを持たないノードにこのキーを拡散させる。
　(だがキャッシュが拡散するのを積極的に邪魔してはならない)

　被参照量の把握と拡散数の上限下限を管理する。(←不要というか、難しい)


　補助のしくみ
　一つのノードにこのキーに含まれているキャッシュが過度に集中しないようにする。
　集中しかけていた場合、転送中止や削除の要請を行う。

>>38 あげないで。

＞データのランダムな一部削除とランダムな改変をしてはどうだろう？
そうしたら、「本当にファイルを受け取りたい人」 も 受信できなくなってしまう。
Ｋ察と一般人を見分ける方法はないんです。

劣化コピー案とかも出てたけど、zipとかでは使えないし、そもそもpeercastでもすれば？ってことになる

3 / 3
　DLのしくみ
　DL要求用ハッシュを受け取ると、キーに含まれるハッシュを使ってキャッシュを
　持っているノードに送信要請をする。
　中継はいくつでもかまわないがDL要求をしたノードは強制転送を受ける。

　DL要求を出したノードが既にそのキャッシュの一部を所持しているときは、そのキャッシュ
　のハッシュを送信する。ハッシュを受けたノードはDL完了までそのキャッシュを隠蔽する。
　(このとき初めてユーザーにDLの進行度を見せることができるが、これを利用してキャッシュ
　消しをされると本末転倒なのでよく考えたほうがいい。)
　DLが完了するまで上の繰り返し。

　DLが完了したノードにキーに含まれる復号キーの断片を送信する。

まず個人がうｐしようとするときに一つのキャッシュをいくつかに分ける。
そのときその結合部分になる小さなファイルを削除しておく。
ってかその復元に必要な結合部分を
ランダムに近くのノードにしばらくとばして削除。
もしくは何処か固定の場所においておくといいかも

うｐする人とダウンしたい人の間には転送する人を絶対に通すようにする。
ダウンしたい人は割れた一つをダウンした時点で一度その人から回線を切る
自動的に転送とupする人の回線も一度切れる。
また転送のときに同じ人と繋がるかもしれないけど
人が多ければ多いほど同じ人間に入る確立が低くなり、事実証拠固めは不可能。

そしてそのファイル割れた部分を集め終わった時点で
結合部分を全く違った人からダウンロード。で結合。

だめ？

L専用のピアとR専用のピアが存在し、
L専用ピアはL専用のファイル情報、R専用のピアはR専用のファイル情報を持つ。
L専用のファイル情報は、どのL専用ピアが所持しても、
自分の持っているものが何のファイルかは一切分からない。
逆の場合も同じとする。

Lピア専用のファイル情報（Lキー）
・自分のハッシュ
・元のファイル情報
・元のファイルのハッシュ
・Rブロックのハッシュ
・Rブロックの暗号鍵
・結合済みブロックのハッシュ

Rピア専用のファイル情報（Rキー）
・自分のハッシュ
・元のファイル情報
・元のファイルのハッシュ
・Lブロックのハッシュ
・Lブロックの暗号鍵
・結合済みブロックのハッシュ

L専用のブロック（Lブロック）……Lブロックの暗号鍵で暗号化済み
・自分のハッシュ
・Rブロックのハッシュ
・Rブロックの暗号鍵
・実際のデータ

R専用のブロック（Rブロック）……Rブロックの暗号鍵で暗号化済み
・自分のハッシュ
・Lブロックのハッシュ
・Lブロックの暗号鍵
・実際のデータ

ソフト起動時に接続される時点で、自分が偶数ピアであるか奇数ピアであるかが決定される。
二回目の起動以降も、ずっとどちらかのピアとなる。

この方式のメリット
・LキーとLブロック、か、RキーとRブロックを何個所持していても、
　自分が持っているファイルの情報は全く分からない
・キー、分割情報、ブロックという管理よりも、
　どのファイルを持ってよくて、どのファイルを捨てなければならないかの判断が容易

この方式の問題点

・ファイルの種類が四種類になるが、効率的な問題はどうか
・LピアとRピアを満遍なく分散させるにはどうするか

このデータ構造における、通信方法を考えてみた。

A：Lノード、、、B：Rノード、、、C：Lノード

Lノードには、Lキーが自動的に送信され、ローカルに随時保存される。
ローカルに検索をかけることで、ネットワークでどういうファイルがやり取りされているのか分かる。

//　これは、ネットワークでどういうファイルが取引されているかを表すというマイナス面もあると思うが、
//　検索ワードを外に公開するよりはプラス要素が大きいと思われる。
//　何か画期的な解決法があればｷﾎﾞﾝﾇ。

A：ローカルに文字列検索をかけ、あるファイルのLキーを入手
A：Lキーに格納されているRブロックハッシュでダウンロード要求

B：ダウンロード要求を受け取る
B：Rブロックを所持していれば、A以外のノードにA宛てでRブロックを送信

A：Rブロックを全てダウンロード、ハッシュ値を確認、RブロックをLキー内の暗号鍵を使ってデコード
A：Rブロック内のLブロックハッシュでローカルを検索し、無ければLブロックハッシュでダウンロード要求

C：ダウンロード要求を受け取る
C：Lブロックを所持していれば、A以外のノードにA宛てでLブロックを送信

A：Lブロックを全てダウンロード、ハッシュ値を確認、LブロックをRブロック内の暗号鍵を使ってデコード。
A：LRブロック結合。Lキー内にある結合ブロックのハッシュ値で確認、さらに、Lキー内の暗号鍵を使ってデコード
A：元のファイルのハッシュをLキー内にあるハッシュ値で確認したのち、Rブロックを削除

＞Freenetでは、ネットワークに参加する各ユーザーが、ハードディスクの一部をアップロード
＞されたコンテンツの保存用に提供する。コンテンツは暗号化されるため、誰も自分のハード
＞ディスクに何が保存されているのかは分からないし、意図的に特定のコンテンツをホスティ
＞ングしたという責任も問われない。
http://www.zdnet.co.jp/news/0210/29/ne00_freenet.html

という事はｗｉｎｎｙからキャッシュ編集機能を廃止したようなものを作れば良いのでは？
でもそれだけだと延々と膨れつづけるから必要であれば容量設定できるようにして。
ＵＰするときも暗号化して同じフォルダに放り込む。winnyでいうＵＰフォルダは存在しない。

中継処理は省いています。

全体の半分しか所持していないということは効率が悪いが、安全性を高めていると思う。
Aからすると、Rブロックを全てダウンロードしないと、
自分のところに目的のLブロックがあるか分からない状態です。

ダウンロード途中で、ローカルにあるRブロックは何であるか分かりますが、アップされません。

この時点で、LノードはLキーかLブロックを、RノードはRキーかRブロックしかアップしないことになります。
つまり、最初の放流主がLノードにいたとして、Rブロックを転送すればバレちゃうでしょう。

つーわけで、Rノードとして繋げてアップするなりなんなりの対策が必要です。
処理はかなり複雑ですが、かなり効果はあるかと思います。
あと、最後のハッシュ値の確認は省いてもいいかも。二重にハッシュ値を確認しているので。

Jony氏ｷﾀｰ！！

>>Jony氏
出来ればWikiに書いていただけるとうれしい・・・

>>43
それ先日オレが言った。
けどいい案だとは思う。

裁判長「被告○○は、○○ソフトのゲーム「恋する妹はせつなくてお兄ちゃんを想うとすぐＨしちゃうの」
　　　　　および「大好きな先生にＨなおねだりしちゃうおませなボクの／私のぷにぷに」を無断で
　　　　　アップロードしたに相違ありませんね？」

('A`)　 「聞き取れませんですた。もう一度おながいします。」

裁判長「被告○○は、○○ソフトのゲーム「恋する妹はせつなくてお兄ちゃんを想うとすぐＨしちゃうの」
　　　　　および「大好きな先生にＨなおねだりしちゃうおませなボクの／私のぷにぷに」を無断で
　　　　　アップロードしたに相違ありませんね？」

('A`)　 「はあ? 違います。私がアップロードしたのは「(個人撮影)超美少女セックス大好き女子高生
　　　　が中出しだらだらでほんとにいいのか？(めちゃかわいいです）」という動画ファイルであって、
　　　　「恋する妹はせつなくてお兄ちゃんを想うとすぐＨしちゃうの」とか「大好きな先生にＨなおねだり
　　　　しちゃうおませなボクの／私のぷにぷに」などというゲームは全く知りません。

裁判長「えっ、では被告○○は、○○ソフトのゲーム「恋する妹はせつなくてお兄ちゃんを想うとすぐＨしちゃうの」
　　　　　および「大好きな先生にＨなおねだりしちゃうおませなボクの／私のぷにぷに」を無断で
　　　　　アップロードしたのでは無く、・・・ん　んん　「(個人撮影)超美少女セックス大好き女子高生
　　　　　が中出しだらだらでほんとにいいのか？(めちゃかわいいです）」という動画ファイルをアップロード
　　　　　したのだね」

('A`)　 「 え　?すんません。聞き取れませんですたのでもう一度おながいします。」

>>49
ずっといますよｗ

>>50
申し訳ない。
早速タイプミス→偶数奇数になっとる→が見つかったので、修正してからWikiります。
Wiki初体験……。

>>52
ノイズと言いたいがﾜﾗﾀ

>>53
ありがとうございます。
がんばれ！

>53
すでに出てましたか…。
思いつきで書いてしまったもので。申し訳ない。

なんかよくわからんがガンガレ

Jonyってなんだ。くせ者め！

ていうかすごい専門的っぽくて
「ほほーう」
と感心しました。

僕らに最高のクリスマスプレゼントを

首
をつって出直します。
手のだけど

あたらしいネットの誕生ねット

ある一定の割合でダミーデータを送信するというのはどうでしょうか？
効率は落ちてしまうが、実際に送っているデータをわかり難くする
ことは出来る。ダミーデータに何か機能を持たせれば、交換が目的
ではないと言い逃れも出来る。

http://2.csx.jp/~p2p/
を作った方へ
すみません。勝手にリンク張りました
http://s2net.s41.xrea.com/
それとWikiの活用、よろしくお願いします。

>>48
LノードはLしかアップしないとすると、ご存知のようにRをアップした瞬間に確実に特定されてしまう。
あるノードがLノードかRノードかという情報は、LRキャッシュの転送率を比較すればすぐにわかる。

Lノード、Rノードは決めずに、LもしくはRのどちらを最初にダウンロードするかはランダムで決定し、
最初にダウンロードした方を残すとした方が、より特定されにくいのではないかと思います。

どっかで見たけど、シェアウェア化ってのは面白いと思った。
1本1億円くらい、パスワードはバレバレにしておく。
一般ユーザーはフツーに使える（作者は訴えない）が、
警察とか出版社とかは金払わないと使えないという。

この方式の最大の利点は――
「外部からは常にキャッシュの一部しか見えない」状態を利用するということです。
自分が何を持っているのかはわかりませんが、それが完全ファイルにならないように
他のノードとお互いを助け合う、という連鎖です。

また公開許可キーによってほとんどの通信を一方通行(同じノードとは通信しない)にすることができます。

＞65 基本的に、K察が一般ユーザーとして購入するのを防げないのでﾀﾞﾒ。その手の案は皆弱い

>>63
ごめん、なんかWiki壊しちゃったみたい……。
意見、のトップページが……。

>>62
ny以上にトラフィックの問題が深刻になる。

ファイルを三つに分ける。
本体キャッシュ・・・全体の95%程度。
結合用キャッシュ・・・キャッシュの5%程度、もしくは何バイトか。
情報キー

本体キャッシュはフォルダに任意固定。
結合用は常に流動させる（アップ本人であっても）。ある程度の上限でアプリ側が消去、
更新する。
結合用キャッシュと情報キーは連動せずに流れる。
情報キーから本体キャッシュをダウン、終了後そのノードとの回線は切断。
そして結合用キャッシュを検索、ダウンして結合する。

どうでしょう？既出っぽいけど・・・

>>67
一応一般ユーザーも勝手に使うのは違法（だが訴えない）
警察が一般ユーザーとして勝手に使ったら訴える

上のようにすればいいんじゃないの？（言ってることは>>65と同じだが）
甘いかな？

匿名性も大事なんだろうが、トラフィックを必要以上に出さないというのもクリアしないといけないんだろうな。

ひとつだけ言っておく
君達はすでに大失敗をしている

どんなシステムを作ろうと無意味

>>72
そうだな。
怪しい挙動だといろいろと厄介だからな。

>>70 part2くらいでｷｼｭﾂ。ｷｰ・分割情報・ブロック。ああなつかしい。いまはその発展形をギロン中、かな？

>>64
自分ノードがLノードかRノードかというのは周りのノードに公開されます。妄想上では。
アップする場合は、対極のノードのようになりすまし、ランダムウェイトの後送信するとか、
または対極のブロックだけを別の場所で配布してもらう（ローテク最強！）とか。

副作用的なもんですが、
対極のキーとブロックがペアで存在すれば、両方用のキーが作れます。
意味があるかは不明……。

こんなのみつけた。SFCの香具師だな。

http://www.sfc.wide.ad.jp/kg/neco/wiki/survey/ExcessBasedEconomicModel.html
http://www.sfc.wide.ad.jp/kg/neco/wiki/survey/tarzan.html
http://www.sfc.wide.ad.jp/kg/neco/wiki/survey/%C8%EB%CC%A9%CA%AC%BB%B6%CB%A1%A4%CB%A4%E8%A4%EB%C6%BF%CC%BE%C4%CC%BF%AE.html
http://www.sfc.wide.ad.jp/kg/neco/blog/archives/000010.html
http://www.sfc.wide.ad.jp/kg/neco/blog/archives/000011.html
http://www.sfc.wide.ad.jp/kg/neco/blog/archives/000013.html

こんなのも投入。
こっちは電通大だな。

http://www.spa.is.uec.ac.jp/~kinuko/wikiform/wikiform.cgi?url=data/p2p-workload.txt
http://www.spa.is.uec.ac.jp/~kinuko/survey/survey.cgi?cmd=index

>>68
ﾜﾗﾀ

>>63
お手数かけますた……。

>>77 おもしろい！！

>>71
不法な手段で得た証拠には証拠能力はない。
だから、次期P2Pソフトが「起動してからのお楽しみソフト」、という名目で
シェアウェア登録すれば、警察はそのソフトを使ってファイル交換が
出来るという事実を知っていれば不法にパスワードを破ったことになる。
一見完璧な気もするが・・・。

>>82 著作権法違反は親告罪らしいので無意味。っつうかその手の話題は法ｽﾚで

>>77

参考になります。　少し熟読してみます。

>>77

参考になります。

>>76
自分がデータを流すのはLだけ、
Rは要求があって初めて転送を装って流せばいいんじゃないの？

まさかLノードはRのデータを転送できない、
というかLとRのホストたちは別のネットワークを形成するってことか？
LがRのデータを持っていることがおかしいということは。

>>86
対極のファイルをうぷ・中継することはあるが、した後に削除すると。
なるほど。そうすることで解決しそうですね。

ツッコミ感謝いたします。

>>87
うぷ・中継の区別が付かないことを前提として。

これから一時熟読タイム？

99%だろうが99.9%だろうが1つのノードが100%のキャッシュを保持しなければ同じじゃない？
暗号化して100%キャッシュにしないと元ファイルに絶対変換できない様にしないとならないけど。

>>90
俺もそう思うが考えるのが疲れた。
50%のリソースを持てない仕様ってのはどうなんだろうな。

>>91
最低でも2つのノードがキャッシュ持ってないとお目当てのファイルが落とせないって点は同じだけど、
50%しか持てないとなると完全ファイルが落とせる可能性が低くなって、
キャッシュ保持ノードを見つけるまでの時間もかかるようになっちゃうような気がするんだけど。

100％の完全ファイル、もしくは完全キャッシュがﾉｰﾄﾞ上に存在しなければ

次に危ないのが全体の99.9を保持し続けてるﾉｰﾄﾞしかないだろ

>>90
責任の分散を目指すならば、ファイルを等分して分散することになると思うけど。
（責任の分散が有効かどうかは別にして）

完全ファイル公開してパス後で教えてるのと同じ・・・。

だから50/50で平均化しましょってことでしょ。
違法ファイルを交換する場合、絶対にリクスは生じる。
責任の分散化と平均化が重要。

分散する量が多ければそれだけDLするチャンスがあるし。

Winnyで逮捕されは、upフォルダに自分が権利を保持していない著作物を置いていたから。
本人が何か全く分からず、かつ、半分以下しか保持していないとすると、安全性は上がる。
絶対ではないのは前に述べたとおり。

しかし責任の平均化となるとランダムバイトで分割はできないのか？

99.9%を保持してるノードには自分が何をうｐしてるのかはファイルからは解らないって仕様に。
これが暗号化。
99.9%を保持してるノードもUPする場合は分割転送を前提にしてる。
50%の時だってブロックファイルはもっと細かいものになるんでしょ？
ﾀﾞｳｿ要求ノードが多い時は細切れファイルでもUPノードになれるような仕様の方が
効率上がると思うけど。

>>95
この場合同じノードがPASSを送ったら絶対アウトだろうけど、
PASSは別ノードからしか送られて来ないんだよ。
ファイルを送ったノードはPASSを知らない。

>>98
逮捕されたのは

それから、上記のRAIDライク管理法でも、保持できるキャッシュは50％以下です。
実際にはさらにブロックで分割される予定です。
っていうか、そうしないとレジュームできない。

ファイルのどの部分からでもダウンロードできるのだから、
100%近くキャッシュがあった場合、今後はマズイと思う。
全部をDLしなくても10%のところからを...20%のところからを...90%のところからを
という感じで突付いてDLしてみるツールがあれば、平均何%そのキャッシュを持ってるのか
わかるような気がするし・・・。

>>100
99.9%のキャッシュを保持しているノードは、決して0.01%のキャッシュを保持してはいけない。
また、99.9%のキャッシュを保持するノードが高速かつ大容量ハードディスクであるとは限らない。

状態を均質化することは、不安定なP2Pネットワークにおいて強い耐性を持つことができる。
理想的には全員が完全キャッシュを保持することだけど、それが危険なので50/50にするってこと。

>ﾀﾞｳｿ要求ノードが多い時は細切れファイルでもUPノードになれるような仕様の方が
>効率上がると思うけど。
これは50/50だろうが、99.9%だろうが同じこと。

>>96
二人なら50:50なんだけど、
そうでなければ最大50:1/nなんだよな。
誰もが50%を持っても平均になるし、
誰もが99%を持っても平均。
持ってる割合で何が左右されるんだろ。

>>104
最後の0.1%をISDNに持たせるようにすると彼らも日の目を見れるね・・・

転送はどうするかなっとコーディング中。俺的にはいらないから付けたくねえ。

>これは50/50だろうが、99.9%だろうが同じこと。
50%しか持ってない奴が近くにいるよりも
99.9%を持ってる奴が近くにいるほうが、
ほしいブロックを持っている奴を見つけやすいって言う単純な話だろ。

k察は違法調査をしないことが建前となっている。

つまり、今回の件では、K察は、著作権ファイル（の一部さえ）をアップロードせず、
著作権ファイルをダウンロードしたことにしているはず。

winny2ではこれが可能だった。

次期P2Pでは、これを不可能な仕様にすればいいのでは？

具体的には、「完全ファイルを作る条件として、１つ以上の不完全ファイルをUPしなければならない」
とか。

内容を知らない不完全ファイルのUPは、違法でないとk察が言ったとすれば、
ファイル分割仕様にすればいいだけ。

>>109 法ｽﾚ池

ブロックにして転送かませば匿名性もあがる。
後は個人がどれぐらいキャッシュを残しておけるかだ。
良識？に任せるか…。

で、何がしたいの？

隣接ノードに情報を漏らさない方式にこだわっていた前スレ849です。
前スレの352,514,533などを参考に、キャッシュを分割する必要のない
転送方式について意見をまとめてみました。
ずいぶん複雑になってしまい申し訳ないのですが、読んでいただければ幸いです。

----------
公開鍵暗号方式を採用する。公開鍵、秘密鍵はソフト起動時に自動的に作成され、
ユーザーは（クラックしなければ）知ることはできないとする。
初期状態ではノード間の接続は以下のとおりとする

　E
　|
　A-B-C-D
　|
　F

以下、DがAからファイルをダウンロードする場合について述べる。
特に明記していないが、当然各ノード間の通信は暗号化されているものとする。
----------
続く

----------
・キー拡散段階
�@　CがBに「CのIPアドレス」と「Cの公開鍵」をセットにして送付。続いてBがこれらをAに転送。
�A　AはCの公開鍵で「Aのupファイルの情報（ファイル名、ハッシュなど）」を暗号化し、
ここに「Aの公開鍵」と「CのIPアドレス」を添付したキーを作り、Eに送る。
�B　EはEの公開鍵で「AのIPアドレス」を暗号化し、キーに追加。
さらに「Eの公開鍵」、「EのIPアドレス」をキーに追加してCに送る。
�C　Cは秘密鍵で解読し、「Eに接続している誰かが持っているファイルのリスト」
を手に入れる。この時点でCの持つキーには

１．Eに接続している誰かが持っているファイルの情報
２．Eにより暗号化されたAのIPアドレス
３．EのIPアドレス
４．Eの公開鍵
５．Aの公開鍵

の情報が含まれる。
----------
続く

----------
・ファイル転送段階
�@　Dがファイルを検索し、Cが保持するキーを見つける。DはCから
「Eに接続している誰かが持っているファイルの情報」、「Eにより暗号化された
AのIPアドレス」、「EのIPアドレス」、「Aの公開鍵」をダウンロードする。
ただし、もしもこのとき Dの公開鍵=Eの公開鍵 なら、Cはキーを送信しない。
�A　DはAの公開鍵で「欲しいファイルのハッシュ」と「DのIPアドレス」を暗号化し、
「Eにより暗号化されたAのIPアドレス」、「Dの公開鍵」とあわせてEに送付する。
�B　Eは「AのIPアドレス」を秘密鍵で解読し、残り3つの情報をAに送信する。
�C　Aは「Dが欲しいファイルのハッシュ」と「DのIPアドレス」を秘密鍵で解読し、
Dの公開鍵で対象のファイルを暗号化して、Fに転送を依頼する。
�D　FはDにファイルを転送する。

■メリット
・完全なファイルをアップロードできるので、分割されたデータの
1部が消滅する問題はない。ランダムな転送も発生しない。
・「誰が」「何のファイルを持っているか」の2点について同時に知ることは
できない（不確定性原理!?）ので、Aが保護される。
・何を転送しているのか知ることができないので、Fも保護される。

■デメリット
・キャッシュを分割する方式とは異なり、絶対に転送が必要。
・転送によるキャッシュの拡散がない。
・アップロードのたびにファイルを暗号化する必要がある。
・DとEがグルなら逮捕
・DOMが増える?

----------
以上。
ここでは分かりやすくするために転送は1段階としていますが、
さらに増やすことにより匿名性は向上すると考えられます。
おかしな部分があればどんどん叩いてください。

一台が一つipアドレスを持たない今はどうするのでしょう？

>>113-115
ネットワークの動的な再構成にとことん弱いことと、
書かれているとおりキャッシュの拡散かな。
これと、既存の方法を組み合わせれば結構いいんじゃない？

ちょっと説明が理解しにくかったけど(私の読解力がない)、良い考えだと思いますね。
DとEがグルになる確率はかなり低くなると思いますし。
ただ、公開鍵で暗号はかなり非現実的です。DH方式で共通鍵を作成するか、
公開鍵で共通鍵を交換した方が良いかと思います。

キャッシュについてはこんなのもあった。
http://ca.geocities.com/fosae2003/

要するに、ファイルを分けて、２つに分けてアプリを起動したら、検索リンクと
つなぐ時に、情報キーを絶対UPとDLしてかた、使えるようにすればいいのかな？
ここに出てる案って、nyの改良止まりだね。

やっぱりIP偽装が次の課題になるんだろうね
K察も法改正とかして、強くなりそうｗ

>>119
アプリは1つ。
初回起動時にLかRに配分される予定らしい。

法律板からのフィードバック〜

[転送]
<著作権法(刑事)>
(可能性1) 送信行為に該当。アウト
(可能性2-こちらの可能性高し) セーフ

<損害賠償(民事)>
ファイルの転送防止が不可能、またはファイルの流通を知らない、
または流通は知っていてもそのファイルが著作権を侵害してると
知ることができない場合には、責任を負わない(そうでなければ負う)

[ダウン]
セーフ。
ただ、ダウンしたものがそのまま送信可能になって
著作権侵害状態になる場合はアウト。

>誰が」「何のファイルを持っているか」の2点について同時に知ることは
できない（不確定性原理)

言葉の響きは何だか魅力的だな、量子コンピュータみたいだ。

>>116
ネットワークもプログラミングも暗号もほとんど知らない厨なので、
おかしなことを言っていたらごめんなさい。
この場合、mxやnyはどうするんですか?
上の案の「IPアドレス」の部分を「IPアドレス＋ポート番号」にすれば解決します?

>>117
なるほど、既存の方法と組み合わせるのはいいアイデアですね。
レアファイルをこちらの方式である程度拡散させた後、
キャッシュを分割する方式を採用すれば、効果的かもしれませんね。

>>118
あんな分かりにくい説明で理解していただけたようで、ありがとうございます。
暗号についてもさっぱり分からないので、改良していただければありがたいです。

>>115
まずこの処理は不可能だろう。
>「EのIPアドレス」をキーに追加してCに送る。
CのIPアドレスはCの公開鍵で暗号化されてるんだろ？
キー情報にはCの公開鍵で暗号化されたCのIPアドレスしか載ってないように見えるが。

そんな複雑な処理にする利点が見えない。
どんなに暗号化をしても直接接続してるピアのIPアドレスは丸見えなのは仕方ない事。
転送ノードにはﾀﾞｳｿノードのIPアドレスとUPノードのIPアドレスが解ってしまうのも。
だから1セッションで全てのファイル転送を終える事は避けたい。
転送してるファイルが何なのかが解らなければkが転送ノードに入ってきたとしても
証拠となるような情報は得られない。

>・キャッシュを分割する方式とは異なり、絶対に転送が必要。
キャッシュ分割方式でも転送を絶対条件にする事は可能だと思う。
流れてきたﾀﾞｳｿ要求キーを受け取ったUPノードが別のノードにﾀﾞｳｿノードのIPアドレス通知して
転送を依頼すれば良い。

>>109
でもさ、もし意味の無いテキスト置かれたら死亡じゃん？

>>125
このあたりは、オープンソースを前提に考えるとかなり難解になってしまいます。
自分も、妄想→穴発見→改良→穴発見→どうしようもない→根本から妄想し直し
を繰り返しているので。

>>124
>まずこの処理は不可能だろう。
>>「EのIPアドレス」をキーに追加してCに送る。
>CのIPアドレスはCの公開鍵で暗号化されてるんだろ？
AはCのIPアドレスは暗号化してないような。。。

存在をごまかす事に必死過ぎないか？
そもそも消す事は不可能なんだぞ。
という事は探せば何れは見つかるってことだ。
それでも今回のぱくられた奴等みたいに馬鹿やらなきゃ
nyやるぐらいでそう簡単にぱくられんだろ。
nyの次を考えるのか、nyよりも更にぱくられ難いようにしたいのか
そこらがはっきり見えない。
逮捕にびびってのnyの改良案出しなら不毛過ぎる。
nyをもっと手軽に簡易に、普及を促進させるだけで
ぱくられる可能性なんてどんどん薄くなる。
そちらの方向の方が47氏のお茶目な思想にも近いだろうし。

いくらIPアドレス偽装したって、しょうがないだろ。
転送ノードなのか、uploadノードなのかの見分けをつかなくすることが重要。

1.uploadノードがファイルを分割。分割前と分割後のハッシュキー生成
2.ファイル情報は、リクエストとは関係なく互いに流通しあう
3.upload／転送ノードともに、downloadリクエストに対して、1IPアドレスに
対して、1分割ファイルしか転送しない。
4.つまりdownloadノードは、IPアドレスの違うnノードから分割ファイルをget
してこなければならない。

n個のファイルに分割した場合、最低でもnノードからのgetリクエストがないと
ファイルは完成しないけど、それくらいのリスクはいいだろ？

>>128
基本的には賛成だがスレ違いなのでどっかいいとこ探してください。

だって技術論のみで右往左往してるように見えてさ。

まぁそう焦る事もないっしょ
期限も無いんだし右往左往しててもいいんじゃない？
いずれ結果が見えてくるさ

一番重要なのはどのようにして共有ソフトをバージョソするかだと思う。
ニセモノのバージョソを防止するために47氏は公式サイトを使ったと思うが
結果、それが住所特定の決め手となったであろうとも予想される。
ユーザーが増えるとオークションに出したりＨＰで公開する厨房が出て
ﾀｲｰﾎされるのは時間の問題なので、その時いかに作者を守るか。
そのためにバージョソ1.0にWindowsUpdateのような機能を付ければ良いと思う。
各ユーザーは匿名ＢＢＳでの告知かソフトに組み込んだ自動Updateでバージョソを行う。
共有ソフト本体の配布はもちろん共有ソフトに放流。
その他は基本的にnyと同様でも匿名性は保証されるであろう。

まーね

>>124
分かりにくい説明、重ね重ねｽﾏｿ。
>>113の最後が誤解を招いてしまったみたいですね。

＞「EのIPアドレス」をキーに追加してCに送る。
は>>114の�Bのことですよね。
CのIPアドレスは暗号化されず、B、A、Eと流れます。

＞だから1セッションで全てのファイル転送を終える事は避けたい。
＞転送してるファイルが何なのかが解らなければkが転送ノードに入ってきたとしても
＞証拠となるような情報は得られない。
上の方法では、たとえ転送ノードがkで、1セッションですべて送信したとしても
問題ありません。AからのファイルはDにしか複合できないので。
でも、万一にそなえて転送者Fは何度か変えるべきかもしれませんね。
簡単に実装できますし。

>>133
自動バージョンは嫌う人が多いと思うけどなぁ。
どうなんだろ。
P２Pネットワークに流すだけでいいと思うよ。
デジタル署名付ければ同一ｻｸｰｼｬが流したって解るし。

>>133
トリップのすんげーの（発行者証明）つけるくらいしか対処方法ないんじゃね？

>>136
作者が特定されないか？

>>136
同一ｻｸｰｼｬがバージョンしてる事がばれるだけで特定されるかどうかは
流すネットワークの安全性と等価だと思う。
最初に公開鍵を公開する時が危ないけど。
その後は一度流れればあとは勝手に誰かが転載してくれるだろう。

>>139は>>138宛、ｽﾏｿ。

>>139
そうか。
肝心なのは初回バージョンのUPなんだな。

・ﾊﾞｰｼﾞｮﾝがどうとか言ってる方は要望ｽﾚへ

ちょっとこんなこと考えてみました。抽象的ではありますが。

　次期P2Pソフトによって完全な大規模匿名掲示板が成立したとする。
で、その中からこのネットワークやそれを成立させる社会基盤に対して
害意を持ってる奴(前者は警察や荒し、
結果的にはいわゆる厨もかな？後者は反日マスコミとか)を
どうやって排除するか。
　こいつらだって掲示板の匿名性によって
その発言(ファイル転送におけるダウンロードする側の立場）を
守られてる訳で。
特定のノードがそのスレッドを管理するなら
その管理人の匿名性は無くなるだろうし、
管理人が排除すべき分子とグルだったらどうしようもない。
管理が出来るノード・人間を増やす？
その中にやっぱりスパイがいたら？

ってことです。この命題にそれなりの解が与えられれば
これをファイル転送に応用することも出来ると思います。
自分は考えたけどさっぱり思いつきませんでしたw
　結局議論の中身がループするような気はしますが、こんな切り口でも
考えられるよーってことを提案してみます。

長文・駄文失礼しました。

>>143
＞その中にやっぱりスパイがいたら？
どうしようもありません。っていうか自分で駄文だと思うなら書かない方が良いよ

おはよー。

　スパイなんてものは　何処にでもいるんだし。
　あんまり気にしないで開発したほうがいいと思うなー

たまに違う方向性から模索するのもいいかもね。
でも、それも技術的な見地からね。
このスレの住人もたまに兄弟スレを見ながら。
定期的にフィードバック書き込まないといけないかも。
て、要望スレが機能してないから辛いが・・・。
自身の無い人・こうしたらいいんじゃ？って人は要望スレへ

次期P2Pに対する要望スレ
http://tmp2.2ch.net/test/read.cgi/download/1070085137/

>>144
お茶出すときに粗茶ですが・・・ってのと同じだろｗ
わかってやれよｗ

>>143
次期P2Pって書いてあるけど、結局nyとちっとも変わらないじゃん。それ

むしろスパイ対策が主眼になるんだが。。。

>>143
その答えはある。
その中の多数派である者達が、害を排除する。
自然淘汰もされていく。
最低限の仕組みやルールみたいなものは必要だけどね。
例えば「法律」「倫理」みたいな。ｗ

まあ　スパイやら厨房やらの排除なわけだが。

オフラインでのスパイはどうにもならんからなー。

共有を前提にしたネットワークなら厨房は排除しない方が良いって。

ｶﾞｲｼｭﾂｶﾞｲｼｭﾂ言いたくないんですが、おまいらｶﾞｲｼｭﾂ過ぎ

>>152
排除したってまた直ぐ湧いてくるんだよ。ｗ

一人が、不特定多数に成りすませないようにするのが一番大切。
んで、一番難しい。
全員がホンネで語るわけだから、現在の世論とは全く変わった世論になるだろうね。

つか、普段から変なことしてる奴は絶対にバレる。
目星付けられてキーロガー仕込まれて終わりだろ。

みなさんﾋﾟﾝﾄ外れ過ぎなんですが

　1,暗号化/複合化
　2,接続管理部
ここは非公開だね。 1は外から扱う仕様のみ公開。
※必ず1と2を切り離して公開する。

1の公開は、とても厳重な管理と、最大限の注意が必要だけど
2の部分は、「既存のライブラリを使うので、詳細な接続方法は知らない。
実際お前らの手元にあるソースの仕様もそうなっているはずだ」と言う事で"言い逃れ"出来る。

どう思う？

次期P2Pのクリアすべき課題を法的な観点から考察
http://tmp2.2ch.net/test/read.cgi/download/1070084504/
次期P2Pに対する要望スレ
http://tmp2.2ch.net/test/read.cgi/download/1070085137/

A ―――→　B　―――→　C　―――→　D
　　　↑
　　　ISPに頼んでアクセス網の段階で擬似nyネットへ経路変更
　　　させる用意をしておく

Aは容疑者
B、C、Dは恐い人達が創った仮想nyネットワーク
事前にA容疑者を内偵しておき、A容疑者がnyを起動したまま
出かける時間を把握

出かけたと同時にISPに連絡
nyパケットの経路を変更し、恐い人達とAのnyが絶対にお友達になるようにする
これができればゲキバレではないですか？
著作権侵害してるっぽいファイルくれよと言ったらAはくれるんですから

素人考えですが、怪しいと目星がつくかどうかが一番問題なのでは？
警察もこの捜査いきなりやると確実に違法っぽいですが、
長期間内偵し手続きをふんで、あるていど証拠を集めれば経路変更は可能でしょう
これは犯行の機会提供にすぎませんから

底では激流が渦巻いていても、水面が波打つ事がないネットワーク構成が理想だと思います

うるせーよ xscvHVtF

>>158
どうでもいいが、複合化じゃなく復号化
あと、それって結局プラグイン化の話だと思われ かなり実装寄り

ｽﾏｿ。間違えた

　1,暗号化/複合化
　2,接続管理部
ここは非公開だね。 1と2は外から扱う仕様のみ公開。
※必ずライブラリとフロントエンドを切り離して公開する。

ライブラリの公開は、とても厳重な管理と、最大限の注意が必要だけど
1,2以外の部分は、「既存のライブラリを使うので、詳細な接続方法は知らない。
実際お前らの手元にあるソースの仕様もそうなっているはずだ」と言う事で"言い逃れ"出来る。

どう思う？

>>162
> かなり実装寄り
そうだね。今こんな話しても仕方ないな。

だから、結局作るﾔｼが居ないのにそういう議論しても仕方ねーだろ
ﾉｲｽﾞ増えすぎ

どうしてもオープンソースにしたいなら、sourceforgeくらい使って今からプロジェクト立てろ矢
クローズドなら、マトモな実装持って鯉や

>>160
その方法だと、やっぱり、
・半分以下しかもってねー
・半分以上持ってるけど半分以上うぷしねー
っていうのは魅力的だね。
絶対に完全ファイルがアップされることはないんだからさ。
まぁ、間が悪く、原本うぷしようとしたら今出てるアイデアでは回避不能だけど。

> ﾉｲｽﾞ増えすぎ

ｽﾏｿ

もうノイズとか気にしないことだなー

>>168
ノイズがノイズ擁護かよｗ

ヽ(´ー`)ﾉさくらたん〜

sourceforge使うのなら
名前決めとかないとまずいよね。

↑こういうノイズもいるわけでして・・・ｗ

俺かＹＯ!

ヽ(´ー`)ﾉさくらたんの時代が到来

名前は立てる人が勝手に決めれば？

素直に、Winoz3
だろ。
MX→NY→OZ

NYの後継版ということで
1.14→2β7.1→3

ま、基本はテキトー。
でも名前考えるスレあるよ。

名前は決めておいてもいいが
　何かと広まりそうな予感がしたら
　変更するとか…。
　

名前は立てるﾔｼが勝手に決めろ！以降、名前関連のﾚｽ禁止。
こう言わなきゃわからないのか？立てる気もないくせに

ID変わってどれが煽り・厨かわからん漏れはもう寝ます

なんでプロジェクト立ち上げに持っていきたがるんですか？＞xscvHVtF

・クローズド開発なら、
開発者が勝手にこのスレ参考にして作り始めればよし。

・オープンの場合、
先にオープンソースプロジェクトの基本方針を決めても
どのみち立候補を募る段階で詰まるのは目に見えているので、
その前に、仕様策定とおおまかな設計を済ませておこう、という主旨のスレです。

…俺、いま良いこと言わなかったか？

まぁね

まーね

>>182-183
なかなかまとまってていいかんじ。次回から天婦羅な。

>>148,>>150,他

俺の中では、

Web割れ、MXでは結局中央サーバーの存在が
潜在的に弱点だったと思ってます。

で、nyはこれを排除した。

nyではスレッドを管理してるノードがあったから、
そのノードの匿名性が失われた。

では、これを排除して、キャッシュを多数が流動的に
管理するようなシステムにしたとする。

すると、「声と態度はでかいが多数派ではあり得ない連中」
というどっかで聞いたようなのが台頭してくると思います。

で、これを管理するために管理人を（ｒｙ
で、この中にスパイ（ｒｙ
（ｒｙ

となって無限ループに突入します。

これをどう解決すべきでしょうか。

> これをどう解決すべきでしょうか。

割れを排除する。

ｋは"後出し"してくるんだから、
こちらは先に対応しなければならない。

>>187 よくわからないんですが、すくなくともスパイ問題（K札の囮PC）は不可避ですので、責任分散というスレの流れでは

~ /先に/必ず先に/g;

>>187
多数が分散して管理するんだよ。
そのためには、その仕組みが必要だけどね。

>>191
結局、>>77に出たような自律的なシステムにせよ、これまでの ny/MX にせよ、
その中にK察のPCが居ることは判別できないので、
責任分散・リスク拡散で逝こう、ってのはものすごくｶﾞｲｼｭﾂなわけで。
で、その流れでデータの流通形態などが、議論されていたハズなのだが、
ノイズに紛れて良く分からなくなってしまった。
休憩中？

ていうかこういう経緯を何度も説明するのはめんどい

スレ建てにリスクが無かったら、クソスレが乱立するだろう。
それを排除する仕組みも必要だし。

ていうか、まずはデータ構造、送受信方法だろ。

154氏はどうしたんだろう？

？ 154って誰だ

転送するデータに宛先ノードとランダムなステップ数を暗号化して埋め込んで、
ノードを通過するたびにステップ数を減算して０になったら宛先ノードに転送する。
ステップ数が０のデータを受け取ったら複合化。
アプリ以外は現在のステップ数がわからないような仕様なら、今起きてる転送が
中継なのかどうかわからんのではないの？

>>195
514氏ぞな。　あと191氏もいるぞな。　このスレには未来が詰まってるﾓﾅー

>>198
あ、そうそう。

…前スレ191氏の降臨が待たれる、、、なんかそういうの詳しそうだったし

>>197
基本的にはそうだよねえ。で、それにファイル分割の考えが加わる。
今までの議論で、漏れが知ってるのは、

・そういった「強制転送」では輻輳を考慮しないとダメだ。
・一番初めのファイル放流元が分かってしまう。（全てのファイル断片を所持するから

あと何があったっけ。

Jony氏・z氏・wiki立てた人・元スレ1・514氏・191氏・・・後よく参加してるスレ住人は
一日一度でいいからトリップださないと混乱しそう
ま、みんな名無しのまままったりいきたいだろうからしょうがないか。

まあ、このスレを見つつすでに作りはじめてる人もいるだろう。

>>192
K察との戦いには興味ないし無駄だと思うので、
それに対する行き過ぎな対策は必要ないと思ってる。（あっちの448で書いたけど）
圧倒的なユーザー数と快適性さえ提供すれば
一時的には大きな盛り上がりと展開を見せるはずだから。
それでも皆がスピード違反をし続けるかどうかは、俺の知ったこっちゃない。
所詮K察は気まぐれ的に逮捕をするだけだから。
目立つ行動をしなきゃいい。後は運だ。
次のP2Pを作るなら（NYの次として）NYよりも快適であることが必須だと思う。
結果普及がNYを超え食い潰すぐらいの勢いも欲しい。
NYはいいとこまで行ってたのに、ほんとこのまま終わらせるのは残念だ。
まだそうと決まったわけじゃないけどね。ｗ
皆頑張って。俺はそろそろ寝ます。では、

>>203 その程度の希望ならnyで十分なんですよ。まぁnyはもうダメですが。おやすみなさい。

>>197
それ、ムリなんよ。
ランダムのステップ数の最大値を付けて送ってきた奴がうぷってバレる。

>>205
たとえば、ある程度の接続を把握してるものとして
その知りうる最大値より大きい値で送出したホストがいない保証を得る方法は？

>>205
分割UPを合わせればばれても問題なくない？
最大値を付けたノードが完全ファイルを持ってるかどうかは解らない。
一部ブロックしか保持してないノードかどうか解らないじゃん。

>>206
例えば、その数値が0〜10の間であったなら、
10を付けて送ってきた奴がうぷノードってバレる。

すぐにはバレないが、長期間見張られていると、バレる。
これを防ごうとすると、10・・・11・・・12・・・と、どんどん増やさないと。

>>206
仕様上ステップ数に上限を設けないなんて出来ないでしょ。
そうすると上限一杯のステップ数をKの転送ノードに送った場合ばれる。

次期P2Pの仕様スレとここの温度差がすごいんだけど・・・。
向こうは北極でこっちは南国のような。
向こうのぴりぴり具合がすごすぎ。

結局、最大値は10くらいが限度だと思われ、いやムリか。3か4くらいかな

>>210
誤爆すまん

>>210
…

>>208
そうだな、データ型にも上限はある。
すっかり忘れてた

>>214
だから、
中継側が、ランダムでさらに中継するか、転送するか選ぶようにしたら？
っていうところで止まってる。

む？転送と中継の違いってなんでしたっけ（申し訳ない。。。

中継と転送って別の意味で使ってたの？
漏れは同じ物として使ってたけど。

またｶﾌﾞｯﾀ。ｽﾏｿ。

Aに送ってくれ！　ってデータがあったとして、
それをBが受け取る。
・Aに送らずCに送る（さらに中継）
・Aに送る（転送）

って勝手に命名してた。ｽﾏｿ。

中継と転送は同じでしょ？

キャッシュとバッファは違うけど。

データ保持者も、中継点として偽装するのはダメ？

今までの流れ
　データ保持者 → 中継 → 要求者

案
　(偽)中継 → (偽)中継 → データ保持者(中継に偽装) → 中継 → 要求者


データ保持者より上にもデータを流さなければならないから、
大きいデータのやり取りするとトラフィックは凄くなりそうだけど…。

ここに時間差送信案も加えれば、追跡は更に困難になると思う。

ダミーデータを流すのは、
トラフィックに問題ありって上で指摘されてなかった？
偽中継からのデータの流れは無いの？

＞中継側が、ランダムでさらに中継するか、転送するか選ぶようにしたら？

こいつを言い換えて、

新規の放流の中継側は、
・データを保持してそれ以上流さない（キャッシュ）か、
・さらに転送するか
ランダムで選ぶようにする。

ってことか。

>>221
えと、データ保持者（原本放流者）だった場合は、
他のノードから何かダウンロードしているときに、アップを行う。
っていうことでいいんですかね？

Twofishとか、暗号化する度に結果が違う暗号とかなら、
偽中継者・放流者・要求者全てを監視していないと、だれが放流か分からなさそ。

>>223
新規放流の中継か、中継の中継か判別できるのはマズいっしょ。
とりあえず、データを受信したら、
・データを保持してそれ以上流さない（キャッシュ）
・さらに転送（さらに中継）
・指定されたノードに送信
の三択？

しまった、コテハンでへタレアイディア書きこんじまった。

訂正。

>> データ保持者より上にもデータを流さなければならないから、
　　　　　　　　　　　　　　　↓
データ保持者より上からデータを流さなければならないから、

> ダミーデータを流すのは、
> トラフィックに問題ありって上で指摘されてなかった？
> 偽中継からのデータの流れは無いの？

うﾞ〜ん…、話の流れを読んでると、みんな割れ物を流したいらしいけどさ、
小さいデータをやり取りするなら転送量もそこまで凄くないと思うんだ。

# ここで言う小さいデータは、IMやChat等の数b-数Mb程度のファイルの事。

漏れが考えてるのはこんな感じ。
A=元ファイルUPノード
B=中継ノード兼ﾀﾞｳｿ要求ノード
Bは1ブロックでもﾀﾞｳｿ完了した時点からUPノードにもなる。

　　　　　　 B←B→B→B
　　　　　　↓　 ↑ ↓
　　　　B←B←A→B→B
　　　　　　↑　↓　↑
　　　　　　 B←B→B

>>225
うーん、というか、
新規放流では、ファイルをあたりに拡散させることが目的で、
要求があった場合、ファイルを持つノードからまた中継で逝くワケで。

新規放流の場合のみ、キャッシュするか転送するかの判定をすればいいワケです。

む。しかしランダムにせよ輻輳するか。。。ふむむ

>>228
そのファイルが出回ってなかったら、新規放流とみなして……ってことでつか？

うｐフォルダに入れるファイルが新規放流です。
この新規放流をバレないようにするには？という議論のはず。

う・強制転送と混同してたみたいだ。うーんまとめないと。。。

Aは1ノードに全ブロックをUPしない。
Bは足りないブロックをB同士で補完し合う。
AとBの区別が付けられなくない？
全ブロックﾀﾞｳｿ出来たBはキャッシュを削って完全キャッシュの保持ノードに
ならないようにしても良いし、しなくても良い。
匿名性の観点からはした方が良いと思うけど。

>>232
なんか、話がお互い噛み合ってない気がしますがｗ
こっちは、なんか、分散保存することによるファイル消失を防ぐアイデアが浮かんできますた。
どんなデータが流れているかというのが分かっているとするならば、
あるデータが流れてきたとき、それが全く出回っていなければ、さらに拡散、
出回っているようならば、拡散はせずにキャッシュ。

……なんともいえないな。

ファイル転送についての仕様決定議論もいいけど、
ＰＣが他人に渡った時にデータがどうなるかってのを
考えると、アプリ起動時に毎回パスワード聞いてきて
何回か失敗するとアプリ及びキャッシュを自動削除するって
機能はいらない？

>>235 それはかなりどうでもよさそう

>235
アイコンはドクロのマークな。

Bが全部kのノードになったら困るから、
AがUPする時のみﾀﾞｳｿ要求を出してないノードに中継させるようにしても良い。
もちろん複数の中継ノードに分散させてUP。

>>235
たとえば警察が触るにしてもめったなことはできないから、
事前にバックアップとるだろ
故障したら証拠能力だって失うんだし

つか、次のスレタイは
■次世代P2Pファイル共有ソフト part7■

はやくもブームが来ている次世代Ｐ２Ｐは　『手渡し』　間違いない

まじめな意見言うと、ｎｙがｍｘより一気に広まったのは
なにより簡単だったから、だから広まるとしたら
操作簡単、バカ以外使えるってのが最低のポイントだと思ふ

思えばｎｙの未来なんたらって文書がｎｙのＨＰに載った時には
Ｋ札から作者たんに警告が来てたのかもね

>>241
ソレ、読んでないんだが何とか読める手段ある？

googleのｷｬｯｼｭを利用。多分これ
http://216.239.57.104/search?q=cache:xAlod_w9srEJ:www.geocities.co.jp/SiliconValley/2949/ny.html+winny%E4%BB%8A%E5%BE%8C%E3%81%AE%E5%B1%95%E6%9C%9B&hl=ja&lr=lang_ja&ie=UTF-8

>>242
ny展望
http://www.geocities.co.jp/SiliconValley/2949/ny.html
Winnyの将来展望について（2003/10/10）
http://216.239.41.104/search?q=cache:xAlod_w9srEJ:www.geocities.co.jp/SiliconValley/2949/ny.html+&hl=ja&lr=lang_ja&ie=UTF-8
http://www.geocities.co.jp/SiliconValley-Oakland/9164/ny.html

デジタル証券によるコンテンツ流通
http://www.geocities.co.jp/SiliconValley/2949/Digikabu.html
デジタル証券によるコンテンツ流通システム
http://216.239.41.104/search?q=cache:ZiyjbIQuni8J:www.geocities.co.jp/SiliconValley/2949/Digikabu.html+&hl=ja&lr=lang_ja&ie=UTF-8
http://www.geocities.co.jp/SiliconValley-Oakland/9164/Digikabu.html

アイコン、Ｐ２Ｐ画面を１８禁仕様にすればいい。

>>241
ここにいる人はnyで捕まった人みたいな馬鹿なことはしないと思うから
房でも利用したほうが得策では？　
ノードとしての役割はきちんと果たしてくれるわけだし。

大半の方が厨房排除を唱えてるけど
扱いが難しくても、房がいなくても、捕まる時は捕まるだろうし
第一、鯖をもたないnyみたいなP2Pソフトは
ノード数が減ることは、かなり問題じゃないかと。

>>246
禿同。

>>246
たしかに。freenet + frost入れてみたけど、匿名性を優先した結果
クソ重い…そして、あきれるほど人がいない…
正直、今作ろうとしているP2Pもこうなる可能性があると思う。

>>248
だからnyができたわけだ

一応関連記事・既出だったら禿シクスマソ

AOL、Nullsoftのファイル交換ソフト1日で公開中止
http://www.zdnet.co.jp/news/0306/03/nebt_05.html

「廃棄処分」後も生き残るNullsoftのP2Pソフト
http://www.zdnet.co.jp/news/0309/29/ne00_waste.html

WASTE sourceforge
http://waste.sourceforge.net/

今のところトラフィックが大きすぎて普通のネットワークでは
使えない代物らしい．

というわけで，個人的には「ネットワーク上でのポエム分割管理」に一票

とういより最初から違法なファイルを交換するソフトではなくて
作文共有ソフト.exeとかにすれば？

ニューズグループはニュースを流すネットです。
IRCはチャットをするネットです。

test

やみ鍋っぽいの出来ましたか？

NYでもやっていたのかも知れんが、うぷフォルダのファイルは無条件に
近接ノードに広げてしまえば良いと思う。ダウソ要求の有無に関わらず。
その方が出所を見つけ難かろう。

新しいのを考えた。
今度は車がメイン
例えばAが100Gもってたとしよう
それを別のHDに暗号化しておく
それをBのノードに届ける。
すると一日で100G
つまり、500人のユーザーがいたとしたら500ｘ100Gのファイルを持つ事ができて、
約500日で最初のハードが帰ってくる。
このとき家が近ければ数時間で巡回するし、遠くても1日。
どうだろか？
抜けがあったら教えてくれ

テンプレがこれじゃあ かんせいしねぇよ

>>256
これいいな。
これをNY3となづけよう。

俺は知っている。
12月24日にすばらしいP2Pが発表されるということを・・・
その名もWin1224







願望の話です。

不審なトラフィック増にはどのように対応するか？
これをクリアできるp2pソフトは未だに無い。

断片だけ話し合ってなんか意味あるの？
ファイル共有ソフトを作るつもりは無いんだけど作る技術を持っている側からすれば、
複雑な割に対して効果の無い様な聞こえの良い物ばかり出てきているだけに見える。

まず自分がどの程度のスキルがある事を示し、その上でどう言った方針で
行くのかを提案する事から始めると良いよ。
このままでは殆ど意味が無い。作る奴が自分の持論、もしくは他のP2Pを参考に
して作る事になる。

>>261

漏れは作るスキル無いんだけど、どの程度のスキルがあれば出来るモンなの?


まずは、オープンソースでベースのみミンナで構築するとか
出来るところから進めていく方が良いと思うんだけど

47氏が作り始めたときもそうだったよな
ほとんど自分の中で考えがまとまってて、ここでは意見を聞くみたいな感じで
作られてたし。やっぱ誰か作り始めなきゃ仕様を話してても進まない。

>>260
今現在光での用途はP2Pくらいしかないのが現状だけど
今後ブロードバンドコンテンツが普及すればトラフィックに関しては解決できるかと。
木を隠すなら森。

転送前にオリジナルポエム※ソフト使用者に著作権があるファイル(以下ポエム)
を互いに交換して、更にファイルの転送と同時にポエムを他所にばらまくってのはどう？

A--Sが調査DLしたりすると、接続先のポエムを他所に転送してしまうから
調査DLしただけでA--Sの振りかざしてる「公衆送信権」を自ら侵害することに・・・

ポエムはインスコ時に作成
ウイザード上で作らないとインスコできない。
※ポエムファイル(*.pem)が無い又は空っぽだとノードに繋がらないor起動しない

結局何やったって捕まる奴は捕まると思うけどなぁ。
どんなに匿名性だとか、あらゆる手を使ってもね。ソーシャルハッキングっていう
言葉は当然知ってるよね？どんなに素晴らしいセキュリティシステム組んだって
使う人間がプアだったら簡単にパスワードとか情報なんて漏れる。
Winnyだって、ネットワークのみで追跡＆被疑者特定に至ったかどうかなんて
非常に怪しい。



「天網恢々疎にして漏らさず」

意味わからなかったら辞書引いて。

>>263に同意
だが作ってくれる神がいないから困ってるんだろ？
製作宣言してる香具師らは何人かいるがいまいち信用できないし・・・・
まぁ47氏が作り始めたときも信じてなかった香具師がほとんどだったろうし
こんなんでもいいのかな？

>>261
物を作るわけじゃないのに、スキルや方針を個々が示す必要があると思う？
ここは悪い言い方をすれば、薀蓄スレだよ？

>>266
「ソーシャルエンジニアリング」なら知ってる。

意味わからなかったら辞書引いて。

>>266
意味は同じだよ。要は人から直接聞き出したり、ゴミ箱から書類を拾い出したり
して情報つかんだりね。

レス番間違えた。

>>269ね。

（ノﾟДﾟ）おはよう

おはよ〜。
やっぱり全然話進んでないね。ｗ

■変形RAID5案概要

まず前提として考えたのは、暗号化をしないことです。なぜなら暗号方式はある通信を第三者が盗聴するのを
防ぐことは出来ても、実地調査で直接ファイルをやり取りしているのが証明できてしまうからです。またコーデック
にかかるコスト（CPUパワーのこと）も無視できないレベルでしょう。ましてやローカルファイルで数ギガに達する
ものを暗号化するなどは、方式にもよりますがある程度の強度を持った暗号だとたぶん一週間かけてもエンコード
完了しません。
問題になるのは「ファイルそのもの」もしくはその「ビット連続性が保たれた断片」を直接通信することにあるため、
RAID5の仕様を元にしてファイルを奇数ビット（OddBit、以下oビット）、偶数ビット（EvenBit、以下eビット）、xorパリ
ティビット（XorBit、以下xビット）の３つに分けて別々のノードに分散してしまうことを提唱しています。
この方式の場合はあるファイルのビットイメージが「000111000111」であったとき、oビット「011011」eビット「001001」
xビット「010010」となり、これらを別々のノードで分散保持します。
復元時はoexの各イメージのうち二つを得ることが出来れば、xor演算で欠落ビットを拾い出すことが出来ますの
で、ファイルを要求している側はoexのうちの二つのイメージを取得すれば復元できます。この方式であれば、調
査実施された際に送信される情報は実態情報素片ですから原本同一性を証明できません。
ここまでは説明のためにビット分割しましたが、これは負荷の面から考えて非常に不利だと思いますので、実装
時にはバイト単位でいいとおもいます。
さらに冗長化を図るためにoex全体をミラーリングで分散します。冗長化のレベルは数学的な検証を必要とします
が仮に１０とします。

■実装案

まず、個々のクライアントは専用の領域を拠出します。説明のために9GB固定で供出と考えます。
この供出されたディスク領域は内部でo、e、xの３つの領域に分割します。もしくは3GBx3で別々
のファイルとしても良いです。
oexの各領域は連続したビットイメージで構成され、ファイルハッシュ等のヘッダに続き具体的
なoexバイトイメージが続きます。実装を容易にするために保持バイト範囲は固定で1MBとして
考えます。もう一度言いますが、ここでディスクに書き込まれているのはoexの素片です。

ここまでで述べたoexディスク素片をネットワーク越しにひとつのディスクとして見せかけるため
のP2PDiskDriverとP2PDiskFileTabelの二つが必要になります。
P2PDiskDriverはここまで説明したややこしいバイト分割や分散を覆い隠してユーザへ単一な
巨大ディスクとしての「見かけ」と「操作性」を提供します。
またその巨大な仮想ディスクのファイル情報を管理するP2PDiskFileTabelとセットで動くことに
なります。P2PDiskFileTabelはP2PDiskに記録されたorされる予定のファイルの情報を統合的
に管理するもので、場合によってはオープンソースのRDBで構築したほうがよいかもしれませ
んが、おそらくP2Pネットワーク全体で共有されるファイル総数は１０万程度見ておけばよいの
ではないか（根拠なし）と思われるのでそこまでしなくてもいいかもしれません。これは数学的検
証を必要とする部分です。

■実際の動作イメージ（初期）

このネットワーク稼動当初はP2PDiskが構築されてもファイルが何もありませんので、ファイルを
公開しようとする人は特定のフォルダに公開するファイルを置いておき、それを共有開始します。
するとP2PDiskFileTabelのほうへその情報が取り込まれ、P2Pネットワーク全体にそのファイルの
存在が広まります。
一方でファイルを要求する側はP2PDiskFileTabelの情報を元にダウンロード要求を発行しますが、
まだファイルはP2PDiskに取り込まれていないのですぐには流れてきません。これはnyと同じです。
P2PDiskFileTabelを介して送信要求がファイル保持者に伝わると、実際の転送が始まりますがこ
のとき実際にはP2PDiskDriverがP2PDiskに対する書き込みという形で処理を行います。
P2PDiskDriverを介して書き込まれる際に、このドライバはoexのバイトにファイルを分割して３つの
ノードにそれを転送します。受信が完了したノードはP2PDiskFileTabelにその旨を通知します。これ
を繰り返して最終的にすべてのファイルイメージがP2PDisk上に保持されることになりますが、平行
して冗長化のための転送を隣接他ノードにも行うことになります。
この動作はP2PDiskFileTabelによって管理され、あるoexブロックの冗長度が10を超えるまで行わ
れます。
もともとファイル要求した側にもどり話を進めます。P2PDiskDriverはP2PDiskFileTabelと連動して
動作していますので、あるoexブロックが転送されたことを確認できますので、転送が完了した
ブロックから順にローカル領域へと取得開始します。この取得過程においてはファイルの原本所
持者とは違うノードから行われており、またブロックが複数あれば同時並行して落とせますので、落
とす速度はかなり速くなります。
またoexのブロックのうち二つが取得できればいいので通信断絶にも比較的強いと言えるかもしれ
ません。

■実際の動作イメージ（中期以降）

いったん共有されてP2PDisk上に取り込まれたファイルは、P2PDiskFileTabelによって冗長化
レベルとオンライン状態を管理します。冗長化レベルが10に満たないブロックが存在する場合は
冗長化レベルの最後のノードに対してP2PDiskDriverが冗長化指示を発行します。発行により指示
のバッティングが発生しますがいったんこれは無視します。
実際にファイルのoexブロックの送信要求を受け付けたノードは、P2PDiskFileTabelを参照して
冗長化レベルが10を超えていたら自分が送信をせずにそのブロックを削除します。
このような動作によって冗長化レベルは目標値と近いレベルではあるが安定しません。

秋敵田・・・
もう説明するのまんどくさいからおまいらがんがれ。

>>278
(´･ω･`)

>>278
オマイが作ったら解決しそうな希ガス

こうして何も出来上がらないのがいつもの２ちゃんであった

>>278
ﾜﾗﾀ。

ディスク上のデータ保持についてビミョーによくわからない気もするんだけど、

・ダウン側がFileTabelから目的のファイルを検索、DL要求
・ファイルにアクセス出来ない（冗長度が足りない）場合、FileTableを書き換え
・FileTableを参照したアップ側（実体を持つノード）が空き領域に転送、FileTable書き換え
・ダウン側が変更されたFileTabｌｅを元に改めてダウンロード

という流れでいいのかな？
ところでFileTableの書き換え情報の伝達はどうゆうタイミングで行うの？
ダウン要求のタイミングで隣接ノードに取りに行ってもそれが最新のTableである保証はなんもないよね。
かといって変更があるたびに全ノードにパケット飛ばしてたらトラフィックがバカにならん。

最新である必要がない、
というか常にFileTableが間違っていて上記の流れになる事を前提にしてるのかもしれんけど
だとしたら冗長度を上げる意味はあんまりないかもしれんね。

>>282
ところでふとオモタがFileTableだよな？
2chでスペルミス指摘してもしゃあないけどさ。

いろんな案はでているが、結局のところ小手先ばかりで、
根本的な解決にはいたら内容に思える・・・。

RAID5に関しては、
俺も漠然ではあるが、使えるのではないかと思っていた。


RAID5マン氏ほど、知識が無いので、
氏の意見へ加勢したくてもできないのだが・・・。
検討するに値すると思う。


で今、俺なりにちと思いついたものが
あるから聞いてくれ。

P1　f1:11110000　f2：11101010 を用意
P1にて　キャッシュ c1:11111010 c2:111010000 を作成及び転送


P2　11111010　P3　11100000　　P4　P5　P6　・・・・・・・・・・・・


P7　f1要求
P2より、c1:11111010　P3よりc2:111010000　　ゲット
で上記より、
f1:11110000　作成


P2〜P6とかが、kでもP1が実体を放出したかどうかなんてわからんし、
実体はP1が流す時と、P7の復元時にしか存在しないし、
しかも完全キャッシュさえも存在しない。

どう？なかなかのものかと思うのだが。


しかし、Xデー依頼こんなことに時間費やしてるって・・・。

P2Pの技術情報がまとまったサイトはないですかね？
英語でも構わないので。

>282
ご指摘のとおりです。冗長化のレベルをっていうか目標値を１０にしてるのは
冗長化の目的もあるけどむしろネットワーク遅延による正確さを保証できないから
目標値に近づくように動作させる方法を取ってます。
だから冗長度はエロイ数学の検証をしてもらって決めればよいとおもう。正直
１０もいらないとおもうし。

FileTableではファイルの存在を保証するけど個々のデータブロック存在は
保証できないから、応答率を高めるために冗長化するってとらえてほしいかも。

この方式はどれぐらいオンライン率を高められるかで成否が変わってくるから
過去２４時間のオンライン率で同時ダウソ数を決定するように実装すれば
いいんでないかとおもうのね。たとえば12時間以下は１、18時間以下は２、
２４時間なら８とかにするの。
そーすればオンラインでいるメリットが出てくるし、P2PDiskの安定度も上がるかなと。

>>287
常設ノードが沢山いてくれるという状況であれば確かに有効かもねー。
実装の話はあんましてもしゃあないけど、その辺り手練手管か。

24時間中の%とかでなく、単純に連続稼働時間で測ったほうが
より信頼性が確かになるんではないかと思う。簡単だし。
切断したら（より正確に言えばオフライン中に呼び出しがあったら）
初期値にリセットくらいな感じでね。

エロい計算は分からんが、ミラーリングに関してはもっと柔軟に考えたほうがいい気もする。
わざわざブロックの削除とかせんでも、FileTable上に記録されてなければ空き容量と変わらんわけだし。
FileTableの大きさ自体も各ノードで統一されてる必要もないよねー。
信頼性の高いノードのFileTableは大きく、低いノードは小さくするだけで
検索精度も変わってくるし、常設化の促進になるやもしれず。

>288
なんでいったん保管したブロックを消すようにしてるかっていうと、
P2Pネットが成長するにつれて新規の流入も増えるから、
古参者＝古参ファイルブロックな状況に陥っちゃう可能性が出てくる
わけなのよね。だから必要なくても定期的にブロックは抹消してどっかに
ミラーかけてやらないとだめぽかなと。
でも常にトラフィック発生させるのも無駄なんで、その辺は実装設定の
さじ加減でいいんでわないかと思う次第です。

>>RAID5マン
煽りじゃないけど、提唱方式ってscalabilityないよね？
10人くらいのお友達とやるなら大丈夫かもしれないけど、
O(10000)の不特定多数では無理な気が・・・

>290
根本的な理解としてはP2Pネットワーク全体で作り出す巨大なディスク
だから容量的なスケーラビリティは実現可能。
簡単に言えばクライアントが増える＝HDD増設したみたいなものって
考えてもらえればいいかと思う。
通信速度面では常に一定の冗長化トラフィックが発生するけど、これは
時間の経過とともに低下するし、nyの個別ファイルと比べてもトラフィック
総量は減るのではないかとおもう。
たとえばいま提唱してる方式はどんなファイルであっても分散化される。
nyみたいに人気ファイルがとんでもない参照量になることもないから
効率的なんじゃないかと。
まぁ実装時に最初の冗長化レベル目標を達成してダウソ要求が少ない
ものは冗長化レベルを下げてもいいかも。逆に多いものは冗長化レベル
を上げるとかね。
多い少ないの判断はｏｅｘブロックに被参照回数を記録することで
自立的に解決すればいいと考えてる。（これは前出のトラフィック
増大の指摘の回避のためでもある）

ポイントはルーズな伝達をどれだけ許容できるかって部分。
だからFileTableでファイルの存在は保証するけど、ブロック存在の
保証は出来ないからFileDriverの転送部分でその不確定要素を
ラッピングして覆い隠すってわけだす。

なんかよさげなんだがRAID5マンは作る気ないの？全部理解してるっぽいし。

次期P2Pの情報や、議論は「P2P　from　２ちゃんねる」で☆
http://www.geocities.jp/p2p_download/

>>RAID5マン
想定している、ユーザ数、総ファイル数、file tableのサイズ、
はどれくらい？
それとファイルの参照数の分散。
どうも想定が現実と乖離している気がする。

えーーー放置かよ・・・。

ダメならダメといってくれ。


記述ミス修正）

> P2　11111010　P3　11100000　　P4　P5　P6　・・・・・・・・・・・・
正： P2　c1:11111010 　P3　c2:111010000　　P4　P5　P6　・・・・・・・・・・・・

>>RAID5マン

>簡単に言えばクライアントが増える＝HDD増設したみたいなものって
>考えてもらえればいいかと思う。

根本的に疎結合網と密結合網は違うよ。
fiber channelみたいなのを想定してない？
漏れはそっち方面の専門じゃないけどiSCSI(RFC3347)関連技術を調べるとほとんど
同じようなのがあったりしない？

わかった。
file tableの自律分散一元管理が不可能。

>>293
この場では「つくる」といえない罠。

作ってもいいけどオデの性格から行って「盲秋田鴨」ってなるのが目に見えてるから
書く気になれないんでつよねぇ。
まぁやってみてもいいけどC#で実装とかの嫌がらせしてもいいか？
まんどくさいからC++では書く気になれん。
２〜３ヶ月してみんな忘れたことろに公表するわ。
アディオス！再見！

>>300
C#だったら秋ても引き継ぐ鴨鴨鴨

やっと、ここ数日のループ議論から一歩踏み出せた気が．．．。

だから自律分散じゃfile talbeの「正しさ」の判定が不可能だって。
ＭＸみたいに一元管理サーバ導入すれば可能だけど。

> → どちらかというと、責任逃れの方法を考えなければならない
>　・言い訳出来る。
責任逃れとか言い訳しなければならないものを流すことを
前提に作ってるんですか?
名目だけでも「うっかり完全キャッシュを保持しただけの
善良なポエマーが逮捕されないように」とかしといたほうが
いい気がするんだけど

>>297
んと結合度の違いは認識してるよ。FileTableの自律分散一元管理もむり。P2Pだから。
さっきも言ったけどルーズな通信を許容できるようにFileTableとFileDriverと分けてる
んだがなぁ。うまくせつめいできねーやｗオデの命名がぁゃしぃのかもしれん・・・

ディスク関係のドライバ書くとわかるんだが、データの伝送経路がローカル配線なのか
ネットワーク経由かが違うだけでプログラムはまったくいっしょだし、バッファリング処理
でももともと遅延想定をして作るんだがそれがミリ秒から数時間へ変更されるだけじゃん
って思うんだが。ソフトウェア的にはレイヤー分けるなり非同期読み書きの実装で
何とでもなる・・・ハズ。

まぁごちゃごちゃ言ってても始まらんのでUML書いてみるわ。
指摘されてた問題点が回避不能かどうかも検証できるだろうしナ。
期待しないで議論を続けてください＞ALL

>>305
ネ申　！　？

>>305
ｶﾞﾝｶﾞｯﾃ(´･ω･`)ノ

>>305
世界規模ＨＤＤ期待

>>308
世界規模ＨＤＤって何バイト？

こ、これは今のところ唯一期待できる神が・・・？

あまりに神神騒ぐのもなんだからRAID5氏に関しては、そっとしておいた方がいいんじゃない？
「RAID5氏に期待するスレ」とか立っても困るし。
これからは「変形RAID5案」中心に議論していく方向が良好なんではなかろうか。
方向性がはっきり分、議論しやすいんではないかと。

>>305
>ミリ秒から数時間へ変更されるだけじゃんって思うんだが。

おいおい。
ＨＤＤの網には故障しているノードはいても、
警察のように「正しく動作しているようだがこちらの識別子を教えてはいけない」というノードはいないぞ。

まじでスマソ。ageちまった。

うｐする側がうｐしたファイルを分割＆暗号化して、その作業を終えたら、分割された
暗号化キャッシュファイルをソフト側がランダムに何個か削除してしまうとかはダメ？

落とす側も一緒で、分割キャッシュファイルを全部ダウンして復元が終了したら
ソフト側で自動的に集めたキャッシュのいくつかがランダムに削除されてしまう、と。
そうすりゃ、常に完全な形でのキャッシュってのは存在しないわけで、ジグソーパズルで
言えば常に数ピース足りない状態。

知らずに貯まったキャッシュも、完全に全部揃えないようにソフト側で制御。

まぁ、分割されたファイルのうち１個でもうｐしたら違法だ、となればこんな事やっても
しょうがないけど。

既存のもので
DL中ファイルのパーツUPとDL完了の自動UP・・・ED2K、BitTorrentがすでにあり
UDPの活用・・・ManolitoP2P(MP2P)。ただし採用のBlubster等はスパイウェア入り、日本で接続報告なし
Mailを使う・・・Maileetがそんな感じ
通信暗号化・・・ES5(怪しすぎ)、Filetopia(トレードモード付き、ただし日本語ダメ)
分散キャッシュインフラ・・・Freenet/Entropy、単体では検索性劣悪。フロントエンドの問題もあるのか異様に遅い
JAVA・・・JXTAプロジェクトレベルで進行中、それなりに使えるものはあるが人いない
NG類似・・・Konspire2b

たぶん+n2NeCqbﾀｿとは論点がかみ合ってなさげです。
指摘は理解できるがこちらの意図が伝わらんみたいやね。いや、煽りじゃないよ。
だってまだ実例もでてねぇから理解しろつーほうがムリだしな。
がんがん議論してくれ。合間みてレス読ませてもらってるから。

>>305
自分も以前似たようなものを妄想していたから、
ルーズなI/OとしてのP2PFileTableは理解できる。

しかしデータサイズが小さいとはいえ、P2PFileTableの同期は必要なはず。
これはどのように解決するのか？ データサイズがかなり大きいと思うが．．．。

あと全般的にガベージの考え方を応用できないだろうか？
参照カウントや世代別管理など。

タトゥーがデンマークのラジオ局のインタビューで日本での騒動について訊ねられて
　「日本は物ばかりが進化していて人間は成長が止まってるのよ。」
　「うん。ステレオタイプの人間が多いのは確かね。」
　「番組の途中で帰ったくらいで騒いでるのよ。笑っちゃうでしょ？」
　「プライベートで日本へ行きたいか？答えはＮＯ！よ。」

あと有名なインタビューで
「日本人は不細工ばかり（ぷぷぷ・・・）」とコメントしてましたね。この話はかなり話題になりました。

ロシアのラジオ局
「日本はどうでしたか？」
「街にはゴミが沢山落ちてて汚かったわ」
「日本人はなんか動物っぽくて嫌ね」
「全員同じメガネを掛けて、同じファッションでダサい。それに臭いから好きじゃないわ」

イギリスの雑誌
日本の印象について
「先進国と思って期待していったらがっかりね、街に歩く人は全員無表情で
気持ち悪い」
「日本人って歯並び悪いし背も小さいし、かっこいい人が全然いないわ　
環境（空気）が悪いせいかしら　笑」

アメリカのラジオ
日本にこないだ行きましたね
「行きたくて行ったんじゃないわよ　」
「騒動って言うけど、あんな下手糞な子供じみた歌番組出れないわ」
「私たちは一流よ！日本人の2流3流の素人歌手と一緒にされるのが間違いよ」

日本での騒動について
「あの人達って、工業製品で小型化得意でしょ、だから心も体も小型化してるのよ」
「だって、みんな唾を飛ばしながら、同じ非難しか言えないでしょ　知能の無いロボットみたい」
↑コレ全板にコピペ推奨 タトゥーは日本を馬鹿にしすぎ

ローカルキャッシュの格納方法はどうなってるんでしょうか？

Winnyの場合だと、OSのファイルシステムを使って管理していたのでキャッシュ即消とか
弊害が色々あったと思います。

既出かと思いますが、ローカルキャッシュは独自データベース／ファイルシステム格納方式にし
そのデータベースは本人しか知らない秘密鍵で暗号化、秘密鍵はシステム起動時に手入力するのはいかがでしょうか？

十分な暗号強度で暗号化し、秘密鍵さえ黙秘していれば起動すら出来ないならば
公衆送信権侵害の確認もままならないと思いますがいかがでしょうか？

素人ですが案を・・・

メッセージは常に何台かPCを通して送っているように見せかける。
実際はランダムで串を通すかを決定する。

A−B−C−・・・　とノードが繋がっているとします
�@AはBに公開鍵を要求します
�ABは自分の鍵か、�@と同じようにCに対して鍵の要求を行います(Cも�Aと同じ動作をする)
�BAはBから教えてもらった鍵でメッセージを暗号化しBに送ります
�CBは解読できたら�@と同じことを行い、解読できなかったらメッセージをCにスルーします。(スルーするときに自分の公開鍵を付加※１)
※1：検索クエリー時のみで、確率により付加するかしないかを決定

返信は逆のことを行うだけ。
一応、メッセージの内容を知らないノードがいくつかできるし、多段串動作にもなったりする。

漏れの妄想
PCにセキュアモードが搭載されたらP2Pもメモリを保護した状態で動作できるんだろか

検索時

キーワードに相当するキーを返す。
これは上で説明したのメッセージでやりとりする
他人の結果に自分の結果をマージさせ、返信する。

キャッシュを保持しているキーには自分のIPを付随させ、メッセージ配信時にスキップされたノードの公開キーでIPのみ暗号化される。
※このＩＰは、メッセージ配信でスキップされるノードのIPで置き換えられる。(中継ノード)
　
これによりアップするIPが一応保護されると思った。
アップするPCのIPを知るのはアップする内容を知らないスキップされたノードのみ。
ダウン側は訳も分からず転送させられているスキップされたノードのIPしか知り得ない

>317
まだ.netライブラリ参照してないからはっきりしたことは言えないけど、たとえば
オデのいったoexのブロックをオブジェクト化してラッピングして必要最低限の
メソッドかインターフェイスを持たせることで自立的に動けないものかなぁと
考えてるですよ。んでオブジェクトの形のままシリアライズして転送。
どうせ共有するのは数百メガ〜数ギガ単位のでかいのファイルだろうから
オブジェクト化の相対的オーバーヘッドは少ないんじゃないかと。
んで、参照カウンタやガベージの話だけど、上のようにデータオブジェクトに
参照フィールド持たせておいて実装できないかなぁと考えてるですよ。

FileTableの管理はファイルの存在を保証する意味でのみ作成しておけば
いいかなと考えてる。ファイル識別のためのハッシュDBみたいなものかな。
ファイル名＋サイズ＋ハッシュ＋冗長度ぐらいの軽いやつです。
んで、具体ファイル断片の検索や転送にはハッシュベースで隣接ノードと
やり取り。バケツリレーで検索は発行すればいいかなと。
で、見つかったoex素片はオブジェクト化してあるから被参照回数と
自己複製回数を見てそのまま転送するのか、自分自身を別のところへ
移動させるのかを決めればいいんでないかな？
ガベージはこの内部カウンタで管理できないかとおもうですよ。

>>321
Nexusモードならメモリ書き換えのクラックとかは防げるね。

>RAID5マンサン
Wikiページに付け足しておきました。
編集があればよろしくお願いします。

暗号化は頭から除外したほうがいいぞ。
散々ｶﾞｲｼｭﾂだが暗号化してあるとかしてないとかなんていうのは
ローカルディスクと通信盗聴にしか効果がない。
今回のnyのような実地調査ではお互い通信してるから
ファイルそのものが流れてくる時点でアウトだ。中継すればいいとか
言ってるのも却下。実地調査では意味がない。
中継＝幇助だろ。そんなもんISPのログたどればすぐわかる。

>>319
その方式でほとんど完成している。
即消しの元凶はフォルダを１つしか指定できないことによる容量不足だと思うけど
複数のフォルダが使えるように実装してみた。それともし消した場合でも
再キャッシュ化時に、前の情報を引き継げる仕組みも実装したので
オリジナルの情報が保持されるようにした。それでも任意でDBから履歴情報を
削除できるように作りますけどね。

前レスにP2Pの文書どーたらこーたら言っておられた方が降りますが
こんなものはいかが？
http://www.ht.sfc.keio.ac.jp/~willow/publications/willow0602n3.pdf

今後、ネットスピードやPCが充分高速化し、各個人のPCが一つの大きなサーバーを構築し
各PC内のデータが、限りなくクラスタ単位に近い形でシェアリングされてしまったらどうなるだろうか?

個人の著作権などエヴァのLCLの海の中に溶け込んでしまったかのように
サイバー世界に消えてしまう気がする

常駐させてキャッシュを流通させた時間分だけ
電話機能（Skypeみたいな）とエミュでの通信対戦機能が
使用できるようにしてくだちい。

>>RAID5氏

実地調査されたときに、自分がどのファイルの断片を持っているかということが
検出されたらマズいんじゃないでしょうか。

自分の持ってるファイルの断片のハッシュは自分の持ってるファイル情報から削除されるとか？

この仕様を決める輪の中に京都府警が入ってたら大変だよね。

自分達の操作しやすい方向に話持っていくの。

>>320
>>113-115で既出

nyではファイルを頭からダウン、進捗率を青地に黄色のバーで表している。
けど頭からダウンだとやっぱ尻切れが発生しやすいし、拡散速度も下がる。
nyでは一度廃されたけど、複数ブロックに分けて落ちてきたほうがいいと思う。
おいら動画落とさないし、この方式のnyでの復活をずーっと望んでたんだけど
そこのところはどうなってます？

Ｗｉｎｎｙネットワークが崩れてからというもの、
約１ＭＢ近くの転送速度の向上してることが判明した。

すまん
　ミスってａｇｅっちまった。

>>332
見ているとは思うぞ。
来年も年末調整で手柄稼がなきゃならんし。

>>Jonyさん
えと、大抵の場合はZipやらRARに圧縮してるはずなのでそれを奇数偶数ビット切り分け
xorパリティ生成します。んで1MB単位とかのブロックに分けちゃうので取得した1MBの
分裂素片から原本同一性を証明して個人攻撃するのはほぼ無理だとおもうですよ。
ダウソに成功したら原本同一性は実証できるけど、それを構成する素片を送出した人
は「どのファイルのどの部分か」わかんないし。
この回答では疑問解消しませんか？

ネット接続をISPに依存している段階では
どんなソフトを作ってもｗハイテク課は楽勝だと考えています
ﾏｼﾞﾃﾞ

RAID5マンさんの方式はオープンソースで開発しても問題ないんじゃない？
なんか期待しちゃうよ。

>>338
つまり、断片を所持していて、その断片が何のファイルの断片か分かっても問題ないと。
……う〜ん、もうちょっと考えさせてください。
偶数奇数の分離は暗号化に比べ高速ですが……。う〜ん。

>>340
オープンソースで問題なのは、データ構造でなく、いかに改悪ピアを弾くかということに
あると思いまつ。

>>339
　Ｐ２Ｐ専用ＩＳＰとかやっても問題だしなー。
　

>>337
じゃぁ、年明け稼動だとしばらく放置してくれるかな？

>>343
一年ぐらい放置してくれます

ところで、パリティビットって何で必要なんだ？
チェックサムやハッシュ値があればエラーは検出できるんだし、
化けたら再度ダウンロードしてくれば済むことじゃないか？

>>342
KaZaAと提携したISPがあったな

もうちょっと補完するとxorビットも入れてほしいです。
効果としては通常用途と同じく欠落ビット（ブロック）復活に使えるし
実地調査でも送受信されるデータの真偽性がわかりにくくなるですよ。
たとえばあるisoイメージをzip圧縮するとその時点でバイナリ列としては
原本からかなり変化する。さらにそれを奇数偶数パリティの３つに分割すると
それぞれの素片見ただけじゃ何がなんだかわかんないでしょ。
仮に原本同一性がそれでも証明できるとしても、送信した人がそれを
認識できる状態には無いから違法性を問うのは非常に難しいかと。

それと「ファイル共有」ソフトは目の敵にされるんで、「P2P仮想ディスク」
とか「P2Pフリーディスク」とかっていう「ディスク領域の共有」てのを
前面に打ち出してほしいです。

共有するのはファイルじゃなくて自由に使えるディスク領域だってコトでｗ

>345
奇数偶数にビット列を分割した上でさらに一定容量でブロック化するから
ブロックが欠落する可能性が否定できんでしょう。
そのためです。

自分でやれ自分で

つまりだ
作り出したい状況というのは・・・

　・ よく分からないファイルの断片をいくつも持ってる
　・ よく分からないファイルの断片を自然とアップロードしている

　　　（よく分からないファイルの断片＝それだけでは意味をなさないファイル）

　・ 何人かの人からよく分からないファイルの断片集めると欲しいファイルになる

それを大人数でやるわけだ

誰一人として完全キャッシュを持たないように
しかもよく分からないファイルの断片がなくならないよう冗長性を持って

>>347
たとえばoddビットとevenビットで復元を試みて失敗した場合
xorビットを取得してそれを使い復元するんだよな？
各チャンクのエラーは、そのチャンクのチェックサムやハッシュ値で判断できるから、
どちらを修復しないとならないかは自明。
xorビットとodd/evenビットの情報量が同じであると仮定するのなら、
エラーを検出した時点でxorビットかodd/evenビットを再度取得してくることに
本質的な違いは無いんじゃないのか？

真偽性の話だけど、それがxorビットであることを知れるとしたら、
そのデータは捨てれば済む話だし。

ちなみに、各チャンク（ブロック）にハッシュ値がついているという前提での話。
チェックサムやハッシュ値を持ちながらパリティビットを設けるのは
無駄な冗長性でしかないのでは？ってこと。

>>348
>仮に原本同一性がそれでも証明できるとしても、送信した人がそれを
>認識できる状態には無いから違法性を問うのは非常に難しいかと。

これを実現しようとすると、自分が持っているブロックのファイル情報は持てない。
それを判断するのは結構時間がかかる処理だと思いますが。
メモリにハッシュテーブルでも用意すれば解決するかなぁ……。
検索かけるときには、検索ワードを他ノードに振りまくと。
まぁ、検索ワードが知られたところで、どうということはないんですけどね。

>>350
おっしゃる事は良く判るし、イイ方法だと思う。
しかし大問題がある。
捏造やられると ｲッﾀーｲ (;;)

なに、結局一人で作る形なの？やっぱり駄目だなこりゃ。

ちなみにRAID5マン案はそもそもどうやってファイルを検索するのかが
どこに書いてあるのか分からない為に断定は出来ないんだけど、
どうやら偽装部分が非常に弱そうだ。

まず暗号化前のファイルを持っている場合、全てのキーを生成する事が出来る点。
つまり出回っているファイルを収集さえすればどのキーが対象のファイルかは
完全に把握可能。はっきり言ってこの技術だけでは駄目。
これを防ぎたい場合3ファイル共通のXORキーを作れば良いが、
同じファイルでも違うファイルとして扱う事になる事情がある為
どのようなファイル検索技術を使っているかが分からんとなんともいえんな。
まぁハッシュなんだろうけど。

誰か仕様をまとめてくれよー。

>>261でどう言った方針かを決めろとは言ったが、
やっぱり複数人数で作った方が色んな意味で良いと思うよ。

そう仕様。




＿|￣|○　

>>356
あえて言うならコレじゃないのか？
http://2.csx.jp/~p2p/
こんなんじゃ仕様が無いけどなｗ

>>359
　それは仕様っていうか版の整理と
　とりあえず決めなければならんリストが書かれているだけだなー。

　海外鯖借りたから、近いうちにまとめておくか…。
　
　3(-_^;)うちの学校の版みたが、恥ずかしく悲しい内容だったよ。
　
　俺の席の後ろの香具師は、
　　ＮＯＣＤを知らない…Ｎｙ未だつなぎぱなし…ｈｔｔｐで落とすのが面倒
　　Ｄｅｍｏｎを知らないでエロゲできるようにしろとほざいてる。
　↑このスレと関係ない話だか、こういうのは放置しかないでしょうか？

#-------------------------------------------------------------------
　

ageて言うことか

>>361
気づかずｱｹﾞｯてしもうただけだ。。
　さっきcookieとか消したからなー。sage入れるの忘れてたわ
　今から仕様らしきレスを取得してまとめてみます。

とりあえずレスつける前に>>1から全部嫁。
この時間帯になると案もださねーのに否定ばっかで気分悪いわヴォケ。
あふぉなレスみるとやる気なくすわ。

>>363
大丈夫デシ。誰も期待してないデシ。

>>364
以下同文
２ちゃんで気分害されても

ログも読まずにまとめてるとこがないとか言ってるアホが多数

>>355
意図を読み違えてるかもしれんがデフラグソフトは簡単に作れちゃうかもね。
自分がどのファイルのデータ素片を持っているのか、
新しく書き込まれたデータ素片がどこから飛んできたかはバレバレという状況で
言い逃れが出来るかどうか、という事にはなるね。
一応現案でも想定されてるとは思うけど。

データ片の送信側は自分が呼び出した場合を除いて
１．実体ファイルを持ったノード
２．ファイルをダウンロードしたノード
３．どこからかデータ素片を送られたノード
のどれかという事になるのかな。

言うまでもなく１はヤバイ。2もあまりバレるのは好ましくない。
3であれば責任の追及は不可能であろうと思われる。

1、2、3が違うものである事が分かってしまうと大変危険と言うことになる。
実装にもよるだろうから何ともいえないけど、
技術的にその辺りの判別は可能なのか、だとしたら回避方法はあるのか
みたいな感じでネタだし出来んものかね。
ちょっともうこれ以上は日曜プログラマには分からん領域なんだけどさ。

47氏ってどれだけ煽られても一度も切れなかったよなぁ
その点は大人だと思うよ

>>363
よくわからんが、それは俺のことか？
新しい案（RAID5方式か？）とやらが既存のものより明らかに
”劣っている”からそこを突いただけで、
否定するたびにまったく新しい案を出さないといけないのなら
それまでよりも劣ったものを持ち出して偉そうにするなってことだよ。

c#での実装がんばってくれや。

夜の部はまだですか？

立ち上げてリンクが確立した段階で、
ドドドーっと勝手にUPファイルを流し始めるってのどうよ？
バケツリレーの中に何だかよくわからないうちに入ってしまうわけね。

違法性のないファイル名にする。
↓
2ch、nybbsなどで実際の内容を公表。
↓
ダウンロード
↓
捕まる
↓
まさか違法なファイルとは思わなかった。

>>369
捕捉しておくと、パリティは明らかに無駄な
単純に殺ぎ落としても問題の無いこれまでの案の中でもっとも劣る設計。
単純に殺ぎ落としてodd/evenに分けたデータを拡散させるだけだと
これまでのものと本質的に同一なものになる。

RAID5案は発展性は皆無で、後退している部分しか存在しないわけ。

っていうか、ネットワークでどういうファイルが取引されているか把握される
っていうのはマズイんかね。
個人的には、本人が、自分の持っているファイルが全く把握できなかったら
責任はかなり薄れると思ってるんだが。

みなさんの意見を聞きたい。あと、まとめぺぃじへのツッコミきぼん。

37歳氏の新P2Pソフト完成をじっくり待つ会 Part3
で議論されたことですが、
P2Pソフトをシェアウェアにしてしまうというのはどうでしょうか？
警察や著作権団体は買わなければなりませんが、
ﾀﾞｳｿの住人は(ry
もしくは、法人や国家機関のみシェアウェアにするとか。

>>772
ダウンロードでは捕まりません。

>>375
どうやって　個人を警察とか国家機関に属している人間だと判断するんだ？？
　まさかドメインで go.jpになってるからとか言わないだろうな？？

>>367
まぁP2PDiskDriverとかいうのとP2PDiskFileタベルとか言う奴の挙動が
物凄く相性が良いと言う話なのかも知れんけどね。

ドメインで go.jpになってるから

>>375
シェアウェアにしたら権利の所在をハッキリさせんといかんくなる罠。
ナプスタ裁判のようにそこを窓口に賠償請求されたらアボーンじゃないん？

○暴ちっくに住所不定無職でも代表に立てて責任逃れでもする？ｗ

>>379
テンプレ嫁

あと
次期P2Pのクリアすべき課題を法的な観点から考察
http://tmp2.2ch.net/test/read.cgi/download/1070084504/

>>377
違法な方法で調査した場合の逮捕は無効になります。

どうにか　ｋとかａが知らないで
俺ら個人だけが知るとかいうのがあればなぁー。
　そんなもの何処にもない罠ｗ

>>375
警察、著作権団体が何故買う必要があるの？
押収すればいいんじゃ・・

>>374
禿同

暗号化された状態で、かつキャッシュは全体ではなく部分
普通の一般人には把握できない

それで問題ないと思われ
さらに改良するならそこまで完成してからで

既出・スレ違いの話題とそれにレス付ける馬鹿がいる限り話が進まないわな

誰が何をもっているか
誰が何をDLしているか
誰が何をULしているか

全てのクライアントに対して完全に隠蔽する構造は思いついたが俺には作れない

シャワー浴びてくる

それも激しくｶﾞｲｼｭﾂ
しかも法律スレ向き

□警察が個人としてツールを利用
　↓
□違法ファイルが流れていることを確認
　↓
□ダウンロード　この時ＩＰをログしておく。
　↓
□警察署で●●ってツールで違法行為やってる人が多いですよ。

　ってﾊﾟﾀｰﾝにならないか？

AU+GtZQdさん、協力してくれる姿勢は有難いのですがスレ違いです。
他の方々共々法律スレへ行って下さい。

375 名前：37 ◆cCUTZgLe.s [] 投稿日：03/12/01 21:33 ID:/hmlRT66
開発状況は70％といったところでしょうか。いろいろな場所で期待されているようで
こちらもやる気がでます。Dorothyではnyのシステムを継承した部分や新機能がいくつかあるので
それを一部ですがお知らせしたいとおもいます。
まずインターフェイスですがnyに似せて作りました。Dorothyもキャッシュシステムを採用していますが
これは改良した部分が多数あります。あとnyよりは軽くしたつもりです(C3 600MHzでダウンロード時負担6％)

只今時期ｐ２ｐソフト開発中の３７氏が書き込んだ模様！！です！

37歳氏の新P2Pソフト完成をじっくり待つ会 Part4
http://tmp2.2ch.net/test/read.cgi/download/1070211340/

>>389
著作権者が捜査を依頼してる場合はノープロブレム
ACCSなんて思いっきりそのための団体

>>384
調査の段階でソフトを解析しなくてはならないから
買う必要がある。

パケットが常にピンポンしている状態であれば良い。ピンポンの
ルールは必要である。欲しいファイルを要求したときにパケット
が順にある程度の形をまとめてストリーミングされてくる。
サーバは存在しない。ファイルも存在しない。ＤＬした側も
コンテンツを見た片っ端から消えてしまう。
ＰＣでしか見ることが出来なくなるが、追いつめていくと
こんな形になるのではないだろうか？
誰がどこから何をしているのか絶対に分からない。たとえ
ピンポンしているパケットを拾っても、それが何であるかは
分からない。

クライアントはデータユニットを常に送出し、一定量のトラフィックを維持する。
ダウンロード要求には明確に応答せず、どのファイルを優先してトラフィックに乗せるかの参考にするだけ。

こんなんで何かメリットあるかな。ｽﾚ汚しスマソ

スレが・・・止まった・・・？

#-------------------------------
　停止中のスレ
#-------------------------------

ホンとだ完璧にとまっちゃってるね

コーディング中なのでは？

RAID5氏はやる気をなくしてしまいましたか？
ぼくは、このような知識がなく何も役に立ちませんが、

かげながら応援しています。
カンバッて下さい。

ほんとに止まったな・・・
ってかUP時に自分のIP+偽装IP99個ぐらいを同時に送れないかなぁ
まあプロバで止められるだろうけど
ピカリのファミリータイプみたいな感じでプロバに繋がってるなら
他のファミリーのIP(実在するIP)で偽装するとか。
受信はUP側が受信側の100IP全てに送信する、で。

・・まあ俺の考える案はいつも夢想だな。

何度か話が出ているけど、シェアウェア化ってアイディアを生かせないかな？

オレの考えでは、
シェアウェアとしてまずnyやMXなど既存のP2Pネットワーク上に流す。(作者の身元をできるだけ分からないようにするため)
インストーラー付きにしてインストール手順で仕様許諾書と作者(著作権者)を明示する。
仕様許諾書の内容は逆コンパイル等禁止・雑誌への掲載禁止・スクリーンショットの公開禁止など(具体的なことは分かりません)
インストール時にパスワードを要求。
パスワードは、表向きでは公式ホームページなどから作者と連絡をとりシェアウェアとして料金を払うことを明示する。
公式ホームページのURLは架空のモノをReadme.txtに乗せる。
実際には公式に料金を払う手段は用意せず、winnyやMXなどで違法シリアル集としてパスワードを配布する

これなら著作権法上、作者に無断で割れて使用するしかないから、警察やACCS等の著作権保護側の団体は起動すらできなくなり
一般人とかは普段からそんなのお構いなしなので普通に落としてこれる。
雑誌への掲載禁止も明示してあるし、著作権法を犯さないと使用できないから雑誌への掲載もできなくなり厨房対策になる。

あとは作者の名義を団体名義にするとか(例えばダウソ板住人名義とか)

どうだろう？

>>402
次期P2Pのクリアすべき課題を法的な観点から考察
http://tmp2.2ch.net/test/read.cgi/download/1070084504/

まあ、でもいい傾向なんでない？
いいかげんみんなネタ不足になってきたのかも。
そしてRAID5氏につっこむほどの技能を持ってる人が実はほとんどいなかった。
>>402
．．．．．．．．．．．．そりゃいい考えだ！とでも言ってほしいのかい？

ノード接続に関してだが、
手動登録できるようにするとｋなどが勝手に個人を特定してつないでしまう。
そこで考えたのだが、

　何処かのWebサーバを利用してそこにアクセスしてるユーザに
　ランダムに接続する。
　それだとＦＷとか使ってやられそうだから、
　
　ｋ　→　１に接続　←単につながるだけで調査できない
　１　→　２に接続　←１につながってるノードからランダムで選ぶ
　２　→　ｋに接続　←これがつながらないｋはノードから切断される。
　　　　　　　　　　　今後、接続できないように設定される。

　っていうのはどうだろうか？？
　俺の考える案も夢想で申し訳ない。

見つかったら著作権系の問題でタイーホにならん？

>>402

夢想ついでに書くと一般ピーポーとKを見分ける方法としては
KのPCには絶対に入れていなければいけない
ソフトorハード(Kが個人で使うPCすらも)
を特定してソレが感知できれば使えない、懐石できない、とかね
逆にあるソフトを入れてなければ次期P2Pソフトを使えない。にして
そのあるソフトはKやAと関係の有る奴は使えない
という規約を付けて配布する。いっそOSから作るとか。
まあこれは法スレの次期P2Pソフトに規約を付ける案とほぼ同じだがね・・

今思ったけど製作する側の人間性って結構重要だよな。
47氏はその点は良く理解して製作してたと思う。

>>403
確かにそちらで書くべきでしたね、以後気を付けます。
>>406
著作権法は親告罪らしいので作者が訴えなければ問題無いかと思いまして。
ただ問題なくても違法であることは変わりないので警察とかは使えないんじゃないかなぁ？
っと夢想してみました。

このスレは素人書込み禁止にすれば？
素人というのは自分でP2Pソフトを作れないやつのこと。
素人がおもいつくようなことはとっくに考えてるだろうし、あくまで
一人で作れるだけの技術がある人が意見を聞く感じでレスすればいい。
それにつっこみいれるのはもちろん歓迎で。47氏もそうだったでしょ？
あと47氏の過去ログ読むのもかなり参考になるよ。

偽装とかしなくても　ファイル―持ち主　の関係を全てのクライアントに完全に隠蔽できるよ
winnyタイプでも　ｍｘタイプでもOK

細かい事を省いて凄く簡単に書くと

ネットワーク内に　IPキーAサーバー　IPキーBサーバー　を置く
それぞれ複数のクライアントで構成し　必要に応じて数を増減させる
IPキーAサーバー　IPキーBサーバー　は一対一で対応する
IPキーA　IPキーB　は二つ揃う事でIPを復元できるキー情報（加算するとかxorするとかで）
IPキーAサーバーはネットワーク一意のIDとIPキーAの対応を管理する　IPキーBサーバーは（ｒｙ
特定のクライアントにアクセスする時はIDを指定し
IPキーサーバーABから任意の中継クライアントにキー（だけIDは開示しない）を渡しIPを復元させアクセスさせる

ファイル転送時には間に一つ以上のクライアントを中継させる
中継するクライアントは次々とかえていく
これを管理する為のファイル転送サーバーを置く
ファイル転送サーバーそれぞれはある程度の数のクライアントのトラフィックの状況を把握し
ファイル転送の中継をするクライアントを手配する
更にファイル転送時に転送元と転送先だけに暗号化、複合化キーを設定しておけば尚よい

後はだいたい想像できると思う

一クライアントとして参加する分には　たとえクラックされたクライアントを使用して情報を収集しようとも
ファイルー所有者　の関係を導き出す事は出来ない
ISPがわで目をつけたユーザーの吐き出すパケットを監視していれば特定できるかもしれないが
それを心配するなら　回避する策もある

なるほど親告罪か・・・
一般ユーザーは訴えなくて　警察は訴えるってかｗ
面白いんじゃない？　損することはなさそうだし・・・
つけてみる価値はあるかもね

sx8Pxyf2 は書込み禁止ｗ

>>402　が言う意見を参考に考えてみたんだが、
　まず本体は、ｗｉｎｎｙやＭＸで配布する。
　シリアルにパスワードを書くといってるが、尻集とか警察も知ってると思う。
　そこで…

　□キージェネを使う。

　キージェネを入れておかないと使えないようにして、
　そのキージェネは不定期で更新される。
　MacAddressとバージョンと起動情報を暗号化させた
　情報ファイルを生成し、正常ならば起動するが、
　ネットワークにつないでる途中で自分と同じMacAddressを使ってるノードを
　検出したら情報ファイルのコピーと見なして利用できないようにしてしまう。
　
　キージェネ本体は、一度使えばEXEを書き換えて利用できないようにする。
　また未使用が流出しないように有効期限を１０日以内とかにしておく。
　もちろん時間をいじくって起動しようとするやつがいるので
　タイムサーバと連携をとり判別する。
　

>>406
「未登録時は1分間だけ使用可能です」とかにしとけば、何とか言い逃れ出来そう

アイコン〜
画像アップ掲示板にはりつけますた

http://www.p-manjiro.com/icon/joyful/joyful.cgi?

P2P from ２チャンネルに置いてあるアイコンの右から二つ目のアイコンから文字ぱくりますた(ﾃﾞﾍﾍ

>>416
(^◇^;)　１分ですか…
　１分だと辛うじて３〜４MBのもせが限度ですなー。
　

何をやっても国家権力にはかないません。

なんだ・・・反応ゼロか

>>415
尻集を警察が知っているってのは自分でも分かっていますが、
違法になるので警察は手を出せないってのが狙いです。

キージェネについてはヘタなこと言うと恥をかくので私は何も言えません(;´Д`)

キャッシュについてですが、RAID案やどんな案でも
完全キャッシュは必ずファイルに復元出来るのだから、
完全キャッシュでなければファイルに復元できない構造にすればいいのでしょ？
たとえ復元できても意味不明のデータになるように。

今、簡単なプログラムを作って試してみたんだけど、
暗号化と、ＸＯＲを上手く使うと、１バイトでも異なれば
無理矢理復元させても最低70%程無意味のデータにさせることが可能です。
最高30%程、元ファイルのデータになりますが、バラバラの位置に出現するので
検出不能だと思います。

これじゃだめ？

>>420
ISPがわで目をつけたユーザーの吐き出すパケットを監視していれば特定できるかもしれないが
それを心配するなら　回避する策もある
↑どのような回避策ですか？

全世界ＨＤＤ計画が、京都府警に取り締まれるの？

>１バイトでも異なれば
1バイトでも存在しなければの間違い

>>420
多分実力ある人なんだろうけど。
こういうのは、ほとんどの人が理解できません。
理解力をつけろ、と言う前に表現力を見につけろ、です。

・それぞれ複数のクライアントで構成し　必要に応じて数を増減させる

何を言っているのかさっぱり判りませんｗ

この記事ワロタ
http://www.zdnet.co.jp/news/0312/01/nj00_top10.html

□キージェネの第二の効果

　Ｗｉｎｎｙでは、バージョンアップが安易にできた。
　ＭＸは、バージョンアップは滅多にしないでよい。
　ただ使えるようになればそれでいいというユーザが増えた。
　逮捕されたなどという情報を入手しようとしない。

　つまり　のほほんと使ってる奴が多いのだ。←アニヲタ等に多い。

そこでキージェネを定期的に取得しなければ、利用できないようにしてしまう。
　古い情報ファイルだと使えないようにすれば、いいのではと思ったり。

　またキージェネのプログラムは、再配布禁止でｎｙやＭＸに流さない。
１０分だけ共有ツールを使えるようにして、そのあいだに新しいキージェネを取得しなければならない。

　こんなのはダメですかね？

>>428
よーわからんが、回線遅い香具師は不利じゃないの？

>>420
もう少し、なんというか。みんなが知っている「キーワード」を散りばめて
わかるようにカキコしてほちい。
原理は何なのかとか、キーポイントはどこなのかとか。

「IPキーAサーバー」っていう単語がいきなり出てきて、迷子になってる俺ですが。

>>423
かなり複雑になると思うけど

初回ログイン時に暗号化キーを設定しておいて
ネットワーク内に保持しておき　一定期間ログインがない場合に削除する
次回ログイン時からはネットワーク内に保持されているキーを使用するので
初回ログイン時をISPに抑えられない限り暗号キーが割れない
キーが削除される前にログインしていればよい

更にULしているか中継しているか判断できないように
UL時にはダミーパケットを受信するようにファイル転送サーバーなんかが手配すれば尚良し

でもこの構造のミソは誰からDLしているか絶対分からないって事かな
中継しているクライアントもｺﾛｺﾛ変わるし
中継してる側もファイルの断片しか分からないし　その上暗号化されていたらなんなのかさっぱり分からない
更に中継するクライアントが一つとは限らないとなれば・・・

そうですね　ちょっと説明不足過ぎだなー
説明するのって凄い面倒で苦手なんだｗ

とりあえず今日ね寝ようっと
すれ汚しスマンです

>>429
　新キージェネそのものは、ネットワーク上にばらまかれているから、
　すぐにヒットするようにしておく。
　ダウンロードの速度が出ない場合は、もう１０分だけ追加時間を与える。

　あと共有ツールで誰かが逮捕者が出たとかいう情報を流したら
　それを取得したノードは、一時的に利用できないようにしてしまうとか。

>>431
「ファイル転送サーバ」がＫにならない保証が必要になると空想してみたけど。

>>434
どこぞのノードがヤバい人物のものになるっていうのは、絶対に防げんと思う。

こんなのはどうだろうか？
　
　まず限られた人、開発者やちゃんねらーなど、
　ここにいる人たちをＡグループとする。

　Ａグループでは、キージェネのみをネットワーク送信するようにする。
　Ａグループでは、他のファイルの共有はない。

　違法なファイルがあるグループをＢグループとする。

　Ｂグループに入るには、Ａグループから取得したキージェネが必要で
　キージェネには、Ｂグループに接続する為のノードが暗号化されて
　記憶されてあり、そのノードにランダムに接続していく。
　
　この場合、Ａグループにｋが侵入していないことが条件となりますが、
　そこらへんは、開発者のみだとかにすればなんとでもなりそう。

>>431
IPキーサーバをどうするかも問題。

>>434
ごめん　「ファイル転送サーバー」ってのも単なる名前なんで・・・

ファイル転送サーバーも必要に応じて一クライアントがサーバー化されて役割を果たす
その際には自分が管理するクライアントのIPアドレスは把握するが
持っているファイル、対応するIDは開示しなければ問題無しです
単に管理するクライアントに　この二つのユーザー間の転送を中継しろという
指示を出すだけで　そのファイルの内容についてはノータッチです

というか寝ます　そのうち文章化してみたいけどできるかな・・・

ついでに・・・

>>437
IPキーAサーバー　IPキーBサ−バ−　は　それぞれ
「IPキーA　と　ID」　「IPキーB　と　ID」　の対応を管理し　直接IPとIDの関係を知る事は出来ません
IPを知る為には　IPキーA　と　IPキーB　が必要になります
IPの復元はサーバーではなく任意のクライアントに行わせますが
その際にはIDを知らせない為そのクライアントはIPと伝えるべき情報だけを知ります　

ん？？？

412>>・偽装とかしなくても　ファイル―持ち主　の関係を全てのクライアントに完全に隠蔽できるよ
439>>・クライアントはIPと伝えるべき情報だけを知ります　

IPと情報が同時に判ったらファイル−持ち主の関係が判る？？？
お休みなさい・・・

皆が比較的簡単に始められないと広まりにくいしコンテンツも増えない。
必要マシンパワーもより多くの人に受け入れられるような仕様にしないとならない。
人数が集まらなければ仮に脆弱性があって違法ファイルが蔓延していた場合の逮捕率も
あがる。
より多くの、出来れば世界向けにすることは一つのセキュリティになる。

と外人の誰かが言ってた。

>>440
IPと同時にわかるとまずい情報の受け渡しは情報自体を二つのキー情報にして
別々のクライアントを経由して行います

おやすみなさい

HALT

>>441
　確かにそうなのだが、必ず下手なことしか捕まる奴は現れると思う。
　そこは、ソフト側で制御してやらなければならないのでは？？

　Ｗｉｎｎｙは、長時間の接続というイメージがあった、
　ＭＸも長時間接続しているユーザも多い。

　長時間、多くの転送をしているとＩＳＰに監視されるのは事実であり、
　●時間以上の通信をできないようにしてしまう。
　
　実際に使う人がコントロールできればいいのだが、
　できない人もいるので逮捕者を出さないためにはこれぐらいの
　制限を与えなければならないかと思います。

　ＨＰで公開したり売ったり、ヤフオクで売るといった
　あほはどうしようもありませんけどねー。

http://s2net.s41.xrea.com/
↑ここに仕様などまとめられているそうです。

つか、もっと単純なモンでもいいような気がしてきた
要点は「P2Pの仕様はOK、でも違法(略)の公開共有はダメ」これに尽きるわけだ
つまり違法(略)さえ流通させなければいいという事になる

Aさんノード「すんげぇ無修正ファイル共有準備」
　　　　　　　　　↓
Aさんノード「自分から見ても合法性100%ファイル(キャッシュ)に変換・共有開始」
　　　　　　　　　↓
しかしBさんノードからは「すんげぇ無修正ファイル」だと視認可能・Down開始」
　　　　　　　　　↓←ときどき中継にCさん参加
Bさんノード「自分から見ても合法性100%ファイル(キャッシュ)Down完了・共有開始」
　　　　　　　　　↓←でもDさんからは「すんげぇ無修正ファイル」だと視認可能・以下略」
Bさんノード「すんげぇ無修正ファイルに変換完了」ﾜｼｮｰｲ

つまり合法性100%のもんしか共有してないようになるわけだ
こんなんでいいんじゃねーの？

( ﾟДﾟ)ﾜｶｯﾀ！
警察を潰せば良いんだよ。

>>447
中々ｲｲ着眼点だ

>>446
自分から見ても合法うんぬんって、無理でしょ。
トラフィックが上がって、そのキャッシュを調べられて
無修正のが露呈したら結局意味なし。
それに、>>446氏の意見はWinnyで実践されている機構の一部。

あと、何がダメって「違法ファイルが送信可能状態になっている」こと。
これが解決できなければ、何も解決していないことと同じ。

>>446
Bが警察だった場合どうするんだ？
考えが浅いよ。

>>447
じゃあ、言い出しっぺの藻前の担当と言うことで。

漏れはプログラミングとかの初心者でこのスレ何言ってるか解らない
レスも迷惑だと思うが、一つだけ言わせてくれ、お前ら最高だ。

神よ。早く次世代ファイル共有ソフトを作ってくれ。
心から応援している。

10年後20年後には俺のスキルも熟すだろう。
そのときは借りを返す。必ずだ。

頼んだぞー！

>>446
　つまり、　●●無修正盗撮ビデオ.AVI とかいうファイルを
　●●への旅.AVI　とかで流せばいいってことか？
　その場合、別に情報データベースが必要となるわけか。
>>447
　どうやって潰すんだよ。
　しかもｋだけでなくａとかｊもいるだろ。

>>453
いっそのこと、ｊと一緒にｉへいこうぜ！！

AU+GtZQdって自分がノイズってこと自覚してんの？
確かにこんなのばっかだと萎えてやる気なくなるな。

だから、漏れは逮捕者をゼロにすることは無理だと思うのよ。
なぜかと言えば、時間と労力をかければ、暗号という物は絶対破られる物だから。
ただ、その「時間と労力」を物凄くかけさせる様にすればいい。
だから某スレで『楕円曲線暗号』の搭載を提唱したんだけどね。
これならRSA暗号と比べて強度がかなり上がるし、処理速度も十倍になるようで。
「以下に手こずらせて、解析に時間をかけさせるか」
これをベースに考えれば、かなり安全性の高いP2Pが完成すると思うよ。

このスレの現在のテーマ:

〜〜〜〜ＫＡＪ対策になっております〜〜〜〜〜〜
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

以下に→いかに

>>453
微妙に違う
自分の保持しているキャッシュ自分から見た場合に限り●●への旅.AVIになるだけ
これでもそれなりの効果はあると思うんだがな
だって自分から見た場合に限りでも、あくまで共有してるのは●●への旅.AVIなわけだし
Kが乗り込んでPC押収して、そのPCから確認しても保持してるのは●●への旅.AVI
しかも中継でたまったのかもしれないというオマケつき
これでそれなりの言い訳できんか？

>>459
パッと見ではわからんのは良いとして、
　ＮＨＫとか、たまにＮＹの画面とかが出ているが
　スーパマリオアドバイス２.ZIP
　とかがずらりとあるが、あれが●●の旅の写真集.ZIPとかになるわけですね。
　これだけでもある程度の対策ですが、

　ｋに押し入られ実行された場合、言い訳が難しいと思いますよ。
　操作する時のマウスのパターンを予め登録しておくなどして
　もし違った操作をしたら、ダウンロードしたファイルやアップロード・
　キャッシュを削除するというのは…。
　パスワードだと、｛パスワード掛かってるぞ、教えれっ｝とか言われそうで。
　マウスパターンなら、気づかれないかと…。
　

>>460
マウスのパターンうんぬんが俺の頭脳では理解できんが
どうやら俺の案はダメらしいというのはわかった
ここで話がされてる「完全キャッシュを残さない」ってのが俺の案と合体したら・・
と缶コーヒー会に行く途中に思ったのだが面倒だ。後は任せた

( ♛Д♛)　ゔ〲〰乜勹〰ｽㄜㄝㄋ

なんかupフォルダ廃止の方向になってるみたいですが、
upフォルダ指定の意思をあいまいにして残す案

まず初回起動時に実在のフォルダをランダムに選んで自動的にupfolder.txtをつくる。
しかも大量に。upfolder001.txt〜upfolder999.txtくらいつくる。
そして本当に指定したいフォルダは、例えばupfolder234.txtに手動で書いておく。

毎回起動時にどれかがランダムに選ばれupフォルダに指定される。
どのフォルダが選ばれたかは分からない

起動後、upfolder234.txtをユーザーの操作で読み込ませる。

これで意図した操作で指定したupフォルダからupするのか、
偶然ランダムに選ばれたフォルダからupされるのか分からなくなる。


で、意図しない送信可能化ってOKなんでしょうかね？

>>461
　他のやつの意見はどうかわからんが、
　例えば、ある人は、円を３回描くようにマウスを動かすといった
　マウスパターンを登録しておく。これがパスワードの代わりだ。
　ｋにＰＣを扱われてもｋは円を３回描くなんてことはしないから
　間違ったマウスパターンでやってしまうと証拠を消す仕組み。

　キャッシュなどは仮想イメージの中に保存されてあるとすれば、
　エクスプローラとかから見られてもわからないはず。

なんで仕様と関係ない話ばっかしてんの？頭の弱い人達なの？

>>465
ｼｰｯ。ｲｯﾁｬﾀﾞﾒﾖ

>>464
なるほど。良くわかった
でも、それかなり難しいような気がするのは俺だけか？
マウスで円を3回描く・・これがパスになるのはいい
問題は3回描くのを理解するｱﾌﾟﾘだ
人間ならファジーな判断も出来るだろうが、機械が判断するとなると
登録時と完全に同じ、1ﾋﾟｸｾﾙも狂わず3回描く必要性がでてくるんじゃないか？

しちめんどくさい事やらずにパスワードにすればﾖﾛし。
パスワードに漢字使える様にすれば、かなりのセキュリティーになるんじゃないの。
それこそエヴァの「希望」とかでもKはわからんっしょ。
それに、円を三回〜とかやっても、暗号部分を解析されたら、それまで。
ちゃんと考えようよ。

>>467
それはブラック&ホワイトってPCゲームをプレイしてみるとわかる。
かなりでたらめに書いても意図したものと認識してくれる(丸と楕円形。とかは難しいが)
だが前例があるだけでそれを誰でも作れるって意味ではないが。

パスワードでも円でもいいとして、
　
ｋ　｛ﾋﾟﾝﾎﾟｰﾝ　警察ですが…
　｛ハーイ(^O^")／いま伺います、少々お待ちを…。(O.O;)(oo;)ｱｾｱｾ
　　　↑ここでデータを一気に消しておけばいいんではなかろうか。
　　　　その為にも違法性あるデータは常に整理整頓をしておくようにする。
　　　　別ＨＤＤとかにしてれば、外して隠せばいいだけだから尚いい。
　｛お待たせしますた。　で何でしょうか？｝
ｋ　｛あなたが●●で違法なファイルをうｐしてるみたいでね。｝
　｛ああ、そのことですか、やってませんよ。｝
ｋ　｛じゃあ、PC調べさせてもらいますね｝
　｛どーぞ。｝

混雑解消……Winny逮捕劇以降、ネットのトラフィックが急減
http://internet.watch.impress.co.jp/static/yajiuma/index.htm
JPNAPサービス：トラフィック図
http://www.mfeed.ad.jp/jpnap/traffic.html
↑急上昇しすぎ。
ぷららも他プロバイダからの接続要求が多すぎるって言ってたし

という事で同プロバイダ間接続を優先、異プロバイダ間転送をなるべく減らす機能必須。

>>470
既に確実なログ取られてたらどうするの？
証拠隠蔽で罪が重くなるよ。

Plalaのみトラフィックが増大する仕様にすることにしました

>>471
スゴ・・
グングン上がってたんだねｗ

MXの逮捕者の中にHDDを破壊しようとして出来なかった奴がいたなぁ

どんな風に破壊しようとしたんだろ・・・

レンジでチ〜ンしてたとか・・・

まぁ消して意味があるのかという問いがありますがｗ

レンジなら放電してきちんと逝く悪寒

完璧なセキュリティー「物理破壊消去可能型HDD」ｷﾎﾞﾝﾇ

こりゃ開発志願者も嫌になるわ

>>481

とりあえず、データ構造から先に進みませんが、
まだ、改善できる部分もあると思うので、じっくりと考えていくことにします。

とりあえず、141氏の転送方法に期待。
今日は来ておられないようですね……。

踏み込まれないようにするのが次期の仕様だろ？

おそらくもうすでこういうスレの案を部分的に採用して作り始めている
ネ申は存在すると思う。
ただ出てこないのは47氏の二の舞にならない方法を
模索しているのではないだろうか。
絶対に作者が捕まらない「これだ！！」って方法はないの？

――電脳世界の話をしよう。
レジスタンス「ＣＨ２」は連邦政府、「Ｊ・Ａ・Ｋ」と戦っていた…。
始めは優勢だったが、ついに主力戦車「ＭＸ」で死亡者が出てしまった。
技術者No.47は操縦者の安全を守るため、装甲が厚く、通信は暗号化する次世代戦車「ＮＹ」を作った。
が、政府は暗号は解らずとも何処から通信しているかは解るので、不手際で目立った奴を殺し、技術者に制裁を加え暗号表を奪った。
このため兵の士気が下がり、技術者は脅え、解放が遠のきつつある。
現状を変えるため「ＣＨ２」は新型戦車を作る事にし、操縦者の死亡率を下げる方法を考え始めたのだが、問題点が…。
・技術者の保護・共同で開発⇒スパイの可能性
・装甲の強化⇒使い勝手が悪い
・暗号の強化⇒使い勝手が悪い
・配備数を増加⇒へたれ操縦者の発生
…ん？なんでへたれ操縦者が増えるんだ？そうだ！奴らだ！犯罪組織「Ｓ」が一般人にマニュアルを売っているからだ！

自分で書いたものですが、>>113-115があまりにも分かりにくいので、記号を使って
まとめてみました。>>113-115とあわせて見ていただければ、多少は分かりやすく
なるかもしれません。
----------
以下は、「隣接ノードに情報を漏らさない」ことにより、ファイルを安全にupする方法の説明です。
暗号には公開鍵暗号方式を採用します（←これについては議論の余地あり）。

＜記号の説明＞
ノードAのupファイルの情報が、ノードCの公開鍵により暗号化してある状態を
・（C：Aのupファイルの情報）
のように示す。つまりこれは、「Aのupファイルの情報はCにしか分からない」ことを示す。
暗号化されてない場合は
・AのIPアドレス
と、カッコなしで示す。

初期のノード間の接続は

　E
　|
　A-B-C-D
　|
　F

とする。ここでは、AのファイルをDがダウンロードする場合について述べる。
以下の方法は、情報を送受信する過程でA以外のどのノードも
・Aのupファイルの情報
・AのIPアドレス
の2つの情報を同時に持たないようにして、Aを保護することを目的とする。
----------
続く

----------
>>114
＜キー拡散段階＞
�@　CはBに以下のデータを送信する。BはそのままAに転送する。
・CのIPアドレス
・Cの公開鍵

�A　AはCの公開鍵を用いて自分のupファイル情報を暗号化し、以下のデータをEに送信する。
・（C：Aのupファイルの情報）
・Aの公開鍵
・CのIPアドレス

�B、�C　Eは、AのIPアドレスを自分の公開鍵により暗号化してキーに追加し、
Eの公開鍵、EのIPアドレスとあわせてCに送信する。CはAのファイル情報を復号する。
結果、Cは以下の5つの情報からなるキーを持つことになる。
・（E：AのIPアドレス）
・Aのupファイルの情報　…注）暗号化されてないが、AのIPアドレスがわからないので問題ない
・EのIPアドレス
・Eの公開鍵
・Aの公開鍵

Cはこれらの中のファイル情報のみを公開する。他のノードはこのファイル情報を検索する。
----------
続く

----------
>>115
＜ファイル転送段階＞
�@　Dは落としたいファイルを検索し、Cが該当するファイルのキーを持つことを知る。DはCから
以下の情報をダウンロードする。ただし、Dの公開鍵=Eの公開鍵であれば、Cはデータを送信しない。
・（E：AのIPアドレス）
・Aのupファイルの情報
・EのIPアドレス
・Aの公開鍵

�A　Dは落としたいファイルのハッシュをAの公開鍵により暗号化してキーに追加する。
さらにDの公開鍵、DのIPアドレスとあわせてEに送信する。
・（A：Dが落としたいファイルのハッシュ）
・（E：AのIPアドレス）
・Dの公開鍵
・DのIPアドレス　…注）>>115では暗号化してますが、今の場合不要でした。失礼。

�B、�C　EはAのIPアドレスを復号し、残りの情報をAに送信する。AはDが落としたい
ファイルのハッシュを復号する。
・Dが落としたいファイルのハッシュ
・DのIPアドレス
・Dの公開鍵

�D　AはファイルをDの公開鍵により暗号化し、Fにファイルの転送を依頼する。
FはDに転送する。Dはファイルを復号して、目的のファイルを手に入れる。
Fは手元に残った無意味なファイルを即座に破棄する。
----------
続く

----------
以上の結果、
B、E、Fは、AのIPアドレスのみ知っている。
C、Dは、Aの保持ファイル情報のみ知っている。
どのノードも2つの情報を同時に知ることはできない。

メリット、デメリットは>>115参照。
----------

上の方法にこだわる理由の一つに、「キャッシュが必要ない」ことがあげられます。
もちろんキャッシュの拡散がないことはデメリットではありますが、このスレの流れの
「キャッシュを分割する方式」はそれ以上に問題がある気がします。

1つは捏造対策が不充分なことです。私の知る限り、これまでに出ている案は全て
「強制的にキャッシュを送りつける」仕様になっていますが、これでは悪意のあるノードが
捏造ファイルを大量にupすることで簡単にネットワークが崩壊してしまいます（既出の
意見で申し訳ない）。
たとえば>>39にある方法では、放流主がわざと公開許可キーを送信しなければ、キャッシュは
全て無駄なファイルになります。公開許可キーがなければ、そのファイルが捏造かどうか
判断することもできないので、対策のしようもありません。

続きです。
>>44からのJony氏の「RAID10ライク」な方法は、自分の保有するキャッシュを
分からなくできる優れた方法だと思います。しかし、ご自分でご指摘の問題点、
＞最初の放流主がLノードにいたとして、Rブロックを転送すればバレちゃうでしょう。
これの解決はかなり難しいのではないかと思います。
LノードとRノードを切り替える方法を提案されていますが、同じIPからLとRの両方で
接続してくるノードが放流主であることが分かる可能性があります。また、普段Lのノードが
放流のためにRに切り替えると、その間は新しいキーで検索できなくなります。理由は、
Rキーで検索しようとすると自分が持っているLブロックの中身が分かってしまう、かといって、
Rピアなので新しいLキーを大量にダウンロードして検索することはできないからです。
大きなファイルを放流するにはそれなりの時間を要するので、その間検索の効率が
落ちるとなると、誰もupしたがらなくなるのではないかと思います。

その他、前スレ191氏が指摘されている消滅確率の問題も、かなりの難題だと思います。
このあたりについて皆さんの意見を伺いたいです。
連かきｽﾏｿ。

次期P2Pに対する要望スレ
http://tmp2.2ch.net/test/read.cgi/download/1070085137/122
> 何回中継しようが、どれだけ暗号化しようが、簡単に摘発できるだろ。
> 捜査当局がDLしてるファイル（著作者から捜査のために許可もらう）の
> 転送元がわからないと言うことはあり得ない。
> その転送元のISPに令状出せば、上位の放流元がわかる。
> 多数の主要ISPからログ取得して、自動照合すればどこからどう中継されてるのか
> 丸わかり。
> 復号は、正規の使用法で復号できないなんてあり得ないんだから、デバッガ使えば
> 自分のマシンのプロセスで使ってる鍵をクローン出来る。

>>491
すごいな。ほぼ完璧じゃないか。
警察が最後の手段として、転送にかかわった疑いのあるISPすべてからログを提出させるなんてことをしなければ完璧。

よくこんなの思いついたなぁ、尊敬するよ。
ただ手順がえらく複雑だから、よっぽどうまくコーディングしないとバグだらけになるな。

しかし、暗号を頻繁に使う仕様なので、相当負荷がかかるな。

>493
そんなにすごい？長いから起きたら読むわ。
あと、これ公僕に踏み込まれた時、言い訳できる？
完全ファイル保持してるようだから。

>>495
踏み込まれた時って、の立場で？
送信者？中継者？それとも受信者？
中継者はすぐにキャッシュを消してしまうから、言い訳できるんじゃない？
送信者はアウトだね。っていうか送信者は身元が割れた時点でアウトなので気にしても仕方ない。

今気づいたが、>>491の方法で唯一気になるのは多段中継がないことだな。
もし警察がその気になってログをとっていったら、すぐにばれそう。
しかしあの複雑な暗号鍵の取り回しを多段中継で行うとなると、相当緻密なモデルが必要だな。っていうか実現可能なのか？

>>490
鋭いツッコミありがとうございます。
まず、公開している最新版は ttp://s2net.s41.xrea.com/ にあります。
さっきも少し変更を加えました。公開していない私のメモでもちょこちょこっと進んでいます。

>ファイル強制転送における捏造ファイルup頻発問題
トリップ評価、ファイル評価の情報交換によって対応するのが基本となります。
ネーム・トリップが必須で、新しいネーム・トリップで参加しても、
しばらくネットワークを使わせてもらえないとか。
他にもいろいろあるんですが、もうちょっと考えてからまとめページにでも載せましょう。
一つ一つはショボイもんですが、組み合わせるとかなり強力になると思います。

>これの解決はかなり難しいのではないかと思います。
難しいです。っていうか、どうしようか困ってますｗ

ノード間は、接続確立時に、公開鍵暗号方式を使って、秘密鍵（ランダムに生成）の交換をしておく。
ブロックのハッシュ値を、宛先との秘密鍵を使って暗号化しておき、その宛先以外に転送。
これによって、中継ノードが何を中継しているか分からない。
……みたいな感じですかね。中継ノードにキャッシュが残らないという問題点がありますが。

>同じIPでLノードとRノードを切り替えたノードが放流主であることが分かる可能性がある
自分で書いておきながら、使い物にならなさそうだなと思うアイデアです。全くというわけではないんですが。
なぜなら、動的グローバルIPアドレスの場合、時間によってLノードとRノードが入れ替わることがあるからです。

>その他、前スレ191氏が指摘されている消滅確率の問題も、かなりの難題だと思います。
消滅確率については、解決できそうです。

周りのノードが、ある50％ブロックを保持しているか？　という情報が
無差別に送りつけられてくるのか、こちらが持ってるか聞きまわるのかどうかは置いといて、
周りがその50％ブロックを持ってるんか？　というのは分かるはずです。
前に、中継ノード側が50％固定で更に中継するか否か決めるといいましたが、
放流主がブロック自体に何％の確率で中継するか自動的に選ぶようにするといいかなと思っています。
30％〜70％ぐらいの幅で周りの普及率に応じて自動的に決定すると。
周りに普及していないブロックについては、中継率高めになるわけです。
30％に指定しようが70％に指定しようが放流主かどうかはほぼ分かりません。


転送方法だけでなく、データ構造も、まだまだ改善の余地があると思っています。
いきなり、ガラリと変わったりすることもあるかと思います。

>>491 さんのアイデアに関しては、じっくり読んで感想を出したいと思います。

ttp://nyamco.ath.cx/nyamco/files2/1070315330.lzh

流れとは関係ないけど、p2p にてどのようにネットワークを
構成しルーティングはどうするのかの参考資料として見てください。

winny ではツリー式で構成されていて高速回線にトラフィックが
集中しがち。そして DOM に吸い逃げされてしまうことも多かった。


そこでメッシュ状に構成した場合を考えました。
ブロック等を要求するリクエストをあるノードが発生させて
バケツリレー式に転送されていくとします。
ループ対策のために各ノードは一度受け取ったリクエストを
受け取っても破棄してしまい転送させません。

各ノードは、平均で３つのノードと接続しているとして
（各ノードが p2p ネットワークに入る時に２接続をしていくとこうなる。）
均等にランダムに分布してるとして

１００万ノードで構成されている場合でもわずか平均 16 ノードを
経由するだけで隅々までリクエストが行き渡ります。

但し上りトラフィックが大きい問題があります。

一リクエスト 256byte として、一ノードが一リクエストを
発生させるだけで、一ノードあたり 512 byte のトラフィックが発生。

各ノードが一時間に一リクエスト発生させるとして、１００万ノードで
運営すると、一ノードあたり 139 Kbyte の上りトラフィックが発生。

TTL値を導入するなどして対処する必要がありそうです。

500

>>490

だからそれじゃ全然だめだってのに。
いくら中継しようとも、中継してるノードと情報を受け取るノードが
手を組んでたり、つまり両方警察だとか、両方クローンノードだったり、
あるいは、中継をエミュレートする一台のノードで複数台のノードを演じていたり
したらアウト。

結局のところ、Ｐ２Ｐネットワークにどれくらい「白くないノード」が含まれているか
に依存して、中継段数における安全性が確定するわけだけど、中継段数を増やすと
アプリケーションルーティングの本質的な問題に行き着くだけ。

アプリケーションルーティングをやろうとすると、結局、エンドノードの
不安定性が問題になって、解決はほぼ困難。そんなのはIRCの時代から指摘されていたこと。

なんでみんな「ノードが動かない」を前提としてるのかな？
そんなのでうまくいくわけないじゃん。

>>499
平均3じゃ、グラフ的に疎すぎるよ。
Ｐ２Ｐネットワークが分断される可能性も高い。
メッシュより、ノードが持つ情報(macとlocal time）から十分に長いn bitの情報を生成して
その情報を元にm次元トーラスにノードを重複無く配置して、後は重み付きでランダムウォークか
ホットポテトのようなルーティングするとかの方法の方が現実的。

47ってすげぇなぁ、とこのスレを見て思った。

読んでいただき、ありがとうございます。
この転送法について昨夜寝床でさらに考えて、改良案を思いつきました。
>>113-115（= >>487-489）に致命的な問題点がないようであれば、
次に書きこむアイデアは間違いなくその上を行くはずです。
もう少し詳しく書くと、＜ファイル転送段階＞の�@で、D=Eのチェックが
不要になります。
残念ながら今は時間がないので、今夜（〜明日未明?）書きこもうと
思います。とは言っても、ちょっとしたひらめきにすぎないので、
思いついた人がいれば私を待たずに遠慮なく書きこんでください
（とかいいつつ、今私が考えているものよりも優れたアイデアを期待
してみるﾃｽﾄ）。

>>492
事はそんなに単純ではないと思います。たとえば>>489の�DでAがFを経由して
Dにファイルを転送する段階で、Fがほかにもファイルを転送中、あるいは
ファイルをダウンロード中だったとすると…

>>Jony氏
wikiは後ほど拝見させていただきます。私のアイデアへの突っ込み、お待ちしてます。

>>504
>事はそんなに単純ではないと思います。たとえば>>489の�DでAがFを経由して
>Dにファイルを転送する段階で、Fがほかにもファイルを転送中、あるいは
>ファイルをダウンロード中だったとすると…

そんなメンドクサイこと考えなくても、単純にL3までしか見えない
ISPに対してそれ以上のレイヤの情報の隠し方なんていくらでもあるよ。
sshやhttpsみたいなので上を隠して、後はノード間で常にダミー
トラフィックかけておいて、L3から見たトラフィックパターンを
常に同じにしておけばいいだけ。
もちろん必要に応じてできるだけシームレスにダミートラフィック
とコモディティトラフィックの割合を入れ替える。

ちなみにISPはportでフィルタするので、httpsとか「ISPが
閉じたら商売にならないport」で隣接の通信を行うのが良い。

もしオープンソースになったらどのぐらいの人が参加できるんだ？
俺もC++ならできるけど#とかは厳しいかも

パチンコ屋方式にしてさ、ファイルのやり取りと変換と別のソフトですれば？
意味不明な物交換するソフトと意味不明な完全ファイルを変換出来るソフト。
素人が口をはさんで悪かった。。。

>>507
口を挟むのはいいけど、散々既出なネタは勘弁してね・・・。

Pass付きZIPにするだけでその目的は達成される。

ファイル壊すソフトで変換かけて、壊れたファイルやりとりするでしょ。
出来上がった物をまたファイル壊すソフト使うと出来あがりみたいな。
度々ごめん。力になりたいのよ

>>510
それを暗号化という。

ここは、既出のツッコミ等以外は素人の発言を禁止したほうがいいね。
かく言う漏れも素人だから既出ツッコミ以外は自粛してまつ(´･ω･`)

だから昼の部なんて言われてしまうのだよ。。。

暗号化と違う点は複数のソフトでやるから無関係という点か？
でも、それはここじゃなくて法律の方で検証するべきだと思う。

昼間の人でも、読んでると面白いと思う時あるよ。
読み返していると、"邪魔"だと感じる事もあるけど。

少なくとも、パート1から"読み考えて"から、書き込みして欲しい。

datファイルが良いなら、datであげるから。

>>507
いやいや、いい着眼点だと思いますよ。
ただ、変換が誰でもできるようなもの(例えば単なる圧縮)だと、
違法ファイルを共有していることそれ自体が違法になるわけです。

スレ２ >>33で出てたように、
完全に共有自体を1つのソフトで行おうとするから
効率と匿名性との二択という隘路に陥るわけです。

まずはWinnyライクの効率重視の共有ソフト。
といってももちろん違法共有を目的とするわけではなくw
そこに共有されているデータを数値として読み取って、
先頭部、1/1000、2/1000・・・最後部のデータの値から
素敵なフラクタル図形を描出するためのソフト。
色んな図形を見るために、皆色々なファイルを共有するわけです。

・・・もしかしたら図形を見たいがために、
パスがかかったファイルとかが共有されているかもしれませんが、
復元不可能な違法ファイルは違法ではありませ。
作成者はパスを隠しておいたのに、どこからともなく知れ渡って
しまった場合でも、作成者自身がパスを流したとか、
すぐ分かるようなヒント付きとかや簡単なパスとかでない限り
過失しか認められないでしょう。

それとは別に、freenetライクの匿名性を重視した共有ソフト。
ここでは、テキストのみが流れます。
無論、ここでこういう妄想を語るのすら躊躇われるような
萎縮状態を取り払い、自由な言論の場を守るためのものです。

・・・もしかしたら違法ファイルのパスとかが流れている
かもしれませんが、まあある程度は必要悪でしょう。
もしかしたらそのパスは、パス付ファイル作成者以外の
誰かが流したり、ネットカフェが発信源かもしれませんね。

これは高位の価値を追求するためのソフトであるので、
ある程度敷居の高いものであっても構わないかもしれませんね。
たとえば LinuxやSolaris用のみとか、
起動時に著作権法の試験に正解しないといけないとか(笑)

つーか今見たら
法律スレ >>737で似たようなのがでてました・・逝ってきます

なんか盛り上がってきたところで自分みたいな初心者が出るのは恐縮なのですが・・・

ネットワーク内に情報サーバを作ることできませんかね？
情報サーバからK、最新ver、捏造、などの情報を流せると便利だと思ったのですが
・・・だめですよね？
なんかペース乱す様なこと言ってすいませんでした。
初心者はしばらく引っ込んでます

>>519
> ネットワーク内に情報サーバを作ることできませんかね？

それじゃPtoPと呼べないな。サーバークライアント方式になる訳だから。

> 情報サーバからK、最新ver、捏造、などの情報を流せると便利だと思ったのですが

・専用サーバーを作った場合、運用・維持管理に費用が掛かる
・サーバーの参照ログをみれば、誰が使用しているか一目瞭然
・専用ソフトをダウンロードして動かすだけでサーバーになれる場合、
　　「悪意のある人間」がサーバーを運用する恐れがある。

>>◆Fw0Kir8iYA
読ませて頂きました。なかなか良いアイディアですねぇ。前の説明よりわかりやすいですしｗ
ただ、今の仕様だと一段中継ですので、少し手を加えて多段中継にしたほうが
良いかもしれません。(>>320みたいなｗ)
それとファイルをアップごとに暗号化するのは実現不可と言っても過言ではなので、
最初にキャッシュに変換しておくのが妥当かと思います。
（簡単な暗号化の案としては430に書いた私の案はいかがでしょう？
誰も何も言ってくれないのですがねｗ）

壊すソフトは純粋にシュレッダー的なソフトとしてベクターとかで配布します。
偶然それ使えば復元出来たみたいなのってどうかと思いまして。
P2Pには壊れた物しか流れてないんで共有ゴミ箱って感じで・・・。
邪魔してすいませんでした。
もう来ませんので、みなさん続きをどうぞ。

>114案をじっくり読ませて頂いたけど
Eが常にAを知っているという状況がちょっと気になるなー。

EのIPはDからは丸見えなんだから、ファイルとEの因果関係は掴めてしまうんですよね？
とすればEノードのISPと協力して通信を監視すればAの所在も簡単にバレてしまうのでは？

Eがキーの寿命に際して都度変化するにしても、Eに繋がる何れかのノードが実体ファイルを
持っている事が確実な以上、いずれはAの存在が浮き出てきてしまうのでは？
Kはそうゆう地道な作業は得意中の得意だしねー。
あとはA、D、E間でのキーの流れを監視すれば暗号を解読するまでもなく
Aがファイルを所持している事が確実になってしまうような。

必要なのは「複雑さ」じゃなくて「不確かさ」のような気がするぽ。
ｎｙは実際にはほとんど発生しない転送を、
それでも0%ではないというこけおどしによって不確実さを保っていたわけで、
この理念自体はいまだ有効だと思うのよ。

もちろん十分な複雑さがあれば解析は困難かもしれないけど、
複雑さは効率とトレードオフなんだよね。
不確かさはそうじゃない。この辺りに重大なヒントがある気がする。

なんつーかJony氏が作ってるのと開発が進んでいるらしき
ドロシーとやらは別物なん？
なんかドロシーは着々と実装してるみたいなんだが・・・

検索キーに
「バルス！」
と入力すると、末端のノードから切断→自己消去

CPUという名の石は負荷の軽くなり・・・

>>524
ドロシーはネタだ！！！

ドロシーやっぱネタなん？いま待つスレ読んでたんだが5日で作るって言ってるし
どーなのかとおもってたんだが。
漏れ的には大人気無い気もするけど（藁）RAID5マン氏の提唱してる方式が
ベースとしてはイイ！って感じるよ。ただ転送の部分とかで詰めきれてない
っぽいから>>487あたりで提唱された方式とのハイブリッド案とかのがよりイイ！
って思うがなー。昨晩プチ切れして（藁）いなくなっちゃったけど誰か検討継続したら？
漏れはJony氏とRAID５マン氏の中間的アプローチで奇数偶数パリティの３つ
のうちわざと奇数か偶数ビット欠落させてパリティとで流せばJony氏のいってる
LR方式と融合できそうな気がする。
どの方式がいいかなんてばかげてるから提案のイイトコ取りで融合すればイイ！んじゃ？

作れる技術がある人はそれぞれ勝手に作ればいいんだよ
どうせ大規模テストしなきゃ使えるか分からないんだから。

>>527
ネタじゃないかもしれないけど、ネタの可能性もありうるな。

>>517
ファイルアップと、ファイルを復元するための鍵を別々に流すという意見は激しくガイシュツ。
この方式の欠点は捏造ファイルへの対処が難しいこと。落としてすぐに確認できないし、意図的に復元用鍵を流通させないことも考えられる。
また、ファイルだけ残っていて復元鍵が失われることもある。

>>523
それは多段中継によってある程度回避できるかと思われ。
EとAの間にもういくつかノードをはさむか、もしくは、実はファイル転送要求をだしたDすらも中継ノードに過ぎなかった、とかのトリックが必要になるが。

完全キャッシュを自分のところに持たないという手法は、freenetみたいにサイズの小さいファイルを共有することを目的とするならOKだが、巨大ファイルを共有するのには激しく向かない。

送信の度に暗号化するというのも、暗号鍵は使い捨てにするという本来の目的にかなった使い方であるが、非常に負荷が高いね。
RSAでなく楕円曲線暗号で１６ビットくらいの鍵ならそれほど負荷はかからないか？

優先順位って
作者の安全＞＞利用者の匿名性＞パフォーマンス≒トラフィック
大体こんな感じだろ？

>>527
トラフィックを単純に1.5倍にしてしまうモデルってあまり好ましくないような

暗号化に6/4は使えませんか？

>>532
詳しい話は夜の部のエロイ人が突っ込むだろうけど、
確かに転送量１．５倍はアレだろって思うな。だから
漏れは偽装化のメリット生かすために奇数ｏｒ偶数ビット
のどっちか欠落させてパリティと流せばっていったんだよね。
これなら双方のメリット生かせるじゃんってのが趣旨なんですが。
まぁ夜の部のエロイ人の突っ込み待ちましょう。

ttp://nyamco.ath.cx/nyamco/files2/1070353465.lzh

プログラムに初歩的なミスがあって間違った結果がでていましたので
訂正させていただきます。

（既に無意味なものですが間違いをそのままにしておくのはなんなので。）

>各ノードは、平均で３つのノードと接続しているとして
正：各ノードは、平均で４つのノードと接続しているとして

おかしいとは思っていたものの、本当におかしいことに気がつきませんでした。

>１００万ノードで構成されている場合でもわずか平均 16 ノードを
正：１００万ノードで構成されている場合でもわずか平均 12 ノードを

>運営すると、一ノードあたり 139 Kbyte の上りトラフィックが発生。
正：運営すると、一ノードあたり 139 Kbyte/sec の上りトラフィックが発生。


>>502

実際、ノード数が充分多いとき１割のノードが切断するだけでほとんどの確率で
分断してしまうようです。
一応分断に対しては対策もあり、各ノードは予め、隣のノードがつないでいる隣隣ノードを
把握しておき、隣のノードとの接続が切れたら隣隣ノードと接続に行きます。
１００％ではありませんが、これでほとんど解決はできます。
（P2P FINDER 対策も一応考えてあります。）



.。oO（Winny の弱点ばっか指摘してきたけど、Winny ってやっぱよくできてるな）

ちょっと横レスして猿。

ドロシーは表向き、一般ねらに「次はコレだ」と宣伝用。
あくまでも本命はコチラだと思って読ませていただいてます。

なんつーの、このスレって一昨年ねらを救った雲丹板ぐらいのインパクトがある
良スレですね。ｻﾗｻﾗさらっと記念パピポ。

では。

p2pism: a simulator for peer-to-peer protocols
http://www.pdos.lcs.mit.edu/p2psim/

>>536
だったらageんほうがいいぞー

実際に作る気がある人間がいるのかどうかが問題だな。
俺なんか仕様書を作った時点で満足しちゃう性質だからなぁ。

つか要望スレであったんだが、
クリック1発でキャッシュの一部を
ランダム値で上書きする機能をソフト自体に標準で搭載っていうのは？

CD、DVD等に焼かなければ安全かと・・・。

>>536
いろんなところで開発している人がいるみたいだから
どれが本命になるかは未知数。

p2p ソフトラッシュになるかもしれません。

>>540
どちらかといえば、ここよりも法スレ向きだと思う。
留守中の家宅捜索に備えてやはり分割は必要。

仕様さえ出来上がれば、自己満足(おなにー)の為に通信部だけ作りますが、何か？

>>542
仕様が完全ならコーディングだけは出来る、なんてコーダーは山程居る。
ただのプログラマーではチヤホヤされませんぞｗ

>>538
あちゃ、今気が付いた。すいませんでした。
さげサゲｓａｇｅ〜！！！失敬。

あのさぁ、
「良し仕様も大体決まったようだから、試しに作ってみるか。」
っていう人が出てきそうに無いと思うんだけど。
ここにいるのって何にも作れない人ばっかりでしょ？

47みたいなのは、もうこの板にはいないでしょ、普通に考えて。
どのスレッドもアホなガキばっかりじゃない。

誰も作らないソフトの仕様を決めて何がしたいんですか？
この屑どもが

定期ageご苦労さん

いや、マジで。
誰も作らないでしょ？
ええ

巡回煽りご苦労さん

>>545
288 [名無し]さん(bin+cue).rar sage New! 03/12/02 18:01 ID:LW9mfKKs
こういうプログラム作るにはどうすればいいの？いま高３で進路迷ってて、こういうプログラム作るような
勉強してみたいとか思ってるんだが・・・。そうするとやっぱ情報系？

すいません。私がアゲたばっかりにヘンなの呼んじゃって、、
ここは一つ「実はﾀﾞｳｿで進行中の開発は全てﾈﾀ」というお約束で。
>>547
そう、2ちゃんねるなんかにＰ2Ｐを開発できるスキルを持つ人はいません全てﾈﾀです。
心配しないでお帰り下さい。

私も帰ります。。。ホントすいませんでした。

プログラムやりたいやつは専門学校いけ。
ゲームの作り方から何から何まで教えてくれるぞ。
大学はプログラム以外の勉強もしなくちゃいけないから、すでにやりたいことが決まっているやつにとってはかなりつらいかもしれない。
ただプログラマーも楽ではないということらしいがな。

C言語とか C++、java,cobolとか色々言語あるけど、結局柔軟な頭をもち
アルゴリズムが出来ると強いよね。

言語も出来ない厨の戯言でした。

技術的な問題だけでは無くてね

俺は、いま専門学生なんだが、
　疑似言語＜ｱﾙｺﾞﾘｽﾞﾑは習っており
　ＣＡＳＬ２やってるんだがさー、
　
　ｖｂとかＣとかやってないのね。
　↑んなために役立たないと思ってる。
　
　Ｃ＃覚えようと思うんだけど、どうかなー。

重要なことなんだが
1) UPする人はファイルを持っていてはいけない
2) DOWNする人はファイルを持っていてはいけない
3) 中継するＰＣはファイルと特定出来る状態でキャッシュを持っていてはいけない

上記が守られないと逮捕だと思うのです

1) を解決するには分散放出です
2) を解決するにはオンデマンドです
3) を解決するには。。。ガイシュツですね。

Ｋが一ユーザを装うことを考えないと、どこかの段階で
ファイルになってしまうとアウトです

夜の部はやく来ないかなー。。。っと

プログラムか、漏れはまだHTMLしか・・・（汗
PHPとJAVAも少々いじれるけど…これじゃあ皆の役に立てない…
高校卒業するまでに独学で　C　を極めてやる！！

ＨＴＭＬってプログラムって感じしないけどねー。
　まあこのスレみてプログラムやろうとしてる人間は少なくとも
　いるようだ。みんなもがんばれ。

このスレで出てるいろんな案はさ、
仮に ISP のログが完全な状態であったとして
それ漁られても up した奴がわからないような代物なのか？

今の時代はjavaが一番トレンディだぞ！

>>557
プログラムの独学結構だが
領域とか流れ図とかちゃんと専用の紙にかいてからしろよ。

ちと聞きたいんだが、
　Ｊａｖａをやるのと、.ＮＥＴをやるのっていったら
　どちらのほうがいいんだろうか？？　スレ違いですまんが教えて欲しい

>>561
　わざわざ専用紙に書くのって面倒じゃない？？
　

烏合の衆がよってたかって設計するより、
Freenetのテスターになった方が現実的。

>>563勉強にならんぞ。
言語のHPをチョチョッと見ただけですぐ理解できるようなもんじゃないだろう
つーか俺がそうだ。
天才じゃない限りは紙にかけ　そして舐めるように見て何度もなぞれ

今の勢いだと今年中に一通りCをマスターできる予定。
TCP/IPも同時進行。高校になる前にC以外の言語も使えるようにしよう

>>565
　まあ学校では書いてるんですけどね。
　結構、成績もいいほういってますし。
　でも今は疑似言語やってます。

アナログに強い奴はデジタルにも強い。
アナログに弱い奴との差は歴然。

やっぱ平日は夜の部遅いね

アニメ好きな奴はプログラムにも強い。これ定説。
ただし出不精なやつはプログラマには向いてない

　　　　　　　　　　　 .t- ..,　
　 _ 　 　 ____　　 _, .-‐'"￣"'-ﾆｭ　
　r,.,ニニ.,,,__ "'" __　 ノ　　 　　　"''- 、　
　/,.- ─ -- 、"_,..,￣ '::.....　　 ヽ､<.　@ヽ, 　
　"　　　　　　 "　　￣^'''^￣^'' ‐‐-ニ-＝

厨房でCを使えるのは凄いことなのか？

>>572
小３がコンパイルできる時代なんだからさ・・・

>571 脚?

＞結構、成績もいいほういってますし。

上には上が居るって思考じゃないと成長しないよ？

擬似言語？・・・
どこかのスレで聞いたことあるような・・・。

夜の部まだかな・・・

クソスレ

だれか答えてけれ

■がﾙｰﾌﾟで
▲が条件で　日本語ｺｰﾃﾞｨﾝｸﾞしていくやつ。
　まあ、上には上がいるってことはこのｽﾚみてつくづく思ってますよ。

ところで47氏も次期P2P製作に参加してるの？

>>573
小３でコンパイルかよ！
俺が小３のころなんて鼻たれて遊んでただけだ・・・

>>580
警察に家宅捜索までされてんのに?本当だったらすごい漢だね

47氏はどこまで行動制限されてるんだろか

>>579
>まあ、上には上がいるってことはこのｽﾚみてつくづく思ってますよ。
自分がある程度、上の位置にいたと思ってたんですね。おめでてーな。

513 名前：[名無し]さん(bin+cue).rar[sage] 投稿日：03/12/02 13:57 ID:zWJfmwcN
だから昼の部なんて言われてしまうのだよ。。。

538 名前：[名無し]さん(bin+cue).rar[sage] 投稿日：03/12/02 18:06 ID:zWJfmwcN
>>536
だったらageんほうがいいぞー

556 名前：[名無し]さん(bin+cue).rar[sage] 投稿日：03/12/02 19:10 ID:zWJfmwcN
夜の部はやく来ないかなー。。。っと

568 名前：[名無し]さん(bin+cue).rar[sage] 投稿日：03/12/02 19:40 ID:zWJfmwcN
アナログに強い奴はデジタルにも強い。
アナログに弱い奴との差は歴然。

これまで沢山出てきた方式の本質は

1. 中継によって身元(IPアドレス)を隠す
2. ファイル暗号化分割放流(一部のファイルだけでは復元不可能)によって
　　一次放流者(神)であることを隠す(中継者を二次放流者とすると、
　　一次と二次は外部観測的に判別不可能)

の二つ。
いろいろ面倒なことやってるけど、上記が満たせていればＯＫ。

実はどっちもトレードオフを抱えててそれは、

1. は中継段数を上げると匿名性が高まるが到達性が下がる、下げると逆。
　　A-----T1------T2-----T3----...-----B
　　と
　　A-----T1----B
　　で、匿名性と到達性がトレードオフ。細いリンク、落ちやすいノードが
　　間に入る可能性が高くなるから。
　　応用を効かせて、複数の異なる経路を確立して、つまり
　　.-----T1------B
　　/　　　　　　/
　　A----T2-----.
　　とかやってAからBに情報を送る場合は必ずT1、T2、あるいはそれ以上の中継
　　経路、中継ノードを通すとかで到達性を高めることもできるが、
　　帯域使用効率が下がる。Aのuplinkが細い場合に経路を
　　冗長化したらほとんどupできない。

(続き)
2. は分割したファイル群を一つの隣接にどれくらいまとめて送るか
　　(とりあえず隣接送信ファイル率とか名づけてみる)、
　　その隣接送信ファイル率を上げると(例えば50%以上)とすると
　　最悪の場合隣接2台が警察なら逮捕、つまり匿名性が下がって、
　　帯域とディスク使用率が上がる、また冗長性は高めになるので
　　目的ファイル入手率は上がる、
　　逆に隣接送信ファイル率を下げると(例えば10%以下)とすると
　　隣接2台くらいが警察であっても復元不可能、つまり匿名性が上がって、
　　その代わり、十分な冗長性が無いと目的ファイル入手率は下がるので、
　　十分な拡散性と冗長性が必要となり帯域とディスク使用率が下がる

匿名性を上げるには、上記2つを組み合わせて使うべきだけど、
結局匿名性を上げるために効率を犠牲にしている。
つまり、本当に匿名性を高めたいなら、上記でのパラメータを最悪を想定して、
中継経路は100本必要、そのそれぞれに100中継ノード必要、
さらにファイルは0.01%のサイズまで分割して、各ノードに0.01%しか送らずに
10000ノードに送って冗長度を100にする。
というとてつもなく効率の悪い代物が出来上がる。
匿名性を極端に下げれば、中継経路1、中継ノード数0、ファイル分割数1、
つまり直接送信。

つまり、匿名性を得るために各種効率を下げるのは仕方ないが、
それでも効率を上げるには、如何にしてP2Pネットワーク内の黒ノード率
を下げるべきか、というあたりがポイント。

>>578
全パケットを盗聴する？
全パケットを記録する？

憲法違反
違法なんてレベルじゃない
まず全員の分記録できないしな

ISPは通信量が多いって意味で絞れるかもしれないが、それで即盗聴・記録となると
確実に違憲で事業免許を潰される可能性まである
相当証拠集めて、理論武装した後でないと、警察もISPもかなり危ない荒業

UPが異常であれば目星は簡単につくけどね、それは何ら容疑にも罪にもならないでしょ
その状態で噛みついた相手が、やっかいな連中と繋がりがあるかもしれないし(政治家や官僚の知人・親族)
変な敵を作らないためにも、安易にとれる手段ではない
何処からか情報がもれ、晒されたら一貫の終わり
組織犯罪であれば可能かもしれないが・・・指定暴力団でもないとねぇ

次期P2Pのクリアすべき課題を法的な観点から考察
http://tmp2.2ch.net/test/read.cgi/download/1070084504/
次期P2Pに対する要望スレ
http://tmp2.2ch.net/test/read.cgi/download/1070085137/

>588 速やかに法律スレに

>>588
記録するだけで憲法違反だったんか
法とかそのへんは全く無知なんで、スマンかった

>>591
ん？
回線事業者だとマズそうだけど、通信事業者なら記録するだけならＯＫじゃないの？
守秘は「外部に対して漏らす」のがマズいだけで。
記録じゃないけど、検査ならあたりまえだよね。
ＩＤＳとか。

>>591
憲法違反っていうのは、国家権力による検閲とかだしょ。民間企業の場合は関係ないべ。
民間企業なら電気通信事業法違反でないの？

なんか37歳氏のスレが盛り上がってるな
ほんとに作っているんだろうか？
ネタだったらやだな・・・

>>592
ペイロードを全部記録は駄目では？
郵便局員が手紙の中身写しておくような物じゃないの？
あまり詳しく無いが


>>593
摘発だから警察の指示が絡んでるとオモタ
確かにISPが違憲は言いすぎでつ
スレチガイスマソ

ここの神が照らす光は
我々MACの民にも見えるのでしょうか？？

>>593
まあ、どっちにしろISPがパケットダンプすることはありえない。
警察もしない。
P2Pユーザーとなって、自分とこに送られてきたパケットを監視するのは合法だべ。

いい加減にしろよ、馬鹿は書き込むな。法律スレいけ。

>>487
少し複雑だな。この複雑さであれば穴が沢山出来ると思うぞ。
例えば公開鍵とIPが関連付けられたらどうする？
この公開鍵を持つIPは○○だ！、と言うことが分かっても大丈夫？
相手は複数のクライアントを使うはずだ。相手が相互に連絡しあった場合に
もこの構造は通用するの？

また送信する内容が割と限定的な場合は公開鍵さえあれば内容を総当りで解読が可能。
（細かく見て無いからこの問題は無いかも知れん）
その他頭良い人ならさらに幾つか穴が発見できるかもしれない。

とは言っても間違っているのは自分かもしれないので、真に受けないように。

補足。
Aの公開鍵はAから渡されるのだから、Aの鍵を持つ奴のIPを
そのノードは分かっていると言う訳だ。

と書いたら余計わからんな。Aってのは適当だからね。

>>599
たしかに、CとEがグルなら公開鍵とIPが関連づけられ、
そのIPが持つキー情報がばれるね。
そうならないために、中継ノードを増やすんじゃない？

公開鍵と一部内容を知っていても解読するのは無理だろ

>>602
だから中継ノードを増やすのは到達性と匿名性のトレードオフ。
それに中継ノード増やしたら経路制御大変だぞ。
下のグラフで２重線が光でただの線がADSLで、..がISDNだったらAからEの経路は？

　　Ｆ−Ｇ−Ｈ
　　｜　　　||
Ａ−Ｂ＝Ｃ..Ｄ＝Ｅ
｜　　　｜　　　||
Ｉ−Ｊ−Ｋ−Ｌ−Ｍ

やっぱりあれだよ、UDPによるパケット偽装しかないって。
誰かUDPでも何とか転送できるプロトコルを考えれ。

>>602
例えば中身がIPアドレスと比較的に変更が少ないファイル一覧だとしよう。
この場合IPアドレスを変更しながら暗号化すれば暗号後のデータと
一致するファイルが必ず生成される。

まぁ関連付けの方は微妙に判りづらい説明でスマン。
簡単に言えば情報収集されると弱い構造なんじゃないか、と言う事。

つぅかADSLすらも使えないやつはP2Pに必要ねぇだろ。
いったいどれぐらい貢献してるんだアナログとかISDNってよ。
nyでもPort0と並ぶ邪魔者だし、新システムではアナログとか
Port０のやつは除外だろ。

ISDNな香具師はエロ画像でも集めてればいいんだよ。
アナログな香具師は。どうでもいいやｗ

P2Pはブロードバンド前提だろ？

>>606
実際にISDNかどうかは問題じゃなくて、
悪意のあるクローンノードが混ざってたら
本当は光のくせに、自分が使い終わったらISDN並みの速度で
転送するようにする、とかいうイタズラも可能なんだよ。
しかもこれはクローン等の問題じゃなく、ソフトや仕様で解決できる問題じゃない。

ちょっと高級なスイッチがあれば速度設定可能だし、
そうじゃなくてもコリジョン発生させまくれば速度落とすのは容易。

>>606
そう虐めるなって！
　まだみかかのサポートが悪くＡＤＳＬにできんやつだっているんだからさー

>>606
アナログとPort0とIPv4は除外っていうのが手っ取り早くていいな。

RAID5案はシンプルであるという点で実現性がわりと高い案だとは思う。
匿名性、効率性に関しては実際に動かしてみないとなんともいえんところも
あるけど
もうちょっと細かく詰めていきたいところ。
参考：>>274-277

例えば今のところ何の言及もされていないファイル検索の仕組について。

1:まず自分のFileTableに検索をかけて該当するファイルの有無を探す
なかった場合は2へ。見つかった場合は3へ
2:隣接ノードにキーを飛ばす（この辺りは暫定的にnyの検索システムと同様のものとする）
ファイル情報をもっていた場合はFileTableを送り返す。3へ
3:FileTable内の情報を元に各ノードにリクエストを送る
破損クラスタがあった場合はFileTableにその旨を書き込む。4へ
4:ファイルが完成しなかった場合は再び検索をかける
2と同様の動作だが、FileTableを受け取る際に相手のFileTableに
自分のファイルテーブル（破損部分を除く）を上書きする

各FileTableが1ファイル分すべてのクラスタアドレス（ミラーリングされたものも含む）
を持っていると仮定してます。
結構な大きさ(1ファイルあたり10KB前後？）になってしまうと思うけど
あくまでファイルの実際のやり取りの際にしかコピーされないので負荷はそれほどでもないかと予想。
もっと効率的なアイデアがあればレスキボンヌ。


ふと思ったんだが、ネットワーク全体を１つの巨大なストレージと仮定すると
FileTableを所持していること自体が違法ファイル所持と同義になってしまうという
法解釈はあり得るかもと思ったり。
自分のFileTableは比較的自由に編集可能という事にすれば
フォーマットしたデータを勝手に持ち出された形になって一応言い訳は立つかな？
まあどっちにしろ踏み込まれたらアウトな訳だけど、ローカルで立証されない限り
外部から公衆送信権の侵害を証明するのはほぼ不可能な悪寒。

前々スレぐらいで見かけたこの意見が一番現実的じゃないか？

91 ：[名無し]さん(bin+cue).rar ：03/11/30 19:37 ID:zsFAGLf1
>>89
> 時間がかかるのが難点か？

バイナリを壊すのは、部分部分で破壊すれば良し。
一つのファイルの中で、"何カ所か"を「数ビット・数バイト」程度ずつ"ランダムで乱数上書き"する。

それが「ファイル内のヘッダ部」か、「データ部の中間をランダムで選ぶ」のか
どちらでも良いのだけど。

ISDN・電話回線にはキー情報だけを
中継させればいいだけじゃん？
ファイルは高速回線だけとかさ。

>>611
たすかに。
留守中に襲われたら死ぬが。

>>610
んで、自ファイルの名前等の情報放流時に全てがバレバレになるシステムが
どの程度魅力あるのかを説明しとくれ。
それとも何か細工があるの？この辺の詳しい説明が無いのでわからん。

>>610
http://citeseer.nj.nec.com/stoica02chord.html

>>610
http://www.google.com/search?num=100&hl=ja&lr=lang_ja&q=consistent+hash+SHA1
このトップにヒントがある。
再発明はやめよう。

>>610
ひとっ風呂浴びてきたらいきなり自分でアラに気付く。
自FileTableにない場合のみ検索キーを飛ばすのでは同名ファイルの検索ができんなｗ。
やはり検索キーは常に飛ばす必要があるか。
ファイル名、ハッシュのみでアドレス情報を持たない空のFileTableをまず伝播させんといかんね。
これなら>>292で言う存在は保証するがブロックの保証はしないっつー形になるかな。

>>606
むしろ光だけで実験的なネットワーク作ってみてほすい。
俺ADSLだけどさ。

>>614>>615
�dクス
ざっと読ませていただきました。勉強になります。
この場合トリガは完全なデータを持ったFileTableという事になるのかな。
いや、違うかファイルそのものを返してもいいんだ。

いっきに読んだんで頭がグルグルしてて意味不明な事いってるかも。
なかなかエキサイティング。

低速にも優しいWinnyだったが、
次期P2Pが出来たらWinMX含め３極化するのかな。

的が外れてたらすまん。

まず空のFileTableを広く伝播させファイルの存在を保証する。
FileTableを元にダウンロードクエリを発行。
PeerCQによってファイル断片を検索しつつ要求ノードに送信。

ということか。どえらいシンプルだ。ちょっと明日早いので寝ます。
面白かった。あり。

MX ny oz この3つを使って初めて1つのファイルにできるとか（�_

ここの、みなさんもドロシーの動向には気になってるのね。
レス止まってるし。

ここは仕様を考えるスレという事で……

ちょっとドロシーの方は祭りでどうしようも無い状態だね。
ただ、気になるのがny1のインターフェイス変えただけな気がする。
ここのスレ住人できちんと検証しないと危ないのでは？
漏れはスキルがないから出来ないのでお願いします。

こんな感じにまとめてみまつた
ttp://poststuff.entensity.net/112603/mario.php

って、ただのコラだったｗ
久しぶりの大ネタだったみたいですね。
でも、これでスレも下がったし、やりやすくなったかな？

FileTableはハッシュ＋ファイル名＋容量＋寿命のデータしか持たせない。P2Pネットワーク内に
探すファイルの「存在可能性」を通知するだけだから。
どっかで出てたがノードを多角形メッシュ状に接続する方式だとFileTableの同期はそれほど時間
かからないはず。

仮に自分がファイルの最初の放流者になろうとしていてその通知をアップしても、FileTable経由で
その通知を知ったノードはその通知が中継されたものなのか最初の放流者の情報なのかは区別が
つかないでしょ。もう一回言うがあくまでここではFileTable経由で「ファイル存在の可能性」を通知し
てるだけ。

実際の検索もメッシュとして配置されたノードに対してFileTableから取得したハッシュベースで検索
をかける。検索通知を受けたノードは自分のoexファイルリストの中に一致するハッシュを持つものが
あれば応答する。しかし応答者が最初の放流者であった場合はoex素片を生成して放流する必要が
あるが、最初のダウソ要求だしてるところへ直接転送するのはあぶないから、ここではじめて分散化
を始める。

分散化手法は前に述べられてるので割愛するとして、最初の放流者は隣接ノードと通信して拠出
ディスクの使用率が閾値以下のところへひとつのブロックだけ放出する。隣接で閾値以下のノード
が見つからなければその先も調べていき、最終的にoexをさらに分割したブロックがすべて転送完了
するまでこの動作は繰り返される。

ダウソ側はnyみたく定期的に検索ハッシュを行って応答を待つだけだが、ダウソ行為は冗長化じゃな
いのでローカルディスクのダウソ作業専用フォルダへの書き込む。

話を戻して分散化が始まったときだろうが、途中の冗長化時だろうがブロックを受け取った側は何を受
け取っているのかわからないし、その動作が最初の放流によるものなのかどうかはわからない（厳密
にはオブジェクト化するのでダンプすればわかるが、初期値を変動性にすればわからなくなる）。また
受け取った素片をどっかからの要求に応答して送信してもそれが、復元のためのダウソなのか冗長化
のためのダウソなのかわからない。

冗長化の管理はoexの細分化ブロックをオブジェクトラップして扱うことで自律的に行う。具体案は検討中。

突っ込みよろすく。今日は酒飲んでないからキレ無い。

明日は早朝会議なのでもう寝る。
だれかエロイやつぁ朝までに突っ込んどいてくれ。
また考える。

>611
うぎゃぁぁぁぁ俺のへタレアイディア晒すのやめて…( ﾉД`)

ここは実装以前の仕様を決めるスレでつよ。

釣り宣言きました。wikiにある37氏語録消したがいいかも？

Dorothyなんて作ってねぇし。(ﾟ∀ﾟ)
http://tmp2.2ch.net/test/read.cgi/download/1070383446/

３７氏は本当にネタだったのか？
結局、開発してるのって誰がいるんだ？

おまえらが仕様考えてどうすんだよ(；´Д｀)

だから、誰も開発なんてしてないし、やろうともしてないし、出来ないって

この板に47みたいな人間はもういないって

お前ら、アホ過ぎ

47よ。魂の深き闇の果てに…。

>>634
あなたの言うとおりです
誰も開発してません
だから上げないでください

彗星のごとく、突然に

とか期待しても無駄

本当に無駄、それを否定したいなら君が作るしか無い

でも、君は作ることはおろか、作ろうともしないだろうな

だって、君はただの阿呆だもの

だれも開発してないというか、いい仕様が決まらんことには動きようがない。
Winnyの次な動きは以前からあったが、結局立ち消えになったし。

デバッグにプライベートな時間も割かれるんだよな
全てボランティアになるし・・・
仲間内でヒッソリならFTPでも良いしHOTLINEでもいいし
特定の人間同士ならP2P MessengerかDirect Connectで良いし

既にプロトタイプを3つほど作ってしまったYo
残念だけど47にはもう期待できねーし。まともに作れているやついなそうなのので
仕方なく作っている。だって俺nyをよく利用してるしね。
nyソースが出る危険性もあるし、もし流出してしまったらクラックに溢れ死滅は時間の問題。
公開はny2に[P2P]をファイル名の最初につけて流すのでヨロ。

今悩んでいることは、始めのノードをどのように公開するかだな。
自分のノード１つ公開するのは自殺行為だし、10個くらいノードが集まった時点で
動き出すというのもいいかもしれないけど、ある方法を使えば誤魔化せるし。
何かよさげな方法はないでつか?

□□□□■□□□□□■□□□□□□□□□□□□□□□□□□□□□
□□□■■□□□□□■□□□□□□□■■■■■■■■■■■■□□
□□■■□□□□□■■■■■■□□□□□□□□□□□□□■■□□
□■■□□■□□□■□□□□■□□□□□□□□□□□□■■□□□
□□■□■■□□■■■□□■■□□□□□□□□□□□■■□□□□
□□□■■□□■■□■■■■□□□□□□□□□□□■■□□□□□
□□■■□□□□□□□■■□□□□□□□□□□□■■□□□□□□
□□■□□□■□□□■■■■□□□□□□□□□□■□□□□□□□
□■■■■■■□□■■□□■■□□□□□□□□□■□□□□□□□
□□□□■□□□■■□□□□■■□□□□□□□□■□□□□□□□
□□■□■□■□□□□■■□□□□□□□□□□□■□□□□□□□
□□■□■□■□□□□□■■□□□□□□□□□□■□□□□□□□
□■■□■□■□□□□□□□□□□□□□□□□□■□□□□□□□
□■□□■□□□□■■■□□□□□□□□□□□□■□□□□□□□
□□□□■□□□□□□■■■□□□□□□□□□□■□□□□□□□
□□□□■□□□□□□□□■■□□□□□□■■■■□□□□□□□

少なくともドロシーの画面見た瞬間にネタと見抜けなかった
人間は、開発など無理

うちの冷蔵庫ん中に
ソースあったよ

さあ、このスレこれからお世話になるからよ。
よろしくな。
荒らしていくぞ。

>>644
荒らすなｗ

まあまあ皆、ﾏﾀｰﾘ逝こうよ
流れを見極めるのも大切だし

オープンソースで荒らしていこうと思うから、よろしくな。

>>640
とりあえずfreenet

>>640
ny2使うんなら、どこぞの廃墟スレ乗っ取れば？
書く分には匿名性高いし、物好き多いから自ノードさらしてくれる人もいるんじゃない。
暗号化はny形式みたいな適当なのでいいし(固定でなければ危険性は低くなるし)

こういうのを「誰か」に作ってほしいって言ってるだけだろお前ら。
自分じゃ作りたくないってのが本音ｗ

>>640
nyはソース押収されちゃったしどんな危険があるか分からんから
Freenetとか匿名端末(無線Lanとか)からうｐろだにうｐとかにしたほうがいいよ。
家宅捜索は嫌でしょ。

ID:R83wNSRg 削除・アクセス禁止希望

より安全なのはネットカフェで数人をつなぐ。
その後はそのソフト内でtxtでノードリストを流通させ
たまに誰かがどこかに貼る。

>>651
そっちより安全。

>>650
はっきり言ってしまうとな
早い話がめんどいのよ
作れと言われてボランティアでやる事ほどつまらない事はない

全て自分のアイデアだけで自分の好きな様に作れるんなら考えるけどな

>>655
俺もそう思う。自分で好きなように作れるからやる気がでるのであって、仕様書が完全に決まってたら作る気になるプログラマーなんていないだろ。

オープンソースにしてちょこちょこ作っていくならともかくな。

まぁ実際に作る香具師と（自称）作れる香具師の違いは簡単なわけだが

RAID5案は違法うんぬん抜きにして単純に学術目的で実現可能なのか興味ある。

おれは好き勝手に作ってるやつがたまにココみて少しでも「お、この考え方は使えそう」と思って
くれればいいや。と思って一応プログラマの観点から意見書いてる。
もちろん相手にされてないかもしれないけどそれはそれでいい。
実は発表できるほどのものじゃないがちょこちょこメモ感覚でプログラム書いてるし、ここの
意見もいくつか参考にしている。ちなみ遊びで書いているので「すげー」物が出来上がらない
かぎり全く公表する意志は無いのであしからず。

>>659
別にそれでいいと思うよ
がんがってくらはい

誰もが参加出来る場所で、話し合う事に大きな意義があるんだよ。

絶対に「アイディアを貯めてるだけ」で作れない/作れない人が居るのは確実で、
そんな中には有益な意見もあるのだから、色々な人に意見を聞くべきだと思う。
最終的に、マージもフィードバックも出来るからね。

# 仕様が出来ても、コーディングの面白さは充分あると思う。
# ここで決めたいのは"核を成す部分だけ"だから。
# とは言っても、仕事じゃないから、誰も仕様通りに作る事は要求しないので、
# 多少の独自拡張もアルゴリズムの改良も良いし。

複数種出来ても、最終的には相互接続できる事を目標に…　なんて考え甘すぎるかな。

例を挙げるとすれば、Mailerだってそうでしょ？あれも規格が決まってるから。
ブラウザだってそう言えるし、広く言えばAPIもMFCも、言語だって規格や仕様は
決まっていて、その制限や自由の中で組むから面白さがあるんだと思える。

仕事だとコーディング規約等に縛られて、面白さやアイディアが半減しちゃう事もあるけどさ。

＞661
ここでそれを決めるにはノイズが多すぎる。
このスレの中盤とか言語がどうだとかくだらない話ばっかだし。
素人は黙ってろっての。

どうやって匿名にするかなどは設計を煮詰めないとだめだが
ファイルをやり取りするというところはどんなファイル共有ソフトでも
同じようなプログラムになっちゃうんでｎｙみたいなものをとりあえず
作っちゃってから改造したほうが早いと思うぞ。

ｎｙ同様、まずは各パーツからだな。

>どっかで出てたがノードを多角形メッシュ状に接続する方式だとFileTableの同期はそれほど時間
かからないはず。

結局RAID5マンもド素人かよ（;´Д｀）

P2Pに過剰な匿名性が果たして必要なものなのだろうか？

>>664
結局、それなんだよな。
もっとマクロな議論をするべきなのに、どうしても話が実装詳細へと流れていく。
話す側は結局自分がちやほやされたいだけで、
持ち上げる側は新しい実装への期待を無意味に膨らませているだけ。
最近神がずいぶん安易なものになった気がするよ。

>>665
平面正方形メッシュじゃなくて立方体メッシュで計算してるか？
LRFBUDの６方向だぞ？

突っ込む側ももド素人かよ（;´Д｀）
ちゃんと数学の先生の話を聞いてましたかぁ？

>>667
はいはいそうだね。
ここは討論の場所でここからネ申が出てくると思うほうが間違い。
ネ申はここも横目でみつつ自分で実装するからアンタの発言は無意味。

>>668
あのさ。
もうそれ以上披露しなくていいよ。
立方体って中学生かよ。
n次元トーラスだろ。

前スレ中盤であった匿名掲示板の話題はここでいいのかな？
P2PNetNewsと言うアイデアをこんな感じで考えてみた。

・発言データは1発言ごとに固有のハッシュ値を与える
・スレ立てはカテゴリ情報を持った新規発言という形
・レスは親発言のハッシュを上位に持つ子発言という扱い。孫発言もアリ
・スレッド内の時系列の保証はしない。一応最も古いタイムスタンプを信じる
・流通したデータはローカルにどんどん蓄積
・スレッド管理、発言のあぼーん等はローカルで行う(2ch専用ブラウザのイメージ）

当然古いレスを新しいレスより後に拾う場合もあるが、元発言へのレスである事は変わらないので気にしない。
タイムスタンプについても同様で、子発言は親発言より新しいという事以外は参考程度と考える。
親発言に関してはカテゴリを選んだ時点で自動的に検索＆隣接ノードに適当に送りつけ。
所詮掲示板の情報などたかが知れてるのであっという間に拡散して発言元ノードの特定はまず無理。

糞スレ乱立タマランという状況になるのは目に見えているので、
各ノードからの糞スレチェックとレス数で評価して不人気スレはリストから見えなくする。
もちろんローカルでの保持は可能なのでハッシュ指定して検索かければ引っ張ってくる事は可能。

みたいなイメージなんだけど、問題点は何かあるかな。
発言者の同一性保証はしない方向を想定。自己主張の激しい人は勝手になのれば？のスタンス
別にMACアドレス辺りを種に十分な強度のトリップ付けることは出来るだろうけど
発言と発言者の対応が取れてしまうとチリツモで発信ノードを推定され得るでしょうし。
あと「嘘を嘘と見抜けない人は」的な、
ID・トリップ実装以前の2chの雰囲気もアリだよね、という気分もあったり。

勢いで書いたのでヒジョーに雑だと思うけど、突っ込みヨロン。

RAID5案の、secret sharingを神の匿名性確保に応用というアイデア自体、は悪くないのだが
xorとか言い出すあたりが素人だな。
secret sharingとかVSSとかでググルだけでRAID5方式を遥かに上回る技術がザクザク出てくるのだが。
xorじゃ30年前の技術の再発明だな。

しかも既にRAID5案以上のものが実装されていてライブラリもある。
ttp://www.google.co.jp/search?hl=ja&ie=UTF-8&oe=UTF-8&q=secret+sharing+library+C+C%2B%2B&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=

本当に次期P2Pソフトを作る気があるなら、この手のライブラリや、世界的な技術や知識の蓄積を
どんどん利用しないとまともなものはできないぞ。

>672
言いたいことはわかるけど理想論だろ
最新バージョンと決めて作成しても リリース時期には次のバージョンが出てるのが
現実なんだし
王道より最新を選ぶのは趣味でやるときだけ

>>673
>王道より最新を選ぶのは趣味でやるときだけ

これは合意できるけど、ライブラリを使わない理由にはなっていない。
currentやベータを使わずに、stableやリリースを使えば良いだけ。

リリース時期にライブラリの次バージョンが出ても、よほどクリティカルなバグフィックスが含まれていない限り、
設計時に決定したバージョンのライブラリを使えばOK。

絵に書いた餅は誰も求めてないよ
とりあえず食えればいいんだよ
それよりうまいものがあれば別だけど

じゃぁ大英帝国語としーぷらぷらがわかるエロイ>>672が実装すればいいじゃん

>>674
ライブラリ使うのは確かに正しい解のひとつだけど、
作る人の目的が単なるアプリケーションの構築ではなく、
作ることそのものだとしたら全部自分でやりたいってのも、
それはそれで間違いではないだろう。

漏れのサル並みの脳みそで>>672のCrypto++の概要読んだけど
たんなる暗号化ライブラリにしかみえんのだが。
ＲＡＩＤ系の分散化とどう関係するのか解説してくれエロイひと

>>672のサイトに
Shamir's secret sharing scheme and Rabin's information dispersal algorithm (IDA)
って書いてある。

そろそろ秋敵他鴨。

http://www.kono.cis.iwate-u.ac.jp/~nisitani/proj4/Theses/98-3b.html

これでラビンて香具師の概要が語られてるな。ちょっと原文をがんがって読んでみる。

>>678
もうちょっと親切に言ってみるテスト。
secret sharing scheme
秘密分散法
で、それぞれ日本語チェックボックスオンでググってみるべし。

秘密分散法に基づいたオープンネットワークRAIDの提案
なんていうそのまんまの論文もでてくる。
読んでみたいが論文の本文が見つからない。

IDAの論文はメンバー登録しないとPDF閲覧できねぇっぽいな。
VSSの方はいま読んでるけど確かにRAID5マンの提案より洗練されてるな。
論文本体探すわ。

http://www.kochi-tech.ac.jp/library/ron/2002/g5/info/1055115.pdf

いい論文みつけた。これなら理解できる。
エロイ>>672ヒントサンクス

これ？
http://www.sfc.wide.ad.jp/kg/neco/wiki/survey/%C8%EB%CC%A9%CA%AC%BB%B6%CB%A1%A4%CB%A4%E8%A4%EB%C6%BF%CC%BE%C4%CC%BF%AE.html

秋田鴨とか言いながらさらに追加。

多段中継、複数経路中継など、中継を考えるなら、以下から辿ってゲットできる文献も参考になる。
http://www.cs.dartmouth.edu/~zhaom/research/marianas/resource.html

どこかP2P関連技術情報まとめたとこないですか？

みんなで一斉に古いバージョンNy使うってのはどう？
Winny2.0 b58とか

>>683
Shamirの(k,n)しきい値秘密分散法って復号化にえらく時間が掛かってるね。
1MBのファイルに48秒じゃ使い物にならないよ。

暗号化の実装なんか後からいくらでも変えれるんじゃないの？
何でも最初はHelloWoldというか
とりあえずP2Pの基本的なものができてないと

>>688
計算機のスペックは？
それとパラメータを変化させてもダメ？
目的は神の匿名性なので、データ自体の暗号化、平文化が多少弱くなってもスピード重視してもいいかもな。

古典的な方法だけど、DESで高速に全体を暗号化して、DESの鍵だけを遅いRSAで安全性を高めるとかいう手もあるけど、
この方法は今回そのまま適用できないけど、同様に複数の符号化手法の組み合わせで高速化できないものだろうか…

>>688
これってk=2なら
ダウンロード完了までの転送量が通常の２倍だよね・・・

>>688

FILE1をP1,P2,P3,P4に分ける。これは単に分割するだけ。
P1をさらにP11,P12,P13...とShamirで分ける。
P2も同様にP21,P22,P23...とShamirで分ける。

P2のパーツをダウンロードしている間にP1を複合化。
CPUのパイプラインみたいなもの。
これで一応時間かせげる。
最後のパーツの複合時間をどうしようか。

閾値分散法ってのはちょっと数学レベルが高すぎてイメージしにくいな。
動作概念はわかったからCrypto++で試しにファイルからシェア？を作成して
それをもとにファイルを復元するプログラムでテストしてみるべ。
ただなんとなくえらくコストの高い処理だと感じるな〜

閾値分散法風に言えばつまりはRAID5だと実際のデータSを構成する要素
がn1,n2,x1て3つ（分割数）あってそのうち二つ（閾値2）そろえば元のデータS
を復元できるってことになるよね？
んで、shamirﾀｿが提唱しているのはデータSからたとえば5個のブロックを
作成してそのうち3つ集まれば、元のデータSが復元できるって言ってるん
だよね？

>>693
実現してもあまり効率化にはつながらない気がする。
復元できなくなる危険性の回避より、効率のほうが重要。
一番重要なのは，いかにネットワーク上に流すデータ量を減らすかだ。

MXの次はなんなんだ？　Part165
http://winny.info/2ch/main/1058199380.html

51 名前： 47 ◆KbtLZwerNc [sage] 投稿日： 03/07/15 01:57 ID:hsfdr3mD

匿名性がまた話題になっているようですが、nyの匿名性に暗号はほぼ関係ありません。
もしWinnyのソースを全て公開して暗号を全て取り除いた状態でもnyの匿名性は変わりません。

通信内容、キャッシュなどを全て解析しても匿名性は保たれように設計されています。
Winnyの匿名性の肝は転送動作であって暗号ではないからです。

わざわざ各所を暗号化したり本体の改造を困難にしたり、通信内容を暗号化しているのは
単に解析を困難にさせるためです。そして、なぜ解析を困難にするかというと、
解析されて改造されるとファイル共有効率が落ちるからです
（ただ、キャッシュの暗号化は管理責任の問題があるかな？）

あと、Winnyが起動されているノード情報はもちろんTCPでコネクション繋いでいる以上
ログを取れば判明しますが、これは初期ノードリスト解析することと同じことです。

ここは一番暗号の弱いところで解析されてもほとんど影響の無い部分です。
初期ノードを暗号化しているのは気分的な問題（公開の際の心理的影響考慮）であって、
ここはデコードされてもほぼ匿名性に影響ないと思います。
それでわかるのはそこでnyが起動されているということだけですので

http://www.eskimo.com/~weidai/pipenet.txt

やっぱ閾値分散法はダメかも。俺の理解不足かも知れんけど
シェアの数を増やせば復元可能性は高くなるけどその分
うぷ量は増えちゃうし、ダウソも最低２必要だからトラフィックが
増えすぎるような希ガス。
むずかしいねぇ。でも勉強になた。論文は面白い。

>>693
そんなん言うとまた話がループしだしそうだが・・

結局アイディア別に数パターンソフトを作って一番良いのを。
みたいのが理想だけど作者の負担が半端じゃないしなぁ(7割完成しなそうだし)

ミス
>>694か。

>>695
暗号化ってあんまり重要じゃないのかな？
今回逮捕されたのって転送がうまく働いてなくて一人から全部DLできたから逮捕されたんだろうか。

IPアドレスは暗号化できないから
誰が何のファイル持ってるか、実際に落としてみれば簡単にわかる。

閾値分散のソースダウンロードして試してみたよ。

Pentium3 850MHzのPCで、
1.6Mbyteのファイルを5個に分けて3つで復元できるようにする、
というのをやってみた。

結果。
計算時間は47秒、
3.2Mbyteのファイルが5個。つまり転送すべきデータは16Mbyteになった。

このままじゃダメだな。こりゃ。

>>702
補足。

復号化もためしてみた。
5個に分割したファイルのうちランダムに３つ選んで複合してみた。

1.6Mbyteのファイルが復号されるためには、3.2Mbyteのファイルが3つ、つまり、9.6Mbyteの
元データが必要で、復号に要する時間は
52秒。

何のためにP2P使ってるか全然理解してない香具師

>>702-703
分割したヤツ合計で元の１〜２倍くらいかな〜と思ってたが、
そんなにデカくなるのかｗ

>>705
漏れも理解できてないのだけど、どうやら元ファイルと同じかそれ以下にする
アルゴリズムもあるらしいね。

分割ファイルを、他の分割ファイルと抱き合わせで１セットにする。
これなら偶然の一致でファイルが完成しただけの理屈になる。
初期放流（A）であっても、他のファイル（B)と結合して拡散するわけで
１本釣りのK対策にもなる。
問題は捏造。

とりあえずnyのソースがあれば、というかUNIXに解析完了した香具師がいるみたいなんで、
そいつにちょこっと仕様弄ってもらえばいいのではないかと。
弄るトコは「UpもDownも必ず転送を噛ます」ようにするのみで。

これで別に警察が解析終わってようがIPの秘匿性はほぼカンペキ(少しもさーっと動くだろうけどw)
転送先の元を調べるには転送者のPCにハッキングしかけねーといけねぇ。
つまり、法がファイル送信元を守ってくれる(てことは散々既出ですね、わかってます)

このバージョンを一つ作った上で、更にキャッシュそのものの秘匿性まで高めたいのなら、
今みなさんがやってる「分断化」を後で取り入れたらいい。

で、転送を必ず噛ますバージョンを作ってしまえばあとはオープンソースでいいのでは?
クラックっても、直接ファィル送信元に繋がりに行くようなクラックは出来ないでしょ。
ny2もクラックバージョン出たけどny1のように完全にUpをカットするようなことは出来なかった。

だからとにかくソースコードが欲しいですねny2の。
誰にとは云わないが持ってる方、自分で仕様変更できないなら晒してください。
ハカー御用達の「あそこ」で待ってます。Free as a board

今回の敗因は作者の身元が割れた。ってことに尽きると思う。
もしも47氏の匿名性が保たれていたとしたら、今頃対策をしてくれてただろう。
そして、問題なくｎｙネットワークは動いてたはず。

これを踏まえて次期P2Pはまず第一に作者の身元が絶対にばれないようにする。
次にシステムはｎｙのままでよくて、必ず中継が起こるようにする。
これだけで十分だと思う。あまり複雑なシステムだと効率を上げるのは大変。
47氏だってｎｙネットワークの効率を上げるために1年近くも時間を費やした。
匿名性を得たかったらfreenetに行けばいいんだが効率が悪すぎて使いものにならない。
これじゃ本末転倒。

つかね、製作者の身元がばれないようなファイルの公開の仕方なんて、
ハカーなら誰でも知ってるから心配無用なのも散々既出。

>>708-709
で、中継ノードなら逮捕されないのかよ、
中継ノードでも著作物を送信可能な状態にしてるだろ、
っていうツッコミが今までに何度か入っています。

>>711
でも今のところ逮捕されてないっぽい。
可能性は無いわけじゃないが。

>>711
違法ファイルの転送に使うのが前提ならそうなるね。
しかし、基本的にユーザは違法ファイルが流れているなんて気がつかないだろ？
「てっきりポエムが流れているものとばかり思っていました。」と言えるw

プロバイダが逮捕されないのと同等だろっと言ってみるテスト。

暗号化ルーチン作成中。

>>711
そこはグレーでしょ。そこに手を出すには警察もかなりチャレンジャーしないといけない。
もちろんキャッシュを分散してしまうやり方はグットなアイデアですから進めるべきで
素晴らしいことだ。是非実現して欲しいとｵﾓｳ。
しかしとりあえずは、nyで４７氏が自信満々だった「転送」の甘さがどうやら今回の捜査で
利用されたというのが大方の見方ですから、まずはここを弄って反応が見たいというのがある。

一からプログラム書くのってめんどうでしょ?それよりも出来てるものを弄ったほうが早いし
参加できるスキル保持者もぐっと増えるよ。

と、友達のスーパーハカーがいってたということにしとく。

中継は逮捕されないでしょ。プロキシが逮捕されないんだから。
で、プロキシは違法目的じゃない、P2Pは違法目的で作られたから駄目ってことでしょ。
だったらP2Pの存在意義を定義すれば良いんじゃない？フリーネットみたいな宣誓書でも同封して。

だから、ソースにしてもバイナリにしても、流すのはfreenet経由にすれば、とりあえず作者の安全は保たれるだろう。
本来freenetはこういう警察や国家権力の横暴に大して抵抗するためのツールなのだから、正しい使い方と思われ。

４７氏がここを見てたら、頼みがある。
もし警察にソースを押収されたのなら、クローズしてる意味はありません。
P2P技術の発展の為にもソースを公開してちょ。

うっかり誰かに送信してw

お願い。

>>713
広域ファイルシステムアプリケーションにすればいいんだよ。
目的は、医療におけるカルテなどが災害時に紛失しないための、
広域分散冗長的ファイルシステム。さらにセキュリティを考慮したアクセス制御機能付き。

それで、ファイルを置く際にはダイアログ出して、「このファイルを不特定多数で共有しますか？ はい いいえ」
で、はい、を選んだらさらにダイアログ出して「このファイルは著作権を侵害していませんか？ はい いいえ」

中継者は、医療等を目的とした重要なファイルが大地震などの自然災害によって
なくならないために協力していた、ということになる。

>>702
検証乙！家に帰ったらやろうと思ったら先にやってる人がいたｗ
つぅかそこまで元ファイルデカクなるんじゃ使い物にならない悪寒。

アップダウンの機能を削除して、中継だけ行うノード、のアプリケーションがあってもいいかもな。
常時接続で立ち上げっ放しにしている香具師の余ってるネットワーク帯域を使わせてもらう。
スクリーンセーバーで、余ってるCPU資源使って、宇宙人探したり癌の薬計算したりするのと基本的に同じ。

インストールされている状態で、しばらく入力がなかったら自動的に利用帯域を増やす。
スクリーンセーバーの機能で、「今あなたのPCは 123 ペタバイトの共有HDDの一部です」とか表示して
エンターテイメント性を高めて、参加意欲をくすぐれば参加者も増えるかもしれない。

>>721
さんざんいわれてることだが、中継専用ノードのソフトをウイルス化して配りまくるべきだな。

低速にも優しいP2Pを

>>719
＞目的は、医療におけるカルテなどが災害時に紛失しないための、
セキュリティに気をつけてということなんだろうが勘弁して欲しいなと思うぞ。

>>721
中継、転送専用ソフトｲｲ。
用はnyにキャッシュ上限を設けて１０ギガ以上は自動削除、
んで、検索機能を剥ぎ取る。これでいいんだ。
ついでにキャッシュを止めて生で流通させる。

そしてこれとは別にファイルを検索するソフトと暗号化したり復号化したりするソフトを
作ればいい。
ん?このアイデア、既に出てたような、、、吊ってきます

>>722
だからウィルスは・・
ttp://www.ipa.go.jp/security/virus/faq/qa_a.html#7-1

仕様サイトでこんなことを言っては何ですが、
P2Pを作ろうスレ
とか言うの立てた実際に動かしていってみてはどうでしょう？

>>727
プログラマー板とかで立てれば作ってくれる人もいるかもしれんが、とにかく今は仕様を固めるのが先。

吊る前に今のまとめておきます。

A・中継転送専用P2Pソフト
これはいわば、P2Pネットワーク内の各PCのHDが「自動的にファイルをやり取りし続けるシステム」
流されるファイルは標準で暗号されているがこのソフトでは復号化できない。
超流動的なプロクシサーバーのようなものな上に暗号化しているから違法性を問うのは難しい。

B・Aに流通しているファイルを検索しファイルの標準暗号化を解くソフト。
一般利用向き。

C・Aに流通しているファイルに様々な暗号をかけるソフト。
商用利用が可能。


では吊ってきます。

winnyクローン作るってなったら作る人結構いるんじゃない？
仕様はもう決まってるし。47氏の過去ログもあるし。

>>718
それやっちゃうと、クラック版より凶悪なソフトが出るんじゃ……。

Dorothyのスクリーンショットどこにあるのか教えてくれー

>>732
おれのPCの「ゴミ箱」の中。

>>732
グランドライン

DOM対策に次期P2PソフトでDOM版を作るってのはどう？
ただしDOM版は中継ばっかりやらすとか速度が出ないようにするとかの制限かける
で、通常版はそれらの制限が無い代わりにキャッシュを削除したらあぼーんなどの
DOMが使用しないような対策をする。どうかな？

>>735
専用作らなくても、中継してないと落とせない仕組みにすればいいんでない？

>>735
速攻でDOM版が苦楽される予感

昔、キャッシュを保存する際に仮想ディスクをローカルに作って
そこに保存するという案があった。何となくおもしろそうなので
ディスクイメージを分割できるようにして作ってみると、
仮想ディスクがフラグメントしていない状態＆HDD3台にイメージを分割で
通常の1.5倍のスピードで書き込み／読み込みが出来たｗ
はぁ、２時間無駄にした。

freenetかny2に
中継・分割・キャッシュ完全のみ変換・キャッシュ高速破壊

これつければもういいだろ。

>>739
freenetはともかく、ソースの公開されてないny2にどうやって機能追加をするんだ？
一から作るのと変わらないだろうに。

47氏がひょっこり出てきて>>739のようなｎｙ3を発表。
ｎｙ2との互換性はありませんってな事になったら祭りだな。

次期P2Pに対する要望スレ
http://tmp2.2ch.net/test/read.cgi/download/1070085137/151-152
こんなことを要望スレに書いたんだけど、
誰かまじめに考えてくれないだろうか。
ｎｙを正当進化させるベクトルもいいんだけど別のベクトルのソフトがあってもいいのではないかと思い
カキコした。
いわばローカル交換をやりやすくするソフト＋合法ファイル共有P2Pネットワーク（＋できればIMとBBS付き）
といったところ。
Ny,ICQ、MX、FTPのいいとこどりをした感じのソフト。
ヤバイファイルがあったとしてもそれらのファイルリストすら知らない人に公開しなければ(もちろん知らなければ落とす事もできん）
何の問題もないっしょ？どう？

>>742
匿名性が綺麗に消えるわけだが・・・
てか、自宅でFTP鯖作ってここで身内とやらを探して、IMとやらをすればいいだけのことのような…
で、パブリックと身内は設定で(ry
わざわざつくら(ry




･・・・まぁ、何ていうか･･･ｶﾞﾝｶﾞﾚ。

>>729
方針を示すという意味で良い感じではあるが、
それだと流通時のトラフィックが酷く増える。現実的じゃないな。
光じゃないと無理っぽいし。

また指定されたA,B,Cだけだとうまく機能しない。
ファイルの情報を管理する何かが必要なんじゃないか？
それとも本末転倒な事に、暗号化されたファイルへ
複合キーやらハッシュやらを全部付属させるのかい？

あとCが良く判らん。暗号化されたファイルをさらに暗号化するということか？

>>744
Cは通常のファイルを流せる形に暗号化する、ってことじゃないの？

話題がループしてるよ〜もう読むの耐えられないよ〜

＞今のところ逮捕されてないっぽい

「今のところ」とか「ぽい」とか、そんな言葉を使う人間に、厳密な仕様が
作れるとは到底思えないよ。このスレのルールは、安全側で行こうなの！

＞基本的にユーザは違法ファイルが流れているなんて気がつかないだろ

そんな言い訳が、Kに通用するとお思いですか？

＞中継は逮捕されないでしょ。プロキシが逮捕されないんだから

包丁と人殺しの道具の話は知ってるよね？
プロキシは包丁側ではないかな？

＞４７氏がここを見てたら、頼みがある。
＞もし警察にソースを押収されたのなら、クローズしてる意味はありません。
＞P2P技術の発展の為にもソースを公開してちょ

Winnyはクラック耐性の設計になっていませんが？

＞さんざんいわれてることだが、中継専用ノードのソフトをウイルス化して配りまくるべきだな

さんざんいわれてると分かってるなら、なぜ過去にウイルス案が却下されたのかは分かるな？

・UPフォルダの概念を無くし、UPファイルは常に暗号化・分割(1ブロックを復号しても意味を成さない
　形で)してキャッシュとして生成される。
・あるファイルの分割キャッシュがUPファイルとして投入、又はDL完了した等してある閾値以上同一
　ノードに存在する場合(当然、自ノードがDL中のファイルは除く)、強制的に他ノードにUP(中継さ
　せることにより複数コピーされる)して自ノード分は削除、DL要求された物に関しても同様にする事
　によりキャッシュをネットワーク内で分散・流動化させる。
・分割キャッシュをUPすることにより安全性が高まる為、UP0クラックを防ぐ事が可能。

効率考えたら、こんなモンで十分だと思うが。
ただ、これでパクられないかっつーと、られる可能性は高い。
が、これで立件される場合、多人数・自分の知らない物で逮捕される可能性が高い為、略式起訴
ではなく裁判になり捜査手法や判例が明らかになる可能性がある。
その時こそ著作権の有り方を真面目に日本社会が考え始めるきっかけになるんじゃないかと…

>>746
いいからスルーしろよ。長文で文句書くほうがよっぽどウザい。

>>743
うん、そう。匿名性ぶっちゃけいらない。

それよりもFTP見たいに設定がえらい複雑で公開するのもえらいめんどくさいく、
しかもFTP鯖のソフトがフリーの奴でまともな日本語のソフトっつたらQuickFTPとかくらいで・・・
WarFTPｄはアップのレジュームききやがらんし・・・
まあ一つの案だけどさ・・・
FTPみたいに完璧に鯖主導なのはちょっといやだなとおもったりするんだよな。
おいらてきにはMXのUp０に標準ではファイルの検索がひっかからん、みたいなのがいい。
んー、まだ考え詰めてなかったけどIRCっぽいのもあってもいいかもなー
プロフィールを作っておいてユーザー検索はできたりとか。

匿名性いらないって話はスレ違いのような？

>>750
P2PBBSを作りたいって人じゃない？
前ももめたよ。それで

>>747
いいね。それに且つ、転送と中継を必ず噛ますようにして、IPが逆探知できないようにするのが
現状で望むべき仕様の総括ということでいいのでは?
↓開発ヨロ

>>749
新しいファイル配信ツｰル作るよ。
http://tmp2.2ch.net/test/read.cgi/download/1069291043/

nurupo

　 （　・∀・）　　　|　|　ｶﾞｯ
　と　　　　）　 　 |　|
　　 Ｙ　/ノ　　　 人
　　　 /　）　 　 < 　>__Λ∩
　 ＿/し'　／／. Ｖ｀Д´）/
　（＿フ彡　　　　　 　　/ 　←>>754

47氏は神様級。1人の誰かに2代目を任せるのは酷。
Winnyの仕様、実装はほぼ完璧。でなきゃMXを超えるか？

Winnyの弱点は初期ノードのアナウンスと開発者のリスクを分散しなかったこと。
後者はオープンソースしかないだろ。

Winnyの作り直しは次のWinnyになりうる。
WinnyだってGnutella+freenet

必要なのは
つかまりにくい使用方法の徹底
落したファイルは楽しんですぐ消す（キャッシュは残す）とか
それでもつかまった奴がいたら、暖かい笑顔で慰めてやる
そういう態度。
もし、オープンソースのWinnyを完成させて
5年程度この板の連中がそういう姿勢を貫けたら
ACCSは1ch.tvみたくなってるよ。

散々既出な事を偉そうに書く↑みたいなのはリアル池沼ですか？

とりあえずテンプレ嫁　　　っと。

まとめサイト
http://s2net.s41.xrea.com/
wiki
http://s2net.s41.xrea.com/P2PWiki/pukiwiki.php
を見て意味が解らん奴は書き込むな　　　　　　　　　　　　っと。

同意。
今は焦らず、じっくりつめてもらった方がいいと思う。
ACCSも個人情報流出があったから、カリカリしてるんじゃねーの。

>>757
>756
「俺は次のP2Pソフトを使いたい
　誰でもいいから早く作れ」
と言いたいだけだよ

>>753
THX。すれ違いだったか・・・・ごめんね。

「前スレ703」氏ってどうなりましたか？

Internetの樹
http://research.lumeta.com/ches/map/gallery/

Gnutellaの樹
http://www.faireal.net/articles/4/08/#d11203

いと美しきかな

中継・MD5などNyもどき(BBSは無い)のソースはある
VBだけど