go version go1.18.9 linux/amd64
go.sum 里面有写 1.20 哈，你试试 1.19 或者 1.20 吧
能再介绍下tuna的原理么，比如alice和bob通信，他们通过中间节点转发。具体流程是不是alice把信息发送给自己的tuna节点服务器，然后tuna节点发送给中间节点，中间节点采用类似whisper的群发机制给其它节点发送信息，但只有bob的tuna节点会接受。大概流程是这样的吗
其实没有这么复杂。就是 bob 通过 tuna 找到几个愿意提供反向代理服务的节点，然后让 alice 使用那些反向代理和 bob 通讯，然后再用我们的 ncp 协议将几个连接合并成一个来加速，并且在两端使用端到端加密来保证通讯内容的私密。
主要是这些中间节点怎么知道bob或alice的NKN地址对应的IP呢，这里又没有chord dht来计算。是不是alice或bob上线会注册自己到这些节点
Tuna 的服务节点会用 subscribe 功能把自己的 IP、价格、提供的服务等信息发送到链上，这样 bob 就可以获取到并自行选择。具体的实现在这个仓库：https://github.com/nknorg/tuna
分析了下源码，发现dial函数内部会调用getPubAddrsFromRemote来获取指定NKN地址的IP，那么这样就有两个问题：一是alice和bob是如何协商利用哪个tuna server作为中间节点的；二是知道对方IP了是不是直连最快，除非对方是内网地址。
这个完全是 bob 决定的，他可以根据自己的测速结果，地理位置，偏好等自行决定。
Alice会根据getPubAddrsFromRemote来获取跟bob交流的wbsocket地址（我看代码使发送getPubAddr），是不是意味着bob决定了中间节点后，会向自己连接的全节点注册信息。
并没有这个步骤
你好，我想问一下，关于运行挖矿软件中出现no shared key yet的解决方式
这个是由于节点和某些邻居的通讯出现了问题，一般来说是正常的，不用管它
如果他会自己修复，亦或者不影响性能的话，我也会不管，但是我发现他只要发生就会一直存在，且多个节点出现no share key的话，就会影响节点的性能，导致收入降低，想问一下能不能加入相关预防，或者修复的功能
出现这个错误导致通讯失败以后，节点还是会一直尝试和对方重连，所以错误会一直存在。影响节点性能和收入降低这个说法有什么依据么？这个错误只会影响和一个邻居的通讯，节点有上百个邻居，影响一般是可以忽略不计的。p2p 通讯失败在网络情况高度动态和不可控的 p2p 网络里是比较常见的，成因也很复杂。如果能发现因为实现导致的问题，那我们一定是会修复的。
此外，我们的讨论和这个帖子是不相关的，建议后续单独开一个帖子，而不是在这里继续回复，这样对后续的信息索引比较友好。
有的，可能单单挖看不出来，但是加入比如npool的矿池后，就可以发现只要这个错误一出现收益就会下降，然后再我重新删除所有，在重安装后才会回复正常，直至下一次错误为止，我不开另一贴有可能是我发的贴都没有人吧，我尝试过发邮件，或者论坛发帖，都没有人回复，这个问题是一个星期前出现的，如果不是我主动在这个贴里面找到活人，估计问题还得在等几个月才能得到回答
能设置一个如果长时间通不了，直接断掉吗？
因为 Chord DHT 的拓扑是基于 ID 的，断开链接并不会导致其他邻居的变化。结果上来说这个方法本质上和直接不显示日志差不多，只是不显示错误日志而已，不会有实际的好处。这个错误只是表象，网络层的问题一般需要查清楚是什么原因导致的双方通讯失败才能解决问题。
所以这是能解决的吗？不然每过个几天我就得重删重装，我记得也有其他人和我同样的错误
目前提供的信息看不太出来是什么问题，如果有能稳定复现的方法，可以给我们提供相应的信息，包括复现的方法，nknd 的版本号或者 commit hash，在什么 VPS 上运行的，VPS 以及机器的防火墙设置等等，我们可以去尝试复现一下来 debug
如果可以的话，我也希望能给你们提供稳定复现的方法，很遗憾的是，我也做不到，毕竟每次重启就会好一段时间，亦或者好很久一段时间，这个现象不是一定会发生，不过我节点比别人相对多了一点才会显得严重，就目前而言，ubuntu20和centos7都是会发生的，其他系统没有测试过，你们那边的人员的节点都是好的吗？