LND 钱包的日常出口是 sendcoins：v0.19.0-beta 源码 cmd/commands/commands.go 里它归类在 On-chain，Usage 一句话——“链上发送比特币到某个地址”，参数形态 addr amt，金额单位聪，地址接受 base58 或 bech32 编码。命令平平无奇，但它身上挂着闪电钱包特有的几个设计决定，值得逐个拆开——尤其是那个叫 sweepall 的开关。
费率与选币的旋钮
conf_target 按目标确认块数向费率估算器要价，sat_per_vbyte 直接按聪每虚拟字节手动定价，两者都可选，都不给就走 lnd.conf 的全局估算配置；历史遗留的 sat_per_byte 已弃用并隐藏。min_confs 给自动选币设确认数下限，源码里的默认值是 1——刚收到、还没拿到任何确认的零钱默认不在选币射程内。utxo 参数可以重复给出 txid:index 形态的币，把输入锁死在你指定的集合上。force 的语义藏着一个脚本友好设计：设置后跳过发送前确认直接广播，而且当标准输出不是终端时它默认就为真——防止旧脚本在管道里卡死等回车。源码注释还提醒一句：位置参数与长选项可以互换但不能混用。
sweepall：把钱包一次搬空
sweepall 置位时 amt 必须留空，语义是让钱包把全部输出（或 utxo 指定集合里的全部资金）扫进目标地址——不留找零。这是闪电场景下它区别于普通 bitcoin-cli 的关键能力：链上余额长期是闪电通道的零钱抽屉，开道退道之后散落一地碎币，定期归集是节点运维的固定节目。配合 utxo，它还能做定向清扫：只处理你挑中的那几枚，其余保持原样。
扫空交易的结构因此有特点：所有可用输入进、唯一输出出，金额等于输入总和减去费用，天然没有找零项——这也是它比普通转账更省体积、但输入集合更不可控的原因。碎币多到一定数量时，一笔扫空交易可能撞上传输或标准性限制，这时分批执行反而稳。
与 sendcoins 名字相近的分界
sendcoins 只管链上：钱从 LND 内置钱包到某个链上地址，一步到位，闪电通道资金不在它的射程。通道余额要回链上走的是关通道或 splicing 提取，那是另一套流程；闪电付款用 sendpayment。很多人把”闪电里还有钱”和”钱包里还有钱”混成一句话向 AI 助手求助，第一个该跑的命令其实是 walletbalance——它先告诉你链上钱包到底有没有可扫的东西。
三条实操纪律
第一，永远先 walletbalance 再 sendcoins，确认目标金额不超过可支配的确认余额，避免交易造不出来时对着”insufficient balance”猜原因。第二，批量脚本里慎用默认的非终端 force 行为——在 cron 或 CI 里，这条命令不打招呼就花钱，这正是它的”特性”；需要人审的场合显式管理这个默认。第三，sweepall 前想清楚归集目的地：一次扫空会把散碎币合成单枚大额 UTXO，隐私画像也随之合并，目标地址选新地址还是老地址，是归集前唯一的隐私决策点。
一次安全的演练脚本
在 signet 或测试钱包上按顺序走一遍：walletbalance 看清可确认余额；随手收两笔不同确认数的小额，体会 min_confs 默认 1 时哪笔会被自动选中；跑 sendcoins 给固定地址转一个小额，观察返回 txid；再故意用 min_confs 拉高到确认数之上重发一次同额请求，看它如何报余额不足——这一次失败比十次成功更能说明选币规则。最后测 sweepall：指定 utxo 只收两枚币，用链上浏览器核对输出是否恰好等于两枚输入减费用、有没有多出找零项。四轮下来，命令的每个默认值都变成了自己的经验，而不是文档里的别人的经验。
最后提醒一个概念分层：sendcoins 与 sweepall 操作的始终是 LND 内置钱包的链上部分，和通道里的资金是两套账本——通道余额要靠关闭通道或正常收付款才回到链上，sendcoins 再怎么写参数也够不到。理解了这个分层，链上余额、通道余额、可动余额三个数字在 walletbalance 与 balance 里的差异就不再需要每次都翻文档确认。
风险提示：本文描述钱包命令的机制与默认值，不构成任何投资建议；涉及真实资金的发送请小额验证后再批量执行，并核对地址与网络一致性。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。