비트코인 p2p를 하거나, 거래소에서 개인지갑으로 옮기는 등, 트랜잭션 데이터를 확인할때 우리는 멤풀을 확인한다.
멤풀이 자세히 무엇인지 알아보자
멤풀이란? 멤풀의 역할
멤풀이란, 새로운 트랜잭션이 제출되었을 때 대기타는 공간이다.
새로 채굴되기를 기다리는 공간으로, 채굴노드는 여기서 수수료가 높은 트랜잭션을 차곡차곡 쌓아서 새로운 블록을 구상한다.

아직 컨펌되지 않은 트랜잭션들이 모여있는 공간인 만큼, 멤풀에 들어오고 나가는 조건이 꽤 까다롭다.
비트코인은 UTXO모델이기 때문에, 위 그림처럼 하나의 UTXO 에서 동시에 비트코인을 사용하려고 하면 막는다.
(1BTC가 존재하는 UTXO에서 0.1BTC를 보내면 나머지 0.9BTC는 다시 내 주소에 보내는 트랜잭션이 되기 때문에 하나의 UTXO가 여러 트랜잭션에서 사용될 수 없다.) 즉, 이는 이중 지불 시도가 되는 것이고 소스코드로 막아두었다.
// validation.cpp 818 번 라인
// Check for conflicts with in-memory transactions
for (const CTxIn &txin : tx.vin)
{
const CTransaction* ptxConflicting = m_pool.GetConflictTx(txin.prevout);
if (ptxConflicting) {
if (!args.m_allow_replacement) {
// Transaction conflicts with a mempool tx, but we're not allowing replacements in this context.
return state.Invalid(TxValidationResult::TX_MEMPOOL_POLICY, "bip125-replacement-disallowed");
}
// RBF가 허용된다면 나중에 사용하기 위해서 충돌 리스트에 추가,
// 나중에 해당 트랜잭션을 더 검사하기 위해 일단 리스트에 추가만,,,
ws.m_conflicts.insert(ptxConflicting->GetHash());
}
}
그런데 위 그림을 보면 자주색 Transaction A와 초록색 Transaction B가 다른 노드로부터 시작되어 전파되고 있다.
이는 논리구조상 가능하다. 왜냐하면 개별 노드 입장에서는 각각이 원본이고, 다른 트랜잭션을 전달받으면 해당 트랜잭션이 이중지불 시도가 되기 때문이다.
멤풀은 이처럼 같은 UTXO에서 다른 트랜잭션을 만들어서 이중지불 하려는 시도를 걸러낸다.

그 뒤, 하나의 트랜잭션이 먼저 채굴되면, 해당 UTXO가 confirmed 되고, 나머지 이중지불 시도 트랜잭션은 멤풀에서 삭제된다.
멤풀에 언제 들어가고? 언제 나가나?
기본적으로 내가 비트코인을 소비하기 위한 트랜잭션을 제출하면 내 노드에 들어가고, 다른 노드에 전파된다.
내 노드가 없다면, 해당 지갑과 연동된 풀노드에서 전파한다.
동일하게 다른 노드에서 전달받을 수 있다. 그러면 내 노드는 이를 검증하고 멤풀에 넣을지 말지 결정한다.
앞서 말한 중복 UXTO 소비같은것을 검증한다.
2025.12.19 - [분류 전체보기] - 비트코인이 동시에 채굴된다면? - chain reorg
비트코인이 동시에 채굴된다면? - chain reorg
2025.12.08 - [분류 전체보기] - 비트코인 채굴과 작업증명과(PoW) 비트코인 채굴과 작업증명과(PoW)가끔 뉴스를 보다보면 비트코인 솔로 채굴에 성공하여 3BTC 가량을 독식했다며 부러움을 자아낸다. (
3min-bitcoin.tistory.com
또 다른 경우는, 이미 블록에 포함되어 멤풀에서 제거되었는데, Stale Block 으로 판명되어 해당 트랜잭션이 다시 멤풀로 되돌아오는 경우가 있다.
반대로 퇴출되는 경우는, 해당 트랜잭션이 포함된 블록이 채굴된 경우다.
혹은, 채굴이 되었다는 정보를 다른 노드로부터 받은 경우다.
또한 위 그림처럼 초록색 트랜잭션 B가 먼저 채굴되어 왼쪽 노드들의 자주색 트랜잭션 A가 conflict를 일으키는 경우 퇴출된다.

// mempool_options.h 18번째 라인
/** Default for -maxmempool, maximum megabytes of mempool memory usage */
static constexpr unsigned int DEFAULT_MAX_MEMPOOL_SIZE_MB{300};
/** Default for -maxmempool when blocksonly is set */
static constexpr unsigned int DEFAULT_BLOCKSONLY_MAX_MEMPOOL_SIZE_MB{5};
/** Default for -mempoolexpiry, expiration time for mempool transactions in hours */
static constexpr unsigned int DEFAULT_MEMPOOL_EXPIRY_HOURS{336};
멤풀에는 유효기간이 있다. 노드는 기본설정으로 트랜잭션을 최대 2주간 담도록 정책이 되어있다. 따라서 2주가 넘으면 퇴출된다.
그리고, 멤풀의 전체 사이즈 리밋이 있는데, 이 단위를 넘어서면 가장 수수료가 적은 트랜잭션부터 퇴출된다.

이 설정들은 내 노드 Settings에서 변경할 수 있다.
마지막으로 RBF로 인해 더 높은 수수료의 트랜잭션으로 교체될 수 있다. (이는 다른 포스트에서 더 자세히 다루겠음)
멤풀에 대해서 간단한 내용들을 다뤄봤다.
나중에 내 노드의 멤풀 설정들을 더 자세히 포스팅 할 예정 !! 😃
참고문헌
https://learnmeabitcoin.com/technical/mining/memory-pool/
Memory Pool | Waiting Area for Transactions
Memory Pool Waiting area for transactions Current Mempool Size: 37,104 transactions Note: This is the size of the mempool for my local node. The size of your memory pool will differ depending on how long your node has been online and which nodes you are co
learnmeabitcoin.com