两个大文件,a.txt和b.txt两个文件的数据都是逐行呈现的, 如何求他们的交集、并集和差集。
用sort+uniq直接搞定:
交集
1 2 3 | |
并集
1
| |
差集
1 2 3 | |
- 在开搞 bloom filter或者bitmap 或者grep -f之前可以先组合工具来一个
两个大文件,a.txt和b.txt两个文件的数据都是逐行呈现的, 如何求他们的交集、并集和差集。
用sort+uniq直接搞定:
1 2 3 | |
1
| |
1 2 3 | |
grep 一个100GB的文件总是很有压力,怎么才能提速呢?
1
| |
LC_ALL=C比LC_ALL=UTF-8要块
不需要正则的话,用fgrep可以提速
1
| |
使用parallel ,和不使用parallel直接grep。结果显而易见,相差 20 倍。这比用啥 ack,ag优化效果明显多了
1 2 3 4 5 | |
这一条xargs把每个echo的数作为参数传给sleep ,所以一共sleep了 1+2+3+4+5=15秒。
如果使用 -P 参数分给5个核,每个核各sleep 1,2,3,4,5秒,所以执行完之后总共sleep的5秒。
1 2 3 4 5 | |
https://www.jianshu.com/p/c5a2369fa613
有时候想在xargs后面接多条命令,这个时候直接加;是不行的,要这样做:
1
| |
有时候find的所有文件要合并为一个argv管道到一个命令里面:
1
| |
在linux要排序一个100G的文件,压力比较大
并行解决之:
1
| |
注意这一招在管道里面行不通,所以要用管道的话一定要先重定向到一个文件里面中转一下。
在之前的谈谈比特币的地址安全问题这篇文章中,我们谈到一个名为”LBC”的项目,这个项目通过暴力碰撞企图打捞到一些什么东西。
令人惊奇的是,他们真的碰到了几个地址。对他们最近发现的4个地址做了一下分析,发现了更让人惊奇的事情。
他们最近的四个发现是:
1 2 3 4 5 6 7 8 | |
有时候gitignore没做好,一不小心就又进来一个二进制文件
在重复了N次Google之后,还是记一下吧
随机生成一个32字节(256bits)的私钥k
采用椭圆曲线算法,以私钥k为起点,将其与曲线上预定的生成点G相乘以获得曲线上的另一点,也就是相应的公钥 K
进一步SHA256=>RIPEMD160 得到地址原始值A: A = RIPEMD160(SHA256(K))
对A进行Base58Check编码,添加前置版本号后Double SHA256取最后四个字节作为校验位,最后 Base58Check(前缀+Base58Check(A)+校验)得到最终地址
整个过程中,私钥的生成空间有256bits,由私钥推出地址过程中,由于用到了RIPEMD160散列,所以生成空间共有160bits。
也就是说,去除版本号变化,某一类型的比特币地址最多有 2^160个。
为什么有步骤3呢,不光增加了地址复杂度,还降低了HASH碰撞空间(从256bits降到160bits)。
所以中本聪的选择只是带来了不必要的复杂度和浪费吗?最后证明,答案是否定的。有另外一个非常好的理由去使用这个”公钥的哈希值”的地址结构:量子加密技术。量子计算机可以破解椭圆曲线数字签名算法(也就是说,给定一个公钥,量子计算机可以相当快速的找到对应的私钥),但它们不能相类似的逆转哈希算法(或者说他们可以,但是将需要花掉280个步骤来完成一个比特币地址的破解,这仍然是相当不可行的)。因此,如果你的比特币资金存放在一个你没有支出过的地址里(这意味着公钥是没有公开的),它们在量子计算机面前也就是安全的,至少在你把它们花掉之前。有理论上的途径可以让比特币完全免于量子计算机的威胁,但一个地址只是一个公钥的哈希值的事实,意味着一旦量子计算机真的出现了,在我们全面切换之前攻击者可以造成的损失要小得多。
请参考:
http://www.8btc.com/satoshis-genius-unexpected-ways-in-which-bitcoin-dodged-some-cryptographic-bullet
比如1HUBHMij46Hae75JPdWjeZ5Q7KaL7EFRSD,这个地址,有转出过,如何得到公钥
原理很简单,但是实践起来比较烦: