51 เรื่องการป้องกันการโจมตีแบบน้ำท่วม

แปลโดย : Claude 3 Opus (Pro)

51

เรื่องการป้องกันการโจมตีแบบน้ำท่วม

ความกังวลที่หยิบยกในที่นี้เทียบเท่ากับการโจมตีแบบปฏิเสธการให้บริการบนเครือข่าย Bitcoin โดยที่หน่วยงานหนึ่งสามารถส่งธุรกรรมหลายล้านรายการ แต่ละรายการโอนจำนวนเงินเล็กน้อย เช่น 1 satoshi (0.00000001 BTC) เธรดนี้มีเนื้อหาทางเทคนิคมากกว่าเธรดอื่นๆ และไม่ได้คัดลอกโพสต์ทั้งหมดมาที่นี่ มีเพียงโพสต์ที่เกี่ยวข้องกับหัวข้อและโพสต์เกี่ยวกับข้อกังวลที่ Satoshi ได้กล่าวถึงเท่านั้น

การโจมตีน้ำท่วม 0.00000001 BC

โพสต์โดย Mionione, 12 กรกฎาคม 2010, 12:04:24 น.

สวัสดี จะเกิดอะไรขึ้นถ้ามีคนส่ง 0.00000001 BC หลายล้านรายการไปยังที่อยู่หลายล้านที่ครับ ?

=> โหนดเพียร์ทั้งหมดในเครือข่ายต้องเก็บธุรกรรมทั้งหมดไว้ใช่ไหม? => เจ้าของ/แฮชของ 0.00000001 แต่ละรายการถูกเก็บไว้ในบล็อกบนเพียร์ทุกตัวใช่ไหม?

ผมไม่ค่อยเข้าใจว่า Bitcoin จัดการกับเศษส่วนของ BC อย่างไร

Re: การโจมตีน้ำท่วม 0.00000001 BC

โพสต์โดย Gavin Andresen, 12 กรกฎาคม 2010, 12:08:45 น.

จากโค้ดต้นฉบับ:

main.h: // เพื่อจำกัดสแปมขยะ ต้องมีค่าธรรมเนียม 0.01 หากเอาต์พุตใดๆ น้อยกว่า 0.01

Re: การโจมตีน้ำท่วม 0.00000001 BC

โพสต์โดย llama, 12 กรกฎาคม 2010, 14:23:46 น.

หืม ผมไม่รู้มาก่อนว่ามีเรื่องนี้ และผมไม่ชอบวิธีการนี้เลย

มันทำลายความเป็นไปได้ที่ Bitcoin จะถูกใช้สำหรับการชำระเงินขนาดเล็กจริงๆ จะดีกว่าไหมถ้าไคลเอ็นต์เพียงแค่ละเว้น IP ที่เป็นสแปม? แน่นอนว่าผู้โจมตีอาจจะได้มากขึ้น แต่เขาก็คงไม่ได้เป็นล้านนะ

Re: การโจมตีน้ำท่วม 0.00000001 BC

โพสต์โดย Gavin Andresen, 12 กรกฎาคม 2010, 14:45:54 น.

แต่คุณจะแยกความแตกต่างระหว่าง IP ที่ประมวลผลการชำระเงินขนาดเล็กที่ถูกต้องตามกฎหมายกับ IP ของสแปม "ฉันอยากทำให้ Bitcoin ใช้แบนด์วิดท์มากเกินไปจนไม่มีใครยอมเปิดมันอีกต่อไป" ได้อย่างไร?

การชำระเงินขนาดเล็กมากๆ ดูเหมือนจะเป็นปัญหาที่ยากมากสำหรับผม และผมไม่คิดว่า Bitcoin ควรพยายามแก้ปัญหาที่ยากมากพร้อมๆ กันหลายเรื่องเกินไป

Re: การโจมตีน้ำท่วม 0.00000001 BC

โพสต์โดย Gavin Andresen, 12 กรกฎาคม 2010, 14:45:54 น.

แต่คุณจะแยกความแตกต่างระหว่าง IP ที่ประมวลผลการชำระเงินขนาดเล็กที่ถูกต้องตามกฎหมายกับ IP ของสแปม "ฉันอยากทำให้ Bitcoin ใช้แบนด์วิดท์มากเกินไปจนไม่มีใครยอมเปิดมันอีกต่อไป" ได้อย่างไร?

Re: การโจมตีน้ำท่วม 0.00000001 BC

โพสต์โดย Insti, 4 สิงหาคม 2010, 14:58:31 น.

สแปมขยะ ที่ค่าธรรมเนียมการทำธุรกรรม 0.01 BTC นี้ "แก้ไข" นั้นคืออะไรกันแน่? มันดูเหมือนจะสร้างความเสียหายมากกว่าความช่วยเหลือ เพราะมันขัดขวางการใช้งานการชำระเงินขนาดเล็กเช่นที่ bytemaster แนะนำ

ผมไม่ทราบว่าเครือข่ายกำลังเครียดกับปริมาณธุรกรรมที่มีอยู่ ใครก็ตามที่ต้องการส่งธุรกรรมจำนวนมาก ก็สามารถทำได้แล้วโดยการส่ง x BTC ไปให้ตัวเองหลายครั้ง

Re: การโจมตีน้ำท่วม 0.00000001 BC

โพสต์โดย satoshi, 4 สิงหาคม 2010, 16:25:36 น.

อ้างอิงจาก: Insti เมื่อ 4 สิงหาคม 2010, 14:58:31 น.

มันดูเหมือนจะสร้างความเสียหายมากกว่าความช่วยเหลือ เพราะมันขัดขวางการใช้งานการชำระเงินขนาดเล็กเช่นที่ bytemaster แนะนำ

ปัจจุบัน Bitcoin ยังไม่เหมาะสำหรับการชำระเงินขนาดเล็กมากๆ ไม่ใช่สำหรับสิ่งต่างๆ เช่น การจ่ายต่อการค้นหาหรือต่อการดูหน้าเว็บโดยไม่มีกลไกการรวมกลุ่ม ไม่ใช่สิ่งที่ต้องจ่ายน้อยกว่า 0.01 ขีดจำกัดสแปมขยะเป็นความพยายามแรกในการป้องกันการชำระเงินขนาดเล็กเช่นนี้โดยเจตนา

Bitcoin เหมาะสำหรับธุรกรรมขนาดเล็กกว่าที่เป็นไปได้กับวิธีการชำระเงินที่มีอยู่ เล็กพอที่จะครอบคลุมสิ่งที่คุณอาจเรียกว่าระดับบนของช่วงการชำระเงินขนาดเล็ก แต่มันไม่ได้อ้างว่าใช้ได้ผลสำหรับการชำระเงินขนาดเล็กตามอำเภอใจ

Re: การโจมตีน้ำท่วม 0.00000001 BC

โพสต์โดย satoshi, 5 สิงหาคม 2010, 16:03:21 น.

ลืมเพิ่มส่วนที่ดีเกี่ยวกับการชำระเงินขนาดเล็ก แม้ว่าผมไม่คิดว่า Bitcoin จะเหมาะสำหรับการชำระเงินขนาดเล็กที่มีขนาดเล็กกว่านี้ได้ในตอนนี้ แต่ในที่สุดมันก็จะเป็นไปได้ เมื่อต้นทุนการจัดเก็บและแบนด์วิดท์ยังคงลดลงอย่างต่อเนื่อง หาก Bitcoin ได้รับความนิยมในระดับใหญ่ มันอาจจะเป็นเรื่องนี้ได้แล้วในเวลานั้น อีกวิธีที่จะทำให้พวกมันใช้งานได้ง่ายขึ้นคือ ถ้าผมนำโหมดเฉพาะไคลเอ็นต์มาใช้ และจำนวนโหนดเครือข่ายรวมเป็นจำนวนเซิร์ฟเวอร์ฟาร์มแบบมืออาชีพที่น้อยลง ไม่ว่าขนาดการชำระเงินขนาดเล็กที่คุณต้องการจะเป็นเท่าไหร่ในที่สุดมันก็จะใช้งานได้จริง ผมคิดว่าใน 5 หรือ 10 ปี แบนด์วิดท์และพื้นที่เก็บข้อมูลจะดูเหมือนเรื่องเล็กน้อย

ผมไม่ได้อ้างว่าเครือข่ายนี้ทนทานต่อการโจมตีแบบ DoS นะ ผมคิดว่าเครือข่าย P2P ส่วนใหญ่สามารถถูกโจมตีแบบ DoS ได้หลายวิธี (เป็นการพูดแทรก ผมเคยอ่านว่าค่ายเพลงอยากจะ DoS เครือข่ายแชร์ไฟล์ทั้งหมด แต่พวกเขาไม่อยากทำผิดกฎหมายป้องกันการแฮ็คและการละเมิด)

หากเราเริ่มถูกโจมตีแบบ DoS ด้วยธุรกรรมขยะที่ถูกส่งไปมาเป็นจำนวนมาก คุณจะต้องเริ่มจ่ายค่าธรรมเนียมธุรกรรมขั้นต่ำ 0.01 จริงๆ แล้ว 0.1.5 มีตัวเลือกให้ตั้งค่านั้น แต่ผมนำออกไปเพื่อลดความสับสน ธุรกรรมฟรีนั้นดี และเราสามารถใช้แบบนั้นได้ต่อไปถ้าผู้คนไม่ใช้มันในทางที่ผิด

นั่นทำให้เกิดคำถามว่า: หากมีค่าธรรมเนียมขั้นต่ำ 0.01 สำหรับแต่ละธุรกรรม เราควรเพิ่มค่าธรรมเนียมโดยอัตโนมัติหรือไม่หากเป็นขั้นต่ำ 0.01 เท่านั้น? มันจะน่ารำคาญมากที่ต้องถามทุกครั้ง ถ้าคุณมี 50.00 และส่ง 10.00 ผู้รับจะได้รับ 10.00 และคุณจะเหลือ 39.99 ผมคิดว่ามันควรเพิ่มโดยอัตโนมัติ มันเป็นเรื่องเล็กน้อยเมื่อเทียบกับค่าธรรมเนียมที่บริการประเภทอื่นๆ หลายแห่งเพิ่มโดยอัตโนมัติ

อ้างอิงจาก: FreeMoney เมื่อ 4 สิงหาคม 2010, 19:30:32 น.

การเพิ่มเข้าไปมากขึ้นจะทำให้อัตราการแฮชของคุณช้าลงหรือไม่?

ไม่เลย ไม่เลยจริงๆ

Re: การโจมตีน้ำท่วม 0.00000001 BC

โพสต์โดย satoshi, 5 สิงหาคม 2010, 16:30:20 น.

อ้างอิงจาก: bytemaster

โดยทั่วไปการชำระเงินจะเป็นการล่วงหน้า เช่น 1 BTC ต่อครั้ง และเมื่อการเชื่อมต่อปิดลง "เงินทอน" ใดๆ จะถูกส่งคืน กฎนี้ทำให้ไม่สามารถจ่ายสำหรับ "คำค้นหา" ธรรมดาโดยไม่มีธุรกรรมเพิ่มเติมได้

อีกทางเลือกหนึ่งคือใช้ระบบปัดเศษ คุณจ่ายเงิน เช่น 1000 หน้าหรือรูปภาพหรือดาวน์โหลดหรือการค้นหาหรืออะไรก็ตามในแต่ละครั้ง เมื่อคุณใช้หน้าของคุณครบ 1000 หน้าแล้ว คุณก็จ่ายเงินสำหรับอีก 1000 หน้า หากคุณใช้เพียง 1 หน้า คุณก็จะเหลืออีก 999 หน้าที่คุณอาจไม่ได้ใช้เลย แต่มันก็ไม่ใช่เรื่องใหญ่เพราะต้นทุนต่อ 1000 หน้ายังคงต่ำอยู่

หรือคุณสามารถจ่ายรายวัน ครั้งแรกที่คุณเข้าถึงไซต์ในวันที่กำหนด คุณจ่ายสำหรับการเข้าถึง 24 ชั่วโมง

ต่อ 1000 ครั้งหรือต่อวันอาจจะเข้าใจง่ายกว่าสำหรับผู้บริโภคด้วย พวกเขากังวลเกี่ยวกับการจ่ายต่อรายการเพราะมันยากกว่าที่จะคำนวณว่ามันอาจจะรวมกันเร็วเกินไปหรือไม่ สำหรับแบบไม่จำกัดเป็นเวลา 24 ชั่วโมง พวกเขารู้ว่าค่าใช้จ่ายจะเป็นเท่าไหร่ หรือถ้า 1000 ครั้งดูเหมือนจะเพียงพอ พวกเขาก็ไม่ต้องกังวลว่ามันจะมีค่าใช้จ่ายเพิ่มขึ้นในแต่ละครั้งที่คลิก หากพวกเขาคิดว่า 1000 ครั้งมากกว่าที่พวกเขาน่าจะใช้

Re: การโจมตีน้ำท่วม 0.00000001 BC

โพสต์โดย satoshi, 5 สิงหาคม 2010, 16:39:58 น.

อ้างอิงจาก: bytemaster เมื่อ 5 สิงหาคม 2010, 15:39:19 น.

วิธีแก้ปัญหานี้วิธีเดียวคือการทำให้การกระจายธุรกรรม "ไม่ฟรี" นั่นคือ หากคุณต้องการให้ผมรวมมันเข้าไป คุณต้องจ่ายเงินให้ผม ผลลัพธ์สุทธิ (ไม่ได้ตั้งใจเล่นคำ) คือแต่ละไคลเอ็นต์จะต้องจ่ายเงินให้ไคลเอ็นต์อื่น ๆ ที่พวกเขาส่งธุรกรรมของตนไปให้ ไม่ใช่แค่บุคคลที่ได้รับมันในบล็อกเท่านั้น ด้วยวิธีนี้กฎทางเศรษฐศาสตร์ก็เข้ามามีบทบาทและไม่มีใครได้นั่งฟรีบนระบบการกระจายธุรกรรม

ผมไม่รู้วิธีนำสิ่งนั้นมาใช้ ค่าธรรมเนียมธุรกรรมสำหรับผู้สร้างบล็อกใช้กลเม็ดพิเศษในการรวมค่าธรรมเนียมธุรกรรมโดยไม่ต้องเพิ่มขนาด หากมีธุรกรรมสำหรับค่าธรรมเนียมธุรกรรมแต่ละรายการ แล้วจะเกิดอะไรขึ้นกับค่าธรรมเนียมธุรกรรมสำหรับธุรกรรมของค่าธรรมเนียมธุรกรรมล่ะ?

Re: การโจมตีน้ำท่วม 0.00000001 BC

โพสต์โดย satoshi, 5 สิงหาคม 2010, 17:49:43 น.

อ้างอิงจาก: bytemaster เมื่อ 5 สิงหาคม 2010, 16:46:52 น.

ตอนนี้ ที่อยู่ค่าธรรมเนียมธุรกรรมถูกเว้นว่าง "ว่างเปล่า" และผู้สร้างบล็อกเป็นผู้กรอก ตอนนี้คุณจะกรอกที่อยู่ของบุคคลที่คุณขอให้สร้างบล็อก

ถ้าคุณจะให้คนเดียวทำงานในการสร้างบล็อก มันอาจจะใช้เวลาหลายวัน โอ้ หรือคุณหมายความว่าส่งรูปแบบที่แตกต่างกันไปยังแต่ละโหนดโดยเขียนค่าธรรมเนียมการทำธุรกรรมถึงพวกเขา?

ตอนนี้ มันเป็นแบบใครสร้างก็ได้รับ

ถ้าเราจำเป็น เราสามารถมีระบบการกระจายธุรกรรมแบบต่างตอบแทนคล้าย BitTorrent ถ้าคุณรีเลย์ธุรกรรมที่จ่ายให้ผม ไม่อย่างนั้นผมจะไม่รีเลย์ให้คุณ แต่มันอาจจะไม่ใช่ปัญหาจริงๆ มันใช้โหนดเพียงตัวเดียวที่รีเลย์อย่างถูกต้องเพื่อหักล้างอีก 7 ตัวที่ไม่รีเลย์อย่างเห็นแก่ตัว

Re: การโจมตีน้ำท่วม 0.00000001 BC

โพสต์โดย satoshi, 11 สิงหาคม 2010, 23:28:50 น.

มันจะดีถ้าเราสามารถทำให้ไฟล์ blk*.dat มีขนาดเล็กได้นานที่สุด

ในที่สุดวิธีแก้ปัญหาก็คือไม่สนใจว่ามันจะใหญ่ขนาดไหน

แต่สำหรับตอนนี้ ในขณะที่มันยังเล็กอยู่ การรักษาให้มันเล็กก็เป็นเรื่องดีเพื่อให้ผู้ใช้ใหม่สามารถเริ่มต้นได้เร็วขึ้น เมื่อผมนำโหมดเฉพาะไคลเอ็นต์มาใช้ในที่สุด สิ่งนั้นจะไม่สำคัญมากอีกต่อไป

ยังมีงานที่ต้องทำเกี่ยวกับค่าธรรมเนียมธุรกรรมอีก ในกรณีที่เกิดน้ำท่วม คุณก็ยังสามารถข้ามคิวและทำให้ธุรกรรมของคุณเข้าไปในบล็อกถัดไปได้โดยการจ่ายค่าธรรมเนียมธุรกรรม 0.01 อย่างไรก็ตาม ผมยังไม่มีเวลาเพิ่มตัวเลือกนั้นในส่วนติดต่อผู้ใช้

ไม่ว่าจะมีขนาดใหญ่หรือไม่ เครือข่ายทดสอบจะตอบสนองในลักษณะเดียวกัน แต่จะใช้แบนด์วิดท์ที่สูญเปล่าและความรำคาญน้อยกว่ามาก