部分签名交易（Partially Signed Bitcoin Transaction, PSBT）是在 (BIP-174)[https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki] 中提出的一种交易格式，它使得用户可以对交易中的一部分输入进行签名，最后和其他用户的输入一起组成新的交易。这种交易格式的应用在于： 离线钱包签名：观察签名进行交易的构造，随后由冷钱包完成签名，最后再广播到节点上，从而保证冷钱包的安全性； 多方交易：多个签名者之间传输交易，最后组成新的交易； NFT 市场：现有的铭文协议中，通常使用 PSBT 来构建买卖双方的交易，由 Dex 完成组装后完成双方的交易； PSBT 规范PSBT 的格式由一系列的键值对映射组成，键值对由 0x00 作为终止符，其二进制下的å格式如下[1]： 1<psbt> := <magic> <global-map> <input-map>* <output-map>* 依次对应每个值，有： 1234< ...

毕业设计相关的内容查了一些论文，好像也没有什么太多的发展，基本上都是2009年左右的内容了，算是稍微整理一下。 自主引导问题：端到端网络（Peer-to-Peer, P2P）网络通常需要一个或一组引导（Bootstrap）节点。在 P2P 网络中，引导也是唯一一个中心化的任务，新节点需要依赖引导节点的帮助来发现其他的节点并建立连接。现有的 P2P 系统会在软件内置一个引导节点列表，新节点在启动时通过这个引导节点列表依次去请求加入网络。那么，是否存在一种技术，使得运行同一个 P2P 服务的节点可以直接发现其他同类节点，而不需要引导的帮助。 随机地址探测一种暴力的地址探测方法[1]，即在固定端口下随机抽取 IP 地址进行探测，运行了同样 P2P 应用的主机会进行响应 但是这样的方法只能适用于规模较大的 P2P 网络，例如 BitTorrent 基于 IPv6 的随机地址探测IPv6 简介IPv6 地址[3][7]的长度为 128 bits，在实际使用的时候写为 16 进制的字符串，每 32 bits 作为一个分组，以冒号作为分隔符 即每个 IPv6 的地址的通用格式为 x:x:x:x: ...

锲子 这篇游记本来是没有打算写的，过去两周后的现在还是觉得比较值得回味，所以就简单地记录一下。 原本预想的是把五一的假期挪到五月底跟着研三的师兄们出去玩，结果去新疆的师兄们行程太长，其他的师兄也没动静，就变成了笔者自己规划的一趟反穿川西小环线。 在临出发之前问了一下在华科的学长有没有想法，所以这一趟行程就是两人一车。 笔者前面几次环线的规划都只是用高德地图画一下路书，然后查查途径点的店，做个收藏点就完了 这一次尝试着用 notion 来规划，发现它的整合功能还是强大很多，也算是趁着这个机会入门 分享一下行程规划的工具： Google XML 路线绘制与导出：My Maps - Google Map 高度图生成：导入 XML 路径文件到 Google Earth 后可以生成高度信息（这个便于看一路上的海拔信息，特别是在川西这种海拔落差比较大的地方很实用） 路书绘制：高德地图 整体行程信息汇总：Notion 天气、云图观测：Windy 通常的小环线攻略是三天的行程：成都-小金/丹巴、小金-塔公-新都桥、新都桥-折多山-泸定-成都 考虑到是头一次走这个路线，就把行程反了过来，然后 ...

0515815a90f71d2e69c573efde1c8119e11756a259a45a05da84968fe21b60f5ebb9d9e79c495841ecd37137e644752b95910b7ad710a4a1a30f4e9bd9e53449e2f0849a09ddde8725219cc521b247b6f79d99004148cc4fbc3b90ac2df3385eb30d4523ed1fb5a6544da48a70173f5aab4911f735bd3ef107e6e575d611b2477cdbcf313b4961092aa37143fa78a913415ef2fd905878b6a86726b1186d14f5cd9bd94db842bcaf7639dd9f6d3c62c86be384a2dcef6f5709fcfe7bedc5c396828ff6f118a41a355b62560e472d857db6098d1193fa438546a994f08cf3ca40c641597a592a7a06d2d639f7680e30b30c05c19ba720c0edb ...

Schnorr 签名为了简便起见这里都用大整数取模运算下的方式来说明签名、验证过程，签名算法也可以同样地在椭圆曲线上实现 签名及验证Schnorr 签名的单一签名过程较为简单，它涉及到的函数只有哈希函数 $H$ 将消息映射为一个大整数，同时所有的运算在群 $G_p$ 下完成，$p$ 是一个大素数，$G_p$ 的生成元是 $g$​ 签名流程 Schnorr 签名方随机选取一个大整数 $x \in G_p$ 作为私钥，在群 $G_p$ 上运算 $y=g^x$ 作为它的公钥，同时签名方为消息 $m$ 进行签名 签名方选取随机数 $r \in G_p$，计算 $R = g^r$ 签名方计算哈希值 $e = H(y||m)$ 通过 $r$ 和 $h$，计算 $s=r+ex$ 最后得到签名为 $\sigma = (R,s)$​ 这个过程表示为 $\sigma \leftarrow Sign(x,m,r,pp)$，$pp$ 是公开参数，包括群的相关信息以及哈希函数 签名验证 在签名验证方，它所具备的公开信息有签名方的公钥 $y=g^x$，签名消息 $m$ 以及签名 $\sigma=(R,s)$， ...

info由于 Bitcoin 中的支付类型众多，这也导致地址各式各样，在 btcd 中提供了不同的函数来为公钥生成不同的地址。 这一篇作为 btcd：Golang 下的交易构建 的补充，说明各种支付方式和地址类型。 另外，这篇博文的大部分内容对应 Learn me a bitcoin [1] 的 Script，所以这篇博文更像一个学习记录 ScriptScript is a mini programming language used as a locking mechanism for outputs in bitcoin transactions. 脚本是一种迷你程序语言，用作比特币交易输出的锁定机制。 在每笔交易的输出上都会由一个锁定脚本，它对应了输出中的 $ScriptPubKey$ 字段； 每笔交易还需要提供对应每个输入的解锁脚本，用于在这笔交易中解锁前一笔交易的输出，这对应了输入中的 $ScriptSig$​ 字段； 锁定脚本和解锁脚本在比特币中体现为二进制形式混合的操作码和数据，并且通过运行时栈来运行，如果最终栈内的唯一元素是OP_1或更大的元素，那么脚本就是有效 ...

锲子 参与 Bitcoin 的相关生态难免需要涉及到链上的操作，相比于 Ethereum 这样简单的交易发送机制，Bitcoin 上构建交易则需要一定的编程能力，这篇博文记录一下 Bitcoin 上构建交易的各种姿势。（博文不间断更新） 这篇博文的前置知识：UTxO、交易结构与脚本语言，可以在 Learn me a bitcoin 学习，另外： 测试网交易池可视化：https://mempool.space/testnet 测试代币水龙头：https://bitcoinfaucet.uo1.net/ 测试私钥生成（主网尽量不要使用）：https://iancoleman.io/bip39/ golang 下的 Bitcoin 工具库为：github.com/btcsuite/btcd 简单交易的构建私钥与地址生成私钥生成私钥有多种形式，在 Bitcoin 中最为常见的是 WIF （Wallet Import Format）格式的私钥，也有 16 进制的私钥，这些私钥之间是可以相互转换的 事实上目前的大多数钱包插件都不支持 WIF 格式的私钥导入，只能使用一些软件钱包才能导入。 ...

做区块链相关的项目难免会遇到需要构建一个 P2P 网络的时候，去年这个时候在 python 上使用的是一个已经停止维护了很久的 Kademlia 库；在今年转到 go 之后就注意到了 go-libp2p 这个库。go-libp2p 源自于 IPFS，它是用于构建 P2P 网络的模块化网络堆栈和库，功能特别强大，但是坑也特别多，主要的原因还是资料和文档都很少。在使用了一段时间后还是觉得需要写一篇博文来记录，还可以作为以后的一个文档吧。 对于 go-libp2p 的不同模块，可以参考 长安链P2P网络技术介绍（2）：初识LibP2P[1]。当然，这是一个很笼统的介绍，而这篇博文也会比较简单（毕竟它所拥有的功能太多了），只会记录笔者所使用到的一些功能：连接建立、流处理、节点发现、消息广播及配置、资源限制；同时，官方的库中也有一些样例可以参考：examples - go-libp2p，这篇博文的完整代码可以在 libp2p-example 查看 连接建立先从最简单的 echo 功能开始：两个节点 A 和 B 在建立连接后，节点 A 向节点 B 发送消息 msg，节点 B 也返回消息 msg ...

Prometheus 是由 SoundCloud 开源的监控告警解决方案[3],它可以被用于程序暴露一系列监控指标给外界，用于对程序的性能、运行状态进行监控，并且还提供了监控告警功能。 基本架构以下是官方给出的架构图 在图中，Prometheus 的组成部分有[3]： Prometheus Server：抓取和存储时间序列化数据 Exporters：主动拉取数据的插件 Pushgateway：被动拉取数据的插件 Altermanager：告警信息发送模块 Prometheus web UI：界面化，包含结合 Grafana 进行数据展示或告警发送 其工作逻辑如下[4]： Prometheus server 定期从静态配置的目标（target）或服务发现的目标中拉取指标（metric）数据； 拉取数据大于内存缓冲区大小时，将数据持久化到数据库（时序数据库）； Prometheus 可以配置规则，用于定时查询数据，在条件触发时将警告推送到配置的 Altermanager； Altermanager 受到告警时，可以根据配置，聚合、去重、降噪，最后发送警告； 可以使用 API、Pr ...

Json Web Token (JWT) 是一个开放标准（RFC 7519），它符合设计 Restful API 时的无状态原则，每一次从客户端向服务器发出的请求都是独立的。 JWT 由三个部分组成：Header、Payload 和 Signature，它是一个长字符串，每个子串之间不存在换行符，一般的格式是[Header].[Payload].[Signature] 其 Header 承载了两部分信息：类型和所使用的密码算法，例如 1234{ "alg": "HS256", "typ": "JWT} Payload 存放了实际需要传递的数据，JWT 中所规定的 7 个可选用的常规字段如下，负载默认是不会进行加密的，所以不可以用来存放秘密信息 Field Name Desc iss Issuer 签发人 exp Expiration Time 过期时间 sub Subject 主题 aud Audience 受众 nbf Not Before 生效时间 ...