Open devrandom opened 9 months ago
The commitment point behavior is changed by this PR: https://github.com/ElementsProject/lightning/pull/6840
Prior behavior would be to do a complete commitment cycle (on original commitment and again for each splice RBF candidate) -- this PR changes the behavior to just do a single commitment for the new splice using the current commitment point number.
Our testing is using #6840
@ksedgwic Is this issue still happening?
Apologies, not sure if still happening
On Thu, Jul 11, 2024 at 11:57 AM Dusty Daemon @.***> wrote:
@ksedgwic https://github.com/ksedgwic Is this issue still happening?
— Reply to this email directly, view it on GitHub https://github.com/ElementsProject/lightning/issues/6870#issuecomment-2223674128, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAJNPTFXLEZUXGLMUZLYALZL3IRVAVCNFSM6AAAAABKXRVQBSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRTGY3TIMJSHA . You are receiving this because you were mentioned.Message ID: @.***>
-- Ken Sedgwick Bonsai Software, Inc. http://www.bonsai.com/ken/ (510) 269-7334 @.*** Public Key: http://www.bonsai.com/ken/ken.asc GPG Fingerprint: 4695 E5B8 F781 BF85 4326 9639 BBFC E515 8602 5550
Issue and Steps to Reproduce
We (VLS) are seeing remote per-commitment point number 1 provided to signer instead of point number 0. This occurs when signing the remote commitment transaction on top of the new splice.
We have a
vlsd
log excerpt in https://gitlab.com/lightning-signer/vls-hsmd/-/merge_requests/132#note_1649538928 with the captured hsmd protocol messages.I believe this happens when running any of the CLN
test_splicing.py
system tests.