혹시 비슷한 상황에  처한분께 도움이 필요하실지도 모르겠고 저도 나중에 다시 참고할 겸 잊어버리기 전에 남겨봅니다.  

------------------------------------------------------ 

간단 요약  -  미리 알아두면 좋은것  

1. 운영중이던  라이트닝 노드를 다른 장비로 옮기기 위해 새 하드웨어 동기화 후 24개 복구단어 세트와  SCB(static channel backup)로 채널 리커버리 하면  기존에 연결했던 모든 채널은 강제 종료됩니다. - 기존에 생각하는 리커버리 방식이 아닙니다.  

2. 버그인지 뭔지 모르겠지만 정상적인 최신 채널백업파일을 사용해도  채널정보가 복원안될수도 있습니다.  - 자산손실 가능성

3.  운영중인 노드를 이전할때는  연결했던 채널을 모두 합의종료하고  새로 개설하시는것을  강력히 추천합니다.  

4. 라이트닝 노드에서 사용하는 지갑은 우리가 알던 BIP39/44 호환 지갑이 아닌  aezeed 알고리즘을 사용하는 별도의 지갑입니다.

이 녀석은 지갑버전과 지갑의 생성날짜를 관리하는데.  복구단어가 비슷하게 생겼어도 기존 BIP39 호환지갑으로는 복구가 안되니 참고하세요.. 

5. 채널 강제 종료중에는  채널 종료 트랜젝션의 처리를  위해 지갑에  일정부부 출금가능한 자산(수수료)이  있어야 합니다.   

지갑이 비어있으면  TX생성이 안되고 진행이 멈춥니다.  

6. 최근 비트코인 트랜젝션은  예전( 6-7년전)과 달리  전송된지 72시간 또는 14일이 지나면 사라지니  주의가 필요합니다.

예전처럼 그냥 기다리면 안됩니다. 

---------------------------------------------------------------

이하  일어난 일 순으로 기술.. 

( 노드 마이그레이션 중 알수 없는 이유로 일부 채널 상태 정보가 누락되어 일부 채널이 좀비 채널이 됨. 

좀비채널은  채널당사자간의 긴밀한 협조가 없으면 복구가 힘듦.

다행이  오리지널 노드에  4개 채널의 정보가 있어 정상종료 했으나 지갑이 비워진 상태라  종료TX가 처리가 안되고 대기.)

기존에  10W정도의  소비전력을 사용하는  Odroid  H2 (J4105)에    1TB   NVME를 하나 꼽고   Esxi 6.7로 가상화해서  

우분투 22.04 LTS와  win10을 각각 설치 후    우분투에는 Umbrel을 설치해서  라이트닝 노드를 운영중이었고.  

윈10은  파이썬 설치해서   모니터링용으로 사용중이었습니다.  

처음에 움브렐을 운영할때는 4GB정도의 램을 할당했었으나.  버거워 하는 모습을 보이길래   8GB까지 추가로 늘려주었으나 이또한 버거워해서  12GB 램을 할당하고 사용중이었습니다. 

문제는    사용앱이  점점 늘어나고   BTCPay  server를 운영해보려 하니 성능저하가 너무 심해져서   전용 장비로  옮겨야겠다 생각했습니다.  

전부 재설치하기도  귀찮아서   새노드에  움브렐 설치 후  기존  노드의 디렉토리를 모두 NFS로 마운트하고 복사했는데.

이상하게 잘 동작을 안하길래..  재설치후   지갑복원하고  채널복원 하면 되겠다 싶었습니다.  

우분투의  lightning앱과 Ride the lightning,  ThunderHub 에서 각각 운영중인 채널들을  별개로  백업후  verify까지 하고 기존  노드를 종료했습니다.  

그리고..  bitcoin  chain동기화가 끝난 새 노드에   24단어 세트를 넣고 라이트닝 노드를 실행했고. 

지갑의 모든 트랜젝션 스캔이 끝나면   비트코인 온체인 자산이 복구되고   

채널정보를 입력해서 복구하는줄 알았는데....  설정에서 리커버 채널을  선택하고  백업된 최신 채널백업을 업로드하니. 

헐... 모든 채널이 종료되기 시작합니다. 

그렇습니다.  24단어로 지갑을 복구한 후   채널백업을 업로드 한다는 의미는  마이그레이션이 아니고..

기존 노드가 복구불능이라   라이트닝네트워크의 채널에 분산되어 있는 내 자산을 회수하는 비상수단이었던 거죠.

암튼 잠시 당황하다가 정신을 차리고 살펴보니..    채널을 종료(closing)하는 방법은 3가지가 있는데.  

1. Collaborative close

서로 간의 채널인 온라인 상태에서 상호합의하게 진행되는 협업적인 종료입니다. 

최신의 잔액을 공유하고 있는 상태에서 진행되기에  일반적인 종료 절차를 따르고 문제소지가 거의 없습니다. 

2.  Force close

노드가  연결이  되지 않거나 하면  강제 종료를 할수 있는데.   위에서 말한  새노드에  채널 정보를 입력하는  자체로 강제종료 상태가 됩니다.  이경우에는   강제종료를 수행한 당사자는 2016블럭 또는 약 2주간 자금이 묶이게 됩니다.  

내가 게시한  채널상태정보(잔액정보 등)와   채널 상대방이 가진  최신채널정보가 일치하면 문제없이 종료되어 자산이 돌아오는데.  문제는  내가 가진  채널의 상세 정보가  사라지고.    상대방이 응답하지 않으면  자산은 영구 미아가 될수도 있습니다.  

3. Disputed close

일단  2주를 기다려서 자산이 복구되는걸 기다려보기로 합니다.   

2주를 기다리니  총 25개의 채널중  21개는  정상종료가 되었는데...  채널 4개는 채널 종료중 메시지만 뜨고 정작 종료가 안됩니다. 

매뉴얼을 참고해서  콘솔에서  펜딩채널 정보를 확인해보니 아래처럼 나옵니다.  

보면  밸런스 정보가 하나도 없습니다.   chan_status_flags 에도  보면 로컬 데이터 손실로 표시됩니다. 

sudo ./scripts/app compose lightning exec lnd lncli pendingchannels

Output was below

{
“channel”: {
“remote_node_pub”: “03864ef025fde8fb587d989186ce6a4a186895ee44a9 26bfc370e2c366597a3f8f”,
“channel_point”: “41f1034ff5df04e4ef247eae3dd90e2f44a27cdcbb05c3 4ec9d057156687156e:0”,
“capacity”: “1000000”,
“local_balance”: “0”,
“remote_balance”: “0”,
“local_chan_reserve_sat”: “0”,
“remote_chan_reserve_sat”: “0”,
“initiator”: “INITIATOR_LOCAL”,
“commitment_type”: “ANCHORS”,
“num_forwarding_packages”: “0”,
“chan_status_flags”: "ChanStatusLocalDataLoss|ChanStatusRestored ",
“private”: true
},
“limbo_balance”: “0”,
“commitments”: {
“local_txid”: “”,
“remote_txid”: “”,
“remote_pending_txid”: “”,
“local_commit_fee_sat”: “0”,
“remote_commit_fee_sat”: “0”,
“remote_pending_commit_fee_sat”: “0”
},
“closing_txid”: “”
}
]
}

아래처럼  강제종료 명령을 내려도   에러가 나며  진행이 안됩니다.  

sudo ./scripts/app compose lightning exec lnd lncli closechannel --force 

41f1034ff5df04e4ef247eae3dd90e2f44a27cdcbb05c34ec9d057156687156e 0
[lncli] rpc error: code = Unknown desc = cannot close channel with state: ChanStatusLocalDataLoss|ChanStatusRestored

해당 상태로 계속 두면 좀비채널이 된다고 해서  걱정이 좀 많이 됩니다.  '

검색해보면  몇년째 이상태인 사람들도 꽤 있습니다.  

상대측 노드에서 종료를 진행해주면 그쪽 마지막 정보로 종료가 가능하기에   상대측 노드에  연락할 방법을 찾아봤는데.   

1ML or amboss에  연락처를 기재해 두었으면 좋았는데. 그렇지 않네요.  

그러다가   lightningnetwork.plus  에서   가입자에게 쪽지를 보낼수 있어. 해당 사이트에서  쪽지를 보내봅니다. 

복구중  사고가 생겨서 강제종료중인데  채널 종료 요청한다... 뭐 이런 메시지 입니다만.. 

며칠째 쪽지를 아무도 읽지 않습니다. 

같은 지갑을 공유하는 라이트닝 노드가 동시에 네트워크에 존재하면 안된다고 알고 있어서..

일단  기존에 90%정도 회수한 지갑의 비트를 전부 개인지갑으로  옮기고.  노드를 종료했습니다.  

그리고  오리지널 노드를 켜봤습니다.   16일넘게 멈춰놔서 동기화에 시간이 조금 걸리긴했는데. 일단  동기화후 살펴보니.

펜딩된 채널 4개가 온라인 상태로 되어 있고  밸런스도 정상적으로 보여집니다. 

여기서 종료하면  정상종료가 가능할것으로 예상해봅니다.   

종료 명령을 내려보니    지난번 과는 다르게 밸런스가 정상으로 표시되면서  종료 중 처리가 됩니다.  

 "channel": {

                "remote_node_pub": "03864ef025fde8fb587d989186ce6a4a186895ee44a926bfc370e2c366597a3f8f",

                "channel_point": "41f1034ff5df04e4ef247eae3dd90e2f44a27cdcbb05c34ec9d057156687156e:0",

                "capacity": "1000000",

                "local_balance": "755727",

                "remote_balance": "242207",

                "local_chan_reserve_sat": "10000",

                "remote_chan_reserve_sat": "10000",

                "initiator": "INITIATOR_LOCAL",

                "commitment_type": "ANCHORS",

                "num_forwarding_packages": "0",

                "chan_status_flags": "ChanStatusBorked|ChanStatusCommitBroadcasted|ChanStatusLocalCloseInitiator",

                "private": false

그러나 하루가 지나도  추가 진행이 되지 않고 계속 그대로 입니다.    종료처리 되는 maturity  표시가 나와야 하는데 안나오네요. 

추가진행이 안되길래   아래 명령으로 강제 종료명령을 내리니  출금진행  TXID가 생성되었습니다.  

 sudo ./scripts/app compose lightning exec lnd lncli closechannel --force 41aeed955fead824a3aff5606f2d0c9c48aa5517432714bc74391fa4bbd33708 0

{

        "closing_txid": "0039d5bbac131fe17e3ca1088f4f7652fda5689ea9d4c105418edfb6d1fb9dce"

}

그런데  TXID가 검색도 안되고   그이후에도 별다른 진행이 없어서     혹시 지갑이 전부 비어서  종료처리에 필요한 사토시가 없어서 그런가  싶어.. 지갑에  5만사토시 정도를 보냈습니다.   그랬더니  바로 전송수수료가 처리되면서 추가 진행이 됩니다.  

그런데  현재 멤풀의  처리가능 수수료가  10사토시/바이트 이상인데..  해당 클로징 트랜젝션의 수수료는 5사토시 입니다.  

수수료 낮아지길 기다리기는것도  힘들어서   RBF로 수수료를 올려보기로 합니다.  

4개 채널의 출금이 하나로 묶여있어서  BRF 수수료를   충분히 줘 봅니다   80.. 

sudo ./scripts/app compose lightning exec lnd lncli wallet bumpfee  --sat_per_vbyte 80   "TXID"

웃긴게. 내 노드의 멤풀에서는  RBF가 적용되어  수수료가 11로 올라갔는데.    블럭생성될때 블럭에 포함되지 않습니다.

외부 멤풀에서 확인해보니  내가  새로 생성한 TX가 브로드캐스팅이 안되어 보이지  않습니다.   음... 

외부 멤풀의 TX 브로드캐스팅  기능을 이용해서  트랜젝션을 전송해봅니다.

https://mempool.space/ko/tx/push

bad-txns-inputs-missingorspent 에러가 나면서 진행이 되지 않습니다.  

뭔가 지갑이  꼬인모양입니다.    검색해봐도 해결책이 떠오르지 않습니다.  

일단 노드를 재부팅하고  자포자기로 반 포기상태에 들어갔는데..   엥.. 한시간쯤 뒤어 살펴보니  채널 종료 TX가 컨펌되었습니다.  

재부팅으로   위 문제가 해결되면서  브로드캐스팅이 되었나봅니다.  

아래는 정상종료후 자금이 풀리길 기다리는 최종대기 상태정보입니다. 

{

            "channel": {

                "remote_node_pub": "03864ef025fde8fb587d989186ce6a4a186895ee44a926bfc370e2c366597a3f8f",

                "channel_point": "41f1034ff5df04e4ef247eae3dd90e2f44a27cdcbb05c34ec9d057156687156e:0",

                "capacity": "1000000",

                "local_balance": "755727",

                "remote_balance": "242207",

                "local_chan_reserve_sat": "0",

                "remote_chan_reserve_sat": "0",

                "initiator": "INITIATOR_LOCAL",

                "commitment_type": "ANCHORS",

                "num_forwarding_packages": "0",

                "chan_status_flags": "",

                "private": false

            },

            "closing_txid": "e26641b2c8965597811bf4e9e1cdda3049575d90e1fdf83948cb6edf49bcfba0",

            "limbo_balance": "756057",

            "maturity_height": 806776,

            "blocks_til_maturity": 642,

            "recovered_balance": "0",

            "pending_htlcs": [

            ],

            "anchor": "LIMBO"

 }

이전 상태정보와 다른게     자금이 풀리는 시점이 나옵니다.  

maturity_height": 806776,

"blocks_til_maturity": 642, 

위 대기시간이 지나면 자금이 풀려서 지갑으로 최종적으로 들어옵니다.  

아직 몇일 더 기다려야 하지만..  잘 될거라 믿고  글 남겨봅니다.  예상외의 일이 생기면 다시 수정하겠습니다. 

-----------------------------------------------------------------------------------------------------------------------------------

9월5일  16:00  추가 

강제 채널 종료 트랜젝션이 활성된 후  이전  초기 채널 오픈시 상대측에 의해 설정된  CSV딜레이에 의해  240블럭을 기다리던 3개의 채널은    지정된  블럭에 도달하니  현 전송수수료에 맞춰서  릴리즈 트랜젝션(?)이 자동생성되고.   수수료  급등이 없어  바로 다음블럭에  컨펌되어  지갑으로 들어왔습니다.  

CSV_DELAY가  720으로 설정되었던 마지막 채널 하나는   약 3.3일을 더 기다려야 최종적으로 릴리즈 될거 같습니다.