bitcoin send and tx sign page

[piatoss3612]

1. �background

• keyring 관련: 서명이 필요한 input에만 서명할 수 있게 input의 인덱스 값이 들어간 inputsToSign 배열을 넘겨주도록 수정
• tx: 인덱서 요청을 통해 트랜잭션을 전송하기 위한 PushBitcoinTransactionMsg 추가

2. stores-bitcoin

• account
  • tx size estimation, utxo selection, psbt build, psbt sign 기능
  • utxo selection 로직은 branch and bound(bitcoin core에서 사용하는) 또는 greedy algorithm을 사용
• queries
  • balance: confirmed utxos의 합을 사용하도록 변경
  • address txs: 주어진 주소의 트랜잭션 히스토리를 가져오는 쿼리
  • fee estimates: 수수료 비율 (sat/vBytes) 값을 가져오는 쿼리. 응답값의 각 키 값은 트랜잭션이 컨펌되는 예상 블록 수.
  • tx: txid로 트랜잭션 상세 정보를 가져오는 쿼리. legacy 주소의 input을 사용할 때 nonWitnessUtxo 필드에 rawTxHex 값을 넣어줘야 돼서 추가해 놓았는데 쓸일은 없을 것 같습니다.
  • utxos: utxo 목록을 가져오는 쿼리. 현재 인덱서에서 파이지네이션을 지원하지 않아서 1000개를 초과한 utxo를 가진 계정은 오류가 반환되는 문제가 있습니다. 그러나 1000개 이상 utxo를 가지고 있는 계정은 일반적으로 인스크립션 찍어내는 공장용 계정이라 크게 문제될 부분은 없어보입니다.

3. hooks-bitcoin

• send config를 sender, recipient, amount, fee rate, tx size, fee로 분리
• fee rate는 인덱서의 fee estimate 쿼리를 통해 가져온 값 또는 사용자 정의 값을 입력가능
• tx size는 psbt simulator에서 시뮬레이션을 통해 utxo 조합을 생성하고 이 과정에서 추정된 트랜잭션의 vBytes 크기를 설정

fee는 fee rate (sat/vBytes) * vBytes로 계산됩니다.

4. extension/hooks/bitcoin

• 사용가능한 utxo를 가져오는 훅, 서명하기 전에 psbt의 유효성을 검증하는 훅 등을 별도의 파일로 분리했습니다.
• 비트코인을 블록 타임이 길기 때문에 값이 변경될 때마다 psbt simulator 함수 안에서 utxo 리스트를 불러오는 것이 불필요하다고 생각하여 분리했습니다.

5. extension/bitcoin/send

• fee modal에서 fee rate를 선택할 수 있도록 추가
• psbt simulator를 주기적으로 refresh하는 대신, simulation key를 구성할 때 변경되는 값에 반응하여 새로 시뮬레이션이 실행되도록 추가
• 한 번 시뮬레이션을 통해 생성된 최적의 utxo 조합 및 psbt는 시뮬레이션이 다시 실행되었을 때 새로 구성하는 것이 불필요하므로 상태에 저장해 뒀다가 next 버튼을 눌렀을 때에도 가져와서 바로 사용할 수 있도록 추가
• 이로 인해 next 버튼을 누르면 화면 전환이 너무 빨라서, 사용자가 실수로 approve 버튼을 누를 수 있으므로 1초 간의 딜레이 추가

6. extension/bitcoin/tx-sign

• fee option을 조정하게 되면 output의 합 + 수수료를 만족시키는 utxo 조합을 새로 생성해야 하는 문제가 있으므로 summary만 보여주도록 추가
• 서명할 데이터를 보여주는 컴포넌트 임시로 추가

7. 미구현 목록

• hooks-bitcoin: amount가 dust인 경우 오류를 반환하도록 추가 필요
• send page: bitcoin address book modal
• tx sign page: 디자인 변경 필요

8. 논의가 필요한 사항

1. 일반적인 balance와 send 기능을 실행할 때의 available balance
   • 현재 일반적인 자산 view에서 보여지는 balance는 confirmed utxo의 합으로 보여주고 있습니다.
   • available balance는 위의 balance에서 inscriptions, runes 등을 제외한 순수하게 utxo만으로 사용할 수 있는 utxo의 합입니다.
   • 이 두 값을 혼용해서 사용을 할지, 하나의 값만 사용할지 (이 경우는 available balance)
   • 일반적으로 inscription utxo에는 dust threshold(546)를 값으로 가지고 있는데, 상당한 액수를 가지고 있는 경우도 종종 있어서 send page에서만 available balance를 사용하는 방식에 대해 고민해 보았습니다.
2. 다중 서명이 필요한 경우에 대한 처리
   • 현재 구현은 input script를 파싱하여 나온 주소가 keyring의 pubkey에서 생성되는 주소들과 매칭되는지 확인하고, 매칭되는 input만 서명하도록 구현해 놓았습니다.
   • 그러나 외부에서 요청이 들어오는 경우에는 다중 서명 스크립트가 주어지고, 거기에 부분적으로 서명을 해야하는 경우가 있을 수 있습니다.
   • 그런데 다른 지갑들도 다중 서명 케이스에 대해 별다른 처리는 없는 것 같습니다.
   • onekey의 경우는 isBtcWalletProvider true일 때 외부에서 요청들어온 것을 처리하는 줄 알았는데, 내부적으로 babylon staking 기능을 구현해놓아서 babylon staking 요청이 들어오면 모두 서명하도록 이렇게 구현해 놓았습니다.
3. bip32 derived publickey 처리
   • publickey만 사용해서 bip32 경로를 추가하여 새로운 publickey를 만들 수 있기 때문에
   • 서명이 필요한 input을 확인할 때 input 데이터에 들어있는 bip32Derivation 또는 tapBip32Derivation 필드를 확인하고 경로를 적용한 주소를 생성하여 매칭해보는 것이 필요할지

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
keplr-wallet-extension	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 7, 2025 11:13am