비트코인의 중복 거래: 최소한의 위험으로 해결되는 재밌는 버그
원래 제목: "비트코인의 중복 거래"
원래 출처: BitMEX Research
비트코인 블록체인에는 두 개의 동일한 거래 세트가 있으며, 한 세트의 거래는 다른 세트의 거래를 "샌드위치"하고 있으며, 둘 다 2010년 11월 중순에 발생했습니다. 중복 거래는 혼란을 초래할 수 있으며, 비트코인 개발자들은 수년에 걸쳐 다양한 방법으로 이에 맞서 싸워 왔습니다. 이 문제는 아직 100% 해결되지 않았고 다음 잠재적 중복 거래는 2046년에 발생할 수 있습니다. 중복 거래와 관련된 위험은 지금은 최소이지만, 생각해 볼 만한 흥미로운 특이점입니다.
개요
일반적인 비트코인 거래는 이전 거래의 거래 ID(TXID)를 참조하여 최소한 하나의 이전 거래 출력을 사용합니다. 사용되지 않은 출력은 한 번만 사용될 수 있습니다. 두 번 사용될 수 있다면 비트코인을 두 번 사용한 셈이 되어 가치가 없게 됩니다. 하지만 실제로 비트코인에는 정확히 두 가지 동일한 거래 집합이 있습니다. 이것이 가능한 이유는 코인베이스 거래에는 거래 입력이 없지만 새로 생성된 코인이 있기 때문입니다. 따라서 서로 다른 두 개의 코인베이스 거래가 같은 주소로 같은 금액을 보내고 정확히 같은 방식으로 구성되어 동일할 수 있습니다. 이러한 거래는 동일하므로 TXID도 일치합니다. TXID는 거래 데이터의 해시 다이제스트이기 때문입니다. TXID를 복제할 수 있는 다른 유일한 방법은 해시 충돌을 통하는 것인데, 이는 암호학적으로 안전한 해시 함수의 경우 발생 가능성이 낮고 달성할 수 없는 것으로 간주됩니다. SHA256과 같은 해시 충돌은 비트코인이나 다른 어느 곳에서도 일어난 적이 없습니다.
두 세트의 중복 거래는 모두 비슷한 시간, 즉 2010년 11월 14일 08:37 UTC와 2010년 11월 15일 00:38 UTC 사이, 약 16시간 동안 발생했습니다. 첫 번째 중복 거래 집합은 두 번째 집합 사이에 끼어 있습니다. 우리는 d5d2….8599를 첫 번째 중복 거래로 분류합니다. 왜냐하면 이것이 처음으로 중복이 된 거래이기 때문입니다. 하지만 흥미롭게도 이 거래는 다른 중복 거래인 e3bf….b468 이후에 블록체인에 처음 나타났습니다.
중복 거래 세부정보
아래 이미지에서는 mempool.space 블록 탐색기의 두 스크린샷을 볼 수 있으며, 두 개의 다른 블록에서 첫 번째 중복 거래가 반복되는 것을 보여줍니다.
흥미롭게도, 관련 URL을 웹 브라우저에 입력하면 mempool.space 블록 탐색기는 기본적으로 d5d2….8599의 경우 이전 블록을 표시하고, e3bf….b468의 경우 이후 블록을 표시합니다. Blockstream.info와 Btcscan.org는 mempool.space와 동일하게 동작합니다. 반면, 기본 테스트에 따르면 Blockchain.com과 Blockchair.com은 다르게 동작하며 브라우저에 URL을 입력하면 항상 복제된 거래의 최신 버전을 표시합니다.
문제의 4개 블록 중에서 단 하나(블록 91,812)에만 추가 거래가 포함되어 있었습니다. 이 거래에서는 1 BTC와 19 BTC 출력을 단일 20 BTC 출력으로 결합했습니다.
이러한 산출물을 사용할 수 있나요?
동일한 TXID 세트가 두 개 있었기 때문에 후속 거래에서 참조 문제가 발생했습니다. 각 반복 거래의 가치는 50 BTC입니다. 따라서 이러한 반복적인 거래에는 총 4 x 50 BTC = 200 BTC가 포함되고, 해석 방법에 따라 2 x 50 BTC = 100 BTC가 됩니다. 어떤 의미에서는 실제로 존재하지 않는 BTC가 100개나 있습니다.
오늘 현재 200 BTC는 모두 사용되지 않은 상태입니다. 우리가 아는 한 (그리고 여기서 우리가 틀릴 수도 있지만) 누군가가 이러한 출력과 관련된 개인 키를 가지고 있다면 그들은 비트코인을 쓸 수 있습니다. 그러나 지출되면 UTXO는 데이터베이스에서 삭제되고 중복된 50 BTC는 지출할 수 없고 손실되므로 100 BTC만 복구할 수 있습니다. 해당 코인이 일찍 사용되었는지, 아니면 최근에 사용되었는지에 따라 어느 블록에서 나오는지는 정의되지 않았거나 판단이 불가능할 수 있습니다.
이 사람은 중복 거래를 생성하기 전에 모든 비트코인을 사용했을 수 있으며, 이로 인해 중복 출력이 생성되어 사용되지 않은 출력의 데이터베이스에 새로운 항목이 생성될 수 있습니다. 이는 중복된 거래뿐만 아니라, 중복된 지출 출력을 가질 수 있는 중복된 거래도 의미합니다. 이런 일이 발생하면 이러한 출력이 소비될 때 더 많은 중복 거래가 생성되어 일종의 중복 체인이 형성될 가능성이 높습니다. 이벤트 순서에 주의해야 하며 항상 복제본을 만들기 전에 지출해야 합니다. 그렇지 않으면 비트코인이 영원히 사라질 수 있습니다. 이러한 새로운 중복 거래는 코인베이스 거래가 아니라 "일반적인" 거래입니다. 다행히도 이런 일은 일어나지 않았습니다.
중복 거래 문제
중복 거래는 분명히 나쁩니다. 이러한 문제는 지갑과 블록 탐색기에 혼란을 초래하고 비트코인의 출처를 모호하게 만듭니다. 또한 이로 인해 많은 공격과 취약점이 발생합니다. 예를 들어, 두 번의 중복 거래를 통해 누군가에게 두 번 돈을 지불할 수 있습니다. 그런 다음 거래 당사자가 자금에 접근하기로 결정했을 때, 회수 가능한 자금이 절반밖에 없다는 것을 알게 될 수도 있습니다. 예를 들어, 공격자는 아무것도 잃지 않고도 입금 직후 자금을 인출할 수 있으므로, 거래 플랫폼을 파산시키려는 공격이 될 수 있습니다.
중복 TXID를 사용하는 거래는 금지됩니다.
중복 거래 문제를 완화하기 위해 2012년 2월 비트코인 개발자 피터 윌리는 이전 TXID가 사용되지 않은 경우 거래에 중복 TXID를 사용하는 것을 금지하는 BIP30 소프트 포크 솔루션을 제안했습니다. 이 소프트 포크는 2012년 3월 15일 이후의 모든 블록에 적용됩니다.
2012년 9월, 비트코인 개발자 Greg Maxwell은 BIP30 검사가 2012년 3월 15일 이후의 블록뿐만 아니라 모든 블록에 적용되도록 이 규칙을 수정했습니다. 이 기사의 앞부분에서 언급한 두 개의 중복 거래는 예외입니다. 이렇게 하면 일부 DOS 버그가 해결됩니다. 기술적으로 보면 이는 또 다른 소프트 포크이지만, 규칙 변경은 6개월 이상 된 블록에만 적용되므로 일반적인 프로토콜 규칙 변경과 관련된 위험이 없습니다.
이 BIP30 검사는 계산 비용이 많이 듭니다. 노드는 새 블록의 모든 거래 출력을 확인하고 이러한 출력 엔드포인트가 UTXO에 이미 존재하는지 확인해야 합니다. 이것이 아마도 Wuille이 사용되지 않는 출력만 확인하는 이유일 것입니다. 모든 출력을 검사하면 컴퓨팅 측면에서 더 많은 비용이 들고, 가지치기도 불가능합니다.
BIP34
2012년 7월, 비트코인 개발자 Gavin Andresen은 BIP34 소프트 포크 계획을 제안했고, 이는 2013년 3월에 활성화되었습니다. 이 프로토콜 변경은 코인베이스 거래에 블록 높이를 포함해야 하며, 이를 통해 블록 버전 관리도 가능해집니다. 블록 높이는 코인베이스 거래 스크립트 Sig의 첫 번째 항목으로 추가됩니다. 코인베이스 scriptSig의 첫 번째 바이트는 블록 높이 번호에 사용되는 바이트 수이고, 그 뒤의 바이트는 블록 높이 번호 자체입니다. 첫 번째 c160년(223 / (하루 144개 블록 * 연간 365일))의 경우 첫 번째 바이트는 0x03이어야 합니다. 그래서 오늘날의 코인베이스 ScriptSig(HEX)는 항상 03으로 시작합니다. 이 소프트 포크는 중복 거래 문제를 완전히 해결한 듯하며, 이제 모든 거래는 고유해야 합니다.
BIP34가 이미 채택된 이후인 2015년 11월, 비트코인 개발자 알렉스 모르코스는 Bitcoin Core 소프트웨어 저장소에 풀 리퀘스트를 추가했습니다. 이 변경으로 인해 노드는 BIP30 검사를 중단하게 되었습니다. 결국, BIP34가 이 문제를 해결했으므로 이제 값비싼 검사는 더 이상 필요하지 않습니다. 당시에는 알려지지 않았지만, 이는 기술적으로 매우 희귀한 일부 미래 블록에 대한 하드 포크였습니다. 지금 당장은 잠재적인 하드 포크가 중요하지 않은 듯합니다. 2015년 11월 이전의 노드 소프트웨어를 실행하는 사람이 거의 없기 때문입니다. forkmonitor.info에서는 2015년 10월에 출시된 Bitcoin Core 0.10.3을 실행하고 있습니다. 따라서 이것은 하드포크 이전 규칙이며 클라이언트는 여전히 비싼 BIP30 검사를 하고 있습니다.
블록 983,702 문제
BIP34가 활성화되기 전에 블록에 일부 코인베이스 거래가 있었고, 당시 사용된 scriptSigs의 첫 번째 바이트가 우연히 미래의 유효한 블록 높이와 일치했습니다. 따라서 BIP34는 거의 모든 경우에서 이 문제를 해결하지만 100% 완벽하게 해결할 수는 없습니다. 2018년, 비트코인 개발자 존 뉴베리는 아래 표에 나와 있는 것처럼 이러한 잠재적 중복의 전체 목록을 인쇄했습니다.
*참고: 이 블록은 2012년과 2017년에 Coinbase 거래를 생성했으며 중복되지 않습니다. 209,921개 블록(첫 번째 반감기에서 불과 79개 블록 떨어짐)은 BIP30이 그 사이에 구현되었기 때문에 중복될 수 없습니다. 출처: https://gist.github.com/jnewbery/df0a98f3d2fea52e487001bf2b9ef1fd 
년별 잠재적으로 중복된 Coinbase 거래 수 출처: https://gist.github.com/jnewbery/df0a98f3d2fea52e487001bf2b9ef1fd
따라서 중복된 거래가 나타날 수 있는 다음 블록은 2046년 1월경에 생성될 블록 1,983,702입니다. 2012년 1월 블록 164,384의 Coinbase 거래는 170BTC를 7개의 다른 출력 주소로 보냈습니다. 따라서 2046년에 채굴자들이 이 공격을 실행하려면 이 블록을 찾을 만큼 운이 좋아야 할 뿐만 아니라, 수수료로 170 BTC에 약간 못 미치는 금액을 소각해야 하며, 0.09765625 BTC 블록 보조금의 기회 비용을 포함한 총 비용은 170 BTC가 조금 넘습니다.
현재 비트코인 가격이 88,500달러인 것을 감안하면, 그 비용은 1,500만 달러가 넘습니다. 2012년 동전 도서관 거래에 사용된 7개 주소를 누가 소유하고 있는지는 아직 알 수 없으며, 열쇠가 분실되었을 가능성이 높습니다. 현재 이 Coinbase 거래의 7개 출력 주소가 모두 사용되었으며, 그 중 3개가 동일한 거래에 사용되었습니다. 우리는 이 자금이 Pirate40 사기와 관련이 있을 수 있다고 생각하지만, 이는 단지 우리의 추측일 뿐입니다. 결과적으로 이 공격은 비용이 많이 들 뿐만 아니라 공격자에게 사실상 무용지물이 되는 것으로 드러났습니다. 31년 전 하드 포크를 통해 2015년 11월의 노드를 네트워크에서 제거하는 데는 상당한 비용이 들었을 것입니다.
복사될 수 있는 다음 취약한 블록은 2012년 3월의 169985입니다. 이 Coinbase는 50 BTC가 조금 넘는 비용으로, 170 BTC보다 훨씬 저렴합니다. 물론, 그 당시 보조금은 50BTC였고, 이 코인베이스 거래가 2078년에 쉽게 반복 가능해지면 보조금은 훨씬 낮아질 것입니다. 따라서 이를 활용하려면 광부들은 수수료로 약 50BTC를 소각해야 하는데, 이는 2012년의 오래된 출력으로 보내야 하기 때문에 돌려받을 수 없습니다. 2078년에 비트코인 가격이 어떻게 될지는 아무도 모르지만, 그러한 공격의 비용도 엄청나게 높을 가능성이 큽니다. 따라서 이 문제는 비트코인에 큰 위험이 아닐 수도 있지만, 여전히 우려되는 사항입니다.
2017년 SegWit 업그레이드 이후, Coinbase 거래에는 블록의 모든 거래에 대한 약속도 포함될 수 있습니다. 이러한 BIP34 이전 블록에는 증인 약속이 포함되지 않았습니다. 따라서 중복된 코인베이스 거래를 생성하려면 채굴자는 블록에서 모든 SegWit 출력 상환 거래를 제외해야 하며, 수수료를 지불하는 다른 거래가 블록에 많이 포함되지 않을 수 있으므로 공격의 기회 비용이 더욱 증가합니다.
결론
복사 거래의 어려움과 비용, 그리고 이를 악용할 수 있는 기회의 희소성을 감안할 때 이 복사 거래 취약성은 비트코인의 주요 보안 문제로 보이지 않습니다. 그래도 반복되는 거래의 참신함과 관련된 시간적 규모를 고려하면 생각해보는 것도 흥미롭습니다. 그럼에도 불구하고 개발자들은 수년에 걸쳐 이 문제에 많은 시간을 투자했으며, 일부 개발자들은 2046년이 이 문제를 해결하는 마감일이라고 생각할 수도 있습니다. 이 버그를 수정하는 방법은 여러 가지가 있으며, 소프트 포크가 필요할 수도 있습니다. 가능한 해결책 중 하나는 SegWit 약속을 강제하는 것입니다.
BlockBeats 공식 커뮤니티에 참여하세요:
Telegram 구독 그룹：https://t.me/theblockbeats
Telegram 토론 그룹：https://t.me/BlockBeats_App
Twitter 공식 계정：https://twitter.com/BlockBeatsAsia
