עסקת התחייבות מייצגת את המצב המוסכם של ערוץ וניתן להשתמש בה כדי ליישב אותה על הבלוקצ'יין של ביטקוין. בתרחיש המתואר ב-PR 5057, העסקה החדשה שנחתמה לא תועדה על ידי מוניטור הערוץ של LDK, הרכיב עוקב אחר תביעות הערוץ ברשת.
פער זה עלול להפוך תשלום מועבר להפסד. השולח הזדוני יכול לאשר את העסקה בשרשרת ולתת לתשלום להסדיר עם הנמען הבא. לאחר מכן, הוא יוכל לדרוש בחזרה את חוזה התשלום הנכנס כאשר יפוג, למרות שצומת ההעברה ידע את הסוד המשמש בדרך כלל לתביעת תשלום.
בקשת ההעברה הייתה משלמת במורד הזרם מבלי לשחזר את הכספים הנכנסים המתאימים. התיקון מאפשר שידור חוזר רק בזמן שהאישור של עמית נשאר יוצא מן הכלל וסגירה בכוח את הערוץ כאשר עמית טוען שעדכון שכבר אושר הוחמצם.
לצד תיקון החיבור מחדש של LDK, גרסה 0.2.7 מתייחסת לנתיב גניבה אחר הכולל תשלומי LSPS2 בדיוק בזמן, שבו שירות נזילות פותח ערוץ כחלק מטיפול בתשלום.
תשלום שיירט עלול להמחיש את הסכום שלו, ולגרום לשירות לפתוח ערוץ ולהעביר יותר ביטקוין מהתשלום הנכנס שסופק. השירות יכסה את ההפרש מהכספים שלו. PR 5042 מתייחס לבדיקת הסכום הזה.
חשיפה זו נוגעת לזרימת השירות של LSPS2. הערות v0.1.13 מפרטות את תיקון החיבור מחדש המשותף מבלי לציין את תיקון LSPS2.
פגמים אלו שונים מהסטת עמלת ספייס וטעינת מצבים שמורה בדוח LDK v0.2.6 של CryptoSlate מ-13 בספטמבר. Core Lightning הוא יישום נפרד, כמתואר בעדכון שלהלן.
תיעוד הארכיטקטורה של LDK מסביר שה-SDK מורכב ומבוצע בתוך יישומים. מפתחים חייבים לשלב את קוד הספרייה המתוקן הרלוונטי בתוכנה שנפרסה. עבור אינטגרציות LSPS2, הסבר ההתחייבות של PR 5042 מסמן שחוזי תשלומים הממוקמים בתור על ידי גרסה קודמת שומרים על סכומים לא מאושרים; הצוותים צריכים לתת דין וחשבון לחוזים הממתינים וכן לעדכן את הספרייה.