<unnamed>

Public Key

npub10yqgu7q6mmrk0nywywd4x0kukx029cnqly5p4yf9ay6zthavjw2syrhcl3

Profile Code

nprofile1qqs8jqyw0qdda3m8ej8z8x6n8mwtr84zufs0j2q6jyj7jdp9m7kf89gpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsdu5aw7

Publishing to

relay.snort.social

Last Notes

2026-10-14 15:12:10 UTC

https://www.twitch.tv/kritta2933 #siamstr

2025-03-18 04:37:31 UTC

Compressed Public Keys
ในยุคแรก ๆ ของบิตคอยน์นั้น มีเพียงการสร้าง public key แบบ 65 Bytes เท่านั้น แต่ในเวลาต่อมา เหล่านักพัฒนาในยุคหลังได้พบวิธีการสร้าง public key แบบใหม่ที่มีเพียง 33 Bytes และสามารถทำงานร่วมกันกับโหนดทั้งหมดในขณะนั้นได้ จีงไม่จะเป็นต้องเปลี่ยนแปลงกฎหรือโครงสร้างภายในโปรโตคอลของบิตคอยน์ โดย poublic key แบบใหม่ที่มีขนาด 33 Bytes นี้เรียกว่า compressed public key (public key ที่ถูกบีบอัด) และมีการเรียก public key ที่มีขนาด 65 Bytes ว่า uncompressed public key (public key ที่ไม่ถูกบีบอัด) ซึ่งประโยชน์ของ public key ที่เล็กลงนั้น นอกจากจะช่วยให้การส่ง public key ให้ผู้อื่นทำได้ง่ายขึ้นแล้ว ยังช่วยให้ธุรกรรมมีขนาดเล็กลง และช่วยให้สามารถทำการชำระเงินได้มากขึ้นในบล็อกเดียวกัน
อย่างที่เราได้เรียนรู้จากเนื้อหาในส่วนของ public key เราได้ทราบว่า public key คือจุด (x, y) บนเส้นโค้งวงรี เนื่องจากเส้นโค้งแสดงฟังก์ชันทางคณิตศาสตร์ จุดบนเส้นโค้งจึงเป็นคำตอบของสมการ ดังนั้นหากเรารู้พิกัด x เราก็สามารถคำนวณพิกัด y ได้โดยแก้สมการ y² mod p = (x³ + 7) mod p นั่นหมายความว่าเราสามารถเก็บเพียงพิกัด x ของ public key โดยละพิกัด y ไว้ ซึ่งช่วยลดขนาดของกุญแจและพื้นที่ที่ต้องใช้เก็บข้อมูลลง 256 บิต การลดขนาดลงเกือบ 50% ในทุกธุรกรรมรวมกันแล้วช่วยประหยัดข้อมูลได้มากมายในระยะยาว!
นี่คือ public key ที่ได้ยกเป็นตัวอย่างไว้ก่อนหน้า
```
x = F028892BAD7ED57D2FB57BF33081D5CFCF6F9ED3D3D7F159C2E2FFF579DC341A
y = 07CF33DA18BD734C600B96A72BBC4749D5141C90EC8AC328AE52DDFE2E505BDB
```
และนี่คือ public key ที่มีตัวนำหน้า 04 ตามด้วยพิกัด x และ y ในรูปแบบ 04 x y:
```
K = 04F028892BAD7ED57D2FB57BF33081D5CFCF6F9ED3D3D7F159C2E2FFF579DC341A07CF33DA18BD734C600B96A72BBC4749D5141C90EC8AC328AE52DDFE2E505BDB
```
uncompressed public key นั้นจะมีตัวนำหน้าเป็น 04 แต่ compressed public key จะมีตัวนำหน้าเป็น 02 หรือ 03 โดยเหตุผลนั้นมาจากสมการ y² mod p = (x³ + 7) mod p เนื่องจากด้านซ้ายของสมการคือ y² คำตอบสำหรับ y จึงเป็นรากที่สอง ซึ่งอาจมีค่าเป็นบวกหรือลบก็ได้ หากมองเชิงภาพ นี่หมายความว่าพิกัด y ที่ได้อาจอยู่เหนือหรือใต้แกน x เราต้องไม่ลืมว่าเส้นโค้งมีความสมมาตร ซึ่งหมายความว่ามันจะสะท้อนเหมือนกระจกโดยแกน x ดังนั้น แม้เราจะละพิกัด y ได้ แต่เราต้องเก็บ เครื่องหมาย ของ y (บวกหรือลบ) หรืออีกนัยหนึ่งคือเราต้องจำว่ามันอยู่เหนือหรือใต้แกน x เพราะแต่ละตำแหน่งแทนจุดที่แตกต่างกันและเป็น public key ที่แตกต่างกัน
เมื่อคำนวณเส้นโค้งวงรีในระบบเลขฐานสองบนสนามจำกัดของเลขจำนวนเฉพาะ p พิกัด y จะเป็นเลขคู่หรือเลขคี่ ซึ่งสอดคล้องกับเครื่องหมายบวก/ลบตามที่อธิบายก่อนหน้านี้ ดังนั้น เพื่อแยกความแตกต่างระหว่างค่าที่เป็นไปได้สองค่าของ y เราจึงเก็บ compressed public key ด้วยตัวนำหน้า 02 ถ้า y เป็นเลขคู่ และ 03 ถ้า y เป็นเลขคี่ ซึ่งช่วยให้ซอฟต์แวร์สามารถอนุมานพิกัด y จากพิกัด x และคลายการบีบอัดของ public key ไปยังพิกัดเต็มของจุดได้อย่างถูกต้อง ดังภาพประกอบต่อไปนี้
https://image.nostr.build/17e2b76fbdfd7bf5b6e39f86fc59511bd835b4af94c724df419ae8f1f78a902e.jpg
นี่คือ public key เดียวกันกับที่ยกตัวอย่างไว้ข้างต้นซึ่งแสดงให้เห็นในรูป compressed public key ที่เก็บใน 264 บิต (66 ตัวอักษรเลขฐานสิบหก) โดยมีตัวนำหน้า 03 ซึ่งบ่งชี้ว่าพิกัด y เป็นเลขคี่:
```
K = 03F028892BAD7ED57D2FB57BF33081D5CFCF6F9ED3D3D7F159C2E2FFF579DC341A
```
compressed public key สอดคล้องกับ private key เดียวกันกับ uncompressed public key หมายความว่ามันถูกสร้างจาก private key เดียวกัน แต่อย่างไรก็ตาม มันก็มีส่วนที่แตกต่างจาก uncompressed public key นั้นคือ หากเราแปลง compressed public key เป็น commitment โดยใช้ฟังก์ชัน HASH160 (RIPEMD160(SHA256(K))) มันจะสร้าง commitment ที่แตกต่างจาก uncompressed public key และจะนำไปสู่ bitcoin address ที่แตกต่างกันในที่สุด สิ่งนี้อาจทำให้สับสนเพราะหมายความว่า private key เดียวสามารถสร้าง public key ในสองรูปแบบที่แตกต่างกัน (แบบบีบอัดและแบบไม่บีบอัด) ซึ่งสร้าง bitcoin address ที่แตกต่างกัน
compressed public key เป็นค่าเริ่มต้นในซอฟต์แวร์บิตคอยน์เกือบทั้งหมดในปัจจุบัน และถูกกำหนดให้ใช้กับคุณสมบัติใหม่บางอย่างที่เพิ่มในการอัปเกรดโปรโตคอลในภายหลัง
อย่างไรก็ตาม ซอฟต์แวร์บางตัวยังคงต้องรองรับ uncompressed public key เช่น แอปพลิเคชันกระเป๋าเงินที่นำเข้า private key จากกระเป๋าเงินเก่า เมื่อกระเป๋าเงินใหม่สแกนบล็อกเชนสำหรับผลลัพธ์และอินพุต P2PKH เก่า มันจำเป็นต้องรู้ว่าควรสแกนกุญแจขนาด 65 ไบต์ (และ commitment ของกุญแจเหล่านั้น) หรือกุญแจขนาด 33 ไบต์ (และ commitment ของกุญแจเหล่านั้น) หากไม่สแกนหาประเภทที่ถูกต้อง อาจทำให้ผู้ใช้ไม่สามารถใช้ยอดคงเหลือทั้งหมดได้ เพื่อแก้ไขปัญหานี้ เมื่อส่งออก private key จากกระเป๋าเงิน WIF ที่ใช้แสดง private key ในกระเป๋าเงินบิตคอยน์รุ่นใหม่จะถูกนำไปใช้แตกต่างกันเล็กน้อยเพื่อบ่งชี้ว่า private key เหล่านี้ถูกใช้ในการสร้าง compressed public key
#siamstr #righttech
อยากแชร์ไปให้คนที่ไม่ได้อยู่บน Nostr อ่านอย่างงั้นเหรอ !?!?!?!? งั้นทางเราขอแนะนำ: https://learnbn.npub.pro/

2025-03-15 06:43:55 UTC

สรุป เสริม เติมแต่ง เนื้อหาของ RightTech ep.2 อีกเรื่องนึง
# Legacy addresses for P2PKH
อย่างที่รู้ ๆ กันว่าในสมัยก่อนการส่งบิตคอยน์ทำได้ด้วยการขอ IP ของปลายทางที่เราต้องการส่ง เพื่อให้โหนดของเราทำการเชื่อมต่อกับโหนดของคนรับเพื่อของ public key
แน่นอนว่าการป้อนที่อยู่ IP ของคนที่คุณต้องการจ่ายเงินให้นั้นมีข้อดีหลายประการ แต่ก็มีข้อเสียหลายประการเช่นกัน หนึ่งในข้อเสียที่สำคัญคือผู้รับจำเป็นต้องให้กระเป๋าสตางค์ของพวกเขาออนไลน์ที่ที่อยู่ IP ของพวกเขา และต้องสามารถเข้าถึงได้จากโลกภายนอก
ซึ่งสำหรับคนจำนวนมากนั่นไม่ใช่ตัวเลือกที่เป็นไปได้เพราะหากพวกเขา:
- ปิดคอมพิวเตอร์ในเวลากลางคืน
- แล็ปท็อปของพวกเขาเข้าสู่โหมดสลีป
- อยู่หลังไฟร์วอลล์
- หรือกำลังใช้การแปลงที่อยู่เครือข่าย (NAT)
โดยบิตคอยน์แก้ปัญหานี้ด้วย ฟังก์ชันแฮช (hash function) ซึ่งเป็นฟังก์ชันที่รับข้อมูลที่อาจมีขนาดใหญ่ นำมาแฮช และให้ผลลัพธ์เป็นข้อมูลขนาดคงที่ ฟังก์ชันแฮชจะผลิตผลลัพธ์เดียวกันเสมอเมื่อได้รับข้อมูลนำเข้าแบบเดียวกัน และฟังก์ชันที่ปลอดภัยจะทำให้เป็นไปไม่ได้ในทางปฏิบัติสำหรับผู้ที่ต้องการเลือกข้อมูลนำเข้าอื่นที่ให้ผลลัพธ์เหมือนกันได้ นั่นทำให้ผลลัพธ์เป็น คำมั่นสัญญา (commitment) ต่อข้อมูลนำเข้า เป็นสัญญาว่าในทางปฏิบัติ มีเพียงข้อมูลนำเข้า x เท่านั้นที่จะให้ผลลัพธ์ X
สมมติว่าผมต้องการถามคำถามคุณและให้คำตอบของผมในรูปแบบที่คุณไม่สามารถอ่านได้ทันที สมมติว่าคำถามคือ "ในปีไหนที่ซาโตชิ นาคาโมโตะเริ่มทำงานบนบิทคอยน์?" ผมจะให้การยืนยันคำตอบของผมในรูปแบบของ
ผลลัพธ์จากฟังก์ชันแฮช SHA256 ซึ่งเป็นฟังก์ชันที่ใช้บ่อยที่สุดในบิทคอยน์:
```
94d7a772612c8f2f2ec609d41f5bd3d04a5aa1dfe3582f04af517d396a302e4e
```
ต่อมา หลังจากคุณบอกคำตอบที่คุณเดาสำหรับคำถามนั้น ผมสามารถเปิดเผยคำตอบของผมและพิสูจน์ให้คุณเห็นว่าคำตอบของผม เมื่อใช้เป็นข้อมูลสำหรับฟังก์ชันแฮช จะให้ผลลัพธ์เดียวกันกับที่ผมให้คุณก่อนหน้านี้
```
$ echo "2007. He said about a year and a half before Oct 2008" | sha256sum
94d7a772612c8f2f2ec609d41f5bd3d04a5aa1dfe3582f04af517d396a302e4e
```
ทีนี้ให้สมมติว่าเราถามบ็อบว่า " public key ของคุณคืออะไร?" บ็อบสามารถใช้ฟังก์ชันแฮชเพื่อให้การยืนยันที่ปลอดภัยทางการเข้ารหัสต่อ public key ของเขา หากเขาเปิดเผยกุญแจในภายหลัง และเราตรวจสอบว่ามันให้ผลการยืนยันเดียวกันกับที่เขาให้เราก่อนหน้านี้ เราสามารถมั่นใจได้ว่ามันเป็นกุญแจเดียวกันที่ใช้สร้างการยืนยันก่อนหน้านี้
ฟังก์ชันแฮช SHA256 ถือว่าปลอดภัยมากและให้ผลลัพธ์ 256 บิต (32 ไบต์) น้อยกว่าครึ่งหนึ่งของขนาด public key ของบิทคอยน์ดั้งเดิม แต่อย่างไรก็ตาม มีฟังก์ชันแฮชอื่นๆ ที่ปลอดภัยน้อยกว่าเล็กน้อยที่ให้ผลลัพธ์ขนาดเล็กกว่า เช่น ฟังก์ชันแฮช RIPEMD-160 ซึ่งให้ผลลัพธ์ 160 บิต (20 ไบต์) ด้วยเหตุผลที่ซาโตชิ นาคาโมโตะไม่เคยระบุ เวอร์ชันดั้งเดิมของบิทคอยน์สร้างการยืนยันต่อ public key โดยการแฮชกุญแจด้วย SHA256 ก่อน แล้วแฮชผลลัพธ์นั้นด้วย RIPEMD-160 ซึ่งให้การยืนยันขนาด 20 ไบต์ต่อ public key
เราสามารถดูสิ่งนี้ตามอัลกอริทึม เริ่มจากกุญแจสาธารณะ K เราคำนวณแฮช SHA256 และคำนวณแฮช RIPEMD-160 ของผลลัพธ์ ซึ่งให้ตัวเลข 160 บิต (20 ไบต์):
A = RIPEMD160(SHA256(K))
โดย K คือ public key และ A คือผลลัพธ์
ทีนี้เราคงเข้าใจวิธีสร้างการยืนยันต่อ public key แล้ว ต่อไปเราจะมาดูวิธีการ
ใช้งานโดยพิจารณาสคริปต์เอาต์พุตต่อไปนี้:
```
OP_DUP OP_HASH160 <Bob's commitment> OP_EQUAL OP_CHECKSIG
```
และสคริปต์อินพุตต่อไปนี้:
```
<Bob's signature> <Bob's public key>
```
และเมื่อเรารวมมันเข้าด้วยกันเราจะได้ผลลัพธ์ดังนี้:
```
<Bob's signature> <Bob's public key> OP_DUP OP_HASH160 <Bob's commitment> OP_EQUAL OP_CHECKSIG
```
จากนั้น เราเริ่มวางรายการลงในสแต็ก ลายเซ็นของบ็อบถูกวางก่อน จากนั้น public key ของเขาถูกวางไว้ด้านบน จากนั้นดำเนินการ OP_DUP เพื่อทำสำเนารายการบนสุด ดังนั้นรายการบนสุดและรายการที่สองจากบนในสแต็กตอนนี้เป็น public key ของบ็อบทั้งคู่ การดำเนินการ OP_HASH160 ใช้ (ลบ) public key บนสุดและแทนที่ด้วยผลลัพธ์ของการแฮชด้วย RIPEMD160(SHA256(K)) ดังนั้นตอนนี้บนสุดของสแต็กคือแฮชของ public key ของบ็อบ ต่อไป commitment ถูกเพิ่มไว้บนสุดของสแต็ก การดำเนินการ OP_EQUALVERIFY ใช้รายการสองรายการบนสุดและตรวจสอบว่าพวกมันเท่ากัน ซึ่งควรเป็นเช่นนั้นหาก public key ที่บ็อบให้ในสคริปต์อินพุตเป็น public key เดียวกันกับที่ใช้สร้างการยืนยันในสคริปต์เอาต์พุตที่อลิซจ่าย หาก OP_EQUALVERIFY ล้มเหลว ทั้งสคริปต์จะล้มเหลว สุดท้าย เราเหลือสแต็กที่มีเพียงลายเซ็นของบ็อบและ public key ของเขา รหัสปฏิบัติการ OP_CHECKSIG ตรวจสอบว่าพวกมันสอดคล้องกัน ดังรูปที่แสดงด้านล่าง
https://image.nostr.build/3ea1036b7de3d83b960d1ed862e738120159e4f173d55a4dfdaddc75c3b25166.png
แม้กระบวนการของการ pay-to-publickey-hash(P2PKH) อาจดูซับซ้อน แต่มันทำให้การที่อลิซจ่ายเงินให้บ็อบมีเพียงการยืนยันเพียง 20 ไบต์ต่อ public key ของเขาแทนที่จะเป็นตัวกุญแจเอง ซึ่งจะมีขนาด 65 ไบต์ในเวอร์ชันดั้งเดิมของบิทคอยน์ นั่นเป็นข้อมูลที่น้อยกว่ามากที่บ็อบต้องสื่อสารกับอลิซ
แต่อย่างไรก็ตาม เรายังไม่ได้พูดถึงวิธีที่บ็อบรับ 20 ไบต์เหล่านั้นจากกระเป๋าเงินบิทคอยน์ของเขาไปยังกระเป๋าเงินของอลิซ มีการเข้ารหัสค่าไบต์ที่ใช้กันอย่างแพร่หลาย เช่น เลขฐานสิบหก แต่ข้อผิดพลาดใด ๆ ในการคัดลอกการยืนยันจะทำให้บิทคอยน์ถูกส่งไปยังเอาต์พุตที่ไม่สามารถใช้จ่ายได้ ทำให้พวกมันสูญหายไปตลอดกาล โดยในส่วนถัดไป เราจะดูที่การเข้ารหัสแบบกะทัดรัดและการตรวจสอบความถูกต้อง
#siamstr #righttech
อยากแชร์ไปให้คนที่ไม่ได้อยู่บน Nostr อ่านอย่างงั้นเหรอ !?!?!?!? งั้นทางเราขอแนะนำ: https://learnbn.npub.pro/