谢谢回复，我也觉得 RGB++ 的想法挺好的，非常有意思，很期待它能真的生根发芽。
CKB 也非常有意思，我之前一直很期待想看看有没有一个 UTXO 模型的支持智能合约的区块链，不过之前一直不知道有 CKB ，这次看到以后就觉得很开心
2 Likes
没错，是这样的。但事实上要想真正的双花 RGB++ 交易，你不仅需要 reorg BTC 也需要同步 reorg CKB，因为 CKB 的交易的 input 同样有双花约束。不过仍然有因为 reorg 造成问题的可能性。
一个平庸的解决方案就是 CKB 上的 BTC 轻客户端只允许用户访问 Tip - N 之前的块头，这样确保所有 CKB 上的交易只能绑定“不可 reorg”的 BTC 交易。但我们也在思考一个更好的方案，允许交易绑定最新的 BTC 交易，但交易者或 dapp 自行决定可接受的 BTC 确认数，例如 N=2 还是 N=6 由用户自行决定。但这个设计还有一些细节需要思考。
1 Like
作为一个怀有恶意的人，我不一定是想要真正地去”双花“一个 UTXO ，我可能只是想“进行破坏”。如果是以进行破坏为目的的话，那么我只需要利用 BTC 链上的 reorg 创造出 CKB 和 BTC 上的数据不一致的情况就可以了。就比如我上面提到的情况：
我们再想象一下，假如 B 在收到 A 的转账后（A 还没进行双花），在一个交易折叠里进行了 20 多次转账，涉及到了 20 多个用户，这些交易里可能还添加了这些用户的其他 UTXO 作为输入，最后这些交易折叠到了一个 BTC 链上交易里。然后 A 实施了双花，于是这 20 多个用户的余额都出现了问题，对于 CKB 而言，那些 UTXO 应该已经被花掉了，但是整个交易链条又是有缺陷的（因为有一个 UTXO 已经不存在了），由于 CKB 上的交易不会因为 BTC 的 reorg 而触发重新确认，于是 CKB 上就出现了大规模的和 BTC 不一致的情况，而且状态没办法回滚到一开始的样子
在这种情况下，我能够以很小的成本创造出很大的混乱
如果由 dapp 自行决定可接受的 BTC 确认数，而 dapp 为了规避我上面提到的“尤其是对于共享状态用例，一旦对应关系被破坏，我感觉恢复起来可能也会比较麻烦”这种麻烦，可能会选择一个操作要等待 5、6 个 BTC block 才能确认，这实在是太难让人接受了
有你这么仔细的兄弟加入，以后CKB上APP的质量和容错相信一定会更上一个台阶，对做开发确实是得较真，不然怎么大规模应用，有时一个BUG就足以毁掉一次策划很久的项目的努力，前段时间OMIGA铭文上线就是有个小漏洞，结果手打铭文最后变成了脚本打铭文，虽然从另一个角度这对CKB也算是一次高频压力测试和验证，但从铭文本身看不得不承认这就是一次由BUG导致的事故，如果是完全手打来，估计现在这波铭文热度还没打完，结果都去刷脚本2天就结束了。。有你这样的人加入，兄弟，相信CKB生态会越来越好！
2 Likes
看高手论道就是精彩
1 Like
- Commitment 里的 CKB TX 应该不包含 CKB 的 TX witness，不然会循环嵌套
- Commitment 里为什么要加入 input utxo？ 约定相同位置input是不是也可以？
- 非交互式转帐里，发送交易没有注明是否要使用 Bitcoin TX A 作为 CKB TX B 的
Witness. - 非交互式转帐里，领取交易里的 commitment 应该是CKB TX B。
- 非交互式转帐里，领取交易是否要使用 BTC 交易作为 witness 进行防呆保证绑定 的UTXO正确？
- 简单分析了一下，在 ckb 这边的 lock args 也可以使用 blind utxo，但是作用有限，因为转出的的时候必须 reveal btc tx 作为 witness，这样隐私只能做到转出之前。
- 因为Bitcoin和CKB都保证了不能双花，对于安全性其实只有一边保证就可以了 （基于同时信任 Bitcoin 和 CKB 的前提下）。所以对于一些中间状态，可以让一边 暂时和链上 UTXO 脱钩，个人觉得是一个值得探索的方向。其实在非交互式转帐里就已经和 Bitcoin UTXO 短暂脱钩了。如果把 Bitcoin UTXO 和 CKB UTXO 比作 RGB++ 的两条腿，这种单边的暂时性脱钩像是交替抬往前走。
2 Likes
为什么选择把 ckb tx 放 commitment 里，而不是放更通用的 state hash？放 ckb tx 的问题是限制的太死不够灵活，碰到网络堵塞没法增加手续费，或者是 script cell deps 升级直接就费了。
除了使用 state hash，也可以用 tx 的部份 hash，比如 hash(ckb input utxo outpoint, ckb new utxo cell output, ckb new utxl cell data)
这一句没太看明白。
用state_hash不太行，主要在于拆分的时候会有问题，A UTXO绑定了100个XYZ Coin，现在要给B UTXO和C UTXO各转移50个，那么如果用状态树的哈希，就很难做到每个用户自己保管自己的资产。但是用Cell模型的Partial Transaction，感觉还是可以的。
比如通过 ckb args lock 找到第 i 个 input 是对应的 btc outpoint, 然后它对应第 i 个位置上的 output 里的 OP_RETURN 就是对应的 commitment，这样就不用在 commitment 里带上 input utxo 封条
如果 CKB 的容量也不够用了，需要扩容，会有哪些方案选择？这些方案和直接在 Bitcoin 上做 client-side validation 的原版 RGB 方案相比会有哪些优势？
- 可以与BTC上的闪电网络整合。
- CKB上的更强大的通道网络。
- 使用zk压缩。
优势：由于交易数据公开，所以进行各式可组合的应用开发会简单，原版的RGB需要用户自己保存整个历史序列，那如果我要开发一个Dex，每挂一个单，都需要用户把整个序列传给我验证，用户体验过差。
劣势就是在隐私这块需要用别的方案来做。
这个描述听着很有哲学道理哈，有点像一项运动里说两个人绑着腿怎样走的更快，关键点是节奏感，节奏对了也不慢，节奏不对就拉最后了。。
这样的话，这个 commitment 是不是就有可能被重用到其他地方呢？
和老的 seal utxo 位置对应，应该是保证了不能双花的。
兄弟，你提的一些安全性问题的关心，在另外一篇“RGB++ 深入讨论(1): 安全性分析”里边提到了，你看看有没有解决你关心的问题？那篇帖子内容比较专业，以我现在的知识储备还不能完全看明白。
好的，谢谢提醒，我去看看
很棒的设计，同构映射和CKB合约验证尤其解决了RGB的DA和通信问题。
但我有些问题，主要是针对实现上的。
RGB++需要在CKB上实现比特币的轻客户端。这里我有两个顾虑。
一是轻客户端的状态存储是增长的，而且这个状态需要占用CKB。不知道量级会如何，以及谁来维护这个状态？
二是RGB的状态验证是累积的——验证时，该资产的所有历史状态都要附带上来（据我了解）。那如果交易的历史链路很长，会不会带来某些验证的问题（比如超过VM的cycle数量，使得该验证无法进行）？
另外，文章提到「Bitcoin TX 需要先于 CKB TX 发送出来」。如果 Bitcoin TX 的计算有问题（但它还是可以正常上链），导致 CKB 上的 RGB++ 状态验证不通过，是不是就意味着这个资产永远没法取回来了？我的理解是，原本代表资产的 Bitcoin UTXO 已经变更，但 RGB++ 的状态又没有变化，会导致这个资产永远无法再被 CKB 验证通过。
1 Like