v0.5

MuSig2 QR 교환 최적화 설계¶

1. 현재 상태 분석 (As-Is)¶

1.1. MuSig2 프로토콜 구조 요약¶

Phase 24 btc-implementation.md에서 확정된 옵션 A(오프체인 승인 + 온체인 마스터 서명 완전 분리) 아키텍처에서, BTC MuSig2는 복수 콜드월렛 운용 시에만 필요하다. 단일 콜드월렛은 BIP-340 Schnorr 단일 서명으로 MuSig2가 불필요하다.

복수 콜드월렛 MuSig2(BIP-327) 서명 프로토콜:

Round 1: Nonce 생성 및 교환
  - 각 서명자 i가 nonce pair (R_i1, R_i2) 생성
  - pubnonce = (R_i1, R_i2) 를 다른 서명자에게 공유

Round 2: Partial Signature 생성 및 교환
  - 모든 pubnonce 수집 후, 각 서명자가 partial signature s_i 생성
  - s_i를 Coordinator에게 전달

Round 3 (집계): Coordinator가 s = sum(s_i) 계산 → 최종 Schnorr 서명

1.2. QR 교환 횟수 산출 공식¶

N-of-N MuSig2에서 서명자 N명, Coordinator(오프라인 앱)가 중개하는 경우:

단계	교환 방향	교환 횟수	설명
PSBT 전달	Coordinator -> 각 서명자	N회	미서명 PSBT + 세션 정보 전달
Round 1 (pubnonce)	각 서명자 -> Coordinator	N회	pubnonce 수집
Round 1 배포	Coordinator -> 각 서명자	N회	전체 pubnonce 세트 배포
Round 2 (partial sig)	각 서명자 -> Coordinator	N회	partial signature 수집
합계		4N회	Coordinator 기준 총 QR 스캔

서명자 개인 기준: 각 서명자는 2회 수신(PSBT + pubnonce 세트) + 2회 송신(pubnonce + partial sig) = 4회/서명자.

1.3. 정족수별 현재 QR 교환 횟수¶

옵션 A에서 복수 콜드월렛 MuSig2 직접 서명(콜드룸 폴백) 시나리오 기준:

정족수	실참여 서명자(N)	Coordinator 기준 QR	서명자 개인 기준 QR	추정 소요 시간
2-of-3	2 (N-of-N)	4 x 2 = 8회	4회	~56초
3-of-5	3 (N-of-N)	4 x 3 = 12회	4회	~84초
5-of-7	5 (N-of-N)	4 x 5 = 20회	4회	~140초

참고: 옵션 A 기존 비교에서 2-of-3 기준 10회로 기술된 것은 5단계 파이프라인 전체(Request 1회 + Approve 6회 + Collect 1회 + Sign 1회 + Broadcast 1회)를 합산한 수치이며, 여기서는 MuSig2 프로토콜 부분만 분리하여 최적화 대상으로 분석한다.

시간 추정 근거: QR 스캔 1회 = 표시(~2초) + 스캔(~3초) + 확인(~2초) = 약 7초/회.

1.4. 라운드별 데이터 크기 추정¶

데이터	크기	설명
pubnonce (1서명자)	66 바이트	2개의 33바이트 compressed point (R_i1, R_i2)
partial signature (1서명자)	32 바이트	32바이트 스칼라 값 s_i
PSBT (일반 출금)	200~500 바이트	1-input 1-output 기준, UR 인코딩 후
MuSig2 세션 컨텍스트	약 100 바이트	key list hash, key coefficients, aggregated key
pubnonce 세트 (N명)	66N 바이트	N명의 pubnonce 배열
CBOR 오버헤드	약 20~50 바이트	CBOR 태그, 배열/맵 헤더

2-of-3 기준 라운드별 총 페이로드: - Round 1 배포(Coordinator -> 서명자): PSBT(~400B) + 세션 컨텍스트(~100B) + pubnonce 세트(66x2=132B) = ~632바이트 - Round 2 수집(서명자 -> Coordinator): partial sig(32B) + 메타데이터(~20B) = ~52바이트

QR Code v25 (alphanumeric) 용량은 약 2,953 바이트이며, BC-UR Bytewords 인코딩 시 약 1,200~1,400 바이트 실효 용량이다. 모든 라운드 데이터는 단일 QR 프레임 내 적재 가능하다.

2. Animated QR 배치 전송 설계 (QR-01)¶

2.1. BC-UR Animated QR 프레임워크¶

Blockchain Commons의 Uniform Resources (UR) 규격은 CBOR 인코딩 데이터를 QR 코드로 전달하기 위한 표준 프레임워크이다. 핵심 특성:

UR 타입 시스템: 데이터 유형별 UR 타입 식별자 (예: crypto-psbt, dcent-approval-bundle)
Bytewords 인코딩: 바이너리 데이터를 QR-friendly 알파뉴메릭 문자로 변환
Fountain Code (FC): 대용량 데이터를 여러 QR 프레임에 분할하여 Animated QR로 전송, 임의의 프레임 조합으로 원본 복원 가능 (Luby Transform Code 기반)
프레임 구조: ur:{type}/{part-index}-{total-parts}/{bytewords-payload}

2.2. 배치 전송 핵심 아이디어¶

기존 MuSig2 프로토콜에서 4N회 QR 교환이 필요한 이유는 각 라운드마다 개별 QR 교환을 수행하기 때문이다. 배치 전송은 다음 두 가지 최적화를 결합한다:

최적화 1: Coordinator-to-Signer 배치 (라운드 통합)

Coordinator가 서명자에게 전달하는 데이터를 단일 Animated QR 시퀀스로 통합:

기존:
  [QR 1: PSBT 전달] -> 서명자 i (1회)
  [QR 2: pubnonce 세트 전달] -> 서명자 i (1회)
  = 서명자 i에게 2회 QR 전달

배치 후:
  [Animated QR: PSBT + pubnonce 세트] -> 서명자 i (1회)
  = 서명자 i에게 1회 QR 전달

최적화 2: Signer-to-Coordinator 배치 (라운드 통합)

서명자가 Coordinator에게 반환하는 데이터를 단일 QR로 통합:

기존:
  서명자 i -> [QR 1: pubnonce] -> Coordinator (1회)
  서명자 i -> [QR 2: partial sig] -> Coordinator (1회)
  = 서명자 i로부터 2회 QR 수신

배치 후:
  서명자 i -> [QR: pubnonce + partial sig] -> Coordinator (1회)
  = 서명자 i로부터 1회 QR 수신

핵심 전제: 서명자가 pubnonce와 partial sig를 동시에 생성하려면, Coordinator가 먼저 모든 서명자의 pubnonce를 수집한 뒤 partial sig 생성을 요청해야 하는 MuSig2 프로토콜 순서를 변경해야 한다. 이를 위해 2-Pass 프로토콜을 설계한다.

2.3. 2-Pass 배치 프로토콜¶

MuSig2의 라운드 의존성(Round 2는 Round 1 결과에 의존)을 고려한 최적화 프로토콜:

=== Pass 1: Nonce 수집 ===

Coordinator                          서명자 1, 2, ..., N
    |                                     |
    |--- [Animated QR: PSBT + 세션정보] -->|  (1회, 브로드캐스트)
    |                                     |
    |<-- [QR: pubnonce_i] --------------- |  (N회, 각 서명자)
    |                                     |

Pass 1 소계: 1 + N = N+1 회

=== Pass 2: 서명 수집 ===

Coordinator                          서명자 1, 2, ..., N
    |                                     |
    |--- [Animated QR: 전체 pubnonce 세트]-|  (1회, 브로드캐스트)
    |                                     |
    |<-- [QR: partial_sig_i] ------------ |  (N회, 각 서명자)
    |                                     |

Pass 2 소계: 1 + N = N+1 회

=== 총계: 2(N+1) 회 ===

Coordinator 브로드캐스트 최적화: Pass 1과 Pass 2에서 Coordinator가 서명자들에게 전달하는 Animated QR은 화면에 한 번 표시하면 모든 서명자가 동시에 스캔 가능하다(1:N 브로드캐스트). 따라서:

단계	교환 횟수	설명
Pass 1: PSBT 브로드캐스트	1회	Coordinator 화면 → 전체 서명자 동시 스캔
Pass 1: pubnonce 수집	N회	각 서명자 → Coordinator 순차 스캔
Pass 2: pubnonce 세트 브로드캐스트	1회	Coordinator 화면 → 전체 서명자 동시 스캔
Pass 2: partial sig 수집	N회	각 서명자 → Coordinator 순차 스캔
합계	2N + 2

2.4. CBOR 배치 인코딩 구조¶

배치 전송 시 CBOR 인코딩 구조:

; Pass 1 브로드캐스트: Coordinator -> 서명자 (전체)
; UR type: dcent-musig2-session (45060)
musig2-session-init = {
  1: bytes,                    ; psbt: 미서명 PSBT (BIP-370)
  2: [+ bytes .size 33],       ; participant_keys: N개 공개 키
  3: uint,                     ; threshold: N (N-of-N)
  4: bytes .size 32,           ; session_id: 세션 고유 ID
  5: uint,                     ; timestamp: 세션 시작 시간
}

; Pass 1 응답: 서명자 -> Coordinator (개별)
; UR type: dcent-musig2-nonce (45061)
musig2-nonce-response = {
  1: bytes .size 66,           ; pubnonce: (R_i1 || R_i2)
  2: bytes .size 33,           ; signer_key: 서명자 공개 키
  3: bytes .size 32,           ; session_id: 세션 ID (바인딩)
}

; Pass 2 브로드캐스트: Coordinator -> 서명자 (전체)
; UR type: dcent-musig2-round2 (45062)
musig2-round2-init = {
  1: bytes .size 32,           ; session_id: 세션 ID
  2: [+ bytes .size 66],       ; all_pubnonces: N개 pubnonce 배열
  3: bytes .size 32,           ; msg: 서명 대상 메시지 (sighash)
}

; Pass 2 응답: 서명자 -> Coordinator (개별)
; UR type: dcent-musig2-partial (45063)
musig2-partial-response = {
  1: bytes .size 32,           ; partial_sig: s_i
  2: bytes .size 33,           ; signer_key: 서명자 공개 키
  3: bytes .size 32,           ; session_id: 세션 ID (바인딩)
}

2.5. Fountain Code 에러 복구¶

Animated QR에서 Fountain Code(Luby Transform Code)를 활용한 에러 복구:

인코딩: 원본 데이터를 K개의 소스 블록으로 분할 → 무한개의 인코딩 심볼 생성 가능
디코딩: 임의의 K+α개 심볼 수신 시 원본 복원 (α: 약 2~5% 오버헤드)
QR 적용: 각 Animated QR 프레임이 하나의 Fountain Code 심볼에 대응
복구 능력: 프레임 누락(카메라 흔들림, 반사 등)이 발생해도 추가 프레임 수신으로 자동 복구

MuSig2 데이터 크기와 Fountain Code 필요성:

정족수	Pass 1 브로드캐스트 크기	Pass 2 브로드캐스트 크기	단일 QR 적재 가능 여부
2-of-3	~600B (PSBT+세션)	~182B (pubnonce 2개+msg)	가능 (단일 프레임)
3-of-5	~600B	~248B (pubnonce 3개+msg)	가능 (단일 프레임)
5-of-7	~600B	~380B (pubnonce 5개+msg)	가능 (단일 프레임)

모든 정족수에서 데이터가 단일 QR 프레임(~1,200B 실효 용량) 내에 적재되므로, Fountain Code는 대형 PSBT(다중 UTXO 통합 등)에서만 필요하다. 일반적인 1~3 input TX에서는 단일 정적 QR로 충분하다.

2.6. 50% 감소 수학적 증명¶

기존 교환 횟수: 4N (섹션 1.2)

배치 후 교환 횟수: 2N + 2 (섹션 2.3)

감소율 계산:

감소율 = (4N - (2N + 2)) / 4N x 100%
       = (2N - 2) / 4N x 100%
       = (N - 1) / 2N x 100%

N (서명자 수)	기존 (4N)	배치 (2N+2)	감소 횟수	감소율
2	8	6	2	25.0%
3	12	8	4	33.3%
5	20	12	8	40.0%
7	28	16	12	42.9%
N -> infinity	4N	2N+2	2N-2	-> 50.0%

분석: 2-Pass 배치만으로는 N=2에서 25%, N=5에서 40%로 50% 미달이다. 50% 이상 달성을 위해 추가 최적화: Pre-commitment Pipelining을 도입한다.

2.7. Pre-commitment Pipelining (50%+ 달성)¶

아이디어: MuSig2 nonce는 서명 대상 메시지와 독립적으로 사전 생성 가능하다(BIP-327 NonceGen은 msg를 선택적 파라미터로 수용). 이를 활용하여 Pass 1을 사전 처리한다.

=== 사전 준비 (Pre-commitment) ===
서명 세션 시작 전에 각 서명자가 nonce를 미리 생성하여 Coordinator에 등록

Coordinator                          서명자 1, 2, ..., N
    |                                     |
    |<-- [QR: pubnonce_i] --------------- |  (N회, 사전 수집)
    |                                     |

사전 준비 소계: N 회 (세션 외 1회성)

=== 서명 세션 (Single-Pass) ===
사전 수집된 pubnonce로 즉시 서명 진행

Coordinator                          서명자 1, 2, ..., N
    |                                     |
    |--- [Animated QR: PSBT + 전체       -|  (1회, 브로드캐스트)
    |     pubnonce 세트 + sighash]         |
    |                                     |
    |<-- [QR: partial_sig_i] ------------ |  (N회, 각 서명자)
    |                                     |

서명 세션 소계: N + 1 회

Pre-commitment 포함 총 교환 횟수: N(사전) + N + 1(서명) = 2N + 1

그러나 Pre-commitment는 서명 세션과 시간적으로 분리되므로, 서명 시점 교환 횟수는 N + 1로 크게 감소한다.

보안 고려: Pre-commitment nonce는 SE의 delete-on-read 규칙과 24시간 세션 타임아웃(Phase 24 섹션 6.2)에 의해 보호된다. 사전 생성된 nonce가 24시간 내에 사용되지 않으면 자동 폐기된다.

2.8. 최적화 방식별 교환 횟수 종합¶

방식	공식	서명 시점 교환	사전 준비 포함 총 교환
기존 (개별 교환)	4N	4N	4N
2-Pass 배치	2N + 2	2N + 2	2N + 2
Pre-commitment + Single-Pass	N + 1	N + 1	2N + 1

서명 시점 기준 감소율 (Pre-commitment 방식):

감소율 = (4N - (N + 1)) / 4N x 100%
       = (3N - 1) / 4N x 100%

N	기존 (4N)	서명 시점 (N+1)	감소율
2	8	3	62.5%
3	12	4	66.7%
5	20	6	70.0%
7	28	8	71.4%

모든 정족수에서 서명 시점 기준 50% 이상 감소를 달성한다.

3. NFC APDU 고속 교환 설계 (QR-02)¶

3.1. NFC APDU 기반 MuSig2 라운드 교환¶

Phase 25 firmware-requirements.md에서 정의된 NFC APDU 7개 명령(CLA 0x80)은 개인 기기 승인용이다. 복수 콜드월렛 MuSig2 서명의 NFC 고속 교환을 위해, 콜드월렛 SE에도 유사한 NFC APDU 인터페이스를 설계한다.

3.1.1. MuSig2 NFC APDU 명령 세트¶

INS	명령	방향	데이터	설명
0x80	MUSIG2_INIT	Coordinator -> CW	세션 정보 + PSBT	MuSig2 세션 초기화
0x81	MUSIG2_GET_NONCE	Coordinator <- CW	pubnonce	콜드월렛 nonce 반환
0x82	MUSIG2_SET_NONCES	Coordinator -> CW	전체 pubnonce 세트	모든 참여자 nonce 전달
0x83	MUSIG2_SIGN	Coordinator <- CW	partial_sig	WYSIWYS 확인 후 partial signature 반환
0x84	MUSIG2_ABORT	Coordinator -> CW	-	세션 취소, nonce 폐기

3.1.2. NFC 통신 시퀀스¶

Coordinator (오프라인 앱, NFC Reader)        콜드월렛 (NFC Tag/Card Emulation)
        |                                          |
        |--- MUSIG2_INIT(PSBT, session_info) ----->|  TAP 1
        |<-- SW 9000 (OK) + session_id ------------|
        |                                          |
        |--- MUSIG2_GET_NONCE() ------------------>|  (같은 TAP 1 내)
        |<-- pubnonce_i (66 bytes) ----------------|
        |                                          |
        ... (다른 콜드월렛에 대해 TAP 2, TAP 3 반복) ...
        |                                          |
        |--- MUSIG2_SET_NONCES(all_pubnonces) ---->|  TAP 4 (다시 CW_1)
        |<-- SW 9000 (OK) + WYSIWYS 시작 ----------|
        |                                          |
        |--- MUSIG2_SIGN() ----------------------->|  (같은 TAP 4 내, 사용자 확인 후)
        |<-- partial_sig_i (32 bytes) -------------|
        |                                          |

3.1.3. NFC TAP 횟수 산출¶

단계	TAP 횟수	설명
초기화 + nonce 수집	N회	각 콜드월렛에 1번 TAP (INIT + GET_NONCE 연속)
nonce 세트 전달 + 서명 수집	N회	각 콜드월렛에 1번 TAP (SET_NONCES + SIGN 연속)
합계	2N회

단일 TAP 내에서 여러 APDU 명령을 연속 실행하므로, QR 대비 교환 단위가 크게 줄어든다.

3.2. NFC 대역폭 및 소요 시간 분석¶

3.2.1. NFC 통신 속도¶

파라미터	값	근거
NFC 대역폭 (ISO 14443-4)	424 kbps	고속 모드, D'CENT X USB-C + NFC 지원
APDU 오버헤드	~10 바이트/명령	CLA+INS+P1+P2+Lc+Le
NFC 프로토콜 오버헤드	~20%	프레이밍, CRC, 재전송
실효 전송 속도	~340 kbps = ~42.5 KB/s	424 x 0.8

3.2.2. 데이터 전송 시간 계산¶

데이터	크기	NFC 전송 시간	설명
MUSIG2_INIT (PSBT + 세션)	~600B	~14ms	즉시
MUSIG2_GET_NONCE 응답	~80B	~2ms	즉시
MUSIG2_SET_NONCES (N=5)	~380B	~9ms	pubnonce 5개
MUSIG2_SIGN 응답	~50B	~1ms	즉시
1회 TAP 총 시간	-	~0.5~1.0초	데이터 전송 + 사용자 물리 동작
WYSIWYS 확인 시간	-	~3~5초	사용자가 화면 확인 + 버튼 클릭

3.2.3. NFC 총 소요 시간 (WYSIWYS 포함)¶

정족수	TAP 횟수	TAP당 시간	WYSIWYS 확인(N회)	총 시간
2-of-3 (N=2)	4회	~1초	2 x 4초 = 8초	~12초
3-of-5 (N=3)	6회	~1초	3 x 4초 = 12초	~18초
5-of-7 (N=5)	10회	~1초	5 x 4초 = 20초	~30초

3.3. QR vs NFC 소요 시간 비교¶

정족수	기존 QR (4N x 7초)	배치 QR (2N+2 x 7초)	Pre-commit QR ((N+1) x 7초)	NFC (2N TAP)
2-of-3	56초	42초	21초	12초
3-of-5	84초	56초	28초	18초
5-of-7	140초	84초	42초	30초

NFC는 기존 QR 대비 78~79% 시간 단축, Pre-commitment QR 대비에도 43~57% 추가 단축을 달성한다.

3.4. NFC APDU 청크 프로토콜¶

대용량 PSBT(다중 UTXO 통합 TX 등)의 경우 255바이트 APDU 제한을 초과할 수 있다. Phase 25 firmware-requirements.md의 P2 시퀀스 번호 기반 청크 프로토콜을 동일하게 적용:

P2 = 0x00: 단일 APDU (데이터 < 255B)
P2 = 0x01: 첫 번째 청크
P2 = 0x02: 두 번째 청크
...
P2 = 0xFF: 마지막 청크 (또는 P1 bit flag로 "last" 표시)

Extended Length APDU 대안: ISO 7816-4 Extended Length APDU는 최대 65,535바이트를 지원하지만, 모든 NFC 컨트롤러가 지원하지 않으므로 청크 프로토콜을 기본으로 한다. D'CENT X의 NFC 컨트롤러가 Extended Length를 지원하는 경우 단일 APDU 전송이 가능하며, 이는 HW-CONFIRM 대상이다.

3.5. NFC + QR 병행 사용 시나리오¶

시나리오	채널 선택	근거
D'CENT X 콜드월렛 (NFC 지원)	NFC 우선	고속 교환, 최소 시간
바이오메트릭 콜드월렛 (NFC 미지원)	QR 폴백	NFC 불가, Animated QR 배치 사용
NFC 통신 오류 시	QR 자동 폴백	3회 NFC 재시도 실패 시 QR 전환
대형 PSBT (>2KB)	QR 우선	Animated QR Fountain Code가 대용량에 유리

폴백 로직:

1. NFC 가용성 확인 (Coordinator 앱에서 NFC Reader 감지)
2. NFC 가용 → NFC 프로토콜로 MuSig2 라운드 교환
3. NFC 불가 또는 3회 실패 → Animated QR 배치 프로토콜로 전환
4. 데이터 크기 > 2KB → Animated QR Fountain Code 사용
5. 채널 선택은 세션 중 변경 불가 (보안: 중간 채널 전환 공격 방지)

3.6. NFC 보안 고려사항¶

위협	위험도	대응
NFC 도청 (~4cm 이내)	낮음	콜드룸 물리적 접근 통제가 1차 방어. NFC 통신은 4cm 이내에서만 가능하며, 콜드룸 외부 도청 불가
Relay Attack	중간	WYSIWYS 표시에 세션 ID 포함하여 물리적 기기 확인. NFC 통신 시간 임계값(~100ms)으로 relay 탐지
데이터 변조	낮음	MuSig2 프로토콜 자체가 검증 메커니즘 내장. partial_sig가 올바른 nonce와 키로 생성되었는지 검증
비인가 기기 접근	낮음	콜드월렛 SE attestation으로 기기 진정성 검증. 미등록 기기의 MuSig2 참여 차단

4. 정족수별 QR 교환 횟수 비교표 (QR-04)¶

4.1. 종합 비교표¶

Coordinator 기준 교환 횟수¶

정족수	실참여(N)	기존 QR	2-Pass 배치 QR	Pre-commit QR (서명 시점)	NFC
2-of-3	2	8회	6회	3회	4 TAP
3-of-5	3	12회	8회	4회	6 TAP
5-of-7	5	20회	12회	6회	10 TAP

서명자 개인 기준 교환 횟수¶

정족수	기존 QR	2-Pass 배치 QR	Pre-commit QR (서명 시점)	NFC
2-of-3	4회	2회	1회(서명) + 1회(사전)	2 TAP
3-of-5	4회	2회	1회(서명) + 1회(사전)	2 TAP
5-of-7	4회	2회	1회(서명) + 1회(사전)	2 TAP

소요 시간 비교¶

정족수	기존 QR 시간	2-Pass 배치 시간	Pre-commit 시간(서명 시점)	NFC 시간
2-of-3	~56초	~42초	~21초	~12초
3-of-5	~84초	~56초	~28초	~18초
5-of-7	~140초	~84초	~42초	~30초

감소율 비교 (기존 QR 대비)¶

정족수	2-Pass 배치 감소율(교환)	Pre-commit 감소율(교환)	NFC 감소율(시간)
2-of-3	25.0%	62.5%	78.6%
3-of-5	33.3%	66.7%	78.6%
5-of-7	40.0%	70.0%	78.6%

4.2. 50% 달성 여부 검증¶

정족수	방식	기존	최적화 후	감소율	50% 달성
2-of-3	2-Pass 배치	8회	6회	25.0%	미달
2-of-3	Pre-commit	8회	3회	62.5%	달성
2-of-3	NFC (시간)	56초	12초	78.6%	달성
3-of-5	2-Pass 배치	12회	8회	33.3%	미달
3-of-5	Pre-commit	12회	4회	66.7%	달성
3-of-5	NFC (시간)	84초	18초	78.6%	달성
5-of-7	2-Pass 배치	20회	12회	40.0%	미달
5-of-7	Pre-commit	20회	6회	70.0%	달성
5-of-7	NFC (시간)	140초	30초	78.6%	달성

결론: 2-Pass 배치 단독으로는 50% 미달이나, Pre-commitment Pipelining 적용 시 모든 정족수에서 62.5~70.0% 감소를 달성한다. NFC 채널은 시간 기준으로 78.6% 감소를 달성한다.

4.3. 권장 최적화 전략¶

우선순위	전략	적용 범위	효과
1순위	Pre-commitment Pipelining + Single-Pass	모든 콜드월렛	QR 교환 62.5~70.0% 감소
2순위	NFC 고속 교환	D'CENT X 콜드월렛	시간 78.6% 감소
3순위	2-Pass 배치 (폴백)	Pre-commit 불가 시	QR 교환 25~40% 감소
공통	Animated QR + Fountain Code	대형 PSBT (>1KB)	에러 복구, 안정성

5. 구현 고려사항¶

5.1. SE nonce 사전 생성 제약¶

Pre-commitment Pipelining의 핵심 전제는 SE가 서명 대상 메시지 없이 nonce를 사전 생성할 수 있어야 한다. BIP-327 NonceGen 함수는 msg를 선택적 파라미터로 정의하므로 이는 프로토콜적으로 허용된다. 단, SE 구현 시 다음 제약을 준수해야 한다:

동시 사전 nonce 최대 2개 (Phase 24 섹션 6.2: 동시 세션 2개 제한)
24시간 자동 폐기 (미사용 nonce 타임아웃)
Delete-on-read (서명 사용 시 즉시 원자적 삭제)
단조 카운터 (롤백 공격 방어)

5.2. 오프라인 앱 Coordinator 역할¶

오프라인 앱(Zone 2)이 MuSig2 Coordinator 역할을 수행하며, 다음 기능을 구현해야 한다:

채널 자동 감지 (NFC Reader 유무 확인)
2-Pass 배치 또는 Pre-commitment 프로토콜 선택
pubnonce 수집 및 세션 상태 관리
partial signature 수집 및 최종 서명 집계
에러 발생 시 QR 폴백 자동 전환

5.3. Animated QR 구현 요구사항¶

BC-UR 라이브러리 통합 (UREncoder/URDecoder)
QR Code v25 이상 생성 (alphanumeric mode)
프레임 레이트: 8~12 fps (사용자 스캔 최적)
Fountain Code 인코더/디코더 (Luby Transform)
커스텀 UR 타입 등록: 45060~45063 (MuSig2 배치 프로토콜용)

설계 기준: Phase 24 btc-implementation.md 옵션 A 채택 결과, Phase 25 firmware-requirements.md NFC APDU 명령 세트 참조: BIP-327 (MuSig2), BC-UR (Blockchain Commons Uniform Resources), ISO 14443-4 (NFC) 정족수 기준: MuSig2 N-of-N 복수 콜드월렛 운용 시나리오 (2-of-3, 3-of-5, 5-of-7)