[Feature request] Cap "select all" coin selection at 256 inputs (the per-transaction maximum)
@ardier16 已经在做这个了。
开始于 2026年10月13日。
评估
调研方向
Start by locating the Android send flow’s coin control screen and the code that handles “Select all” for manually selected UTXOs. Trace how that selection reaches transaction building, and check whether an existing coin selection rule sets the input order or limit. Done means selection is capped at 256, the UI reports how many remain, and the large manual selection failure is investigated.
由索引模型根据 Issue 内容生成。
描述
Title: Cap "select all" coin selection at 256 inputs (the per-transaction maximum)
Description
When a wallet has more than 256 UTXOs, the "select all" option in manual coin control currently tries to include every input. Since a single transaction supports at most 256 inputs, this results in an invalid or failing transaction rather than a usable one.
Expected behaviour
"Select all" should select the top 256 UTXOs (e.g. largest-value first, or whatever ordering coin selection already uses), filling the transaction to its maximum input count instead of exceeding it. The UI should make it clear that the selection has been capped and how many UTXOs remain unselected.
Current behaviour
All UTXOs are selected regardless of count, so wallets with >256 UTXOs cannot use "select all" to build a valid transaction.
Steps to reproduce
- Use a wallet (mainnet, testnet, or Liquid) holding more than 256 UTXOs.
- Open Send → coin control / manual UTXO selection.
- Tap "Select all".
- Attempt to build or sign the transaction.
Proposed solution
- Change "Select all" to select
min(total_utxos, 256)inputs, ordered by value descending (or by the existing coin-selection heuristic). - Show a notice such as "256 of N UTXOs selected (transaction limit)".
- Optionally offer a "Select next 256" action so users can consolidate large UTXO sets across several transactions.
Related: sending 255 manually selected inputs fails
Even staying under the limit, building a transaction with 255 manually selected UTXOs fails with:
Made one or multiple attempts, all errored:
- EOF while parsing a value at line 1 column 0
This looks like a serde_json error from GDK receiving an empty response from a backend call (fee estimation, UTXO fetch, or broadcast) rather than a transaction-construction error. Possibly a request timeout or payload size limit when the input set is large.
Steps to reproduce
- Open Send → coin control.
- Manually select 255 UTXOs.
- Enter a recipient and amount, continue to review/sign.
- Error above is shown; the transaction is never built.
Questions for maintainers
- Is there a practical input limit below 256 that the app enforces or should enforce?
- Does the same happen with a smaller selection (e.g. 100 inputs)? (fill in if you've tested)
- 主要语言
- Kotlin
- 星标
- 273
- 派生
- 111
- PR 合并指标
- 30 天内没有已合并 PR
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
Blockstream/green_android 的其他 Issue
-
难度 1/5 1 小时以内 新手友好度 88/100
Blockstream/green_android#313 ·
-
"UniFFI API checksum mismatch" in LWK bindings on armeabi-v7a可能已有人在做 @ardier16 于 1 天前认领。 未关闭bug status: confirmed
Blockstream/green_android#317 · 3 条评论 · 已指派 1 人 ·
-
难度 3/5 1-2 天 新手友好度 76/100
Blockstream/green_android#315 ·
-
难度 4/5 3-5 天 新手友好度 55/100
Blockstream/green_android#314 ·
-
Support scanning SeedQR recovery phrases可能重新可做 @ardier16 于 54 天前认领，目前没有进行中的 PR。 未关闭feature request
Blockstream/green_android#311 · 2 条评论 · 已指派 1 人 ·
查看 Blockstream/green_android 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 68/100
维护者通常 1 天内回复
-
good first issue help wanted
难度 2/5 1-3 小时 新手友好度 66/100
dafonton77-tech/Cadreenf#11 ·
-
难度 2/5 1-3 小时 新手友好度 80/100
Hy4ri/hermes-mobile#1647 ·
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 67/100
rawnaldclark/Stash#649 ·
维护者通常 1 天内回复
-
documentation
难度 2/5 1-3 小时 新手友好度 79/100
维护者通常 1 天内回复