区块链DeFi金融科技【免费下载链接】bisqA decentralized bitcoin exchange network项目地址https://gitcode.com/gh_mirrors/bi/bisq点击查看免费下载导读Bisq 1.10.3 是一个以安全加固为核心的发布版本重点围绕过滤器Filter信任边界、交易状态机防护、存款/延迟赔付交易绑定以及支持与争议消息认证四条主线收紧安全策略。本文以 release-notes/1.10.3/notable-changes.md 为主体结合仓库源码逐项还原每项变更的实现细节与影响面。读完本文你将掌握未签名过滤器字段为何被禁用、Core API 如何阻止失败交易被推进、存款与延迟赔付交易的绑定校验如何防止伪造交易注入以及支持/争议消息如何校验发送者身份并了解对应的回归测试覆盖。一、版本概览与兼容性说明1.10.3 全量提交范围从358b546526到292f438112共 10 个提交7 个普通提交、3 个合并提交涉及 27 个文件。官方完整记录见 release-notes/1.10.3/full-release-notes.md。对用户与运营方operator而言本版本的兼容性要点集中在以下几条应用与打包版本号提升为1.10.3最终 tagv1.10.3内含后续的安全加固提交见 release-notes/1.10.3/notable-changes.md 的 Release Version 一节。过滤器提供的 BTC 节点与种子节点字段被禁用后续章节详述。Core API 拒绝为已失败交易确认已开始支付。存款交易与延迟赔付交易在处理前执行更严格的绑定校验。交易聊天、ACK、争议开启、对端开启争议与争议结果消息在发送者签名公钥不匹配期望的交易对手或争议代理时被直接忽略。由于这是一次安全加固发布官方建议依赖过滤器、API 交易控制或争议消息处理路径的节点运营方及时升级。二、未签名过滤器字段禁用filterProvidedBtcNodes与filterProvidedSeedNodes2.1 背景过滤器签名覆盖范围Bisq 的网络过滤器Filter由受信任开发者私钥签名后经 P2P 网络分发客户端通过校验签名来决定是否应用。问题在于Filter数据模型中addedBtcNodes与addedSeedNodes两个字段并未被当前过滤器签名所覆盖参见 core/src/main/java/bisq/core/filter/Filter.java 中addedBtcNodes、addedSeedNodes字段定义及其序列化/反序列化逻辑。这意味着攻击者一旦能伪造一份不带这些字段签名的过滤器载荷理论上可诱导客户端把任意的 BTC 节点或种子节点当作受信任节点接入从而发起中间人MITM等攻击。2.2 实现变更1.10.3 的处理策略是双管齐下不再持久化/应用FilterManager收到来自网络的新过滤器时不再将getAddedBtcNodes()/getAddedSeedNodes()写回配置文件saveBannedNodes调用链见 core/src/main/java/bisq/core/filter/FilterManager.java。同时节点选择逻辑中这部分来源被置空。启动时忽略历史残留此前版本可能已把这两个值持久化到配置文件中1.10.3 的Config解析层直接忽略filterProvidedBtcNodes/filterProvidedSeedNodes两个命令行选项的取值选项定义见 common/src/main/java/bisq/common/config/Config.java防止陈旧残留值在启动时被重新应用。2.3 源码验证在 core/src/main/java/bisq/core/btc/nodes/BtcNodesSetupPreferences.java 的selectPreferredNodes方法中PROVIDED模式下构造候选 BTC 节点流时filterProvidedBtcNodes来源仅在--ignoreNetworkFilter未开启时才被读取StreamString filterProvidedBtcNodes config.ignoreNetworkFilter ? Stream.empty() : config.filterProvidedBtcNodes.stream();最终由FederatedBtcNodeProvider.getNodes(...)将硬编码节点与过滤来源合并见 core/src/main/java/bisq/core/btc/nodes/FederatedBtcNodeProvider.java。种子节点侧同理core/src/main/java/bisq/core/network/p2p/seed/DefaultSeedNodeRepository.java 只在非ignoreNetworkFilter时才把config.filterProvidedSeedNodes加入种子节点缓存。回归测试 core/src/test/java/bisq/core/filter/FilterManagerInitializationTests.java 验证了启动时配置文件中残留的filterProvidedBtcNodes、filterProvidedSeedNodes会被清理而无关的otherOptionkeep得以保留。2.4 对运营方的影响若你的配置文件或启动参数中显式设置了--filterProvidedBtcNodes/--filterProvidedSeedNodes1.10.3 将忽略这些值——这是预期行为并非配置错误。官方说明该处理是临时性的在新的过滤器实现覆盖这些字段签名可用之前一律按不安全处理相关值作为空值写入/应用。三、BTC 费用接收地址过滤器条目临时禁用3.1 变更内容过滤器字段btcFeeReceiverAddresses提供的地址被临时从 mempool 服务的 BTC 费用接收地址列表中排除。该路径当前并未被积极使用预计将由新的过滤器实现接管。DAO 捐赠地址与 Burning Man焚烧人接收地址不受影响继续留在列表中。3.2 源码现状Mempool 服务在构造全部 BTC 费用接收者列表时见 core/src/main/java/bisq/core/provider/mempool/MempoolService.java 的getAllBtcFeeReceivers()列表来源包括daoFacade.getAllDonationAddresses()—— DAO 补偿请求等捐赠地址Burning Man 地址列表的 legacy 地址过滤器提供的btcFeeReceiverAddressesBtcFeeReceiverService.getConfiguredReceiverAddresses(...)见 core/src/main/java/bisq/core/dao/burningman/BtcFeeReceiverService.java历史上曾销毁 BSQ 的 Burning Man 候选人的所有地址。也就是说过滤器条目在代码路径上依然被读取解析parseBtcFeeReceiverAddresses对非法配置会回退到仅 Burning Man 配置FeeReceiverConfig.forBurningManOnly()但 1.10.3 官方说明强调其临时排除意图是等待新过滤器实现重新接管该路径。阅读此部分源码时应以本版本发布说明为准理解该字段的实际生效状态。3.3 相关测试core/src/test/java/bisq/core/provider/mempool/MempoolServiceTest.java 覆盖费用接收地址列表构造行为core/src/test/java/bisq/core/dao/burningman/BtcFeeReceiverServiceTest.java 覆盖接收地址解析与合法校验。四、失败交易 API 防护Failed Trade API Guard4.1 问题场景Core API 允许客户端如bisq-cli通过confirmPaymentStarted方法确认买家已开始支付从而驱动交易沿买家协议路径前进。若交易已失败failed仍允许推进该状态机不仅违反协议语义还可能导致资金路径异常。4.2 实现在 core/src/main/java/bisq/core/api/CoreTradesService.java 的confirmPaymentStarted(String tradeId, ...)方法中首先检查是否按买家协议跟进isFollowingBuyerProtocol随后if (trade.hasFailed()) { throw new FailedPreconditionException(Cannot confirm payment started for a failed trade.); }同时该方法还保留了两道前置约束交易存款交易必须已确认trade.isDepositConfirmed()否则报错提示需等 deposit tx 确认合约与卖方支付账户载荷sellerPaymentAccountPayload必须已收到否则报错提示未收到卖方支付账户详情——桌面客户端禁用确认按钮采用同一条件。这样即使 API 客户端误调或恶意调用失败交易也无法再沿买家协议路径前进。五、存款与延迟赔付交易绑定加固这一节对应提交7e7e4ed905Harden deposit transaction and delayed payout transaction binding是 1.10.3 最核心的协议层加固之一。5.1 买家侧校验对方存款交易必须与本地一致买家处理DepositTxAndDelayedPayoutTxMessage时见 core/src/main/java/bisq/core/trade/protocol/bisq_v1/tasks/buyer/BuyerProcessDepositTxAndDelayedPayoutTxMessage.java执行以下绑定检查后再触碰钱包或交易状态本地存款交易获取作为 taker 时直接使用已设置的processModel.getDepositTx()作为BuyerAsMakerTrade时因为 maker 尚未设置存款交易使用processModel.getPreparedDepositTx()预构建的存款交易。延迟赔付交易字节一致性要求对方发来的 DPT 序列化字节与本地trade.getDelayedPayoutTxBytes()完全一致否则checkArgument直接失败。规范字段校验对对方存款交易调用checkCanonicalDepositTxFields见 core/src/main/java/bisq/core/trade/validation/DepositTxValidation.java。DPT 输入绑定调用DelayedPayoutTxValidation.checkDelayedPayoutTxInput(...)验证 DPT 的输入确实指向该存款交易。本地比对通过checkDepositTxMatchesIgnoringWitnessesAndScriptSigs忽略 witness 与 scriptSig 后比对对方存款交易与本地存款交易防止收到一份序列化合法但绑定到不同交易的存款。5.2 DPT 输入必须花费存款交易 output 0core/src/main/java/bisq/core/trade/validation/DelayedPayoutTxValidation.java 的checkDelayedPayoutTxInput严格校验DPT 输入数量必须为 1该输入的outpoint.getHash()必须等于存款交易的txId且outpoint.getIndex() 0校验失败时抛出Input of delayed payout transaction does not point to output 0 of deposit tx。这防止了攻击者提交一份序列化正确但绑定到另一笔存款交易的 DPT。同一文件中的checkLegacyDelayedPayoutTxOutput还校验 DPT 输出数量为 1、金额等于买家保证金 卖家保证金 交易金额之和。5.3 过期存款确认回调不再推进交易1.10.3 将存款确认回调绑定到其注册时的交易 ID如果一笔过期的回调stale callback在交易当前存款交易已变化后触发该回调会被忽略而不是把交易误标记为存款已确认。这一改动堵住了状态机在交易迁移期间被旧回调提前推进的窗口。5.4 存款交易监听器要求独立的 maker-fee 与 taker-fee 输入旧实现只统计输入父交易 ID 命中两个费用交易 ID 的数量count 2存在一个攻击面恶意 seller-as-maker 可以用自己 maker 费用交易的不同输出费用输出、reserved-for-trade 输出、找零输出构造两笔输入从而在计数检查中伪造一笔从未被 taker 共同注资的假存款交易。加固后的isConfTxDepositTx见 core/src/main/java/bisq/core/trade/protocol/bisq_v1/tasks/buyer/BuyerSetupDepositTxListener.java改为遍历输入分别标记hasMakerFeeInput与hasTakerFeeInput当takerFeeTxId已知taker 角色时要求两个标志同时为 true——必须各有一个独立的 maker-fee 输入和一个独立的 taker-fee 输入当takerFeeTxId为 nullbuyer-as-maker 角色时仅要求 maker-fee 输入存在同时校验存款地址depositTxAddress作为该交易的输出出现而非仅作为输入避免历史交易因多签地址复用被误判为当前存款交易。六、支持与争议消息认证加固对应提交292f438112Harden support and dispute message sender authentication。6.1 基础机制发送者签名公钥比对SupportManagercore/src/main/java/bisq/core/support/SupportManager.java是所有支持/争议消息处理的基类。核心校验方法isSenderSignaturePubKeyExpected(...)将解密后的发送者签名公钥与期望的PubKeyRing签名公钥逐字节比对不匹配则记Ignoring ... because sender signature pubKey does not match the expected peer并返回 false。PubKeyRing为 null 时本地交易记录缺失期望密钥同样拒绝处理。6.2 交易聊天与 ACK 消息交易聊天消息onChatMessage必须来自期望的交易对手发送者签名公钥需匹配本地交易记录中对应角色的PubKeyRing。ACK 消息onAckMessage同样比对发送者若 ACK 所引用的源消息在本地找不到则直接忽略而不是从未经信任的消息数据中解析对端密钥避免凭不可信数据推断信任。6.3 争议开启必须匹配合约声明的交易者DisputeManagercore/src/main/java/bisq/core/support/dispute/DisputeManager.java中的isDisputeOpenerSignaturePubKeyValid校验从争议中取出合约Contract缺失则拒绝依据dispute.isDisputeOpenerIsBuyer()取合约中的买家或卖家PubKeyRing作为期望开启者发送者签名公钥必须匹配该期望开启者——即争议开启者必须与合约中声明的交易者一致拒绝冒名开启争议。6.4 对端开启的争议与争议结果必须匹配本地期望的代理isDisputeAgentSignaturePubKeyValid校验本地必须存在对应交易的交易记录否则拒绝无法认证争议代理getExpectedAgentPubKeyRing(trade)得到的期望代理密钥必须与发送者签名公钥匹配载荷中的代理密钥dispute.getAgentPubKeyRing()必须等于交易记录的期望代理防止攻击者在消息载荷里塞入自己声明的代理密钥。这一校验同时适用于本地期望的调解代理mediation、退款代理refund与仲裁代理arbitration仲裁侧见 core/src/main/java/bisq/core/support/dispute/arbitration/ArbitrationManager.java调解侧见 core/src/main/java/bisq/core/support/dispute/mediation/MediationManager.java。6.5 关键原则认证失败先于状态变更所有无效或未认证的消息都在争议列表、聊天状态或持久化被修改之前被忽略。换言之非法消息不会污染争议列表、不会进入聊天历史、也不会触发磁盘写入——这与先认证、后变更的安全顺序一致。七、回归测试覆盖1.10.3 为上述加固补齐了聚焦的回归测试对应源码位置的测试文件包括测试主题对应源码相关测试存款/DPT 绑定、DPT 输入校验BuyerProcessDepositTxAndDelayedPayoutTxMessage、DelayedPayoutTxValidationBuyerProcessDepositTxAndDelayedPayoutTxMessageTest.java、DelayedPayoutTxValidationTest.javabuyer-as-maker 存款处理BuyerSetupDepositTxListener覆盖于上述 buyer 测试族过滤器/配置路径清理FilterManager、ConfigFilterManagerInitializationTests.java费用接收地址列表MempoolService、BtcFeeReceiverServiceMempoolServiceTest.java、BtcFeeReceiverServiceTest.java官方说明还提到新增了对支持 ACK 认证、争议开启者认证、争议代理认证、争议认证期间的失败交易查找、调解争议结果发送者认证的回归覆盖以及过期存款确认回调与不匹配存款交易被拒绝的用例。八、发布版本与升级建议8.1 版本与提交应用与打包版本号提升为1.10.3提交7a441aa6fcBump version number forv1.10.3最终 tagv1.10.3包含版本提升提交及后续的存款/DPT 绑定加固与争议消息认证加固提交。8.2 发布门禁Release Gate作为安全加固发布官方建议在发布验证中包含以下聚焦测试路径过滤器/配置路径确认filterProvidedBtcNodes、filterProvidedSeedNodes不再被持久化或应用历史配置残留被忽略/清理Core API 失败交易防护确认confirmPaymentStarted对hasFailed()交易抛出FailedPreconditionException存款/DPT 绑定确认对方存款交易、DPT 输入output 0、费用输入独立 maker/taker fee 输入、过期回调等路径的校验生效支持/争议消息认证确认交易聊天、ACK、争议开启、对端开启争议、争议结果消息在发送者签名公钥不匹配时被忽略且不触发状态变更。8.3 对运营方与开发者的实践建议节点运营方升级后检查配置文件若存在filterProvidedBtcNodes/filterProvidedSeedNodes项可手动清理或交给 1.10.3 启动逻辑自动处理依赖过滤器推送 BTC/种子节点的部署需等待新过滤器实现。API 集成方调用confirmPaymentStarted前需自行检查交易状态isFailed避免在失败交易上收到FailedPreconditionException并导致集成流程中断。阅读源码者如需深入理解过滤器签名与字段覆盖问题可结合 docs/filter-and-deny-list.md过滤器与拒绝列表机制文档与 core/src/main/java/bisq/core/filter/Filter.java过滤器数据模型交叉阅读Burning Man 接收地址机制可参考 docs/burningman/filter-controlled-btc-fee-receiver-routing.md。结语1.10.3 没有引入新功能却是一版对信任边界要求极高的安全修复它把未经签名覆盖的过滤器字段挡在信任圈之外用FailedPreconditionException阻断失败交易的异常推进以字节级一致 输入指向 output 0 独立费用输入 回调绑定交易 ID四道防线锁定存款与延迟赔付交易的绑定关系并在支持/争议消息处理的最前端完成发送者身份认证。对于依赖过滤器、API 交易控制或争议处理路径的部署本版本值得优先升级而其沉淀的回归测试也为后续过滤器实现的替换新签名方案提供了可验证的基线。赞分享区块链DeFi金融科技【免费下载链接】bisqA decentralized bitcoin exchange network项目地址https://gitcode.com/gh_mirrors/bi/bisq点击查看免费下载相关推荐Crawl4AI v0.9.0 深度解析默认安全加固的 Docker API 服务器与信任边界设计Crawl4AI v0.9.0 深度解析默认安全加固的 Docker API 服务器与信任边界设计 Crawl4AI v0.9.0 是其自托管 Docker网页爬虫RAG人工智能AI 应用Apache APISIX 威胁模型解析攻击面、信任边界与安全加固实践Apache APISIX 威胁模型解析攻击面、信任边界与安全加固实践 本文以 Apache APISIX 官方威胁模型根目录 THREAT_MODEL.mAPI网关后端云原生微服务LunaTranslator 视觉小说实时翻译完整指南从第一次运行到进阶调优LunaTranslator 视觉小说实时翻译完整指南从第一次运行到进阶调优 LunaTranslator 是一款免费开源的视觉小说实时翻译工具它从正在运行桌面应用OCR人工智能创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/14 16:37:23 · 阅读 1.2k Bisq 1.10.3 安全加固解析：过滤器信任边界、交易绑定与消息认证的全面收紧
区块链DeFi金融科技【免费下载链接】bisqA decentralized bitcoin exchange network项目地址https://gitcode.com/gh_mirrors/bi/bisq点击查看免费下载导读Bisq 1.10.3 是一个以安全加固为核心的发布版本重点围绕过滤器Filter信任边界、交易状态机防护、存款/延迟赔付交易绑定以及支持与争议消息认证四条主线收紧安全策略。本文以 release-notes/1.10.3/notable-changes.md 为主体结合仓库源码逐项还原每项变更的实现细节与影响面。读完本文你将掌握未签名过滤器字段为何被禁用、Core API 如何阻止失败交易被推进、存款与延迟赔付交易的绑定校验如何防止伪造交易注入以及支持/争议消息如何校验发送者身份并了解对应的回归测试覆盖。一、版本概览与兼容性说明1.10.3 全量提交范围从358b546526到292f438112共 10 个提交7 个普通提交、3 个合并提交涉及 27 个文件。官方完整记录见 release-notes/1.10.3/full-release-notes.md。对用户与运营方operator而言本版本的兼容性要点集中在以下几条应用与打包版本号提升为1.10.3最终 tagv1.10.3内含后续的安全加固提交见 release-notes/1.10.3/notable-changes.md 的 Release Version 一节。过滤器提供的 BTC 节点与种子节点字段被禁用后续章节详述。Core API 拒绝为已失败交易确认已开始支付。存款交易与延迟赔付交易在处理前执行更严格的绑定校验。交易聊天、ACK、争议开启、对端开启争议与争议结果消息在发送者签名公钥不匹配期望的交易对手或争议代理时被直接忽略。由于这是一次安全加固发布官方建议依赖过滤器、API 交易控制或争议消息处理路径的节点运营方及时升级。二、未签名过滤器字段禁用filterProvidedBtcNodes与filterProvidedSeedNodes2.1 背景过滤器签名覆盖范围Bisq 的网络过滤器Filter由受信任开发者私钥签名后经 P2P 网络分发客户端通过校验签名来决定是否应用。问题在于Filter数据模型中addedBtcNodes与addedSeedNodes两个字段并未被当前过滤器签名所覆盖参见 core/src/main/java/bisq/core/filter/Filter.java 中addedBtcNodes、addedSeedNodes字段定义及其序列化/反序列化逻辑。这意味着攻击者一旦能伪造一份不带这些字段签名的过滤器载荷理论上可诱导客户端把任意的 BTC 节点或种子节点当作受信任节点接入从而发起中间人MITM等攻击。2.2 实现变更1.10.3 的处理策略是双管齐下不再持久化/应用FilterManager收到来自网络的新过滤器时不再将getAddedBtcNodes()/getAddedSeedNodes()写回配置文件saveBannedNodes调用链见 core/src/main/java/bisq/core/filter/FilterManager.java。同时节点选择逻辑中这部分来源被置空。启动时忽略历史残留此前版本可能已把这两个值持久化到配置文件中1.10.3 的Config解析层直接忽略filterProvidedBtcNodes/filterProvidedSeedNodes两个命令行选项的取值选项定义见 common/src/main/java/bisq/common/config/Config.java防止陈旧残留值在启动时被重新应用。2.3 源码验证在 core/src/main/java/bisq/core/btc/nodes/BtcNodesSetupPreferences.java 的selectPreferredNodes方法中PROVIDED模式下构造候选 BTC 节点流时filterProvidedBtcNodes来源仅在--ignoreNetworkFilter未开启时才被读取StreamString filterProvidedBtcNodes config.ignoreNetworkFilter ? Stream.empty() : config.filterProvidedBtcNodes.stream();最终由FederatedBtcNodeProvider.getNodes(...)将硬编码节点与过滤来源合并见 core/src/main/java/bisq/core/btc/nodes/FederatedBtcNodeProvider.java。种子节点侧同理core/src/main/java/bisq/core/network/p2p/seed/DefaultSeedNodeRepository.java 只在非ignoreNetworkFilter时才把config.filterProvidedSeedNodes加入种子节点缓存。回归测试 core/src/test/java/bisq/core/filter/FilterManagerInitializationTests.java 验证了启动时配置文件中残留的filterProvidedBtcNodes、filterProvidedSeedNodes会被清理而无关的otherOptionkeep得以保留。2.4 对运营方的影响若你的配置文件或启动参数中显式设置了--filterProvidedBtcNodes/--filterProvidedSeedNodes1.10.3 将忽略这些值——这是预期行为并非配置错误。官方说明该处理是临时性的在新的过滤器实现覆盖这些字段签名可用之前一律按不安全处理相关值作为空值写入/应用。三、BTC 费用接收地址过滤器条目临时禁用3.1 变更内容过滤器字段btcFeeReceiverAddresses提供的地址被临时从 mempool 服务的 BTC 费用接收地址列表中排除。该路径当前并未被积极使用预计将由新的过滤器实现接管。DAO 捐赠地址与 Burning Man焚烧人接收地址不受影响继续留在列表中。3.2 源码现状Mempool 服务在构造全部 BTC 费用接收者列表时见 core/src/main/java/bisq/core/provider/mempool/MempoolService.java 的getAllBtcFeeReceivers()列表来源包括daoFacade.getAllDonationAddresses()—— DAO 补偿请求等捐赠地址Burning Man 地址列表的 legacy 地址过滤器提供的btcFeeReceiverAddressesBtcFeeReceiverService.getConfiguredReceiverAddresses(...)见 core/src/main/java/bisq/core/dao/burningman/BtcFeeReceiverService.java历史上曾销毁 BSQ 的 Burning Man 候选人的所有地址。也就是说过滤器条目在代码路径上依然被读取解析parseBtcFeeReceiverAddresses对非法配置会回退到仅 Burning Man 配置FeeReceiverConfig.forBurningManOnly()但 1.10.3 官方说明强调其临时排除意图是等待新过滤器实现重新接管该路径。阅读此部分源码时应以本版本发布说明为准理解该字段的实际生效状态。3.3 相关测试core/src/test/java/bisq/core/provider/mempool/MempoolServiceTest.java 覆盖费用接收地址列表构造行为core/src/test/java/bisq/core/dao/burningman/BtcFeeReceiverServiceTest.java 覆盖接收地址解析与合法校验。四、失败交易 API 防护Failed Trade API Guard4.1 问题场景Core API 允许客户端如bisq-cli通过confirmPaymentStarted方法确认买家已开始支付从而驱动交易沿买家协议路径前进。若交易已失败failed仍允许推进该状态机不仅违反协议语义还可能导致资金路径异常。4.2 实现在 core/src/main/java/bisq/core/api/CoreTradesService.java 的confirmPaymentStarted(String tradeId, ...)方法中首先检查是否按买家协议跟进isFollowingBuyerProtocol随后if (trade.hasFailed()) { throw new FailedPreconditionException(Cannot confirm payment started for a failed trade.); }同时该方法还保留了两道前置约束交易存款交易必须已确认trade.isDepositConfirmed()否则报错提示需等 deposit tx 确认合约与卖方支付账户载荷sellerPaymentAccountPayload必须已收到否则报错提示未收到卖方支付账户详情——桌面客户端禁用确认按钮采用同一条件。这样即使 API 客户端误调或恶意调用失败交易也无法再沿买家协议路径前进。五、存款与延迟赔付交易绑定加固这一节对应提交7e7e4ed905Harden deposit transaction and delayed payout transaction binding是 1.10.3 最核心的协议层加固之一。5.1 买家侧校验对方存款交易必须与本地一致买家处理DepositTxAndDelayedPayoutTxMessage时见 core/src/main/java/bisq/core/trade/protocol/bisq_v1/tasks/buyer/BuyerProcessDepositTxAndDelayedPayoutTxMessage.java执行以下绑定检查后再触碰钱包或交易状态本地存款交易获取作为 taker 时直接使用已设置的processModel.getDepositTx()作为BuyerAsMakerTrade时因为 maker 尚未设置存款交易使用processModel.getPreparedDepositTx()预构建的存款交易。延迟赔付交易字节一致性要求对方发来的 DPT 序列化字节与本地trade.getDelayedPayoutTxBytes()完全一致否则checkArgument直接失败。规范字段校验对对方存款交易调用checkCanonicalDepositTxFields见 core/src/main/java/bisq/core/trade/validation/DepositTxValidation.java。DPT 输入绑定调用DelayedPayoutTxValidation.checkDelayedPayoutTxInput(...)验证 DPT 的输入确实指向该存款交易。本地比对通过checkDepositTxMatchesIgnoringWitnessesAndScriptSigs忽略 witness 与 scriptSig 后比对对方存款交易与本地存款交易防止收到一份序列化合法但绑定到不同交易的存款。5.2 DPT 输入必须花费存款交易 output 0core/src/main/java/bisq/core/trade/validation/DelayedPayoutTxValidation.java 的checkDelayedPayoutTxInput严格校验DPT 输入数量必须为 1该输入的outpoint.getHash()必须等于存款交易的txId且outpoint.getIndex() 0校验失败时抛出Input of delayed payout transaction does not point to output 0 of deposit tx。这防止了攻击者提交一份序列化正确但绑定到另一笔存款交易的 DPT。同一文件中的checkLegacyDelayedPayoutTxOutput还校验 DPT 输出数量为 1、金额等于买家保证金 卖家保证金 交易金额之和。5.3 过期存款确认回调不再推进交易1.10.3 将存款确认回调绑定到其注册时的交易 ID如果一笔过期的回调stale callback在交易当前存款交易已变化后触发该回调会被忽略而不是把交易误标记为存款已确认。这一改动堵住了状态机在交易迁移期间被旧回调提前推进的窗口。5.4 存款交易监听器要求独立的 maker-fee 与 taker-fee 输入旧实现只统计输入父交易 ID 命中两个费用交易 ID 的数量count 2存在一个攻击面恶意 seller-as-maker 可以用自己 maker 费用交易的不同输出费用输出、reserved-for-trade 输出、找零输出构造两笔输入从而在计数检查中伪造一笔从未被 taker 共同注资的假存款交易。加固后的isConfTxDepositTx见 core/src/main/java/bisq/core/trade/protocol/bisq_v1/tasks/buyer/BuyerSetupDepositTxListener.java改为遍历输入分别标记hasMakerFeeInput与hasTakerFeeInput当takerFeeTxId已知taker 角色时要求两个标志同时为 true——必须各有一个独立的 maker-fee 输入和一个独立的 taker-fee 输入当takerFeeTxId为 nullbuyer-as-maker 角色时仅要求 maker-fee 输入存在同时校验存款地址depositTxAddress作为该交易的输出出现而非仅作为输入避免历史交易因多签地址复用被误判为当前存款交易。六、支持与争议消息认证加固对应提交292f438112Harden support and dispute message sender authentication。6.1 基础机制发送者签名公钥比对SupportManagercore/src/main/java/bisq/core/support/SupportManager.java是所有支持/争议消息处理的基类。核心校验方法isSenderSignaturePubKeyExpected(...)将解密后的发送者签名公钥与期望的PubKeyRing签名公钥逐字节比对不匹配则记Ignoring ... because sender signature pubKey does not match the expected peer并返回 false。PubKeyRing为 null 时本地交易记录缺失期望密钥同样拒绝处理。6.2 交易聊天与 ACK 消息交易聊天消息onChatMessage必须来自期望的交易对手发送者签名公钥需匹配本地交易记录中对应角色的PubKeyRing。ACK 消息onAckMessage同样比对发送者若 ACK 所引用的源消息在本地找不到则直接忽略而不是从未经信任的消息数据中解析对端密钥避免凭不可信数据推断信任。6.3 争议开启必须匹配合约声明的交易者DisputeManagercore/src/main/java/bisq/core/support/dispute/DisputeManager.java中的isDisputeOpenerSignaturePubKeyValid校验从争议中取出合约Contract缺失则拒绝依据dispute.isDisputeOpenerIsBuyer()取合约中的买家或卖家PubKeyRing作为期望开启者发送者签名公钥必须匹配该期望开启者——即争议开启者必须与合约中声明的交易者一致拒绝冒名开启争议。6.4 对端开启的争议与争议结果必须匹配本地期望的代理isDisputeAgentSignaturePubKeyValid校验本地必须存在对应交易的交易记录否则拒绝无法认证争议代理getExpectedAgentPubKeyRing(trade)得到的期望代理密钥必须与发送者签名公钥匹配载荷中的代理密钥dispute.getAgentPubKeyRing()必须等于交易记录的期望代理防止攻击者在消息载荷里塞入自己声明的代理密钥。这一校验同时适用于本地期望的调解代理mediation、退款代理refund与仲裁代理arbitration仲裁侧见 core/src/main/java/bisq/core/support/dispute/arbitration/ArbitrationManager.java调解侧见 core/src/main/java/bisq/core/support/dispute/mediation/MediationManager.java。6.5 关键原则认证失败先于状态变更所有无效或未认证的消息都在争议列表、聊天状态或持久化被修改之前被忽略。换言之非法消息不会污染争议列表、不会进入聊天历史、也不会触发磁盘写入——这与先认证、后变更的安全顺序一致。七、回归测试覆盖1.10.3 为上述加固补齐了聚焦的回归测试对应源码位置的测试文件包括测试主题对应源码相关测试存款/DPT 绑定、DPT 输入校验BuyerProcessDepositTxAndDelayedPayoutTxMessage、DelayedPayoutTxValidationBuyerProcessDepositTxAndDelayedPayoutTxMessageTest.java、DelayedPayoutTxValidationTest.javabuyer-as-maker 存款处理BuyerSetupDepositTxListener覆盖于上述 buyer 测试族过滤器/配置路径清理FilterManager、ConfigFilterManagerInitializationTests.java费用接收地址列表MempoolService、BtcFeeReceiverServiceMempoolServiceTest.java、BtcFeeReceiverServiceTest.java官方说明还提到新增了对支持 ACK 认证、争议开启者认证、争议代理认证、争议认证期间的失败交易查找、调解争议结果发送者认证的回归覆盖以及过期存款确认回调与不匹配存款交易被拒绝的用例。八、发布版本与升级建议8.1 版本与提交应用与打包版本号提升为1.10.3提交7a441aa6fcBump version number forv1.10.3最终 tagv1.10.3包含版本提升提交及后续的存款/DPT 绑定加固与争议消息认证加固提交。8.2 发布门禁Release Gate作为安全加固发布官方建议在发布验证中包含以下聚焦测试路径过滤器/配置路径确认filterProvidedBtcNodes、filterProvidedSeedNodes不再被持久化或应用历史配置残留被忽略/清理Core API 失败交易防护确认confirmPaymentStarted对hasFailed()交易抛出FailedPreconditionException存款/DPT 绑定确认对方存款交易、DPT 输入output 0、费用输入独立 maker/taker fee 输入、过期回调等路径的校验生效支持/争议消息认证确认交易聊天、ACK、争议开启、对端开启争议、争议结果消息在发送者签名公钥不匹配时被忽略且不触发状态变更。8.3 对运营方与开发者的实践建议节点运营方升级后检查配置文件若存在filterProvidedBtcNodes/filterProvidedSeedNodes项可手动清理或交给 1.10.3 启动逻辑自动处理依赖过滤器推送 BTC/种子节点的部署需等待新过滤器实现。API 集成方调用confirmPaymentStarted前需自行检查交易状态isFailed避免在失败交易上收到FailedPreconditionException并导致集成流程中断。阅读源码者如需深入理解过滤器签名与字段覆盖问题可结合 docs/filter-and-deny-list.md过滤器与拒绝列表机制文档与 core/src/main/java/bisq/core/filter/Filter.java过滤器数据模型交叉阅读Burning Man 接收地址机制可参考 docs/burningman/filter-controlled-btc-fee-receiver-routing.md。结语1.10.3 没有引入新功能却是一版对信任边界要求极高的安全修复它把未经签名覆盖的过滤器字段挡在信任圈之外用FailedPreconditionException阻断失败交易的异常推进以字节级一致 输入指向 output 0 独立费用输入 回调绑定交易 ID四道防线锁定存款与延迟赔付交易的绑定关系并在支持/争议消息处理的最前端完成发送者身份认证。对于依赖过滤器、API 交易控制或争议处理路径的部署本版本值得优先升级而其沉淀的回归测试也为后续过滤器实现的替换新签名方案提供了可验证的基线。赞分享区块链DeFi金融科技【免费下载链接】bisqA decentralized bitcoin exchange network项目地址https://gitcode.com/gh_mirrors/bi/bisq点击查看免费下载相关推荐Crawl4AI v0.9.0 深度解析默认安全加固的 Docker API 服务器与信任边界设计Crawl4AI v0.9.0 深度解析默认安全加固的 Docker API 服务器与信任边界设计 Crawl4AI v0.9.0 是其自托管 Docker网页爬虫RAG人工智能AI 应用Apache APISIX 威胁模型解析攻击面、信任边界与安全加固实践Apache APISIX 威胁模型解析攻击面、信任边界与安全加固实践 本文以 Apache APISIX 官方威胁模型根目录 THREAT_MODEL.mAPI网关后端云原生微服务LunaTranslator 视觉小说实时翻译完整指南从第一次运行到进阶调优LunaTranslator 视觉小说实时翻译完整指南从第一次运行到进阶调优 LunaTranslator 是一款免费开源的视觉小说实时翻译工具它从正在运行桌面应用OCR人工智能创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考