Reddit User Account Overview



As for Muun wallet itself, I unfortunately don't have a very good impression about it:

Commented by /u/KiFastCallEntry in /r/Bitcoin on November 26, 2022 13:55:38

Once you withdraw your bitcoins to any non-custodial wallet, you gain full control of your bitcoins therefore there will be nothing like "withdrawal limit" - you can simply move any amount/fraction of bitcoins you own from your wallet to any address which you want to send to.

Commented by /u/KiFastCallEntry in /r/Bitcoin on November 26, 2022 13:40:11

>low fees A (non-custodial) wallet itself doesn't charge you any fee (because it's nothing more than a piece of software which allows you to move bitcoins on the blockchain) - the transaction fee goes to miners. If there's congestion (mempool backlog, so that your transaction has to wait before getting its first confirmation) you then have to compete with other users by raising fee rate (sat/vbyte) to prioritise your transaction - RBF helps you in this situation by allowing you to raise fee rate afterwards. >frequently transacting In my opinion, I don't recommend keeping bitcoins in your own (non-custodial) wallet if you transact very frequently, because blockchain confirmation not only takes relatively long/unpredicatable time but also charges you miner fees (mentioned above). If your exchange/service supports lightning network you can then keep self-custody without the confirmation waiting time/miner fee problems, however LN fundamentally cannot be restored by your mnemonic words because channel data cannot be deterministically derived from it. Some wallets like [Phoenix]( developed by ACINQ are able to handle this problem for you (so that you as the user can still keep nothing more than the 12-word mnemonic phrase), however you rely on their service in this case, which kind of violating the definition of self-custody.

Commented by /u/KiFastCallEntry in /r/Bitcoin on November 26, 2022 13:34:50


Commented by /u/KiFastCallEntry in /r/China_irl on January 20, 2022 14:44:49


Commented by /u/KiFastCallEntry in /r/China_irl on January 20, 2022 14:38:40


Commented by /u/KiFastCallEntry in /r/China_irl on December 31, 2021 02:21:23

虽然是开放注册没有门槛,很多年前就有人吐槽社区水化,但也不至于有楼上说的那么不堪吧。 我来逆风尬吹一下,就比如shadowsocks,我记得就是在那里发布的(后来还专门给它开了个子版块,虽然那个子版块后来各种加码增加访问限制减小曝光度)。 被墙过,然后为了解封而在墙内备案过,但后来又搬了出来、彻底被墙……可以稍微翻翻知乎(注册墙可以通过在搜索引擎搜索点进具体内容来绕开)和维基百科。 放个暴论,我觉得v2ex有和这个sub类似的里外不是人的微妙境遇。比如你可以参照这个知乎帖子和楼上的回复:

Commented by /u/KiFastCallEntry in /r/China_irl on December 28, 2021 17:03:51

你sub前两天刚刚才从v2ex转过关于steam被墙的帖子:转载_关于steam被墙的专业解读_及部分评论/ 原帖链接是这个: 原标题:Steam 商店 疑似 443 端口被干扰? ICMP 80 端口均正常

Commented by /u/KiFastCallEntry in /r/China_irl on December 27, 2021 15:07:18


Commented by /u/KiFastCallEntry in /r/China_irl on December 26, 2021 08:54:06

Not sure whether other people have posted similar comments, but I still have to say: no, it's not "DNS cache poisoning": Tldr: GFW stealthily destabilizes the connection between Chinese users and intl Steam servers. It's not fully blocked, just destabilized, which is the reason why there are conflicting reports.

Commented by /u/KiFastCallEntry in /r/Games on December 26, 2021 08:40:35

No it's not DNS cache poisoning. See my post here:

Commented by /u/KiFastCallEntry in /r/gamedev on December 26, 2021 08:30:35

(sorry for my bad English grammar) >some reports/rumors saying "DNS poisoning" No it's not. It's actually *destabilized* rather than fully *blocked* so that the connections **occasionally** break. DNS responses are not polluted. The current situation is: imposed probabilistic packet loss according to host name leaked by TLS SNI. That's saying, the GFW knows we are connecting Steam by peeking through the SNI field of TLS client hello request headers, then it will stealthily drop *some* (not all, generally) packets to destabilize our connection to Steam. Currently this mechanism has a hilarious flaw that if you (inside the GFW) attempt to connect to any random website outside the GFW, pretending as if it was Steam (using `curl --resolve`), then the GFW (being triggered by SNI) will start to impose such nasty packet loss on your connection as well. For now it indicates it's GFW rather than natural technical outage (especially with a negative control using hostnames other than ``), however who knows what GFW will do in the next hour/day/month/year...

Commented by /u/KiFastCallEntry in /r/gamedev on December 26, 2021 08:25:24

If you wipe trezor without valid seed backup, maybe some fund was stored on forgotten passphrase, then it's permanently lost after wiping the seed from trezor.

Commented by /u/KiFastCallEntry in /r/TREZOR on October 10, 2021 23:51:18

Watch out for passphrase

Commented by /u/KiFastCallEntry in /r/TREZOR on October 10, 2021 09:49:46

Oh thanks, but I have already fixed this problem myself. In fact lghub\_updater.exe crashed every time I launched it, until I managed to fix this problem using the trick described in my post.

Commented by /u/KiFastCallEntry in /r/LogitechG on September 22, 2021 13:34:15

It's my first time to install G Hub. I had't installed it before.

Commented by /u/KiFastCallEntry in /r/LogitechG on September 21, 2021 17:03:56

又搜了一下: >南京市启动第六轮部分区域大范围核酸检测 > >据央视新闻消息,今天(8月8日)上午,江苏省南京市召开新闻发布会,介绍疫情防控最新情况。发布会上,南京市卫健委副主任丁小平介绍: > >南京市启动第六轮部分区域大范围核酸检测。本轮核酸检测的区域包括21个街道和镇,浦口区、栖霞区、六合区、高淳区、江北新区不在本轮核酸检测范围。 [\_114988]( 第六次确实不止江宁区,但也不是全城全部覆盖,只覆盖重点的街道。 前几次我懒得搜了……

Commented by /u/KiFastCallEntry in /r/China_irl on August 27, 2021 10:50:02

而且大规模普筛其实也会搞不止一次。就像楼上说的一样,很显然不可能是全国14亿都测,只是重点城市重点区域会测(而且是10人混一管这样混检)。但就南京江宁区来说,3天一轮普筛,测了5轮还是多少轮来着…… edit: 大概搜了一下,南京全城貌似是3轮: 南京江宁区6轮: 江宁区部分区域还有第7轮:

Commented by /u/KiFastCallEntry in /r/China_irl on August 26, 2021 18:57:32


Commented by /u/KiFastCallEntry in /r/China_irl on August 26, 2021 18:51:15

首先流调其实就已经排查出密接和次密接了,已经把感染风险比较高的人都圈起来送去集中隔离,或者要求居家隔离了。管你真阴性还是假阴性,都隔离。 然后,就算(大范围全员普筛)假阴性漏出去一两个(而且跑到流调排查范围之外)又如何……要么传染开,然后下面这一串总得有人能测出来真阳性了吧?要么传不开,那这个人自己也迟早自愈。 只要出一个阳性,一个小区都给你封了(具体我也不是非常了解,但我这么说大概也不算多夸张),再加上整个城市级别的各种限制人流量的封锁措施(这个真有代价,不仅仅是设个路障拦起来不让进,不少店面都停业了)……最终收敛到归零(真•归零)貌似并不难。

Commented by /u/KiFastCallEntry in /r/China_irl on August 26, 2021 18:46:59


Commented by /u/KiFastCallEntry in /r/China_irl on August 20, 2021 16:35:16


Commented by /u/KiFastCallEntry in /r/China_irl on August 12, 2021 05:31:01


Commented by /u/KiFastCallEntry in /r/China_irl on August 11, 2021 18:05:48

“什么是荣 什么是耻 八荣八耻 人人须知” “习近平新时代中国特色社会主义思想” 差别也许没多大吧,貌似也就是习把自己的名字给突出强调了一下

Commented by /u/KiFastCallEntry in /r/China_irl on July 10, 2021 06:35:14


Commented by /u/KiFastCallEntry in /r/China_irl on July 10, 2021 06:29:42

挺多地方吧,比如 (不过现在有广告了)

Commented by /u/KiFastCallEntry in /r/China_irl on July 7, 2021 07:17:00

我主要想说的不是什么唯结果论之类的,而是……哎其实我自己也不是很清楚,大概就是自由派一直叨叨的陈词滥调吧,“文革2.0”。 科学上的事情不说什么唯结果论,也是一切以事实为依据吧,事实和理论不符,要么修正理论,要么抛弃旧理论创造新理论。 然后社会政治上的事情就完全不一样了,就像……比如堕胎和反堕胎?在美国可能这两派永远都说服不了对方,都觉得对方不可理喻;作为中国人可能还会感觉“卧槽这居然还能成为一个问题”觉得这个争论的存在本身就很荒唐。这个好像并不是什么理论是不是经得起实践检验,就好像……我也不知道这个例子合不合适,有人说智能设计论其实就是披着科学外衣的神创论,其实还是反科学的,于是,我觉得这某种程度上也能算是“理论的进化”…… 说出来可能有点搞笑,我甚至觉得“粉红”这一派是不是有点复仇的心态?(而不是挺多反贼叨叨的所谓“大逃杀内卷”)所谓“十年以前”好像他们都被当作皇帝的新装一样对待,太憋屈了,所以现在他们觉得既然一切都拨乱反正了,那就要把他们眼中“真正的老鼠”一个个都抓出来、人人喊打,老虎要打,苍蝇也要打[doge] 哎,说着说着我都理不清楚自己在说啥了(所以主贴我都自删了,抱歉)

Commented by /u/KiFastCallEntry in /r/China_irl on July 7, 2021 05:29:25

>内核驱动的签名 你说的是驱动签名强制(DSE)么?我记得DSE本质上并不靠谱,因为各种需要加载进内核的驱动太多了,总是会有厂商搞出来含有漏洞的驱动,然后利用漏洞就可以进ring0执行代码,这样DSE就形同虚设了。即便是封杀证书(实际上貌似也没真正封,至少好多年前,天翼蓝屏事件里的木马其实就是用吊销证书签的名,照样开机加载进内核,照样引发蓝屏)肯定也有滞后,而且还可能误伤,误伤可能导致无法开机之类的。 而且回到TPM这个话题上……我不记得DSE这玩意和TPM有啥关系……

Commented by /u/KiFastCallEntry in /r/China_irl on June 28, 2021 08:00:44

我是半桶水……不过我印象里TPM实际上并不是做加解密运算的,它在BitLocker里只是负责保管密钥,开机时PIN输对了就放出来密钥这样,然后密钥还是会被CPU知道,被读到内存里。 再然后读写硬盘时的on-the-fly加解密还是CPU在做,然后现在CPU也有AES硬件加速,所以性能也不差。 除此之外后来的BitLocker还支持offloading,可以让硬盘自己完成加解密运算,所以加解密运算不再占用CPU的性能。 (不过,offloading这种情况下密钥是不是还是先会被CPU读到内存里,再喂给硬盘,这个我就不知道了)

Commented by /u/KiFastCallEntry in /r/China_irl on June 28, 2021 07:54:28

BitLocker本质上并不依赖TPM,组策略里就有选项,打开所谓的“额外验证”,就可以手动输密码。有TPM只是使用方便很多,可以用很短的PIN(因为TPM被认为在硬件上可以防止暴力试错破解),不用记忆和输入很长很难记住的复杂密码。 还有,其实强密码也未必是一堆乱七八糟的乱码……就像币圈用的BIP39助记词,从2048个单词的单词表里随机挑选12个英文单词(实际上是先生成128bit的随机熵,再据此算出4bit的校验码,然后再把这个132bit编码成12个单词……不过不要在意这些细节),就能表示128bit的熵,足够强了,和比特币用的secp256k1 ECDSA数字签名强度是等同的。记住12个英文单词,我感觉未必是多难的事情。

Commented by /u/KiFastCallEntry in /r/China_irl on June 28, 2021 07:27:02

新网站非得迁就旧浏览器,这个可能确实是挺恶心的。 但是,要求所有网页都必须跟着新技术走,我感觉这个要求还是有点霸道了。(虽然,留着一个年久失修被发现各种安全漏洞的东西在系统里同样挺恶心的?) 所以我不觉得这事喜大普奔,只想叹一口气。

Commented by /u/KiFastCallEntry in /r/China_irl on June 28, 2021 07:21:03


Commented by /u/KiFastCallEntry in /r/China_irl on June 7, 2021 09:03:37


Commented by /u/KiFastCallEntry in /r/China_irl on May 30, 2021 01:57:47

额,比特币矿工和节点这两个角色早就是分离状态了吧……只在极早期的时候这两个角色才是重合的。 极早期的时候挖矿的人也不多,也没有怎么“产业化”。后来挖矿的人越来越多,每天能挖出的“矿”(区块)数量则是基本固定的(难度调整机制会自动调整到接近每天144块),如果你算力很小,可能几个月都挖不到一块矿。所以为了稳定收入,绝大多数矿工都加入矿池了。 更不用说比特币很早就被ASIC矿机统治了。矿机唯一的功能就是暴力试错算哈希值,并不在乎矿池喂给自己的任务挖的是什么链;矿工其实也基本不在乎,只要能赚到钱怎么来都OK。 所以这也是比特币经常被批评说丧失去中心化的一个老梗…… 也就比特币的开发者们算是有信仰,最近几年搞了新的挖矿协议,声称是让矿工重新取回“具体在挖什么”的选择权…… 我不知道矿圈具体情况,不过凭直觉的话,情况应该仍然不乐观。 前一阵子我还在知乎上看到一篇文章,写的是自己怎么帮助别人诊断出托管矿机时被中间人攻击偷算力的故事(啊,不过有一说一,那个故事里的矿机是显卡矿机,主要挖ETH的,不是BTC),写得跟侦探小说似的……但从原理上讲真是不新鲜,也不“高级”。所以我可以暴论一下:矿工在技术以及信仰方面是什么样的状况,管中窥豹,可见一斑。 (严格来讲,矿池的中心化,和矿机以及矿主在地理分布以及法律上所有权的中心化,其实是两个层面的事情。比特币开发者提出新挖矿协议,就是在第一个层面的中心化很难挽回的情况下,重新发掘第二个层面的去中心化潜力,同时减轻第一个层面中心化的影响,从而改善局面)

Commented by /u/KiFastCallEntry in /r/China_irl on May 24, 2021 04:29:57

还有,混币的问题就是所有人都可以看到你的币是混过的,而且跟你一同混币的可能有洗黑钱的人。混币只是混完了大家都搅和在一起了、分不清各自去向而已。 我记得有些交易所还把xmr之类隐私币给直接下架了。

Commented by /u/KiFastCallEntry in /r/China_irl on April 16, 2021 14:47:41

据我所知比较靠谱的就是wasabi wallet,用的chaumian coinjoin 其实理论上光是用轻钱包就可能造成泄露导致白混,因为钱包服务器知道某个IP查询了一串btc地址,那么这些btc地址应该就都是同一个人的马甲。

Commented by /u/KiFastCallEntry in /r/China_irl on April 16, 2021 14:13:08


Commented by /u/KiFastCallEntry in /r/China_irl on April 16, 2021 14:12:25

还有,我感觉好像极少有人会否定女性是弱势群体吧?生孩子需要社会支持,这个我觉得应该也是绝大多数人都同意的,只不过是实操起来貌似很难落实。 这类事情我觉得说难听点可以说是老大难问题,但不代表社会上所有人都不愿意解决这些问题。 换个说法,这些问题也可以算是“老生常谈”。在我浅薄的见识里,女拳闹来闹去,眼球还是都被吸引到“女拳”身上去了,原来存在的问题未必见得因为有女拳来闹就能往积极的方向转变。

Commented by /u/KiFastCallEntry in /r/China_irl on April 14, 2021 22:25:18


Commented by /u/KiFastCallEntry in /r/China_irl on April 14, 2021 22:00:55


Commented by /u/KiFastCallEntry in /r/China_irl on April 14, 2021 21:59:59

“在这些“极端女权”出现之前,性别议题受到的关注少多了”——怎么算多怎么算少,这个好像很难扯明白。反正在我印象里第一次看到女权开始上推送热点的时候,就已经是女权VS女拳的分辨了。 “至少大家都开始讨论性别问题了”——然后就是极端分子互相撕,正常人有时都不敢开口说话。 “如果你从小就心安理得地接受父母的偏爱,认为身为男性就是要做一家之主,可能你不会意识到父母的做法是错误的,也不会意识到妹妹被差别对待”——这样的人肯定存在,这种人才是斗争对象,即便如此也不是要诅咒对方去死,促使这种人的思想行为发生改变才是目的不是么。 “也许你所说的那种妹妹的确存在”——我已经说了我是“诉诸感情”。哪怕是坐公交车,旁边有个人大大咧咧破口大骂,你至少也会避着他三分不是么。

Commented by /u/KiFastCallEntry in /r/China_irl on April 14, 2021 21:47:04

“敌意是怎么来的”——冤有头债有主,把仇恨指向全体男性的时候,极端女拳为什么不思考一下对面的仇恨是哪来的? 争取平权是毋庸置疑的好事。到底怎样才算平权存在争议也正常。采取拒绝交流的仇恨态度(另一个层面我觉得就是试图霸占话语权,只有我同意的才是正确的,我不同意的都非蠢即坏),我觉得啊,怎么看,都不像是要提建设性建议,不是要解决问题。 能无视这些极端言论已经是我能做到的最大宽容。

Commented by /u/KiFastCallEntry in /r/China_irl on April 14, 2021 21:38:54

楼主的逻辑在我这里很难捋顺。 楼主举了(面对老封建家庭)被偏爱的弟弟、(面对不负责且歧视女性的老板)被男同学刷掉等等例子,这些例子涉及到的问题和诉求好像本来就不是同工同酬能完全涵盖的。这本来就不完全是一码事啊,有什么奇怪的么?就比如,社会上封建遗毒确实没有扫清,那你举着同工同酬的大炮当然打不准了…… 再有就是,楼主是不是认为不讲道理的“反抗”是有建设性的?为什么?能稍微讲明白一点么? 在我看来不分青红皂白的所谓反抗,很多时候只不过是转移矛盾、饮鸩止渴,很可能不仅没有建设性,反倒会让问题更加复杂、更加积重难返。 然后我再诉诸感情一下。 大言不惭地讲,如果我有个妹妹,父母非得偏着我,什么资源都不分给/少分给妹妹,那我肯定是要向父母抗议的,哪怕这反过来会让我受到的偏爱减少。功利地讲,可以解释成我不想搞成兄妹反目(多一个仇人对我不利);但我觉得我不是出于功利的目的,我就是觉得这个时代还讲究那套重男轻女的封建老古板不可接受。 但是如果这个妹妹看到我就不顺眼,天天想打小报告找我的茬给我下绊子想让我倒霉(而不仅仅是嘴上骂一骂),诅咒我怎么不早点死,你说我在这种情况下还要同情这个妹妹,需要多高的思想境界?如果我不是出生于老封建家庭,却仍然有这么一个妹妹呢?

Commented by /u/KiFastCallEntry in /r/China_irl on April 14, 2021 04:01:43


Commented by /u/KiFastCallEntry in /r/China_irl on April 14, 2021 02:31:06


Commented by /u/KiFastCallEntry in /r/China_irl on April 12, 2021 03:05:27

前一阵子[在推上看到](说辉瑞疫苗对南非 B.1.351 变种(含E484K突变)临床效果看上去也非常好,疫苗组病例数为0,安慰剂对照组病例数则是9(样本总量 800 )。 简而言之,难道mRNA疫苗效果就那么好,即便不更新(edit:[有报道](的改良新冠疫苗开始进行人体测试-11615430711)说moderna已经针对变异毒株更新了疫苗,现在已经开始临床试验,但目前貌似也仅限于此),目前也不怎么受变异影响?而相比之下灭活疫苗就不太行,尤其是科兴,同是灭活疫苗里它好像最糟糕? 感觉有点出乎意料。或者说其实我还抱有怀疑。我记得疫苗三期临床是需要攒到足够多的感染病例才足以得出比较可靠的结论的,至少现在看感染病例数就实在是太少。 ​ 印象里,之前看到,[DrEricDing 发推说](,南非的实验室用康复患者的血清检测,发现竟然有一半样本完全就不能中和病毒,(以我这个外行视角看)很不乐观。虽然当时看到DrEricDing 在推上说其实即便中和抗体滴度下降了,对疫苗影响也应该不是很大,因为中和抗体滴度即便下降了也仍然高于能形成有效保护的门槛,所以有效率大概只会降几个百分点……但说实话我感觉这好像有点太乐观了。 而且我记得之前很多地方都说巴西玛瑙斯本来都自然群体免疫了(这其实已经蛮惨的了),结果带E484K突变的变种来了,群体免疫又没了,二次爆发了,惨不忍睹…… 疫苗诱导的免疫力比自然感染得到的免疫力更强,这个大概也不奇怪;但是现在看到的好消息感觉似乎是too good to be true了。

Commented by /u/KiFastCallEntry in /r/China_irl on April 11, 2021 14:38:01


Commented by /u/KiFastCallEntry in /r/China_irl on April 6, 2021 11:53:31

Thank you very much for your hard work.

Commented by /u/KiFastCallEntry in /r/androiddev on March 2, 2021 13:49:27

(之前的内容编辑掉了,算了,少倒点垃圾吧) 虽然说幸灾乐祸不好,但是推上看到老美貌似有很多人自己都不怎么在乎呢……摊手。感觉在那边支持严格抗疫的人应该很绝望吧。

Commented by /u/KiFastCallEntry in /r/China_irl on February 23, 2021 21:48:57


Commented by /u/KiFastCallEntry in /r/China_irl on February 21, 2021 07:45:06

哎,看着难受。楼上貌似指望着疫苗最不济可以减轻症状和死亡率,但是即便打了疫苗我也绝对不想得一遍(甚至可能是好几遍,考虑到免疫未必能长期保持,以及免疫逃逸突变)新冠。然而我在这里说很显然是没有任何卵用的。 未来会不会放开,我也不知道。不过对于成功控制疫情的国家地区,放开限制是理所当然的吧。越多地区成功搞定疫情,“解放区”覆盖面就越大。我觉得未来应该是这个样子。

Commented by /u/KiFastCallEntry in /r/China_irl on February 13, 2021 11:30:48

我之前的回贴戾气比较重,不合适,所以我自删了。 不过我还是忍不住想把我这些不新鲜的观点啰嗦啰嗦: 1.我当然认为这些抗疫措施都是正确的、必要的,但是在这次疫情面前可以起到决定性作用么?也许南京比别的四五六线小城镇做得好,而且之前清零了那么久也会导致防控措施松懈,但是……**如果仅仅靠量量体温、布置塑料隔离膜之类轻描淡写的措施就能搞定这个病毒、把R0压制到1以下,那也许疫情初期的封城都不是必要的了,最近也不会有二次爆发了。** 当然,视频里的措施也远不止量量体温什么的,我觉得最重要关键的还是能够根据登记信息回溯追踪密切接触者,这个就属于用不着的时候嫌麻烦、用得着的时候能救命的关键措施(有点“事后止损”那意思,但意义远不止止损)。即便二次爆发还是发生了,很显然能够有效追踪密接和两眼一抹黑那还是天壤之别。 2.站在中国人立场上,看到有外国友人用自己的作品把中国的优秀展示给全世界,当然应该是开心的。但是,思维跳跃一下,现在距离去年刚刚把第一波疫情清零(也大概是这个纪录片发布的时候)**过去了近一年**,抗疫措施又不是没有影响没有代价的,尤其是不幸接触过高风险人员或者身处高风险地区的人……**因为封锁措施而产生怨气几乎是必然的**。我不知道本sub对“零号病人”尹老太怎么看,反正我个人的观点就是她不幸碰巧成了人民群众的出气筒。 回到这个纪录片本身,现在回顾一年前的这个纪录片,不同人感受不一样,但反正我个人的心情就是:不再那么畅快了,哪怕国内刚刚才成功把这次二次爆发清零,也不知道下一次疫情打地鼠会不会打到自己居住的城市。 3.很显然这次疫情的重心目前已经不在国内了,反倒是国内持续面临境外输入的压力。*我也知道世界很大,老实说绝大多数国家在哪我都找不到……所以我只能把自己有限的眼界能看到的东西拿出来说说。* 前一阵子观察者网乃至国内对荷兰反封城抗议/暴乱的幸灾乐祸,其实荷兰那边也知道。就比如这个讨论串,里面有[转述国内对西方疫情的评论]( >现在是整个欧美都陷入了严重新冠疫情灾难中。**西方政府措施不力,民众对抗政府的防疫措施。由此恶性循环**,西方从根本上难以达到中国的防疫水平,已无力回天 我看下面也有人对这个观点表示认同。 4.但是,就比如吧,这位哥,是一位荷兰的程序员,原来是搞物理的,现在是Bitcoin Core开发者,[他是坚决支持严控疫情的,文章中甚至对中国的抗疫成果做了辩护(不过这也是为了反驳西方一部分人对中国疫情控制成果的否认)](。**他作为一个曾经给中国抗疫成果辩护过的西方人,看到上述的推文讨论串,也仍然是当场就破防了**,[整了个whataboutism怼了回去](。 (额,可能我这样直接贴推文链接也有点不礼貌,希望大家不要顺着链接随随便便去打扰别人) 于是我思维就又跳跃了,就在想,西方人看到竹内亮导演的这个纪录片,真的会虚心接受、并反思学习么?恐怕是悬。 5.再有,也许是哪壶不开提哪壶了,但是回想起中国官方在疫情初期的所作所为……反正我是不能给先是官宣“持续人传人风险低”,然后前脚刚刚宣布武汉封城,后脚就让世卫组织不要宣布PHEIC之类的行为做辩护。也许可以说这就是维护国家利益,天经地义,但这么“维护”,我感觉其实是在给自己挖坑。 6.虽然中国官方前期的做法确实操蛋,但是其他(尤其是部分西方)国家的状况又要操蛋十倍百倍;而且……大概什么样的人民配什么样的政府?西方有些人到现在还主张新冠是不可能积极主动采取措施去控制住的,甚至[将“零新冠”和封城支持者称为“邪教徒”“狂信徒”](。 世界是一个整体,任何一个地方控制不住疫情,整场疫情就无法结束。 7.疫苗能给这次疫情带来希望么?也许,但是因为病毒已经产生了免疫逃逸突变,最近刚刚才有[阿斯利康的一款疫苗在南非被暂停接种](了。我也看到有专家表示现有疫苗[应该仍然会有效,只是有效率会略微下降](对这一点我也有点怀疑,因为有瑞德西韦这个先例)。再有就是疫苗都是可以更新的,可以做成多价疫苗,但是真的可以追得上病毒突变么?万一出现ADE之类更糟糕的情况呢?

Commented by /u/KiFastCallEntry in /r/China_irl on February 13, 2021 09:53:03


Commented by /u/KiFastCallEntry in /r/China_irl on January 27, 2021 00:05:49


Commented by /u/KiFastCallEntry in /r/China_irl on January 1, 2021 23:26:51

我不算懂哥……纯外行。 可控核聚变是否真的有传说中那么美好? - 见南山的回答 - 知乎 []( 英文原文:[]( >但是与太阳聚变产物几乎无害不同的是, 地球上的聚变反应堆高能中子流占氘氚反应聚变能量输出的80%,氘 - 氘反应的35%。现在,由80%高能中子流组成的能源可以说是完美的中子源,但真正奇怪的是,它却被誉为是理想的电源。事实上,这些中子流直接导致了四个难以解决的问题:辐射对结构的破坏,大量放射性废物;生物屏蔽的需要;以及生产武器级钚239的潜力 - 从而增加了核武器扩散的威胁,而不是减少它,因为聚变支持者会拥有它。 (“从而增加了核武器扩散的威胁,而不是减少它,因为聚变支持者会拥有它”这里貌似是翻译错了?我感觉应该是“从而增加了核武器扩散的威胁,而不是像聚变支持者认为的那样会减少这个威胁”) ​ (我不是针对哪个国家,这个事情无论在哪个国家都是一样的)

Commented by /u/KiFastCallEntry in /r/China_irl on December 28, 2020 02:41:54

纯外行,复制粘贴一下我比较相信的: 可控核聚变是否真的有传说中那么美好? - 见南山的回答 - 知乎 []( 英文原文(这个网站上有著名的doomsday clock):[]( >但是与太阳聚变产物几乎无害不同的是, 地球上的聚变反应堆高能中子流占氘氚反应聚变能量输出的80%,氘 - 氘反应的35%。现在,由80%高能中子流组成的能源可以说是完美的中子源,但真正奇怪的是,它却被誉为是理想的电源。事实上,这些中子流直接导致了四个难以解决的问题:辐射对结构的破坏,大量放射性废物;生物屏蔽的需要;以及生产武器级钚239的潜力 - 从而增加了核武器扩散的威胁,而不是减少它,因为聚变支持者会拥有它。 (“从而增加了核武器扩散的威胁,而不是减少它,因为聚变支持者会拥有它”这里貌似是翻译错了?我感觉应该是“从而增加了核武器扩散的威胁,而不是像聚变支持者认为的那样会减少这个威胁”) ​ (我不是针对哪个国家,这个事情无论在哪个国家都是一样的)

Commented by /u/KiFastCallEntry in /r/China_irl on December 28, 2020 02:01:09


Commented by /u/KiFastCallEntry in /r/China_irl on December 17, 2020 08:09:48
/r/China_irl/comments/k7jpbu/mit研究莫德纳和辉瑞的新馆疫苗对亚裔效果更低/get0xpg/ 随便搜到的,感觉炒菜油烟这个解释还是蛮合理的(虽然这未必有严格的科学证据和分析)。

Commented by /u/KiFastCallEntry in /r/China_irl on December 6, 2020 04:42:16

我说的不是这次疫苗的事情,我回复的是楼上,癌症靶向药的事情。我记得当时是读了这篇文章: 但是现在翻出来重新看了一下,好像文中也没有具体分析出现这种差异的原因,尤其是没有提生活习惯这方面。也许是我记错了。

Commented by /u/KiFastCallEntry in /r/China_irl on December 6, 2020 04:12:27


Commented by /u/KiFastCallEntry in /r/China_irl on December 6, 2020 02:45:57

>even if you don't enable the Registration Lock, they would not gain access to any of your Signal data. What if the Signal PIN is disabled? Edit: IIRC, enabling PIN just *allows* recovery from the same phone number in cases like app reinstall. Without PIN, the previous account data is simply locked up forever. However I'm not currently quite sure about this.

Commented by /u/KiFastCallEntry in /r/signal on November 24, 2020 06:47:25

By the way, what actually worried me was that: my device suddenly rebooted with a "black out" several weeks ago, after that I found that the secure startup was disabled - the userdata partition was still encrypted, however it didn't require my password to decrypt. I then set up the password once again to re-enable secure startup. I don't know whether this was related to the issue you posted.

Commented by /u/KiFastCallEntry in /r/LineageOS on November 20, 2020 11:29:13

I don't know. It doesn't look like to be the same situation of me. >KLTE bootloops at least after the second reboot after typing in the encryption key at "preboot" stage. My device bootlooped **before** typing the decryption password - I was unable to see the decrypt prompt at all. To be honest, my device is still not totally working flawlessly, probably. It still seems to fail to boot (bootloop) sometimes (before the decryption prompt IIRC), however this doesn't disturb me so much, because it doesn't take much time to boot into the decryption prompt. I can simply press power key down to force a reboot. Actually I'm not quite sure whether this problem is related to OpenGapps.

Commented by /u/KiFastCallEntry in /r/LineageOS on November 20, 2020 11:24:59

>It's not necessary to update Open GApps Thanks. Sometimes I just want to squeeze a little bit more space by uninstalling the update. >What is you device model & recovery version? twrp-3.4.0-0-z2\_plus >If you want a GApps dev to notice it & help other users you could report it in the Open GApps support thread on XDA I'm not quite sure whether this is reproducible. I'm also too lazy to enable adb logcat etc on-boot...

Commented by /u/KiFastCallEntry in /r/LineageOS on November 20, 2020 05:42:02

一边觉得自己病倒不是因为新冠,一边又喊着要大夫给他开(川普钦定的?)神药…… 说实话疫情期间搞几个神药我不反对,甚至支持,毕竟维系社会信心也很重要,最差也就是望梅止渴的white lie嘛。 但是“都有神药了还抗什么疫”这个就是截然不同的另一回事了。

Commented by /u/KiFastCallEntry in /r/China_irl on November 17, 2020 03:44:02

“的确有困难”,这一点我刚刚编辑了最初对你的 [回复](客座评论中国自由主义群体因美大选分裂_德国之声中文网/gbxcjpi),加上了我对这个问题的看法。

Commented by /u/KiFastCallEntry in /r/China_irl on November 11, 2020 08:49:56

对于经济状况不差的人来说,即便强调“性行为并不是神圣不可亵玩”,只要是生命神圣性支持的堕胎禁令等在后面等着,那很显然性行为的自由实质上就收缩了。 即便是不滥交的家庭,只要有性生活,那就避免不了怀孕。说实话但凡是堕胎我都觉得挺恶心,但是我还是更愿意手握选择权,甚至是犹豫到最后一刻的选择权。

Commented by /u/KiFastCallEntry in /r/China_irl on November 11, 2020 08:25:47

病人这里,你的意思貌似是有清醒意识且能够表达自己的意愿,而不是(一般认为是外界/社会赋予的)“选择权”。所以这里其实就不好说了,一个人说“我愿意死”,他就真的愿意死么?多数情况是被逼无奈吧,但凡有不用死的选项,他就不用“选择”死了。 至于降低生活质量,你似乎是制造了一个道德上可以谴责的情景。我之前就说了,能玩到随随便便堕胎的女性,有不少本来就(其实这也只是以社会世俗眼光来看)是不太检点,对自己都不负责,这才是问题的根源,堕胎“只是症状,不是病因”。而且我也提了相互拖累,甚至恶性循环这种现实中经常发生的状况。 然后我觉得,按照这个思路,貌似不仅生命是神圣的(实际上我觉得这个概念蛮扯蛋),生殖行为也是神圣的(不瞒你说,我中学生物老师讲这块内容的时候就提了一嘴“生殖是神圣的”,哈哈),于是……嗯,这就有意思了,我印象里,貌似“性是神圣的,不可亵玩”是某些教徒才会认可的教条。于是性行为就不能再是自由的了,一不小心就要犯什么重罪了…… 最后,虽然我不了解,但是中国至少也有福利院,而且愿意收养孩子的家庭虽然占比可能确实极少,绝对数量还是不少的,然后社会上一般也认为这种行为是高尚的吧。

Commented by /u/KiFastCallEntry in /r/China_irl on November 11, 2020 08:20:11

刚刚我说可以按照早产儿是否能够生存来划定界限,实际上,这么想我也是给自己挖坑把自己埋了。 有个关键的问题,就是我一开始说的“算不算杀人”,不管界限怎么划定,这都是实实在在会落到女性头上的限制甚至是罪名。 如果一个病人因为缺钱得不到救治,也许会有人觉得他的亲属有罪,甚至觉得整个社会有罪;但也有不少人会觉得这就是现实的无奈,人的能力是有限的,不能让人长生不老,死亡是不可避免的,甚至病人本身可能都会觉得愧疚,认为自己的苟延残喘拖累了家人。(这里还可以绕回到potential的问题上,实际上如果病人活下来了,也是有potential的不是么,并不是只有小婴儿才有potential;而且除开potential,也可以说并不是弱者、是一个苟延残喘的病人,就没有生命权) 我觉得堕胎也应该类似于这种情况。而且我觉得应该尽量向非罪化方向靠拢。

Commented by /u/KiFastCallEntry in /r/China_irl on November 11, 2020 07:30:27

首先,关键并不是受精卵这种细节问题。其实我举受精卵这个例子是舍近求远了,堕胎不就是人工流产么,流产的概念比堕胎大多了,流产的情况可多了,然后岂不是统统都能算杀人…… 至于potential,这个也不好说啊…… 首先,现实中怎么才能让这个potential避免发展成互相拖累恶性循环呢? 其次,在我看来,根本问题在于,胚胎其实就和器官一样,就是一块切离母体后即会失去生命活性的肉,并不能独立生存,这一点上胚胎其实和器官更相似。 于是我可以耍个流氓:一个器官移植给别人,算不算器官有potential?也许照这么说,人受伤也是过失犯罪,自残更是故意犯罪(我朝传统貌似也有类似的说法,“身体发肤,受之父母”——嗯,扯远了)。 (扯太远了,我拉回来一点)胎儿有没有生命权,这个问题也许本质上就比较模糊,比如婴儿没有人照料的话也不能“独立生存”;甚至再扯大点,哪怕是成人,脱离社会也不能(或者说很难)“独立生存”(嗯,扯得更远了)。 我觉得总得有个界限,虽然我是外行,但据我所知,早产儿即便出生也更难活下来,太早了甚至压根就无法生存,这也算是公认的事实吧。我不知道别人怎么想,但我觉得从这个角度出发去划定界限还是可以接受的。(说到这里,其实我觉得这和需要投入大量资源还未必能救治成功的病人情况已经有点类似了) 最后,这确实是个复杂的社会问题。理想中,只要健康的孩子都能生下来(甚至不怎么健康的都仍然可以让ta尽量健康),然后让社会公共资源去养育ta,让ta能够健康长大,即便父母有不堪的过往也不会拖累到孩子,我也觉得是一幅很美的图景。不过很可惜,现实是复杂的,无奈的,丑陋的,现实和理想不是一回事。

Commented by /u/KiFastCallEntry in /r/China_irl on November 11, 2020 07:10:12

有生命的东西多了去了……这是个抬杠的话题。扯远点,虽然伦理上禁止,但是技术上并不是不可能克隆人。不扯那么远,比如人工授精技术,可能也不是一次就能成功吧,难道失败了就算杀人么。 而且这不仅是缺钱这么简单的事情,谁都知道养育孩子不容易,十年树木百年树人。能随随便便就堕胎的女性,八成是不怎么靠谱,对自己都不负责(所以才“随便”),对孩子那不就更悬了。

Commented by /u/KiFastCallEntry in /r/China_irl on November 11, 2020 06:40:26

反正我是理解不了老外为啥会搞所谓的pro-life运动……如果说理解,那只能从宗教角度“理解”(这就比较厚黑/阴谋论了,也就是“小孩子从小就开始灌输才方便”)。 谁也不会觉得堕胎是好事,都是逼不得已才堕的,哪来的casual呢。堕完了对女性自己的身体也有很大伤害。本来就是两害相权取其轻。 edit:我觉得下面有位朋友,似乎一再想说的是这种情景:经济条件并不差的人,只是不想付出抚育孩子的负担,就选择堕胎。这个看上去确实不能算是逼不得已,但是我还是觉得,现实中给不给堕胎(乃至堕胎算不算犯罪),难道还要额外调查个人/家庭经济状况?这好像有点“管得太宽”了吧。而且我觉得讲到这里就不可避免地会提到性行为的问题,如果性行为的后果(因为所谓“生命神圣性”支持的堕胎禁令而变得)如此沉重,那即便是不说性行为是神圣的,人们自由选择的空间也会毋庸置疑地缩小,会有更多的顾忌,乃至整个社会层面也会有更加保守的风气,对“不检点”的人来说面临“社会性死亡”的威胁会更大——至于什么才叫“不检点”,那就说不定了。

Commented by /u/KiFastCallEntry in /r/China_irl on November 11, 2020 06:26:38

SARS、MERS,不都是不用疫苗就在全世界范围内控制住了……虽然这样比可能确实有点问题,因为新冠传染性强,而且潜伏期还能传染。 edit:我一直都有一种想法,就是这次新冠致死率不太高,不像SARS、MERS那么吓人,所以很多国家就不愿意(下大力气)防(严防死守)了。其实真下大力气不是搞不定,不就是隔离么……就是不想搞。

Commented by /u/KiFastCallEntry in /r/China_irl on November 11, 2020 01:44:48

其实我到现在也不太信(一般的)口罩,我觉得一般的口罩,气密性那是完全没有,所以最大的作用就是阻止飞沫,让已经感染的人(而且还很可能没有自觉,毕竟这病毒潜伏期贼长,好几天,潜伏期又能传染)不要传播给别人,也就是保护别人、保护整个群体; 至于保护自己,我不太相信一般的口罩,大概需要闷得比较死的N95之类(这简直都不能叫口罩了,叫呼吸器还差不多)才比较靠谱。然而N95闷不说,还略贵,使用寿命还不长(主要靠静电吸附过滤病毒吧,受潮了,静电逐渐跑掉了,就不行了)。 很多地方其实都是蛮密闭的,空气各种循环,其实蛮细思恐极的。

Commented by /u/KiFastCallEntry in /r/China_irl on November 11, 2020 00:48:41

应该是我没表达好。我的意思是,对于要给健康人大规模接种的疫苗来说,万分之一的概率仍然是几乎不可接受的高,需要进一步研究搞清楚,排除掉地雷——不过,“需要”“想要”这么做,并不意味着“很快”“就能”做到。 你说的“利大于弊”(刚刚打错,纠正了一下)“避免养蛊”,其实我也有比较大程度的认同,除了一点:中国(其实不止中国,但是我们确实是做的很好)已经用事实证明,不需要疫苗,更不需要特效药,照样可以把这个病毒控制住,甚至近乎消灭。

Commented by /u/KiFastCallEntry in /r/China_irl on November 11, 2020 00:30:15


Commented by /u/KiFastCallEntry in /r/China_irl on November 10, 2020 09:02:03


Commented by /u/KiFastCallEntry in /r/China_irl on November 10, 2020 05:54:49

滞后效应,这个很难说啊……要说这是莫须有,那我也能想到氢化植物油、马兜铃酸之类的例子…… 不过,我还是觉得,如果真有滞后效应,三期临床这么短时间内也照顾不到吧,这得是四期才能监控到了。

Commented by /u/KiFastCallEntry in /r/China_irl on November 10, 2020 05:53:22


Commented by /u/KiFastCallEntry in /r/China_irl on November 10, 2020 02:11:03

严谨地讲,其实“有”未必比“没有”强,万一不仅无效还起反作用呢(就比如前一阵子有人科普的概念,ADE效应)。确实是有赌的成分,但是信心到底有多大、来自哪里,我这个局外人就不知道了——我脑补了一种可能,就是三期虽然没做完,但是早期数据也已经一定程度上显示出效果。(而且前面两期也是过了,才会有三期,安全性和有效性还是有一定程度的验证的,无非就是可信度还不高) 还有,俄罗斯貌似也是被diss的对象吧……

Commented by /u/KiFastCallEntry in /r/China_irl on November 10, 2020 02:08:18

国内紧急使用的疫苗不止一个公司提供吧,科兴应该是其中之一。 >目前不清楚中国已有多少人接种了新冠病毒疫苗。国有企业国药集团的一种疫苗已进入后期试验阶段,该公司称,已有数十万人接种了这种疫苗。**北京科兴控股生物技术有限公司说**,在北京已有一万多人注射了公司的疫苗。另外,该公司表示,几乎所有员工(约3000人)和他们的家人已接种了疫苗。 [](

Commented by /u/KiFastCallEntry in /r/China_irl on November 9, 2020 23:49:57

机器翻译,貌似说这例死亡(可能)与疫苗无关: [\_/status/1325982185548079112]( edit:啊,科兴公司,甚至外交部都一起回应了,与疫苗无关。

Commented by /u/KiFastCallEntry in /r/China_irl on November 9, 2020 23:45:46

我了个去,前两天刚刚才官宣[国药集团:5.6万人接种新冠疫苗后离境 无一感染]( 来着,怎么又来这么一出…… 中国小范围放开紧急接种这事,外媒也报道过不止一次了,貌似都是偏负面的态度,比如: []( >先是国企的工作人员接种。然后是政府官员和疫苗制造企业的员工。接下来是教师、超市员工和去国外高危地区旅行的人。 我虽然是外行,但一直都觉得,只要范围不是扩得特别大,并没有多大问题,因为三期临床本来也是在成千上万的真人身上试、在真实世界进行检验,而且还有安慰剂对照(如果疫苗其实是安全有效呢?不小心抽到安慰剂的岂不是“倒霉”了——甚至,疫苗的三期临床本来就是预定要有一定数量的志愿者染病,才可以产生足够可靠的数据供分析的)。 纽约时报这则9月28日的报道里还提到: >目前不清楚中国已有多少人接种了新冠病毒疫苗。国有企业国药集团的一种疫苗已进入后期试验阶段,该公司称,已有数十万人接种了这种疫苗。**北京科兴控股生物技术有限公司说**,在北京已有一万多人注射了公司的疫苗。另外,该公司表示,几乎所有员工(约3000人)和他们的家人已接种了疫苗。 让子弹飞一会吧……总觉得有点诡异…… ​ 再补个链接,不相关,但是看上去蛮相似的事情,也就刚刚过去没多久: [观察者网:阿斯利康疫苗一巴西志愿者死亡,巴西媒体:接种了安慰剂](

Commented by /u/KiFastCallEntry in /r/China_irl on November 9, 2020 23:24:41


Commented by /u/KiFastCallEntry in /r/China_irl on November 9, 2020 23:18:47

其实事态发展到现在这样真是意想不到。本来以为像非典那样疫情很快就直接被控制了,压根不需要再继续搞疫苗的。 我一直到现在都搞不懂为啥老外对抗疫都那么抵触,要说经济的话不也应该是长痛不如短痛么。

Commented by /u/KiFastCallEntry in /r/China_irl on November 9, 2020 11:31:22


Commented by /u/KiFastCallEntry in /r/China_irl on November 9, 2020 11:26:20

“有效非特效”,我国对磷酸氯喹不也是这个定调么……我之前也信,现在感觉八成只是稳住公众信心的说辞,有点狡猾,但也确实不是坏事,甚至还挺有必要。 瑞德西韦和(羟)氯喹,我主要是信这两篇:

Commented by /u/KiFastCallEntry in /r/China_irl on November 9, 2020 10:42:09

是三期,确实只是期中分析有结果了,不是最终结果,实验还在继续,但目前只是可靠度略差吧,已经可以说明问题了。 同时辉瑞也向FDA提交了紧急使用许可申请。 在我看来这太过于保守了,我国疫苗早就可以紧急使用了,难道美国一直到现在还压根没有紧急使用么(可能是我误解了?也许这个“紧急使用许可”其实是放宽范围,之前也是已经允许少部分人使用)?每天都有人被感染,还有人死去,更不用提连带的经济等方面的影响……少拖一天总是比多拖一天强的。

Commented by /u/KiFastCallEntry in /r/China_irl on November 9, 2020 09:59:53

这样也不是好事,还是科学政治化。我不太相信,也不希望事实是这样。(而且老美这种两党制,不是川就是拜,支持拜基本也就等于反川了,不少人投票给拜其实纯粹就是对川忍不了了,要vote him out)

Commented by /u/KiFastCallEntry in /r/China_irl on November 9, 2020 09:32:17

再扯点不太相关的,有个观点是这次疫情在全世界范围里政治化都太严重了,我非常同意。大难临头还只顾着拉帮结派搞内斗,你球裸猿💊 ​ 就比如瑞德西韦,一开始亲西方的人在国内猛劲吹,一个孤例好了,就是“立竿见影”(也许是我比较low吧,我只看到微博知乎上对中医粉各种输出);然后三期结果出来了(额,结果确实表明是没什么X用),就是(中医粉)各种反攻倒算…… (羟)氯喹也是一样的,这药被懂王盯上真是倒了血霉了,挺懂王=羟氯喹安全有效,黑懂王=羟氯喹毒药无效。实际上羟氯喹应该介于这两者之间吧,没什么X用,但(在不过量乱用的情况下,否则确实够喝一壶)也没啥毒性。 其实就瑞德西韦来讲,我(额,现在)相信它并不是100%一点点用都没有,只是鸡肋,需要用得足够早(现实中几乎做不到),而且需要注射,不方便。另外羟氯喹体外实验的有效剂量和瑞德西韦也是同一个水平,但是在国内就是,羟氯喹和氯喹是区别对待的,前者和懂王一起被往死里黑,后者就没怎么被黑……虽然说这两个药确实结构有区别,但是实际上效果真有那么大区别么?未必吧。 ​ 本来一个纯粹的科学问题,放到现实里,没有几个人能真正做到不带立场、不戴有色眼镜的(大概包括我在内?……我也不是专业人士)。 ​ 这次疫情经常让我想起Rick and Morty,比如Jerry和Beth在外星gagoo面前吵架,两别都是一出现对自己有利的证据就眉开眼笑,那副德行外星人看了都忍不了。 再有就是Armothy那集,我觉得现代人八成多多少少都有点心理疾病,就和Morty一样,把自己身上的情绪纠结都发泄到无关的人身上——嗯,主要这次知乎有个ID是杀生丸的不大不小的V,这次疫情里真是大起大落,先是以体制外高人的形象出现(某种程度上和吹各种药的川粉有意无意地重合在一起了),对国内各种嘲讽;然后国内外疫情反转,又被扒皮批斗……哎,这事让我一直不能释怀(以至于让我用这种小人之心度别人君子之腹,哈哈)。

Commented by /u/KiFastCallEntry in /r/China_irl on November 9, 2020 09:26:21

之前看英国金融时报有讲过疫苗,标题是《新冠疫苗面世还需多久?》 里面提到,实验是否结束,貌似是看入组志愿者的感染数量的,(入组前当然是没有感染啦,看的是入组打过疫苗/安慰剂之后)达到一定的感染数量,就可以在安慰剂组和对照组之间对比分析出来疫苗是不是有效了(这个过程是盲的,只有DSMB专家组成员可以监控数据)。 进行实验的地方疫情越严重,感染人数上升越快,实验就能越早得到结果。 ​ 辉瑞这次宣布的并不是最终的三期临床结果,而是期中分析(interim analysis)的结果。目前是有94例,最终需要164例确诊: []( 而且我也觉得奇怪,辉瑞说刚刚向FDA提交紧急使用许可申请——额,中国疫苗不是早就可以紧急使用了么?难道老美一直到现在都压根没有紧急使用么?这么不敢放开? ​ 要说是不是整川普的阴谋,我感觉不至于吧,如果有这回事,也太明目张胆了。

Commented by /u/KiFastCallEntry in /r/China_irl on November 9, 2020 08:54:45


Commented by /u/KiFastCallEntry in /r/China_irl on October 22, 2020 07:22:48

我还是觉得这和分权制衡、不可篡改关系不大。比如,也许一个养鸡场只有一个老板,但是N个养鸡场有N个老板,这样就能保证这些老板之间可以互相监督互相制衡了么?还是未必吧。账本上的内容是别人写的,不知道实际情况的外人再怎么验证,也验证不出来里面写的东西是真是假。即使老板甲有动机检举揭发老板乙(挤走竞争对手),也不好判断是不是老板甲栽赃陷害老板乙呢。 还有,就拿比特币来说,其实并不是每个人只保存一部分账本。现在的比特币全节点哪怕启用区块链裁剪(其实也不是白皮书上说的那个裁剪,白皮书写的那个裁剪貌似是没有意义的,一直都没有实现),也仍然是从创世区块开始完整下载整个区块链账本进行验证的,启用裁剪也只不过是一边下载新区块一边删掉就区块而已。 比特币确实有一个来自外界真实世界、又可以轻易验证的信息,就是矿工挖出每个区块付出的工作量。但是很显然挖矿暴力试错计算本身没有什么现实意义,甚至可以说就是一种浪费,唯一的意义就是提高51%攻击门槛、“保护比特币网络安全”。除此之外,比特币账本可以被验证,但是仍然必须完整下载才能验证,而且能验证的只有比特币转账信息,其他的涉及外界真实世界的信息真伪还是无能为力,最多也就是像open timestamp那样打个时间戳,做“存在性证明”。

Commented by /u/KiFastCallEntry in /r/China_irl on October 22, 2020 03:47:53


Commented by /u/KiFastCallEntry in /r/China_irl on October 22, 2020 02:09:52

让我想起币圈的梗satoXi nakamoto。 “只要能让我们这帮bagholder解套、财富自由,他要干什么我都支持。”🤣

Commented by /u/KiFastCallEntry in /r/China_irl on October 20, 2020 22:34:59

我觉得有点奇怪,好奇想问问,没有恶意…… 如果说大陆这边的说法是民族主义,那自称“我是台湾人”这就不是民族主义了?

Commented by /u/KiFastCallEntry in /r/China_irl on October 20, 2020 21:32:59


Commented by /u/KiFastCallEntry in /r/China_irl on October 17, 2020 23:58:51

传说中的密码无政府主义😅 还有,貌似电报默认也不端对端加密吧(包括群聊),也就是传说中运营方头很铁而已。

Commented by /u/KiFastCallEntry in /r/China_irl on October 17, 2020 23:13:31

除了楼上说的,跟这次疫苗有关系的,我还回想起3月4日CGTN的记者徐兆群专访曹彬(“针对新冠病毒的药物研发进展如何?”),曹彬用英语谈论克力芝和瑞德西韦的时候,字幕翻译也不准确,容易让人产生误解。 那个时候瑞德西韦在武汉的三期临床已经开始了,但是结果还没出来。曹彬前面讲了他们用克力芝进行治疗的情况,然后,先介绍了瑞德西韦的(三期)临床,分轻症和重症两个实验;然后提到体外药物敏感性实验里面瑞德西韦比克力芝强,但是翻译的时候“体外药物敏感性实验”这个意思漏掉了,容易让人误以为是瑞德西韦的临床实验(在病人身上做的,而不是体外)在那个时候已经有了积极结果。 后来的事情大家都知道了,重症瑞德西韦的三期临床挂掉了,然后粉红和中医粉各种反攻倒算,高强度输出(哎,其实瑞德西韦吹和吉利德公司也不是啥好鸟)……回想起来曹彬那个时候说话真有艺术性,实际上克力芝的效果也不怎么样吧(貌似也可以算是挂掉了。毕竟本来就是老药新用,本来不是干这个活的,克力芝本来是对付艾滋病的),但经他这么一说就很鼓舞人,给人很大希望。

Commented by /u/KiFastCallEntry in /r/China_irl on October 15, 2020 13:42:39

>所有的三期临床试验都是所谓“基于事件”的试验,这意味着只有在接种疫苗组与对照组(只服用安慰剂)中一定数量的人感染了新冠病毒并出现症状时,试验才会停止。例如,Moderna将这些所谓的“阳性事件”的数量设定为151个。这还意味着,在试验期间这种疾病在人群中越流行,收集结果的速度就越快。 (以上来自FT中文网文章《新冠疫苗面世还需多久?》英文标题是“How close is a coronavirus vaccine?”) 其实吧,都到三期了,本来就是比较大范围地在人身上试,只不过是科学上更严谨吧,双盲对照,随时监控不良反应。

Commented by /u/KiFastCallEntry in /r/China_irl on October 15, 2020 13:24:20


Commented by /u/KiFastCallEntry in /r/China_irl on October 14, 2020 10:42:03
/r/China_irl/comments/jaler6/想问一下可控核聚变的进展怎么样了/g8rg56n/ 这篇文章是几年前的了,但是作者在这个领域工作了很久。 好像本来就很够呛。人类并不能像太阳一样点燃氢(氕),只能点燃氘氚这样含有中子的同位素(反应难度差了24个数量级),然后高能中子跑出来就产生很多问题。甚至可以说核聚变未必比核裂变好到哪里去,该有的问题还是都有。

Commented by /u/KiFastCallEntry in /r/China_irl on October 13, 2020 23:08:55

0xDUDE 不是爆料过一次了么。

Commented by /u/KiFastCallEntry in /r/chonglangTV on October 13, 2020 06:04:15


Commented by /u/KiFastCallEntry in /r/China_irl on October 11, 2020 20:58:55


Commented by /u/KiFastCallEntry in /r/China_irl on October 6, 2020 00:10:40

>我所在墙里见过的大部分听到“台湾”二字状态下的大陆人,都会瞬间失智。 首先怎么叫“失智”呢……顶多算是政治狂热吧(这么说好像也有点不恰当?) 要是只看网上的言论,那确实,不少人一提到台湾都有点政治狂热——但是,反过来看着ID里顶着青天白日满地红旗的人,我只能说彼此彼此。 甚至可以说,在我的印象里,他们在口出恶言肆意诅咒对岸这方面,是有过之而无不及。

Commented by /u/KiFastCallEntry in /r/China_irl on October 3, 2020 07:39:00


Commented by /u/KiFastCallEntry in /r/China_irl on October 2, 2020 21:56:07

1. You are strongly recommended to use advanced recovery, which scrambles the keyboard, rather than shuffling the words, so that no info leak due to keyloggers will happen at all. (Of course you still have to watch out for hidden/hacked camera etc, as it still can possibly see Trezor's screen directly) 2. Trezor docs already cover your problem: If you use traditional scramble-word recovery rather than the newly designed advanced recovery, you still have about 80 bits of security despite all 24 scrambled word being leaked. 3. If you didn't mean the scrambled words scenario, the answer would be unlimited. Pay attention that Bitcoin is a decentralised system, where the "account balance database" (UTXO set) is public to everyone. That's the reason why nobody should use obsolete human-generated brain wallet any more. You may have a glance at Ryan Castellucci DEFCON Talk about brain wallet, so that you will learn that bitcoin is actually similar to a website whose password database is already leaked. Link:

Commented by /u/KiFastCallEntry in /r/TREZOR on September 24, 2020 07:52:12

(1) BIP32/39/44/49/84 BIP32: the standard which defines how hierarchical deterministic (HD) wallet works. It allows you to generate brand-new addresses/private keys without the pain about frequent backups - all the private keys are derived from one single seed, while all the corresponding addresses (themselves, they could still be linked together by analysing transaction flows etc) cannot be linked together by surveillance people who don't have your xpub(s). BIP39: the (controversial, but de-facto) mnemonic (seed format) standard. BIP44: standard HD derivaion path (BIP39 doesn't define it, which is main reason why people dislike BIP39) to generate classic 1-starting addresses (P2PKH addresses) designed by Satoshi. It also defines how different groups of addresses for different use cases (address types, coin types, "accounts" which are actually isolated subgroups of addresses) should be isolatedly derived. SLIP44: standard document maintained by SatoshiLabs, where the various coin types (BTC, LTC, ETH etc) registered. BIP49: standard HD derivaion path to generate 3-starting "compatible" SegWit addresses which enjoy an artificial discount when you send the coins out. It's actually an use case of BIP44. BIP84: standard HD deviation path to generate bc1-starting "native" (bech32-encoding which doesn't contain mixed cases of alphabets, instead of the classic mixed-case Base58check encoding designed by Satoshi) SegWit addresses, which enjoy even more artificial discount when you send the coins out, at the cost of compatibility issues (other people, including some exchanges, are too lazy to upgrade their wallet software to recognize bc1 addresses). It's actually an use case of BIP44, too. (2) Besides importing the mnemonic (24-word secret seed phrase) into some other BIP39-complaint wallet, you may use Electrum with Trezor in that case. Electrum is a software wallet itself, but it can also work as front-end of hardware wallets. You can also point your Electrum wallet (lightweight client) to your own full node (with help of Chris Belcher's ultra-lightweight electrum-personal-server software or Blockstream's Electrs Electrum server software), if you want to make your first step towards better privacy in Bitcoin.

Commented by /u/KiFastCallEntry in /r/TREZOR on September 18, 2020 10:37:20

我第一次听到这个调子是Rick and morty在致敬一部老恐怖片……

Commented by /u/KiFastCallEntry in /r/China_irl on September 11, 2020 12:02:30


Commented by /u/KiFastCallEntry in /r/China_irl on September 11, 2020 05:10:10


Commented by /u/KiFastCallEntry in /r/China_irl on September 11, 2020 05:08:14


Commented by /u/KiFastCallEntry in /r/China_irl on September 11, 2020 05:05:54

之前本sub有人发过: [\_irl/comments/ionwv8/%E5%B9%BF%E5%B7%9E%E5%9C%B0%E9%93%81\_x\_%E6%9D%B1%E6%96%B9project\_%E8%81%94%E5%8A%A8/]( 可能有些人会误解成是官方联动吧。

Commented by /u/KiFastCallEntry in /r/China_irl on September 11, 2020 03:37:47

Fanart: []( >2. 《Herz In Canton》是同人作品,和广州地铁官方没有任何关联。 Google translate: >2. "Herz In Canton" is a fan work and has nothing to do with the official Guangzhou Metro.

Commented by /u/KiFastCallEntry in /r/touhou on September 11, 2020 03:22:53

这个貌似是辟谣了?只是同人绘本而已。 []( [](

Commented by /u/KiFastCallEntry in /r/China_irl on September 11, 2020 03:20:23

我在楼上的回复里说“ 明摆着需要提交信息”,那个时候我还没下载安装app。然后我去app store下载安装了,发现居然真的是“明摆着需要提交信息”,**必须**实名认证,甚至还需要人脸识别认证,才可以开始使用,**否则压根就不能用**。 不过这个实名认证也不算多过分吧,毕竟涉及举报,万一有栽赃陷害呢。真受害者去报案也是需要登记身份信息的吧。(这个问题我没想太多;但我感觉如果不愿意接受实名认证,大不了直接就卸载不用,所以问题貌似不大) 而且我点进去看了,各种举报类型里,貌似也没有比较宽泛的选项。 ​ 还有,其实这里涉及人脸信息了,我就有安全方面的担心了,只不过这个担心和赵弹关系不是太大。现在到处都是人脸识别,一方面被大量收集的人脸数据有没有可能泄露(不知道这里能不能做类似加盐哈希之类的保护);另一方面就是即便没有拖库泄露事件,被拍照拍到脸也是无法避免的,会不会有deepfake之类技术能伪造视频通过认证(到处都是人脸识别,那不就是到处都可能被冒用身份么)。

Commented by /u/KiFastCallEntry in /r/China_irl on September 10, 2020 21:06:23

要是“诈骗**等违法不良信息举报**”这种,我也要浮想联翩了;但是就我看到的,好像真的就纯粹只是“反电诈”而已。另外貌似也就帝都在搞这个?反正我这边没听说过。我猜这八成就是形式主义,要给某些人刷成绩,不过是不是八成我也说不好,毕竟我没能力把那个app逆向拆开看看有没有问题。 还有,要说装app我也觉得多余;但是对于电信诈骗其实不能掉以轻心,今天感觉被骗的案例离谱,明天也许就轮到别人觉得自己离谱了,还是多关注这方面的信息为好。

Commented by /u/KiFastCallEntry in /r/China_irl on September 10, 2020 11:08:49

其实我第一反应想起的是绿坝,没记错的话绿坝就是因为强制要求PC制造商安装才火的,不然的话……嗯大概还是会火(毕竟还涉及审查、贪腐等问题;抛开事件背景不谈光是这个软件本身也涉及隐私等问题)。 但是我大概扫了一眼,这个东西好像没说“不良信息”,只是反诈骗,所以才感觉大概率没有那么玄乎。

Commented by /u/KiFastCallEntry in /r/China_irl on September 10, 2020 09:46:07


Commented by /u/KiFastCallEntry in /r/China_irl on September 10, 2020 09:37:48

电信诈骗本来就很猖獗,上当的人一直以来都是多到数不清。而且现在还有杀猪盘这种玩法,“赌”“诈”交织,受害人可以一边冷笑着“这tmd就是一群该死的骗子”一边自作聪明地把钱送给骗子。 (有些人可能理解不了,其实我也理解不了。这种骗术貌似并不算高明,很老套,但是就是有很多人自动跳坑……) 至于隐私,我倒觉得光是一个微信就不知道已经掌控多少敏感信息了。真怕被查水表的很显然也不可能给自己安装这种明摆着需要提交信息的反诈骗app。所以我觉得没必要太过被害妄想。

Commented by /u/KiFastCallEntry in /r/China_irl on September 10, 2020 09:28:11

BIP44 standard is already taking care of this: >This algorithm is successful because software should disallow creation of new accounts if previous one has no transaction history, as described in chapter "Account" above. However you can't be sure every wallet / tool in the world in every circumstance would respect such limit. Just like using Ian Coleman's BIP39 tool, generally people won't mess around the account number, but if you did something on the account number, it could lead to problems.

Commented by /u/KiFastCallEntry in /r/TREZOR on September 10, 2020 09:09:41

I said "it has always been there" - I'm sorry and terrified, that I forgot to mention the critical part - if you store the funds on some path which is too "deep", like "account #2048", the wallet won't be able to scan the balance / funds stored on it, so that it will look like to be "lost". If the number is large enough (like "account #1394818595"), it might be almostly equivalent to a "real" fund loss (just like forgetting the passphrase of your BIP39 seed). That's exactly the reason why there's only a button called "add account" rather than "specify account number". Edit: it's not necessarily "deep", but "skipping" the number which would lead to problems.

Commented by /u/KiFastCallEntry in /r/TREZOR on September 10, 2020 08:50:19

Actually it's not "added", it has always been there, because "accounts" are actually just different derivation paths according to BIP44/49/84.

Commented by /u/KiFastCallEntry in /r/TREZOR on September 10, 2020 06:44:49

I installed opengapps stock, which includes Google dialer/SMS etc. Then it seems to work up till now.

Commented by /u/KiFastCallEntry in /r/LineageOS on September 9, 2020 05:53:35


Commented by /u/KiFastCallEntry in /r/China_irl on September 8, 2020 02:19:40

央视我不知道,我知道人日的官推干过一次敌在中宣部性质的事情:今年新冠疫情,火神山医院还没建好的时候,他们无脑转了一张图说第一栋房子建好了;实际上那张图在网上可以搜到很久以前就存在了,就是集装箱板房的一个样板图片。 现在搜好像又不太能搜得到了,Google以图搜图也显示结果是武汉火神山医院🤦……不过仔细找还是可以找到的,比如(真正的原出处在哪我就不知道了): 那个时候好像确实还没开直播,直播小绿小蓝挖掘机云监工什么的是后来才有的。

Commented by /u/KiFastCallEntry in /r/China_irl on September 7, 2020 22:26:43

这个案子都是去年的了… 当时推上有币圈人转发搬运过这个消息: (可能是我不太会用,我看到视频播放界面有显示原作者推号,但是点进去只是账号主页,这个转发搬运是我到账号主页里一个个翻才翻到的)

Commented by /u/KiFastCallEntry in /r/China_irl on September 7, 2020 21:51:40

也许是我比较幼稚,我觉得吧……真涉及到切身利益了,八成还是会真有一头牛的,无论对哪一方都是这样。 就像游戏机,我一个从来没拥有过主机/掌机的无机酸都记得这个: >彭博社的报导,官方英文报纸《中国日报》称中国可能将解除长达12年的游戏机禁令。这一消息刺激了索尼和任天堂股价上涨。中国从2000年开始禁止游戏机,原因是担心游戏可能会伤害青少年的身体和精神发育,但通过黑市和水货市场PS3和XBOX360等游戏机在中国售出了至少数百万台。《中国日报》引用匿名消息来源称,文化部正和其它相关部门讨论结束禁令。

Commented by /u/KiFastCallEntry in /r/China_irl on September 6, 2020 23:43:21

所以说跟彭佩奥的净网行动是一个性质吧,保护主义、排外而已。 我看过一个xkcd画过漫画的概念NIH(not invented here),貌似真从技术角度看(某种程度上也算是上帝视角吧)这种重复造轮子的行为是愚蠢的,但是现实中还是天天都在发生。

Commented by /u/KiFastCallEntry in /r/China_irl on September 6, 2020 23:20:33

我不知道你说的可信计算指的是什么。我说的这个可信计算,打个很不恰当的比方,就像是游戏主机,从硬件上就设计了各种安全机制(比如强制验证数字签名,私钥只有官方有),用户对系统没有真正的控制权,所以用户才只能老老实实掏钱买正版,不能直接复制粘贴免费白嫖。 开过挂的人也大概知道,有些挂需要加载驱动(内核模块),深入操作系统底层去折腾,反外挂也是同理。即便微软搞了DSE、PatchGuard之类机制,可以制造一些阻碍和麻烦,归根到底用户也还是有机器最根本的控制权。 不过众所周知,游戏机以前就经常被破解;Intel的 SGX也爆过N次漏洞,不知道这方面后来会怎么样。

Commented by /u/KiFastCallEntry in /r/China_irl on September 6, 2020 22:53:29

首先微软貌似没跟我国闹掰,老美好像也没怎么找微软麻烦。UOS之类的基于Linux的桌面系统还是比较小众。而且软件总有破解的办法(除非以后可信计算之类剥夺用户对机器绝对控制权的技术能靠谱并普及),总是可以有盗版。 盗版这事也是一言难尽,其实像是笔记本之类品牌机是有正版系统的,授权费也不贵(当然换来的就是功能阉割的“家庭中文版”),但是微软和硬件制造商为了利益会在里面捆绑各种垃圾bloatware,而且一般人为了方便也宁愿去找盗版盘(里面有盗版制作商塞进去的垃圾bloatware甚至是木马病毒)而不是去跟一股官僚气的官方客服打交道。现在鼓吹原版系统的多了(其实里面还是有微软自己的垃圾bloatware),但是也就是个人有闲工夫和兴趣才折腾这个,真做生意的人眼里看的还是效率,时间就是金钱嘛,更何况国内很多大厂还倒塞钱给你,让你给客户安装bloatware来抢市场。 然后,操作系统这东西,本身是不是足够好用,可能都不是最重要的,最重要的还是生态,也就是有多少人给这个系统开发应用(其中有多少杀手级应用会让你不惜捏着鼻子也要用),然后有多少用户天天在用(然后才能迅速发现问题并解决)。举个不太好的例子WinXP,N多新特性都不支持,连安全dll路径都没有,安全漏洞微软也不提供补丁(实际上未必是不修,只是版权,也就是给钱的问题。我记得XP对应的嵌入式Windows微软还是在维护的,即使(我也不清楚现在啥情况)现在不维护了,也比公开宣布XP退役晚了很久),但是现在照样不少人在用,我甚至还听说电脑城有在用一种用虚拟机封装起来的XP一键安装盘。 以前看到过一个比方,就像水管子,谁也不愿意平白无故就把自己家自来水管砸了换另一家的。 中国人玩操作系统应该还是蛮6的,至少中国的安全研究员(黑客)能挖到不少0day。(这里的“黑客”很显然不是破坏分子这种贬义意味,而是指对系统有透彻了解、可以想到常人想不到的创新“猥琐”思路的专家) 要说开源/自由软件社区,我感觉在这个圈子里强调国家啦民族啦什么的似乎比较狭隘,哪怕是最近出于反歧视原因掀起的改名运动也有很大的抱怨(我也觉得改名这种事纯属没事找事,然后刻意去反对也有点浪费精力)。 更不用说有些打着自主研发的旗号的……哎不说了。

Commented by /u/KiFastCallEntry in /r/China_irl on September 6, 2020 22:41:27

抠个字眼,疫情防控我觉得主要是保护尚未感染的绝大多数人,跟已经感染后的救治其实不是一码事。 要说医疗水平,我随便搜了一下印度的数据,死亡7万多除以累计感染411万,大概1.7%吧,貌似不算多糟糕也不算多好。 我国算上湖北都5%了(主要是武汉前期太操蛋,医疗系统都搞击穿了;再有就是新病毒谁也不知道咋治,只能大概参考过往经验进行摸索),除去湖北只有0.7%的死亡率。

Commented by /u/KiFastCallEntry in /r/China_irl on September 6, 2020 21:33:18

Going offline still makes sense. I just said there's no absolute security.

Commented by /u/KiFastCallEntry in /r/Bitcoin on September 6, 2020 11:10:07

Even if Google search ad didn't promote such scam, a user could still be scammed elsewhere, too. It's not very easy to confirm authenticity, trustability etc.

Commented by /u/KiFastCallEntry in /r/Bitcoin on September 6, 2020 09:42:07

An offline tool can be backdoored as well, like: rigged random number generator, show fake addresses belong to the scammer instead of real ones belong to the user, etc. Offline wallet can be backdoored as well, secret info can be stealthily leaked through rigged ECDSA digital signature produced by maliciously picked k value:

Commented by /u/KiFastCallEntry in /r/Bitcoin on September 6, 2020 09:38:06

火星文在我印象里纯粹是为了好玩吧,当时还有火星文输入法(也许现在还有?),我不记得是为了绕开审查。 还有,很多时候机器审查好像不至于那么要命,真是啥啥发不出去的话,一般是被人工重点照顾了,玩法也多种多样,比如限流(发得出去,但别人看不到推送)。 貌似不止中国有花式玩法,老外也动不动就怀疑是不是有shadowban什么的。

Commented by /u/KiFastCallEntry in /r/China_irl on September 3, 2020 20:35:23


Commented by /u/KiFastCallEntry in /r/China_irl on September 3, 2020 00:48:12

现在貌似已经关了?说暂时不对外开放使用。 点开大概看过,感觉就是实名的,或者说就是银行账户,只是形式稍有变化。不满足现实世界中现金匿名不可追溯的属性。还是需要提供个人信息进行注册;或者说是前台匿名,后台实名。这样某种程度上也算是“满足民众匿名支付需要”了吧,也没有超出我的想象空间。反正不像比特币那样,地址和私钥本质上就是一随机生成的密钥,一个数字,所以离线也可以生成。 双离线支付,建行这个也并没有支持,断网了就不能用。这也没超出意料之外,比特币不也是一样的,断网了就不能用,付款交易发不出去,收款是否到账也查不到。 如果想双离线交易,估计是需要可信执行环境(TEE),换言之就是你手里的电子设备不受你控制,这样你就不能双花作弊了。 比特币也有人做过基于TEE的技术,比如TEEChan/TEEChain,工作方式类似于闪电网络,官网宣传特色之一就是可以离线使用。不过这个技术依赖的Intel SGX之类TEE已经不止一次被爆出安全漏洞了。(我之前说是类似的技术,其实不对,用过闪电网络的都知道闪电网络其实不太好用,主要就是因为通道里的资金容易不平衡,全部偏向自己这边时就不能收款,反之亦然,全部都在对端时就不能付款。更何况闪电网络之所以叫网络,是因为一笔转账可以穿过一连串的多个通道来间接完成,中间有任何一个通道卡壳了,那整笔转账就会失败。有AMP这种技术可以把一笔转账分割成多个小块分别完成、尽量规避这个问题,但是仍然不能彻底避免这个问题。这个TEEChain作为TEE版的闪电网络也是,原作者自己都在推上说过,这类二层网络技术局限性很大——当然,这位原作者Emin Gün Sirer因为支持大区块,长久以来就跟目前支持小区块的比特币社区不对付;而二层网络又被视为小区块下解决扩容问题的一大出路……这就说来话长了) (比特币圈子还有一个有趣的东西opendime,它是造价便宜、一次性使用的硬件钱包,类似小猪存钱罐,只能一次性打破、把所有币拿出来,然后硬件本体就等于是作废了;在“打破”之前,可以把硬件本体直接交给对方,这样也是离线交易,收款方不怕付款方作弊,因为付款方自己不“打破”就不知道私钥,也就不能双花作弊。不过即便是这样,很显然也需要联网才能查到那个地址上的余额到底是多少,至少至少也要先联网得到SPV证明数据才可以)

Commented by /u/KiFastCallEntry in /r/China_irl on August 29, 2020 22:56:22

To me it's just psychological placebo. Using 256 bits of raw entropy can probably make you feel better, however it can't change the fact that a 256-bit privkey is only as secure as a 128-bit symmetric key. The checksum issue doesn't really matter as long as you take much care of it. Even 24-word still has a possibility of 1/256 to encounter the same problem if you mistype your seed. It also has nothing to do with the situation that a mistake was made during writing down the seed onto paper.

Commented by /u/KiFastCallEntry in /r/TREZOR on August 21, 2020 08:27:50

Also he might have been able to use CPFP against you?

Commented by /u/KiFastCallEntry in /r/Bitcoin on August 21, 2020 04:43:55

The double-spent tx seems to be discarded by blockcypher. bitflyer's chainflyer explorer still has it: [](

Commented by /u/KiFastCallEntry in /r/Bitcoin on August 21, 2020 04:42:37

There's another "risk" that 12-word only has 4-bit checksum, which means trezor (or some other cryptocurrency wallet) has a chance of 1/16 to accept a mistyped mnemonic phrase as a valid one. 24-word has 8-bit checksum, so that such possibility is shrunk to 1/256 rather than 1/16. However I don't think it would be a fatal issue, because iterating all possible mistyped variants of the original mnemonic phrase would not cost much computational resources.

Commented by /u/KiFastCallEntry in /r/TREZOR on August 20, 2020 03:23:30

Oh there is one thing I forgot to mention. Some users still consider 256-bit 24-word more secure than 128-bit 12-word, because the above "256-bit ECDSA privkey is only equivalent to 128-bit AES key" nuance doesn't apply to the case that the public key is not yet exposed. However you will eventually spend the bitcoins, the public key inevitably exposes, at least there's about 10 minutes before the transaction gets first confirmation (even if it gets 6 confirmations, it's still not completely impossible to reverse it as long as the attacker has significant portion of hash power). Besides, bitcoin is an economic system, there are also countless users who already use 12-word. To be short, I think it's similar to the case that people worry about taproot and quantum computing because taproot exposes public key in the beginning. See: In my opinion it's just some extra paranoia or psychological placebo which doesn't matter so much in reality.

Commented by /u/KiFastCallEntry in /r/TREZOR on August 20, 2020 03:12:39

The point is that asymmetric ciphers have much "weaker" security than a symmetric cipher with the same key length. Although bitcoin uses secp256k1 ECDSA (asymmetric cipher) which has 256-bit privkey, it only has 128-bit level security (comparing to symmetric cipher like AES). Just like the case of RSA, another well-known asymmetric cipher, a 1024-bit privkey is actually no longer considered to be secure any more. ECDSA is also an asymmetric cipher, which seems to be much "better" than RSA, that 256-bit privkey is equivalent to 128-bit symmetric (like AES) key - still secure. Thus, 24-word BIP39 mnemonic phrase (256-bit entropy, another 8-bit is just used as checksum) is indeedly an overkill. 12-word is already as secure as a single privkey. Trezor One uses 24-word to mitigate the keylogger risk - since Trezor One itself doesn't have keyboard or touchscreen, the mnemonic phrase must be typed on the computer, which obviously faces the risks of keylogger malware. Trezor One scramble 24 words to provide about 80-bit security in this situation. Since the "advanced recovery" (designed by johoe) had been supported by Trezor One (and Trezor model T itself has a touchscreen), such keylogger issue no longer exists. So as long as you use advanced recovery (which scramble the keyboard, rather than the mnemonic phrase itself) it's safe to use 12-word.

Commented by /u/KiFastCallEntry in /r/TREZOR on August 20, 2020 02:57:54

I think whole user data backup has some problems around keymaster. It may be a false sense of safety that some data you thought to be backuped is not actually backuped at all. After backup & freshly installing another version of LOS, some app using fingerprint sensor stopped working, I deleted & re-added fingerprints to make them work again, however there's still some apps using system keychain not decrypting its data. Related:

Commented by /u/KiFastCallEntry in /r/LineageOS on July 30, 2020 03:38:01

It should be about an Android permission issue. I edited packages.xml (under TWRP) to grant three required permissions to trebuchet. However if you create a new user or Android for Work space (created by Oasis Feng's "Island", which is actually a new local user account as well), those three permissions will be missing once again, so that you have to edit packages.xml once again... Now I have given up to struggle like that, because some newer opengapps (stock) version directly uninstalled my trebuchet, so that pixel launcher became my only choice. I condemned it, but I finally decided to accept such fact.

Commented by /u/KiFastCallEntry in /r/LineageOS on July 17, 2020 00:29:57

How did you know which of them are correct, and which of them are "scammy"?

Commented by /u/KiFastCallEntry in /r/Bitcoin on June 28, 2020 11:49:29

256-bits is still 60% longer than 160-bits. But the fungibility may overweight address length.

Commented by /u/KiFastCallEntry in /r/Bitcoin on June 25, 2020 02:42:31

It can be a good representation. However it doesn't handle the situation that only the corresponding p2pkh address is known. It's a hash which is not reversible.

Commented by /u/KiFastCallEntry in /r/Bitcoin on June 24, 2020 09:49:17

However I can't see how (as merely one of many popular online block explorers) displaying previous outpoints instead of displaying previous output addresses directly can avoid the potential misunderstanding. (Oh, in the beginning the previous output addresses were even not displayed at all IIRC! Fortunately they finally added this, but still inside an expanded view which requires an extra click) Once again, I agree that the ambiguity between P2PK and P2PKH is not good. However I don't agree that the P2PK should have no proper presentation at all. I think something like output descriptor should cover this. Especially, there are countless historical posts mentioned those "1-starting addresses". I think a self-explanatory output descriptor really seems to handle this elegantly.

Commented by /u/KiFastCallEntry in /r/Bitcoin on June 22, 2020 01:47:00

Sorry, but I still can't understand what the case looks like. Signing P2PK doesn't look so different than signing P2PKH. Actually P2PK even looks slightly simpler than P2PKH. For me the only possible problem seems to be the ambiguity.

Commented by /u/KiFastCallEntry in /r/Bitcoin on June 22, 2020 01:39:14

>Legacy addresses represent p2pkh scriptpubkey, not a p2pk. Almostly I agree with this, however there are countless historical posts containing "ambiguous" usage of p2pkh address, just like [(2013) how SDLerner analyzed the genesis block]( , [(2012) how Chris Moore analyzed historical bitcoin rich list]( , and so on. There's even [a very recent example that some early miners called out CSW's fraud]( (sorry, I pasted [incorrect link]( unintentionally. I've fixed the link) In my opinion, **probably we should just deal with the ambiguity properly, instead of making such a "simple and crude" change which obviously contradicts the whole history.** >Saying otherwise was a bug with many implications and people writing broken code as a result. Please elaborate? Although I'm not a developer myself, I think it's a fact that P2PK coins (UTXOs) still exist, so that they should be treated carefully as well. AFAIK P2PK has exactly the same ownership with P2PKH, so that it won't be much different than P2PKH UTXOs, they are just "as spendable as P2PKH" (but obviously they don't have exactly the same way to be spent, as spending P2PKH requires pushing pubkey to the stack in the scriptSig). To me the only problem seems to be ambiguity.

Commented by /u/KiFastCallEntry in /r/Bitcoin on June 21, 2020 07:12:02

However, it's also untrue that "there's no address at all in Satoshi's era" - the screenshot of ancient bitcoin client disproves this claim. The address obviously has been existing since that time. I don't know when did the ecosystem start to treat P2PK as if it's P2PKH, however this has involved too many historical posts, so that such change to Bitcoin Core is on the contrary making things more confusing IMHO. To me it's similar to the case of "bitcoin doesn't have any from address!" - yeah of course a transaction itself doesn't contain such thing, but the tuple of previous txid and vout uniquely points to the previous output entry, so that it's definitely the "from address". Like it or not it's just how bitcoin works. It doesn't seem wise to make a block explorer less useful to merely "respect the fact that a transaction itself doesn't contain any from address", especially when it can already display such info without problem.

Commented by /u/KiFastCallEntry in /r/Bitcoin on June 20, 2020 16:50:56

Personally I don't think Bitcoin Core should treat legacy bare-pubkey output like that, I think it should still be properly presented. I wish that a new output decriptor like "barepk(ADDR)" can be used to match/describe such output, or just extend the existing "pk(KEY)" descriptor to allow it to match bare P2PK outputs, like "pk(ADDR)".

Commented by /u/KiFastCallEntry in /r/Bitcoin on June 20, 2020 00:46:09

Hopefully your transaction would go through by tomorrow morning. However, sadly nobody can guarantee what would happen in the following dozen hours (maybe there would be more high-fee-rate transactions sent by other people, generally this sort of phenomon is caused by significant market movements), so that it's still possible that your transaction would be still stuck tomorrow moring :-/

Commented by /u/KiFastCallEntry in /r/Bitcoin on June 18, 2020 10:27:03

Obviously this estimation is not accurate, because nobody can predict in the future how many transactions with fee rates higher than yours would be sent to the bitcoin network. You may end up wait for longer time than this. 12 blocks would take 2 hrs in average, but since bitcoin mining is a poisson process, the actual time would vary around this.

Commented by /u/KiFastCallEntry in /r/Bitcoin on June 18, 2020 10:19:06

The "easiest and preferably fastest way" is probably the "transaction accelerator" method, which is also the most expensive one :-/ I don't recommend this unless you are really in hurry. I would suggest you to just wait for a few more blocks.

Commented by /u/KiFastCallEntry in /r/Bitcoin on June 18, 2020 10:11:52

There's also a myth that "the stuck bitcoins would automatically return" - which is not correct. Although a transaction has its timeout in each node's mempool, a transaction itself doesn't have any expiration time, so that it could be rebroadcasted anytime someone (including your own wallet) does this. Therefore, to keep completely safe, you must either wait for the transaction to confirm, or invalidate it with double-spending (the double-spending transaction would face exactly the same situation, that it has to be confirmed).

Commented by /u/KiFastCallEntry in /r/Bitcoin on June 18, 2020 10:06:57

Are you new to crypto? Just 2hrs? Frankly speaking it's not so bad still. A low-fee transaction could be "stuck" for days or even weeks if the mempool (the queue of unconfirmed/0-conf transactions to be packed into new blocks) backlogs/congestion keeps uncleared, which simply means there're a lot of people sending their transactions with fee rates (sat/vB) higher than yours, so that your low-fee transaction has to wait. 1/ You can just wait for it to be confirmed, just like following the queue in front of the counter. These days the mempool congestion is not so bad, so that your transaction probably won't be stuck for too long. 2/ (This option doesn't seem available for you) You can raise the miner fee to "cut in the queue". However generally this requires a change output, which means you haven't cleared out all the bitcoins in the wallet - if so, this option is not available for you. If not, in other words, your stuck tx has a change output, hopefully you may have enabled RBF (BIP-125 Replace-By-Fee) of the "stuck" transaction so that you can do this directly, by replacing the old low-fee "stuck" one with a new one with higher fee. If you haven't enabled RBF, Electrum still provides the CPFP (Child-Pay-For-Parent) function which would send a second tx with much-higher miner fee, so that the average fees of the two transactions would be raised. 3/ You can buy a "transaction accelerator" from some big mining pools, like BTC.COM ( ) and Poolin ( ). However this transaction prioritising service is generally very expensive. 4/ You can send a double-spending transaction to invalidate the former "stuck" one. It's somewhat complicated to do this. Firstly you should check the details of the stuck transaction to find out exactly which UTXO(s) (txid:output index, like ed0aeb21cf714b7fb0a35e118c5e570136bbb3cdcc9d2cb1c4801c933f3ae711:0) have been spent; then save out origin transaction; after that, disconnect Internet, and then import your privkey/seed to a newly-created Electrum wallet, so that you can import the origin transaction(s) into it; Finally, you would be able to "double-spend" the imported origin transaction once again, with higher fee this time. You should save out the new double-spending transaction out, and then try to broadcast it (after reconnecting to Internet of course).

Commented by /u/KiFastCallEntry in /r/Bitcoin on June 18, 2020 10:03:14

Oh, I think I might get your point. HW wallets generally don't allow such transactions at all. Software wallets generally has the ability to let the user examine the input amounts on the offline "cold" device, then there's inevitably a chance for the user to notice the discrepancy.

Commented by /u/KiFastCallEntry in /r/Bitcoin on June 4, 2020 23:45:21

It seems that only the amounts would be tampered. Generally the victim still relies on the wallet software running on the online "hot" device to examine the amounts.

Commented by /u/KiFastCallEntry in /r/Bitcoin on June 4, 2020 23:38:57

Sorry, but I still can't see what discrepancy would be seen by the victim. Although the input belongs to the attacker must be signed together (by default the ANYONECANPAY flag is not set) as well, its amount is not covered by any signature signed by the victim, right? it's only covered by the attacker himself. Did I misunderstand anything?

Commented by /u/KiFastCallEntry in /r/Bitcoin on June 4, 2020 22:19:27

What if the transaction involves multiple payers? Could the attacker trick the victim (as one of the multiple involved payers) into paying much higher amount than what he originally expected?

Commented by /u/KiFastCallEntry in /r/Bitcoin on June 4, 2020 04:11:38

Trezor is open-source. I've seen "compatible" "unofficial" Trezor to be sold (whether it's trustworthy is in doubt), let alone the outright malicious imitations.

Commented by /u/KiFastCallEntry in /r/TREZOR on May 31, 2020 08:45:39

Probably it's more subtle than that. After upgrading to 20200531, I saw pics from 51510 AD 😂 However this only happened to the timeline, the time showed in the detail window was still correct.

Commented by /u/KiFastCallEntry in /r/LineageOS on May 31, 2020 07:07:41

Upgraded to 20200531 for z2_plus. It seemed to contain a fix for this sorting problem, however, it turned out to be still problematic. The time showed in the gallery timeline was just **crazy**! It told me those pictures were from the far future - 51510 AD 😂 OMG... I don't know what the situation is at all... Note: it was just a small fraction of the pictures, which were downloaded by ~~twitter~~ some chinese social media app like weibo, tieba etc, which had such incorrect timeline problem. Actually the time showed in the detail window of each individual picture was normal. Oh, so weird...

Commented by /u/KiFastCallEntry in /r/LineageOS on May 31, 2020 05:47:49

>Is LineageOS encrypted by default? I'm not sure... You may check this out in the settings yourself. >I don't have Google apps Some games might complain if you don't have GMS installed - actually that might be the most important reason why some people want to flash Gapps. Besides, some people flash Gapps to use Google Play market. Also, it's generally recommended to use some backup service in case of device malfunction/loss etc. >It seems to be needed for connectivity check. `adb shell "settings put global captive_portal_http_url http://SOME_SERVER/generate_204"` `adb shell "settings put global captive_portal_https_url https://SOME_SERVER/generate_204"` That's all I know. You may also check `adb shell "settings list global"`.

Commented by /u/KiFastCallEntry in /r/LineageOS on May 24, 2020 09:42:50

Needs explicit opt-in of the app developer, right? So, its usefulness would be quite limited. Albeit this, it **might** be great **if** the "internal audio+mic" option would be available - which had been an available option in SCR Screen Recorder (won't work on recent versions of Android) **years ago** (needs root however)! I have been so frustrated and confused why google has to put such an awful limitation to Android. Pirates always find their way to pirate contents. Such awful limitation could only block legit use cases.

Commented by /u/KiFastCallEntry in /r/Android on April 5, 2020 06:41:47

I have exactly the same problem. Reproducible for a newly created user account of Android system. Currently I have to use SE file explorer or something alike to install apk. By the way, after installing Island by Oasis Feng & grant the storage permission to Island, it seems that Firefox would call Island to open the apk. I'm using official LineageOS 17.1 with OpenGapps micro. I don't know whether it's a bug of LOS/OpenGapps.

Commented by /u/KiFastCallEntry in /r/firefox on April 4, 2020 05:29:56

Ah, it's so embarrassing for me to confirm that I was wrong. There's indeed an "Import" option in the "Private key" submenu. I did create such non-HD wallet in the past, but I don't use such type of wallet daily. Maybe I confused such wallet with a watch-only one...

Commented by /u/KiFastCallEntry in /r/Bitcoin on January 18, 2020 12:19:50

I said "directly" because I found the fact Electrum doesn't allow the user to add any more key/addr to an existing wallet. Maybe it's really bad phrasing. I didn't say you cannot import privkeys/addrs to Electrum at all.

Commented by /u/KiFastCallEntry in /r/Bitcoin on January 17, 2020 23:09:15

Of course I tried. I didn't say you can't create such a "special" wallet that no HD seed is present. I found that such "special" wallet didn't allow me to import (add) another privkeys either, just like the case of "standard" HD wallet.

Commented by /u/KiFastCallEntry in /r/Bitcoin on January 17, 2020 23:06:07

I actually said: >an Electrum wallet doesn't **directly** provide the ability to "import private keys", instead, it can only "sweep" (send all the coins to the current wallet with an on-chain transaction) private keys. > >If you really want to import private keys, you must **"New/Restore"** a wallet. Which is same to what the doc your link pointed to said: >In Electrum 2.0, you **cannot** import private keys in a wallet that has a seed. You should sweep them instead. > >If you want to import private keys and not sweep them, you need to create a special wallet that does not have a seed. **For this, create a new wallet, select “restore”**, and instead of typing your seed, type a list of private keys Maybe I didn't express it in proper phrasing. Sorry.

Commented by /u/KiFastCallEntry in /r/Bitcoin on January 17, 2020 22:44:46

~~Remark: an Electrum wallet doesn't directly provide the ability to "import private keys", instead, it can only "sweep" (send all the coins to the current wallet with an on-chain transaction) private keys.~~ If you really want to import private keys, you must "New/Restore" a wallet. ~~I think it's a good design, because such design could avoid messing up the wallet.~~ Edit: I'm sorry for misguiding. I tried the current latest release (3.3.8) of Electrum, and it turned out to be completely able to add more private keys to an existing non-HD wallet.

Commented by /u/KiFastCallEntry in /r/Bitcoin on January 17, 2020 21:37:34

Add the "p2wpkh:" prefix for "bc1..." addresses (Bech32 native SegWit address) Add the "p2wpkh-p2sh:" prefix for "3..." addresses (P2SH-wrapped compatible SegWit address)

Commented by /u/KiFastCallEntry in /r/Bitcoin on January 17, 2020 21:31:01

A 12-word BIP39 mnemonic can only represent 128 bits of entropy, because the last 4 bits are the deducible checksum.

Commented by /u/KiFastCallEntry in /r/Bitcoin on January 17, 2020 20:21:04

Bitcoin Core uses 256 bit seed:

Commented by /u/KiFastCallEntry in /r/Bitcoin on January 17, 2020 20:19:23

Bonus, the legacy Trezor One uses 24 words merely because it once needed the extra 79-80bits of entropy provided by scrambled word sequence during the old recovery process to mitigate the risk of possibly infected computer. Both the "advanced recovery" process for Trezor One and the touchscreen of Trezor Model T have eliminated this risk completely.

Commented by /u/KiFastCallEntry in /r/Bitcoin on January 17, 2020 13:33:49

Besides, for BIP39, although 24 words seem to be able to represent 264 bits of entropy, it can actually represents only 256 bits, because 8 bits are used as the (deducible) checksum.

Commented by /u/KiFastCallEntry in /r/Bitcoin on January 17, 2020 13:25:06

You can't evaluate the strength of an asymmetric cipher like ECDSA by simply counting bits: Actually, it's "halved" due to birthday attack.

Commented by /u/KiFastCallEntry in /r/Bitcoin on January 17, 2020 13:22:26

>other software that expects (and only accepts) a seed import I don't know any wallet like that. I think it's common for a wallet to accept BIP32 extended pub/priv keys only, instead of mnemonic words. BIP39/44/49/84 scheme could also be criticised for it could possibly create ambiguity around derivation paths. I think it's a valid point, because I'm concerned about the fact that, some (LN) wallets seemed to pick some "barely-used" derivation paths as their own paths. However, I still think it's better, for a user who is doing wallet recovery, to type/paste a "magical string called 'derivation path'" to the wallet, than to search/download an "magical executable called 'recovery tool'". >But both that and the multilingual issue are relatively minor in the grand scheme of things. Agreed. That's why I'm disappointed with the fact that some prominent wallets (like Electrum and Bitcoin Core) have been resisting BIP39 up till now...

Commented by /u/KiFastCallEntry in /r/Bitcoin on January 17, 2020 05:11:17

I know only one shortcoming of such non-invertible nature of BIP39, that the utility of its multilingual support is vastly decreased.

Commented by /u/KiFastCallEntry in /r/Bitcoin on January 17, 2020 04:04:42

Never mind. For BIP39, it's already safe to keep the mnemonic (and the passphrase, if there's one) only, because it's obvious that the BIP32 seed is derived from the mnemonic. BIP39 mnemonic is one-way hashed (through 2048-rounds PBKDF2) to derive the master seed of BIP32. Then the master seed is hashed with HMAC-SHA512 to derive the master (depth=0, aka the "m" in the derivation path) key node.

Commented by /u/KiFastCallEntry in /r/Bitcoin on January 17, 2020 04:01:08

>A "seed" is actually just a representation of a special private key called a "master key". That's not true, at least for BIP39. A BIP39 mnemonic is one-way hashed to derive the BIP32 seed.

Commented by /u/KiFastCallEntry in /r/Bitcoin on January 17, 2020 03:50:25

It's well known to be a **messy (read: incompatible/non-interoperable)** situation for backup schemes based on mnemonic (the "seed" mentioned by you). That's probably why even some OG users still sticks to pub/priv keypairs (usually in the Wallet Import Format, aka WIF). It's so frustrating for me to see that, some significant wallet devs (like Bitcoin Core and Electrum) have been resisting BIP39 for quite a long time, with various excuses, albeit BIP39 had been described as the "de-facto standard" in the *Mastering Bitcoin* book years ago. ​ I'll take Electrum as an example. Electrum blamed BIP39 for its "lack of version number" - however, it's actually a "feature" of BIP39, which allows a mnemonic to be universal - for example, you can upgrade to SegWit, or accept yet-another new altcoin, without making any new backup. To embed a "version number", Electrum actually does a "vanity mining" during its seed generation process, which not only causes slightly lag of the wallet UI, but also decreases the security of the seed by several bits (which is fortunately "absorbed" by the KDF, which is also present in BIP39). ​ I admit that the "univesality" of BIP39 could become a security threat, that (lazy) people generally tend to import their mnemonic everywhere, which would essentially bypass the separation provided by BIP44 (and BIP49/84), so that the user could easily trap him/herself into an **"one compromised, all compromised"** situation. However, I think it's inevitable for a sword to have two edges - that the "universality" is also interoperability, and safety against risks like project abandonment. ​ I also dislike the non-invertible nature of BIP39, which rendered its multilingual support much less useful. However, it's just a fait accompli, that's not likely to be easily changed/improved in the future.

Commented by /u/KiFastCallEntry in /r/Bitcoin on January 17, 2020 03:42:39

Why does Trezor One use 24 words instead of 12 words? That's because Trezor once relied on the entropy (which is merely around 79-80 bits however) provided by scrambled input sequence during typing the mnemonic words on a possibly-infected computer. Once the "advanced recovery" of Trezor had came into being, such problem could be completely avoided.

Commented by /u/KiFastCallEntry in /r/Bitcoin on January 17, 2020 03:22:25

>What would be harder to compromise A 12 words mnemonic phrase is already equally strong to a single secp256k1 public/private key pair, let alone 24 words. (NOTE: 12 words should be equivalent to 128 bits of entropy - for BIP39, it's not 132 bits, since the last 4 bits are the deducible checksum) (ANOTHER NOTE: it's said that hashing the pubkey could protect bitcoin from quantum computers - unfortunately, it's [NOT really true]( (JUST ANOTHER NOTE: a "seed", defined in BIP32, is NOT the same thing with the "seed" mentioned by Trezor. The "seed" mentioned by Trezor is actually BIP39 mnemonic phrase, which would derive the BIP32 seed through **one-way** hash function - but never mind, **it's already safe to keep the mnemonic words (and the passphrase, if you have one)**, since the seed is derived from it) However, there's a potential risk, which would decrease the security of such "bunch of different derived keys" to the level of one single pub/priv keypair: leaking one non-hardened child privkey + leaking the parent (not the "grandparent" or the "uncle" ones) extended pubkey (**xpub**/ypub/zpub) = leaking the extended privkey (xprv) = leaking all the non-hardened child privkey of such parent key. **Anyway, it's not recommended to play with single privkeys.** Trezor's web wallet UI used to upload the xpub to their servers. There are also many light-weight wallets doing the same. Generally, it's only a **privacy** concern, instead of a security concern. If you really care about this, you may use things like Electrum Personal Server. Also, BIP44 provides separation between different "account" nodes, that the leaking risk mentioned above could be limited within one "account", if only one account extended pubkey and its child privkey were leaked. >a 24 word seed that is password-encrypted (e.g. on a hardware wallet like trezor) Trezor adopts the BIP39/44/49/84 scheme. Usually the PIN is enabled, however, **enabling the PIN won't encrypt the seed at all** \- that's why **attacks with physical access** has always been a concern. BIP39 also defined an extra **passphrase**, which is a **completely different thing than the PIN**, that it's in fact an extra part of your 12/24 words mnemonic phrase - that's saying, if you lost the passphrase, you would lost access to the corresponding wallet, probably permanently. ​ >The second example would be like a hold only/saving address where btc is only sent but never spent Obviously you can do the same for an HD seed, and HD wallet can provide you better privacy, because you can use a different receiving address each time.

Commented by /u/KiFastCallEntry in /r/Bitcoin on January 17, 2020 03:03:53

According to the rogue centralised case of Monero, then ... oh, I'm not quite sure, maybe Roger / Craig etc could retake the brand of "Bitcoin"? Who knows.

Commented by /u/KiFastCallEntry in /r/Buttcoin on January 8, 2020 12:37:01

>with a more complicated procedure By killing the original chain? Then, there would be a rogue centralised way of resistance: >It's well known that cryptocurrencies like bitcoin are implicitly influenced/controlled by the developers, which has been criticised to be "pseudo-decentralisation" for quite a long time, so that, ASIC miners would generally face a threatening by the "Core devs", if they want to do coercive things - that's why I said that "a PoW change chain could still appear".

Commented by /u/KiFastCallEntry in /r/Buttcoin on January 8, 2020 12:37:00

>Before you edited your comment, I did edited [my post](, however, I said in the very beginning that: >I think soft-fork is only INTENDED not to disrupt non-upgraded software. ​ >it said that soft and hard forks were distinguished by whether they would create (or were meant to create) a chain split or not I never said that. In fact, I had said **exactly the opposite**, in [another reply]( >**Either soft-fork or hard-fork** could be constructive or malicious, self-consistent or flawed/inconsistent, unanimously-accepted or contentious. > >It won't be surprising that a malicious/flawed/contentious upgrade (rule change) could cause a chain split, **either soft-fork or hard-fork**. It seemed to be you who first [said]( that: >A HARD FORK SPLITS THE CHAIN, THE COIN, THE USERS, AND THE MINERS\[...\] > >A SOFT FORK DOES NOT SPLIT THE COIN, THE BLOCKCHAIN, THE USERS, OR THE MINERS\[...\] Oh, you also accused me for: >refusing to understand the technical points, sorry. ​ >and that I was confusing cause and effect. Okay, okay. Anyway, I have now realized that we actually didn't have any disagreement on the definition of soft-fork and hard-fork.

Commented by /u/KiFastCallEntry in /r/Buttcoin on January 8, 2020 12:14:13

>> So, sorry, I cannot really understand your definition of soft-fork and hard-fork so far, because such definition seemed to be confusing cause and effect. Why did I say that? Because, you seemed to have been insisting on a confusing argument that "such inflation extension block soft-fork is a soft-fork, so that it WON'T SPLIT THE COIN" for many times.

Commented by /u/KiFastCallEntry in /r/Buttcoin on January 8, 2020 09:05:15

I still can't see how I could have misunderstood soft-fork and hard-fork. I had edited my [reply]( to further elaborate the situation, which you probably hasn't read through before sending this reply to me. I await your response to it, although I hasn't complete reading this reply by you so far.

Commented by /u/KiFastCallEntry in /r/Buttcoin on January 8, 2020 08:51:58

I never denied the ability of the majority hashpower that they can always do coercive or even malicious things - however, (1) Usually (but not always) they lack the incentive to do such thing - that's why I said that "miners generally won't mind if more and more minable coins would continuously appear". (2) It's well known that cryptocurrencies like bitcoin are implicitly influenced/controlled by the developers, which has been criticised to be "pseudo-decentralisation" for quite a long time, so that, ASIC miners would generally face a threatening by the "Core devs", if they want to do coercive things - that's why I said that "a PoW change chain could still appear".

Commented by /u/KiFastCallEntry in /r/Buttcoin on January 8, 2020 08:37:19

Either soft-fork or hard-fork could be constructive or malicious, self-consistent or flawed/inconsistent, unanimously-accepted or contentious. It won't be surprising that a malicious/flawed/contentious upgrade (rule change) could cause a chain split, either soft-fork or hard-fork.

Commented by /u/KiFastCallEntry in /r/Buttcoin on January 8, 2020 07:54:18

>Soft-fork is a name for such a change of the protocol, that doesn't disrupt non-upgraded software. I think soft-fork is only INTENDED not to disrupt non-upgraded software. EDIT: it doesn't seem to be well-defined that what's "not to disrupt non-upgraded software". I'd like take the case of integer overflow of bitcoin as an example, which is a "remedial" soft-fork type of bug fix, that old nodes would still follow the new chain, however, once the old node attempt to exploit the overflow bug, such block/transaction would be considered invalid by the new nodes, so that as long as the new nodes have majority of hashrate, the system will be still kept as whole. I'd also like to take the case of CVE-2018-17144 as an example of unintentional/implicit harmful (but not seemed to be intentionally malicious) hard-fork, which hasn't really cause any chain split on bitcoin so far. I once heard that this vulnerability had been exploited on some altcoins - in such cases, even if the new (exploited) chain has more cumulative proof-of-work, which must be produced by a majority of hashrate, the old (unaffected) nodes will still consider such chain invalid, which would obviously lead to chain fork. It's notable that once the old (unaffected) nodes regain the majority of hash rate, the new (vulnerable) nodes will still turn to follow the "old" (clean) chain, instead of their "new" (exploited) chain, since the "old" (clean) chain will still be considered valid by the new (vulnerable) nodes - that's obviously because such hard-fork was (seemed to be, at least) unintentional, so that the new rule (vulnerability) was not well-designed, to guarantee that the new chain won't be discarded anyway, even if a more-PoW chain which doesn't have the "new freedom" appears - that, might be the reason why hard-forks are generally considered more subtle - in the case of soft-fork, even if the old nodes regain the majority of hash rate, as long as the "old" chain contains things forbidden by the new rule (which would be usually true), the new nodes will still consider the "old" chain invalid, and then ignore it. >The new rule change is implemented in such a way, that non-upgraded software ALWAYS validate it (as true) under old ruleset, even as it is not understanding what it means under new rule. I think soft-fork could be more than that: a soft-fork should be a **tighter** rule, that some previously allowed behavoir would be forbidden (while a hard-fork should be a *looser* rule, that there will be some "new freedom"). What you said should be merely a subset of soft-fork, that some *"grey area"* (that "weird-but-still-valid") would be forbidden.

Commented by /u/KiFastCallEntry in /r/Buttcoin on January 8, 2020 07:43:29

>\[DOES NOT\] SPLIT\[S\] THE CHAIN I consider that either "hard-fork" or "soft-fork" should be a type of rule change, as means to upgrade the protocol, which could either cause a chain split, or not; while "chain splitting" should be the consequence in reality. So, sorry, I cannot really understand your definition of soft-fork and hard-fork so far, because such definition seemed to be confusing cause and effect.

Commented by /u/KiFastCallEntry in /r/Buttcoin on January 8, 2020 00:18:19

> Coins can only move from the old part to the new part, never the other way. I saw what I had misunderstood - I thought the new coins could still be converted back, which didn't match your definition. The reason why I had such misunderstanding was because I had compatibility in the mind, that a sane soft-fork should guarantee that the old wallet app would still be able to receive new coins. However, according to your definition that: >Except that, if a transaction has all its inputs in the "old" part of the block, the transaction itself is placed in the old part. > >Then, users with the old version of the wallet, that only sees the old part of each block, can still spend their old coins and see the transactions confirmed as usual. Therefore, there would still be *two different coins*, which would be the similar case of the XCP token, that although old coins would be simply [burnt]( (no way back) to be converted into new coins, the remaining *old coins would still be circulating*. That's saying, you are still *assuming* that the cryptocurrency ecosystem would be stupid enough to fail to recognise the fact that there would be two different coins. >People who invest in crypto are stupid, like people who invest in lotteries, ponzis, or pyramid schemes -- for the same reason. I didn't say they are not. As long as there are a non-negligible number of greater-fools who keep investing, it seem that there will always be some trashcoins/scamcoins/etc in the world, maybe this situation could come to an end in some date if regulators took further actions. However, this seems to be irrelevant - I actually said that they should not be stupid *enough* to fail to recognise a simple fact.

Commented by /u/KiFastCallEntry in /r/Buttcoin on January 8, 2020 00:18:17

In my opinion, such inflation soft-fork would work just like alloys - brass, a kind of alloy, contains both copper and zinc, which doesn't mean that copper atoms and zinc atoms which brass consisted has turned into anything different, these two chemical elements could still be separated once again (just like those new coins and old coins could be "converted" back and forth). Obviously some people don't know or care about that fact, however, once a person gained enough knowledge about chemistry, he would inevitably understand that fact. SegWit works just like the fact that the copper/zinc/iron/brass/etc (just like bitcoin/inflated fraction of the new coins/litecoin/new coins on the inflation extension part/etc) could be casted into various shapes, which has nothing to do with the concept of chemical elements. Your argument seemed to simply assume that the cryptocurrency ecosystem was stupid enough that they would be unable to recognise that fact at all. In my opinion, although countless ridiculous things had once taken place in this field, they should not be that stupid yet.

Commented by /u/KiFastCallEntry in /r/Buttcoin on January 7, 2020 15:57:27

>refuse to accept those coins or any coins that have been mixed with them. It doesn't really matter wheter they want to refuse to accept either type of the coins. What I said is that the ecosystem would be highly likely to recognise that "there are **two different and separate coins, and the new coins exist only in the new part**" - that's my point, that even "which coin is the one true bitcoin" is not important at all. If I didn't misunderstand this point, it's probably saying that such soft-fork doesn't really consist. >post-2008 dollars Frankly speaking, this doesn't seem to be a good metaphor to me, otherwise, BTC/BCH/BSV should be completely interchangeable, that they should all have almostly equal price in the market, since all of them could be recognised as "a kind of bitcoin", right? >That does not matter, because those "old" TXOs that got spent by transactions in the "new" extension cannot be spent again by anyone. I mentioned this detail to explain that, there would still be a clear borderline between new coins and old coins. >Yes, but that is not the idea. The scenario is that a majority of the miners wants to increase the reward with a soft fork, *without* requiring users to upgrade -- precisely because that will not split the coin, and will keep al lazy users on the same coin. Generally miners won't mind if more and more minable coins would continuously appear. Even if a majority of miners were so determined to kill any resistant (original) chain (while they created a hard-fork instead of a soft-fork), there's still a possibilty that a PoW change (hard-fork as well) chain would finally appear.

Commented by /u/KiFastCallEntry in /r/Buttcoin on January 7, 2020 06:59:57

I'm sorry that I didn't describe my idea properly, but, I don't think I misunderstood soft-forks so far, if so, please correct me. ​ In my opinion, there's indeedly a *possibility* that no chain fork would appear at all - however, there would be a subtle problem still: how could the ecosystem recognise ~~the definitely distinguishable "inflated fraction" of new coins, which would exist only in the new part~~ the definitely distinguishable new coins which would exist only in the new part, which would definitely contain the "inflated fraction", which could not exist in the old part at all? Then, there would be two possibilities: One would be exactly what you had supposed, that all the new coins would be recognised as "bitcoin" as well; The other, would seem to be weird: the new coins, which would obviously exist only in the new part, would be recognised as a somehow "pegged" altcoin, instead of bitcoin itself. ​ There's actually a difference between SegWit and your "inflation soft-fork", that once the old non-segwit coins got converted into new segwit coins, the old coins/UTXOs would just be destroyed, which is *not the case* in your "inflation soft-fork" - there should be still "stubs" on the non-existension part of the chain, in other words, those "converted" coins won't disappear on "the old part" of the blockchain anyway. ​ >even if some dissenters do a hard fork and create a "BTC Scarce" (BTS) If I understood correctly, it should be the inflationists, *not the dissenters*, who had to do a hard fork, in order to make the new coins really indistinguishable with original coins, which would be true only on their own hard-forked chain still.

Commented by /u/KiFastCallEntry in /r/Buttcoin on January 7, 2020 04:54:32

> the decision matches what I wrote Sorry, but I didn't really get it. Are you referring to this? >The clients would have a hard time arguing in court that those coins are less valuable than the old coins that they deposited. Frankly speaking, I actually considered this to be irrelevant, because, in that case: >fork coins were still recognised as different coins, and, "protected by law because its property nature and economic value". However, I still think this problem interesting as well, just like what BitMEX had done - they simply refused withdrawal requests of forked coins.

Commented by /u/KiFastCallEntry in /r/Buttcoin on January 7, 2020 04:17:51

In my opinion, it's highly unlikey to avoid a coin split. Frankly speaking, I still don't think the idea of a SegWit-style soft-fork technique, which could avoid coin/chain split, is convincing, because, again, in such a soft-fork: >However, the extra reward coins will exist only in the new part. And, we both [agreed]( that: >To make the "old coins" and "new coins" really indistinguishable with each other, it had to be a hard-fork Then, why couldn't the ecosystem recognise that, it's actually something like just another merge-mined altcoin? I say "something like altcoin" instead of "altcoin" here, because I agree that there's possibly a chance that the entire ecosystem would just accept such a soft-fork as their fate, without any resistance - however, this does not seem to be very likely to happen for me. In my opinion, it would be very likely to see a resistant original chain fork to appear, therefore, the "coin split" would be unavoidable. Even if there would be no chain fork, I still think it would just work like 1-to-1 pegged coins like WBTC on the ETH chain - anyway, it would be a *different* coin, with a broken "pegged" definition in the beginning.

Commented by /u/KiFastCallEntry in /r/Buttcoin on January 7, 2020 03:18:40

I'm sorry for unconscious deviation from your definition. I have noticed that inconsistency in my logic just now, and responded [~~here~~]( [here](

Commented by /u/KiFastCallEntry in /r/Buttcoin on January 7, 2020 02:38:07

>They will be increasingly isolated from the bitcoin economy. That's why I considered the situation might be just similar to the ETH/DAO hard-fork case. To make the "old coins" and "new coins" really indistinguishable with each other, I thought it had to be a hard-fork (which would deviate from your definition). The original resisting chain may or may not survive, but, however, there's always a potential that such a fork could be launched.

Commented by /u/KiFastCallEntry in /r/Buttcoin on January 7, 2020 02:31:03

>as indistinguishable from "old" bitcoins as SegWit bitcoins are indistinguishable from non-SegWit bitcoins. Not really, Although "new (possibly inflated) coins" and "old coins" could be converted back and forth, the old nodes won't allow the "inflated fraction of new coins" to be converted back to "old coins". I agree that P2SH-wrapped SegWit coins are indistinguishable form non-SegWit P2SH coins, before exposure of their "redeem script" (which would almostly inevitably happen when these coins would be spent), however, I don't see this relevant.

Commented by /u/KiFastCallEntry in /r/Buttcoin on January 7, 2020 02:27:51

>Accoridng to the old rules Then those coins which could only circulate on the extension part would be considered invalid, or nothing - that's saying, it's just another merge-mined altcoin which inherited some properties from fork coins.

Commented by /u/KiFastCallEntry in /r/Buttcoin on January 7, 2020 02:06:46

>I don't get what you mean. There is no "original BTC chain". I meant the partial blockchain without the SegWit extension part. >The proposed scenario would be similar. There will be only one BTC chain, and, after activation, **all** mined blocks would need to have a valid new extension (besides the SegWit one), otherwise they would be orphaned. It might not be similar to SegWit that "there will be only one chain", since ETC, the original chain of ETH, had survived. Even for the SegWit case, the big blockers had created a forked chain (BCH) as well. ​ >The difference is visible on the bills (because of the date) Due to the nature of UTXO, that spent coins got "destroyed", I can't really see such property on bitcoin... To my understanding, the "taint" indeedly exists, however, it's irrelevant to what we have been discussing, because both you and me had agreed that: >However, the extra reward coins will exist only in the new part. Perhaps you meant that "the entire ecosystem would simply ignore the potential that an resisting original fork could survive at all"? If so, I could probably agree. ​ EDIT: Here, I unconsciously supposed that it would have to be a hard-fork, which deviated from /u/jstolfi's definition - a SegWit-style soft-fork. However, I still think it would be probably more similar to the ETH/DAO hard-fork case, that a resisting original forked chain might appear. [Here]( are the [reasons](

Commented by /u/KiFastCallEntry in /r/Buttcoin on January 7, 2020 01:57:29

> they would the in the same chain IMHO I can't really agree still. I have responded to this claim [here]( >IMHO, it *would* cause a coin split, as long as some "patriots" could maintain a forked chain, with the original version of node software - the problem is just whether the "patriotic" original chain could survive. ​ >mix them with new coins in their hot or cold wallets, and offer only tainted coins to clients who ask to withdraw. Again, we had both agreed that: >However, the extra reward coins will exist only in the new part. In my opinion, such "mixing" would not be quite different than the case that coins from a fraudulent exchange are still circulating on the main chain as usual. ​ >The clients would have a hard time arguing in court that those coins are less valuable than the old coins that they deposited. There's a case in reality: []( In this case, I saw the fork coins were still recognised as different coins, and, "protected by law because its property nature and economic value".

Commented by /u/KiFastCallEntry in /r/Buttcoin on January 7, 2020 01:23:31

> the receiver has no obligation to help him with that. Agreed. However, for the case where a merchant unwillingly received some trashcoins as a "payment for goods", he could still send these trashcoins back anyway. ​ >You surely can see the huge risks of doing that. The receiver could simply send out the more valuable coin first. It would be just cumbersome, not inevitably risky.

Commented by /u/KiFastCallEntry in /r/Buttcoin on January 7, 2020 01:16:35

>No,it will not be sililar. Again, it would be a soft fork (just like SeegWit) Just like the case of SegWit that the "segregated witness" data only exist outside the original chain, you had also said: >However, the extra reward coins will exist only in the new part. ​ >Said another way, the tracking of stolen or drug money does NOT make the money itself "dirty". Then what's the case for the inflated coins? I'm still confused on this point: > The taint of "newness" would be permanent and irreversible.

Commented by /u/KiFastCallEntry in /r/Buttcoin on January 7, 2020 00:58:57

>The wallet would not be "malicious". The increase of reward would be announced as necessary to "save" bitcoin from hashrate collapse, and would be supported by a number of hired whorexperts. It seems that this would be quite similar to the ETH/DAO hard-fork case. ETC, the original chain, had survived, but almostly abandoned by the market (and it had also been 51%-attacked). >The advantage of the extension block technique Since the blockchain has the nature of transparency, I on the contrary think this technique has inherent "disadvantage" that the inflation would be public. >it can be imposed on everybody by a simple majority of the miners, without causing a coin split, and does not require all users to upgrade before the activation. IMHO, it *would* cause a coin split, as long as some "patriots" could maintain a forked chain, with the original version of node software - the problem is just whether the "patriotic" original chain could survive. >protected by the same PoW as the oldcoins There are already bunch of merge-mined coins, which have always been recognised as different coins so far. >Any mixing of "old" and "new" (tainted) coins would result in "new" (tainted) coins. I don't agree still. Just like what we had both said before, there would be new coins which could only circulate outside the original chain. The problem was just whether the new coins could be recognised as the "upgraded" or "official" one. >Also, the taint of "criminal origin", like that of banknotes from a bank heist, will evaporate after a few transactions. The taint of "newness" would be permanent and irreversible. Honestly speaking, I didn't get this point... >As I explained above, those exchanges would only lose clients. So far, although those KYC/AML compliant exchanges have been claimed to be "evil" by the "hard core believers", those exchanges still remain to be top exchanges - that's why I thought this situation was interesting. >They would have a hard time justifying that in court. Like a store owner who takes a bank deposit of $1000 but refuses to send the goods because he claims that the deposit included "bogus post-2008" dollars. I was actually describing an embarrasing situation for crypto gamblers. There's also another embarrasing situation for them, that they had once erroneously sent their fork coins to the deposit address of another fork coin. After that, the exchange may not be willing to help their poor customer to take back their erroneously sent fork coins - however, the exchange technically always has the ability to return those erroneusly sent coins, which would still be recognised as a *different* type of coin.

Commented by /u/KiFastCallEntry in /r/Buttcoin on January 7, 2020 00:34:51

>If someone sends new or tainted coins to that merchant, neither party can reverse the transaction -- until the receiver upgrades his wallet, and sends them back. This situation had already happened actually, for fork coins like BTC/BCH/BSV. Then... they were just treated as different coins still. It was interesting still, because it's said that many crypto investors felt panic for "dilution of value caused by fork coins".

Commented by /u/KiFastCallEntry in /r/Buttcoin on January 6, 2020 23:52:28

>The idea is that the miners bribe the developers to release a wallet I don't think this could work on significant coins easily. If it's so easy to let such such a malicious wallet go right under people's noses, probably it's better to directly embed a backdoor into the wallet software - just like the case of the DAO, nobody can tell it's really an unexpected "hack", or an intentional backdoor. Also, isn't such extension-block-style soft-fork completely unnecessary, if 51% of the hashpower are considered to dominate the system already? >Then, users with the old version of the wallet, that only sees the old part of each block, can still spend their old coins and see the transactions confirmed as usual. > >However, the extra reward coins will exist only in the new part. Users with the new release can receive and spend those coins, and mix them with old coins, seamlessly. This seems to be quite similar to a fraudulent/insolvent/hacked centralized exchange for me. >True-blood butters claim that they will just refuse to accept coins that are in the extension part. Surprisingly, it seemed that they didn't really care to take those "tainted" coins, did they? >That would be like a store owner refusing to accept any dollar bill printed after 2008 because he believes that those dollars are "bogus". That's basically the case of KYC/AML compliant exchanges, which seems to be subtle, because I didn't remember the "tainted coins" could always be tracked/marked. However, the situation that big exchanges might reject (or even confiscate) the deposited coins is interesting still.

Commented by /u/KiFastCallEntry in /r/Buttcoin on January 6, 2020 23:22:24

I once had a similar idea, but, I thought that such "soft-fork" didn't really differ from a hard fork, since there would be a new type of coin circulating on the extension blocks only. SegWit coins at least circulate on the main chain in a seemingly strange way. I even thought that such hard-fork didn't really differ from an insolvent centralized exchange.

Commented by /u/KiFastCallEntry in /r/Buttcoin on January 6, 2020 12:54:46

>but "IF" Then the BDoS blog post mentioned a mitigation that the miners could set a deadline for such suspicious block headers.

Commented by /u/KiFastCallEntry in /r/Buttcoin on January 6, 2020 10:00:47

I actually agree that SegWit is over complexed, just to achieve the goal of "no hardfork!!!" - however, I think at least some ideas behind SegWit are beneficial to bitcoin as well, although these benefits can not outweigh the network congestion itself at all, and besides, some previously promoted "benefits" like "signature pruning" and "compact fraud proofs" turned out to have little practical value or even impossible. If I recalled correctly, SegWit was recognised as an "all-in-one" solution which was intended to achieve multiple goals at same time. It drastically changed bitcoin transaction data structure and signature verification/sighash serialisation stuffs, which was its real value to my understanding, because the original transaction data structure/sighash serialisation design of Satoshi was actually inefficient and confusing (correct me if I misunderstood this point). As for block size increasing... there was once a (seemingly convoluted as well) proposal called "extension blocks" as well, wasn't it? What do you think of that? I didn't look into it, but I think it didn't seem to be a good way to increase the block size either.

Commented by /u/KiFastCallEntry in /r/Buttcoin on January 6, 2020 09:57:49

It doesn't make much difference because of such exaggeration. It's still astounding that there's any talented dev who devoted/wasted his life to such a field. And, it might not be exaggeration, because as we all know, the blockchain/cryptocurrency stuff has already became a "global phenomenon" which even involved reputable academic institutions...

Commented by /u/KiFastCallEntry in /r/Buttcoin on January 6, 2020 09:46:06

Then someone just argued that "if the miners extend complete blocks (instead of merely block headers) only, this attack is equivalent to the old selfish mining attack, which isn't that novel, nor that harmful..."

Commented by /u/KiFastCallEntry in /r/Buttcoin on January 6, 2020 08:45:12

The BDoS blog post mentioned something named "profitability factor", which depends on the price of coin and the cost of energy consumed by mining rigs. That's saying, the reason why the BDoS attack could exist is that most miners have to pay their electricity bill, which must be covered by the profits of mined coins. In other words, that's saying, the BDoS could only halt the system by pushing the miners (slightly) below the bottom line of profitability (sorry, I don't know proper terms). Is the above understanding correct? If so, I think it seems to be similar to selfish mining attack.

Commented by /u/KiFastCallEntry in /r/Buttcoin on January 6, 2020 03:07:31

To me, the most impressive limitation/risk of PoS is the "long-range attack", that the former stakers who just held some voting power in the past are still able to attack the current system, in which they don't hold majority of voting power, or even worse, that they no longer hold anything any more. Such attack was said to be the reason why PoS coins cannot get rid of checkpoints, which is generally considered a form of centralisation, since people who hasn't been involved in the system previously cannot determine which chain is the malicious attacking one or the honest original one, therefore they must trust someone. However, I've read an article written by a researcher, in which he argued that "checkpoints are acceptable, because people naturally believe something outside the blockchain, which could be named as 'social common knowledge', which would make the long-range attack highly unlikely to succeed, therefore, PoS systems are highly likely to be secure even if there's no checkpoint at all". He also argued that the "nothing-at-stack" attack, rather than the long-range attack, is the real threat to PoS systems - however, I still don't get this point so far...

Commented by /u/KiFastCallEntry in /r/Buttcoin on January 6, 2020 02:52:58

That big blocker provided an explanation of empty blocks, which was argued to be "evidence of covert ASICBoost" by Core supporters - never mind, that's not what I'm asking. I'm curious that what's you opinion on Peter Rizun's signature withholding attack against SegWit? He actually commented right under that blog post that it was quite similar to the BDoS attack.

Commented by /u/KiFastCallEntry in /r/Buttcoin on January 5, 2020 22:00:46

When did the pools stop engaging in SPV mining? I saw a big blocker defending against accusations about covert ASICBoost in 2017 with an argument like "that's SPY (header-only) mining, not covert ASICBoost", if I recalled correctly. Also, what's your opinion about Greg's SegWit-defending argument?

Commented by /u/KiFastCallEntry in /r/Buttcoin on January 5, 2020 19:16:13

>the malicious nodes can force either of those two bad outcomes. I'm still confused that whether the innocent participants of PoS systems like (specifically) Algorand or Avalanche could know that they are not in consensus, if some malicious participants were present? If so, it doesn't seem to be so bad to face such limitation or risk, because the users could clearly know that the system was "out of service", instead of being defrauded.

Commented by /u/KiFastCallEntry in /r/Buttcoin on January 5, 2020 17:17:37

Although I didn't thoroughly read the BDoS attack blog post, it seemed to be related about miner incentives. I've seen some people argued that such attack is impractical, in other words, they argued that, in reality, it would be equivalent to the selfish mining attack proposed years ago. >Actually it is not the miners but the mining pools that create block candidates and decide which parent block to use. This seemed to be a well-known fact. >The badly named "SPV mining" practice is another common modification. As far as I could remember, Greg Maxwell also argued that a similar attack against SegWit proposed by Peter Rizun was pointless, because it would be far more efficient to exploit SPV mining, which is irrelevant to SegWit. (link: []( )

Commented by /u/KiFastCallEntry in /r/Buttcoin on January 5, 2020 17:08:52

> I mean this post is pure fantasy by OP. I don't agree. There're definitely some talented devs like Rusty Russell who are devoted (or "wasting their lives" in other words) to crypto stuff. > How many coders are there in the world? How many comparitively are in crytpo? This point could be interesting. However, the OP didn't mention that, did (s)he?

Commented by /u/KiFastCallEntry in /r/Buttcoin on January 5, 2020 16:59:38

>One advantage of Satoshi's majority-of-work rule is that it cannot get stuck: no matter what the miners do, there will be always one branch that has a majority of the work. Recently several researchers proposed this, which seemed to be relevant: []( What's your opinion on this? >an attacker who controls 35% of the total voting power (total stake) can prevent the other 65% from reaching a consensus Sorry, but I didn't understand what you meant. Would innocent participants be able to notice that they are not in consensus?

Commented by /u/KiFastCallEntry in /r/Buttcoin on January 5, 2020 15:57:37

>hundreds of people will get to work of that goal ​ >all those"scientists " and "developers" would keep working, and announcing "substantial progress", for as long as that VC money lasts. Did you imply that those "scientists" and "developers" are intentionally disingenuous, or just "brainwashed" to believe such impossible lies?

Commented by /u/KiFastCallEntry in /r/Buttcoin on January 5, 2020 15:16:49

[\_Russell]( Edit: [\_Cohen#cite\_ref-6]( [\_Eich#cite\\_8-0]( I don't know much about this topic actually... I just felt a bit disappointed, since I didn't see anyone mentioning any talented devs in this thread.

Commented by /u/KiFastCallEntry in /r/Buttcoin on January 5, 2020 13:40:18

[]( []( [\_D.\_Green]( [\_Micali](

Commented by /u/KiFastCallEntry in /r/Buttcoin on January 5, 2020 10:28:30

What's your opinion about Algorand, and it's founder, Silvio Micali? Do you feel kinda depressed for him?

Commented by /u/KiFastCallEntry in /r/Buttcoin on January 5, 2020 09:56:34

But why did Lenovo mount the data partition with the discard parameter? Is that behaviour simply wrong?

Commented by /u/KiFastCallEntry in /r/LineageOS on November 6, 2019 23:17:40

Then Lenovo was wrong on mounting the /data (including the emulated sdcard) with discard parameter? As far as I could remember, the performance issue of discard exists only on limited devices...

Commented by /u/KiFastCallEntry in /r/LineageOS on October 30, 2019 21:39:42

>resizing the partition No, It's not the partition needs to be shrunk, but the filesystem.

Commented by /u/KiFastCallEntry in /r/LineageOS on October 11, 2019 08:32:58

Have anyone actually tried to recompile the kernel yet?

Commented by /u/KiFastCallEntry in /r/LineageOS on October 9, 2019 00:34:21

>selecting different coins This reminds me of an issue related to "manual full-RBF": []( I didn't see coin selection mentioned in this guide, which seemed to be possible to cause similar problems. I'm sorry that this might be off-topic, but, I'm curious that how this issue was fixed/avoided, too.

Commented by /u/KiFastCallEntry in /r/Bitcoin on September 25, 2019 23:26:21

I once heard that a flawed implementation of BIP70 could allow a malicious payee to capture signed transaction, then the malicious payee could defraud the payer by tricking him into thinking the payment was unsuccessful/canceled, while the payment transaction was actually broadcasted. To me this issue doesn't seem to be very serious. A malicious merchant always has countless ways to defraud their customers. Also, it seems that this issue can be easily fixed in the wallet app used by the payer, by simply notifying the payer that the transaction is already sent out even if the server responded "there's something wrong". As for privacy, I once heard that BitPay refused to process payments if the payer was connecting through Tor - however, this didn't seem to be a problem of BIP70 itself, since BitPay or any other online merchants/payment processors can always reject customers connecting through Tor, with or without BIP70. I'm really concerned that whether BIP70 could leak privacy informations such as transaction history/addresses/labels/etc. I wonder if BIP70 has problems like that?

Commented by /u/KiFastCallEntry in /r/Bitcoin on September 25, 2019 22:18:38

>BIP70 has resulted in remotely exploitable vulnerabilities that would allow an attacker to steal the wallet's private keys. > >BIP70 has had multiple serious privacy vulnerabilities Holy shit... That really scares me. Could you elaborate? Are Bitcoin Core users vulnerable?

Commented by /u/KiFastCallEntry in /r/Bitcoin on September 25, 2019 21:52:19

> it's a modified version that was never supported in Bitcoin-Qt in the first place Can Bitcoin Core work with BitPay (flawlessly or imperfectly or not working at all)? Is there any security/privacy concerns? Please elaborate, thanks. >You're welcome to maintain a version, or find someone who does, which retains this feature. That includes the ability to provide binaries for others. For example Bitcoin Knots is a maintained fork of the software, with a different set of features. I'm worried that some users will try to find insecure ways to bypass BIP70.

Commented by /u/KiFastCallEntry in /r/Bitcoin on September 25, 2019 21:50:15

The internal entropy is mixed with external entropy, so even if the internal entropy is backdoored, this backdoor is actually nullified, as long as the external entropy works fine. However, if an attacker has the ability to rig the internal entropy, why would he perform the attack in such a way that is both convoluted and extremley unlikely to work...

Commented by /u/KiFastCallEntry in /r/TREZOR on August 22, 2019 08:02:02

"Recovery seed" in Trezor' term actually means "mnemonic". Trezor mixes two sources of entropy to generate the mnemonic. The mnemonic (together with optional passphrase) is then used to generate the BIP32 seed through PBKDF2 stretching. []( [\_5\_7]( []( ​ If you want to generate the mnemonic without Trezor, you may use [Ian Coleman's BIP39 tool]( on a offline computer which is trusted to be free of backdoors, by rolling something like a casino-grade dice. However, you are still trusting your Trezor anyway, as long as you use it as a wallet, eg. a backdoor like [this]( might exist.

Commented by /u/KiFastCallEntry in /r/TREZOR on August 22, 2019 06:18:33

Did you forget "/s"? I have tried all 2048 words with help of a simple script. The results (for 24-word seed phrase) are: `bacon flag gas great slice solution summer they trade trap zebra` For 12-word seed phrase, there are much more results (130 in total) due to shorter checksum bits: `action agent aim all ankle announce audit awesome beef believe blue border brand breeze bus business cannon canyon carry cave century cereal chronic coast convince cute dawn dilemma divorce dry elevator else embrace enroll escape evolve exclude excuse exercise expire fetch fever forward fury garment gauge gym half harsh hole hybrid illegal include index into invest involve jeans kick kite later layer legend life lyrics margin melody mom more morning nation neck neglect never noble novel obvious ocean oil orphan oxygen pause peasant permit piano proof pumpkin question real report rough rude salad scale screen sea seat sell seminar seven sheriff siege silver soldier spell split spray stadium sugar sunny sure tobacco tongue track tree trouble twelve twice type uniform useless valid very vibrant virtual vocal warrior word world yellow`

Commented by /u/KiFastCallEntry in /r/TREZOR on June 29, 2019 11:40:16

It has almost 0 possibility to get a seed phrase like that... unless you are finding them out on purpose, instead of randomly picking one.

Commented by /u/KiFastCallEntry in /r/TREZOR on June 29, 2019 11:09:12

Of course it's normal. You can use it with full confidence. Several duplicate words won't make cracking any easier.

Commented by /u/KiFastCallEntry in /r/TREZOR on June 29, 2019 11:08:13

There's already a "Hide all private info" checkbox.

Commented by /u/KiFastCallEntry in /r/Bitcoin on May 20, 2019 04:35:18

Your browser may automatically send your seed phrase to Google/Mozilla/etc's online spellcheck server through HTTPS, if you are using old versions of Ian Coleman's BIP39 tool, with Internet connected.

Commented by /u/KiFastCallEntry in /r/Bitcoin on May 19, 2019 23:57:50


Commented by /u/KiFastCallEntry in /r/Bitcoin on May 19, 2019 23:22:00

AFAIK, peerbloomfilters specifies that whether your node will act as a "server" for BIP37 SPV wallets (like schildbach's wallet, but not Electrum). Turning this config to 0 can block any SPV clients, including those annoying VDS (a Chinese pyramid scheme) mobile wallets. However, it cannot block VDS desktop wallet nodes (which are pruning-enabled 0.16.1 full nodes).

Commented by /u/KiFastCallEntry in /r/Bitcoin on May 6, 2019 09:18:44

They should be participants of a Chinese pyramid scheme, VDS. They don't have NODE_NETWORK enabled, because they must have enabled blockchain pruning.

Commented by /u/KiFastCallEntry in /r/Bitcoin on May 6, 2019 09:04:03

High-speed rail and airplane ticket are considered relative "luxurious", that's the real reason of such restriction. Normally, low social credit is only caused by escape/default of debts. Those people are still able to buy normal train tickets (but "soft sleeper" is still not allowed, though).

Commented by /u/KiFastCallEntry in /r/Bitcoin on March 2, 2019 23:06:23

It should be related to this: [](

Commented by /u/KiFastCallEntry in /r/Bitcoin on February 13, 2019 15:24:45

Syncing requires a large amount of RAM. Enlarging database cache to \~6GB should be enough for avoiding slow disk I/O. There's also a dirty trick: put the chainstate subdirectory into RAMDisk (like ImDisk), use a NTFS junction to redirect the original chainstate path to the RAMDisk, then restart the syncing process. 4GB should be enough for this, but this trick seems to be slower than simply enlarging database cache.

Commented by /u/KiFastCallEntry in /r/Bitcoin on February 11, 2019 02:37:09

bootstrap.dat is trustless, since the full node will still validate it & find for longer blockchain on the network. But, chainstate (UTXO) isn't, the user must trust the provider that he didn't sneak sth malicious into it.

Commented by /u/KiFastCallEntry in /r/Bitcoin on February 11, 2019 02:32:11

People shouldn't use such service to "update chainstate", this is insecure, since without validating the entire blockchain, you cannot ensure that the chainstate is not a fake.

Commented by /u/KiFastCallEntry in /r/Bitcoin on February 11, 2019 02:27:54

Plain text still can be used to defraud the user. Electrum client connects to electrum servers, not Bitcoin Core full nodes(which lacks some indexing functionality). The Electrum devs have fixed this problem by receiving an error code from the server first, then looking up the corresponding error message locally, instead of receiving error messages directly from the server.

Commented by /u/KiFastCallEntry in /r/Bitcoin on February 10, 2019 00:07:48

Electrum devs did a white hat phishing, which is intended to reach users who still has not upgraded. It's embarrasing that the evil phishing attackers exploited the same flaw, so this white hat phishing may muddy the waters more.

Commented by /u/KiFastCallEntry in /r/Bitcoin on February 9, 2019 23:59:04

They had already fixed this. But, it's pretty hard to reach every user who is still using old versions. So, ElectrumX server implemented a white hat phishing to reach those users.

Commented by /u/KiFastCallEntry in /r/Bitcoin on February 9, 2019 23:56:09

Your computer could be hacked, then the hacker would gain full control of it, that's why hardware wallets exist. The hacker may hijack your wallet software to replace the recipient address and amount, so that he could steal your coins. Hardware wallet prevents this by displaying the transaction details on it's own screen and letting you to authenticate the transaction by pressing its own button.

Commented by /u/KiFastCallEntry in /r/Bitcoin on February 6, 2019 18:43:38

Always check the screen of your hardware wallet.

Commented by /u/KiFastCallEntry in /r/Bitcoin on February 6, 2019 16:55:31

Hardware wallet and Electrum Personal Server might help, but, I also heard that the user should be cautious with such combination.

Commented by /u/KiFastCallEntry in /r/Bitcoin on February 6, 2019 05:10:50

This issue seems to be somewhat persistent: []( Personally I just want to make a reminder, it's up to the mods to decide whether to continue to pin it or not.

Commented by /u/KiFastCallEntry in /r/Bitcoin on February 6, 2019 05:04:20

At least you should never expose the RPC port to untrusted network (e.g. the public internet/guest wifi hotspot/public VPN client or server), otherwise the funds stored in Core/LND could be stolen. An extra-strong password is also recommended for RPC authentication, if you may browse some random untrusted websites with your Pi (this is out of paranoia, because modern browsers have CORS support already) Theoretically your node is possible to be targeted from various attacks, the worst thing is a 0day RCE vulnerability which enables the hacker to take full control of your Pi, but I have never learned that such thing once happened. The devs are also extra cautious about security stuff.

Commented by /u/KiFastCallEntry in /r/Bitcoin on February 4, 2019 02:48:15

This still doesn't solve the problem completely, since vulnerable electrum won't see the "white hat phishing" if it chooses an evil server initially.

Commented by /u/KiFastCallEntry in /r/Bitcoin on February 3, 2019 23:30:18

I'm not using public servers, because I'm using electrum personal server+bitcoin core. In my opinion, they should alert the user **without** giving links directly.

Commented by /u/KiFastCallEntry in /r/Bitcoin on February 3, 2019 20:13:01

If most users must rely on trusted 3rd party, what's the point to use Bitcoin or LN, instead of the existing banking system?

Commented by /u/KiFastCallEntry in /r/Bitcoin on January 13, 2019 02:34:50

I guess that this feature is just a simple automated process of get_invoice and pay. So that the receiver still need to keep online.

Commented by /u/KiFastCallEntry in /r/Bitcoin on January 12, 2019 06:16:56

BlueWallet seems to be a custody service. I found nowhere to control my channels. You must rely on exchanges like zigzag to get your LN funds out.

Commented by /u/KiFastCallEntry in /r/Bitcoin on January 12, 2019 05:56:00

Of course yes. 1.Watchtowers are still in research/development. If you are receiving funds through LN, you must keep your LN node online, at least every now and then. 2.c-lightning had a crashing bug fixed just now: [\_twit/status/1083633822929805313](

Commented by /u/KiFastCallEntry in /r/lightningnetwork on January 11, 2019 08:36:09

1.The price is too high. 2.It should be done by splicing and dual-funded channels. 3.I hope LN could make such type of service completely unnecessary in the future.

Commented by /u/KiFastCallEntry in /r/lightningnetwork on January 9, 2019 17:26:56

>What if I send a large amount of BTC using LN and no node has enough balance to afford it ? Will the transaction stuck in the network ? No, it won't stuck. It will simply fail, after several rounds of probes/attempts. AMP (a WIP tech) could improve this by combining local balances of multiple channels. >Where would the original BTC go es ? Payment channels. A payment channel looks like an ordinary 2of2 multisig address, but both participating parties hold their own unboradcasted transactions, which can be broadcasted whenever something goes wrong, like cheating penalty/unilateral force-closing. >What is the concept of deposit balance of LN BTC wallet ? There's actually no unified "deposit balance" in LN, although a LN wallet could simply add up local balances of all existing channels together. Different channel has different counterparty, thus they have different liquidity or "reachable ranges". However, a wallet could try to rebalance its channels (by on-chain operations like splicing) to circumvent such problem. >Would BTC LN affects the BTC price by this ? It's hard to say. Some hype might arise, but LN should be able to improve usability of Bitcoin in general after all. [Bitcoin is highly speculative.](

Commented by /u/KiFastCallEntry in /r/Bitcoin on January 8, 2019 09:17:54

Ah, I think there's something wrong about your lntip bot. I've sent a private message to you.

Commented by /u/KiFastCallEntry in /r/bottesting on January 8, 2019 00:24:39

Currently, AFAIK, a table (a payment channel) only allows two persons to sit around. You pass some cards placed on table A to Bob, while Bob pass some other cards placed on table B to Carol. It might be possible to allow more people to sit around a single table in the future, but such technology is still under researuch/development. The "Channel factories" technology is intended to do the job of "using other people's table" to my knowledge.

Commented by /u/KiFastCallEntry in /r/Bitcoin on January 7, 2019 22:40:42

If you want to have a try with LN, you could install **Eclair wallet for Android**, which is quite simple to use. You can find some popular services accepting LN on []( ​ **LN is an off-chain scaling techology.** It consists of many payment channels. A payment channel looks like ordinary 2of2 multisig address, but it's much more than that, because both parties hold some unbroadcasted transactions which could be broadcasted to the bitcoin network in case of misbehavior (like stealing spent funds back). Therefore, currently **LN requires the user to keep online, at least every now and then**, in order to watch potential cheating transaction broadcasted to the bitcoin network by a malicious counterparty. If the user is unable to run his own LN node to do that, there must be someone else to do so instead, such technology is under development, which is called "watchtower". Furthermore, since HTLC requires that all participating parties must negotiate with each other to complete each payment, **it's impossible to receive LN payment offline** \- ~~except for custodial wallets~~ this is true even for custodial wallets (although such service could free their users from maintaining LN nodes), because the provider of such custodial service still has to run his LN node & keep it online, which is not the case with ordinary on-chain transactions. In addtition, custodial services provided by 3rd party are obviously against the trustless/decentralizaion idea of bitcoin. For example, if you want to pay Walmart, you could open a channel with them directly. Once the channel setup is complete, you and Walmart could repartition the funds stored in the 2of2 multisig address, which is equivalent to sending funds back and forth. But, this is obviously quite limited, because a single channel only enables two related party to transact with each other, in other words, the fund is in fact locked in that 2of2 multisig address. Techniques like splicing may relieve such limitation, but you must do on-chain transactions to take your funds out of a channel, which doesn't meet the idea of off-chain scaling. The core idea of LN is that a payment could be "routed" through a series of payment channels, therefore the limitations mentioned above could be circumvented. HTLC ensures that the relaying nodes along the path cannot cheat, otherwise they would be penalized. For example, If Bob has some spare bitcoins, he could use these bitcoins to open payment channels with some popular businesses, like Starbucks, McDonald's, whatever. After that, you could simply open a channel with Bob, then Bob will use his spare bitcoins which are already deposited in the payment channels to "route" payments for you. In more detail, while making a payment, your wallet software would have some negotiation with both Bob and Starbucks first, which ensures both you and Bob cannot cheat against each other. After that, Bob first pays Starbucks with some of his spare bitcoins with confidence, you then pay Bob the price of a cup of coffee+a little bit routing fee.

Commented by /u/KiFastCallEntry in /r/Bitcoin on January 7, 2019 21:41:48

All BTC lightning transactions are in fact bitcoin transactions, which could be broadcasted to the bitcoin network any time - but you don't have to do that except there is something wrong, like unilateral force-closing of a channel. LN could be used for cryptocurrencies other than bitcoin, but currently it has the best adoption in BTC.

Commented by /u/KiFastCallEntry in /r/Bitcoin on January 7, 2019 21:04:30

Oh, the devs are working on paging support: I hope this problem would be resolved soon.

Commented by /u/KiFastCallEntry in /r/Bitcoin on December 7, 2018 05:24:38

"Sorry! Addresses with a large number of transactions aren't currently supported."

Commented by /u/KiFastCallEntry in /r/Bitcoin on December 6, 2018 23:00:46

The model described by that blog post seems to have poor privacy, since gateway nodes are able to monitor end users. "Hey, gateway X, open a private channel to me" is actually "I'm an end user, not an intermediate node".

Commented by /u/KiFastCallEntry in /r/Bitcoin on December 2, 2018 04:35:54

Commented by /u/KiFastCallEntry in /r/rootstock on November 19, 2018 00:51:43

"getnewaddress" generates a new address (corresponding to a new public/private keypair). "addwitnessaddress" turns a traditional 1-prefixing P2PKH address into a 3-prefixing P2SH-P2WPKH address, it doesn't generate new address.

Commented by /u/KiFastCallEntry in /r/Bitcoin on October 5, 2018 13:26:15

Selfish mining is known as "25% attack" brought up by Emin Gün Sirer. It has nothing to do with these empty blocks.

Commented by /u/KiFastCallEntry in /r/Bitcoin on October 5, 2018 12:50:46

> Bitcoin Core 0.17.0 lets users create new wallets whenever they’d like, and it offers this feature in the GUI. Creating/loading wallets is **not a feature available from GUI**. Currently this feature is only accessible from JSON-RPC command line. > As an added benefit, Bitcoin Core 0.17.0 introduces a feature called “Scantxoutset.” This lets users quickly verify whether their new wallet already includes coins (for example, because the private keys are imported from another wallet) by checking the unspent transaction output (UTXO) set, instead of rescanning the entire transaction history. "scantxoutset" is still **experimental**. This feature is actually not able to update wallet balance to correct value, especially for pruning mode users (who are eager to this feature the most), since this action must be done through "importprunedfunds", and the "importprunedfunds" needs a **"txoutproof"**, which is usually **not available from a pruned node**. However, "scantxoutset" already provides enough information to sign a raw transaction spending related coins.

Commented by /u/KiFastCallEntry in /r/Bitcoin on October 5, 2018 12:27:02

It might be hard to tell which factor is the most critical advantage of a smaller block size. The UTXO bloating issue even made a well known big blocker Gavin Andresen worry. BTW, currently, pruning mode has some inconvenience. After importing private keys/wallet.dat/watch-only addresses or pubkeys, you must redownload the entire blockchain data again to find all historical transactions back, as well as to recalculate correct wallet balance. The idea that importing keys without redownloading gigantic blockchain data (while inevitably abandon retrieving complete transaction history) had been proposed several years ago, ~~but, unfortunately, this idea still hasn't came to reality up to now.~~I'm sorry that I didn't read the release note carefully... Bitcoin Core 0.17 actually has a new experimental RPC command "scantxoutset", which is intended to do this. (though very awkward to use for now)

Commented by /u/KiFastCallEntry in /r/Bitcoin on October 5, 2018 08:41:05

Bigger blocks may allow more users, but unlimited block size encourages users to use on-chain transactions without care, so it's expected that more and more users would create countless on-chain transaction, which would obviously bloat the UTXO set.

Commented by /u/KiFastCallEntry in /r/Bitcoin on October 5, 2018 08:08:50

Of course you can. Pruning is simply deleting old blockXXXXX.dat, which is usuallly nearly instant, so it shouldn't have too much negative impact on syncing time.

Commented by /u/KiFastCallEntry in /r/Bitcoin on October 5, 2018 08:02:47

> I do not think Microsoft has some sort of secret compression algorithm that can compress all of 60GB of 24bit WAV files into a few gigabytes Agreed. Are you using HDDs or SSDs? AFAIK, HDDs have a much greater chance to recover deleted files than SSDs. If you remember some filenames, you may also try voidtools' Everything search engine - though most probably you will finally find nothing, but it doesn't bother much to have a try. PS: CAB is merely a container, its compression ratio is various, depend on specific compression algo (eg. LZX has a much greater ratio than DEFLATE).

Commented by /u/KiFastCallEntry in /r/Windows10 on October 5, 2018 05:47:15

Block size has significant impact on: 1/ IBD (Initial Blockchain Download) An average PC is still capable to fully validate the whole transaction history of Bitcoin nowadays, whcih enables the trustless way to use Bitcoin. But, this process usually takes days and nights to complete. By default, Bitcoin Core skips digital signature validation prior to a hard-coded block hash. A user may turn this off by passing "-assumevalid=0" argument to bitcoind/bitcoin-qt. Although turning this off would slow down the inital sync process in some extent, an average PC is still capable to accomplish this mission. SegWit also enables the potential to skip downloading&validating digital signatures - this is often trolled by BCH fanboys, but BCH devs are planing more aggressive things, like UTXO commitment and backward syncing, otherwise the inital sync process for a newcomer full node might last forever. 2/ Block propagation Block propagation is crucial to miners. They are willing to do anything to reduce block propagation delay, otherwise they will be "punished" by higher orphan rate. An extremely long block propagation delay actually prohibits the distributed consensus mechanism of Bitcoin. Obviously, a bigger block takes longer time to propagate. There are some techniques (compact block/IBLT/etc) trying to overcome this problem, but difficult corner cases also exist. 3/ UTXO set The UTXO set (stored in chainstate directory) is intensively accessed by the full node, which makes a significant I/O performance bottleneck. This issue is usually resolved by caching the UTXO set in RAM, otherwise validating a single block would take an insane period(several minutes). Maybe future technologies like NVMe SSDs will resolve this, but a bigger UTXO set still results in slower validation performance in general. 4/ Miner revenue and network security Small blocks are expected to drive the on-chain tx fees up, which seems awful to some users, but, this will compensate the halvened block reward, incentivising the miners to maintain a secure hashrate. Off-chain solutions like Lightning Network will take care of "low value" coffee transactions. The main Bitcoin blockchain is both costly and set-in-stone secure.

Commented by /u/KiFastCallEntry in /r/Bitcoin on October 5, 2018 02:07:07

The developer had already started working on 0.17 support several months ago:

Commented by /u/KiFastCallEntry in /r/Bitcoin on October 4, 2018 09:41:12

Such "sudden jump" happens daily, it actually means nothing. Please, read the description below that chart carefully: > The number of payments is grouped by calendar day (UTC). This site is much better in my opinion:

Commented by /u/KiFastCallEntry in /r/Bitcoin on October 4, 2018 09:32:54

There's no sudden jump at all. > The number of payments is grouped by calendar day (UTC).

Commented by /u/KiFastCallEntry in /r/Bitcoin on October 4, 2018 05:49:26

LN is still in beta & it still has tons of problems. Andreas Brekken's giant hub affect the whole network so significantly, which is not a good sign in my opinion: I'm still waiting for AMP/watchtowers/dual funded channels/splicing etc to play out.

Commented by /u/KiFastCallEntry in /r/Bitcoin on July 21, 2018 23:01:58

AFAIK, dual funded channels are not available till now. So, I suppose that both channels you opened with ACINQ is funded by yourself, not ACINQ, which means that your LND node don't have enough inbound liquidity to receive the payment.

Commented by /u/KiFastCallEntry in /r/Bitcoin on July 21, 2018 22:46:37

You may try this to accelerate the syncing progress: move the "chainstate" (as well as the "blocks/index" subdirectory, if you enabled txindex) directory to SSD, by creating a symbolic link (or "NTFS junction" for Windows).

Commented by /u/KiFastCallEntry in /r/Bitcoin on July 21, 2018 22:33:57

Maybe not. Most nodes discard transactions paying a fee lower than 1 sat/B, so you may fail to broadcast the tx. Even if the tx is successfully broadcasted, it's still unlikely to be accepted by miners.

Commented by /u/KiFastCallEntry in /r/Bitcoin on July 15, 2018 11:07:58

So... does the fee market still exist for now?

Commented by /u/KiFastCallEntry in /r/Bitcoin on July 15, 2018 10:58:04

1/ "SegWit can't scale" SegWit will never raise the block size limit significantly(current avg. block size is about 1.1MB, even if SW is 100% adopted, the block size is still limited to lower than 4MB). Schnorr may help save some bytes, but the overall on-chain TPS performance still sucks. 2/ "SegWit can't decrease fees" Yes, it can, slightly. Currently, the market is much more calmed down, so the demand for block space is greatly relieved - but this situation may not last forever. As for LN, AFAIK, LN is only for micropayments. BTW, don't forget the full-block fee market policy and the "champagne". 3/ "SegWit is anyone-can-spend" No, it's not. But, how could we upgrade the protocol without miner's cooperation? UASF is very controversial.

Commented by /u/KiFastCallEntry in /r/Bitcoin on July 15, 2018 10:45:41

1/ Native SegWit address starts with "bc1", including two types: native P2WPKH and P2WSH. P2WSH could be used for multisig wallets, just like P2SH. 2/ P2SH address starts with "3", it might be a "encapsulated" SegWit address (P2SH-P2WPKH or P2SH-P2WSH), or not (eg. traditional multisig). In other word, a P2SH-SegWit address is not distinguishable with traditional P2SH-multisig addresses, until it's spent. 3/ You can check the input script with block explorers like BitFlyer's ChainFlyer, spending bitcoins stored in any SegWit address would have a "Witness" field.

Commented by /u/KiFastCallEntry in /r/Bitcoin on June 24, 2018 00:44:39

Commented by /u/KiFastCallEntry in /r/Bitcoin on June 16, 2018 07:32:26
/r/Bitcoin/comments/8ptvp9/miscalculated_negative_transaction_fee_by_forklol/e0e08kv/ block explorer has the same issue, it shows that Transaction Fees = -6.25 BTC. LOL.

Commented by /u/KiFastCallEntry in /r/Bitcoin on June 9, 2018 12:43:15

I'm curious about dual funded channels - when will this feature be available?

Commented by /u/KiFastCallEntry in /r/Bitcoin on May 30, 2018 15:00:32

Nothing fresh. Chinese govt is always positive on "blockchain tech", not Bitcoin. For example, OKEx has been semi-GFWed right now(by the method of URL filtering/TCP reset, therefore OKEx is still accessible via HTTPS). It' reported that they were trying to ban OTC exchanges, OKEx is one of most popular OTC exchanges. Fortunately, the bitcoin P2P protocol per se has not been GFWed yet.

Commented by /u/KiFastCallEntry in /r/Bitcoin on February 27, 2018 11:48:31

Hmm...Electrum has implemented this feature, but they found that their implementation is not compatible with other wallet:

Commented by /u/KiFastCallEntry in /r/Bitcoin on February 26, 2018 11:01:58

Is message sign/verify feature available?

Commented by /u/KiFastCallEntry in /r/Bitcoin on February 26, 2018 09:25:06

Of course, yes, it is a scam.

Commented by /u/KiFastCallEntry in /r/Bitcoin on February 26, 2018 09:22:14

So... How about using GDAX instead of Coinbase? GDAX provides free and fast withdrawal. It's just another product powered by Coinbase:

Commented by /u/KiFastCallEntry in /r/Bitcoin on January 14, 2018 01:59:42

Commented by /u/KiFastCallEntry in /r/Bitcoin on January 10, 2018 00:00:41

"Each byte of the witness part of a segregated witness (segwit) transaction will only count as 0.25 bytes towards the size of the transaction. Since transaction fees are based on the size of a transaction, this is effectively a 75% discount on fees for that part of a transaction—but only for people who use segwit."

Commented by /u/KiFastCallEntry in /r/Bitcoin on January 9, 2018 00:12:55

I've tried LN on testnet with Eclair. To be honest, I don't think LN is ready for production for now. The Eclair LN node attempted to map the entire network's topology - so, what if the network becomes much more complex in the future? There are only less than 2000 channels on the testnet till now, and Eclair took minutes to sync. BTW, my payment to sometimes fail. Fortunately, I didn' see any fund loss.

Commented by /u/KiFastCallEntry in /r/Bitcoin on January 8, 2018 19:19:58

The "dusts" are usually stored in P2PKH addresses. Will Schnorr sigs bring them back to life, too?

Commented by /u/KiFastCallEntry in /r/Bitcoin on January 8, 2018 09:19:43

It seems that rising tx fees will turn some UTXOs "unspendable dust". Is it possible to solve this problem?

Commented by /u/KiFastCallEntry in /r/Bitcoin on January 8, 2018 09:01:08

1/ The "solution" is port forwarding, which requires a server which have a public IP address to forward traffic for the user. In other word, it just bypassed the problem, not solving it. 2/ I've done some searching, and I learned that LN is supposed to have some small hubs connecting a lot of users. But, I wonder if there is anything preventing these small hubs growing up to giants. 3/ It's clear that anyone won't be forced to open channel with someone. Even using LN per se is not compulsory. But, the onchain tx fee rate is high currently. BTW, users usually want stable/supported services. Some big blockers then concluded that only "professional LN hub operators" may meet that demand, which may finally give birth to "super LN hub", after that, the govt may have excuse to censor them. According to such assumption, users who reject govt censorship must overcome problems like high onchain tx fees or lack of merchant support.

Commented by /u/KiFastCallEntry in /r/Bitcoin on January 7, 2018 22:47:44

But, how could Bitcoin scale without LN (or with a centralized/censored LN)? I know technologies like Schnorr may save up more space on the blockchain, but these tech doesn't seem to scale significantly. There are many people like me expecting LN to scale Bitcoin exponentially.

Commented by /u/KiFastCallEntry in /r/Bitcoin on January 7, 2018 22:28:03

AFAIK, SegWit addresses (P2SH-P2WPKH) is already available if you are using latest version of Electrum:

Commented by /u/KiFastCallEntry in /r/Bitcoin on December 22, 2017 09:48:38