没错，是这样的。但事实上要想真正的双花 RGB++ 交易，你不仅需要 reorg BTC 也需要同步 reorg CKB，因为 CKB 的交易的 input 同样有双花约束。不过仍然有因为 reorg 造成问题的可能性。
一个平庸的解决方案就是 CKB 上的 BTC 轻客户端只允许用户访问 Tip - N 之前的块头，这样确保所有 CKB 上的交易只能绑定“不可 reorg”的 BTC 交易。但我们也在思考一个更好的方案，允许交易绑定最新的 BTC 交易，但交易者或 dapp 自行决定可接受的 BTC 确认数，例如 N=2 还是 N=6 由用户自行决定。但这个设计还有一些细节需要思考。
作为一个怀有恶意的人，我不一定是想要真正地去”双花“一个 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生态会越来越好！
看高手论道就是精彩
为什么选择把 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 方案相比会有哪些优势？
优势：由于交易数据公开，所以进行各式可组合的应用开发会简单，原版的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 验证通过。
最后一个问题是所有将 state machine 节点和 btc utxo 绑定协议的共同问题，因为 Bitcoin 上不验证规则。一种可能的方案是支持某种 rollback 方案，就两个父子 BTC 交易打包一起验证，同时证明其中的父交易的状态变化是错误的