UTXO（Unspent Transaction Output），翻译过来就叫未花费的交易输出。
UTXO是比特币的账户模型，与以太坊的账户余额模型形成鲜明对比。
在比特币系统中，用户的比特币不是集中存储在一个账户中，而是分散在多个UTXO中，每个UTXO都代表一定数量的比特币。我私下把UTXO理解成装在存钱罐里的硬币，要花10块钱的时候，就去找10个散装硬币。
双花攻击是电子货币系统面临的核心问题，即同一笔资金被重复使用。比特币通过UTXO模型巧妙解决了这一问题：
UTXO模型通过密码学机制确保只有合法所有者才能花费比特币:
1. 交易创建过程：
2. 支配权验证流程：
用户用私钥生成签名，将签名和公钥放入输入脚本
输出脚本包含接收方的公钥哈希
交易输出会包含一个脚本，这个脚本说 “这个输出谁能拿出一个签名和接收方的公钥地址匹配上，就支付给谁”。
交易验证通过脚本执行实现
3. 脚本执行过程（基于比特币的栈式虚拟机）：
输入脚本：
OP_PUSHDATA(Sig) // 推送有权花费这笔UTXO的用户的私钥签名
OP_PUSHDATA(PubKey) // 推送有权花费这笔UTXO的用户的公钥
输出脚本：
OP_DUP // 复制有权花费这笔UTXO的用户的公钥（复制栈顶元素）
OP_HASH160 // 对以上公钥进行哈希（弹出栈顶元素，对公钥进行哈希运算，再压入栈顶）
OP_PUSHDATA(PubKeyHash) // 压入输出脚本中的收款方的公钥哈希
OP_EQUALVERIFY // 弹出栈顶的两个元素，比较是否相等，目的是防止有人冒名顶替收款方
OP_CHECKSIG // 弹出栈顶的两个元素，用公钥检查签名是否正确，到此验完有权花费这笔UTXO的用户身份
如果整个脚本执行过程没有错误，且最终栈顶为真值，则验证通过，交易有效。
当用户发送比特币时：
输入选择： 钱包选择一个或多个UTXO作为交易输入
找零处理： 如果选定的UTXO总额超过需支付金额，会创建一个"找零"输出，返回给发送者
**新UTXO生成：**交易完成后，原UTXO被标记为已花费，同时生成新的UTXO（包括接收方的和找零的）
举例说明：
假设Alice有3个UTXO（价值分别为2、3和5 BTC），她想向Bob发送4 BTC：
Alice的钱包选择2和3的UTXO作为输入（总计5 BTC）
创建两个输出：一个给Bob（4 BTC），一个找零给Alice自己（1 BTC，减去交易费）注意：矿工费并不作为输出，而是使用输入总额-输出总额的差额作为矿工费。
用私钥签名交易
交易广播后，原来的两个UTXO被消费，网络中产生两个新UTXO
附比特币的交易结构：
{
"txid": "921af728159e3019c18bbe0de9c70aa563ad27f3f562294d993a208d4fcfdd24", // 交易哈希：全网唯一
"size": 226, // 交易数据的大小：以字节为单位
"version": 1, // 交易的版本号
"locktime": 0, // 交易的锁定时间：0表示无锁定，立即生效
"fee": 29040, // 矿工费：以聪（satoshis）为单位
"inputs": [
{
"coinbase": false, // 来源类型：这笔BTC是否为挖矿所得，true-是，false-否
"txid": "c0cb92ca8e41070233bf965d808b0fc4bac144dab05690b17823fac3e184c57b", // 交易哈希：这笔输入来自哪笔交易哈希
"output": 0, // 输出序号：这笔输入来自哪笔交易哈希的第几笔输出
"sigscript": "483045022100928496fb0d2a25e4e7c99b9c60d4d0d12fcf8974a0faffcb30119b0d385872a30220253d3d0c507e5e44e123bc28b795ab4a38bf3b205455403e77aa72d58d9e17110121022ef8d3a6dd8a7039e513acc8ecf9b094ed7e85439824a1d11920f85927cd0018", // 签名脚本：解锁这个输入所需的脚本
"sequence": 4294967295, // 序列号：用于支持替换费率（RBF）功能，通常设置为最大值表示不使用RBF。 sequence < 0xFFFFFFFF-1 = 4,294,967,295 时，表示这笔交易如果未确认时，支持替换，以便加快打包速度
"pkscript": "76a914e1a8cdae6411b17ee1d4cecfe47bafce37e14d1488ac", // 公钥脚本：锁定该输入的脚本
"value": 76469684, // 输入金额：该输入的比特币金额，以聪为单位
"address": "1MaBFqBEfcQyXPv3fm5WAW9aQuJuKHaA3A", // 输入地址：花这笔BTC的人的钱包地址
"witness": [] // 见证数据：用于SegWit交易的额外数据
}
],
"outputs": [
{
"address": "19z8LJkNXLrTv2QK5jgTncJCGUEEfpQvSr", // 输出地址：接收方的钱包地址
"pkscript": "76a914628ed6567c0b9056067309f07bbea2992ecad74388ac", // 公钥脚本：锁定该输出的脚本
"value": 22684000, // 输出金额：该输出的比特币金额，以聪为单位
"spent": true, // 是否已花费：表示该输出是否已被使用
"spender": {
"txid": "437f8e2d8b33dc46f73e8d57be5fc739c5a70d2dc02e1326a6a530adf4c3c57b", // 使用该输出的交易哈希：花费这个输出的交易ID
"input": 0 // 使用该输出的输入索引：花费这个输出的输入索引
}
},
{
"address": "1LvGTpdyeVLcLCDK2m9f7Pbh7zwhs7NYhX", // 输出地址：接收方的钱包地址
"pkscript": "76a914da7d57dfd02c6f5a9c649e891b5ac199ad012cd288ac", // 公钥脚本：锁定该输出的脚本
"value": 53756644, // 输出金额：该输出的比特币金额，以聪为单位
"spent": true, // 是否已花费：表示该输出是否已被使用
"spender": {
"txid": "a9fcce7933c672b058a4c9534ca1e975db002f85d19ef7124356e7285c48c428", // 使用该输出的交易哈希：花费这个输出的交易ID
"input": 0 // 使用该输出的输入索引：花费这个输出的输入索引
}
}
],
"block": {
"height": 530657, // 区块高度
"position": 25 // 交易位置：该交易在区块中的位置
},
"deleted": false, // 是否已删除：表示交易是否已被删除或取消
"time": 1530846727, // 交易时间：UNIX时间戳，表示交易被包含进区块的时间
"rbf": false, // 替换费率（RBF）：表示该交易是否支持替换费率功能
"weight": 904 // 交易权重：用于计算交易的相对成本，考虑了SegWit优化
}
以上矿工费 = 76469684 - 22684000 - 53756644 = 29040，与fee字段值一致。
安全性： 通过密码学确保只有拥有私钥的用户才能花费UTXO
隐私性： 可以每次交易使用新地址，增强隐私保护
并行处理： 不同UTXO的交易可以并行验证，提高网络吞吐量
状态简化： 只需维护未花费交易集合，而非全部交易历史
复杂的脚本支持有限： 相比以太坊，比特币脚本功能较为有限
碎片化： 长期使用会产生大量小额UTXO，增加交易费用
应用开发难度高： 相比账户模型，基于UTXO构建应用更复杂
基于全文检索与主题相似度
结论 先说结论：理论上能攻破，但实际上不可能发生。 为什么？ 因为设计者中本聪在设计之初就考虑到了量子计算的威胁，巧妙地为其准备了3个锦囊（安全防线）：隐身术、闪电战、终极进化。只需在不同时期按顺序掏出这些锦囊，比特币就能逢凶化吉。 这3个锦囊到底是什么东东，为何如此强大？简单解释一下： - 隐身术
一个不愿提及的教训 2021年的一天，我丢失了价值约¥2W的数字货币。这源于一个愚蠢的操作，至今记忆犹新。回顾起来，这是在HD Wallet理解上交的一笔“学费”。 事情是这样的：我用一个测试钱包接收了一笔USDT，这个钱包的助记词曾在我的博客文章（如何使用MetaMask）中公开过。我知道这个助记
说在前面 作为一个在区块链搬砖多年的开发者，我发现共识机制是面试中最常被问到的技术问题之一。 今天，我想梳理一下6种主流共识机制，为我也为你在面对相关问题时能够准确、专业地回答。 共识机制解决的核心问题 在分布式网络中，节点之间如何在没有中心权威的情况下对某个值或状态达成一致？这就是共识机制要解决的