Lightning Network 라우팅 노드에 해결되지 않는 가비지 트랜잭션이 공급되면 어떻게됩니까? 요컨대, 라우팅 노드에 많은 슬픔을 초래합니다. 한때 순조롭고 글로벌 한 결제 시스템이었던 것은 정통한 스크립트 작성자의 사소한 노력으로 잠길 수 있습니다.
소규모 라우팅 노드 팀에서 작업하면서 실제 자금으로 공격 테스트를 성공적으로 수행하고 "리핑”공격 설명 주스트 예거. 이 공격은 자금 도난이 아니기 때문에 슬픔 공격이라고 불리지 만 피해자의 번개 자금이 동결되게합니다. 우리가 발견 한 사실은 슬픔이 비트 코인으로 수익을 올릴 것으로 예상하는 대규모 "wumbo"채널에 심각한 위협이되지만 일정 기간 동안 만 자금이 동결된다는 것입니다.
이것은 대부분 슬픔에 잠긴 공격입니다. 자금 손실은 없지만 피해자는 값 비싼 채널 강제 종료에 대해 비용을 지불해야 할 수 있습니다. 이것은 메인 넷 라이트닝의 알려진 취약점이며 특히 비트 코인 라이트닝 네트워크의 초기 시장 단계에서 이해하고 우선 순위를 정해야합니다.
이 테스트에 기꺼이 참여해 주신 Clark Burkhardt와 Phillip Sheppard에게 감사 드리며,이 취약점에 관심과 우선 순위를 부여하기 위해 지칠 줄 모르는 노력에 대해 Jager에게 감사드립니다. Jager는 데모를 위해 공격자 역할을 수행했으며 Burkhardt와 Sheppard는 연결된 피해자 라우팅 노드로 저와 합류했습니다.
공격 작동 방식
공격자는 최종 결제로 해결되지 않는 Hashed Time Locked Contract (HTLC)로 하나 (또는 여러) 채널을 포화시킵니다. 이들은 HODL 송장으로 알려진 특별한 유형의 HTLC입니다. 이러한 미해결 HTLC 중 483 개만이 방향 당 채널을 압도하는 데 필요합니다. HTLC가 채널에 있으면 해당 채널을 협력 적으로 닫는 트랜잭션을 포함하여 동일한 채널 방향을 사용하는 모든 트랜잭션이 불가능합니다.
이론적으로 공격자는 피해자에게 연락하여 (아마도 키 엔드 메시지 또는 "양파 덩어리"를 통해) 공격을 중단하기 위해 몸값을 요구할 수 있습니다. 몸값이 지불되면 공격자는 해결되지 않은 지불금을 제거하여 공격을 끝낼 수 있습니다. 공격은 무기한으로 지속될 수 있으며 해당 채널의 모든 라우팅 및 지불 활동을 중지합니다. 그러면 Lightning 채널의 자금이 동결됩니다.
인바운드 및 아웃 바운드 모두에서 각 방향으로 483 개의 HTLC를 사용하여 채널에서 양방향 결제가 지연 될 수 있습니다.
공격을 받고있는 Burkhardt에 대한 균형 잡힌 채널의 Thunderhub보기. 채널은 Burkhardt가 오프라인 상태 인 것처럼 "활성화되지 않음"으로 표시되지만 그렇지 않습니다. 파란색으로 표시된 금액은 sats의 로컬 잔액이고, 녹색으로 표시된 금액은 Burkhardt가 소유 한 sats의 원격 잔액입니다. 출처: Thunderhub.
공격자가 이런 일을하는 이유는 무엇입니까?
가장 먼저 떠오르는 동기는 대속을 요구하는 것입니다. 이 공격은 피해자에게 고통을 야기하며, 공격이 중단 될 것이라는 확신 없이도 몸값을 지불하는 것이 피해자에게 매력적일 수 있습니다. 피해자에게 연락하는 것은 공격자에게 위험 할 수 있지만 몸값 지불이 누군가가 이것을하는 유일한 이유가 아닐 수도 있습니다.
슬픔 공격을 시작하는 이차적 인 인센티브는 라우팅 경쟁을 방해하는 것입니다. 경쟁자의 경로를 방해하면 공격자가 소유 한 경로에 대한 더 많은 요구가 발생할 수 있습니다.
벤치 마크로 Lightning Labs의 루프 노드는 때때로 지불 수수료 (ppm) (2,500 %)의 0.25ppm을 지불하는 유동성에 대한 지속적인 수요가 있음을 고려하십시오. 내 경험상, 그들은 일반적으로 약 16 주 (연간 비율 5.2 %) 안에 XNUMX 만 석 상당의 유동성을 소진 할 것이지만, 경쟁이 존재하는 상황입니다.
공격자가 더 낮은 수수료율로 경쟁 경로를 비활성화 할 수있는 경우, Loop는 더 높은 수수료율을 기꺼이 지불 할 수 있습니다 (이제 유동성 공급이 감소했기 때문에). 루프가 3,000ppm (0.3 %)을 지불하고 다른 채널이 작동하지 않기 때문에 유동성을 더 빨리 사용한다고 가정 해 보겠습니다. Loop는 그 유동성을 절반의 시간, 예를 들어 일주일 안에 사용할 수 있습니다. 공격자는이 예에서 평균 수익률의 두 배 이상인 15.6 % APR을 만들 것입니다. 공격자의 유일한 비용은 기존 채널에서 스크립트를 실행하는 비용과 라이트닝 네트워크에 대한 부도덕 한 / 손상을 입히는 심리적 비용입니다. 단일 공격자 채널을 사용하면 악의적 인 공격자가 약 XNUMX 개의 채널을 방해 할 수 있습니다. Jager 's tweets about this).
이 공격의 피해자는 무엇을 경험할까요?
이 공격의 피해자는 보류중인 HTLC에 대해 특별한 경고를 설정하지 않는 한이 공격이 발생하고 있다는 사실을 알지 못합니다. Thunderhub 사용자 (강력히 권장되는 도구)의 경우 홈 화면에 보류중인 HTLC 차트와 채널이 보류중인 HTLC를 483 개만 보유 할 수 있다는 경고가 표시됩니다.
출처 : Thunderhub
실제로 내 노드는 빠르게 불안정 해졌고 문제를 알려주는 유일한 앱인 Thunderhub를 포함하여 여러 앱 충돌이 발생했습니다. 그런 다음 "Balance of Satoshis"텔레 그램 봇 덕분에 채널 폐쇄 알림을 받았습니다. 공격중인 채널이 저절로 폐쇄되었습니다! 그것은 실험의 일부가 아니 었습니다. (불수의 적 강제 종료에 대한 자세한 기술 정보는 아래의 추가 강제 종료 데이터를 참조하십시오.)
공격으로 Burkhardt (salmiak) 채널을 사용한 테스트 결제가 실패했습니다. 이 경고는 Burkhardt의 노드가 온라인이지만 오프라인 상태임을보고합니다. 출처 : Thunderhub.
피해자는 슬픔에 잠긴 공격을 막기 위해 무엇을 할 수 있습니까?
공격이 시작되면 피해자는 기본적으로이를 막기 위해 아무것도 할 수 없습니다. 진행중인 공격을 막을 수있는 유일한 대안은 공격당하는 채널을 강제 폐쇄하는 것입니다. 이는 테러리스트가 승리한다는 것을 의미합니다.
상해에 대한 모욕을 더하기 위해 채널을 강제 종료하면 해결되지 않은 지불이 온 체인 트랜잭션 데이터로 푸시되어 강제 종료 개시 자에 대한 보조 온 체인 트랜잭션이 트리거됩니다. 50 sats / vbyte 및 483 온 체인 트랜잭션에서 이는 공격을 받고있는 단일 채널을 강제로 폐쇄하기위한 1 만 개의 sat 가격표입니다 (오늘의 가격으로 368 달러의 채널 폐쇄 수수료). 여러 온 체인 거래는 출력이 최소 지불“먼지”한도를 초과하는 경우에만 발생합니다. (보다 이 예 테스트 넷에서.)
Lightning 채널의 개시자가 마감 수수료를 지불합니다.
483 (비 먼지) htlcs를 원하지 않는 또 다른 이유는 50 sat / vB에서 잠재적 인 강제 종료 트랜잭션이 다음과 같기 때문입니다. https://t.co/z6mAGZxvrC.
Jager는 공격자를 격리하고 싸우는 데 도움이되는 개념 증명 프로그램을 개발하고 있습니다. 그는 그의 프로그램을“회로 차단기.” Circuitbreaker는 네트워크 수준에서 작동합니다. 이는 안타깝게도 사람 효과가 있으려면 참여해야합니다.
그 외에도이 문제는 더 나은 솔루션을 찾기 위해 전담 엔지니어 / 개발자의 우선 순위와주의가 필요합니다. 또한 Bitcoin Optech 뉴스 레터 (문제 번호 122 또는 # 126)에서 프로토콜 수정에 대한 좋은 토론이있었습니다.
이 공격은 오늘 실행할 수 있습니다. 이미 악의적으로 사용되지 않은 것은 기적입니다. 이는 오늘날 Lightning을 사용하는 사람들에 대한 인센티브를 반영하여 개방적이고 보편적 인 지불 네트워크가 될 수 있도록합니다. 실제 해를 입히기 전에이 문제를 해결하기 위해 더 많은 작업을 장려하고 영감을 줄 수 있도록이 게시물을 공유하십시오.
비자발적 강제 종료에 대한 추가 기술 정보
다음은 위에서 언급 한 비자발적 강제 종료가 발생한 시점에 LND 0.11을 실행하는 내 노드의 로그입니다.
2020-11-26 21:24:47.374 [ERR] HSWC: ChannelLink(657759:561:0): failing link: ChannelPoint (c37bec006b18df172698a84739ca47128935e0a8666fecd1a843e49b01db207c:0): received error from peer: chan_id=7c20db019be443a8d1ec6f66a8e035891247ca3947a8982617df186b00ec7bc3, err=rejected commitment: commit_height=455, invalid_commit_sig=3044022076fd65191eb6305b723fa6012be378413b6326e2786c38db58b4c02e1f3999d202207605ca31de8b4c5b1d9cd20dc1581dfa2383e0b4e06c8ad4f718ab5c434d8cf5, commit_tx=02000000017c20db019be443a8d1ec6f66a8e035891247ca3947a8982617df186b00ec7bc300000000008a792e8002210d0000000000002200201031cf10a1efef261edd3d0a1a6a953b27bc25bd7150bb2b07afdc69805e02157213000000000000160014de650929042bef58b71783ae1a44834a902a8f2d542ca720, sig_hash=4e0fb804c74376020e4c44a60969b9206eb0aaa9a89b76017d60f23ad5cf63e5 with error: remote error
로그에 LND의 알려진 문제인 "invalid_commit_sig"가 표시됩니다. 재 연결시 발생할 수 있으며 채널 방해의 직접적인 결과가 아닙니다. 안타깝게도 보류중인 HTLC의 양으로 인해 발생할 가능성이 더 높습니다. Jager는 프로세스를 채널 방해 –> 무한 지불 루프 (버그) –> 노드 다운 –> 재 연결 –> 유효하지 않은 커밋 시그 (버그) –> 채널 강제 종료로 설명하는 데 도움을주었습니다.
"무한"루프 버그는 HTLC 제한에 도달하고 추가 HTLC가 전송 될 때 발생하는 알려진 버그입니다. 결제 실패로 끝나는 대신 LND는 계속해서 루프에서 결제를 시도합니다. 이 버그를 해결하려면 다음을 참조하십시오. LND 문제 # 4656.
Jestopher의 게스트 포스트입니다. 표현 된 의견은 전적으로 자신의 것이며 BTC Inc 또는 Bitcoin Magazine.