- 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
最后一个问题是所有将 state machine 节点和 btc utxo 绑定协议的共同问题，因为 Bitcoin 上不验证规则。一种可能的方案是支持某种 rollback 方案，就两个父子 BTC 交易打包一起验证，同时证明其中的父交易的状态变化是错误的
2 Likes
the way to properly implement this is with a cryptographic accumulator on CKB, with this design, only enough information to cryptographically prove inclusion of a block is required, it is on the order of about 1000 bytes
2 Likes
Are you saying that each user will each have to lock 1000 CKB to run a BTC light client if they want to use RGB++? @matt.bit
Only one for everyone.
1 Like
OK, thanks!
我这里有三个问题
- 原始的RGB在链下有着几乎不妥协的处理能力，可以处理一些对计算力有需求的场景，同时也只需要付出常数级别的交易费。而现在不仅需要根据交易复杂程度支付交易费，单笔交易的处理能力也受到了限制。
- 原始的RGB协议中借助于UTXO，只需要保证交易的偏序性就可以了。而如果要引入共享状态，那么由于存在对共享状态的争抢，交易的全序性就至关重要了，这是intent cell也无法解决的问题。如果CKB上交易被审查，将会影响已提交commitment的执行结果。
- 交易折叠的问题。在承诺-公开的两阶段框架下，在承诺被提交到btc链上时，CKB上对应的交易应该已经被构造好了，那么交易折叠在哪些场景下可用呢？能否给出一个实际的例子。