应用与扩展
托管、时间戳、域名和微支付,包括当时尚未实现的设想。
按议题整理 · 中文阅读 · 42 条发言。英文及完整讨论可回到对应档案查看。
托管与多方签名
8 条
如果脚本语言不是无状态的,如果它可以访问任何会变化、或在不同节点之间有所不同的外部信息,攻击者就可以利用它让链分叉。唯一的例…
你好,中本聪:
希望你一切都好。最近我一直在想,比特币怎样能帮助应对互联网滥用行为,很想听听你的看法。
我的‘本职工作’是在 Google 的反滥用团队。我们大量使用电话验证,来控制从我们网络发出的垃圾信息。Facebook 和 Craigslist 也这么做。电话验证效果不错,因为大多数人至少能使用一两个电话号码,却很少能使用更多。不过,它也有明显的缺点:对我们来说成本高、不稳定,有些人不喜欢它对隐私的影响,而且有些垃圾信息的利润足够高,值得购买大量 SIM 卡。
如果能用比特币为一个账户提供抵押,就很理想了。抵押的数量可以帮助系统决定对你的行为设定什么限制,例如能发送多少邮件,同时保持匿名和隐私。但该怎样实现呢?
永久销毁币很容易,只要把唯一的输出设为 <pubkey> OP_FALSE。这样,你就可以用那个密钥签署服务器提供的某个质询,证明你确实销毁了那些币。一个密钥只能用于一个账户,因此垃圾信息发送者不能简单地提供巨额抵押,再转卖用这个密钥生成的签名。如果发现账户被用于滥用行为,就像现在一样封禁它,那些币也就‘没了’。
不过,人们确实会加入或离开这些大型网络。要是退出 Google、自己运行邮件服务就会失去那些币,这个想法就不那么吸引人了。如果币能被锁定一段时间,在时间 X 之前无法花费,而币的所有者想延后时又可以不断把 X 往后推,否则这些币最终就恢复可花费状态,那会很理想。要验证你的 Google 账户,你可以拿出一定数量的币(比如 10 枚),设置成 6 个月内无法花费。
脚本语言里没有时间的概念。OP_BLOCKNUMBER 被排除了,因为重组有可能让整条交易链失效。但 OP_DAY 可行吗?我在想一种操作码,它返回区块头中的时间戳,不过会四舍五入到最近的一天,以处理区块链里自然存在的时钟偏差。
如果这能行,就很容易构造一笔交易,把币锁定到某一天之后。要更新交易,让到期时间不断后移,就比较困难。一种简单直接的办法,是要求用户提供 2 倍的币,在第一笔交易即将到期、恢复可花费时,创建第二笔交易。这样总有至少一笔到期时间足够远的交易可以充当抵押。不过,这不太优雅。更好的办法,是引入一条新规则,允许一笔交易在期限到来之前连接到这样的输出,只要这笔交易的输出仍然是同样形式、带有期限的输出。不过,它的通用性又不如脚本语言,所以也有些不够优雅。
你怎么看?
如果脚本语言不是无状态的,如果它可以访问任何会变化、或在不同节点之间有所不同的外部信息,攻击者就可以利用它让链分叉。唯一的例外是:它在某个时间之前始终为假,在那之后永久为真;这一点通过 nLockTime 实现。
既然 Google 是受信任的,用户不能向 Google 支付一笔象征性的押金,然后在关闭账户时,由 Google 把钱退还给他们吗?
不过,回答你的问题:是的,可以不依靠信任来做到:
用户发出的 Tx 1 付款到一个脚本,花费它需要 Google 和用户双方的签名。
Tx 2(合约)花费 Tx 1,把钱支付给用户。nLockTime 是释放资金的时间。
步骤:
- Google 给用户一个公钥,用于创建 Tx 1。
- 用户私下创建 Tx 1,暂不广播。
- 用户把 Tx 1 的哈希交给 Google。
- Google 在已设置好 nLockTime 的 Tx 2 中签署属于自己的部分,并把它交给用户。
- 用户广播 Tx 1。
- 用户签署 Tx 2 中属于自己的一半,并广播它。
按照这些步骤,用户在广播 Tx 1 之前,手中就已经有了 Google 签署的那一半 Tx 2,因此可以确定,自己签名付出资金时,同意的是什么条件。
这是安全签署合约的一般模式。先准备 Tx 2,让各方知道自己把钱投入的是什么。广播 Tx 1,以锁定资金,并将其指定给 Tx 2。换句话说,各方把自己的钱放入一个只有全体一致同意才能动用的资金池;但在此之前,大家已经签署了对资金默认处理方式的协议,或者已经为多个可选方案作了部分签名,其中一方只需加上最后一个签名就能完成。
只要相互同意,各方始终可以编写另一个版本的 Tx 2,立即释放资金。
尚未实现,但网络能支持要求两个签名的交易。它在这里有描述:
尚未实现,但网络能支持要求两个签名的交易。它在这里有描述:
http://bitcointalk.org/index.php?topic=750.0
它绝对比没有托管的直接支付更安全,但不如人工仲裁的托管好——前提是你足够信任那个人。
在这种托管里,骗子赢不了,但你仍然可能吃亏。它至少消除了骗你的利润动机。卖方得到保证:钱是留给他的;买方也保留着制约卖方的手段:交易完成之前,卖方还拿不到钱。
你这么说,听起来像是钱会莫名其妙地丢掉、即便双方想合作也拿不回来。
其他参与者原话jgarzik原帖 ↗去问问实际做生意的商家,看他们愿不愿意告诉客户:你的钱有可能永远消失,任何一方都无法追回。
你这么说,听起来像是钱会莫名其妙地丢掉、即便双方想合作也拿不回来。
你预先付款买东西时,钱同样拿不回来。消费者对此看起来习以为常。不会比那更糟。
任何一方永远都有把钱释放给对方的选项。
其他参与者原话nelisky原帖 ↗但烧钱方案虽然极好地防止了经济上可行的欺诈,却对报复无能为力,而且一旦一方不诚实,实际上让所有人都受损。我绝不会背书它。
那你也一定反对常见的预付款制度——那种制度里吃亏的是客户。
预付款:客户吃亏,骗子拿到钱。
简单托管:客户吃亏,但骗子也拿不到钱。
你们是在说预付款更好吗?因为至少骗子拿到了钱,至少有人得到了它?
想象有人偷了你的东西。你拿不回来,但假如它有一个能远程触发的停用开关,你会用吗?让窃贼知道你所有的东西都有停用开关、偷了也没用(虽然你自己也照样失去它),这是好事吗?如果他们还回来,你可以重新激活。
想象金子被偷就变成铅。窃贼还回来,它又变回金子。
在我看来,问题可能还是在于以正确的方式呈现它。首先,在博弈论讨论的语境里别把「烧钱」说得那么直白。钱从来不会被真正烧掉。你永远保有随时放款的选项。
下面概述一种可以通过软件实现的托管交易。这还没有实现,我近期多半也没时间实现,只是先让大家了解有哪些可能。
下面概述一种可以通过软件实现的托管交易。这还没有实现,我近期多半也没时间实现,只是先让大家了解有哪些可能。
基本托管:买方把一笔付款存入托管。卖方收到一笔资金处于托管状态的交易,但在买方解锁之前他不能花。买方可以在那之后的任何时间放款,也可以永远不放。这不允许买方把钱拿回去,但确实给了他一个选项:出于怨恨永远不放行,把钱烧掉。卖方则可以把钱退回给买方。
这个系统虽然不保证双方免于损失,但它让作弊变得无利可图。
如果卖方不发货,他就拿不到钱。买方的钱还是打了水漂,但至少卖方没有骗人的金钱动机。
买方无法靠不付款获益。他拿不回托管的钱。他不可能因资金不足而付不了款。卖方可以看到资金已锁定到自己的密钥上、不能发给别人。
当然,经济学家会说,一个欺诈卖方可以开始讨价还价,比如「你放款,我分你一半」,但到了那一步,信任荡然无存、怨气冲天,谈判不太可能发生。一个已经在违背诺言偷钱的骗子,凭什么会守约分你一半?我想,如果金额不大,几乎所有人都会基于原则拒绝。
真的吗?你觉得人们会理解不了它的好处吗?(如果你的回应是争辩说它根本没有好处,我猜那反倒印证了人们理解不了它。)
可以写出一笔需要两个签名才能花掉的交易。你写一笔付款,要求收款人和发送人双方的签名才能花掉它。要释放托管资金,你把自己这一方…
可以写出一笔需要两个签名才能花掉的交易。你写一笔付款,要求收款人和发送人双方的签名才能花掉它。要释放托管资金,你把自己这一方的签名交给收款人;或者由收款人把他这一方的签名交给你,以便把钱退回来。这个简单情形里没有中间人。制约手段就是拒绝放行——等于把钱烧掉。
软件本来就是设计来支持这类东西的。我本来打算发一篇托管(Escrow)方案的详细计划帖,但被 slashdot 报道之后就一…
这条发言承接前面的讨论,可通过下方入口查看完整上下文。
软件本来就是设计来支持这类东西的。我本来打算发一篇托管(Escrow)方案的详细计划帖,但被 slashdot 报道之后就一直没时间。
我不是律师,不可能回答这个问题。我猜,如果法律适用于银行、金融机构或其他中间人,那么这里就不适用,因为没有银行参与,只有双方…
你好,中本聪:
我刚读了下面这个维基页面:
http://en.wikipedia.org/wiki/Chargeback
其中声称:
Mike 引用的网页说明维基百科(Mike 来信所引)来源 ↗‘根据《电子资金转账法》下的美联储 E 条例,美国借记卡持有人享有获得交易撤销的保障。依据相应银行卡组织或银行网络制定的规则,类似权利也适用于世界其他地方。’
‘电子资金转账法’听起来适用范围很广。你觉得它会适用于比特币吗?如果会,无法做退单是否有可能让比特币变得不合法?
我不是律师,不可能回答这个问题。我猜,如果法律适用于银行、金融机构或其他中间人,那么这里就不适用,因为没有银行参与,只有双方直接交易,就像他们当面使用现金,或拿实物商品以物易物一样。
比特币的根本设计目标,就是能够进行不可逆交易,而且确实有一些应用需要这一点。
如果有人希望可以拒付,就可以使用托管交易。这个功能还没有实现,但会是接下来要做的事情之一。例如,可以把交易写成这样:指定一个第三方,在付款人不放款时决定是否退回,并在若干天后自动放款。我会先实现一种更基本的托管形式,但网络基础设施包含一种谓词语言,能够表达任意多种选项。
脚本、时间锁与时间戳
6 条
这真是个好消息!只针对客户端需求,从头做一个简洁的实现,可以摆脱许多复杂性,而且也向 Java 开发者打开了大门。
阅读完整通信正文 · Mike Hearn · 2011-03-07 · BitCoinJ 发布与协议问题
你好,Satoshi,
希望你一切都好。我终于获得了所有律师的认可,可以用谷歌的名义,采用 Apache 2 许可证发布 BitCoinJ:
http://www.bitcoin.org/smf/index.php?topic=4236.0
它还不完整——尤其是还不能正确处理区块链分叉——不过其余功能正在逐步补上。我在文档和注释上花了很多功夫,希望能让那些无法理解或编译现有代码的人,也有机会了解并使用比特币。接下来一两个月,我会补齐几项主要的缺失功能,把客户端模式完整实现出来。
我知道你现在很忙,不过还是希望你能抽空回答几个问题。
为了实现完整的 SPV,我在考虑给协议增加一条 getmerklebranch 消息。给定交易哈希后,它会返回一组 {blockhash, branch} 对,这样便可以在不存储完整区块链的情况下,验证已经广播、但尚未纳入区块的交易。你觉得这种办法怎么样?
另外,我最近也在考虑探索不同的交易类型,比如移除测试网的 IsStandard() 检查。显然,你从一开始就对交易做了很多思考,远不止简单地转移币;可惜这些想法既没写进论文,也没有在代码中记录下来。托管、多方支付等都很有意思,我想知道你能否找个时间,整理一份可以用脚本语言实现的构想清单。
最后,允许交易替换的代码已经被禁用,但注释没有说明原因。这只是为了减少攻击面或复杂度,还是另有更深的原因?我还没完全理解,为什么序列号是交易输入的属性,而不是交易本身的属性。
希望你很快能抽出时间和精力,重新参与进来!不知道你是否看过这个:
http://bitcoin.sipa.be/speed-lin.png
网络的发展真让人兴奋!
谢谢! /mike
引用的来信Mike Hearn来源 ↗希望你一切都好。我终于让所有律师都满意了,可以以 Google 的名义,按 Apache 2 许可证发布 BitCoinJ:
它还不完整——特别是还不能正确处理区块链分叉——但其余部分会陆续完成。我在文档和注释上花了很多功夫,希望能让那些无法理解或构建现有代码的新群体,也能接触比特币。在接下来一两个月里,我会补齐完整客户端模式实现中一些较大的缺失部分。
这真是个好消息!只针对客户端需求,从头做一个简洁的实现,可以摆脱许多复杂性,而且也向 Java 开发者打开了大门。
引用的来信Mike Hearn来源 ↗我知道你现在很忙,但希望你能抽时间回答我的几个问题。
我很乐意回答任何问题。
引用的来信Mike Hearn来源 ↗为了实现完整 SPV,我在考虑向协议添加一个 getmerklebranch 消息。它会返回一组 {blockhash, branch} 对
那就是 CMerkleTx
引用的来信Mike Hearn来源 ↗输入是交易哈希,这样便可以在不存储完整链的情况下,验证已经广播、但尚未纳入区块的交易。你觉得这种办法好吗?
我不明白。Merkle 分支把一笔交易连接回某个区块,而只有该区块具有工作量证明时,这才有意义。连接回一个尚未求解的区块,什么也证明不了。
网络节点能够验证零确认交易,是因为它们拥有完整的交易索引,所以它们可以:
- 对照依赖交易验证签名。
- 声明自己还没有看到另一笔花费,因为它们知道所有现存的交易。
你说的是这笔交易所依赖交易的 CMerkleTx 吗?那可以做到第 1) 点,但做不到第 2) 点。
如果不知道所有现存的交易,我不知道该如何做到第 2) 点。对此,你只能依靠信任其他节点。这种信任可以分散到多个节点。节点只会转发它们接受为有效的交易。如果你从所有相连的节点都收到了某笔交易的 inv 消息,它们就是在作证:这笔交易有效,而且是它们最先看到的花费。
引用的来信Mike Hearn来源 ↗另外,最近我在考虑探索不同的交易类型,例如移除测试网上的 IsStandard() 检查。
很好的想法。在 -testnet 上绝对应该允许这样做。
引用的来信Mike Hearn来源 ↗显然,你一开始就在交易方面作了很多考虑,远不止简单地转移币,但遗憾的是,论文没有提到,代码里也没有文档说明。托管、多方支付等等都很有趣,我想知道,你是否能在某个时候整理一份清单,列出我们可以用脚本语言做的事情。
最后,允许交易替换的代码已经禁用了,但注释没有说原因。这只是为了减少攻击面/复杂性,还是有更深层的原因?
只是为了减少攻击面。它对提高手续费没有帮助。交易从 nLockTime 开始有效。让一笔交易在某个时间失效,是行不通的;一笔交易一旦变得有效,就必须永久保持有效。
参见这些主题:
http://www.bitcoin.org/smf/index.php?topic=1786.msg22119#msg22119
http://www.bitcoin.org/smf/index.php?topic=2181.msg28729#msg28729
引用的来信Mike Hearn来源 ↗我还没有完全理解,为什么序列号是交易输入的属性,而不是交易本身的属性。
这是为合约准备的。一笔尚未记录、仍未定稿的交易,可以在 nLockTime 之前不断被替换。它可能包含多方的付款。每个输入的所有者签署自己的输入。要写出一个新版本,每个人都必须签署更高的序列号(参见 IsNewerThan)。输入所有者签名,等于是在说:“只要大家都把钱放进来,而且输出是这样,我就同意把自己的钱放进来。”SignatureHash 还有其他选项,例如 SIGHASH_SINGLE,意思是:“只要这一个输出(也就是我的)符合我的要求,我就同意,其他输出怎么处理我不管。”如果以较高的 nSequenceNumber 签署这一项,该方就可以退出协商,只保留这一条要求;或者签署 SIGHASH_NONE,完全退出协商。
各方可以创建一笔 nSequenceNumber 更高的交易,使用 OP_CHECKMULTISIG,要求其中部分参与方签名才能完成签名,从而建立一个预先商定的默认选项。各方保留这笔交易备用,必要时相互传递,直到它获得足够的签名。
nLockTime 的一种用途,是一组参与方之间的高频交易。他们可以经全体一致同意,不断更新一笔交易。付款方会首先签署下一个版本。如果某一方不再同意变更,最后的状态就会在 nLockTime 被记录。需要的话,可以在每个版本之后准备一笔默认交易,让 n-1 方能够把一个不响应的参与方排除出去。中间交易无需广播。网络只记录最终结果。就在 nLockTime 即将到来时,各方及少数见证节点会广播它们见过的序列号最高的交易。
当我意识到新交易类型能多快被添加进来时,我也转而同意 Gavin 的白名单主张了。
新的交易模板能按需添加。几天之内就会有大量 GPU 算力接受并处理它。网络会先提供全面支持,很久之后才会有足够多的客户端懂得…
新的交易模板能按需添加。几天之内就会有大量 GPU 算力接受并处理它。网络会先提供全面支持,很久之后才会有足够多的客户端懂得接收和解释新交易。
时间戳哈希现在已经可行:
txin: 0.01
txout: 0.00
fee: 0.01
如果真有像 BitDNS 这样的应用准备开始插入哈希,我们随时能为时间戳加一个专门的交易模板。
我喜欢 Hal Finney 那个用户友好的时间戳构想。把文件的哈希转换成一个比特币地址,然后向它发送 0.01:
其他参与者原话Hal原帖 ↗我想到了一个简单办法来实现上面说的时间戳概念。对想加时间戳的文件跑 sha1sum。把结果转换成一个比特币地址,比如通过 http://blockexplorer.com/q/hashtoaddress。然后向那个地址发一笔小额支付。
这笔钱将永远丢失,因没有办法再花出去,但这个时间戳比特币地址会留在区块链里,作为该文件存在过的记录。
我明白,这样使用比特币的分布式数据库也许并不合适,但没有什么能阻止人们这么做,因此我们应该意识到这可能会发生。
我们不能安全地实现 OP_BLOCKNUMBER。如果网络分裂后发生区块链重组,交易必须仍能进入更晚的区块。OP_BLOCK…
我们不能安全地实现 OP_BLOCKNUMBER。如果网络分裂后发生区块链重组,交易必须仍能进入更晚的区块。OP_BLOCKNUMBER 交易及其所有依赖交易会失效。这对后来持有这些币、但并未参与限时交易的人不公平。
nTimeLock 的作用正好相反。它是一笔尚未锁定的交易,在截止期限前能不断被新版本替换。只有锁定后,它才能被记录到链上。期限到达时版本最高的那笔会被记录。举例来说,它能用来写一笔托管交易,自动永久锁定并完成——除非在期限前被撤销。这个特性尚未启用或使用,但支持代码已在,之后能实现。
Bitcoin 客户端目前只创建和识别匹配两种模板之一的交易。
Bitcoin 客户端目前只创建和识别匹配两种模板之一的交易。
那是一些快速测试,粗略检查交易是否符合标准交易的某些总体指标。节点只会着手把这些交易加进自己的区块。
将来如果我们给现有的 2 类交易增加更多模板,我们能修改「不处理非标准交易」的检查条件来接受它们。
Bitcoin 的性质决定了:一旦 0.1 版发布,核心设计在此后的整个生命周期里就已经定型了。因此,我想把它设计成支持我能…
Bitcoin 的性质决定了:一旦 0.1 版发布,核心设计在此后的整个生命周期里就已经定型了。因此,我想把它设计成支持我能想到的每一种可能的交易类型。问题在于,每种东西无论用不用,都需要专门的支持代码和数据字段,而且每次只覆盖一种特例。特例会爆炸式增长。解决方案是脚本——它把问题泛化,交易双方可以把交易描述为一个由节点网络求值的谓词。节点只需理解交易到足以判断发送方设定的条件是否满足即可。
脚本实际上就是一个谓词。它只是一个求值为真或假的等式。Predicate 是个又长又生僻的词,所以我管它叫 script。
收款方对脚本做模板匹配。目前,接收方只接受两种模板:直接付款和比特币地址。未来版本可以加入更多交易类型的模板,运行该版本或更高版本的节点就能接收它们。网络中所有版本的节点都能把任何新交易验证并处理进区块,哪怕它们不知道如何解读这些交易。
这个设计支持我在多年以前就设计好的、极其多样的可能交易类型。托管交易、担保契约、第三方仲裁、多方签名等。如果 Bitcoin 大规模流行起来,这些是我们将来想要探索的东西,但它们都必须在开端就设计好,以确保日后有可能实现。
我不相信 Bitcoin 的第二个兼容实现会是个好主意。这个设计有太多部分依赖所有节点在每一步都保持同步,得到完全相同的结果,第二个实现将是网络的威胁。MIT 许可与所有其他许可及商业用途兼容,故从许可的角度也没有重写的必要。
域名系统与合并挖矿
7 条
网络不会忘掉,所有者的客户端也会不断重新广播它。即使剩余的 0.3.8 节点逐渐减少,网络仍记得那笔溢出交易,持续了好几个月…
阅读完整通信正文 · Mike Hearn · 2011-03-09 · 交易替换、合约与联合挖矿
有道理。对,我说的是验证输入,不过,除非同时知道所有尚未确认的交易,否则这么做确实没有意义。所以,能否获取一个 CMerkleTx 并不重要。
明白了。所以目前手续费比较棘手,因为必须事先决定付多少;如果估得太低,就无法修正这笔交易。虽然网络最终会忘记它,钱包却仍然记录着这些币已经花出去了。这种情况已经开始出现。
啊哈,一个完全没有探索过的领域在我眼前展开了 :-) 在无需信任中间人的情况下建立分布式合约和托管交易,我觉得这个构想几乎和比特币本身一样新颖。
我还有更多问题!
协议里有一部分尚未完成,涉及建立发布者/订阅者通道,通过网络进行分布式路由。这是做什么用的?是想建立一个点对点市场,还是有某种更底层的用途,比如广播预期的交易手续费?
几个月前,有人讨论过把比特币推广到更一般的用途,很有意思,不过我们很难完全理解你打算怎样实现。我想,我理解了在多条独立链之上再放一棵默克尔树的构想:
http://www.bitcoin.org/smf/index.php?topic=3414.msg48171#msg48171
不过,我没理解你提到为向后兼容预留 200 字节的说法。另外,我猜这可能很明显,但还是想确认清楚:在你的构想里,其他链会与比特币采用完全相同的格式和验证规则(相同的脚本语言等等),这样所有矿工就都能验证所有区块,即便那些区块本质上与金融无关?那么,使用独立区块链的意义,就只是控制客户端模式实现的存储和带宽成本吗?
谢谢!
引用的来信Mike Hearn来源 ↗Mike 引用的中本聪旧信中本聪来源 ↗明白了。所以现在手续费很棘手,因为必须事先决定手续费应该是多少;如果估得太低,就无法修正交易。虽然网络最终会忘掉它,你的钱包仍会记录这些币已经花出。这种情况已经开始发生了。
网络不会忘掉,所有者的客户端也会不断重新广播它。即使剩余的 0.3.8 节点逐渐减少,网络仍记得那笔溢出交易,持续了好几个月。
优先级还考虑时间因素,因此交易等待得越久,这一因素的贡献就越大,最终会获得足够高的优先级。
上面的一个链接里,我考虑过发送一笔诚实的双重支付交易,以提高手续费。工作量很大,但可以做到。我认为目前不值得做。
目前的系统运作得足够好:节点确保按当前状况附上足够的手续费,而网络确保所有交易最终都得到处理。节点在创建自己的交易时没有检查优先级,这是一个疏漏,Gavin 正在修复。
如果用户仍然担心处理速度的不确定性,应该把它看作添加手续费的理由。
引用的来信Mike Hearn来源 ↗协议中有一个未完成的部分,涉及建立发布/订阅通道,通过网络进行分布式路由。它是做什么用的?是想做一个点对点市场,还是有某种更底层的功能,例如广播预期手续费?
我当时试图实现一个内置于客户端的 eBay 式市场。发布/订阅机制用来广播商品报价和评分/评价。你发表的评价会按你生成的区块加权。后来我放弃了它,转而采用 JSON-RPC,让其他作者可以在外部实现,这是正确的选择。发布/订阅的“在中间相遇”机制是个有趣的概念,但现在没有任何东西再使用它。
这是编写代码、探索技术要求最高的使用场景的一部分,目的是确保比特币能支持未来可能需要的一切,因为区块链一旦启动,规则就会锁定。
引用的来信Mike Hearn来源 ↗几个月前,有一场关于推广比特币用途的有趣讨论,但我们很难完全理解你打算如何实现。我想我理解了在多条独立链之上再放一棵 Merkle 树的概念:
http://www.bitcoin.org/smf/index.php?topic=3414.msg48171#msg48171
但我不明白你关于为向后兼容保留 200 字节的说法。另外,我猜这很明显,但为了彻底说清楚——按照你的想法,其他链会与比特币使用完全相同的格式和验证规则集(相同的脚本语言等),这样所有矿工都可以验证所有区块,即使它们不是金融性质的?那么,使用独立区块链的目的,只是管理客户端模式实现的存储成本和带宽吗?
不是,其他链不遵循比特币的规则。它们是完全独立的链。除了矿工,它们不共享任何东西。其他网络对工作量证明的定义是:生成一个已经求解的比特币格式区块(按它们自己链的难度),其中包含它们自己的区块哈希。它们不在乎这个比特币区块是否有效,或是否被比特币使用,但这能让矿工同时为两条链工作。
对 BitDNS 区块进行哈希运算的步骤:
- 计算 BitDNS 区块的哈希
- 构造一个比特币区块
- 把 BitDNS 哈希插入该比特币区块中第 0 笔交易的 scriptSig
- 计算比特币区块的哈希
如果该哈希低于 BitDNS 的目标值,BitDNS 区块就有效。
BitDNS 区块需要附带约 200 字节的数据,以重建哈希运算中使用的比特币区块:
- 比特币区块头
- 通向第 0 笔交易的 Merkle 分支
- 第 0 笔交易(顺便说一下,第 0 笔交易的前序哈希始终为 0,所以省略它能节省 32 字节)
注意,作为计算材料的“比特币区块”在比特币链中是否真的有效,并不重要,虽然它也可能有效。对 BitDNS 来说,它只是一堆用于执行复杂哈希计算的必要盐值。如果一个矿工只为 BitDNS 挖矿,不关心比特币,就会使用一个全为 0 的空白比特币区块(nonce 除外)。
为了进一步扩展这个想法、增强可扩展性,可以考虑:不把 BitDNS 区块哈希放进第 0 笔交易,而是放入一棵包含 BitDNS 的 Merkle 树的根。这就是概念上位于最顶层的那棵 Merkle 树。
@dtvan:这 3 点都很到位。
@dtvan:这 3 点都很到位。
1) IP 记录不必进链,只做注册商功能,不做 DNS。顺带把 CA 问题也解决了,漂亮。
2) 选一个顶级域名,.web +1。
3) 过期机制加可观的续期费用,相当重要。
其他参与者原话joe原帖 ↗不过现在多想了想,我支持在主网络中加入额外的 coinbase/记录系统。这么做的原因是避免 CPU 算力被稀释到多个网络。我们要的是一张强大的网络,因此网络应该具备多种功能。
避免 CPU 算力碎片化已经不是理由了。独立的网络/链能在无需共享太多其他内容的情况下共享算力。参见:http://bitcointalk.org/index.php?topic=1790.msg28696#msg28696 和 http://bitcointalk.org/index.php?topic=1790.msg28715#msg28715
我同意。所有交易——IP 更改、续期等等——都应该带一笔归矿工的手续费。
我同意。所有交易——IP 更改、续期等等——都应该带一笔归矿工的手续费。
你能考虑用一定量的工作来生成一个域名,而不是固定总量发行。每个域名所需的工作量可以按照摩尔定律逐步增加。这样域名的数量会随需求和用户数的增长而增长。
对,域名和比特币之间的汇率会是浮动的。
其他参与者原话Hal原帖 ↗额外的区块链各自发行自己的币,在交易所与比特币交易?这些链专属的币用来奖励那些链上的矿工,并在那条链的领域内购买某些权利或特权?
对,域名和比特币之间的汇率会是浮动的。
对 BitDNS 来说,比 10 分钟更长的出块间隔更合适。
按照目前讨论的内容,就已经需要不少管理数据了。如果你能自由使用所需的空间、不必为比特币链里的昂贵空间付手续费,事情会容易得多。有这么几种交易:
更改 IP 记录。
改名。一个域名对象能让你持有一个域名,并且能随意把它改成任何未被占用的名字。这会鼓励用户释放不再想要的域名。生成的域名起初是空白的,由矿工卖给某个人,由他改成自己想要的名字。
续期。可以免费,也可以考虑要求消耗另一个域名对象。在后者情况下,域名对象(域名币?)能代表持有一个域名一年的权利。花掉的金额会作为下一区块的手续费归矿工。
把世界上所有的工作量证明共识系统都堆进一个数据集是不可扩展的。
把世界上所有的工作量证明共识系统都堆进一个数据集是不可扩展的。
Bitcoin 和 BitDNS 能分开使用。用户并不应该为了用其中一个就得把两个的全部数据都下载下来。BitDNS 用户也未必想下载接下来好几个互不相干的网络决定塞进来的所有东西。
两个网络需要有各自独立的命运。BitDNS 用户可能完全不介意加入各种涉及大量数据的功能,因需要的域名注册商相对较少;而比特币用户可能会越来越强硬地限制链的体积,好让大量用户和小型设备用得轻松。
担心能否用比特币安全购买域名,会把讨论引向无关的问题。用比特币交换其他不可抵赖的商品很容易。
如果你还在担心,密码学上能实现无风险交易。双方在两侧各设置交易,使得当双方都签名后,第二个签名者的签名会触发两笔交易同时释放。第二个签名者无法只释放一笔而不释放另一笔。
激励在于:同样一份工作,还能从额外的侧链拿到报酬。
其他参与者原话nanotube原帖 ↗这样矿工基本上就得多干「额外的活」。如果从 bitdns 挖矿的额外工作里得不到回报(这当然会拖慢比特币主链的挖矿工作),矿工有什么动力把 bitdns(以及其他任何侧链)纳入进来呢?
激励在于:同样一份工作,还能从额外的侧链拿到报酬。
既然你本来就在挖比特币,为什么不让同一份工作量证明顺便获得免费域名呢?
如果你现在每周能生成 50 BTC,那么现在你还能同时得到 50 BTC 和一些域名。
你手里有一份工作。解出它,就同时解出 Bitcoin 和 BitDNS 各一个区块。概念上,它们通过一棵默克尔树绑在一起。要提交给 Bitcoin,就去掉 BitDNS 分支;要提交给 BitDNS,就去掉 Bitcoin 分支。
实践中,要为 Bitcoin 做兼容改造,BitDNS 侧大概要多占约 200 个额外字节,但这不算什么。你一直在说每个区块 50 个域名,相比下为了向后兼容每区块多出的这 200 字节根本不值一提。如果我们足够在意省这几个字节,将来还可以安排一个遥远的区块高度,让比特币升级到顶部带默克尔树的现代化结构。
注意,各条链都在这棵新默克尔树下。也就是说,Bitcoin 和 BitDNS 各自在自己的区块内部拥有自己的链环。这与常见的时间戳服务器结构正好相反——常见结构是链条在上、默克尔树在下,因那样会形成一条共同的主链。而这是两个不共享链的时间戳服务器。
我认为,有可能让 BitDNS 拥有完全独立的网络和区块链,同时与比特币共享 CPU 算力。唯一的重叠是让矿工能同时为两个网…
我认为,有可能让 BitDNS 拥有完全独立的网络和区块链,同时与比特币共享 CPU 算力。唯一的重叠是让矿工能同时为两个网络寻找工作量证明。
两个网络之间不需要任何协调。矿工能并行订阅两个网络。他们进行 SHA 哈希运算,如果找到符合条件的结果,就可能同时为两个网络找到解。如果其中一个网络难度较低,解可能只属于其中一个网络。
我想外部矿工程序能同时对两个程序调用 getwork 并合并工作。也许先调用 Bitcoin,从它那里拿到工作,再交给 BitDNS 的 getwork,合并成一份工作任务。
各网络的 CPU 算力不再相互分散,而是可以共享,并增强彼此的总算力。这就解决了另一个问题:如果存在多个网络,而可用的 CPU 算力集中围攻其中一个,网络之间就会互为威胁。相反,世界上所有网络共享合并的 CPU 算力,总强度反而增加。小网络也能借助现成的矿工基础更容易起步。
微支付与实际应用
21 条
重复一下我自己说过的话:这有现成的开源软件,因此只需加装一个 Bitcoin 支付机制。我找到的一个好东西是 Mihalis…
对没有信用卡或不想使用现有信用卡的人来说,Bitcoin 会相当方便。不想用卡的原因包括:不想让配偶在账单上看到,不放心把卡…
这条发言承接前面的讨论,可通过下方入口查看完整上下文。
对没有信用卡或不想使用现有信用卡的人来说,Bitcoin 会相当方便。不想用卡的原因包括:不想让配偶在账单上看到,不放心把卡号交给「色情业者」,或者害怕自动续费。
一个替代方案是按固定数量打包计费。你一次为 1000 个页面、图片、下载或搜索之类付费。用完 1000 页,再买 1000 …
其他参与者原话Quote from: bytemaster付款一般是预付的,比如一次 1 BTC,连接关闭时退还「找零」。这条规则让单纯的「搜索查询」无法在没有后续交易的情况下完成付费。
一个替代方案是按固定数量打包计费。你一次为 1000 个页面、图片、下载或搜索之类付费。用完 1000 页,再买 1000 页。如果你只用 1 页,剩下 999 页可能永远用不上,但这不要紧,因为每 1000 次的费用仍然很低。
或者按天付费。你在某天第一次访问该网站时,为 24 小时的访问权付费。
按每 1000 次或按天收费,对消费者来说可能也更容易理解。按次计费让他们担心累积得太快、算不过来。24 小时不限量,他们知道成本是多少。或者如果 1000 次看起来绰绰有余,只要他们觉得 1000 次多于自己会用到的量,就不会担心每点一下都在花钱。
Bitcoin 目前还不适合金额极小的微支付。例如,没有合并结算机制的按次搜索或按页浏览付费,以及金额低于 0.01 的付款…
我觉得这是目前最好的办法。就像现金,你不会把全部身家揣在口袋里,只带点零花的钱应付日常开支。
其他参与者原话sirius-m原帖 ↗在手机浏览器上当然可以用 vekja.net 或 mybitcoin.com 这类服务,按你对这些服务的信任程度决定存入多少资金。
我觉得这是目前最好的办法。就像现金,你不会把全部身家揣在口袋里,只带点零花的钱应付日常开支。
他们可以做一个针对手机优化的缩小版网站。如果做应用,它可以作为这类服务的前端,主要功能是二维码扫描器;或者也许已经有通用的二维码扫描应用,网站可以设计成接受它们的扫描。
如果有一个 iPhone 应用,只是 vekja 或 mybitcoin 的前端,不涉及庞大的 P2P,苹果会批准吗?如果不批,依据是什么?反正也可以做 Android 应用。不过应用并非必需,一个手机尺寸的网站就够了。
给你家里的 Bitcoin 服务器做 Web 界面,并不是对每个人都可行的方案。大多数用户没有静态 IP,设置端口转发也太麻烦。
Mihalism Multi Host 是一个流行的开源 PHP 文件托管服务器。
Mihalism Multi Host 是一个流行的开源 PHP 文件托管服务器。
它偏向图片托管,但我认为只要提高文件大小上限、放宽允许的扩展名,它同样可以轻松用作通用文件上传托管。他们需要这些限制来维持免费服务的合理运转,但如果我们装上比特币支付机制,限制就可以放宽。
它没有一堆需要扒掉的客户端脚本或防嵌入的破烂。它生成正常工作的标准链接。
这些免费托管站点的更新换代很频繁。小站可以提供免费图片托管,但一旦开始走红,就会被蹭免费带宽的揩油者淹没。任何出了名的网站都得变得更咄咄逼人地催缴费,以覆盖带宽成本。这是服务定价的完美案例:所需价位落在无人区——免费提供会有些成本负担,但收费金额又太低,让多数用户觉得不值得费事使用传统方式付款。它就卡在 0 和 19.95 之间的鸿沟里。他们最好的办法也许是争取 1000 个用户里有 1 个付 9.95,但那意味着 999/1000 的用户被当成蹭饭的。靠广告也撑不住,因为图片是嵌在别的网站上、根本不经过托管站就被下载的。
运行这套软件的网站示例:
论坛:
下载:
http://code.google.com/p/mihalismmh/
大家怎么看?如果我为它做一个比特币支付集成,会有人有兴趣运行它吗?它也许是第一个可以用比特币购买的全自动服务。相比免费服务,它的优势在于提供大文件的通用上传托管,而不必让下载用户跑到上传站点、百般周折。它会给出直指文件的普通链接。
有实际运行代理服务经验的人在,很有帮助。你觉得 Psiphon 是目前最好的吗?(有时你运行的这个在你入行时是最好的,但后来…
这条发言承接前面的讨论,可通过下方入口查看完整上下文。
标题已改。
有实际运行代理服务经验的人在,很有帮助。你觉得 Psiphon 是目前最好的吗?(有时你运行的这个在你入行时是最好的,但后来你发现了更好的)
好主意。这类服务的生意很兴旺,但我一直觉得标准支付方式与注重隐私的顾客格格不入。
好主意。这类服务的生意很兴旺,但我一直觉得标准支付方式与注重隐私的顾客格格不入。
你愿意把软件免费放出来,让任何人都能轻松架一套吗?出于竞争考虑你多半想留着自己用,但如果任何人只要把软件装上服务器,就能让别人通过代理接入自己所在国家的网络,使用量也许能大一个数量级。
我在想,还有没有其他类型的 web 应用服务器,我们只需要往现成系统上附加一个支付机制?
想把图片上传嵌入论坛帖子时,有 imageshack 之类的服务,但因为是免费的,它们限制查看次数。带宽成本微乎其微,但人家…
想把图片上传嵌入论坛帖子时,有 imageshack 之类的服务,但因为是免费的,它们限制查看次数。带宽成本微乎其微,但人家也不能白送,总得有点甜头。要是能付点钱买带宽、避开限制就好了,可对这么小的事,传统付款实在麻烦。
想上传文件供别人下载就更糟。有 rapidshare 之类的服务,但它们要求下载者多走额外步骤、忍受延迟,逼人看广告或升级付费订阅,还限制 10 次左右的下载。
如果我们能写一套可免费使用的 PHP 代码,用来搭建以比特币收费的图片与文件托管服务,那就好了。有点富余带宽额度的人都可以把它扔到自己的 web 服务器上运行。用户终于可以付点小钱覆盖带宽成本、避开限制和麻烦。理想情况下,它应该是 MIT 许可或公共领域。
这类服务对匿名用户会特别有用——他们付款本来就不容易。
等规模够了,也许可以做一个不做转账的兑换网站:只撮合买家和卖家直接互相兑换,类似 e-bay 的运作方式。
等规模够了,也许可以做一个不做转账的兑换网站:只撮合买家和卖家直接互相兑换,类似 e-bay 的运作方式。
为了更安全,兑换站可以充当比特币一侧的托管。卖家把比特币付款放进托管,买家把传统付款直接发给卖家。兑换服务不经手任何现实世界的货币。
这会比 e-bay 更进一步。即便付款落空后寄出的货物无法追回,e-bay 也照样运转良好。
要是有一份静态 IP 列表供新用户发测试捐赠、看看软件怎么运作,就太好了。如果你能接受入站连接、又有静态 IP 地址,就贴在…
要是有一份静态 IP 列表供新用户发测试捐赠、看看软件怎么运作,就太好了。如果你能接受入站连接、又有静态 IP 地址,就贴在这里!
发到这些 IP 的任何金额都应视为捐赠。
如果你确实希望对方把币转回来,务必在备注里附上用于收回款项的比特币地址或 IP,但请做好对方不会转回的准备。对方不一定会留意收到的交易并把币退回。
你总可以兑换成 Liberty Reserve。它是一种类似 e-Bullion、Pecunix 或 Webmoney 的在…
阅读完整通信正文 · Martti Malmi · 2010-01-05 · 比特币兑换
bitcoinexchange.com 服务的原型现在已经可以用了(登录信息:bitcoin/bit)。它运行在使用 Python 的 Django Web 应用框架上;与 PHP 相比,用起来让人愉快得多。
接下来几天我得学习,之后就能继续做兑换服务。接下来要做的事情包括调整定价,让比特币的价格在我持有的数量接近零时趋向无穷大。这样就能找到市场价格,并维持在供需平衡的水平。我还不完全确定这条定价双曲线应该采用什么参数,这还需要想一想。
你总可以兑换成 Liberty Reserve。它是一种类似 e-Bullion、Pecunix 或 Webmoney 的在线货币,允许兑换,不多过问,也保护隐私。
LR 和其他这类货币难买,但容易兑现。难买是因为兑换商非常谨慎,怕被撤销付款骗走钱,所以要求更多资料和等待时间。兑现则很容易。LR 不可撤销,所以有大量兑换商乐意把 LR 换成任何形式的付款。
比特币则相反,只要生成就能轻松获得比特币。顾客很容易走 bitcoin->LR->cash、bitcoin->LR->gold、bitcoin->LR->paypal 这样的路径,或者可能只是想把钱存着,那就只需 bitcoin->LR。
还有 BTC2PSC 的想法:用比特币出售 paysafecards。既可以发邮件提供卡号,在线交付,也可以邮寄未拆封的实体卡。这些卡有很多变体。在某些国家,它们叫礼品卡,任何接受信用卡的地方都能用。我想,更多使用者是那些信用记录不足、办不了真正信用卡的人,所以他们自己购买礼品卡,用来支付需要信用卡的东西。
别急着往前冲,在还没来得及看看是否有更好办法之前,就让所有支付渠道都拒绝你。我建议先等等,暂时不要联系更多支付处理商。其他用…
别急着往前冲,在还没来得及看看是否有更好办法之前,就让所有支付渠道都拒绝你。我建议先等等,暂时不要联系更多支付处理商。其他用户想到并尝试的东西,可能会给你启发。
随便说几个不完整的想法:也许可以把它定位成某种虚拟商品等微支付所用的中间额度。或者让付款只往一个方向走。如果你只买比特币,就只是把钱付出去,而不收别人的钱,这对于给货币确立价格参照仍然有用。那也许可以算是购买计算机时间的付款。
信用卡只能单向使用。连向客户信用卡退钱这个想法都不要提。信用卡公司很讨厌这一点。
无论如何,任何支付处理商都会期望你卖的是某种实际的东西。
你们国家有电子转账或纸质支票吗?(即使只能在欧洲内部使用。)
对移动设备而言,这确是个好思路。用 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 上这个选项,就是在"启动"文件夹里添加或删除一个图标。
我之前开始实现一个市场功能,方便发布待售物品和接受订单,不过只完成了一半。有点像 e-bay,但没有拍卖,只有“立即购买”。…
哦,对,当然,这一点是根本。是我糊涂了。谢谢你的回答。我建议早期版本的软件把提示写得尽可能明确,例如‘全局链目前共有 %d 个区块’。
我想眼下的主要问题是,生成了币以后,找不到人一起测试,哪怕只是做些模拟交易。有没有计划建立邮件列表,或者某种简单的市场,让大家能拿新生成的比特币做点事情?
我之前开始实现一个市场功能,方便发布待售物品和接受订单,不过只完成了一半。有点像 e-bay,但没有拍卖,只有“立即购买”。它的用途之一,就是让任何人都能方便地提供货币兑换服务。
如果你向 1PhUXucRd8FzQved2KGK3g1eKfTHPGjgFu 发送一些币,并发邮件告诉我你的比特币地址,或是在能接收传入连接的情况下告诉我 IP,我会返还同样数量再加 50。
Hal Finney 写道:
Hal Finney 写道:
引用的来信Hal Finney来源 ↗引用的来信Jonathan Thornburg来源 ↗
- 垃圾邮件发送者的僵尸网络可以轻易突破按发送付费的邮件过滤器
如果工作量证明代币真的变得有用,尤其是变成货币,机器就不会再闲置。用户会期望自己的电脑为自己赚钱(假设收益高于运行成本)。一台收益被僵尸网络窃取的电脑,会比今天更容易引起主人的注意,因此我们可以预期,在那样的世界里,用户会更加努力地维护电脑,清除僵尸网络感染。
如果工作量证明代币有价值,还有一个因素可以缓解垃圾邮件问题:利润会驱使人们建立海量虚假邮箱,从垃圾邮件中收集工作量证明代币。实质上,他们是在用自动邮箱对垃圾邮件发送者以其人之道还治其人之身:收取对方的工作量证明,却不读消息。虚假邮箱与真实用户的比例可能高到让发送垃圾邮件不再划算。
这个过程本身就有可能最先确立工作量证明代币的价值,因为没有僵尸网络的垃圾邮件发送者可以从收集者那里购买代币。虽然回购会暂时让更多垃圾邮件通过,但只会加速这个适得其反的循环,最终让过多的收集者来占垃圾邮件发送者的便宜。
有趣的是,一个 e-gold 系统已经出现了一种叫“撒尘”的垃圾信息。发送者转出极少量金粉,以便在交易备注栏里加入垃圾信息。如果系统允许用户设置愿意接收的最低付款额,或者至少设置能够附带消息的最低金额,用户就可以决定自己愿意收多少钱来接收垃圾信息。
Satoshi Nakamoto
如果工作量证明代币有价值,还有一个因素会减少垃圾邮件:人们会有逐利动机,建立大量虚假邮箱,从垃圾邮件中收集工作量证明代币。实…
引用的来信Hal Finney来源 ↗引用的来信Jonathan Thornburg来源 ↗
- 垃圾邮件发送者的僵尸网络可以轻而易举地突破按次付费发送的邮件过滤器
如果工作量证明代币真的有用,尤其是成为货币,机器就不会再闲着。用户会期望电脑替自己赚钱(假设收入高于运行成本)。如果一台电脑的收益被僵尸网络偷走,主人会比现在更容易注意到,所以我们可以预期,在那样的世界里,用户会更努力地维护电脑,清除僵尸网络的感染。
如果工作量证明代币有价值,还有一个因素会减少垃圾邮件:人们会有逐利动机,建立大量虚假邮箱,从垃圾邮件中收集工作量证明代币。实质上,他们是在用自动邮箱对垃圾邮件发送者以其人之道还治其人之身:收集对方的工作量证明,却不读消息。虚假邮箱与真人的比例可能变得太高,以至于发送垃圾邮件不再划算。
这个过程本身就有可能最初确立工作量证明代币的价值,因为没有僵尸网络的垃圾邮件发送者,可以向收集者购买代币。虽然回购会暂时让更多垃圾邮件通过,但它只会加快这种适得其反的循环,最终让太多收集者从垃圾邮件发送者身上获利。
有趣的是,一个 e-gold 系统已经有一种叫作“撒尘”的垃圾信息。发送者转出一点点金粉,好在交易备注栏中放入垃圾信息。如果系统允许用户设置愿意接收的最低付款金额,或者至少设置能够附带消息的最低金额,用户就可以设定,收多少钱才愿意接收垃圾邮件。
Satoshi Nakamoto
我们已经知道该怎样实现电子货币,使它不至于因可信第三方临阵退缩而被迫简化。如果 10 年后我们还没有以某种方式使用电子货币,…
引用的来信Dustin D. Trammell来源 ↗Dustin D. Trammell 写道:
引用的中本聪旧文中本聪来源 ↗Satoshi Nakamoto 写道:你知道,我认为 90 年代感兴趣的人要多得多,但经历了十多年基于可信任第三方的系统(Digicash 等)的失败后,他们觉得这件事已经没希望了。我希望他们能区分出:据我所知,这是我们第一次尝试一个不以信任为基础的系统。
是的,这就是最吸引我的特点。真正的难点是让人们实际赋予比特币价值,让它们成为货币。
我们已经知道该怎样实现电子货币,使它不至于因可信第三方临阵退缩而被迫简化。如果 10 年后我们还没有以某种方式使用电子货币,我会很惊讶。
它可以从一个狭窄的领域起步,比如奖励积分、捐赠代币、游戏货币,或成人网站的微支付。最初可以把它用在工作量证明应用中,用于那些几乎可以免费、但又不能完全免费的服务。
它现在就可以用于付费发送电子邮件。发送对话框可以调整大小,你想输入多长的消息都可以。连接建立后,消息就会直接发送。收款人双击交易,就能看到完整消息。如果某位名人收到的邮件多到看不过来,但仍希望给粉丝留一种联系自己的方式,就可以设置 Bitcoin,并在网站上公布 IP 地址。“向我在这个 IP 上的优先热线发送 X 枚比特币,我就会亲自阅读这条消息。”
提供订阅的网站如果需要在免费试用中增加一点工作量证明,以免试用蚕食订阅收入,就可以为试用收取比特币。
考虑到它可能会流行起来,先拿一些或许是合理的。如果足够多的人都这么想,就会成为一个自我实现的预言。一旦它启动起来,如果向网站支付几分钱能像向自动售货机投币一样轻松,就会有非常多的应用。
Satoshi Nakamoto http://www.bitcoin.org
我们已经知道该怎样实现电子货币,使它不至于因可信第三方临阵退缩而被迫简化。如果 10 年后我们还没有以某种形式使用电子货币,…
引用的来信Dustin D. Trammell来源 ↗Dustin D. Trammell 写道:
引用的中本聪旧文中本聪来源 ↗Satoshi Nakamoto 写道:你知道,我觉得 90 年代对此感兴趣的人多得多,但经过十多年基于可信第三方的系统(Digicash 等)接连失败,他们认为这件事已经没有希望了。我希望他们能看出区别:据我所知,这是我们第一次尝试一种不以信任为基础的系统。
是的,这就是最吸引我的特点。真正难的是让人们切实认可比特币的价值,使它成为货币。
我们已经知道该怎样实现电子货币,使它不至于因可信第三方临阵退缩而被迫简化。如果 10 年后我们还没有以某种形式使用电子货币,我会很意外。
它可以从小众用途起步,例如奖励积分、捐赠代币、游戏货币,或成人网站的微支付。最初,它可以用于工作量证明应用,服务于那些几乎能够免费、但还不能完全免费的服务。
它现在已经可以用于付费发送电子邮件。发送对话框可以调整大小,你可以输入任意长度的消息。连接建立后,消息会直接发送。收件人双击交易,就能看到完整消息。如果某位名人收到的电子邮件多到读不完,但仍想让粉丝有办法联系自己,就可以运行 Bitcoin,并在网站上公布 IP 地址。“向这个 IP 上的优先热线发送 X 个比特币,我会亲自阅读消息。”
订阅网站如果需要为免费试用增加一些工作量证明,以免试用影响付费订阅,就可以为试用收取比特币。
先弄一些,以备它日后流行起来,也许是有道理的。如果足够多的人这么想,这就会成为自我实现的预言。一旦起步,如果你能像往自动售货机里投币一样,轻松向网站支付几分钱,就会有很多应用。
Satoshi Nakamoto http://www.bitcoin.org
我们已经知道该怎样实现电子货币,使它不至于因可信第三方临阵退缩而被迫简化。如果 10 年后我们还没有以某种方式使用电子货币,…
阅读完整通信正文 · Dustin Trammell · 2009-01-16 · 邮件列表、早期使用与微支付
我很确定那不是我。工作电脑上的 BitCoin 应该通过我们的静态 NAT 地址连接;家里的连接也已经至少 3 天使用我告诉你的那个 IP 了(这几天我一直在两台电脑之间转币做测试)。
当然,没问题。
我现在就加入,谢谢。(:
是的,我看到了那封邮件,这也是我这么快就启动节点的原因之一。我的电脑空闲时也没什么别的事可做,为什么不生成比特币呢?如果有一天它们值钱了……?那就是额外的收获!
我能想到,各类需要微支付的网站都可以使用它们。不过,如果它们想使用现有的比特币节点网络,而不是封闭系统,我觉得实际采用时也会有一个障碍:它们必须先生成足够支持业务的币,或者从别人那里买入。封闭系统显然没有这个问题。
挺有意思的应用。(:
又一个好主意。
-- Dustin D. Trammell dtrammell@dustintrammell.com http://www.dustintrammell.com
引用的来信Dustin D. Trammell来源 ↗引用的中本聪旧文中本聪来源 ↗你知道,我觉得 90 年代对这个领域感兴趣的人要多得多,但经过十多年基于可信第三方的系统(Digicash 等)不断失败,他们认为这已经没有希望了。我希望他们能分清区别:据我所知,这是我们第一次尝试一个不依赖信任的系统。
是的,这正是最吸引我的特点。真正的难点是让人们实际认可 BitCoins 的价值,使它们成为货币。
我们已经知道该怎样实现电子货币,使它不至于因可信第三方临阵退缩而被迫简化。如果 10 年后我们还没有以某种方式使用电子货币,我会很惊讶。
它可以从一个小众领域起步,比如奖励积分、捐赠代币、游戏货币,或者成人网站的小额支付。起初,它可以用于工作量证明应用,为那些几乎可以免费、却又不能完全免费的服务付费。
它已经可以用于付费发送电子邮件。发送对话框可以调整大小,你想输入多长的消息都可以。连接建立时,消息会直接发送。接收方双击交易,就能看到完整消息。如果某位名人收到的邮件多到看不完,却仍然希望给粉丝保留联系自己的途径,他可以设置好比特币,在网站上公布 IP 地址。“向这个 IP 上的我的优先热线发送 X 个比特币,我会亲自阅读你的消息。”
订阅网站如果需要为免费试用增加一些工作量证明,避免试用蚕食付费订阅,就可以为试用收取比特币。
考虑到它可能会流行起来,先弄一点也许是有道理的。如果有足够多的人都这么想,就会成为自我实现的预言。一旦它起步成功,只要能像往自动售货机里投币一样,轻松地向网站支付几分钱,就会有非常多的应用。
Satoshi Nakamoto http://www.bitcoin.org
至少有一个节点的入站 IP 一直在同一个 B 类网络内变化。也许每次运行程序都会变。我没预料到这一点。
引用的来信Dustin D. Trammell来源 ↗不过我用这个地址已经有一阵子了,所以希望我的 dhcp 客户端能够成功续租,不会丢掉地址。地址时不时会变化,但这个地址应该还能用一段时间。
至少有一个节点的入站 IP 一直在同一个 B 类网络内变化。也许每次运行程序都会变。我没预料到这一点。
你介意我把下面这些内容抄送到 bitcoin-list 或 Cryptography 吗?
顺便说一下,bitcoin-list 是: bitcoin-list@lists.sourceforge.net 订阅/退订页面: http://lists.sourceforge.net/mailman/listinfo/bitcoin-list 存档: http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-list
引用的来信Dustin D. Trammell来源 ↗引用的中本聪旧文中本聪来源 ↗你知道,我觉得 90 年代对此感兴趣的人多得多,但经过十多年基于可信第三方的系统(Digicash 等)接连失败,他们认为这件事已经没有希望了。我希望他们能看出区别:据我所知,这是我们第一次尝试一种不以信任为基础的系统。
是的,这就是最吸引我的特点。真正难的是让人们切实认可比特币的价值,使它成为货币。
Hal 隐约提到,它或许可以被看作一种成功概率很低的投资。我们已经知道该怎样实现电子货币,使它不至于因可信第三方临阵退缩而被迫简化。如果 10 年后我们还没有以某种形式使用电子货币,我会很意外。
即使它不能立刻流行起来,下一个想出需要某种代币或电子货币的方案的人,现在也已经可以用它了。它可以从封闭系统或小众用途起步,例如奖励积分、捐赠代币、游戏货币,或成人网站的微支付。一旦起步,如果你能像往自动售货机里投币一样,轻松向网站支付几分钱,就会有很多应用。
它现在已经可以用于付费发送电子邮件。发送对话框可以调整大小,你可以输入任意长度的消息。连接建立后,消息会直接发送。收件人双击交易,就能看到完整消息。如果某位名人收到的电子邮件多到读不完,但仍想让粉丝有办法联系自己,就可以运行 Bitcoin,并在网站上公布 IP 地址。“向这个 IP 上的优先热线发送 X 个比特币,我会亲自阅读消息。”
订阅网站如果需要为免费试用增加一些工作量证明,以免试用影响付费订阅,就可以为试用收取比特币。
Satoshi
目录与阅读顺序由本站整理;原话保留各自日期与上下文。文中软件版本、费用和设置属于当时的历史语境。