56 เกี่ยวกับประเภทของบล็อกเชนทางเลือกที่มีเพียงบันทึกแฮช

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

เกี่ยวกับประเภทของบล็อกเชนทางเลือกที่มีเพียงบันทึกแฮช

ที่นี่ มีการอภิปรายข้อเสนอแนะที่ Satoshi เห็นว่าน่าสนใจ ข้อเสนอแนะนี้อาศัยการให้ข้อมูลที่น้อยลงในบล็อกเชน โดยมีเจตนาที่จะให้ระดับความเป็นส่วนตัวที่มากขึ้น

ไม่ใช่ข้อเสนอแนะ

โพสต์โดย Red, 10 สิงหาคม 2010, 05:45:45 น.

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

ดังนั้นนี่จึงไม่ใช่ข้อเสนอแนะสำหรับการเปลี่ยนแปลง bitcoin แต่เป็นคำถามเกี่ยวกับสิ่งที่เป็นไปได้และสิ่งที่ไม่เป็นไปได้

คำถามทั่วไปคือ บัญชีรายการบล็อก (block list) สามารถ/เคยถูกใช้งานในลักษณะที่ไม่ได้เก็บธุรกรรมเต็มรูปแบบในรายการหรือไม่? โดยเฉพาะอย่างยิ่ง บางที อาจเป็นไปได้ที่จะเก็บเพียงแฮช (hashes) ของจุดเข้า (in-points) และจุดออก (out-points) ในบัญชีรายการบล็อกเท่านั้น ซึ่งจะมีการประทับเวลา (notarized) ในบัญชีรายการบล็อกเช่นเดียวกับที่ทำอยู่ในปัจจุบัน

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

เมื่อเขาต้องการโอนเหรียญไปยังบุคคลถัดไป เขาจะสร้างธุรกรรมเช่นเดียวกับที่ทำอยู่ในปัจจุบัน ยกเว้นว่าเขาจะต้องส่งส่วนที่มาก่อนหน้า (antecedents) ของธุรกรรมเพื่อการตรวจสอบความถูกต้องด้วย สำหรับการตรวจสอบความถูกต้อง ส่วนที่มาก่อนหน้าแต่ละรายการของจุดเข้า (in-points) จะถูกแฮชและตรวจสอบว่ามีอยู่ในบัญชีรายการบล็อกหรือไม่ จุดเข้า (in-points) จะถูกแฮชและระบุในบัญชีรายการบล็อกว่ายังไม่ถูกใช้จ่าย จากนั้นธุรกรรมจะถูกตรวจสอบความถูกต้องเช่นเดียวกับที่ทำในปัจจุบัน

หากทุกอย่างผ่านการตรวจสอบความถูกต้องอย่างถูกต้อง แฮชจุดเข้า/จุดออก (in/outpoint hashes) เพิ่มเติมจะถูกเพิ่มเข้าไปในบล็อก ซึ่งจะปิดจุดเข้าของธุรกรรม และทำเครื่องหมายแฮชจุดออกใหม่ว่ายังไม่ได้ใช้จ่าย

เมื่อโหนดทำการสร้างบล็อกเสร็จสิ้น (โดยชนะการแข่งขันแฮช) เขาจะกระจายบล็อกของแฮชและธุรกรรมที่เกี่ยวข้อง พร้อมทั้งส่วนที่มาก่อนหน้าไปยังโหนดอื่น ๆ สำหรับการยืนยันและการยอมรับ

ตัวอย่างคร่าว ๆ:

{block-9 hash-a, hash-b, hash-c, hash-x} {block-12 hash-a, hash-y, hash-c, hash-d} {block-17 hash-b, hash-d, hash-e, hash-z, hash-f}

{Transaction {in-points: hash-x, hash-y, hash-z} {address, signature and other transactions stuff} {out-points: hash-payed, hash-change} }

{generating-block hash-x, hash-y, hash-z, hash-payed, hash-change}

ดังนั้น โดยพื้นฐานแล้ว หากแฮชจุดเข้า/ออก (i/o-point hash) ปรากฏอยู่สองครั้งในบัญชีรายการบล็อก แสดงว่าได้ถูกใช้จ่ายไปแล้ว หากปรากฏเพียงครั้งเดียว แสดงว่ายังไม่ได้ใช้จ่าย

ดังนั้น หลังจากบล็อก-17: a, b, c และ d ถูกใช้จ่ายไปแล้ว ส่วน e, f, x, y, z ยังไม่ได้ถูกใช้จ่าย

ธุรกรรมจะใช้ x, y และ z และสร้าง hash-payed และ hash-change ดังนั้นธุรกรรมจึงถูกต้อง

หลังจากบล็อกที่สร้างขึ้น (generating-block): a, b, c, d, x, y, และ z ถูกใช้จ่ายไปแล้ว ส่วน e, f, payed, change ยังไม่ได้ถูกใช้จ่าย

====

เป้าหมาย:

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

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

====

คำถาม:

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

"สามารถลบธุรกรรมได้เร็วที่สุดเมื่อใด?"

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

====

มีความคิดเห็นใด ๆ ไหม มีวิธีที่ชัดเจนที่ผู้คนสามารถโกงและรวยได้ไหม

Re: ไม่ใช่ข้อเสนอแนะ

โพสต์โดย Insti, 10 สิงหาคม 2010, 09:34:14 น.

ในระบบของคุณ แทนที่จะได้รับธุรกรรมจากบล็อกเชนเพียงอย่างเดียว ผมต้องเฝ้าดูทุกธุรกรรม (ซึ่งผมจะเห็นอยู่แล้ว) และบันทึกธุรกรรมเหล่านั้นไปยังเซิร์ฟเวอร์ลับของผม

คุณเพียงแค่สนับสนุนความปลอดภัยผ่านความคลุมเครือ (security through obscurity)

Re: ไม่ใช่ข้อเสนอแนะ

โพสต์โดย Red, 10 สิงหาคม 2010, 02:09:36 น.

อ้างอิงจาก: Insti เมื่อ 10 สิงหาคม 2010, 09:34:14 น.

คุณเพียงแค่สนับสนุนความปลอดภัยผ่านความคลุมเครือ

ผมได้กล่าวถึงเรื่องนั้นแล้ว ผมจะไม่หวังพึ่งสิ่งนี้เพื่อความปลอดภัยทางการเงิน ผมอยากให้ระบบนี้เทียบเท่ากับระบบปัจจุบัน

อย่างไรก็ตาม ความคลุมเครือในความเป็นส่วนตัว (privacy obscurity) เป็นที่ทราบกันดีว่าเพิ่มมูลค่า เพื่อนบ้านหรือ FBI ของคุณอาจจับตาดูทุกสิ่งที่คุณทำตลอดทั้งวัน แต่พวกเขาก็อาจจะไม่ได้ทำ หากคุณกลายเป็นคนที่ "น่าสนใจ" แน่นอนว่าพวกเขาสามารถเริ่มจับตามองคุณตั้งแต่ตอนนี้และตั้งแต่นี้เป็นต้นไปได้

แต่อำนาจทางกฎหมายเพิ่มเติมที่ถูกร้องขอมากที่สุดดูเหมือนจะเป็น "ให้ฉันตรวจสอบบันทึกของทุกคน!" (การโทร, เสาสัญญาณมือถือ, การเชื่อมต่ออีเมล, การเชื่อมต่อ Facebook, ธุรกรรมบัตรเครดิต/เดบิต, ประวัติ Google, ประวัติเบราว์เซอร์) ระบบอื่น ๆ คือ "ความปลอดภัยผ่านอำนาจ (security through authority)" Bitcoin ไม่มีสิ่งนั้น

อย่างไรก็ตาม ผมไม่อยากกระจายธุรกรรมทุกรายการไปยังทุกโหนดเช่นกัน แต่นั่นเป็นอีกเรื่อง

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

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

Re: ไม่ใช่ข้อเสนอแนะ

โพสต์โดย Insti, 10 สิงหาคม 2010, 03:06:16 น.

อ้างอิงจาก: Red เมื่อ 10 สิงหาคม 2010, 02:22:09 น.

คุณไม่จำเป็นต้องพิสูจน์ต่อโนตารีด้วยว่าคุณมี X BTC ในบัญชีของคุณเพื่อใช้จ่าย

แม้ว่าเมื่อเร็ว ๆ นี้ผมได้อ่านเกี่ยวกับหลักฐานแบบไม่เปิดเผยข้อมูล (Zero-knowledge proofs) (http://en.wikipedia.org/wiki/Zero-knowledge_proof) ถ้าคุณสามารถใช้สิ่งที่คล้ายกันเพื่อพิสูจน์ว่าบัญชีของคุณมี X BTC อยู่โดยไม่ต้องเปิดเผยข้อมูลอื่นใด มันอาจเป็นสิ่งที่คุณกำลังมองหา

ผมแค่กังวลว่าสิ่งที่คุณต้องการนั้นอาจเป็นไปไม่ได้ในทางทฤษฎี

Re: ไม่ใช่ข้อเสนอแนะ

โพสต์โดย Red, 10 สิงหาคม 2010, 05:29:44 น.

อ้างอิงจาก: Insti เมื่อ 10 สิงหาคม 2010, 03:06:16 น.

แม้ว่าเมื่อเร็ว ๆ นี้ผมได้อ่านเกี่ยวกับหลักฐานแบบไม่เปิดเผยข้อมูล (Zero-knowledge proofs) (http://en.wikipedia.org/wiki/Zero-knowledge_proof)

เป็นความคิดที่น่าสนใจที่จะหยิบขึ้นมาทบทวนอีกครั้ง! ขอบคุณ ผมไม่ได้คิดถึงพวกเขามาสักพักแล้ว

Re: ไม่ใช่ข้อเสนอแนะ

โพสต์โดย Satoshi, 11 สิงหาคม 2010, 12:14:22 น.

นี่เป็นหัวข้อที่น่าสนใจมาก หากพบทางแก้ไข การใช้งาน Bitcoin ที่ดีกว่า ง่ายกว่า และสะดวกกว่ามากจะเป็นไปได้

แต่เดิมนั้น เหรียญสามารถเป็นเพียงห่วงโซ่ของลายเซ็นได้ ด้วยบริการประทับเวลา เหรียญเก่าจะสามารถถูกดรอปทิ้งได้ในที่สุดก่อนที่จะมีการย้อนกลับ (backtrace) ที่แตกกิ่งก้านมากเกินไป หรือเหรียญสามารถถูกเก็บไว้เป็นรายบุคคลหรือตามหน่วย มันคือความจำเป็นที่ต้องตรวจสอบว่าไม่มีการใช้จ่ายซ้ำ (double-spends) ซึ่งต้องการการรู้จักธุรกรรมทั้งหมดในระดับสากล

ความท้าทายคือ จะพิสูจน์ได้อย่างไรว่าไม่มีการใช้จ่ายอื่นอยู่? ดูเหมือนว่าโหนดต้องรู้เกี่ยวกับธุรกรรมทั้งหมดเพื่อจะสามารถตรวจสอบได้ หากมันรู้เพียงแฮชของจุดเข้า/ออก (in/outpoints) มันก็ไม่สามารถตรวจสอบลายเซ็นเพื่อดูว่าจุดออกถูกใช้ไปแล้วหรือไม่ คุณมีไอเดียเกี่ยวกับเรื่องนี้ไหม?

มันยากที่จะคิดว่าจะนำหลักฐานแบบไม่เปิดเผยข้อมูล (zero-knowledge-proofs) มาประยุกต์ใช้ในกรณีนี้ได้อย่างไร

เรากำลังพยายามพิสูจน์การไม่มีอยู่ของบางสิ่ง ซึ่งดูเหมือนว่าจะต้องรู้เกี่ยวกับทุกอย่างและตรวจสอบว่าสิ่งนั้นไม่ได้รวมอยู่ด้วย

Re: ไม่ใช่ข้อเสนอแนะ

โพสต์โดย Red, 11 สิงหาคม 2010, 04:58:50 น.

Satoshi: ผมรู้ว่าคุณรู้ส่วนแรกของสิ่งที่ผมกำลังเขียน แต่ผมอยากให้คนอื่น ๆ สามารถติดตามได้และให้คุณแก้ไขความเข้าใจผิดใด ๆ ที่ผมอาจมี

ผมกำลังดูการใช้งาน Merkle tree ในปัจจุบันพยายามที่จะหาว่าธุรกรรมสามารถถูกลบออกได้เมื่อใดโดยไม่สูญเสียความปลอดภัย

ในแง่ของกราฟธุรกรรม ธุรกรรมแทนโหนด ขอบของกราฟธุรกรรมแสดงโดยจุดเข้า (in-points) ซึ่งชี้ไปยังธุรกรรมก่อนหน้าโดยใช้โครงสร้างแบบ BlockHash->TransHash->OutPoint การมีอยู่ของจุดเข้าเป็นตัวบ่งชี้ว่าจุดออกก่อนหน้าถูกใช้ไปแล้ว

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

นั่นยังหมายความด้วยว่าไม่มีธุรกรรมใดที่สามารถถูกตัดออกจากรายการบล็อกได้ จนกว่าจุดออกทั้งสองจะถูกใช้จ่ายไป มิฉะนั้นเหรียญจะหายไป

อย่างไรก็ตาม คุณสามารถลบธุรกรรมที่มีการผูกมัดซ้ำ (double-bound) ทั้งหมดได้ทันทีที่คุณมั่นใจว่าบล็อกที่ผูกมัดครั้งที่ 2 จะคงอยู่ (ความเป็นไปได้เร็วที่สุด)

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

ซึ่งทำให้ผมคิดว่า มีวิธีที่จะพิสูจน์ความถูกต้องได้หรือไม่ถ้าคุณไม่เคยใส่ธุรกรรมทั้งหมดลงในกราฟตั้งแต่แรก?

อ้างอิงจาก: satoshi เมื่อ 11 สิงหาคม 2010, 12:14:22 น.

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

เฉพาะตัวตรวจสอบธุรกรรมเท่านั้นที่จำเป็นต้องรู้ที่อยู่ bitcoin ที่เชื่อมโยงกับแฮชจุดออกที่ถูกบันทึกไว้ นั่นมาจากธุรกรรมก่อนหน้า (antecedent transaction) ที่ถูกส่งมาสำหรับจุดเข้าของธุรกรรมปัจจุบัน ธุรกรรมก่อนหน้าและจุดออกจะถูกแฮชและสันนิษฐานว่าถูกต้องและยังไม่ได้ใช้จ่าย หากแฮชนั้นปรากฏครั้งเดียวเท่านั้นในรายการบล็อก

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

อ้างอิงจาก: satoshi เมื่อ 11 สิงหาคม 2010, 12:14:22 น.

ในกรณีนี้เรากำลังพยายามพิสูจน์การมีอยู่ของแฮชที่ตรงกันหนึ่งอันและการไม่มีอยู่ของแฮชที่ตรงกันสองอัน มันต้องการรู้แฮชทั้งหมดเพื่อพิสูจน์

ผมคิดว่าข้อห้ามต่อการใช้จ่ายซ้ำ (double spending) นั้นแข็งแกร่งเท่ากับในเวอร์ชันปัจจุบัน

==== ระวัง! ====

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

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

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

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

----------

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

อ้างอิงจาก: satoshi เมื่อ 11 สิงหาคม 2010, 12:14:22 น.

มันยากสำหรับผมเช่นกัน! :-) แต่ก็เป็นเรื่องที่น่าสนใจที่จะอ่านทบทวนอีกครั้ง!

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

แต่มันไม่ได้เป็นอย่างนั้น :-)

Re: ไม่ใช่ข้อเสนอแนะ

โพสต์โดย satoshi, 11 สิงหาคม 2010, 09:07:59 น.

ยังคิดผ่านไอเดียนี้อยู่ . . .

งานเดียวที่เครือข่ายต้องทำคือการบอกว่าการใช้จ่าย outpoint เป็นครั้งแรกหรือไม่

หากเรายินยอมให้ไคลเอนต์เก็บประวัติเงินของตัวเอง ข้อมูลบางส่วนอาจไม่จำเป็นต้องถูกเก็บโดยเครือข่าย เช่น:

• มูลค่า

• การเชื่อมโยงระหว่างจุดเข้าและจุดออกในธุรกรรมเดียว

เครือข่ายจะติดตามจุดออก (outpoints) ที่เป็นอิสระจำนวนหนึ่ง โดยไม่รู้ว่าจุดเหล่านั้นเป็นของธุรกรรมหรือจำนวนเงินใด ไคลเอนต์สามารถตรวจสอบได้ว่า outpoint ถูกใช้จ่ายไปแล้วหรือยัง และสามารถส่ง inpoint ที่เป็นที่พอใจเพื่อกำหนดให้มันใช้จ่ายได้ เครือข่ายเก็บ outpoint และ inpoint ที่ถูกต้องตัวแรกที่พิสูจน์ว่ามันถูกใช้จ่ายไปแล้ว inpoint เซ็นแฮชของ outpoint ถัดไปที่เกี่ยวข้องและค่า salt ดังนั้นจึงสามารถแสดงแบบส่วนตัวได้ว่าลายเซ็นนั้นเซ็น outpoint ถัดไปเฉพาะเจาะจงหากคุณรู้ค่า salt แต่โดยสาธารณะแล้วเครือข่ายไม่รู้ว่า outpoint ถัดไปคืออะไร

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

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

Re: ไม่ใช่ข้อเสนอแนะ

โพสต์โดย Red, 12 สิงหาคม 2010, 01:10:19 น.

อ้างอิงจาก: satoshi เมื่อ 11 สิงหาคม 2010, 09:07:59 น.

ยังคิดผ่านไอเดียนี้อยู่...

มันเป็นไอเดียที่ทำให้สมองบิดเบี้ยวไปหน่อยเลยใช่ไหม :-)

กลายเป็นว่าแนวคิดของการโนตารีที่สามารถยกเลิกได้นั้นสามารถนำไปใช้ได้ทั่วไปอย่างดี

ตัวอย่างเช่น ระบบนี้ไม่ได้จำกัดอยู่แค่ธุรกรรม bitcoin เท่านั้น เนื่องจากมีการเก็บสัญญาที่ลงนามไว้ภายนอก พร้อมกับกฎการตรวจสอบ/โนตารีเพิ่มเติม คุณสามารถนำไปใช้กับสิ่งต่าง ๆ เช่น ตั๋วสัญญาใช้เงิน (IOUs) หรือตั๋วเรียกร้อง (claim checks) ได้อย่างง่ายดาย

ถ้ามีคนให้เงินคุณ 5 ดอลลาร์ คุณสามารถให้ตั๋วสัญญาใช้เงิน (IOU) มูลค่า 5 ดอลลาร์แก่เขาได้ แฮชของตั๋วสัญญาใช้เงินนั้นจะถูกโนตารีเข้าไปในรายการบล็อก (ของแฮช) เมื่อคุณจ่ายเงินคืนให้พวกเขา คุณสามารถให้พวกเขาเซ็นในตั๋วสัญญาใช้เงินเพื่อยืนยันได้ จากนั้นให้โนตารีใส่การยกเลิกแฮชตั๋วสัญญาใช้เงินเข้าไป แล้วจะไม่มีใครสามารถนำสำเนาตั๋วสัญญาใช้เงินมาแสดงและเรียกร้องให้จ่ายเงินซ้ำได้

อ้างอิงจาก: satoshi เมื่อ 11 สิงหาคม 2010, 09:07:59 น.

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

ผมก็คิดแบบนี้ในตอนแรกเหมือนกัน แต่แล้วผมก็โน้มน้าวตัวเองเป็นอย่างอื่น

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

หากคุณมั่นใจในกระบวนการที่ตรวจสอบความถูกต้องของธุรกรรมในระหว่างการสร้างบล็อก (การยอมรับของ CPU มากกว่า 50%) และหากคุณมั่นใจว่าบล็อกก่อนหน้าไม่สามารถเปลี่ยนแปลงได้ (คุณพิสูจน์สิ่งนี้แล้ว) คุณก็เพียงแค่ต้องตรวจสอบว่าจุดออกที่เกี่ยวข้องยังไม่ถูกใช้จ่ายเท่านั้น คุณลักษณะด้านความปลอดภัยยังคงอยู่ในรายการบล็อกและกระบวนการ แม้ว่าตัวธุรกรรมเองจะถูกเก็บไว้ภายนอกและส่วนก่อนหน้าจะไม่ถูกเก็บไว้เลย คุณแสดงให้เห็นด้วยตัวคุณเองแล้วโดยการพิสูจน์ว่าธุรกรรมเก่าสามารถลบออกได้โดยใช้ Merkle tree เพื่อรักษาความสอดคล้อง

อ้างอิงจาก: satoshi เมื่อ 11 สิงหาคม 2010, 09:07:59 น.

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

จริง ๆ แล้ว ความเป็นส่วนตัวนั้นเกี่ยวข้องโดยตรงกับความสามารถในการสังเกตเห็น ถ้ามีฝ่ายกลางอย่างผู้แลกเปลี่ยนเงิน เขาสามารถเชื่อมโยงจุดออก (out-points) ได้มาก แต่ถ้าเราเลิกยึดติดกับแนวคิดที่ว่าทุกเหรียญต้องสามารถย้อนกลับไปถึงการสร้างได้ ขอบเขตการสังเกตจะแคบลงมาก

----

มันแปลกจริง ๆ ที่ต้องทำใจยอมรับความคิดที่ว่าเหรียญนี้ถูกต้องเพียงเพราะกระบวนการไม่ยอมให้มันถูกรวมเข้าไปได้หากเป็นอย่างอื่น แต่จริง ๆ แล้ว นั่นคือวิธีการทำงานของการสร้าง bitcoin อย่างแน่นอน ธุรกรรมไม่มีอินพุต แต่ทุกคนตัดสินใจว่าจุดออก (out-point) ต้องถูกต้องเพียงเพราะมิฉะนั้นแล้ว มันจะไม่อยู่ในบล็อกเลยด้วยซ้ำ :-)

Re: ไม่ใช่ข้อเสนอแนะ

โพสต์โดย satoshi, 12 สิงหาคม 2010, 02:46:56 น.

อ้างอิงจาก: Red เมื่อ 12 สิงหาคม 2010, 01:10:19 น.

อ้างอิงจาก: satoshi เมื่อ 11 สิงหาคม 2010, 09:07:59 น.

คุณกลับมาพูดถึงระบบ Bitcoin ที่มีอยู่ในตอนนี้หรือเปล่า?

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

ถ้าไคลเอนต์ไม่มีอยู่จนกระทั่งเมื่อเร็ว ๆ นี้ วิธีการสองวิธีในการโน้มน้าวให้ไคลเอนต์เชื่อว่าธุรกรรมมีอดีตที่ถูกต้องคือ:

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

แต่ถ้าเครือข่ายไม่รู้จักมูลค่าและลำดับชั้นทั้งหมดของธุรกรรม ผมคิดว่ามันคงทำ 2) ไม่ได้

Re: ไม่ใช่ข้อเสนอแนะ

โพสต์โดย Red, 12 สิงหาคม 2010, 04:25:51 น.

อ้างอิงจาก: satoshi เมื่อ 12 สิงหาคม 2010, 02:46:56 น.

อ้างอิงจาก: Red เมื่อ 12 สิงหาคม 2010, 01:10:19 น.

คุณกลับมาพูดถึงระบบ Bitcoin ที่มีอยู่ในตอนนี้หรือเปล่า?

ใช่ ผมกำลังพูดถึงระบบสมมติ

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

เช่นเดียวกับระบบปัจจุบัน ถ้าธุรกรรมไม่ผ่านการตรวจสอบความถูกต้อง (รวมถึงแฮชจุดออกที่รวมอยู่ด้วย) โหนดอื่น ๆ จะปฏิเสธบล็อก ถ้าบล็อกไม่ได้รับการยอมรับโดยอย่างน้อย 50% ของพลังประมวลผล (CPU power) มันก็จะไม่ติดอยู่ในรายการบล็อก

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

ดังนั้น (เว้นแต่กรณีแฮชชนกัน) ถ้ามีคนส่งธุรกรรมที่มาก่อน (antecedent transaction) ซึ่งตรงกับจุดออกที่ยังไม่ได้ใช้จ่าย มันต้องถูกต้อง

ต้นตอ (antecedent) ของต้นตอนั้นก็ต้องถูกต้องเช่นกัน มิฉะนั้นต้นตอจะถูกปฏิเสธ และก็เป็นเช่นนั้นเรื่อยไป

สำหรับกรณีที่ไม่เป็นเช่นนั้น คุณต้องสมมติว่ามีช่วงเวลาหนึ่งที่บล็อกไม่ได้รับการตรวจสอบความถูกต้องกับแฮชจุดออก (out-point hashes) แต่เป็นไปไม่ได้อย่างสมเหตุสมผลกับระบบการแข่งขัน CPU

อ้างอิงจาก: satoshi เมื่อ 12 สิงหาคม 2010, 02:46:56 น.

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

ถ้าไคลเอนต์เข้าร่วมเครือข่ายเมื่อเร็ว ๆ นี้ มันทำเช่นนั้นโดยสันนิษฐานว่าผู้ตรวจสอบความถูกต้องก่อนหน้าทำตามกฎและบล็อกที่มีอยู่ก่อนหน้านั้นถูกต้อง (ไม่มีใครอยากเข้าร่วมเครือข่ายที่รู้ว่าเสียหาย)

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

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

สิ่งที่ผมกำลังพูดเป็นพิเศษคือ ถ้าคุณมั่นใจในกระบวนการแข่งขันตรวจสอบความถูกต้องของ bitcoin (และเรามั่นใจ!) คุณไม่จำเป็นต้องให้ "บล็อกลึกอย่างถี่ถ้วนใน 2)" ลึกมากเลย มีคนพูดในอีกกระทู้ว่าไคลเอนต์ปฏิเสธการเปลี่ยนแปลงใด ๆ กับบล็อกที่เก่ากว่าสองชั่วโมง ดังนั้นเราจึงมั่นใจอย่างสมบูรณ์ในบล็อกที่ถูกฝังลึกถึง 12 ชั้น

ดังนั้นถ้าธุรกรรมยังไม่ถูกใช้จ่ายและถูกฝังลึกถึง 12 ชั้น เราสามารถล้างบรรพบุรุษทั้งหมดของมันได้ พวกเขาให้ความรู้สึกอบอุ่นใจ แต่ไม่ได้เพิ่มการตรวจสอบความถูกต้องอะไรเลย เราต้องพึ่งพาพวกเขา เพราะไม่มีทางที่จะถอยหลังกลับไปและเปลี่ยนเส้นทางเลย

หลังจากนั้นทุกบล็อกที่ตามมาจะสันนิษฐานว่าบล็อกก่อนหน้าทั้งหมดเป็นความจริง มิฉะนั้นมันจะเป็นการแยกสาขา (fork) ไม่ใช่บล็อกที่ตามมา ดังนั้นสำหรับธุรกรรมใดก็ตามที่ได้รับการตรวจสอบความถูกต้องกับจุดออก (out-points) ในบล็อกก่อนหน้า ถ้าจุดออกเหล่านั้นมีอยู่และยังไม่ได้ใช้จ่าย ต้องสันนิษฐานว่าถูกต้อง ถ้าสันนิษฐานว่าจุดเหล่านั้นถูกต้อง ก็ต้องสันนิษฐานว่าบรรพบุรุษของพวกมันถูกต้องแม้ว่าจะถูกล้างออกไปแล้ว

---

ในระบบที่ถูกเสนอ สิ่งเดียวกันนี้เป็นความจริงพอดี

ถ้าแฮชจุดออก (out-point hash) ของต้นตอ (antecedent) ยังไม่ได้ใช้จ่ายและถูกฝังลึกกว่า 12 บล็อก แสดงว่ามันยังไม่ได้ถูกใช้จ่ายแน่นอน ไม่มีอะไรเปลี่ยนแปลงข้อเท็จจริงนั้นได้ ไม่มีประเด็นที่จะต้องไปตรวจสอบบรรพบุรุษของมัน คุณสามารถตรวจสอบความถูกต้องของธุรกรรมจนเสร็จ ยกเลิกแฮชจุดเข้า (in-points hashes) และสร้างแฮชจุดออกใหม่

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

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

=====

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

ส่วนที่เหลือเป็นเพียงความรู้สึกอบอุ่นใจ

-ป.ล. -

ผมรู้ว่านี่ยาวเกินไปและซ้ำซ้อน แต่ผมเหนื่อยเกินกว่าจะแก้ไข :-)

Re: ไม่ใช่ข้อเสนอแนะ

โพสต์โดย satoshi, 13 สิงหาคม 2010, 07:28:47 น.

ผมยังไม่เข้าใจความคิดของคุณเลย มันซ่อนข้อมูลใด ๆ จากเครือข่ายสาธารณะหรือไม่? ข้อดีคืออะไร?

ถ้าอย่างน้อย 50% ของโหนดตรวจสอบความถูกต้องของธุรกรรมจนสามารถทิ้งธุรกรรมเก่าได้ แสดงว่าทุกคนเห็นทุกอย่างและสามารถเก็บบันทึกไว้ได้

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

มันซ่อนที่อยู่บิตคอยน์หรือเปล่า? ถ้าใช่ก็โอเค บางทีตอนนี้ผมอาจจะเข้าใจแล้ว ถ้าใช่

การเข้ารหัสอาจเสนอวิธีการทำ "การบดบังคีย์" ผมทำการวิจัยบ้างและมันค่อนข้างคลุมเครือ แต่อาจมีบางอย่างที่นั่น "ลายเซ็นกลุ่ม" (group signatures) อาจเกี่ยวข้อง

มีบางอย่างที่นี่ในพื้นที่ทั่วไป: http://www.users.zetnet.co.uk/hopwood/crypto/rh/

สิ่งที่เราต้องการคือวิธีสร้างรูปแบบคีย์สาธารณะที่ถูกบดบังเพิ่มเติม รูปแบบที่ถูกบดบังจะมีคุณสมบัติเดียวกับคีย์สาธารณะรากฐาน (root) เพื่อให้คีย์ส่วนตัวสามารถสร้างลายเซ็นสำหรับรูปแบบใดก็ได้ คนอื่นไม่สามารถบอกได้ว่าคีย์ที่ถูกบดบังเกี่ยวข้องกับคีย์รากฐานหรือคีย์ที่ถูกบดบังอื่นจากคีย์รากฐานเดียวกันหรือไม่ นี่คือคุณสมบัติของการบดบัง โดยย่อแล้ว การบดบังคือ x = (x * large_random_int) mod m

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

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

ยกตัวอย่างเช่น สมมติว่าจะต้องมีคำสั่งให้มีการโจมตีทางทหารที่ไม่เป็นที่นิยม แต่ไม่มีใครอยากจดจำว่าเป็นคนสั่งให้โจมตีในประวัติศาสตร์ หากมีผู้นำ 10 คนมีคีย์ส่วนตัว หนึ่งในนั้นสามารถเซ็นคำสั่งได้และคุณจะไม่รู้ว่าใครทำ

Re: ไม่ใช่ข้อเสนอแนะ

โพสต์โดย Red, 13 สิงหาคม 2010, 09:48:56 น.

ผมจะตอบสิ่งนี้เป็นสองส่วน

อ้างอิงจาก: satoshi เมื่อ 13 สิงหาคม 2010, 07:28:47 น.

ผมยังไม่เข้าใจความคิดของคุณเลย

นั่นเป็นความผิดของผม เพราะผมพยายามที่จะไม่อ้างสิ่งต่าง ๆ มากเกินไปในครั้งเดียว ผมยังพยายามไม่แนะนำ "คุณสมบัติ" ใหม่มากเกินไปในครั้งเดียวเพื่อการวิเคราะห์ด้วย

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

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

อ้างอิงจาก: satoshi เมื่อ 13 สิงหาคม 2010, 07:28:47 น.

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

ในตอนแรก ผมหวังว่าธุรกรรมทั้งหมดจะถูกตรวจสอบความถูกต้องเฉพาะระหว่างฝ่ายที่เกี่ยวข้องเท่านั้น โดยผลแล้ว โหนดที่สร้างบล็อกจะเพียงแค่บันทึกแฮชที่ถูกบอกมาเท่านั้น

อย่างไรก็ตาม ในนาทีสุดท้าย ผมตระหนักว่าเนื่องจากแฮชไม่ได้ถูกเซ็นหรือตรวจสอบอย่างอื่น จึงเป็นไปได้ที่จะปลอมแปลง "ยกเลิกแฮชจุดออก (out-point hash) ก่อนหน้า" ได้อย่างง่ายดาย คุณไม่สามารถขโมยเหรียญของคนอื่นได้ แต่คุณสามารถทำให้มันเป็นโมฆะได้

ผมเห็นสามวิธีที่เป็นไปได้ในการแก้ไขรายละเอียดที่น่ารำคาญนั้น 1) ปล่อยให้ผู้ตรวจสอบทั้งหมดเห็นธุรกรรม ลดสิ่งที่ถูกบันทึกให้เหลือน้อยที่สุด 2) หาวิธีลดจำนวนผู้ตรวจสอบความถูกต้องให้น้อยที่สุดที่จำเป็นต้องเห็นแต่ละธุรกรรม 3) สร้างคู่คีย์ที่ใช้ครั้งเดียวสำหรับทุก out-point ใหม่ เซ็นแฮช (เพิ่งคิดได้!)

ในตอนแรก ผมเขียนเกี่ยวกับกรณีแรก เพราะมันแนะนำตัวแปรน้อยกว่าในครั้งเดียว ผมอยากแน่ใจว่าการบันทึกเฉพาะแฮชนั้นไม่ใช่ความล้มเหลวที่ชัดเจน

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

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

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

แต่แทนที่จะรับประกันว่าต้องใช้พลังประมวลผล (CPU power) 50% ของทั้งหมดเพื่อปลอมแปลงบางอย่าง คุณอาจตั้งเป้าหมายไปที่การยอมรับ 100% และการกระจายเช็คซัมของโซ่และ/หรือบล็อกอย่างสมบูรณ์ ดังนั้นเมื่อมีการจัดระเบียบ DHT ใหม่เป็นระยะ ๆ โหนดใหม่ใด ๆ ก็สามารถยืนยันได้ว่าห่วงโซ่ยังคงสอดคล้องกัน 100% เสมอ (คล้ายกับการเผยแพร่แต่ละ 1024 ค่าเช็คซัมในหนังสือพิมพ์ทุกวัน)

สิ่งนี้จำกัดการมองเห็นของผู้โจมตีในการรู้ว่าเขาต้องการยกเลิกแฮชใด (ผมเห็นแค่ 1/1024 ของธุรกรรมเท่านั้น) และจำกัดช่วงเวลาของเขาในการส่งคำขอยกเลิกที่ฉ้อฉลเป็นช่วงเวลาที่เขาควบคุมผู้ตรวจสอบทั้งหมดของ bucket

ดังนั้นจึงมีแนวทางที่เป็นไปได้ในการได้รับความเป็นส่วนตัวบางส่วนโดยการจำกัดการมองเห็นบางอย่าง มันมาพร้อมกับความเสี่ยงที่อาจเกิดขึ้นบางประการ

ดังนั้นในความเป็นจริง ผมต้องขอบคุณคุณที่จุดประกายไอเดียที่ดีที่สุด ชมเชย! ในตอนแรกผมปฏิเสธไอเดียการเซ็นแฮช outpoint เพราะดูคล้ายกับที่อยู่ bitcoin ที่มีอยู่มาก ผมสันนิษฐานว่าคีย์สาธารณะ (public key) ที่ต้องใช้ในลายเซ็นจะเชื่อมโยงสิ่งต่าง ๆ เข้าด้วยกันมากเกินไป

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

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

เพื่ออำนวยความสะดวกในเรื่อง "หมายเลขบล็อกปัจจุบัน" ผู้ส่งอาจส่งลายเซ็นสำหรับหมายเลขบล็อก 3-4 หมายเลขถัดไป ผู้ตรวจสอบความถูกต้องจะบันทึกเฉพาะหมายเลขที่เหมาะสมเท่านั้น ไปยังบล็อก

มันเพิ่มบิตในรายการบล็อกมากกว่าที่ผมหวังไว้ ผมคิดว่าแฮชเพียงอย่างเดียวเป็นทางเลือกที่ดีที่สุด

====

โครงสร้างเข้ารหัสที่เล็กที่สุดที่มีคุณสมบัติต่อไปนี้คืออะไร? อาจพิจารณาสิ่งนี้แทนแฮชและลายเซ็นแบบเต็ม

ผมให้อะไรบางอย่างที่ดูไม่เจาะจงกับคุณ
ผมให้อะไรบางอย่างที่ดูเหมือนจะเกี่ยวข้องกับ #1 ของคุณได้ง่าย แต่ไม่เกี่ยวข้องกับ #1 ของคนอื่น
ไม่มีใครสามารถหา #2 ของคุณจาก #1 ได้

====

ตัวอย่างเช่น

ผมให้ Z กับคุณ โดยที่ Z = X * Y และทั้ง X และ Y เป็นจำนวนเฉพาะขนาดใหญ่
ผมให้ tuple (X, Y) กับคุณ
ไม่มีใครสามารถแยกตัวประกอบ X และ Y จาก Z ได้

ในกรณีนั้น เมื่อส่งธุรกรรมแบบออฟไลน์ ผู้ส่งจะแนบ (X,Y) สำหรับแต่ละ in-point ผู้รับจะสร้าง (X,Y) ใหม่แบบส่วนตัวสำหรับแต่ละ out-point ใหม่ จากนั้นผู้รับจะกระจาย (X,Y) ของแต่ละ in-point เพื่อยกเลิก และกระจาย Z ของแต่ละ out-point เพื่อสร้างพวกมัน

มันใช้ได้ไหม หรือมันง่ายเกินไป?

Re: ไม่ใช่ข้อเสนอแนะ

โพสต์โดย Red, 13 สิงหาคม 2010, 10:20:50 น.

อ้างอิงจาก: satoshi เมื่อ 13 สิงหาคม 2010, 07:28:47 น.

การเข้ารหัสอาจเสนอวิธีการทำ "การบดบังคีย์" ผมทำการวิจัยบ้างและมันค่อนข้างคลุมเครือ แต่อาจมีบางอย่างที่นั่น "ลายเซ็นกลุ่ม" อาจเกี่ยวข้อง

มีบางอย่างที่นี่ในพื้นที่ทั่วไป: http://www.users.zetnet.co.uk/hopwood/crypto/rh/

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

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

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

โดยที่คีย์สาธารณะที่ถูกปิดบังนั้นเทียบเท่ากับคีย์สาธารณะของที่อยู่บิตคอยน์ในธุรกรรม สมมติว่าคู่คีย์สาธารณะ/ส่วนตัวของที่อยู่บิตคอยน์คือ P/p คีย์สาธารณะที่ถูกปิดบังก็จะเป็น P1, P2, P3...Pn โดยที่แต่ละอันสามารถตรวจสอบความถูกต้องของสิ่งที่เซ็นด้วยคีย์ส่วนตัว (p)

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

นี่มันอัจฉริยะมาก!

Previous55 เรื่องการขุด Bitcoin เป็นการสิ้นเปลืองทรัพยากร Next57 เกี่ยวกับต้นทุนที่สูงขึ้นของการขุด

Last updated 6 months ago