北大肖臻老师《区块链技术与应用》系列课程学习笔记[8]BTC课堂问答

​

1.转账交易如果接收者不在线，怎么办？

  单纯的转账交易不需要接收者在线，转账交易只不过需要在区块链上记录一下，把A账户上的比特币转到B的账户上，与接收者是否连在比特币网络中无关。

2.假设某个全节点收到了转账交易，有没有可能转账交易中接收者的收款地址是这个全节点以前从未听说过的？

  这是有可能的。比特币系统中，账户创建的时候是不需要通知其他人的，只需要在本地产生一个公私钥对就可以了。只有在以后，该账户产生的收款地址收到钱的时候，其他节点才会知道该账户的存在。

3.如果账户的私钥丢失了，该怎么办？

  其实是没有办法的，账户上的钱就变成了死钱，是没有办法取出来的。比特币系统是去中心化的系统，是没有人可以帮你重置密码的。

  有些加密货币是有交易所的，交易所是一个中心化的机构，一般来说，在交易所注册账户时，需要提供身份证。这种情况下，将比特币保存在交易所里，私钥实际上是由交易所保管的。登录交易所跟登录银行账户的操作类似，一般需要用户名、口令和二次验证消息（如Google身份验证器生成的一次性密码），在这种情况下，如果登录口令丢失，可以联系交易所，通过身份验证后重置密码。

  上述这种丢失口令的情况跟比特币系统中丢失私钥的情况是很不一样的。比特币系统中虽然也存在一些能够帮忙保管私钥的应用，如比特币钱包等。但是，并不能说明这些应用保管私钥会比私人保存更安全。历史上发生过很多次加密货币的交易所被黑的情况，黑客从里面偷到了大量加密货币。其中最著名的是Mr. Gox的例子，这个曾经是世界上最大的比特币交易所，交易量达到了全球比特币交易量的70%，后来被 黑客攻击，丢失了大量的比特币，这个交易所后来破产了，其CEO被判刑。而且这种情况并非个例，各种加密货币交易所出现问题的情况发生过很多次，也有监守自盗的情况，有的工作人员、管理层人员卷款跑路的情况也都发生过。相比之下，有些冷钱包或者说硬件钱包是比较安全的。
  私钥丢失之后，那么这些比特币将会永远花不出去，但矿工并不知道这个账户的私钥已经丢失了，这些比特币是取不出来的，所以他需要永远把交易的输出保存在UTXO中，这个操作对全节点是不友好的。

4.如果私钥泄露了，怎么办？

  尽快把这个账户上的钱转到其他安全账户上。因为区块链是去中心化的，所以没有人能够充当“银行”的角色帮你冻结账户或者重置密码。账户创建的时候会在本地创建一对公私钥对，私钥就是这个时候产生的，公私钥对一旦生成无法修改。可以生成新账户，但是原账户的私钥无法修改，账户的持有者也没办法阻止他人发布从该账户转账的交易，任何有私钥的人都可以发布转账交易，把账户里的比特币转走。

问：用户持有者如何知道自己的私钥泄露了，是否看见从该账户上转出的非本人发起的交易才能知道？

5.如果转账时写错了地址，该怎么办？

  转账时，本来需要把比特币转给A，结果写错了A的地址，错将比特币转入了B的账户。这时我们是没有办法取消已经发布的交易的，比特币系统中一旦交易发布到区块上就没办法取消了，在比特币系统中没有提供一些能取消已经发布交易的机制。如果转账转到错误的地址，若知道地址归属于某账户（如B）的话，可以跟对方联系，看对方是否愿意把比特币还给你，但是这种情况也只能与对方商量，这个没有办法强迫。如果不知道转入地址归属哪个账户，或者转入地址是一个不存在的地址，就没有办法了。（这里个人感觉效果类似充话费的时候输错的电话号码）

  地址一般是该账户公钥取哈希值得到的，但是有些地址其实并不是取公钥的哈希得到的，如Digital Commitment。如果想要把某项内容发布在区块上，证明在某个时间知道某个事情，这里有一种比较经典的方法就是Proof of Burn，就是将需要发布的内容的哈希值存放在OP_RETURN后面。但是有的人不这么做，他用哈希值生成一个像是比特币地址的东西，来代替比特币的转账交易接收方的地址的内容。就比如说正常实现转账交易A→B，这里B表示账户公钥取哈希值得到的地址，但是如果用其他哈希值来代替接收方的地址的内容，比特币系统并不知道这个地址是真的还是假的，这样转账的比特币就成了死钱，是取不出来的。这种虽然也达到了牺牲一点比特币，往比特币中写入一点东西的效果，类似于Proof of Burn，但是这种做法是很不提倡的，因为这样的交易的输出将会永远被写在UTXO集合中，全节点收到这样的转账交易，并不能判断这个交易的地址是否为真，不知道这个转账交易是花不出去的，这个操作对全节点是不友好的。

  在Proof of Burn的情况下，OP_RETURN后的结果是无条件返回错误，不满足合法区块才会被写入区块中的条件，那么为什么还会用这种方式来向区块链中写入内容呢？验证的时候是将这个交易的输入脚本与前一个交易的输出脚本拼在一起运行，顺利执行就是合法交易。而在Proof of Burn的情况下OP_RETURN是写在输出脚本中的，所以验证这个交易合法性的时候并不会执行到OP_RETURN，也就不会返回错误。如果后面再有一笔交易想要花这笔交易里的钱的时候，才需要验证这个交易的输出脚本。所以判断交易是否合法，能否写入区块的时候，并不会执行到OP_RETURN部分。

6.比特币挖矿的实质是在找合适的Nonce，看看哪个Nonce符合难度要求。那么会不会有矿工“偷答案”，如，他自己没有找到合适的Nonce，其他矿工发布Nonce，他看到区块之后，查了一下这个Nonce是符合要求的，他就将这个作为自己找到的Nonce发布出去。如何辨别是哪个矿工最前找到的这个Nonce？

  发布的区块里面有个CoinBase Transaction，里面有个收款人地址，是挖到矿的矿工的地址。如果要“偷答案”，需要将收款人的地址改为自己的地址，那么这个CoinBase Transaction的内容将会发生改变，这样会导致Merkel Tree的根哈希值会发生变化。Nonce在块头中，根哈希值也在块头中，Block Header的值发生变化之后，原来找到的Nonce就作废了。

问：如果要是挖到矿的矿工与偷答案的矿工同属于一个矿场呢？

7.交易费可以看作是发布一个交易的时候给矿工的一点小费，那么如何知道这个交易费给哪个矿工，如何事先知道哪个矿工会挖到矿？

  事先不需要知道哪个矿工会挖到矿。交易费的计算是total inputs - total outputs，即总输入与总输出的差值，哪个矿工先挖到矿了不需要事先知道，挖到矿的矿工可以将区块中所包含交易发输入与输出的差额收集起来，作为他自己的交易费。

​