← 主题目录全部档案 →

比特币还能做什么

支付之外的设想:托管、脚本、时间戳与域名系统。

按议题整理 · 中文阅读 · 28 条发言。英文及完整讨论可回到对应档案查看。

托管与多方签名

6 条
中本聪SN-1809软件本来就是设计来支持这类东西的。我本来打算发一篇托管(Escrow)方案的详细计划帖,但被 slashdot 报道之后就一…

这条发言承接前面的讨论,可通过下方入口查看完整上下文。

软件本来就是设计来支持这类东西的。我本来打算发一篇托管(Escrow)方案的详细计划帖,但被 slashdot 报道之后就一直没时间。

中本聪SN-1822可以写出一笔需要两把签名才能花掉的交易。你写一笔付款,要求收款人和发送人双方的签名才能花掉它。要放行托管,你把你的那一半签名…

可以写出一笔需要两把签名才能花掉的交易。你写一笔付款,要求收款人和发送人双方的签名才能花掉它。要放行托管,你把你的那一半签名给收款人;或者收款人把他签好的一半给你,把钱退回来。这个简单情形里没有中间人。制约手段就是拒绝放行——等于把钱烧掉。

中本聪SN-1825真的吗?你觉得人们会理解不了它的好处吗?(如果你的回应是争辩说它根本没有好处,我猜那反倒印证了人们理解不了它。)

这条发言承接前面的讨论,可通过下方入口查看完整上下文。

其他参与者原话jgarzik原帖 ↗

由于存在这种制约手段,它不太可能被用作托管机制

中本聪回应

真的吗?你觉得人们会理解不了它的好处吗?(如果你的回应是争辩说它根本没有好处,我猜那反倒印证了人们理解不了它。)

中本聪SN-2171下面是软件上可行的托管交易的一个概要。这没有实现,我近期多半也没时间实现,但让你知道什么是可能的。

下面是软件上可行的托管交易的一个概要。这没有实现,我近期多半也没时间实现,但让你知道什么是可能的。

基本托管:买方把一笔付款存入托管。卖方收到一笔钱在托管中的交易,但在买方解锁之前他不能花。买方可以在那之后的任何时间放款,也可以永远不放。这不允许买方把钱拿回去,但确实给了他一个选项:出于怨恨永远不放行,把钱烧掉。卖方则可以把钱退回给买方。

这个系统虽然不保证双方免于损失,但它把作弊的利润抽掉了。

如果卖方不发货,他就拿不到钱。买方的钱还是打了水漂,但至少卖方没有骗人的金钱动机。

买方无法靠不付款获益。他拿不回托管的钱。他不可能因资金不足而付不了款。卖方可以看到资金已锁定到自己的密钥上、不能发给别人。

当然,经济学家会说,一个欺诈卖方可以开始讨价还价,比如「你放款,我分你一半」,但到了那一步,信任荡然无存、怨气冲天,谈判不太可能发生。一个已经在违背诺言偷钱的骗子,凭什么会守约分你一半?我想对适度的金额,几乎所有人都会基于原则拒绝。

中本聪SN-2180你这么说,听起来像是钱会莫名其妙地丢掉、即便双方想合作也拿不回来。
其他参与者原话jgarzik原帖 ↗

去问问真实世界的商户,看他们愿不愿意告诉客户:你的钱有可能永远消失,任何一方都无法追回。

中本聪回应

你这么说,听起来像是钱会莫名其妙地丢掉、即便双方想合作也拿不回来。

你预先付款买东西时,钱同样拿不回来。消费者对此看起来习以为常。不会比那更糟。

任何一方永远都有把钱释放给对方的选项。

其他参与者原话nelisky原帖 ↗

但烧钱方案虽然极好地防止了经济上可行的欺诈,却对报复无能为力,而且一旦一方不诚实,实际上让所有人都受损。我绝不会背书它。

中本聪回应

那你也一定反对常见的预付款制度——那种制度里吃亏的是客户。

预付款:客户吃亏,骗子拿到钱。

简单托管:客户吃亏,但骗子也拿不到钱。

你们是在说预付款更好吗?因为至少骗子拿到了钱,至少有人得到了它?

想象有人偷了你的东西。你拿不回来,但如果可以——如果它有一个可远程触发的自毁开关——你会用吗?让窃贼知道你所有的东西都有自毁开关、偷了也没用(虽然你自己也照样失去它),这是好事吗?如果他们还回来,你可以重新激活。

想象金子被偷就变成铅。窃贼还回来,它又变回金子。

在我看来,问题可能还是在于以正确的方式呈现它。首先,在博弈论讨论的语境里别把「烧钱」说得那么直白。钱从来不会被真正烧掉。你永远保有随时放款的选项。

中本聪SN-2817尚未实现,但网络能支持要求两个签名的交易。它在这里有描述:

尚未实现,但网络能支持要求两个签名的交易。它在这里有描述:

http://bitcointalk.org/index.php?topic=750.0

它绝对比没有托管的直接支付更安全,但不如人工仲裁的托管好——前提是你足够信任那个人。

在这种托管里,骗子赢不了,但你仍然可能吃亏。它至少消除了骗你的利润动机。卖方得到保证:钱是留给他的;买方保留着杠杆:交易完成之前卖方尚未拿到钱。

脚本、时间锁与时间戳

5 条
中本聪SN-0757Bitcoin 的本性是:一旦 0.1 版发布,核心设计在其余生中就基本定型了。因此,我想把它设计成支持我能想到的每一种可能…

Bitcoin 的本性是:一旦 0.1 版发布,核心设计在其余生中就基本定型了。因此,我想把它设计成支持我能想到的每一种可能的交易类型。问题在于,每种东西无论用不用,都需要专门的支持代码和数据字段,而且每次只覆盖一种特例。特例会爆炸式增长。解决方案是脚本——它把问题泛化,交易双方可以把交易描述为一个由节点网络求值的谓词。节点只需要理解到"求值发送方的条件是否满足"这个程度。

脚本实际上就是一个谓词。它只是一个求值为真或假的等式。Predicate 是个又长又生僻的词,所以我管它叫 script。

收款方对脚本做模板匹配。目前,接收方只接受两种模板:直接付款和比特币地址。未来版本可以加入更多交易类型的模板,运行该版本或更高版本的节点就能接收它们。网络中所有版本的节点都能把任何新交易验证并处理进区块,哪怕它们不知道如何解读这些交易。

这个设计支持我在多年以前就设计好的、极其多样的可能交易类型。托管交易、担保契约、第三方仲裁、多方签名等。如果 Bitcoin 大规模流行起来,这些是我们将来想要探索的东西,但它们都必须在开端就设计好,以确保日后有可能实现。

我不相信 Bitcoin 的第二个兼容实现会是个好主意。这个设计有太多部分依赖所有节点以步进一致的方式得到完全相同的结果,第二个实现将是网络的威胁。MIT 许可与所有其他许可及商业用途兼容,故从许可的角度也没有重写的必要。

中本聪SN-2718Bitcoin 客户端目前只创建和识别匹配两种模板之一的交易。

Bitcoin 客户端目前只创建和识别匹配两种模板之一的交易。

那是一些快速测试,粗略检查交易是否符合标准交易所符合的某些总体指标。节点只会着手把这些交易加进自己的区块。

将来如果我们给现有的 2 类交易增加更多模板,我们能修改「不愿处理非标准交易」的测试来接受它们。

中本聪SN-3355我们不能安全地实现 OP_BLOCKNUMBER。一旦发生分叉重组,交易必须仍能进入更晚的区块。OP_BLOCKNUMBER…

我们不能安全地实现 OP_BLOCKNUMBER。一旦发生分叉重组,交易必须仍能进入更晚的区块。OP_BLOCKNUMBER 交易及其所有依赖交易会失效。这对后来持有这些币、但并未参与限时交易的人不公平。

nTimeLock 的方向正相反。它是一笔开放交易,在截止期限前能不断被新版本替换。它不能被记录到链上,直到锁定期满。期限到达时版本最高的那笔会被记录。举例来说,它能用来写一笔托管交易,自动永久锁定并完成——除非在期限前被撤销。这个特性尚未启用或使用,但支持代码已在,之后能实现。

中本聪SN-3801新的交易模板能按需添加。几天之内就会有大量 GPU 算力接受并处理它。网络支持会远远早于「出现足够多懂得接收和解释新交易的客…

新的交易模板能按需添加。几天之内就会有大量 GPU 算力接受并处理它。网络支持会远远早于「出现足够多懂得接收和解释新交易的客户端」而就绪。

时间戳哈希现在已经可行:

txin: 0.01

txout: 0.00 OP_CHECKSIG

fee: 0.01

如果真有像 BitDNS 这样的应用准备开始插入哈希,我们随时能为时间戳加一个专门的交易模板。

我喜欢 Hal Finney 那个用户友好的时间戳构想。把文件的哈希转换成一个比特币地址,从而向它发送 0.01:

其他参与者原话Hal原帖 ↗

我想到了一个简单办法来实现上面说的时间戳概念。对想加时间戳的文件跑 sha1sum。把结果转换成一个比特币地址,比如通过 http://blockexplorer.com/q/hashtoaddress。从而向那个地址发一笔小额支付。

这笔钱将永远丢失,因没有办法再花出去,但这个时间戳比特币地址会留在区块链里,作为该文件存在过的记录。

我明白这算不算对比特币分布式数据库的正当用法尚有争议,但没有什么能阻止人们这么做,因此我们应该意识到这可能会发生。

中本聪SN-3803当我意识到新交易类型能多快被添加进来时,我也转而同意 Gavin 的白名单主张了。

当我意识到新交易类型能多快被添加进来时,我也转而同意 Gavin 的白名单主张了。

其他参与者原话nanotube原帖 ↗

为什么不让大家省点事,直接允许交易里携带比如 64 或 128 字节的随机数据呢?

中本聪回应

这已经可行了。 OP_CHECKSIG。 能是 33 到 120 字节。

我也支持增加第三种交易类型,承载时间戳哈希大小的任意数据。反正现在已经能做到,不提供反而不合理。它还可以告诉节点:不必费心为它建索引。

域名系统与合并挖矿

6 条
中本聪SN-3577我认为 BitDNS 完全能是一个独立的网络、独立的区块链,同时与比特币共享 CPU 算力。唯一的重叠是让矿工能同时为两个网…

我认为 BitDNS 完全能是一个独立的网络、独立的区块链,同时与比特币共享 CPU 算力。唯一的重叠是让矿工能同时为两个网络寻找工作证明。

两个网络之间不需要任何协调。矿工能并行订阅两个网络。他们扫描 SHA,如果命中,就可能同时解出两个网络的解。如果其中一个网络难度较低,解可能只属于其中一个网络。

我想外部矿工程序能同时对两个程序调用 getwork 并合并工作。也许先调用 Bitcoin,从它那里拿到工作,再交给 BitDNS 的 getwork 合并成一份合并工作。

网络之间不是彼此碎片化,而是共享并增强彼此的总 CPU 算力。这就解决了另一个问题:如果存在多个网络,而可用的 CPU 算力集中围攻其中一个,网络之间就会互为威胁。相反,世界上所有网络共享合并的 CPU 算力,总强度反而增加。小网络也能借助现成的矿工基础更容易起步。

中本聪SN-3584激励在于:同样一份工作,还能从额外的侧链拿到报酬。
其他参与者原话nanotube原帖 ↗

这样矿工基本上就得多干「额外的活」。如果从 bitdns 挖矿的额外工作里得不到回报(这当然会拖慢主比特币的工作),矿工有什么动力把 bitdns(以及其他任何侧链)纳入进来呢?

中本聪回应

激励在于:同样一份工作,还能从额外的侧链拿到报酬。

既然你本来就在挖比特币,为什么不让同一份工作量证明顺便获得免费域名呢?

如果你现在每周能生成 50 BTC,那么现在你还能同时得到 50 BTC 和一些域名。

你手里有一份工作。解出它,就同时解出 Bitcoin 和 BitDNS 各一个区块。概念上,它们通过一棵默克尔树绑在一起。要提交给 Bitcoin,就把 BitDNS 分支掰掉;要提交给 BitDNS,就把 Bitcoin 分支掰掉。

实践中,要为 Bitcoin 做兼容改造,BitDNS 侧大概要多占约 200 个额外字节,但这不算什么。你一直在说每个区块 50 个域名,相比下为了向后兼容每区块多出的这 200 字节根本不值一提。如果我们足够在意省这几个字节,将来还可以安排一个遥远的区块高度,让比特币升级到顶部带默克尔树的现代化结构。

注意,各条链都在这棵新默克尔树下。也就是说,Bitcoin 和 BitDNS 各自在自己的区块内部拥有自己的链环。这与常见的时间戳服务器结构正好相反——常见结构是链条在上、默克尔树在下,因那样会形成一条共同的主链。而这是两个不共享链的时间戳服务器。

中本聪SN-3601把世界上所有的工作证明共识系统都堆进一个数据集是不可扩展的。

把世界上所有的工作证明共识系统都堆进一个数据集是不可扩展的。

Bitcoin 和 BitDNS 能分开使用。用户并不应该为了用其中一个就得把两个的全部数据都下载下来。BitDNS 用户也不会想下载接下来好几个互不相干的网络决定塞进来的所有东西。

两个网络需要有各自独立的命运。BitDNS 用户恐对加入各种大数据特性相当宽松,因需要的域名注册商相对较少;而比特币用户可能会越来越强硬地限制链的体积,好让大量用户和小型设备用得轻松。

关于能否用比特币安全购买域名的担忧是个烟雾弹。用比特币交换其他不可抵赖的商品很容易。

如果你还在担心,密码学上能实现无风险交易。双方在两侧各设置交易,使得当双方都签名后,第二个签名者的签名会触发两笔交易同时释放。第二个签名者无法只释放一笔而不释放另一笔。

中本聪SN-3610对,域名和比特币之间的汇率会是浮动的。
其他参与者原话Hal原帖 ↗

额外的区块链各自创造自己风味的币,在交易所与比特币交易?这些链专属的币用来奖励那些链上的矿工,并在那条链的领域内购买某些权利或特权?

中本聪回应

对,域名和比特币之间的汇率会是浮动的。

对 BitDNS 来说,比 10 分钟更长的出块间隔更合适。

到目前为止这场讨论里已经需要不少管理数据了。如果你能自由使用所需的空间、不必为比特币链里的昂贵空间付手续费,事情会容易得多。有这么几种交易:

更改 IP 记录。

改名。一个域名对象能让你持有一个域名,并且能随意把它改成任何未被占用的名字。这会鼓励用户释放不再想要的域名。生成的域名起初是空白的,由矿工卖给某个人,由他改成自己想要的名字。

续期。能免费,或者要求消耗另一个域名对象来续期。在后者情况下,域名对象(域名币?)能代表持有一个域名一年的权利。花费掉的手续费作为下一区块的费用归矿工。

中本聪SN-3613我同意。所有交易——IP 更改、续期等等——都应该带一笔归矿工的手续费。

我同意。所有交易——IP 更改、续期等等——都应该带一笔归矿工的手续费。

你能考虑用一定量的工作来生成一个域名,而不是固定总量发行。每个域名的工作量能按随摩尔定律增长的计划表来安排。这样域名的数量会随需求和用户数的增长而增长。

中本聪SN-3620@dtvan:这 3 点都很到位。

@dtvan:这 3 点都很到位。

1) IP 记录不必进链,只做注册商功能,不做 DNS。顺带把 CA 问题也解决了,漂亮。

2) 选一个顶级域名,.web +1。

3) 过期机制加可观的续期费用,相当重要。

其他参与者原话joe原帖 ↗

不过现在多想了想,我支持在主网络中加入额外的 coinbase/记录系统。这么做的原因是避免 CPU 算力被稀释到多个网络。我们要的是一张强大的网络,因此网络应该是多能的。

中本聪回应

避免 CPU 算力碎片化已经不是理由了。独立的网络/链能在不共享其他东西的前提下共享算力。参见:http://bitcointalk.org/index.php?topic=1790.msg28696#msg28696http://bitcointalk.org/index.php?topic=1790.msg28715#msg28715

微支付与实际应用

11 条
中本聪SN-0034对移动设备而言,这确是个好思路。用 PHP(任何语言都可)调用的编程式 API,配一个 web UI,就能覆盖远程管理、移动…
其他参与者原话madhatter2原帖 ↗

前端还可以跑在手机这类 CPU 算力很低的设备上。

中本聪回应

对移动设备而言,这确是个好思路。用 PHP(任何语言都可)调用的编程式 API,配一个 web UI,就能覆盖远程管理、移动设备,以及一切无法全天在线、没有静态 IP 的客户端。这有点像 webmail。新用户只需在网站注册个账号、不必安装软件,上手就会容易许多。

引用 · 发言者未注明

应用可以在下载前预置种子。预置种子还能一并解决 TOR+IRC 的问题。我知道会有人想通过 I2P+TOR 运行这套系统。

中本聪回应

是啊,待静态节点多到可以预先编一份种子列表,就可以逐步停用 IRC。一旦有了种子,也就不再需要 IRC 了。

引用 · 发言者未注明

另外还可以预置区块,这样,首次运行就不用下载了。(在较慢的 ADSL 上下载 28,000 个区块要花很久,我不敢想象有几百万个区块时得等多久——一辈子。)

中本聪回应

0.1.5 里初始区块下载偶尔会卡住。0.2 加了代码以保证顺畅。我想应该用不了一小时。我得抓紧把 0.2 发出去。

区块是线性增长的,要过几十年,才会到几百万。理论上,区块下载时间会在 8 个月之后到顶,那时,摩尔定律的增速,将超过区块链的增速。

引用 · 发言者未注明

能否给我 CVS 权限什么的?(不行的话,我可以给你发补丁。)我想帮上忙。

中本聪回应

这里用的是 sourceforge 的 SVN。把你的 sourceforge 账号私信或邮件给我,我给你权限。

引用 · 发言者未注明

我主要是 Linux/BSD 背景,愿意在这些方面出力。

中本聪回应

那太好了,因为这些恰好是我不太在行的地方。比如,Linux 上"开机启动 Bitcoin"怎样实现为最好,我还没研究过。Windows 上这个选项,就是在"启动"文件夹里添加或删除一个图标。

中本聪SN-0348要是有一份静态 IP 列表供新用户发测试捐赠、看看软件怎么运作,就太好了。如果你能接受入站连接、又有静态 IP 地址,就贴在…

要是有一份静态 IP 列表供新用户发测试捐赠、看看软件怎么运作,就太好了。如果你能接受入站连接、又有静态 IP 地址,就贴在这里!

发到这些 IP 的任何金额都应视为捐赠。

如果你确实请求往返,务必在备注里附上你的回程比特币地址或 IP,但请默认它是单向的。对方不一定守着来账交易等你回寄。

中本聪SN-0439想把图片上传嵌入论坛帖子时,有 imageshack 之类的服务,但因为是免费的,它们限制查看次数。带宽成本微乎其微,但人家…

想把图片上传嵌入论坛帖子时,有 imageshack 之类的服务,但因为是免费的,它们限制查看次数。带宽成本微乎其微,但人家也不能白送,总得有点甜头。要是能付点钱买带宽、避开限制就好了,可对这么小的事,传统付款实在麻烦。

想上传文件供别人下载就更糟。有 rapidshare 之类的服务,但它们要求下载者多走额外步骤、忍受延迟,逼人看广告或升级付费订阅,还限制 10 次左右的下载。

如果我们写一套收费的免费 PHP 图片与文件托管服务代码,用比特币计费,那就好了。有点富余带宽额度的人都可以把它扔到自己的 web 服务器上运行。用户终于可以付点小钱覆盖带宽成本、避开限制和麻烦。理想情况下,它应该是 MIT 许可或公共领域。

这类服务对匿名用户会特别有用——他们付款本来就不容易。

中本聪SN-0441好主意。这类服务的生意很兴旺,但我一直觉得标准支付方式与注重隐私的顾客格格不入。

好主意。这类服务的生意很兴旺,但我一直觉得标准支付方式与注重隐私的顾客格格不入。

你愿意把软件免费放出来,让任何人都能轻松架一套吗?出于竞争考虑你多半想留着自己用,但如果任何人只要把软件装上服务器就能给自己国家开放代理,使用量也许能大一个数量级。

我在想,还有没有其他类型的 web 应用服务器,我们只需要往现成系统上附加一个支付机制?

中本聪SN-0444有实际运行代理服务经验的人在,很有帮助。你觉得 Psiphon 是目前最好的吗?(有时你运行的这个在你入行时是最好的,但后来…

这条发言承接前面的讨论,可通过下方入口查看完整上下文。

标题已改。

有实际运行代理服务经验的人在,很有帮助。你觉得 Psiphon 是目前最好的吗?(有时你运行的这个在你入行时是最好的,但后来你发现了更好的)

中本聪SN-0445Mihalism Multi Host 是一个流行的开源 PHP 文件托管服务器。

Mihalism Multi Host 是一个流行的开源 PHP 文件托管服务器。

它偏向图片托管,但我认为只要提高文件大小上限、放宽允许的扩展名,它同样可以轻松用作通用文件上传托管。他们需要这些限制来维持免费服务的合理运转,但如果我们装上比特币支付机制,限制就可以放宽。

它没有一堆需要扒掉的客户端脚本或防嵌入的破烂。它生成正常工作的标准链接。

这些免费托管站点的更新换代很频繁。小站可以提供免费图片托管,但一旦开始走红,就会被蹭免费带宽的揩油者淹没。任何出了名的网站都得变得更咄咄逼人地催缴费,以覆盖带宽成本。这是服务定价的完美案例:所需价位落在无人区——免费送就略贵,而对大多数用户来说又便宜到犯不上走传统付款的麻烦。它就卡在 0 和 19.95 之间的鸿沟里。他们最好的办法也许是争取 1000 个用户里有 1 个付 9.95,但那意味着 999/1000 的用户被当成蹭饭的。靠广告也撑不住,因为图片是嵌在别的网站上、根本不经过托管站就被下载的。

运行这套软件的网站示例:

http://www.imagez.ws/

论坛:

http://www.mihalism.net/

下载:

http://code.google.com/p/mihalismmh/

大家怎么看?如果我为它做一个比特币支付集成,会有人有兴趣运行它吗?它也许是第一个可以用比特币购买的全自动服务。相比免费服务,它的优势在于提供大文件的通用上传托管,而不必让下载用户跑到上传站点、百般周折。它会给出直指文件的普通链接。

中本聪SN-0712我觉得这是目前最好的办法。就像现金,你不会把全部身家揣在口袋里,只带点零花的钱应付日常开支。
其他参与者原话sirius-m原帖 ↗

在手机浏览器上当然可以用 vekja.net 或 mybitcoin.com 这类服务,把你信得过的额度的钱存进去。

中本聪回应

我觉得这是目前最好的办法。就像现金,你不会把全部身家揣在口袋里,只带点零花的钱应付日常开支。

他们可以做一个针对手机优化的缩小版网站。如果做应用,它可以作为这类服务的前端,主要功能是二维码扫描器;或者也许已经有通用的二维码扫描应用,网站可以设计成接受它们的扫描。

如果有一个 iPhone 应用,只是 vekja 或 mybitcoin 的前端,不涉及庞大的 P2P,苹果会批准吗?如果不批,依据是什么?反正也可以做 Android 应用。不过应用并非必需,一个手机尺寸的网站就够了。

给你家里的 Bitcoin 服务器做 Web 界面,并不是对每个人都可行的方案。大多数用户没有静态 IP,设置端口转发也太麻烦。

中本聪SN-0990Bitcoin 目前还不适用于非常小额的微支付。像按次搜索或按页浏览这种没有聚合机制的做不到,需要支付低于 0.01 的也做…
其他参与者原话Insti原帖 ↗

它弊大于利,因为它阻碍了 bytemaster 提议的那类小额支付实现。

中本聪回应

Bitcoin 目前还不适用于非常小额的微支付。像按次搜索或按页浏览这种没有聚合机制的做不到,需要支付低于 0.01 的也做不到。灰尘垃圾限额就是对故意阻止这类过小额微支付做的第一次尝试。

对于比现有支付方式更小的交易,Bitcoin 是实用的。小到足以涵盖你可以称之为微支付区间顶端的那部分。但它并不声称适用于任意小的微支付。

中本聪SN-0999一个替代方案是用凑整制。你一次为 1000 个页面、图片、下载或搜索之类付费。用完 1000 页,再买 1000 页。如果你…
其他参与者原话Quote from: bytemaster

付款一般是预付的,比如一次 1 BTC,连接关闭时退还「找零」。这条规则让单纯的「搜索查询」无法在没有后续交易的情况下完成付费。

中本聪回应

一个替代方案是用凑整制。你一次为 1000 个页面、图片、下载或搜索之类付费。用完 1000 页,再买 1000 页。如果你只用 1 页,剩下 999 页可能永远用不上,但这不要紧,因为每 1000 的单价仍然很低。

或者按天付费。你在某天第一次访问该网站时,为 24 小时的访问权付费。

按 1000 或按天对消费者来说也更容易理解。按次计费让他们担心累积得太快、算不过来。24 小时不限量,他们知道成本是多少。或者如果 1000 次看起来绰绰有余,只要他们觉得 1000 次多于自己会用到的量,就不会担心每点一下都在花钱。

中本聪SN-2036对没有信用卡、或不想用手里那张卡的人来说,Bitcoin 会相当方便——不想让配偶在账单上看到、不信任把卡号交给「色情业者」…

这条发言承接前面的讨论,可通过下方入口查看完整上下文。

对没有信用卡、或不想用手里那张卡的人来说,Bitcoin 会相当方便——不想让配偶在账单上看到、不信任把卡号交给「色情业者」、或者害怕自动续费的人。

中本聪SN-2808重复一下我自己说过的话:这有现成的开源软件,因此只需加装一个 Bitcoin 支付机制。我找到的一个好东西是 Mihalis…
其他参与者原话kiba原帖 ↗

1. 像 rapidshare 和其他破托管一样的下载站。麻烦的验证码和强制的 paypal。Bitcoin 或许能同时顶替两者并理顺整个流程。

中本聪回应

重复一下我自己说过的话:这有现成的开源软件,因此只需加装一个 Bitcoin 支付机制。我找到的一个好东西是 Mihalism Multi Host。它按免费托管设计,因此只需稍作调整、放宽限制以配合付费使用。

目录与阅读顺序由本站整理;原话保留各自日期与上下文。文中软件版本、费用和设置属于当时的历史语境。

← 选择其他主题全部档案 →

阅读字号

选择适合你的字号,之后阅读会继续使用。