矿机设备托管协议_百度文库
赠送免券下载特权
10W篇文档免费专享
部分付费文档8折起
每天抽奖多种福利
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
矿机设备托管协议
&&比特币、数字货币、矿机托管协议
阅读已结束，下载本文需要
想免费下载本文？
定制HR最喜欢的简历
下载文档到电脑，同时保存到云知识，更方便管理
加入VIP
还剩3页未读，
定制HR最喜欢的简历
你可能喜欢《好看》依托百度技术，精准推荐优质短视频内容，懂你所好，量身打造最适合你的短视频客户端！比特币挖矿机开发之路（一）
- Go语言中文网 - Golang中文社区
<meta name="author" content="polaris ">
比特币挖矿机开发之路（一）
· 3848 次点击 ·
开始浏览 & &
开发分为两个部分，part A：LSP(Live Sequence Protocol)的开发 ， part B：Distributed Bitcoin Miner
文档位置：https://github.com/modiziri/p1
【首先要说一下低级网络协议，之所以称之为低级是因为这种IP只能提供不可靠的数据传递服务，也就是说，这种简单的数据传输很容易导致延迟，丢包和重复。而且，还有最大字节的限制。不过，值得庆幸的是，低于1500字节的传输还是相对很安全的，不过要是超过，那就很容易发生上面的问题了。
几乎没有应用程序会直接用IP来传输数据，相应的，他们会用UDP和TCP代替。
UDP：也就是USER DATAGRAM PROTOCOL，用户数据包协议。这同样也是不可靠的数据服务，不过允许数据包在同一台电脑的不同终端通过端口传输。也就是说，一台电脑就可以运行多个客户端或者服务端了，这项技术叫做多路发讯。
TCP：也就是Transmission Control Protocol，传输控制协议。不同于UDP，这项protocol提供的是可靠的有序的流服务。实现方式是，固定长度的一段流数据被分散到不同的数据包传输，到了终端之后再重新组合。TCP会处理好丢包和重包而且阻止sender在发包时覆盖掉一些数据（多数是后包覆盖前包），both in 带宽和缓冲区终端。
不过我们这次要做的是ＬＳＰ（Live Sequence Protocol），与上面两者既有相同又有不同。
特色：不同于UDP和TCP，LSP是有客户-终端交流模板的，可以省下许多工程量
而且这项服务是连接一堆客户端的（这里终于可以看出挖矿机的苗头了），而且给每个客户端都有一个专属的连接ID。
每个方向的客户端与服务端连接都是靠一序列的离散（不连续的）数据，也就是说，很难甚至无法破译。
数据大小被限制在了类似UDP数据包的大小，大概1000字节左右。
数据传输绝对可靠，每个信息都只能被接受一次并且一定要按照发送的顺序。
客户端和服务器是有连接监控的，如果其中一方断线了会被马上发现。（再次加上安全度）
LSP传输数据：一般每次传输都会包含以下四个数据：
Message Type：只能是以下三种类型
Connect：客户端建立与服务器的连接
Data:由客户端或者服务器发送信息
Ack: 由客户端或者服务器建立去获取connect或者Data（小知识，人家建立了是放在公处你还没拿到，你要去ack人家才会给你的，跟github上的ADD 与commit关系很像）
Connection ID：一般为非零正数用来区分客户端-服务器的连接
Sequence Number：同一条连接在传输多个数据时需要用到递增的队列数字，用来区别顺序，0代表初始请求
Payload：负载，表示可以传输的上限，一般为一串字节，格式由应用软件决定。（可以自己决定要传多少）
以上的数据可以由下面的格式来发送：
（connect,0, 0）:连接请求，前面那个0是连接ID，后面那个0是队列号（建立连接一般两个都为0）
（Data,id, sn, D）：表示要传输数据，id是连接的ID，sn是队列号，D是payload负载。
（Ack,id, sn）: 获取数据或者连接，id，sn意思同上，若同时为0自然就是获取连接了。
下面我讲一步步的讲述整个连接的过程：
建立连接：在数据传输之前，连接必须被建立。连接通常都是由客户端给服务器发送请求的。作为回应，服务器会生成并且分配一个唯一的连接ID给这个新的连接，然后就把这个ID连同队列号0，负载nil（即0），打包发送给客户端作为接受信号。也就是简单的（connect，0,0）之后客户端给一个（ack，id，0）
这个连接ID是没有硬性要求的，而这个项目我们简单地把开始ID定为1.
发送接收信号：当连接被建立，信息就可以从两端相互发送了，正如前面说的，是散列的队列数据信息。假设所有信息都是合法的，这种情况下客户端和服务器都有自己的一套识别队列的序号，这样就能区分到底是谁给谁发信息了。这样有什么好处呢？首先，服务器和客户端互相发信号是异步的，极有可能你还在等待验证，你就要再发一个了，或者你还没接受完这个信号，下一个又来了。这种情况，同步的队列序号根本无法处理。另外，还有可能你先发的信号还没后发的信号快，也就是后来先至，这个时候要是没有序列你就乱套了。
跟TCP很像，LSP包含一个滑动窗口协议（sliding window protocol）。这个名词是直译的，有点别扭，到底是什么东西呢，其实就是一个类似于传输上限的东西。（个人认为这个名字起得糟透了。。。）形象地说，这个协议就是设立传输中的信号上限。因为我们知道，客户端与服务器的传输必须是一问一答，有来有往的。所以要是去了还没回来的信号肯定是还在路上，还没处理完或者出问题了（这种情况现在不作考虑）。那我们设立传输上限就可以最大程度让通信整整有条了，假设设立通讯上限a
= 1，那么第一个出去了，在还没收到回应之前第二个就不能出去，如果a = 2，那么出去两个信号，如果不回来回应，第三个就不能发送。
当然了，这种发送是要按照队列序号的，不可能序列是3的比序列是1的先处理，一定会按顺序来。也就是说一旦有一个信号（假设是n）卡住了，那么最大的传输限度就是n + a – 1.
那卡主了是不是就这样结束了呢？其实并不是，如果卡主了端口会自动隔一段时间再次发送，当然如果还是卡主了，还是会继续发送的，不过就只能继续卡了。。。这个滑动窗口协议是客户端和服务器都会用到的，很常见。
下面要讲的是一个突破性的优化：
队伍序列传输法虽然保证了传输的安全性，不会丢包不会重发。但是同时也有问题，要是发生了丢包或者其他故障，那么客户端，服务器或者两者同时就停止工作了——都在等那个丢的包。
要使LSP更加funtional and robust，我们就要用到下面的这个方法了。
我们首先给客户端和服务器都建立一个简单的时间触发器，这个定时器会定期开始工作，把时间切割成一个队列的时间点。这里我们姑且认为时间是有时间点和时间段组成的，设定时间点的个数为b, 我们默认为2000微秒，虽然这个量是会变化的。
一旦时间点开始数，那么客户端就会做下面的事情：
如果连接请求没有被服务器回应，那么就再发一次时间请求
如果连接请求被发送并且被回应，但是没有数据(data)被接收，那就发送队列0的回应（解释：如果服务器已经发出连接回应了还没有收到数据只有两个可能，一个是根本没有数据，这个当然没有问题，另外一个就是回应丢包了。这种情况下我们再次发送队列0，也就是connect的回应可以防止丢包终止程序了）
3，每个已经发出但是没有回应的数据信息都会再次发送。
4，如果卡主了，再次发送最后a（刚才定义的传输上限）个数据包的回应，注意，只发回应。
而服务器也会设立一个类似的一些关于连接的机制：
1，如果一直收不到客户端的数据，那就再把连接请求的回应再发一次。
2，每个发送的数据如果得不到回应就再把数据发一次。
3，如果卡主了，再次发送最后a（刚才定义的传输上限）个数据包的回应，只发回应。
刚才说时间触发器还不是很清楚，我们就举个例子好了。假如客户端想要发送第i个数据，但是回应文件丢包（这是服务器的问题）。同时，服务器也想发第j个数据，但是本身文件丢包，发不出去，跟上面不同，这也是服务器的问题。但是，这时的时间触发器时间点在客户端上，那么触发器就会发送第j - 1个包的回应，注意，这时触发器在客户端上，所以只能发送j而不是i的回应。这时服务器就能接到回应，同时客户端也会再次发送数据i的包。
如果这时时间触发器的点也在服务器的话，注意，前面也说过服务器跟客户端是异步的，所以两个触发器极有可能会发现同时的情况。也就是两边都出现问题但是两边同时解决（跟先后解决是有区别的，自己衡量一下），这时服务器的解决办法是，把i的回应再发一遍，然后重发j的数据包。仔细看看，其实两者都能解决问题，而且都在解决同一个问题。
而且上面的例子验证并且举出了一种会重包的情况，上面的同时解决其实就是一种重包错误。在大多情况下，队列序号在这里就能起作用了，每个端口都会有一个计数器来计算并且区分这次要进来的包的序列号，然后抛弃那些对不上号的。这里讲一个重复请求的例子，对于客户端来说，很有可能会重复发送连接请求的。这时，服务器必须跟踪主地址，记录每个连接请求的号码，然后抛弃所有的那些号码已经被建立连接的和主机被联合的。
之前就讲过时间点触发器，那么这个时间点是怎么定义的呢。一般我们都会这样设计，每个时间点都会最少有一个数据在传输中。还有一个重要特征，我们会追踪每个连接，在到最后时间点之前，从这头信息传递到那头（已经被那头接收，且不算回应）之后消耗的时间点（也就是无效时间点）。一旦这个花费超过了一个特殊的时间上限，这里定义为k，我们就会认定，连接已经丢失了。我们实施的时候默认k的值为5，所以，如果有一个已经建立后的端口在 k*b 的时间段里一直没有接收到东西，那么我们就可以认定这个连接已经丢失了。提示，这里的b在上文定义为时间点的时间间隔，默认为2000微秒。
（未完待续）
3848 次点击 &
被以下专栏收入，发现更多相似内容
请尽量让自己的回复能够对别人有帮助
支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
支持 @ 本站用户；支持表情（输入 : 提示），见
图片支持拖拽、截图粘贴等方式上传
记住登录状态
开发分为两个部分，part A：LSP(Live Sequence Protocol)的开发 ， part B：Distributed Bitcoin Miner
文档位置：https://github.com/modiziri/p1
【首先要说一下低级网络协议，之所以称之为低级是因为这种IP只能提供不可靠的数据传递服务，也就是说，这种简单的数据传输很容易导致延迟，丢包和重复。而且，还有最大字节的限制。不过，值得庆幸的是，低于1500字节的传输还是相对很安全的，不过要是超过，那就很容易发生上面的问题了。
几乎没有应用程序会直接用IP来传输数据，相应的，他们会用UDP和TCP代替。
UDP：也就是USER DATAGRAM PROTOCOL，用户数据包协议。这同样也是不可靠的数据服务，不过允许数据包在同一台电脑的不同终端通过端口传输。也就是说，一台电脑就可以运行多个客户端或者服务端了，这项技术叫做多路发讯。
TCP：也就是Transmission Control Protocol，传输控制协议。不同于UDP，这项protocol提供的是可靠的有序的流服务。实现方式是，固定长度的一段流数据被分散到不同的数据包传输，到了终端之后再重新组合。TCP会处理好丢包和重包而且阻止sender在发包时覆盖掉一些数据（多数是后包覆盖前包），both in 带宽和缓冲区终端。
不过我们这次要做的是ＬＳＰ（Live Sequence Protocol），与上面两者既有相同又有不同。
特色：不同于UDP和TCP，LSP是有客户-终端交流模板的，可以省下许多工程量
而且这项服务是连接一堆客户端的（这里终于可以看出挖矿机的苗头了），而且给每个客户端都有一个专属的连接ID。
每个方向的客户端与服务端连接都是靠一序列的离散（不连续的）数据，也就是说，很难甚至无法破译。
数据大小被限制在了类似UDP数据包的大小，大概1000字节左右。
数据传输绝对可靠，每个信息都只能被接受一次并且一定要按照发送的顺序。
客户端和服务器是有连接监控的，如果其中一方断线了会被马上发现。（再次加上安全度）
LSP传输数据：一般每次传输都会包含以下四个数据：
Message Type：只能是以下三种类型
Connect：客户端建立与服务器的连接
Data:由客户端或者服务器发送信息
Ack: 由客户端或者服务器建立去获取connect或者Data（小知识，人家建立了是放在公处你还没拿到，你要去ack人家才会给你的，跟github上的ADD 与commit关系很像）
Connection ID：一般为非零正数用来区分客户端-服务器的连接
Sequence Number：同一条连接在传输多个数据时需要用到递增的队列数字，用来区别顺序，0代表初始请求
Payload：负载，表示可以传输的上限，一般为一串字节，格式由应用软件决定。（可以自己决定要传多少）
以上的数据可以由下面的格式来发送：
（connect,0, 0）:连接请求，前面那个0是连接ID，后面那个0是队列号（建立连接一般两个都为0）
（Data,id, sn, D）：表示要传输数据，id是连接的ID，sn是队列号，D是payload负载。
（Ack,id, sn）: 获取数据或者连接，id，sn意思同上，若同时为0自然就是获取连接了。
下面我讲一步步的讲述整个连接的过程：
建立连接：在数据传输之前，连接必须被建立。连接通常都是由客户端给服务器发送请求的。作为回应，服务器会生成并且分配一个唯一的连接ID给这个新的连接，然后就把这个ID连同队列号0，负载nil（即0），打包发送给客户端作为接受信号。也就是简单的（connect，0,0）之后客户端给一个（ack，id，0）
这个连接ID是没有硬性要求的，而这个项目我们简单地把开始ID定为1.
发送接收信号：当连接被建立，信息就可以从两端相互发送了，正如前面说的，是散列的队列数据信息。假设所有信息都是合法的，这种情况下客户端和服务器都有自己的一套识别队列的序号，这样就能区分到底是谁给谁发信息了。这样有什么好处呢？首先，服务器和客户端互相发信号是异步的，极有可能你还在等待验证，你就要再发一个了，或者你还没接受完这个信号，下一个又来了。这种情况，同步的队列序号根本无法处理。另外，还有可能你先发的信号还没后发的信号快，也就是后来先至，这个时候要是没有序列你就乱套了。
跟TCP很像，LSP包含一个滑动窗口协议（sliding window protocol）。这个名词是直译的，有点别扭，到底是什么东西呢，其实就是一个类似于传输上限的东西。（个人认为这个名字起得糟透了。。。）形象地说，这个协议就是设立传输中的信号上限。因为我们知道，客户端与服务器的传输必须是一问一答，有来有往的。所以要是去了还没回来的信号肯定是还在路上，还没处理完或者出问题了（这种情况现在不作考虑）。那我们设立传输上限就可以最大程度让通信整整有条了，假设设立通讯上限a
= 1，那么第一个出去了，在还没收到回应之前第二个就不能出去，如果a = 2，那么出去两个信号，如果不回来回应，第三个就不能发送。
当然了，这种发送是要按照队列序号的，不可能序列是3的比序列是1的先处理，一定会按顺序来。也就是说一旦有一个信号（假设是n）卡住了，那么最大的传输限度就是n + a – 1.
那卡主了是不是就这样结束了呢？其实并不是，如果卡主了端口会自动隔一段时间再次发送，当然如果还是卡主了，还是会继续发送的，不过就只能继续卡了。。。这个滑动窗口协议是客户端和服务器都会用到的，很常见。
下面要讲的是一个突破性的优化：
队伍序列传输法虽然保证了传输的安全性，不会丢包不会重发。但是同时也有问题，要是发生了丢包或者其他故障，那么客户端，服务器或者两者同时就停止工作了——都在等那个丢的包。
要使LSP更加funtional and robust，我们就要用到下面的这个方法了。
我们首先给客户端和服务器都建立一个简单的时间触发器，这个定时器会定期开始工作，把时间切割成一个队列的时间点。这里我们姑且认为时间是有时间点和时间段组成的，设定时间点的个数为b, 我们默认为2000微秒，虽然这个量是会变化的。
一旦时间点开始数，那么客户端就会做下面的事情：
如果连接请求没有被服务器回应，那么就再发一次时间请求
如果连接请求被发送并且被回应，但是没有数据(data)被接收，那就发送队列0的回应（解释：如果服务器已经发出连接回应了还没有收到数据只有两个可能，一个是根本没有数据，这个当然没有问题，另外一个就是回应丢包了。这种情况下我们再次发送队列0，也就是connect的回应可以防止丢包终止程序了）
3，每个已经发出但是没有回应的数据信息都会再次发送。
4，如果卡主了，再次发送最后a（刚才定义的传输上限）个数据包的回应，注意，只发回应。
而服务器也会设立一个类似的一些关于连接的机制：
1，如果一直收不到客户端的数据，那就再把连接请求的回应再发一次。
2，每个发送的数据如果得不到回应就再把数据发一次。
3，如果卡主了，再次发送最后a（刚才定义的传输上限）个数据包的回应，只发回应。
刚才说时间触发器还不是很清楚，我们就举个例子好了。假如客户端想要发送第i个数据，但是回应文件丢包（这是服务器的问题）。同时，服务器也想发第j个数据，但是本身文件丢包，发不出去，跟上面不同，这也是服务器的问题。但是，这时的时间触发器时间点在客户端上，那么触发器就会发送第j - 1个包的回应，注意，这时触发器在客户端上，所以只能发送j而不是i的回应。这时服务器就能接到回应，同时客户端也会再次发送数据i的包。
如果这时时间触发器的点也在服务器的话，注意，前面也说过服务器跟客户端是异步的，所以两个触发器极有可能会发现同时的情况。也就是两边都出现问题但是两边同时解决（跟先后解决是有区别的，自己衡量一下），这时服务器的解决办法是，把i的回应再发一遍，然后重发j的数据包。仔细看看，其实两者都能解决问题，而且都在解决同一个问题。
而且上面的例子验证并且举出了一种会重包的情况，上面的同时解决其实就是一种重包错误。在大多情况下，队列序号在这里就能起作用了，每个端口都会有一个计数器来计算并且区分这次要进来的包的序列号，然后抛弃那些对不上号的。这里讲一个重复请求的例子，对于客户端来说，很有可能会重复发送连接请求的。这时，服务器必须跟踪主地址，记录每个连接请求的号码，然后抛弃所有的那些号码已经被建立连接的和主机被联合的。
之前就讲过时间点触发器，那么这个时间点是怎么定义的呢。一般我们都会这样设计，每个时间点都会最少有一个数据在传输中。还有一个重要特征，我们会追踪每个连接，在到最后时间点之前，从这头信息传递到那头（已经被那头接收，且不算回应）之后消耗的时间点（也就是无效时间点）。一旦这个花费超过了一个特殊的时间上限，这里定义为k，我们就会认定，连接已经丢失了。我们实施的时候默认k的值为5，所以，如果有一个已经建立后的端口在 k*b 的时间段里一直没有接收到东西，那么我们就可以认定这个连接已经丢失了。提示，这里的b在上文定义为时间点的时间间隔，默认为2000微秒。
（未完待续）
1198 人在线
&最高记录 2928
& studygolang.com Go语言中文网，中国 Golang 社区，致力于构建完善的 Golang 中文社区，Go语言爱好者的学习家园。
Powered by
&o&服务器由
赞助 &·&CDN 由
VERSION: V3.5.0&·&1.s&·&为了更好的体验，本站推荐使用 Chrome 或 Firefox 浏览器
登录和大家一起探讨吧
记住登录状态
还不是会员比特币充当底层协议 | 巴比特
比特币充当底层协议
从我们最喜欢的老牌网站到最新近的移动应用，我们日常使用的很多创新技术都要归功于其背后的技术性很强的协议们的存在。终端用户对于这些协议的了解程度，不需要比司机对汽车引擎的工作原理了解的更多。然而，政策制定者们为了推动免许可的分布式创新——也就是由很多独立的个人和创业公司所发起的创新——需要去理解这些协议的重要性。举个例子，超文本传输协议（HTTP）是用来让浏览器可以和网站服务器进行“对话”的——只要服务器实现了这个协议，它就能向任何一个浏览器提供创新的内容或者服务。HTTP本身是建立在许多其他较低层次的协议之上的，比如说DNS和TCP/IP协议。从历史上来看，协议要不是出自研究项目，要不就是出自个人或者小群体。在关于比特币的争论中，理解比特币有潜力成为一个可以开启许多新的创新的协议这一情况，是很重要的。
比特币的核心是一个根本性的创新：一个分布式的公共总账。从会计上来讲，总帐是一本你一旦做出编辑就不能再修改的书。如果你犯了个错，唯一的弥补方法就是在总账上再添加一笔用以撤销那个错误的交易。我们从会计欺诈中可以知道，当有人想出一些法子，使得他们可以不再总帐上做出记录的同时完成交易，或者在时候篡改总账记录（这也是为何不是真正的属于会计系统）。比特币的总账被叫做“区块链”，区块链有很多份的拷贝并且广泛的分布在世界各地，同时还联合了相当够分量的数学知识，以保证一笔交易一旦被收录到区块链中就没有办法被修改了。当今世界上还没有其他的被广泛使用的协议达到了这样的效果：通过比特币，任何人都可以作出一个声明（一笔交易）并把它记录在一本全世界每一个人都可以看到的且不可修改的总账里面。
为何这个很重要？因为事实证明，可以记录在比特币总账的交易，内置了很多的以脚本语言的形式表现出来的表达能力。这使得某些类型的合约可以建立在比特币之上，从存款到中介再一直到分布式的股票交易。比如说，有一个叫做“色彩币”的提议，它允许额外的数据被附着在比特币之上，并可以在之后的所有交易中都保持两者的关联。举个例子，当区块链成为一间公司的股票份额所有权的完全分布式的公共总账的时候，那些数据就可以代表那家公司的股票的份额（这可能用于取代仍然被大部分创业公司所使用的物理证明或者独立的托管服务）。因为脚本语言的存在，这本总账是事实上智能的，并且一旦股票份额以那种方式被呈现，构建自动化版本的衍生品合约也就变得可能。
这只是比特币作为一种协议可以在金融服务业开启的创新的一些例子。除此之外，比特币协议还有潜力可以以一种全球分布式的方式解决其他的问题，比如说如何分配和管理唯一的名字（参见）。随着各种机构开始考虑对比特币的监管，在对消费者的保护以及对（有组织的）犯罪的执法，和维护比特币协议成为一种根本性的创新推动者的潜力之间取得一个平衡，是非常重要的。
译者注：作者 Albert Wenger是（）USV的成员，USV曾投资了Coinbase等比特币相关项目。
部分评论：
：感谢Albert，我感觉主流对话中缺少这样的对比特币的展望。
：我昨天和一名经验丰富的互联网支付的高管聊了下，他热爱比特币的概念，但认为它将在美国被停止，但在世界上其他法律薄弱的地区，它将带来极大的影响。
：有意思，我还没有那样的想过比特币。但比特币不会因为它的总量有限，而使得这种创新只能被限制围绕在交易上吗？
（原文作者）：这的确是当前比特币协议的一个潜在的缺陷。我们将在实践中看到比特币可以非常精细的拆分的能力和速度上的增加，能否能否覆盖它的用途。
：一个比特币可以拆分成“聪”
（作者）：是的，人们已经指出了那个事实，但仅仅是那个事实并不能应付通缩的可能性（这反过来会带来囤货居奇和价格的剧烈波动——这和事实上观察到的结果没什么不一样）
（作者）：完全同意交易费最后能够维持挖矿的进行。
Guest：了不起的文章，让我们好好看看peercoin（PPC，点点币）和primecoin（XPM素数币）吧，它们是基于比特币代码的分支，而不是像色彩币那样的在比特币之上的创新。
Peercoin（PPC）相较于比特币来说，来说更加安全并且节能。它将很有可能成为一个市场份额的有力对手。它也用了和比特币一样的哈希算法，所以比特币的挖矿硬件可以轻易的转向去挖PPC，他们当然当着在财政上有意义的时候去做这个事。那一刻已经很近了。
Primecoin（XPM）可以发现可以卖给科学社区的大素数，所以矿工们的“工作”有着实际的价值，而不像比特币。
PPC和XPM这两种创新替代币，都是有一名叫做Sunny King的开发者创造的。这名（或者这一群）开发者是搅局者，并且我确信他们还有其他的创造更多基于比特币代码的创新替代币的想法。
这个故事的寓意：如果人们真的对发现和投资那些将改变世界并同时获得投资回报的创新科技，那么现在的最佳着眼点就是山寨币了。把你的所有鸡蛋都放到比特币这个篮子里是不明智的。
：你怎么看待Litecoin（LTC）?还有，对PPC和XPM的投资途径你有没有什么推荐。
Guest：首先我必须说，我不希望的所说的话被当作是投资建议。所有的这些举动都很有风险。我认为LTC相较于BTC只有一个优势：更快的确认。那也就是说，它拥有一个相对更大的社区在背后（比如那些买了它然后等待升值的人），所以它有可能会成功。但LTC使用了一个和BTC不同的哈希算法，所以比特币矿机——支持和保卫一种货币的硬件——不能用在LTC上面。我因此怀疑LTC的长期前景。
但比特币矿机可以轻松的转移到PPC上面，因为它们使用了相同的算法。这对于一个像比特币这样的开源项目来说是坏消息也是好消息——你使得竞争对手能轻松的进入你的市场。
你可以在多家交易所买到PPC和XPM，我认为BTC-E和Virures是当前声誉最好的
在强调一次，这不是投资建议。我也的确拥有一些PPC，所以如果你投资的话我可能会受益。不管你打算怎么做，花点时间了解哪个币更好，以及更好的原因，并且只在上面投资你能够损失的数量的钱。
：像Armory这样的项目，已经相当成熟地准备好要去做这件事了：
：Albert，文章帮助许多人补上了比特币知识的一块短板。感谢！
作者 Albert Wenger
翻译 He1l_Q
本文如有帮助，请考虑捐助：15X9AMhccjqqPRkhpgraoj7fgdqymW3iSC
欢迎转载，转载时请注明作者翻译者和出处，谢谢支持！
版权声明：
作者保留权利。文章为作者独立观点，不代表巴比特立场。
您需要登录后才可以回复
资助 0.1BTC
87eb3b62da4ac007cfadefb477df16ff8be828b642ac5e7d0fbf4
亲，喜欢你的微博 ，咱相互关注下吧[互粉]，以后多多交流。[v5][可爱]
回复@小谷optima:不在武汉了
@长铗 你现在还在武汉吗？周末去武汉，有空能拜会一下你吗，我也是比特币爱好者。
回复@磁暴天尊特斯拉:我投了啊，但没被发表呢。
之前说“智能资产”遭遇各种怀疑，其实换成叫“智能总账”也许就好理解很多。所谓智能资产也只是这一“智能总账”所能承载的形式之一。//@暴走恭亲王: 转发微博
问一下，你现在真的完全不写科幻了吗。。。当年好喜欢你的小说[泪]。。。还是因为《若马凯还活着》才看nfl的。。。
你好，请问一下MyBitfund这个网站
里面的基金真的是你们运作？
回复@荷兰姑娘:嗯，最近的确有病
了不起的文章，了不起的评论！充当互联网货币底层协议的比特币
终端用户对于这些协议的了解程度，不需要比司机对汽车引擎的工作原理了解的更多。比特币协议还有潜力可以以一种全球分布式的方式解决其他的问题。}