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