那朵花，一定还在某处继续绽放着。 如果不是因为在 16 岁的那个夏天点开《未闻花名》这部动漫，或许一辈子也不会知道秩父这座小城，也不会在八年后的初夏来到这里。在那个年纪初看动漫时并没有得到很大的触动，随着年龄的增长反而开始缅怀这样的青春和友情了。在去到秩父市之前已经在日本玩了一周，从福冈一路北上刚到东京。东京也有很多经典动漫的取景地，但是太多太杂，并且在东京又开始感受岛熟悉的大城市的感觉和“班味”，所以并没有在东京逛太多地方。而秩父这样的地方很能满足我对小城市在心理上的偏爱，所以在东京的三天时间单独留了一天来逛一下这座小城。 很有意思的是《未闻花名》最开始就有在动漫里提到秩父，也就是封面图的秩父牛奶，但是刷过很多次也没有留意过地名。 从东京去秩父最方便的就是搭乘电车，在池袋站出发搭乘西武铁路可以经过一次换乘后到秩父，电车的时刻信息可以在雅虎的【换乘案内】应用上查到（iOS 需要日区账号下载，新干线、JR 的交通信息也可以在上面查询）。圣地巡礼也少不了一个地图，最方便的自然就是巡礼地图 anitabi.cn 了，可以查到大部分动漫的取景地信息。 在巡礼之前查询到的信息都说可能 ...

深入学习一点 Solidity 的优化方法，不然很多时候书到用时方恨少，主要内容来源于 The Optimization Iceberg 还没完全写完，有空了再补充（挖坑） 数据存放原理在 EVM 中，存放数据的位置有 stack、calldata、memory、storage、code 和 log stack：即运行时栈，用于保存 EVM 指令的输入和输出数据。stack 的最大深度为 1024，在运行的时候只能访问栈顶的 16 个元素[1]，每个元素的长度为 256 bits; calldata[3]：函数调用的输入，对应的是交易的 data 域。在正确调用合约时，calldata 的前 8 个字节用于指定函数，后跟的数据用于存放调用参数； memory：临时的数据存放区域，在函数运行期间存放数据，在函数结束运行后销毁。在运行前 memory 是空的，每一次需要使用 memory 时会进行扩容，如果访问 memory 的数据超出页面大小，它会自动增大 32 字节，扩容需要耗费 gas[2]； storage：用于对数据进行持久化的存储，它以数据槽（slot）为单位进行数据的存 ...

应用程序中的插件功能可以通过 4 个基本概念来描述[1]： Discovery（发现）：用于正在运行的程序找出它可以使用哪些插件的机制，需要给应用程序指定查看什么位置（工作路径）以及需要查找什么； Registration（注册）：用于插件告知应用程序 - I’m here, ready to do work 的一种机制，将插件载入到应用程序中； Hooks（挂载点）：插件可以将自身”附加”到应用程序的位置，表明它可以获取信息并参与流的范围，挂载点的确切性很大程度上取决于应用程序的设计。这个过程时插件注册自己的功能到应用程序，再由应用程序调用插件的方法（应用程序 -> 插件）； Extension API（扩展 API）：应用程序需要公开插件可以使用的 API，用于授予它们对应用程序的访问、调用权限。这个过程是应用程序提供一些方法给插件，插件再运行时进行调用（插件 -> 应用程序）； Golang 中的插件可以根据实现方式划分为三种：编译时插件、运行时插件、远程调用插件 远程调用插件通常通过 IPC、RPC 或 TCP 通信的方式来实现，插件作为一个独立的进程在本地 ...

部分签名交易（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 格式的私钥导入，只能使用一些软件钱包才能导入。 ...