折腾过很多，我觉得最灵活的还是 zerotier, tailscale 这样的虚拟局域网，装个客户端虽然觉得多了个东西，但长期来看其实比自己折腾一堆配置来的简单；

zerotier 这样的服务麻烦的地方就是国内不能直连的时候速度慢，需要自建 moon ，需要一台 VPS ，而各类云的 1M1C1G 的小 VPS 问题就是带宽太小；

前一段时间站里有老哥发了个类似的服务，把 VPS 自建中转 这一块做成服务了，我自己用了下感觉他家的软件比较简陋，但是组网是没问题的，也挺稳定,可以试试：

https://v2ex.com/t/796362

推荐我自己维护的一个二级混合债基配置方案，策略是公开开源的，我起名为潜龙在渊：

这是一个可转债和信用债结合的组合包；既适合一次性投入，也适合分批买入，适合能承受 10%最大回撤的投资者：

潜龙在渊的期望年化收益是 6%--10%；

https://qieman.com/portfolios/ZH039295

wind 可试用 15 天，年费大概 4-6 万元：

https://www.wind.com.cn/NewSite/wft.html

如果学好 Python，可以去量化网站上写脚本获取数据，比如聚宽之类的网站：

https://www.joinquant.com/

这个需求挺有意思的，

如果搞工程的话，1000 米的巷道，设备不动，我能想到的最简单的实际操作的办法：

* 电流传感器引出到继电器，加个蜂鸣报警器，灯灭了长响几声，然后安排工人排班监控即可；制定规章制度，报警喇叭长响就暂停生产；

这个成本低，但是不自动化，要依靠规章制度和人员管理来实现；

要自动化的，不管是单片机、载波、电力线缆通信，都得要现成的厂家解决方案和成熟产品，因为井下是不能给你搞实验的，所以最靠谱的就是问有没有做井下矿灯监控的现成产品~~~这个我没接触过，期待有人推荐个成熟的厂商产品；


========================
如果要搞研究，就复杂了，可以扩展为"如何方便的对井下数据采集" 这个问题；


我刚毕业是从事矿山机械设备维护的工作，下了不少矿井；就我的实际经验来看，技术选型首先要确定采用无线方案还是有线方案；

我更倾向于无线方案，有线方案的弊端非常明显，就我的实际经验看，在巷道里布线，时刻要面对如下问题：

* 回采面不断推进，包括本安电源、照明设备、变压器等等都需要频繁移动位置，这中间拖着电源线缆就已经很麻烦了，如果再加通信线路就更累赘

* 工人维护线缆是个精细活，占用大量人工；而且去井下干过活的人都知道，井上 1 个小时能检查完的工作，井下一般要 3 个小时；如果有人在井下接过断掉的通讯线路就有体会了；

* 理论上井下引入的所有的设备都要有本安认证，不管是个小小的传感器，还是电源、电缆；而且各种设备安全限制，所以在井上看来理所当然的事情在井下行不通；

刚毕业的时候能折腾，有个 idea，用本安无线 AP 覆盖巷道，把定位设备做在矿灯里，实现简单的通信、信号采集上传等等；后来做了一个原型：

https://github.com/brain-zhang/icaplamp

后来发现功耗、精度、范围等等都不好达到要求，就作罢了；

后来 2014 年开始的时候，基于 Zigbee 的巷道通讯方案渐渐多了起来，我已经不再从事这个行业了，就没有深挖过；今天重新看到类似问题，又去研究了一下 Zigbee 的相关论文，我觉得这貌似是个井下组网的好办法；

http://gb.oversea.cnki.net/KCMS/detail/detail.aspx?filename=DZJY201312040&dbcode=CJFD&dbname=CJFD2013

https://xueshu.baidu.com/usercenter/paper/show?paperid=e74861ebfdd52729b56bb0aab9380e9f&site=xueshu_se

搞研究的话，我倾向于 Zigbee 组网方案；

这个问题我要仔细答一答；

我属于那种人家看一眼就可以判定比较"老实"的人；我不知道为什么会这样，但是相信大家都会遇上那种人，一看就是特别愚钝，特别老实相，特别憨，就是容易受骗 /(ㄒoㄒ)/~~

我刚毕业的第一份工作，是机械设备的售后维护工作，天南海北的出差；神奇的是，每次去火车站，总是会碰上"不小心丢了钱包，就缺 20,30 块钱买车票"的人；那个时候还是诺基亚的时代，没有电子支付，没有这么多高铁，没有自动取票机，小车站乱哄哄的，但人家总能找到我这个肯借钱的人~~~

总之毕业第一年，我大概碰上了四五次这种事情，钱说多不多，加起来也就 200 来块，但对于那时的我也是个挺心疼的数目，自己有时候在外边吃面加个蛋都要考虑一番，但是愣是拒绝不了；我总想着可能人家真的是需要救急，每次我也都留下电话，但是一次也没有回应；可能人家拿到钱之后光顾着嘲笑我这种憨蛋吧；但说实话，我真的没有分辨真假的能力，那时候遇到各色各样的借钱者，但要么是衣冠楚楚，要么是风尘仆仆，特别真实，老实说，每一次受骗后我仔细琢磨，也找不到破绽；

后来我在上海工作了几年，碰上了好几次"外地人丢钱包 /找不到子女 /亲戚"等等一类的接口，这个时候我已经长心眼了：带你吃饭可以，去警察局帮忙找人也可以，现金不给~~~

这几年得益于电子支付的普及，这种骗局已经渐渐销声匿迹了；不过我有时候想起来当年的自己，是不是就是这么个憨蛋，那时候自己出差自带干粮，长毛了都舍不得丢，却一次次掏钱受骗，值不值得....

到今天也没有答案；

哈，同道中人啊；

虽然我一点也不相信将来 AI 投资会比长期拿者低估指数得到更高的收益；

但是我们喜欢玩啊，Maybe 找到一个短期有效的策略呢；

不过小赌怡情，不要下大注；

楼主的思路非常 Nice，这个乐观好玩的投资心态值得赞一个；

最后自推我自己开发的一个非常简陋、没有任何高科技含量的开源策略，这个策略目前正在经受市场上的狂风大浪，但还能稳稳的行船，欢迎大家来关注：

https://github.com/brain-zhang/xianglong

可以手工导出 TOTP token ；隔一段时间做一次备份即可；

https://github.com/alexzorin/authy

下载这个库，安装相应依赖，然后执行:

```
go run $GOPATH/src/github.com/alexzorin/authy/cmd/authy-export/authy-export.go
```

运行起来之后，首先要求输入的是 Authy 的电话区号，不带+号的。

然后输入手机号，它会联系 Authy 服务器，此时你的 Authy 设备上会有个登录提示，按照提示同意即可。

然后会显示输入 backup password，输入你的密码后，就会显示出你所有的 token。

输出的都是 otp:// 开头的 2FA URI，你就可以把这些 OTP 导入其他 2FA 验证器了

这是我个人看法，我觉得 n=0 的时候就表示系统不可用了；当然，可能是偏见；

明白了，是我的理解有偏差；感谢解释。

如您所说，对 Merkle Tree 进行裁剪，把本来没花掉的币“修剪”掉, 这只能自嗨，对于现有的系统运行有什么影响呢？当前系统并没有一种场景供恶意节点利用这一点作恶。

至于"完全可以把已经花掉的币重新加回来"， 且不修改 Merkle Tree，这又是怎样实现的呢？

总结一下，就是现在几乎所有的全节点或轻节点实现，都自带有几个 bitcoin 历史上著名的 checkpoint HASH 值；

想要欺骗这些节点，代价是巨大的，因为几乎要一己之力计算整条包含这几个 checkpoint HASH 值的链；

再重新说明一下第一个疑问:

Merkle 树的任何修改都会影响 Merkle Root，而 Merkle Root 的改变会影响 block header，此时要保证 block header 的合法性，就需要重新计算 coinbase 交易，这个过程为什么不需要算力呢？

一个轻节点收到一条 SPV 证明，验证逻辑是：

1. 验证 Merkle 树的合法性
2. 通过 Merkle Root 验证其所在 block header 的合法性；
3. 轻节点通过其自带的 check point HASH 值，以及接收到的其他全节点广播的最近的 block header 验证此 block header 合法性

不论怎样，要发送一个修改的 Merkle 树作为 SPV 证明欺骗轻节点，前提是需要伪造一个合法的 block header，这同样需要极大的算力才能做到啊?

有些地方我不是很理解；

1. 我仔细阅读了您提到的裁剪 Merkle 树对一些 SPV 节点"欺诈"的过程，其实还是没有搞明白：

Merkle 树的任何裁剪都会影响 Merkle Root，而 Merkle Root 的改变会影响 Coinbase 交易，如果要裁剪 Merkle，那么 Coinbase 交易，以及工作量证明都需要重新计算，即使是不考虑其他全节点的广播，我作为一个 SPV 节点，即使只收到了一笔有意义的最近的 block，那么就肯定得出了当前难度值的下限，那么此时我收到了许多"欺诈节点"发来的 block，即使这些 block 中的交易构造是一个裁剪过的 Merkele 树以及合法难度的 Coinbase 交易，不都是要花费相当大的算力的吗？为什么不需要有算力呢？

除非这个 SPV 节点从头到尾都沉浸在"欺诈"的全节点的包围中，但这就是私有链了；而且现在所有开源的 SPV 钱包实现，其实发行版都包含了几个 checkpoint 之前的合法的 block header 集合，接收到全节点的广播后，一般钱包会再就 SPV 同自带的本地的 block header 相比较，所以工程实现上基本上没有问题。


2. 中本聪原论文中的算力攻击计算其实省略了一部分，分叉攻击者有两种情况：

* 当两条分叉从同一起点开始竞争时，就是一个酒鬼漫步问题；攻击者一方相当于不断的要逼近诚实者一方挖出的区块高度；这时候其实只需要 50%的算力即可完成攻击；

* 从交易被收录进区块的时候开始，诚实矿工出了 z 个块。攻击矿工在此期间出块数记为 k，只要攻击者不广播别人就不知道，k 可能等于 0、1、2……直到无穷大。此时的攻击成功概率是中本聪论文中计算的结果；

关于这个问题，我也写过一篇科普文：

https://happy123.me/blog/2018/11/17/bchfen-cha-cheng-dan-de-feng-xian-51-percent-gong-ji-zhe-gai-lu-wen-ti/

严格说来，51%攻击其实是个 50%攻击问题，当然这也是吹毛求疵了。

@acess 感谢科普；

前几年我也花了一段时间认真学习比特币的原理知识，共用了 pyspv 和 pycoind 的实现，写了一个简单的 Segwit 分叉之前的比特币全节点；

https://github.com/brain-zhang/chainhorn

实现了 PROTOCOL_VERSION(60002)最基本的交易接收，广播功能；

之后也没什么人有兴趣关注就没有再继续下去，您有兴趣来参与一下吗？

1. 写入区块链的交易才被承认，双花交易只存在于内存池中，所有的双花交易只能有一笔进入区块链
2. 更改已经进入区块链的交易，只有发动 50%攻击
3. 消费 coinbase 交易需要 100 block 的成熟期，现在不少裁剪节点是以 prune 方式运行的，一般设定 prune=4096，所以说，理论上区块链重组是有可能的，但是 100 个 block，4000 个 block 级别就变成近乎不可能的事情，一般情况下，6 个 block 确认就基本上确保一切； 历史上曾发生过最多 31 个 block 的重组事件，是在 2013 年 3 月份发生的，现在几乎不可能再有这种情况发生了；

我比较仔细的研究过这些情况，写过一篇科普文章，有兴趣可以翻阅下：

https://happy123.me/blog/2019/01/21/bi-te-bi-de-blockchain-1/

我不知道楼主对高主频要求到哪种程度，我自己也在做一些大数据量运算，比较看重核数；

个人觉得配台式机不如淘宝一台二手刀片服务器，或者工作站，内存插到 1T 也可以；

个人在用 HPZ840:

E5-2699V3*2 2.3G 主频 36 核心 /72 线程
DDR4 ECC 16G*16

加个渲染显卡 1.5 万元左右，价格实惠;

稳定运行 1 年；

台式机主要是稳定性不靠谱，我之前同样配了台台式机，最长不过运行 3 个月，总是有问题；实际体验靠谱的二手工作站稳定性优于自配台式；

typo fix:

再仔细想一想，其实这是人们对于某一样风险的定价不同而已；

对一些人来说，死亡是一个无限大的风险，他愿意买保险，锻炼身体，注意交通安全......

对一些人来说，比起死亡，穷困潦倒一生无疑风险更大，所以他愿意买彩票，横穿马路节省点时间挣钱.....

虽然很残酷，但现实就是如此。

再仔细想一想，其实这是人们对于某一样风险的低价不同而已；

对一些人来说，死亡是一个无限大的风险，他愿意买保险，锻炼身体，注意交通安全......

对一些人来说，比起死亡，穷困潦倒一生无疑风险更大，所以他愿意买彩票，横穿马路节省点时间挣钱.....

虽然很残酷，但现实就是如此。