test.jsp

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
<%@ page contentType="text/html;charset=UTF-8" %>
<%

out.print("将该文件编译,作为一个servlet");

out.println(this.getClass().getName() + "<br>"); // org.apache.jsp.test_jsp (文件名是test.jsp)

out.println(request.getClass().getName() + "<br>"); // org.apache.catalina.connector.RequestFacade 跟 servlet中的一样(这是org.apache.catalina.connector.Request的门面,org.apache.coyote.Request的wrapper)
out.println(response.getClass().getName() + "<br>"); // org.apache.catalina.connector.ResponseFacade 跟 servlet中的一样

// 注意区分这三种输出方式
out.println(response.getWriter().getClass().getName() + "<br>"); // org.apache.catalina.connector.CoyoteWriter
out.println(out.getClass().getName() + "<br>"); // org.apache.jasper.runtime.JspWriterImpl
response.getWriter().println("print from response.getWriter()" + "<br>");
//response.getWriter().close();
// response.getOutputStream().write("print from response.getOutputStream() <br>".getBytes()); // 这个输出会覆盖掉其他的输出,而且不能喝getWriter()同时出现
//

out.println(request.getSession().getClass().getName() + "<br>");
out.println(session.getClass().getName() + "<br>"); // org.apache.catalina.session.StandardSessionFacade =request.getSession()

out.println(request.getServletContext().getClass().getName() + "<br>");
out.println(application.getClass().getName() + "<br>"); // org.apache.catalina.core.ApplicationContextFacade =request.getServletContext()



out.println(config.getClass().getName() + "<br>"); // org.apache.catalina.core.StandardWrapperFacade
out.println(pageContext.getClass().getName() + "<br>"); // org.apache.jasper.runtime.PageContextImpl
out.println(page.getClass().getName() + "<br>"); // org.apache.jsp.test_jsp
//out.println(Exception.getClass().getName() + "<br>");



out.println("<br>methods:<br>");
for(java.lang.reflect.Method m:this.getClass().getMethods()) {
out.println(m.getName() + "<br>");
}
out.println("<br>fields:<br>");
for(java.lang.reflect.Field f:this.getClass().getFields()) {
out.println(f.getName() + "<br>");
}

out.println("<br>DeclaredFields:<br>");
for(java.lang.reflect.Field f:this.getClass().getDeclaredFields()) {
out.println(f.getName() + "<br>");
}


String a="this is a string variable";
for(int i=0;i<10;i++) {
out.println(i+" in loop\n\n");
}

%>
Date:<%=new java.util.Date()%>

dd

远程调用API

  • 分布式对象(Distributed Objects,简称DO)
    • CORBA/RMI/EJB/DCOM/.NET Remoting
  • 远程过程调用(Remote Procedure Call,简称RPC)
    • SOAP/XML-RPC/JSON-RPC/Hessian/Burlap/Flash AMF/Dubbo RPC
    • 基于Google Protocol Buffer数据交换格式的各种RPC协议
    • 基于Apache Thrift的各种RPC协议,例如唯品会的OSP
  • 表述性状态移交(Representational State Transfer,简称REST)
    • 将HTTP协议真正作为一种 应用协议 来使用,不再需要基于HTTP的各种RPC协议
    • RESTful API——符合REST架构风格要求的API

对于HTTP的常见误解

  • 浏览器只支持GET/POST方法
    • HTML表单仅支持GET/POST方法,但是可以通过附加参数(例如_method)的方式模拟PUT/DELETE请求
    • XMLHttpRequest对象GET/POST/PUT/DELETE 4种方法均可支持
  • 未遵循HTTP协议的指导误用HTTP方法
    • GET方法:安全的、幂等的
    • POST方法:不安全的、不幂等的
    • PUT/DELETE方法:不安全的、幂等的
  • 过度使用GET方法
    • 敏感信息位于URL中,不够安全
    • 容易受到爬虫的伤害
  • 过度使用POST方法
    • 例子:SOAP等RPC风格的调用协议
    • 一个方法承担了过多职责
    • 没有充分利用HTTP的优势
  • HTTP是一种RPC风格的协议
    • 事实:HTTP其实是一种REST风格的协议
    • 统一接口是REST与RPC两种风格协议的主要区别
  • HTTP是一种“传输”协议(transport protocol)
    • 被错误翻译为“超文本传输协议”
    • 事实:HTTP其实是一种“移交”协议(transfer protocol)。TCP才是传输协议,对传输这件工作已经做的很好了。
    • 传输协议和移交协议的区别
      • 传输协议做的是底层搬运比特之类的苦力活,不包含操作的语义
      • 移交协议做的事情比传输协议更高级,包含了操作的语义
  • HTTP不具备互操作性
    • 因此需要在HTTP之上设计SOAP这种“简单”的协议(事实上很复杂)
    • 事实:充分利用好HTTP,已经能够得到足够好的互操作性,在很多场合甚至比使用SOAP更好

对于REST的常见误解

  • REST只适用于面向机器的Web API,不适用于面向人类的Web App
    • 事实:REST在Web上是普遍适用的
  • 直接使用HTTP的API就是RESTful API
    • 事实:在SOAP与真正的RESTful API之间还有广大的中间地带
    • 只达到Richardson成熟度模型第0级的API不是RESTful API
  • REST只不过是更漂亮的URI设计
    • 事实:这仅仅是REST的一个外在特征而已
  • HATEOAS并不重要
    • 事实:这两个方面都是REST架构风格的核心特征
    • 至少需要实现统一接口,否则可以确定是冒牌的RESTful API
  • 统一接口只能使用HTTP实现
    • 事实:HTTP仅仅是实现REST架构风格的一种方式
    • 其他符合REST统一接口的例子:扩展了HTTP协议的WebDAV协议

示例

solr的api设计

1
2
3
4
/select?
/update

/core?

tomcat example的url设计

http://127.0.0.1:8983/solr/admin/form.jsp

bluescan的设计

  • 一点都不restful

  • 资源有什么?manager
    get docs?docid= & userid=
    post docs? //add或者upload操作
    get clauses?docid=
    users, database,

  • 引入delete

问题集

注意区分url设计和api设计。

restful指的api。

【机器翻译】字符级机器翻译 - BPE

2016

Neural Machine Translation of Rare Words with Subword Units

解决的问题

OOV问题

中文也存在OOV问题。比如分词以后

核心思想

其核心思想是语料库中的高频词作为整体出现的可能性大,因此不对其进行切分,而对低频词进行切分,由此增加稀疏词中子词的共现次数。

encoding rare and unknown words as sequences
of subword units.

本文讨论了subword的不同分割技巧:

  • 直接采用char,信息损失较多
  • character n-gram models
  • segmentation based on the byte pair encoding compression algorithm

规避大词典。原来都是先把一个数据集中所有单词找出来,把最常用的一些(如90%)做成一个大词典,显然这是冗余的,words和word完全没必要区分。动不动就是50K的单词表,非常耗内存,在像Czech这类语言上更加不行。关键是冗余不优雅。很多研究者都注意到这个问题:

  • subword,就是统计一下符号的频率,如“est”可能是一个符号,能组成“w est,b est”等词,因此称为subword。我觉得还是不够自然,而且效果并不是很好。
  • Hybrid Word-Character Models,相当于把未知的词训练成RNN小单元,据说华为很早就申请专利了。我表示,不能有word。
  • Junyoung Chung提出的不需要显式分隔的模型。提出bi-scale的RNN,我觉得很有意思,但我有个疑问,这跟base的RNN有什么区别?论文中也显示,确实差不多。我不知道为什么性能那么好。由于没有训练时间、训练所用内存等更多信息我无法作出判断。
  • 还有Wang Ling提出的,但是完全不是NMT,需要借助IBM model来对齐和分层训练,而且效果不好。

related work

  • 2016 年,Rico Sennrich 和 Barry Haddow 等人提出了 Byte Pair Encoding (BPE)的方法,将原有的单词拆解成了更小单元的高频词进行翻译。 BPE 方法在多大程度上解决了未登录词翻译的问题。对未登录词的翻译精准度达到了 45%左右,

参考

启动引导程序 grub

前言

Boot Loader 是电脑启动时运行的第一个程序,它负责装载内核并将控制权转交。内核再初始化操作系统的其它部分。官方所称的 GRUB 是软件的第二版,即 GRUB2

GRUB 命名约定

GRUB 对于硬盘和分区自有一套命名规则(hdN,M),其中 N 是硬盘数,M 是分区号。硬盘数 N 从 0 开始计数,分区数需要区别对待——主分区从 1 开始计数而扩展分区从 5 开始计数。

磁盘编号

Grub在表示方式上并不区分IDE硬盘、SATA硬盘和SCSI硬盘等,所有硬盘会被识别为hd#,”#”是从0开始的硬盘编号,而软盘被类似地识别为fd#

分区编号

通常情况下,在使用MBR格式的分区表的电脑中,最多有四个主分区,其中一个可以是扩展分区,内含若干逻辑分区。装有Windows的硬盘中,通常C盘是主分区,其它盘是扩展分区下的逻辑分区。

Grub 2的分区编号从1开始。如(hd0)的第一个主分区(hd0, msdos1),而第一个逻辑分区从(hd0, msdos5)开始计数。

为什么这里扩展分区从 5 计数,可以查看 mbr 的相关知识。早期版本的 GRUB 是什么计算磁盘和分区数,我忘记了,不过,大家就记住新的就好啦。

Grub配置文件

GRUB 会将一些数据写入硬盘的第一个物理扇区。这一部分不属于任何一个操作系统,在启动时,该部分数据激活,然后寻找 Grub 的模块,Grub 模块的默认位置为 /boot/grub/

雷军
既然不属于任何一个操作系统,为何操作系统有权限修改grub配置文件?
1
cat /etc/default/grub
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
# info -f grub -n 'Simple configuration'

GRUB_DEFAULT=0
#GRUB_HIDDEN_TIMEOUT=0
#GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=15
GRUB_RECORDFAIL_TIMEOUT=60
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="nomodeset net.ifnames=0"
GRUB_CMDLINE_LINUX=""

# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"

# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"

Grub加密与字符界面分辨率调整

重启后进入grub rescue

什么原因?

怎样解决?

参考

常见的比特币命令

钱包的概要信息

1
2
3
4
5
6
7
8
9
10
11
12
13
14
$ bitcoin-cli getwalletinfo
{
"walletname": "wallet.dat",
"walletversion": 159900,
"balance": 0.00000000, # 已确认的账户余额,使用BTC单位
"unconfirmed_balance": 0.00000000, # 支付到该钱包,但尚未确认的交易的总额
"immature_balance": 0.00000000, # 挖矿奖励金额需要等待100次确认后才能使用,在此之前,这部分金额都是immature状态。
"txcount": 0, # 钱包里涉及的交易总个数
"keypoololdest": 1527560439, # 是指最早生成的key的unix时间戳
"keypoolsize": 1000, # 允许预先生成的公钥、私钥对的个数。私钥参与交易的目的是提升安全性和反跟踪。
"keypoolsize_hd_internal": 1000, # 用于内部使用(如找零)的钱包地址个数。
"paytxfee": 0.00000000,
"hdmasterkeyid": "3850de05ae997e53dc5271f4e889aa5f2a6b213b"
}

getblockchaininfo

这个命令用来显示比特币网络概览

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
$ bitcoin-cli getblockchaininfo
{
"chain": "main",
"blocks": 373185, # 已经下载了329136个block,下载进度=373185/524904=71%。
# 截止2018/05/29 11:30,一共挖了524904个block。
# 可以在该地址查看最新数据。https://blockexplorer.com/api/status?q=getBlockCount
"headers": 524904,
# 当前最可信区块的ID,即当前最长链的最后一个有效区块。它可能是被挖掘出来的最新块,也可能不是—这取决于被挖掘出来的最新块是否在正确的分叉上。
"bestblockhash": "0000000000000000056ff4b4bb1579533f3e901e90f6f4966104811df4705823",
"difficulty": 56957648455.01001, # 当前块的难度值
# 每个区块都包含着一个unix time时间戳。只有当这个时间戳大于mediantime,并且小于某个调整后的网络时间[1]时,这个区块才会被确认。
"mediantime": 1441481425, # 过去11个区块的中值时间。注意这里引用的区块是最长链上已确认的区块。
# 在一个新安装的Full Node上,由于区块首先要下载完成才能进行确认,而确认时间较快,所以可以把这个比例当成区块下载完成进度。
# 为什么这个比例不等于blocks/headers?
"verificationprogress": 0.2479860418344433, # 已确认的交易占比,为何这么低?
"initialblockdownload": true,
"chainwork": "00000000000000000000000000000000000000000009e65a3d8485126dc3d47a",
"size_on_disk": 50381675110, #
"pruned": false, # 如果处于pruned模式,则下载的区块可以被删除以节省磁盘空间。
"softforks": [ # 比特币分叉信息
{
"id": "bip34",
"version": 2,
"reject": {
"status": true
}
},
{
"id": "bip66",
"version": 3,
"reject": {
"status": true
}
},
{
"id": "bip65",
"version": 4,
"reject": {
"status": false
}
}
],
"bip9_softforks": {
"csv": {
"status": "defined",
"startTime": 1462060800,
"timeout": 1493596800,
"since": 0
},
"segwit": {
"status": "defined",
"startTime": 1479168000,
"timeout": 1510704000,
"since": 0
}
},
"warnings": ""
}

未验证的交易存在哪?存在局部节点
验证后的交易存在哪?被广播,并加入全局block chain

getblockhash

每个区块是通过其id来标识的,每个id都是一个256位的hash。这个id非常不方便交流。同时我们知道,每一个区块都有一个高度值,而对于主链来说,每一个高度值都对应着惟一一个区块。

我们可以通过这个命令来查找创世块、第一个区块(由中本聪在赫尔辛基的一个服务器上挖出)和其它任意高度的区块的id,并进而得到该区块的信息。

1
2
3
4
$ bitcoin-cli getblockhash 0
000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
$ bitcoin-cli getblockhash 1000
00000000c937983704a73af28acdec37b049d214adbda81d7e2a3dd146f6ed09

getblock

根据区块的ID,可以查看其详细信息。一般有一下三种方式;

  1. bitcoin-cli getblock命令
  2. web api的方式,例如 https://blockchain.info/rawblock/00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048
  3. web界面的方式,例如 https://www.blockchain.com/zh-cn/btc/block/000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f

创世区块(高度为0)

创世区块指区块链上的第⼀个区块,⽤来初始化相应的加密货币。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
$ bitcoin-cli getblock 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
{
"hash": "000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f", # 哈希值,也是区块id,256字节。上一区块是000...000
"confirmations": 384844, # 该区块已经过多少次确认。如果该区块属于best chain,则此值等于全链高度,也是本块的深度。
"strippedsize": 285,
"size": 285, # 本块的大小,0.285 kB
"weight": 1140,
"height": 0, # 高度为0
"version": 1,
"versionHex": "00000001",
"merkleroot": "4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b", # 默克尔树,一种用来表达链上历史交易记录的数据结构,32 Bytes。
"tx": [
"4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b"
], # 交易记录
"time": 1231006505, # 时间戳,2009-01-03 18:15:05
"mediantime": 1231006505,
"nonce": 2083236893, # 随机数,也就是 PoW 要计算的数
"bits": "1d00ffff", # 网络难度
"difficulty": 1, # 难度系数。2018.09.01的难度已经是 6,727,225,469,722.53
"chainwork": "0000000000000000000000000000000000000000000000000000000100010001", # 这是什么鬼?
"nextblockhash": "00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048" # 最后一个block的next为空
}
# 1. 为什么没保存上一个区块 previousblockhash?只保存了下一个的?
# 2. 新区块奖励: 50BTC。记录在哪?
# 3. 计算目标 486604799。记录在哪?
# 4. 重量: 0.896 kWU。记录在哪?
# 5. 总输出量、预计交易量、保存在哪?

也可以通过浏览器查看

对应的交易记录

https://www.blockchain.com/zh-cn/btc/tx/4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b

1
2


没有输入(新生成的比特币)
新区块奖励 0

区块#1

https://www.blockchain.com/zh-cn/btc/block/00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048

最新区块

可以在 https://www.blockchain.com/zh-cn/explorer 查看

这样得到的信息并不包含交易信息,也即我们得到的是区块的头。要得到全部的信息,需要传入verbosity参数,当参数值为2时,即可得到全部信息:

gpu挖矿

挖矿算法

目前的挖矿机理都是基于 PoW(proof-of-work, 工作量证明)的,它通过大量简单的重复运算产出一个符合要求的结果,并且这个结果很容易验证。

举个例子,为了通过考试不挂科,你需要不断地大量练习,才能解出一道题,然而对于阅卷而言只需和标准答案对比一下就完了,几乎不需要成本。PoW 的技术原理主要通过 hash 实现,这里先不讨论。

由于挖矿过程是分别在全球各地执行,而网络同步有延时,有可能出现多个矿工同时抢到了某一高度(可理解为区块序号)的区块,在全网同步时就会出现冲突,这时有个规则是,谁后面接的区块多就以谁的为准,其它的作废

挖矿设备

挖矿的过程,简单地说,就是不断的执行HASH算法,类似穷举的方式去碰答案。这个过程完全是个烧CPU的过程。

挖矿设备主要经历了从 CPU -> GPU -> FPGA -> ASIC 的变化,挖矿效率也是越来越强大。

与 GPU 相比,CPU 包含多数(对于挖矿计算而言)无用的控制单元等结构,因此性价比很低。这就好比让两个大学教授和 100 个小学生一起计算一些 10 以内的加减法,显然小学生们计算的更快,教授就是大材小用了。

FPGA 的芯片生产困难,因此生存时间很短。在将 FPGA 中不需要的逻辑实现删掉后, ASIC 矿机问世。

ASIC 矿机(也就是目前我们所说的矿机)是为挖矿量身定制的,因此挖矿速度非常快(价格也比较高),除了挖矿什么都做不了。一旦遇上“矿难”,那你面对的就是一堆废铁,而显卡至少还有其他用处。

矿池

现在致力于挖矿的组织都要使用专业的挖矿机器(一个装满显卡的机器),而且是千台以上的矿机组成矿场来挖矿。但是这么多机器各自挖效率低,还容易自已抢自已生意,咋办呢?于是出现了一个新的挖矿模式–矿池。矿池是一个统筹算力的服务组织,挖矿机可以加入矿池来挖矿,相当于N台矿机都在算同一个区块,这样就避免了冲突,加快了挖矿的速度。

加入矿池相当于选择组队挖矿,因为一个人可能很难挖到一个币,但是在矿池中就可以按照你的算力占全矿池的算力比例来给你分配收益。这就好比一个人买彩票几乎没啥希望,但是如果规定一亿个人一起买,中奖的平分的话,这样收益就稳定多了。当然,矿池会收取一定的费用

挖矿客户端

用比特币钱包就可以挖矿,只要简单地打开其中的挖矿开关就可以,这也是最原始的挖矿工具

我采用的https://github.com/tpruvot/ccminer

参考

https://www.jianshu.com/p/d0f69961e7f9

比特币挖矿教程 - ubuntu

下载比特币核心钱包(Bitcoin Core wallet)

1
2
3
sudo add-apt-repository ppa:bitcoin/bitcoin
sudo apt update
sudo apt install bitcoin-qt bitcoind

core只是个钱包,不是挖矿的,

比特币钱包的图形界面

1
bitcoin-qt

首次运行下载整个链,有些人要一两周。我运行在下载超快,4个小时。美国服务器。

为什么这么快?性能好?网络好?bitcoin进行过优化?

GPU: Tesla K80 * 4,单卡显存12205MiB

1
2
3
4
5
6
7
8
top
Tasks: 335 total, 1 running, 334 sleeping, 0 stopped, 0 zombie
%Cpu(s): 3.9 us, 0.5 sy, 0.0 ni, 95.6 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 65859336 total, 4927116 free, 1657532 used, 59274688 buff/cache
KiB Swap: 1998844 total, 1997836 free, 1008 used. 63587368 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
13981 root 20 0 3299756 1.189g 120768 S 119.6 1.9 30:05.16 bitcoin-qt

非图形化运行

也可以非图形化运行

1
2
3
4
# 前台运行
bitcoind
# 后台运行
bitcoind --daemon

运行的时候我们可以使用命令查看bitcoind的运行情况:

比特币网络

也可以直接查看debug.log,监控当前运行情况。

1
2
cd $HOME/.bitcoin
tail -f debug.log

备份钱包

这三个很重要

  1. 比特币钱包地址
  2. 比特币私钥
  3. 比特币公钥

这三个存储在wallet.dat中,这个文件丢失了,比特币也就没了。

三者关系

钱包生成私钥→私钥生成公钥→公钥生成公钥哈希→公钥哈希生成地址→地址用来接受比特币。(公钥不能推导出私钥)

地址可以公开,因为它是用来接受比特币的,公钥和公钥哈希也可以公开,没啥问题。私钥绝对不能公开,因为有了它本质上就取得了对应比特币的所有权。

比特币钱包地址

比特币地址是一串由26位到34位字母和数字字符串组成的。
看上去像一堆乱码一样,说白了这个就像你的银行卡卡号一样,可以有N个这样的账户。
通过区块链查可以查每个比特币地址的所有转账记录,公开透明。

如果购买的比特币数额较大,建议大家提到自己的钱包里,不要长期放在交易所里。
对于新手建议还是创建一个比特币钱包比较安全。

如何获得比特币地址?

点击【收币】就可以看到自己的地址了。

在“接收”(Receive)选项卡,我们可以获取自己的钱包地址。直接点击“请求付款”(Request Payment),将生成一个新的地址。你可以将这个地址发送给别人,让他们向你支付比特币。

我的地址

1
aa

每次点击“请求付款”都会重新生成新的地址。

尚未请求地址,挖到的矿会存在哪?

钱包地址删除或丢失,钱包的钱就没了吗?

还能找到。只要你用过的地址 那还是你的。

一个私钥可以对应很多公钥。公钥就是你的钱包地址,它是两个大质数的乘积。私钥就是其中的一个大质数。所以私钥和任何其它大质数的乘积都可以作为你的公钥,就是你的地址。它们都可以被你的私钥打开。

私钥掉了,钱包的钱就消失了吗?

消失是没消失,但永远不会流通了。所以比特币会通缩。

根据钱包地址,能查到所有者吗?能查到国家吗?

钱包没有国家的属性,你在任何国家都可以使用任何地址。

如果地址有过交易,可以查这笔交易是从哪里广播的。如果主人没有隐藏自己,这个广播的ip就是他的地址。

比特币密码忘了怎么办?

  • 钱包地址、公钥掉了,无所谓
  • 私钥忘了,永久丢失
  • 钱包加密的密码丢失,永久丢失
    • if you encrypt your wallet and lose your passphrase, you will lose all of your bitcoins

假如我找到一个私钥,有很多币,拿去卖钱是不是也没有任何人能去告我偷或者不当得利之类的?

采用违法行为所得肯定会遭遇调查。但是由于加密货币的匿名性,无法查找到你头上。但是你通过黑客方式获取密钥,那还是可以追踪到你的

fbi已经收缴过一次大额比特币了

比特币匿名性较弱,追踪起来有难度,但是还是可以尝试追踪的,利益关系大的话,追到的可能性也大。

“比特币这么贵了,我一个都买不起呀?”

实际上,比特币最小单位并不是 1,而是“聪”,没错,就是中本聪的“聪”。1 BTC = 1 亿聪,也就是说最小单位是十的负八次方

私钥 公钥

导入已有钱包 或区块链

1
mv ~/.bitcoin ~/.bitcoin.backup

没看懂的

Regular people don’t run a full node. regular people just want to maintain a bitcoin wallet. it doesn’t need the full blockchain to be downloaded.

参考

区块链数据文件

在Linux中bitcoind的数据存在.bitcoin目录下,该目录下有以下的文件。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
$ cd .bitcoin
$ tree
|-- banlist.dat
|-- bitcoind.pid # bitcoind运行的进程文件
|-- blocks # 区块链数据文件 181G
| |-- blk00000.dat
...
| |-- blk01271.dat
| |-- index
| | |-- 000197.ldb
| | |-- 000198.ldb
...
| | |-- CURRENT
| | |-- LOCK
| | -- MANIFEST-000412
| |-- rev00000.dat
| |-- rev00001.dat
...
|-- chainstate # 区块链状态的数据库使用LevelDB存储 2.8G
| |-- 147873.ldb
...
| |-- 151713.ldb
| |-- CURRENT
| |-- LOCK
| -- MANIFEST-151563
|-- debug.log # 运行时的日志文件
|-- fee_estimates.dat
|-- mempool.dat
|-- peers.dat
-- wallets # 钱包文件 1.4M
|-- database
| -- log.0000000001
|-- db.log
-- wallet.dat

5 directories, 4196 files

比特币挖矿攻略

比特币矿池

比特币挖矿的用户数量非常庞大,而每10分钟产出的比特币又十分有限,形成了千万人抢1个区块的情况出现,所以,如果你用个人电脑单独挖矿,有可能一整年也抢不到一个区块,在这种情况下,人们就想出了一种组队挖矿的方法,所谓的组队挖矿,就是我们现在要讲述的矿池(mining pool)。

矿池是一个通过特定算法而设计的服务器,所有连接到矿池服务器的用户,会组队进行挖矿,个人电脑的性能虽然渺小,但是成千上万的人进行组队挖矿,总体性能就会变得十分强大,在这种情况,挖矿的成功率会大大提升,一旦矿池中的队伍成功制造了一个区块,那么所有队伍中的人会根据每个人的电脑性能进行分红。比如:1000人在同一个矿池中挖矿,挖出一个区块后,这个区块产生的N个比特币的报酬,会根据这1000个人的电脑性能进行分红。如果你的电脑性能强劲,也许会分到100分之1,如果性能落后,也可能会分到10000分之1。

在这种情况,矿池的开发者一般会对每个用户收取1%~3%的费用作为手续费,但由于这种方法让大家更稳定得获得比特币,几乎所有人都会选择矿池挖矿,而不是单独挖矿

在上文挖矿教程中讲到的比特时代免费提供的矿池,采用P2Pool技术架构,不向用户收取任何费用,是主流矿池中的一个,另外还有BTC Guild和deepbit等矿池,人气也是非常旺的。虽然每个矿池的设计都不太一样,但是使用方法基本上是雷同并且简单的,因此本教程不再做进一步的讲述,大家可以自行摸索。即使小编在前面的教程中已经默认给大家配置了比特时代提供的矿池和端口,但为了让大家对矿池有更深入的了解,这里再给大家介绍几个主流的矿池供大家选择:

比特矿池(免费,小编推荐) | BitCoin.CZ(适合新手) | BTC Guild(最老牌) | deepbit(稳定高效) | f2pool(国内)

#

只要电脑性能越好,挖矿的效率就越高。而由于比特币的算法原因,其实就是显卡核心的性能越好,挖矿的效率越高。下面本教程给大家罗列一下经过测试以后,主流显卡核心的挖矿效率进行对比:

ATI系列显卡
HD 6570 | 速率 78.5 MHash/S
HD 6670 | 速率 96.9 MHash/S
HD 6750 | 速率 156.3 MHash/S
HD 6770 | 速率 182.3 MHash/S
HD 6790 | 速率 182.5 MHash/S
HD 5870 | 速率 343.2 MHash/S
HD 6950 | 速率 299.3 MHash/S
HD 6970 | 速率 355.1 MHash/S
HD 6990 | 速率 714.8 MHash/S
HD 7950 | 速率 453.7 MHash/S
HD 7970 | 速率 566.2 MHash/S
HD 7990 | 速率 1073.5 MHash/S
NVIDIA系列显卡
GTX 285 | 速率 56.1 MHash/S
GTX 460 | 速率 71.1 MHash/S
GTX 570 | 速率 124.2 MHash/S
GTX TITAN | 速率 302.4 MHash/S

挖矿的效率对比上,同样价格的N系列显卡完全比不上A系列显卡,这是由显卡的设计架构决定的

职业挖矿1:显卡集装矿机

职业挖矿2:专用工业矿机

参考

http://www.btc38.com/newbie.html