비트코인은 왜 AES로 “암호화”하지 않을까? — ECC·ECDSA부터 P2P 통신(8333)까지, ‘신뢰의 네트워크’ 한 번에 끝내기

[서론]
정보보안기사나 네트워크 실무를 하다 보면 ECC/ECDSA/ECDH가 한 덩어리로 보이고, 비트코인은 더 난해하게 느껴져요. “암호화”라면서 왜 내용을 숨기지(Encrypt) 않고, 오히려 전 세계에 평문으로 뿌리며(Sign), 그게 어떻게 “신뢰”가 된다는 건지.

이 글은 한 줄로 정리하면 이거예요.

비트코인은 ‘비밀 편지(AES)’가 아니라 ‘공개 수표(서명)’를 굴리는 시스템이라서, 암호화가 아니라 서명+검증+합의(P2P 전파)가 핵심이에요.

이제 ECC → ECDSA → 트랜잭션 서명 → P2P 전파(8333/TCP) → 블록 누적/검증 → 차단이 어려운 이유까지, “패킷이 눈에 보이게” 풀어드리겠습니다.

[본론] 1) ECC vs ECDSA: “분야(카테고리)”와 “도구(구현체)”의 포함 관계

1-1. 용어 정리(시험·실무 공통)

• ECC (Elliptic Curve Cryptography): 타원곡선 기반 암호 “기술 분야/계열”
• ECDSA: ECC를 이용한 전자서명 알고리즘
• ECDH: ECC를 이용한 키 교환 알고리즘
• (확장) Schnorr: 비트코인이 Taproot에서 도입한 서명 방식(시그니처) (bips.dev)

1-2. 왜 다들 ECC를 좋아할까? (RSA 대비 “동급 보안에서 키가 짧다”)

실무에서 ECC가 자주 튀어나오는 이유는 대체로 “성능/키길이” 때문입니다. 보안 강도(대략적인 동급)를 비교하면 ECC 256-bit ≈ RSA 3072-bit처럼 키 길이가 훨씬 짧게 잡히는 구간이 있고, 이게 곧 연산량/핸드셰이크 비용/인증서 크기에 영향을 줍니다. (learnmeabitcoin.com)

실무 감각 포인트
TLS에서도 ECDHE(=ECC 기반 키 교환)를 흔히 보는데, 이건 “세션키 협상(키 교환)”에서 ECC를 쓰는 전형적인 사례입니다. (IETF Datatracker)

2) 비트코인의 핵심: “암호화(기밀성)”가 아니라 “서명(소유권/무결성)”

2-1. RSA+AES 하이브리드 vs 비트코인: 목적이 다릅니다

비트코인은 “공공 장부”라서, 거래 내용이 암호화되면 검증자(노드)가 정당성을 확인할 수 없어요. 그래서 비트코인 레이어의 기본 설계는 Encrypt보다 Verify에 최적화되어 있습니다.

3) 비트코인 트랜잭션은 “원본 + 서명 + 공개키(또는 스크립트 증빙)” 세트로 굴러갑니다

3-1. 트랜잭션이 네트워크로 퍼질 때(핵심 교정)

노드가 검증하려면 “해시만”으로는 부족합니다. 실제로는 대략 이런 세트가 필요해요.

1. Raw Transaction(원본 트랜잭션): 입력(Input)이 어떤 UTXO를 쓰는지, 출력(Output)이 누구에게 얼마인지
2. Signature(서명): 개인키로 “이 입력을 내가 쓴다”를 증명
3. 공개키/스크립트 증빙: 서명 검증에 필요한 재료

Verify 메커니즘(보안 관점 핵심식)
Sign = ECDSA_Sign(privkey, Hash(raw_tx))
Verify = ECDSA_Verify(pubkey, Sign, Hash(raw_tx))

3-2. SegWit 이후: “서명(witness)”을 분리해 전송/구조 효율을 개선

SegWit은 트랜잭션에서 서명 데이터(witness)를 분리하고, 블록 용량을 weight(가중치)로 계산하도록 바꿨습니다. 그 결과 규칙은 블록 weight ≤ 4,000,000으로 정의됩니다. (bips.dev)

실무 비유
본문(기본 데이터)은 4배 무겁고(witness보다 비용 큼), 서명(witness)은 1배로 계산되는 “요금제”로 바꿔서 네트워크 부담을 균형 있게 만든 느낌입니다. (bips.dev)

4) “원장이 무한히 커지면 느려지지 않나?” — 커지지만, ‘느려지게’ 설계하진 않습니다

4-1. 데이터 증가는 ‘통제된 속도’로(난이도 조절 + 평균 10분)

비트코인은 블록 생성 주기를 평균적으로 10분으로 유지하려고 설계되어 있고, 난이도는 2,016블록마다(약 2주) 조절됩니다. (developer.bitcoin.org)

이 말은 인프라 관점에서 중요합니다.

• 원장(스토리지)은 누적된다
• 그러나 전파되는 트랜잭션/블록 메시지 크기는 프로토콜 제약(블록 용량/weight 등) 하에서 움직인다 (bips.dev)

4-2. “모든 노드가 다 저장하나?” → 역할이 갈립니다

• Full Node: 제네시스부터 전부 검증/저장(가장 독립적)
• Pruning Node: 검증은 하되 오래된 블록 데이터는 삭제(저장공간 절약)
• SPV(라이트) 노드: 헤더 중심으로 최소 검증(모바일 지갑 등)

(이 분화가 가능한 이유 자체가 “머클 트리/헤더 구조” 덕분입니다.)

4-3. 머클 트리: “전체를 들고 다니지 않고 포함 증명”

블록 헤더에는 머클 루트(Merkle Root)가 들어가고, 이를 통해 특정 트랜잭션이 블록에 포함됐는지 “효율적으로” 증명할 수 있습니다.

4-4. 전송 최적화: Compact Blocks(요약 전파)

노드가 블록을 전파할 때 “풀 데이터”만 뿌리면 대역폭이 터지죠. 그래서 Compact Block Relay(BIP152) 같은 최적화가 사용됩니다. (bips.dev)

5) 네트워크 엔지니어 관점 핵심: 비트코인은 “TCP 기반 P2P 가십 프로토콜”입니다

5-1. L4~L7 한 줄 요약

• L4: TCP
• 기본 포트: 8333(mainnet)
• 모델: 중앙 서버 없는 P2P, 새 소식(트랜잭션/블록)을 이웃에게 릴레이

5-2. 전파 플로우(가십의 정석): inv → getdata → tx(또는 block)

불필요한 대역폭을 줄이려고 “있냐/없냐” 확인 후 요청하는 구조로 갑니다.

1. inv: “나 새 트랜잭션/블록 ID 있어”
2. getdata: “그거 없으니 보내줘”
3. tx / block: 원본 데이터 전송

이 메시지 구조는 비트코인 P2P 문서에 정리돼 있습니다. (GitHub)

5-3. 패킷으로 보면(메시지 헤더 24바이트)

비트코인 P2P 메시지는 공통 헤더를 가지며, 여기엔 네트워크 식별용 값, 커맨드, 길이, 체크섬 등이 포함됩니다. (GitHub)

실무 팁 (Wireshark 관찰 포인트)

• TCP 세션 위에 “비트코인 애플리케이션 메시지”가 흐릅니다.
• version/verack로 애플리케이션 레벨 핸드셰이크를 합니다. (GitHub)

6) “그럼 방화벽에서 TCP 8333 막으면 끝?” — 불편할수는 있지만, ‘중단’은 불가능합니다

여기서부터가 비트코인의 “성격(내성)”이 드러나는 구간입니다.

6-1. 포트는 설정값입니다(바꿀 수 있어요)

8333은 기본값일 뿐, 운영자는 다른 포트로도 통신할 수 있습니다. (물론 생태계 표준 포트가 주는 연결성 이점은 줄어듭니다.)

6-2. DPI(심층 패킷 분석)로 식별? → v2 Transport(BIP324)로 난이도 상승

예전(v1) P2P는 관측/식별이 쉬운 편이었는데, BIP324(v2 transport)는 노드 간 통신에 기회적 암호화(opportunistic encryption)를 도입합니다. 그리고 Bitcoin Core 27.0에서 v2 transport가 기본 활성화로 들어갔습니다. (Bitcoin Core)

즉, “8333 포트 + 평문 패턴”만으로 트래픽을 규정하기가 점점 어려워집니다.

6-3. 결론적으로: ‘완전 차단’은 비용이 너무 큽니다

비트코인을 “기술적으로” 완전 차단하려면, 일반 인터넷 트래픽까지 함께 죽이는 수준(화이트리스트 폐쇄망)에 가까워져서 현실 비용이 커집니다. 그래서 실제로는 보통 거래소(현금화 경로) 규제가 더 강하게 작동합니다. (네트워크 자체를 끊는 것과 자산의 제도권 출입구를 통제하는 건 난이도가 다릅니다.)

7) 그래서 비트코인은 왜 “신뢰”를 만들 수 있나? (인프라적 결론)

비트코인의 신뢰는 “누가 서버를 운영하냐”가 아니라,

• 누구나 검증 가능한 서명(소유권 증명)
• 누구나 공유하는 장부(블록체인)
• 평균 10분 블록 + 2,016블록 단위 난이도 조절로 유지되는 합의 리듬

이 3개가 합쳐져서 만들어집니다. (developer.bitcoin.org)

[실무 팁] 직접 “네트워크 장비 감각”으로 확인해보는 체크리스트

A) 내 노드가 어떤 피어와 붙어있는지(운영 관점)

• bitcoin-cli getpeerinfo : 피어 IP/포트/지연/서비스 플래그/버전 등을 확인하는 데 자주 씁니다.

B) Wireshark에서 최소 관찰 필터 예시

tcp.port == 8333

tcp.port == 8333

C) NAT 뒤에 두면 생기는 현상(연결성 관점)

• Outbound는 잘 붙는데 Inbound가 잘 안 붙을 수 있어요.
• “내 노드가 다른 노드에게 더 잘 발견되게” 하려면 인바운드 포트를 열어야 하고, 그렇지 않으면 보통 “클라이언트형 노드”로 남습니다.

[결론] 3줄 요약

1. ECC는 분야, ECDSA는 그 분야의 ‘전자서명 도구’이고 비트코인은 서명으로 소유권을 증명해요.
2. 비트코인은 암호화(AES)가 목적이 아니라 공개 장부에서의 검증(서명+합의)가 목적이라 트랜잭션이 기본적으로 공개됩니다.
3. 통신은 TCP 기반 P2P 가십이며, BIP324(v2 전송 암호화) 같은 개선으로 “식별/차단” 난이도는 계속 올라가는 방향입니다. (Bitcoin Core)