พอเข้าใจหลักการได้ มองภาพออก ผมว่ากรณีป้องกันคนขายเงินบาทเบี้ยวเงินให้ service สร้าง lnurl ให้คนขาย sat ส่งมาให้ sevice ก่อน แล้วพอคนโอนบาทมาแล้ว sevice ก็สร้าง lnurl ถอนมาเพื่อรับ sat แต่แบบนี้อาจจะดูไม่ค่อยจะเป็น p2p ซักเท่าไหร่เพราะยังมี service เป็นตัวกลาง ซึ่งต้องสร้างควาทเชื่อใจให้กับผู้ใช้ในระดับหนึ่ง บางที protocol nostr อาจจะแก้ในจุดนี้ได้
ปล. รู้สึกว่า scenario 3 จะดูงง ๆ มีส่วนซ้ำกับ 2 คิดว่าน่าจะเขียนผิดนะครับ😅
ส่วนที่ 3 นี่นิ้วเบียดจริงครับ เพิ่งมาเห็น 555
เอาจริง ๆ ตัว Service ไม่ได้ถือเงินโดยตรงครับ แต่เป็นการครอบ Invoice จากที่ผู้รับสร้างขึ้นมาเป็น holdinvoice ซึ้งฝั่งผู้รับ sats มีลูกเล่นเพิ่มขึ้นเช่นการชะรอเงินไว้ยังไม่ settled เป็นระยะเวลานึงได้ และไม่ได้ถือเงินของผู้ใช้โดยตรง เนื่องจากเป็น invoice ที่สร้างจากของผู้ใช้ ตัว service จะเอาเงินคนใช้หนีไปไม่ได้เลยครับ
อ้อ ผมเพิ่งเก็ทคำว่า hold invoice คือ service เป็นคนถือ lnurl invoice ไว้ใช่มั้ยมั้ยครับ ดังนั้นการแลกเปลี่ยนก็จะเกิดขึ้นแบบ p2p จริง ๆ
ลูกเล่นการกำหนดช่วงเวลาก็น่าสนใจนะครับ กรณีที่มีการเบี้ยวเงิน หรือไม่โอนเงินบาทในเวลาที่กำหนด invoice นั้นก็ไม่สามารถทำงานได้ การแลกเปลี่ยนไม่เกิดขึ้น
ใช่ครับพี่ holdinvoice จะมาทำหน้าที่แบบเดียวกับระบบ escrow ได้ระดับนึง ถ้าเสริมกับ social graph แบบ nostr เข้าไปผมเชื่อว่าจะเป็นตลาดแลกเปลี่ยนที่มีความเชื่อถือได้ระดับนึง
ร้านค้าที่จริงใจปั้นตัวเองมาก็จะไม่สร้างตามเสื่อมเสียให้ตนเอง ส่วนพวกแสกมนั้นช่วงแรกถึงกลางอาจจะมีบ้าง แต่ระยะยาวมันจะอยู่ไม่ได้เอง
