비트코인 옵테크 뉴스레터는 독자들에게 비트코인에서 발생하는 가장 중요한 기술 뉴스에 대한 최고 수준의 요약과 더 많은 정보를 배울 수 있는 리소스를 제공합니다. 독자들이 비트코인에 대한 최신 정보를 유지할 수 있도록, 아래에 이 뉴스레터의 최신 호를 재발행합니다. 이 콘텐츠를 직접 이메일로 받으려면 구독하는 것을 잊지 마세요.
이번 주 뉴스레터에는 탭루트 준비 방법을 설명하는 정기 섹션, 최신 릴리스 및 릴리스 후보 요약, 인기 비트코인 인프라 프로젝트의 주목할 만한 변경 사항 목록이 포함되어 있습니다.
뉴스
이번 주에는 특별한 뉴스가 없습니다.
탭루트 준비 #7: 다중 서명
개발자와 서비스 제공자가 블록 높이 709,632에서 예정된 탭루트 활성화를 준비하는 방법에 대한 주간 시리즈입니다.
이 글을 작성하기 전 받은 1,000개의 블록 중 11%의 모든 거래 입력이 다중 서명 opcode를 포함하고 있었습니다. 탭루트의 두 가지 가장 큰 즉각적인 이점은 이러한 거래를 생성하는 많은 사용자와 서비스가 다중 서명 opcode에서 스크립트 없는 다중 서명으로 전환할 경우 나타납니다.
첫 번째 주요 이점은 거래 크기의 감소입니다. 스크립트 기반 다중 서명은 더 많은 키와 서명이 필요할수록 크기가 증가하지만, 다중 서명은 일정한 작은 크기를 유지합니다. 가장 작은 효과적인 다중 서명 정책(1-of-2)은 수천 명의 서명자가 포함될 수 있는 다중 서명 정책보다 더 많은 공간을 요구합니다. 크기의 감소는 다중 서명 사용자에 대한 수수료의 직접적인 감소로 이어지며, 동일한 양의 확인된 거래에 대한 수요를 더 적은 블록 공간으로 충족할 수 있기 때문에 모든 사용자에 대한 수수료의 간접적인 감소로 이어집니다.
두 번째 주요 이점은 향상된 개인 정보 보호입니다. 다중 서명의 각 사용은 블록 체인에 독특하게 기록되어 감시자들이 개별 사용자의 지갑 역사와 현재 잔액에 대한 정보에 기반한 추측을 할 수 있도록 합니다. 예를 들어, 블록 692,039를 살펴보면, 우리는 단일 서명 지출과 다중 서명 지출을 구별할 뿐만 아니라 다중 서명의 서로 다른 세트 크기와 임계값을 구별할 수 있습니다.
비교하자면, 블록 체인 데이터만 보는 제3자는 지출자가 다중 서명을 사용했는지 알 수 없습니다. 다중 서명이 키 경로 지출에 사용될 때, 단일 서명 지출과 구별할 수 없습니다. 위 블록의 모든 단일 서명 및 다중 서명이 P2TR 키 경로 지출로 전환된다면, 몇 가지 이국적인 지출만이 그들의 스크립트에 의해 구별될 수 있습니다(그리고 그조차도 최상의 경우 키 경로 지출을 사용할 수 있습니다).
다중 서명 사용하기
우리는 비트코인을 위해 특별히 설계된 세 가지 슈노르 기반 다중 서명 스킴을 알고 있으며, 모두 MuSig 패밀리의 구성원입니다:
- MuSig(또는 MuSig1)는 구현하기 간단하지만 서명 과정에서 세 번의 통신 라운드가 필요합니다.
- MuSig2는 구현하기도 간단합니다. 하나의 통신 라운드를 제거하고 다른 라운드를 키 교환과 결합할 수 있습니다. 이는 오늘날 스크립트 기반 다중 서명에서 사용하는 것과 유사한 서명 프로세스를 사용할 수 있게 해줍니다. 이는 추가 데이터를 저장하고 서명 소프트웨어나 하드웨어가 서명 세션의 일부를 무의식적으로 반복하도록 속이지 않도록 해야 합니다.
- MuSig-DN(결정론적 논스)은 구현하기 훨씬 더 복잡합니다. 참가자 간의 통신은 키 교환과 결합할 수 없지만, 반복 세션 공격에 취약하지 않다는 장점이 있습니다.
모든 서명자는 사용할 프로토콜에 동의해야 하므로, 많은 구현이 동일한 프로토콜을 선택하는 네트워크 효과가 있을 수 있습니다. MuSig 제안의 저자들은 상대적으로 간단하고 유용성이 높기 때문에 MuSig2가 선택될 것이라고 제안합니다.
MuSig2 지원을 추가하기 위한 libsecp256k1-zkp 프로젝트에 대한 오픈 및 활발히 개발 중인 PR이 있습니다. 기본 다중 서명 워크플로우는 다음과 비슷할 것으로 예상합니다:
- 각 참가자의 지갑은 BIP32 xpub를 생성하고, 이를 출력 스크립트 설명자 또는 다른 방법을 통해 모든 다른 참가자와 공유합니다(현재 다중 서명에 대해 일반적으로 수행되는 것과 동일합니다).
- 지갑은 또한 다른 참가자와 공유되는 논스 세트를 생성합니다. 지갑은 BIP32 경직 파생을 사용하여 이러한 논스를 생성할 수 있습니다. 논스는 32바이트이며 서명당 두 개가 필요합니다. 드물게 사용되는 지갑의 경우, 전체 지갑 수명 동안 필요한 모든 논스를 미리 공유할 수 있습니다. 더 자주 사용되는 지갑(예: LN 라우팅 노드)의 경우, 각 지갑은 현재 거래에 대한 서명과 다음 거래에 대한 논스를 함께 보낼 수 있습니다.
- 그런 다음 지갑 중 어느 것이든 특정 BIP32 깊이에서 자신의 pubkey와 다중 서명 연합의 모든 다른 지갑에서 동일한 깊이의 pubkey를 결합하여 집계된 공개 키를 생성할 수 있습니다. 집계된 공개 키는 P2TR 지불을 받는 데 사용할 수 있습니다.
- 지갑 중 하나가 자금을 지출하고 싶을 때, 스크립트 기반 다중 서명에서 사용하는 것과 유사한 PSBT 기반 워크플로우를 사용합니다. 다중 서명과 달리, 지갑은 MuSig2 알고리즘에 따라 다음 논스와 모든 다른 참가자의 다음 논스를 사용하여 공유 논스를 생성합니다; 그런 다음 해당 논스와 거래에 대해 부분 서명을 생성합니다.
- 다른 지갑이 PSBT를 받으면 동일한 절차를 사용합니다. 부분 서명이 결합되어 최종 서명을 생성하고 거래가 방송됩니다.
임계값 서명
MuSig 패밀리의 다중 서명 스킴은 n-of-n 서명만 제공합니다. 집계된 공개 키에 기여하는 모든 당사자는 최종 서명에 부분 서명을 기여해야 합니다. 이는 오늘날 스크립트 기반 다중 서명의 일부 사용을 직접 대체하는 데 완벽하게 작동하지만, 많은 거래소에서 사용되는 2-of-3 다중 서명 스크립트와 같은 다른 인기 정책과는 다릅니다.
여러 개발자가 k-of-n 시나리오에 다중 서명의 효율성과 개인 정보 보호 이점을 가져오는 임계값 서명 스킴을 작업하고 있지만, 이러한 스킴이 사용 가능해질 때까지 사용할 수 있는 간단한 요령이 있습니다.
많은 임계값 경우에서, 서명할 가능성이 가장 높은 참가자가 미리 알려져 있습니다. 예를 들어, 2-of-3 상황에서는 일반적으로 앨리스와 밥이 공동 서명하고, 캐롤은 다른 사람 중 한 명이 사용할 수 없을 때만 서명하는 것으로 알려질 수 있습니다. 이러한 상황에서는 기본 키가 탭루트 키 경로 지출을 위해 다중 서명을 사용할 수 있으며(예: 앨리스와 밥 간), 추가 결과(앨리스와 캐롤 또는 밥과 캐롤)는 탭 스크립트 트리의 별도 분기에서 OP_CHECKSIG opcode를 사용하여 다중 서명을 사용할 수 있습니다.
정상적인 경우, 위의 방법은 단일 서명 또는 다중 서명 거래와 동일한 만큼의 효율성과 개인 정보 보호를 제공합니다. 비정상적인 경우에도 지출은 여전히 예상대로 작동하며, 다중 서명 매개변수를 온체인에 게시하는 것보다 더 효율적이고 개인적입니다.
최소 수수료와 최대 개인 정보를 원하는 사용자가 궁극적으로 순수 임계값 서명 스킴으로 전환할 수 있지만, 위의 스킴은 감사인에게 온체인 증명을 제공하기 때문에 계속 사용될 수 있습니다(모든 참가자의 공개 키를 알고 있는 경우).
릴리스 및 릴리스 후보
인기 비트코인 인프라 프로젝트의 새로운 릴리스 및 릴리스 후보. 새로운 릴리스로 업그레이드하거나 릴리스 후보 테스트를 도와주십시오.
- C-Lightning 0.10.1rc2는 여러 새로운 기능, 몇 가지 버그 수정 및 개발 프로토콜(이중 자금 조달 및 제안 포함)에 대한 몇 가지 업데이트가 포함된 업그레이드의 릴리스 후보입니다.
주목할 만한 코드 및 문서 변경 사항
이번 주 비트코인 코어, C-Lightning, Eclair, LND, Rust-Lightning, libsecp256k1, 하드웨어 지갑 인터페이스(HWI), Rust 비트코인, BTCPay 서버, 비트코인 개선 제안(BIPs), 및 라이트닝 BOLTs에서의 주목할 만한 변경 사항입니다.
- 비트코인 코어 #22006은 사용자 공간, 정적으로 정의된 추적(USDT) 및 첫 세 개의 추적 지점에 대한 문서를 추가합니다. 이 문서에 대한 빌드 지원 및 매크로는 비트코인 코어 #19866에서 추가되었습니다. eBPF 추적이 활성화된 비트코인 코어를 빌드하는 사용자는 제공된 예제 스크립트로 추적 지점에 연결하거나 새로운 블록이 연결될 때, 수신된 P2P 메시지, 발신된 P2P 메시지에 대한 더 큰 관찰 가능성을 위해 자신의 추적 스크립트를 작성할 수 있습니다. 문서에는 사용 예제와 새로운 추적 지점을 추가하기 위한 지침도 포함되어 있습니다.
- Eclair #1893은 공지되지 않은 채널, 공지된 채널 및 트램폴린 릴레이 최소에 대한 수수료율을 별도로 구성할 수 있게 합니다. 이 PR은 또한 공지되지 않은 채널(0.01%)과 공지된 채널(0.02%)에 대해 서로 다른 기본 릴레이 수수료율을 설정합니다.
- Rust-Lightning #967은 send_spontaneous_payment 함수 호출을 통해 키 전송 스타일의 자발적인 지불을 지원합니다. 이 변경으로 인해 우리가 다루는 네 가지 LN 구현 모두 키 전송을 지원하게 됩니다.
저자는 또한 키 전송 지불에 대한 해당 문서(아직 병합되지 않음)를 BLIP(비트코인 라이트닝 개선 제안)로 제출했습니다. 이는 LN BOLTs 사양의 일부로 포함되지 않는 기능 및 모범 사례를 문서화하는 제안된 방법입니다.
원본 게시물은 여기에서 확인하세요.
