LearnBN
Learning_BTC&NOSTR

https://learnbn.npub.pro/

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

Public Key

npub10yqgu7q6mmrk0nywywd4x0kukx029cnqly5p4yf9ay6zthavjw2syrhcl3

NIP-05 Address

Learning@siamstr.com

NIP-57 Address

Learning@siamstr.com

Profile Code

nprofile1qqs8jqyw0qdda3m8ej8z8x6n8mwtr84zufs0j2q6jyj7jdp9m7kf89gecjq3u

Author Public Key

npub10yqgu7q6mmrk0nywywd4x0kukx029cnqly5p4yf9ay6zthavjw2syrhcl3

Show more details

Last Notes

2024-09-02 04:26:56

คิ้กค้ากกกก แน่นอนว่าคำประหลาด ๆ แบบนี้มาพร้อมกับการ "ขายของ"
โดยบทความข้างล่างนี้เกี่ยวกับการขยายตัวของ Nostr และความเป็นไปได้ที่อาจจะเกิดขึ้นในอนาคตของรีเลย์ ไม่ว่าจะเป็น
- ป้องกันสแปม
- การขยายตัวของระบบ
- รวมทั้งปัญหาต่าง ๆ ที่มีในปัจจุบันและแนวทางการแก้ปัญหา
#siamstr
#naddr1qv…ad7l

2024-09-01 06:52:32

NIP-104: การส่งข้อความแบบ E2EE โดยใช้โปรโตคอล Message Layer Security (MLS)
โดย NIP นี้ได้นำเสนอ E2EE หรือการส่งข้อความที่มีการเข้ารหัสตั้งแต่ต้นทางไปจนถึงปลายทาง โดยเสนอให้มีการเพิ่มไปทั้งแชทส่วนตัวหรือแชทกลุ่ม โดยการใช้โปรโตคอล Messaging Layer Security (MLS)
เดิมทีการส่งข้อความตรงแบบหนึ่งต่อหนึ่ง (DMs) ใน Nostr เกิดขึ้นผ่านรูปแบบที่กำหนดไว้ใน NIP-04 แต่ NIP นี้ไม่ได้รับการแนะนำ เพราะแม้ว่ามันจะเข้ารหัสเนื้อหาของข้อความแต่ความเป็นส่วนตัวของเราและคู่สนทนานั้นกลับไม่มีอยู่เลย
แต่ด้วยการมาของ NIP-44 ทำให้เรามีรูปแบบการเข้ารหัสที่อัปเดตซึ่งปรับปรุงการรับประกันความลับ แต่ก็ไม่ได้กำหนดรูปแบบใหม่สำหรับการส่งข้อความตรง โดยใช้รูปแบบการเข้ารหัสนี้ ดังนั้น จึงแทบจะไม่สร้างความแตกต่างใด ๆ กับความเป็นส่วนตัว
และล่าสุดนี้ NIP-17 ได้รวมการเข้ารหัส NIP-44 และ warp ด้วย NIP-59 เพื่อซ่อนข้อความตรงที่เข้ารหัสไว้ภายในชุดของกิจกรรมอื่น ๆ เพื่อให้แน่ใจว่าไม่สามารถมองเห็นได้ว่าใครกำลังคุยกับใคร และเมื่อใดที่ข้อความถูกส่งผ่านระหว่างผู้ใช้ ซึ่งส่วนใหญ่จะช่วยแก้ปัญหารั่วไหลของข้อมูล ในขณะที่ยังคงเป็นไปได้ที่จะเห็นว่าผู้ใช้กำลังรับ event ที่ warp แต่คุณไม่สามารถบอกได้ว่ามาจากใคร และ event ประเภทใดที่อยู่ภายใน event ที่ถูก warp ซึ่งจะช่วยให้ปฏิเสธได้ในระดับหนึ่ง แต่ก็ไม่ได้แก้ปัญหาการรักษาความลับล่วงหน้าหรือความปลอดภัยหลังการถูกบุกรุก กล่าวคือ หากกุญแจส่วนตัวของผู้ใช้ (หรือกุญแจการสนทนาที่คำนวณร่วมกันระหว่างผู้ใช้สองคนที่ใช้ในการเข้ารหัสข้อความ) ถูกโจมตี ผู้โจมตีจะสามารถเข้าถึง DMs ทั้งหมดที่ส่งผ่านระหว่างผู้ใช้เหล่านั้นได้อย่างสมบูรณ์ทั้งในอดีตและอนาคต
นอกจากนี้ ทั้ง NIP-04 หรือ NIP-17 ต่างก็ไม่ได้พยายามแก้ปัญหาของการส่งข้อความในแชทกลุ่ม
แล้วทำไมมันถึงสำคัญละ?
เพราะว่าหากปราศจาก E2EE ที่เหมาะสม Nostr จะไม่สามารถใช้เป็นโปรโตคอลสำหรับไคลเอนต์การส่งข้อความที่ปลอดภัยได้ ในขณะที่ไคลเอนต์อย่าง Signal ทำงานได้อย่างยอดเยี่ยมกับ E2EE แต่ก็ยังคงอาศัยเซิร์ฟเวอร์ส่วนกลาง ซึ่งอาจถูกปิดกั้นโดยผู้ที่มีอำนาจ และเป้าหมายของ Nostr ไม่ใช่แค่การป้องกันหน่วยงานส่วนกลางจากการเซ็นเซอร์คุณและการสื่อสารของคุณ แต่ยังรวมถึงการป้องกันไม่ให้ผู้ที่มีอำนาจระดับรัฐสามารถหยุดยั้งบริการประเภทนี้ได้ตั้งแต่แรก การแทนที่เซิร์ฟเวอร์ส่วนกลางด้วยรีเลย์แบบกระจายศูนย์ทำให้ผู้ที่มีอำนาจแทบจะเป็นไปไม่ได้เลยที่จะหยุดการสื่อสารระหว่างผู้ใช้แต่ละรายได้อย่างสมบูรณ์
แล้วทำไมต้องเป็น MLS?
การปรับใช้โปรโตคอล Message Layer Security (MLS) ให้เข้ากับการใช้งาน Nostr ลองคิดง่าย ๆ ว่า MLS เป็นวิวัฒนาการของ Signal Protocol ก็ได้ อย่างไรก็ตาม MLS ได้ปรับปรุงความสามารถในการขยายขนาดของการดำเนินการเข้ารหัสสำหรับการส่งข้อความกลุ่มขนาดใหญ่ได้อย่างมาก (linear -> log) โดยสร้างขึ้นเพื่อรองรับสภาพแวดล้อมแบบรวมศูนย์ และยังช่วยให้อัปเดตชุดรหัสและเวอร์ชันได้อย่างราบรื่นเมื่อเวลาผ่านไป นอกจากนี้ยังมีความยืดหยุ่นสูงและข้อความเข้ารหัสที่ส่งในระบบนั้นไม่ขึ้นอยู่กับเนื้อหาของข้อความที่ส่ง การอธิบายโปรโตคอล MLS นั้นอยู่นอกเหนือขอบเขตของ NIP นี้ แต่คุณสามารถอ่านเพิ่มเติมได้ในภาพรวมทางสถาปัตยกรรมหรือ RFC MLS กำลังอยู่ระหว่างการพัฒนาเป็นมาตรฐานอินเทอร์เน็ตภายใต้ IETF ดังนั้นโปรโตคอลจึงได้รับการตรวจสอบและวิจัยมาเป็นอย่างดี ซึ่งหมายความว่า MLS มีศักยภาพในการทำงานร่วมกันของการส่งข้อความข้ามเครือข่ายได้ในอนาคต เมื่อ MLS ได้รับการยอมรับมากขึ้น
MLS มีจุดเด่นอะไรที่จะมาช่วยพัฒนา Nostr ได้บ้าง?
- ความเป็นส่วนตัวและความปลอดภัย: แม้ว่าระบบการส่งข้อความส่วนตัวบน nostr ที่มีอยู่แล้วและมีความปลอดภัยที่สูง(NIP-04, NIP17) แต่ในแง่ของความเป็นส่วนตัวนั้นยังบกพร่องอยู่ ซึ่งในจุดนี้เองที่ MLS สามารถเข้ามาช่วยเพิ่มความเป็นส่วนตัวได้
- ความหยืดหยุ่น: MLS นั้นมีระบบการจัดการข้อความแบบกลุ่ม ซึ่งสามารถจัดการได้อย่างมีประสิทธิภาพสูง ซึ่งน่าจะเข้ามาช่วยเสริม
- การสอดคล้องกับการกระจายอำนาจ: การใช้ประโยชน์จากโครงสร้างพื้นฐานรีเลย์แบบกระจายอำนาจที่มีอยู่ของ Nostr สำหรับการส่งข้อความ MLS ทำให้สามารถส่งข้อความได้อย่างปลอดภัย และมีความเป็นส่วนตัวมากขึ้น
เป้าหมายของ NIP นี้
- ข้อความตรงและข้อความกลุ่มแบบส่วนตัวและเป็นความลับ
- ส่วนตัว หมายความว่าผู้สังเกตการณ์ไม่สามารถบอกได้ว่าอลิซและบ็อบกำลังคุยกันอยู่ หรืออลิซเป็นส่วนหนึ่งของกลุ่มใดกลุ่มหนึ่ง ซึ่งจำเป็นต้องมีการปกป้องข้อมูล
- เป็นความลับ หมายความว่าเฉพาะผู้รับที่ต้องการเท่านั้นที่สามารถดูเนื้อหาของการสนทนาได้
- การรักษาความลับล่วงหน้าและความปลอดภัยหลังการถูกบุกรุก
- การรักษาความลับล่วงหน้า หมายความว่าเนื้อหาที่เข้ารหัสในอดีตจะยังคงถูกเข้ารหัสอยู่ แม้ว่ากุญแจจะรั่วไหลก็ตาม
- ความปลอดภัยหลังการถูกบุกรุก หมายความว่าการรั่วไหลของคีย์ไม่อนุญาตให้ผู้โจมตีอ่านข้อความในอนาคตได้อย่างไม่มีกำหนด
- ปรับขนาดได้อย่างมีประสิทธิภาพสำหรับกลุ่มขนาดใหญ่
- อนุญาตให้ใช้อุปกรณ์/ไคลเอนต์หลายเครื่องในการสนทนา/กลุ่มเดียว

2024-08-28 05:29:16

Mining & Pool
Mining หรือการขุด เป็นอีกหนึ่งสิ่งที่เป็นพื้นฐานของระบบบิตคอยน์ ซึ่งดำเนินการโดยการนำกำลังประมวลผลมาแข่งกันในการหา hash ให้เข้าเป้า เพื่อที่จะให้ได้รับสิทธิ์ในการใส่บล๊อกที่ตนสร้างลงไปในบล๊อกเชนของบิตคอยน์ และนักขุดที่สามารถหา nonce ที่ทำให้ hash เข้าเป้าได้ก่อนก็จะได้รับบิตคอยน์ที่ถูกผลิตขึ้นใหม่ในบล๊อกนั้น ๆ และ ค่าธรรมเนียมจากการทำธุรกรรมต่าง ๆ ในบล๊อกนั้น ๆ อีกด้วย แต่หลังจากเครือข่ายของบิตคอยน์ได้มีการเจริญเติบโตขึ้นเรื่อย ๆ ทำให้การแข่งขันกันของเหล่านักขุดก็เกิดขึ้นด้วย เมื่องแรงขุดในระบบเพิ่มขึ้น ความยากในการหา hash ที่จะตรงกับเป้าหมายก็ยากขึ้นเรื่อย ๆ ตาม difficulty adjustment algorithm อีกด้วย ด้วยเหตุนี้เองจึงทำให้โอกาสที่นักขุดที่ขุดด้วยตัวคนเดียวจะสามารถได้รับบิตคอยน์จากการขุดนั้นยากขึ้นเรื่อย ๆ เหล่าบรรดานักขุดจึงเริ่มมีการรวมกำลังในการขุดของแต่ละคน เพื่อเพิ่มโอกาสที่จะได้รับบิตคอยน์จากการขุด จึงเกิดเป็นสิ่งที่เรียกว่า Mining Pool ในภายหลัง
Mining Pool คืออะไร?
Mining Pool คือการรวมกันของกำลังขุดจากนักขุดแต่ละคน เพื่อที่จะเพิ่มโอกาสในการได้รับบิตคอยน์จากการขุด โดยหาก pool ของพวกเขาได้รับบิตคอยน์มาก็จะทำการอจกจ่ายไปให้กับสมาชิกใน pool ตามแรงขุดที่แต่ละคนส่งมา และด้วยสิ่งนี้เองทำให้ mining pool ได้เข้ามาแก้ปัญหาของความยากที่เพิ่มขึ้นในการขุดบิตคอยน์ และนอกจากการเพิ่มโอกาสในการได้บิตคอยน์จากการขุดแล้ว อีกเหตุผลที่มักจะทำให้นักขุดเข้าร่วมกับ pool ต่าง ๆ คือการที่จะสามารถเพิ่มความสเถียรของรายได้
จะเกิดอะไรขึ้นถ้ามี pool ใด ๆ ที่รวมกำลังขุดเกิน 51 % ? จะมีปัญหาอะไรไหม ?
ในกรณีนี้ก็ต้องบอกว่าขึ้นอยู่กับนโยบายของ pool นั้น ๆ หาก pool นั้น ๆ ยังเล่นตามกติกา ไม่มีการเซนเซอร์ใด ๆ และมุ่งเน้นไปที่การทำบล๊อกเทมเพสที่ได้ค่าธรรมเนียมมากที่สุด และกระจายบิตคอยน์ที่ได้กับนักขุดอย่างยุติธรรม ก็อาจจะเป็นแรงจูงใจที่ทำให้นักขุดที่อยากจะส่งแรงขุดไปที่ pool นั้น ๆ และหาก pool ไหนที่พยายามจะแซกแซงระบบไม่ว่าจะเป็นการ เซนเซอร์ธุรกรรมหรืออื่น ๆ แน่นอนว่าการทำแบบนั้นย่อมส่งผลโดยตรงกับกำไรที่นักขุดจะได้รับ แล้วทำไมเหล่านักขุดถึงจะต้องส่งกำลังขุดไปยัง pool เหล่านั้น และการแก้ไขปัญหาหากมีเรื่องแบบนี้เกิดขึ้น เหล่านักขุดก็สามารถที่จะย้ายกำลังขุดของตัวเองทั้งหมด ไปยัง pool ใหม่ หรือจะกลับมาขุดด้วยตัวเองก็เป็นเรื่องที่สามารถทำได้โดยง่ายและไม่มีต้นทุนใด ๆ ในการย้ายนอกจากเวลา
#siamstr

2024-08-21 09:35:03

OP_CHECKTEMPLATEVERIFY (CTV)
OP_CHECKTEMPLATEVERIFY (CTV) เป็นโอปโค้ดใหม่ที่ถูกเสนอขึ้น โดยรับค่าแฮชของข้อผูกมัดเป็นพารามิเตอร์ และกำหนดให้ธุรกรรมใด ๆ ที่ดำเนินการด้วยโอปโค้ดนี้ต้องมีชุดของเอาต์พุตที่ตรงกับข้อผูกมัดนั้น ด้วยสิ่งนี้เอง ทำให้สามารถสร้างที่อยู่ที่ระบุวิธีการใช้จ่ายเงินใด ๆ ที่ได้รับไปยังที่อยู่นั้นได้ ซึ่งเป็นการออกแบบที่รู้จักใน Bitcoin ว่าเป็นพันธสัญญา (covenant)
เดิมทีนำเสนอภายใต้ชื่อ OP_CHECKOUTPUTSHASHVERIFY (COSHV) ซึ่งข้อเสนอนี้มุ่งเน้นไปที่ความสามารถในการสร้างธุรกรรมโดยใช้ congestion control (คล้าย ๆ กันกับที่ใช้คุมการไหลของ data packets ใน TCP ) ซึ่งผู้ใช้จ่ายเงินไปยังที่อยู่เดียวโดยใช้ CTV ซึ่งเมื่อได้รับการยืนยันในระดับที่เหมาะสมแล้ว จะทำให้ผู้รับหลายรายมั่นใจได้ว่าพวกเขาแต่ละคนจะได้รับเงิน กระบวนการสองขั้นตอนนี้น่าจะสามารถใช้ได้ทุกที่ ที่มีตัวเลือกการรวมการชำระเงิน (payment batching) โดยมีแนวโน้มว่าจะสามารถช่วยลดค่าธรรมเนียมได้มากกว่าการรวมการชำระเงิน
ข้อเสนอในเวอร์ชันต่อ ๆ มา มีการให้ความสำคัญกับสัญญาและพันธสัญญาอื่น ๆ ที่สามารถสร้างได้โดยใช้โอปโค้ดใหม่ เช่น ความสามารถในการสร้าง กระเป๋าสตางค์ (vaults) และธุรกรรม CoinJoin ในรูปแบบใหม่ที่อาจช่วยลดความซับซ้อนในการสร้างหรือลดค่าธรรมเนียมลงได้ นอกจากนี้ผู้เขียนท่านอื่น ๆ ได้กล่าวถึงว่าโอปโค้ดใหม่อาจใช้เพื่อให้ผู้ใช้สามารถรวมเงินทุนของตนเข้าด้วยกันใน UTXO เดียวได้อย่างน่าเชื่อถือและความเป็นส่วนตัวมากยิ่งขึ้น
การทำงานของ OP_CHECKTEMPLATEVERIFY
OP_CHECKTEMPLATEVERIFY ใช้โอปโค้ด OP_NOP4 (0xb3) เป็นการอัปเกรดซอฟต์ฟอร์ก
OP_CHECKTEMPLATEVERIFY ทำงานดังนี้:
- ต้องมีอย่างน้อยหนึ่งองค์ประกอบบนสแต็ก ไม่งั้นจะไม่สามารถทำงานได้
- องค์ประกอบบนสแต็กต้องมีความยาว 32 ไบต์ หากไม่ใช่จะทำเป็น NOP (No Operation)
- DefaultCheckTemplateVerifyHash ของธุรกรรม ณ ดัชนีอินพุตปัจจุบันต้องเท่ากับองค์ประกอบบนสแต็ก หากไม่เท่ากันจะล้มเหลว
- DefaultCheckTemplateVerifyHash ผูกมัดกับ: เวอร์ชัน,ล็อกไทม์, แฮชของ ScriptSigs (ถ้ามี ScriptSigs ที่ไม่ใช่ค่า Null), จำนวนอินพุต, แฮชของลำดับ, จำนวนเอาต์พุต, แฮชของเอาต์พุต, ดัชนีอินพุตที่กำลังดำเนินการอยู่
กฎมาตรฐานที่แนะนำเพิ่มเติม:
ปฏิเสธข้อมูลที่ไม่ใช่ 32 ไบต์ เป็น SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS
detail มากกว่านี้: https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki

2024-08-19 02:50:33

ฮี่ ๆ ไม่ใช้คำเดิมละเดี๋ยวโดนจับได้อีก แต่วันนี้ผมมีของใหม่มานำเสนอ
#naddr1qv…cje5
#siamstr

2024-08-18 05:43:24

Event
Event คืออะไร?
Event เป็น object เพียงประเภทเดียวที่มีอยู่บน Nostr โดยมีโครงสร้างประมาณนี้
```
{"id":"84d5d3dc9c388a702f39cad6360d41ebb804e809fb822f110ff8a14dfd35fc6c",
"pubkey":"66df60562d939ada8612436489945a4ecf1d62346b3d9478dea8a338f3203c64",
"created_at":1722315959,
"kind":1,
"tags":[["t","siamstr"]],
"content":"ไปสั่งกาแฟเมื่อกี้ พส เจ้าของร้านชมว่าเดี๋ยวนี้คล่องภาษาญี่ปุ่นแล้วนะ ไอเราก็ดีใจ พอเดินกลับถึงที่ทำงานละก็ตระหนักได้ว่า ตะกี้เราสั่ง “ไอซ์โคฮี โอเนไงชิมัส” “เทคเอาส์” “คาโดะเดสส” ไอบ้าไหนญี่ปุ่นก่อนอังกฤษทั้งนั้น 🤣🤣\n\n#siamstr",
"sig":"8f066a0099a5f580b605ebdb220179c4eca298947c38b855a0a8bf2783f28ddb537cb74a7f61d3ce8891189f719870efdf320ea4f895e03cdac44284c450c5c4"}
```
อย่าง Event ข้างต้นนี้มี kind เป็น 1 ซึ่งหมายถึง "ข้อความโน้ต" ซึ่งก็คือข้อความธรรมดา สั้น ๆ คล้ายกับที่ใช้กันใน Twitter เช่น บนฟีด การตอบกลับ และการโควท
ประเภทของ Event (Event Kinds)
หมายเลขของ kind แต่ละตัวมีความหมายแตกต่างกัน ตัวอย่างเช่น 0 หมายถึงอีเวนต์ "ข้อมูลเมตา" ใช้สำหรับให้รายละเอียดเกี่ยวกับผู้ใช้ เช่น ชื่อและรูปโปรไฟล์ รีเลย์ (Relays) สามารถจัดการกับ kind ที่แตกต่างกันได้ เช่น รีเลย์มักจะลบอีเวนต์ kind:0 เวอร์ชันเก่ากว่าออกไป และเก็บไว้เฉพาะเวอร์ชันล่าสุด ในขณะที่โดยทั่วไปจะเก็บอีเวนต์ kind:1 ไว้หลายรายการสำหรับแต่ละคีย์
โดยทั่วไปแล้ว คุณไม่จำเป็นต้องใช้ kind เกินกว่า 0 และ 1 ในการสร้างแอปพลิเคชันโซเชียลมีเดียบน Nostr แต่ kind อื่น ๆ ถูกคิดค้นขึ้นโดยไคลเอนต์ เพื่อมอบฟังก์ชันการทำงานอื่น ๆ ตามที่ระบุไว้ใน NIP บาง kind ไม่เกี่ยวข้องกับเครือข่าย และให้บริการตามความต้องการอื่น ๆ ของไคลเอนต์ที่เฉพาะเจาะจงกับฟังก์ชันการทำงานเหล่านั้น ซึ่งแนวคิดก็คือ สำหรับกรณีการใช้งานใหม่ ๆ แต่ละกรณี จะต้องมีการพิจารณาและเสนอซับโปรโตคอลเป็น NIP เพื่อให้สามารถทำงานร่วมกับไคลเอนต์ที่มีอยู่และในอนาคต ซึ่งอาจสนใจที่จะนำฟังก์ชันการทำงานนั้นไปใช้ ขณะเดียวกันก็มั่นใจได้ถึงความเข้ากันได้ย้อนหลัง และการรองรับสิ่งต่าง ๆ ที่มีอยู่และไม่ต้องการเปลี่ยนแปลง
คุณสมบัติอื่น ๆ ของ Event
created_at: เป็น Timestamp ของ UNIX ที่กำหนดโดยผู้สร้างอีเวนต์ โดยปกติจะเป็นเวลาที่สร้าง แม้ว่าจะไม่มีการตรวจสอบ แต่ก็ไม่ใช่ปัญหา
content: ขึ้นอยู่กับความหมายของ kind ในกรณีของ kind:1 จะเป็นเพียงสตริงข้อความธรรมดาที่คนอื่น ๆ อ่านได้
tags: ขึ้นอยู่กับ kind เช่นกัน แต่แท็กทั่วไปบางอย่างที่มักปรากฏในอีเวนต์ kind:1 และ kind อื่นๆ คือ "p" ซึ่งใช้เพื่อกล่าวถึงคีย์สาธารณะ และ "e" ใช้เพื่ออ้างถึงอีเวนต์อื่น
อยากแชร์ไปให้คนที่ไม่ได้อยู่บน Nostr อ่านอย่างงั้นเหรอ !?!?!?!? งั้นทางเราขอแนะนำ: https://learnbn.npub.pro/

2024-08-17 11:58:37

Nostr Implementation Possibilities (NIPs)
NIP คืออะไร?
NIP มีไว้เพื่อส่งเสริมความสามารถในการทำงานของ Nostr และเป็นตัวคอยกำหนดให้ เหล่านักพัฒนาทำสิ่งต่าง ๆ ที่เหมือนกันในรูปแบบเดียวกัน เพราะมันคงไม่ใช่ความคิดที่ดีนัก หากนักพัฒนาแต่ละคนจะคิดค้นวิธีแก้ปัญหาทั่วไปของตัวเองและนำไปใช้ในแอปของตัวเองเท่านั้น และคงจะเป็นการดีกว่า ถ้าหากทุกคนใช้วิธีแก้ปัญหาที่เหมือนกัน นั่นคือเหตุผลที่ต้องมี NIP อยู่ในโปรโตคอลของ Nostr และในทำนองเดียวกัน แนวคิดใหม่อาจดูดีในแอปของนักพัฒนาบางราย แต่จะดูดียิ่งขึ้นอย่างแน่นอนหากแอปอื่น ๆ อีกมากมายใช้มาตรฐานเดียวกันและสามารถทำงานร่วมกันได้อย่างราบรื่น
ทำไมมันถึงหน้าสนใจ?
อย่าลืมว่า Nostr เป็นระบบแบบกระจายอำนาจและไม่ได้มีบริษัทหรือใครที่เป็นเจ้าของมัน อย่างเช่นโซเชียลมีเดียอื่น ๆ เช่น ทวิตเตอร์ อ่อไม่สิตอนนี้คงต้องเรียกมันว่า X สินะ ซึ่งหมายความว่าทิศทางของโพรโทคอล Nostr นั้นขึ้นอยู่กับพวกเราทุกคน! ไม่ว่าใคร ๆ ก็สามารถเสนอแนะและสนับสนุนการเปลี่ยนแปลงและให้ข้อเสนอแนะเกี่ยวกับแนวคิดที่ผู้อื่นเสนอ และการที่คุณเป็นส่วนหนึ่งของชุมชนนี้ ก็ทำให้คุณมีส่วนร่วมในทิศทางของ Nostr อีกด้วย
จากที่ส่งหากันได้แค่ข้อความ มาเป็นรูปภาพ มาเป็นวิดีโอ และมาเป็น”เงิน” นี่คือเส้นทางการเดินทางของโปรโตคอลนี้ในอดีต แล้วในอนาคตมันจะพัฒนาไปยังไงต่อก็ขึ้นอยู่กับเหล่าผู้ใช้งานและนักพัฒนาในอนาคต แล้วทำไมสิ่งนี้ถึงจะไม่น่าสนใจละ ?
อย่างแชร์ไปให้คนที่ไม่ได้อยู่บน Nostr อ่านอย่างงั้นเหรอ !?!?!?!? งั้นทางเราขอแนะนำ: https://learnbn.npub.pro/

2024-08-16 05:31:53

รีเลย์คืออะไร?
รีเลย์เปรียบเสมือนเซิร์ฟเวอร์ที่อยู่เบื้องหลังของ Nostr และทำหน้าที่รับ event ต่าง ๆ มาจากไคลเอนต์ Nostr และอาจจะจัดเก็บและกระจายข้อความเหล่านั้นไปยังไคลเอนต์อื่น ๆ ที่มีการเชื่อมต่ออยู่
เทคโนโลยีของรีเลย์นั้นเปลี่ยนแปลงอย่างรวดเร็ว ดังนั้นคาดว่าจะมีการเปลี่ยนแปลงอีกมากมายในอนาคต อย่างในปัจจุบันที่มีการนำเสนอ bostr หรือ รีเลย์ที่จะคอยส่ง event ของเราต่อให้กับรีเลย์อื่น ๆ ที่มีการเชื่อมต่อ เพื่อช่วยลดภาระของไคลเอนต์ในการรับส่งข้อมูลจากหลาย ๆ รีเลย์พร้อม ๆ กัน หรืออย่างการป้องกันสแปมด้วย POW หรือประเภทที่สามารถเก็บรูปหรือวิดีโอที่มีขนาดใหญ่ได้
แต่สิ่งหนึ่งที่ควรทราบก็คือ การที่ Nostr นั้นพยายามจะกระจายศูนย์และเหตุผลหลัก ๆ ที่สามารถทำแบบนั้นได้ก็ขึ้นอยู่กับรีเลย์ในการจัดเก็บและดึงข้อมูล ดังนั้น หากคุณรู้สึกว่าไคลเอนต์ Nostr ของคุณทำงานช้า ส่วนใหญ่ก็มักเกิดจากรีเลย์ที่คุณกำลังเชื่อมต่ออยู่ คุณอาจลองแก้ไขปัญญาโดยการเปลี่ยนหรือเพิ่มรีเลย์อีกสองสามรายการในไคลเอนต์ที่คุณใช้
แล้วจะสามารถหารายการรีเลย์ได้จากไหน?
การที่เราจะหารายการรีเลย์ที่เราควรเชื่อมต่อนั้น ๆ จริงแล้ว ๆ สามารถทำได้หลายวิธี แต่วิธีที่ผมแนะนำที่สุดจะเป็นการใช้ตามคนที่เราติดตามอยู่ เพราะจะเป็นวิธีที่เราสามารถเห็น event ต่าง ๆ ของคนที่เราติดตามได้ง่ายที่สุด และเช่นเดียวกัน เพื่อน ๆ หรือคนที่เราติดตามก็จะสามารถเห็น event ของเราได้เช่นกัน และสำหรับในประเทศไทย เรามีรีเลย์ที่คนไทยส่วนใหญ่นิยมใช้กันอยู่สองอัน นั้นคือ wss://relay.siamstr.com/ และ wss://relay.notoshi.win/ ถ้าหากว่าอยากเห็นคนไทยเยอะ ๆ บนหน้าไทม์ไลน์ ผมแนะนำเป็นอย่างยิ่งว่าควรเพิ่ม รายการรีเลย์เหล่านี้ลงไปในบัชญีหรือไคลเอนต์ต่าง ๆ ที่คุณใช้ด้วย
สำหรับอีกวิธีหนึ่งผมแนะนำให้เข้าไปในเว็บไซต์ nostr.watch เนื่องจากในเว็บไซต์นี้เป็นแหล่งข้อมูลที่ดีที่สุดสำหรับการค้นหาและประเมินความเร็วของรีเลย์ต่าง ๆ
จะเกิดอะไรขึ้นถ้ารีเลย์ทั้งหมดที่ฉันเชื่อมต่ออยู่หยุดให้บริการ?
สิ่งนี้เป็นสิ่งที่คุณต้องระวังมากที่สุดในการใช้งาน nostr เนื่องจากหากรีเลย์ทั้งหมดที่คุณเก็บข้อมูลไว้หยุดให้บริการทั้งหมดและคุณไม่มีการสำรองข้อมูล event ของคุณเก็บไว้เลย มันแปลว่าโพสต์ทั้งหมดของคุณ ผู้ติดตาม และรายการต่าง ๆ ที่คุณสรรค์สร้างไว้จะไม่สามารถกู้คืนได้ไปตลอดการ นี่จึงเป็นเหตุผลหลัก ๆ ที่ Nostr อนุญาตให้ผู้ใช้งานนั้นสามารถเชื่อมต่อกับรีเลย์ได้เป็นจำนวนมาก ก็เพื่อให้แน่ใจว่ามีข้อมูลสำรองเก็บไว้อยู่ที่ใดที่หนึ่งในระบบเสมอ แต่อย่างไรก็ตาม หากคุณต้องการที่จะมั่นใจได้ว่าข้อมูลต่าง ๆ ของคุณจะไม่ถูกเซ็นเซอร์ สิ่งที่คุณสามารถสามารถทำได้คือการใช้รีเลย์ส่วนตัวของคุณและกำหนดนโยบายต่าง ๆ ภายในรีเลย์ของคุณด้วยตัวคุณเอง
แล้วฉันจะสามารถใช้รีเลย์ส่วนตัวได้อย่างไร?
*อะแฮ่ม ๆ ขอบอกไว้ก่อนว่ามันไม่คุ้มค่ากับความยุ่งยากสำหรับคนโดยทั่ว ๆ ไป ถึงในปัจจุบันจะมีเทคโนโลยีบางตัวที่เข้ามาช่วยให้มันทำได้ง่ายขึ้นแล้วก็ตาม
หากคุณต้องการที่จะสำรองข้อมูลนั้น การที่จะมีรีเลย์ส่วนตัวที่ออนไลน์ตลอดเวลาอาจเป็นเรื่องที่ไม่ได้จำเป็นขนาดนั้น เนื่องจากเราสามารถใช้งานบริการอย่าง https://nostrsync.live/ ในการดาวน์โหลดข้อมูลของเราจากรีเลย์ต่าง ๆ ได้ หรือการติดตั้งรีเลย์ส่วนตัวอย่าง nostr-relay-tray: https://github.com/CodyTseng/nostr-relay-tray ที่ช่วยให้เราสามารถมีรีเลย์ส่วนตัวที่ใช้สำหรับสำรองข้อมูลได้
อย่างแชร์ไปให้คนที่ไม่ได้อยู่บน Nostr อ่านอย่างงั้นเหรอ !?!?!?!? งั้นทางเราขอแนะนำ: https://learnbn.npub.pro/

2024-08-15 06:03:26

ไคลเอนต์คืออะไร?
หากจะอธิบายให้เห็นภาพอยากให้มองว่าไคลเอ็นต์ Nostr นั้นเป็นเหมือนกับแอปที่คุณใช้งานเพื่อเข้าถึง Twitter, Facebook, youtube เป็นต้น พวกมันคือ แอปพลิเคชัน, เว็บแอป ที่เชื่อมต่อคุณกับโลกของ Twitter, Facebook, youtube โดยตัวของไคลเอนต์ใน Nostr เองก็เปรียบเสมือนแอปต่าง ๆ ที่คุณใช้ดูหน้าฟีดนั่นเอง แต่ข้อดีของ Nostr ที่เหนือแอปพลิเคชันอื่น ๆ คือความเรียบง่ายและยืดหยุ่น ส่งผลให้ไคลเอ็นต์แต่ละตัวมีวิธีนำเสนอและใช้งานที่แตกต่างกันไป บางไคลเอ็นต์อาจออกแบบให้ใช้งานง่ายเหมือน Twitter บางตัวเน้นให้เห็นบทบาทสำคัญของรีเลย์ หรือโหนดที่กระจายข้อมูลอยู่ทั่วโลก บางตัวใช้ระบบอัลกอริทึมเพื่อให้แน่ใจว่าข้อมูลไม่ถูกปิดกั้น โดยไม่ทำให้ผู้ใช้งานรู้สึกยุ่งยาก
เรียบง่ายและยืดหยุ่น?
เนื่องจากการออกแบบของโปรโตคอลที่ทำการแยกข้อมูลของผู้ใช้ทั้งหมดออกจากไคลเอนต์ ทำให้ตัวของผู้ใช้งานเองนั้นมีอิสระเต็มที่ที่จะเลือกใช้ไคลเอนต์ต่าง ๆ เพื่อเข้าใช้งาน Nostr และแน่นอนว่า ผู้ใช้งานสามารถสลับหรือลงชื่อเข้าใช้ ไคลเอ็นต์ได้หลายตัวตามต้องการ ตราบใดที่ไคลเอ็นต์ทั้งหมดเชื่อมต่อกับชุดรีเลย์เดียวกัน คุณก็จะเห็นข้อมูลเดียวกันในทุก ๆ ไคลเอ็นต์
ลงชื่อเข้าใช้ ไคลเอ็นต์หลาย ๆ ตัวแล้วจะกระทบต่อความปลอดภัยของแอคเคาร์ไหม?
คำตอบของคำถามนี้นั้นขึ้นอยู่กับวิธีการที่คุณลงชื่อเข้าใช้ หากคุณลงชื่อเข้าใช้ด้วยกุญแจส่วนตัว ถึงแม้ว่าไคลเอ็นต์ส่วนใหญ่จะพยายามรักษาความปลอดภัยของกุญแจส่วนตัวอย่างดีที่สุด แต่ด้วยข้อจำกัดของซอฟต์แวร์ ย่อมมีความเสี่ยงที่จะเกิดช่องโหว่ การเจาะระบบ และข้อผิดพลาด ที่อาจทำให้กุญแจส่วนตัวของคุณรั่วไหลออกไปได้ ส่วนวิธีการป้องกันเกี่ยวกับเรื่องนี้คือการใช้ส่วนขยายของเว็บเบราว์เซอร์ เพราะการเข้าสู่ระบบในไคลเอนต์ต่าง ๆ ผ่านส่วนขยายนั้นจะใช้เพียงกุญแจสาธารณะในการเข้าสู่ระบบและทุกครั้งที่เราต้องการจะโพสต์หรือสร้าง event บน Nostr ไคลเอนต์จะทำการร่าง event นั้น ๆ และเว้นช่องของลายเซ็นเอาไว้จากนั้นเราจะต้องทำการเซ็นผ่านส่วนขยาย ด้วยวิธีนี้ทำให้กุญแจส่วนตัวของเราไม่หลุดออกไปไหนตลอดการใช้งาน
#siamstr
อย่างแชร์ไปให้คนที่ไม่ได้อยู่บน Nostr อ่านอย่างงั้นเหรอ !?!?!?!? งั้นทางเราขอแนะนำ: https://learnbn.npub.pro/

2024-08-14 05:37:50

องค์ประกอบของโปรโตคอลที่ชื่อว่า Nostr
หลังจากได้ทำความรู้จัก Nostr กันไปแล้วเมื่อคราวก่อน คราวนี้เรามาเจาะดูองค์ประกอบของโปรโตคอลนี้กันดีกว่า
Keys ระบบบัญชีผู้ใช้และรหัสผ่านสำหรับ Nostr
บัญชี Nostr แต่ละบัญชีจะใช้คู่กุญแจสาธารณะ/ส่วนตัว (Public/Private Key ) เปรียบเทียบง่าย ๆ คือ กุญแจสาธารณะของคุณคือชื่อผู้ใช้ และกุญแจส่วนตัวก็เป็นรหัสผ่าน แต่ว่า ก็มีข้อแตกต่างที่สำคัญอยู่ นั่นคือ กุญแจส่วนตัวของคุณนั้นจะไม่สามารถรีเซ็ตได้หากเกิดการสูญหายขึ้น คุณจะเสียบัญชีนั้นไปตลอดกาล
โดยทั่วไปแล้ว กุญแจสาธารณะจะแสดงเป็นข้อความที่ขึ้นต้นด้วย npub1 และกุญแจส่วนตัวจะขึ้นต้นด้วย nsec1
ทั้งนี้คุณควรที่จะตรวจสอบให้แน่ใจว่าคุณได้เก็บกุญแจส่วนตัวของคุณไว้ในที่ปลอดภัย เช่น โปรแกรมจัดการรหัสผ่านอย่างเช่น Bitwarden
โปรโตคอลกับไคลเอนต์ ต่างกันอย่างไร?
Nostr เองเป็นเพียงโปรโตคอล หมายความว่า Nostr นั้นเป็นเพียงกระบวนการที่ตกลงกันไว้สำหรับการส่งข้อความผ่านอินเทอร์เน็ต (เหมือนข้อกำหนด)
ซึ่งการที่คุณจะเข้าถึง Nostr (โปรโตคอล) นั้น ผู้ใช้ส่วนใหญ่จะใช้งานผ่านไคลเอนต์ ซึ่งตัวของไคลเอนต์นั้นอาจเป็นเว็บ แอปพลิเคชันเดสก์ท็อป หรือ แอปพลิเคชันมือถือ โดยไคลเอนต์สามารถดึงข้อมูลจากรีเลย์ และสร้างข้อมูลใหม่ และส่งข้อมูลนั้นไปยังรีเลย์เพื่อให้ผู้ใช้คนอื่น ๆ สามารถเรียกอ่าน ข้อมูลนั้น ๆ ได้ โดย "ข้อมูล" เพียงรูปแบบเดียวที่มีอยู่ใน Nostr คือสิ่งที่เราเรียกกันว่า event
การพิสูจน์ความเป็นเจ้าของข้อมูลบน Nostr
บน Nostr นั้นการพิสูจน์ตัวตนเป็นเรื่องที่ง่ายมากเนื่องจากทุก ๆ event ที่เกิดขึ้น *จำเป็น*ต้องมีลายเซ็นดิจิทัล (Digital Signature) โดยลายเซ็นนั้นจะช่วยให้มั่นใจได้ว่า ใครเป็นผู้สร้าง event นั้น ๆ ขึ้นมา โดยการพิสูจน์ทางคณิตศาสตร์
โดยในการสร้างลายเซ็นแต่ละครั้ง ไคลเอนต์จะจำเป็นต้องใช้กุญแจส่วนตัวของคุณ โดยทั่วไปแล้ว แอปพลิเคชันเจะมีที่ให้คุณใส่กุญแจส่วนตัวของคุณ เมื่อเปิดแอปพลิเคชันครั้งแรก พวกเขาสามารถคำนวณกุญแจสาธารณะของคุณได้จากกุญแจส่วนตัวเช่นกัน
ส่วนในกรณีที่คุณใช้งานผ่านเว็บแอป ผมไม่แนะนำให้ใส่กุญแจส่วนตัวลงไป แต่แนะนำให้ใช้ส่วนขยายของเบราว์เซอร์ ที่ใช้งานฟังก์ชันที่เกี่ยวข้องกับ Nostr ซึ่งอนุญาตให้เว็บไคลเอ็นต์ส่ง event ที่ยังไม่ถูกเซ็นมาให้ส่วนขยายและส่วนขยายจะทำหน้าที่เซ็น สำหรับวิธีนี้ เว็บไคลเอ็นต์ต่าง ๆ ไม่จำเป็นต้องรู้กุญแจส่วนตัวของคุณ แต่คุณก็ยังสามารถลงนามใน event ต่าง ๆ ได้ตามปกติ โดยส่วนขยายที่ได้รับความนิยมก็จะเป็น Flamingo, Alby และ nos2x
#siamstr
อย่างแชร์ไปให้คนที่ไม่ได้อยู่บน Nostr อ่านอย่างงั้นเหรอ !?!?!?!? งั้นทางเราขอแนะนำ: https://learnbn.npub.pro/

2024-08-12 07:44:09

Nostr: โปรโตคอลทางเลือกใหม่สำหรับโซเชียลมีเดียที่เป็นอิสระ ปลอดภัย และไร้การควบคุม
Nostr คือโปรโตคอลแบบเปิดที่เรียบง่าย ซึ่งช่วยให้สามารถสร้างโซเชียลมีเดียระดับโลกที่กระจายอำนาจและป้องกันการเซ็นเซอร์ได้
จากที่กล่าวข้างต้น เราสามารถพูดได้ว่า Nostr นั้นถูกออกแบบมาให้ใช้งานง่าย โดยมีเป้าหมายหลัก ๆ เพื่อสร้างเครือข่ายโซเชียลระดับโลกที่ปราศจากการเซ็นเซอร์ แล้วทำไมมันถึงทำอย่างนั้นได้? ในจุดนี้เราก็ต้องมาเจาะดูคุณสมบัติหลัก ๆ ของโปรโตคอลที่เรียกว่า Nostr กันก่อน:
เรียบง่าย
- โปรโตคอลนี้ใช้โครงสร้างข้อมูลแบบ Event Object ที่เรียบง่ายและยืดหยุ่น (ซึ่งส่งเป็น JSON ธรรมดา) และใช้การเข้ารหัส แบบ Elliptic-curve มาตรฐานสำหรับคีย์และลายเซ็น
- ช่องทางการสื่อสารที่รองรับเพียงอย่างเดียวคือการเชื่อมต่อ WebSockets จากไคลเอนต์ไปยังรีเลย์
- การออกแบบนี้ทำให้ง่ายต่อการพัฒนาไม่ว่าจะไคลเอนต์หรือรีเลย์ และยังช่วยส่งเสริมความหลากหลายของซอฟต์แวร์
ยืดหยุ่น
- เนื่องจาก Nostr ไม่ได้พึ่งพาเซิร์ฟเวอร์ที่เชื่อถือได้เพียงจำนวนหยิบมือ สำหรับการเคลื่อนย้ายหรือจัดเก็บข้อมูล แต่ใช้เซิร์ฟเวอร์จำนวนมหาศาลและกระจายตัวอยู่ทั่วโลก จึงมีความยืดหยุ่นสูง และมีการกระจายศูนย์อย่างแท้จริง
- โปรโตคอลนี้ถูกออกแบบมาโดยคำนึงถึงความเป็นไปได้ที่รีเลย์จะหายไป และอนุญาตให้ผู้ใช้เชื่อมต่อและเผยแพร่ข้อมูลไปยัง
- รีเลย์จำนวนมากได้ตามต้องการ และยังสามารถเปลี่ยนแปลงได้ตลอดเวลาอีกด้วย
ตรวจสอบได้
- เนื่องจากบัญชี Nostr ใช้การเข้ารหัสแบบ PKE จึงง่ายต่อการตรวจสอบว่าข้อความถูกส่งมาจากผู้ใช้ที่ระบุจริงหรือไม่
เช่นเดียวกับ HTTP หรือ TCP-IP Nostr เป็นโปรโตคอลหรือมาตรฐานแบบเปิดที่ทุกคนสามารถนำไปสร้างต่อยอดได้ มันไม่ใช่แอปหรือบริการที่คุณจำเป็นต้องลงทะเบียน
แล้วทำไมเราถึงต้องการ Nostr?
โซเชียลมีเดียได้พัฒนาเป็นช่องทางสำคัญในการไหลเวียนของข้อมูลทั่วโลก แต่น่าเสียดายที่ระบบโซเชียลมีเดียในปัจจุบันของเรานั้นมีข้อบกพร่องมากมาย:
1. ใช้ความสนใจของคุณเพื่อขายโฆษณา
2. ใช้เทคนิคแปลกๆ เพื่อทำให้คุณเสพติด (อ้างอิงจากข้อ 1)
3. ตัดสินใจว่าจะแสดงเนื้อหาใดให้คุณเห็นโดยใช้อัลกอริทึมลับที่คุณไม่สามารถตรวจสอบหรือเปลี่ยนแปลงได้
4. ควบคุมอย่างเต็มที่ว่าใครสามารถเข้าร่วมและใครถูกเซ็นเซอร์
5. เต็มไปด้วยสแปมและบอท
ด้วยข้อจำกัดเหล่านี้ Nostr จึงเป็นทางเลือกที่น่าสนใจในการสร้างโซเชียลมีเดียที่เป็นอิสระ ปลอดภัย และไร้การควบคุม
#siamstr

2024-08-09 07:01:17

อะแฮ่ม ๆ รวมโน๊ตทั้งหมดที่เกี่ยวกับ BTC whitepaper มาแล้ว อ่านทีเดียวยาว ๆ ได้เลย เย้
#siamstr
#naddr1qv…9nk8

2024-08-08 12:14:36

12. Conclusion
เราได้นำเสนอระบบธุรกรรมอิเล็กทรอนิกส์ที่ไม่ต้องพึ่งพาความไว้วางใจ เริ่มต้นจากกรอบแนวคิดของเหรียญที่สร้างจากลายเซ็นดิจิทัล ซึ่งช่วยควบคุมความเป็นเจ้าของได้อย่างดีแต่ก็ยังไม่สมบูรณ์ หากปราศจากวิธีการป้องกันการใช้จ่ายซ้ำซ้อน เพื่อแก้ปัญหานี้ เราจึงเสนอเครือข่ายแบบเพียร์ทูเพียร์ที่ใช้ proof-of-work ในการบันทึกประวัติธุรกรรมสาธารณะ ซึ่งจะกลายเป็นเรื่องยากอย่างมากสำหรับผู้โจมตีที่จะเปลี่ยนแปลง หาก node ที่ซื่อสัตย์ควบคุมพลังประมวลผล CPU ส่วนใหญ่ เครือข่ายนี้มีความแข็งแกร่งในความเรียบง่ายที่ไม่มีโครงสร้างใด ๆ ที่ซับซ้อน node ต่าง ๆ ทำงานพร้อมกันโดยประสานงานกันเพียงเล็กน้อย ไม่จำเป็นต้องระบุตัวตน เนื่องจากข้อความไม่ได้ถูกส่งไปยังสถานที่ใดสถานที่หนึ่งโดยเฉพาะ และเพียงแค่ต้องส่งมอบให้ถึงมือผู้รับอย่างดีที่สุด node สามารถออกจากและเข้าร่วมเครือข่ายได้ตามต้องการ โดยยอมรับ chain ที่มี proof-of-work มากที่สุดเป็นสิ่งที่เกิดขึ้นในขณะที่ไม่ได้เชื่อมต่อ พวกเขาโหวตด้วยพลังประมวลผล CPU แสดงการยอมรับบล็อกที่ถูกต้องโดยการทำงานเพื่อขยายบล็อก และปฏิเสธบล็อกที่ไม่ถูกต้องโดยการปฏิเสธที่จะทำงานกับบล็อกเหล่านั้น กฎและแรงจูงใจใด ๆ ที่จำเป็นสามารถบังคับใช้ได้ด้วยกลไกฉันทามตินี้
#siamstr

2024-08-07 12:22:37

11. Calculations
หากลองพิจารณาสถานการณ์ที่ผู้โจมตีพยายามสร้าง chain ปลอมให้เร็วกว่า chain จริง แม้ว่าจะทำได้สำเร็จ แต่มันก็ไม่สามารถทำให้ระบบเปิดรับการเปลี่ยนแปลงตามอำเภอใจได้อยู่ดี เช่น การสร้างมูลค่าจากอากาศธาตุ หรือการรับเงินที่ไม่เคยเป็นของผู้โจมตีมาก่อน Node ต่าง ๆ จะไม่ยอมรับธุรกรรมที่ไม่ถูกต้องเป็นการชำระเงิน และ Node ที่สุจริตก็จะไม่ยอมรับบล็อกที่มีธุรกรรมเหล่านั้นอย่างแน่นอน ผู้โจมตีทำได้เพียงพยายามเปลี่ยนแปลงธุรกรรมของตนเอง เพื่อนำเงินที่ใช้ไปแล้วกลับคืนมาเท่านั้น
การแข่งขันระหว่าง chain สุจริตกับ chain ของผู้โจมตี สามารถอธิบายได้ด้วยแบบจำลองการเดินสุ่มทวินาม (Binomial Random Walk) โดยเหตุการณ์ที่สำเร็จ หมายถึง chain ที่สุจริตถูกขยายออกไปอีกหนึ่งบล็อก เพิ่มความยาวนำหน้าไป +1 และเหตุการณ์ที่ล้มเหลว หมายถึง chain ของผู้โจมตีถูกขยายออกไปหนึ่งบล็อก ลดช่องว่างลง -1
ความน่าจะเป็นที่ผู้โจมตีจะไล่ตามทันจากช่องว่างที่กำหนด สามารถเปรียบเทียบด้วย Gambler's Ruin problem โดยสมมติว่านักพนันที่มีเครดิตไม่จำกัด เริ่มต้นด้วยการขาดทุน และเล่นพนันไปเรื่อย ๆ เพื่อให้ถึงจุดคุ้มทุน เราสามารถคำนวณความน่าจะเป็นที่เขาจะกลับมาถึงจุดคุ้มทุนได้ หรือความน่าจะเป็นที่ผู้โจมตีจะไล่ทัน chain ที่สุจริตได้ ดังนี้ [8]:
p = ความน่าจะเป็นที่ Node ที่สุจริตจะพบบล็อกถัดไป
q = ความน่าจะเป็นที่ผู้โจมตีจะพบบล็อกถัดไป
qz = ความน่าจะเป็นที่ผู้โจมตีจะไล่ทัน จากที่ตามหลังอยู่ z บล็อก
https://i.imgur.com/vePe255.png
จากสมมติฐานที่ว่า p > q ความน่าจะเป็นจะลดลงแบบเอกซ์โพเนนเชียล เมื่อจำนวนบล็อกที่ผู้โจมตีต้องไล่ตามทันเพิ่มขึ้น หากเขาไม่สามารถพุ่งขึ้นนำได้อย่างรวดเร็วตั้งแต่แรก โอกาสของเขาก็จะลดลงจนน้อยมาก ๆ เมื่อเขาตามหลังมากขึ้นเรื่อย ๆ
ทีนี้ลองพิจารณาว่า ผู้รับธุรกรรมใหม่ต้องรอเป็นเวลานานเท่าใด จึงจะแน่ใจได้ว่าผู้ส่งไม่สามารถเปลี่ยนแปลงธุรกรรมได้แล้ว เราสมมติว่าผู้ส่งเป็นผู้โจมตี ที่ต้องการให้ผู้รับเชื่อว่าเขาได้รับเงินไปแล้ว จากนั้นจึงเปลี่ยนให้เงินกลับเข้าหาตัวเองหลังจากเวลาผ่านไประยะหนึ่ง ผู้รับจะได้รับแจ้งเมื่อเกิดเหตุการณ์นี้ขึ้น แต่ผู้ส่งหวังว่ามันจะสายเกินไปแล้ว
ผู้รับจะสร้างคู่กุญแจใหม่ และให้กุญแจสาธารณะแก่ผู้ส่งไม่นานก่อนที่จะลงนาม ซึ่งจะป้องกันไม่ให้ผู้ส่งเตรียมบล็อกเชนปลอมไว้ล่วงหน้า โดยการทำงานอย่างต่อเนื่องจนกว่าเขาจะมีโอกาสได้บล็อกที่ยาวพอ จากนั้นจึงดำเนินธุรกรรมในทันที เมื่อส่งธุรกรรมแล้ว ผู้ส่งที่ไม่สุจริตจะเริ่มทำงานอย่างลับ ๆ บนบล็อกเชนคู่ขนาน ที่มีธุรกรรมในเวอร์ชันของเขาเองอยู่
ผู้รับจะรอจนกว่าธุรกรรมจะถูกเพิ่มลงในบล็อก และมีบล็อกที่ถูกเชื่อมต่อตามหลังมาอีก z บล็อก เขาไม่ทราบจำนวนความคืบหน้าที่แน่นอนที่ผู้โจมตีได้ทำไปแล้ว แต่สมมติว่าบล็อกที่สุจริตใช้เวลาเฉลี่ยต่อบล็อกตามที่คาดไว้ ความคืบหน้าที่อาจเกิดขึ้นได้ของผู้โจมตีจะเป็นการแจกแจงแบบปัวซง (Poisson distribution) ซึ่งมีค่าคาดหวังดังนี้:
https://i.imgur.com/mYsb48i.png
เพื่อให้ได้ความน่าจะเป็นที่ผู้โจมตียังคงสามารถไล่ทันได้ เราจะคูณความหนาแน่นของปัวซง สำหรับความคืบหน้าแต่ละระดับที่เขาสามารถทำได้ ด้วยความน่าจะเป็นที่เขาสามารถไล่ทันจากจุดนั้น:
https://i.imgur.com/jQGkQ8r.png
จัดเรียงใหม่เพื่อหลีกเลี่ยง infinite tail ของการแจกแจง
https://i.imgur.com/OOO6Gm9.png
แปลงมันให้เป็น C code
#include <math.h>
double AttackerSuccessProbability(double q, int z)
{
double p = 1.0 - q;
double lambda = z * (q / p);
double sum = 1.0;
int i, k;
for (k = 0; k <= z; k++)
{
double poisson = exp(-lambda);
for (i = 1; i <= k; i++)
poisson *= lambda / i;
sum -= poisson * (1 - pow(q / p, z - k));
}
return sum;
}
เมื่อรันผลลัพธ์บางส่วน เราจะเห็นว่าความน่าจะเป็นลดลงแบบเอกซ์โพเนนเชียลเมื่อ z เพิ่มขึ้น
q=0.1
z=0 P=1.0000000
z=1 P=0.2045873
z=2 P=0.0509779
z=3 P=0.0131722
z=4 P=0.0034552
z=5 P=0.0009137
z=6 P=0.0002428
z=7 P=0.0000647
z=8 P=0.0000173
z=9 P=0.0000046
z=10 P=0.0000012
q=0.3
z=0 P=1.0000000
z=5 P=0.1773523
z=10 P=0.0416605
z=15 P=0.0101008
z=20 P=0.0024804
z=25 P=0.0006132
z=30 P=0.0001522
z=35 P=0.0000379
z=40 P=0.0000095
z=45 P=0.0000024
z=50 P=0.0000006
การแก้หาค่า P ที่น้อยกว่า 0.1%...
P < 0.001
q=0.10 z=5
q=0.15 z=8
q=0.20 z=11
q=0.25 z=15
q=0.30 z=24
q=0.35 z=41
q=0.40 z=89
q=0.45 z=340
#siamstr

2024-08-04 07:25:13

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

2024-08-01 11:43:31

7. Reclaiming Disk Space
เมื่อธุรกรรมถูกบรรจุลงในบล๊อกแล้ว สามารถกำจัดธุรกรรมที่ใช้ไปแล้วก่อนหน้านั้นออกได้เพื่อประหยัดพื้นที่ดิสก์ แต่การจะทำอย่างนี้ได้โดยไม่ให้เลข hash ของบล๊อกมีการเปลี่ยนแปลงนั้น ธุรกรรมจึงจำเป็นต้องถูก hash ในรูปแบบของ Merkle Tree [7][2][5] โดยมีแค่ root node ของ tree เท่านั้นที่จะรวมอยู่ใน hash ของบล๊อก นี่เป็นวิธีที่ทำให้สามารถบีบอัดข้อมูลในบล๊อกเก่า ๆ ได้โดยการตัดพวก hash ส่วนอื่น ๆ ของ tree ที่ไม่ใช่ root node ออก (ไม่จำเป็นต้องเก็บ hash ในชั้นอื่น ๆ ของ tree)
https://image.nostr.build/3ed95334891d91baca3f3f6f624a7ae22620be4ebfe0db5eb652cfce11255b9a.png
โดยในส่วน 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.

2024-07-31 10:12:32

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

2024-07-30 04:49:13

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

2024-07-29 13:43:16

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 ของบล็อกนั้นและบล็อกที่ตามมาใหม่ทั้งหมด
https://image.nostr.build/c039ef4ca6833cb1ecee65ac5991df2406be9b7e490b86b3b19f94f267767182.png
นอกจากนี้ 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,"
http://www.hashcash.org/papers/hashcash.pdf , 2002.
#siamstr

2024-07-28 12:33:08

3. Timestamp Server
สำหรับแนวทางการแก้ปัญหาในครั้งนี้ เราจะใช้ประโยชน์จาก timestamp server ที่จะทำหน้าที่บันทึก hash ของบล๊อกที่ต้องการให้มีการบันทึกเวลา และจากนั้นจะทำการเผยแพร่ hash ดังกล่าว เหมือนกับหนังสือพิมพ์หรือโพสต์ใน Usenet [2-5] (ฟีลแบบทุกคนจะเห็นโพสต์นี้น้าา ประมาณนั้น) การบันทึกเวลานี้จะพิสูจน์ได้ว่าข้อมูลที่ถูก hash นั้นจะต้องมีอยู่จริงในเวลานั้นเพื่อให้ได้มาซึ่ง hash ดังกล่าว แต่ละการบันทึกเวลาจะรวมการบันทึกเวลาของหน้านี้ไว้ใน hash ของมันเพื่อสร้างเป็น chain โดยการบันทึกเวลาแต่ละครั้งจะยืนยันความถูกต้องของการบันทึกก่อนหน้าได้อีกด้วยด้วย
https://image.nostr.build/ddf92417c45dbb6e25da0af80a10d4cdbc3e725d047d65f54a3e3bfcf358c4d6.png
[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

2024-07-27 13:48:34

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

2024-07-26 12:27:26

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

2024-07-25 13:14:46

ระบบเงินอิเล็กทรอนิกส์แบบ peer-to-peer
ระบบเงินอิเล็กทรอนิกส์แบบ peer-to-peer นั้นจะช่วยให้เราสามารถชำระเงินผ่านทางออนไลน์ได้โดยตรงจากฝ่ายหนึ่งไปยังอีกฝ่ายหนึ่งโดยไม่ต้องผ่านตัวกลางอย่างพวกสถาบันการเงิน โดยใช้ digital signature เป็นส่วนหนึ่งในการแก้ปัญหานี้ แต่มันจะไม่มีประโยชน์ใด ๆ เลยหากยังคงต้องอาศัยตัวกลางที่เชื่อถือได้มาแก้ปัญหา double spending เราขอเสนอวิธีแก้ปัญหา double spending โดยใช้เครือข่ายแบบ peer-to-peer ให้เครือข่ายคอยประทับเวลาธุรกรรมต่าง ๆ ในระบบและนำมาเรียงร้อยกันเป็นเส้นสายของ proof-of-work ที่ใช้ hash เพื่อสร้างธุรกรรมที่ไม่สามารถเปลี่ยนแปลงได้ โดยไม่ต้องทำ proof-of-work ใหม่ โดยให้เส้นสายที่ยาวที่สุดนั้น ไม่เพียงแต่ทำหน้าที่เป็นลำดับของธุรกรรมที่เกิดขึ้นเท่านั้น แต่ยังเป็นสิ่งที่พิสูจน์ได้ว่ามาจากกำลังประมวลผล CPU ที่มากที่สุด และตราบใดที่ nodes ส่วนใหญ่ไม่ได้ร่วมมือกันโจมตีเครือข่ายและยังคงควบคุมกำลังประมวลผลส่วนใหญ่ในระบบไว้ พวกเขาก็จะสร้างเส้นสายที่ยาวที่สุดและสามารถเอาชนะผู้ประสงค์ร้ายที่จะโจมตีระบบได้ ตัวเครือข่ายเองไม่ได้ต้องมีโครงสร้างอะไรที่ซับซ้อน ข้อมูลต่าง ๆ ในเครือข่ายจะถูกกระจายส่งต่อโดยไม่ต้องสนใจว่าผู้รับจะได้รับหรือไม่ และ nodes ต่าง ๆ เองก็สามารถที่จะออกจากเครือข่ายและกลับเข้าร่วมใหม่ได้ตามที่ต้องการ โดยยอมรับเส้น proof-of-work ที่ยาวที่สุด เป็นหลักฐานของสิ่งที่เกิดขึ้นในขณะที่ node นั้น ๆ ไม่ได้อยู่ในเครือข่าย
#siamstr
/ปล. ถ้าใครอ่านแล้วคุ้นก็ใช่ครับ white paper นั้นแหละ ผมเชื่อว่าหลาย ๆ คนน่าจะยังไม่เคยมีโอกาสได้อ่าน (9 หน้ามันก็ยาวอะเนอะ) เลยคิดว่าจะหั่นออกมาทีละส่วน เผื่อใครตามอ่านทุกวันสักสองอาทิตย์ก็เหมือนอ่าน white paper จบ/

2024-07-24 03:54:28

มาสร้าง emoji ของเราบน nostr กันเถอะ!!
ครั้งนี้จะเป็นการสร้าง emoji list ผ่านทาง nostrudel เนื่องจากเป็น client ที่เป็นที่นิยมและคิดว่าหลาย ๆ คนน่าจะเคยใช้งานกันมาบ้างแล้ว
1. ให้ไปที่ส่วนของ other stuff จากนั้นเลือก more แล้วเราจะเจอหน้าตาประมาณนี้ (รูปที่ 1)
https://image.nostr.build/8ea33eee04941e7da7df36101959e9cc1463b65f174e657eae1c362c8aef50cf.png
2. กดเข้าไปในหัวข้อ emoji จากนั้นเลือก create new pack บนมุมบนขวา (รูปที่ 2) https://image.nostr.build/df55f7b8af81e6ca64c8593468481afdefd7dcc8125c1a05b610606e587ca883.png
3. หลังใส่ชื่อเรียบร้อยเราจะเข้าสู่หน้านี้ (รูปที่ 3)
https://image.nostr.build/16f50256fbdd373622de3ebecfef39c6ca45984f8c07bd1b832e6eac4501bf9e.png
4. เมื่อเรากด edit ที่มุมบนขวาเราก็จะได้ช่องที่ใส่ชื่อของอิโมจิตัวนั้น ๆ และช่องใส่ url ของรูปภาพหรือ gif มา (รูปที่ 4)
https://image.nostr.build/cd3549a7bb098ee38f25ffcc2d834b46f86404715756af40198cee98ca1e938b.png
5. หลังใส่รายละเอียดแล้วให้เรากด add และทำวนไปเรื่อย ๆ จนกว่าจะพอใจ หลังจากนั้นให้เรากด save และทำการ sign ธุรกรรมนั้นก็เป็นอันเสร็จสิ้น เพียงเท่านี้เราก็จะมีอิโมจิของเราที่ไม่เหมือนใครเอาไว้ใช้แล้ว

2024-07-23 06:49:04

Emoji บน Nostr
บน nostr นั้นการกด reaction (kind 7) ในแต่ละโพสต์นั้นค่อนข้างแตกต่างกับโซเชียลมีเดียอื่น ๆ เป็นอย่างมากเนื่องจากผู้ใช้ทุกคนสามารถที่จะออกแบบและเลือกใช้อิโมจิอะไรก็ได้ที่ตัวผู้ใช้นั้น ๆ ต้องการ โดย emoji จะถูกเก็บอยู่ในลักษณะของ list (NIP-51) เหมือนกับพวก following list, mute list แต่การใช้งานจริง ๆ ทำได้หลากหลายมากกว่านั้น เช่นการจับลง kind 0 หรือ kind 1 ก็สามารถทำได้เช่นกัน ทีนี้เรามาลองดูโครงสร้าง event ของ list emoji กันดีกว่า
{
"id": "c25122084feb5b70c4c141c515e91dfb6a65c494dae2baf091839ff88a4cc0c3",
"pubkey": "66df60562d939ada8612436489945a4ecf1d62346b3d9478dea8a338f3203c64",
"created_at": 1710736175,
"kind": 30030,
"tags": [
[ "d", "ชื่อเซตอิโมจิ"],
["emoji","ชื่อสั้น ๆ ","httpรูปหรือ gif"],
[ "emoji","ชื่อสั้น ๆ ""httpรูปหรือ gif"],
["emoji","ชื่อสั้น ๆ ","httpรูปหรือ gif"],
[ "emoji","ชื่อสั้น ๆ ""httpรูปหรือ gif"],
"content": "",
"sig": "c4fb0626619fc0881d859570d0d00d72f7a429aca53a322768a6a0c69ddb00e44a87b65bf75a07eb7647407b78803f76720e22eed0724d554470d30371ab1173"
}
อย่างที่เห็นว่าจุดแตกต่างของ event ที่ทำให้ client ต่าง ๆ รู้ว่ามันคืออีโมจิคือ tag "d"(identifier) และ "emoji" และต้องมีโครงสร้างดังนี้ ["emoji", <shortcode>, <image-url>]
เมื่อทำการเผยแพร่ event ในลักษณะนี้แล้วเราก็จะได้ list ของอิโมจิออกมาแบบนี้
#naddr1qv…8v76
ส่วนถ้าเราต้องการนำ emoji ที่เราสร้างไปใส่ในหน้าโปรไฟล์หรือเวลาเราโพสต์เราต้องทำอย่างไร ?
โปรไฟล์(kind 0)
{
"kind": 0,
"content": "{\"name\":\"Alex Gleason :soapbox:\"}",
"tags": [
["emoji", "soapbox", "http s://gleasonator.com/emoji/Gleasonator/soapbox.png"]
],
"pubkey": "79c2cae114ea28a981e7559b4fe7854a473521a8d22a66bbab9fa248eb820ff6",
"created_at": 1682790000
}
ใน part ของโปรไฟล์นั้นเพียงแค่เราเพิ่ม shortcode ลงไปในจุดที่เราต้องการใส่และทำการเพิ่ม emoji ใน tag ก็สามารถใช้ได้แล้ว และในทำนองเดียวกันสำหรับการโพสต์ (kind 1)
{
"kind": 1,
"content": "Hello :gleasonator: 😂 :ablobcatrainbow: :disputed: yolo",
"tags": [
["emoji", "ablobcatrainbow", "https: //gleasonator.com/emoji/blobcat/ablobcatrainbow.png"],
["emoji", "disputed", "https: //gleasonator.com/emoji/Fun/disputed.png"],
["emoji", "gleasonator", "https: //gleasonator.com/emoji/Gleasonator/gleasonator.png"]
],
"pubkey": "79c2cae114ea28a981e7559b4fe7854a473521a8d22a66bbab9fa248eb820ff6",
"created_at": 1682630000
}
และประเภทสุดท้ายของการใช้ emoji บน nostr และหน้าจะเป็นประเภทที่หลาย ๆ คนใช้กันมากที่สุดอย่างการกด reaction ด้วย emoji จะมี event หน้าตาประมาณนี้
{
"kind": 7,
"content": ":soapbox:",
"tags": [
["emoji", "soapbox", "https ://gleasonator.com/emoji/Gleasonator/soapbox.png"]
],
...other fields
}
ทั้งหมดนี้คือวิธีการใช้อิโมจิต่าง ๆ บน nostr ซึ่งจัดเป็นอีกฟังก์ชั่นที่น่าสนใจมาก ๆ ในการเพิ่มสีสันให้สังคม nostr โดยในปัจจุบันมีหลาย ๆ client ได้รองรับการใช้ custom emoji เหล่านี้แล้วส่วนวิธีการสร้างแบบง่าย ๆ โดยที่ไม่ต้องสนใจสิ่งที่กล่าวมาข้างต้นนั้นสามารถทำได้บน emojito.meme หรือ Nostrudel ได้เลย
#siamstr

2024-07-22 03:23:34

Bitcoin node
บิตคอยน์โหนด หรือก็คือเหล่าบรรดาคุณป้าข้างบ้านที่มีปัญญาในการจดจำอันเลิศล้ำและคอยบอกต่อเรื่องราวต่าง ๆ ที่เขารับรู้มาให้เราเสมอไม่ว่าจะเรื่องราวของข้างบ้าน ข้างหมู่บ้าน ลูก หลาน เหลน ได้อย่างไม่เหน็ดเหนื่อย โอเคกับมาเข้าเรื่องก่อน บิตคอยน์โหนดคือโปรแกรมที่ทำหน้าที่ในการตรวจสอบธุรกรรม หากถูกต้องตามกฎและระเบียบที่แต่ละโหนดกำหนดไว้ โหนดก็จะส่งธุรกรรมและบล๊อกที่ได้รับนั้นไปยังโหนดอื่น ๆ และเก็บสำรองข้อมูลเหล่านั้นไว้เพื่ออ้างอิงในอนาคตด้วย
แล้วมันทำงานยังไง ?
เมื่อธุรกรรมใหม่ถูกสร้างและส่งต่อในเครือข่าย, บิตคอยน์โหนดจะรับธุรกรรมเหล่านั้นและทำการตรวจสอบตามกฎที่โหนดนั้น ๆ เลือก เช่น ตรวจสอบลายเซ็นดิจิทัลและตรวจสอบ unspent transaction outputs (UTXOs) โดยโหนดจะใช้ BIP ต่าง ๆ เป็นตัวช่วยในการตรวจสอบ เช่น BIP-66 เพื่อการตรวจสอบ digital signature
หลังจากการตรวจสอบความถูกต้องของธุรกรรม, บิตคอยน์จะรวมธุรกรรมที่ตรวจสอบแล้วเหล่านี้เข้าไปใน mempool ซึ่งเป็นพื้นที่เก็บข้อมูลของธุรกรรมที่รอการบรรจุลงในบล็อกถัดไป โหนดจะคอยตรวจสอบบล็อกใหม่ที่เผยแพร่จาก miner ซึ่งจะมีการยืนยันบล็อกใหม่เหล่านี้โดยการตรวจสอบลำดับของบล็อกและการตรวจสอบปัญหาต่าง ๆ เช่น มี double-spending มั้ย, มีธุรกรรมที่ out มากกว่า in มั้ย
เมื่อโหนดยืนยันบล็อกใหม่แล้ว, บล็อกดังกล่าวจะถูกเพิ่มลงใน blockchain และโหนดจะเผยแพร่ข้อมูลบล็อกใหม่ไปยังโหนดอื่น ๆ ในเครือข่าย เพื่อให้ข้อมูลนี้ถูกกระจายออกไปทั่วเครือข่าย
#siamstr

2024-07-18 03:14:15

- reply

แฮร่ โป๊ะแล้วโป๊ะอีก โป๊ะแบบซ้ำซ้อน บ้าบอ

2024-07-18 03:07:50

- reply

รบกวนขอผลลัพธ์ด้วยนะครับ ผมคิดว่า wherostr ทำได้แน่ ๆ ครับ

2024-07-18 02:36:23

Lightning Zaps
การ zap บน nostr ก็เป็นอีเว้นประเภทหนึ่ง ๆ โดยการใน zap แต่ละครั้งจะประกอบไปด้วย 2 อีเว้นก็คือ zap request (9734) และ zap receipt (9735) โดย flow ในการทำงานของการ zap มีดังนี้
1. client จะทำการอ่าน LNurl หรือ LNaddress จาก profile ของคนที่เราจะ zap และทำการส่ง request ไปยัง LNaddr server นั้น ๆ เมื่อ server ตอบกลับมาก็จะเช็คพารามิเตอร์สองตัวนั้นคือ allowsNostr(True or False) และ nostrPubkey(ตรงกับ npub ของโปรไฟล์ที่เราจะ zap มั้ย) ตามลำดับ ถ้าถูกต้องจะทำการการอ่านพารามิเตอร์ callback(ส่งเงินไป address ไหน), minSendable(ยอดขั้นต่ำ), และ maxSendable(ยอดสูงสุด) กระบวนการทั้งหมดของข้อนี้คือ zap request
2. เมื่อเราทำการจ่าย invoice เรียบร้อย จะมีการสร้าง zap receipt และส่งไปยัง relay ต่าง ๆ
โดย event ของทั้สองประดภทมีลักษณะดังนี้
zap request (9734)
{
"kind": 9734,
"content": "Zap!",
"tags": [
["relays", "รีเลย์หนึ่ง", "รีเลย์สอง"],
["amount", "จำนวนที่เราอยาก zap"],
["lnurl", "lnurl ของคนรับ"],
["p", "pubkey คนรับในรูป hex"],
["e", "event id ที่เราจะ zap"]
],
"pubkey": "pubkeyคนส่ง",
"created_at": เวลา,
"id": " ID ของอีเว้นนี้",
"sig": " Digital sigature ของธุรกรรมนี้"
}
zap receipt (9735)
{
"id": "ID ของอีเว้นนี้",
"pubkey": "pubkey ของคนส่ง",
"created_at": เวลาที่สร้าง,
"kind": 9735,
"tags": [
["p", "pubkeyคนส่งในรูป hex"],
["e", "event id ที่มีคนมา zap"],
["bolt11", "Ln invoice"],
["description", " zap request ทั้งอีเว้น"],
["preimage", "preimage ของ invoice"]
],
"content": "",
"sig": "Digital signatureของคนส่ง"
}
#siamstr

2024-07-16 02:17:38

Bitcoin Transaction Structure
ธุรกรรมของบิตคอยน์คือสิ่งที่เกิดขึ้นทุกครั้งที่เราทำการส่งบิตคอยน์ ไม่ว่าจะส่งไปให้คนอื่น หรือแค่ทำสังคายนา utxo ของตัวเองก็ตาม ถ้าให้ว่ากันง่าย ๆ จริง ๆ แล้ว ธุรกรรมของบิตคอยน์ก็แค่ชุดข้อมูลจำนวนหนึ่งที่เอาไว้แค่ล๊อคบิตคอยน์และปลดล๊อคบิตคอยน์ โดยในธุรกรรมจะแบ่งส่วนหลัก ๆ 2 part คือ ขาเข้า(input): เลือกบิตคอยน์ที่เราต้องการปลดล๊อค, ขาออก(output): เอาบิตคอยน์จาก input ไปล๊อคไว้ที่ไหนต่อ และแน่นอนว่าในแต่ละธุรกรรมนั้นจำนวน input และ output นั้นสามารถมีได้มากกว่า 1
โอเคทีนี้เรามาลองดูตัวอย่าง transaction กัน
(ตัวอย่างจาก 1de09872f8726ab057e8b116faf55d0e502acbe8ff94b8025a40105a85218140 // Height 114,932)
tx data: 0100000001c3756a5279ed61735f5ab085f6e10b3f36423020cd4746876dd353ec610cf52c000000008b4830450221008c5730e8dd9509275ab6b8172c9dcfb74b98c855b328cce8b539701755875a53022055caafcff30d19e5fa28b671a37f00704ef8daac0ef06ba35696650850b820bb01410456ee2d5b710bce0e7ce5fd15c47c4021495ad9109a544ffcf7ecd2b049fe98f168ba973c161fa3cdffb1df4d0f208a576a45dea6cbc2b20a48cfc0a588a5b2afffffffff020014df200f0000001976a914ead1471151871931cfe3ed41beb99662f4248d1288ac40420f00000000001976a9146abb64c4751ede732ba3a584de223dbd8989531288ac00000000
ทีนี้เรามาลองชำแหละธุรกรรมนี้กัน ในธุรกรรมนี้มีส่วนประกอบดังนี้: version, input count, input data, output count, output data, และ time lock ดูข้อความด้านล่างนี้ประกอบเอานะครับ
version(4 byte): 01000000
input count: 01 แปลว่าธุรกรรมนี้มี 1 input
input data: ในส่วนนี้แบ่งเป็น 5 ส่วนของแต่ละ input ดังนี้
TXID(32 byte):c3756a5279ed61735f5ab085f6e10b3f36423020cd4746876dd353ec610cf52c
VOUT(4 byte):00000000
ScriptSig Size:8b
ScriptSig:4830450221008c5730e8dd9509275ab6b8172c9dcfb74b98c855b328cce8b539701755875a53022055caafcff30d19e5fa28b671a37f00704ef8daac0ef06ba35696650850b820bb01410456ee2d5b710bce0e7ce5fd15c47c4021495ad9109a544ffcf7ecd2b049fe98f168ba973c161fa3cdffb1df4d0f208a576a45dea6cbc2b20a48cfc0a588a5b2af
* ตรงนี้มันคือ OP_PUSHBYTES_72 กับ OP_PUSHBYTES_65 ไว้เขียนวันหลังนะครับ
sequence(4 byte):ffffffff ส่วนนี้คือตัวกำหนดพวก lock time หรือ RBF (ffffffff คือปกติ ,fdffffff คือ RBF ส่วนพวก timelockจะเริ่มจาก 00000000 และเปลี่ยนลำดับที่ 2 ตามจำนวน block ที่ต้องการเช่น 3 block ก็ 03000000)
input count:02 ธุรกรรมนี้มี 2 output
input data: ในส่วนนี้แบ่งเป็น 3 ส่วนของแต่ละ output ดังนี้
output 1
amount(Little Endian 8 Byte): 0014df200f000000 (64,976,000,000 sat) *รวยเกิ้นนน
ScriptPubKey Size: 19
ScriptPubKey: 76a914ead1471151871931cfe3ed41beb99662f4248d1288ac
output 2
amount(Little Endian 8 Byte): 40420f0000000000 (1,000,000 sat)
ScriptPubKey Size: 19
ScriptPubKey: 76a9146abb64c4751ede732ba3a584de223dbd8989531288ac
time lock: 00000000
โดยคร่าว ๆ ก็ประมาณนี้ครับ ตัวอย่างอาจจะเก่าไปหน่อยแล้วเป็น P2PKH ด้วย เลยไม่ได้มีตัวอย่างในส่วนที่ใช้กันบน segwit อย่าง maker, flag, witness ให้แต่เนื่องจากความยาวพอสมควรแล้วผมขอติดไว้ก่อนแล้วกันนะครับ
#siamstr

2024-07-15 05:22:38

- reply

https://image.nostr.build/a01534206993b13d911eb56094d3067c845c452df63b65c59b13b7eb37723d70.png

2024-07-15 05:14:36

- reply

งงครับนี่ไดโนเสาร์

2024-07-14 02:34:05

Merkle Tree
Merkle Tree เป็น hash-based data structure เหมือนกับ binary tree แต่แตกต่างกันตรงที่ leaf node จะทำการเก็บเพียงแค่ค่า hash ของข้อมูลธุรกรรม ส่วน node ที่ไม่ใช่ leaf node จะเก็บค่าจากการ hash ที่ได้จาก children node หากจะให้เห็นภาพมากขึ้นลองมาดูตัวอย่างตามนี้กันครับ
สมมุติให้มี transaction ทั้งหมด 4 transaction: t1, t2, t3, t4 ก็แปลว่า hash ของทั้ง 4 transaction ก็จะเป็น leaf node ดังนี้
H(1), H(2), H(3), H(4) และเนื่องจาก 1 node จะมี 2 children แปลว่า ก็จำเป็นต้องมี 2 node ที่เก็บ hash ของ H(1), H(2), H(3), H(4) ดังนั้นในชั้นที่ 2 ของ tree แต่ละ node จะต้องเก็บข้อมูลเป็น H(H(1)+H(2)), และ H(H(3)+H(4)) ตามลำดับ และดังที่กล่าวไว้ข้างต้น เนื่องจาก 1 node จะมี 2 children แปลว่า ก็จำเป็นต้องมี 1 node ที่เก็บค่า H(H(H(1)+H(2)) + H(H(3)+H(4))) ดังรูปที่แสดงข้างล่างนี้
https://image.nostr.build/fc973bc4a3c9dd9330fdd754461ac0f45c6cf031509a0815ddba10764a9588fd.png
เมื่อเราใช้ Merkle Tree มาช่วยจัดการการตรวจสอบธุรกรรมบนบิตคอยน์ ทำให้เราไม่จำเป็นต้องตรวจสอบทุกธุรกรรมในบล๊อก เนื่องจากเราสามารถเช็คเพียงแค่ root hash ว่าตรงกับคนอื่นมั้ย ถ้าตรงก็แปลว่าข้อมูลที่เรารับมาถูกต้อง ในทางกลับกันหากไม่ตรงเราสามารถไล่เช็คตามลำดับของ tree เพื่อตามหาธุรกรรมเจ้าปัญหาได้ง่ายกว่าการไล่เช็คทั้งหมด การนำ merkle tree มาใช้ช่วยให้ การตรวจสอบบล๊อกนั้นทำได้ง่ายขึ้นและใช้พื้นที่ในการเก็บข้อมูลน้อยลง
#siamstr

2024-07-13 12:26:48

POW
การสร้างเซิร์ฟเวอร์บันทึกเวลาแบบกระจาย (Distributed Timestamp Server) ที่ทำงานแบบ peer-to-peer จะต้องอาศัยระบบ proof-of-work ซึ่งคล้ายกับ Hashcash ของ Adam Back
ระบบ proof-of-work ทำงานโดยการค้นหาค่า ๆ หนึ่งและเมื่อนำค่านั้นไปคำนวณ hash (เช่น SHA-256) ผลลัพธ์ (hash) จะต้องเริ่มต้นด้วยจำนวน bit ที่ได้กำหนดไว้ โดยความยากในการทำงาน (work) จะเพิ่มขึ้นแบบทวีคูณตามจำนวน bit ที่ต้องการ แต่ในการตรวจสอบความถูกต้องนั้นกับสามารถทำได้โดยการคำนวณ hash เพียงครั้งเดียว
โดยในระบบของบิตคอยน์จะมีการเพิ่มค่า nonce ลงไปในแต่ละบล๊อก จนกว่าจะพบค่าที่ทำให้ hash ของบล็อกเริ่มต้นด้วยจำนวน bit ที่กำหนดไว้ เมื่อใช้พลังประมวลผลเพื่อให้บล็อกสอดคล้องกับ proof-of-work แล้ว บล็อกนั้นจะไม่สามารถแก้ไขได้โดยไม่ต้องทำ proof-of-work ใหม่ เนื่องจากบล็อกใหม่ ๆ จะถูกเชื่อมโยงต่อกันหลังจากบล็อกนั้นแล้ว การแก้ไขบล็อกเดิมจะต้องทำ proof-of-work ใหม่สำหรับบล็อกนั้นและบล็อกทั้งหมดที่ตามมา นอกจากนี้ proof-of-work ยังแก้ปัญหาการตัดสินใจแบบเสียงข้างมากด้วย เพราะการตัดสินใจแบบเสียงข้างมากมักใช้ IP ในการนับโหวต ในระบบแบบนี้สามารถถูกโจมตีได้โดยบุคคลที่สามารถควบคุม IP address ได้ในจำนวนมาก แต่ proof-of-work เป็นเหมือนการใช้กำลังในการประมวลผลในการตัดสินใจแบบเสียงข้างมากจะแสดงโดย chain ที่ยาวที่สุดซึ่งมี proof-of-work ที่ถูกลงทุนไปมากที่สุด หากพลังประมวลผลของ majority เป็นของ node ที่ซื่อสัตย์ chain ของ node ที่ซื่อสัตย์จะเติบโตเร็วที่สุดและจะเหนือกว่า chain อื่น ๆ
เพื่อชดเชยความเร็วของฮาร์ดแวร์ที่เพิ่มขึ้นและความสนใจที่แตกต่างกันในการทำงานของ node และความยากของ proof-of-work จะถูกกำหนดโดยค่าเฉลี่ยทุก ๆ 2016 บล๊อก ซึ่งมีเป้าหมายที่จำนวนบล็อกต่อชั่วโมง หากบล็อกถูกสร้างขึ้นเร็วเกินไป ความยากจะเพิ่มขึ้น หากช้าไปก็จะง่ายขึ้นแทน โดยมีสมการในการปรับดังนี้ New Difficulty = Old Difficulty × (Actual Time / Target Time)
#siamstr

2024-07-12 03:08:45

Nostr event
event บน nostr หรือก็คือ โน๊ตหรือข้อมูลต่าง ๆ ที่เราเห็นกันบน nostr ไม่ว่าจะเป็นข้อมูล profile, เนื้อหาบน note, long-form, หรือแม้แต่การไลฟ์ ล้วนแล้วแต่เป็น event ทั้งหมด โดย event จะมีหน้าตาประมาณนี้
{
"id": ,
"pubkey": ,
"created_at": ,
"kind": ,
"tags": [ [...],[...] ],
"content": ,
"sig":
}
id ก็คือ event id ที่มักจะโชว์เวลาทำการโควทบางโน๊ตบน nostr คำนวณโดยการ นำข้อมูลส่วนอื่น ๆ ใน event (pubkey,create_at,kid,tg,content) มา Serialize จากนั้น hash ด้วย sha256
pubkey ก็คือ npubของเราแต่จะอยู่ในรูปของ hex
create_at ก็คือเวลาที่เราสร้างโน๊ต อยู่ในรูปของ unix timestamp ในวินาที
kind ก็คือเลขที่ใช้กำหนดประเภทของ event อยู่ในรูปของ int (0-65,535)
tag ก็คือ # ที่เราใส่ในโพสต์ต่าง ๆ
content ก็คือเนื้อหาที่อยู่บนโน๊ต
sig ก็คือ digital signature ของเรา ใช้เพื่อยืนยันว่า note นี้มาจาก nsec นั้น ๆ ที่เป็นเจ้าของ npub นั้น ๆ จริง ๆ คำนวณด้วยการใช้ ECDSA กับ serialized event data จาก id และ private key ของเรา
อย่างที่เห็นว่าทุกส่วนของ event ถูกเก็บในรูปของ text แล้ว เราสามารถเห็นรูปภาพหรือวิดีโอบน nostr ได้อย่างไร ?
ที่เราสามารถเห็นรูปภาพหรือวิดีโอบน client ต่าง ๆ ของ nostr ได้เนื่องจากการใช้ URL References
ถ้าเอาแบบเข้าใจง่าย ๆ ก็คือสิ่งที่เก็บบน event ของ nostr คือ url ที่ใช้ Markdown-style เพื่อทำ image embedding ขึ้นมา
#siamstr

2024-07-11 04:01:23

Elliptical Curve Digital Signature Algorithm
ECDSA เป็นฟังก์ชันการเข้ารหัสแบบอสมมาตร (asymmetric cryptographic function) ซึ่งอยู่บนสมการ 𝑦² = 𝑥³ + 𝑎𝑥 + 𝑏
ซึ่งจุดเด่นของ Elliptic curve คือเมื่อลากเส้นผ่านสองจุดบนเส้นโค้ง จะมีจุดที่สามที่เส้นตัดผ่านเสมอ จึงเหมาะสมที่จะใช้เป็น ฟังก์ชันทางเดียว (เมล็ดกาแฟและผงกาแฟที่ยกตัวอย่างในโพสต์ก่อน) เนื่องจากมันสามารถที่จะสร้างจุดบนเส้นโค้งที่ไม่มีความสัมพัธ์ใด ๆ กับจุดเริ่มต้นของมันหลังจากทำซ้ำหลาย ๆ ครั้ง โดยบิตคอยน์ใช้ secp256k1 ซึ่งมีพารามิเตอร์ดังนี้
1. a และ b บนสมการเป็น 0 และ 7 ตามลำดับ
2. Prime modulo: 2²⁵⁶ - 2³² - 2⁹ - 2⁸ - 2⁷ - 2⁶ - 2⁴ - 1
3. base point p (บาง source ใช้ว่า Generator point) ในเลขฐาน 16: 04 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798 483ADA77 26A3C465 5DA4FBFC 0E1108A8 FD17B448 A6855419 9C47D08F FB10D4B8
4. ลำดับในเลขฐาน 16: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141
* สุดท้ายแล้วสมการออกมาแบบนี้ 𝑦² = (𝑥³+7)over (F p)
* ซึ่งตัวเลขเหล่านี้ไม่ได้อุปโหลกขึ้นมามั่ว ๆ แต่เป็นเลขที่ได้มาตรฐานจาก SECG (The Standards for Efficient Cryptography Group)
อย่างที่กล่าวไว้โพสต์ก่อน private key นั้นมาจากการสุ่ม ส่วน public key นั้นมาจากการคำนวณตามสูตร
public key = private key * base point P
ซึ่งเป็นการทำ scalar multiplication และอย่างที่กล่าวไว้ข้างต้น base point P กำหนดโดย secp256k1และเป็นค่าเดียวกันสําหรับทุกคนที่สร้าง public key หมายความว่า private key หนึ่งอันผ่านสมการนี้ยังไงก็จะได้ public key เดิมเสมอ และเนื่องจากลักษณะของ Elliptic curve ที่เป็นฟังก์ชันที่ย้อนกลับไม่ได้ จึงทำให้ public key ไม่สามารถย้อนกลับไปเป็น private key ได้
#siamstr

2024-07-10 06:17:31

Digital keys บนบิตคอยน์
บิตคอยน์ใช้ PKE ซึ่งเป็น asymmetric cryptography เพื่อที่จะสร้างคู่กุญแจขึ้นมา นั้นคือ public key และ private key โดยหากมี private key เราสามารถคำนวณเพื่อหา public key ได้ แต่ในทางกลับกันการมี public key เพียงอย่างเดียวนั้นไม่สามารถย้อนกลับไปหา private key ได้ ถ้าจะให้เห็นภาพง่าย ๆ ลองจินตนาการถึง เมล็ดกาแฟกับผงกาแฟ โดยให้ private key เปรียบเสมือน เมล็ดกาแฟและให้ public key เป็นผงกาแฟ เราสามารถนำเมล็ดกาแฟมาบดเพื่อให้ได้ผงกาแฟเสมอ แต่ในทางกลับกันเราไม่สามารถนำผงกาแฟมาประกอบกับเป็นเมล็ดกาแฟได้ แล้วกุญแจทั้งสองสร้างอย่างไร ?
Private key นั้นสร้างโดยการสุ่มตัวเลข ซึ่งเป็นเลขฐาน 16 จำนวน 64 ตำแหน่ง จึงแทบจะเป็นไปไม่ได้เลยที่จะมีคนที่เผลอสร้าง private key แล้วจะออกมาซ้ำกัน เนื่องจาก private key นั้นมีความเป็นไปได้ถึง 16^64 หรือ 2^256 ซึ่งเท่ากับ 115,792,089,237,316,195,423,570,985,008,690,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000 หรือ 115 * 10^75 ความเป็นไปได้ ใครคิดจะ random เพื่อหาบิตคอยน์ก็สู้ ๆ นะครับผมเป็นกำลังใจให้
Public key สร้างโดยการใช้ private key ของเราไปผ่าน ECDSA (Elliptical Curve Digital Signature Algorithm)
แล้วกุญแจทั้งสองในบิตคอยน์นั้นสามารถทำอะไรได้บ้าง
Public key: มีหน้าที่สำคัญ ๆ อยู่สองอย่าง นั้นคือการสร้าง bitcoin address โดยการนำ public key ไป hash, ใช้เพื่อยืนยันธุรกรรมของบิตคอยน์ (ทั้งสองกระบวนการที่กล่าวมานั้นไม่จำเป็นต้องใช้ private key)
Private key: เป็นส่วนสำคัญในการทำธุรกรรมของบิตคอยน์เนื่องจากทุกธุรกรรมบนบิตคอยน์จำเป็นต้องมี digital signature เพื่อยืนยันว่าคุณเป็นเจ้าของบิตคอยน์นั้นจริง ๆ
* ที่สำคัญเลยคือ private คือของบิตคอยน์นั้นคุณควรเก็บไว้ให้ดีอย่าให้ใครรู้ เนื่องจากหากมีบุคคลอื่นรู้ถึง private key ของคุณ วกเขาก็จะสามารถสร้างธุรกรรมบิตคอยน์ด้วย digital signature ของคุณได้ (เขาจะขโมยบิตคอยน์ของคุณได้!!)