비트코인의 반복 거래: 위험이 극히 적은 흥미로운 버그

원문 제목：《Bitcoin's Duplicate Transactions》

원문 출처：BitMEX Research

편집：BlockBeats

비트코인 블록체인에는 두 개의 완전히 동일한 거래가 존재하며, 한 거래가 다른 거래를 "끼고" 있습니다. 이들은 모두 2010년 11월 중순에 발생했습니다. 중복 거래는 혼란을 초래할 수 있으며, 비트코인 개발자들은 수년 동안 다양한 방법으로 이를 해결하기 위해 노력해왔습니다. 이 문제는 여전히 100% 해결되지 않았으며, 다음 잠재적인 중복 거래는 2046년에 발생할 수 있습니다. 현재 중복 거래와 관련된 위험은 매우 작지만, 이는 생각해볼 가치가 있는 흥미로운 버그입니다.

개요

정상적인 비트코인 거래는 이전 거래의 거래 ID(TXID)를 참조하여 최소한 하나의 이전 거래 출력을 사용합니다. 이러한 미사용 출력은 한 번만 사용될 수 있으며, 두 번 사용될 수 있다면 비트코인을 이중 지불할 수 있어 비트코인의 가치를 무의미하게 만들 수 있습니다. 그러나 비트코인에서는 실제로 두 개의 완전히 동일한 거래가 존재합니다. 이러한 상황이 발생할 수 있는 이유는 coinbase 거래가 거래 입력이 없고, 대신 새로 생성된 코인이 있기 때문입니다. 따라서 두 개의 서로 다른 coinbase 거래가 동일한 수량을 동일한 주소로 보내고 완전히 동일한 방식으로 구성될 수 있습니다. 이러한 거래가 동일하기 때문에 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을 입력할 때 항상 중복 거래의 최신 버전을 표시하는 방식이 다릅니다.

관련된 네 개의 블록 중, 오직 하나의 블록(블록 91,812)만 다른 거래를 포함하고 있습니다. 이 거래는 1 BTC와 19 BTC의 출력을 합쳐 20 BTC의 출력을 생성했습니다.

이러한 출력은 사용될 수 있나요?

동일한 TXID가 두 세트 존재하기 때문에, 이는 후속 거래에 대한 참조 문제를 생성합니다. 각 중복 거래의 가치는 50 BTC입니다. 따라서 이러한 중복 거래는 총 4 x 50 BTC = 200 BTC에 해당하며, 또는 다른 이해 방식에 따라 2 x 50 BTC = 100 BTC에 해당할 수 있습니다. 어떤 면에서는 100 BTC는 실제로 존재하지 않습니다.

오늘날까지 모든 200 BTC는 사용되지 않았습니다. 우리가 아는 한(여기서 우리가 잘못될 수 있습니다), 만약 누군가가 이러한 출력과 연관된 개인 키를 가지고 있다면, 그들은 이 비트코인을 사용할 수 있습니다. 그러나 한 번 사용되면, UTXO는 데이터베이스에서 삭제되며, 중복된 50 BTC는 따라서 사용될 수 없게 되어 사라지므로, 오직 100 BTC만 회수될 수 있습니다. 이러한 코인이 사용된다면, 그것들이 어느 블록에서 나올지는 더 이른 것인지 최근 것인지 정의되지 않거나 확인할 수 없을 수 있습니다.

이 사람은 중복 거래를 생성하기 전에 모든 비트코인을 사용할 수 있었고, 그런 다음 중복 출력을 생성하여 미사용 출력의 데이터베이스에 새 항목을 생성할 수 있었습니다. 이는 중복 거래뿐만 아니라 중복된 사용된 출력의 중복 거래도 발생할 수 있음을 의미합니다. 만약 이러한 일이 발생한다면, 이러한 출력이 사용될 때 더 많은 중복 거래가 생성되어 중복 체인을 형성할 수 있습니다. 사람들은 사건의 순서에 주의해야 하며, 항상 중복을 생성하기 전에 사용해야 합니다. 그렇지 않으면 비트코인이 영원히 사라질 수 있습니다. 이러한 새로운 중복 거래는 coinbase 거래가 아니라 "정상" 거래가 될 것입니다. 다행히도 이러한 상황은 결코 발생하지 않았습니다.

중복 거래의 문제

중복 거래는 분명히 좋지 않습니다. 이들은 지갑과 블록 탐색기에 혼란을 초래하며, 비트코인의 출처를 불분명하게 만듭니다. 또한 많은 공격과 취약점을 초래할 수 있습니다. 예를 들어, 두 개의 중복 거래로 누군가에게 두 번 지불할 수 있습니다. 그런 다음 거래 당사자가 이 자금을 사용하려고 시도할 때, 그들은 회수할 수 있는 자금이 절반만 있다는 것을 발견할 수 있습니다. 예를 들어, 이는 거래 플랫폼에 대한 공격이 될 수 있으며, 공격자는 손실 없이 자금을 즉시 인출할 수 있습니다.

중복 TXID 사용 금지 거래

중복 거래 문제를 완화하기 위해, 2012년 2월 비트코인 개발자 Pieter Wuille는 중복 TXID를 사용한 거래를 금지하는 BIP30 소프트포크 제안을 했습니다. 이는 이전 TXID가 사용되었을 경우에만 적용됩니다. 이 소프트포크는 2012년 3월 15일 이후의 모든 블록에 적용됩니다.

2012년 9월, 비트코인 개발자 Greg Maxwell은 이 규칙을 수정하여 BIP30 검사가 2012년 3월 15일 이후의 블록뿐만 아니라 모든 블록에 적용되도록 했습니다. 앞서 언급한 두 개의 중복 거래는 제외됩니다. 이는 일부 DOS 취약점을 수정했습니다. 기술적으로 이는 또 다른 소프트포크였지만, 규칙 변경은 6개월 이상 된 블록에만 적용되므로 정상 프로토콜 규칙 변경과 관련된 위험은 존재하지 않습니다.

이 BIP30 검사의 계산 비용은 매우 높습니다. 노드는 새 블록의 모든 거래 출출을 검사하고, 이러한 출력 끝점이 UTXO에 이미 존재하는지 확인해야 합니다. 이는 Wuille이 사용되지 않은 출력만 검사한 이유일 수 있습니다. 모든 출출을 검사하면 계산 비용이 더 높아지고 가지치기가 불가능해집니다.

BIP34

2012년 7월, 비트코인 개발자 Gavin Andresen은 BIP34 소프트포크 제안을 했고, 2013년 3월에 활성화되었습니다. 이 프로토콜 변경은 coinbase 거래에 블록 높이를 포함하도록 요구하며, 이는 블록 버전 관리도 가능하게 합니다. 블록 높이는 coinbase 거래 스크립트 Sig의 첫 번째 항목으로 추가됩니다. coinbase scriptSig의 첫 번째 바이트는 블록 높이 숫자에 사용되는 바이트 수이며, 다음 바이트는 블록 높이 숫자 자체입니다. 첫 번째 c160년(223/(하루 144 블록 * 매년 365일)) 동안 첫 번째 바이트는 0x03이어야 합니다. 이것이 오늘날의 coinbase ScriptSig(HEX)가 항상 03으로 시작하는 이유입니다. 이 소프트포크는 중복 거래 문제를 완전히 해결한 것으로 보이며, 이제 모든 거래는 고유해야 합니다.

BIP34가 채택된 이후, 2015년 11월 비트코인 개발자 Alex Morcos는 비트코인 코어 소프트웨어 저장소에 풀 리퀘스트를 추가했습니다. 이 변경은 노드가 BIP30 검사를 중단하게 만들었습니다. 결국, BIP34가 이 문제를 수정했으므로 이 비싼 검사는 더 이상 필요하지 않았습니다. 당시에는 알지 못했지만, 기술적으로 이는 미래의 매우 드문 블록을 위한 하드포크였습니다. 현재로서는 잠재적인 하드포크가 중요하지 않은 것으로 보입니다. 왜냐하면 2015년 11월 이전의 노드 소프트웨어를 실행하는 사람은 거의 없기 때문입니다. forkmonitor.info에서 우리는 2015년 10월에 출시된 Bitcoin Core 0.10.3를 실행하고 있습니다. 따라서 이는 하드포크 이전의 규칙이며, 클라이언트는 여전히 비싼 BIP30 검사를 수행하고 있습니다.

블록 983,702 문제

사실, BIP34가 활성화되기 전의 블록 중 일부 coinbase 거래가 있었으며, 당시 사용된 scriptSigs의 첫 번째 바이트가 미래에 유효한 블록 높이와 정확히 일치했습니다. 따라서 BIP34가 거의 모든 경우에 이 문제를 수정했지만, 이는 완전한 100% 수정이 아닙니다. 2018년, 비트코인 개발자 John Newbery는 이러한 잠재적 중복의 전체 목록을 인쇄했습니다.

*주: 이 블록은 2012년과 2017년에 생성된 Coinbase 거래가 중복되지 않습니다. 209,921개의 블록(첫 번째 반감기까지 79개 블록 남음)은 중복될 수 없습니다. 왜냐하면 BIP30가 이 기간 동안 시행되었기 때문입니다.

출처：https://gist.github.com/jnewbery/df0a98f3d2fea52e487001bf2b9ef1fd

연도별 잠재적 중복 Coinbase 거래 수

출처：https://gist.github.com/jnewbery/df0a98f3d2fea52e487001bf2b9ef1fd

따라서 다음으로 중복 거래가 발생할 가능성이 있는 블록은 1,983,702로, 2046년 1월경에 생성될 것입니다. 2012년 1월에 생성된 164,384 블록의 Coinbase 거래는 170 BTC를 일곱 개의 서로 다른 출력 주소로 보냈습니다. 따라서 2046년의 채굴자가 이 공격을 시도하려면, 이 블록을 찾는 데 충분히 운이 좋을 뿐만 아니라 170 BTC 이하의 수수료를 소모해야 하며, 총 비용은 170 BTC를 약간 초과하는 비용이 발생합니다. 여기에는 0.09765625 BTC 블록 보조금의 기회 비용이 포함됩니다.

현재 비트코인 가격이 88,500달러로 계산될 경우, 이는 1,500만 달러가 넘는 비용이 들 것입니다. 2012년의 coinbase 거래의 일곱 개 주소가 누구에게 속하는지는 현재로서는 알 수 없으며, 키는 아마도 잃어버렸을 가능성이 높습니다. 현재 이 coinbase 거래의 모든 일곱 개 출력 주소는 사용되었으며, 그 중 세 개는 동일한 거래에서 사용되었습니다. 우리는 이 자금이 Pirate40 폰지 사기와 관련이 있을 것이라고 생각하지만, 이는 단지 우리의 추측일 뿐입니다. 따라서 이 공격은 비용이 많이 들 뿐만 아니라 공격자에게 거의 쓸모가 없어 보입니다. 31년 전의 2015년 11월 노드를 네트워크에서 제거하는 것은 상당한 비용이 들 것입니다.

다음으로 복제될 가능성이 있는 취약한 블록은 2012년 3월의 169985입니다. 이 coinbase는 50 BTC를 조금 넘는 금액만 사용했으며, 170 BTC보다 훨씬 적습니다. 물론 50 BTC는 당시의 보조금이며, 이 coinbase 거래가 2078년에 중복될 가능성이 있을 때 보조금은 훨씬 낮아질 것입니다. 따라서 이를 이용하려면 채굴자는 약 50 BTC의 수수료를 소모해야 하며, 이 수수료는 2012년의 오래된 출력으로 보내야 하므로 회수할 수 없습니다. 2078년 비트코인의 가격이 얼마일지는 아무도 모르지만, 이 공격의 비용도 무시할 수 없을 정도로 높을 수 있습니다. 따라서 이 문제는 비트코인의 주요 위험 요소는 아닐 수 있지만 여전히 우려스러운 문제입니다.

2017년 SegWit 업그레이드 이후, Coinbase 거래는 또한 블록 내 모든 거래에 대한 약속을 포함할 수 있습니다. 이러한 BIP34 이전의 블록은 증인 약속을 포함하지 않습니다. 따라서 중복된 Coinbase 거래를 생성하려면 채굴자는 블록에서 모든 SegWit 출력 상환 거래를 제외해야 하며, 이는 공격의 기회 비용을 더욱 증가시킵니다. 왜냐하면 블록이 많은 다른 수수료 지불 거래를 포함할 수 없기 때문입니다.

결론

복제 거래의 난이도와 비용, 그리고 이를 이용할 기회가 매우 드물다는 점을 고려할 때, 이 복제 거래 취약점은 비트코인의 주요 보안 문제처럼 보이지 않습니다. 그럼에도 불구하고 관련된 시간 규모와 중복 거래의 참신성을 고려할 때, 생각해보는 것은 여전히 흥미롭습니다. 그럼에도 불구하고, 개발자들은 수년 동안 이 문제에 많은 시간을 할애했으며, 2046년이라는 날짜는 일부 개발자들에게 이 문제를 해결해야 하는 마지막 기한일 수 있습니다. 이 오류를 수정하는 방법은 여러 가지가 있으며, 소프트포크가 필요할 수 있습니다. 가능한 수정 방법 중 하나는 SegWit 약속을 강제하는 것입니다.