对于 Alice 发送 BSV 给 Bob 这种常见的使用场景，交易的矿工费一般是由 Alice 也就是交易的发送方支付的。而对于 BIP-270 所描述的支付场景，商户也就是收款方可能更愿意承担这部分费用，替用户支付交易的矿工费来尽可能的促成交易或提升用户体验。
本文将针对收款方如何代付 BSV 交易的矿工费，给出可行的解决方案。
称球问题 - 通解证明和方案构造
抖音上看到的面试题：
有 12 个外观一样的小球，只知道其中一个球的重量与其它球不同。用一个没有砝码的天平，最坏情况下最少要称几次，才能找到这个重量不一样的小球并确定它是偏轻还是偏重。
正确答案 3 次。
水龙头合约
本文将实现一个运行在 BSV 链上的“水龙头”（faucet）合约，它可以满足以下需求：
- 任何人都可以从合约中提取（withdraw）固定数量的 BSV，但连续两次提取必须至少间隔一定的冷却（cool down）时间
- 任何人都可以随时向合约中充值（deposit）
- 部署合约的人可以随时销毁（destroy）合约
BSV 的 nLocktime 和 nSequence
BSV 的创世纪升级，恢复了交易的 nLockTime 字段和交易输入的 nSequence 字段的原始功能。这两个字段会共同决定交易的“最终性”（finality）。
计数器合约详解
在文章有状态的 UTXO 和 OP_PUSH_TX 的技术原理中，我们提到了计数器合约，它可以把自己被调用的次数记录在链上，具体为：
- 有一个 UTXO 被称作计数器合约，状态初始值为 0
- 该 UTXO 被花费时，必须生成一个新的计数器 UTXO，并将之前的状态值加 1 记录到新的 UTXO 中
- 规则 [2] 由矿工验证，如果没有生成符合要求的新 UTXO，就无法花费当前这个 UTXO
本文将介绍该合约 5 个不同版本的实现，带你了解如何使用 sCrypt 在 BSV 上开发智能合约。
BSV 交易签名相关的技术名词
在介绍 BSV 交易的签名时，出现了不少技术名词。可能有一些历史原因、翻译的差别，抑或是习惯叫法的不同，导致大家给同样的东西起了不同的名字。这虽没有大的问题，但十分影响交流。
本文将试着对签名相关的技术名词做一个梳理和对应。
有状态的 UTXO 和 OP_PUSH_TX 的技术原理
一般都认为，UTXO 是“无状态”的。对于生活中常见的支付场景，币转出后就意味着失去了对这些币的“控制权”，收款人可以随意支配收到的 BSV。
那 UTXO 可以做到“有状态”吗？
本文将介绍“有状态” UTXO 的实现原理。请在继续阅读前，先理解 OP_CHECKSIG 操作码的工作方式。
操作码 OP_CHECKSIG 和 SIGHASH 标记
锁定脚本中的 OP_CHECKSIG 操作码，会要求解锁脚本能提供正确的 ECDSA 签名。
验证 ECDSA 签名是否有效，需要三个参数：公钥、签名和被签名的消息。对于 P2PKH 这种最常见的使用了 OP_CHECKSIG 的交易模板：
[签名] [公钥] OP_DUP OP_HASH160 [公钥哈希] OP_EQUALVERIFY OP_CHECKSIG |
脚本中并没有直接提供被签名的消息的内容（P2PK 也是这样）。实际上，解锁脚本中的签名数据，由两部分构成：
- 按 DER 格式序列化后的 ECDSA 签名
- SIGHASH 标记
在之前的文章中我们提过：“交易中被签名的消息，是交易本身。更准确的说，是通过 SIGHASH 标记区分的、交易中特定的数据子集”。交易本身在签名和验签时是已知的，也就是说，虽然脚本中没有直接提供消息的内容，但存储了能间接推算出消息内容的 SIGHASH 标记，它可以指示 OP_CHECKSIG 如何根据交易本身计算出这个消息（交易摘要），进而完成 ECDSA 的验签。
这篇文章，将介绍操作码 OP_CHECKSIG 的工作方式，以及 SIGHASH 标记的技术细节。
BSV 脚本里的整数
BSV 脚本里被送到栈上的数据，其数据类型都是字节序列（数组）。对于 OP_ADD 这类算术运算操作码，是如何将字节序列转成有符号整数的呢？
简单来说，只有两点：
- 如果这个数据会被解释为整数，则使用带符号位的原码（signed magnitude）格式，编码成最短的小端字节序列
- 编码后的数据（字节序列）通过 pushdata 上栈
因为本质上还是使用 pushdata 并且这部分脚本会被执行，所以需要遵守“最小推送”（minimal push）规则。