hackmd-github-sync-badge UTXO transactions management is hard because they may be stuck in or even dropped from the CKB node transactions pool when the fee is too low. This guideline is for any transactions generator which wants to trace the transaction status before finally confirmed in the chain. Transaction States The transaction lifecycle starts after creation and ends when it is finally confirmed or conflicts with a confirmed transaction. During the lifecycle, the transaction is in one of the following states. Pending

dApp Programming on UTXO is Hard Separating the generator and verifier is a premature optimization. Typically, using a generator to recreate the result and check whether it matches the given result is enough in most situations. However, attempting to separate the generator and verifier can lead to unnecessarily complex design. Another issue that arises is the signature, which can make it difficult for users to understand the transaction. The situation becomes even more complicated when working on the partial signing proposal, in which users must sign selected fields in a transaction. Our observations indicate that properly implementing partial signing can be challenging, and can increase the disparity between what the transaction actually does and what the user is signing. The New OOP Idea These issues lead to an idea: Why not let users sign their intentions as messages sent to a cell? This approach is similar to Object-Oriented Programming (OOP), where users can sign and send messages to cells. The lock script can then verify the signature, and the typescript can handle message processing. During message processing, side effects such as creating, modifying, or deleting a cell can occur, and these ultimately determine the transaction outcome in a deterministic way. The generator uses these side effects to create transactions in a deterministic manner. The verifier then recreates the transaction and verifies that it matches the original transaction.

Synopsis This survey covers SDK interfaces for constructing CKB transactions and includes a case study on txforge, a Bitcoin transaction builder. The txforge interfaces may inform the development of a more effective transaction builder interface for CKB. Provoking Questions 对于 tx builder 接口有什么改进建议？有没有参考项目推荐？ 目前 SDKs 只对 system scripts 和某些我们挑选的 scripts 作了封装，对于其它 scripts 则缺少支持，也没法去全部支持，那如何才能简化应用间的交互呢？ 目前我们 SDKs 走的多语言路线，那是不是 dApps 想被集成，也得维护多语言的 SDK 呢？ 我的想法是需要有一个语言无关的关于交易构建的标准，这样只需要输入一些参数就能创建出一个其它 dApp 的合法交易出来。对于这样的标准，有没有什么想法？ 除开交易构建标准，有其它的办法能解决 Scripts 互操作的问题吗？

Attention that this is a planned feature which is not available yet. Currently, the transaction pool reject new transactions when it is full. When a transaction is stuck in the Pending or Reverted state for a long time, the generator has two choices. CPFP, Child Pays For Parent. The generator creates a child transaction spending the outputs of the stuck transaction. RBF, Replace By Fee. The generator marks the stuck transaction as Abandon and uses all or some of its inputs to create a new transaction. Fee Estimate For New Transaction In CKB, the block limits the supply of transaction space in two dimensions: