一个基于BCH的付费电驴下载的设想

[RicardoMLu]

作者新浪微博：中本蒜-袁维

感觉不比ipfs和joystream差
​​​刚刚吃饭，想到了一个付费下载的解决方案，可以把电驴和BCH结合在一起。

虽然目前有ipfs和joystream，但是前者似乎也没解决好这个问题；而后者只有加速时才需要付费，其实对上传者依然不够友好，而且多个bt种子做种时，电脑压力还是挺大的，使用电驴就好多了。

而电驴的主要问题在于上传者（不仅仅是发布者）的利益往往得不到保证，无法根据上传量精准计价收费，这其实是bt和电驴都存在的一个现象，所以只要解决好这个问题，去中心化下载最头疼的“无人做种/上传”就彻底解决了。


我想到的方案，说白了就是“文件切片，然后加密，然后下多少付多少费，然后给密码逐个解密，然后合并还原成文件”，具体方法如下：

1、分享者A将文件X​拖拽至电驴，即可开始共享（这就是电驴的好处，比bt要方便很多，缺点就是以文件为单位，而不能以文件夹为单位，bt则可以以文件夹为单位）；

2、下载者B搜索文件名，找到X（DHT可以解决搜索的问题），开始下载，假设文件X为1000MB大小；​

3、​A的电驴客户端按照每M（也可以是每10M）为一个标准单位，即时将X分解为1000个文件包，并且分别用不同的密码进行加密，并且记下密码的序号，并记下B传输过来的B的BCH地址；

4、CDE如果也拥有X的话​，可以按照步骤3做同样的事情，也就是说，B可以从A处下载第1,2,3,10,234,365,965号文件包，也可以从C处下载4,5,6,11,78,103号文件包，从D.....以此类推。每一个文件包都被上传者加了独一无二的密，同时用下载者的BCH地址做了标记；

5、当B下载完成后，开始付费用，比如从A处下载了238个包，则按照一开始A设定的1M的单价，支付238份的价格给A，同时在op_return里注明这238个文件包的序列号；​

6、A收到费用后，按照op_return里注明的文件包序列号，通过电驴客户端，将这238个文件包的238个独立密码全部发送给B，B将238个文件包解密。以此类推分别付费给CDE。最终1000个文件包全部解密，然后组合成文件X，下载完成。​

​
在这个过程里：

1、​每一个上传者都根据自己的上传量，收到了上传费用；

2、费用是一次性支付，可以大大降低手续费；​

3、下载完成后，B不支付​费用，就无法解密，下了也白下；

4、B可以向CDE要求提供​A处下载的1,2,3,10,234,365,965号文件包的hash值，相互验证文件包的正确性，避免有人传输错误的文件包。

5、所有的双方的交易信息，都记录在他们对应的BCH地址，作为信用记录。

6、如果以BCH地址为电驴账户名的话，其实都可以不需要op_return写那些文件包序号，直接用电驴客户端索取即可，因为每一个文件包都被上传者加了独一无二的密，同时用下载者的BCH地址做了标记，所以不会和其他下载者弄混。每一笔账都对得起来。


我想了想，好像没什么问题，似乎可行。​​​​

[1714781073]

1714781073

[1714781073]

1714781073

[1714781073]

1714781073

[1714781073]

1714781073

[sos1311]

想法很不错呢，可以跟BCH团队再沟通沟通去，完善下

[hunanay]

这个不错，有创意。

[nazinan0]

那么楼主什么时候写白皮书，ICO搞起来？？

[tom2236497]

作者新浪微博：中本蒜-袁维

感觉不比ipfs和joystream差
​​​刚刚吃饭，想到了一个付费下载的解决方案，可以把电驴和BCH结合在一起。

虽然目前有ipfs和joystream，但是前者似乎也没解决好这个问题；而后者只有加速时才需要付费，其实对上传者依然不够友好，而且多个bt种子做种时，电脑压力还是挺大的，使用电驴就好多了。

而电驴的主要问题在于上传者（不仅仅是发布者）的利益往往得不到保证，无法根据上传量精准计价收费，这其实是bt和电驴都存在的一个现象，所以只要解决好这个问题，去中心化下载最头疼的“无人做种/上传”就彻底解决了。


我想到的方案，说白了就是“文件切片，然后加密，然后下多少付多少费，然后给密码逐个解密，然后合并还原成文件”，具体方法如下：

1、分享者A将文件X​拖拽至电驴，即可开始共享（这就是电驴的好处，比bt要方便很多，缺点就是以文件为单位，而不能以文件夹为单位，bt则可以以文件夹为单位）；

2、下载者B搜索文件名，找到X（DHT可以解决搜索的问题），开始下载，假设文件X为1000MB大小；​

3、​A的电驴客户端按照每M（也可以是每10M）为一个标准单位，即时将X分解为1000个文件包，并且分别用不同的密码进行加密，并且记下密码的序号，并记下B传输过来的B的BCH地址；

4、CDE如果也拥有X的话​，可以按照步骤3做同样的事情，也就是说，B可以从A处下载第1,2,3,10,234,365,965号文件包，也可以从C处下载4,5,6,11,78,103号文件包，从D.....以此类推。每一个文件包都被上传者加了独一无二的密，同时用下载者的BCH地址做了标记；

5、当B下载完成后，开始付费用，比如从A处下载了238个包，则按照一开始A设定的1M的单价，支付238份的价格给A，同时在op_return里注明这238个文件包的序列号；​

6、A收到费用后，按照op_return里注明的文件包序列号，通过电驴客户端，将这238个文件包的238个独立密码全部发送给B，B将238个文件包解密。以此类推分别付费给CDE。最终1000个文件包全部解密，然后组合成文件X，下载完成。​

​
在这个过程里：

1、​每一个上传者都根据自己的上传量，收到了上传费用；

2、费用是一次性支付，可以大大降低手续费；​

3、下载完成后，B不支付​费用，就无法解密，下了也白下；

4、B可以向CDE要求提供​A处下载的1,2,3,10,234,365,965号文件包的hash值，相互验证文件包的正确性，避免有人传输错误的文件包。

5、所有的双方的交易信息，都记录在他们对应的BCH地址，作为信用记录。

6、如果以BCH地址为电驴账户名的话，其实都可以不需要op_return写那些文件包序号，直接用电驴客户端索取即可，因为每一个文件包都被上传者加了独一无二的密，同时用下载者的BCH地址做了标记，所以不会和其他下载者弄混。每一笔账都对得起来。


我想了想，好像没什么问题，似乎可行。​​​​

为什么我看到电驴两个字就很激动呢。。。。老了啊

[ggugoienpai]

电驴，莫名的激动啊。想起了我年轻的时候。

[belladd]

我觉得付费的下载的话，其实在国外可能是挺流行的，但是在国内的话就不行了，国人已经习惯了享受那些免费的资源，你一下子要求付费的话，我觉得很难运转起来的。
当然你可以试一下，说不定也会成功呢。

[tudglien]

最吸引我的是电驴两个字，这个设想有前途，我做你的粉丝。

[realmud]

有想法，接下去就是实践，另外到时候还需要推广，电驴什么的都是靠免费打下的基础，这个感觉开始会比较困难，得找到切入点。

[ji23189455]

什么年代了，还电驴下载，bch这宣传。。。

[juirzhbv]

一个没有使用过电驴的青年不是好青年，一个没有电驴带你翱翔片场的互联网世界不会一个真正的自由世界。

[wuqing78]

这个跟人人影视的CVN可能有点像，http://cvn.network/

[anesthia8]

电驴，莫名的激动啊。想起了我年轻的时候。

这时代的电驴，真是有意思，挺一个。

[as453omg]

一个没有使用过电驴的青年不是好青年，一个没有电驴带你翱翔片场的互联网世界不会一个真正的自由世界。

哈哈哈哈，你这波宣传666啊，老铁

[lindatang]

不错，想法很好，之前国内有BTC浪费电和计算机资源的说法，不可否认确实存在。
但如果将加密币与现实资源利用起来，充分发挥大家的积极性，这样加密币就不仅仅停留在概念了。

[ZOOLOO]

这个想法我也有过，后面看到了IPFS，我才知道我想多了。是一种点到点的分布式文件系统，它连接的计算设备都拥有相同的文件管理模式。从某种意义上来说这个概念跟Web的最初理念很类似，但是实际上IPFS更像是互相转发Git目标的单个Bittorrent用户群。IPFS具备成为internet子系统的素质，通过合理配置可以完备甚至替代HTTP。

[waikey]

先把文件的合法性搞清楚吧，
如果是盗版无原创的就算了，网上BT, 磁力一大堆。。。

[richwanghai]

这个想法是好的
很多cdn挖矿也是有这个思路在里面的。

[seadahai001]

这个思路想想是可以的，但是不符合实际，说的不好听一点有点太老了。
现在可以获取资源的方式有很多，我为啥要用bch来支付，吃饱了撑的么。