비트코인 옵테크 뉴스레터는 독자들에게 비트코인에서 발생하는 가장 중요한 기술 뉴스에 대한 최상위 요약과 더 많은 정보를 배울 수 있는 리소스를 제공합니다. 독자들이 비트코인에 대한 최신 정보를 유지할 수 있도록, 아래에 이 뉴스레터의 최신 호를 재발행합니다. 이 콘텐츠를 직접 이메일로 받으려면 구독하는 것을 잊지 마세요.
이번 주 뉴스레터는 제안된 새로운 opcode에 대한 논의를 요약하고 bech32m 지원을 추적하기 위한 업데이트된 위키 페이지에 링크를 제공합니다. 또한 비트코인 코어 PR 리뷰 클럽 회의의 하이라이트, 탭루트 준비에 대한 제안, 인기 있는 비트코인 인프라 프로젝트의 주목할 만한 변경 사항에 대한 설명이 포함되어 있습니다.
뉴스
- OP_CHECKSIGFROMSTACK 디자인 제안 요청: Jeremy Rubin은 비트코인-개발 메일링 리스트에 OP_CHECKSIGFROMSTACK opcode에 대한 초안 사양을 게시하고 대체 디자인을 선호하는 개발자들로부터 피드백을 요청했습니다. 몇 가지 대안이 논의되었지만, 스레드는 OP_CAT opcode를 동시에 도입해야 하는지에 대한 논의로도 분기되었습니다.
- OP_CAT 및 OP_CSFS는 임의의 거래 내부 관찰을 가능하게 합니다. 이는 비트코인을 지출하는 스크립트의 거의 모든 부분을 확인할 수 있는 능력을 의미합니다. 이는 많은 고급 기능을 가능하게 할 수 있지만, OP_CAT은 또한 재귀적인 계약을 생성할 수 있게 하여 계약에 커밋된 비트코인의 지출 가능성을 영구적으로 제한할 수 있습니다. 일부 사람들은 비트코인에서 계약을 허용하는 것에 반대했지만, 재귀 계약의 최악의 경우 문제는 이미 오늘날 비트코인에 존재하므로 OP_CAT 또는 유사한 opcode를 활성화하는 것에 대해 걱정할 필요가 없다는 주장이 제기되었습니다.
- 논의에도 불구하고, Rubin은 OP_CSFS 제안을 OP_CAT 추가 제안과 독립적으로 유지하고 싶다고 결정했습니다. 그는 OP_CSFS가 그 자체로 충분히 유용하다고 주장했습니다.
- bech32m 지원 추적: 비트코인 위키의 bech32 채택 페이지가 업데이트되어 탭루트에 대한 bech32m 주소로 지출하거나 수신하는 소프트웨어 및 서비스 지원을 추적합니다.
- 비트코인 코어 PR 리뷰 클럽
이번 월간 섹션에서는 최근 비트코인 코어 PR 리뷰 클럽 회의를 요약하며, 중요한 질문과 답변을 강조합니다. 아래 질문을 클릭하면 회의에서의 답변 요약을 볼 수 있습니다.
script_util 헬퍼를 사용하여 P2{PKH,SH,WPKH,WSH} 스크립트를 생성하는 것은 Sebastian Falbesoner의 PR로, 기능 테스트에서 수동 스크립트 생성을 script_util 헬퍼 함수 호출로 대체하고 get_multisig() 함수의 오류를 수정합니다. 리뷰 클럽 회의에서는 용어와 PR에서 사용된 각 스크립트 출력 유형을 설명했습니다. - script_util.py의 key_to_p2pkh_script, script_to_p2sh_script, key_to_p2wpkh_script 및 script_to_p2wsh_script는 무엇을 합니까?
이들은 공개 키와 스크립트로부터 Pay to Public Key Hash, Pay to Script Hash, Pay to Witness Public Key Hash 및 Pay to Witness Script Hash 스크립트에 대한 CScript 객체를 구성하는 헬퍼 함수입니다. ➚ - scriptPubKey, scriptSig 및 witness를 정의하십시오.
scriptPubKey와 scriptSig는 각각 거래의 출력 및 입력에서 지출 조건을 지정하고 충족하기 위한 필드입니다. witness는 Segregated Witness와 함께 도입된 동일한 목적을 위한 추가 필드입니다. 지출 요구 사항은 출력의 scriptPubKey에 커밋되며, 이를 지출하는 입력은 scriptSig 및/또는 witness에서 이러한 조건을 충족하는 데이터를 동반해야 합니다. ➚ - redeem script와 witness script를 정의하십시오. 이들 간의 관계는 무엇입니까?
P2SH 및 P2WSH 출력 유형은 scriptPubKey에서 스크립트 해시에 커밋됩니다. 출력이 지출될 때, 지출자는 스크립트 자체와 이를 통과시키기 위해 필요한 서명 또는 기타 데이터를 제공해야 합니다. 스크립트는 scriptSig에 포함될 때 redeemScript라고 하고 witness에 포함될 때 witness script라고 합니다. 그런 의미에서, redeemScript는 P2SH 출력에 대한 것이고 witness script는 P2WSH 출력에 대한 것입니다. 그러나 이들은 상호 배타적이지 않으며, P2SH-P2WSH 출력을 지출하는 거래는 둘 다 포함합니다. ➚ - 지출 조건이 인코딩된 스크립트로 누군가에게 코인을 보내려면, 출력의 scriptPubKey에 무엇이 포함됩니까? 코인이 지출될 때 입력에서 무엇을 제공해야 합니까?
scriptPubKey에는 스크립트 해시와 일치를 확인하는 opcodes가 포함됩니다: OP_HASH160 OP_PUSHBYTES_20 <20B 스크립트 해시> OP_EQUAL. scriptSig에는 스크립트 자체와 초기 스택이 포함됩니다. ➚ - 왜 Pay-To-Script-Hash를 사용하고 Pay-To-Script를 사용하지 않습니까?
BIP16에서 명시된 주요 동기는 지출 조건을 제공하는 부담을 자금을 회수하는 사람에게 두면서 임의로 복잡한 거래를 자금 조달하는 일반적인 방법을 만드는 것입니다. 참가자들은 또한 scriptPubKeys에서 스크립트를 제외하면 관련 수수료가 환수될 때까지 지불되지 않으며, 결과적으로 더 작은 UTXO 세트를 생성한다고 언급했습니다. ➚ - 비세그윗 노드가 P2SH-P2WSH 입력을 검증할 때, 무엇을 합니까? 세그윗 지원 노드는 비세그윗 노드가 수행하는 절차 외에 무엇을 추가로 수행합니까?
비세그윗 노드는 witness를 전혀 보지 않습니다; 단순히 redeemScript가 scriptPubKey에 커밋된 해시와 일치하는지 확인하여 P2SH 규칙을 시행합니다. 세그윗 노드는 이 데이터를 witness 프로그램으로 인식하고 witness 데이터와 적절한 scriptCode를 사용하여 세그윗 규칙을 시행합니다. ➚ - 원래 get_multisig() 함수의 P2SH-P2WSH 스크립트에 무엇이 잘못되었습니까?
그것은 P2SH-P2WSH redeem script에서 해시 대신 witness 스크립트를 사용합니다. ➚ - 탭루트 준비 #4: P2WPKH에서 단일 서명 P2TR로
블록 높이 709,632에서 예정된 탭루트 활성화를 위해 개발자와 서비스 제공자가 준비할 수 있는 방법에 대한 주간 시리즈입니다.
이미 v0 세그윗 P2WPKH 출력을 수신하고 지출하는 것을 지원하는 지갑의 경우, 단일 서명을 위한 v1 세그윗 P2TR로 업그레이드하는 것은 쉬워야 합니다. 주요 단계는 다음과 같습니다: - 새로운 BIP32 키 파생 경로 사용: BIP32 계층 결정적(HD) 코드를 변경할 필요가 없으며 사용자가 시드를 변경할 필요도 없습니다. 그러나 P2TR 공개 키에 대해 새로운 파생 경로를 사용하는 것이 강력히 권장됩니다(예: BIP86에 의해 정의됨); 이를 수행하지 않으면 ECDSA 및 schnorr 서명을 모두 사용하는 경우 공격이 발생할 수 있습니다.
- 해시로 공개 키 조정: 단일 서명에 대해 기술적으로 필수는 아니지만, 모든 키가 무작위로 선택된 BIP32 시드에서 파생된 경우에는 BIP341이 키가 지출할 수 없는 스크립트 해시 트리에 커밋되도록 권장합니다. 이는 공개 키와 해당 키의 해시의 곡선 점을 더하는 타원 곡선 덧셈 작업을 사용하는 것만큼 간단합니다. 이 권장 사항을 준수하면 나중에 스크립트 없는 다중 서명 지원을 추가하거나 tr() 설명자 지원을 추가할 경우 동일한 코드를 사용할 수 있습니다.
- 주소를 생성하고 모니터링: bech32m을 사용하여 주소를 생성합니다. 지불은 scriptPubKey OP_1 <조정된_pubkey>로 전송됩니다. P2WPKH와 같은 v0 세그윗 주소에 대해 스캔하는 방법을 사용하여 스크립트에 지불하는 거래를 스캔할 수 있습니다.
- 지출 거래 생성: 탭루트에 대한 모든 비증인 필드는 P2WPKH와 동일하므로 거래 직렬화의 변경에 대해 걱정할 필요가 없습니다.
- 서명 메시지 생성: 이는 지출 거래의 데이터에 대한 커밋입니다. 대부분의 데이터는 P2WPKH 거래에 서명하는 것과 동일하지만, 필드의 순서가 변경되고 몇 가지 추가 항목이 서명됩니다. 이를 구현하는 것은 다양한 데이터를 직렬화하고 해시하는 문제일 뿐이므로 코드를 작성하는 것은 쉬워야 합니다.
- 서명 메시지의 해시 서명: schnorr 서명을 생성하는 방법에는 여러 가지가 있습니다. 가장 좋은 방법은 “자신의 암호화”를 하지 않고 신뢰할 수 있는 잘 검토된 라이브러리의 기능을 사용하는 것입니다. 그러나 어떤 이유로 그렇게 할 수 없다면, BIP340은 ECDSA 서명을 만드는 데 필요한 기본 요소가 이미 있는 경우 구현하기 쉬운 알고리즘을 제공합니다. 서명을 얻으면 이를 입력의 witness 데이터에 넣고 지출 거래를 전송합니다.
- 탭루트가 블록 709,632에서 활성화되기 전에도, 테스트넷, 공개 기본 시그넷 또는 비트코인 코어의 개인 regtest 모드를 사용하여 코드를 테스트할 수 있습니다. 오픈 소스 지갑에 탭루트 지원을 추가하면, 다른 개발자들이 귀하의 코드에서 배울 수 있도록 비트코인 위키의 탭루트 사용 및 bech32m 채택 페이지에 이를 구현하는 PR에 대한 링크를 추가하는 것을 권장합니다.
릴리스 및 릴리스 후보
인기 있는 비트코인 인프라 프로젝트의 새로운 릴리스 및 릴리스 후보. 새로운 릴리스로 업그레이드하거나 릴리스 후보 테스트를 도와주십시오. - LND 0.13.1-beta.rc2는 0.13.0-beta에서 도입된 기능에 대한 경미한 개선 및 버그 수정을 포함한 유지 관리 릴리스입니다.
주목할 만한 코드 및 문서 변경 사항
- 비트코인 코어, C-Lightning, Eclair, LND, Rust-Lightning, libsecp256k1, 하드웨어 지갑 인터페이스(HWI), Rust 비트코인, BTCPay 서버, 비트코인 개선 제안(BIPs), 라이트닝 BOLTs에서 이번 주 주목할 만한 변경 사항입니다.
- C-Lightning #4625는 LN 제안 구현을 최신 사양 변경 사항에 맞게 업데이트합니다. 특히, 제안에는 더 이상 서명이 필요하지 않습니다. 이는 제안의 인코딩된 문자열을 상당히 단축시켜 QR 코드 인식성을 향상시킵니다.
- Eclair #1746은 기본 SQLite 데이터베이스와 병렬로 PostgreSQL 데이터베이스에 데이터를 복제하는 지원을 추가합니다. 이 기능은 궁극적으로 백엔드 전환을 원하는 서버의 테스트를 용이하게 하기 위한 것입니다. 작년, Suredbits 엔지니어 Roman Taranchenko는 PostgreSQL 백엔드로 기업 사용을 위해 Eclair를 사용자 정의하는 방법을 Optech 현장 보고서에서 설명했습니다.
- LND #5447은 클러스터의 여러 LND 노드를 설정하는 방법을 설명하는 문서를 추가합니다. 이 문서는 클러스터의 노드 간에 복제되는 대체 데이터베이스를 사용하며 자동 장애 조치를 허용합니다. 관심 있는 독자는 이를 Eclair에서 취한 접근 방식과 Newsletter #128에서 설명된 내용을 비교할 수 있습니다.
- Libsecp256k1 #844는 schnorr 서명에 대한 API를 여러 가지 업데이트합니다. 가장 주목할 만한 것은 임의 길이의 메시지를 서명하고 검증할 수 있도록 하는 커밋입니다. 현재 비트코인에서 서명의 모든 사용은 32바이트 해시를 서명하지만, 가변 길이 데이터를 서명할 수 있도록 하는 것은 비트코인 외부의 응용 프로그램이나 OP_CHECKSIGFROMSTACK과 같은 새로운 opcode를 활성화하는 데 유용할 수 있습니다. 비트코인에 대한 schnorr 서명의 BIP340 사양이 가변 길이 데이터를 안전하게 서명하는 방법을 설명하도록 업데이트될 것으로 예상됩니다.
- BIPs #943은 BIP118을 업데이트하여 곧 활성화될 탭루트 및 tapscript에 기반하도록 하고 SegWit v0 대신 사용됩니다. 또한, 이 수정은 제목을 SIGHASH_ANYPREVOUT으로 변경하여 sighash 플래그가 이제 “ANYPREVOUT”으로 언급되도록 반영합니다. 이는 서명과 함께 사용될 수 있는 모든 이전 출력이 있을 수 있지만, 입력의 일부 측면은 여전히 커밋된다는 것을 의미합니다.
- BTCPay 서버 #2655는 사용자가 블록 탐색기에서 거래 링크를 클릭할 때 HTTP referer 필드를 보내지 않도록 웹 브라우저에 신호를 보냅니다. 이는 사용자가 어떤 BTCPay 서버에서 왔는지를 블록 탐색기에 알리는 것을 피합니다. 이 정보는 사용자가 블록 탐색기에서 보고 있는 거래가 발생했거나 수신된 서버에 대한 강력한 증거가 됩니다. 이러한 변경에도 불구하고, 강력한 개인 정보를 원하는 사용자는 여전히 제3자 블록 탐색기에서 자신의 거래를 조회하는 것을 피해야 합니다.
- 각주
- OP_CHECKSIGFROMSTACK (OP_CSFS)를 사용하여 BIP118의 SIGHASH_ANYPREVOUT 또는 BIP119의 OP_CHECKTEMPLATEVERIFY와 같은 제안의 주요 기능을 구현하려면 스크립트 경로 지출이 사용될 경우 최적화된 제안보다 더 많은 블록 공간이 필요합니다. OP_CSFS에 대한 주장은 일반적인 구성으로 시작하고 사람들이 실제로 이 기능을 사용할 것임을 증명한 후 합의 변경을 사용하여 더 효율적인 구현을 추가할 수 있도록 허용한다는 것입니다. 또한, 탭루트 키 경로 지출의 도입으로 인해 어떤 스크립트도 최소한의 블록 공간 사용으로 해결될 수 있는 상황이 있어 비최적 상황에서 공간을 절약하는 특정 구성이 필요하지 않을 수 있습니다. ↩
- Electrum이 세그윗 v0으로 업그레이드되었을 때, bech32 주소를 수신하려는 모든 사람은 새로운 시드를 생성해야 했습니다. 이는 기술적으로 필수는 아니었지만, Electrum의 저자들이 사용자 정의 시드 파생 방법에 몇 가지 새로운 기능을 도입할 수 있게 했습니다. 이러한 기능 중 하나는 시드 버전 번호가 시드가 사용될 스크립트를 지정할 수 있도록 하는 것이었습니다. 이는 오래된 스크립트를 안전하게 사용 중단할 수 있게 합니다(예: 향후 Electrum의 버전이 더 이상 레거시 P2PKH 주소로 수신하는 것을 지원하지 않을 수 있습니다).
Electrum 개발자들이 버전이 있는 시드를 배포하는 동안, 비트코인 코어 개발자들은 출력 스크립트 설명자를 사용하여 스크립트 사용 중단을 허용하는 동일한 문제를 해결하기 시작했습니다(다른 문제를 해결하는 것 외에도). 다음 표는 Electrum의 버전이 있는 시드와 비트코인 코어의 설명자를 이전에 두 지갑이 사용했던 암묵적 스크립트 방법과 비교합니다.
원본 게시물을 여기에서 찾으십시오.
매달 이 콘텐츠를 직접 이메일로 받으려면 비트코인 옵테크 뉴스레터에 직접 구독하십시오.
