上一篇文章我们介绍过了关于区块链地址标签的一些基本概念。
地址标签可以说是链上数据分析最为重要的基础数据之一，地址标签的应用场景也非常广泛，比如对恶意地址的资金流向分析、或是针对某些特定任务或巨鲸的地址做资金流入流出预警，这些都需要地址标签数据。
知名的 Whale Alert 就是专门针对主流区块链项目的链上资金变动进行告警的产品，其预警信息中最大的价值就在于对资金流向的判断会有地址属性的说明 —— 流出某交易所、流入某交易所、某个事件中涉及的资金异动等等：
从这一篇开始，我们就介绍几种最简单的地址标签识别思路。大家也就可以据此去开始着手打造自己的链上追踪能力了。
今天先从地址类别开始讲起
这是最简单的方式了，肉眼即可完成、使用正则即可批量完成，主要应用于BTC。在BTC地址中，可以根据格式分为几类常见地址：
地址以1开头，为P2PKH
地址以3开头，为P2SH
地址以bc1开头，为Bech32
那么，这几类分别是什么？首先需要先明确在BTC中的两个概念：
什么是Public Key
安全领域的读者都应该很清楚什么是非对称加密，非对称加密中会产生一对key，分别是 Private Key （私钥）和 Public Key（公钥）。私钥需要私密保存、公钥可以任何人持有。使用私钥对某段内容进行签名后，持有公钥的人可以验证该签名内容的来源属实，这就是数字签名的过程；
区块链，此处尤其特指 BTC，它的交易实现逻辑就来自于数字签名，私钥持有者对交易进行签名，签好的数据在共识层面会用公钥进行验证，数字签名没问题那就是说你确实拥有这个地址的私钥，允许上链；
所以，我们可以这样简单的理解：在区块链世界里，Public Key 就是你的钱包地址，Private Key 就是你的钱包私钥（当然，真实世界中会比这个复杂一些）；
什么是Script
BTC 的脚本可以理解为对交易的一种控制语言，只不过这种脚本语言相对我们平时使用的诸如Python、JS等脚本要简单的多。最常见的脚本会出现在 BTC 交易的输入输出中，输入中的脚本会告诉交易我要用哪笔钱付款、输出中的脚本会说明这笔交易的对手方是谁。关于脚本更复杂的细节在此不再展开。总之，大家只要了解，脚本通过某种特定格式来描述并帮助 BTC 完成了每一次交易即可；
有了以上两个基础概念，就可以对刚才遗留的几个疑问展开说明了。到底是什么 P2PKH、什么又是 P2SH 等等问题：
P2PKH 是 Pay to Public Key Hash 的缩写。
如果 Public Key 就被简单粗暴的理解为钱包地址的话，那么 Public Key Hash 就可以更粗暴的理解为对地址做了一次 HASH 计算，那么，Pay to Public Key Hash 的理解是不是就很简单了？
为什么要对 Public Key 做 HASH 呢？这可以防止一种极端场景。比如，产生公私钥对的算法出现了漏洞，那么可能拿到 Public Key 便可破解出 Private Key，而在 BTC 的世界里拿到了 Private Key 就是相当于拿到了钱包的所有权。所以考虑到极端情况下，对 Public Key 做一次 HASH 计算得到 Public Key 的密文，这样即便算法出现漏洞，想要通过密文得到 Public Key 的明文也是有一定难度的。这就在一定程度上加了一道双重保险。
在 BTC 世界中还有一种更简单的格式，便是P2PK，了解了 P2PKH 之后再理解 P2PK 就容易多了，就是少了个 HASH 过程，直接暴露 Public Key。
P2PKH 这种严谨的方式便是 BTC 最早的地址格式，至今也依然在沿用。
P2SH是Pay to Script Hash的缩写。
使用 P2PKH 地址转账时，其他本质依然是向一个固定的 Public Key 转账，而每个 Public Key 与 Private Key 的对应关系又是唯一的，即，只能由一个人来控制。因此就是带来了一个问题，如果当我们的交易需要一个人以上授权的时候怎么办？
所以就有了 P2SH，P2SH 本质上就是将 Public Key 换成了 Script。也就是说，控制过程不再是一个公私钥对的方式，而是可以通过脚本对控制过程进行编程，那么，就有了一种可能性，控制钱包的人不少一个人而是很多人。
所以，P2SH 地址常用于多签，即，多个人出示了自己的 Private Key 进行验证之后，这笔交易才能够被发送出去。
第三种格式，Bech32格式。
它与前两种格式地址截然不同，是专为SegWit开发的地址格式，不区分大小写，有固定的地址前缀便于识别。SegWit 来自 Segregated Witness 的缩写，中文称“隔离见证”。是 BTC 的一种扩容方案，简单来说就是把原来 BTC 交易的数据结构做了一些拆分。有兴趣的读者可以去看看细节。
以上对三种地址格式做了介绍。可能不熟悉交易细节的读者依然无法理解，这么简单的地址标记逻辑，在实际应用中真的有用吗？好，举例说明。
以最典型的 P2SH 为例，我们来找一个3 开头的地址：
36KAwNUR8VeLpUfGwdk7LEN6F4yvoRWMjn
从这个地址的交易中抽取一个哈希为36a4daa66e7d4892adc662f8dbf2429f5567a686f2e7fc45e48df4f4f0723e44的交易，如下图：
从这个交易中可以提取它的Redeem Script 信息（图中被圈红色的部分），通过BTC节点的RPC方法decodescript（hexstring）：
$ curl --data-binary '{"jsonrpc": "1.0", "id": "curltest", "method": "decodescript", "params": ["522102bca8b2795561f5822e68ac75f1ec253285b8d22bd7648c1b905509517e3d5a7a210363598b591b5fe2eba9322a1b6e55f6bfc3fc27f8060e3de7240e1de67f8adae62103a6890dff6fbf2c897b1e578b6cbe6e5dd6c7652f538162a851410270cb4b106a53ae"]}' -H 'content-type: text/plain;' http://your_bitcoin_node_rpc_url | jq
即可解析出这个交易背后的“真相” —— 即，发起交易的地址是一个多签地址，其背后还有三个权限地址：
`{` `"result": {` `"asm": "2 02bca8b2795561f5822e68ac75f1ec253285b8d22bd7648c1b905509517e3d5a7a 0363598b591b5fe2eba9322a1b6e55f6bfc3fc27f8060e3de7240e1de67f8adae6 03a6890dff6fbf2c897b1e578b6cbe6e5dd6c7652f538162a851410270cb4b106a 3 OP_CHECKMULTISIG",` `"reqSigs": 2,` `"type": "multisig",` `"addresses": [` `"1HfoxzkAwMpF1TrNceEY9EHZi2qGgmtDCi", //多签地址1` `"1Au8p4wagsHM5Ph6CAmDkQqdzeXspLypob", //多签地址2` `"1NLHhwxYj4ETz2qH3twycFyPSKNy1aTmoc" //多签地址3` `],` `"p2sh": "36KAwNUR8VeLpUfGwdk7LEN6F4yvoRWMjn"` `},` `"error": null,` `"id": "curltest"``}`` `
从以上结果来看：
type中的 multisig 告诉了我们这是一个多签地址
addresses 中则告诉我们了这个多签地址背后的三个权限地址
而 reqSigs 则告诉了我们至少需要 2 个地址同意才能发起交易
所以，在这一个过程下来之后，我们至少为这个地址获得了两个标签 —— P2SH 和 多签地址 —— 而同时我们又获得了三个权限地址及其对应标签。
当然，至于多签地址这一标签的应用，会涉及到很多不同的追踪场景，例如，多签地址的上游地址，很可能会具备很强的中心化平台特征或是个人投资属性特征，这些特征都需要放在具体场景中去使用和分析。
至此大家也可以看出，地址标签实际上在多数情况下只作为第一层数据而已，在不同的应用场景下，可以在标签基础上深挖出第二层、第三层 …… 越深入，内容越丰富，价值越大。限于篇幅在此先不展开，后面的各类实战介绍中会陆续有所涉及。