비트코인 옵텍 뉴스레터는 독자들에게 비트코인에서 발생하는 가장 중요한 기술 뉴스의 최상위 요약과 함께 더 많은 정보를 배울 수 있는 자원을 제공합니다. 독자들이 비트코인에 대한 최신 정보를 유지할 수 있도록, 우리는 아래에 이 뉴스레터의 최신 호를 재발행하고 있습니다. 이 콘텐츠를 직접 이메일로 받으려면 구독하는 것을 잊지 마세요.
이번 주 뉴스레터에서는 수수료에 의한 보편적인 거래 교체를 허용하는 제안과 taproot 준비에 관한 새로운 주간 시리즈의 첫 번째 게시물이 포함되어 있습니다. 또한 클라이언트 및 서비스 업데이트, 새로운 릴리스 및 릴리스 후보, 인기 있는 비트코인 인프라 프로젝트의 주목할 만한 변경 사항을 설명하는 정기 섹션도 포함되어 있습니다.
뉴스
- 기본적으로 거래 교체 허용: 오늘날 거의 모든 비트코인 전체 노드는 BIP125 옵트인 수수료에 의한 교체(Replace By Fee, RBF)를 구현하고 있는 것으로 보이며, 이는 확인되지 않은 거래를 더 높은 수수료를 지불하는 대체 버전으로 교체할 수 있게 해줍니다. 하지만 이는 거래 생성자가 원래 거래에서 신호를 설정해야만 가능합니다. 이 옵트인 행동은 수수료 증가 또는 추가 결제 배치와 같은 거래 교체를 허용하고자 하는 사람들과, 교체를 허용하면 확인되지 않은 거래를 최종으로 받아들이는 상인을 사기하는 도구를 구축하는 것을 간소화하기 때문에 반대하는 사람들 간의 타협으로 제안되었습니다.
5년이 지난 지금, 오늘날 확인되지 않은 거래를 최종으로 받아들이는 상인은 매우 적어 보이며, 그렇게 하는 상인들 중 얼마나 많은 이들이 실제로 BIP125 옵트인 신호를 확인하고 그 거래를 다르게 취급하는지는 불확실합니다. 아무도 BIP125 신호에 의존하지 않는다면, 모든 거래를 교체 가능하게 하는 것은 다음과 같은 몇 가지 이점을 제공할 수 있습니다: - RBF 수수료 증가를 사용하는 아이디어가 악의적인 상대방이 BIP125 신호 설정을 방해할 수 있는 능력을 고려해야 하는 사전 서명 거래 프로토콜(예: LN 및 금고)에 대한 분석을 간소화합니다. 모든 거래가 교체 가능하다면, 이는 문제가 되지 않을 것입니다.
- RBF에 옵트인한 거래는 옵트인하지 않은 거래와 온체인에서 다르게 보이기 때문에 거래 분석 기회를 줄입니다. 대부분의 지갑이 일관되게 옵트인하거나 그렇지 않기 때문에, 이는 감시 회사가 누가 어떤 비트코인을 소유하고 있는지를 식별하는 시도에 사용할 수 있는 증거를 제공합니다. 모든 거래가 교체 가능하다면, BIP125 신호를 설정할 필요가 없습니다.
- 이번 주, Antoine Riard는 비트코인 개발 메일링 리스트에 BIP125 옵트인 신호를 설정했는지 여부에 관계없이 모든 거래에 대해 RBF를 허용하기 위해 비트코인 코어의 코드를 변경하는 제안서를 게시했습니다. 이 아이디어는 첫 번째 거래 중계 워크숍 회의에서도 논의되었습니다. 여러 회의 참가자들은 비트코인 코어 PR #10823을 대안 접근 방식으로 언급했습니다. 이는 거래가 노드 메모리풀에서 일정 시간(원래는 6시간; 나중에 72시간으로 제안됨)을 소비한 후에만 교체할 수 있도록 허용합니다.
Riard의 이메일과 회의 참가자들은 BIP125 옵트인 신호가 포함되지 않은 거래를 교체하기 위한 제안은 현재 BIP125 행동에 의존하는 상인들의 피드백이 필요하다고 언급했습니다. 옵텍은 그러한 상인들이 메일링 리스트 스레드에 응답하기를 권장합니다.
서비스 및 클라이언트 소프트웨어 변경 사항
이번 월간 특집에서는 비트코인 지갑 및 서비스에 대한 흥미로운 업데이트를 강조합니다.
- Trezor Suite가 RBF 지원 추가: Trezor의 지갑 소프트웨어인 Trezor Suite는 버전 21.2.2에서 수수료에 의한 교체(Replace-by-Fee, RBF) 지원을 추가했습니다. RBF는 기본적으로 활성화되어 있으며, 일부 Trezor 하드웨어 장치에서도 지원됩니다.
- Lightning Labs가 Terminal Web 발표: 최근 블로그 게시물에서 Lightning Labs는 웹 기반의 라이트닝 노드 점수 대시보드인 Terminal Web을 설명합니다.
- Specter v1.4.0 출시: Specter v.1.4.0은 BIP125 옵트인 수수료에 의한 교체(RBF)를 사용하여 거래를 “취소”하는 기능을 추가합니다.
- Phoenix가 LNURL-pay 추가: ACINQ의 모바일 지갑 Phoenix는 v1.4.12 릴리스에서 LNURL-pay 프로토콜을 지원합니다.
- JoinMarket v0.8.3 출시: JoinMarket v0.8.3은 사용자 정의 변경 주소를 제공할 수 있는 기능과 Electrum 호환 segwit signmessage 구현을 추가합니다.
taproot 준비 #1: bech32 전송 지원
개발자와 서비스 제공자가 블록 높이 709,632에서 예정된 taproot 활성화를 준비하는 방법에 대한 주간 시리즈의 첫 번째 세그먼트입니다.
블록 709,632부터, 11월에 예상되는 시점에 비트코인 사용자는 taproot 주소로 안전하게 결제를 받을 수 있습니다. taproot에 대한 사용자 열정과 지갑 개발자들이 이를 지원하기 위해 구현할 수 있는 5개월을 고려할 때, 옵텍은 사용자들이 가능한 한 빨리 taproot 주소를 생성할 수 있는 여러 인기 있는 지갑이 있을 것으로 예상합니다.
이는 비트코인을 사용자 제공 주소로 전송하는 다른 지갑이나 서비스가 블록 709,632까지 taproot 주소로 전송할 수 있어야 하며, 그렇지 않으면 사용자에게 혼란과 실망을 줄 위험이 있음을 의미합니다. TapRoot(P2TR) 주소는 BIP350에 명시된 대로 bech32m을 사용하며, 이는 segwit v0 P2WPKH 및 P2WSH 주소에 사용되는 BIP173의 bech32 알고리즘과 약간 다릅니다. Bech32m은 체크섬 함수에서 bech32의 0x01 대신 0x2bc830a3 상수를 사용합니다.
이 단일 상수를 변경하면 bech32m 체크섬을 검증할 수 있는 능력이 제공되지만, 코드는 여전히 기존 P2WPKH 및 P2WSH 주소에 대해 원래 상수를 사용해야 합니다. 코드는 체크섬을 검증하지 않고 주소를 디코딩하고, v0 segwit(bech32) 또는 v1+ segwit(bech32m)를 사용하는지 여부를 결정한 다음, 적절한 상수로 체크섬을 검증해야 합니다. 예시를 보려면 C, C++, JS 및 Python에 대한 bech32 참조 구현을 업데이트한 PR을 참조하세요. 코드가 이미 참조 라이브러리를 사용하고 있다면, 해당 저장소의 최신 코드로 업데이트할 수 있지만, 일부 API에 약간의 변경 사항이 있음을 유의하세요. BIP350과 참조 구현은 모든 bech32m 구현이 사용해야 할 테스트 벡터를 제공합니다.
비트코인 주소로 결제를 받는 것은 블록 709,632까지 안전하지 않지만, 결제를 보내는 것은 송신자에게 문제를 일으키지 않아야 합니다. 비트코인 코어는 버전 0.19(2019년 11월 출시)부터 taproot 지불 출력을 가진 거래의 중계 및 채굴을 지원해 왔습니다. 옵텍은 지갑 및 서비스 개발자들이 taproot 주소에 대한 bech32m 지불 지원을 지금 구현할 것을 권장합니다.
릴리스 및 릴리스 후보
인기 있는 비트코인 인프라 프로젝트에 대한 새로운 릴리스 및 릴리스 후보. 새로운 릴리스로 업그레이드하거나 릴리스 후보 테스트를 도와주세요.
- LND 0.13.0-beta는 앵커 출력을 기본 커밋 거래 형식으로 설정하여 수수료 관리 개선, 잘린 비트코인 전체 노드를 사용하는 지원 추가, Atomic MultiPath(AMP)를 사용하여 결제를 수신 및 전송할 수 있도록 하며, LND의 PSBT 기능을 증가시키는 등 많은 개선 사항과 버그 수정을 포함한 새로운 주요 릴리스입니다.
주목할 만한 코드 및 문서 변경 사항
이번 주 비트코인 코어, C-Lightning, Eclair, LND, Rust-Lightning, libsecp256k1, 하드웨어 지갑 인터페이스(HWI), Rust Bitcoin, BTCPay Server, 비트코인 개선 제안(BIPs), 및 Lightning BOLTs에서의 주목할 만한 변경 사항입니다.
- 비트코인 코어 #21365는 지갑이 taproot 지출을 위한 서명을 생성할 수 있는 기능을 추가합니다. 여기에는 P2TR 공개 키를 사용하는 키 경로 지출과 tapscript를 사용하는 스크립트 경로 지출이 포함됩니다. 지갑은 taproot 지출 PSBT에 대해서도 서명할 수 있지만, 지갑이 필요한 모든 키 경로 또는 스크립트 경로 정보를 이미 가지고 있어야 합니다. 다소 관련된 병합 PR #22156은 taproot가 활성화된 후에만 해당 키 경로 및 스크립트 경로 정보를 가져오는 것을 허용합니다(메인넷의 블록 709,632이지만, taproot가 이미 활성화된 테스트 네트워크에서는 지금 가져올 수 있습니다).
- 비트코인 코어 #22144는 메시지 처리 스레드에서 피어가 서비스되는 순서를 무작위화하여 P2P 메시지를 피어로부터 파싱하고 처리하며 해당 피어에게 메시지를 전송하는 책임이 있습니다. 이전에는 메시지 처리 스레드가 피어와의 연결이 처음 설정된 순서대로 각 피어를 라운드 로빈 방식으로 서비스했습니다. 이 PR은 메시지 처리 루프의 각 반복에서 피어가 서비스되는 순서를 무작위화하는 논리로 변경합니다. 피어는 여전히 동일한 빈도로 서비스되지만(각 피어는 각 반복마다 한 번 서비스됨), 피어 서비스의 결정론적 순서에 의존하는 약점이나 악용을 피할 수 있습니다.
- 비트코인 코어 #21261은 수신 연결 보호를 더 많은 네트워크로 확장하는 것을 쉽게 만들고, 그 프레임워크를 사용하여 I2P를 보호된 네트워크 목록에 추가합니다. 다양성 보호(종종 퇴출 보호라고 불림)는 비트코인 코어가 고지연 연결을 잘라내는 경우에도 몇몇 바람직한 특성을 가진 피어가 연결된 상태를 유지할 수 있도록 합니다. 익명성 네트워크의 피어와의 몇몇 연결을 유지하는 것은 거래 생성자가 해당 네트워크를 사용하여 네트워크 신원을 숨길 수 있게 해주고, 정규 인터넷 프로토콜 외에 해당 네트워크를 통해 블록을 수신할 수 있는 능력이 일부 유형의 일식 공격을 방지할 수 있기 때문에 매우 바람직합니다.
- Rust Bitcoin #601은 bech32m 주소를 파싱하는 지원을 추가하고 v1+ 네이티브 segwit 주소가 bech32m으로 인코딩되어야 하며 bech32로 인코딩되어서는 안 된다고 요구합니다.
- BTCPay Server #2450은 사용자가 결제를 수신하기 위해 핫 월렛을 사용하는 경우 payjoin 호환 인보이스 생성을 기본값으로 설정합니다. 지갑 생성 화면의 버튼을 통해 사용자는 이 기본 설정에서 옵트아웃할 수 있습니다.
- BTCPay Server #2559는 사용자가 지갑에서 지출하는 거래에 서명하는 방법에 대한 선택을 안내하는 별도의 화면을 추가합니다. 핫 월렛의 경우 서버가 그냥 서명할 수 있지만, 키가 다른 곳에 저장된 지갑의 경우 매력적이고 유익한 GUI가 사용자가 복구 니모닉 입력, 하드웨어 서명 장치 사용 또는 서명 지갑으로 전송할 PSBT 생성과 같은 서명 옵션을 안내합니다.
원본 게시물을 여기에서 확인하세요.
매달 이 콘텐츠를 직접 이메일로 받으려면 비트코인 옵텍 뉴스레터에 직접 구독하세요.
