Blog · Jingyu Liu

ChaumMian CoinJoin

Thu, 26 Oct 2023 10:34:07 +0800

目标：构建一笔 bitcoin mixer 交易, 打乱 Inputs Outputs 的关联.
前置知识
- Coinjoin
- UTXO
- 盲签名介绍：
  - https://mp.weixin.qq.com/s/gjmWhFVBpVrbW_wCd7UucA
  - UnBlind ( Sign( Blind(msg) ) ) = Sign(msg)
参与者：
- 用户
- coordinator: 一个无需信任的第三方
为了简单起见，假设池子的单位为 1 btc，全部使用 P2PKH 的方式进行转账。参与者 alice 想要自己的 addr1 的 tx ouput（大于 1btc ）当中转 1btc 到 bob 的地址 addr2 当中
过程
- alice 使用某个匿名的网络 id1 连上 coordiantor（tor etc）
- alice 向 coordiator 证明自己可以解锁一个未使用的 ouput（大于 1btc ）OP1
  - alice -> coordinator: 我拥有地址 addr1, 可以解锁 OP1 ( 使用 pk 就可以证明)
  - coordinator -> alice: 麻烦您签个名，我认证一下哈
  - alice -> coordinator: 签名消息
  - coordinator 验证成功
- alice 向 coordiator 发送 bob 公钥的盲消息 M1 = < Blind(Hash(addr2.pk)) >
- coordinator 对 M1 直接签名，并向 alice 返回签名消息：M2 = Sign(Coordinator.sk, M1)
- coordinator 向当前池子 tx 的临时 outputs 当中加上一条对 alice 的找零 output
  - OP_DUP OP_HASH160 <Hash(addr1.pk)> OP_EQUALVERIFY OP_CHECKSIG
- alice 在网络 id 1 下线，更换 id2 连上 coordinator（tor etc）
- alice 对 M2 去盲得到 M3 =Sign(Coordinator.sk, Hash(addr2.pk)),并把 M2 和接收者的公钥哈希发送到 coordinator
- coordinator 用自己的私钥验证，发现自己的确对这个接收者签了名
- coordinator 向当前池子 tx 的临时 outputs 当中加上一条对 addr2 的 1btc 转账
  - OP_DUP OP_HASH160 <Hash(addr2.pk)> OP_EQUALVERIFY OP_CHECKSIG
- 当 coordinator 发现池子足够大的时候把完整的 outputs 发给所有的该池子的用户，要求所有的参与者签名，锁住 outputs（此时 outputs 不会在添加了）
- alice 从网络 id2 下线，更换 id3
- alice 接收到了完成的 outputs，作了个简单的算术，发现自己的两笔转账都在里面（一笔 1btc 给bob 的，一笔找零给自己的）满意地签了名，把签名和自己的公钥（addr1.pk）发给 coordinator
- coordinator 收集到了所有的签名，构建了所有的inputs ，把完整的池子 tx 发送到 btc 网络上，完成交易
- 待交易确认之后，bob 可以向正常使用 P2PKH 一样使用 alice 的转过来的 1btc
匿名问题：有谁知道转移对？
- alice：alice 作为发起人，当然知道
- bob：如果bob 只知道链上的消息，bob不知道这笔钱是 alice 给转的。但是alice 和 bob 往往在链下有联系（要不然为什么要向bob 转账呢？除了投毒攻击，甚至往往可能是同一个人。
- coordinator:coordinator 知道所有 input 对应的公钥. 由于 alice 使用两个不同的网络 id 发送 M1 M3. coordinator 无法将 M1 和M3 关联起来，除非 coordinator 关联了 id。
- 混币池子里面其他的用户：无法知道其他的转移对，只知道完整的整个池子的转移
- 其他人：更加无从得知转移对。
破解匿名的方法：
- 网络层面关联 id1 id2
- coinjoin 常规攻击：在一个池子当中混入足够多的内鬼交易对（可以被攻击者知晓的交易对），可以暴露其他混币者的转移对。
安全问题：
- alice 怎样不会被 coordinator欺骗？
  - 在整个交易过程当中，alice 只签名了两次
    - 第一次签名用于证明了自己掌握了某个 output，过程与使用钱包连接dapp的过程一致，签名消息都是明文。
    - 第二次是对整个池子 coinjoin 进行签名，alice只要验证钱是否有足够的钱转到 bob 和自己的，就可以签名了。
- coordinator 怎样不被用户欺骗？
  - Coordinator 会对所有用户合格用户进行一个盲签。在我们举的例子当中，coordinator 会对所有 160 bit 的消息进行签名。
- 混币池子里面其他的用户：无法知道其他的转移对，只知道完整的
- 盲签的安全性:
  - 为了防止攻击者构造特殊的hash攻击让 coordinator 签名，盲签采用的签名方法应该与 btc 网络当中的签名方法完全不同，这样攻击者无法伪造 tx 签名。

参考链接

Taproot Asset 快速上手体验

Fri, 20 Oct 2023 10:34:07 +0800

参考学习

taproot asset 介绍:
- https://www.btcstudy.org/2022/04/08/how-bitcoin-taro-protocol-works/
- https://www.btcstudy.org/2022/04/07/announing-Taro-a-new-protocol-for-multi-asset-bitcoin-and-lightning/
taproot asset 文档
- https://docs.lightning.engineering/the-lightning-network/taproot-assets
taproot asset demo
- https://www.youtube.com/watch?v=JNaryHu2mFc
- https://www.youtube.com/watch?v=xtklaJHfKIY

安装与配置

docker
docker compose/ docker desktop
polar:
- https://github.com/jamaljsr/polar
- linux 下可能要注意 docker volume 没有权限读取的问题, chmod chown 一下就行
btc exporer
- https://github.com/janoside/btc-rpc-explorer
- 主要用来看一下 bitcoin regtest 链上信息.
- 需要根据 bitcoin core node 的 rpc 相关信息配置一下 .env 文件:

简单的 mint transfer test

下面我将使用 Polar 测试 Taproot asset, 测试网络结构如下:

当用户相信 Defi 与传统金融服务具有相同的安全性时会发生什么?

Tue, 17 Oct 2023 10:34:07 +0800

本文探讨的 defi 均是指基于账户模型智能合约形式 defi protocol: uniswap, aave, compound, maker dai 等.

主流 defi 应用的合规化是不可避免的
- 当今主要的 defi 合约都部署在基于 PoS 相关算法的 L1 或是基于此类 L1 的 rollup 上
  - L1 质押中心化
  - L1 结点的中心化
- Defi 治理团体的实体化
  - 例子:
    - Makerdao RWA
    - DAO as LLC at some states in the US
- defi 本质是提供一种金融服务, 所有服务必然 Liable, 即服务的提供方必须对自己提供的服务负有责任.
  - 在一个法治国家, 现实生活中所有的服务都是需要接受监管, 即使该服务是非盈利性质的.
  - 监管是对"民众对服务安全性的要求"的共识的执行.
- 前两点阐释了合规化的可实现原因, 最后一点实现了合规实现的动机
合规化/审查可能会发生在哪些层面?
- Consensus Layer:
  - 对 validator 的审核(比如 kyc);
  - 对 p2p 网络的审核 (屏蔽某些地区的结点);
  - 所有结点对交易进行一定审核(相当与一套对交易的共识规则);
  - 配合监管方进行 fork, 类似 2016 The DAO Fork;
- Execution Layer: 单个结点( sequenser, block builder…) 对交易的审核
- Protocol Layer: defi protocol 对交易进行审查
- Frontend: UI 前端对交易进行审查
那些实体有被监管的风险?
- 所有使用者
- Governance Token 持有者
- 受雇佣于某个 DAO 的实体: 开发者, 律师, 交易员等等.
如果要对 defi 达到传统金融服务相同的监管力度, 需要哪些层面的监管?
- 不幸的是, 如果我们仅仅思考现实世界 “银行经营需要政府颁发执业许可” 这一条要求, 就会发现我们需要在 consensus layer 实现审查. 具体来说, 制定一条如下的规则:
  - “审查每个上链的合约, 判断是否为银行合约(lending protocol like aave, compound…), 如果是的话就要检查该合约是否合规”
  - 而"合规性检查"进一步会对该 protocol 的发行方进行审查(显然需要发行方进行 KYC)并要求该 protocol 满足反洗钱要求.
悲观的看, 如果政府使用相同的监管力度约束 defi 服务, 那么 defi 寄生的链将会直接变成一条联盟链, 所有 defi 的用户都要进行 KYC.
幸运的是, 区块链在执行层上的无需信任性与透明性(或是可证明性在某些隐私链上)给予了 defi 更为宽松的监管力度, 使得 defi 可以在更低的审查力度下, 更低的监管成本下运行.
- 让我们再回顾一下政府(民选)监管的目的: 让民众感到安全. 这是一个非常主观的而且变化的指标.
- 面对一个每时每刻公开自己的账本的金融服务商(而且保证为真)和一个每年公开自己账本(还不知道增加)一次的服务商, 前者显然在更宽松的监管下可以给与后者一样安全感.

总而言之, 相较于传统金融服务, defi protocol 依靠其无需信任性与透明性溢价, 换取了更为宽松的监管力度, 从而进一步换取在流动性与开放性的优势. 至于能换来多少优势, 取决于到底要大多的监管力度才能让用户感到安全. 下面是几种可能的形态:

Byzantine Consensus under Static Peer Assumption

Fri, 06 Oct 2023 10:34:07 +0800

Some notes for the book “Foundations of Distributed Consensus and Blockchains” by Elaine Shi

What is a Byzantine Fault?
- Crash Fault: Adversarial nodes do not send or receive any messages.
- Omission Fault: Adversarial nodes selectively choose to drop or let through each message sent or received.
- Byzantine Fault: Adversarial nodes can deviate from the protocol arbitrarily.
What is static assumption?

如何利用 zk-snark 解决 Mental Poker 问题

Sun, 10 Sep 2023 10:34:07 +0800

最近读到了几篇很有意思的文章, 讨论的是如何解决 Mental Poker 问题.

Mental poker 问题是由 Rivest, Shamir and Adleman 三位密码学家于1979年提出 (就是 RSA 的那三位). 简单来讲, Mental Poker 问题可以理解为是在没有 “性感荷官” (一个 private 可信的第三方) 的场景下,进行扑克游戏. 下面的讨论我们将默认该 poker 游戏使用德州扑克的规则.

xv6 file system

Fri, 01 Oct 2021 10:34:07 +0800

xv6 File system overview

In general, There are 3 different ascpect on unix-like file system, file descriptor, file/directory and block. In xv6, they are distributed into 7 layers:

Block interface

The xv file system’s block interface consists of 34 layers(disk, buffer cache , logging and bitmap) Goal: achieve crash recovery

MIT xv6 design from user prespective

Fri, 01 Oct 2021 10:34:07 +0800

I will use mit 6.s801 lab1 “util” as an entry to the code behind. This article will not talk much about how to do lab1, but reveal some delicate design behind the syscall lab1 use.

Ubuntu

Mon, 23 Nov 2020 21:30:32 +0800

outline

硬件准备
clash on linux
开发环境搭建

硬件准备

灵越 7590 ， windows 系统盘 ssd + sn750 空盘
bios 中，把硬盘模式调到achi ，关闭security boot ，关闭 windows 快速启动，打开legency boot
插入ssd，windows中初始化硬盘，不分区
制作iso启动盘
进入bios，打开boot sequence ，把usb/boot//grub.efi加入boot 列表
f12，引导选择，清空ssd sn750 ，安装ubuntu

clash on linux 搭建

安装git vim ，解决raw.githubusercontent.com dns 污染问题（在hosts中加入ip）（更改为aliyun 的源）
安装 clash on linux ，解压tar
给clash 赋予对应权限
启动
找到.config/clash 中的config.yaml 和 country.mmdb 文件（前者为代理服务器文件，后者为ip分流文件）
从服务商获得yaml文件，和mmdb文件，替换原文件
clash 运行
打开clash.razord.top 进入控制面板（使用chrome 不要用firefox，firefox在会出现验证障碍）
把proxy 中继指向config.yaml对应端口（127.0.0.1:0000)

环境配置

zsh 配置（注意dns污染问题

春梦的联想

Tue, 03 Mar 2020 20:02:36 +0800

这个春日的午后

很温暖

窗外

每栋楼上，影子的边缘都格外清晰

不知名的鸟在空中盘旋