비트코인 옵테크 뉴스레터는 독자들에게 비트코인에서 발생하는 가장 중요한 기술 뉴스에 대한 최고 수준의 요약과 더 많은 정보를 배울 수 있는 리소스를 제공합니다. 독자들이 비트코인에 대한 최신 정보를 유지할 수 있도록, 우리는 아래에 이 뉴스레터의 최신 호를 재발행하고 있습니다. 이 콘텐츠를 직접 이메일로 받으려면 구독하는 것을 잊지 마세요.
이번 주 뉴스레터는 JoinMarket의 충실도 채권에 대한 이전 설명을 후속하며, 비트코인 코어 PR 리뷰 클럽 회의 요약, 탭루트 준비를 위한 제안, 릴리스 및 릴리스 후보 발표, 인기 인프라 프로젝트의 주목할 만한 변경 사항 설명을 포함한 정기 섹션을 포함합니다.
뉴스
- 충실도 채권의 구현: JoinMarket 0.9.0의 코인조인 구현은 충실도 채권을 지원합니다. 뉴스레터 #57에서 설명한 바와 같이, 이 채권은 JoinMarket 시스템의 시빌 저항성을 개선하여 코인조인 시작자(“테이커”)가 독특한 유동성 제공자(“메이커”)를 선택할 수 있는 능력을 증가시킵니다. 출시 며칠 만에 50 BTC 이상(현재 200만 달러 이상 가치)이 시간 잠금된 충실도 채권에 배치되었습니다.
특정 구현은 JoinMarket에 고유하지만, 전체 설계는 비트코인 위에 구축된 다른 분산 프로토콜에서도 유용할 수 있습니다.
비트코인 코어 PR 리뷰 클럽
이 월간 섹션에서는 최근 비트코인 코어 PR 리뷰 클럽 회의를 요약하고, 중요한 질문과 답변을 강조합니다. 아래 질문을 클릭하면 회의에서의 답변 요약을 볼 수 있습니다.
가능한 경우 GetTransaction에 txindex를 사용하라는 PR은 Jameson Lopp가 작성했으며, 이는 가능한 경우 트랜잭션 인덱스(txindex)를 활용하여 GetTransaction(그리고, 확장하여 사용자에 대한 getrawtransaction RPC)의 성능을 향상시킵니다. 이 변경은 txindex가 활성화된 노드에서 트랜잭션을 포함하는 블록의 해시로 getrawtransaction을 호출할 때 예상치 못한 성능 저하를 수정합니다. 리뷰 클럽은 txindex가 있는 경우와 없는 경우 트랜잭션을 검색하는 단계를 비교하여 이 성능 문제의 원인을 평가했습니다.
- GetTransaction이 디스크에서 트랜잭션을 검색할 수 있는 다양한 방법은 무엇인가요?
트랜잭션은 메모리 풀에서(확인되지 않은 경우), 디스크에서 전체 블록을 검색하여 트랜잭션을 찾거나, txindex를 사용하여 디스크에서 트랜잭션을 직접 가져오는 방식으로 검색할 수 있습니다. - 블록 해시가 제공될 때 성능이 더 나쁜 이유는 무엇인가요?(txindex가 활성화된 경우)
참가자들은 병목 현상이 블록의 역직렬화에 있다고 추측했습니다. 전체 블록을 가져오는 데 고유한 또 다른 프로세스는 전체 트랜잭션 목록을 통해 선형 검색하는 것입니다. - 블록 해시로 트랜잭션을 조회할 때 단계는 무엇인가요? 얼마나 많은 데이터가 역직렬화되나요?
우리는 먼저 블록 인덱스를 사용하여 블록에 접근하는 데 필요한 파일과 바이트 오프셋을 찾습니다. 그런 다음 전체 블록을 가져와서 역직렬화하고 트랜잭션 목록을 스캔하여 일치를 찾습니다. 이 과정에서 약 1-2MB의 데이터가 역직렬화됩니다. - txindex를 사용하여 트랜잭션을 조회할 때 단계는 무엇인가요? 얼마나 많은 데이터가 역직렬화되나요?
txindex는 트랜잭션 ID에서 파일, 블록 위치(블록 인덱스와 유사), 트랜잭션이 시작되는 blk*.dat 파일 내의 오프셋으로 매핑됩니다. 우리는 블록 헤더와 트랜잭션을 가져와서 역직렬화합니다. 헤더는 80B이며 사용자에게 블록 해시를 반환할 수 있게 해줍니다(이는 txindex에 저장되지 않는 정보입니다). 트랜잭션은 어떤 크기일 수 있지만 일반적으로 블록보다 수천 배 작습니다. - 이 PR의 첫 번째 버전은 동작 변경을 포함했습니다: GetTransaction에 잘못된 block_index가 제공될 경우, txindex를 사용하여 트랜잭션을 찾아 반환합니다. 이 변경이 개선이라고 생각하나요? 이 PR에 포함되어야 하나요?
참가자들은 도움이 될 수 있지만 오해의 소지가 있다고 동의했으며, 잘못된 블록 해시 입력에 대해 사용자에게 알리는 것이 더 좋다고 언급했습니다. 또한 성능 개선과 동작 변경은 별도의 PR로 나누는 것이 가장 좋다고 언급했습니다.
탭루트 준비 #8: 다중 서명 넌스
개발자와 서비스 제공자가 블록 높이 709,632에서 다가오는 탭루트 활성화를 준비하는 방법에 대한 주간 시리즈입니다.
지난 주 칼럼에서는 다중 서명에 대해 설명하고 MuSig2를 사용하는 예를 들었습니다. 우리의 설명은 기술적으로 올바른 것으로 보였지만, MuSig2에 기여한 여러 암호학자들은 우리가 제안한 사용 방식이 위험하다고 우려했습니다. 우리는 그들의 즉각적인 우려를 해결하기 위해 설명을 업데이트한 후, 이 문제를 더 철저히 조사하기 시작했습니다. 이번 포스트에서는 다중 서명을 안전하게 구현하는 데 있어 가장 큰 도전이 될 수 있는 사항인 넌스 재사용을 피하는 방법에 대해 살펴보겠습니다.
비트코인에서 서명을 검증하려면 서명, 서명된 메시지(예: 트랜잭션), 공개 키 및 공개 넌스를 사용하여 공개적으로 알려진 방정식을 작성합니다. 개인 키와 넌스의 개인 형태를 알지 못하면 그 방정식을 균형 있게 유지할 수 없습니다. 따라서 그러한 균형 잡힌 방정식을 보는 사람은 해당 메시지와 공개 키에 대한 서명이 유효하다고 간주합니다.
서명과 메시지를 방정식에 포함하는 동기는 분명합니다. 공개 키는 개인 키의 대체물입니다. 공개 넌스는 무엇을 위한 것인가요? 그것이 없다면, 개인 키를 제외한 방정식의 모든 다른 값이 알려지게 되어 기본 대수를 사용하여 그 단일 미지수를 해결할 수 있습니다. 그러나 대수는 두 개의 미지수를 해결할 수 없으므로 넌스의 개인 형태는 개인 키를 비밀로 유지하는 역할을 합니다. 그리고 서명 방정식에서 공개 키가 개인 키의 대체물인 것처럼, 넌스의 공개 형태는 개인 형태의 대체물입니다.
이 맥락에서 넌스는 단순히 한 번 사용되는 숫자가 아니라 단 한 번만 사용해야 하는 숫자입니다. 두 개의 서로 다른 서명에 동일한 넌스를 재사용하면 두 서명 방정식이 결합될 수 있으며, 넌스는 취소될 수 있고, 누군가가 다시 남은 유일한 미지수인 개인 키를 해결할 수 있습니다. BIP32 표준 파생(비하드닝 파생)을 사용하는 경우(거의 모든 다중 서명 지갑이 그렇게 할 가능성이 높음), 하나의 개인 키가 드러나면 동일한 BIP32 경로의 모든 다른 개인 키가 드러납니다(다른 경로에서도 그럴 수 있습니다). 이는 비트코인을 백 개의 서로 다른 주소로 받은 다중 서명 지갑이 단 하나의 넌스를 재사용하는 서명자에게 모든 주소가 손상된다는 것을 의미합니다.
단일 서명 지갑이나 스크립트 기반 다중 서명을 사용하는 지갑은 서명할 때마다 새로운 무작위 넌스를 생성하도록 하여 넌스 재사용을 피하는 간단한 방법을 사용할 수 있습니다. 메시지에 변화가 있을 경우 넌스가 변경되므로 넌스를 재사용하지 않습니다.
다중 서명은 이 트릭을 사용할 수 없습니다. 각 공동 서명자는 부분 서명뿐만 아니라 부분 공개 넌스도 기여해야 합니다. 부분 공개 넌스는 결합되어 서명할 메시지와 함께 포함되는 집계된 공개 넌스를 생성합니다.
즉, 트랜잭션이 동일하더라도 동일한 부분 넌스를 두 번 이상 사용하는 것은 안전하지 않습니다. 만약 두 번째 서명 시 공동 서명자 중 한 명이 자신의 부분 넌스를 변경하면(집계된 넌스가 변경됨), 두 번째 부분 서명은 사실상 다른 메시지에 대한 것이 됩니다. 이는 개인 키를 드러냅니다. 모든 당사자가 자신의 개인 넌스를 다른 당사자의 부분 공개 넌스에 의존하도록 만드는 것은 불가능하게 순환적이므로, 다중 서명에서 넌스 재사용을 피하는 간단한 방법은 없습니다.
처음에는 이것이 큰 문제가 아닌 것처럼 보입니다. 서명자가 서명할 때마다 새로운 무작위 넌스를 생성하도록 하면 됩니다. 그러나 이는 생각보다 더 어렵습니다. 2012년 이후로 무작위 넌스를 생성하는 데 의존하는 지갑에서 비트코인을 잃는 버그가 발견되었습니다.
그러나 지갑이 고품질의 무작위 넌스를 생성하더라도 각 넌스가 최대 한 번만 사용되도록 해야 합니다. 이는 실제로 도전이 될 수 있습니다. 지난 주 칼럼의 원래 버전에서는 MuSig2 호환 콜드 지갑 또는 하드웨어 서명 장치가 첫 번째 실행 시 많은 수의 넌스를 생성한다고 설명했습니다. 그런 다음 지갑이나 장치는 이러한 넌스가 한 개의 부분 서명과 함께 사용되지 않도록 보장해야 합니다. 이는 간단하게 들리지만—넌스가 사용될 때마다 카운터를 증가시키는 것—소프트웨어와 하드웨어가 우연히 실패할 수 있는 모든 방법을 처리할 때는 실제로 도전이 될 수 있습니다. 외부의 악의적인 개입에 의해 영향을 받을 수도 있습니다.
지갑이 넌스 재사용의 위험을 줄이는 가장 쉬운 방법은 가능한 한 짧은 시간 동안 넌스를 저장하는 것입니다. 지난 주의 예에서는 넌스를 몇 개월 또는 몇 년 동안 저장하는 것을 제안했는데, 이는 잘못될 기회를 많이 만들 뿐만 아니라 넌스를 지속 가능한 저장 매체에 기록해야 하며, 이는 백업 및 복원되거나 예기치 않은 상태에 놓일 수 있습니다. MuSig2를 사용하는 대안적인 방법은 PSBT가 수신될 때와 같이 필요할 때만 넌스를 생성하는 것입니다. 넌스는 필요한 짧은 시간 동안 휘발성 메모리에 유지될 수 있으며, 소프트웨어 충돌이나 전원 손실과 같은 예기치 않은 상황에서 자동으로 파괴(재사용 불가능하게)될 수 있습니다.
그럼에도 불구하고 이 문제를 다루고 있는 암호학자들은 원래 MuSig 프로토콜(MuSig1)과 MuSig2에서 넌스 재사용을 방지할 수 있는 확실한 방법이 부족하다는 점에 대해 매우 우려하고 있는 것 같습니다. MuSig-DN(결정론적 넌스)은 해결책을 제공하지만, 복잡하고 느립니다(알파 구현은 2.9 GHz Intel i7에서 넌스 증명을 생성하는 데 거의 1초가 걸립니다; 훨씬 덜 정교한 프로세서를 가진 16 MHz 하드웨어 서명 장치에서 얼마나 걸릴지는 알 수 없습니다).
다중 서명 서명을 구현하는 모든 사람에게 조언하는 것은, #secp256k1 IRC 방이나 비트코인 암호학자들이 모이는 다른 장소를 방문하여 계획을 설명하고 시간이나 자원에 대한 주요 투자를 하기 전에 조언을 구하는 것입니다.
릴리스 및 릴리스 후보
인기 비트코인 인프라 프로젝트의 새로운 릴리스 및 릴리스 후보. 새로운 릴리스로 업그레이드하거나 릴리스 후보 테스트를 도와주십시오.
- C-Lightning 0.10.1은 여러 새로운 기능, 여러 버그 수정 및 개발 프로토콜(이중 자금 조달 및 제안 포함)에 대한 몇 가지 업데이트를 포함하는 릴리스입니다.
- 비트코인 코어 22.0rc2는 이 전체 노드 구현의 다음 주요 버전 및 관련 지갑 및 기타 소프트웨어에 대한 릴리스 후보입니다. 이 새로운 버전의 주요 변경 사항에는 I2P 연결 지원, 버전 2 Tor 연결 지원 제거, 하드웨어 지갑에 대한 향상된 지원이 포함됩니다.
주목할 만한 코드 및 문서 변경 사항
이번 주 비트코인 코어, C-Lightning, Eclair, LND, Rust-Lightning, libsecp256k1, 하드웨어 지갑 인터페이스(HWI), Rust Bitcoin, BTCPay Server, 비트코인 개선 제안(BIPs), 및 Lightning BOLTs에서의 주목할 만한 변경 사항입니다.
- 비트코인 코어 #21528은 전체 노드 수신 주소의 p2p 전파를 개선하는 것을 목표로 합니다. 다양한 주소 세트에 노출되는 것은 네트워크 분할(예: 이클립스 공격)에 대해 노드를 보호하는 데 중요합니다. 비트코인 코어 노드가 10개 이하의 주소를 포함하는 주소 메시지를 수신하면, 이를 1개 또는 2개 피어에게 전달합니다. 이는 주소를 자가 광고하는 데 사용되는 주요 기술이므로, 이러한 주소를 전달하지 않는 피어에게 보내는 것은 네트워크를 통한 전파를 효과적으로 중단하거나 “블랙홀”로 만들 것입니다. 악의적인 경우 전파 실패를 방지할 수는 없지만, 이 패치는 블록 릴레이 전용 연결이나 라이트 클라이언트와 같은 정직한 경우의 주소 전파를 개선합니다.
이 업데이트는 수신 연결이 addr, addrv2 또는 getaddr와 같은 주소 관련 메시지를 통해 주소를 전달할 후보인지 여부에 따라 수신 연결을 식별합니다. 따라서 주소 메시지를 수신하는 데 의존하지만 주소 관련 메시지를 시작하지 않는 소프트웨어가 네트워크에 있을 경우 이 동작 변경은 문제가 될 수 있습니다. 따라서 저자는 이 제안된 변경 사항이 병합되기 전에 메일링 리스트에 게시하고 다른 오픈 소스 클라이언트와의 호환성을 확인하는 등 주의 깊게 진행했습니다. - LND #5484는 모든 데이터를 단일 외부 Etcd 데이터베이스에 저장할 수 있도록 합니다. 이는 클러스터 리더십 변경을 즉각적으로 만들어 고가용성 배포를 개선합니다. 해당 LND 클러스터링 문서는 이전에 뉴스레터 #157에서 다루어졌습니다.
- Rust-Lightning #1004는 결제가 성공적으로 전달될 때 추적할 수 있는 PaymentForwarded에 대한 새로운 이벤트를 추가합니다. 성공적인 전달은 노드에 수수료를 발생시킬 수 있으므로, 이는 사용자의 회계 기록을 위한 수입 추적을 가능하게 합니다.
- BTCPay Server #2730은 송장 생성 시 금액을 선택 사항으로 만듭니다. 이는 운영자가 금액 선택을 사용자에게 위임하는 경우(예: 계좌 충전 시) 결제 흐름을 단순화합니다.
원본 게시물을 여기에서 확인하세요.
