创建具有找零地址的交易
之前的文章讲了构建裸交易的过程，但是上文直接构建裸交易是没有创建找零地址的，所以输入和输出的差值都会成为矿工的交易费。极容易造成高额的交易费，所以这篇文章在之前的基础上使用 fundrawtransaction 来创建具有找零地址的交易。 先列出主干 创建一笔没有输入的交易 添加充足的未签名的的交易来满足交易需求 签名 广播 具体过程 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101111121131141151161171181191201211221231241251261271281291301311321331341351361371381391401411421431...
使用比特币节点进行交易
使用比特币节点进行交易如果读过之前的完整的一系列文章，应该已经经历了从节点源代码编译，运行，和配置 rpc 的完全过程，本文在之前工作的过程上进行总结，使用比特币节点发起一笔交易。 注意：读了之前的文章也应该清楚一点，比特币节点代码和 rpc api 更新较快。本文依赖比特币 0. 18 版本，系统环境乌班图。 比特币发起交易步骤首先列出比特币交易的最主干的过程如下 提取UTXO 发起交易 对交易进行签名 广播交易 提取UXTO交易的最重要的部分就是一开始的提取UXTO的过程。根据官方的 RPC Api 。我们可以使用 listunspent 的api 来获取UTXO的列表。 这是交易过程中第一个会出现问题的地方，如果我们直接使用这个 api 会发现一个问题，我们可能会发现完全提取不倒信息。 这是因为我们想要发起交易，很大程度上依赖的是比特币节点的钱包的功能。（关于比特币全节点的概念，请参考《精通比特币》一书）。这个比特币地址如果和本节点上的钱包是没有关联的话，我们是无法得到UTXO的。 接下来介绍什么叫做关联：根据比特币早期的文档（文档版本比较老，可以去查阅早期...
比特币节点远程访问
比特币节点远程访问在上一篇文章中详细描述了比特币节点的配置，其中诸多参数的意义可以在上文中找到解释，也可以使用 -help 或者 -？来查看说明。本文讲是配置一台运行比特币的服务器（我的环境是乌班图），远程访问比特币核心。 通过比特币核心提供的RPC服务来和比特币核心进行交互。在网上用配置比特币远程服务等关键字搜索得到的信息好多都是过时的，因为比特币版本升级迭代的比较快。请注意本文配置的时间节点是 2019-9-1，后续参考本文请注意时间节点。 在默认的状态下，bitcoind(以后统称为bitcoind)，监听的是本地回环地址 127.0.0.1 。默认监听的正式地址的端口是 8332 123$ netstat -alpn | grep 8332tcp 0 0 127.0.0.1:8332 0.0.0.0:* LISTEN 18787/bitcoindtcp6 0 0 ::1:8332 :::* LISTEN 18787/bitcoind 在本地节点使用 bitcoin-cli 或者...
比特币客户端的设置
比特币客户端的设置关于如何从源码编译出一个比特币程序网上已经有很多文章了，而且写的非常详细，按照上面的步骤一步步的安装依赖库就可以编译出一个完整的客户端。下面列出搜集到比特币客户端的设置，作为资料备查。 我安装的环境是乌班图系统 关于比特币编译过程可以参考这一篇 Bitcoin 比特币官方客户端有两个版本：一个是图形界面的版本，通常被称为bitcoin-qt，以及一个简洁的版本（称为bitcoind）。它们相互间是兼容的，有着同样的命令行参数，读取相同的配置文件，也读写相同的数据文件。你可以在一台电脑中运行Bitcoin 客户端或是bitcoind 客户端的其中一个（如果不小心尝试同时运行另外一个客户端，它会提示你已经有一个客户端在运行并且自动退出）。当然简易的配置直接参考《精通比特币》一书的配置，根据自己安装环境选择两类配置。 命令行参数使用 -? 或–help 参数运行Bitcoin 或bitcoind，它会提示常用的命令行参数并退出。用法： 1234bitcoind [选项]bitcoind [选项] <命令> [参数] 将命令发送到 -server 或...
比特币交易基本问题
经过一段时间的学习，尝试去理解比特币和区块链的概念，也在阅读rust-bitcoin项目下的代码。现在来提出一个比特币交易的基本问题： 我们怎样去实现比特币交易？问题的产生问题的产生很简单，现在只有一个目的，想要在比特币网络上实现一次转账交易。在实现这个目标之前，我做了一些准备工作： 阅读了mastering bitcoin 参阅了 rust-bitcoin 项目下 rust-wallet的源码 阅读了bitcoinJ的源码，根据bitcoinJ的实现梳理出一个我认为的交易实现的过程 查阅了 rust-bitcoin 项目的子项目murmel，该项目是一个 SPV 节点的实现，截止目前还暂时无法运行 之前也在博客撰写了 比特币交易过程 的文章，可以在之前的博客看到。其中涉及熵的生成，助记词生成，秘钥的派生等钱包的概念。也在后续的文章中提炼出来交易过程中的脚本构建的过程。初步构建了比特币交易的流程。也有文章描述了SPV节点的概念，简单来讲 SPV 节点不存储完整的区块链信息，使用称为 merkle tree 的数据结构来验证交易信息。 初步思考第一层的准备工作完成之后...
申请测试比特币的过程
接上文，在之前的流程图中明白了比特币交易的基本过程，现在需要使用是用测试比特币来完成一笔交易。本片文章就是完成交易的前置工作的记录——申请测试币。 按照完整的流程，我们应该按照以下的过程完成 生成我们需要的私钥，和比特币地址。这样别人就可以把测试币发到你的地址上了。 去特定的faucet上申请测试币 1. 生成比特币测试地址建议去以下的网址生成比特币测试地址 比特币地址生成 需要特别注意的是，如果不加参数 ?testnet=true的话，生成的是正式地址。如果使用正式地址，faucet网站是不会给你打测试币的。 加参数的话请直接在链接的最后面加上这个参数，加上的话话出出现 TESTNET EDITION ACTIVED 请务必注意这一点。 还有一点需要仔细看的是生的的地址 以1开头的都是正式地址 ，以m或者其他开头的是测试地址 生成好记得保存。记得测试完成之后归还测试币。 2. 申请测试币发放测试币是社区或者其无偿提供的服务，所以很多发放地址会随着时间而实效，甚至于bicoinj上提供的地址在我用的时候已经实效了。下面列出我使用的两个地址 https://testn...
比特币交易过程二
接上一篇文章，这张星图描绘了比特币交易细节中的脚本。 注意这也是后续比特币的继承者们对比特币不满意的地方。因为比特币交易脚本是基于栈堆的非图灵完备语言，后续的追求者希望在区块链的基础上运行强大的机器语言，让每个用户都可以见证其运行的过程的结果“智能合约”应运而生。当然，这里的图只简单指出比特币的交易脚本。
比特币交易过程一
根据Mastering Bitcoin梳理出的比特比交易过程，涉及公/私钥生成，钱包，和真正的交易过程，涉及较多细节。 因为设计细节较多，单纯做一张图已经难以阅读，（同时也因为节点太多绘图工具太卡了…）所以拆分开来。本文章的图从三点钟方向开始阅读，顺时针方向阅读。这次的星图只到交易脚本构建结束，后续的文章将从交易脚本构建开始描述。
SPV
SPV是什么何为SPV文章的开头首先要明确一个问题，什么是SPV？ SPV是一个典型的区块链的领域知识，SPV的全称叫做 Simplified Payment Verification翻译成中文就叫做“简单支付认证”。 其实对应简单支付认证的是不是还有一个叫做复杂支付认证的东西呢？答案是肯定的。虽然说对应的知识叫做不叫做”复杂支付认证“但是我们还有有必要来了解其概念。 我们都知道，SPV是去中心化的分布式存储结构，一个完整的区块链节点包含以下四个部分（这种节点叫做full Node） W -> Wallet M -> Miner B -> Full Blockchain N -> (Network) Routing Node 以上四个节点分别代表了钱包，矿工，完整的取款链数据库和网络路由。虽然是分布式，完全公平的节点，但是受限于网络，机器等具体情况，并不是每个节点都具有完整的这四个部分。特别是Full Blockchain。一个完整的比特币数据库，在比特币网络不断膨胀的今天，已经有数百G之多。实际情况中，很多比特币的节点都运行...
跨域问题
之前写的安卓程序，并不存在跨域这种说法，是可以自由的从不同的域名下请求数据的，现在看前端知识，则就出现了跨域这个概念。了解跨域，主要清楚以下的知识点就可以。 什么是同源策略，满足同源策略的三个条件是什么 跨域的具体方案是什么，怎么处理。 什么是同源策略，满足同源策略的三个条件是什么浏览器为了安全起见，制定了同源策略，只允许在本域名下的数据请求操作，同源策略主要要求以下三个条件 协议相同，注意http和https是不同的协议 域名相同 端口一致 请求的url和当前html的url满足以上三个条件就是同源的，非同源的情况下，使用数据就会受到限制。 跨域的具体方案是什么，怎么处理实际场景中，我们不可能什么东西都放在自己的域名下来处理，比如我们可能需要一个天气请求的API，但是我们的主业是电商，那我们很可能就需要一个第三方的API来做。这个时候我们就不得不跨域。目前主流的跨域的方案有一下三类。 JSONP JSONP是JSON with padding的简称。我们知道 Script 标签中的js不受同源策略的影响，我们可以自由加载任何域名下的js来执行。JSONP就是以此为...