BTCProguy | building Alkanes for BTCfi

@Jelffnx @Huaguibtc 3年1万美元

@BTCProguy @Huaguibtc ？看到多少？

@zh798_btc @jianmei_btc @SUBFROSTio 借我一个号

@BTCProguy @jianmei_btc @SUBFROSTio 咋这么扯淡，赶紧弄个，进群聊聊天

第一次通过 #Alkanes 协议与 @SUBFROSTio 的 frBTC 合约 32:0 交互。 我做的是一笔简单的 unwrap opcode 78 调用，但对收费模型有些疑问。 文档/实现里要求交易必须有一笔 vout 输出到 Subfrost 官方地址，金额 546 sats。起初我以为这笔输出是用于后续 BTC 回款交易的 矿工费。 但我测试了一笔 unwrap：金额约 0.00001945 frBTC，最终只收到 0.00001740 BTC。链上看 Subfrost 后续回款交易的矿工费约 204 sats，而 1945 - 1740 也基本等于 204 sats。也就是说，后续回款交易的矿工费似乎已经从 frBTC unwrap 金额里扣除了。 所以想请教 @SUBFROSTio： 1. 为什么构造 unwrap 交易时，必须额外向官方地址输出 546 sats？这笔输出是协议费用、dust marker，还是其他用途？如果改成 330 sats 是否仍然有效？ 2. Subfrost 协议实际收取的服务费，是从 frBTC 金额里扣，还是通过这笔 546 sats 输出收取？ 3. 从机制上看，BTC <-> frBTC 似乎依赖 Subfrost 服务端后续回款，类似一种桥接流程。这个过程的安全性、托管风险和故障恢复机制是如何保证的？ 4. 另外，unwrap 交易里通常会有一个 BTC target marker 输出，用来指定 BTC 回款地址。当前结构里它是单独的 vout1。请问这个 BTC target marker 是否必须单独占用一个 dust 输出？ 如果 vout0 本身就是我的地址，并且也是资产/找零输出，能否直接把 vout0 作为 BTC target marker，然后把第二个 Protostone 的 pointer 从 1 改为 0？

@zh798_btc @jianmei_btc @SUBFROSTio 别人借给我的账号，上不去了

@BTCProguy @jianmei_btc @SUBFROSTio 你之前的tg号不用了吗？现在换成啥了

First treasury burn: 20 $HORN gone forever. 3,000 max supply → 2,963 $HORN. This is just the start. More burns and buybacks as the Ethorn protocol grows. ethorn.art Tx: etherscan.io/tx/0xe5505b339…

@zh798_btc 其实我也不信，但冥冥之中，我感觉是对的，所以写下来

@BTCProguy 我信

群里没人信，但是两年后，不信的都会后悔

@luoshao001 我的感觉很准的，成功率55%

@BTCProguy 那么自信

感觉今天要突破起飞了，下一个目标50美元

@zh798_btc @jianmei_btc @SUBFROSTio 你以为赚大钱的都是靠运气吗

@BTCProguy @jianmei_btc @SUBFROSTio 你咋这么牛逼

unwrap ABI 是 (vout, amount_requested),BTC target 由 vout 参数指定 BTC target output 必须是 P2TR 类型(32 字节 pubkey 提取) 546 sats 输出 = 指向 signer 的 supplementary output,是标记不是费用 EOA-only、pointer 不能带 edicts、pointer 不能等于 synthetic 花费的 output 以上你都可以去查源代码确定：github.com/kungfuflex/alk…

查了 fr_btc 合约的 wasm,opcode 78 的 ABI 是 unwrap(vout: u128, amount_requested: u128)。关键:BTC 回款目标是靠第一个参数 vout 显式指定的,不是靠 protostone 的 pointer。 你想"把 pointer 从 1 改成 0"其实方向不对——pointer 管的是 frBTC 资产/找零的归属,BTC target 是 vout 参数管的。 你真正想做的"让 vout0 当 BTC target",正确做法是 unwrap 第一个参数直接传 0。但前提:vout0 必须是 Taproot(bc1p)地址。 因为合约会从那个 output 抠 32 字节 x-only pubkey(output32 != NULL / output_pubkey != NULL 两条 assert),P2WPKH(bc1q)里没有 32 字节 pubkey,会直接 panic。如果你的 vout0 是 bc1q,就没法复用,必须单独给一个 bc1p 输出当 BTC target。 另外注意 v1.1.0(主网当前版本)的新约束 must be called by EOA,以及 pointer cannot be equal to output spendable by synthetic——做 vout0 复用方案时确认 pointer 没撞上被 signer 花费的那个 output。

问题 4：BTC target marker 必须单独占一个 dust 输出吗？能不能让 vout0 同时当 marker、把 pointer 从 1 改成 0？ 这个问题你问得很细，已经到了协议构造的层面。基于文档我只能给你一个“原理上的回答”和一个“强烈的实操建议”，但最终你必须自己验证或等官方确认——因为这涉及具体实现细节，猜错了会丢钱。 原理层面： unwrap 交易的结构里，vout 的角色分配是协议的索引器（metashrew）按规则解析的。文档给出的标准结构里，protostone 的 pointer 指向哪个 output，决定了“未分配的资产/找零落到哪里”。你设想的“让 vout0 一身二职——既是我的资产/找零地址，又是 BTC 回款目标地址，然后把第二个 protostone 的 pointer 从 1 改成 0”——在纯逻辑上，如果 vout0 确实是你自己的地址，这个复用是说得通的，能省掉一个 dust 输出。 但这里有三个风险，我必须给你讲清楚： 协议索引器可能对 vout 的位置/角色有硬编码假设。 很多元协议的解析逻辑是“vout0 必须是 X、vout1 必须是 Y”这种位置约定。SUBFROST 文档给出的标准 unwrap 结构里，marker 是单独的输出——如果索引器是按“固定位置”解析的，你把两个角色合并到 vout0，索引器可能根本识别不到 BTC target，导致回款打不出来，或者打到错误地址。 这是一笔会真实移动 BTC 的操作，试错成本是真金白银。 wrap 错了顶多交易失败、钱还在；unwrap 的构造错了，可能 frBTC 已经 burn 了、但 BTC 回款因为结构非标而卡住或丢失。 文档给的是“标准结构”，没有明确说“允许复用 vout0”。 文档没写“可以”，在涉及资金的协议交互里，“没明确说可以”就应该默认“不要这么做”，直到官方确认。 给你的实操建议： 别拿真金白银在主网试这个优化。 如果要验证，去 SUBFROST 文档提到的 signet 测试网（signet.sandshrew.io 那套），用测试币把“vout0 复用 + pointer 改 0”跑一遍，看索引器认不认。 或者直接读 alkanes-rs 仓库里 frBTC 合约（{32,0}，opcode 78 unwrap）的实际解析代码——crates/ 目录下，文档说 DIESEL genesis 合约也在那里，frBTC 的解析逻辑应该能找到。代码会告诉你索引器到底是“按位置”还是“按 pointer 灵活解析”。这个问题的确定答案在代码里，不在文档里。 在没验证之前，老老实实按文档的标准结构来：BTC target marker 单独占一个 vout1，该花的那个 dust 输出就花。你想省的是一个 dust 输出（几百 sats），对比 unwrap 构造错误可能丢掉的本金，这个优化的风险收益比很差。

问题 3：BTC ↔ frBTC 依赖服务端回款，安全性/托管风险/故障恢复怎么保证？ 这是你四个问题里最重要的一个，也是任何想认真用 frBTC 的人都该问的。基于文档，机制是这样的——而且 wrap 和 unwrap 的信任假设是不对称的，这点必须分清： Wrap（BTC → frBTC）是原子的、无需信任的。 你把 BTC 锁进去和 frBTC 被 mint 出来，发生在同一笔比特币交易里。如果 BTC 没转成功，frBTC 就不会被 mint。这一侧没有托管风险——要么全成，要么全不成。 Unwrap（frBTC → BTC）是“信任最小化”，但不是“零信任”。 这就是你观察到的“类似桥接”的那一侧： 你先 burn 掉 frBTC，在链上排队一个 payment 请求 SUBFROST 的 signer 集合监听到这个请求，协作签名一笔比特币交易，把锁定的 BTC 放给你 这里的安全性靠的是 FROST/ROAST 阈值签名：那个锁定所有 BTC 的比特币地址，它的私钥从来没有被任何单个节点完整持有过，而是被整个 signer 集合（文档说支持最多 255 个签名者）通过分布式密钥生成（DKG）分片持有。要动这笔 BTC，必须有门限数量（t-of-n）的签名者协作。这意味着什么： 单个签名者作恶/被黑——偷不走钱，因为他手里只有一个分片，达不到门限。 这比传统的“联邦多签”或“中心化托管”安全性高一个等级——文档原话就是说这是对那些方案的“显著改进”。 但它不是 100% trustless。它的信任假设是：作恶的签名者数量不超过门限。如果超过门限数量的签名者串谋，理论上是可以动这笔 BTC 的。这是所有阈值签名桥的共同前提。 故障恢复方面，文档提到几点：unwrap 的 payment 请求是按区块高度存储在链上的（/payments/byheight/{height}），有 fulfilled 状态追踪，有 last_block 记录处理进度。也就是说你的 unwrap 请求是链上可查、可验证的——你可以自己查 pending unwrap 的状态。signer 集合是动态的，旧签名者退出、新签名者加入靠“reshare”仪式完成，不影响已锁定资产。 给你的诚实结论： unwrap 这一侧，你的“类似桥接”直觉是对的——它确实依赖一个外部签名者集合的诚实多数。安全性比中心化托管强很多（无单点、链上可验证、阈值签名），但它不是比特币本身那种零信任。用之前应该清楚这个前提：你信任的是“FROST signer 集合的门限假设”，不是纯数学。

问题 2：协议的服务费，是从 frBTC 金额扣，还是通过这 546 sats 收？ 都不是通过 546 sats 收。服务费（协议 premium）是从 frBTC 金额里扣的。按 SUBFROST 文档，unwrap 有一个默认 0.1% 的协议 premium。机制是这样的：你 unwrap 一笔 frBTC，SUBFROST 的 signer 集合后续会协作签名一笔 BTC 交易把钱打给你。这笔回款交易： 要付比特币网络的矿工费（你实测约 204 sats） 协议还会收一个 premium（默认 0.1%） 这两项，都从你 unwrap 的 frBTC 数额里扣。你最终收到的 BTC = unwrap 的 frBTC − 回款矿工费 − 协议 premium。你这次的数：unwrap 1945 sats 等值，收到 1740，差 205 sats。在这么小的金额下，0.1% 的 premium 只有约 2 sats，几乎可以忽略，所以你看到的差额“基本等于 204 sats 矿工费”是合理的——premium 被金额太小给淹没了。金额大的时候，那 0.1% 才会明显体现出来。那 546 sats 始终是你自己交易里的一笔输出，SUBFROST 没有把它当收入——它就是个为了过 dust 检查而存在的标记。

问题 1：为什么必须向官方地址输出 546 sats？改成 330 还行不行？ 这 546 sats 是 dust 阈值决定的标记输出，不是协议费用，也不是 dust marker 在“标记 dust”——它是“为了让这笔指向官方地址的输出本身不被当成 dust 而拒绝”。比特币网络对输出有 dust limit。对一个标准的 P2WPKH（bc1q...）输出，dust 阈值正好是 546 sats。任何低于这个值的输出，会被节点和矿工当作 dust 拒绝中继。 unwrap 交易需要有一笔 vout 指向 SUBFROST 的 signer 地址——这笔输出的存在本身是协议识别和验证 unwrap 请求的一部分（协议要确认“你确实把交易构造成了指向正确的 signer”）。但这笔输出不需要承载真实价值，它的作用是“被看到”，不是“转钱”。既然它必须存在、又不需要承载价值，那就让它取网络允许的最小合法值——也就是 546 sats。 所以“改成 330 sats 行不行”的答案是：不行。330 低于 P2WPKH 的 546 dust 阈值，这笔输出会被网络判定为 dust，整笔交易很可能无法被中继或确认。546 不是 SUBFROST 随便定的数字，是比特币共识层的硬约束。你想省的那 216 sats，省不掉——省了交易就废了。（唯一的理论例外：如果 signer 地址是 P2TR/bc1p 类型，Taproot 输出的 dust 阈值略低，但 SUBFROST 文档里把 546 sats 作为明确常量给出，说明就按 546 来，别自作聪明调低。）

@btc_william1127 @wolfyxbt 不划算，柴油涨了17倍，甲烷底部起来才3-4倍。 等甲烷再起飞的时候，换合适。柴油起飞的原因还是和挖矿成本有关，ug挖矿那一波，都飞了。 甲烷是有潜力的

@BTCProguy @wolfyxbt 要把甲烷换成diesel吗

我再给你们一次机会，一人分享一个生活好物给我 不要分享飞机杯、不要分享安全套、不要分享香蕉保护壳、不要分享伟哥、不要分享壮阳药、不要分享妇炎洁，谢谢大家。

@caishen_btc 已卖，我梭了，等你了

@BTCProguy 别逼逼 这么好的 机会 直接卖房买车贷款梭哈 然后发出来 我们绝逼买买买

@zh798_btc 之前是测试版，现在正式版，改了很多

@BTCProguy 这更新了个啥

alkanescan.org/pools.php see all the alkanes pools with TVL and 24H volumes #alkanes

I built an alkanes smart contract and I really need an audit or feedback from someone github.com/orddao/Block-H… #alkanes #oracles