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

9. Combining and Splitting Value แม้ว่าการจัดการเหรียญหลาย ๆ เหรียญจะเป็นสิ่งที่สามารถทำได้ แต่การจัดการธุรกรรมแยกต่างหากสำหรับแต่ละเหรียญในการโอนก็คงเป็นเรื่องที่น่าปวดหัวอยู่ดี ฉะนั้นแล้วเพื่อให้สามารถแยกและรวมมูลค่ากันได้ ธุรกรรมจึงสามารถมี input และ output ได้หลายรายการ ซึ่งโดยปกติแล้วจะมี input เดียวจากธุรกรรมก่อนหน้าที่มีขนาดใหญ่กว่า หรือ input จำนวนเล็ก ๆ หลาย ๆ รายการ และ output ไม่เกินสองรายการ คือ รายการหนึ่งสำหรับการชำระเงิน และอีกหนึ่งรายการสำหรับการส่งเงินทอน หากมีกลับไปยังผู้ส่ง ควรสังเกตว่า fan-out (กระจายของธุรกรรม) ซึ่งเป็นกรณีที่ธุรกรรม ธุรกรรมหนึ่งนั้นขึ้นอยู่กับหลายธุรกรรม และธุรกรรมเหล่านั้นเองก็ขึ้นอยู่กับอีกหลายธุรกรรม แต่ไม่ใช่ปัญหาในที่นี้ เพราะไม่มีความจำเป็นในการดึงประวัติการทำธุรกรรมทั้งหมดออกมาเป็นสำเนา #siamstr

8. การตรวจสอบธุรกรรม (แบบไม่ต้องรัน full node) การที่จะยืนยันการชำระเงินโดยไม่จำเป็นต้องรัน full node ได้นั้น ผู้ใช้เพียงแค่เก็บสำเนาของส่วนหัวบล็อก (block header) ของสายบล็อก (chain) ที่ยาวที่สุด ซึ่งสามารถรับได้โดยการสอบถามจาก node อื่น ๆ ในเครือข่ายจนมั่นใจว่าได้รับสายที่ยาวที่สุด และรับ Merkle branch ที่เชื่อมโยงธุรกรรมกับบล็อกที่มีการประทับเวลา (Timestamp) อยู่ ถึงแม้ผู้ใช้จะไม่สามารถตรวจสอบธุรกรรมด้วยตัวเองได้ แต่การเชื่อมโยงธุรกรรมกับตำแหน่งในสายบล็อกจะทำให้เห็นว่า node ในเครือข่ายยอมรับแล้ว และบล็อกที่เพิ่มเข้ามาหลังจากนั้นเป็นการยืนยันเพิ่มเติมว่าเครือข่ายยอมรับธุรกรรมนี้แล้ว การตรวจสอบดังกล่าวจะเชื่อถือได้ตราบใดที่ node ที่ซื่อสัตย์ยังคงควบคุมเครือข่าย แต่จะมีความเสี่ยงมากขึ้นหากเครือข่ายถูกโจมตีและถูกควบคุม ในขณะที่ node ในเครือข่ายสามารถตรวจสอบธุรกรรมได้ด้วยตัวเอง แต่วิธีการแบบง่ายนี้อาจถูกหลอกลวงโดยการใช้ธุรกรรมปลอมของผู้โจมตี ตราบใดที่ผู้โจมตียังคงสามารถควบคุมเครือข่ายได้ กลยุทธ์หนึ่งในการป้องกันปัญหานี้คือ การรับการแจ้งเตือนจาก node อื่น ๆ ในเครือข่ายเมื่อตรวจพบบล็อกที่ไม่ถูกต้อง ซึ่งจะแจ้งให้ซอฟต์แวร์ของผู้ใช้ดาวน์โหลดบล็อกแบบเต็มและธุรกรรมที่แจ้งเตือน เพื่อยืนยันความไม่สอดคล้องกัน ธุรกิจที่ได้รับการชำระเงินบ่อยครั้งอาจยังคงต้องการรัน node ของตนเอง เพื่อความปลอดภัยที่เป็นอิสระและการตรวจสอบที่รวดเร็วยิ่งขึ้น #siamstr

7. Reclaiming Disk Space เมื่อธุรกรรมถูกบรรจุลงในบล๊อกแล้ว สามารถกำจัดธุรกรรมที่ใช้ไปแล้วก่อนหน้านั้นออกได้เพื่อประหยัดพื้นที่ดิสก์ แต่การจะทำอย่างนี้ได้โดยไม่ให้เลข hash ของบล๊อกมีการเปลี่ยนแปลงนั้น ธุรกรรมจึงจำเป็นต้องถูก hash ในรูปแบบของ Merkle Tree [7][2][5] โดยมีแค่ root node ของ tree เท่านั้นที่จะรวมอยู่ใน hash ของบล๊อก นี่เป็นวิธีที่ทำให้สามารถบีบอัดข้อมูลในบล๊อกเก่า ๆ ได้โดยการตัดพวก hash ส่วนอื่น ๆ ของ tree ที่ไม่ใช่ root node ออก (ไม่จำเป็นต้องเก็บ hash ในชั้นอื่น ๆ ของ tree) โดยในส่วน header ของบล็อกที่ไม่มีธุรกรรมจะมีขนาดประมาณ 80 ไบต์ หากเราสมมติว่าบล็อกถูกสร้างขึ้นทุก ๆ 10 นาที 80 ไบต์ * 6 * 24 * 365 = 4.2MB ต่อปี โดยที่ระบบคอมพิวเตอร์ทั่วไปที่วางขายในปี 2551 มี RAM 2GB และกฎของมัวร์ทำนายการเติบโตในปัจจุบันที่ 1.2GB ต่อปี การจัดเก็บข้อมูลไม่น่าจะเป็นปัญหาแม้ว่าส่วนหัวของบล็อกจะต้องถูกเก็บไว้ในหน่วยความจำก็ตาม #siamstr [2] H. Massias, X.S. Avila, and J.-J. Quisquater, "Design of a secure timestamping service with minimal trust requirements," In 20th Symposium on Information Theory in the Benelux, May 1999. [5] S. Haber, W.S. Stornetta, "Secure names for bit-strings," In Proceedings of the 4th ACM Conference [7] R.C. Merkle, "Protocols for public key cryptosystems," In Proc. 1980 Symposium on Security and Privacy, IEEE Computer Society, pages 122-133, April 1980.

6. แรงจูงใจ โดยปกติแล้ว ธุรกรรมแรกของแต่ละบล๊อกนั้นจะเป็นธุรกรรมพิเศษที่จะขุดเหรียญที่สร้างขึ้นใหม่ซึ่งเป็นกรรมสิทธิ์ของผู้สร้างบล็อกนั้น ๆ ซึ่งจะเป็นการเพิ่มแรงจูงใจให้กับ node ต่าง ๆ ในการสนับสนุนเครือข่าย และเป็นวิธีการกระจายเหรียญให้หมุนเวียน เนื่องจากไม่มีหน่วยงานส่วนกลางที่ทำหน้าที่ในการออกเหรียญ การเพิ่มเหรียญใหม่ในปริมาณคงที่อย่างต่อเนื่องนั้นคล้ายคลึงกับการที่คนงานเหมืองทองคำใช้แรง และ เวลา เพื่อเพิ่มทองคำให้หมุนเวียน ในกรณีนี้ คือ เวลา กำลังประมวลผล และไฟฟ้าที่ถูกใช้ไป นอกจากนี้แรงจูงใจจะมาจากค่าธรรมเนียมการทำธุรกรรม หากมูลค่าผลลัพธ์ของธุรกรรมน้อยกว่ามูลค่าที่ใส่เข้ามา ส่วนต่างนั้นก็คือค่าธรรมเนียมการทำธุรกรรมที่จะเพิ่มเข้าไปในมูลค่าแรงจูงใจของบล็อกที่มีธุรกรรมนั้น เมื่อเหรียญทั้งหมดในระบบมีจำนวนเท่ากับที่กำหนดไว้แล้ว แรงจูงใจหลักก็จะถูกเปลี่ยนมาเป็นค่าธรรมเนียมการทำธุรกรรม และปราศจากภาวะเงินเฟ้อโดยสิ้นเชิง แรงจูงใจอาจช่วยกระตุ้นให้ node ต่าง ๆ ยังคงซื่อสัตย์ หากผู้โจมตีที่ละโมบสามารถรวบรวมกำลังประมวลผล ได้มากกว่า node ที่ซื่อสัตย์ทั้งหมด เขาจะต้องเลือกระหว่างการใช้มันเพื่อฉ้อโกงผู้อื่นโดยการใช้จ่ายซ้ำซ้อน หรือใช้มันเพื่อสร้างเหรียญใหม่ พวกเขาจะพบว่าการเล่นตามกฎ กฎที่เอื้อประโยชน์ให้กับเขาด้วยเหรียญใหม่มากกว่าคนอื่น ๆ รวมกันนั้นทำกำไรได้มากกว่าการบ่อนทำลายระบบและความถูกต้องของทรัพย์สินของเขาเอง #siamstr

5. Network เครือข่ายนั้นมีการทำงาน ดังนี้ 1. การประกาศธุรกรรมใหม่: ธุรกรรมใหม่จะถูกประกาศ (broadcast) ไปยังทุก node ในเครือข่าย 2. การรวบรวมธุรกรรม: แต่ละ node จะรวบรวมธุรกรรมใหม่ ๆ เหล่านี้ ไว้ในบล็อก 3. การค้นหา Proof-of-Work: แต่ละ node จะทำการคำนวณ เพื่อค้นหา Proof-of-Work ตามค่า difficulty สำหรับบล็อกนั้น ๆ 4. การประกาศบล็อก: เมื่อ node ใดค้นหา Proof-of-Work ได้แล้ว node นั้นจะทำการประกาศบล็อกไปยังทุก node ในเครือข่าย 5. การตรวจสอบและยอมรับบล็อก: node อื่น ๆ จะทำการตรวจสอบและยอมรับบล็อกนั้น เฉพาะเมื่อธุรกรรมทั้งหมดภายในบล็อกนั้นถูกต้องและยังไม่ถูกใช้มาก่อน 6. การสร้างบล็อกถัดไป: node ต่าง ๆ แสดงการยอมรับบล็อกโดยการเริ่มต้นสร้างบล็อกถัดไปใน chain ด้วย hash ของบล็อกที่ยอมรับ เป็น hash ก่อนหน้าในโครงสร้างของบล๊อกใหม่ที่กำลังสร้าง node ต่าง ๆ จะถือว่า chain ที่ยาวที่สุดเป็น chain ที่ถูกต้องและจะทำงานเพื่อขยาย chain นั้นต่อไป หากมีสอง node ที่ได้ประกาศบล็อกเวอร์ชันที่แตกต่างกันในเวลาพร้อมกัน node บาง node อาจได้รับบล็อกหนึ่งก่อน อีกบล็อกหนึ่ง ในกรณีนี้ node เหล่านั้น จะทำงานบนบล็อกที่ได้รับก่อน แต่จะเก็บสำเนาของบล็อกอีกอันหนึ่งไว้ ในกรณีที่บล็อกนั้น กลายเป็นบล็อกที่อยู่ใน chain ที่ยาวกว่าปัญหาข้อโต้แย้งนี้ก็จะได้รับการแก้ไข เมื่อพบ Proof-of-Work อันถัดไปและ chain ใด chain หนึ่งยาวขึ้น node ที่กำลังทำงานอยู่บน chain ที่สั้นกว่าก็จะเปลี่ยนไปทำงานบน chain ที่ยาวกว่าแทน การประกาศธุรกรรมใหม่ ไม่จำเป็นต้องไปถึงทุก node ในเครือข่าย ตราบใดที่พวกเขายังไปถึง node ส่วนใหญ่ในระบบได้ ธุรกรรมเหล่านั้นก็จะถูกบรรจุอยู่ในบล็อกในไม่ช้า นอกจากนี้การประกาศบล็อกยังไม่ต้องกังวลเรื่องจะมีบล๊อกที่สูญหาย เนื่องจากหากว่า node ไม่ได้รับบล็อกใด ๆ node ก็จะตระหนักได้ว่าพลาดบล็อกก่อนหน้าไปเมื่อได้รับบล๊อกใหม่มา และ node จะทำการร้องขอ block ที่ขาดไปจากเครือข่าย #siamstr

4. Proof-of-Work ในการสร้าง Timestamp Server แบบกระจายศูนย์บนพื้นฐานแบบ peer to peer เราจำเป็นต้องใช้ระบบ Proof-of-Work (PoW) ที่คล้ายกับ Hashcash ของ Adam Back [6] แทนที่จะใช้วิธีการแบบเดิม ๆ อย่างการประกาศในหนังสือพิมพ์หรือ Usenet โดย PoW ใช้ในการตรวจสอบค่าที่มาจากกระบวนการ hash เช่น SHA-256 แล้ว ผลลัพธ์ที่ได้ (Hash) จะขึ้นต้นด้วยเลขศูนย์จำนวนหนึ่ง โดยที่ work (ประมาณว่าพลังประมวลผล) ที่ต้องใช้จะเพิ่มขึ้นแบบทวีคูณตามจำนวนเลขศูนย์ที่ต้องการ และสามารถตรวจสอบได้โดยการรัน Hash เพียงครั้งเดียว ซึ่งสำหรับ timestamp network ของเรานั้น เราใช้ PoW โดยการเพิ่มค่า Nonce ในบล็อกไปเรื่อย ๆ จนกว่าจะพบค่าที่ทำให้ Hash ของบล็อกนั้นมีเลขศูนย์ตามที่กำหนด และเมื่อใช้กำลังประมวลผลของ CPU ไปกับการทำ PoW จนสำเร็จแล้ว บล็อกจะไม่สามารถเปลี่ยนแปลงได้ หากไม่มีการทำงานซ้ำใหม่ เนื่องจากบล็อกที่สร้างขึ้นภายหลังจะเชื่อมโยงกับบล็อกก่อนหน้า การเปลี่ยนแปลงบล็อกใด ๆ จะต้องทำ PoW ของบล็อกนั้นและบล็อกที่ตามมาใหม่ทั้งหมด นอกจากนี้ PoW ยังช่วยแก้ปัญหาของเสียงส่วนมากที่มาตัดสินใจในระบบนี้ เพราะหากเสียงข้างมากอ้างอิงจากหลักการหนึ่ง IP หนึ่งเสียง ใครก็ตามที่สามารถสร้าง IP ได้จำนวนมากก็จะสามารถควบคุมระบบได้ จึงใช้หลักการหนึ่ง CPU หนึ่งเสียงแทน การตัดสินใจของเสียงข้างมากจะแสดงด้วย Chain ที่ยาวที่สุด ซึ่งบ่งบอกถึงความพยายามในการคำนวณ (Proof-of-Work) ที่มากที่สุด หาก Node ที่ซื่อสัตย์ (Honest nodes) มีกำลังประมวลผลของ CPU ส่วนใหญ่อยู่ในการควบคุม Honest Chain ก็จะเติบโตเร็วที่สุดและแซงหน้า Chain อื่น ๆ ได้ ผู้โจมตีที่ต้องการแก้ไขบล็อกในอดีตจะต้องทำ Proof-of-Work ของบล็อกนั้นและบล็อกที่ตามมาใหม่ทั้งหมด และต้องทำงานให้เร็วกว่า Honest Node ด้วย ซึ่งโอกาสที่ผู้โจมตีจะตามทันนั้นจะลดลงแบบทวีคูณเมื่อมีการเพิ่มบล็อกมากขึ้น เพื่อชดเชยความเร็วของฮาร์ดแวร์ที่เพิ่มขึ้นและความสนใจในการรัน Node ที่ผันผวน ระดับความยากของ Proof-of-Work จะถูกกำหนดโดยค่าเฉลี่ย โดยตั้งเป้าไว้ที่จำนวนบล็อกเฉลี่ยต่อชั่วโมง หากสร้างบล็อกได้เร็วเกินไป ระดับความยากก็จะเพิ่มขึ้น [6] A. Back, "Hashcash - a denial of service counter-measure," 📄.pdf , 2002. #siamstr

3. Timestamp Server สำหรับแนวทางการแก้ปัญหาในครั้งนี้ เราจะใช้ประโยชน์จาก timestamp server ที่จะทำหน้าที่บันทึก hash ของบล๊อกที่ต้องการให้มีการบันทึกเวลา และจากนั้นจะทำการเผยแพร่ hash ดังกล่าว เหมือนกับหนังสือพิมพ์หรือโพสต์ใน Usenet [2-5] (ฟีลแบบทุกคนจะเห็นโพสต์นี้น้าา ประมาณนั้น) การบันทึกเวลานี้จะพิสูจน์ได้ว่าข้อมูลที่ถูก hash นั้นจะต้องมีอยู่จริงในเวลานั้นเพื่อให้ได้มาซึ่ง hash ดังกล่าว แต่ละการบันทึกเวลาจะรวมการบันทึกเวลาของหน้านี้ไว้ใน hash ของมันเพื่อสร้างเป็น chain โดยการบันทึกเวลาแต่ละครั้งจะยืนยันความถูกต้องของการบันทึกก่อนหน้าได้อีกด้วยด้วย [2] H. Massias, X.S. Avila, and J.-J. Quisquater, "Design of a secure timestamping service with minimal trust requirements," In 20th Symposium on Information Theory in the Benelux, May 1999. [3] S. Haber, W.S. Stornetta, "How to time-stamp a digital document," In Journal of Cryptology, vol 3, no 2, pages 99-111, 1991. [4] D. Bayer, S. Haber, W.S. Stornetta, "Improving the efficiency and reliability of digital time-stamping," In Sequences II: Methods in Communication, Security and Computer Science, pages 329-334, 1993. [5] S. Haber, W.S. Stornetta, "Secure names for bit-strings," In Proceedings of the 4th ACM Conference on Computer and Communications Security, pages 28-35, April 1997. #siamstr

2. Transactions นิยามของเหรียญอิเล็กทรอนิกส์ในที่นี้ คือห่วงโซ่ที่คล้องเกี่ยวกันของ digital signature โดยที่เจ้าของเหรียญอิเล็กทรอนิกส์จะโอนเหรียญไปยังเจ้าของคนถัดไป ด้วยการลง digital signature บน hash ของธุรกรรมก่อนหน้ารวมถึงกุญแจสาธารณะของเจ้าของคนถัดไป และผนวกมันไว้ที่ส่วนท้ายของธุรกรรม และผู้รับเงินเองก็สามารถตรวจสอบลายเซ็นเพื่อยืนยันความเป็นเจ้าของได้ แน่นอนว่าปัญหาก็คือผู้รับเงินไม่สามารถตรวจสอบได้ว่าเจ้าของคนใดคนหนึ่งก่อนหน้าเขาได้ใช้เหรียญดังกล่าวซ้ำซ้อนมากกว่าหนึ่งครั้งหรือไม่ และวิธีการแก้ไขปัญหานี้โดยทั่วไปก็คงเป็นการกำหนดตัวกลางที่มีความน่าเชื่อถือมาเป็นคนตรวจสอบทุกธุรกรรมเพื่อป้องกันการใช้จ่ายซ้ำซ้อน และหลังจากการทำธุรกรรมแต่ละครั้ง เหรียญจะต้องถูกส่งกลับไปยังตัวกลางเพื่อออกเหรียญใหม่ และจะมีเพียงเหรียญที่ออกจากตัวกลางโดยตรงเท่านั้นที่จะเชื่อถือได้ว่าจะไม่ถูกใช้จ่ายซ้ำซ้อน แต่ปัญหาก็คือ ชะตากรรมของระบบเงินทั้งหมดจะขึ้นอยู่กับตัวกลางตัวนี้ เพราะทุกธุรกรรมจำเป็นจะต้องผ่านพวกเขา ซึ่งก็ไม่ต่างอะไรกับธนาคาร เราจึงต้องการวิธีการที่ทำให้ผู้รับเงินทราบได้ว่าเจ้าของคนก่อน ๆ ไม่ได้ลงนามในธุรกรรมใด ๆ มาก่อน เพื่อให้บรรลุวัตถุประสงค์นี้ เราจะทำการนับว่าธุรกรรมที่เกิดขึ้นก่อนเป็นธุรกรรมที่ถูกต้อง และจะไม่สนใจความพยายามใด ๆ ในการที่จะใช้เหรียญนั้น ๆ ซ้ำอีก และวิธีเดียวที่ทำแบบนี้ได้ คือการรับรู้ถึงธุรกรรมทั้งหมด เช่นเดียวกับโมเดลที่ได้กล่าวข้างต้น ที่ตัวกลางจะรับรู้ถึงธุรกรรมทั้งหมดและตัดสินว่าธุรกรรมใดมาก่อนมาหลัง เพื่อให้บรรลุเป้าหมายนี้โดยไม่ต้องมีบุคคลที่สามที่เชื่อถือได้ ธุรกรรมทั้งหมดจะต้องถูกประกาศต่อสาธารณะ [1] และเราต้องการระบบที่ผู้เข้าร่วมเห็นพ้องในประวัติธุรกรรมชุดเดียวกันตามลำดับที่ได้รับ ส่วนผู้รับเงินก็จำเป็นจะต้องมีหลักฐานว่า ในขณะที่ทำธุรกรรม "โหนด" ส่วนใหญ่ในระบบเห็นพ้องต้องกันว่าธุรกรรมนั้นได้รับเป็นลำดับแรก(ไม่มีธุรกรรมที่ใช้เหรียญพวกนี้มาก่อน) [1] W. Dai, "b-money," 📃.txt, 1998. #siamstr

1. Introduction (white paper with Dino) ไม่ว่าใครจะใคร่ซื้อใคร่ขายอะไรใด ๆ บนอินเตอร์เน็ตนั้น ก็จำเป็นต้องพึ่งพาสถาบันการเงินในฐานะของบุคคลที่สามเพื่อดำเนินการชำระเงินทางอิเล็กทรอนิกส์เสมอ ๆ ซึ่งถึงแม้ว่าระบบนี้มันจะทำงานได้ดีสำหรับธุรกรรมส่วนใหญ่ ๆ แต่ระบบก็ก็มีจุดอ่อนอยู่ที่ยังต้องอาศัยความไว้เนื้อเชื่อใจ (trust) ในระบบนี้การทำธุรกรรมที่ไม่สามารถย้อนกลับได้อย่างสมบูรณ์นั้นมันแทบจะเป็นไปไม่ได้เลย เนื่องจากสถาบันการเงินไม่สามารถหลีกเลี่ยงการเป็นตัวกลางในการไกล่เกลี่ยข้อพิพาทต่าง ๆ ที่อาจเกิดขึ้นได้ มิหนำซ้ำต้นทุนในการไกล่เกลี่ยยังทำให้ต้นทุนการทำธุรกรรมเพิ่มสูงขึ้น และเมื่อต้นทุนสูงขึ้นขนาดของธุรกรรมที่สามารถใช้งานได้จริงก็สูงขึ้นตามไปด้วย ธุรกรรมเล็ก ๆ น้อย ๆ ก็ไม่สามารถเกิดขึ้นได้ เมื่อมีความเป็นไปได้ที่ธุรกรรมจะเกิดการย้อนกลับ ความจำเป็นในการสร้างความไว้วางใจก็ยิ่งทวีคูณมากขึ้น ผู้ค้าก็จำเป็นต้องระมัดระวังลูกค้า ต้องเรียกร้องข้อมูลมากกว่าที่จำเป็น การฉ้อโกงกลายเป็นเรื่องที่หลีกเลี่ยงไม่ได้เพราะต้นทุนและความไม่แน่นอนในทำธุรกรรมเหล่านี้ แน่นอนว่าเราสามารถหลีกเลี่ยงมันได้โดยการใช้เงินสด แต่ก็ไม่มีกลไกใดที่ทำให้สามารถใช้เงินสดผ่านช่องทางการสื่อสาร (เอาให้เข้าใจง่ายก็อินเตอร์เน็ต)ได้ โดยไม่ต้องมีตัวกลาง ;-; แปลว่าสิ่งที่จำเป็นสำหรับการแก้ไขปัญหานี้คือระบบการชำระเงินทางอิเล็กทรอนิกส์ ที่อยู่บนพื้นฐานของการพิสูจน์ด้วยการเข้ารหัสแทนที่จะเป็นความไว้วางใจ ซึ่งจะทำให้คู่สัญญาสองฝ่ายที่ยินยอมสามารถทำธุรกรรมร่วมกันได้โดยตรง โดยไม่จำเป็นต้องมีบุคคลที่สามมาคอยเป็นตัวกลาง ธุรกรรมที่ยากต่อการย้อนกลับจะช่วยปกป้องผู้ขายจากการฉ้อโกง และสามารถใช้กลไก escrow เพื่อปกป้องผู้ซื้อได้อีกด้วย ในเอกสารชุดนี้ เราขอเสนอวิธีแก้ปัญหาการใช้จ่ายซ้ำซ้อนโดยใช้เซิร์ฟเวอร์ timestamp กระจายศูนย์แบบ peer-to-peer เพื่อสร้างหลักฐานการคำนวณลำดับเวลาของธุรกรรม โดยระบบนี้จะปลอดภัยตราบใดที่กลุ่มของ node ที่ซื่อสัตย์ ยังคงมีกำลังประมวลผลที่มากกว่ากลุ่มที่ประสงค์ร้ายกับระบบ #siamstr