Transaction

j"19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAutMQ# KaChing APDU Transaction Protocol Explained [Source(Permalink)](https://kaching.cards/explained/ )  # KaChing APDU Transaction Protocol Explained 解释 KaChing APDU 交易协议 #### The reader of this article is expected to have a fairly good knowledge about bitcoin at a technical level. 本文的读者应该在技术层面上对比特币有相当好的了解 #### **Protocol specification: 协议规格:** <http://kaching.cards/katp.pdf> The KaChing APDU Transaction Protocol (KATP) is a protocol allowing two entities to perform peer-to-peer bitcoin transactions. It’s primarily designed for local communication, where the wallet and terminal are physically close. Kaching APDU 交易协议(KATP)是一个允许两个实体执行对等比特币交易的协议。 它主要是为本地通信而设计的，钱包和终端在物理上保持近距离。 During a transaction session one peer acts as the terminal while the other acts as the wallet. Some devices such as an app on a smartphone will have the ability to act both as terminal and wallet. 在交易会话中，一个对等点充当终端，而另一个充当钱包。 有些设备，比如智能手机上的应用程序，可以同时充当终端和钱包的角色。 Both the terminal and wallet are able to add as many inputs and outputs to the transaction as they wish. This allows both the wallet and terminal to consolidate their UTXOs as part of normal use. 终端和钱包都能够按照自己的意愿向交易添加任意多的输入和输出。 这使得钱包和终端都可以合并它们的 UTXOs (未花费的交易输出)作为正常使用的一部分。 Metadata may be added in the form of OP\_RETURN outputs by both terminal and wallet. 元数据可以通过终端和钱包以OP\_RETURN 输出的形式添加。 ## Terminal role 终端角色 The terminal is the host of the communication session. It is responsible for determining the correct fee and publishing the completed transaction to the blockchain. 终端是通信会话的主机。 它负责确定正确的费用，并将完成的交易发布到区块链。 ## Wallet role 钱包角色 The wallet is responsible for keeping track of it’s own UTXOs. A wallet doesn’t need any internet connectivity. Such a wallet can only receive (and spend) funds when communicating with a terminal. 钱包负责跟踪它自己的 UTXOs。 钱包不需要任何网络连接。 这种钱包只有在与终端通信时才能接收(和使用)资金。 ## Card pairing and management protocol 卡片配对和管理协议 KATP defines only the public protocol of a KaChing wallet implemented in a smart card. A smartcard wallet will also need to support some protocol for managing the card, such initializing the master key, setting PIN and spend limits. Since that protocol typically will only be used between the card holder and their own phone, standardizing that protocol is of less concern. KATP 仅定义了在智能卡中植入的 KaChing 钱包的公共协议。 智能卡钱包还需要支持一些管理卡的协议，比如初始化主密钥、设置 PIN 和花费限制。 由于该协议通常只在卡持有者和他们自己的手机之间使用，因此对该协议进行标准化就不那么重要了。 ## Physical communication 物理通信 KATP doesn’t dictate any specific physical communication protocol. Any protocol that allows for the transmission of APDU packets can be used. For interoperability contactless communication using ISO/IEC 14443 A/B is recommended. KATP 不规定任何特定的物理通信协议。 可以使用任何允许传输 APDU 数据包的协议。 建议使用 ISO/IEC 14443 A/B 进行互用性非接触通信。 ## NFC: Near-field communication NFC 近场通信 NFC is a set of protocols managed by the NFC Forum for contactless communication. KaChing APDU Transaction Protocol is not built on top of the NFC protocols, but a contactless wallet will make use of the same underlying protocols such as APDU and ISO/IEC 14443. A smart card implementing KATP might also implement an NFC tag to enhance the user experience. NFC是一套由 NFC 论坛管理的非接触式通信协议。 Kaching APDU 交易协议并不建立在 NFC 协议之上，但非接触式钱包将使用相同的底层协议，如 APDU 和 ISO/IEC 14443 。 实现 KATP 的智能卡还可以植入 NFC 标签，以增强用户体验。 ## Android devices 安卓设备 Android devices can be programmed to both operate as a KaChing terminal and as a wallet. An Android device with NFC support can communicate with wallets supporting ISO/IEC 14443 A or B. The communication is done using the [IsoDep interface](https://developer.android.com/reference/android/nfc/tech/IsoDep). This interface allows the transmission of APDU packages directly bypassing the NFC higher level protocols. 安卓设备可以被编程为既是一个 KaChing 终端又是一个钱包。 支持 NFC 的 Android 设备可以与支持 ISO/IEC 14443 A 或 B 的钱包通信。 通信是使用[IsoDep 接口](https://developer.android.com/reference/android/nfc/tech/IsoDep)完成的。 这个接口允许直接传输 APDU 包并绕过 NFC 中的高级协议。 In order to implement a wallet, [host-based card emulation is used](https://developer.android.com/guide/topics/connectivity/nfc/hce). 为了实现一个钱包，使用了[HCE: 基于主机的卡模拟](https://developer.android.com/guide/topics/connectivity/nfc/hce). The KaChing protocol can be used for phone to phone payments. This requires one of the phones to act as the terminal and the other to act as the wallet. The phone acting as terminal must have internet connection. Kaching 协议可以用于手机对手机的支付。 这需要一部手机充当终端，另一部充当钱包。 作为终端的手机必须有互联网连接。 ## iOS devices iOS 设备 As of today, third party apps are not given sufficient access to the built-in NFC of iOS devices required to implement the KaChing protocol. In order to implement a KaChing terminal on an iOS device, external hardware is required. 到目前为止，第三方应用程序还没有获得足够的权限访问内置的 iOS 设备的 NFC，而这些设备需要实现 KaChing 协议。 为了在 iOS 设备上实现一个 KaChing 终端，需要外部硬件。 ## APDU The APDU protocol is specified in ISO/IEC 7816-4. KaChing APDU Transaction Protocol uses only a subset of this protocol. Communication is performed in command-response pairs. The command APDU is sent by the terminal. The wallet sends a response APDU back. APDU 协议由 ISO/IEC 7816-4 规定。 Kaching APDU 交易协议仅使用该协议的一个子集。 通信是在命令-响应消息对中执行的。 终端发送命令 APDU。 钱包发回一个响应 APDU 。 Note that in order to parse APDUs the length must be known. 请注意，为了解析 APDUs，必须知道长度。 ## Command APDU 命令APDU The CLA bytes must always be ‘80’. Logical channels, command chaining and secure messaging are not used. CLA 字节必须始终为"80"。 不使用逻辑通道、命令链接和安全消息传递。 The parameter bytes P1-P2 must always be ‘00’. 参数字节 P1-P2必须始终为'00'。 Nc is a number denoting the length of the data field in the command APDU. It is encoded in the command APDU as the field Lc. Nc 是命令 APDU 中表示数据字段长度的数字。 它在 APDU 命令中被编码为字段 Lc。 Ne is a number denoting the expected maximum length of the data field in the response APDU. It is encoded in the command APDU as the field Le. Ne 是一个数字，表示响应 APDU 中数据字段的预期最大长度。 它在 APDU 命令中被编码为字段 Le。 When the value of both Nc and Ne is equal to or less than 255, the encoding is simple. If the value is zero, the corresponding field is omitted in the command APDU. Any other value is encoded as a single byte. 当 Nc 和 Ne 的值都等于或小于255时，编码很简单。 如果该值为零，则在命令 APDU 中省略对应的字段。 任何其他值都被编码为单个字节。 It’s highly recommended to keep the value of Nc and Ne within the range 0-255. The encoding of extended length is a bit complicated and support is still missing in some libraries and smart cards. 强烈建议将 Nc 和 Ne 的值保持在0-255之间。 扩展长度的编码有点复杂，在一些库和智能卡中仍然缺乏支持。 ## Response APDU 响应 APDU The response APDU consist of up to Ne bytes data followed by two status bytes denoted SW1-SW2. Status bytes ‘9000’ indicates success. 响应 APDU 由多达 Ne 个字节的数据和两个标识为 SW1-SW2的状态字节组成。 状态字节"9000"表示成功。 ## Limitations 限制 KATP puts no limits on the size of transactions, the number of inputs and outputs nor the size of each input and output. KATP 没有限制交易的大小、输入和输出的数量，也没有限制每个输入和输出的大小。 In practice there will be limits. It can be expected that wallets implemented as smart cards can handle transactions of at least 2000 bytes. 实际上是有限度的。 可以预期，钱包实现为智能卡可以处理至少2000字节的交易。 ## Transaction Session 交易会话 Before the transaction session can start the terminal must wait for: 在交易会话可以启动之前，终端必须等待: * Transfer amount 转帐金额 * The wallet to be presented to the terminal 将被提交给终端的钱包 For best user experience a terminal should be prepared for these events to happen in any order. 为了获得最佳的用户体验，终端应该为这些事件以任何顺序发生做好准备。 The session is successfully completed with the transaction being committed to the wallet and published to the blockchain. The wallet must be programmed to be fail safe in case of aborted sessions. 当交易被提交给钱包并发布到区块链时，会话成功地完成。 钱包必须被设定为在中止会话的情况下是故障安全的。 The wallet doesn’t have to be aware of any dust limit policy in output amounts. If the wallet produces an output with value below dust limit, the terminal can resolve this either by retrying the transaction session with a slightly different transfer amount or by removing the problematic output. A wallet that has been programmed to be aware of current dust limits, might refuse to sign the transaction if it’s output has been modified by the terminal. 钱包不必知道任何灰尘限制政策的产量。 如果钱包产生的输出值低于尘埃限制，终端可以通过以稍微不同的传输量重试交易会话或移除有问题的输出来解决这个问题。 如果一个钱包的输出被终端修改了，它可能会拒绝在交易上签名，因为这个钱包已经被设定为知道当前的灰尘限制。 There is no support for retrying individual commands in the protocol. 不支持在协议中重试单个命令。 ## 0 Select KaChing 选用 KaChing Before sending any of the KATP commands the terminal should issue the SELECT command as defined in ISO/IEC 7816-4. This command has many options. In order to reduce the burden on wallet implementers it is highly recommended to only use the following options: 在发送任何 KATP 命令之前，终端应该发出 iso / iec 7816-4中定义的 SELECT 命令。 这个命令有很多选项。 为了减轻钱包实现者的负担，强烈建议只使用以下选项: * CLA = ‘00’ * INS = ‘A4’ * P1 = ‘04’ * P2 = ‘00’ * Lc = ‘0A’ * Command data = ’A0000008194B43E282BF’ * Le = omitted (Ne = 0, no response expected) The command data is the international AID for KATP. It consist of a two parts 命令数据是 KATP 的国际 AID。 它由两部分组成： * International RID = ’A000000819’ * PIX = ‘4B43E282BF’ Usage of this AID is subject to the conditions found in the standard document. The RID is assigned to Bitcoin.no AS by ISO. 这个 AID 的使用受到标准文档中的条件的制约。 国际标准化组织 ISO 将这个 RID 分配给Bitcoin.no AS。 ## 1 Get Transaction Template from Wallet 从钱包中获取交易模板 The transaction template is in bitcoin format including version number and nLockTime. 交易模板是比特币格式，包括版本号和 nLockTime。 ### Transfer amount examples 转账金额示例 Payment of 1000 satoshis including any transaction fees. Transfer amount is 1000. 支付1000聪，包括任何交易费用。 转账金额为 1000。 Payment of 1000 satoshis excluding any transaction fees. Transfer amount is 1000 + estimated fee. 支付1000聪，不包括任何交易费用。 转账金额为 1000 + 估计手续费。 Request to send 1000 satoshis to wallet. Transaction fee is paid by the sender. Transfer amount is -1000. 请求发送1000聪到钱包。 交易费由发送人支付。 转账金额为 -1000。 Request to send 1000 satoshis to wallet. Transaction fee is paid by the receiver. Transfer amount is -(1000 - estimated fee). 请求发送1000聪到钱包。 交易费由收款人支付。 转账金额为 -(1000-估计手续费)。 ### Fee estimation 手续费估算 Fee estimation must be done by the terminal before any transaction data is received from the wallet. If the estimate is way off, the terminal can either try to adjust the amount in some of the outputs or retry the session with a better estimate. 在从钱包接收任何交易数据之前，手续费的估计必须由终端完成。 如果估计错误，终端可以尝试调整某些输出中的数量，或者用更好的估计重试会话。 ### PIN 口令密码 PIN is optional. Some cards might require PIN only after a certain amount has been spent. When one of the PIN required status bytes is returned, the terminal must prompt the user for the PIN and retry the session. The PIN code can be any Unicode string, but a terminal will typically only allow entry of the digits 0-9. PIN码是可选的。 有些卡可能需要密码后，才有一定的金额已花费。 当返回一个所需的 PIN 状态字节时，终端必须提示用户输入 PIN 并重试会话。 Pin 码可以是任何 Unicode 字符串，但终端通常只允许输入数字0-9。 When using contactless cards, the card holder might have to tap the card twice. Once to get prompted for the PIN entry and once more to complete the transaction. 当使用非接触式卡片时，卡片持有者可能需要点击卡片两次。 一次获得提示输入 PIN，再一次完成交易。 ### Chunked Response 分块回应 If the transaction template returned from the wallet doesn’t fit into a single response, it will be split into chunks. The terminal retrieves more data by reissuing the command with empty command data. The terminal must support basic transaction parsing in order to determine if the complete transaction has been received. 如果钱包中返回的交易模板不适合单个响应，那么它将被拆分为多个块。 终端通过使用空命令数据重新发出命令来检索更多的数据。 终端必须支持基本交易解析，以确定是否已经接收到完整的交易。 ## 2 Get Public Meta-Key from Wallet 从钱包获取公共元密钥 One intended usage of the public meta-key is for the terminal to embed a receipt into the transaction. The receipt is encrypted using the public meta-key and embedded in an OP\_RETURN out of the transaction. If a receipt is too big to fit into the current transaction, an encrypted link can be embedded instead, e.g. using [b://](https://b.bitdb.network/) or [c://](https://c.bitdb.network/) protocols. 公共元密钥的一个预期用途是用于终端将收据嵌入到交易中。 收据使用公共元密钥进行加密，并嵌入到交易之外的 OP\_RETURN中。 如果收据太大而无法放入当前交易，则可以嵌入加密后的收据链接，例如使用 b: // 或 c: // 协议。 The rationale for this is to allow the user of a smart card, with limited storage, to get a receipt for all purchases. The card holder has paired the card with an app on their smartphone. The app watches the blockchain for transactions signed by the card. The app also has the master key used by the card to derive the public meta-keys. This allows the app to show the purchase including receipt immediately after the card has been used. 这样做的基本原理是允许智能卡的用户在有限的存储空间内获得所有购买的收据。 持卡人已经将卡片与智能手机上的应用程序配对。 该应用程序监视区块链上由卡片签署的交易。 该应用程序还有卡片使用的主密钥，以推导公共元密钥。 这使得卡片被使用之后，应用程序立即显示购买记录和收据。 ## 3 Write Transaction to Wallet 将交易写入钱包 The terminal completes the transaction by adding its own inputs and outputs to the template retrieved from the wallet. The terminal is encouraged to shuffle the order of inputs and outputs to enhance privacy. 终端通过将自己的输入和输出添加到从钱包检索的模板中来完成交易。 该终端是鼓励随机化交易输入和输出的顺序，以提高隐私。 ## 4 Get Signatures from Wallet 从钱包中获取签名 The terminal might have modified the outputs of the transaction template returned by the wallet. Any spend limit checks must be redone, potentially triggering PIN requirement at this stage. 终端可能已经修改了钱包返回的交易模板的输出。 任何花费限制检查必须重做，在这个阶段可能触发 PIN 要求。 ## 5 Get Transaction Hash from Wallet 从钱包中获取交易哈希值 At this stage both the terminal and wallet has a copy of the complete transaction. The terminal should compare the hash calculated by the wallet with its own. 在这个阶段，终端和钱包都有完整交易的一份副本。 终端应该将钱包计算的哈希散列值与它自己的散列值进行比较。 A wallet implemented in a smart card should do any time consuming housekeeping at this stage. 在智能卡中实现的钱包应该在这个阶段做任何消耗时间的整理工作。 ## 6 Commit Transaction to Wallet 将交易提交给钱包 The commit step is the only command where communication failure can result in the wallet becoming out of sync with the blockchain. 提交步骤是唯一一个可因通信故障，导致钱包与区块链失去同步的步骤。 When processing the commit command, the wallet must do as little processing as possible. In practice this means that the next wallet state must be fully prepared and saved into persisted memory during the processing of the previous command. The terminal must never issue the commit command more than once. Adding checks in the wallet to protect against a misbehaving terminal is likely to be counterproductive. It adds complexity to the wallet, with more things that can go wrong. 在处理提交命令时，钱包必须尽可能少进行处理。 在实践中，这意味着下一个钱包状态必须被完全准备好，并在处理前一个命令期间保存到持久内存中。 终端绝不能多次发出提交命令。 在钱包中添加检查以防止终端行为不当可能会适得其反。这会增加钱包的复杂性，并且会有更多的事情可能出错。 Only the terminal should publish the transaction. If the terminal doesn’t receive a successful response from the wallet it assumes the transaction failed. No payment has been made, the customer will not receive any goods or services. 只有终端应该发布交易。 如果终端没有从钱包收到成功的响应，那么它就认为交易失败了。 付款没有发生，客户将不会收到任何货物或服务。 In the worst case the wallet can end up with some transaction in its UTXO set that’s never been published to the blockchain. An online wallet can resolve this by timing out the missing transaction. How fast the transaction is timed out should depend on how confident the wallet is that the transaction hasn’t been published. A highly confident wallet can time out the transaction within a few seconds. 在最坏的情况下，钱包的UTXO集合中会剩下一些从未被发布到区块链的交易。 一个在线钱包可以通过超时丢失的交易来解决这个问题。 交易超时的速度应该取决于钱包对交易未被公布的信心程度。 一个高度自信的钱包可以在几秒钟内将交易设为超时。 译者：wer5lcy text/markdownUTF-8LMKaChing APDU Transaction Protocol Explained (Simplified Chinese Translation)
| Çã
$&zرÌ?èÚlØQ:š‚ó-Æò[@ⴎ9·ðbitpastembtip462 prerender