比特币正本

Bitcoin open source implementation of P2P currency

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleBitcoin open source implementation of P2P currency

Date2009-02-11 22:27:00 UTC

ForumP2P Foundation · 原文

我开发了一种名为比特币的新型开源点对点电子货币系统。它是完全去中心化的，没有中央服务器，也不依赖任何受信任方，因为一切都基于密码学证明而非信任。欢迎试用，或查看截图和设计论文：

在 http://www.bitcoin.org 下载 Bitcoin v0.1

传统货币的根本问题是，为了让它运转，需要太多的信任。中央银行必须被信任不会让货币贬值，但法币的历史上充满了这种信任被辜负的记录。银行必须被信任会保管我们的钱、电子转账，但它们只留着微不足道的一点准备金，把钱贷出去，掀起一波又一波的信贷泡沫。我们必须信任它们保护我们的隐私，信任它们不会让身份窃贼掏空我们的账户。它们庞大的管理成本让小额支付成为不可能。

一代人之前，多用户分时计算机系统也有类似的问题。在强加密出现之前，用户不得不依靠密码保护来保障文件安全，把信任寄托于系统管理员会保护他们的信息隐私。管理员总可以根据自己的判断，在隐私原则与其他考量之间权衡，或在上级的要求下，随时凌驾于隐私之上。后来强加密走进了大众，信任不再是必需。数据可以用一种别人从物理上根本无法访问的方式来保护，无论出于什么理由，无论借口多么冠冕堂皇，都不行。

我们的货币也该有同样的东西了。有了基于密码学证明的电子货币，无需信任第三方中介，货币可以安全，交易也可以轻松。

这类系统的一项基本构建块是数字签名。一枚数字币包含其所有者的公钥。要转移它，所有者将该币连同下一个所有者的公钥一起签名。任何人都可以验证签名，以确认所有权链。用它来保障所有权很有效，但还有一个大问题没有解决：双重支付。任何所有者都可以通过把一枚已经花掉的币再次签名给另一个所有者，来尝试重复花费。通常的解决办法是让一家受信任的公司用中央数据库来检查双重支付，但这又回到了信任模型。处于中央位置的公司可以凌驾于用户之上，而维持公司运转所需的费用又让小额支付不切实际。

比特币的解决办法是用点对点网络来检查双重支付。简而言之，网络就像一台分布式时间戳服务器，为第一笔花费某枚币的交易盖上时间戳。它利用了信息易于传播、难以压制的特性。工作原理的细节请看设计论文：http://www.bitcoin.org/bitcoin.pdf

最终得到的是一个没有单点故障的分布式系统。用户自己持有自己资金的密码学密钥，直接彼此交易，并借助点对点网络来检查双重支付。

Satoshi Nakamoto

http://www.bitcoin.org

英文原文

I've developed a new open source P2P e-cash system called Bitcoin. It's completely decentralized, with no central server or trusted parties, because everything is based on crypto proof instead of trust. Give it a try, or take a look at the screenshots and design paper:

Download Bitcoin v0.1 at http://www.bitcoin.org

The root problem with conventional currency is all the trust that's required to make it work. The central bank must be trusted not to debase the currency, but the history of fiat currencies is full of breaches of that trust. Banks must be trusted to hold our money and transfer it electronically, but they lend it out in waves of credit bubbles with barely a fraction in reserve. We have to trust them with our privacy, trust them not to let identity thieves drain our accounts. Their massive overhead costs make micropayments impossible.

A generation ago, multi-user time-sharing computer systems had a similar problem. Before strong encryption, users had to rely on password protection to secure their files, placing trust in the system administrator to keep their information private. Privacy could always be overridden by the admin based on his judgment call weighing the principle of privacy against other concerns, or at the behest of his superiors. Then strong encryption became available to the masses, and trust was no longer required. Data could be secured in a way that was physically impossible for others to access, no matter for what reason, no matter how good the excuse, no matter what.

It's time we had the same thing for money. With e-currency based on cryptographic proof, without the need to trust a third party middleman, money can be secure and transactions effortless.

One of the fundamental building blocks for such a system is digital signatures. A digital coin contains the public key of its owner. To transfer it, the owner signs the coin together with the public key of the next owner. Anyone can check the signatures to verify the chain of ownership. It works well to secure ownership, but leaves one big problem unsolved: double-spending. Any owner could try to re-spend an already spent coin by signing it again to another owner. The usual solution is for a trusted company with a central database to check for double-spending, but that just gets back to the trust model. In its central position, the company can override the users, and the fees needed to support the company make micropayments impractical.

Bitcoin's solution is to use a peer-to-peer network to check for double-spending. In a nutshell, the network works like a distributed timestamp server, stamping the first transaction to spend a coin. It takes advantage of the nature of information being easy to spread but hard to stifle. For details on how it works, see the design paper at http://www.bitcoin.org/bitcoin.pdf

The result is a distributed system with no single point of failure. Users hold the crypto keys to their own money and transact directly with each other, with the help of the P2P network to check for double-spending.

Satoshi Nakamoto

http://www.bitcoin.org

Bitcoin P2P e-cash paper

Mon, 01 Jan 0001 00:00:00 +0000

FromSatoshi Nakamoto

SubjectBitcoin P2P e-cash paper

Date2008-10-31 18:10:00 UTC

ListCryptography Mailing List · 原文

我一直在研究一种新型电子现金系统，它完全是点对点的，没有可信第三方。

论文地址：
http://www.bitcoin.org/bitcoin.pdf

主要特性：
双重支付通过点对点网络防止。
没有铸币方或其他可信第三方。
参与者可以保持匿名。
新币由 Hashcash 式工作量证明产生。
新币生成所用的工作量证明同时驱动整个网络，以防止双重支付。

比特币：一种点对点电子现金系统

摘要。纯粹点对点版本的电子现金将允许在线支付从一方直接发送给另一方，而无需经过金融机构的负担。数字签名提供了部分解决方案，但如果仍需要可信第三方来防止双重支付，其主要优势便会丧失。我们提出了一种使用点对点网络解决双重支付问题的方案。网络通过将交易哈希成一条基于哈希的工作量证明的持续链来为交易打时间戳，形成一条未经重做工作量证明就无法更改的记录。最长链不仅是所见事件序列的证明，也是它来自最大 CPU 算力池的证明。只要诚实节点控制着网络上最多的 CPU 算力，它们就能生成最长链，并超过任何攻击者。网络本身所需的结构极小。消息以尽力而为的方式广播，节点可以随意离开和重新加入网络，并接受最长工作量证明链作为其离开期间所发生事件的证明。

论文全文：
http://www.bitcoin.org/bitcoin.pdf

Satoshi Nakamoto

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

英文原文

I've been working on a new electronic cash system that's fully
peer-to-peer, with no trusted third party.

The paper is available at:
http://www.bitcoin.org/bitcoin.pdf

The main properties:
Double-spending is prevented with a peer-to-peer network.
No mint or other trusted parties.
Participants can be anonymous.
New coins are made from Hashcash style proof-of-work.
The proof-of-work for new coin generation also powers the
network to prevent double-spending.

Bitcoin: A Peer-to-Peer Electronic Cash System

Abstract. A purely peer-to-peer version of electronic cash would
allow online payments to be sent directly from one party to another
without the burdens of going through a financial institution.
Digital signatures provide part of the solution, but the main
benefits are lost if a trusted party is still required to prevent
double-spending. We propose a solution to the double-spending
problem using a peer-to-peer network. The network timestamps
transactions by hashing them into an ongoing chain of hash-based
proof-of-work, forming a record that cannot be changed without
redoing the proof-of-work. The longest chain not only serves as
proof of the sequence of events witnessed, but proof that it came
from the largest pool of CPU power. As long as honest nodes control
the most CPU power on the network, they can generate the longest
chain and outpace any attackers. The network itself requires
minimal structure. Messages are broadcasted on a best effort basis,
and nodes can leave and rejoin the network at will, accepting the
longest proof-of-work chain as proof of what happened while they
were gone.

Full paper at:
http://www.bitcoin.org/bitcoin.pdf

Satoshi Nakamoto

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

Bitcoin open source implementation of P2P currency

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleBitcoin open source implementation of P2P currency

Date2009-02-15 16:42:00 UTC

ForumP2P Foundation · 原文

有可能。他们谈论的还是老式的 Chaum 式中央铸币那套，但也许只是因为那是当时唯一可用的东西。也许他们会有兴趣走一条新路。

很多人因为 90 年代以来那些失败的公司，就自动把电子货币当作注定失败的事业而不屑一顾。我希望这一点是显而易见的：害死它们的只是那些系统的中央控制本质。我想，这是我们第一次尝试去中心化的、不基于信任的系统。

英文原文

Could be. They're talking about the old Chaumian central mint stuff, but maybe only because that was the only thing available. Maybe they would be interested in going in a new direction.

A lot of people automatically dismiss e-currency as a lost cause because of all the companies that failed since the 1990's. I hope it's obvious it was only the centrally controlled nature of those systems that doomed them. I think this is the first time we're trying a decentralized, non-trust-based system.

Bitcoin P2P e-cash paper

Mon, 01 Jan 0001 00:00:00 +0000

FromSatoshi Nakamoto

SubjectBitcoin P2P e-cash paper

Date2008-11-03 01:37:43 UTC

ListCryptography Mailing List · 原文

Satoshi Nakamoto 写道：
> 我一直在研究一种新型电子现金系统，它完全是点对点的，没有可信第三方。
>
> 论文地址：
> http://www.bitcoin.org/bitcoin.pdf

我们非常、非常需要这样一个系统，但就我对您提案的理解，它似乎无法扩展到所需的规模。

可转让的工作量证明代币要有价值，必须具有货币价值。要具有货币价值，必须在一个非常大的网络中流通——例如类似 bittorrent 的文件交易网络。

要及时发现并拒绝双重支付事件，必须掌握交易中币的大部分历史交易，若天真地实现，这要求每个节点掌握大部分历史交易，或大部分近期历史交易。如果有数亿人进行交易，那需要大量带宽——每个节点必须知道全部或相当大的一部分。

早在网络规模接近那个程度之前，用户就可以安全地使用简化支付验证（第8节）来检查双重支付，该方法只需要拥有区块头链，每天约12KB。只有试图创造新币的人才需要运行网络节点。起初，大多数用户会运行网络节点，但随着网络增长超过某个规模，这将越来越多地留给拥有专用硬件服务器农场的专家。一个服务器农场只需要在网络上有一个节点，局域网内的其余部分都连接到这个节点。

带宽可能并不像您想的那么高。一笔典型的交易大约400字节（ECC相当紧凑）。每笔交易需要广播两次，姑且按每笔交易1KB计算。Visa在2008财年处理了370亿笔交易，即平均每天1亿笔。这么多交易需要100GB带宽，相当于12张DVD或2部高清电影的容量，按当前价格约值18美元带宽费。

如果网络真发展到那么大，需要数年时间，到那时，通过互联网传输2部高清电影可能算不上什么大事。

Satoshi Nakamoto

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

英文原文

Satoshi Nakamoto wrote:
> I've been working on a new electronic cash system that's fully
> peer-to-peer, with no trusted third party.
>
> The paper is available at:
> http://www.bitcoin.org/bitcoin.pdf

We very, very much need such a system, but the way I understand your
proposal, it does not seem to scale to the required size.

For transferable proof of work tokens to have value, they must have
monetary value. To have monetary value, they must be transferred within
a very large network - for example a file trading network akin to
bittorrent.

To detect and reject a double spending event in a timely manner, one
must have most past transactions of the coins in the transaction, which,
naively implemented, requires each peer to have most past
transactions, or most past transactions that occurred recently. If
hundreds of millions of people are doing transactions, that is a lot of
bandwidth - each must know all, or a substantial part thereof.

Long before the network gets anywhere near as large as that, it would be safe for users to use Simplified Payment Verification (section 8) to check for double spending, which only requires having the chain of block headers, or about 12KB per day. Only people trying to create new coins would need to run network nodes. At first, most users would run network nodes, but as the network grows beyond a certain point, it would be left more and more to specialists with server farms of specialized hardware. A server farm would only need to have one node on the network and the rest of the LAN connects with that one node.

The bandwidth might not be as prohibitive as you think. A typical transaction would be about 400 bytes (ECC is nicely compact). Each transaction has to be broadcast twice, so lets say 1KB per transaction. Visa processed 37 billion transactions in FY2008, or an average of 100 million transactions per day. That many transactions would take 100GB of bandwidth, or the size of 12 DVD or 2 HD quality movies, or about $18 worth of bandwidth at current prices.

If the network were to get that big, it would take several years, and by then, sending 2 HD movies over the Internet would probably not seem like a big deal.

Satoshi Nakamoto

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

Bitcoin open source implementation of P2P currency

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleBitcoin open source implementation of P2P currency

Date2009-02-18 20:50:00 UTC

ForumP2P Foundation · 原文

它是一个全球分布式数据库，数据库的增补由多数人的共识决定，依据的是他们遵循的一套规则：

- 每当有人找到工作量证明生成一个区块，他就能得到一些新币

- 工作量证明的难度每两周调整一次，目标是整个网络平均每小时 6 个区块

- 每个区块给出的币每 4 年减半

可以说，币是由多数人发行的。发行量有限，且事先确定。

举个例子，如果有 1000 个节点，每小时有 6 个节点得到币，那你可能要等一周才能得到点什么。

关于 Sepp 的问题，确实，没有人扮演中央银行或美联储的角色，来随着用户群的增长调整货币供应。那需要一个受信任方来决定价值，因为我不知道软件有什么办法能知道现实世界中东西的真实价值。如果有什么巧妙的办法，或者我们愿意信任某人来主动管理货币供应、把它锚定到某种东西上，规则本来也可以写成那样的。

从这个意义上说，它更像贵金属。不是供应变化来维持价值不变，而是供应事先确定，价值变化。随着用户数量增长，每枚币的价值会上升。它有形成正反馈循环的潜力：用户增加，价值上涨，这又会吸引更多用户来分享价值上涨的收益。

英文原文

It is a global distributed database, with additions to the database by consent of the majority, based on a set of rules they follow:

- Whenever someone finds proof-of-work to generate a block, they get some new coins

- The proof-of-work difficulty is adjusted every two weeks to target an average of 6 blocks per hour (for the whole network)

- The coins given per block is cut in half every 4 years

You could say coins are issued by the majority. They are issued in a limited, predetermined amount.

As an example, if there are 1000 nodes, and 6 get coins each hour, it would likely take a week before you get anything.

To Sepp's question, indeed there is nobody to act as central bank or federal reserve to adjust the money supply as the population of users grows. That would have required a trusted party to determine the value, because I don't know a way for software to know the real world value of things. If there was some clever way, or if we wanted to trust someone to actively manage the money supply to peg it to something, the rules could have been programmed for that.

In this sense, it's more typical of a precious metal. Instead of the supply changing to keep the value the same, the supply is predetermined and the value changes. As the number of users grows, the value per coin increases. It has the potential for a positive feedback loop; as users increase, the value goes up, which could attract more users to take advantage of the increasing value.

Bitcoin P2P e-cash paper

Mon, 01 Jan 0001 00:00:00 +0000

FromSatoshi Nakamoto

SubjectBitcoin P2P e-cash paper

Date2008-11-03 16:23:49 UTC

ListCryptography Mailing List · 原文

> 只要诚实节点控制着网络上最多的 CPU 算力，
> 它们就能生成最长链，并超过任何攻击者。

但事实并非如此。坏人通常控制着拥有10万台甚至更多机器的僵尸网络。我认识的运行垃圾邮件僵尸黑名单的人告诉我，他们经常每天看到上百万新增僵尸机。

这也是 hashcash 在当今互联网上无法奏效的原因——好人拥有的计算火力远少于坏人。

感谢您提出这一点。

我本可以将那个陈述说得更严谨些。要求是：好人一方合计拥有的 CPU 算力超过任何单个攻击者。

存在许多不足以压倒网络的小型僵尸网络，它们仍可通过生成比特币赚钱。这些小型网络就成了"诚实节点"。（我需要一个比"诚实"更好的词）越多的小型网络转而生成比特币，压倒网络的门槛就越高，使得较大的网络也小到不足以压倒网络，于是它们也不妨转而生成比特币。根据"长尾"理论，小型、中型乃至仅仅是大型的网络加起来，其总量应远超过最大的僵尸网络。

即使坏人压倒了网络，也不意味着他立刻暴富。他所能做到的只是取回自己花掉的钱，就像开空头支票一样。要利用它，他得先从商家那里买东西，等商品发货，然后压倒网络，试图把钱要回来。我认为他搞这种盗刷骗局赚的钱，不会比生成比特币赚的多。拥有那么大的僵尸网络，他生成的比特币会比所有其他人加起来还多。

比特币网络甚至可能通过把僵尸网络引向生成比特币来减少垃圾邮件。

Satoshi Nakamoto

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

英文原文

> As long as honest nodes control the most CPU power on the network,
> they can generate the longest chain and outpace any attackers.

But they don't. Bad guys routinely control zombie farms of 100,000
machines or more. People I know who run a blacklist of spam sending
zombies tell me they often see a million new zombies a day.

This is the same reason that hashcash can't work on today's Internet
-- the good guys have vastly less computational firepower than the bad
guys.

Thanks for bringing up that point.

I didn't really make that statement as strong as I could have. The requirement is that the good guys collectively have more CPU power than any single attacker.

There would be many smaller zombie farms that are not big enough to overpower the network, and they could still make money by generating bitcoins. The smaller farms are then the "honest nodes". (I need a better term than "honest") The more smaller farms resort to generating bitcoins, the higher the bar gets to overpower the network, making larger farms also too small to overpower it so that they may as well generate bitcoins too. According to the "long tail" theory, the small, medium and merely large farms put together should add up to a lot more than the biggest zombie farm.

Even if a bad guy does overpower the network, it's not like he's instantly rich. All he can accomplish is to take back money he himself spent, like bouncing a check. To exploit it, he would have to buy something from a merchant, wait till it ships, then overpower the network and try to take his money back. I don't think he could make as much money trying to pull a carding scheme like that as he could by generating bitcoins. With a zombie farm that big, he could generate more bitcoins than everyone else combined.

The Bitcoin network might actually reduce spam by diverting zombie farms to generating bitcoins instead.

Satoshi Nakamoto

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

Bitcoin P2P e-cash paper

Mon, 01 Jan 0001 00:00:00 +0000

FromSatoshi Nakamoto

SubjectBitcoin P2P e-cash paper

Date2008-11-06 20:15:40 UTC

ListCryptography Mailing List · 原文

[冗长的关于系统易受暴力垄断攻击的论述从略。]

您在密码学中找不到解决政治问题的方法。

是的，但我们可以在这场军备竞赛中赢得一场重大战役，并为数年时间赢得一片新的自由领地。

各国政府擅长斩首像 Napster 这样集中控制的网络的首脑，但像 Gnutella 和 Tor 这样的纯 P2P 网络似乎仍能自保。

Satoshi

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

英文原文

[Lengthy exposition of vulnerability of a systm to use-of-force
monopolies ellided.]

You will not find a solution to political problems in cryptography.

Yes, but we can win a major battle in the arms race and gain a new territory of freedom for several years.

Governments are good at cutting off the heads of a centrally controlled networks like Napster, but pure P2P networks like Gnutella and Tor seem to be holding their own.

Satoshi

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

Welcome to the new Bitcoin forum!

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleWelcome to the new Bitcoin forum!

Date2009-11-22 18:04:28 UTC

ForumBitcointalk · 原文

欢迎来到新的比特币论坛！

旧论坛仍可在这里访问：
http://bitcoin.sourceforge.net/boards/index.php

我会在这里重新发布一些精选的帖子，并在力所能及处补充更新后的回答。

常见问题
http://bitcoin.sourceforge.net/wiki/index.php?page=FAQ

下载
http://sourceforge.net/projects/bitcoin/files/

英文原文

Welcome to the new Bitcoin forum!

The old forum can still be reached here:
http://bitcoin.sourceforge.net/boards/index.php

I'll repost some selected threads here and add updated answers to questions where I can.

FAQ
http://bitcoin.sourceforge.net/wiki/index.php?page=FAQ

Download
http://sourceforge.net/projects/bitcoin/files/

Bitcoin P2P e-cash paper

Mon, 01 Jan 0001 00:00:00 +0000

FromSatoshi Nakamoto

SubjectBitcoin P2P e-cash paper

Date2008-11-08 18:54:38 UTC

ListCryptography Mailing List · 原文

Ray Dillinger：
> 这种"货币"每年约有35%的通胀率
> 因为计算机每年提速就是这么多
> ……35%的通胀率几乎是技术注定的

硬件提速问题已有处理："为了补偿硬件速度的提升，以及长期运行节点意愿的变化，工作量证明难度由一个移动平均值决定，目标是每小时平均区块数。如果区块生成过快，难度就会上调。"

随着计算机提速、用于创造比特币的总算力增加，难度将按比例上调，以保持新币总产量恒定。因此，未来每年将创造多少新比特币是预先可知的。

新币的产生意味着货币供应量按计划增长，但这不一定导致通胀。如果货币供应量的增速与使用人数的增速相同，价格将保持稳定。如果供应增速不及需求，就会出现通缩，货币的早期持有者会看到其价值上涨。

币总要以某种方式初始分配出去，恒定速率似乎是最好的方案。

Satoshi Nakamoto

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

英文原文

Ray Dillinger:
> the "currency" is inflationary at about 35%
> as that's how much faster computers get annually
> ... the inflation rate of 35% is almost guaranteed
> by the technology

Increasing hardware speed is handled: "To compensate for increasing hardware speed and varying interest in running nodes over time, the proof-of-work difficulty is determined by a moving average targeting an average number of blocks per hour. If they're generated too fast, the difficulty increases."

As computers get faster and the total computing power applied to creating bitcoins increases, the difficulty increases proportionally to keep the total new production constant. Thus, it is known in advance how many new bitcoins will be created every year in the future.

The fact that new coins are produced means the money supply increases by a planned amount, but this does not necessarily result in inflation. If the supply of money increases at the same rate that the number of people using it increases, prices remain stable. If it does not increase as fast as demand, there will be deflation and early holders of money will see its value increase.

Coins have to get initially distributed somehow, and a constant rate seems like the best formula.

Satoshi Nakamoto

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

Repost: Bitcoin Maturation

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRepost: Bitcoin Maturation

Date2009-11-22 18:31:44 UTC

ForumBitcointalk · 原文

--------------------
bitcoinbitcoin:
Bitcoin Maturation
发表于：2009 年 10 月 1 日星期四 (14:12 UTC)

从用户的角度看，比特币的成熟过程可以分为 8 个阶段。

1. 你第一次点击"生成货币"（Generate Coins）时发生的初始网络交易。
2. 从该初始网络交易到比特币条目准备好出现在"所有交易"列表中的时间。
3. 比特币条目从"所有交易"字段之外进入该字段的变化。
4. 从比特币出现在"所有转账"列表到描述准备好变为"已生成（Generated，50.00 在 x 个区块后成熟）"的时间。
5. 描述变为"已生成（50.00 在 x 个区块后成熟）"的变化。
6. 从描述显示"已生成（50.00 在 x 个区块后成熟）"到准备好变为"已生成"的时间。
7. 描述变为"已生成"的变化。
8. 描述变为"已生成"之后的时间。

哪些阶段需要网络连接、大量的本地 CPU 占用和/或大量的远程 CPU 占用？这些阶段有名字吗？

--------------------
sirius-m:
回复：Bitcoin Maturation
发表于：2009 年 10 月 22 日星期四 (02:36 UTC)

据我所知，点击"生成货币"时并没有网络交易——你的电脑只是开始计算下一个工作量证明。生成货币时 CPU 占用是 100%。

在这个例子中，网络连接是在你广播自己创建的工作量证明区块的信息时用到的（正是这个区块让你有权获得新币）。成功生成货币需要持续的连接，这样当别人先你一步得到当前区块时，你能开始处理下一个区块。

英文原文

--------------------
bitcoinbitcoin:
Bitcoin Maturation
Posted:Thu 01 of Oct, 2009 (14:12 UTC)

From the user's perspective the bitcoin maturation process can be broken down into 8 stages.

1. The initial network transaction that occurs when you first click Generate Coins.
2. The time between that initial network transaction and when the bitcoin entry is ready to appear in the All Transactions list.
3. The change of the bitcoin entry from outside the All Transaction field to inside it.
4. The time between when the bitcoin appears in the All Transfers list and when the Description is ready to change to Generated (50.00 matures in x more blocks).
5. The change of the Description to Generated (50.00 matures in x more blocks).
6. The time between when the Description says Generated (50.00 matures in x more blocks) to when it is ready to change to Generated.
7 The change of the Description to Generated.
8. The time after the Description has changed to Generated.

Which stages require network connectivity, significant local CPU usage and or significant remote CPU usage? Do any of these stages have names?

--------------------
sirius-m:
Re: Bitcoin Maturation
Posted:Thu 22 of Oct, 2009 (02:36 UTC)

As far as I know, there's no network transaction when you click Generate Coins - your computer just starts calculating the next proof-of-work. The CPU usage is 100% when you're generating coins.

In this example, the network connection is used when you broadcast the information about the proof-of-work block you've created (that which entitles you to the new coin). Generating coins successfully requires constant connectivity, so that you can start working on the next block when someone gets the current block before you.

Bitcoin P2P e-cash paper

Mon, 01 Jan 0001 00:00:00 +0000

FromSatoshi Nakamoto

SubjectBitcoin P2P e-cash paper

Date2008-11-09 01:58:48 UTC

ListCryptography Mailing List · 原文

Hal Finney 写道：
> 文中提到，如果广播的交易没有传达到所有节点，也没关系，因为它很快就会进入区块链。这是如何发生的——如果创建"下一个"区块的节点（第一个找到 hashcash 碰撞的节点）没有听到这笔交易，之后又有几个区块被同样没听到该交易的节点添加进去呢？所有听到这笔交易的节点是否都会保留它，希望自己运气好找到下一次碰撞、成为出块者时把它纳入区块？

没错，节点会把交易保留在工作集中，直到它们进入区块。如果一笔交易传达到了90%的节点，那么每当发现一个新区块，它就有90%的概率被包含在内。

或者举例来说，如果一个节点在等待看哪条链增长最快的过程中同时保留两条或多条链，而此时到来一个属于链A的区块，其中包含对链B中某币的双重支付，系统会检查这种情况吗？（这可能发生在有人双重支付、两组不同节点分别听到同一枚币的两笔不同交易时。）

这不需要检查。最终胜出的分支中的那笔交易成为有效交易，另一笔无效。如果有人试图这样双重支付，最终总有且仅有一笔支付有效，其余无效。

交易收款方通常需要等待一小时左右，让这类可能性有时间解决。他们仍可以立即再花掉这些币，但在采取发货等行动前应先等待。

我也不太明白，一个能集结超过所有诚实参与者算力的强大攻击者，究竟如何实现双重支付或取消交易。我看到他可以创建新区块并添加到最长链上，但他如何抹去或添加链中的旧交易？当攻击者发送他的新区块时，诚实节点难道不会做一致性检查，以确保没有任何内容被抹去吗？多解释一下这种攻击会很有帮助，以便判断攻击者的收益是否比简单地用他的算力诚实地铸造新币更高。

攻击者不是在末尾追加区块。他必须回过头重做他那笔交易所在的区块及其之后的所有区块，还包括他操作期间网络在末尾不断添加的新区块。他在改写历史。一旦他的分支更长，它就成为新的有效链。

这触及一个关键点。即使在场的人都看到了其中的猫腻，也无法利用这个事实。

最长链始终被视为有效链，这一点是绝对必要的。在场的节点可能记得某个分支先出现、后被另一个分支取代，但他们无法让不在场的人相信这一点。我们不能让一部分节点派系死守他们认为先出现的分支，另一部分节点则死守自己先见到的分支，还有后来加入、从没见过事发经过的节点。CPU算力工作量证明投票必须拥有最终决定权。让所有人保持一致的唯一办法是：相信最长链永远是有效链，无论如何。

关于支付交易，币的接收方需要做哪些检查？她需要回溯这枚币的整个转移历史，并确保列表上的每笔交易确实都链接进了"时间戳"区块链吗？还是只需检查最新的一笔？

收款方只需回溯验证到区块链中足够深的深度，这通常只需要回溯2笔交易。更早的所有交易都可以丢弃。

时间戳节点会检查交易吗？确保一枚币的前一笔交易在链中，从而强制执行"链中所有交易代表有效币"这条规则？

没错，正是如此。当节点收到一个区块时，它会根据区块中的历史交易检查其中每笔交易的签名。区块只能包含依赖于先前区块（或同一区块）中有效交易的交易。交易C可以依赖同一区块中的交易B，B依赖更早区块中的交易A。

抱歉问了这么多问题，但正如我所说，这确实是一个非常有前景、非常原创的想法，我期待看到这个概念进一步发展。如果能看到一个更面向过程的描述，包含各种对象（币、区块、交易）数据结构的具体细节、消息中包含的数据，以及处理系统中各类事件的过程算法描述，会很有帮助。您提到正在做一个实现，但我认为一个更正式的文字版系统描述会是很有帮助的下一步。

感谢您的提问。我做这件事的顺序其实是反的：我必须先写出所有代码，才能说服自己可以解决每一个问题，然后才写了论文。我想我发布代码的速度会比写出详细规范更快。在您自行补齐空白的那些假设中，大多数已经是对的。

Satoshi Nakamoto

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

英文原文

Hal Finney wrote:
> it is mentioned that if a broadcast transaction does not reach all nodes,
> it is OK, as it will get into the block chain before long. How does this
> happen - what if the node that creates the "next" block (the first node
> to find the hashcash collision) did not hear about the transaction,
> and then a few more blocks get added also by nodes that did not hear
> about that transaction? Do all the nodes that did hear it keep that
> transaction around, hoping to incorporate it into a block once they get
> lucky enough to be the one which finds the next collision?

Right, nodes keep transactions in their working set until they get into a block. If a transaction reaches 90% of nodes, then each time a new block is found, it has a 90% chance of being in it.

Or for example, what if a node is keeping two or more chains around as
it waits to see which grows fastest, and a block comes in for chain A
which would include a double-spend of a coin that is in chain B? Is that
checked for or not? (This might happen if someone double-spent and two
different sets of nodes heard about the two different transactions with
the same coin.)

That does not need to be checked for. The transaction in whichever branch ends up getting ahead becomes the valid one, the other is invalid. If someone tries to double spend like that, one and only one spend will always become valid, the others invalid.

Receivers of transactions will normally need to hold transactions for perhaps an hour or more to allow time for this kind of possibility to be resolved. They can still re-spend the coins immediately, but they should wait before taking an action such as shipping goods.

I also don't understand exactly how double-spending, or cancelling
transactions, is accomplished by a superior attacker who is able to muster
more computing power than all the honest participants. I see that he can
create new blocks and add them to create the longest chain, but how can
he erase or add old transactions in the chain? As the attacker sends out
his new blocks, aren't there consistency checks which honest nodes can
perform, to make sure that nothing got erased? More explanation of this
attack would be helpful, in order to judge the gains to an attacker from
this, versus simply using his computing power to mint new coins honestly.

The attacker isn't adding blocks to the end. He has to go back and redo the block his transaction is in and all the blocks after it, as well as any new blocks the network keeps adding to the end while he's doing that. He's rewriting history. Once his branch is longer, it becomes the new valid one.

This touches on a key point. Even though everyone present may see the shenanigans going on, there's no way to take advantage of that fact.

It is strictly necessary that the longest chain is always considered the valid one. Nodes that were present may remember that one branch was there first and got replaced by another, but there would be no way for them to convince those who were not present of this. We can't have subfactions of nodes that cling to one branch that they think was first, others that saw another branch first, and others that joined later and never saw what happened. The CPU power proof-of-work vote must have the final say. The only way for everyone to stay on the same page is to believe that the longest chain is always the valid one, no matter what.

As far as the spending transactions, what checks does the recipient of a
coin have to perform? Does she need to go back through the coin's entire
history of transfers, and make sure that every transaction on the list is
indeed linked into the "timestamp" block chain? Or can she just do the
latest one?

The recipient just needs to verify it back to a depth that is sufficiently far back in the block chain, which will often only require a depth of 2 transactions. All transactions before that can be discarded.

Do the timestamp nodes check transactions, making sure that
the previous transaction on a coin is in the chain, thereby enforcing
the rule that all transactions in the chain represent valid coins?

Right, exactly. When a node receives a block, it checks the signatures of every transaction in it against previous transactions in blocks. Blocks can only contain transactions that depend on valid transactions in previous blocks or the same block. Transaction C could depend on transaction B in the same block and B depends on transaction A in an earlier block.

Sorry about all the questions, but as I said this does seem to be a
very promising and original idea, and I am looking forward to seeing
how the concept is further developed. It would be helpful to see a more
process oriented description of the idea, with concrete details of the
data structures for the various objects (coins, blocks, transactions),
the data which is included in messages, and algorithmic descriptions
of the procedures for handling the various events which would occur in
this system. You mentioned that you are working on an implementation,
but I think a more formal, text description of the system would be a
helpful next step.

I appreciate your questions. I actually did this kind of backwards. I had to write all the code before I could convince myself that I could solve every problem, then I wrote the paper. I think I will be able to release the code sooner than I could write a detailed spec. You're already right about most of your assumptions where you filled in the blanks.

Satoshi Nakamoto

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

Repost: Request: Make this anonymous?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRepost: Request: Make this anonymous?

Date2009-11-22 18:32:00 UTC

ForumBitcointalk · 原文

--------------------
anonguy54:
请求：能做成匿名的吗？
发表于：2009 年 10 月 15 日星期四 (19:58 UTC)

有没有计划把这个服务做成匿名的？

比如：能通过 Tor 路由比特币。

英文原文

--------------------
anonguy54:
Request: Make this anonymous?
Posted:Thu 15 of Oct, 2009 (19:58 UTC)

Are there any plans to make this service anonymous?

e.g; Being able to route BitCoin through Tor.

Bitcoin P2P e-cash paper

Mon, 01 Jan 0001 00:00:00 +0000

FromSatoshi Nakamoto

SubjectBitcoin P2P e-cash paper

Date2008-11-09 03:09:49 UTC

ListCryptography Mailing List · 原文

James A. Donald 写道：
> 核心概念是：众多实体各自维护完整且一致的、关于谁拥有哪枚比特币的信息。
>
> 但保持一致性很棘手。我不清楚的是：当有人向一个维护者上报一笔交易，另一个人向另一个维护者传送另一笔交易时，会发生什么。在一笔交易被纳入所有历史交易的全局共享视图之前，无法知道它是有效的；而在一段时间过去、许多新交易到来之前，没人能知道所有历史交易的全局共享视图确实是全局共享的。
>
> 您解释过如何做到这一点、只是我没听进去，还是您确信能做到、但细节上有点含糊？

工作量证明链是同步问题的解决方案，也是无需信任任何人就能知晓全局共享视图是什么的方案。

一笔交易会在网络中快速传播，因此如果同一笔交易的两个版本在接近同一时间上报，先行的那个在更早到达更多节点方面将有很大优势。节点只接受它看到的第一个，拒绝后来到达的第二个，所以更早的交易会有更多节点努力将其纳入下一个工作量证明。实际上，每个节点通过把自己先看到的交易纳入工作量证明计算，为自己的观点投票。

如果两笔交易确实在完全同一时间到来且势均力敌，那就看哪一个先进入工作量证明，以此决定哪笔有效。

当一个节点找到工作量证明时，新区块会在网络中传播，所有人都把它加到链上，并开始在它之后挖下一个区块。任何持有另一笔交易的节点都会停止试图把它纳入区块，因为根据已被接受的链，它现在已经无效。

工作量证明链本身就是它来自全局共享视图的不证自明的证据。只有全网大多数节点合在一起才有足够的 CPU 算力生成如此困难的工作量证明链。任何用户收到工作量证明链后，都能看到网络大多数批准了什么。一旦一笔交易被哈希进链上靠后几环的某一环中，它就被牢牢地刻进了全局历史。

Satoshi Nakamoto

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

英文原文

James A. Donald wrote:
> The core concept is that lots of entities keep complete and consistent
> information as to who owns which bitcoins.
>
> But maintaining consistency is tricky. It is not clear to me what
> happens when someone reports one transaction to one maintainer, and
> someone else transports another transaction to another maintainer. The
> transaction cannot be known to be valid until it has been incorporated
> into a globally shared view of all past transactions, and no one can
> know that a globally shared view of all past transactions is globally
> shared until after some time has passed, and after many new
> transactions have arrived.
>
> Did you explain how to do this, and it just passed over my head, or
> were you confident it could be done, and a bit vague as to the details?

The proof-of-work chain is the solution to the synchronisation problem, and to knowing what the globally shared view is without having to trust anyone.

A transaction will quickly propagate throughout the network, so if two versions of the same transaction were reported at close to the same time, the one with the head start would have a big advantage in reaching many more nodes first. Nodes will only accept the first one they see, refusing the second one to arrive, so the earlier transaction would have many more nodes working on incorporating it into the next proof-of-work. In effect, each node votes for its viewpoint of which transaction it saw first by including it in its proof-of-work effort.

If the transactions did come at exactly the same time and there was an even split, it's a toss up based on which gets into a proof-of-work first, and that decides which is valid.

When a node finds a proof-of-work, the new block is propagated throughout the network and everyone adds it to the chain and starts working on the next block after it. Any nodes that had the other transaction will stop trying to include it in a block, since it's now invalid according to the accepted chain.

The proof-of-work chain is itself self-evident proof that it came from the globally shared view. Only the majority of the network together has enough CPU power to generate such a difficult chain of proof-of-work. Any user, upon receiving the proof-of-work chain, can see what the majority of the network has approved. Once a transaction is hashed into a link that's a few links back in the chain, it is firmly etched into the global history.

Satoshi Nakamoto

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

Re: Repost: Bitcoin Maturation

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Repost: Bitcoin Maturation

Date2009-11-22 18:34:21 UTC

ForumBitcointalk · 原文

在你试图生成一枚币（一个区块）的过程中，以及成功生成的那一刻，网络连接很重要。

1) 生成过程中（状态栏显示"正在生成"、你用 CPU 寻找工作量证明时），你必须持续与网络保持联系，以接收最新的区块。如果你的区块没有链接到最新的区块，它可能不会被接受。

2) 当你成功生成一个区块，它会立即广播到网络。其他节点必须收到它并链接到它，它才能被接受为新的最新区块。

把它想象成一次合作造链的努力。当你加上一环，你必须先找到链当前的那一端。如果你找到最后一环，然后离开一小时去锻造你的一环，回来把它接到一小时前的那一端上，别人可能已经加了好几环，他们可不想用你这条从中间岔出去的环。

区块生成之后，120 个区块的成熟时间是为了绝对确保该区块属于主链，之后才能被花费。那段时间你的节点并没有对这个区块做什么，只是在等你的区块后面再加上其他区块。那段时间你不必在线。

英文原文

It's important to have network connectivity while you're trying to generate a coin (block) and at the moment it is successfully generated.

1) During generation (when the status bar says "Generating" and you're using CPU to find a proof-of-work), you must constantly keep in contact with the network to receive the latest block. If your block does not link to the latest block, it may not be accepted.

2) When you successfully generate a block, it is immediately broadcast to the network. Other nodes must receive it and link to it for it to be accepted as the new latest block.

Think of it as a cooperative effort to make a chain. When you add a link, you must first find the current end of the chain. If you were to locate the last link, then go off for an hour and forge your link, come back and link it to the link that was the end an hour ago, others may have added several links since then and they're not going to want to use your link that now branches off the middle.

After a block is created, the maturation time of 120 blocks is to make absolutely sure the block is part of the main chain before it can be spent. Your node isn't doing anything with the block during that time, just waiting for other blocks to be added after yours. You don't have to be online during that time.

Bitcoin P2P e-cash paper

Mon, 01 Jan 0001 00:00:00 +0000

FromSatoshi Nakamoto

SubjectBitcoin P2P e-cash paper

Date2008-11-09 16:31:26 UTC

ListCryptography Mailing List · 原文

James A. Donald 写道：
>好，假设一个节点在工作量证明中纳入了一批交易，全部是诚实的合法单次支付，另一个节点在其工作量证明中纳入了另一批交易，也全部是同样诚实的合法单次支付，且两个证明在大约同一时间生成。
>
>那会发生什么？

它们都广播自己的区块。所有节点都收到这两个区块并都保留，但只在先收到的那个上工作。假设恰好一半节点先收到一个，另一半先收到另一个。

短时间内，所有交易都会传播完毕，每个人都拥有完整集合。在每一方工作的节点会试图补上本方缺失的交易。当下一个工作量证明被找到时，无论那个节点之前在哪边工作，那条分支都会变长、僵局被打破。无论是哪一方胜出，新区块都会包含另一半交易，所以无论哪种情况，分支都会包含所有交易。即使极不可能地连续分叉两次，第二次分叉的两边也都会包含完整的交易集合。

如果交易需要多等一个或几个周期才能进入区块，这不是问题。

Satoshi Nakamoto

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

英文原文

James A. Donald wrote:
>OK, suppose one node incorporates a bunch of
>transactions in its proof of work, all of them honest
>legitimate single spends and another node incorporates a
>different bunch of transactions in its proof of
>work, all of them equally honest legitimate single
>spends, and both proofs are generated at about the same
>time.
>
>What happens then?

They both broadcast their blocks. All nodes receive them and keep both, but only work on the one they received first. We'll suppose exactly half received one first, half the other.

In a short time, all the transactions will finish propagating so that everyone has the full set. The nodes working on each side will be trying to add the transactions that are missing from their side. When the next proof-of-work is found, whichever previous block that node was working on, that branch becomes longer and the tie is broken. Whichever side it is, the new block will contain the other half of the transactions, so in either case, the branch will contain all transactions. Even in the unlikely event that a split happened twice in a row, both sides of the second split would contain the full set of transactions anyway.

It's not a problem if transactions have to wait one or a few extra cycles to get into a block.

Satoshi Nakamoto

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

Re: Repost: Request: Make this anonymous?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Repost: Request: Make this anonymous?

Date2009-11-22 18:35:15 UTC

ForumBitcointalk · 原文

0.2 版会有代理设置，让你可以通过 TOR 连接。我已经仔细检查过，确保代理模式下它不会用 DNS，也不会做任何会泄露你 IP 的事。

英文原文

There will be a proxy setting in version 0.2 so you can connect through TOR. I've done a careful scrub to make sure it doesn't use DNS or do anything that would leak your IP while in proxy mode.

Bitcoin P2P e-cash paper

Mon, 01 Jan 0001 00:00:00 +0000

FromSatoshi Nakamoto

SubjectBitcoin P2P e-cash paper

Date2008-11-10 22:18:20 UTC

ListCryptography Mailing List · 原文

James A. Donald 写道：
> 那么输掉竞赛的那枚币会怎样？
>
> ……如果第二名很可能丢掉他的币，那有点太残酷了。

当同一笔交易有多个双重支付版本时，有且仅有一个会成为有效的。

收款方在确认支付有效前必须等待一小时左右。届时网络会解决所有可能的双重支付竞赛。

收到后来变为无效的双重支付的那个人，从一开始就不会认为自己得到了它。他的软件会显示交易从"未确认"变为"无效"。如有必要，UI可以隐藏交易，直到它们在区块链中有足够深度。

此外，您对事件的描述暗示了对时间和币生成速度的限制——整个网络生成币的速度，相对于新币消息传遍网络所需的时间而言很慢。

抱歉，如果我没有说清楚的话。区块间隔目标时间可能是10分钟。

每个区块都包含其创建时间。如果时间偏差超过36小时，其他节点不会在它上面工作。如果最近 6*24*30 个区块的时间跨度小于15天，说明区块生成过快，工作量证明难度加倍。每个人都用相同的链数据做同样的计算，因此在链的同一环节都会得到相同结果。

我们希望支付方能在支付传遍网络的时间内就确信交易有效，而不是在分支竞赛解决的时间内才确信。

即时不可否认性不是一个特性，但这仍然比现有系统快得多。纸质支票可能在一两周后被退票。信用卡交易在60到180天内都可能被争议。比特币交易在一两小时内就足以不可逆。

如果一个节点忽略所有它不关心的支付，它不会遭受任何不利后果。

采用我最近发布的基于交易费的激励机制，节点会有动力把收到的所有付费交易都纳入。

Satoshi Nakamoto

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

英文原文

James A. Donald wrote:
> So what happened to the coin that lost the race?
>
> ... it is a bit harsh if the guy who came second
> is likely to lose his coin.

When there are multiple double-spent versions of the same transaction, one and only one will become valid.

The receiver of a payment must wait an hour or so before believing that it's valid. The network will resolve any possible double-spend races by then.

The guy who received the double-spend that became invalid never thought he had it in the first place. His software would have shown the transaction go from "unconfirmed" to "invalid". If necessary, the UI can be made to hide transactions until they're sufficiently deep in the block chain.

Further, your description of events implies restrictions
on timing and coin generation - that the entire network
generates coins slowly compared to the time required for
news of a new coin to flood the network

Sorry if I didn't make that clear. The target time between blocks will probably be 10 minutes.

Every block includes its creation time. If the time is off by more than 36 hours, other nodes won't work on it. If the timespan over the last 6*24*30 blocks is less than 15 days, blocks are being generated too fast and the proof-of-work difficulty doubles. Everyone does the same calculation with the same chain data, so they all get the same result at the same link in the chain.

We want spenders to have certainty that their
transaction is valid at the time it takes a spend to
flood the network, not at the time it takes for branch
races to be resolved.

Instantant non-repudiability is not a feature, but it's still much faster than existing systems. Paper cheques can bounce up to a week or two later. Credit card transactions can be contested up to 60 to 180 days later. Bitcoin transactions can be sufficiently irreversible in an hour or two.

If one node is ignoring all spends that it does not
care about, it suffers no adverse consequences.

With the transaction fee based incentive system I recently posted, nodes would have an incentive to include all the paying transactions they receive.

Satoshi Nakamoto

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

Repost: How anonymous are bitcoins?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRepost: How anonymous are bitcoins?

Date2009-11-25 18:15:57 UTC

ForumBitcointalk · 原文

--------------------
bitcoinbitcoin:
比特币有多匿名？

网络上的节点能看出币是从哪个、向哪个比特币地址发送的吗？区块里是否包含比特币转到过哪里、从哪里转来的历史？节点能看出哪些比特币地址属于哪些 IP 地址吗？比特币第一次启动时有没有命令行选项可以启用 sock 代理？如果你把比特币发到一个有多个客户端通过网络地址转换（NAT）连接的 IP 地址，会发生什么？

英文原文

--------------------
bitcoinbitcoin:
How anonymous are bitcoins?

Can nodes on the network tell from which and or to which bitcoin address coins are being sent? Do blocks contain a history of where bitcoins have been transfered to and from? Can nodes tell which bitcoin addresses belong to which IP addresses? Is there a command line option to enable the sock proxy the first time that bitcoin starts? What happens if you send bitcoins to an IP address that has multiple clients connected through network address translation (NAT)?

Bitcoin P2P e-cash paper

Mon, 01 Jan 0001 00:00:00 +0000

FromSatoshi Nakamoto

SubjectBitcoin P2P e-cash paper

Date2008-11-10 02:14:30 UTC

ListCryptography Mailing List · 原文

James A. Donald 写道：
> 此外，它无法奏效，因为在所提议的系统中，跟踪谁拥有哪些币的工作由铸币税支付，而这需要通胀。

如果您对通胀问题感到困扰，很容易把它改成交易费模式。就这么简单：让任何交易的输出值比输入值少1美分。要么客户端软件自动把交易写成比预期支付值多1美分，要么由收款方承担。节点为区块找到工作量证明时的奖励可以是该区块中所有费用的总和。

Satoshi Nakamoto

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

英文原文

James A. Donald wrote:
> Furthermore, it cannot be made to work, as in the
> proposed system the work of tracking who owns what coins
> is paid for by seigniorage, which requires inflation.

If you're having trouble with the inflation issue, it's easy to tweak it for transaction fees instead. It's as simple as this: let the output value from any transaction be 1 cent less than the input value. Either the client software automatically writes transactions for 1 cent more than the intended payment value, or it could come out of the payee's side. The incentive value when a node finds a proof-of-work for a block could be the total of the fees in the block.

Satoshi Nakamoto

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

Re: Repost: How anonymous are bitcoins?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Repost: How anonymous are bitcoins?

Date2009-11-25 18:17:23 UTC

ForumBitcointalk · 原文

网络上的节点能看出币是从哪个、向哪个比特币地址发送的吗？区块里是否包含比特币转到过哪里、从哪里转来的历史？

比特币是在比特币地址之间发送的，比特币地址本质上是没有身份信息的随机数。

当你发送到一个 IP 地址时，交易仍然是写到一个比特币地址上的。IP 地址只用来连接到接收方的电脑，请求一个新的比特币地址，把交易直接交给接收方并得到确认。

区块包含一枚币被转移到过的比特币地址的历史。如果使用这些比特币地址的人的身份不为人知，而且每个地址只用一次，那么这些信息只揭示了：某个不知名的人把一定数量转给了另一个人。

能否匿名或化名，取决于你有没有在与你使用的比特币地址相关联的场合透露任何身份信息。如果你把自己的比特币地址发到网上，那就等于把这个地址以及与之相关的所有交易，跟你发帖用的名字关联起来了。如果你发帖用的网名没有跟你的真实身份关联，那你仍然是化名的。

为了更好的隐私，最好每个比特币地址只用一次。你可以用"选项 -> 更改你的地址"随时换地址。通过 IP 地址的转账每次都会自动用新的比特币地址。

节点能看出哪些比特币地址属于哪些 IP 地址吗？

不能。

比特币第一次启动时有没有命令行选项可以启用 sock 代理？

在下一个版本（0.2）中，第一次启动就通过代理运行的命令行是：
bitcoin -proxy=127.0.0.1:9050

TOR 的问题在于，比特币用来初始发现其他节点的 IRC 服务器像所有 IRC 服务器一样封禁了 TOR 出口节点。如果你之前已经连接过一次，你已经有种子了，但第一次连接时，你需要像这样提供一个节点的地址：
bitcoin -proxy=127.0.0.1:9050 -addnode=<某个ip地址>

如果有运行节点、拥有可接受入站连接的固定 IP 地址的人能把自己的 IP 发出来供 -addnode 使用，那就太好了。

如果你把比特币发到一个有多个客户端通过网络地址转换（NAT）连接的 IP 地址，会发生什么？

你把 NAT 设置里把 8333 端口转发给谁，谁就收到。如果你的路由器转发时能改端口号，你可以让多个客户端都能接收。比如，如果 8334 端口转发到某台电脑的 8333 端口，发送方就可以发到"x.x.x.x:8334"。

如果你的 NAT 不能转换端口号，目前还没有命令行选项能改比特币绑定的入站端口，但我会研究一下。

英文原文

Can nodes on the network tell from which and or to which bitcoin
address coins are being sent? Do blocks contain a history of where
bitcoins have been transfered to and from?

Bitcoins are sent to and from bitcoin addresses, which are essentially random numbers with no identifying information.

When you send to an IP address, the transaction is still written to a bitcoin address. The IP address is only used to connect to the recipient's computer to request a fresh bitcoin address, give the transaction directly to the recipient and get a confirmation.

Blocks contain a history of the bitcoin addresses that a coin has been transferred to. If the identities of the people using the bitcoin addresses are not known and each address is used only once, then this information only reveals that some unknown person transferred some amount to someone else.

The possibility to be anonymous or pseudonymous relies on you not revealing any identifying information about yourself in connection with the bitcoin addresses you use. If you post your bitcoin address on the web, then you're associating that address and any transactions with it with the name you posted under. If you posted under a handle that you haven't associated with your real identity, then you're still pseudonymous.

For greater privacy, it's best to use bitcoin addresses only once. You can change addresses as often as you want using Options->Change Your Address. Transfers by IP address automatically use a new bitcoin address each time.

Can nodes tell which bitcoin addresses belong to which IP addresses?

No.

Is there a command line option to enable the sock proxy the first
time that bitcoin starts?

In the next release (version 0.2), the command line to run it through a proxy from the first time is:
bitcoin -proxy=127.0.0.1:9050

The problem for TOR is that the IRC server which Bitcoin uses to initially discover other nodes bans the TOR exit nodes, as all IRC servers do. If you've already connected once before then you're already seeded, but for the first time, you'd need to provide the address of a node as such:
bitcoin -proxy=127.0.0.1:9050 -addnode=<someipaddress>

If someone running a node with a static IP address that can accept incoming connections could post their IP to use for -addnode, that would be great.

What happens if you send bitcoins to an IP address that has multiple
clients connected through network address translation (NAT)?

Whichever one you've set your NAT to forward port 8333 to will receive it. If your router can change the port number when it forwards, you could allow more than one client to receive. For instance, if port 8334 forwards to a computer's port 8333, then senders could send to "x.x.x.x:8334"

If your NAT can't translate port numbers, there currently isn't a command line option to change the incoming port that bitcoin binds to, but I'll look into it.

Bitcoin P2P e-cash paper

Mon, 01 Jan 0001 00:00:00 +0000

FromSatoshi Nakamoto

SubjectBitcoin P2P e-cash paper

Date2008-11-13 22:56:55 UTC

ListCryptography Mailing List · 原文

James A. Donald 写道：
> 仅仅"每个人都知道X"是不够的。我们还需要每个人都知道每个人知道X，以及每个人都知道每个人知道每个人知道每个人知道X——这和拜占庭将军问题一样，是分布式数据处理的经典难题。

工作量证明链是拜占庭将军问题的一个解决方案。我试着在那个语境中重新表述。

一批拜占庭将军每人有一台计算机，想通过暴力破解密码攻击国王的 wi-fi，他们得知密码长度为特定字符数。一旦他们刺激网络生成一个数据包，就必须在有限时间内破解密码、入侵并抹去日志，否则就会被发现并惹上麻烦。只有当大多数人同时进攻时，他们才有足够的 CPU 算力快速破解。

他们并不特别在意攻击何时进行，只在意达成一致。已经决定：任何愿意的人都可以宣布一个时间，最先被听到的时间就是官方攻击时间。问题在于网络不是瞬时的，如果两个将军在接近同一时间宣布了不同的攻击时间，有些人可能先听到一个，其他人可能先听到另一个。

他们用工作量证明链来解决这个问题。每个将军收到他最先听到的攻击时间后，就让自己的计算机求解一个极其困难的工作量证明问题，该问题的哈希中包含攻击时间。这个工作量证明非常困难，预计他们所有人同时工作10分钟才会有人找到解。一旦某位将军找到工作量证明，他就向网络广播，所有人都把当前的工作量证明计算改为包含这个工作量证明的新哈希。如果有人正在为另一个攻击时间工作，就切换到这个，因为它的工作量证明链现在更长了。

两小时后，一个攻击时间应被一条包含12个工作量证明的链哈希。每个将军只需验证工作量证明链的难度，就能估算每小时投入了多少并行 CPU 算力，并看出在规定时间内产出这么多工作量证明必定需要大多数计算机参与。他们必定都看到过它，因为工作量证明就是他们参与过的证明。如果工作量证明链展示的 CPU 算力足以破解密码，他们就可以在约定的时间安全进攻。

您问到的所有同步、分布式数据库和全局视图问题，都是通过工作量证明链解决的。

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

英文原文

James A. Donald wrote:
> It is not sufficient that everyone knows X. We also
> need everyone to know that everyone knows X, and that
> everyone knows that everyone knows that everyone knows X
> - which, as in the Byzantine Generals problem, is the
> classic hard problem of distributed data processing.

The proof-of-work chain is a solution to the Byzantine Generals' Problem. I'll try to rephrase it in that context.

A number of Byzantine Generals each have a computer and want to attack the King's wi-fi by brute forcing the password, which they've learned is a certain number of characters in length. Once they stimulate the network to generate a packet, they must crack the password within a limited time to break in and erase the logs, otherwise they will be discovered and get in trouble. They only have enough CPU power to crack it fast enough if a majority of them attack at the same time.

They don't particularly care when the attack will be, just that they all agree. It has been decided that anyone who feels like it will announce a time, and whatever time is heard first will be the official attack time. The problem is that the network is not instantaneous, and if two generals announce different attack times at close to the same time, some may hear one first and others hear the other first.

They use a proof-of-work chain to solve the problem. Once each general receives whatever attack time he hears first, he sets his computer to solve an extremely difficult proof-of-work problem that includes the attack time in its hash. The proof-of-work is so difficult, it's expected to take 10 minutes of them all working at once before one of them finds a solution. Once one of the generals finds a proof-of-work, he broadcasts it to the network, and everyone changes their current proof-of-work computation to include that proof-of-work in the hash they're working on. If anyone was working on a different attack time, they switch to this one, because its proof-of-work chain is now longer.

After two hours, one attack time should be hashed by a chain of 12 proofs-of-work. Every general, just by verifying the difficulty of the proof-of-work chain, can estimate how much parallel CPU power per hour was expended on it and see that it must have required the majority of the computers to produce that much proof-of-work in the allotted time. They had to all have seen it because the proof-of-work is proof that they worked on it. If the CPU power exhibited by the proof-of-work chain is sufficient to crack the password, they can safely attack at the agreed time.

The proof-of-work chain is how all the synchronisation, distributed database and global view problems you've asked about are solved.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

Repost: Linux/UNIX compile

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRepost: Linux/UNIX compile

Date2009-11-27 17:17:22 UTC

ForumBitcointalk · 原文

--------------------
scott:
Linux/UNIX 编译
发表于：2009 年 10 月 8 日星期四 (05:49 UTC)

能不能给出在 Linux 上编译安装比特币的说明或修改？命令行版本就太好了。

英文原文

--------------------
scott:
Linux/UNIX compile
Posted:Thu 08 of Oct, 2009 (05:49 UTC)

Can we get instructions or modifications to compile and install BitCoin on Linux? A command line version would be great.

Bitcoin P2P e-cash paper

Mon, 01 Jan 0001 00:00:00 +0000

FromSatoshi Nakamoto

SubjectBitcoin P2P e-cash paper

Date2008-11-14 18:55:35 UTC

ListCryptography Mailing List · 原文

Hal Finney 写道：
> 我认为节点有必要为每个候选链分别维护一份待处理交易列表。
> ……人们也可能会问……一个节点在同一时间平均必须跟踪多少条候选链？

幸运的是，只需要为当前最优分支维护一个待处理交易池。当最优分支有新区块到来时，ConnectBlock 会把该区块的交易从 pending-tx 池中移除。如果另一条分支变长，它会从分叉点对主分支调用 DisconnectBlock，把区块交易返回到 pending-tx 池，再对新分支调用 ConnectBlock，吸回两个分支中都包含的交易。预计这种重组会很少见，也很浅。

有了这个优化，候选分支基本不算负担。它们只是放在磁盘上，除非成为主链，否则无需理会。

或者如 James 早前提出的，如果网络广播可靠但依赖于可能缓慢的泛洪算法，这对性能有何影响？

广播很可能几乎完全可靠。如今 TCP 传输很少丢包，广播协议还有重试机制，过一段时间可以从其他节点获取数据。如果实践中广播比预期慢，可能需要增加区块间隔目标时间以避免浪费资源。我们希望区块传播通常远快于生成，否则节点会把太多时间花在过时区块上。

我计划运行一个自动化测试：计算机随机地互相发送支付，并随机丢包。

3. 比特币系统被证明对社会有用且有价值，于是节点运营者觉得自己的努力在为世界做有益的贡献（类似于各种 "@Home" 计算项目，人们自愿捐出算力做公益）。

在这种情况下，我觉得单纯的利他主义就足以维持网络正常运行。

如果我们能解释清楚，这对自由主义者观点很有吸引力。不过我更擅长写代码，不擅长写文字。

Satoshi Nakamoto

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

英文原文

Hal Finney wrote:
> I think it is necessary that nodes keep a separate
> pending-transaction list associated with each candidate chain.
> ... One might also ask ... how many candidate chains must
> a given node keep track of at one time, on average?

Fortunately, it's only necessary to keep a pending-transaction pool for the current best branch. When a new block arrives for the best branch, ConnectBlock removes the block's transactions from the pending-tx pool. If a different branch becomes longer, it calls DisconnectBlock on the main branch down to the fork, returning the block transactions to the pending-tx pool, and calls ConnectBlock on the new branch, sopping back up any transactions that were in both branches. It's expected that reorgs like this would be rare and shallow.

With this optimisation, candidate branches are not really any burden. They just sit on the disk and don't require attention unless they ever become the main chain.

Or as James raised earlier, if the network broadcast
is reliable but depends on a potentially slow flooding
algorithm, how does that impact performance?

Broadcasts will probably be almost completely reliable. TCP transmissions are rarely ever dropped these days, and the broadcast protocol has a retry mechanism to get the data from other nodes after a while. If broadcasts turn out to be slower in practice than expected, the target time between blocks may have to be increased to avoid wasting resources. We want blocks to usually propagate in much less time than it takes to generate them, otherwise nodes would spend too much time working on obsolete blocks.

I'm planning to run an automated test with computers randomly sending payments to each other and randomly dropping packets.

3. The bitcoin system turns out to be socially useful and valuable, so
that node operators feel that they are making a beneficial contribution
to the world by their efforts (similar to the various "@Home" compute
projects where people volunteer their compute resources for good causes).

In this case it seems to me that simple altruism can suffice to keep the
network running properly.

It's very attractive to the libertarian viewpoint if we can explain it properly. I'm better with code than with words though.

Satoshi Nakamoto

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

Re: Repost: Linux/UNIX compile

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Repost: Linux/UNIX compile

Date2009-11-27 17:27:09 UTC

ForumBitcointalk · 原文

Linux 版正在路上。Martti 的 Linux 移植已经合并进主代码分支，New Liberty Standard 一直在测试它。它会包含在下一个版本 0.2 里。

命令行版在 0.2 之后的待办事项里。

英文原文

The Linux version is on its way. Martti's Linux port was merged into the main code branch and New Liberty Standard has been testing it. It'll be in the next release, version 0.2.

Command line is on the to-do list after 0.2.

[OLD THREAD] Bitcoin version 0.2 development status

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

Title[OLD THREAD] Bitcoin version 0.2 development status

Date2009-11-27 22:48:39 UTC

ForumBitcointalk · 原文

我们一直在为下一个版本努力改进。Martti (sirius-m) 加了一些好功能，让它更友好、更容易在后台运行：
- 最小化到系统托盘选项
- 开机自动启动选项，让你可以在后台自动保持运行
- 新的选项对话框布局
- Windows 安装包（EXE），除了压缩包下载之外

我一直在打磨网络代码，做一些改进，也为将来的功能打基础。0.2 版还会有：
- 生成货币的多处理器支持
- 代理支持

英文原文

We've been working hard on improvements for the next version release. Martti (sirius-m) added some nice features to make it more user friendly and easier to run in the background:
- Minimize to system tray option
- Autostart on boot option so you can keep it running in the background automatically
- New options dialog layout
- Setup EXE for Windows, in addition to the archive download

I've been working on a number of refinements to the networking code and laying the groundwork for future functionality. Also coming in version 0.2:
- Multi-processor support for coin generation
- Proxy support

Bitcoin P2P e-cash paper

Mon, 01 Jan 0001 00:00:00 +0000

FromSatoshi Nakamoto

SubjectBitcoin P2P e-cash paper

Date2008-11-15 04:43:00 UTC

ListCryptography Mailing List · 原文

我会尽快发布源代码，作为参考来澄清所有这些实现问题。

Ray Dillinger (Bear) 写道：
> 当一枚币被花掉时，买卖双方用数字签名签署一笔（盲化的）交易记录。

只有买方签名，没有盲化。

如果有人双重支付，那么交易记录可以被去盲化，揭示作弊者的身份。

不使用身份，也没有追索机制。一切都是预防。

这通过相当标准的切分-选择算法实现，买方用秘密份额回应多个挑战。

没有挑战，也没有秘密份额。基本交易就是第2节图中展示的那样：一个（买方的）签名，满足前一笔交易的公钥；以及一个新的（卖方的）公钥，下次花掉它时必须满足该公钥。

他们在工作时也可能收到与正试图扩展的链一样长的链，其中最后几个"环"是与他们正在工作的链*不*相同的环。这些他们忽略。

没错，如果长度相等，就保留最先收到的那个来打破平局。

如果它包含双重支付，他们就创建一笔"交易"作为双重支付的证明，加入他们的 pool A，广播出去，继续工作。

没必要像那样报告"双重支付证明"。如果同一条链包含两笔支付，那么该区块无效并被拒绝。

区块工作量证明不足时也一样。该区块无效并被拒绝，没必要为此传播报告。每个节点都能在转发前看出并拒绝它。

如果有两条竞争的链，每条包含同一笔交易的不同版本，一条试图把钱给一个人，另一条试图把同一笔钱给另一个人，那么裁决哪笔支付有效正是整个工作量证明链的意义所在。

我们不是在"盯梢"双重支付以拉响警报、抓作弊者。我们只是裁决哪笔支付有效。交易收款方必须等待几个区块，以确保裁决有时间完成。想作弊的人可以尽情同时双重支付，而他们能得到的唯一结果是：几个区块内，一笔支付有效，其余无效。一旦主链中已有了一笔支付，任何后续的双重支付都会被立即拒绝。

即使更早的那笔支付还没进入链，只要它已在所有节点的池中，那么所有已持有第一笔支付的节点都会拒绝第二笔支付。

如果新链被接受，他们就放弃添加当前环，把 pool L 中的所有交易倒回 pool A（连同开始工作以来收到或创建的交易），从 pool A 中删除已是新链某一环组成部分的那些交易记录，再开始工作，试图扩展新链。

没错。每当有新交易进来他们也会刷新，所以 L 基本上一直包含 A 中的所有内容。

CPU 密集型的数字签名算法，用于签署包含新区块 L 的链。

它是 Hashcash 式 SHA-256 工作量证明（零的部分原像），不是签名。

有没有机制确保"链"不只由最快的 3 或 4 个节点添加的环组成？因为一条广播的交易记录很容易漏过那 3 或 4 个节点，如果那样，而这些节点又继续主导链，那么这笔交易可能永远加不进去。

如果您把它想成 CPU 密集型的数字签名，那您可能是把它想成谁先完成漫长操作谁就赢的竞赛。

这个工作量证明是 Hashcash 式 SHA-256 碰撞求解。这是一个无记忆的过程：每秒做数百万次哈希，每次都有微小概率找到解。最快的 3 或 4 个节点的优势只与其占总 CPU 算力的份额成正比。任何人在任何时刻找到解的概率都与其 CPU 算力成正比。

会有交易费，所以节点有动力接收并纳入尽可能多的交易。当创造的币总量达到预定上限后，节点最终将完全靠交易费获得补偿。

另外，为链添加一个环的工作量要求应随该链前一周添加的环数变化（再次呈指数变化），使币生成速率（从而通胀）受到严格控制。

没错。

要扩展，您需要币聚合。需要一种"可证明"的交易：某人收回十个单币，创造一枚面值为十的新币，等等。

每笔交易都是这样的。第9节"合并与拆分价值"。

Satoshi Nakamoto

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

英文原文

I'll try and hurry up and release the sourcecode as soon as possible to serve as a reference to help clear up all these implementation questions.

Ray Dillinger (Bear) wrote:
> When a coin is spent, the buyer and seller digitally sign a (blinded)
> transaction record.

Only the buyer signs, and there's no blinding.

If someone double spends, then the transaction record
can be unblinded revealing the identity of the cheater.

Identities are not used, and there's no reliance on recourse. It's all prevention.

This is done via a fairly standard cut-and-choose
algorithm where the buyer responds to several challenges
with secret shares

No challenges or secret shares. A basic transaction is just what you see in the figure in section 2. A signature (of the buyer) satisfying the public key of the previous transaction, and a new public key (of the seller) that must be satisfied to spend it the next time.

They may also receive chains as long as the one they're trying to
extend while they work, in which the last few "links" are links
that are *not* in common with the chain on which they're working.
These they ignore.

Right, if it's equal in length, ties are broken by keeping the earliest one received.

If it contains a double spend, then they create a "transaction"
which is a proof of double spending, add it to their pool A,
broadcast it, and continue work.

There's no need for reporting of "proof of double spending" like that. If the same chain contains both spends, then the block is invalid and rejected.

Same if a block didn't have enough proof-of-work. That block is invalid and rejected. There's no need to circulate a report about it. Every node could see that and reject it before relaying it.

If there are two competing chains, each containing a different version of the same transaction, with one trying to give money to one person and the other trying to give the same money to someone else, resolving which of the spends is valid is what the whole proof-of-work chain is about.

We're not "on the lookout" for double spends to sound the alarm and catch the cheater. We merely adjudicate which one of the spends is valid. Receivers of transactions must wait a few blocks to make sure that resolution has had time to complete. Would be cheaters can try and simultaneously double-spend all they want, and all they accomplish is that within a few blocks, one of the spends becomes valid and the others become invalid. Any later double-spends are immediately rejected once there's already a spend in the main chain.

Even if an earlier spend wasn't in the chain yet, if it was already in all the nodes' pools, then the second spend would be turned away by all those nodes that already have the first spend.

If the new chain is accepted, then they give up on adding their
current link, dump all the transactions from pool L back into pool
A (along with transactions they've received or created since
starting work), eliminate from pool A those transaction records
which are already part of a link in the new chain, and start work
again trying to extend the new chain.

Right. They also refresh whenever a new transaction comes in, so L pretty much contains everything in A all the time.

CPU-intensive digital signature algorithm to
sign the chain including the new block L.

It's a Hashcash style SHA-256 proof-of-work (partial pre-image of zero), not a signature.

Is there a mechanism to make sure that the "chain" does not consist
solely of links added by just the 3 or 4 fastest nodes? 'Cause a
broadcast transaction record could easily miss those 3 or 4 nodes
and if it does, and those nodes continue to dominate the chain, the
transaction might never get added.

If you're thinking of it as a CPU-intensive digital signing, then you may be thinking of a race to finish a long operation first and the fastest always winning.

The proof-of-work is a Hashcash style SHA-256 collision finding. It's a memoryless process where you do millions of hashes a second, with a small chance of finding one each time. The 3 or 4 fastest nodes' dominance would only be proportional to their share of the total CPU power. Anyone's chance of finding a solution at any time is proportional to their CPU power.

There will be transaction fees, so nodes will have an incentive to receive and include all the transactions they can. Nodes will eventually be compensated by transaction fees alone when the total coins created hits the pre-determined ceiling.

Also, the work requirement for adding a link to the chain should
vary (again exponentially) with the number of links added to that
chain in the previous week, causing the rate of coin generation
(and therefore inflation) to be strictly controlled.

Right.

You need coin aggregation for this to scale. There needs to be
a "provable" transaction where someone retires ten single coins
and creates a new coin with denomination ten, etc.

Every transaction is one of these. Section 9, Combining and Splitting Value.

Satoshi Nakamoto

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

Bitcoin P2P e-cash paper

Mon, 01 Jan 0001 00:00:00 +0000

FromSatoshi Nakamoto

SubjectBitcoin P2P e-cash paper

Date2008-11-15 18:02:00 UTC

ListCryptography Mailing List · 原文

Ray Dillinger 写道：
> 实现这一点的一种方法是，
> 让收到币的人生成一对非对称密钥对，
> 然后把其中一半随交易一起公布。
> 以后为了花费这枚币，他/她必须
> 证明自己持有该非对称密钥对的另一半，
> 可能是用它对新卖方提供的密钥进行签名。

对，这是 ECC 数字签名。每笔交易都使用一对新的密钥对。

它不是假名制（用 nyms 标识人的身份）意义上的匿名，但至少具有一点假名性：币的下一个动作可以被识别为来自该币的所有者。

嗯。这让我有些不舒服。你是说
根本不做任何识别和排除不合作节点的努力？
我觉得这会导致麻烦，甚至可能引发 DOS 攻击。

我们对识别任何人没有任何依赖。如你所说，那是徒劳的，sock puppets（傀儡账号）就能轻而易举地将其攻破。

确立某人真实性的凭证，是其能够提供 CPU 算力的能力。

等到……等到什么？人们怎么知道一笔交易
何时变得不可撤销？所谓"几个"区块是三个？
三十个？一百个？这取决于节点数量吗？
是跟节点数量呈对数关系还是线性关系？

第 11 节计算了受攻击时的最坏情况。通常，5 或 10 个区块就足够了。如果你卖的东西不值得攻击者发动全网规模的攻击来窃取，实际中可以把等待时间压得更短。

但在没有身份的情况下，如果他们已经拿到了
用双重支付骗来的货物（网站访问权、下载，等等），
即使花费无效，他们也没有什么损失。
商家只能拿着"无效"的币吃哑巴亏，
除非他们等上那个神奇的"几个区块"
（他们又怎么知道要等几个？），
然后再把花费者视为已付款。

消费者不会接受：花了币，还要等一个小时
交易清算后才能做他花币要做的事。
商家也不会接受：当发现收到的币无效是因为
顾客双重支付时，无法向顾客追偿。

这是版本 2 层面的问题，我相信对大多数应用来说都可以解决得相当令人满意。

关键是抢先把你的交易在网络上传播开。想想六度空间——它是呈指数扩散的。一笔交易大概只需约 2 分钟就能广泛传播开，迟到的竞争者在第一笔交易席卷整个网络之前，几乎没有机会抢占到多少节点。在这 2 分钟里，商家的节点可以监视是否有双重支付的交易。双重支付者没法在商家收不到的情况下把他的替代交易广播到全世界，所以他必须先等一等才能动手。

如果真实交易传播到了 90% 的节点，而双重支付的交易只传到了 10%，那么双重支付者只有 10% 的概率不用付钱跑掉，90% 的概率他的钱会被花掉。对于几乎所有类型的商品，骗子这么干都不划算。

像网站访问权、下载这类信息商品是不可销赃的（non-fencible）。没人能靠偷网站访问权或下载为生。他们去文件共享网络就能偷到。大多数即时获取型产品并没有很大的被偷动机。

如果商家真的被盗成问题，他们可以让顾客等 2 分钟，或者等电子邮件里的某样东西——很多商家已经这样做了。如果真想优化，对于大文件下载，可以在交易被确认双重支付后在下载中途取消下载。如果是网站访问权，通常让顾客先访问 5 分钟、然后在交易被拒绝时切断访问，也不算什么大事。很多这类网站本来就有免费试用。

Satoshi Nakamoto

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

英文原文

Ray Dillinger wrote:
> One way to do this would be
> to have the person recieving the coin generate an asymmetric
> key pair, and then have half of it published with the
> transaction. In order to spend the coin later, s/he must
> demonstrate posession of the other half of the asymmetric
> key pair, probably by using it to sign the key provided by
> the new seller.

Right, it's ECC digital signatures. A new key pair is used for every
transaction.

It's not pseudonymous in the sense of nyms identifying people, but it
is at least a little pseudonymous in that the next action on a coin
can be identified as being from the owner of that coin.

Mmmm. I don't know if I'm comfortable with that. You're saying
there's no effort to identify and exclude nodes that don't
cooperate? I suspect this will lead to trouble and possible DOS
attacks.

There is no reliance on identifying anyone. As you've said, it's
futile and can be trivially defeated with sock puppets.

The credential that establishes someone as real is the ability to
supply CPU power.

Until.... until what? How does anybody know when a transaction
has become irrevocable? Is "a few" blocks three? Thirty? A
hundred? Does it depend on the number of nodes? Is it logarithmic
or linear in number of nodes?

Section 11 calculates the worst case under attack. Typically, 5 or
10 blocks is enough for that. If you're selling something that
doesn't merit a network-scale attack to steal it, in practice you
could cut it closer.

But in the absence of identity, there's no downside to them
if spends become invalid, if they've already received the
goods they double-spent for (access to website, download,
whatever). The merchants are left holding the bag with
"invalid" coins, unless they wait that magical "few blocks"
(and how can they know how many?) before treating the spender
as having paid.

The consumers won't do this if they spend their coin and it takes
an hour to clear before they can do what they spent their coin on.
The merchants won't do it if there's no way to charge back a
customer when they find the that their coin is invalid because
the customer has doublespent.

This is a version 2 problem that I believe can be solved fairly
satisfactorily for most applications.

The race is to spread your transaction on the network first. Think 6
degrees of freedom -- it spreads exponentially. It would only take
something like 2 minutes for a transaction to spread widely enough
that a competitor starting late would have little chance of grabbing
very many nodes before the first one is overtaking the whole network.
During those 2 minutes, the merchant's nodes can be watching for a
double-spent transaction. The double-spender would not be able to
blast his alternate transaction out to the world without the merchant
getting it, so he has to wait before starting.

If the real transaction reaches 90% and the double-spent tx reaches
10%, the double-spender only gets a 10% chance of not paying, and 90%
chance his money gets spent. For almost any type of goods, that's
not going to be worth it for the scammer.

Information based goods like access to website or downloads are
non-fencible. Nobody is going to be able to make a living off
stealing access to websites or downloads. They can go to the file
sharing networks to steal that. Most instant-access products aren't
going to have a huge incentive to steal.

If a merchant actually has a problem with theft, they can make the
customer wait 2 minutes, or wait for something in e-mail, which many
already do. If they really want to optimize, and it's a large
download, they could cancel the download in the middle if the
transaction comes back double-spent. If it's website access,
typically it wouldn't be a big deal to let the customer have access
for 5 minutes and then cut off access if it's rejected. Many such
sites have a free trial anyway.

Satoshi Nakamoto

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

Re: A few suggestions

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: A few suggestions

Date2009-12-09 18:45:10 UTC

ForumBitcointalk · 原文

建议很有帮助，谢谢。

引用自：madhatter，2009 年 12 月 9 日 05:34:46 AM（https://bitcointalk.org/index.php?topic=12.msg40#msg40）

当比特币软件与一个节点建立连接时（客户端 TCP 套接字），让客户端先发送握手字符串。现在是服务器端（服务器 TCP 套接字）先发送。我的理由当然是匿名性。ISP 对客户端做端口扫描、从而发现它们在运行这个程序，实在太容易了。

这是个好主意。接受连接的一方只需要在收到有效握手之前不发送任何数据。任何端口扫描都只能得到一个不会主动暴露身份的死连接。

引用：

在握手过程中使用某种加密（与上面那条建议/需求相关），以在 DPI（深度包检测）面前混淆这个软件是什么。我真正想到的是那些不自由（指自由层面）国家的人，比如中国/伊朗。

我考虑过最终给所有连接加上 SSL。我认为，面对 DPI，任何比 SSL 弱的手段都没有意义。一个更直接的办法可能是走 TOR 连接，0.2 版会支持。

引用：

需要某种 API，以便这个系统能和网站集成、提供即开即用的服务。一个简单的 https 回执机制会大有帮助。让客户端把每笔入账支付连同所有相关信息 POST 到一个 https 网址，并提供状态更新。另外出账支付机制也很好，这样就可以自动（批量）向外付款。状态可以通过 https 回执接口返回。

这是 0.2 之后议程上的主要事项之一。

引用：

静态端口/随机端口。加一个设置项，随机分配运行端口（防火墙特别严格时也可以设为静态）。

是的，如果端口号永远不变，其他隐身手段就没什么意义了。

引用：

UPnP 支持。让客户端在上游路由器上自动创建端口转发。默认开启，可以在选项菜单里关掉。

我很想试试 UPnP。大多数 P2P 客户端默认都开 UPnP 吗？

引用：

能编译出无头（纯控制台）版本给 *NIX 系统。也支持只作为网络服务运行。最好有个能 telnet 进去的控制端口（甚至 unix socket 也行）。

我还在考虑管理接口怎么设计最好。也许是用命令行与后台守护进程通信，查询收到的交易、发起转账。那样对自动化更友好。或者在 80 以外的某个端口上开一个 http 接口，用浏览器管理？

英文原文

Helpful suggestions, thanks.

Quote from: madhatter on December 09, 2009, 05:34:46 AM（https://bitcointalk.org/index.php?topic=12.msg40#msg40）- When the bitcoin software establishes a connection with a peer (client TCP socket) have the client send the handshake string. Right now you have the server (server TCP socket) send the handshake. My reasons for this are anonymity of course. It is far too easy for ISPs to portscan clients and detect they are running this program.
That's a good idea. The side accepting the connection just needs to withhold from sending anything until it receives a valid handshake. Any portscan would only get a dead connection that doesn't volunteer to identify itself.

Quote- Use some sort of encryption during the handshake (sort of goes with the statement/request above) to obfuscate what the software is during DPI (deep packet inspection). I am really thinking about people in non-free (as in freedom) countries such as China/Iran.
I have thought about eventually SSLing all the connections. I assume anything short of SSL would be pointless against DPI. Maybe a better more immediate solution is to connect through TOR, which will be possible with 0.2.

Quote- Some sort of an API is needed so that this system can be integrated with websites to provide instant-on services. A simple https receipt mechanism would do wonders. Have the client post each incoming payment to an https url with all of the relevant information and provide status updates. Also an outbound payment mechanism would be nice. So one could automate payments (and batch payments) outbound. Status could be returned via the https receipt interface.
That's one of the main things on the agenda after 0.2.

Quote- Static port/Random port. Have a setting to randomly assign the port that it runs on. (also be able to set it statically for very restrictive firewalls).
Yeah, the other stealth stuff would be kinda pointless if it's always the same port number.

Quote- UPnP support. Have the client automatically create the port forward on upstream routers. Enabled by default. Can be turned off in the options menu.
I'm looking forward to trying UPnP. Do most P2P clients typically have UPnP enabled by default?

Quote- Ability to compile a headless (console only) install for *NIX systems. Also have the ability to just run as a network service. Perhaps with a telnet-able port for control (or even a unix socket would be ok).
I'm still thinking about how best to structure the management interface. Maybe command line commands to communicate with the background daemon to query transactions received and initiate sending transfers. That would be more automation friendly. Or what about an http interface on some port other than 80 to manage it with a browser?

Bitcoin P2P e-cash paper

Mon, 01 Jan 0001 00:00:00 +0000

FromSatoshi Nakamoto

SubjectBitcoin P2P e-cash paper

Date2008-11-17 17:24:43 UTC

ListCryptography Mailing List · 原文

James A. Donald 写道：
> > 幸运的是，我们只需要为
> > 当前最佳分支维护一个
> > 待处理交易池。
>
> 这就要求我们知道，也就是说一个诚实
> 守规矩的对等方，其通信和数据存储
> 都工作正常，知道当前的最佳分支是什么——

我的意思是，一个节点只为它所拥有的最佳分支维护待处理交易池。就是它当前认为是最佳的那条分支。这正是它将尝试在其上生成区块的分支，也是它需要这个池的全部用途。

> 广播可能几乎完全
> 可靠。

与其假设每条消息至少送达一次，
我们必须设计一种机制，使信息即使
通过经常丢失的消息传递也能送达。

我认为点对点网络的广播机制我已经想清楚了。

每个节点向其邻居发送一份库存清单，列出它拥有的新区块和交易的哈希。邻居们请求它们还没有的条目。如果超时后条目仍未送达，它们会向另一个拥有该条目的邻居请求。由于所有或大多数邻居最终都会拥有每个条目，即使与某个邻居的通信出了问题，它们也可以逐个尝试从其他邻居那里获取。

这种清单—请求—数据（inventory-request-data）方案会引入一点延迟，但通过让多余的数据块不进入传输队列、节省带宽，最终反而有助于提速。

你已经有了一个
大纲和设计方案，这是很大的进步，
但魔鬼藏在细节里。

我相信在过去一年半的编码过程中，我已经把所有这些小细节都理清了，而且细节确实很多。论文中没有涉及功能层面的细节，但源代码很快就会发布。我把主要文件发给你了。（目前可应要求提供，完整版即将发布）

Satoshi Nakamoto

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

英文原文

James A. Donald wrote:
> > Fortunately, it's only necessary to keep a
> > pending-transaction pool for the current best branch.
>
> This requires that we know, that is to say an honest
> well behaved peer whose communications and data storage
> is working well knows, what the current best branch is -

I mean a node only needs the pending-tx pool for the best branch it
has. The branch that it currently thinks is the best branch.
That's the branch it'll be trying to make a block out of, which is
all it needs the pool for.

> Broadcasts will probably be almost completely
> reliable.

Rather than assuming that each message arrives at least
once, we have to make a mechanism such that the
information arrives even though conveyed by messages
that frequently fail to arrive.

I think I've got the peer networking broadcast mechanism covered.

Each node sends its neighbours an inventory list of hashes of the
new blocks and transactions it has. The neighbours request the
items they don't have yet. If the item never comes through after a
timeout, they request it from another neighbour that had it. Since
all or most of the neighbours should eventually have each item,
even if the coms get fumbled up with one, they can get it from any
of the others, trying one at a time.

The inventory-request-data scheme introduces a little latency, but
it ultimately helps speed more by keeping extra data blocks off the
transmit queues and conserving bandwidth.

You have an outline
and proposal for such a design, which is a big step
forward, but the devil is in the little details.

I believe I've worked through all those little details over the
last year and a half while coding it, and there were a lot of them.
The functional details are not covered in the paper, but the
sourcecode is coming soon. I sent you the main files.
(available by request at the moment, full release soon)

Satoshi Nakamoto

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

Re: A few suggestions

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: A few suggestions

Date2009-12-10 19:31:49 UTC

ForumBitcointalk · 原文

引用自：madhatter2，2009 年 12 月 10 日 02:00:17 PM（https://bitcointalk.org/index.php?topic=12.msg44#msg44）

前端也可以跑在 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 账号 PM 或邮件发我，我给你开权限。

引用：

我主要是 Linux/BSD 方向的，想在这方面出力。

太好了，这正是我不擅长的。比如 Linux 上"开机启动比特币"怎么做最好，我还没研究过。在 Windows 上，这个选项就是在"启动"文件夹里加/删一个图标。

英文原文

Quote from: madhatter2 on December 10, 2009, 02:00:17 PM（https://bitcointalk.org/index.php?topic=12.msg44#msg44）Front ends can also be ran on clients with very low cpu power such as mobile phones.
That's a good approach for mobile. Programmatic API used by PHP (any language) to present a web UI covers remote admin, mobile and any other client that can't be online all the time with a static IP. It would be like webmail. It would be easier for new users to get started if they only need to create an account on a website, not install software.

QuoteThe app could be pre-seeded before downloading. Pre-seeding would also cure the TOR+IRC problem. I know that people will want to run this system over I2P+TOR.
Yeah, we can phase out IRC when there are enough static nodes to preprogram a seed list. Once you get seeded, you don't need IRC.

QuoteAlso you could pre-seed the blocks so they won't have to be downloaded upon initial run. (Downloading 28,000 blocks on a slower ADSL takes forever I couldn't imagine how long it would take when there are millions of blocks -- a lifetime).
There were some issues in 0.1.5 where the initial block download could get bogged down. 0.2 has code to make sure it goes smoothly. It ought to take less than an hour, I think. I need to hurry up and get 0.2 out the door.

The blocks increase linearly, it'll be decades before it's millions. In theory, the block download time should top out 8 months from now when Moore's Law will be growing faster than the block chain.

QuoteCan you give me CVS access or something? (If not, can I send you patches?) I'd like to help out.
It's SVN on sourceforge. PM or e-mail me your sourceforge account and I'll give you access.

QuoteI am mostly a Linux/BSD guy and I would like to lend my expertise in those areas.
That's great because that's where I have less expertise. For instance, I haven't researched the best way to do the "Start Bitcoin on system startup" feature on Linux. On Windows, the option adds/removes an icon in the Startup folder.

[bitcoin-list] Welcome

Mon, 01 Jan 0001 00:00:00 +0000

FromSatoshi Nakamoto

Subject[bitcoin-list] Welcome

Date2008-12-10 17:00:23 UTC

Listbitcoin-list · 原文

欢迎加入 Bitcoin 邮件列表！

英文原文

Welcome to the Bitcoin mailing list!

Re: Questions about Bitcoin

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Questions about Bitcoin

Date2009-12-10 20:49:02 UTC

ForumBitcointalk · 原文

1-3:
要达到那个级别的匿名性，你需要通过 TOR 连接，0.2 版就可以，离发布只有几周了。到时候我会发 TOR 使用说明。

4:
0.1.5 版：备份整个 %appdata%\Bitcoin 目录。
0.2 版：只需备份 wallet.dat。

5:
不行。整个设计就是为了防止那种做法得逞。

6:
那些币永远无法找回，总流通量就少了。既然有效流通量减少，剩下的币就都稍微更值钱一点。这跟政府印钞、现有货币贬值正好相反。

7:
现在是 29,296 个区块。流通量是区块数乘以 50，所以当前流通量是 1,464,800 bc。

如果你只有 24000 个区块，说明初始区块下载还没完成。退出比特币再重新启动。0.2 版的初始区块下载更好/更快。

8:
目前通常是几百个。现在很容易，但随着网络增长会变难。

9:
好问题，是 TCP。网站需要更新，写成 TCP 8333 端口。

端口转发是为了让其他节点能连到你，这样你能连上更多节点，连接更稳定。别人要通过 IP 地址给你付款，你也需要它。

10:
不，其他节点不会接受那样。

开源意味着任何人都可以独立审查代码。如果是闭源，没人能验证安全性。我认为这种性质的程序必须开源。

11:
慢的机器产的币少。跟 CPU 速度成正比。

12:
还会有更多。

13:
它用的是一个叫 Berkeley DB 的事务型数据库。系统崩溃不会丢数据。交易一收到就立刻写入数据库。

14:
目前你可以把总区块数乘以 50 就行。比特币网络已经运行快一年了。设计和编码从 2007 年开始。

英文原文

1-3:
For that level of anonymity you need to connect through TOR, which will be possible with version 0.2, which is only a few weeks away. I'll post TOR instructions at that time.

4:
Version 0.1.5: backup the whole %appdata%\Bitcoin directory.
Version 0.2: you can backup just wallet.dat.

5:
Nope. The whole design is all about preventing that from working.

6:
Those coins can never be recovered, and the total circulation is less. Since the effective circulation is reduced, all the remaining coins are worth slightly more. It's the opposite of when a government prints money and the value of existing money goes down.

7:
It's currently 29,296 blocks. The circulation is the number of blocks times 50, so the current circulation is 1,464,800 bc.

If you only have 24k blocks, it must not have finished the initial block download. Exit bitcoin and start it again. Version 0.2 is better/faster at the initial block download.

8:
Typically a few hundred right now. It's easy now but it'll get harder as the network grows.

9:
Good question, it's TCP. The website needs to be updated to say TCP port 8333.

The port forwarding is so other nodes can connect to you, so it helps you stay connected because you are able to be connected with more nodes. You also need it to receive payments by IP address.

10:
No, the other nodes won't accept that.

Being open source means anyone can independently review the code. If it was closed source, nobody could verify the security. I think it's essential for a program of this nature to be open source.

11:
Slower machines produce fewer coins. It's proportional to CPU speed.

12:
There are more coming.

13:
It uses a transactional database called Berkeley DB. It will not lose data in a system crash. Transactions are written to the database immediately when they're received.

14:
For now, you can just multiply the total blocks by 50. The Bitcoin network has been running for almost a year now. The design and coding started in 2007.

Bitcoin v0.1 released

Mon, 01 Jan 0001 00:00:00 +0000

FromSatoshi Nakamoto

SubjectBitcoin v0.1 released

Date2009-01-08 19:27:40 UTC

ListCryptography Mailing List · 原文

宣布发布 Bitcoin 的第一个版本：一种使用点对点网络防止双重支付的全新电子现金系统。它是完全去中心化的，没有服务器或中央权威机构。

截图见 bitcoin.org。

下载链接：
http://downloads.sourceforge.net/bitcoin/bitcoin-0.1.0.rar

目前仅支持 Windows。附带开源 C++ 代码。

- 将文件解压到一个目录
- 运行 BITCOIN.EXE
- 它会自动连接到其他节点

如果你能让一个接受传入连接的节点持续运行，会对网络大有帮助。防火墙上的 8333 端口需要打开以接收传入连接。

该软件仍处于 alpha 测试阶段，带有实验性质。不能保证在必要时系统的状态不会被重启，尽管我已尽最大努力在其中构建了可扩展性和版本控制。

你可以通过让别人转给你一些币来获得币，或者打开 Options->Generate Coins 让节点运行并生成区块。我把初始的工作量证明难度设得极低，所以在开头的一小段时间里，一台普通 PC 只需几个小时就能生成币。当竞争促使自动调整机制推高难度时，挖币会难得多。生成的币必须等待 120 个区块才能成熟，然后才能花。

发送货币有两种方式。如果收款人在线，你可以输入他们的 IP 地址，它会连接过去、获取一个新的公钥并附带备注发送交易。如果收款人不在线，可以发送到他们的 Bitcoin 地址，即他们给你的公钥的哈希值。他们下次联网并收到该交易所在区块时就会收到这笔交易。这种方法的缺点是备注信息不会被发送，而且如果地址被多次使用，可能会损失一点隐私；但如果双方无法同时在线，或者收款人无法接收传入连接，这是一个实用的替代方案。

总发行量将为 21,000,000 币。它们将在节点生成区块时分配给网络节点，数量每 4 年减半。

前 4 年：10,500,000 币
后 4 年：5,250,000 币
后 4 年：2,625,000 币
后 4 年：1,312,500 币
依此类推……

当发行完毕后，如有需要，系统可以靠交易费维持。它基于公开市场竞争，届时应该总会有愿意免费处理交易的节点。

Satoshi Nakamoto

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

英文原文

Announcing the first release of Bitcoin, a new electronic cash
system that uses a peer-to-peer network to prevent double-spending.
It's completely decentralized with no server or central authority.

See bitcoin.org for screenshots.

Download link:
http://downloads.sourceforge.net/bitcoin/bitcoin-0.1.0.rar

Windows only for now. Open source C++ code is included.

- Unpack the files into a directory
- Run BITCOIN.EXE
- It automatically connects to other nodes

If you can keep a node running that accepts incoming connections,
you'll really be helping the network a lot. Port 8333 on your
firewall needs to be open to receive incoming connections.

The software is still alpha and experimental. There's no guarantee
the system's state won't have to be restarted at some point if it
becomes necessary, although I've done everything I can to build in
extensibility and versioning.

You can get coins by getting someone to send you some, or turn on
Options->Generate Coins to run a node and generate blocks. I made
the proof-of-work difficulty ridiculously easy to start with, so
for a little while in the beginning a typical PC will be able to
generate coins in just a few hours. It'll get a lot harder when
competition makes the automatic adjustment drive up the difficulty.
Generated coins must wait 120 blocks to mature before they can be
spent.

There are two ways to send money. If the recipient is online, you
can enter their IP address and it will connect, get a new public
key and send the transaction with comments. If the recipient is
not online, it is possible to send to their Bitcoin address, which
is a hash of their public key that they give you. They'll receive
the transaction the next time they connect and get the block it's
in. This method has the disadvantage that no comment information
is sent, and a bit of privacy may be lost if the address is used
multiple times, but it is a useful alternative if both users can't
be online at the same time or the recipient can't receive incoming
connections.

Total circulation will be 21,000,000 coins. It'll be distributed
to network nodes when they make blocks, with the amount cut in half
every 4 years.

first 4 years: 10,500,000 coins
next 4 years: 5,250,000 coins
next 4 years: 2,625,000 coins
next 4 years: 1,312,500 coins
etc...

When that runs out, the system can support transaction fees if
needed. It's based on open market competition, and there will
probably always be nodes willing to process transactions for free.

Satoshi Nakamoto

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

Re: Questions about Bitcoin

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Questions about Bitcoin

Date2009-12-11 17:58:57 UTC

ForumBitcointalk · 原文

没错，用发送到 IP 的选项，你就是发给应答那个 IP 的人。发到比特币地址就没有这个问题。

计划是实现一个 IP + 比特币地址的选项，兼得两者之长。它仍然每次交易用不同地址，但接收方会用给定的比特币地址对一次性地址签名，证明它属于预期的接收方。

英文原文

That's true, with the send-to-IP option, you are sending to whoever answers that IP. Sending to a bitcoin address doesn't have that problem.

The plan is to implement an IP + bitcoin address option that would have the benefits of both. It would still use a different address for each transaction, but the receiver would sign the one-time-use address with the given bitcoin address to prove it belongs to the intended receiver.

[bitcoin-list] Bitcoin v0.1.2 now available

Mon, 01 Jan 0001 00:00:00 +0000

FromSatoshi Nakamoto

Subject[bitcoin-list] Bitcoin v0.1.2 now available

Date2009-01-11 22:32:18 UTC

Listbitcoin-list · 原文

Bitcoin v0.1.2 现已可下载。

下载链接见 http://www.bitcoin.org。

我发现的所有问题都出在自动查找并连接到其他节点的代码里，因为直到现在我才得以在真实环境中测试它。在真实的互联网上，连接出问题的方式要多得多。

修复的 bug：
- 修复了导致新节点难以发现可连接节点的一系列问题。
- 如果你在防火墙后面，它只能接收一个连接，第二个连接会不断断开并重连。

这些问题正在扰乱网络，而且随着更多用户到来会更严重，所以请务必升级。

Satoshi Nakamoto

英文原文

Bitcoin v0.1.2 is now available for download.

See http://www.bitcoin.org for the download link.

All the problems I've been finding are in the code that
automatically finds and connects to other nodes, since I wasn't
able to test it in the wild until now. There are many more ways
for connections to get screwed up on the real Internet.

Bugs fixed:
- Fixed various problems that were making it hard for new nodes to
see other nodes to connect to.
- If you're behind a firewall, it could only receive one
connection, and the second connection would constantly disconnect
and reconnect.

These problems are kind of screwing up the network and will get
worse as more users arrive, so please make sure to upgrade.

Satoshi Nakamoto

Re: A few suggestions

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: A few suggestions

Date2009-12-11 19:27:55 UTC

ForumBitcointalk · 原文

对，SVN 上是接近发布候选的 0.2 源码，在 Linux 上也能编译运行。FreeBSD 上还没测过。

引用自：madhatter2，2009 年 12 月 11 日 04:59:19 AM（https://bitcointalk.org/index.php?topic=12.msg47#msg47）

如果能搞出可在 FreeBSD 上跑的后端进程，我就能架常年在线的种子节点。

那会帮大忙。TOR 用户就不用愁怎么连上种子节点，我们也不用依赖 IRC。

不用 UI 也能跑几种简单的模式，只要你不介意桌面上有个最小化的窗口。（0.1.5 没有 -min，会是个打开的窗口。）

只跑种子节点：

bitcoin -min -gen=0

看 debug.log 就能大致监控。停的话直接杀进程，数据库没事。

要挖矿：

bitcoin -min -gen

要取出挖到的币，得把 wallet.dat（0.2 版）拷到有 UI 的机器上，替换掉 wallet.dat，运行 bitcoin 再把币转到你的主账户。（0.1.5 版则要拷整个 "%appdata%/Bitcoin" 目录。）拷 wallet.dat 有个注意事项：如果恰好在它生成币或收到付款的那一瞬间杀掉程序，wallet.dat 可能单独用不了，就得拷整个目录。

引用：

我真觉得下载包里带一份每日更新的种子快照能改善冷启动。我见过全新安装时应用卡在 0 连接 / 1 区块，看 debug.log 发现 IRC 服务器（我记得是 freenode）说我已经连上了，不让我再连进去做种子。（举个例子。）

明白，多台机器共用同一个 NAT 或 VPN、或者 ISP 把大家都 funnel 到几个代理后面时就会这样。我刚往 SVN 提交了一个修复：如果遇到 "433" 昵称已被占用（是 433 错误吧？），就换个不带地址的随机用户名重试。

引用：

不管怎样，我想帮忙。我时间很多，这样的项目太让人兴奋了。

太好了，非常感谢任何帮助！

英文原文

Right, the SVN has the almost-release-candidate 0.2 source, which can also be built and run on Linux. It hasn't been tested on FreeBSD.

Quote from: madhatter2 on December 11, 2009, 04:59:19 AM（https://bitcointalk.org/index.php?topic=12.msg47#msg47）If we can get to the point where we have a working backend process that will run on FreeBSD I can run always-on seeds.
That would be a big help. TOR users wouldn't have to worry about how to get seeded, and we wouldn't depend on IRC.

It can be run in a few simple modes without access to the UI if you don't mind a minimized window on the desktop. (0.1.5 doesn't have -min so it would be an open window)

To only run a seed:
bitcoin -min -gen=0

You could sort of monitor it by looking at debug.log. To stop it, kill the process, the database won't mind.

To generate:
bitcoin -min -gen

To get the generated bitcoins, you'd have to copy wallet.dat (with version 0.2) to a machine with a UI, swap in the wallet.dat, run bitcoin and transfer the coins to your main account. (With version 0.1.5 you'd have to copy the whole "%appdata%/Bitcoin" directory.) There is one caveat about copying wallet.dat: if you happened to kill the program at the exact moment that it generated a coin or received a payment, wallet.dat might not work by itself and you'd have to copy the whole directory.

QuoteI really think that having the download package contain a daily seed snapshot will improve the bootstrapping. I have seen instances on new test installs here where the application will sit with 0 connections / 1 block. Upon inspecting the debug.log I find that the IRC server (freenode, I believe) claims I am already connected and refuses to let me seed the application. (Just an example).
I see, that would happen with multiple nodes using the same NAT or VPN or some ISP that funnels everyone through a few proxy servers. I just committed a fix to SVN for this. If it gets "433" name already in use (it was error 433, right?), it'll retry with a non-address random username.

QuoteIn any event, I would like to help. I have a lot of time and a project like this one is very exciting.
That's great, any help is really appreciated!

[bitcoin-list] Bitcoin v0.1 Alpha release notes

Mon, 01 Jan 0001 00:00:00 +0000

FromSatoshi Nakamoto

Subject[bitcoin-list] Bitcoin v0.1 Alpha release notes

Date2009-01-12 20:20:47 UTC

Listbitcoin-list · 原文

Bitcoin v0.1 Alpha 发布说明

Bitcoin 是一种使用点对点网络防止双重支付的全新电子现金系统。它是完全去中心化的，没有服务器或中央权威机构。

截图和下载链接见：
http://www.bitcoin.org

目前仅支持 Windows。附带开源 C++ 代码。

- 将文件解压到一个目录
- 运行 BITCOIN.EXE
- 它会自动连接到其他节点

如果你能让一个接受传入连接的节点持续运行，会对网络大有帮助。防火墙上的 8333 端口需要打开以接收传入连接。

该软件仍处于 alpha 测试阶段，带有实验性质。不能保证在必要时系统的状态不会被重启，尽管我已尽最大努力在其中构建了可扩展性和版本控制。

总发行量将为 21,000,000 币。它们将在节点生成区块时分配给网络节点，数量每 4 年减半。

前 4 年：10,500,000 币
后 4 年：5,250,000 币
后 4 年：2,625,000 币
后 4 年：1,312,500 币
依此类推……

当发行完毕后，如有需要，系统可以靠交易费维持。它基于公开市场竞争，届时应该总会有愿意免费处理交易的节点。

Satoshi Nakamoto

英文原文

Release notes for Bitcoin v0.1 Alpha

Bitcoin is a new electronic cash system that uses a peer-to-peer
network to prevent double-spending. It's completely decentralized
with no server or central authority.

You can find screenshots and the download link at:
http://www.bitcoin.org

Windows only for now. Open source C++ code is included.

- Unpack the files into a directory
- Run BITCOIN.EXE
- It automatically connects to other nodes

If you can keep a node running that accepts incoming connections,
you'll really be helping the network a lot. Port 8333 on your
firewall needs to be open to receive incoming connections.

Total circulation will be 21,000,000 coins. It'll be distributed
to network nodes when they make blocks, with the amount cut in half
every 4 years.

first 4 years: 10,500,000 coins
next 4 years: 5,250,000 coins
next 4 years: 2,625,000 coins
next 4 years: 1,312,500 coins
etc...

When that runs out, the system can support transaction fees if
needed. It's based on open market competition, and there will
probably always be nodes willing to process transactions for free.

Satoshi Nakamoto

Re: A few suggestions

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: A few suggestions

Date2009-12-12 17:52:44 UTC

ForumBitcointalk · 原文

全网每天生成的币的平均总量保持不变。快的机器只是比慢的机器分到更多。如果大家都买更快的机器，得到的币不会比以前多。

我们应该有个君子协定：为了网络好，尽量推迟 GPU 军备竞赛。让新用户不用操心 GPU 驱动和兼容性就能上手，轻松得多。现在只要有 CPU 的人都能相当公平地竞争，这样挺好。

英文原文

The average total coins generated across the network per day stays the same. Faster machines just get a larger share than slower machines. If everyone bought faster machines, they wouldn't get more coins than before.

We should have a gentleman's agreement to postpone the GPU arms race as long as we can for the good of the network. It's much easer to get new users up to speed if they don't have to worry about GPU drivers and compatibility. It's nice how anyone with just a CPU can compete fairly equally right now.

[bitcoin-list] Bitcoin v0.1.3

Mon, 01 Jan 0001 00:00:00 +0000

FromSatoshi Nakamoto

Subject[bitcoin-list] Bitcoin v0.1.3

Date2009-01-12 22:48:23 UTC

Listbitcoin-list · 原文

看来最糟糕的互联网连接问题已经过去了。0.1.3 修复了一个节点通信会在运行一段时间后中断的问题。这个版本让网络运行顺畅多了。

如果你成功生成过一个区块，你会看到在花它之前有一个成熟倒计时。一旦成熟，Credit 列会从 0.00 变为 50.00。要使一个区块有效，它必须被广播到网络并进入区块链——这就是 Generate 在未联网时不会运行的原因。如果你在未联网时生成了一个区块，网络不会知道它，会继续在没有它的情况下构建链条，把它甩在后面；当你的节点发现它没有被采用时，成熟倒计时会变成"(not accepted)"。用状态列的数字减 1，就是在你那个区块之后又接上了多少个区块。

Satoshi Nakamoto

英文原文

It looks like we're through with the worst of the Internet
connection issues. 0.1.3 fixed a problem where your node's
communications could go dead after a while. The network is
running much more smoothly now with this version.

If you've successfully generated a block, you've seen it has a
maturation countdown before you can spend it. Once it matures,
the Credit column will change from 0.00 to 50.00. For a block to
be valid, it has to be broadcasted to the network and get into the
block chain, which is why Generate does not run if you're not
connected. If you generated a block without being connected, the
network wouldn't know about it and would continue building the
chain without it, leaving it behind, and the maturation countdown
would change to "(not accepted)" when your node sees that it
wasn't used. If you subtract 1 from the status column, that's how
many blocks have been chained after yours.

Satoshi Nakamoto

Re: A few suggestions

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: A few suggestions

Date2009-12-12 18:17:10 UTC

ForumBitcointalk · 原文

引用自：madhatter2，2009 年 12 月 12 日 06:34:21 AM（https://bitcointalk.org/index.php?topic=12.msg51#msg51）

svn 0.2 在 Mac OS X 10.4.11/Intel 上快编译通过了（我这还有台 PPC970 的机器，也可以编 PPC 版）。窗口是 wxwidgets 的原生 carbon！飞快！我新建了个 makefile（makefile.osx，当然是基于 makefile.unix 的……考虑过用 autoconf 吗？），还在 header.h 里加了几个 ifdef。我有补丁。继续折腾。下一步可能试 FreeBSD。

能支持 Mac 就好了。wxWidgets 的跨平台真是没白选。

别试 PPC 了。PPC 是大端序，比特币是小端序，无穷无尽的大小端 bug 会让我更难调试网络——万一有个到处字节交换的节点在外面。PPC 反正也快被淘汰了。

考虑过 autoconf。autoconf 是那种 makefile 一团糟的大项目才需要的，我觉得我们还小，不用它更划算。makefile 能简单就尽量简单。

引用：

我觉得把比特币拆成两个应用最理想。一个 wxwidgets 前端（反正基本都有了），一个绑控制 TCP 套接字的后端。我读了下源码，感觉拆起来应该不难。当然得先开发 API。

光想想我就头疼。把 UI 后端全 funnel 到一条 TCP 连接上，所有事都难一倍。因为 listview 控件的工作方式，UI 和内部数据结构之间带宽需求太大，要不停地更新 listview。

我更想要命令行控制，那样远程管理和批量自动化都有了。

英文原文

Quote from: madhatter2 on December 12, 2009, 06:34:21 AM（https://bitcointalk.org/index.php?topic=12.msg51#msg51）I almost have the svn 0.2 compiling on Mac OS X 10.4.11/Intel (I also have a PPC970 machine here as well so a PPC build would be possible as well). The windowing is native carbon too via wxwidgets! It is FAST! I had to create a new makefile (makefile.osx; based on makefile.unix of course.. given any thought to using autoconf?) and put some ifdef's into header.h. I have patches. I will keep toying around. I might try it on FreeBSD next.
Mac support would be nice. wxWidgets really pays off for cross platform.

Please don't try PPC. PPC is big-endian and Bitcoin is little-endian, there would be endless endian bugs making it harder for me to debug the network if there's a potentially byte-swapping node out there. PPC is on its way out anyway.

Considered autoconf. Autoconf is a necessity for large projects with a quagmire makefile, but I think we're small enough that it's more optimal without it. I'd rather keep the makefile simple as long as possible.

QuoteI think that breaking bitcoin into two apps is ideal. A wxwidgets front end (since it is mostly all there) and a backend that binds to a control TCP socket. I have been reading over the source to see how hard it would be to break it apart and I think it should be fairly simple. Of course an API would have to be developed.
My head hurts just thinking about that. Funnelling all the UI backend through a TCP connection would make everything twice as hard. There's too much bandwidth between the UI and the internal data structures in order to keep the listview control updated, because of the way the listview control works.

I'd rather have command line control, that would get us remote admin and batch automation.

Re: [bitcoin-list] Bitcoin v0.1 released

Mon, 01 Jan 0001 00:00:00 +0000

FromSatoshi Nakamoto

SubjectRe: [bitcoin-list] Bitcoin v0.1 released

Date2009-01-16 18:35:32 UTC

Listbitcoin-list · 原文

Dustin D. Trammell 写道：
> Satoshi Nakamoto 写道：
> 你知道吗，我觉得 90 年代对这感兴趣的人要多得多，
> 但在经历了十多年基于可信第三方的系统（Digicash 等）的失败后，
> 他们将其视为无望的事业。我希望他们能看出区别：
> 据我所知，这是我们第一次尝试一个
> 非信任型系统。

对，那正是最吸引我的主要特性。真正的诀窍
将是让人们真正认可比特币的价值，使其成为
货币。

如果 10 年后我们还没有以某种方式使用电子货币，我会感到惊讶——既然我们已经知道了一种实现方式，当可信第三方退缩时，它不会不可避免地被削弱降级。

它可以从积分奖励、捐赠代币、游戏内货币或成人网站微支付这类狭窄领域起步。最初，它可用于工作量证明应用场景——那些本可以几乎免费、但又不完全免费的服务。

它已经可用于付费发送电子邮件。发送对话框可调整大小，你可以输入任意长的消息。连接上后它会被直接发送出去。收款人双击交易即可查看完整消息。如果某个名人收到的邮件多到读不过来，但仍希望粉丝有联系到他的方式，他可以装上 Bitcoin，并在网站上公布 IP 地址："Send X bitcoins to my priority hotline at this IP and I'll read the message personally."

需要为免费试用增加一点额外的工作量证明、以免蚕食正式订阅的订阅制网站，可以对试用收费比特币。

哪怕只是为了以防它流行起来，囤一点比特币也是有道理的。如果足够多的人都这么想，这就成了自我实现的预言。一旦它被引导起来，只要你能像往自动售货机投币一样轻松地向网站支付几分钱，应用场景将数不胜数。

Satoshi Nakamoto
http://www.bitcoin.org

英文原文

Dustin D. Trammell wrote:
> Satoshi Nakamoto wrote:
> You know, I think there were a lot more people interested in the 90's,
> but after more than a decade of failed Trusted Third Party based systems
> (Digicash, etc), they see it as a lost cause. I hope they can make the
> distinction that this is the first time I know of that we're trying a
> non-trust-based system.

Yea, that was the primary feature that caught my eye. The real trick
will be to get people to actually value the BitCoins so that they become
currency.

I would be surprised if 10 years from now we're not using
electronic currency in some way, now that we know a way to do it
that won't inevitably get dumbed down when the trusted third party
gets cold feet.

It could get started in a narrow niche like reward points,
donation tokens, currency for a game or micropayments for adult
sites. Initially it can be used in proof-of-work applications
for services that could almost be free but not quite.

It can already be used for pay-to-send e-mail. The send dialog is
resizeable and you can enter as long of a message as you like.
It's sent directly when it connects. The recipient doubleclicks
on the transaction to see the full message. If someone famous is
getting more e-mail than they can read, but would still like to
have a way for fans to contact them, they could set up Bitcoin and
give out the IP address on their website. "Send X bitcoins to my
priority hotline at this IP and I'll read the message personally."

Subscription sites that need some extra proof-of-work for their
free trial so it doesn't cannibalize subscriptions could charge
bitcoins for the trial.

It might make sense just to get some in case it catches on. If
enough people think the same way, that becomes a self fulfilling
prophecy. Once it gets bootstrapped, there are so many
applications if you could effortlessly pay a few cents to a
website as easily as dropping coins in a vending machine.

Satoshi Nakamoto
http://www.bitcoin.org

Re: A few suggestions

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: A few suggestions

Date2009-12-13 16:51:25 UTC

ForumBitcointalk · 原文

运行时会有一个命令行开关，让它在无界面模式下运行。它要做的只是不创建主窗口。简单的做法是在 ui.cpp 里禁用"pframeMain->Show"和"ptaskbaricon->Show"。网络线程不在乎界面在不在。除了磁盘空间不足时 CheckDiskSpace 会弹一个消息框，就没有别的界面了。

然后再单独做一个命令行工具跟它通信来做事。叫什么名字还没想好。

"natural deflation"（自然通缩）……我喜欢这个名字。是的，由于付款失误和数据丢失，会有自然通缩。币的产出最终会慢到被自然通缩超过，我们就会进入净通缩。

英文原文

There would be a command line switch at runtime to tell it to run without UI. All it needs to do is not create the main window. A simplistic way would be to disable "pframeMain->Show" and "ptaskbaricon->Show" in ui.cpp. The network threads don't care that the UI isn't there. The only other UI is a message box in CheckDiskSpace if it runs out of disk space.

Then a separate command line utility to communicate with it to do things. Not sure what it should be named.

"natural deflation"... I like that name for it. Yes, there will be natural deflation due to payment mistakes and lost data. Coin creation will eventually get slow enough that it is exceeded by natural deflation and we'll have net deflation.

Bitcoin v0.1 released

Mon, 01 Jan 0001 00:00:00 +0000

FromSatoshi Nakamoto

SubjectBitcoin v0.1 released

Date2009-01-16 16:03:14 UTC

ListCryptography Mailing List · 原文

Dustin D. Trammell 写道：
> Satoshi Nakamoto 写道：
> 你知道吗，我觉得 90 年代对这感兴趣的人要多得多，
> 但在经历了十多年基于可信第三方的系统（Digicash 等）的失败后，
> 他们将其视为无望的事业。我希望他们能看出区别：
> 据我所知，这是我们第一次尝试一个
> 非信任型系统。

对，那正是最吸引我的主要特性。真正的诀窍
将是让人们真正认可比特币的价值，使其成为
货币。

需要为免费试用增加一点额外的工作量证明、以免蚕食正式订阅的订阅制网站，可以对试用收费比特币。

Satoshi Nakamoto
http://www.bitcoin.org

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

英文原文

Dustin D. Trammell wrote:
> Satoshi Nakamoto wrote:
> You know, I think there were a lot more people interested in the 90's,
> but after more than a decade of failed Trusted Third Party based systems
> (Digicash, etc), they see it as a lost cause. I hope they can make the
> distinction that this is the first time I know of that we're trying a
> non-trust-based system.

Yea, that was the primary feature that caught my eye. The real trick
will be to get people to actually value the BitCoins so that they become
currency.

Subscription sites that need some extra proof-of-work for their
free trial so it doesn't cannibalize subscriptions could charge
bitcoins for the trial.

Satoshi Nakamoto
http://www.bitcoin.org

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

Re: A few suggestions

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: A few suggestions

Date2009-12-14 17:15:56 UTC

ForumBitcointalk · 原文

引用自：madhatter2，2009 年 12 月 14 日 03:01:39 PM（https://bitcointalk.org/index.php?topic=12.msg66#msg66）

有人能指点一下吗？

（以下编译错误日志保留英文原文：）

g++ -c -O0 -Wno-invalid-offsetof -Wformat -g -D__WXMAC__ -DNOPCH -DBUILD_MACOSX -I"/usr/include" -I"/usr/local/include/wx-2.8" -I"/usr/local/include" -I"/usr/local/boost_1_41_0" -I"/sw/include/db4" -I"/usr/local/ssl/include" -I"/usr/local/lib/wx/include/mac-ansi-release-2.8" -o headers.h.gch headers.h
...
ui.h:430: error: no matching function for call to 'wxTextCtrl::SetValue(const std::basic_string<char, std::char_traits<char>, std::allocator<char> >&)'
/usr/local/include/wx-2.8/wx/textctrl.h:303: note: candidates are: virtual void wxTextCtrlBase::SetValue(const wxString&)

看起来 std::string 到 wxString 的隐式转换没生效。这个转换到处都在用，必须能工作。

wxString 比较麻烦，因为它要同时支持 win32 的 16 位 wchar 和 8 位 ansi 双编译。在 Windows 上如果用了 "unicode"（指 wchar）构建也会出这个问题，那时 wxString 是 wchar 而 std::string 是 char。

多半是 wxWidgets 的编译宏或构建配置问题。你 "configure" 脚本用的什么选项？

我不确定 __WXMAC__ 是不是对的宏。可能是 Mac Classic 支持在捣乱 wxString，而我们只要 OSX。试试 __WXOSX__（或看下面）

http://docs.wxwidgets.org/stable/wx_cppconst.html

"Mac OS 有两个 wxWidgets 移植版。其中 wxMac 有两个版本：Classic 和 Carbon。Classic 版是唯一能在 Mac OS 8 上跑的。Carbon 版可以编成 CFM 或 Mach-O（二进制格式，类似 ELF），前者能在 OS 9 下跑，后者只能跑在 OS X。最后还有一个新的 Cocoa 移植版，只能用在 OS X。总结如下：

* 如果要检测所有 Mac 平台，classic 和 OS X，得同时测 __WXMAC__ 和 __WXCOCOA__。
* 如果要检测 OS X 下任意 GUI 版 Mac 移植，用 __WXOSX__。
* 如果要检测 Mac OS X 下任意移植，包括比如 wxGTK 还有 wxBase，用 __DARWIN__"

英文原文

Quote from: madhatter2 on December 14, 2009, 03:01:39 PM（https://bitcointalk.org/index.php?topic=12.msg66#msg66）Can anyone shed some light here?

It looks like the implicit conversion from std::string to wxString isn't working. That's used everywhere, the conversion needs to work.

wxString is complicated by supporting win32's 16-bit wchar and 8-bit ansi dual-compile. You can get that problem on Windows if the "unicode" (meaning wchar) build is used, so that wxString is wchar and std::string is char.

It's probably some wxWidgets compile defines or build configuration. What "configure" options did you use?

I'm not sure __WXMAC__ is the right define. It may be the Mac Classic support that's complicating wxString, and we only want OSX. Try __WXOSX__ (or see below)

http://docs.wxwidgets.org/stable/wx_cppconst.html
"There are two wxWidgets ports to Mac OS. One of them, wxMac, exists in two versions: Classic and Carbon. The Classic version is the only one to work on Mac OS version 8. The Carbon version may be built either as CFM or Mach-O (binary format, like ELF) and the former may run under OS 9 while the latter only runs under OS X. Finally, there is a new Cocoa port which can only be used under OS X. To summarize:

* If you want to test for all Mac platforms, classic and OS X, you should test both __WXMAC__ and __WXCOCOA__.
* If you want to test for any GUI Mac port under OS X, use __WXOSX__.
* If you want to test for any port under Mac OS X, including, for example, wxGTK and also wxBase, use __DARWIN__"

Re: [bitcoin-list] Problems

Mon, 01 Jan 0001 00:00:00 +0000

FromSatoshi Nakamoto

SubjectRe: [bitcoin-list] Problems

Date2009-01-25 16:45:25 UTC

Listbitcoin-list · 原文

From: Nicholas Bohm 2009-01-25 10:17
> 运行 bitcoin 时我遇到了几个问题：在这个列表上报合适吗（带约 70kb 的附件）？

你遇到了什么问题？

如果你把 debug.log 文件直接发给我（最好不要把附件发到列表上），我可以看看发生了什么。

Satoshi Nakamoto
bitcoin-help at vistomail dot com

英文原文

From: Nicholas Bohm 2009-01-25 10:17
> I have had a couple of problems running bitcoin: is this an appropriate
> list for reporting them (with about 70kb of attachments)?

What's the problem you're having?

If you send me your debug.log file directly (best not to send attachments
to the list), I can take a look at what's happening.

Satoshi Nakamoto
bitcoin-help at vistomail dot com

Re: A few suggestions

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: A few suggestions

Date2009-12-15 20:37:32 UTC

ForumBitcointalk · 原文

引用自：madhatter2，2009 年 12 月 15 日 05:21:09 AM（https://bitcointalk.org/index.php?topic=12.msg68#msg68）

最新的 Ubuntu Linux 上也报同样的 std::string 问题。

那肯定是你编译或配置 wxWidgets 的方式哪里不一样。

wxWidgets "configure" 脚本你用的什么选项？我用的选项在 build-unix.txt 里。

引用：

问下，怎么开 debug.log？我试过停掉 bitcoin，touch ~/.bitcoin/debug.log 再启动，但它好像从不写文件。我漏了什么吗？

没听说过这种情况。debug.log 里有什么？既然你 touch 了文件，说明里面应该有东西。程序有写权限吗？

英文原文

Quote from: madhatter2 on December 15, 2009, 05:21:09 AM（https://bitcointalk.org/index.php?topic=12.msg68#msg68）It is also throwing the same std::string issue on the latest version of Ubuntu Linux.
Then it must be something you're doing differently with building or configuring wxWidgets.

What options did you use on the wxWidgets "configure" script? The options I used are in build-unix.txt.

QuoteOne question: how do I enable the debug.log? I have tried stopping bitcoin and touching ~/.bitcoin/debug.log and starting bitcoin again. It never seems to write to the file. Am I missing something?
Never heard of that happening. Is there anything in debug.log? If you touched the file, that sounds like something is there. Does the program have write access to the file?

Bitcoin 0.2 released!

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleBitcoin 0.2 released!

Date2009-12-16 22:45:36 UTC

ForumBitcointalk · 原文

Bitcoin 0.2 版来了！

下载链接：
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.2.0-win32-setup.exe/download
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.2.0-win32.zip/download
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.2.0-linux.tar.gz/download

新功能

Martti Malmi
- 最小化到系统托盘选项
- 开机自动启动选项，让你可以在后台自动保持运行
- 新的选项对话框布局，便于未来扩展
- Windows 安装程序
- Linux 版（在 Ubuntu 上测试过）
Satoshi Nakamoto
- 生成货币的多处理器支持
- 配合 TOR 使用的代理支持
- 修复了初始区块下载的一些卡顿

特别感谢 Martti Malmi (sirius-m) 所有的编码工作，以及他托管新网站和这个论坛，还要感谢 New Liberty Standard 帮助测试 Linux 版。

英文原文

Bitcoin version 0.2 is here!

Download links:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.2.0-win32-setup.exe/download
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.2.0-win32.zip/download
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.2.0-linux.tar.gz/download

New Features

Martti Malmi
- Minimize to system tray option
- Autostart on boot option so you can keep it running in the background automatically
- New options dialog layout for future expansion
- Setup program for Windows
- Linux version (tested on Ubuntu)
Satoshi Nakamoto
- Multi-processor support for coin generation
- Proxy support for use with TOR
- Fixed some slowdowns in the initial block download

Major thanks to Martti Malmi (sirius-m) for all his coding work and for hosting the new site and this forum, and New Liberty Standard for his help with testing the Linux version.

Bitcoin v0.1 released

Mon, 01 Jan 0001 00:00:00 +0000

FromSatoshi Nakamoto

SubjectBitcoin v0.1 released

Date2009-01-25 15:47:10 UTC

ListCryptography Mailing List · 原文

Hal Finney 写道：
> > 垃圾邮件僵尸网络可以轻易
> > 烧穿按发送付费的邮件过滤器
> 如果工作量证明代币变得有用，尤其是如果它们变成货币，
> 机器将不再闲置。用户会期望自己的电脑
> 在为他们赚钱（假设收益大于运营成本）。
> 一台收益被僵尸网络偷走的电脑，
> 对它的主人来说会比今天更显眼，因此我们可能会
> 期待，在那样的世界里，用户会更努力地维护
> 自己的电脑，清除僵尸网络的感染。

如果工作量证明代币有价值，还有另一个因素会遏制垃圾邮件：人们会有盈利动机去建立大量虚假电子邮箱账号，从垃圾邮件中收割工作量证明代币。他们本质上是用自动化邮箱对垃圾邮件发送者进行"反向群发"——只收集他们的工作量证明、不读消息。虚假邮箱与真实人数之比可能高到让垃圾邮件无利可图。

这个过程本身就有潜力确立工作量证明代币的价值，因为没有僵尸网络的垃圾邮件发送者可以从收割者那里购买代币。虽然回购会暂时放行更多垃圾邮件，但这只会加速自我毁灭的循环——越来越多的收割者在剥削垃圾邮件发送者。

有趣的是，某个 e-gold 系统已经有了一种叫"dusting"（撒尘）的垃圾邮件形式。垃圾邮件发送者发送极少量的金粉，只为把垃圾消息塞进交易的备注字段。如果系统允许用户设置自己愿意接受的最低付款额，或至少设置附带消息的最低付款额，用户就能决定自己愿意收多少钱来接收垃圾邮件。

Satoshi Nakamoto

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

英文原文

Hal Finney wrote:
> > * Spammer botnets could burn through pay-per-send email filters
> > trivially
> If POW tokens do become useful, and especially if they become money,
> machines will no longer sit idle. Users will expect their computers to
> be earning them money (assuming the reward is greater than the cost to
> operate). A computer whose earnings are being stolen by a botnet will
> be more noticeable to its owner than is the case today, hence we might
> expect that in that world, users will work harder to maintain their
> computers and clean them of botnet infestations.

Another factor that would mitigate spam if POW tokens have value:
there would be a profit motive for people to set up massive
quantities of fake e-mail accounts to harvest POW tokens from
spam. They'd essentially be reverse-spamming the spammers with
automated mailboxes that collect their POW and don't read the
message. The ratio of fake mailboxes to real people could become
too high for spam to be cost effective.

The process has the potential to establish the POW token's value
in the first place, since spammers that don't have a botnet could
buy tokens from harvesters. While the buying back would
temporarily let more spam through, it would only hasten the
self-defeating cycle leading to too many harvesters exploiting the
spammers.

Interestingly, one of the e-gold systems already has a form of
spam called "dusting". Spammers send a tiny amount of gold dust
in order to put a spam message in the transaction's comment field.
If the system let users configure the minimum payment they're
willing to receive, or at least the minimum that can have a
message with it, users could set how much they're willing to get
paid to receive spam.

Satoshi Nakamoto

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

[bitcoin-list] Bitcoin v0.1.5 released

Mon, 01 Jan 0001 00:00:00 +0000

FromSatoshi Nakamoto

Subject[bitcoin-list] Bitcoin v0.1.5 released

Date2009-02-04 19:46:04 UTC

Listbitcoin-list · 原文

0.1.5 版本现已发布。包含对 Nicholas 遇到的问题的修复、磁盘满检测，以及为改善一些令人困惑之处所做的改动。

特别感谢 Nicholas 和 Dustin 的帮助与反馈！

下载链接：
http://sourceforge.net/project/showfiles.php?group_id=244765&package_id=298441

改动：
- 磁盘满警告
- 修复了 DNS 查询失败时可能出现的 bug
- 禁止在地址簿中输入自己的地址，
之前这会让人困惑地更改了自己地址的标签
- 将 change 地址按钮移到 options 菜单下
- 加快连接速度的微调
- 退出时关闭 sockets
- 对小于 1 美分的交易设置了最低手续费
- 隐藏了只有一个选项的交易类型选择框
- 略微清理了 ParseMoney
- 消息文本的重新排版稍整洁
- 更改了交易详情对话框中的字体
- 在交易详情中为生成的币添加了说明文字
- 改写了通过 bitcoin 地址收到的交易的描述

Satoshi Nakamoto
http://www.bitcoin.org

英文原文

Version 0.1.5 is now available. It includes the fix for the problem
Nicholas had, checking for disk full and changes to try to improve
things that were confusing.

Special thanks to Nicholas and Dustin for all their help and feedback!

Download link:
http://sourceforge.net/project/showfiles.php?group_id=244765&package_id=298441

Changes:
- disk full warning
- fixed a bug that could occur if dns lookup failed
- prevent entering your own address in the address book,
which confusingly changed the label for your own address
- moved change address button to menu under options
- tweaks to make it get connected faster
- close sockets on exit
- created minimum fee for transactions less than 1 cent
- hid the transaction-type selection box that only had one choice
- cleaned up ParseMoney a little
- slightly cleaner reformatting of message text
- changed the font in transaction details dialog
- added some explanation text to transaction details for generated coins
- reworded the description for transactions received with bitcoin address

Satoshi Nakamoto
http://www.bitcoin.org

Re: A few suggestions

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: A few suggestions

Date2009-12-17 18:38:06 UTC

ForumBitcointalk · 原文

不错，在 FreeBSD 上运行正常吗？

我把改动提交到 headers.h 了。为了统一，我用的是 __BSD__。完整的 define 列表在 http://docs.wxwidgets.org/stable/wx_cppconst.html
#ifdef __BSD__
#include <netinet/in.h>
#endif

malloc.h 只在 Windows 上需要，我把它移到 __WXMSW__ 那部分去，免得再惹麻烦。

英文原文

That's good, is it running fine on FreeBSD?

I committed the changes to headers.h. For consistency, I used __BSD__. The complete list of defines is at http://docs.wxwidgets.org/stable/wx_cppconst.html
#ifdef __BSD__
#include <netinet/in.h>
#endif

malloc.h is only needed on windows, I'll move that into the __WXMSW__ section before it causes any more trouble.

[p2p-research] Bitcoin open source implementation of P2P currency

Mon, 01 Jan 0001 00:00:00 +0000

FromSatoshi Nakamoto

Subject[p2p-research] Bitcoin open source implementation of P2P currency

Date2009-02-11 22:37:54 UTC

ListP2P Research List · 原文

我开发了一个全新的开源 P2P 电子现金系统，叫 Bitcoin。它是完全去中心化的，没有中央服务器，也没有可信方，因为一切都建立在密码学证明而非信任之上。试用一下，或者看看截图和设计论文：

在 http://www.bitcoin.org 下载 Bitcoin v0.1

传统货币的根本问题在于让它运转所需的信任太多。中央银行必须被信任不会让货币贬值，但法定货币的历史充满了对这种信任的背叛。银行必须被信任来保管我们的钱并电子化转移它，但它们却在一波波信贷泡沫中放贷，准备金只有微不足道的一小部分。我们必须把隐私托付给它们，信任它们不会让身份窃贼掏空我们的账户。它们庞大的运营成本让微支付成为不可能。

一代人以前，多用户分时计算机系统也有类似的问题。在强加密出现之前，用户只能靠密码保护来保障文件安全，把隐私托付给系统管理员。管理员总能根据自己对隐私原则与其他关切的权衡、或其上级的要求，来凌驾于隐私之上。然后，强加密普及到了大众手中，信任不再是必需的。数据可以被保护到让他人在物理上无法访问的程度，无论出于什么原因、无论借口多么充分、无论如何。

是时候让货币也拥有同样的东西了。基于密码学证明的电子货币，不再需要信任第三方中间人，货币可以安全，交易可以轻松。

这类系统的基本构件之一是数字签名。一枚数字币包含其所有者的公钥。要转移它，所有者将这枚币与下一位所有者的公钥一起签名。任何人都可以检查签名来验证所有权链。它在保障所有权方面很有效，但留下一个大问题未解决：双重支付。任何所有者都可能把一枚已经花过的币再次签名给另一位所有者来重新花费。常规方案是由一家拥有中央数据库的可信公司来检查双重支付，但那又回到了信任模型。凭借其中心位置，该公司可以凌驾于用户之上，而维持该公司所需的费用让微支付变得不切实际。

Bitcoin 的解决方案是用点对点网络来检查双重支付。简而言之，网络像一台分布式时间戳服务器，给第一笔花费某枚币的交易盖上时间戳。它利用了信息易于传播、难以封杀的特性。工作原理详见设计论文：
http://www.bitcoin.org/bitcoin.pdf

结果是一个没有单点故障的分布式系统。用户持有自己资金的密码学密钥，直接相互交易，并借助 P2P 网络检查双重支付。

Satoshi Nakamoto
http://www.bitcoin.org

英文原文

I've developed a new open source P2P e-cash system called Bitcoin. It's
completely decentralized, with no central server or trusted parties,
because everything is based on crypto proof instead of trust. Give it a
try, or take a look at the screenshots and design paper:

Download Bitcoin v0.1 at http://www.bitcoin.org

The root problem with conventional currency is all the trust that's
required to make it work. The central bank must be trusted not to
debase the currency, but the history of fiat currencies is full of
breaches of that trust. Banks must be trusted to hold our money and
transfer it electronically, but they lend it out in waves of credit
bubbles with barely a fraction in reserve. We have to trust them with
our privacy, trust them not to let identity thieves drain our accounts.
Their massive overhead costs make micropayments impossible.

A generation ago, multi-user time-sharing computer systems had a similar
problem. Before strong encryption, users had to rely on password
protection to secure their files, placing trust in the system
administrator to keep their information private. Privacy could always
be overridden by the admin based on his judgment call weighing the
principle of privacy against other concerns, or at the behest of his
superiors. Then strong encryption became available to the masses, and
trust was no longer required. Data could be secured in a way that was
physically impossible for others to access, no matter for what reason,
no matter how good the excuse, no matter what.

It's time we had the same thing for money. With e-currency based on
cryptographic proof, without the need to trust a third party middleman,
money can be secure and transactions effortless.

One of the fundamental building blocks for such a system is digital
signatures. A digital coin contains the public key of its owner. To
transfer it, the owner signs the coin together with the public key of
the next owner. Anyone can check the signatures to verify the chain of
ownership. It works well to secure ownership, but leaves one big
problem unsolved: double-spending. Any owner could try to re-spend an
already spent coin by signing it again to another owner. The usual
solution is for a trusted company with a central database to check for
double-spending, but that just gets back to the trust model. In its
central position, the company can override the users, and the fees
needed to support the company make micropayments impractical.

Bitcoin's solution is to use a peer-to-peer network to check for
double-spending. In a nutshell, the network works like a distributed
timestamp server, stamping the first transaction to spend a coin. It
takes advantage of the nature of information being easy to spread but
hard to stifle. For details on how it works, see the design paper at
http://www.bitcoin.org/bitcoin.pdf

The result is a distributed system with no single point of failure.
Users hold the crypto keys to their own money and transact directly with
each other, with the help of the P2P network to check for double-spending.

Satoshi Nakamoto
http://www.bitcoin.org

Re: A few suggestions

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: A few suggestions

Date2009-12-18 17:37:48 UTC

ForumBitcointalk · 原文

目前你可以做的是在选项里设"最小化到托盘"，然后用"bitcoin -min"运行，让它启动时就是最小化的。唯一可见的就是托盘上一个小（20x20）图标，双击可以打开界面。注意：64 位 Karmic Koala 上托盘图标有时会消失，有个 bug，不确定是 64 位的问题还是 Karmic 的问题，32 位 Jaunty 上没事。

0.2 的 Linux 版没来得及实现"系统启动时启动比特币"功能，所以是灰的。我想 Linux 用户反正不介意手动做。我猜他们得知道 -min 开关才能做对。

你可以用"-datadir=<目录>"开关把数据目录放到你想放的地方。我知道已经有人这么干，把它放到 TrueCrypt U 盘上了。

英文原文

What you can currently do is set "Minimize to the tray" in options, then run it as "bitcoin -min" so it starts minimized. The only visible part will be a small (20x20) icon on the tray, which can be doubleclicked if you want to access the UI. Note: there's a bug with tray icons sometimes disappearing on 64-bit Karmic Koala, not sure if it's from 64-bit or Karmic, it was fine on 32-bit Jaunty.

We didn't have time to implement the "Start Bitcoin on system startup" feature on Linux in time for 0.2 so it's greyed out. I figured Linux people wouldn't mind doing that manually anyway. I guess they need to know about the -min switch to do it right.

You can locate the data directory where you want with the "-datadir=<directory>" switch. I know someone is already doing that to put it on a TrueCrypt USB drive.

[p2p-research] Bitcoin open source implementation of P2P currency

Mon, 01 Jan 0001 00:00:00 +0000

FromSatoshi Nakamoto

Subject[p2p-research] Bitcoin open source implementation of P2P currency

Date2009-02-12 19:08:24 UTC

ListP2P Research List · 原文

Martien van Steenbergen 写道：
> 非常有意思。这和 David Chaum 的匿名数字货币类似吗？
> 他的概念确保了货币是匿名的，除非它被攻破，也就是
> 同一笔钱被花费不止一次。一旦被攻破，
> “伪造者”就会立刻被公开揭露。

它在这一点上是类似的：都使用数字签名来表示币，但在隐私和防止双重支付的
方法上有所不同。比特币支付的接收方可以检查这笔支付是否是首次
支出，而第二次支出不会被接受。不存在一种离线模式，让双重支付者在事后
被抓出来示众，因为这要求参与者拥有身份。

为了保护隐私，每对密钥只使用一次，每笔交易
都使用一对新的密钥。币的所有者就是持有其私钥的人。

当然，最大的区别在于没有中央服务器。这是 Chaumian 系统的
阿喀琉斯之踵；当中央公司倒闭时，货币也就随之终结了。

另外，在比特币中，货币供应量是有限的吗（需要
管理）？还是说货币恰好在交易发生的瞬间被创造？

货币供应量是有限的。流通量将是 21,000,000 币。交易
只转移所有权。

感谢你的提问，

Satoshi

http://www.bitcoin.org

英文原文

Martien van Steenbergen wrote:
> Very interesting. Is this akin to David Chaum's anonymous digital money?
> His concept makes sure money is anonymous unless it is compromised, i.e.
> the same money spent more than once. As soon as it's compromised, the
> ‘counterfeiter’ is immediately publicly exposed.

It's similar in that it uses digital signatures for coins, but different
in the approach to privacy and preventing double-spending. The
recipient of a Bitcoin payment is able to check whether it is the first
spend or not, and second-spends are not accepted. There isn't an
off-line mode where double-spenders are caught and shamed after the
fact, because that would require participants to have identities.

To protect privacy, key pairs are used only once, with a new one for
every transaction. The owner of a coin is just whoever has its private key.

Of course, the biggest difference is the lack of a central server. That
was the Achilles heel of Chaumian systems; when the central company shut
down, so did the currency.

Also, in bitcoin, is there a limited supply of money (that must be
managed)? Or is money created exaclty at the moment of transaction?

There is a limited supply of money. Circulation will be 21,000,000
coins. Transactions only transfer ownership.

Thank you for your questions,

Satoshi

http://www.bitcoin.org

Re: Is my second Transaction working correctly? +Transfer Question

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Is my second Transaction working correctly? +Transfer Question

Date2010-01-05 20:00:46 UTC

ForumBitcointalk · 原文

如果是按 IP 地址发送，转账是即时的。如果按比特币地址发送、而对方当时不在线，可能要 30 分钟甚至更久才能看到。

另外，接收方必须先跟区块链同步完才能看到收到的交易。也就是说底部状态栏至少要显示 33000 个区块，像 "x connections 33200 blocks x transactions" 这样。

引用自：sirius-m，2010 年 1 月 5 日 01:20:06 AM（https://bitcointalk.org/index.php?topic=17.msg84#msg84）

引用：

不过，那笔交易完成后，新交易好像没开始。也可能开始了。列表里只有一笔交易，但"状态"下面我已经到 131 个区块了。本来就该这样吗？它是会一直在同一笔交易上处理、每 120 个区块左右生成一次币？还是应该开始一笔新交易？

一笔交易的区块数，指的是这笔交易之后全网新生成的区块数。链上每多一个新区块，就意味着它的创造者有了新币。你的交易列表里有一笔 "generated" 交易，说明你生成了一个区块。"区块"这个概念第一眼看着有点晕，你不是第一个。

如果状态显示成 "x confirmations"，会不会清楚点，比如：

2/unconfirmed
3/unconfirmed
4/unconfirmed
5/unconfirmed
6 confirmations
7 confirmations
8 confirmations

每个区块本质上都意味着又有一个节点确认了它认可截至目前的所有交易。

英文原文

The transfer is immediate if you send by IP address. If you send by bitcoin address and the recipient isn't online at the time, it might take 30 minutes or more to see it.

Also, the recipient needs to be synced up with the block chain before it'll see the received transaction. That means the status bar at the bottom needs to say at least 33000 blocks, like "x connections 33200 blocks x transactions".

Quote from: sirius-m on January 05, 2010, 01:20:06 AM（https://bitcointalk.org/index.php?topic=17.msg84#msg84）QuoteHowever, once that transaction was complete, a new transaction hasn't started. Or maybe it has. There's only one transaction in the list but I'm up to 131 Blocks under "Status". Is this the way it's supposed to happen? Does it keep processing on the same transaction and generating coins every 120 blocks or so? Or is it supposed to start a new transaction?

The number of blocks of a transaction is the amount of new blocks that have been generated by the whole network after the transaction. Each new block in the chain means new coins to its creator. One "generated" -transaction in your transaction list means that you have generated one block. You're not the first one to find the concept of a "block" a bit confusing on the first sight.

Would it be clearer if the status said "x confirmations", like:
2/unconfirmed
3/unconfirmed
4/unconfirmed
5/unconfirmed
6 confirmations
7 confirmations
8 confirmations

Each block essentially means another node has confirmed that it agrees with all transactions up to that point.

[p2p-research] Bitcoin open source implementation of P2P currency

Mon, 01 Jan 0001 00:00:00 +0000

FromSatoshi Nakamoto

Subject[p2p-research] Bitcoin open source implementation of P2P currency

Date2009-02-13 02:38:20 UTC

ListP2P Research List · 原文

Martien van Steenbergen 写道：
> 也很希望看到不需要供应和管理货币的支持。
> 那样会更容易、更便宜地维护，
> 并且货币供应总是充分，无论何时何地。
> 没有稀缺，没有过剩，在任何时候都恰好是合适的量，
> 自组织。

这做得到。可以编程使其遵循任何规则。

我把比特币看作一个基础和第一步，如果你想实现
像 Marc 的设想以及这里讨论过的其他那种可编程点对点
社会货币。首先你需要一个正常、可用的基础点对点货币。
一旦它确立并经受住检验，动态的智能货币就是一个简单的
下一步。

我很喜欢虚拟的、非地域性社区尝试新经济范式的想法。

让我想起：

* AardRock » Wizard Rabbit Treasurer
<http://wiki.aardrock.com/Wizard_Rabbit_Treasurer>; 以及
* AardRock » Pekunio <http://wiki.aardrock.com/Pekunio>

确实，在向网络上的一批节点喷洒每笔交易的冗余副本
这个概念上，它很像 Pekunio，但实现并不是像 Wizard Rabbit Treasurer 那样的
声誉网络。事实上，比特币根本不使用声誉。它把网络
看作一大群人，不太在意跟谁交谈、听谁说了什么，只要其中
至少有一个把在网络中广播的信息中继给它。它不在意，
是因为它没法被欺骗。你要么给它密码学证明，要么它就不理你。

你熟悉 Ripple 吗？

就信任体系而言，Ripple 的独特之处在于它把信任分散开来，而不是
集中它。

比特币是否有协议规范版本（以方便不同语言的
绑定和实现；以规范统一，以实现竞争）。

最好参考 C++ 源代码。我计划实现用任何语言
发送和接收交易的软件接口，这样服务端代码就可以轻松用于
基于 Web 的电子商务站点。

Satoshi

英文原文

Martien van Steenbergen wrote:
> Would love to also see support for not having to supply and
> managing money. Would make it easier and cheaper to maintain
> and results in have sufficient money, always and everywhere.
> No scarcity, no abundance, exactly the right amount all times,
> self-organizing.

That's do-able. It can be programmed to follow any set of rules.

I see Bitcoin as a foundation and first step if you want to implement
programmable P2P social currencies like Marc's ideas and others
discussed here. First you need normal, basic P2P currency working.
Once that is established and proven out, dynamic smart money is an easy
next step.

I love the idea of virtual, non-geographic communities experimenting
with new economic paradigms.

Reminds me of:

* AardRock » Wizard Rabbit Treasurer
<http://wiki.aardrock.com/Wizard_Rabbit_Treasurer>; and
* AardRock » Pekunio <http://wiki.aardrock.com/Pekunio>

Indeed, it is much like Pekunio in the concept of spraying redundant
copies of every transaction to a number of peers on the network, but the
implementation is not a reputation network like Wizard Rabbit Treasurer.
In fact, Bitcoin does not use reputation at all. It sees the network
as just a big crowd and doesn't much care who it talks to or who tells
it something, as long as at least one of them relays the information
being broadcast around the network. It doesn't care because there's no
way to lie to it. Either you tell it crypto proof of something, or it
ignores you.

Are you familiar with Ripple?

As trust systems go, Ripple is unique in spreading trust around rather
than concentrating it.

Is bitcoin also available as a protocol spec (facilitating differen
language bindings and implementations; unite on specs, compete on
implementation).

It would be best to refer to the C++ source code. I plan to implement
interfaces for using the software to send and receive transactions from
any language, so server side code can easily use it for web based
e-commerce sites.

Satoshi

Re: 64bit support

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: 64bit support

Date2010-01-14 20:17:20 UTC

ForumBitcointalk · 原文

我还没试过编译 64 位。64 位不会更快，因为只有少数地方用 64 位数，SHA-256 是 32 位算法，但对跑 64 位系统的人来说可能更方便。有机会我试试 -m64，看看问题出在哪。

在 64 位 Linux 上装 ia32-libs 就能跑 32 位版。(sudo apt-get install ia32-libs) 如果我们做 Debian 包，可以把它作为依赖自动装上。

英文原文

I haven't tried compiling 64-bit yet. 64-bit wouldn't make it any faster, since it uses 64-bit numbers in only a few places and SHA-256 is a 32-bit algorithm, but it may be convenient for those running a 64-bit OS. If I get a chance I'll try -m64 and see what the problem is.

You can run the 32-bit version on 64-bit Linux by installing ia32-libs. (sudo apt-get install ia32-libs) If we made a Debian package, it could automatically pull that in as a dependency.

[p2p-research] Bitcoin open source implementation of P2P currency

Mon, 01 Jan 0001 00:00:00 +0000

FromSatoshi Nakamoto

Subject[p2p-research] Bitcoin open source implementation of P2P currency

Date2009-02-13 18:36:45 UTC

ListP2P Research List · 原文

Michel Bauwens 写道：
> 你的项目现在有多可用？人们还要多久才能
> 在真实生活中使用它？

它已完全可用，网络也在增长。如果你试用软件，请把你的
比特币地址通过邮件发给我，我会给你发几个币。

我们只需要传播消息，让更多人产生兴趣。

我会在下一封邮件中转发发布介绍。

Satoshi

http://www.bitcoin.org

英文原文

Michel Bauwens wrote:
> how operational is your project? how soon do you think people will be
> able to use it in real life?

It's fully operational and the network is growing. If you try the
software, e-mail me your Bitcoin address and I'll send you a few coins.

We just need to spread the word and keep getting more people interested.

I'll forward the release introduction in the next message.

Satoshi

http://www.bitcoin.org

Re: Number of connections?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Number of connections?

Date2010-01-20 20:07:15 UTC

ForumBitcointalk · 原文

连接数只要 ≥1，币的生成速度都一样。

更多的连接只是增加冗余。如果你只有一个连接，万一那个节点很慢、很忙，或者只跟你一个人连呢？多几个连接能更确定你跟网络连得很好。实际中这不是问题，网络连得非常充分。有 2、3 个连接就够了。

英文原文

Coins generate at the same speed with any number of connections >= 1.

More connections just add redundancy. If you only had one connection, what if that node is slow or busy, or only connected to you? Having several connections increases the certainty that you're well connected to the network. That hasn't been a problem in practice, the network is very thoroughly connected. If you have 2 or 3 connections, you're fine.

[p2p-research] Bitcoin P2P e-currency v0.1 released

Mon, 01 Jan 0001 00:00:00 +0000

FromSatoshi Nakamoto

Subject[p2p-research] Bitcoin P2P e-currency v0.1 released

Date2009-02-13 18:52:41 UTC

ListP2P Research List · 原文

宣布发布比特币，一种全新的开源点对点电子现金
系统，完全去中心化，没有中央服务器或可信方。用户自己持有加密
密钥来保管自己的钱，彼此直接交易，并借助点对点网络
检查双重支付。

支持 Windows NT/2000/XP/Vista。附带开源 C++ 代码。

下载：http://www.bitcoin.org

- 把文件解压到一个目录
- 运行 BITCOIN.EXE
- 它会自动连接到其他节点

如果你能让一个接受入站连接的节点保持运行，你就真的在
帮网络大忙了。你防火墙上的 8333 端口需要开放，才能接收入站连接。

你可以通过别人给你转账来获得币，或者打开
Options->Generate Coins，让一个节点运行并生成区块。我把
工作量证明难度一开始设得非常非常低，所以在最初的一小段时间里，
一台普通的电脑只需几个小时就能生成币。当竞争加剧，自动
调节推高难度时，难度会难得多。生成的币必须等待 120 个区块成熟，
之后才能花费。

发送货币有两种方式。如果接收方在线，你可以
输入他们的 IP 地址，它会连接，获取一个新的公钥，然后带着
评论发送交易。如果接收方不在线，可以发送到他们的比特币地址，
也就是他们给你的其公钥的哈希。他们下次连接并获取到
包含这笔交易的区块时，就会收到这笔交易。这种方式的缺点
是没有评论信息被发送，而且如果一个地址被多次使用，可能会
损失一点隐私，但如果双方不能同时在线，或接收方无法接收
入站连接，这是一个实用的替代方案。

总流通量将是 21,000,000 币。它们将随着区块的生成分发给
网络节点，每 4 年减半一次。

前 4 年：10,500,000 币
后 4 年：5,250,000 币
再后 4 年：2,625,000 币
再后 4 年：1,312,500 币
依此类推……

当分发完毕后，如有需要，系统可以支持交易费。
它是基于公开市场竞争的，很可能永远都有愿意免费
处理交易的节点。

Satoshi Nakamoto

http://www.bitcoin.org

英文原文

Announcing the release of Bitcoin, a new open source peer-to-peer
electronic cash system that's completely decentralized, with no central
server or trusted parties. Users hold the crypto keys to their own
money and transact directly with each other, with the help of the P2P
network to check for double-spending.

Windows NT/2000/XP/Vista. Open source C++ code is included.

Download: http://www.bitcoin.org

- Unpack the files into a directory
- Run BITCOIN.EXE
- It automatically connects to other nodes

If you can keep a node running that accepts incoming connections, you'll
really be helping the network a lot. Port 8333 on your firewall needs
to be open to receive incoming connections.

You can get coins by getting someone to send you some, or turn on
Options->Generate Coins to run a node and generate blocks. I made the
proof-of-work difficulty ridiculously easy to start with, so for a
little while in the beginning a typical PC will be able to generate
coins in just a few hours. It'll get a lot harder when competition
makes the automatic adjustment drive up the difficulty. Generated coins
must wait 120 blocks to mature before they can be spent.

There are two ways to send money. If the recipient is online, you can
enter their IP address and it will connect, get a new public key and
send the transaction with comments. If the recipient is not online, it
is possible to send to their Bitcoin address, which is a hash of their
public key that they give you. They'll receive the transaction the next
time they connect and get the block it's in. This method has the
disadvantage that no comment information is sent, and a bit of privacy
may be lost if the address is used multiple times, but it is a useful
alternative if both users can't be online at the same time or the
recipient can't receive incoming connections.

Total circulation will be 21,000,000 coins. It'll be distributed to
network nodes when they make blocks, with the amount cut in half every 4
years.

first 4 years: 10,500,000 coins
next 4 years: 5,250,000 coins
next 4 years: 2,625,000 coins
next 4 years: 1,312,500 coins
etc...

When that runs out, the system can support transaction fees if needed.
It's based on open market competition, and there will probably always be
nodes willing to process transactions for free.

Satoshi Nakamoto

http://www.bitcoin.org

Re: TOR and I2P

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: TOR and I2P

Date2010-01-20 22:05:28 UTC

ForumBitcointalk · 原文

我想这个事想了一阵了。我想先加上对 .onion 地址的后端支持、能连上它们，再往下走。

现在用 .onion 地址的场景不多，因为用户要走好几个步骤才能创建一个：配置 TOR 生成 .onion 地址，重启 TOR，再把生成的地址配进去。也许这是故意的，好让 TOR 没法被充分自动化地集成进文件共享程序。

英文原文

I've been thinking about that for a while. I want to add the backend support for .onion addresses and connecting to them, then go from there.

There aren't many .onion addresses in use for anything because the user has to go through a number of steps to create one. Configure TOR to generate a .onion address, restart TOR, configure it with the generated address. Perhaps this is intentional to keep TOR so it can't be integrated into file sharing programs in any sufficiently automated way.

Re: [bitcoin-list] Bitcoin v0.1.5 released

Mon, 01 Jan 0001 00:00:00 +0000

FromSatoshi Nakamoto

SubjectRe: [bitcoin-list] Bitcoin v0.1.5 released

Date2009-02-22 17:47:52 UTC

Listbitcoin-list · 原文

接下来是什么？

v0.1.6 的下一件事是利用多处理器生成区块。目前它只启动
一个线程。如果你有多核处理器，比如 Core Duo 或
Quad，你的产出将翻倍或翻两番。

之后我想添加接口，让从任何服务端语言集成
到网站变得非常简单。

Satoshi

http://www.bitcoin.org

英文原文

What's next?

The next thing for v0.1.6 is to take advantage of multiple
processors to generate blocks. Currently it only starts one
thread. If you have a multi-core processor like a Core Duo or
Quad this will double or quadruple your production.

Later I want to add interfaces to make it really easy to integrate
into websites from any server side language.

Satoshi

http://www.bitcoin.org

Re: Bitcoin crash when sending coins

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Bitcoin crash when sending coins

Date2010-01-27 21:52:27 UTC

ForumBitcointalk · 原文

到处复制钱包文件就会这样。如果你把钱包文件复制到第二台电脑，两台电脑都会觉得钱包里的钱是自己的。一台花了其中一部分，另一台不知道那些币已经花掉了，会想再花一次，你就撞上这个报错了。

既然已经明确这是个关键报错信息，它应该写得更像这样："the money appears to be already spent... this could happen if you used a copy of your wallet file on another computer."

你可以移动或备份钱包文件，但它必须只有一条"血统"，同一时间只能在一个地方用。你一旦从里面转出钱，就不能再用之前的任何副本。

这提了个好问题。万一你恢复的备份是在你花掉一些币之前的，我们需要加个功能来重新同步，查出哪些币其实已经被花掉了。这不难做，只是还没实现。我加到待办里。有了它，大部分情况是能修复的，而不是报这个错。

英文原文

That is what happens if you copy wallet files around. If you copy your wallet file to a second computer, then they both think the money in the wallet is theirs. If one spends any of it, the other doesn't know those coins are already spent and would try to spend them again, and that's the error you would hit.

Now that it's clear this is a key error message, it ought to be something more like "the money appears to be already spent... this could happen if you used a copy of your wallet file on another computer."

You can move or backup your wallet file, but it needs to have only one "lineage" and only used in one place at a time. Any time you transfer money out of it, then you must no longer use any previous copies.

This brings up a good point. In the case of restoring a backup that may be from before you spent some coins, we need to add functionality to resync it to discover which coins have already been spent. This would not be hard to do, it just hasn't been implemented yet. I'll add it to the list. This would make it mostly repair the situation instead of giving that error message.

Re: [bitcoin-list] Bitcoin v0.1.5 released

Mon, 01 Jan 0001 00:00:00 +0000

FromSatoshi Nakamoto

SubjectRe: [bitcoin-list] Bitcoin v0.1.5 released

Date2009-03-04 16:59:12 UTC

Listbitcoin-list · 原文

Hal Finney 写道：
> 听起来不错。我也想能运行多个币/区块
> 生成器，在多台机器上，都在同一个 NAT 地址后面。我
> 还没试过，不知道在当前软件上能不能行。

当前版本可以正常工作。它们各自通过互联网
连接，而入站连接只会到达 8333 端口被路由到的那台
主机。

作为一种优化，我会加一个开关 "-connect=1.2.3.4"，让它只连接
到一个指定的地址。你可以让额外的节点连接到你的主
节点，只有主节点通过互联网连接。这现在其实没多大关系，
因为网络要变得巨大，带宽消耗才会有非同小可的量。

对了，我不记得我们有没有聊过，但前几天有人提到
安全的时间戳。你想能证明某个文件在过去的某个时间
确实存在过。在我看来，比特币的区块栈非常适合这个。

确实，比特币是交易的分布式安全时间戳服务器。几行代码
就能创建一笔带有一个额外哈希的交易，给任何需要打时间戳的
东西打上戳。我应该加一个命令，用这种方式给文件打时间戳。

> > 之后我想添加接口，让从任何服务端语言集成
> > 到网站变得非常简单。

对，我也希望能看到更多库接口，可以在
客户端从编程或脚本语言调用。

完全同意。

Satoshi Nakamoto

http://www.bitcoin.org

英文原文

Hal Finney wrote:
> That sounds good. I'd also like to be able to run multiple coin/block
> generators on multiple machines, all behind a single NAT address. I
> haven't tried this yet so I don't know if it works on the current
> software.

The current version will work fine. They'll each connect over the
Internet, while incoming connections only come to the host that
port 8333 is routed to.

As an optimisation, I'll make a switch "-connect=1.2.3.4" to make
it only connect to a specific address. You could make your extra
nodes connect to your primary, and only the primary connects over
the Internet. It doesn't really matter for now, since the network
would have to get huge before the bandwidth is anything more than
trivial.

BTW I don't remember if we talked about this, but the other day some
people were mentioning secure timestamping. You want to be able to
prove that a certain document existed at a certain time in the past.
Seems to me that bitcoin's stack of blocks would be perfect for this.

Indeed, Bitcoin is a distributed secure timestamp server for
transactions. A few lines of code could create a transaction with
an extra hash in it of anything that needs to be timestamped.
I should add a command to timestamp a file that way.

> > Later I want to add interfaces to make it really easy to integrate
> > into websites from any server side language.

Right, and I'd like to see more of a library interface that could be
called from programming or scripting languages, on the client side as
well.

Exactly.

Satoshi Nakamoto

http://www.bitcoin.org

Re: A newb's test - anyone want to buy a picture for $1?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: A newb's test - anyone want to buy a picture for $1?

Date2010-01-28 01:01:48 UTC

ForumBitcointalk · 原文

是的，这是技术限制。通过比特币地址发送，是把交易记进网络，接收方从网络上发现它。你不直接跟对方连接，对方当时也不必在线。

我很想找办法附上一段短消息，但问题是，全世界都能看到这条消息。你再怎么提醒大家消息完全没有隐私可言，都难免出事。

不幸的是，ECDSA 只能签名，不能加密消息，而我们需要 ECDSA 的小体积。RSA 能加密消息，但比 ECDSA 大很多倍。

英文原文

Yes, it's a technical limitation. Sending by bitcoin address enters the transaction into the network and the recipient discovers it from the network. You don't connect directly with them and they don't have to be online at the time.

I very much wanted to find some way to include a short message, but the problem is, the whole world would be able to see the message. As much as you may keep reminding people that the message is completely non-private, it would be an accident waiting to happen.

Unfortunately, ECDSA can only sign signatures, it can't encrypt messages, and we need the small size of ECDSA. RSA can encrypt messages, but it's many times bigger than ECDSA.

Re: [bitcoin-list] Does Bitcoin Crash in Windows?

Mon, 01 Jan 0001 00:00:00 +0000

FromSatoshi Nakamoto

SubjectRe: [bitcoin-list] Does Bitcoin Crash in Windows?

Date2009-10-23 23:57:51 UTC

Listbitcoin-list · 原文

Liberty Standard 写道：
> 你们 Windows 用户有没有偶尔遇到比特币崩溃？
> 最近在 wine-1.0.1 下运行的比特币频繁崩溃。我只是
> 想知道这是 Wine 的问题还是比特币的问题。

我没收到过 v0.1.5 崩溃的报告。在我这里的 Windows 上它一直稳
如磐石。我想这应该是 Wine 相关的问题。如果你在 Wine 里又崩溃了，
终端打印了什么，请发邮件给我，我也许能弄清楚发生了什么，
也许能想办法绕过去。Martti 和我一直在做一个即将发布的
新版本，如果能把 Wine 的修复也放进去就好了。

启动比特币时，终端会打印下面这四行。
fixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot
fixme:toolhelp:Heap32ListFirst : stub
fixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot
fixme:toolhelp:Heap32ListFirst : stub

那些看起来没什么可担心的。大概是 Wine 未实现、被无害地打桩
的函数。

我以前不是从终端启动比特币，所以不知道崩溃时会打印
什么，但下次崩溃时我会把结果回复给你。

比特币第一次下载之前已完成的区块时，文件
debug.log 会增长到 17.4 MB 然后停止增长。我猜它会随着更多比特币
被完成而继续增长。

如果你不想占磁盘空间，可以偶尔删除 debug.log。它只是帮助
调试的状态信息。

bitcoin.sourceforge.net 现在看起来正常了。可能是 sourceforge 在
做一些维护。

Satoshi

英文原文

Liberty Standard wrote:
> Do you Windows users experience occasional Bitcoin crashes?
> Lately Bitcoin running in wine-1.0.1 has been crashing frequently. I was
> just wondering whether this is a Wine issue or a Bitcoin issue.

I haven't had any reports of crashes in v0.1.5. It's been rock solid
for me on Windows. I think it must be Wine related. If you get another
crash in Wine and it prints anything on the terminal, e-mail me and I
may be able to figure out what happened, maybe something I can work
around. Martti and I have been working on a new version to release soon
and it would be nice to get any Wine fixes in there.

The following four lines print from the terminal when I start Bitcoin.
fixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot
fixme:toolhelp:Heap32ListFirst : stub
fixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot
fixme:toolhelp:Heap32ListFirst : stub

Those don't look like anything to worry about. Probably functions
unimplemented by Wine that are harmlessly stubbed out.

I previously wasn't starting Bitcoin from the terminal, so I don't know what
gets printed out when it crashes, but I'll reply with the results the next
time it crashes.

While Bitcoin first downloads previously completed blocks, the file
debug.log grows grows to 17.4 MB and then stops growing. I imagine it will
continue to grow as more bitcoins are completed.

You can delete debug.log occasionally if you don't want to take the disk
space. It's just status messages that help with debugging.

bitcoin.sourceforge.net looks fine now. Maybe sourceforge was doing
some maintenance.

Satoshi

Re: Blocks never stop generating?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Blocks never stop generating?

Date2010-01-28 01:08:33 UTC

ForumBitcointalk · 原文

状态栏里写着"# blocks"的地方，我要改成"# confirmations"。这样可能更清楚。

双击那笔交易能看到更多一点的信息。

英文原文

Where it says "# blocks" in the status column I'm changing it to say "# confirmations". That might be clearer.

If you doubleclick on the transaction you get a little more information.

[bitcoin-list] Bitcoin 0.2 released

Mon, 01 Jan 0001 00:00:00 +0000

FromSatoshi Nakamoto

Subject[bitcoin-list] Bitcoin 0.2 released

Date2009-12-17 06:52:09 UTC

Listbitcoin-list · 原文

Bitcoin 0.2 来了！

下载（Windows，以及现已提供 Linux 版本）
http://sourceforge.net/projects/bitcoin/files/

新功能

Martti Malmi
- 最小化到系统托盘选项
- 开机自启动选项，可自动在后台保持运行
- 新的选项对话框布局，便于未来扩展
- Windows 安装程序
- Linux 版本（在 Ubuntu 上测试过）
Satoshi Nakamoto
- 币生成的多处理器支持
- 支持配合 TOR 使用的代理
- 修复了初始区块下载中的一些缓慢问题

我们还在 http://www.bitcoin.org/smf/ 建立了一个新论坛

感谢 Martti (sirius-m) 所有的开发工作，也感谢 New Liberty Standard 在
测试 Linux 版本中的帮助。

Satoshi Nakamoto

英文原文

Bitcoin 0.2 is here!

Download (Windows, and now Linux version available)
http://sourceforge.net/projects/bitcoin/files/

New Features

Martti Malmi
- Minimize to system tray option
- Autostart on boot option so you can keep it running in the
background automatically
- New options dialog layout for future expansion
- Setup program for Windows
- Linux version (tested on Ubuntu)
Satoshi Nakamoto
- Multi-processor support for coin generation
- Proxy support for use with TOR
- Fixed some slowdowns in the initial block download

We also have a new forum at http://www.bitcoin.org/smf/

Many thanks to Martti (sirius-m) for all his development work, and to
New Liberty Standard for his help with testing the Linux version.

Satoshi Nakamoto

Re: Bitcoin crash when sending coins

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Bitcoin crash when sending coins

Date2010-01-28 23:08:02 UTC

ForumBitcointalk · 原文

重新同步的想法是：遍历你的钱包，跟区块索引对一遍，找出你的这台电脑还不知道已经被花掉的交易。可能的情况是：这些币是在另一台用了钱包副本的电脑上花掉的，或者你把钱包恢复到了花掉它们之前的备份。目前软件只是假定自己永远知道交易花没花掉，因为花的时候它会在 wallet.dat 里标记已花掉。

钱包合并工具可以实现，但有了重新同步，大部分问题都解决了，需求就小多了。有了重新同步，你把一台钱包的钱全转到另一台，基本能达到同样的效果：接收方重新同步，发现重叠的币都被花掉了，然后在新交易里收到它们。

英文原文

The resync idea would go through your wallet and check it against the block index to find any transactions that your current computer doesn't realize are already spent. That could happen if they were spent on another computer with a copy of the wallet file, or you had to restore the wallet to a backup from before they were spent. Currently, the software just assumes it always knows whether its transactions are spent because it marks them spent in wallet.dat when it spends them.

A wallet merge tool is possible to implement but much less in demand once resync solves most of the problem. With resync, you could do about the same thing by sending all the money from one wallet to the other. The receiver would resync and discover all its overlapping coins were spent, then receive them in the new transaction.

[bitcoin-list] Bitcoin 0.3 released!

Mon, 01 Jan 0001 00:00:00 +0000

FromSatoshi Nakamoto

Subject[bitcoin-list] Bitcoin 0.3 released!

Date2010-07-06 21:53:53 UTC

Listbitcoin-list · 原文

宣布比特币 0.3 版本发布，点对点加密货币！比特币是一种
使用密码学和分布式网络的数字货币，以取代对可信中央
服务器的需求。摆脱集中管理货币的任意通胀风险！比特币的总流通量
限制为 2100 万币。币会根据节点贡献的 CPU 算力逐步释放给
网络节点，所以贡献你的闲置 CPU 时间就能获得其中的一份。

新内容：
- 命令行和 JSON-RPC 控制
- 包含一个无 GUI 的守护进程版本
- 交易过滤标签页
- 哈希速度提升 20%
- Hashmeter 性能显示
- Mac OS X 版本（感谢 Laszlo）
- 德语、荷兰语和意大利语翻译（感谢 DataWraith、Xunie
和 Joozero）

在 http://www.bitcoin.org 获取，并阅读论坛了解更多。

英文原文

Announcing version 0.3 of Bitcoin, the P2P cryptocurrency! Bitcoin is a
digital currency using cryptography and a distributed network to replace
the need for a trusted central server. Escape the arbitrary inflation
risk of centrally managed currencies! Bitcoin's total circulation is
limited to 21 million coins. The coins are gradually released to the
network's nodes based on the CPU power they contribute, so you can get a
share of them by contributing your idle CPU time.

What's new:
- Command line and JSON-RPC control
- Includes a daemon version without GUI
- Transaction filter tabs
- 20% faster hashing
- Hashmeter performance display
- Mac OS X version (thanks to Laszlo)
- German, Dutch and Italian translations (thanks to DataWraith, Xunie
and Joozero)

Get it at http://www.bitcoin.org, and read the forum to find out more.

Re: Payment server

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Payment server

Date2010-01-28 23:26:09 UTC

ForumBitcointalk · 原文

riX 说的没错，就是该这么做。软件可以每次付款都生成一个新的比特币地址。"Please send X bc to [single-use bitcoin address] to complete your order"（请把 X bc 发到[一次性比特币地址]以完成订单）。服务器收到发到这个比特币地址的款，就可以触发自动履约，或给店主发邮件。

加命令行支持是高优先级。只是需要时间写代码。

英文原文

That's the right way to do it as riX says. The software can generate a new bitcoin address whenever you need one for each payment. "Please send X bc to [single-use bitcoin address] to complete your order" When the server receives that amount to the bitcoin address, that could trigger it to automatically fulfil the order or e-mail the shop owner.

Adding command line support is a high priority. It's just a matter of getting the time to code it.

[bitcoin-list] Alert: upgrade to bitcoin 0.3.6

Mon, 01 Jan 0001 00:00:00 +0000

FromSatoshi Nakamoto

Subject[bitcoin-list] Alert: upgrade to bitcoin 0.3.6

Date2010-07-30 06:02:38 UTC

Listbitcoin-list · 原文

请尽快升级到 0.3.6，以获取一个重要的 bug 修复。

下载链接见 bitcoin.org 主页。

英文原文

Please upgrade to 0.3.6 ASAP to get an important bugfix.

See the bitcoin.org homepage for download links.

Re: A newb's test - anyone want to buy a picture for $1?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: A newb's test - anyone want to buy a picture for $1?

Date2010-01-29 00:22:13 UTC

ForumBitcointalk · 原文

订单付款的推荐做法：
1) 商家有固定 IP，顾客发到它并附上留言。
2) 商家创建一个新的比特币地址给顾客，顾客发到这个地址。这会是网站软件的标准做法。

RSA vs ECDSA：不是可执行文件的体积问题，是数据的体积。我觉得如果区块链、比特币地址、磁盘空间和带宽需求都大一个数量级，就不切实际了。而且就算用 RSA 传消息，比特币网络本身还是用 ECDSA 合理，只在消息部分并行用 RSA。那样的话，到目前为止实现的东西会原样保留。

我们可以晚得多再想怎么做最好。它可以用另一套（也许现成的）邮件或即时通讯基础设施来传消息，不用 RSA 也行，也许只在交易里放消息的哈希，证明这笔交易对应消息里描述的订单。消息里得加盐，不然别人可以暴力破解哈希，还原出短消息。

英文原文

The recommended ways to do a payment for an order:
1) The merchant has a static IP, the customer sends to it with a comment.
2) The merchant creates a new bitcoin address, gives it to the customer, the customer sends to that address. This will be the standard way for website software to do it.

RSA vs ECDSA: it's not the size of the executable but the size of the data. I thought it would be impractical if the block chain, bitcoin addresses, disk space and bandwidth requirements were all an order of magnitude bigger. Also, even if using RSA for messages, it would still make sense to do all the bitcoin network with ECDSA and use RSA in parallel for only the message part. In that case, everything that's been implemented up to now would be implemented exactly as it has been.

We can figure out the best way to do this much later. It could use a separate (maybe existing) e-mail or IM infrastructure to pass messages, and instead of RSA, maybe just put a hash of the message in the transaction to prove that the transaction is for the order described in the message. The message would have to include a salt so nobody could brute force the hash to reveal a short message.

[bitcoin-list] ALERT - we are investigating a problem

Mon, 01 Jan 0001 00:00:00 +0000

FromSatoshi Nakamoto

Subject[bitcoin-list] ALERT - we are investigating a problem

Date2010-08-15 20:38:33 UTC

Listbitcoin-list · 原文

*** 警告 *** 我们正在调查一个问题。在问题解决之前，请勿信任在
15.08.2010 17:05 UTC（区块 74638）之后发生的任何交易。

英文原文

*** WARNING *** We are investigating a problem. DO NOT TRUST ANY
TRANSACTIONS THAT HAPPENED AFTER 15.08.2010 17:05 UTC (block 74638)
until the issue is resolved.

Re: 64bit support

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: 64bit support

Date2010-01-29 00:42:49 UTC

ForumBitcointalk · 原文

我提交了 64 位编译的修复，还有支持 wxWidgets 2.9.0 的一些修复。

serialize.h 里有个 min(sizeof()) 的编译错误，我修了 64 位的。我遇到的其他 64 位编译错误都在 wxWidgets 2.8.9 里，所以我开始做 wxWidgets 2.9.0 的支持。

wxWidgets 2.9.0 是 UTF-8 的。我们一直在用 wxWidgets 2.8.9 的 ANSI 版，就是等 wxWidgets 的 UTF-8 支持。

我在 64 位 Ubuntu 9.10 Karmic 上编译运行了。

我觉得剩下的唯一 bug 是状态数字显示挤在一起。我怀疑是 UTF-8 的问题，但想不出怎么会这样。还没细查。

build-unix.txt 更新了，SVN 上有两个 makefile：
makefile.unix.wx2.8
makefile.unix.wx2.9

不幸的是，我们用的两个 wxWidgets 版本目前都没有 debian 包。他们只有 wxWidgets 2.8 的 wchar（"unicode"）版，这是个灾难，因为 wchar 的 wxString 转不成 std::string。我们用 ANSI 版 wxWidgets 2.8 或 wxWidgets 2.9。所以你还得自己拿下来编译。

英文原文

I committed a fix for 64-bit compile and some fixes to support wxWidgets 2.9.0.

There was one compile error in serialize.h with min(sizeof()) that I fixed for 64-bit. The rest of the 64-bit compile errors I was getting were in wxWidgets 2.8.9, so I started working on supporting wxWidgets 2.9.0.

wxWidgets 2.9.0 is UTF-8. We've been using the ANSI version of wxWidgets 2.8.9 in anticipation of wxWidgets UTF-8 support.

I compiled and ran on 64-bit Ubuntu 9.10 Karmic.

I think the only bug left is where the status number is mashed up. I'm not sure why, I have to suspect it's a UTF-8 thing, but no idea how that could happen. Haven't looked into it.

build-unix.txt is updated and two makefiles on SVN:
makefile.unix.wx2.8
makefile.unix.wx2.9

Unfortunately there's still no debian package for either version of wxWidgets we use. They only have the wchar ("unicode") version of wxWidgets 2.8, which is a disaster because wchar wxString doesn't convert to std::string. We use either ANSI wxWidgets 2.8, or wxWidgets 2.9. So you still have to get it and build it yourself.

[bitcoin-list] Bitcoin 0.3.18 is released

Mon, 01 Jan 0001 00:00:00 +0000

FromSatoshi Nakamoto

Subject[bitcoin-list] Bitcoin 0.3.18 is released

Date2010-12-08 23:11:55 UTC

Listbitcoin-list · 原文

0.3.18 版本现已发布。

变更：
- 修复了从 0.3.17 降级后再升级时出现的 wallet.dat 兼容性问题
- IsStandard() 检查，只把已知交易类型包含进区块
- Jgarzik 的优化，略微加快初始区块下载

本版本的主要新增是 Gavin 一直在做的基于账户的 JSON-RPC
命令（更多详情见 http://www.bitcoin.org/smf/index.php?topic=1886.0）。
- getaccountaddress
- sendfrom
- move
- getbalance
- listtransactions

下载：
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.18/

英文原文

Version 0.3.18 is now available.

Changes:
- Fixed a wallet.dat compatibility problem if you downgraded from 0.3.17
and then upgraded again
- IsStandard() check to only include known transaction types in blocks
- Jgarzik's optimisation to speed up the initial block download a little

The main addition in this release is the Accounts-based JSON-RPC
commands that Gavin's been working on (more details at
http://www.bitcoin.org/smf/index.php?topic=1886.0).
- getaccountaddress
- sendfrom
- move
- getbalance
- listtransactions

Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.18/

Re: Bitcoin crash when sending coins

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Bitcoin crash when sending coins

Date2010-02-03 23:29:57 UTC

ForumBitcointalk · 原文

我把这个修复传到 SVN 了。它会盯着已花掉的币，在加载时更新你的钱包，之后区块进来时也会持续更新。我还换了个更好的报错信息，但它应该永远碰不到，因为它总能提前发现已花掉的币，除非你在两台电脑上同时花同一笔钱。

想试的话，给我私信或发邮件，告诉我邮箱（我发附件给你），还有你的系统（win、linux 32 位、linux 64 位）。

英文原文

I uploaded this fix to the SVN. It watches for spent coins and updates your wallet on load and also continuously as blocks come in. I also put a better error message, but it should never hit it because it always finds spent coins ahead of time, unless you spent the same money at the same time on two computers at once.

If you want to try it, PM or e-mail me your e-mail address where I can send it as an attachment and also what OS (win, linux 32-bit, linux 64-bit).

[bitcoin-list] Bitcoin 0.3.19 is released

Mon, 01 Jan 0001 00:00:00 +0000

FromSatoshi Nakamoto

Subject[bitcoin-list] Bitcoin 0.3.19 is released

Date2010-12-13 16:12:09 UTC

Listbitcoin-list · 原文

这是一个次要版本，增加了一些 DoS 防护。

变更：
- 增加了一些 DoS 限制，不过距离真正抗 DoS 还差得很远。
- 移除了“safe mode”警报。

http://www.bitcoin.org/smf/index.php?topic=2228.0

下载：
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.19/

英文原文

This is a minor release to add some DoS protection.

Changes:
- Added some DoS limits, though it's still far from DoS resistant.
- Removed "safe mode" alerts.

http://www.bitcoin.org/smf/index.php?topic=2228.0

Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.19/

Re: Win32 CPU Cycles vs 'Live Protection' Engines ?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Win32 CPU Cycles vs 'Live Protection' Engines ?

Date2010-02-03 23:36:54 UTC

ForumBitcointalk · 原文

谢了。你用的哪个 Windows 版本？

英文原文

Thanks for that. Which version of Windows?

Re: Questions about Addresses

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Questions about Addresses

Date2010-02-04 00:07:07 UTC

ForumBitcointalk · 原文

端口转发是把一个端口转发到一台电脑。它告诉路由器哪台电脑处理连到这个端口的连接。所以收到的是那台电脑。

如果你没设端口转发，入站连接就到不了任何电脑，别人发到这个 IP 会提示连不上接收方，什么都发不出去。通过 IP 发送时，你还是发到一个比特币地址，只不过你的电脑连到那个 IP，从它那里拿到一个新的比特币地址，把交易直接交给对方，并确认已收到、已接受。

应该有人把自己的固定 IP 发出来，让大家试试通过 IP 发送，也顺便给那人送点免费的钱。

比特币地址里有个 32 位校验码，所以你不可能手误输错成一个无效地址。

第 4) 条，如果你发给了一个已经放弃或弄丢 wallet.dat 的接收方，钱就丢了。可以顺带说一句：既然流通中的钱总量少了，大家手里剩下的钱就稍微更值钱一点，也就是"自然通缩"。

英文原文

Port forwarding forwards a port to one computer. It tells the router which computer handles connections to that port. So that's the computer receiving.

If you didn't set up port forwarding, then incoming connections won't go to any computer, and attempts to send to that IP would just say it couldn't connect to the recipient and nothing is sent. When sending by IP, you still send to a bitcoin address, but your computer connects to that IP, gets a new bitcoin address from it, gives the transaction directly to the them and confirms that it was received and accepted.

Someone should post their static IP so people can try out sending by IP and also give that user free money.

There's a 32-bit checksum in bitcoin addresses so you can't accidentally type an invalid address.

If 4) you send to a recipient who has abandoned or lost their wallet.dat, then the money is lost. A subtle point can be made that since there is then less total money in circulation, everyone's remaining money is worth slightly more, aka "natural deflation".

Re: TOR and I2P

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: TOR and I2P

Date2010-02-04 00:30:50 UTC

ForumBitcointalk · 原文

用代理端口 9050 时，它只会尝试连一次 IRC，然后放弃，因为它知道大概率永远连不上——IRC 服务器封禁了所有 TOR 出口节点。如果你用别的端口，它会以为那是个普通的老式代理，以越来越长的间隔不断重试 IRC。你不该用 Polipo 或 Privoxy，那些是 http 过滤器和缓存，改动了比特币的消息就会把它搞坏。比特币可能会试图重连来对抗。你应该用 9050 端口。

正如 riX 说的，"is giving Tor only an IP address. Apps that do DNS..." 这些警告不用担心。代理模式下比特币根本不用 DNS。

因为比特币通过 Tor 连不上 IRC，它不知道现在哪些节点在线，所以只能把最近见过的节点都试一遍。它尽量省着用连接尝试，但大家又希望启动时连得快、断线后重连快。它用的算法是：一个 IP 上次成功连接是越久以前的事，重试间隔就越长。比如，一个 24 小时前见过的节点，它会每 5 小时试连一次。一旦有了至少 2 个连接，超过一周没见过的就不再试；有了 5 个连接，超过 24 小时没见过的就不再试。

英文原文

When using proxy port 9050, it will only make one attempt to connect to IRC, then give up, since it knows it will probably always fail because IRC servers ban all the TOR exit nodes. If you're using another port, it would assume it might be a regular old normal proxy and would keep retrying IRC at longer and longer intervals. You should not use Polipo or Privoxy as those are http filters and caches that would corrupt Bitcoin's messages if they make any changes. Bitcoin might be trying to overcome it by reconnecting. You should use port 9050.

As riX says, the "is giving Tor only an IP address. Apps that do DNS..." warnings are nothing to worry about. Bitcoin doesn't use DNS at all in proxy mode.

Since Bitcoin can't get through to IRC through Tor, it doesn't know which nodes are currently online, so it has to try all the recently seen nodes. It tries to conserve connection attempts as much as possible, but also people want it to connect quickly when they start it up and reconnect quickly if disconnected. It uses an algorithm where it tries an IP less and less frequently the longer ago it was successful connected. For example, for a node it saw 24 hours ago, it would wait 5 hours between connection attempts. Once it has at least 2 connections, it won't try anything over a week old, and 5 connections it won't try anything over 24 hours old.

Proof-of-work difficulty increasing

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleProof-of-work difficulty increasing

Date2010-02-05 19:19:12 UTC

ForumBitcointalk · 原文

我们在 2009 年 12 月 30 日做了第一次工作量证明难度的自动调整。

最低难度是 32 个零比特，所以就算全网只有一个人在跑节点，难度也不会比这更低。去年大部分时间我们都在最低难度以下晃。12 月 30 日我们突破了它，算法调高了难度。从那以后每次调整都在变难。

2 月 4 日那次调整，把难度从去年的 1.34 倍提到了比去年难 1.82 倍。就是说同样的工作量，只能生成 55% 的币。

难度按全网总算力的比例调整。如果节点数翻倍，难度也翻倍，总产出回到目标速率。

懂技术的可以在 debug.log 里搜"target:"看到工作量证明难度。它是一个 256 位无符号十六进制数，SHA-256 值必须小于它才能成功生成区块。每 2016 个区块（通常两周）调整一次，这时 debug.log 会打印"GetNextWorkRequired RETARGET"。

minimum 00000000ffff0000000000000000000000000000000000000000000000000000
30/12/2009 00000000d86a0000000000000000000000000000000000000000000000000000
11/01/2010 00000000c4280000000000000000000000000000000000000000000000000000
25/01/2010 00000000be710000000000000000000000000000000000000000000000000000
04/02/2010 000000008cc30000000000000000000000000000000000000000000000000000
14/02/2010 0000000065465700000000000000000000000000000000000000000000000000
24/02/2010 0000000043b3e500000000000000000000000000000000000000000000000000
08/03/2010 00000000387f6f00000000000000000000000000000000000000000000000000
21/03/2010 0000000038137500000000000000000000000000000000000000000000000000
01/04/2010 000000002a111500000000000000000000000000000000000000000000000000
12/04/2010 0000000020bca700000000000000000000000000000000000000000000000000
21/04/2010 0000000016546f00000000000000000000000000000000000000000000000000
04/05/2010 0000000013ec5300000000000000000000000000000000000000000000000000
19/05/2010 00000000159c2400000000000000000000000000000000000000000000000000
29/05/2010 000000000f675c00000000000000000000000000000000000000000000000000
11/06/2010 000000000eba6400000000000000000000000000000000000000000000000000
24/06/2010 000000000d314200000000000000000000000000000000000000000000000000
06/07/2010 000000000ae49300000000000000000000000000000000000000000000000000
13/07/2010 0000000005a3f400000000000000000000000000000000000000000000000000
16/07/2010 000000000168fd00000000000000000000000000000000000000000000000000
27/07/2010 00000000010c5a00000000000000000000000000000000000000000000000000
05/08/2010 0000000000ba1800000000000000000000000000000000000000000000000000
15/08/2010 0000000000800e00000000000000000000000000000000000000000000000000
26/08/2010 0000000000692000000000000000000000000000000000000000000000000000

date, difficulty factor, % change
2009 1.00
30/12/2009 1.18 +18%
11/01/2010 1.31 +11%
25/01/2010 1.34 +2%
04/02/2010 1.82 +36%
14/02/2010 2.53 +39%
24/02/2010 3.78 +49%
08/03/2010 4.53 +20%
21/03/2010 4.57 +9%
01/04/2010 6.09 +33%
12/04/2010 7.82 +28%
21/04/2010 11.46 +47%
04/05/2010 12.85 +12%
19/05/2010 11.85 -8%
29/05/2010 16.62 +40%
11/06/2010 17.38 +5%
24/06/2010 19.41 +12%
06/07/2010 23.50 +21%
13/07/2010 45.38 +93%
16/07/2010 181.54 +300%
27/07/2010 244.21 +35%
05/08/2010 352.17 +44%
15/08/2010 511.77 +45%
26/08/2010 623.39 +22%

英文原文

We had our first automatic adjustment of the proof-of-work difficulty on 30 Dec 2009.

The minimum difficulty is 32 zero bits, so even if only one person was running a node, the difficulty doesn't get any easier than that. For most of last year, we were hovering below the minimum. On 30 Dec we broke above it and the algorithm adjusted to more difficulty. It's been getting more difficult at each adjustment since then.

The adjustment on 04 Feb took it up from 1.34 times last year's difficulty to 1.82 times more difficult than last year. That means you generate only 55% as many coins for the same amount of work.

The difficulty adjusts proportionally to the total effort across the network. If the number of nodes doubles, the difficulty will also double, returning the total generated to the target rate.

For those technically inclined, the proof-of-work difficulty can be seen by searching on "target:" in debug.log. It's a 256-bit unsigned hex number, which the SHA-256 value has to be less than to successfully generate a block. It gets adjusted every 2016 blocks, typically two weeks. That's when it prints "GetNextWorkRequired RETARGET" in debug.log.

Re: Questions about Addresses

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Questions about Addresses

Date2010-02-05 19:44:46 UTC

ForumBitcointalk · 原文

引用自：Sabunir，2010 年 2 月 5 日 05:31:30 PM（https://bitcointalk.org/index.php?topic=34.msg246#msg246）

是不是该有个功能防这个？比如，如果一笔交易长时间（一个月？）没被接收方接受，交易就取消，币退回给发送方？

不可能。钱的控制权已经交到了接收方的密钥对手里，只有那个密钥能动它。

就像你用 AES 加高强度密码加密了个文件，然后把密码弄丢了，数据就没了。

英文原文

Quote from: Sabunir on February 05, 2010, 05:31:30 PM（https://bitcointalk.org/index.php?topic=34.msg246#msg246）Perhaps there should be a feature against this? For instance, if a transaction isn't accepted by the recipient for a long period of time (a month?), the transaction will be canceled and the coins returned to the one who sent them?

That's not possible. You've handed control of the money over to the recipient's keypair. Only that key can control it.

It's similar to if you encrypt a file with AES and a strong password, and you lose the password. The data is lost.

Re: Repost: Request: Make this anonymous?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Repost: Request: Make this anonymous?

Date2010-02-06 21:06:32 UTC

ForumBitcointalk · 原文

当你发到一个比特币地址时，你并不连接接收方。你把交易发给网络，跟你转发交易的方式一样。你自己发起的交易和你从别的节点收到、正在广播转发的交易，没有区别。不过网络还很小的时候，有人也许还能用排除法猜出来。等网络大了会好一些。

如果你通过 IP 发送，接收方能看到你，因为你连到了他们的 IP。你可以用 TOR 遮一下。

如果你连比特币都不想让人知道你在用，可以用 TOR。

比特币还很新，还没有被独立分析过。如果你真在意隐私，TOR 是值得采取的预防措施。

英文原文

When you send to a bitcoin address, you don't connect to the recipient. You send the transaction to the network the same way you relay transactions. There's no distinction between a transaction you originated and one you received from another node that you're relaying in a broadcast. With a very small network though, someone might still figure it out by process of elimination. It'll be better when the network is larger.

If you send by IP, the recipient sees you because you connect to their IP. You could use TOR to mask that.

You could use TOR if you don't want anyone to know you're even using Bitcoin.

Bitcoin is still very new and has not been independently analysed. If you're serious about privacy, TOR is an advisable precaution.

Re: How divisible are bitcoins and other market/economic questions

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: How divisible are bitcoins and other market/economic questions

Date2010-02-06 23:25:53 UTC

ForumBitcointalk · 原文

如果它真的发展壮大，最终全世界 68 亿人最多只有 2100 万枚币。

但别担心，内部还有 6 位没显示出来的小数，一共 8 位。它显示 1.00，内部是 1.00000000。如果未来出现大规模通缩，软件可以显示更多小数位。

如果跟小数打交道太烦，我们可以改显示小数点的位置。钱的数额不变，只是小数点和千分位的约定不同。比如小数点右移 3 位，之前显示 1.00000 的，现在显示 1,000.00。

英文原文

Eventually at most only 21 million coins for 6.8 billion people in the world if it really gets huge.

But don't worry, there are another 6 decimal places that aren't shown, for a total of 8 decimal places internally. It shows 1.00 but internally it's 1.00000000. If there's massive deflation in the future, the software could show more decimal places.

If it gets tiresome working with small numbers, we could change where the display shows the decimal point. Same amount of money, just different convention for where the ","'s and "."'s go. e.g. moving the decimal place 3 places would mean if you had 1.00000 before, now it shows it as 1,000.00.

Re: Make your "we accept Bitcoin" logo

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Make your "we accept Bitcoin" logo

Date2010-02-08 01:22:29 UTC

ForumBitcointalk · 原文

没有，抱歉。我一直想重做。看起来还行的最大图标是 20x20 的，就是 GNOME 托盘图标用的那个。再大就难看了。16x16 和 20x20 的都做了不少手工微调，才让像素对齐。如果你直接把大图缩小，像素会糊，"BC"里的线条落不到像素格点上，看着别扭。

带完整 alpha 通道的最佳 16x16 在 src/rc/bitcoin.ico 里。32x32 的那个我不喜欢。

我附上 bitcoin20x20.png，带全透明的 20x20 版。

英文原文

No, sorry. I've been meaning to redo it. The largest icon that still looks good is the 20x20 one which is used for the tray icon in GNOME. Any larger than that looks bad. The 16x16 and 20x20 ones have quite a bit of hand tweaking to get the pixels to work out right. If you just scale down a larger image, the pixels end up blurred and awkward in places where the lines in "BC" don't land square on a pixel.

The best 16x16 with full alpha channel is in src/rc/bitcoin.ico. I don't like the 32x32 version.

I'm attaching bitcoin20x20.png, the 20x20 version with full transparency.

Bitcoin client and website translation

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleBitcoin client and website translation

Date2010-02-08 01:27:02 UTC

ForumBitcointalk · 原文

谢谢你愿意帮忙翻译。这大概是你能帮上的最好的忙。

我得先把代码准备好做翻译。wxWidgets 有 locale 支持，大部分字符串在已封装的生成代码里，应该不难。我们还得先完成升级到 wxWidgets-2.9.0 才有 UTF-8 支持。我用 2.9.0 做过测试构建，还剩一个 bug 要修。

你用的什么系统？Windows、Linux 32 位还是 64 位？

从另一个帖子拆分出来（https://www.bitcoin.org/smf/index.php?topic=44）。
sirius-m

英文原文

Thank you for the offer to help translate. That is probably the best way you could help.

I will need to prepare the code for translation first. wxWidgets has locale support, and most strings are in generated code that is already wrapped, so it shouldn't be too hard. We also must finish upgrading to wxWidgets-2.9.0 to get UTF-8 support. I've done test builds with 2.9.0 and there is one bug left to fix.

What operating system are you using? Windows, Linux 32-bit or 64 bit?

Split from another thread（https://www.bitcoin.org/smf/index.php?topic=44）.
sirius-m

Bitcoin client and website translation

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleBitcoin client and website translation

Date2010-02-08 16:10:37 UTC

ForumBitcointalk · 原文

单个二进制文件加多个 .mo 文件要省心得多。搞一堆构建变体维护工作量太大。软件支持一旦实现，谁都可以贡献翻译。

wxWidgets 用 gettext 标准。你用 gettext 工具或 poedit 之类的，扫描源文件里的字符串生成 .po 文件，把翻译填进去，再编译成 .mo 文件。程序运行时加载 .mo 文件，给所有字符串换皮。加新语言不用重新编译程序，加 .mo 文件就行。

在 Windows 上，.mo 文件放在 EXE 所在目录下的 lang 子目录。

我现在在做 JSON-RPC 和命令行支持，做完希望接下来做这个。

英文原文

It's much easier to have a single binary and multiple .mo files. It's too much maintenance work to have lots of build variations. Once the software support is implemented, anyone could contribute translations.

wxWidgets uses the gettext standard. You use the gettext tools or something like poedit to create a .po file by scanning the sourcefiles for strings and editing the translations into the .po file, then compile it into a .mo file. The program loads the .mo file at runtime and reskins all the strings. Additional languages can be added to an existing program by adding .mo files without recompiling the program.

On Windows, the .mo files would go in a lang subdirectory in the directory where the EXE is located.

Right now I'm working on JSON-RPC and command line support, but when I'm finished with that I hope to do this next.

Re: Simple to implement feature requests

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Simple to implement feature requests

Date2010-02-08 16:37:24 UTC

ForumBitcointalk · 原文

有这些命令行选项：

bitcoin -addnode=1.2.3.4 告诉 bitcoin 要连的节点
bitcoin -connect=1.2.3.4 只连指定的节点

可以多用几个，比如
bitcoin -connect=(先试这个) -connect=(再试这个) ...

-connect 可以指定不可路由的 IP，比如 192.168.x.x，所以如果你有个服务器群，想让一台服务器连外网、其余的都连这台服务器，可以这么做。

特别地，如果你一直走 TOR 连接，就需要 -addnode，因为 IRC 服务器封禁了所有 TOR 出口节点。走 TOR 连接可以这样：

bitcoin -proxy=127.0.0.1:9050 -addnode=212.159.72.216

英文原文

There are command line options:

bitcoin -addnode=1.2.3.4 to tell bitcoin about a node to connect to
bitcoin -connect=1.2.3.4 connect only to the specified node(s)

You can use more than one of these, for instance
bitcoin -connect=(first to try) -connect=(next to try) ...

You can specify non-routable IPs with -connect like 192.168.x.x, so if you had a server farm and you wanted one server to connect to the world and the rest to connect to the one server, you could do that.

In particular, -addnode is needed if you're always going to connect through TOR, since the IRC server blocks all the TOR exit nodes. To connect through TOR, you could use:

bitcoin -proxy=127.0.0.1:9050 -addnode=212.159.72.216

Re: DEB Package?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: DEB Package?

Date2010-02-12 02:33:02 UTC

ForumBitcointalk · 原文

你是只想跑程序，还是真要编译？有个 32 位 linux 二进制，在 64 位 ubuntu 上"sudo apt-get ia32-libs"就能跑。
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.2.0-linux.tar.gz/download

我最近更新了 SVN，可以在 64 位 Karmic 上用 wxWidgets 2.9.0 构建了。这是在 0.2.0 发布之后。0.2.0 发布版还不能在 64 位上构建。

不幸的是，我们能用的两个 wxWidgets 版本目前都没有 -dev 的 deb 包。Karmic 上只有 UTF-16 版。我们要么用 ANSI（libwxgtk2.8-ansi-dev）版，要么用 UTF-8（wxWidgets 2.9.0）版。我们正在往 2.9.0 走。

我知道你说不想用虚拟机，但万不得已的话，我上次试 Windows 版在 Wine 里跑得挺好。

英文原文

Are you just trying to run the program or do you really need to compile it? There's a 32-bit linux binary that can be run on 64-bit ubuntu if you "sudo apt-get ia32-libs".
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.2.0-linux.tar.gz/download

I recently updated the SVN for building on 64-bit Karmic with wxWidgets 2.9.0. This was after the 0.2.0 release. The 0.2.0 release did not build on 64-bit yet.

Unfortunately there currently isn't a -dev deb package of either of the versions of wxWidgets that we can use. On Karmic they only have the UTF-16 version. We need either the ANSI (libwxgtk2.8-ansi-dev) version or the UTF-8 (wxWidgets 2.9.0) version. We're moving towards 2.9.0.

I know you said you didn't want VM, but as a last resort, last I checked the Windows version runs fine in Wine.

Re: What's with this odd generation?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: What's with this odd generation?

Date2010-02-12 03:08:08 UTC

ForumBitcointalk · 原文

很大的交易有一点小额手续费。生成包含这笔交易的区块的节点得到这笔手续费。

同一笔钱再发一次，不会再收一次费。如果你钱包里全是生成的币，一次性全发出去一笔大交易，就得把几百个 50 bc 的币打包到一起。之后就只是一行，发送合并后的总额。

英文原文

There's a small transaction fee for very large transactions. The node that generates the block that contains the transaction gets the fee.

If the same money gets sent again, it won't incur the fee again. If all you have is generated coins in your wallet, if you send them all in one huge transaction, it has to bundle hundreds of 50 bc coins together. After that it's just one line to send the combined unit.

Re: DEB Package?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: DEB Package?

Date2010-02-12 15:57:37 UTC

ForumBitcointalk · 原文

引用自：soultcer，2010 年 2 月 12 日 02:31:50 PM（https://bitcointalk.org/index.php?topic=49.msg321#msg321）

需要的话，我可以提供预编译好的二进制。

是我漏了什么吗？bitcoin.org 上的 32 位 linux 预编译二进制有什么问题？

发行版里的 bitcoin 二进制静态链接了 wxWidgets 库，它的共享链接库（openssl 和 GTK）Ubuntu 自带，所以不用做成 .deb 去拉依赖也能跑。

因为要升级到 wxWidgets 2.9.0 来支持 UTF-8，而它还没有 DEB 包，我们还得继续静态链接。

英文原文

Quote from: soultcer on February 12, 2010, 02:31:50 PM（https://bitcointalk.org/index.php?topic=49.msg321#msg321）If you want, I can provide you with a precompiled binary.

Am I missing something? Is there something wrong with the 32-bit linux precompiled binary on bitcoin.org?

The bitcoin binary in the distribution static links the wxWidgets library, and its shared links (openssl and GTK) are included in Ubuntu, so it can run without needing to be a .deb to pull down dependencies.

Since we're upgrading to wxWidgets 2.9.0 for UTF-8, which doesn't have a DEB package yet, we'll continue to need to static link it.

Re: Repost: Request: Make this anonymous?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Repost: Request: Make this anonymous?

Date2010-02-12 17:28:32 UTC

ForumBitcointalk · 原文

没错，通过 Tor 用 IP 发送是拆东墙补西墙。Tor 出口节点能看到你消息的明文，还可能中间人攻击你。

最好只发到比特币地址。通过比特币地址的付款是作为正常网络流量的一部分在网络上广播的。跟网络的所有通信都是公开信息的广播。

英文原文

True, sending by IP through Tor trades one problem for another. The Tor exit node can see the text of your message and potentially MITM you.

Best to only send to bitcoin addresses then. Payments by bitcoin address are broadcast over the network as part of the normal network traffic. All communications with the network are broadcasts of public information.

Re: DEB Package?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: DEB Package?

Date2010-02-13 01:38:37 UTC

ForumBitcointalk · 原文

wxWidgets 2.8.9 我在 Karmic 64 位上也编译不过。

我一直在 Karmic 64 位上用 wxWidgets 2.9.0 编译最新的 SVN，64 位下编译没问题。看 build-unix.txt，按给的参数配 wxWidgets 的 ../configure，就能直接用附带的 makefile.unix.wx2.9。（--enable-debug --disable-shared --enable-monolithic）

2.9.0 还有个显示上的 bug 要修，状态数字显示挤在一起，不知为什么。——已修

首页的下载链接是 sourceforge 的 tar.gz 包，里面是 32 位二进制和 0.2.0 源码，当时还不能在 64 位上构建。

SVN 第一次能在 64 位上用 wx2.9.0 构建是 2010 年 1 月 28 日。

希望哪天他们能出 wxWidgets 2.9.0 的 debian 包。

英文原文

I couldn't get wxWidgets 2.8.9 to compile on Karmic 64-bit either.

I have been compiling the latest SVN on Karmic 64-bit with wxWidgets 2.9.0, which compiles fine on 64-bit. Read build-unix.txt and use the given ../configure parameters on wxWidgets so you can use the makefile.unix.wx2.9 as supplied. (--enable-debug --disable-shared --enable-monolithic)

There's one cosmetic bug with 2.9.0 I still need to fix where the status number display is bunched up for some reason. -- fixed

The download link on the homepage is to the sourceforge tar.gz archive which contains the 32-bit binary and the 0.2.0 sources, which were not yet buildable on 64-bit at the time.

The SVN was first buildable on 64-bit with wx2.9.0 on 28 January 2010.

Hopefully they'll have a wxWidgets 2.9.0 debian package someday.

Re: What's with this odd generation?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: What's with this odd generation?

Date2010-02-14 06:28:03 UTC

ForumBitcointalk · 原文

引用自：theymos，2010 年 2 月 12 日 08:31:52 AM（https://bitcointalk.org/index.php?topic=48.msg318#msg318）

发送方客户端会多付一点比特币来 covering 手续费吗（这样接收方就能拿到预期金额）？

会。

引用自：SmokeTooMuch，2010 年 2 月 12 日 01:11:09 PM（https://bitcointalk.org/index.php?topic=48.msg319#msg319）

我们为什么还需要手续费？我还以为免手续费是比特币的优势之一呢？！

几乎所有交易都是免费的。只有当一笔交易需要凑齐超过 500 笔你收到过的最大付款才能凑够金额时，才算超过了大小上限。超大的交易只要加一点点手续费照样能发。

普通交易、乃至比平均大 500 倍的交易，都是免费的。

只有发那种特别巨大的交易时才会碰到手续费，而且也就金额的 0.002% 左右。这钱不是被系统抽走了，只是给了其他节点。你要心疼这手续费，大可以反过来自己跑个节点，说不定哪天也能收一笔 0.44 的手续费。

英文原文

Quote from: theymos on February 12, 2010, 08:31:52 AM（https://bitcointalk.org/index.php?topic=48.msg318#msg318）Does the sending client send more BitCoins to account for the fee (so the recipient gets what he's expecting)?
Yes.

Quote from: SmokeTooMuch on February 12, 2010, 01:11:09 PM（https://bitcointalk.org/index.php?topic=48.msg319#msg319）why do we even need fees ? i thougt the no-fees-feature was one of the advantages of bitcoin ?!
Almost all transactions are free. A transaction is over the maximum size limit if it has to add up more than 500 of the largest payments you've received to make up the amount. A transaction over the size limit can still be sent if a small fee is added.

The average transaction, and anything up to 500 times bigger than average, is free.

It's only when you're sending a really huge transaction that the transaction fee ever comes into play, and even then it only works out to something like 0.002% of the amount. It's not money sucked out of the system, it just goes to other nodes. If you're sad about paying the fee, you could always turn the tables and run a node yourself and maybe someday rake in a 0.44 fee yourself.

Re: What's with this odd generation?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: What's with this odd generation?

Date2010-02-14 15:52:23 UTC

ForumBitcointalk · 原文

对。不然就没法有 2100 万枚币的有限上限了，因为生成总得有点最低奖励。几十年后奖励小到不行时，交易手续费会成为节点的主要报酬。我确信 20 年后要么交易量非常大，要么没有交易量。

英文原文

Right. Otherwise we couldn't have a finite limit of 21 million coins, because there would always need to be some minimum reward for generating. In a few decades when the reward gets too small, the transaction fee will become the main compensation for nodes. I'm sure that in 20 years there will either be very large transaction volume or no volume.

Re: Proof-of-work difficulty increasing

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Proof-of-work difficulty increasing

Date2010-02-15 06:28:38 UTC

ForumBitcointalk · 原文

14/02/2010 0000000065465700000000000000000000000000000000000000000000000000

2009 1.00
30/12/2009 1.18 +18%
11/01/2010 1.31 +11%
25/01/2010 1.34 +2%
04/02/2010 1.82 +36%
14/02/2010 2.53 +39%

昨天难度又大跳了一次，从 1.82 倍跳到 2.53 倍，10 天涨了 39%。是 10 天不是 14 天，因为更多节点加入，2016 个区块用更短时间就生成完了。

英文原文

14/02/2010 0000000065465700000000000000000000000000000000000000000000000000

2009 1.00
30/12/2009 1.18 +18%
11/01/2010 1.31 +11%
25/01/2010 1.34 +2%
04/02/2010 1.82 +36%
14/02/2010 2.53 +39%

Another big jump in difficulty yesterday from 1.82 times to 2.53 times, a 39% increase since 10 days ago. It was 10 days apart not 14 because more nodes joined and generated the 2016 blocks in less time.

Re: Setting up multiple bitcoin machines behind NAT

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Setting up multiple bitcoin machines behind NAT

Date2010-02-16 01:34:56 UTC

ForumBitcointalk · 原文

目前还没有端口号设置能做这个。这功能还没实现。你的 NAT 只能端口转发到其中一台电脑。（我之前说过 NAT 端口转换，但那行不通，其他节点不知道连那个端口。）

如果你想，顺手做个小优化，其余电脑可以这样跑：
bitcoin -connect=<第一台电脑的 IP>

这样它们的所有网络通信都走第一台电脑，不用每台都单独连外网拿同样的信息。省带宽，不过本来带宽用得也不多，除非你有成吨的电脑，否则无所谓。

为了第一台电脑挂掉时有冗余，可以让两台往外连，其余的连这两台。前两台正常跑，其余的这样跑：
bitcoin -connect=<IP1> -connect=<IP2>

英文原文

Right now there isn't a port number setting to do that. It's a feature yet to be implemented. You can only set up your NAT to port-forward to one of the computers. (I said something earlier about NAT port translation, but that wouldn't work, other nodes wouldn't know to connect to that port)

If you want, as a small optimization, you could run the rest of your computers as:
bitcoin -connect=<the IP of the first computer>

so they get all their network communication from the first computer and don't all connect over the net individually for the same information. This saves bandwidth, although it doesn't use much bandwidth to begin with, so it wouldn't really matter unless you had tons of computers.

For redundancy in case the first computer goes down, you could have two that connect out and the rest connect to both of them. The first two are run normally, the rest are run like:
bitcoin -connect=<IP1> -connect=<IP2>

Re: Proof-of-work difficulty increasing

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Proof-of-work difficulty increasing

Date2010-02-16 17:36:40 UTC

ForumBitcointalk · 原文

引用自：Suggester，2010 年 2 月 16 日 02:15:49 AM（https://bitcointalk.org/index.php?topic=43.msg361#msg361）

Satoshi，我算了下，我这台还算新的酷睿 2 双核要不停跑 20 小时才能生成 ฿50.00！旧电脑更是遥遥无期。大家都想尽快"拥有"点什么，能不能把生成切得更碎一点？比如说，别 20 小时出 ฿50，改成 2 小时出 ฿5？

我想过，但没有切实可行的办法切更碎。出块频率是在"尽快确认交易"和"网络延迟"之间权衡的。

算法目标是平均每小时 6 个块。如果改成 5 币、每小时 60 个块，块的数量多 10 倍，初始区块下载也要慢 10 倍。而且根本行不通，因为平均 1 分钟一个块，网络一大就跟广播延迟差不多了。

英文原文

Quote from: Suggester on February 16, 2010, 02:15:49 AM（https://bitcointalk.org/index.php?topic=43.msg361#msg361）Satoshi, I figured it will take my modern core 2 duo about 20 hours of nonstop work to create ฿50.00! With older PCs it will take forever. People like to feel that they "own" something as soon as possible, is there a way to make the generation more divisible? So say, instead of making ฿50 every 20 hours, make ฿5 every 2 hours?
I thought about that but there wasn't a practical way to do smaller increments. The frequency of block generation is balanced between confirming transactions as fast as possible and the latency of the network.

The algorithm aims for an average of 6 blocks per hour. If it was 5 bc and 60 per hour, there would be 10 times as many blocks and the initial block download would take 10 times as long. It wouldn't work anyway because that would be only 1 minute average between blocks, too close to the broadcast latency when the network gets larger.

Re: Proof-of-work difficulty increasing

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Proof-of-work difficulty increasing

Date2010-02-17 17:58:03 UTC

ForumBitcointalk · 原文

引用自：Sabunir，2010 年 2 月 16 日 08:51:51 AM（https://bitcointalk.org/index.php?topic=43.msg372#msg372）

可能跟我的连接延迟特别高有关（平均 2000ms 以上）

双向 2 秒延迟，挖矿成功率损失不到 1%。

引用自：Sabunir，2010 年 2 月 16 日 08:51:51 AM（https://bitcointalk.org/index.php?topic=43.msg372#msg372）

和/或丢包率高（有时丢包 10%）？

应该没问题，但我不确定。协议设计成能 resync 到下一条消息，收不到的消息会向所有连着的节点反复索取。漏了块的话，每进来一个新块、发现有缺口，它也会继续要。正式发布前我做过测试，重负载下随机丢 1/4 的消息，能整夜跑下来没有节点卡死。

英文原文

Quote from: Sabunir on February 16, 2010, 08:51:51 AM（https://bitcointalk.org/index.php?topic=43.msg372#msg372）. Perhaps it has to do with my connection's very high latency (2000ms or more on average)
2 seconds of latency in both directions should reduce your generation success by less than 1%.

Quote from: Sabunir on February 16, 2010, 08:51:51 AM（https://bitcointalk.org/index.php?topic=43.msg372#msg372）and/or my high packet loss (sometimes up to 10% loss)?
Probably OK, but I'm not sure. The protocol is designed to resync to the next message, and messages get re-requested from all the other nodes you're connected to until received. If you miss a block, it'll also keep requesting it every time another blocks comes in and it sees there's a gap. Before the original release I did a test dropping 1 out of 4 random messages under heavy load until I could run it overnight without any nodes getting stuck.

Re: Bitcoin client and website translation

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Bitcoin client and website translation

Date2010-02-17 19:19:43 UTC

ForumBitcointalk · 原文

我更新了 SVN，加了支持翻译的改动。可翻译的字符串都包在 _("") 里，所有平台都用 UTF-8。

程序运行时，会在 EXE 所在目录找这个文件：locale\<langcode>\LC_MESSAGES\bitcoin.mo

<langcode> 是你的系统语言的两位代码，比如"de"或"nl"。

Linux 上还会找：
/usr/share/locale/<langcode>/LC_MESSAGES/bitcoin.mo
/usr/local/share/locale/<langcode>/LC_MESSAGES/bitcoin.mo
（linux 上还有别的标准位置该找吗？）

用 poedit 做 .po 和 .mo 文件的快速步骤：

- 从 SVN 下载比特币源码
- 在 trunk 目录建 locale\<lang>\LC_MESSAGES
- poedit 里，文件->新建目录->路径页
- 点"新建条目"的虚线矩形按钮
- 填"../../.."，一定要按回车确认添加路径
- 点确定
- 把文件存为 LC_MESSAGES 目录下的"bitcoin.po"
- 它会扫描源码，找到约 170 个字符串
- 如果什么都没找到，检查目录->设置->路径页，确认"../../.."加上了

翻译完后，把 bitcoin.po（可编辑的目录文件）和 bitcoin.mo（程序用的编译数据）都提交。

英文原文

I updated the SVN with changes to support translation. Translatable strings are all enclosed in _(""), and we're using UTF-8 on all platforms.

When the program runs, it looks in the directory of the EXE for the file: locale\<langcode>\LC_MESSAGES\bitcoin.mo

<langcode> is the two letter code of the language your OS is set to, like "de" or "nl".

On Linux, it also looks for:
/usr/share/locale/<langcode>/LC_MESSAGES/bitcoin.mo
/usr/local/share/locale/<langcode>/LC_MESSAGES/bitcoin.mo
(are there other standard places it should look on linux?)

Here's a quick walkthrough using poedit to make a .po and .mo file:

- Download the bitcoin sourcecode from SVN
- In the trunk directory, mkdir locale\<lang>\LC_MESSAGES
- In poedit, File->New catalog->Paths tab
- Click the "New item" dotted rectangle button
- Put "../../.." and MAKE SURE TO PRESS ENTER to add the path
- Click OK
- Save the file as "bitcoin.po" in the LC_MESSAGES directory you made
- It should then scan the sourcecode and find about 170 strings
- If it didn't find anything, check Catalog->Settings->Path tab, make sure the "../../.." was added

When you're done translating, commit both bitcoin.po (the editable catalog file) and bitcoin.mo (compiled data used by the program).

Re: Number of connections

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Number of connections

Date2010-02-21 03:43:48 UTC

ForumBitcointalk · 原文

节点到 15 个连接就不再主动发起新连接了。如果你能接受入站连接，别人连你，能远超这个数；否则最多 15 个。

我不知道 15 个连接有没有必要。也许该是 10 个。

现在只能往外连的节点多半时间都在 15 个左右，你应该能趋向一个平衡。45 说明只能出不能进的节点和能接受入站的节点比例是 3:1。

连接数以后不能再当网络规模的衡量了。应该有人定期 IRC 上 bitcoin 频道 chat.freenode.net 数数用户数。那是网络节点的总数（TOR 节点除外）。

出块又跑到进度前面了。下次调整还有约 5 天，难度又要大跳一步。

英文原文

Nodes stop trying to initiate connections once they have 15. If you can accept incoming connections, then you can get well above that from nodes connecting to you, otherwise you max out at 15.

I don't know if there's any reason to have 15 connections. Maybe it should be 10.

Since nodes that can only connect out are probably at or near 15 most of the time now, you should level off to an equilibrium. 45 suggests a ratio of 3 out-only nodes to every 1 in-accepting node.

The number of connections won't be a good gauge of the size of the network any more. Someone should periodically IRC to the bitcoin channel on chat.freenode.net and count the number of users. That gives you the total count of network nodes (except TOR nodes).

Block generation is again running ahead of pace. We're in for another big step up in difficulty at the next adjustment in about 5 days.

Post your static IP

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitlePost your static IP

Date2010-02-21 04:19:53 UTC

ForumBitcointalk · 原文

要是能有个固定 IP 列表就好了，新用户可以往上面发测试捐赠，看看软件怎么工作。如果你能接受入站连接又有固定 IP 地址，发到这里！

发到这些 IP 的都算捐赠。

如果你要往返测试，一定要在留言里写上你的回款比特币地址或 IP，但请默认它是单向的。他们不一定会盯着入站交易给你回。

英文原文

It would be nice to have a list of static IPs for new users to send test donations to so they can see how the software works. If you can accept incoming connections and you have a static IP address, post it here!

Anything sent to these IPs should be considered a donation.

If you do request a round-trip, be sure to include your return bitcoin address or IP in the comment, but please assume it'll be one-way. They won't necessarily be watching for incoming transactions to send back.

Re: Current Bitcoin economic model is unsustainable

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Current Bitcoin economic model is unsustainable

Date2010-02-21 05:44:24 UTC

ForumBitcointalk · 原文

分析得漂亮，xc。

一个预期会升值的东西，理性的市场价格已经反映了预期未来涨幅的现值。你在心里做个概率估算，权衡它继续涨的可能性。

没有市场来定价时，NewLibertyStandard 按生产成本的估算是个不错的猜测，也是个有用的服务（谢了）。任何商品的价格都倾向于向生产成本靠拢。价格低于成本，生产就放缓；价格高于成本，生成再卖就能赚钱。同时，产量增加会推高难度，把生成成本推向价格。

往后几年，新币生成只占现有供应的一小部分时，市场价格决定生产成本的程度会超过反过来。

眼下生成投入在快速增加，说明大家估计的现值高于当前的生产成本。

英文原文

Excellent analysis, xc.

A rational market price for something that is expected to increase in value will already reflect the present value of the expected future increases. In your head, you do a probability estimate balancing the odds that it keeps increasing.

In the absence of a market to establish the price, NewLibertyStandard's estimate based on production cost is a good guess and a helpful service (thanks). The price of any commodity tends to gravitate toward the production cost. If the price is below cost, then production slows down. If the price is above cost, profit can be made by generating and selling more. At the same time, the increased production would increase the difficulty, pushing the cost of generating towards the price.

In later years, when new coin generation is a small percentage of the existing supply, market price will dictate the cost of production more than the other way around.

At the moment, generation effort is rapidly increasing, suggesting people are estimating the present value to be higher than the current cost of production.

UI improvements

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleUI improvements

Date2010-02-21 21:48:01 UTC

ForumBitcointalk · 原文

传了些 UI 改动到 SVN，算 0.2.5 版。

原来的"查看->显示已生成"改成了页签：
- 所有交易（All Transactions）
- 发出/收到（Sent/Received）
- 发出（Sent）
- 收到（Received）

切到收到页查付款方便多了。

把"你的地址"本并进了主地址本。两个地址本放着让人糊涂。

"发件人：未知，收件人：（你的一个比特币地址）"里的"收件人："还是别扭，我改成了"发件人：未知，收到于："。比特币地址是缩写的，能看到你在地址本接收页设的标签。

修了几个升级到 wxWidgets 2.9.0 带来的 UI 小毛病。

想要无界面版的朋友我没忘，但我得先玩点有意思的，再回去折腾构建。

英文原文

Uploaded some UI changes to SVN as version 0.2.5.

Instead of View->Show Generated, we now have tabs:
- All Transactions
- Sent/Received
- Sent
- Received

Makes it a lot easier to flip to received and check for payments.

Moved the "Your Addresses" book inside the main address book. It was confusing having two address books.

I found the "To:" in "From: unknown, To: (one of your bitcoin addresses)" still confusing, so I changed it to "From: unknown, Received with:". The bitcoin address is abbreviated so you can see the label that you set in the Receiving tab of the address book.

Fixed a few UI glitches from the upgrade to wxWidgets 2.9.0.

I haven't forgotten about you people who want non-UI, but I had to do some fun stuff before more build bashing.

Re: generation slowed down dramatically

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: generation slowed down dramatically

Date2010-02-23 00:49:56 UTC

ForumBitcointalk · 原文

就是一串倒霉的随机运气。我看挺稳的。

竞争要到下一次自动重定向调整才起作用，还没到呢。

调整是每 2016 个区块。要算离下一次还有多远，把区块总数除以 2016，小数部分就是进度。

我粗算一下：42032 个区块/2016 = 20.85 = 走了 85%。离下一次还有约 1.5 天。离上次才约 10 天，目标是 14 天，所以 14/10 = 1.4 = 难度涨约 40%。

英文原文

Just a random streak of bad luck. It looks steady to me.

Competition doesn't have an effect until the next automatic retarget adjustment, and we haven't reached the next one yet.

The adjustments are every 2016 blocks. To calculate our progress towards the next one, divide the block total by 2016. The fractional part is how far we are to the next one.

My back-of-the-envelope projection: 42032 blocks/2016 = 20.85 = 85% of the way. About 1.5 days to go until the next one. That'll only be about 10 days since the last one, the target is 14 days, so 14/10 = 1.4 = around 40% difficulty increase.

Re: UI improvements

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: UI improvements

Date2010-02-23 01:16:28 UTC

ForumBitcointalk · 原文

地址本里现在有"发送"和"接收"页签了。你的地址叫"接收地址"。

madhatter 在 Mac 上构建，报错大概是 UTF-16 的 wxWidgets 2.8 闹的。换 2.9.0 应该运气好点。wxWidgets 2.9.0 是 UTF-8，不会有这问题。

我觉得他在 FreeBSD 上跑起来了，但他想要无界面版。

命令行和 JSON-RPC 守护进程版我已经跑起来了。一两天内传 SVN。

我把 Ubuntu 上的 gdm 关了，开机进命令行。希望还能用 rcconf 把它开回来。

英文原文

There are now "Sending" and "Receiving" tabs in the Address Book. Your addresses are referred to as "receiving addresses".

madhatter was working on building it on Mac. He had errors probably caused by UTF-16 wxWidgets 2.8. Should have better luck now with 2.9.0. wxWidgets 2.9.0 is UTF-8 and wouldn't have that problem.

I think he had it working on FreeBSD, but he wanted a non-UI version.

I have the command line and JSON-RPC daemon version working now. Will SVN it in a day or two.

I disabled gdm on my Ubuntu system so it boots into command line. I hope I will be able to get it enabled again with rcconf.

Re: Bitcoin Address Collisions

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Bitcoin Address Collisions

Date2010-02-23 16:26:09 UTC

ForumBitcointalk · 原文

每个比特币地址都有一对独立的公钥/私钥。不是一把私钥开所有东西。比特币地址是公钥的 160 位哈希，系统里其他东西都是 256 位。

如果真撞了，撞中的人能花发到那个地址的钱。只限发到那个地址的钱，不是整个钱包。

如果你故意去撞，现在生成一个撞中的比特币地址要比生成一个区块多花 2^126 倍的时间。你还不如去生成区块，赚得多。

随机种子做得很扎实。Windows 上用性能监视器的全部数据，自你开机以来度量的每一比特磁盘性能、网卡指标、CPU 时间、分页等等。Linux 有内置的熵收集器。另外，你在比特币窗口里每动一下鼠标都在产生熵，磁盘操作的时间也被采集为熵。

英文原文

There's a separate public/private keypair for every bitcoin address. You don't have a single private key that unlocks everything. Bitcoin addresses are a 160-bit hash of the public key, everything else in the system is 256-bit.

If there was a collision, the collider could spend any money sent to that address. Just money sent to that address, not the whole wallet.

If you were to intentionally try to make a collision, it would currently take 2^126 times longer to generate a colliding bitcoin address than to generate a block. You could have got a lot more money by generating blocks.

The random seed is very thorough. On Windows, it uses all the performance monitor data that measures every bit of disk performance, network card metrics, cpu time, paging etc. since your computer started. Linux has a built-in entropy collector. Adding to that, every time you move your mouse inside the Bitcoin window you're generating entropy, and entropy is captured from the timing of disk ops.

Re: UI improvements

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: UI improvements

Date2010-02-23 16:53:27 UTC

ForumBitcointalk · 原文

引用 Xunie（February 23, 2010, 12:28:27 PM）（https://bitcointalk.org/index.php?topic=60.msg439#msg439）：

/etc/init.d/gdm start and it will start gdm!

啊对，这样就恢复正常了。

这台电脑上 ctrl+alt+F[1-8] 从来就没好使过，屏幕直接乱套。

英文原文

Quote from: Xunie on February 23, 2010, 12:28:27 PM（https://bitcointalk.org/index.php?topic=60.msg439#msg439）:
> /etc/init.d/gdm start and it will start gdm!
>
Ah yes, there we go, back to normal again.

The ctrl+alt+F[1-8] thing never worked on this computer. The screen just goes haywire.

Command Line and JSON-RPC

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleCommand Line and JSON-RPC

Date2010-02-23 22:15:41 UTC

ForumBitcointalk · 原文

SVN 上的 0.2.6 版本现在可以作为守护进程运行，并通过命令行或 JSON-RPC 来控制。

在 Linux 上需要安装 libgtk2.0-0，但不需要运行 GUI。希望 gtk 可以在不安装窗口系统的情况下装上。

以守护进程方式启动的命令是：
bitcoin -daemon [switches...]

或者，在正常运行 UI 的同时也想通过命令行或 JSON-RPC 控制它，请使用 "-server" 开关。
bitcoin -server [switches...]

使用任一开关，它都会运行一个 HTTP JSON-RPC 服务器，接受 127.0.0.1:8332 上的本地套接字连接。端口绑定在 loopback 上，只能从本机访问，但可以是本机的任意账户，不限于运行它的那个用户。

要从命令行控制它，接口是：一个不带任何开关的命令名，后面跟参数（如果有）。
bitcoin <command> [params...]

例如：
bitcoin getinfo
bitcoin getdifficulty
bitcoin setgenerate true
bitcoin stop

它是一个简单的 JSON-RPC 客户端，会打印出 JSON 结果。命令列表请看 rpc.cpp。

Web 应用或任何自动化程序通常会直接使用 JSON-RPC，而不是命令行。各主流语言都有 JSON-RPC 库。在 PHP、Python 这样的脚本语言里，语法跟调用本地函数一样自然。

英文原文

Version 0.2.6 on SVN can now run as a daemon and be controlled by command line or JSON-RPC.

On Linux it needs libgtk2.0-0 installed, but does not need a GUI running. Hopefully gtk can be installed without having a windowing system installed.

The command to start as a daemon is:
bitcoin -daemon [switches...]

Or, to run the UI normally and also be able to control it from command line or JSON-RPC, use the "-server" switch.
bitcoin -server [switches...]

With either switch, it runs an HTTP JSON-RPC server that accepts local socket connections on 127.0.0.1:8332. The port is bound to loopback and can only be accessed from the local machine, but from any account, not just the user it's running under.

To control it from the command line, the interface is a command name without any switches, followed by parameters if any.
bitcoin <command> [params...]

For example:
bitcoin getinfo
bitcoin getdifficulty
bitcoin setgenerate true
bitcoin stop

It's a simple JSON-RPC client and prints the JSON result. Look at rpc.cpp for the list of commands.

Web apps or anything automated will normally use JSON-RPC directly, not command line. There are JSON-RPC libraries for all the major languages. In script languages like PHP and Python the syntax is as natural as calling a local function.

Re: Bitcoin Address Collisions

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Bitcoin Address Collisions

Date2010-02-23 22:24:00 UTC

ForumBitcointalk · 原文

引用 NewLibertyStandard（February 23, 2010, 07:04:47 PM）（https://bitcointalk.org/index.php?topic=62.msg450#msg450）：

生成的比特币是用主 Bitcoin 窗口中当前显示的那个地址加密的吗？

不是，每笔生成的交易都使用一个新的、一次性的地址。

主窗口里的地址什么都不用，只是放在那里方便你复制。0.2.5 在它旁边加了一个 "New..." 按钮，方便你每次使用时更换。

英文原文

Quote from: NewLibertyStandard on February 23, 2010, 07:04:47 PM（https://bitcointalk.org/index.php?topic=62.msg450#msg450）:
> Are generated bitcoins encrypted with whichever address is currently displayed in the main Bitcoin window?
>
No, each generated transaction uses a new, single-use address.

Nothing uses the address in the main window, it's just there for convenience for you to copy. 0.2.5 has a "New..." button next to it to make it easy to change each time you use it.

Re: URI-scheme for bitcoin

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: URI-scheme for bitcoin

Date2010-02-24 05:57:43 UTC

ForumBitcointalk · 原文

在销售终端用这个会很好。收银机在屏幕上显示一个编码了比特币地址和金额的二维码，你用手机拍下来就行。

英文原文

That would be nice at point-of-sale. The cash register displays a QR-code encoding a bitcoin address and amount on a screen and you photo it with your mobile.

Re: Command Line and JSON-RPC

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Command Line and JSON-RPC

Date2010-02-24 06:17:23 UTC

ForumBitcointalk · 原文

引用 theymos（February 24, 2010, 03:07:37 AM）（https://bitcointalk.org/index.php?topic=63.msg467#msg467）：
> 引用 satoshi（February 23, 2010, 10:15:41 PM）（https://bitcointalk.org/index.php?topic=63.msg452#msg452）：
> > 在 Linux 上需要安装 libgtk2.0-0
> >
> 这个依赖以后会去掉吗？我实在不想跟 GTK 打交道。
>
GTK 到底需要多少"打交道"？是不是只要 "sudo apt-get install libgtk2.0-0"，让一些额外的库待在那里就行？GTK 什么都不用做，只要在 bitcoin 加载时能链接到它就行，没有 GUI 时 gtk-init-check 调用失败，然后就完事了。

这样可以省得我们用一堆 ifdef 把代码切得七零八落，还要单独编译、单独出二进制，就为了用 wxBase 来避免链接 GTK。

英文原文

Quote from: theymos on February 24, 2010, 03:07:37 AM（https://bitcointalk.org/index.php?topic=63.msg467#msg467）:
> Quote from: satoshi on February 23, 2010, 10:15:41 PM（https://bitcointalk.org/index.php?topic=63.msg452#msg452）:
> > On Linux it needs libgtk2.0-0 installed
> >
> Will this requirement be removed sometime? I'd rather not have to deal with GTK.
>
How much "dealing with" does GTK actually require? Is it just a matter of "sudo apt-get install libgtk2.0-0" and having some extra libraries sitting around? GTK doesn't have to do anything, just be there for bitcoin to link to when it loads up, have the gtk-init-check call fail because no GUI present, then it's done.

It saves us butchering everything with ifdefs and a separate compile and binary to use wxBase just to try to avoid linking GTK.

New icon/logo

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleNew icon/logo

Date2010-02-24 21:24:23 UTC

ForumBitcointalk · 原文

新图标，大家觉得怎么样？比旧的好吗？

全尺寸 530x529 图片，可用于缩放到自定义尺寸：
http://www.bitcoin.org/download/bitcoin530.png

大尺寸上的透视阴影太粗了。我更新了 32、48 和全尺寸版本。

我把这些图片发布到公有领域（public domain，无版权）。我要求衍生作品也做成公有领域。

英文原文

New icons, what do you think? Better than the old one?

Full size 530x529 image for scaling down to custom sizes:
http://www.bitcoin.org/download/bitcoin530.png

The perspective shadow was too thick on the larger sizes. I updated 32, 48 and the full size.

I release these images into the public domain (copyright-free). I request that derivative works be made public domain.

Re: Make your "we accept Bitcoin" logo

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Make your "we accept Bitcoin" logo

Date2010-02-24 21:53:52 UTC

ForumBitcointalk · 原文

如果你用 GPL 协议发布东西，我就得避开用它。不是对 GPL 本身有什么意见，而是 Bitcoin 是 MIT 协议的项目。任何 GPL 的东西请明确标出来。

英文原文

If you GPL stuff, I have to avoid using it. Nothing against GPL per-se, but Bitcoin is an MIT license project. Anything GPL please clearly mark it as such.

Re: Command Line and JSON-RPC

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Command Line and JSON-RPC

Date2010-02-24 22:08:55 UTC

ForumBitcointalk · 原文

内存是什么时候、以多快的速度涨上去的？是一启动就涨，还是在很长时间里慢慢涨，还是在某个稍后的事件之后开始涨？

我的 -daemon 跑在 ubuntu 9.10 64 位上，内存占用很稳定。

肯定是服务器上除了 64 位之外的某些差异导致的。也可能是缺少 GUI 引发的某种故障。内存泄漏调试工具也许能给出线索。

英文原文

When and how fast did memory usage increase? Right away, slowly over a long time, or starting at some later event?

I have -daemon running on ubuntu 9.10 64-bit and memory usage is steady.

It has to be something about the difference on the server besides 64-bit. Maybe some malfunction from the lack of GUI. A memory leak debug tool could give a clue.

Re: Proof-of-work difficulty increasing

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Proof-of-work difficulty increasing

Date2010-02-24 22:42:24 UTC

ForumBitcointalk · 原文

自动调整在今天早些时候发生了。

24/02/2010 0000000043b3e500000000000000000000000000000000000000000000000000

24/02/2010 3.78 +49%

我更新了首帖。

英文原文

The automatic adjustment happened earlier today.

24/02/2010 0000000043b3e500000000000000000000000000000000000000000000000000

24/02/2010 3.78 +49%

I updated the first post.

Re: New icon/logo

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: New icon/logo

Date2010-02-25 01:56:24 UTC

ForumBitcointalk · 原文

引用 Sabunir（February 25, 2010, 01:47:56 AM）（https://bitcointalk.org/index.php?topic=64.msg519#msg519）：

我很喜欢。有更高分辨率的版本吗？

有，原图是 546x531 像素。

大尺寸看起来也不错，但平时看到最多的还是小图标，所以我想先按小图标的效果来评判。稍后我会发布更大的尺寸和全尺寸版本。

英文原文

Quote from: Sabunir on February 25, 2010, 01:47:56 AM（https://bitcointalk.org/index.php?topic=64.msg519#msg519）:
> I like them. Do they come in higher resolutions?
>
Yes, the original is 546x531 pixels.

It looks good at larger size too, but since the small icons are what you mostly always see, I wanted to judge it on those first. I'll post larger sizes and full size a little later.

Re: Command Line and JSON-RPC

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Command Line and JSON-RPC

Date2010-02-25 22:54:17 UTC

ForumBitcointalk · 原文

好的，我加了一个构建目标 bitcoind，它只链接 wxBase，不链接 GTK。SVN 上的 0.2.7 版本。

我把初始化和关闭相关的代码从 ui.cpp 里拆出来放进了 init.cpp，这样 ui.cpp 现在就是纯 UI 了。ui.h 在 wxUSE_GUI=0 时提供内联桩函数。我们只有四个从节点调到 UI 的接口函数。在 bitcoind 构建里，我们不链接 ui.o 和 uibase.o。

引用 sirius-m（February 25, 2010, 04:32:17 PM）（https://bitcointalk.org/index.php?topic=63.msg538#msg538）：

它一启动就开始涨。我看看 valgrind 能不能帮上忙。

感觉很像是 wxWidgets 在某个 UI 相关的东西失败、或某个东西没正确初始化之后不停重试导致的。我们那个忽略初始化失败、硬跑起来的 hack 让我们进入了未知领域。我们能依赖的只是这种模式下几乎用不到 wx。不过还是用到了一些，比如 wxGetTranslation 和 wxMutex。

另一种调试办法是：用 gdb 跑起来，等一切安静下来、所有线程都应该空闲的时候，打断它，看哪个线程在忙、忙什么。

我估计 bitcoind 应该能正常工作，不过还是希望你能把这个问题调出来。

英文原文

OK, I made a build target bitcoind that only links wxBase and does not link GTK. Version 0.2.7 on SVN.

I split out the init and shutdown stuff from ui.cpp into init.cpp, so now ui.cpp is pure UI. ui.h provides inline stubs if wxUSE_GUI=0. We only have four functions that interface from the node to the UI. In the bitcoind build, we don't link ui.o or uibase.o.

Quote from: sirius-m on February 25, 2010, 04:32:17 PM（https://bitcointalk.org/index.php?topic=63.msg538#msg538）:
> It started increasing right away. I'll see if valgrind can help me.
>
Sure feels like it could be something in wxWidgets retrying endlessly because some UI thing failed or something wasn't inited correctly. Our hack to ignore the initialize failure and run anyway means we're in uncharted territory. We're relying on the fact that we hardly use wx in this mode. We do still use a few things like wxGetTranslation and wxMutex.

Another way to debug would be to run in gdb, wait until everything is quiet and all threads should be idle, and break it and see which thread is busily doing something and what it's doing.

I suspect bitcoind will probably work fine, but I hope you can still debug the problem.

Re: Proof-of-work difficulty increasing

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Proof-of-work difficulty increasing

Date2010-02-25 23:06:29 UTC

ForumBitcointalk · 原文

公式基于生成 2016 个区块所花的时间。难度乘以 14/（实际花费天数）。比如这次用了 9.4 天，所以计算是 14/9.4 = 1.49。之前的难度 2.53 * 1.49 = 3.78，涨了 49%。

我不知道你在说的接受更低难度是怎么回事。

英文原文

The formula is based on the time it takes to generate 2016 blocks. The difficulty is multiplied by 14/(actual days taken). For instance, this time it took 9.4 days, so the calculation was 14/9.4 = 1.49. Previous difficulty 2.53 * 1.49 = 3.78, a 49% increase.

I don't know what you're talking about accepting easier difficulties.

Re: Command Line and JSON-RPC

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Command Line and JSON-RPC

Date2010-02-26 16:29:21 UTC

ForumBitcointalk · 原文

wx/clipbrd.h 没用到，把它挪到 #if wxUSE_GUI 里面去。

SVN 上的 headers.h 已更新。

抱歉，我链接的是 wxbase，但我电脑上装的是完整版 wxWidgets。

db.h:140 class Db 没有名为 "exisits" 的成员，这个更奇怪。pdb->get、pdb->put、pdb->del 在那之前都编译通过了。你的 Berkeley DB 是不是 4.7.25 版本？

Db::exists()
http://www.oracle.com/technology/documentation/berkeley-db/db/api_reference/CXX/frame_main.html
http://www.oracle.com/technology/documentation/berkeley-db/db/api_reference/CXX/dbexists.html

我猜他们可能是最近才加的 exists，之前用的是 get。

英文原文

wx/clipbrd.h isn't used, move it inside the #if wxUSE_GUI.

Updated headers.h on SVN.

Sorry, I linked to wxbase but I had full wxWidgets on my computer.

The db.h:140 class Db no member named "exisits" is stranger. pdb->get, pdb->put, pdb->del compiled before that. Do you have version 4.7.25 of Berkeley DB?

I suppose they might have added exists recently, using get before that.

Re: New icon/logo

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: New icon/logo

Date2010-02-26 23:17:19 UTC

ForumBitcointalk · 原文

好建议。B 稍微调亮了一点，背景稍微调暗了一点。非常轻微。前景色现在跟旧图标里 BC 的颜色完全一样。

16x16 上看不清 B 也没太大关系。在那个尺寸下，你只需要能看出来它是个硬币就行。上面压的是什么花纹没那么重要，关键是要有点细节，因为如果是光滑的空白圆盘就不像硬币了。

它比高略宽一点，因为下面的深色透视阴影往右延伸得比往下多。

我做好了 32x31 和 48x47 版本，发在首帖里了。我很喜欢 48 的那个。

大家觉得 B 符号外面那两道竖线怎么样？能接受它做我们的 logo 吗？

英文原文

Good suggestion. I made the B slightly lighter and the background slightly darker. Very slightly. The foreground is now exactly the same colour as the BC in the old one.

It's kind of OK if you can't easily read the B in the 16x16. At that size, you just need to see that it's a coin. It doesn't matter so much what's embossed on it, just that there be some detail there because it wouldn't look like a coin if it was a blank smooth circle.

It's slightly wider than tall because the dark perspective under it goes more to the right than down.

I finished and posted the 32x31 and 48x47 versions in the first message. I like the 48 a lot.

How does everyone feel about the B symbol with the two lines through the outside? Can we live with that as our logo?

Re: Command Line and JSON-RPC

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Command Line and JSON-RPC

Date2010-02-26 23:48:44 UTC

ForumBitcointalk · 原文

你用的是 wxWidgets 2.9.0 吗？我不建议用 2.9.0 之外的任何版本。

看起来 wx 头文件（arrstr.h）里引用了 wxBase 之外的东西。

把 bitcoin 的 makefile 里 -D__WXDEBUG__ 去掉应该就能解决。

如果还不行，而你只想先把它跑起来，可以编辑 wxWidgets 的 include/wx/arrstr.h 第 167 行，把 wxASSERT_MSG 那行注释掉。

英文原文

Are you using wxWidgets 2.9.0? I don't recommend using anything other than 2.9.0.

It looks like they've got a reference in the wx headers (arrstr.h) to something outside of wxBase.

Removing -D__WXDEBUG__ from bitcoin's makefile would probably solve it.

If that doesn't work and you just want to get it working, you could edit wxWidgets include/wx/arrstr.h, line 167 and comment out the wxASSERT_MSG.

Re: New icon/logo

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: New icon/logo

Date2010-02-27 04:28:29 UTC

ForumBitcointalk · 原文

引用 Cdecker（February 27, 2010, 03:24:07 AM）（https://bitcointalk.org/index.php?topic=64.msg565#msg565）：

要不要出个 SVG 版本？这样就可以按需自动生成更小或更大的版本了。

我不会做 SVG，不过原图做得非常大，超过 500 像素宽，可以往下缩。等我做完会把原图放出来。

每个图标尺寸我都得手工微调，让竖线正好落在像素上，否则又糊又不均匀，难看得很。做图标就是这么折腾。原图适合缩放到 48 到 500 之间的自定义尺寸，再小就不行了。

英文原文

Quote from: Cdecker on February 27, 2010, 03:24:07 AM（https://bitcointalk.org/index.php?topic=64.msg565#msg565）:
> How about an SVG version? That way we could automatically generate smaller and larger versions as needed.
>
I don't know how to do SVG, but I did the original very large, over 500 pixels across, so it can be scaled down. I'll give the original when I'm finished.

I had to custom tweak each icon size so the vertical lines land square on their pixels, otherwise they're ugly blurry and inconsistent. Such is the challenge of making icons. The original will be good for scaling to custom sizes between 48 and 500 but not smaller.

Re: wxWidgets 2.9.0

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: wxWidgets 2.9.0

Date2010-02-27 21:22:53 UTC

ForumBitcointalk · 原文

引用 Cdecker（February 27, 2010, 05:09:59 PM）（https://bitcointalk.org/index.php?topic=65.msg569#msg569）：

看了下 2.8.10 的源码，那个版本好像也支持 unicode。

在 Windows 世界里，"unicode" 指的是 UTF-16（wchar）。

2.8 有两种构建变体：ANSI 和 UTF-16（unicode）。UTF-16 版本就是 Debian 包里那个标着 "unicode" 的版本。我认为论坛里描述的构建问题，根源就是 2.8 和它那个只标 "unicode" 的 UTF-16 构建。我们之前用的是 2.8 ANSI，为的是将来能直接上 UTF-8，跳过 UTF-16 这个坑。我们没法用 UTF-16 编译。

2.9 只有一个版本：UTF-8。在 Windows 上我们把代码页设为 UTF-8，所以所有平台上我们的代码都是 UTF-8，wxWidgets 跟我们交互也用 UTF-8。在 Linux 上我估计代码页本来就是 UTF-8。统一用 2.9 就避开了 2.8 的多构建混乱，而且我们做 UTF-8 国际化也需要 2.9。

一定要读 build-unix.txt，按里面给的 configure 参数来配置 wxWidgets。

好奇问下，为什么提供 wxWidgets 2.9.0 会"无比困难"？如果是对用户而言，那正是我们静态链接它的原因。

很遗憾我们需要这么多庞大的依赖，但每个都是必需的。好在 Debian/Ubuntu 上除了 wxWidgets，其他都有现成的包。迟早他们会提供 2.9 的包。

英文原文

Quote from: Cdecker on February 27, 2010, 05:09:59 PM（https://bitcointalk.org/index.php?topic=65.msg569#msg569）:
> Looking through the source of 2.8.10 it appears that unicode is possible with that version too.
>
In the Windows world, "unicode" means UTF-16 (wchar).

2.8 has two build variations, ANSI and UTF-16 (unicode). The UTF-16 version is the "unicode" version provided in the Debian package. I believe 2.8 and its UTF-16 build labelled simply "unicode" has been the source of build problems described in the forum. We were previously using 2.8 ANSI in anticipation of getting to UTF-8 without going through UTF-16 hell. We cannot compile with UTF-16.

2.9 has only one version, UTF-8. On Windows, we set the codepage to UTF-8, so on all platforms our code is UTF-8 and wxWidgets interfaces with us in UTF-8. On Linux I assume the codepage is already UTF-8. By standardizing on 2.9 we avoid the multi-build confusion of 2.8, and we need 2.9 for UTF-8 internationalization.

Make sure you read build-unix.txt and configure wxWidgets using the configure parameters given.

Curious, why is it incredibly hard to provide wxWidgets 2.9.0? If you mean for users, that's why we static link it.

It's unfortunate that we require so many big dependencies, but we need them all. At least on Debian/Ubuntu, all but wxWidgets are available as packages. Eventually they'll provide a 2.9 package.

Re: New icon/logo

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: New icon/logo

Date2010-03-02 02:33:05 UTC

ForumBitcointalk · 原文

标准图标尺寸都有了，全尺寸缩放到其他尺寸效果也很好。

我把全尺寸加到首帖里了。

英文原文

We have the standard icon sizes, and the full size scales nicely to anything else.

I added the full size to the first post.

Re: Money Transfer Regulations

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Money Transfer Regulations

Date2010-03-03 04:28:56 UTC

ForumBitcointalk · 原文

等规模够大的时候，也许可以有个兑换网站，它自己不做划转，只撮合买卖双方直接兑换，有点像 e-bay 的模式。

为了更安全，兑换网站可以为比特币那一侧的支付做托管。卖家把比特币放进托管，买家把法币直接付给卖家。兑换服务本身不经手任何现实世界的钱。

这会比 e-bay 还好用一步。e-bay 即使在付款出问题、发出去的货追不回来的情况下都能运转得不错。

英文原文

When there's enough scale, maybe there can be an exchange site that doesn't do transfers, just matches up buyers and sellers to exchange with each other directly, similar to how e-bay works.

To make it safer, the exchange site could act as an escrow for the bitcoin side of the payment. The seller puts the bitcoin payment in escrow, and the buyer sends the conventional payment directly to the seller. The exchange service doesn't handle any real world money.

This would be a step better than e-bay. E-bay manages to work fine even though shipped goods can't be recovered if payment falls through.

Re: Command Line and JSON-RPC

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Command Line and JSON-RPC

Date2010-03-05 01:46:25 UTC

ForumBitcointalk · 原文

引用 sirius-m（February 24, 2010, 06:17:35 PM）（https://bitcointalk.org/index.php?topic=63.msg502#msg502）：

真奇怪……我在 64 位 Linux 服务器上以守护进程启动 Bitcoin，它会吃光剩下的 250MB 内存、700MB 交换分区，最后崩溃。在 32 位 Ubuntu 台式机上就没事，内存占用稳定在 15MB。服务器跑的是 64 位构建的 Bitcoin。可能是构建有问题之类的。

sirius-m 调出来了，是 64 位相关的问题。

修复已在 SVN 上，文件 util.cpp。

英文原文

Quote from: sirius-m on February 24, 2010, 06:17:35 PM（https://bitcointalk.org/index.php?topic=63.msg502#msg502）:
> This is strange... When I start Bitcoin as a daemon on my 64 bit Linux server, it eats up all the 250MB of remaining RAM, 700MB of swap and eventually crashes. On my 32 bit Ubuntu desktop, it works fine and stays at 15MB of memory usage. The server is running a 64 bit build of Bitcoin. Maybe there's something wrong with the build or something.
>
sirius-m debugged this, it was 64-bit related.

The fix is now available on SVN, file util.cpp.

Re: bitcoin auto-renice-ing

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: bitcoin auto-renice-ing

Date2010-03-15 18:44:12 UTC

ForumBitcointalk · 原文

它给每个线程设了不同的优先级。生成线程跑在 PRIO_MIN，其他线程几乎不占 CPU，跑在普通优先级。

#define THREAD_PRIORITY_LOWEST PRIO_MIN
#define THREAD_PRIORITY_BELOW_NORMAL 2
#define THREAD_PRIORITY_NORMAL 0

从 Windows 优先级换算过来的值大概来自这样一张表：

"下表展示了 nice 值与 Win32 优先级的映射。关于 Win32 优先级问题的更多信息，请参阅 SetThreadPriority() 的 Win32 文档。

nice 值 Win32 优先级
-20 到 -16 THREAD_PRIORITY_HIGHEST
-15 到 -6 THREAD_PRIORITY_ABOVE_NORMAL
-5 到 +4 THREAD_PRIORITY_NORMAL
+5 到 +14 THREAD_PRIORITY_BELOW_NORMAL
+15 到 +19 THREAD_PRIORITY_LOWEST"

如果你有更好的值，欢迎建议。

另外，网上有建议说 Linux 上用 PRIO_PROCESS 是因为线程就是进程。如果这话不对，那可能就是它把整个应用的优先级都意外改了的原因。

// threads are processes on linux, so PRIO_PROCESS affects just the one thread
setpriority(PRIO_PROCESS, getpid(), nPriority);

英文原文

It sets different priorities for each thread. The generate threads run at PRIO_MIN. The other threads rarely take any CPU and run at normal.

#define THREAD_PRIORITY_LOWEST PRIO_MIN
#define THREAD_PRIORITY_BELOW_NORMAL 2
#define THREAD_PRIORITY_NORMAL 0

The priorities converted from Windows priorities were probably from a table like this:

"The following table shows the mapping between nice values and Win32 priorities. Refer to the Win32 documentation for SetThreadPriority() for more information on Win32 priority issues.

nice value    Win32 Priority
-20 to -16    THREAD_PRIORITY_HIGHEST
-15 to -6    THREAD_PRIORITY_ABOVE_NORMAL
-5 to +4    THREAD_PRIORITY_NORMAL
+5 to +14    THREAD_PRIORITY_BELOW_NORMAL
+15 to +19    THREAD_PRIORITY_LOWEST"

If you have better values, suggestions welcome.

Also, there was some advice on the web that PRIO_PROCESS is used on Linux because threads are processes. If that's not true, maybe it accounts for unexpectedly setting the priority of the whole app.

// threads are processes on linux, so PRIO_PROCESS affects just the one thread
setpriority(PRIO_PROCESS, getpid(), nPriority);

Idea for file hosting and proxy services

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleIdea for file hosting and proxy services

Date2010-03-15 19:16:56 UTC

ForumBitcointalk · 原文

当你想上传一张图片嵌入论坛帖子时，有 imageshack 这样的服务，但因为是免费的，它们会限制浏览次数。带宽成本微乎其微，但它们不能白送，总得图点什么。能付点带宽费、避开这些限制就好了，可为这点小事走传统支付太麻烦。

如果你想上传文件给别人下载就更糟。有 rapidshare 这样的服务，但它们要求下载者多走几步、看广告或被怂恿升级付费订阅，还限制只能下载十来次。

要是我们能写一套免费的 PHP 代码，做收比特币的图片和文件托管服务就好了。谁有多余的带宽配额，往自己的 web 服务器上一扔就能跑。用户终于可以付那点小钱覆盖带宽成本，避开限制和麻烦。最好是 MIT 协议或公有领域。

这类服务对匿名用户会很友好，他们本来就很难为东西付钱。

英文原文

When you want to upload an image to embed in a forum post, there are services like imageshack, but because they're free, they limit the number of views. It's a minuscule amount of bandwidth cost, but they can't just give it away for free, there has to be something in it for them. It would be nice to be able to pay for the bandwidth and avoid the limits, but conventional payments are too inconvenient for such a minor thing.

It's worse if you want to upload a file for others to download. There are services like rapidshare, but they require the downloaders to go through extra steps and delays to make them look at advertising or encourage upgrading to a paid subscription, and they limit it to 10 or so downloads.

It would be nice if we made some free PHP code for an image and file hosting service that charges Bitcoins. Anyone with some extra bandwidth quota could throw it on their webserver and run it. Users could finally pay the minor fee to cover bandwidth cost and avoid the limits and hassles. Ideally, it should be MIT license or public domain.

Services like this would be great for anonymous users, who have trouble paying for things.

Re: On IRC bootstrapping

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: On IRC bootstrapping

Date2010-03-16 19:48:47 UTC

ForumBitcointalk · 原文

感谢 soultcer 跟 Freenode 的工作人员沟通。很高兴知道目前这个规模没问题，他们也知道我们是谁了。他们支持 TOR 这样的项目，希望也会对我们友好。我们不想赖着不走。如果我们长太大，那按同样的道理，我们也大到不需要 IRC 了，会自己撤出来。

我们当初需要 IRC 只是因为没人有固定 IP。早期有几位稳定的支持者，但他们的 IP 都是动态分配的，隔几天就变。IRC 本来就只是临时方案。Bitcoin 内置的 addr 系统才是主要方案。

Bitcoin 可以从任意 bitcoin 节点拿到 IP 列表。从这个意义上说，每个节点都是目录服务器。

等有足够多的固定 IP 节点，让我们有把握在当前版本被淘汰之前至少还有一个活着，我们就可以预置一个种子列表。

你觉得种子列表该怎么编？从当前已连接、且稳定在线一段时间的 IP 里挑，可以吗？

顺便说一句，如果我们想额外部署独立的目录服务器软件，我推荐 IRC？IRC 是个很好的目录服务器（听说它还有别的用处），有成熟的 IRC 服务器实现，谁都能跑。Bitcoin 的 IRC 客户端实现已经过充分测试。

英文原文

Thanks soultcer for talking with the Freenode staffer. Good to know it's OK at the current size, and now they know who we are. They're supportive of projects like TOR so I hope they would probably be friendly to us. We don't want to overstay our welcome. If we get too big, then by the same token, we're big enough that we don't need IRC anymore and we'll get off.

We only needed IRC because nobody had a static IP. In the early days there were some steady supporters, but they all had pool-allocated IPs that change every few days. IRC was only intended as a temporary solution. Bitcoin's built-in addr system is the main solution.

Bitcoin can get the list of IPs from any bitcoin node. In that sense, every node serves as a directory server.

When there are enough static IP nodes to have a good chance that at least one will still be running by the time the current version goes out of use, we can preprogram a seed list.

How do you think we should compile the seed list? Would it be OK to create it from the currently connected IPs that have been static for a while?

BTW, if we want to supplement by deploying separate directory server software, may I suggest IRC? IRC is a good directory server (I've heard it has other uses too), and there are mature IRC server implementations available that anyone can run. Bitcoin's IRC client implementation is already thoroughly tested.

Re: Idea for file hosting service

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Idea for file hosting service

Date2010-03-16 20:17:34 UTC

ForumBitcointalk · 原文

好主意。这类服务生意兴隆，但我一直觉得标准支付方式跟注重隐私的客户是拧着的。

你考虑把软件免费放出来、让谁都能轻松搭一个吗？我知道出于竞争考虑本能是想自己留着，但如果谁都能往服务器上一放就给所在国家提供代理接入，用量可能会大一个数量级。

我在想，还有没有别的 Web 应用服务器类型，我们只需要把支付机制嫁接到现成系统上就行？

英文原文

That's a great idea. There's a thriving business in those services, but I've always thought the standard payment methods are at odds with privacy minded customers.

Would you consider making your software freely available so anyone could easily set one up? I know for competitive reasons the inclination is to keep it to yourself, but it could get an order of magnitude more use if anyone could give proxy access to their country just by putting the software on a server.

I wonder if there are other kinds of web application servers where we would only have to tack on the payment mechanism to an already existing system?

Re: who is bitcoin.com

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: who is bitcoin.com

Date2010-03-23 15:22:41 UTC

ForumBitcointalk · 原文

没关系。我起步的时候那里什么都没有。

.com 注册的价格低得不合理，所以你能想到的好名字永远都已经被某个域名投机者占了。好在开源项目用 .org 是惯例。

英文原文

It's unrelated. There wasn't anything there when I started.

The price of .com registrations is lower than it should be, therefore any good name you might think of is always already taken by some domain name speculator. Fortunately, it's standard for open source projects to be .org.

Re: Exchange Methods

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Exchange Methods

Date2010-03-23 17:35:34 UTC

ForumBitcointalk · 原文

LR 和 Pecunix 有很多成熟的兑换商，可以通过各种支付方式兑换成纸币，也有不少商家接受它们付款，所以 Bitcoin 和 LR/Pecunix 之间搭一条兑换通道，就能二手接入那一整套体系。能通过它们套现，对支撑比特币的价值有帮助。

Bitcoin 有独特的互补属性。LR/Pecunix 匿名花出去很容易，但匿名买进来很难，小额买也不划算。而 Bitcoin 恰恰相反，小额匿名获取很容易。用比特币去买 LR/Pecunix，会比走传统支付方式方便。

大多数想换成 LR 去买东西的客户，大概会先问卖家收不收 Bitcoin，顺带就把他们拉进来开始接受了。

英文原文

LR and Pecunix have many established exchanges to paper currencies by various payment methods, and a number of vendors accept them as payment, so an exchange link between Bitcoin and LR/Pecunix would give us 2nd-hop access to all that. The possibility to cash out through them would help support the value of bitcoins.

Bitcoin has unique properties that would be complementary. LR/Pecunix are easy to spend anonymously, but hard to buy anonymously and not worth the trouble to buy in small amounts. Bitcoin, on the other hand, is easy to get in small amounts anonymously. It would be convenient to buy LR/Pecunix with bitcoins rather than through conventional payment methods.

Most customers who convert to LR to buy something would probably ask the seller first if they accept Bitcoin, encouraging them to start accepting it.

Re: Idea for file hosting and proxy services

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Idea for file hosting and proxy services

Date2010-03-24 18:01:57 UTC

ForumBitcointalk · 原文

标题改了。

有真正跑过代理服务经验的人在，太好了。你觉得 Psiphon 是目前最好的吗？（有时候你跑的那个只是你起步时最好的，后来发现了更好的）

英文原文

Title changed.

It helps that we have someone with actual experience running a proxy service. Do you think Psiphon is the best one currently? (sometimes the one you run was the best when you started but you found better ones later)

Re: Idea for file hosting and proxy services

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Idea for file hosting and proxy services

Date2010-03-24 18:02:55 UTC

ForumBitcointalk · 原文

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

它偏向图片托管，但我觉得把文件大小限制调大、允许的文件扩展名放宽，它同样能做通用文件上传托管。它们设限制是为了作为免费服务能撑住，但如果接上 Bitcoin 支付机制，限制就可以放宽。

它没有一堆客户端脚本和反嵌入的幺蛾子要拆。生成的都是标准链接，正常可用。

这类免费托管站有个兴衰轮回。小站能提供免费图片托管，可一旦某家火起来，就会被蹭免费带宽的人挤爆。任何出了名的站都得变得更 aggressive 地催付费来覆盖带宽成本。这是教科书级的例子：需要的价格点卡在无人区——免费嫌贵了一点点，但又便宜到大多数用户懒得走传统支付。就卡在 0 到 19.95 之间。它们能做到的最好也就是指望 1000 个用户里有 1 个付 9.95，但代价是把另外 999 个当蹭网的对待。也做不了广告支撑，因为图片是嵌在别的站里的，下载根本不经过托管站。

一个跑这套软件的站的例子：
http://www.imagez.ws/

论坛：
http://www.mihalism.net/

下载：
http://code.google.com/p/mihalismmh/

你觉得怎么样？如果我给它做个 Bitcoin 支付集成，有人愿意跑吗？这可能是第一个能用 Bitcoin 购买的全自动服务。它相对免费服务的优势是：通用文件上传托管、大文件，不用让下载用户跑到上传站去跳各种坑。直接给文件的普通链接。

英文原文

Mihalism Multi Host is a popular open source PHP file hosting server.

It's geared toward image hosting, but I think by increasing the file size limit and liberalising the allowed file extensions, it could just as easily be used for general file upload hosting. They need the limits to keep it reasonable as a free service, but if we bolt on a Bitcoin payment mechanism, the limits could be relaxed.

It doesn't have a bunch of client side scripting or anti-embedding junk to rip out. It generates standard links that work normally.

There's a turnover churn in these free hosting sites. Small sites can give free image hosting, but once one starts getting popular, it gets too swamped with moochers using them for free bandwidth. Any site that gets well known has to become more aggressively pay-naggy to cover bandwidth costs. It's a perfect example of a service where the needed price point is in the no-man's-land between just a little too expensive to be free, but too cheap for most users to take the trouble of a conventional payment. It's in the gap between 0 and 19.95. The best they can do is try to maybe get 1 out of 1000 users to pay 9.95, but that has 999/1000 users treated like freeloaders. It can't really be advertising supported because the images are embedded in other sites and downloaded without going to the hosting site.

An example of a site running the software:
http://www.imagez.ws/

Forum:
http://www.mihalism.net/

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

What do you think? If I made a Bitcoin payment integration for this, would anyone be interested in running it? It might be the first fully automated service available to buy with Bitcoins. The advantage it could offer over the free services is general file upload hosting of large files without making downloading users go to the upload site and jump through hoops. It would give a normal link directly to the file.

Re: URI-scheme for bitcoin

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: URI-scheme for bitcoin

Date2010-05-16 22:37:21 UTC

ForumBitcointalk · 原文

引用 Karmicads（May 01, 2010, 06:06:53 AM）（https://bitcointalk.org/index.php?topic=55.msg1038#msg1038）：

freenet 的 URI 长这样：

http://127.0.0.1:8888/USK@oshw3DxmJUt7q4ThF4dCez5IXbc9hCGcv0VuwLRCmeQ,ckeXv20F1gBzkqssB4RXHZ2nB1YRT8Pb8KYZk8wj-bs,AQACAAE/occamsrazor/6/f.pdf

就是，我们完全可以照着做，比如：
http://127.0.0.1:8330/?to=<bitcoinaddress>;amount=<amount>

Bitcoin 可以在本地 loopback 上监听 8330 端口，就像 JSON-RPC 监听 8332 一样。然后给出一个 HTTP 应答。

引用 DataWraith（May 02, 2010, 11:13:09 AM）（https://bitcointalk.org/index.php?topic=55.msg1045#msg1045）：

我觉得 bitcoin 链接应该更像 mailto: 而不是 magnet:。

我觉得可以做到。

虽然让 Bitcoin 在 HTTP 应答里直接把活干了、给用户呈现 HTML 界面在技术上可行，但作为用户，我会犯嘀咕：到底是某个网站在骗我，还是我真的在跟自己的 Bitcoin 服务器说话。

HTTP 应答可以只是一段 HTML，带一段相当于后退按钮的 JavaScript，把页面送回去。然后 Bitcoin 弹出 Send Bitcoins 对话框，收款比特币地址和金额都已经填好。效果就跟 mailto: 链接弹出新邮件、收件人已填好一样。

127.0.0.1 loopback 本机上的任意用户都能访问，没有按用户隔离，但没关系，因为它只承担预填对话框字段的便利功能。你还是得亲手按 Send。得确保 Send 按钮不是默认选中的，免得你在敲空格或回车时它突然跳到前台。

英文原文

Quote from: Karmicads on May 01, 2010, 06:06:53 AM（https://bitcointalk.org/index.php?topic=55.msg1038#msg1038）:
> A freenet URI is like this:
>
> http://127.0.0.1:8888/USK@oshw3DxmJUt7q4ThF4dCez5IXbc9hCGcv0VuwLRCmeQ,ckeXv20F1gBzkqssB4RXHZ2nB1YRT8Pb8KYZk8wj-bs,AQACAAE/occamsrazor/6/f.pdf
>

There you go, we could easily do it the same way, like:
http://127.0.0.1:8330/?to=<bitcoinaddress>;amount=<amount>

Bitcoin can answer port 8330 on local loopback just as it does for JSON-RPC on 8332. It would give an HTTP answer.

Quote from: DataWraith on May 02, 2010, 11:13:09 AM（https://bitcointalk.org/index.php?topic=55.msg1045#msg1045）:
> A bitcoin-link should be more like mailto: than magnet: IMHO.
>

I think we can do that.

Although it would be possible for Bitcoin to take care of business in the HTTP response by presenting HTML UI to the user, as a user I would wonder if some website is trying to trick me or if I'm really talking to my own Bitcoin server.

The HTTP response could simply be HTML with the JavaScript equivalent of the back button, sending it back to the page. Bitcoin then pops up the Send Bitcoins dialog with the destination bitcoin address and amount already filled in. It would work just like a mailto: link that pops up a new email with the address filled in.

127.0.0.1 loopback is accessible by any user on the machine, it doesn't have per-user separation, but it's OK because it would only serve the convenience function of pre-filling the fields in a dialog. You'd still have to press Send. We'd have to make sure the Send button is not selected so it couldn't jump into the foreground while you're typing a space or enter.

Re: Exception: 9key_error error

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Exception: 9key_error error

Date2010-05-16 22:53:59 UTC

ForumBitcointalk · 原文

是每次运行都这样，还是某次随机出现的一次？

我以前没见它失败过。那是对 OpenSSL 的一次调用，我以为它永远不会失败，只是以防万一加了个错误检查。我想不出它怎么会失败。可能是内存耗尽。

代码是：

key.h:
EC_KEY* pkey;

pkey = EC_KEY_new_by_curve_name(NID_secp256k1);
if (pkey == NULL)
throw key_error("CKey::CKey() : EC_KEY_new_by_curve_name failed");

NID_secp256k1 是个常量。

英文原文

Does it happen every time you run it, or just happened once at some random time?

I've never seen that fail before. It's a call to OpenSSL that I assumed would never fail, but I put an error check there just in case. I can't imagine how it would fail. Out of memory maybe.

The code is:

key.h:
EC_KEY* pkey;

pkey = EC_KEY_new_by_curve_name(NID_secp256k1);
if (pkey == NULL)
throw key_error("CKey::CKey() : EC_KEY_new_by_curve_name failed");

NID_secp256k1 is a constant.

Re: removing bitcoin addresses

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: removing bitcoin addresses

Date2010-05-16 23:34:40 UTC

ForumBitcointalk · 原文

SheriffWoody：
你生成的 Bitcoin 地址会永远保留。比特币地址必须保留，才能证明发到它名下的东西的所有权。如果你能删掉一个比特币地址，而有人往它发了钱，钱就丢了。它们也就 500 字节左右。

sirius-m：
几千个自己的地址完全不是问题。如果你已经生成了 50000 BTC，那你已经有 1000 个自己的地址了，每 50 个生成币对应一个。它们是隐藏的，UI 里看不到。

加一小段代码、让同一个 IP 一直拿到同一个地址会是个好主意。我在 C++ 里就是这么做的，让同一个 key（也就是比特币地址）一直发给同一个 IP，直到他们用了它：

// Keep giving the same key to the same ip until they use it
if (!mapReuseKey.count(pfrom->addr.ip))
mapReuseKey[pfrom->addr.ip] = GenerateNewKey();

...sends the key mapReuseKey[pfrom->addr.ip]

...later...

// Received something with this key
mapReuseKey.erase(pfrom->addr.ip);

如果不方便知道什么时候收到了，就每 20 分钟清空一次缓存的 key。

我想给 getnewaddress 加个参数：多少天没收到东西就过期。

英文原文

SheriffWoody:
Bitcoin addresses you generate are kept forever. A bitcoin address must be kept to show ownership of anything sent to it. If you were able to delete a bitcoin address and someone sent to it, the money would be lost. They're only about 500 bytes.

sirius-m:
Thousands of own addresses should not be any problem at all. If you've generated 50000 BTC, then you already have 1000 own addresses, one for each 50 generated. Those are hidden, they're not shown in the UI.

It would be a good idea to add a little code that keeps giving the same address to the same IP. Here's what I did in C++ to keep giving the same key (aka bitcoin address) until they use it:

// Keep giving the same key to the same ip until they use it
if (!mapReuseKey.count(pfrom->addr.ip))
mapReuseKey[pfrom->addr.ip] = GenerateNewKey();

...sends the key mapReuseKey[pfrom->addr.ip]

...later...

// Received something with this key
mapReuseKey.erase(pfrom->addr.ip);

If it's not convenient to know when you've received, just clear the cached keys every 20 minutes.

I want to add a parameter to getnewaddress for number of days to expire if nothing is received with the address.

Re: Setting up multiple bitcoin machines behind NAT

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Setting up multiple bitcoin machines behind NAT

Date2010-05-16 23:56:03 UTC

ForumBitcointalk · 原文

目前它总是假设入站端口是 8333，所以即使你是从别的端口转发过来的，它也会告诉其他 bitcoin 节点去连 router:8333。

我不太急着修这个，因为我想不出多一个入站端口有什么好处。如果你提供了一个入站端口，你已经为网络尽了自己的一份力。同一个人开两个入站端口对冗余没有帮助。

如果你有很多台电脑，更合理的做法是在大多数机器上用 -connect 开关连到本地。

英文原文

At the moment, it always assumes the incoming port is 8333, so it would tell other bitcoin nodes to connect to router:8333 even if you're redirecting from another port number.

I'm not in a big hurry to fix this because I can't think of any benefit to having more than one incoming connection port. If you're providing one incoming port, then you've done your bit to help the network. Having two incoming ports to the same person doesn't help redundancy.

If you have many computers, then using the -connect switch on most of them to connect locally makes more sense.

Re: Could the bitcoin network be destroyed by someone generating endless bitcoin add

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Could the bitcoin network be destroyed by someone generating endless bitcoin add

Date2010-05-16 21:01:44 UTC

ForumBitcointalk · 原文

你生成一个新的比特币地址，只占你自己电脑上一点磁盘空间（大概 500 字节）。就像生成一个新的 PGP 私钥，只不过它是 ECC，CPU 开销更小。地址空间实际上是无限的。不伤害任何人，想生成多少生成多少。

英文原文

When you generate a new bitcoin address, it only takes disk space on your own computer (like 500 bytes). It's like generating a new PGP private key, but less CPU intensive because it's ECC. The address space is effectively unlimited. It doesn't hurt anyone, so generate all you want.

Re: For a website taking payments with bitcoins, better: IP or bitcoin addresses?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: For a website taking payments with bitcoins, better: IP or bitcoin addresses?

Date2010-05-16 21:37:36 UTC

ForumBitcointalk · 原文

引用 Xunie（May 14, 2010, 09:52:53 PM）（https://bitcointalk.org/index.php?topic=129.msg1124#msg1124）：

我建议用户用代理的时候禁用 IP 交易！

稳妥起见。

好主意。至少弹个警告对话框，说明它会连到那个 IP、并以明文发送信息，给用户取消的机会。

英文原文

Quote from: Xunie on May 14, 2010, 09:52:53 PM（https://bitcointalk.org/index.php?topic=129.msg1124#msg1124）:
> I suggest we disable IP transactions while the user uses a Proxy!
> Just to be on the safe side.
>
That's a good idea. At the very least a warning dialog explaining that it'll connect to the IP and send the information cleartext, giving the chance to cancel.

Re: Is there a way to automate bitcoin payments for a website?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Is there a way to automate bitcoin payments for a website?

Date2010-05-18 02:58:11 UTC

ForumBitcointalk · 原文

有点晚了，不过万一别人也遇到同样的问题。编译输出里有 2 个警告（每个 20 行长）和 2 个链接错误。错误是：

Quote:

obj/nogui/init.o(.gnu.linkonce.t._ZNK13wxArrayString4ItemEm+0x13): In function `wxArrayString::Item(unsigned long) const':

/usr/local/include/wx-2.9/wx/buffer.h:42: undefined reference to `wxTheAssertHandler'

obj/nogui/init.o(.gnu.linkonce.t._ZNK13wxArrayString4ItemEm+0x45): In function `wxArrayString::Item(unsigned long) const':

/usr/src/bitcoin/trunk/uint256.h:526: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'

大概是因为切到了 wxWidgets 的 release 构建而不是 debug 构建。它们正在往只保留 debug 构建、砍掉 release 构建的方向走，所以 release 构建里引用了不存在的 assert 东西、坏了它们大概也不在乎。debug 构建没什么可怕的，完全适合拿来发布。

bitcoind 以守护进程运行，可以通过命令行或 JSON-RPC 控制。

感谢 madhatter 和 generica 详细写了在 freebsd 上构建的步骤。

英文原文

A little late, but in case anyone else has the same issue. The compile dump had 2 warnings (that were 20 lines long) and 2 link errors. The errors were:

Quote:
> obj/nogui/init.o(.gnu.linkonce.t._ZNK13wxArrayString4ItemEm+0x13): In function `wxArrayString::Item(unsigned long) const':
> /usr/local/include/wx-2.9/wx/buffer.h:42: undefined reference to `wxTheAssertHandler'
>
> obj/nogui/init.o(.gnu.linkonce.t._ZNK13wxArrayString4ItemEm+0x45): In function `wxArrayString::Item(unsigned long) const':
> /usr/src/bitcoin/trunk/uint256.h:526: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'
>

Those are probably due to switching to the release build of wxWidgets instead of debug. They're moving towards only debug build and ditching the release build, so they probably don't care that their release build is broken by referring to non-existent assert stuff. There's nothing to fear about the debug build. It's fully suitable for releases.

bitcoind runs as a daemon and can either be controlled by command line or JSON-RPC.

Thanks madhatter and generica for detailing the instructions for building on freebsd.

Re: Ummmm... where did my bitcoins go?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Ummmm... where did my bitcoins go?

Date2010-05-18 20:06:46 UTC

ForumBitcointalk · 原文

慢的不是下载本身，而是下载的同时要验证所有区块里所有签名，这才是耗时的。

初始区块下载一般要多久？是中途变慢，还是全程速度差不多？

我想过对大部分链、只到最后几千个区块之前做个粗略检查的办法。技术上可行，但工作量很大，而且还有很多优先级更高的事要做。

Simplified Payment Verification（简化支付验证）是给轻量级纯客户端用户用的，他们只做交易、不生成、也不参与节点网络。他们不需要下载区块，只需要哈希链，目前大概 2MB，验证起来非常快（验证整条链不到一秒）。如果网络变得非常大，比如超过 100,000 个节点，我们就用它让普通用户不用跑全节点也能交易。到那时，大多数用户应该开始跑纯客户端软件，只有专业的服务器机房继续跑全网络节点，有点像 usenet 网络的集中化过程。

SPV 还没实现，而且要到很久以后才会实现，但目前的所有实现都是围绕着支持它来设计的。

与此同时，vekja.net（http://vekja.net）和 www.mybitcoin.com（http://www.mybitcoin.com）这样的站在试验账户制网站。你在网站上开个户，比特币存在账户里，转进转出。在网站上开户比安装、学习使用软件容易得多，对大多数人来说也是更熟悉的方式。唯一的缺点是你要信任这个站，但对零钱级别的微支付和日常开销来说没问题。这是个容易上手的起点，等金额大了再升级到真正的 bitcoin 软件。

英文原文

It's not the download so much as verifying all the signatures in all the blocks as it downloads that takes a long time.

How long is the initial block download typically taking? Does it slow down half way through or is about the same speed the whole way?

I've thought about ways to do a more cursory check of most of the chain up to the last few thousand blocks. It is possible, but it's a lot of work, and there are a lot of other higher priority things to work on.

Simplified Payment Verification is for lightweight client-only users who only do transactions and don't generate and don't participate in the node network. They wouldn't need to download blocks, just the hash chain, which is currently about 2MB and very quick to verify (less than a second to verify the whole chain). If the network becomes very large, like over 100,000 nodes, this is what we'll use to allow common users to do transactions without being full blown nodes. At that stage, most users should start running client-only software and only the specialist server farms keep running full network nodes, kind of like how the usenet network has consolidated.

SPV is not implemented yet, and won't be implemented until far in the future, but all the current implementation is designed around supporting it.

In the meantime, sites like vekja.net（http://vekja.net） and www.mybitcoin.com（http://www.mybitcoin.com） have been experimenting with account-based sites. You create an account on a website and hold your bitcoins on account there and transfer in and out. Creating an account on a website is a lot easier than installing and learning to use software, and a more familiar way of doing it for most people. The only disadvantage is that you have to trust the site, but that's fine for pocket change amounts for micropayments and misc expenses. It's an easy way to get started and if you get larger amounts then you can upgrade to the actual bitcoin software.

Re: We accept Bitcoins

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: We accept Bitcoins

Date2010-05-20 21:43:42 UTC

ForumBitcointalk · 原文

引用 DataWraith（May 19, 2010, 07:52:42 PM）（https://bitcointalk.org/index.php?topic=30.msg1161#msg1161）：

我能插个问题问下为什么吗？在我看来，既然 Bitcoin 用公钥密码学来转移币的所有权，那附上一段只有收款人能读的短消息应该是小事一桩。

差一点，但不完全是。Bitcoin 用的是 EC-DSA，它只能做数字签名，做不了加密。RSA 两样都能做，但我没用它，因为它要大一个数量级，不现实。

英文原文

Quote from: DataWraith on May 19, 2010, 07:52:42 PM（https://bitcointalk.org/index.php?topic=30.msg1161#msg1161）:
> Can I just butt in with a question on why that is? To me it seems that if Bitcoin uses public-key cryptography to transfer ownership of the coins, it should be a trivial matter to include a short message that is only readable by the recipient.
>
Almost but not quite. Bitcoin uses EC-DSA, which can only do digital signing, not encryption. RSA can do both, but I didn't use it because it's an order of magnitude bigger and would have been impractical.

JSON-RPC programming tips using labels

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleJSON-RPC programming tips using labels

Date2010-05-26 18:27:25 UTC

ForumBitcointalk · 原文

我加了跟 label 相关的函数，方便管理每个用户下的多个地址。新增或改名的函数有：
getreceivedbyaddress -- 单个地址收到的金额
getreceivedbylabel -- 该 label 下所有地址收到的金额
listreceivedbyaddress -- 列出地址及各自收到的金额
listreceivedbylabel -- 列出 label 及各自收到的金额
setlabel -- 为完整起见的杂项 label 函数
getlabel
getaddressesbylabel

为保持一致，我把 getamountreceived 改名为 getreceivedbyaddress、getallreceived 改名为 listreceivedbyaddress。旧名字还留着，免得破坏现有代码，但已废弃。

思路是：每次调用 getnewaddress 时都带上用户名，就可以用 "bylabel" 函数查到该用户所有地址收到的总额。你可以随意更换他的地址，不用操心跟踪他所有的旧地址。

自动更换用户收款地址的好办法：在展示他当前地址之前，先查一下这个地址有没有收到过东西，如果有就换个新的：

// Get a new address whenever the current one has received anything
if (strAddr == "" || getreceivedbyaddress(strAddr) > 0)
strAddr = getnewaddress(strUsername); // Label the address with username
Display(strAddr); // Display their current receiving address

// Get total received by all the user's addresses
getreceivedbylabel(strUsername, 0) // unconfirmed
getreceivedbylabel(strUsername, 1) // available balance

如果只是查某个特定用户的余额，比如响应他的一次页面请求，用 getreceivedbylabel；但如果是遍历所有用户，用 listreceivedbylabel 一次拿到完整列表再扫更好。用 getreceivedbylabel 去扫用户是 n 平方，用 listreceivedbylabel 是 n log n（或线性）。

只有当你需要轮询、收到钱就自动触发动作，而不是用户自己上网页看余额、再告诉你怎么处理时，才需要扫全用户。轮询也不用太频繁。如果你要求 1 个确认，平均也要 10 分钟，所以几分钟轮询一次以上没有意义。

如果你卖的是数字商品和服务，损失不大、被白嫖也转卖不了牟利，我觉得接受 0 确认没问题。

只有卖黄金或货币这种，才需要多个确认。

英文原文

I added label related functions to help with managing multiple addresses per user. New or renamed functions are:
getreceivedbyaddress -- amount received on a single address
getreceivedbylabel -- amount received by all addresses with this label
listreceivedbyaddress -- list addresses and amounts they've received
listreceivedbylabel -- list labels and amounts they've received
setlabel -- misc label functions for completeness
getlabel
getaddressesbylabel

For consistency I renamed getamountreceived->getreceivedbyaddress and getallreceived->listreceivedbyaddress. The old names are still there so as not to break existing code, but they're deprecated.

The idea is that if you give the username whenever you call getnewaddress, you can get the user's total received across all their addresses using the "bylabel" functions. You can freely change their address without worrying about tracking all their old addresses.

A good way to automate changing the user's receiving address: just before displaying their current address, check if it has been used to receive anything, if it has then replace it with a new one:

// Get total received by all the user's addresses
getreceivedbylabel(strUsername, 0) // unconfirmed
getreceivedbylabel(strUsername, 1) // available balance

If you're just getting one particular user's balance, such as in response to a page request by that user, use getreceivedbylabel, but if you're scanning over all users, it's better to use listreceivedbylabel to get the complete list and scan against the result. Scanning users with getreceivedbylabel would be n-squared, using listreceivedbylabel is n-log-n (or n linear).

You should only really need to scan all users if you're polling in order to spontaneously take action in response to money received, rather than the user going to a webpage, seeing their balance and telling you what to do with it. It's not necessary to poll very frequently. If you require 1 confirmation, that'll take an average of 10 minutes anyway, so there's no point in polling more often than every few minutes.

If you're selling digital goods and services, where you don't lose much if someone gets a free access, and it can't be resold for profit, I think you're fine to accept 0 confirmations.

It's mostly only if you were selling gold or currency that you'd need multiple confirmations.

Re: Tracing a coin's lineage

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Tracing a coin's lineage

Date2010-05-26 18:51:04 UTC

ForumBitcointalk · 原文

引用 Xunie（May 26, 2010, 12:50:04 AM）（https://bitcointalk.org/index.php?topic=154.msg1242#msg1242）：

能不能强制用户每次收款都用新地址？

每次收到付款就在地址栏里显示另一个 Bitcoin 地址。（只针对走 Bitcoin 地址的交易，走 IP 的当然不行，那样没用，对吧？）

实际的 key 还是会保留，确保有人往旧地址付款用户照样能收到。

这个在我待办里。我很快会让 "Your Bitcoin Address:" 窗口在显示的地址收到任何东西后自动更换。

我也推荐 web 应用按这个思路实现。我刚发了些示例代码，展示了建议的实现方式。

0.2.4 之后的 SVN 版本在地址栏旁边已经有个 "New..." 按钮，鼓励大家手动更换。

@theymos：如果实在不行，将来我们可以退回那个方案。

英文原文

Quote from: Xunie on May 26, 2010, 12:50:04 AM（https://bitcointalk.org/index.php?topic=154.msg1242#msg1242）:
> Can't we force a user to use a new address for receiving payments?
> Every time a payment is received display another Bitcoin address in the address bar. (only transactions via Bitcoin addresses, NOT IPs of course, since that'd be useless, right?)
> The actual key would still be kept to ensure that the user would still receive payments of people sending to the same address.
>
This is on my list. I will soon make the "Your Bitcoin Address:" window automatically change whenever you receive anything to the address displayed.

I'm also recommending this approach for the implementation of web apps. I just posted some sample code showing a suggested way of implementing this.

Versions on SVN since 0.2.4 already have a "New..." button next to the address bar to encourage changing it manually too.

@theymos: If nothing else, we can fall back on that solution in the future.

Re: CLI bitcoin generation

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: CLI bitcoin generation

Date2010-05-26 20:09:34 UTC

ForumBitcointalk · 原文

引用 molybdenum（May 22, 2010, 06:44:20 PM）（https://bitcointalk.org/index.php?topic=145.msg1194#msg1194）：

加个可选参数，指定那笔交易之后最少经过多少个区块（getallreceived 1 是当前行为，或者就 getallreceived；偏执的用 getallreceived 5，想要即时确认的用 getallreceived 0）？

对，其实就是这个意思。getallreceived 0 就能达到你要的效果。（现在它改名叫 listreceivedbyaddress 0）默认是 1 个确认，但我觉得现实中大多数数字商品和服务 0 确认就行。就像你说的，如果需要 0 个以上的确认，可以同时显示两个数：未确认和可用余额，这样他们立刻就能看到交易过去了。

listreceivedbyaddress [minconf=1] [includeempty=false]
[minconf] 是付款计入之前的最小确认数。
[includeempty] 是否包含没收到过付款的地址。
返回一个对象数组，包含：
"address" : 收款地址
"label" : 收款地址的 label
"amount" : 该地址收到的总额
"confirmations" : 计入的最近一笔交易的确认数

如果用用户名给地址打 label，就用 listreceivedbylabel。

目前我主要在做给 web 商家用的函数，无头（headless）挖矿机的远程管理功能还没怎么顾上。

英文原文

Quote from: molybdenum on May 22, 2010, 06:44:20 PM（https://bitcointalk.org/index.php?topic=145.msg1194#msg1194）:
> An optional parameter to specify the minimum number of blocks after that transaction (getallreceived 1 for current behavior, or just getallreceived, getallreceived 5 for the paranoid, getallreceived 0 for instant confirms)?
>
Yeah, that actually is what it is. getallreceived 0 should do what you want. (now it's renamed to listreceivedbyaddress 0) The default is 1 confirmation, but I think in reality most digital goods and services can be 0 confirmations. Like you say, if you need more than 0 confirmations, you could show two numbers, unconfirmed and available balance, so they immediately see their transaction went through.

listreceivedbyaddress [minconf=1] [includeempty=false]
[minconf] is the minimum number of confirmations before payments are included.
[includeempty] whether to include addresses that haven't received any payments.
Returns an array of objects containing:
"address" : receiving address
"label" : the label of the receiving address
"amount" : total amount received by the address
"confirmations" : number of confirmations of the most recent transaction included

or listreceivedbylabel if you're labelling addresses with their username.

So far I've concentrated on functions for web merchants, not so much on stuff for remote management of headless coin generators yet.

Re: Share database blocks ?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Share database blocks ?

Date2010-05-26 20:34:34 UTC

ForumBitcointalk · 原文

它确实是一次下载 500 个区块，然后计数器在逐个验证区块时一个一个数。

让 bitcoin 自己下载并验证区块的好处是：你不用信任你从谁那里下载。如果从某个网站下载 blk*.dat 文件，你就得信任那个网站，因为你是未经自己验证就接受了数据。如果是从你自己的另一台电脑上拷 blk*.dat，那没问题。

你的初始区块下载一般要多久？

英文原文

It does in fact download 500 blocks at a time, then the counter counts one at a time as it verifies the blocks.

The advantage of letting bitcoin download and verify the blocks is that you do not have to trust the person you're downloading them from. If you downloaded the blk*.dat files from some site, you would have to trust that site, since you would be accepting the data without verifying it yourself. If you're copying blk*.dat from another computer of yours, that should be fine.

How long is the initial block download taking for you?

Re: Website translations

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Website translations

Date2010-05-26 21:16:34 UTC

ForumBitcointalk · 原文

有人愿意翻译 Bitcoin 客户端本身吗？0.3 版本能带上至少一门其他语言就太好了。

很简单：装个 poedit，翻译我附在这帖里的 po 文件就行。不到 750 个词。

0.3.1 更新了 bitcoin.po 附件。

英文原文

Does anyone want to translate the Bitcoin client itself? It would be great to have at least one other language in the 0.3 release.

All you have to do is get poedit and translate the po file I'm attaching to this post. It's less than 750 words.

Updated bitcoin.po attachment for 0.3.1

Re: Odd amount of generated coins

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Odd amount of generated coins

Date2010-05-26 21:34:32 UTC

ForumBitcointalk · 原文

在 SVN 版本里，如果一笔交易需要交易费，它会说
"This transaction is over the size limit. You can still send it for a fee of #,
which goes to the nodes that process your transaction and helps to support the network.
Do you want to pay the fee?"

如果加上手续费后你的钱不够，它会说
"Total exceeds your balance when the # transaction fee is included "

英文原文

In the SVN version, if a transaction requires a transaction fee, it says
"This transaction is over the size limit. You can still send it for a fee of #,
which goes to the nodes that process your transaction and helps to support the network.
Do you want to pay the fee?"

If you don't have enough money with the fee added, it says
"Total exceeds your balance when the # transaction fee is included "

Re: Website translations

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Website translations

Date2010-05-27 14:18:22 UTC

ForumBitcointalk · 原文

好耶！我们有了第一门语言。我把它上传到 SVN，会进 0.3 版本。

英文原文

Hurray! We have our first language. I uploaded it to SVN to go in with the 0.3 release.

Re: Hostnames instead of IP Addresses

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Hostnames instead of IP Addresses

Date2010-06-02 18:18:15 UTC

ForumBitcointalk · 原文

现在的 IP 发送不太实用：它直连 IP，所以你想用 TOR 匿名，但那样就会被全程窃听和中间人。

将来给 IP 发送的计划是做成比特币地址加 IP，像这样：

1auaDZCFYqaGx4FKS5WenNfurk2SkoDu4h<someseparatorcharacter>1.2.3.4
或
1auaDZCFYqaGx4FKS5WenNfurk2SkoDu4h<someseparatorcharacter>domain.com

分隔符用什么，我需要建议。":" 是个候选，但 IPv6 里有 :，可能会混淆。最好是 url 参数里允许的字符。

我想用 SSL 建连接，用比特币地址的公钥做证书。你就能确定连到的是你以为的那个人，而且加密安全。比特币地址不用于交易，只用于认证。一个新生成的比特币地址会通过这条 SSL 连接发过去。

既然认证了，那 IP 地址用域名也就安全了。要注意的是，如果用了代理，得让它用 socks4a 而不是 DNS 解析。

英文原文

The current sending by IP is not very useful: it connects to the IP, so you'd like to use TOR for anonymity, but then it can totally be eavesdropped and man-in-the-middled.

The future plan for sending to an IP is to make it a bitcoin address plus IP, like:

1auaDZCFYqaGx4FKS5WenNfurk2SkoDu4h<someseparatorcharacter>1.2.3.4
or
1auaDZCFYqaGx4FKS5WenNfurk2SkoDu4h<someseparatorcharacter>domain.com

I need suggestions for the separator character. ":" is a candidate, but IPv6 has : in it and that might get confusing. Something that's allowed in url parameters would be nice.

I want to use SSL for the connection, using the bitcoin address' public key as the cert. You would be certain you're connected to who you thought, and safely encrypted. The bitcoin address would not be used for the transaction, only for authentication. A new generated bitcoin address would be sent through the SSL connection.

Since it's authenticated, it would then be safe to allow the IP address to be a domain name. Some care taken that if a proxy is used, it uses socks4a instead of DNS lookup.

Re: Proof-of-work difficulty increasing

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Proof-of-work difficulty increasing

Date2010-06-02 18:45:38 UTC

ForumBitcointalk · 原文

好主意。我还没想好具体放哪，但它确实可以算出区块生成的预期平均间隔，让大家知道该预期什么。

每个节点、每个处理器的区块里都有不同的公钥，所以保证了它们扫描的是不同的区间。

32 位 nonce 每次从 1 重新开始时，bnExtraNonce 就加一，它是个任意精度整数。

英文原文

That's a good idea. I'm not sure where exactly to fit that in, but it could certainly calculate the expected average time between blocks generated, and then people would know what to expect.

Every node and each processor has a different public key in its block, so they're guaranteed to be scanning different territory.

Whenever the 32-bit nonce starts over at 1, bnExtraNonce gets incremented, which is an arbitrary precision integer.

Re: Website translations

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Website translations

Date2010-06-02 22:18:09 UTC

ForumBitcointalk · 原文

我把完成 93% 的荷兰语翻译上传到 SVN 了。谢谢！

英文原文

I uploaded the 93% complete Dutch translation to SVN. Thanks!

Re: On IRC bootstrapping

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: On IRC bootstrapping

Date2010-06-14 18:13:21 UTC

ForumBitcointalk · 原文

Bitcoin 有自己的分布式地址目录，用 "addr" 消息。是时候把当前长期在线的固定节点的列表写进代码做种子了。我可以加一段代码，让新节点不赖在种子节点上，只是连上去拿列表就走，这样不会给它们造成负担。

大家觉得呢，我直接加上种子？

它还是会先试 IRC。IRC 的好处是列出来的是当前在线的节点，因为它们得保持连接才能留在列表上；坏处是单点故障。"addr" 系统没有单点故障，但只能告诉你最近见过哪些节点，所以有些试的节点已经下线，初次连上会慢一点。两者结合，取长补短，更健壮。

有人愿意在 freenode 嫌我们烦的时候，志愿跑个 IRC 服务器吗？

英文原文

Bitcoin has its own distributed address directory using the "addr" message. It's about time we coded in a list of the current long running static nodes to seed from. I can add code so new nodes do not preferentially stay connected to the seed nodes, just connect and get the list, so it won't be a burden on them.

What do you think, should I go ahead with adding the seeds?

It'll still try IRC first. The IRC has the advantage that it lists nodes that are currently online, since they have to stay connected to stay on the list, but the disadvantage that it's a single point of failure. The "addr" system has no single point of failure, but can only tell you what nodes have recently been seen, so it takes a little longer to get connected since some of the nodes you try have gone offline. The combination of the two gets us the best of both worlds and more total robustness.

Is there anyone who wants to volunteer to run an IRC server in case freenode gets tired of us?

Re: Hostnames instead of IP Addresses

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Hostnames instead of IP Addresses

Date2010-06-14 19:53:44 UTC

ForumBitcointalk · 原文

SirArthur 关于普通在线商家场景的观点很对，IP 发送选项更适合的就是这种场景。也就是商家有固定 IP 的服务器、有自己的域名和 SSL 证书的情况。

不用按 IP 连，我们可以按域名走 SSL 连，用现有的 CA 体系认证你连到的是该域名的所有者。

用户发送到 domain.com（www.domain.com（http://www.domain.com）也行）。这很自然，用户能看到、核实自己要付给谁。

SSL 也让 TOR 用户安全了。

问题是，我觉得商家还是更愿意用比特币地址，这样才能确定这笔付款是干嘛的。你根本指望不上用户在备注栏里填对东西来标识交易。除非有 mailto 风格的链接、把订单号预填进备注栏才勉强可行，但那样的链接直接做成比特币地址也一样。

在 domain.com 上开个开放的 bitcoin 服务器、让用户往里打匿名付款，责任太大了。普通用户没有"付款得先标识自己"这个概念。商家会收到一堆空白付款，一周后接着一堆"我付过钱了，我的货呢？！"。

付款流程里有一步是收款方在接受前核验订单。它可以拒绝付款、返回错误信息，如果付款里没有有效订单号的话。但这需要把定制代码跟 bitcoin 服务器做深度的集成，难度不小。

英文原文

SirArthur has a good point about the normal online merchant case, which is what the send-by-IP option is more suited to. This is the case where the merchant will have a server on a static IP and their own domain name and SSL cert.

Instead of connecting by IP, we can connect to a domain name by SSL, using the existing CA infrastructure to authenticate that you're connected to the owner of that domain.

The user would send to domain.com (or www.domain.com（http://www.domain.com） is ok too). That would be very natural and users could see and verify that what they entered is who they intend to pay.

The SSL also makes it safe for TOR users.

Problem is, I think merchants would still prefer to use bitcoin addresses to be certain they know what the payment is for. You simply cannot count on users to enter the right thing in the comment fields to identify the transaction. It would only approach practical if we had a mailto style link that prepopulates the comment field with the order number, but then the link could just as well be a bitcoin address.

Just having an open bitcoin server at domain.com that users could send unidentified payments to would be too much of a liability. Regular users aren't used to the idea of having to identify the payment. Merchants would get too many blank payments followed by "I paid you, where's my stuff?!" a week later.

The payment sequence does have a step where the receiver verifies the order before accepting it. It can reject the payment and return an error message if it doesn't contain a valid order number. That would require a difficult level of integration of custom code with the bitcoin server though.

Re: Dealing with SHA-256 Collisions

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Dealing with SHA-256 Collisions

Date2010-06-14 20:39:50 UTC

ForumBitcointalk · 原文

SHA-256 非常强。它不是 MD5 到 SHA1 那种小步迭代。除非出现重大的突破性攻击，它能撑几十年。

如果 SHA-256 被彻底攻破，我觉得我们可以对出事之前那条诚实的链达成共识，把它锁定，然后换新的哈希函数继续。

如果哈希是慢慢出问题的，我们可以有序过渡到新哈希。软件会设定从某个区块号开始用新哈希。大家要在那之前升级。软件可以把所有旧区块的新哈希存下来，确保没人能拿另一个有相同旧哈希的区块来顶替。

英文原文

SHA-256 is very strong. It's not like the incremental step from MD5 to SHA1. It can last several decades unless there's some massive breakthrough attack.

If SHA-256 became completely broken, I think we could come to some agreement about what the honest block chain was before the trouble started, lock that in and continue from there with a new hash function.

If the hash breakdown came gradually, we could transition to a new hash in an orderly way. The software would be programmed to start using a new hash after a certain block number. Everyone would have to upgrade by that time. The software could save the new hash of all the old blocks to make sure a different block with the same old hash can't be used.

Re: Technical clarifications

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Technical clarifications

Date2010-06-14 22:21:55 UTC

ForumBitcointalk · 原文

3）如果用比特币地址发送：没区别
5）它是去中心化的。第一次连上网络之后，你就不再需要 IRC 了。

英文原文

3) Nothing, if sending by bitcoin address
5) It is decentralised. After you have connected to the network the first time, you no longer need IRC.

Re: Can't Build r80 from SVN

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Can't Build r80 from SVN

Date2010-06-14 22:40:14 UTC

ForumBitcointalk · 原文

抱歉，最近几个 revision 我没在 linux 上测试编译。

回滚了 makefile.unix。

英文原文

Sorry, I didn't test compile on linux the last few revisions.

Reverted makefile.unix.

Re: What is the incentive to collect transactions?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: What is the incentive to collect transactions?

Date2010-06-15 23:41:29 UTC

ForumBitcointalk · 原文

引用 theymos（June 05, 2010, 04:26:09 PM）（https://bitcointalk.org/index.php?topic=165.msg1373#msg1373）：

往你正在挖的区块里加交易会拖慢你的生成速度

这个前提是错的。往你正在挖的区块里加更多交易，并不会拖慢你的生成速度。generate 扫描哈希时只哈希区块头，区块头是固定大小的。区块头里包含交易的哈希（默克尔根），只是偶尔更新一下。

如果有必要，我可以写代码让节点倾向于不用交易太少的区块。一个交易不够多的区块几乎总是进不了主链，但万一进去了也会被接受。我怀疑这没必要，因为节点不打包全部交易并没有什么好处。

英文原文

Quote from: theymos on June 05, 2010, 04:26:09 PM（https://bitcointalk.org/index.php?topic=165.msg1373#msg1373）:
> Adding transactions to the block you're working on will slow down your generation rate
>
The premise is false. Adding more transactions to the block you're working on does NOT slow down your generation rate. When generate is scanning hashes, it only hashes the header of the block, which is constant size. The header contains a hash of the transactions (the Merkle root) and is only updated occasionally.

If necessary I can write code to make nodes prefer not to use a block if it doesn't contain enough of the transactions they know about. A discouraged block would almost always fail to be included in the main chain, but would be accepted if it did get in. I doubt this will be necessary, since there's no real advantage for nodes not to include all transactions.

Re: URI-scheme for bitcoin

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: URI-scheme for bitcoin

Date2010-06-16 00:15:47 UTC

ForumBitcointalk · 原文

http://127.0.0.1:8330/?to=domain.com&amount=200.00&comment=order_12345
或
http://127.0.0.1:8330/?to=<bitcoinaddress><separatorchar>1.2.3.4&amount=200.00

但既然链接已经替你把字打了，我看不出用域名地址比用比特币地址有什么好处。用比特币地址，用户打不出匿名付款。不拿到正确的比特币地址，他们就付不出去。

按域名发送的好处是能直观核实钱去向谁。

更关键的问题是：如果浏览器不允许连 127.0.0.1 怎么办：
http://bitcointalk.org/index.php?topic=63.msg1589#msg1589

如果真是这样，那个例子里带 127.0.0.1 的 freenet 链接又怎么说？

英文原文

http://127.0.0.1:8330/?to=domain.com&amount=200.00&comment=order_12345
or
http://127.0.0.1:8330/?to=<bitcoinaddress><separatorchar>1.2.3.4&amount=200.00

But as long as the link is already doing the typing for you, I don't see much benefit in using a domain address instead of bitcoin address. With a bitcoin address, the user can't send an unidentified payment. They can't send payment until they've been given a correct bitcoin address to send to.

What would be nice about sending by domain is you could visually verify who it's going to.

A more crucial issue is what if the browser isn't allowed to connect to 127.0.0.1:
http://bitcointalk.org/index.php?topic=63.msg1589#msg1589

and if that's true, then what about that example freenet link that had 127.0.0.1 in it?

Re: Website translations

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Website translations

Date2010-06-16 16:53:34 UTC

ForumBitcointalk · 原文

谢谢 DataWraith！德语翻译已上传 SVN。

太好了，我们已经有 3 门主流语言了。

英文原文

Thanks DataWraith! The German translation is uploaded to SVN.

This is great, we've already got 3 major languages.

Re: new binary release?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: new binary release?

Date2010-06-17 17:07:56 UTC

ForumBitcointalk · 原文

我正在尽快把 0.3 版本发出来。只剩最后几件事了。离 0.2 已经很久了，我们得把带命令行和 JSON-RPC 的预编译 bitcoind 放出来。这次 linux 二进制会有 32 位和 64 位两个版本，Laszlo 会构建 Mac OSX 版。另外还会带上 DataWraith、Xunie 和 Joozero 做的德语、荷兰语和意大利语翻译（谢谢你们！）。

英文原文

I'm working on getting version 0.3 released as soon as I can. Just a last few things left to do. It's been a long time since 0.2 and we need to get a prebuilt bitcoind with command line and JSON-RPC available. This time we'll have both 32-bit and 64-bit linux binaries, and Laszlo is going to build a Mac OSX release. Plus, we'll include the German, Dutch and Italian translations by DataWraith, Xunie and Joozero (thanks you guys!).

Re: Transactions and Scripts: DUP HASH160 ... EQUALVERIFY CHECKSIG

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Transactions and Scripts: DUP HASH160 ... EQUALVERIFY CHECKSIG

Date2010-06-17 18:46:08 UTC

ForumBitcointalk · 原文

Bitcoin 的特性决定了：一旦 0.1 发布，核心设计就终身冻结了。正因为这样，我想让它支持我能想到的所有交易类型。但问题是，每种东西都要专门的支持代码和数据字段，不管用不用都得带着，而且一次只覆盖一个特例。这样下去特例会爆炸。解决办法是脚本，它把问题一般化了：交易双方可以把自己的交易描述成一个谓词，由节点网络来求值。节点只需要理解交易到"判断发送方的条件是否满足"这个程度。

脚本实际上就是个谓词。它就是个求值得真或假的等式。Predicate 这个词又长又陌生，所以我叫它 script。

收款方对脚本做模板匹配。目前收款方只接受两种模板：直接付款和比特币地址。以后版本可以加更多交易类型的模板，跑那个版本及更高版本的节点就能收。新交易所有版本的节点都能验证、打包进区块，哪怕它们读不懂。

这个设计支持种类极多的可能交易类型，都是我几年前设计好的。托管交易、保证金合约、第三方仲裁、多方签名等等。如果 Bitcoin 大规模流行起来，这些都是我们将来想探索的，但都得在一开始就设计好，确保以后能做。

我不认为第二个兼容实现的 Bitcoin 会是个好主意。这么多设计都依赖所有节点步调一致、算出完全相同的结果，第二个实现会是网络的祸害。MIT 协议跟其他所有协议和商业用途都兼容，所以从协议角度也没必要重写。

英文原文

The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime. Because of that, I wanted to design it to support every possible transaction type I could think of. The problem was, each thing required special support code and data fields whether it was used or not, and only covered one special case at a time. It would have been an explosion of special cases. The solution was script, which generalizes the problem so transacting parties can describe their transaction as a predicate that the node network evaluates. The nodes only need to understand the transaction to the extent of evaluating whether the sender's conditions are met.

The script is actually a predicate. It's just an equation that evaluates to true or false. Predicate is a long and unfamiliar word so I called it script.

The receiver of a payment does a template match on the script. Currently, receivers only accept two templates: direct payment and bitcoin address. Future versions can add templates for more transaction types and nodes running that version or higher will be able to receive them. All versions of nodes in the network can verify and process any new transactions into blocks, even though they may not know how to read them.

The design supports a tremendous variety of possible transaction types that I designed years ago. Escrow transactions, bonded contracts, third party arbitration, multi-party signature, etc. If Bitcoin catches on in a big way, these are things we'll want to explore in the future, but they all had to be designed at the beginning to make sure they would be possible later.

I don't believe a second, compatible implementation of Bitcoin will ever be a good idea. So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network. The MIT license is compatible with all other licenses and commercial uses, so there is no need to rewrite it from a licensing standpoint.

Re: Transactions and Scripts: DUP HASH160 ... EQUALVERIFY CHECKSIG

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Transactions and Scripts: DUP HASH160 ... EQUALVERIFY CHECKSIG

Date2010-06-18 16:17:14 UTC

ForumBitcointalk · 原文

第二个版本对我来说是巨大的开发和维护负担。在没有第二个版本把东西锁死的情况下，维护向后兼容、升级网络已经够难了。如果第二个版本搞砸了，用户体验会连累两边，虽然至少能让用户更明白坚持用官方版的重要性。如果有人准备 fork 第二个版本，我得先把用少数版本的各种风险声明讲一堆。这个设计里，有分歧时多数版本赢，对少数版本来说会很难看，我不想细说，只要只有一个版本我就不用面对。

我知道，大多数开发者都不喜欢自己的软件被 fork，但这次我有真正的技术原因。

引用 gavinandresen（June 17, 2010, 07:58:14 PM）（https://bitcointalk.org/index.php?topic=195.msg1613#msg1613）：

我很佩服交易里塞脚本这个方案的灵活性，但我这邪恶的小脑瓜立刻开始想怎么滥用它。我可以在 TxOut 脚本里编码各种有意思的信息，如果没魔改的客户端验证完就忽略这些交易，那它就是个好用的隐蔽广播信道。

酷是酷，可一旦流行起来，有人决定拿几百万笔交易往支付网络里灌、给所有朋友传最新的 Lady Gaga 视频，那就好玩了……

这也是交易费存在的原因之一。真有必要我们还有别的招。

引用 laszlo（June 17, 2010, 06:50:31 PM）（https://bitcointalk.org/index.php?topic=195.msg1612#msg1612）：

Satoshi 你这个设计搞了多久？想得太周全了，不像是坐下来没经过大量头脑风暴和讨论就直接写出来的。大家都在找茬挑毛病，可它一直立得住。

从 2007 年开始。某个时刻我确信了这事可以做到完全不需要信任，就忍不住一直想下去。设计的工作量比写代码大得多。

好在到目前为止，大家提出的所有问题都是我以前考虑过、做过预案的。

英文原文

A second version would be a massive development and maintenance hassle for me. It's hard enough maintaining backward compatibility while upgrading the network without a second version locking things in. If the second version screwed up, the user experience would reflect badly on both, although it would at least reinforce to users the importance of staying with the official version. If someone was getting ready to fork a second version, I would have to air a lot of disclaimers about the risks of using a minority version. This is a design where the majority version wins if there's any disagreement, and that can be pretty ugly for the minority version and I'd rather not go into it, and I don't have to as long as there's only one version.

I know, most developers don't like their software forked, but I have real technical reasons in this case.

Quote from: gavinandresen on June 17, 2010, 07:58:14 PM（https://bitcointalk.org/index.php?topic=195.msg1613#msg1613）:
> I admire the flexibility of the scripts-in-a-transaction scheme, but my evil little mind immediately starts to think of ways I might abuse it. I could encode all sorts of interesting information in the TxOut script, and if non-hacked clients validated-and-then-ignored those transactions it would be a useful covert broadcast communication channel.
>
> That's a cool feature until it gets popular and somebody decides it would be fun to flood the payment network with millions of transactions to transfer the latest Lady Gaga video to all their friends...
>
That's one of the reasons for transaction fees. There are other things we can do if necessary.

Quote from: laszlo on June 17, 2010, 06:50:31 PM（https://bitcointalk.org/index.php?topic=195.msg1612#msg1612）:
> How long have you been working on this design Satoshi? It seems very well thought out, not the kind of thing you just sit down and code up without doing a lot of brainstorming and discussion on it first. Everyone has the obvious questions looking for holes in it but it is holding up well
>
Since 2007. At some point I became convinced there was a way to do this without any trust required at all and couldn't resist to keep thinking about it. Much more of the work was designing than coding.

Fortunately, so far all the issues raised have been things I previously considered and planned for.

Re: On IRC bootstrapping

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: On IRC bootstrapping

Date2010-06-18 17:28:18 UTC

ForumBitcointalk · 原文

SVN 版现在先用 IRC，失败了就 fallback 到写死的种子节点列表。现在种子节点够多了，到下个版本发布时应该还有不少活着。它只是短暂连一下种子节点拿地址列表然后断开，所以你的连接数会归零一阵。这时候耐心点，只是第一次连上慢。

这意味着 TOR 用户不用再 -addnode 了，会自动连上。

英文原文

The SVN version now uses IRC first and if that fails it falls back to a hardcoded list of seed nodes. There are enough seed nodes now that many of them should still be up by the time of the next release. It only briefly connects to a seed node to get the address list and then disconnects, so your connections drop back to zero for while. At that point, be patient. It's only slow to get connected the first time.

This means TOR users won't need to -addnode anymore, it'll get connected automatically.

Re: Get 5 free bitcoins from freebitcoins.appspot.com

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Get 5 free bitcoins from freebitcoins.appspot.com

Date2010-06-18 23:08:34 UTC

ForumBitcointalk · 原文

选得好，这项目作为第一个练手很合适，干得漂亮。要是没人做，我本来打算自己做这个：等凡人挖不动 50BTC 的时候，新用户能立刻拿到点币玩玩。靠捐赠应该能一直装满。发放器上显示余额的做法会鼓励大家往里充。

你应该在页面上放个捐赠比特币地址，给想充钱的人，理想情况是每收到一笔就换个新地址。

英文原文

Excellent choice of a first project, nice work. I had planned to do this exact thing if someone else didn't do it, so when it gets too hard for mortals to generate 50BTC, new users could get some coins to play with right away. Donations should be able to keep it filled. The display showing the balance in the dispenser encourages people to top it up.

You should put a donation bitcoin address on the page for those who want to add funds to it, which ideally should update to a new address whenever it receives something.

Re: Bitcoin in Ubuntu 10.04

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Bitcoin in Ubuntu 10.04

Date2010-06-21 17:20:21 UTC

ForumBitcointalk · 原文

引用 NewLibertyStandard（May 23, 2010, 04:28:12 PM）（https://bitcointalk.org/index.php?topic=149.msg1203#msg1203）：

Bitcoin 在 Ubuntu 的新默认主题下好丑。好像有些主题设置生效了，有些没生效。未选中的文件菜单应该是深底浅字，但它错误地用了浅底浅字，在我显示器上都快看不清了。下个稳定版之前应该修掉。

SVN 版已经修了。
1）菜单栏默认颜色。
2）余额栏不再是异色。
3）比特币地址和余额后面的背景现在跟工具栏同色。

我把标准主题都看了一遍，感觉都还行。

Ubuntu 最小化、最大化、关闭按钮放右边：
gconf-editor
apps->metacity->general
button_layout=menu:minimize,maximize,close

藏得够深的，10 个用户里 9 个都习惯放右边。

英文原文

Quote from: NewLibertyStandard on May 23, 2010, 04:28:12 PM（https://bitcointalk.org/index.php?topic=149.msg1203#msg1203）:
> Bitcoin looks ugly in Ubuntu's new default theme. It seems that some, but not all of the theme settings are being picked up. The unselected file menu should have light text with a dark background, but it incorrectly has light text with a light background. They're similar enough that it's unreadable on my display. It should be fixed before the next stable release.
>
This is now fixed in the SVN version.
1) Menu bar default color.
2) Balance bar not a different color.
3) Background behind bitcoin address and balance now the same color as toolbar.

I checked all the standard themes and it seems reasonable with all of them.

Ubuntu minimize,maximize,close buttons to the right:
gconf-editor
apps->metacity->general
button_layout=menu:minimize,maximize,close

They've got it awfully buried considering 9 out of 10 users are used to having it on the right.

Re: Dying bitcoins

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Dying bitcoins

Date2010-06-21 17:48:26 UTC

ForumBitcointalk · 原文

丢的币只会让其他人的币稍微更值钱一点。就当是捐给大家了。

引用 laszlo（June 21, 2010, 01:54:29 PM）（https://bitcointalk.org/index.php?topic=198.msg1640#msg1640）：

不过我在想，有没有这么个临界点：生成新 coinbase 的难度高到离谱，还不如去恢复丢的币的 key、或者偷别人的币划算？破解的难度确实很高，所以目前生成划算得多，我就是好奇真实数字……会不会有反超的那天？也许 Satoshi 能算算……

计算机得快 2^200 倍才会开始有这个问题。算力多的人拿去生成比拿去偷赚得多。

英文原文

Lost coins only make everyone else's coins worth slightly more. Think of it as a donation to everyone.

Quote from: laszlo on June 21, 2010, 01:54:29 PM（https://bitcointalk.org/index.php?topic=198.msg1640#msg1640）:
> I wonder though, is there a point where the difficulty of generating a new coinbase is so high that it would make more sense to try to recover keys for lost coins or steal other people's coins instead? The difficulty of that is really high so for now it makes a lot more sense to generate but I just wonder what the real figures are.. would that ever become more productive? Maybe Satoshi can address this..
>
Computers have to get about 2^200 times faster before that starts to be a problem. Someone with lots of compute power could make more money by generating than by trying to steal.

Re: Proof-of-work difficulty increasing

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Proof-of-work difficulty increasing

Date2010-06-21 18:09:17 UTC

ForumBitcointalk · 原文

我把 hashmeter 的想法集成进 SVN 版了。它在状态栏左侧显示 khash/s。

两条新的日志信息：
21/06/2010 01:23 hashmeter 2 CPUs 799 khash/s
21/06/2010 01:23 generated 50.00

grep 你的 debug.log 找 "generated" 看生成了多少，grep "hashmeter" 看性能。windows 上用：
findstr "hashmeter generated" "%appdata%\bitcoin\debug.log"

我设的 hashmeter 消息一小时一条。你们觉得多久一条合适？

英文原文

I integrated the hashmeter idea into the SVN version. It displays khash/s in the left section of the status bar.

Two new log messages:
21/06/2010 01:23 hashmeter 2 CPUs 799 khash/s
21/06/2010 01:23 generated 50.00

grep your debug.log for "generated" to see what you've generated, and grep for "hashmeter" to see the performance. On windows, use:
findstr "hashmeter generated" "%appdata%\bitcoin\debug.log"

I have the hashmeter messages once an hour. How often do you think it should be?

Re: Bitcoin in Ubuntu 10.04

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Bitcoin in Ubuntu 10.04

Date2010-06-22 03:45:56 UTC

ForumBitcointalk · 原文

在 Ubuntu 10.04 上它没法干净地去掉任务栏按钮，所以我让它留在那了。

不过你既然提了，有这个功能、哪怕有点糙，也比没有强，虽然任务栏按钮暂时赖着不走、点一下才消失可能会让几个人困惑。

SVN 已更新。

谢谢测试。

英文原文

On Ubuntu 10.04 it wouldn't remove the taskbar button cleanly, so I made it leave it there.

But now that you mention it, it's probably better to have the feature, even if it's messy, than not to have it, though it may confuse a few people when the taskbar button temporarily stays around but disappears if you click on it.

Updated SVN.

Thanks for testing.

0.3 almost ready -- please test the Mac version!

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

Title0.3 almost ready -- please test the Mac version!

Date2010-06-22 04:01:53 UTC

ForumBitcointalk · 原文

0.3 版本我要做的事都做完了。SVN 上的代码基本可以发布了。

这时候的测试非常感谢。

英文原文

I finished everything on my list to do for version 0.3. The code on SVN is about ready to release.

Testing at this point is much appreciated.

Re: How fast do the fastest computers generate bitcoins?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: How fast do the fastest computers generate bitcoins?

Date2010-06-22 04:35:26 UTC

ForumBitcointalk · 原文

我注意到哈希性能在不同 CPU 之间的差异没有想象中大。跟老 CPU 比，新 CPU 在哈希上的提速，不如在通用基准测试上明显。

我猜近年的 CPU 优化都集中在 I/O、分支预测这些地方了。大多数程序都是一堆内存访问、比较和分支，很少有长时间吭哧吭哧纯算数的。

最新 SVN 版有 khash/s 显示。每个处理器 400 khash/s 左右是典型值。

英文原文

I've noticed that hashing performance doesn't vary as much between CPUs as you'd expect. Compared to an old CPU, a newer CPU doesn't show as much of a speedup at hashing as it does on general benchmarks.

I guess recent CPU optimizations must have concentrated on things like I/O and branch prediction. Most programs are a bunch of memory access, comparisons and branching, they rarely get down to cranking away at maths for very long.

The latest SVN version has a khash/s display. Around 400 khash/s per processor is typical.

Re: Bitcoin in Ubuntu 10.04

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Bitcoin in Ubuntu 10.04

Date2010-06-22 16:39:43 UTC

ForumBitcointalk · 原文

0.3 现在加功能已经太晚了，但我会把它记到 0.3 之后的待办里。要不是你指出来，我永远注意不到。

英文原文

It's too late now for feature changes to 0.3, but I'll add that to the post-0.3 to do list. I never would have noticed that if you hadn't pointed it out.

Re: Proof-of-work difficulty increasing

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Proof-of-work difficulty increasing

Date2010-06-22 16:51:14 UTC

ForumBitcointalk · 原文

同意。确实太鸡毛蒜皮，不值得分散用户注意力。

我改成每 30 分钟了。

如果提到每 10 分钟，日志文件里也还是小意思。问题是用户 grep 的时候会不会嫌输出太多。

英文原文

Agree. Certainly too trivial to clutter the user's attention with.

I changed it to every 30 minutes.

If I increased it to every 10 minutes, it would still be a small enough presence in the log file. Question is whether that would be more output than the user wants when they grep.

Re: 0.3 almost ready

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: 0.3 almost ready

Date2010-06-22 17:02:07 UTC

ForumBitcointalk · 原文

引用自：lachesis，2010 年 6 月 22 日 06:20:02 AM（https://bitcointalk.org/index.php?topic=199.msg1658#msg1658）

下个版本发布前能把 listtransactions RPC 方法做完就好了。

我担心太多程序员会拿它来查收款，那样永远靠不住。list/getreceivedbyaddress/label 这几个函数才是靠谱的办法。

我们不能为了等齐所有功能无限延期。总有下一件事要做。

英文原文

Quote from: lachesis on June 22, 2010, 06:20:02 AM（https://bitcointalk.org/index.php?topic=199.msg1658#msg1658）It would be nice if the listtransactions RPC method were finished before the next release, though.
My fear is too many programmers would latch onto that for checking for received payments. It can never be reliable that way. The list/getreceivedbyaddress/label functions are the only way to do it reliably.

We shouldn't delay forever until every possible feature is done. There's always going to be one more thing to do.

Re: 0.3 almost ready

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: 0.3 almost ready

Date2010-06-22 17:37:08 UTC

ForumBitcointalk · 原文

这是用于测试的 Windows 版 RC1：
（已删除，见下文 RC2）

请只在您打算测试并反馈一切是否正常的情况下下载。请务必查看 "c:\program files\bitcoin" 中的文件。

英文原文

Here's RC1 for windows for testing:
(removed, see RC2 below)

Please only download this if you're going to test and report back whether everything seems fine or not. Make sure to look through the files in "c:\program files\bitcoin"

Re: 0.3 almost ready

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: 0.3 almost ready

Date2010-06-22 19:11:41 UTC

ForumBitcointalk · 原文

引用自：davidonpda，2010 年 6 月 22 日 06:23:26 PM（https://bitcointalk.org/index.php?topic=199.msg1673#msg1673）

EXCEPTION: 22DbRunRecoveryException
DBENv::open: DB_RUNRECOVERY: Fatal error, run database recovery
C:\Program Files\Bitcoin\bitcoin.exe in OnInit()

什么操作系统？

一般报这个是因为数据目录该在的地方不存在。看看 "%appdata%" 目录在不在。

0.2 也报这个错吗？0.3 和 0.2 在这方面没区别，0.3 报而 0.2 不报就说不通了。

英文原文

Quote from: davidonpda on June 22, 2010, 06:23:26 PM（https://bitcointalk.org/index.php?topic=199.msg1673#msg1673）EXCEPTION: 22DbRunRecoveryException
DBENv::open: DB_RUNRECOVERY: Fatal error, run database recovery
C:\Program Files\Bitcoin\bitcoin.exe in OnInit()
What operating system?

Normally when it does that it's because the directory where the data directory should go doesn't exist. See if the "%appdata%" directory exists.

Do you get that error with 0.2 also? It's hard to see how you could get that with 0.3 and not with 0.2 since there's nothing different in that regard.

Re: 0.3 almost ready

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: 0.3 almost ready

Date2010-06-22 19:25:13 UTC

ForumBitcointalk · 原文

davidonpda，你之前运行的也是 laszlo 的构建版本吗？

检查一下 "%appdata%" 目录是否存在，以及 "%appdata%\bitcoin"。

试试：
rename "%appdata%\bitcoin" bitcoin2

这样能行吗？

英文原文

davidonpda, were you also running laszlo's build previously?

Check if the "%appdata%" directory exists, and "%appdata%\bitcoin"

Try:
rename "%appdata%\bitcoin" bitcoin2

does it work then?

Re: 0.3 almost ready

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: 0.3 almost ready

Date2010-06-22 19:46:23 UTC

ForumBitcointalk · 原文

你比我回复的速度还快，自己就找到了原因。

看起来 laszlo 构建的 Berkeley DB 所用的 database/log.* 文件与我们的不兼容。.dat 文件没问题，它们的格式应该永远不会变。所有数据都存放在 .dat 文件里。你自己的所有数据都存放在 wallet.dat 中。如果你等它重新下载完区块链，等区块链同步到那些交易被记录的位置时，你丢失的交易和已生成的币就会重新出现。

你把目录复制过去但排除了 log.0000000002，这是最好的解决办法。你现在应该没问题了。

database/log.* 文件只包含临时的数据库数据。如果你上次是正常退出 bitcoin 的，而不是强制终止或崩溃退出，那么 database/log.* 文件通常可以安全删除。它们只用于这种情况：如果数据库在事务进行中时电脑崩溃、程序被终止或崩溃，那么它可以恢复而不丢失数据。

如果可能的话请继续运行 v0.3，不要退回 v0.2.10。

其他遇到这个问题的人，请把 database\log.000000000* 文件移到别处。（如果之后运行正常，可以再删除它们）

我不太愿意让安装程序去删除或移动这些文件。如果上一次运行是因崩溃或被终止而停止的，那么那样做就是错的。

英文原文

You figured it out faster than I could post a reply.

It looks like laszlo's build of Berkeley DB has database/log.* files that are not compatible with ours. The .dat files are fine, their format shouldn't ever change. All data is stored in the .dat files. All your own data is stored in wallet.dat. If you had waited for it to redownload the block chain, your missing transactions and generateds would have appeared as the block chain reached the point where those transactions were recorded.

When you copied the directory except log.0000000002, that's the best solution. You should be good now.

The database/log.* files only contain temporary database data. If you exited bitcoin normally the last time, not exited by forced terminating it or crashing, then the database/log.* files can normally be deleted safely. They're only used so that if the database is in the middle of a transaction when the computer crashes or the program is killed or crashes, then it could recover without losing data.

Please keep running v0.3 if at all possible, don't go back to v0.2.10.

Anyone else who hits this problem, move the database\log.000000000* files somewhere else. (if it works fine after that, you can delete them later)

I'm reluctant to make the installer delete or move those files. If the previous run was stopped by crashing or killed, that would be the wrong thing to do.

Re: 0.3 almost ready

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: 0.3 almost ready

Date2010-06-22 22:23:39 UTC

ForumBitcointalk · 原文

Laszlo 发现启用更多的优化可以让性能提高约 20%，所以 0.3 的哈希速度比 0.2.0 快 20%，不过我猜他是在自己的构建版本里用的这个优化。

30khash 的增量是相对于多少的总速率？（用来算增幅百分比）

英文原文

Laszlo figured out that enabling some more optimisation increased performance about 20%, so 0.3 hashes 20% faster than 0.2.0, but I assume he used that in his own build.

30khash increase to what total rate? (to figure the % increase)

Re: 0.3 almost ready

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: 0.3 almost ready

Date2010-06-24 17:40:05 UTC

ForumBitcointalk · 原文

这是用于测试的 Linux 版 RC1：
（链接已删除，见下文）

它包含 32 位和 64 位二进制文件。

Re: 0.3 almost ready

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: 0.3 almost ready

Date2010-06-25 02:17:41 UTC

ForumBitcointalk · 原文

我不知道。也许有 Linux 经验更丰富的人知道怎么安装它需要的库。

我是用 Ubuntu 10.04 构建的。希望这不是个错误。也许应该用更老的版本构建，以获得更好的向后兼容性。在 Linux 上是不是有这个问题：在最新版本上构建的东西，在老版本上运行会有麻烦？我在 10.04 上有什么办法把 GCC 降级到老版本吗？

64 位版本应该不会比 32 位版本快，不过如果有人能把两个 Linux 版本做个并排对比测试一下就太好了。SHA-256 是 32 位算法，BitcoinMiner 里根本没用到任何 64 位的东西。

Windows 就没必要折腾 64 位版本了。32 位程序在所有 Windows 版本上都能运行。不像 Linux，64 位系统就想要 64 位程序。

我也很好奇它在 Linux 上是不是比 Windows 上快一点。

你觉得我应该把目录做成：
/bin32/
/bin64/
而不是
/bin/32/
/bin/64/ 吗？

英文原文

I don't know. Maybe someone with more Linux experience knows how to install the library it needs.

I built it on Ubuntu 10.04. I hope that wasn't a mistake. Maybe it should have been built on an older version for more backward compatibility. Is this a problem on Linux, that if you build on the latest version, then it has trouble working on older versions? Is there any way I can downgrade to an older version of GCC on 10.04?

The 64-bit version shouldn't be any faster than the 32-bit version, but it would be great if someone could do a side-by-side comparison of the two linux versions and check. SHA-256 is a 32-bit algorithm and nothing in BitcoinMiner uses 64-bit at all.

We don't need to bother with a 64-bit version for Windows. 32-bit programs work on all versions of Windows. It's not like Linux where the 64-bit OS wants 64-bit programs.

I'm also curious if it's a little faster on linux than windows.

Do you think I should make the directories:
/bin32/
/bin64/
instead of
/bin/32/
/bin/64/

Re: 0.3 almost ready

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: 0.3 almost ready

Date2010-06-25 14:10:06 UTC

ForumBitcointalk · 原文

谢谢 virtualcoin，这是个完美的对比。

32 位 Windows（2310k）到 32 位 Linux（2500k）这 8% 的提速，很可能来自 Linux 上更新的 GCC 版本（4.4.3 对 3.4.5）。

32 位 Linux 到 64 位 Linux 这 15% 的提速就比较难解释了。代码完全是 32 位的。

嗯，我想 x86-64 多出的 8 个寄存器应该就是原因。如果能把 16 个状态变量中的大部分放到寄存器里，对 SHA 来说会带来显著的提升。

英文原文

Thanks virtualcoin, that's a perfect comparison.

The 8% speedup from 32-bit Windows (2310k) to 32-bit Linux (2500k) is probably from the newer version of GCC on Linux (4.4.3 vs 3.4.5).

The 15% speedup from 32-bit to 64-bit Linux is more of a mystery. The code is completely 32-bit.

Hmm, I think the 8 extra registers added by x86-64 must be what's helping. That would make a significant difference to SHA if it could hold most of the 16 state variables in registers.

Re: Bitcoin clients getting k-lined from the IRC bootstrapping channel

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Bitcoin clients getting k-lined from the IRC bootstrapping channel

Date2010-06-25 21:15:15 UTC

ForumBitcointalk · 原文

MadHatter，我们需要更多关于发生了什么的细节。

0.2 和 0.3 都有不依赖 IRC 的备用连接方式，只是连接会慢一些。

0.2 在曾经连接过的情况下可以不依赖 IRC 找到其他节点，但全新安装的版本无法在没有 IRC 的情况下首次发现网络。

0.3 也可以不依赖 IRC 进行种子播撒。必要时它可以完全脱离 IRC 运行，但有 IRC 作为冗余更好。

英文原文

We need more details about what happened MadHatter.

Both 0.2 and 0.3 have a backup way of getting connected without IRC, it's just slower to get connected.

0.2 can find other nodes without IRC if it's ever been connected before, but a new install can't discover the network for the first time without IRC.

0.3 can also seed without IRC. It can operate entirely without IRC if it needs to, but it's better having IRC for redundancy.

Re: On IRC bootstrapping

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: On IRC bootstrapping

Date2010-06-25 22:40:47 UTC

ForumBitcointalk · 原文

引用自：laszlo，2010 年 6 月 14 日 06:30:58 PM（https://bitcointalk.org/index.php?topic=84.msg1580#msg1580）

我架了个 IRC 服务器可以用，挺稳的，就是没做冗余。也就两台服务器，我们也不折腾它，就一直跑着。

我的机器是专用 irc 服务器：
2:28PM up 838 days, 20:54, 1 user, load averages: 0.06, 0.08, 0.08

连 irc.lfnet.org 就行。

这主意不错。

大家觉得呢，0.3 要不要切过去？

英文原文

Quote from: laszlo on June 14, 2010, 06:30:58 PM（https://bitcointalk.org/index.php?topic=84.msg1580#msg1580）I run an IRC server you can use, it's fairly stable but it's not on redundant connections or anything. It is only two servers right now but we don't mess with it or anything, it just runs.

My box is a dedicated irc server:
2:28PM up 838 days, 20:54, 1 user, load averages: 0.06, 0.08, 0.08

You can use irc.lfnet.org to connect.
This seems like a good idea.

What does everyone think, should we make the switch for 0.3?

Re: 0.3 almost ready

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: 0.3 almost ready

Date2010-06-26 00:32:09 UTC

ForumBitcointalk · 原文

我们改用 Laszlo 的 irc.lfnet.org 替代 freenode 试试。这是 RC2，唯一的改动就是这个：

（下载链接见下文）

英文原文

Lets try using Laszlo's irc.lfnet.org instead of freenode. Here's RC2, that's the only change in it:

(see below for download links)

Re: Bitcoin clients getting k-lined from the IRC bootstrapping channel

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Bitcoin clients getting k-lined from the IRC bootstrapping channel

Date2010-06-26 14:28:06 UTC

ForumBitcointalk · 原文

Freenode 太显眼了，正好在那些用户和管理员聚集的地方。Laszlo 的方案更适合我们。

我发布了使用 irc.lfnet.org 替代 freenode 的 0.3.0.RC2，如果你想开始切换：
http://bitcointalk.org/index.php?topic=199.msg1787#msg1787

英文原文

Freenode is too visible, right in the middle of where all those users and moderators are hanging out. Laszlo's option is a much better fit for us.

I made 0.3.0.RC2 available that uses irc.lfnet.org instead of freenode if you want to start switching over:
http://bitcointalk.org/index.php?topic=199.msg1787#msg1787

Re: 0.3 almost ready

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: 0.3 almost ready

Date2010-06-26 15:10:10 UTC

ForumBitcointalk · 原文

状态栏的第一个面板与鼠标悬停在菜单项上时的帮助描述是共用的。由于我们的菜单项描述全是空的，所以当你把鼠标悬停在菜单上时，它就被替换成空的了。

英文原文

The first panel of the status bar is shared with the help description of menu items as you hover over them. Since all our menu item descriptions are blank, it replaces it with blank when you're hovering in a menu.

Beta?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleBeta?

Date2010-06-26 17:02:43 UTC

ForumBitcointalk · 原文

是不是该去掉 Beta 了？这次发布我会定为 1.3 版本。

英文原文

Is it about time we lose the Beta? I would make this release version 1.3.

Re: 1.3 almost ready

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: 1.3 almost ready

Date2010-06-26 19:21:05 UTC

ForumBitcointalk · 原文

已把版本号改为 1.3 并去掉 "Beta"。

（链接已删除，见下文）

使用 irc.lfnet.org。

英文原文

Changed the version number to 1.3 and removed "Beta".

(links removed, see below)

Uses irc.lfnet.org.

Re: Bitcoin mobile.

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Bitcoin mobile.

Date2010-06-26 20:58:26 UTC

ForumBitcointalk · 原文

引用自：sirius-m，2010 年 6 月 10 日 01:51:16 PM（https://bitcointalk.org/index.php?topic=177.msg1452#msg1452）

当然可以在手机浏览器上用 vekja.net 或 mybitcoin.com 这类服务，存多少看你多信任它们。

我觉得目前这是最好的选择。跟现金一样，你不会把全部身家揣兜里，带的都是零花钱。

他们可以做个手机优化的小版本网站。如果有 App，它可以是其中一家的前端，主要功能就是二维码扫描器，或者已经有通用的二维码扫描 App，网站直接适配扫码也行。

如果有个 iPhone App 只是 vekja 或 mybitcoin 的前端，不做大的 P2P，苹果会批吗？不批的话理由是什么？实在不行做安卓版也行。其实 App 不是必需的，手机版网站就够了。

在自己家比特币服务器上开个 Web 界面不是人人适用的办法。大多数用户没有固定 IP，设端口转发也太麻烦了。

英文原文

Quote from: sirius-m on June 10, 2010, 01:51:16 PM（https://bitcointalk.org/index.php?topic=177.msg1452#msg1452）You can of course use services like vekja.net or mybitcoin.com on a mobile browser, depositing money there to the extent you trust them.
I think that's the best option right now. Like cash, you don't keep your entire net worth in your pocket, just walking around money for incidental expenses.

They could make a smaller version of the site optimized for mobile. If there was an app, it could be a front end to one of those, with the main feature being QR-code reader, or maybe there's already a universal QR-code reading app that web sites can be designed to accept scans from.

If there was an iPhone app that was just a front end for vekja or mybitcoin, not a big involved P2P, would apple approve it and if not, on what basis? It could always be an Android app instead. An app is not really necessary though, just a mobile sized website.

A web interface to your own Bitcoin server at home wouldn't be a solution for everyone. Most users don't have a static IP, and it's too much trouble to set up port forwarding.

Re: Building BitCoin Client completely Headless

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Building BitCoin Client completely Headless

Date2010-06-26 21:06:06 UTC

ForumBitcointalk · 原文

"1.3 almost ready" 帖子里的 Linux 候选版本包含预编译好的 bitcoind。

英文原文

The linux release candidate in the "1.3 almost ready" thread contains prebuilt bitcoind.

Re: Bitcoin Faucet changes

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Bitcoin Faucet changes

Date2010-06-26 21:39:52 UTC

ForumBitcointalk · 原文

很多大型 ISP 每次连接都会给你分配一个新 IP，通常在同一个 B 类网段里（a.b.?.?）。也许你应该按 B 类网段设置两次付款之间的最小间隔时间。

如果解决不了这个问题，你可以一直降低每次发放的比特币数量，直到可控为止，并且始终要求验证码。

英文原文

Many big ISPs give you a new IP every time you connect, usually in the same class B (a.b.?.?). Maybe you should have a minimum time between payments per class-B.

If you can't solve the problem, you can always keep lowering the amount of bitcoins given until it's manageable, and always require captcha.

Re: Beta?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Beta?

Date2010-06-27 12:43:50 UTC

ForumBitcointalk · 原文

但 1.0 听起来像第一个版本。有些东西新是优点，但对这类软件来说，成熟和稳定才重要。我不想把钱放在一个 1.0 的东西里。1.0 也许一时更有话题性，但之后我们仍然是 1.0，每个后来的人都会觉得我们才刚刚起步。这是第三个大版本，1.3 反映了这个开发历程。（0.1、0.2、1.3）

英文原文

But 1.0 sounds like the first release. For some things newness is a virtue but for this type of software, maturity and stability are important. I don't want to put my money in something that's 1.0. 1.0 might be more interesting for a moment, but after that we're still 1.0 and everyone who comes along thinks we just started. This is the third major release and 1.3 reflects that development history. (0.1, 0.2, 1.3)

Re: IPv6, headless client, and more

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: IPv6, headless client, and more

Date2010-06-27 13:02:38 UTC

ForumBitcointalk · 原文

欢迎，Harry。

我还没想过先不用 bitcoin 而直接上手 bitcoind。我想目前这个帖子就当作教程吧。

bitcoind 目前的重点更多是为网站提供后端支持。对管理无头挖矿机来说，有些功能会很方便，比如 listgenerated。目前，你可以在 debug.log 文件里 grep "generated" 和 "hashmeter" 来获得一些反馈信息。生成的区块大约需要 24 小时才会记入你的余额。

英文原文

Welcome, Harry.

I hadn't thought about starting out using bitcoind without using bitcoin first. I guess for now, this thread serves as the tutorial.

The focus for bitcoind so far has been more on backend support for websites. There's demand for things that would be nice for adminning headless generators like listgenerated. For the moment, you can grep the debug.log file for "generated" and "hashmeter" for some feedback. Generated blocks take about 24 hours before they're credited to your balance.

Re: 1.3 almost ready

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: 1.3 almost ready

Date2010-06-27 15:30:13 UTC

ForumBitcointalk · 原文

MinGW 还是只有老而稳定的 3.4.5。他们也没什么理由去更新它。

我看过 3.4.5 编译出来的 SHA 反汇编代码，完全看不出还有什么优化空间。我想象不出还能再挤出 8%。Windows 有可能有 8% 的额外开销吗？没有系统调用之类的，只是纯粹繁忙的计算代码，任务切换和其他管家操作会耗掉这么多吗？

英文原文

MinGW still only has good old stable 3.4.5. There's not much reason for them to update it.

When I looked at the 3.4.5 compiled SHA disassembly, I couldn't see any room for improvement at all. I can't imagine how 8% more could be squeezed out of it. Is it possible Windows could have 8% more overhead? Not making system calls or anything, just plain busy computational code, could task switching and other housekeeping operations take away that much?

Re: Major Meltdown

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Major Meltdown

Date2010-06-27 19:06:09 UTC

ForumBitcointalk · 原文

这是个类似问题的回答，关于大崩溃后怎么恢复。

https://www.bitcoin.org/smf/index.php?topic=191.msg1585#msg1585

引用自：satoshi，2010 年 6 月 14 日 08:39:50 PM（https://bitcointalk.org/index.php?topic=191.msg1585#msg1585）

如果 SHA-256 被彻底攻破，我觉得我们可以先对"出事前哪条是诚实链"达成共识，把它锁定，再换个新哈希函数继续。

如果哈希是慢慢被攻破的，我们可以有序过渡到新哈希。软件会设定从某个块号开始用新哈希，大家到时候升级就行。软件可以把所有旧块的新哈希存下来，确保没人能拿一个旧哈希相同、内容不同的块来捣乱。

英文原文

Here's an answer to a similar question about how to recover from a major meltdown.
https://www.bitcoin.org/smf/index.php?topic=191.msg1585#msg1585

Quote from: satoshi on June 14, 2010, 08:39:50 PM（https://bitcointalk.org/index.php?topic=191.msg1585#msg1585）If SHA-256 became completely broken, I think we could come to some agreement about what the honest block chain was before the trouble started, lock that in and continue from there with a new hash function.

Re: Feature Request: Limiting Connections

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Feature Request: Limiting Connections

Date2010-07-02 19:21:36 UTC

ForumBitcointalk · 原文

感谢对此的反馈。

我们可以做的一件事是把出站连接数从 15 降到 10，甚至可能降到 5。15 这个数是随意定的。只要足够保证冗余和消息的快速指数级传播就行。10 也绰绰有余。5 应该也够。10 是个不错的整数，用户能看出它是故意停在这个数的。

实现 UPnP 会有帮助，这样接受入站连接的节点会更多。你的连接数等于接受入站连接的节点数与只出站节点数的比例乘以 15。我们需要鼓励更多人接受入站连接。

我会实现一个功能：当达到一定数量时就停止接受入站连接。

你运行的是哪个版本？

有人知道像 BitTorrent 这样的典型 P2P 软件一般能达到多少连接数吗？

英文原文

Thanks for the feedback on this.

One thing we could do is lower the outbound connections from 15 to 10 or maybe even 5. The choice of 15 was arbitrary. It just needs to be enough for redundancy and fast exponential propagation of messages. 10 would still be plenty. 5 should be fine. 10 is good as a nice round number so users can see that it stopped intentionally.

It would help to implement UPnP so there would be more inbound accepting nodes. Your number of connections is the ratio of inbound accepting nodes to out-only times 15. We need to encourage more people to accept inbound connections.

I will implement a feature to stop accepting inbound connections once you hit a certain number.

Which version are you running?

Anyone know how many connections typical P2P software like BitTorrent can get up to?

Re: 1.3 almost ready

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: 1.3 almost ready

Date2010-07-02 20:37:17 UTC

ForumBitcointalk · 原文

引用自：dkaparis，2010 年 6 月 27 日 10:02:25 PM（https://bitcointalk.org/index.php?topic=199.msg1842#msg1842）

顺带问下，这东西 Visual C++ 能编译吗？我有空想试试。

能，但挖矿慢一倍不止。

英文原文

Quote from: dkaparis on June 27, 2010, 10:02:25 PM（https://bitcointalk.org/index.php?topic=199.msg1842#msg1842）On a related note, is the thing compilable by Visual C++? I'm inclined to give it a try when I get around to it.
It is, but generating is more than twice as slow.

Re: 0.3 almost ready

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: 0.3 almost ready

Date2010-07-02 21:57:45 UTC

ForumBitcointalk · 原文

（已回退到 rc2）

链接已删除，0.3 已正式发布，请去 http://www.bitcoin.org 下载。

英文原文

(reverted to rc2)

Links removed, 0.3 is now released, so go to http://www.bitcoin.org to download it.

Re: Beta?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Beta?

Date2010-07-02 22:03:41 UTC

ForumBitcointalk · 原文

好吧，那就回到 0.3。

请尽快下载 RC4 并检查一下。我想尽快发布。

http://bitcointalk.org/index.php?topic=199.msg1927#msg1927

除了版本号变更（包括 readme.txt 和 setup.nsi 的改动）之外，我把最大出站连接数从 15 降到了 8，这样接受入站连接的节点就不会有太多连接了。15 远超需要，8 的冗余也绰绰有余。

英文原文

OK, back to 0.3 then.

Please download RC4 and check it over as soon as possible. I'd like to release it soon.

http://bitcointalk.org/index.php?topic=199.msg1927#msg1927

Other than the version number change, which included changes in readme.txt and setup.nsi, I reduced the maximum number of outbound connections from 15 to 8 so nodes that accept inbound don't get too many connections. 15 was a lot more than needed. 8 is still plenty for redundancy.

Re: Feature Request: Limiting Connections

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Feature Request: Limiting Connections

Date2010-07-02 22:20:20 UTC

ForumBitcointalk · 原文

我在 RC4 中把最大出站连接数从 15 降到了 8。

15 远超冗余所需，8 的冗余也绰绰有余。

随着节点升级到这个版本，接受入站连接的节点收到的连接数将减半。

如果有人想要超过 8 个连接，可以在防火墙上打开 8333 端口。

英文原文

I reduced max outbound connections from 15 to 8 in RC4.

15 was way more than we needed for redundancy. 8 is still plenty of redundancy.

As the nodes upgrade to this version, this will cut in half the number of connections that inbound accepting nodes get.

If anyone wants more than 8 connections, they can open port 8333 on their firewall.

Re: 0.3 almost ready -- please test the Mac version!

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: 0.3 almost ready -- please test the Mac version!

Date2010-07-04 21:52:28 UTC

ForumBitcointalk · 原文

Laszlo 的构建版本将是我们的第一个 Mac 发布版，请大家测试！

英文原文

Laszlo's build is going to be our first Mac release so please test it!

Re: Slashdot Submission for 1.0

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Slashdot Submission for 1.0

Date2010-07-05 21:31:14 UTC

ForumBitcointalk · 原文

顺便说一句，在经历了那场短暂的 1.3 折腾之后我恢复了理智，这次发布仍然是 0.3 beta，不是 1.0。

我非常感谢大家的努力，但里面有很多问题。

我们不想把 "anonymous" 放在最前面。（我一直想改首页）

"开发者预计这将产生一种相对于能源稳定的、不受任何政府控制的货币。"——我绝对不会做这样的挑衅式断言。

它不是相对于能源稳定的。之前有过讨论。它并不与能源成本挂钩。NLS 基于能源的估算是很好的估算起点，但市场力量将越来越多地主导价格。

抱歉要泼冷水。给这个东西写面向大众的描述实在太难了，找不到任何可以类比的东西。

英文原文

BTW, I did come to my senses after that brief bout with 1.3, this release is still going to be 0.3 beta not 1.0.

I really appreciate the effort, but there are a lot of problems.

We don't want to lead with "anonymous". (I've been meaning to edit the homepage)

"The developers expect that this will result in a stable-with-respect-to-energy currency outside the reach of any government." -- I am definitely not making an such taunt or assertion.

It's not stable-with-respect-to-energy. There was a discussion on this. It's not tied to the cost of energy. NLS's estimate based on energy was a good estimated starting point, but market forces will increasingly dominate.

Sorry to be a wet blanket. Writing a description for this thing for general audiences is bloody hard. There's nothing to relate it to.

Bitcoin 0.3 released!

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleBitcoin 0.3 released!

Date2010-07-06 18:32:35 UTC

ForumBitcointalk · 原文

宣布比特币 0.3 版本发布——P2P 加密货币！比特币是一种数字货币，使用密码学和分布式网络来取代对可信中央服务器的需求。摆脱中心化管理货币的任意通胀风险！比特币的总发行量限制在 2100 万枚。币会根据节点贡献的 CPU 算力逐步释放给网络中的节点，所以你可以通过贡献闲置 CPU 时间获得其中的一份。

新功能：
- 命令行和 JSON-RPC 控制
- 包含无图形界面的守护进程版本
- 交易筛选标签页
- 哈希速度提升 20%
- Hashmeter 性能显示
- Mac OS X 版本（感谢 Laszlo）
- 德语、荷兰语和意大利语翻译（感谢 DataWraith、Xunie 和 Joozero）

请到 http://www.bitcoin.org 下载，或阅读论坛了解更多。

英文原文

Announcing version 0.3 of Bitcoin, the P2P cryptocurrency! Bitcoin is a digital currency using cryptography and a distributed network to replace the need for a trusted central server. Escape the arbitrary inflation risk of centrally managed currencies! Bitcoin's total circulation is limited to 21 million coins. The coins are gradually released to the network's nodes based on the CPU power they contribute, so you can get a share of them by contributing your idle CPU time.

Get it at http://www.bitcoin.org or read the forum to find out more.

Re: 0.3 almost ready -- please test the Mac version!

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: 0.3 almost ready -- please test the Mac version!

Date2010-07-06 19:43:18 UTC

ForumBitcointalk · 原文

0.3 已发布
http://bitcointalk.org/index.php?topic=238.msg2004#msg2004

英文原文

0.3 released
http://bitcointalk.org/index.php?topic=238.msg2004#msg2004

Re: On IRC bootstrapping

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: On IRC bootstrapping

Date2010-07-07 01:31:07 UTC

ForumBitcointalk · 原文

大家都得连同一个 IRC 服务器和频道，才能找到彼此。

引用自：Vasiliev，2010 年 6 月 25 日 11:50:15 PM（https://bitcointalk.org/index.php?topic=84.msg1785#msg1785）

可以把 Freenode 留着做备用——他的服务器不行就用 Freenode 的。

一下子把一大堆用户 rush 到 freenode 可能不太好。

备用方案是我们自己的种子系统。

irc.lfnet.org 挺老的了，uptime 很可观。我觉得没问题。

以后想拿掉 IRC 也行，但我更想慢慢来，先把我们自己的种子系统当备份测着。我很喜欢这两个系统互补冗余的特性。

英文原文

Everybody needs to connect to the same IRC server and channel so they can find each other.

Quote from: Vasiliev on June 25, 2010, 11:50:15 PM（https://bitcointalk.org/index.php?topic=84.msg1785#msg1785）You may want to leave Freenode in as a fallback server -- if his server doesn't work, use Freenode's.
It might not be good if we suddenly rushed freenode with a ton of users all at once.

The fallback is our own seed system.

irc.lfnet.org is pretty old and has impressive uptime. I think it's going to be fine.

We could take IRC out at some point if we want, but I'd rather ease into it and just test our own seed system as a backup for now, and I really like the complementary redundant attributes of the two different systems.

Re: bitcoin 0.3 win64 - broken access to APPDATA if non-latin characters in username

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: bitcoin 0.3 win64 - broken access to APPDATA if non-latin characters in username

Date2010-07-08 18:24:19 UTC

ForumBitcointalk · 原文

感谢你发现这个问题。我们在 0.2 中用的是 ANSI，0.3 切换到了 UTF-8，所以肯定和这个有关。

为了确认：如果你用含非拉丁字符的用户名登录，在还没有 appdata/Bitcoin 目录的情况下运行 Bitcoin，让它从头创建数据库，这样行不行？

英文原文

Thanks for finding that. We switched from ANSI in 0.2 to UTF-8 in version 0.3, so it must be related to that.

Just to confirm, if you log in with the non-latin character username, not having an appdata/Bitcoin directory yet, and run Bitcoin and let it create the database from scratch, does it work or not?

Re: Anonymity

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Anonymity

Date2010-07-08 19:12:00 UTC

ForumBitcointalk · 原文

很难想象互联网会被分割得密不透风。那得是一个国家故意把自己和全世界彻底隔绝。

任何能同时接触到两边的节点都会自动把区块链传过去，比如有人用拨号调制解调器或卫星电话绕过封锁。只需要一个节点就能做到。任何想继续做生意的人都会有这个动力。

如果网络被分割后又重新合并，较短分叉中那些不在较长分叉中的交易会被重新释放到交易池中，重新有资格进入未来的区块。它们的确认数会重新计算。

如果有人利用分割进行双重支付，也就是在两边花同一笔钱，那么较短分叉中的双重支付就会失败，变成 0/未确认，并且一直保持这样。

要利用分割来双重支付并不容易。如果从一边完全无法和另一边通信，你怎么把花费放在两边？如果有办法做到，那么别人很可能也在用这个办法把区块链传过去。

你通常会知道自己在较小的那一边。比如，如果你的国家把自己和世界隔绝，那么世界其他地方就是较大的那一边。如果你处在较小的一边，你应该假定什么都没被确认。

英文原文

It's hard to imagine the Internet getting segmented airtight. It would have to be a country deliberately and totally cutting itself off from the rest of the world.

Any node with access to both sides would automatically flow the block chain over, such as someone getting around the blockade with a dial-up modem or sat-phone. It would only take one node to do it. Anyone who wants to keep doing business would be motivated.

If the network is segmented and then recombines, any transactions in the shorter fork that were not also in the longer fork are released into the transaction pool again and are eligible to get into future blocks. Their number of confirmations would start over.

If anyone took advantage of the segmentation to double-spend, such that there are different spends of the same money on each side, then the double-spends in the shorter fork lose out and go to 0/unconfirmed and stay that way.

It wouldn't be easy to take advantage of the segmentation to double-spend. If it's impossible to communicate from one side to the other, how are you going to put a spend on each side? If there is a way, then probably someone else is also using it to flow the block chain over.

You would usually know whether you're in the smaller segment. For example, if your country cuts itself off from the rest of the world, the rest of the world is the larger segment. If you're in the smaller segment, you should assume nothing is confirmed.

Re: bitcoin 0.3 win64 - broken access to APPDATA if non-latin characters in username

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: bitcoin 0.3 win64 - broken access to APPDATA if non-latin characters in username

Date2010-07-09 03:01:35 UTC

ForumBitcointalk · 原文

我想我看到问题出在哪了。巧的是，我最近刚写了个有问题的那个函数的替代版本，应该能修好它。它还没有启用，但在 SVN 版本里它会在 debug.log 中打印一条调试信息，显示新目录值和旧目录值供对比。

英文原文

I think I see where the problem is. Coincidentally, I recently coded a replacement for the function in question which should fix it. It's not enabled yet, but in the SVN version it prints a debug message in debug.log showing the new directory value and old value for comparison.

Re: BTC Vulnerability? (Massive Attack against BTC system. Is it really?)

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: BTC Vulnerability? (Massive Attack against BTC system. Is it really?)

Date2010-07-09 03:28:46 UTC

ForumBitcointalk · 原文

楼主描述的那种行为叫 "cornering the market"（囤积居奇、操纵市场）。当有人试图买下全世界某种稀缺资产的全部供应时，买得越多价格涨得越高。到某个点上，价格高到他们再也买不起了。这对事先持有的人来说是好事，因为他们可以把东西以离谱的高价卖给囤积者。随着价格不断上涨，总有人还在期待更高的价格而拒绝卖出。

亨特兄弟在 1979 年试图操纵白银市场，最后把自己搞破产了，这是著名案例：
"亨特兄弟 Nelson Bunker Hunt 和 Herbert Hunt 于 20 世纪 70 年代末至 80 年代初试图操纵世界白银市场，一度持有超过全球可交割白银一半的权益。[1] 在亨特兄弟囤积白银期间，银价从 1979 年 9 月的每盎司 11 美元涨到 1980 年 1 月的接近每盎司 50 美元。[2] 两个月后，银价最终暴跌到每盎司 11 美元以下，[2] 其中大部分跌幅发生在后来被称为"银色星期四"（Silver Thursday）的那一天，原因是交易所修改了关于保证金购买大宗商品的规则。[3]"

http://en.wikipedia.org/wiki/Cornering_the_market

英文原文

What the OP described is called "cornering the market". When someone tries to buy all the world's supply of a scarce asset, the more they buy the higher the price goes. At some point, it gets too expensive for them to buy any more. It's great for the people who owned it beforehand because they get to sell it to the corner at crazy high prices. As the price keeps going up and up, some people keep holding out for yet higher prices and refuse to sell.

The Hunt brothers famously bankrupted themselves trying to corner the silver market in 1979:
"Brothers Nelson Bunker Hunt and Herbert Hunt attempted to corner the world silver markets in the late 1970s and early 1980s, at one stage holding the rights to more than half of the world's deliverable silver.[1] During Hunt's accumulation of the precious metal silver prices rose from $11 an ounce in September 1979 to nearly $50 an ounce in January 1980.[2] Silver prices ultimately collapsed to below $11 an ounce two months later,[2] much of the fall on a single day now known as Silver Thursday, due to changes made to exchange rules regarding the purchase of commodities on margin.[3]"

http://en.wikipedia.org/wiki/Cornering_the_market

Re: bitcoin 0.3 win64 - broken access to APPDATA if non-latin characters in username

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: bitcoin 0.3 win64 - broken access to APPDATA if non-latin characters in username

Date2010-07-09 15:37:05 UTC

ForumBitcointalk · 原文

我在 XP 上用一个非低位 ASCII 的账户名测试了这个问题，确认了这个 bug，然后测试了新的 GetDefaultDataDir 能修好它。这个改动是 SVN 的 revision 102。

英文原文

I tested this with a non-lower-ASCII account name on XP and confirmed the bug, then tested that the new GetDefaultDataDir fixed it. This change is revision 102 of the SVN.

Re: Security

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Security

Date2010-07-10 12:58:02 UTC

ForumBitcointalk · 原文

我会开始考虑怎么做。

目前，你可以用 -connect 来变通一下。你可以用 -connect 让它连接到局域网内的本地电脑，比如 -connect=192.168.0.100。如果你启动时不让它连接主网络，难度仍然是最初的低难度。不过如果你做了端口转发，外面的节点还是可能连进来。

用 -connect 时它还是会用 IRC，你觉得当用 -connect 指定只连特定节点时，它是不是就不该上 IRC？-connect 的主要场景是服务器集群：其中两台连到网络，其余的连到这两台。这种情况下，你不会希望用 -connect 的机器上 IRC。

void ThreadIRCSeed(void* parg)
{
if (mapArgs.count("-connect"))
return;

英文原文

I'll start thinking about how to do this.

At the moment, you can kind of use -connect. You can use -connect to make it connect to local computers on your LAN, like -connect=192.168.0.100. If you start it out blank and don't let it connect to the main network, the difficulty is still at the original low difficulty. If you've port-forwarded though, then outside nodes might still connect inward to you.

With -connect it still uses IRC, do you think it shouldn't get on IRC when you're telling it to only connect to specific nodes with -connect? The main scenario for -connect is where you have a server farm, with two connected to the network and the rest connected to the first two. In that case, you wouldn't want the -connect computers on IRC.

void ThreadIRCSeed(void* parg)
{
if (mapArgs.count("-connect"))
return;

Re: Major Meltdown

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Major Meltdown

Date2010-07-10 13:36:17 UTC

ForumBitcointalk · 原文

引用自：llama，2010 年 7 月 1 日 10:21:47 PM（https://bitcointalk.org/index.php?topic=202.msg1920#msg1920）

不过，万一签名被攻破了（比如整数分解被解决了、量子计算机？），那连"最后一个有效块"达成共识都没意义了。

对，如果是突然发生的，确实没意义。如果是慢慢发生的，我们还能过渡到更强的算法。你第一次运行升级后的软件时，它会用新的更强的签名算法重新签署你所有的钱（做法是建一笔把钱转给自己的交易，用强签名）。

英文原文

Quote from: llama on July 01, 2010, 10:21:47 PM（https://bitcointalk.org/index.php?topic=202.msg1920#msg1920）However, if something happened and the signatures were compromised (perhaps integer factorization is solved, quantum computers?), then even agreeing upon the last valid block would be worthless.
True, if it happened suddenly. If it happens gradually, we can still transition to something stronger. When you run the upgraded software for the first time, it would re-sign all your money with the new stronger signature algorithm. (by creating a transaction sending the money to yourself with the stronger sig)

Re: No blocks downloaded... why?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: No blocks downloaded... why?

Date2010-07-14 16:22:03 UTC

ForumBitcointalk · 原文

所以是它导致区块下载不下来吗？

链接："Win32 CPU Cycles vs 'Live Protection' Engines"

对 BitcoinFX 来说，Live Protection 让它拿不到用于生成币的 CPU。你说你朋友能达到 1400-1600 khash/s，所以它拿到 CPU 了。我猜 Live Protection 一定是拦截了程序的其他部分吧？

英文原文

So that was responsible for keeping blocks from downloading?

The link: "Win32 CPU Cycles vs 'Live Protection' Engines"

For BitcoinFX, Live Protection was keeping it from getting CPU for generating coins. You said your friend was getting 1400-1600 khash/s, so it was getting CPU. I guess Live Protection must have been blocking some other part of the program then?

Re: resource hog

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: resource hog

Date2010-07-14 16:29:39 UTC

ForumBitcointalk · 原文

在 Windows 里，你可以在任务管理器中选中进程，右键点击"设置优先级"。把它设为"低于标准"或"低"。不过这应该不会有区别。

如果你关掉"生成币"（Generate Coins），CPU 占用会降下来吗？如果会，就能确认它占用的所有 CPU 时间都是挖矿用的，而挖矿本来就是最低（空闲）优先级了。

也可能慢只是因为你同时运行的东西太多，内存不够了。在不同程序之间切换时，它得从磁盘把数据分页调入内存。

英文原文

In Windows, you select the process in the task manager, right click, Set Priority. Set it to BelowNormal or Low. That shouldn't make a difference though.

If you turn off Generate Coins, does the CPU usage go flat? That would confirm that all the CPU time it's taking is generate, which is idle priority already.

It could be it's slow just because you have too many things running at once and you're out of memory. When you switch from one thing to another, it has to page it in from disk.

Re: stopped prodicing coins

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: stopped prodicing coins

Date2010-07-14 17:04:02 UTC

ForumBitcointalk · 原文

谢谢你做了这个计算器。

一两天前难度翻倍了，而且这本来就是随机的，你可能会遇到长得惊人的颗粒无收期。

英文原文

Thanks for making that calculator.

The difficulty doubled a day or two ago, plus it's just random and you can have surprisingly long dry spells.

Re: Building Bitcoin 0.3

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Building Bitcoin 0.3

Date2010-07-14 17:34:50 UTC

ForumBitcointalk · 原文

它在 wxWidgets 2.8 上不行，需要 wxWidgets 2.9。不幸的是，Debian 还没有 wxWidgets 2.9 的包。

英文原文

It doesn't work with wxWidgets 2.8, it needs wxWidgets 2.9. Unfortunately, there isn't a Debian package of wxWidgets 2.9 yet.

Re: bitcoin auto-renice-ing

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: bitcoin auto-renice-ing

Date2010-07-14 17:38:31 UTC

ForumBitcointalk · 原文

Laszlo 纠正了这个问题，但很遗憾没能赶上 0.3.0。不过应该很快会有 0.3.1。

问题在于我用了 PRIO_MIN，其实应该用 PRIO_MAX 来表示最低优先级。操作系统本不该允许提升优先级，所以 PRIO_MIN 应该会让它停留在优先级 0。

英文原文

Laszlo corrected this, but unfortunately it was too late to make it into 0.3.0. There will probably be a 0.3.1 soon though.

The problem is I used PRIO_MIN, I should have used PRIO_MAX for the lowest priority. The OS isn't supposed to let you increase priority, so the PRIO_MIN ought to leave it at priority 0.

Re: Stuck on 513 blocks

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Stuck on 513 blocks

Date2010-07-14 18:02:28 UTC

ForumBitcointalk · 原文

这是我第二次看到有人报告这个 "Live Protection" 问题。

它一定是拦截了程序的网络通信。听起来它允许建立连接——这就是为什么显示有 10 个连接——但不允许在这些连接上发送或接收任何数据。

我们需要更好地了解这个问题。

能不能有人在 wiki 上写个说明，讲讲怎么关闭 Live Protection，或者怎么给它添加排除项，不管它的完整正式名称是什么。

英文原文

This is the second time I've seen this "Live Protection" problem reported.

It must be blocking the program's network communication. It sounds like it's allowing connections to be made, hence the 10 connections shown, but not allowing any data to be sent or received on them.

We need to understand this problem better.

Can someone write some instructions on the wiki explaining how to turn off or add an exclusion to Live Protection or whatever its full proper name is.

Re: Error on Ubuntu 10.04

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Error on Ubuntu 10.04

Date2010-07-14 18:25:41 UTC

ForumBitcointalk · 原文

你的电脑设置的是什么语言？是德语、荷兰语还是意大利语？是像 "nl-??" 这样的子语言吗？

它正在尝试加载一个翻译但失败了。你可以删掉 bitcoin 自带的 locale 目录，这样它就不会尝试用了。

能不能有人在 Ubuntu 上逐个测试每种语言，看看是只有一种有问题，还是三种都有问题？

英文原文

What language is your computer set to? Is it set to German, Dutch or Italian? Is it one of those sub-languages like "nl-??"?

It's trying to load a translation and failing. You could delete the locale directory that came with bitcoin so it doesn't try to use it.

Can someone test each language on Ubuntu and see if there's a problem with just one of them or maybe all three?

Re: Runaway CPU usage for 64bit BitCoin (Linux Client)

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Runaway CPU usage for 64bit BitCoin (Linux Client)

Date2010-07-14 18:45:53 UTC

ForumBitcointalk · 原文

一开始它会错误地把自己设成最低优先级，之后 generate 线程只在找到块的那一刻临时调一次优先级。找到块以后，你肯定想让它赶紧广播出去，越快越好，免得别人先找到、让你的块作废。generate 线程每隔几天才有不到一秒切到高优先级。

0.3.1 应该快发了。发布前还有几个问题要修。

引用自：knightmb，2010 年 7 月 12 日 10:39:13 PM（https://bitcointalk.org/index.php?topic=299.msg2409#msg2409）

顺带说下，另一个 GUI 问题我定位到了。

"最小化到托盘而不是任务栏"这个选项把我机器 CPU 吃满了。关掉就好了，CPU 狂飙问题解决。

好像只影响 64 位客户端，我的 32 位客户端都没事。

我在 64 位客户端上看到，它会不停地 spawn 托盘图标，直到 X server 挂掉，所以我是不是该去哪报个 bug？

有意思。我知道 Ubuntu 上最小化到托盘很 clunky，但不知道还 peg CPU。还有人能复现吗？以前 Linux 上这个功能是关掉的，后来觉得有残缺的 UI 也比完全没这功能好。我在想是不是在 Linux 上重新关掉。

英文原文

After it initially tries incorrectly to set itself to the lowest priority, the generate thread only changes its priority again temporarily when it finds a block. When you've found a block, you should want it to hurry up and broadcast it as soon a possible before someone else finds one and makes yours invalid. The generate thread only changes to higher priority for less than a second every few days.

There should be a 0.3.1 release for this soon. There are a few other issues we need to look at fixing in 0.3.1 before making a release.

Quote from: knightmb on July 12, 2010, 10:39:13 PM（https://bitcointalk.org/index.php?topic=299.msg2409#msg2409）On a side note, I've tracked down the other GUI issue.

The "minimize to tray instead of taskbar" is what was eating up all the CPU on my system. After I turned this off, the issue was resolved with Runaway CPU.

This only seems to affect the 64 bit Client, as the 32 bit Clients I have don't seem to be affected by this.

I did notice on the 64 bit Client, what happens is, it spawns multiple "tray" icons until X server finally kills over, so I guess I should submit that as a bug to somewhere?
That's interesting. I know the minimize to tray on Ubuntu is very clunky, but I didn't know it had a CPU peg problem too. Anyone else able to reproduce this problem? We had this feature disabled on Linux before, but then it seemed better to have the imperfect UI than to lose the feature entirely. I'm thinking we should disable it again on Linux.

Re: Warning this block was not received by any other nodes

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Warning this block was not received by any other nodes

Date2010-07-14 18:56:29 UTC

ForumBitcointalk · 原文

是 Microsoft Security Essentials 的 Live Protection 拦截了你和网络的通信。你有连接，这让比特币误以为自己已连接，但这些连接是静默的，因为数据被拦截了。

你需要把 bitcoin.exe 在 Live Protection 中设为排除进程。

这正在成为一个常见问题。应该有人在置顶帖里把这事写清楚。

"Warning: This block was not received by any other nodes"（警告：这个区块没有被任何其他节点接收）这条消息出现在比特币广播了一个区块、但没有任何人确认收到的时候。这个警告正是为这种情况准备的：莫名其妙地你有连接，但它们都断了，没有人能听到你。你的区块永远不会有效，因为没人收到它。

英文原文

Microsoft Security Essentials Live Protection is blocking your communication with the network. You have connections, which tricks Bitcoin into thinking it's connected, but they are silent because the data is being blocked.

You need to make bitcoin.exe an excluded process in Live Protection.

This is becoming a common problem. Someone should write this up in a pegged thread.

The message "Warning: This block was not received by any other nodes" occurs when Bitcoin broadcasts a block, but nobody confirms they received it. The warning is there just for this kind of situation, where for some reason you have connections, but they have gone dead and nobody can hear you. Your block will never become valid because nobody received it.

Re: Hash/sec Throttling for Democracy

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Hash/sec Throttling for Democracy

Date2010-07-14 20:25:06 UTC

ForumBitcointalk · 原文

引用自：knightmb，2010 年 7 月 14 日 07:17:43 PM（https://bitcointalk.org/index.php?topic=325.msg2917#msg2917）

所以如果你的电脑已经"解出"了 1% 的 block 68000……这是个常见的误解。"解了 1%"这种事不存在。你并没有在朝解出来推进。跑了 24 小时之后，你解出的概率和刚开始、和任意时刻都一样。

就像一次抛 37 枚硬币、要全是正面。每次试，成功的概率都一样。

RNG 是 OpenSSL 的安全随机数发生器。Windows 上用的是开机以来所有硬件性能计数器的全集做种子，Linux 上是 dev/random。

英文原文

Quote from: knightmb on July 14, 2010, 07:17:43 PM（https://bitcointalk.org/index.php?topic=325.msg2917#msg2917） So if your computer was only 1% towards solving block 68000 This is a common point of confusion. There's no such thing as being 1% towards solving a block. You don't make progress towards solving it. After working on it for 24 hours, your chances of solving it are equal to what your chances were at the start or at any moment.

It's like trying to flip 37 coins at once and have them all come up heads. Each time you try, your chances of success are the same.

The RNG is the OpenSSL secure random number generator. On Windows it's seeded with the complete set of all hardware performance counters since your computer started, on Linux it's dev/random.

Re: Scalability

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Scalability

Date2010-07-14 21:10:52 UTC

ForumBitcointalk · 原文

设计中规划了一种不需要完整区块链的轻量级客户端。在设计 PDF 里它叫 Simplified Payment Verification（简化支付验证）。轻量级客户端可以发送和接收交易，只是不能生成区块。轻量级客户端还没有实现，计划是等到需要时再实现。目前，大家都运行完整的网络节点。

我预计节点总数永远不会超过 10 万，很可能更少。它会达到一个均衡状态：再加入更多节点就不划算了。其余的将是轻量级客户端，可能达到几百万。

在达到均衡规模时，很多节点会是服务器集群，其中一两个网络节点通过局域网为集群的其余部分提供数据。

英文原文

The design outlines a lightweight client that does not need the full block chain. In the design PDF it's called Simplified Payment Verification. The lightweight client can send and receive transactions, it just can't generate blocks. It does not need to trust a node to verify payments, it can still verify them itself.

The lightweight client is not implemented yet, but the plan is to implement it when it's needed. For now, everyone just runs a full network node.

I anticipate there will never be more than 100K nodes, probably less. It will reach an equilibrium where it's not worth it for more nodes to join in. The rest will be lightweight clients, which could be millions.

At equilibrium size, many nodes will be server farms with one or two network nodes that feed the rest of the farm over a LAN.

Re: Runaway CPU usage for 64bit BitCoin (Linux Client)

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Runaway CPU usage for 64bit BitCoin (Linux Client)

Date2010-07-15 00:18:23 UTC

ForumBitcointalk · 原文

好吧，这个没有文档记载的开关 "-minimizetotray" 可以重新启用这个选项。

我已经把改动上传到 SVN 了。

英文原文

OK, the undocumented switch "-minimizetotray" which re-enables the option.

I uploaded the change to SVN.

Re: [Bitcoin 0.3.0] Runtime error

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: [Bitcoin 0.3.0] Runtime error

Date2010-07-15 14:05:20 UTC

ForumBitcointalk · 原文

更直接的在这里：
http://bitcointalk.org/index.php?topic=246.0

我很快会发布包含这个修复的 0.3.1 候选版本。请试一下，告诉我问题是否解决了。

英文原文

More directly, this:
http://bitcointalk.org/index.php?topic=246.0

I will be posting release candidate of 0.3.1 with this fix shortly. Please try that and let me know if it fixes the problem.

Re: Static Linux x86_64 bins for those having libcrypto troubles

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Static Linux x86_64 bins for those having libcrypto troubles

Date2010-07-15 14:33:04 UTC

ForumBitcointalk · 原文

我们连链接 glibcxx_3.4.11 都没指定，所以 gcc 一定是在背后自动链接的。应该有个编译器开关可以让它静态链接。我不确定授权方面会有什么问题。通常来说，编译器相关的东西都是可以完全再分发的。

英文原文

We don't even specify linking glibcxx_3.4.11, so gcc must automatically link it behind the scenes. There's probably a compiler switch that would tell it to static link it. I'm not sure what the licensing issues would be. Typically, compiler stuff is fully redistributable.

Re: resource hog

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: resource hog

Date2010-07-15 14:59:00 UTC

ForumBitcointalk · 原文

那所有的 CPU 时间都是挖矿线程占用的，它肯定运行在最低的优先级，也就是空闲优先级。CPU 表显示 100% 是正常的。因为是空闲优先级，即使 CPU 表显示 100%，它也不会真的拖慢其他任何东西。

英文原文

Then all the CPU time is the generate thread, which definitely runs at the lowest possible priority, idle priority. It's normal that your CPU meter is 100%. Since it's idle priority, it won't actually slow anything else down, even though the CPU meter is 100%.

Bitcoin 0.3.1 released

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleBitcoin 0.3.1 released

Date2010-07-15 17:05:54 UTC

ForumBitcointalk · 原文

这是一个修 bug 的维护版本。已经上传到 SourceForge。Mac OS X 不需要任何修复，所以我们其实不用更新它，0.3.0 仍然可用。

下载链接在 bitcoin.org 上。

改动：
- 增加了 Tiago Faria 做的葡萄牙语翻译
Windows
- 修复了用户名含非 ascii 字符时的 22DbRunRecoveryException 问题
Linux
- Laszlo 的修复：把挖矿线程降到最低优先级
- 修复了 libcrypto 链接有问题的情形
- Gavin Andresen 实现的"随窗口系统启动"选项

英文原文

This is a bugfix maintenance release. It is now uploaded to SourceForge. Mac OS X didn't need any fixes so we don't really need to update it, 0.3.0 is still good.

The download links are on bitcoin.org

Changes:
- Added Portuguese translation by Tiago Faria
Windows
- Fix for 22DbRunRecoveryException if your username has non-ascii characters in it
Linux
- Laszlo's fix for lowering generate thread to lowest priority
- Fix for if you're having trouble with libcrypto linkage
- Gavin Andresen's implementation of "start on windowing system startup" option

Re: 0.3.1 release candidate, please test

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: 0.3.1 release candidate, please test

Date2010-07-15 17:23:48 UTC

ForumBitcointalk · 原文

嗯，备份一下没坏处，定期备份也是个好习惯，但装这个之前不需要备份。

英文原文

Well, it can't hurt to do a backup and it's a good idea to backup regularly, but no, a backup is not required before installing this.

Re: 0.3.1 release candidate, please test

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: 0.3.1 release candidate, please test

Date2010-07-15 17:56:43 UTC

ForumBitcointalk · 原文

我觉得你没什么特别的问题，我觉得你的系统卡顿是因为同时运行的东西太多，内存满了之后命中了页面文件。你已经确认过，关掉挖矿后 CPU 降到 0%，所以 CPU 占用肯定全是空闲优先级的。0.3.1 里没有什么会影响这些东西的。

英文原文

I don't think you have a particular problem, I think your system is laggy because you're running a lot of things at once and hitting the pagefile because memory is full. You confirmed when you shut off generation that your CPU drops to 0%, so the CPU usage is definitely all idle priority. There's nothing in the 0.3.1 that would affect these things.

Re: Website and software translations

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Website and software translations

Date2010-07-15 18:30:22 UTC

ForumBitcointalk · 原文

引用自：aidos，2010 年 7 月 15 日 12:49:11 AM（https://bitcointalk.org/index.php?topic=151.msg3017#msg3017）

这是法语 .po 文件。顺手记了几个问题：

1. "关于"框没吃翻译，还是显示英文版，虽然软件其他地方都用了翻译字符串，.po 文件里也有"关于"框消息的翻译。设置窗口里的"应用"按钮也一样。

我得给你个更新的 .po 文件。

引用自：aidos，2010 年 7 月 15 日 12:49:11 AM（https://bitcointalk.org/index.php?topic=151.msg3017#msg3017）

2. 主窗口交易列表里，如果某笔交易的描述带变音字符（比如 "éàèç"），就显示不出来。我猜是某处没把字符串当 UTF8 处理。

OK，这肯定是哪儿有问题，我得看看，或者其他 dev 也可以看下。

引用自：aidos，2010 年 7 月 15 日 12:49:11 AM（https://bitcointalk.org/index.php?topic=151.msg3017#msg3017）

4. 关于 .po 文件：
- 有些字符串不用翻译（比如 "Bitcoin"），是不是不该包在 _（"..."）里？
- 有些不该拆开。我记得有一条交易费的消息，字符串被拆成两截、中间插手续费数值，其实直接放个 %s 就行。拆开后难翻，我得去源码里找才知道怎么回事。
- 有些字符串首尾带空格，必要性很可疑，在 PoEdit 里还容易漏看。

很多字符串在 uiproject.fbp 自动生成的代码里，那些地方动不了。我有个小程序，专门找你 .po 文件里字符串首尾空格不一致的地方，传 SVN 前我手动修好。

英文原文

Quote from: aidos on July 15, 2010, 12:49:11 AM（https://bitcointalk.org/index.php?topic=151.msg3017#msg3017）Ok here is the .po file for French. While I'm at it, I noted a couple of issues:

1. The "About" box didn't take the translation into account, it still displays the english version to me, even though the rest of the software is using the translated strings, and the .po file contains the translation string of the "About" box message. Same problem with the "Apply" button in the Settings window.
I need to give an updated .po file.

Quote from: aidos on July 15, 2010, 12:49:11 AM（https://bitcointalk.org/index.php?topic=151.msg3017#msg3017）2. If an transaction's description in the list of transaction in the main window contains a diacritical character (such as "éàèç"), it's not displayed. I suppose the string is not being properly handled as UTF8 somewhere.
OK, this must be a problem somewhere, I'll have to take a look at it or one of the other devs can.

Quote from: aidos on July 15, 2010, 12:49:11 AM（https://bitcointalk.org/index.php?topic=151.msg3017#msg3017）4. About the .po file :
- There are a few strings in the .po file that don't needs translation (ie: "Bitcoin"). Maybe those shouldn't be inside _("...") ?
- Others shouldn't be split. I can remember one message about transaction fee where the string is split in two to insert the fee value, where you could simply have put a %s. It makes the message harder to translate as I had to go in the source to find exactly what was going on.
- Some strings have whitespace at the end or start, which necessity is very debatable, and it's easy to miss in PoEdit.
Many of the strings are in code automatically generated from uiproject.fbp where nothing can be done about these things. I have a program I use to find all the spacing inconsistencies at the beginning and ending of strings in your .po file and manually fix them up before I upload them to SVN.

Re: Website and software translations

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Website and software translations

Date2010-07-15 18:37:13 UTC

ForumBitcointalk · 原文

我上传了更新后的 0.3.1 版 bitcoin.po，就附在这条消息里：
http://bitcointalk.org/index.php?topic=151.msg1259#msg1259

如果你要开始一个新的翻译，请用它。

如果你已经有 po 文件，poedit 可以更新它。
- 从开发区发布的 0.3.1 候选版本里拿到 src 目录，任何版本都行：
http://bitcointalk.org/index.php?topic=383.0
- 在 src 下建一个子目录：locale/??/LC_MESSAGES
（?? 可以是任何东西，"en" 或你语言的两字母代码）
- 把你的 .po 文件放进去
- 用 poedit 打开它
- 在 poedit 里，目录 -> 从源更新（Catalog->Update from sources）

关键是：放源文件的 src 目录必须在 .po 文件的上三层目录。

英文原文

I uploaded an updated bitcoin.po for 0.3.1 attached to this message:
http://bitcointalk.org/index.php?topic=151.msg1259#msg1259

please use it if you're starting a new translation.

If you already have a po file, poedit can update it.
- Get the src directory from the 0.3.1 release candidate posted in the development forum, any version will do:
http://bitcointalk.org/index.php?topic=383.0
- Make a subdirectory under src: locale/??/LC_MESSAGES
(?? could be anything really, "en" or your language 2-letter code)
- Put your .po file there
- Open it with poedit
- In poedit, Catalog->Update from sources

The key is that the src directory with the sourcefiles needs to be 3 directories up from the .po file.

Re: Website and software translations

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Website and software translations

Date2010-07-15 18:43:54 UTC

ForumBitcointalk · 原文

引用自：SmokeTooMuch，2010 年 7 月 13 日 06:55:55 PM（https://bitcointalk.org/index.php?topic=151.msg2619#msg2619）

建议删掉首页底部的下载链接。

你看，英文页的链接指向新的 0.3 版，但其他语言页还是 0.2 旧版的链接。

反正右边已经有个当前版本的下载框了，干嘛不把翻译页的链接删了。

我更新到 0.3.0 了。

我有点想把其他语言的下载链接删掉、只留英文的。

0.3.1 很快又要更新了。也许该找个人专门管翻译版 drupal 页面的更新。

英文原文

Quote from: SmokeTooMuch on July 13, 2010, 06:55:55 PM（https://bitcointalk.org/index.php?topic=151.msg2619#msg2619）I recommend to remove the download links at the bottom of the main page.
As you can see the links on the English page points to the new 0.3 release, but the other languages only contain links for the old 0.2 version.
There's a download box with the current releases on the right anyway, so why not remove the links from the translated pages.
I updated them to 0.3.0.

I am tempted to remove the download links from the other languages and only keep it on English.

They will need to be updated for 0.3.1 soon. Perhaps there's a way for someone to manage the updating of the translated drupal pages.

Re: Website and software translations

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Website and software translations

Date2010-07-15 19:12:14 UTC

ForumBitcointalk · 原文

感谢西班牙语和法语翻译！编辑和更新后的 .po 文件附在这里了。

我已经把它们上传到 SVN。

英文原文

Thanks for the Spanish and French translations! The edited and updated .po files are attached.

I uploaded these to the SVN.

Re: 0.3.1 release candidate, please test

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: 0.3.1 release candidate, please test

Date2010-07-15 21:40:34 UTC

ForumBitcointalk · 原文

引用自：knightmb，2010 年 7 月 15 日 07:37:10 PM（https://bitcointalk.org/index.php?topic=383.msg3269#msg3269）

Windows 上，生成币的优先级仍然是普通。如果开着生成币模式跑比特币，再开个吃满 CPU 的东西（比如 CPU hog：http://www.microtask.ca/cpuhog.html），会看到比特币和 CPU hog 各占 50%，而不是 CPU hog 占满、比特币只在空闲/低优先级跑。khash/s 也掉了一半，进一步说明线程没跑在低于普通的优先级。

我没复现出来。我是双核，跑了两个 memory hog。任务管理器显示比特币占 0% CPU。khash/sec 表卡住不动，因为它抢不到 CPU 来更新。

你是双核吗？确定你跑的不是单核 hog？

英文原文

Quote from: knightmb on July 15, 2010, 07:37:10 PM（https://bitcointalk.org/index.php?topic=383.msg3269#msg3269）On Windows, the priority of the Coin Generation is still net for normal. If you run BitCoin in Generate Coin mode, then load up something to eat up all the CPU (like CPU hog for example: http://www.microtask.ca/cpuhog.html) you'll see that both BitCoin and CPU hog share the CPU 50/50 instead of CPU Hog taking all the CPU and BitCoin running only on idle/low process. The khash/s is also reduced in half, so further evidence that the threads are not running in a lower than normal prioirty.
I was not able to reproduce this. I have dual-proc, so I ran two memory hogs. Bitcoin got 0% of CPU according to the task manager. The khash/sec meter stayed stuck because it couldn't get any CPU to update it.

Do you have dual-proc? Are you sure you weren't running a single processor hog?

Re: 0.3.1 release candidate, please test

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: 0.3.1 release candidate, please test

Date2010-07-15 22:07:35 UTC

ForumBitcointalk · 原文

引用自：knightmb，2010 年 7 月 15 日 08:15:46 PM（https://bitcointalk.org/index.php?topic=383.msg3274#msg3274）

Linux 客户端（64 位）上，"关闭时最小化"还是会最小化到托盘（不停 spawn 托盘图标，过一会儿 X server 就 hang 了）。

我在首帖更新了 rc2 的 linux 链接，修了这个。请确认下你那边好了没。谢谢！

http://www.bitcoin.org/download/bitcoin-0.3.1.rc2-linux.tar.gz

英文原文

Quote from: knightmb on July 15, 2010, 08:15:46 PM（https://bitcointalk.org/index.php?topic=383.msg3274#msg3274）On the Linux client (64 bit), the "minimize on close" will still minimize to tray (causing X server hang after a short while by spawning multiple tray icons).
I updated the first post with a link to rc2 for linux with the fix for this. Please check that this is fixed for you. Thanks!

http://www.bitcoin.org/download/bitcoin-0.3.1.rc2-linux.tar.gz

Re: 0.3.1 release candidate, please test

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: 0.3.1 release candidate, please test

Date2010-07-15 22:10:19 UTC

ForumBitcointalk · 原文

引用自：db，2010 年 7 月 15 日 08:39:08 PM（https://bitcointalk.org/index.php?topic=383.msg3278#msg3278）

bincoind help 里 listreceivedbyaddress 和 getreceivedbyaddress 命令重复了。（0.3.0 也一样。）

是个 bug。下个版本修。

英文原文

Quote from: db on July 15, 2010, 08:39:08 PM（https://bitcointalk.org/index.php?topic=383.msg3278#msg3278）The listreceivedbyaddress and getreceivedbyaddress commands are duplicated in bincoind help. (Same in 0.3.0.)
Yes a bug. It'll have to be fixed in the next version.

Re: "SetIcons(): icon bundle doesn't contain any suitable icon"

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: "SetIcons(): icon bundle doesn't contain any suitable icon"

Date2010-07-15 22:18:26 UTC

ForumBitcointalk · 原文

奇怪，我们之前居然从没听说过这个问题。

也许你是第一个在 Vista 上运行它的人。

我猜这和你的显示颜色深度设置有关。比如 8 位、16 位、24 位、32 位，你的是哪个？你的显卡、显示设置有没有什么特别的，或者你是在平板电脑或手机之类的设备上运行吗？

英文原文

That's surprising that we've never heard of that before now.

Maybe you're the first person to ever run it on Vista

I have to guess it has something to do with your display color depth selection. e.g. 8-bit, 16-bit, 24-bit, 32-bit, what is it? Do you have a weird video card, display setup or running it on a tablet or mobile or something?

Re: Runaway CPU usage for 64bit BitCoin (Linux Client)

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Runaway CPU usage for 64bit BitCoin (Linux Client)

Date2010-07-15 22:22:30 UTC

ForumBitcointalk · 原文

Linux 线程优先级问题的修复已包含在 0.3.1 候选版本里，见：
http://bitcointalk.org/index.php?topic=383.msg3198#msg3198

英文原文

The fix for the thread priority level on linux is available in the 0.3.1 release candidate here:
http://bitcointalk.org/index.php?topic=383.msg3198#msg3198

Re: 0.3.1 release candidate, please test

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: 0.3.1 release candidate, please test

Date2010-07-15 23:23:04 UTC

ForumBitcointalk · 原文

引用自：RHoning，2010 年 7 月 15 日 10:29:28 PM（https://bitcointalk.org/index.php?topic=383.msg3311#msg3311）

我两个都没看到，不过它确实进了"启动"文件夹。这也太 Windows 95 了（开玩笑……微软这块搞得一团糟，一点都不好笑）。我推荐用注册表，理由很多，包括大多数软件都把开机启动放那儿，虽然我个人觉得启动文件夹更顺眼，Windows 软件本来就该这样。

两种都行。启动文件夹的好处是用户能看见，万一他已经把比特币目录连卸载程序一起删了，还能用常规 UI 手动删掉（不用 regedit）。比特币不会你删了它还拼命加回来。

OpenOffice 也是把快捷方式放启动文件夹的例子。

英文原文

Quote from: RHorning on July 15, 2010, 10:29:28 PM（https://bitcointalk.org/index.php?topic=383.msg3311#msg3311）I don't see either happening, although it did get put into the "Startup" folder. That is so Windows 95ish (just kidding..... Microsoft has so screwed this up that it isn't even funny). I would recommend the registry settings for a number of reasons including the fact that most software puts the startup in that location, even though I personally find the startup folder to be more attractive and how most software on Windows should behave.
It could go either way. The Startup folder has the advantage that the end user can see it and manually remove it with the regular UI (not regedit) if they already blew away the Bitcoin directory and its uninstaller. Bitcoin will not relentlessly keep re-adding it if you delete it manually.

OpenOffice is another example of something that puts its link in the Startup folder.

Re: "SetIcons(): icon bundle doesn't contain any suitable icon"

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: "SetIcons(): icon bundle doesn't contain any suitable icon"

Date2010-07-15 23:41:23 UTC

ForumBitcointalk · 原文

引用自：bdonlan 于 July 15, 2010, 11:27:14 PM（https://bitcointalk.org/index.php?topic=391.msg3320#msg3320）
in 120DPI mode.

什么是"120DPI 模式"？这是某处实际存在的设置吗？听起来是个足够冷门的候选项。我猜它需要两倍分辨率的图标来填充左上角图标的尺寸。目前只提供了一种尺寸。

英文原文

Quote from: bdonlan on July 15, 2010, 11:27:14 PM（https://bitcointalk.org/index.php?topic=391.msg3320#msg3320）
in 120DPI mode.

What is "120DPI mode"? Is that an actual setting somewhere? Sounds like an obscure enough candidate. I suppose it needs twice the resolution icon to fill the size of the upper left corner icon. Only one size is provided.

Re: 0.3.1 release candidate, please test

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: 0.3.1 release candidate, please test

Date2010-07-16 00:44:32 UTC

ForumBitcointalk · 原文

用未公开的开关 -minimizetotray 运行它，选项菜单里就会出现该选项。

我不知道怎么修。这是 wxWidgets 或 GTK 或 Gnome 深处的问题。

英文原文

Run it with the undocumented switch -minimizetotray and the option is available in the options menu.

I don't know how to fix it. It's something wrong deep inside wxWidgets or GTK or Gnome.

Re: Donations to freebitcoins.appspot.com needed!

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Donations to freebitcoins.appspot.com needed!

Date2010-07-16 02:02:07 UTC

ForumBitcointalk · 原文

5 BTC 现在看起来有点多，也许正常数额应该是 1 或 2 BTC。

这是项重要服务，这样即便挖矿太难，新用户至少也能得到一些。

英文原文

5 BTC seems like a lot these days, maybe the normal amount should be 1 or 2 BTC.

This is an important service so new users can at least get something if generating is too hard.

Re: "SetIcons(): icon bundle doesn't contain any suitable icon"

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: "SetIcons(): icon bundle doesn't contain any suitable icon"

Date2010-07-16 02:43:29 UTC

ForumBitcointalk · 原文

那应该就是原因了。

它一定是在找更大的图标，比如 20x20 的，但我们没有。

英文原文

That must be it then.

It must be looking for a larger icon like 20x20 but we don't have one.

Re: Proof-of-work difficulty increasing

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Proof-of-work difficulty increasing

Date2010-07-16 14:46:12 UTC

ForumBitcointalk · 原文

目前工作量证明难度是 45.38。（见 http://www.alloscomp.com/bitcoin/calculator.php）

几小时后它又要上调了。距离上次上调才 3-4 天，所以我预计这次会按最大值 4 倍、或接近最大值上调。这样难度会达到 181.54。

两次调整之间的目标间隔是 14 天，14/3.5 天 = 4.0 倍上调。

英文原文

The proof-of-work difficulty is currently 45.38. (see http://www.alloscomp.com/bitcoin/calculator.php)

It's about to increase again in a few hours. It's only been 3-4 days since the last increase, so I expect it will increase by the max of 4 times, or very nearly the max. That would put it at 181.54.

The target time between adjustments is 14 days, 14/3.5 days = 4.0 times increase.

Re: Assertion Failure - Ubuntu Lucid

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Assertion Failure - Ubuntu Lucid

Date2010-07-16 14:52:04 UTC

ForumBitcointalk · 原文

这是我第一次见到这个错误。

你有多少个区块？（状态栏里）

你应该把 blk*.dat 文件（在 ~/.bitcoin 里）移到另一个目录，让它重新开始下载区块链。如果不介意的话，能不能把旧的 blk*.dat 文件保留一段时间，以防我需要查看？

英文原文

That's the first time I've seen this error.

How many blocks do you have? (in the status bar)

You should move your blk*.dat files (in ~/.bitcoin) to another directory and let it start over downloading the block chain again. If you don't mind, could you keep the old blk*.dat files for a little while in case I need to look at them?

Re: Fedora 13 libcrypto

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Fedora 13 libcrypto

Date2010-07-16 14:55:23 UTC

ForumBitcointalk · 原文

请试试 0.3.1 候选发布版，它至少应该能解决 libcrypto 依赖问题：

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

告诉我是否有效。

英文原文

Please try the 0.3.1 release candidate, it should at least resolve the libcrypto dependency:

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

Let me know if that works.

Re: Resending transaction

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Resending transaction

Date2010-07-16 15:01:33 UTC

ForumBitcointalk · 原文

如果比特币收到不包含你交易的新区块，会自动重播你的交易。重播可能需要大约一小时。不过它很执着，会一直不停地向网络广播，直到你的交易进入一个区块为止。

英文原文

Bitcoin automatically rebroadcasts your transactions if it receives new blocks that don't contain them. It may take about an hour to get rebroadcasted. It is relentless though. It will keep nagging the network forever until your transaction gets into a block.

Re: 0.3.1 release candidate, please test

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: 0.3.1 release candidate, please test

Date2010-07-16 15:09:59 UTC

ForumBitcointalk · 原文

因为不同系统缺少各种依赖。能静态链接的就直接静态链接，更省事。体积增加得不多。

英文原文

Because of all the dependencies that different systems don't have. It's easier to just static link what we can. It doesn't increase the size by very much.

Re: Source code documentation

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Source code documentation

Date2010-07-16 15:37:00 UTC

ForumBitcointalk · 原文

我喜欢在对外 API 的库里这么做，但你大概能从代码看出来，我不喜欢给内部函数加这个。每个函数都加个大大的强制性注释头会把代码撑得很散，让你在创建一个小函数时犹豫——注释头比函数本身还大。维护起来也麻烦，函数一改，注释头也得跟着改。我喜欢保持代码紧凑，这样一屏能看到更多代码。

现在这个阶段再去加，写出来的也只是看函数就能看明白的东西。

我们现有的对外 API 在 rpc.cpp 里，用法文档都在帮助字符串里。

抱歉扫大家的兴。

英文原文

I like that in libraries for the external API's, but you can probably tell from the code that I'm not a fan of it for interior functions. Big obligatory comment headers for each function space out the code and make you hesitate about creating a small little function where the comment header would be bigger than the function. They're some trouble for maintenance, as changes to the function then require duplicate changes in the comment header. I like to keep code compact so you can see more code on the screen at once.

To add them now at this point, what would be written would just be what's obvious from looking at the function.

The external API we have, in rpc.cpp, the usage documentation is in the help string.

Sorry to be a wet blanket.

Re: Hash() function not secure

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Hash() function not secure

Date2010-07-16 16:13:53 UTC

ForumBitcointalk · 原文

SHA256 不像从 128 位到 160 位那一步。

打个比方，它更像从 32 位到 64 位地址空间那一步。16 位计算机很快就用完了地址空间，32 位计算机在 4GB 处用完了地址空间，但这不意味着 64 位地址空间很快就会用完。

在我们有生之年，SHA256 不会被摩尔定律带来的算力提升攻破。如果它会被攻破，那一定是某种突破性的破解方法。一种能把 SHA256 彻底打垮、拉进可计算范围的攻击，很大概率也能把 SHA512 打垮。

如果我们看到 SHA256 的弱点是逐渐显现的，我们可以在某个区块高度之后切换到新的哈希函数。每个人都必须在那个区块高度之前升级软件。新软件会保存所有旧区块的一个新哈希，以确保它们不会被另一个具有相同旧哈希的区块替换。

英文原文

SHA256 is not like the step from 128 bit to 160 bit.

To use an analogy, it's more like the step from 32-bit to 64-bit address space. We quickly ran out of address space with 16-bit computers, we ran out of address space with 32-bit computers at 4GB, that doesn't mean we're going to run out again with 64-bit anytime soon.

SHA256 is not going to be broken by Moore's law computational improvements in our lifetimes. If it's going to get broken, it'll be by some breakthrough cracking method. An attack that could so thoroughly vanquish SHA256 to bring it within computationally tractable range has a good chance of clobbering SHA512 too.

If we see a weakness in SHA256 coming gradually, we can transition to a new hash function after a certain block number. Everyone would have to upgrade their software by that block number. The new software would keep a new hash of all the old blocks to make sure they're not replaced with another block with the same old hash.

Re: Request: expected bitcoins per day display

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Request: expected bitcoins per day display

Date2010-07-16 16:47:14 UTC

ForumBitcointalk · 原文

很多生意都这样。对汽车销售员来说，下一位顾客什么时候进门？

关于楼主的问题，这是个好功能，但问题是，我们该怎么措辞，才能让人们不会指望在那个具体时间之后一定有所收获？"它说 7 天，我等了一个多星期什么都没得到！"写成"大约""平均"也没用，他们还是会这么想。除非我们能想到别的地方放，否则它不能是完整的一句话，但放哪儿呢？有什么建议？

难度几分钟前翻了两番，到了 181.54。现在挖到一个区块通常要大约一周时间。

英文原文

Many businesses are like that. For a car salesman, when will the next customer walk in the door?

On the OP's question, it's a good feature, but the question is, how would we word it so people don't expect to get something after that specific amount of time? "it said 7 days and I waited more than a week and didn't get anything!" Approx, average, but still they're going to think that way. It can't be a whole sentence, unless we think of somewhere else to put it, but where would that be? Suggestions?

The difficulty quadrupled a few minutes ago to 181.54. It's going to take typically about a week to generate now.

Re: Proof-of-work difficulty increasing

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Proof-of-work difficulty increasing

Date2010-07-16 16:56:54 UTC

ForumBitcointalk · 原文

几分钟前难度调整到了 181.54。现在挖到一个区块通常需要大约一周时间。

难度可以下调也可以上调。

现在网络应该接近每小时生成 6 个区块了。

英文原文

It adjusted to 181.54 a few minutes ago. Typical time to get a block is about a week now.

The difficulty can adjust down as well as up.

The network should be generating close to 6 blocks per hour now.

Re: Source code documentation

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Source code documentation

Date2010-07-16 17:15:47 UTC

ForumBitcointalk · 原文

在 init.cpp 里。

这是个 wxWidgets 应用，所以它没有 main() 函数。不过快了，因为我马上就能让 bitcoind 不依赖 wxBase 构建了。（会在 init.cpp 里）

抱歉我选了 "main.cpp" 这个文件名，另一个可能的名字是 "core.cpp"。现在改已经太晚了。我还是更喜欢 main.cpp。

我们仍然非常需要一份示例代码，展示在典型网店网站上搭建基本账户系统时使用 JSON-RPC 函数的推荐方式，比如用 getreceivedbylabel、以用户名作为标签，某个账户的已存比特币地址一旦被用过就换成新的比特币地址。我在论坛某处贴过一段示例代码片段。（搜索 getreceivedbylabel 或 getnewaddress）示例代码可以是一个简简单单的银行网站，能存入和发送付款。

英文原文

It's in init.cpp.

It's a wxWidgets app, so it doesn't have a main() function. It may in a little while, since I'm pretty close to making bitcoind build w/o wxBase. (it'll be in init.cpp)

Sorry about my choice of the filename "main.cpp", another possible name would have been "core.cpp". It's much too late to change. I still prefer main.cpp.

We're still in great need of sample code showing the recommended way to use the JSON-RPC functions, like for a basic account system on a typical storefront website. Using getreceivedbylabel using the username as the label, changing to a new bitcoin address once the stored one for that account gets used. I posted a sample code fragment on the forum somewhere. (search on getreceivedbylabel or getnewaddress) The sample code could be a plain vanilla bank site where you can deposit and send payments.

Re: 0.3.1 release candidate, please test

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: 0.3.1 release candidate, please test

Date2010-07-16 17:26:17 UTC

ForumBitcointalk · 原文

说得对。如果你要让超过 8 个局域网节点连到同一个网关节点，那你最好把网关节点设置成能接受传入连接。否则，当网关节点的连接数达到 8 个或更多时，它就不会再尝试增加出站连接。随着你连接的外部节点来来去去，它不会新建出站连接来替代。你能接受传入连接就没问题，那样会有很多人连到你。

英文原文

Good point. If you're going to have more than 8 LAN nodes connect to one gateway node, then you'd better have the gateway node set up so it can receive incoming connections. Otherwise, while the gateway node has 8 or more connections, it will not try to add any more outbound connections. As the outside nodes you're connected to come and go, it doesn't make new outbound connections to replace them. You'll be fine if you can accept incoming connections, then there will be plenty of others connecting to you.

Re: Proof-of-work difficulty increasing

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Proof-of-work difficulty increasing

Date2010-07-16 17:29:28 UTC

ForumBitcointalk · 原文

对，大约 20 小时。（120 个确认 / 每小时 6 个区块 = 20 小时）这是你挖到币之后、能花它之前的正常时长。你会在那之前很久就知道自己挖到了一个。

英文原文

Yes, about 20 hours. (120 conf / 6 blocks per hour = 20 hours) That's the normal length of time before you can spend it. You know long before that that you won one.

Re: bitcoin trademark?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: bitcoin trademark?

Date2010-07-16 17:47:05 UTC

ForumBitcointalk · 原文

不，完全没有关系。

英文原文

No, not related at all.

Re: The dollar cost of bitmining energy

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: The dollar cost of bitmining energy

Date2010-07-16 17:58:44 UTC

ForumBitcointalk · 原文

不错的图表。

难度刚刚上调了 4 倍，所以你现在的成本是每 BTC 0.02 美元。

英文原文

Neat chart.

Difficulty just increased by 4 times, so now your cost is US$0.02/BTC.

Re: Website integration for bitcoin

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Website integration for bitcoin

Date2010-07-16 18:23:04 UTC

ForumBitcointalk · 原文

我一直在鼓励有人写一份示例 Python 代码并发布，展示做典型记账工作时的推荐做法，但一直没人写。如果你不用像现在这样重复造轮子就好了。搜索 getnewaddress，应该能找到一个我给过一小段示例伪代码的帖子。

英文原文

I've been trying to encourage someone to write and release some sample Python code showing the recommended way to do the typical accounting stuff, but to no avail. It would be nice if you didn't have to re-invent the wheel like you're doing here. Search on getnewaddress and you should find a thread where I gave a small fragment of sample pseudocode.

Re: Proof-of-work difficulty increasing

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Proof-of-work difficulty increasing

Date2010-07-16 18:43:51 UTC

ForumBitcointalk · 原文

对，难度调整的目标是让整个网络平均每小时生成 6 个区块。你的区块成熟时间永远在 20 小时左右。

最近这次调整又让我们回到了接近每小时 6 个区块。

有个网站可以看到区块间隔时间，自从 68545 号区块以来，更像是每 10 分钟一个区块：
http://nullvoid.org/bitcoin/statistix.php

英文原文

Right, the difficulty adjustment is trying to keep it so the network as a whole generates an average of 6 blocks per hour. The time for your block to mature will always be around 20 hours.

The recent adjustment put us back to close to 6 blocks per hour again.

There's a site where you can see the time between blocks, and since block 68545, it's been more like 10 minutes per block:
http://nullvoid.org/bitcoin/statistix.php

Sample account system using JSON-RPC needed

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleSample account system using JSON-RPC needed

Date2010-07-16 19:45:10 UTC

ForumBitcointalk · 原文

我们需要有人写一份示例代码，最好是 Python 或 Java，展示用 JSON-RPC 接口搭建账户系统的推荐方式。大多数卖东西的网站都会需要这个。一直关注 JSON-RPC 相关帖子的人应该知道它大概该怎么写。

当用户登录自己的账户时，你向他展示一个可以发送比特币来充值的比特币地址。在展示之前，你先检查它是否被用过，如果用过就换成新的（getnewaddress <username>）。你的数据库里每个账户只需要保存最新的比特币地址。（我在之前某个帖子里贴过这段的示例代码片段，搜索 getnewaddress）

你用 getreceivedbylabel <username>，以用户名作为标签，来获取账户的"贷方"金额。你需要在数据库里保存一个"借方"金额。账户当前余额 =（贷方 - 借方）。当用户花钱时，你增加借方。

如果你要求大于 0 个确认，最好同时显示当前余额（0 个确认）和可用余额（1 个或更多确认），这样他们能立刻看到付款已被确认。不是所有网站都需要等确认，所以当前余额和可用余额的双显示应该是可选的。大多数卖数字商品的网站接受 0 确认没问题。

一个不错的示例应用是简单的银行网站，包含上面这些功能，外加向比特币地址发送付款的选项。示例代码应该尽可能简单，只保留让它成为一个能跑起来的网站的最少额外内容。

vekja.net 就是这类网站的一个例子。

英文原文

We need someone to write sample code, preferably Python or Java, showing the recommended way to use the JSON-RPC interface to create an account system. Most sites that sell things will need something like this. Someone who's kept up on the JSON-RPC threads here should have some idea how it should work.

When a user is logged in to their account, you show the bitcoin address they can send to to add funds. Before showing it, you check if it's been used, if it has then you replace it with a new one (getnewaddress <username>). You only need to keep the latest bitcoin address for the account in your database. (I posted a sample code fragment for this in an earlier thread somewhere, search on getnewaddress)

You use getreceivedbylabel <username> with the username as the label to get the "credit" amount of the account. You need to keep a "debit" amount in your database. The current balance of the account is (credit - debit). When the user spends money, you increase debit.

If you're requiring more than 0 confirmations, it's nice if you show the current balance (0 confirmations) and the available balance (1 or more confirmations), so they can immediately see that their payment is acknowledged. Not all sites need to wait for confirmations, so the dual current & available should be optional. Most sites selling digital goods are fine to accept 0 confirmations.

A nice sample app for this would be a simple bank site, which would have the above, plus the option to send a payment to a bitcoin address. The sample code should be the simplest possible with the minimum extra stuff to make it a working site.

vekja.net is an example of a site like this.

Re: Bitcoin 0.3.1 released

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Bitcoin 0.3.1 released

Date2010-07-16 21:06:57 UTC

ForumBitcointalk · 原文

我把 windows 0.3.1 rc1 和 linux 0.3.1 rc2 上传到了 SourceForge，并更新了首页上的链接。

除非你遇到了首帖里列出的问题，否则不需要更新到 0.3.1。如果 0.3.0 已经跑得好好的，就继续用 0.3.0。

英文原文

I uploaded windows 0.3.1 rc1 and linux 0.3.1 rc2 to SourceForge and updated the links on the homepage.

You don't need to update to 0.3.1 unless you had one of the problems listed in the first post. If you've got it working already, stay with 0.3.0.

Re: A New Currency System for the World

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: A New Currency System for the World

Date2010-07-16 22:20:09 UTC

ForumBitcointalk · 原文

引用自：hugolp 于 May 08, 2010, 10:38:51 AM（https://bitcointalk.org/index.php?topic=128.msg1082#msg1082）
我一运行 bitcoin 它就变得非常卡，几乎没法用。我一停掉 bitcoin 就一切正常。系统是 Ubuntu desktop 10.04 amd64，用 ia32libs 和 bitcoin 0.20 压缩包里的二进制文件。

0.3.1 修复了这个问题，把挖矿线程设成了最低优先级。下载链接已经在首页了。

英文原文

Quote from: hugolp on May 08, 2010, 10:38:51 AM（https://bitcointalk.org/index.php?topic=128.msg1082#msg1082）
When I run bitcoin it becomes very sluggish, almost unusable. When I stop bitcoin everything goes ok again. Its running Ubuntu desktop 10.04 amd64 using ia32libs and the binary in bitcoin 0.20 tarball.

0.3.1 fixes that, sets the generate threads to the lowest priority. Download links are on the homepage now.

Re: BUG Report: Rounding glitch

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: BUG Report: Rounding glitch

Date2010-07-17 16:06:12 UTC

ForumBitcointalk · 原文

这一定是 getinfo 把结果转成浮点数返回 JSON-RPC 结果时的舍入误差。唯一用浮点数表示金额的地方，就是在 JSON-RPC 里返回值。

1.139999999999 比比特币内部能表示的精度更长。

内部它只能是：
1.13999999 或
1.14000000

1.139999999999 离 1.14000000 比离 1.13999999 近得多，所以它一定是 1.14000000。

代码是这样的：
(double)GetBalance() / (double)COIN.

（我一时想不出简单的修复办法）

英文原文

It must be a rounding error when getinfo converts to floating point to return the JSON-RPC result. The only place where it uses floating point to represent money is returning a value in JSON-RPC.

1.139999999999 is longer than bitcoin can internally represent.

internally, it could only be:
1.13999999 or
1.14000000

1.139999999999 is much much closer to 1.14000000 than 1.13999999, so it must be 1.14000000.

The code is this:
(double)GetBalance() / (double)COIN.

(I can't think of an easy way to fix it at the moment)

Re: Privacy versus Safety: handling change

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Privacy versus Safety: handling change

Date2010-07-17 16:27:39 UTC

ForumBitcointalk · 原文

我们应该在钱包里预先排好一批预制地址，需要新地址时就用。地址不大，多备一些也无妨。这样也能更普遍地覆盖这种情况：有人备份之后，又申请了新地址并收到了一笔大额付款。也许应该用分开的队列，一种地址需求就不会把另一种的备货耗光。

地址会在正常位置创建和存储，但同时也会列在一个单独的"已创建但从未使用"地址列表里。当有人申请地址时，就把从未使用队列最前面的地址发出去，同时再创建一个新地址加到队尾。

区块加载代码里有某种重扫描，是用来修复有人复制 wallet.dat 的情况的。我需要确认这个重扫描能处理这种情况：钱包恢复后，已经收到的区块里收到过的付款被遗忘了，需要重新发现。

英文原文

We should queue up a supply of pre-made addresses in the wallet to use when a new address is needed. They aren't very big, so it wouldn't hurt to have a lot of them. This would more generally cover the case also where someone backs up, then requests a new address and receives a big payment with it. Maybe there should be separate queues so one type of demand on addresses doesn't deplete it for the others.

The addresses would be created and stored in the normal place, but also listed on a separate list of created-but-never-used addresses. When an address is requested, the address at the front of the never-used queue is handed out, and a new address is created and added to the back.

There's some kind of rescan in the block loading code that was made to repair the case where someone copied their wallet.dat. I would need to check that the rescan handles the case of rediscovering received payments in blocks that were already received, but are forgotten because the wallet was restored.

Re: Nenolod, the guy that wants to prove Bitcoin doesn't work.

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Nenolod, the guy that wants to prove Bitcoin doesn't work.

Date2010-07-17 16:56:06 UTC

ForumBitcointalk · 原文

0.3.2 加入了一些安全保护措施，把到此为止的区块链锁定，并能在有人拿到 50% 算力时多少限制一下破坏。

但如果有人拥有 50% 以上的 CPU 算力且怀有恶意，他就能证明设计文档里已经写明的东西。

英文原文

0.3.2 has some security safeguards to lock in the block chain up to this point and limit the damage a little if someone gets 50%.

But if someone has 50%+ of the CPU power and malicious intent, they can prove what it already says in the design document.

Bitcoin 0.3.2 released

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleBitcoin 0.3.2 released

Date2010-07-17 21:35:51 UTC

ForumBitcointalk · 原文

下载链接已在 bitcoin.org 上线。每个人都应该升级到这个版本。

- 加了一道简单的安全保护，把到此为止的区块链锁定。
- 减少了 addr 消息以节省带宽，现在可连接的节点已经够多了。
- milkiway 贡献的西班牙语翻译。
- aidos 贡献的法语翻译。

这道安全保护的作用是：即使有人拥有了超过 50% 的网络 CPU 算力，他也无法回去重做昨天之前的区块链。（如果你装了这个更新）

我大概以后每个版本都会放一个检查点。一旦软件已经确定了被广泛接受的区块链，就没必要再给几个月之后的不受欢迎的非零修订可能性留门了。

英文原文

Download links available now on bitcoin.org. Everyone should upgrade to this version.

- Added a simple security safeguard that locks-in the block chain up to this point.
- Reduced addr messages to save bandwidth now that there are plenty of nodes to connect to.
- Spanish translation by milkiway.
- French translation by aidos.

The security safeguard makes it so even if someone does have more than 50% of the network's CPU power, they can't try to go back and redo the block chain before yesterday. (if you have this update)

I'll probably put a checkpoint in each version from now on. Once the software has settled what the widely accepted block chain is, there's no point in leaving open the unwanted non-zero possibility of revision months later.

Re: Bitcoin snack machine (fast transaction problem)

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Bitcoin snack machine (fast transaction problem)

Date2010-07-17 22:29:13 UTC

ForumBitcointalk · 原文

我相信支付处理公司有可能把这做成一项服务：在 10 秒甚至更短的时间内，以足够好的检查快速分发交易。

网络节点只接受它们收到的交易的第一个版本，放进它们正在尝试生成的区块里。当你广播一笔交易时，如果同时有人广播了一笔双重支付，那就是一场看谁先传播到最多节点的竞速。只要一方稍有领先，它就会以几何级数更快地扩散开，占据大多数节点。

一个粗略的估算示例：
1 0
4 1
16 4
64 16
80% 20%

所以如果双重支付哪怕晚了一秒，就处于巨大劣势。

支付处理商连接着很多节点。当它收到一笔交易，就把它猛烈地广播出去，同时监听网络上有没有双重支付。如果它在任何一个监听节点上收到了双重支付，就会发出警报说这笔交易有问题。一笔被双花的交易不可能在不被某个监听器听到的情况下传很远。双花者必须等到监听阶段结束，但到那时，支付处理商的广播已经覆盖了大多数节点，或者传播领先太多，双花者已经没希望抢到剩下节点中的可观比例了。

英文原文

I believe it'll be possible for a payment processing company to provide as a service the rapid distribution of transactions with good-enough checking in something like 10 seconds or less.

The network nodes only accept the first version of a transaction they receive to incorporate into the block they're trying to generate. When you broadcast a transaction, if someone else broadcasts a double-spend at the same time, it's a race to propagate to the most nodes first. If one has a slight head start, it'll geometrically spread through the network faster and get most of the nodes.

A rough back-of-the-envelope example:
1 0
4 1
16 4
64 16
80% 20%

So if a double-spend has to wait even a second, it has a huge disadvantage.

The payment processor has connections with many nodes. When it gets a transaction, it blasts it out, and at the same time monitors the network for double-spends. If it receives a double-spend on any of its many listening nodes, then it alerts that the transaction is bad. A double-spent transaction wouldn't get very far without one of the listeners hearing it. The double-spender would have to wait until the listening phase is over, but by then, the payment processor's broadcast has reached most nodes, or is so far ahead in propagating that the double-spender has no hope of grabbing a significant percentage of the remaining nodes.

Re: Assertion Failure - Ubuntu Lucid

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Assertion Failure - Ubuntu Lucid

Date2010-07-17 22:37:06 UTC

ForumBitcointalk · 原文

引用自：singpolyma 于 July 17, 2010, 10:19:48 PM（https://bitcointalk.org/index.php?topic=400.msg3815#msg3815）
我的币不见了，不过我猜区块下载到最新后它们会回来吧？

对，等它把所有区块下载完，它们就会重新出现。

英文原文

Quote from: singpolyma on July 17, 2010, 10:19:48 PM（https://bitcointalk.org/index.php?topic=400.msg3815#msg3815）
My coins disappeared, but I assume they'll come back when it's up to current?

Right, they'll re-appear when it's finished downloading all the blocks.

Re: Bitcoin 0.3.2 released

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Bitcoin 0.3.2 released

Date2010-07-17 22:54:24 UTC

ForumBitcointalk · 原文

引用自：llama 于 July 17, 2010, 09:56:25 PM（https://bitcointalk.org/index.php?topic=437.msg3810#msg3810）
不过，重要的是你不能一直锁定到最新的区块。不然的话，攻击者可以在你锁定之前刚好生成一个假区块（或几个），那他的攻击就会比没有区块锁定时容易得多。

我往回锁了大约 200 个区块。区块链是一条干净的直线，没有分叉，被锁定的区块也只有一个已知版本。

引用自：llama 于 July 17, 2010, 09:56:25 PM（https://bitcointalk.org/index.php?topic=437.msg3810#msg3810）
还有，我猜区块锁意味着区块会和客户端一起预装。是这样吗？

抱歉，还没有，不过我确实想让初始区块下载更快一些。

英文原文

Quote from: llama on July 17, 2010, 09:56:25 PM（https://bitcointalk.org/index.php?topic=437.msg3810#msg3810）
However, it's important that you don't lock all the way up the very latest block. Otherwise, the attacker could generate a fake block (or a few) right before you happen to lock it, and then his attack would be far easier than it would have been without the block lock.

I went about 200 blocks back. The block chain was a clean straight line without branches, and there was only one known version of the locked block.

Quote from: llama on July 17, 2010, 09:56:25 PM（https://bitcointalk.org/index.php?topic=437.msg3810#msg3810）
Also, I'm assuming that the block lock means that the blocks will also come prepackaged with the client. Is this so?

Sorry, not yet, but I do want to make the initial block download faster.

Re: Source code documentation

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Source code documentation

Date2010-07-17 23:18:30 UTC

ForumBitcointalk · 原文

我没想到你会把所有故意不写文档的命令都写成文档。它们是不被支持的，也不打算给用户用。

所有面向用户的命令都在 -? 帮助里列着。

英文原文

I didn't realize you were going to document all the intentionally undocumented commands. They're unsupported and not intended to be used by users.

All the user-facing commands are listed in the -? help.

Re: Network Size

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Network Size

Date2010-07-17 23:25:16 UTC

ForumBitcointalk · 原文

引用自：NewLibertyStandard 于 July 17, 2010, 10:22:09 PM（https://bitcointalk.org/index.php?topic=419.msg3817#msg3817）
0.3 版应该把未做端口转发的客户端的出站连接数从 15 降到 8，但我觉得好像没生效。我不确定是不是这样。如果我说错了请纠正我。

在 0.3.0 里，降到 8 的改动只进了 Windows 版，其他版本还是 15。

请升级到 0.3.2，现在已经有了。

英文原文

Quote from: NewLibertyStandard on July 17, 2010, 10:22:09 PM（https://bitcointalk.org/index.php?topic=419.msg3817#msg3817）
Version 0.3 was supposed to reduce the number of outgoing connections on non-port forwarded clients from 15 to 8, but I don't think it really happened. I'm not positive if this is the case. Correct me if I'm wrong.

In 0.3.0, the change to 8 only ended up in the Windows version, the other versions still had 15.

Please upgrade to 0.3.2, it's available now.

Re: Bitcoin snack machine (fast transaction problem)

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Bitcoin snack machine (fast transaction problem)

Date2010-07-18 01:59:15 UTC

ForumBitcointalk · 原文

引用自：llama 于 July 18, 2010, 12:03:29 AM（https://bitcointalk.org/index.php?topic=423.msg3836#msg3836）
这是个好的开始，但还不是无懈可击。

我没说无懈可击，我说的是足够好。实际中的损失会比信用卡低得多。

引用
（比如，拒绝在自动售货机那台机器上传播这笔交易的消息）

不，自动售货机是和一家大型服务商（也就是支付处理商）对话的，这家服务商为很多商家提供这项服务。可以把它想成一家信用卡处理商接了份新活。他们会有很多连接良好的网络节点。

英文原文

Quote from: llama on July 18, 2010, 12:03:29 AM（https://bitcointalk.org/index.php?topic=423.msg3836#msg3836）
This is a good start, but still not impermeable.

I didn't say impermeable, I said good-enough. The loss in practice would be far lower than with credit cards.

Quote
(for example, by refusing to propogate word of the transaction at the vending machine)

No, the vending machine talks to a big service provider (aka payment processor) that provides this service to many merchants. Think something like a credit card processor with a new job. They would have many well connected network nodes.

Re: Source code documentation

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Source code documentation

Date2010-07-18 15:12:54 UTC

ForumBitcointalk · 原文

它们只打算给敢读源代码的勇敢程序员用。

英文原文

They're only intended for intrepid programmers who read the sourcecode.

Re: URI-scheme for bitcoin

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: URI-scheme for bitcoin

Date2010-07-18 16:06:16 UTC

ForumBitcointalk · 原文

引用自：lachesis 于 June 16, 2010, 06:14:05 AM（https://bitcointalk.org/index.php?topic=55.msg1597#msg1597）
我觉得你误解了问题。我的浏览器永远能访问 127.0.0.1（除非有什么奇怪的 IE 设置或病毒）。如果我在地址栏输入地址或点链接，都能正常工作。但没法用 Javascript 在不同域之间（或同一域的不同端口之间）完成 POST 请求。

我也是这么想的。

引用自：sirius-m 于 June 16, 2010, 08:26:14 AM（https://bitcointalk.org/index.php?topic=55.msg1598#msg1598）
对，我是想说跨域 javascript 调用是被禁止的，所以你不能从一个不在 127.0.0.1 上的 javascript 去调用 127.0.0.1。想想看，如果浏览器允许恶意的跨域 javascript 去改别人的 Facebook 页面，那就太好笑了。

现在我听说 javascript 是可以向 127.0.0.1 做跨域 POST 请求的。不是别的域，唯独就是这一个。可以……

如果是这样，那就不要在你用来上网的系统上用 -server 开关或 bitcoind。

我这就开始加密码字段。

英文原文

Quote from: lachesis on June 16, 2010, 06:14:05 AM（https://bitcointalk.org/index.php?topic=55.msg1597#msg1597）
I think you're misunderstanding the issue. My browser will always be able to go to 127.0.0.1 (barring some strange IE settings or a virus). If I type the address into the URL bar or click a link, it will work fine. However, it isn't possible to use Javascript to complete POST requests between domains (or ports on the same domain).

That's what I thought too.

Quote from: sirius-m on June 16, 2010, 08:26:14 AM（https://bitcointalk.org/index.php?topic=55.msg1598#msg1598）
Yeah, I meant to say that cross-domain javascript calls are forbidden, so you can't call 127.0.0.1 from a javascript that doesn't reside in 127.0.0.1. Come to think of it, it would be quite funny if browsers allowed malicious cross-domain javascript to change people's Facebook pages etc.

Now I'm hearing a report that it IS possible for javascript to do a cross-domain POST request to 127.0.0.1. Not other domains, but just specifically to that one. Great...

If this is the case, then do not use the -server switch or bitcoind on a system where you do web browsing.

I'll get started on adding the password field.

Re: Bitcoin 0.3.2 released

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Bitcoin 0.3.2 released

Date2010-07-18 18:58:21 UTC

ForumBitcointalk · 原文

改动列表基本就是首帖里列的那些。每个人都应该升级，以获得重要的安全改进。

最小化到托盘在 Linux 上至少有 3 处不同的小毛病和 bug，包括一个会导致崩溃的，所以我又把它禁用了。如果你想用，可以用 "-minimizetotray" 重新打开这个选项。这些 bug/小毛病在 wxWidgets 或 GTK 或 Gnome 里，我不知道怎么修。抱歉，我实在想不出别的办法，它作为主线功能实在太毛病太多了。

英文原文

The change list is basically encompassed by what's listed in the first message. Everyone should upgrade to get the important security improvements.

Minimizing to tray had at least 3 different glitches and bugs on Linux, including a crash one, so I disabled it again. You can still re-enable the option with "-minimizetotray" if you want to use it anyway. The bugs/glitches are somewhere in wxWidgets or GTK or Gnome and I don't know how to fix them. Sorry, I just don't know what else to do, it's just too glitchy and buggy to have as a mainline feature.

JSON-RPC password

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleJSON-RPC password

Date2010-07-18 20:49:22 UTC

ForumBitcointalk · 原文

我把给 JSON-RPC 加密码的改动上传到了 SVN。如果你能自己构建，请帮忙测试。

-server 开关被 -rpcpw=<password> 取代了，bitcoind 也用它。
bitcoin -rpcpw=<password> -- 以 JSON-RPC 端口开放的方式运行
bitcoind -rpcpw=<password> -- 带密码的守护进程

如果你对开关名有更好的想法，告诉我，但记住以后数据库加密也会有个密码。我不确定，但我觉得它们可能想用两个不同的密码。

如果你不设密码，它会给出警告。

现在所有命令都要求密码作为第一个参数。如果你运行 "bitcoind help" 它会告诉你。

核心代码：

// Check password
if (params.size() < 1 || params[0].type() != str_type)
throw runtime_error("First parameter must be the password.");
if (params[0].get_str() != strRPCPassword)
{
if (strRPCPassword.size() < 15)
Sleep(50);
begin = strRequest.end();
printf("ThreadRPCServer incorrect password attempt\n");
throw runtime_error("Incorrect password.");
}

对这些决定有什么评论吗？

1) if (strRPCPassword.size() < 15) Sleep(50); -- 意思是如果密码很短，每次尝试后会等 50ms。这可能被用作 DoS 攻击，但我想如果密码很短，防范暴力密码扫描更重要。这可能会让外界知道密码是否少于 15 个字符，但少于 15 也没什么大不了，大多数密码都少于 15。如果你想堵住 DoS 的可能，就用 15 个字符或更长的密码。

2) begin = strRequest.end(); -- 如果一次请求里有多次调用，其中一次密码错了我就把剩下的全扔掉。这样你就没法在一个包里塞几百万次密码尝试。你觉得这样做对吗？（多次调用反正几乎没人用）

我还修了帮助里列出的两个重复命令：

getaddressesbylabel <pw> <label>
getbalance <pw>
getblockcount <pw>
getblocknumber <pw>
getconnectioncount <pw>
getdifficulty <pw>
getgenerate <pw>
getinfo <pw>
getlabel <pw> <bitcoinaddress>
getnewaddress <pw> [label]
getreceivedbyaddress <pw> <bitcoinaddress> [minconf=1]
getreceivedbylabel <pw> <label> [minconf=1]
help <pw>
listreceivedbyaddress <pw> [minconf=1] [includeempty=false]
listreceivedbylabel <pw> [minconf=1] [includeempty=false]
sendtoaddress <pw> <bitcoinaddress> <amount> [comment] [comment-to]
setgenerate <pw> <generate> [genproclimit]
setlabel <pw> <bitcoinaddress> <label>
stop <pw>

英文原文

I uploaded to SVN my changes to add a password to JSON-RPC. If you're set up to build, please test it.

The -server switch is replaced with -rpcpw=<password>, which is also used with bitcoind.
bitcoin -rpcpw=<password> -- runs with JSON-RPC port open
bitcoind -rpcpw=<password> -- daemon with password

If you have a better idea for the switch name, let me know, but keep in mind there will eventually be a password for encrypting the database too. I'm not sure but I think they may want to use different passwords for the two.

It gives a warning if you don't set a password.

All commands now require the password as the first parameter. It'll tell you that if you run "bitcoind help".

The central code:

Any comments on these decisions?

1) if (strRPCPassword.size() < 15) Sleep(50); -- this means if it's a short password, it'll wait 50ms after each attempt. This might be used as a DoS attack, but I figured if it's a short password, it's more important to protect against brute force password scan. This may tell outsiders whether the password is less than 15 characters, but less than 15 isn't all that noteworthy, most passwords are less than 15. If you want to close the DoS possibility, just use a password 15 characters or longer.

2) begin = strRequest.end(); -- if it's a single request with multiple invocations, I throw away the rest if one has a bad password. This is so you can't stuff it with millions of password attempts in one packet. What do you think, is this the right thing to do? (multiple invocation is probably almost never used anyway)

I also fixed the two duplicated commands listed in the help:

Re: MSVC build & SHA-256

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: MSVC build & SHA-256

Date2010-07-18 21:24:09 UTC

ForumBitcointalk · 原文

OpenSSL 没有只做 SHA256 底层原始块哈希部分的接口。SHA256 开始时要把你的数据包进一个特殊格式的缓冲区。只哈希一两个块（像我们这样）时，搭这个缓冲区的时间比实际哈希长一个数量级。它是假设你在哈希很多 KB 或 MB 数据、时间能被摊薄而设计的。在 BitcoinMiner 里，我们把缓冲区格式化一次然后反复用。

如果你能找到比我们现在用的更快的 SHA256 代码（MinGW/GCC 下），那就太棒了！（不过注意许可证）我们现在这个是我试过的唯一一个，所以有很大改进空间。

我写它的时候是 2 年多前，那时有快得吓人的 SHA1 实现，但 SHA256 几乎没人关注。那时到现在已经很久了，他们应该搞出了更好的东西。当时 SHA256 比最快的 SHA1 慢，我觉得慢得不应该。显然 SHA256 应该比 SHA1 慢一定幅度，但不该慢那么多。

（希望你不介意我改了你的帖子标题，SHA-256 优化是我一直记着要做的重要事）

英文原文

OpenSSL doesn't have any interface for doing just the low level raw block hash part of SHA256. SHA256 begins by wrapping your data in a specially formatted buffer. Setting up the buffer takes an order of magnitude longer than the actual hashing if you're only hashing one or two blocks like we do. It's intended that the time is amortised if you were hashing many KB or MB of data. In BitcoinMiner, we format the buffer once and keep reusing it.

If you can find SHA256 code that's faster (with MinGW/GCC) than what we've got, that would be really great! (although, keep licensing in mind) The one we have is the only one I tried, so there's significant chance for improvement.

When I wrote it more than 2 years ago, there were screaming hot SHA1 implementations but minimal attention to SHA256. That's a lot of time for them to come up with better stuff. SHA256 was a lot slower than the fastest SHA1 at the time than I thought it should be. Obviously SHA256 should be slower than SHA1 by a certain amount, but not by as much as I saw.

(hope you don't mind I renamed your thread, SHA-256 optimisation is something important that I keep forgetting about)

Re: Nenolod, the guy that wants to prove Bitcoin doesn't work.

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Nenolod, the guy that wants to prove Bitcoin doesn't work.

Date2010-07-18 21:56:18 UTC

ForumBitcointalk · 原文

通常超过 25,000 BTC。

英文原文

Typically, over 25,000 BTC.

Re: Did block generation crawl to a halt?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Did block generation crawl to a halt?

Date2010-07-18 23:35:27 UTC

ForumBitcointalk · 原文

漂亮的图！加个移动平均来平滑一下就更好了。

http://nullvoid.org/bitcoin/statistix.php 说过去 24 小时有 212 个区块，即每小时 8.8 个。

英文原文

Nice graph! A moving average to smooth it out would be nice.

http://nullvoid.org/bitcoin/statistix.php says 212 blocks in the last 24 hours, or 8.8 per hour.

Re: JSON-RPC password

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: JSON-RPC password

Date2010-07-19 04:43:13 UTC

ForumBitcointalk · 原文

对，那确实好得多。

你能举些别的也这么做的东西的例子吗？（命令行长什么样）

你说的主要改动是：启动 bitcoind 时不用 -rpcpw=，而是用一个开关指定一个文本文件去里面读密码，对吧？（这个开关叫什么好，你有想法吗？）

英文原文

Right, that is quite a bit better.

Can you give me any examples of other stuff that does it that way? (and what the command line looks like)

The main change you're talking about here is instead of -rpcpw= when you start bitcoind, you'd use a switch that specifies a text file to go and read it from, right? (any ideas what I should name the switch?)

Warning: don't use -server or bitcoind where you web browse (v0.3.2 and lower)

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleWarning: don't use -server or bitcoind where you web browse (v0.3.2 and lower)

Date2010-07-19 16:01:38 UTC

ForumBitcointalk · 原文

不要在你用网页浏览器的机器上用 -server 或 -daemon 开关，也不要运行 bitcoind。它会在 127.0.0.1（本地回环地址）上打开 8332 端口，你可能觉得浏览器没法跨站访问它，但其实是可以的。

我们正在准备一个给 JSON-RPC 接口加密码的新版本，但在那之前，避免用 -server 开关，也不要在运行 bitcoind 的同一台机器上上网。

更新：
0.3.3 的 JSON-RPC HTTP 认证功能解决了这个问题。

英文原文

Don't use the -server or -daemon switch or run bitcoind on a machine where you use a web browser. It opens port 8332 on 127.0.0.1, the local loopback address, and you wouldn't think that web browsers could cross-site access it, but it is possible.

We're working on a release soon that puts a password on the JSON-RPC interface, but until then, avoid using the -server switch, and don't web browse on the same machine where bitcoind is running.

Update:
The JSON-RPC HTTP authentication feature in 0.3.3 solves this problem.

Re: JSON-RPC password

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: JSON-RPC password

Date2010-07-19 16:20:50 UTC

ForumBitcointalk · 原文

所以是在 ~/.bitcoin 目录里放个设置文件，听起来更好。在"未设置密码"的警告里，可以告诉你文件在哪、该怎么做。

最流行最常见的设置文件格式是什么？

HTTP 基本认证也值得考虑。但实际中，网页开发者要搞明白怎么通过 HTTP 或 JSON-RPC 包装器的某个额外参数来指定密码，比直接在参数列表开头多加一个参数要费劲得多。你觉得呢？HTTP 基本认证能给我们带来什么额外好处吗？把它从参数列表挪走，但你还得在一个更冷门的地方指定它，我不确定这是不是净收益。

引用自：gavinandresen 于 July 19, 2010, 12:02:39 PM（https://bitcointalk.org/index.php?topic=461.msg4215#msg4215）
我一开始有点懵，因为密码在命令行里是放在最后的，但在 JSON-RPC 参数列表里却是放在最前的。我同意从文件里读命令行密码会更方便也更安全。

你也把我搞糊涂了，你什么意思？我做了什么意料之外的事吗？

英文原文

So you drop a settings file in the ~/.bitcoin directory, that sounds better. In the "no password is set" warning, it could tell you where the file is and what to do.

What is the most popular and common settings file format?

HTTP basic authentication should be considered. In actual practice though, it's more work for web developers to figure out how to specify the password through some extra parameter in the HTTP or JSON-RPC wrapper than to just stick an extra parameter at the beginning of the parameter list. What do you think? Does HTTP basic authentication get us any additional benefits? Moving it off the parameter list but then you still have to specific it in a more esoteric place I'm not sure is a net win.

Quote from: gavinandresen on July 19, 2010, 12:02:39 PM（https://bitcointalk.org/index.php?topic=461.msg4215#msg4215）
I was confused for a bit because the password is given LAST on the command line, but FIRST in the JSON-RPC params list. I agree that reading the command-line password from a file would be more convenient and more secure.

You're also confusing me, what do you mean? Did I do something unintended?

Re: They want to delete the Wikipedia article

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: They want to delete the Wikipedia article

Date2010-07-20 18:38:28 UTC

ForumBitcointalk · 原文

比特币是 Wei Dai 在 1998 年于 Cypherpunks 上提出的 b-money 方案 http://weidai.com/bmoney.txt 和 Nick Szabo 的 Bitgold 方案 http://unenumerated.blogspot.com/2005/12/bit-gold.html 的一个实现。

这个时机很奇怪，正好是我们被 slashdot 报道后第三方报道快速增加的时候。希望他们不要急着收尾做决定。维基百科对这类问题通常开放多久的评论？

尽快把条目浓缩一下、去掉宣传腔会很有帮助。让人知道它是什么、它在电子货币领域的位置就行，不是去说服别人它有多好。他们大概想要个一般性地说明它是什么的东西，而不是把工作原理全讲一遍。

如果你去 http://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Bitcoin 发言，请不要说"是啊，但比特币真的很重要很特别，所以规则不该适用"，也不要争辩说规则很蠢或不公平。那只会让事情更糟。试着去论证规则是怎么被满足的。

在 google 上搜 "bitcoin"，看看除了 infoworld 和 slashdot 之外还能不能找到更多大的引用。可能有记者听说了 slashdot 的文章后正在写很新的报道。

我希望它别被删掉。如果被删了，要推翻之前的决定会很难。机构的惯性是维持上次的决定。（编辑：或者至少我猜是这样，世界通常这么运转，但维基也许不一样）

英文原文

Bitcoin is an implementation of Wei Dai's b-money proposal http://weidai.com/bmoney.txt on Cypherpunks http://en.wikipedia.org/wiki/Cypherpunks in 1998 and Nick Szabo's Bitgold proposal http://unenumerated.blogspot.com/2005/12/bit-gold.html

The timing is strange, just as we are getting a rapid increase in 3rd party coverage after getting slashdotted. I hope there's not a big hurry to wrap the discussion and decide. How long does Wikipedia typically leave a question like that open for comment?

It would help to condense the article and make it less promotional sounding as soon as possible. Just letting people know what it is, where it fits into the electronic money space, not trying to convince them that it's good. They probably want something that just generally identifies what it is, not tries to explain all about how it works.

If you post in http://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Bitcoin please don't say "yeah, but bitcoin is really important and special so the rules shouldn't apply" or argue that the rule is dumb or unfair. That only makes it worse. Try to address how the rule is satisfied.

Search "bitcoin" on google and see if you can find more big references in addition to the infoworld and slashdot ones. There may be very recent stuff being written by reporters who heard about it from the slashdot article.

I hope it doesn't get deleted. If it does, it'll be hard to overcome the presumption. Institutional momentum is to stick with the last decision. (edit: or at least I assume so, that's how the world usually works, but maybe Wiki is different)

Re: JSON-RPC password

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: JSON-RPC password

Date2010-07-21 00:05:20 UTC

ForumBitcointalk · 原文

还是得知道 Linux 上最典型的设置文件格式是什么。有标准的文件扩展名吗？我从没见过用 JSON 的设置文件，而且所有东西都要加引号，看起来对人不友好。我平时见的一般是这样：
# comment
setting=value

Boost 里有设置文件相关的东西吗？

当你用 bitcoind 在命令行发命令当客户端用时，能不能也让它从设置文件里读密码？

Gavin 指出我忘了在 CommandLineRPC 里把数字那一列递增，所以现在的 -rpcpw= 实现在命令行下对非字符串参数工作不正常。（JSON-RPC 没问题）还在施工中。

英文原文

Still need to know what's the most typical settings file format on Linux. Is there a standard file extension? I've never seen a settings file using JSON, and it doesn't look very human friendly with everything required to be in quotes. I think what I usually see is like:
# comment
setting=value

Is there a settings file thing in Boost?

When you're using bitcoind to issue commands from the command line as a client, can we have it get the password from the settings file then too?

Gavin pointed out I forgot to increment the column of numbers in CommandLineRPC, so the current -rpcpw= implementation doesn't work right from the command line with non-string parameters. (JSON-RPC is fine) Still under construction.

Re: JSON-RPC password

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: JSON-RPC password

Date2010-07-21 05:51:34 UTC

ForumBitcointalk · 原文

我研究了一下配置文件格式，做了个对比。

YAML 太庞大了。我不确定有没有轻量好集成的库能放进我们项目。感觉杀鸡用牛刀。

JSON 很诱人，我也挺喜欢，但有两个主要问题：
1) 没有注释！配置文件里连一行都不能注释掉禁用，这怎么行？
2) 对人不友好，所有字符串包括键都要"加引号"，还得记住行尾加逗号。
{
"key" : "value",
}

我想我们可以很容易地预处理 JSON：读配置文件时一行一行读，在任何 # 字符处（和/或 "//"？）截断行，把它们拼成一个字符串再传给 JSON，这样就可以：
# comment
"key" : "value", # 逗号还是得记住
"key2" : "value", // 这样注释或两种都行

Boost 有 boost::program_options。

我们也可以自己按行读，喂进一个 map<string, string> mapConfig。

while (!eof)
read line
if '#' found, truncate line
split line at first ':' -> key, value
mapConfig.insert(key, value)

如果用这个语法：
# comment
key : value

……而且键前面不允许缩进空格，那我们就是 YAML 的一个子集，以后需要更复杂时可以切到 YAML。

就算用自解析，也不意味着特定参数值不能用 JSON。如果某个选项需要列表或更结构化的数据，它的值随时可以按 json 解析：
key : ["item1", "item2", "item3"]

不过那样就必须全在一行里了。

我想我倾向于自解析的 mapConfig：
# comment
key : value

英文原文

I was researching config file formats, here's a comparison.

YAML is massive. I'm not sure there's a lightweight easy to build library we can integrate into our project. Seems overkill.

JSON is tempting and I'm inclined to like it, but two main sticking points:
1) No comments! How can you have a config file where you can't comment out a line to disable it?
2) Not very user friendly to have to "quote" all the strings, including the keys, and also have to remember the comma at the end of lines.
{
"key" : "value",
}

I suppose we could easily preprocess JSON reading the config file one line at a time, truncate the lines at any # character (and/or "//"?), concatenate them into a string and pass it to JSON, so you could go:
# comment
"key" : "value", # still have to remember the comma
"key2" : "value", // comment like this or both

Boost has boost::program_options.

We could read lines ourselves and feed them into a map<string, string> mapConfig.

while (!eof)
read line
if '#' found, truncate line
split line at first ':' -> key, value
mapConfig.insert(key, value)

If we use the syntax:
# comment
key : value

...and don't allow whitespace indenting before the keys, I guess we would be a subset of YAML and could switch to YAML someday if we need more complexity.

If we go with self parsed, that doesn't mean we can't use JSON on particular parameter values as needed. If an option needs a list or more structured data, it could always parse its value as json:
key : ["item1", "item2", "item3"]

Although it has to be all on one line then.

I guess I'm leaning towards self parsed mapConfig:
# comment
key : value

Re: JSON-RPC password

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: JSON-RPC password

Date2010-07-21 16:07:57 UTC

ForumBitcointalk · 原文

引用自：gavinandresen 于 July 21, 2010, 12:11:10 PM（https://bitcointalk.org/index.php?topic=461.msg4709#msg4709）
我刚才快速调查了我的 debian 系统 /etc 下的 20 个 .conf 文件，发现：
1 个文件用 "key value"
5 个用 "key=value"

谢谢你的调查！

我觉得 "key value" 有点别扭。键和值之间应该有个更明确的分隔符，暗示这是赋值。用 split 函数的人可能只是图省事。
key=some full sentence with spaces in it. # 这样更清楚
key some full sentence with spaces in it. # 比这样好

好，那就用自解析的 mapConfig，语法：
# comment
key=value

文件扩展名 .conf。文件名是什么，~/.bitcoin/settings.conf 还是 ~/.bitcoin/bitcoin.conf 还是别的？

我觉得键和值首尾的空白最好去掉。
# user who likes column formatted
k = value
key = value
longerkey = this sentence would be this # "this sentence would be this"
key = value # guess this is ok too
nextkey = value
right = justified

正常语法应该是 "key=value"，但偶尔有人写成 "key = value" 也不能怪人家。

英文原文

Quote from: gavinandresen on July 21, 2010, 12:11:10 PM（https://bitcointalk.org/index.php?topic=461.msg4709#msg4709）
I just did a quick survey of 20 .conf files in /etc on my debian system, and found:
1 file used "key value"
5 used "key=value"

Thanks for that survey!

I find "key value" a little unnatural. There ought to be a more definite separator between key and value that suggests assignment. The space people may just be getting lazy using their language's split function.
key=some full sentence with spaces in it. # seems more clear
key some full sentence with spaces in it. # than this

Allright then, lets go with self-parsed mapConfig, syntax:
# comment
key=value

file extension .conf. What's the filename, is it ~/.bitcoin/settings.conf or ~/.bitcoin/bitcoin.conf or what?

I think we better strip whitespace at the beginning and end of the key and the value.
# user who likes column formatted
k = value
key = value
longerkey = this sentence would be this # "this sentence would be this"
key = value # guess this is ok too
nextkey = value
right = justified

The normal syntax should be "key=value", but you can't blame people for the occasional "key = value".

Re: JSON-RPC password

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: JSON-RPC password

Date2010-07-21 17:31:09 UTC

ForumBitcointalk · 原文

boost::program_options 也是 "key=value" 格式。Gavin 指出我们可以简单地用它当解析器，不用去碰那些冷门的 C++ 语法，比如 typed value extraction。以后想用更多功能也行。

那就用 HTTP 基本认证，代替把密码当参数。

英文原文

boost::program_options has the same "key=value" format. Gavin pointed out we can use it in a simple way as a parser without getting into all the esoteric c++ syntax like typed value extraction. We can use more features if we want later.

Lets go ahead with HTTP basic authentication instead of password as a parameter.

Re: JSON-RPC password

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: JSON-RPC password

Date2010-07-22 02:34:23 UTC

ForumBitcointalk · 原文

引用自：gavinandresen 于 July 22, 2010, 01:11:26 AM（https://bitcointalk.org/index.php?topic=461.msg4908#msg4908）
TODO：如果没设 rpc.user/rpc.password，弹对话框或在 debug.log 里警告，说明怎么设置。

在 RPC 这些代码的很多场景里，你可以像这样用 fprintf(stdout 往控制台打印：
#if defined(__WXMSW__) && wxUSE_GUI
MyMessageBox("Warning: rpc password is blank, use -rpcpw=<password>\n", "Bitcoin", wxOK | wxICON_EXCLAMATION);
#else
fprintf(stdout, "Warning: rpc password is blank, use -rpcpw=<password>\n");
#endif

英文原文

Quote from: gavinandresen on July 22, 2010, 01:11:26 AM（https://bitcointalk.org/index.php?topic=461.msg4908#msg4908）
TODO: dialog box or debug.log warning if no rpc.user/rpc.password is set, explaining how to set.

In many of the contexts of this RPC stuff, you can print to the console with fprintf(stdout, like this:
#if defined(__WXMSW__) && wxUSE_GUI
MyMessageBox("Warning: rpc password is blank, use -rpcpw=<password>
", "Bitcoin", wxOK | wxICON_EXCLAMATION);
#else
fprintf(stdout, "Warning: rpc password is blank, use -rpcpw=<password>
");
#endif

Re: JSON-RPC password

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: JSON-RPC password

Date2010-07-23 17:07:40 UTC

ForumBitcointalk · 原文

引用自：gavinandresen 于 July 23, 2010, 03:11:45 PM（https://bitcointalk.org/index.php?topic=461.msg5296#msg5296）
问大家一个问题：要不要在 wiki 页面上加一节，详细讲怎么做 HTTP 基本认证？PHP 和 Python 里这非常容易——直接用 http://user:pass@host:port/ 这种 URL 语法就行。

对，我觉得那会非常好，这样每个开发者就不用自己琢磨了。我们需要 Python、PHP 和 Java 各一个简单例子，讲怎么导入 json-rpc 库、做一次 getinfo 之类的调用，包括做 http 认证的部分。

英文原文

Quote from: gavinandresen on July 23, 2010, 03:11:45 PM（https://bitcointalk.org/index.php?topic=461.msg5296#msg5296）
Question for everybody: should I add a section to the wiki page describing, in detail, how to do HTTP Basic authentication? PHP and Python make is really easy-- just use the http://user:pass@host:port/ URL syntax.

Yes, I think that would be really good so each dev doesn't have to figure it out themselves. We need a simple example for each of Python, PHP and Java importing the json-rpc library and using it to do a getinfo or something, including doing the http authentication part.

Re: JSON-RPC password

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: JSON-RPC password

Date2010-07-23 17:14:31 UTC

ForumBitcointalk · 原文

Gavin 的改动看起来不错。我觉得已经完成了。这是测试构建版，请测试！

http://www.bitcoin.org/download/bitcoin-0.3.2.5-win32.zip
http://www.bitcoin.org/download/bitcoin-0.3.2.5-linux.tar.gz

英文原文

Gavin's changes look good. I think everything is complete. Here's a test build, please test it!

http://www.bitcoin.org/download/bitcoin-0.3.2.5-win32.zip
http://www.bitcoin.org/download/bitcoin-0.3.2.5-linux.tar.gz

Re: bitcoind not responding to RPC

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: bitcoind not responding to RPC

Date2010-07-23 17:23:47 UTC

ForumBitcointalk · 原文

如果我没记错，500 是 JSON-RPC 错误响应的规定状态码。回复正文里还是有 JSON 响应说明错误原因，比如 {"result":"","error":"bitcoin address not found","id":"1"}。

英文原文

If I recall correctly, 500 is the prescribed status code for JSON-RPC error responses. There is still a JSON response in the body of the reply telling the explanation of the error, which could be something like {"result":"","error":"bitcoin address not found","id":"1"}.

Faster initial block download (5x faster)

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleFaster initial block download (5x faster)

Date2010-07-23 18:24:56 UTC

ForumBitcointalk · 原文

通过调整数据库设置，我把初始区块下载提速了约 5 倍。现在大约 30 分钟就能下载完。

数据库默认是每个区块同步写入磁盘，这没必要。我改成让它在内存里缓存改动、批量写出。区块仍然是事务性写入的，所以要么完整变更生效、要么完全不生效，两种情况下数据都保持有效状态。

我只在初始区块下载期间启用这个改动。当你离最新区块不到 2000 个区块时，这些改动会关闭，变回原来的慢速方式。

我做了个测试构建版，如果你想用可以开始用了：

http://www.bitcoin.org/download/bitcoin-0.3.2.5-win32.zip
http://www.bitcoin.org/download/bitcoin-0.3.2.5-linux.tar.gz

这些二进制文件还包含了 Gavin Andresen 的 JSON-RPC HTTP 认证功能和 0.3.2 的其他重要安全改进。

过去 24 小时我一直在跑一个测试，每 2-60 秒随机杀掉重启它（可怜的家伙），当时它正在做初始区块下载，一直都没问题。

钱包 wallet.dat 的处理方式没有任何改动。这个改动只针对 blk*.dat 和不重要的 addr.dat。blk*.dat 坏了你随时可以删掉让它重下。

英文原文

By making some adjustments to the database settings, I was able to make the initial block download about 5 times faster. It downloads in about 30 minutes.

The database default had it writing each block to disk synchronously, which is not necessary. I changed the settings to let it cache the changes in memory and write them out in a batch. Blocks are still written transactionally, so either the complete change occurs or none of it does, in either case the data is left in a valid state.

I only enabled this change during the initial block download. When you come within 2000 blocks of the latest block, these changes turn off and it slows down to the old way.

I built a test build if you'd like to start using it:

http://www.bitcoin.org/download/bitcoin-0.3.2.5-win32.zip
http://www.bitcoin.org/download/bitcoin-0.3.2.5-linux.tar.gz

These binaries also include Gavin Andresen's JSON-RPC HTTP authentication feature and the other important security improvements from 0.3.2.

I've been running a test over the last 24 hours that kills and restarts it randomly every 2-60 seconds (poor thing) while it's trying to do an initial block download and it's been fine.

There are no changes to the way it handles wallet.dat. This change is only for blk*.dat and the non-critical addr.dat. You can always delete blk*.dat if it gets screwed up and let it re-download.

Re: Faster initial block download

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Faster initial block download

Date2010-07-23 20:13:27 UTC

ForumBitcointalk · 原文

引用自：knightmb 于 July 23, 2010, 07:32:58 PM（https://bitcointalk.org/index.php?topic=550.msg5369#msg5369）
停在离最新 2000 个区块的地方，有安全上的理由吗？能不能调成比如剩 500 个区块时停？

没什么特别理由。下次我改成 1000。

英文原文

Quote from: knightmb on July 23, 2010, 07:32:58 PM（https://bitcointalk.org/index.php?topic=550.msg5369#msg5369）
Is there a safety reason to stop within the last 2000 blocks or can it be tweaked to stop at remaining 500 blocks for example?

Not really. I'll change it to 1000 next time.

Re: JSON-RPC password

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: JSON-RPC password

Date2010-07-23 20:39:03 UTC

ForumBitcointalk · 原文

我觉得如果没有 conf 文件、或配置文件里没有 "rpcpassword"，默认不该禁用认证，但如果文件里写的是 "rpcpassword=" 呢？

两边都有道理。

如果程序员搞不定他那门语言（Fortran 之类的）怎么做 HTTP 认证，或者他的 JSON-RPC 库根本不支持，该不该允许他显式禁用密码要求？

反过来说，如果有个模板 conf 文件，里面写着
rpcpassword= # fill in a password here

很多系统不允许无密码登录。比如这个论坛。Gavin 的观点似乎更有力。

顺便说，我没测试过，但希望 conf 文件里写 rpcpassword= 是合法的。只有用 -server 或 -daemon 或 bitcoind 时才应该报错警告。如果不需要密码，应该没问题。对吧？

英文原文

I don't think authentication should be disabled by default if there's no conf file or the config file doesn't contain "rpcpassword", but what if it contains "rpcpassword="?

I can see both points.

What if the programmer can't figure out how to do HTTP authentication in their language (Fortran or whatever) or it's not even supported by their JSON-RPC library? Should they be able to explicitly disable the password requirement?

OTOH, what if there's a template conf file, with
rpcpassword= # fill in a password here

There are many systems that don't allow you to log in without a password. This forum, for instance. Gavin's point seems stronger.

BTW, I haven't tested it, but I hope having rpcpassword= in the conf file is valid. It's only if you use -server or -daemon or bitcoind that it should fail with a warning. If it doesn't need the password, it should be fine. Is that right?

Re: JSON-RPC Multiple Invocations

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: JSON-RPC Multiple Invocations

Date2010-07-24 00:59:08 UTC

ForumBitcointalk · 原文

它重复 header 显然是个 bug。

我是想遵循 1.0 规范：http://json-rpc.org/wiki/specification 它要求支持多次调用。

我想它的意思是这样的，但我不确定：

Post:
{"method": "postMessage", "params": ["Hello all!"], "id": 99}
{"method": "postMessage", "params": ["I have a question:"], "id": 101}

Reply:
{"result": 1, "error": null, "id": 99}
{"result": 1, "error": null, "id": 101}

我记不清在哪看到的，说错误回复应该返回 HTTP 状态 500。如果一次回复里有多个响应、其中一个是错误，那整个是不是都算 500，我猜是。也许应该永远返回 200。我记得有人说过 500 可能在惹麻烦。

这大概在 0.3.3 之后修。在那之前，只用单次调用。我怀疑有没有 JSON-RPC 包支持多次调用，大概没有。

要是能在修之前先把多次调用到底该怎么工作（如果该支持的话）定下来就好了，还有错误响应返回 HTTP 状态 500 到底对不对。

英文原文

Obviously it's a bug that it repeats the header.

I was trying to follow the 1.0 spec: http://json-rpc.org/wiki/specification It called for multiple invocation.

I think they mean it's like this, but I'm not sure:

Post:
{"method": "postMessage", "params": ["Hello all!"], "id": 99}
{"method": "postMessage", "params": ["I have a question:"], "id": 101}

Reply:
{"result": 1, "error": null, "id": 99}
{"result": 1, "error": null, "id": 101}

I can't remember where I think I saw that it's supposed to send back HTTP status 500 for an error reply. If it contains multiple responses and one is an error, I wonder if that makes the status 500 for the whole thing, I guess so. Maybe it should always return 200. I think someone sounded like the 500 might be causing a problem.

This probably gets fixed after 0.3.3. Until then, just use single invocation. I wonder if any JSON-RPC package even supports multiple invocation, probably not.

It would be nice if we could pin down better how multiple-invocation is supposed to work, if at all, before trying to fix it, and whether returning HTTP status 500 for error response is right.

Re: bitcoind not responding to RPC

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: bitcoind not responding to RPC

Date2010-07-24 01:15:58 UTC

ForumBitcointalk · 原文

谁能确认一下，JSON-RPC over HTTP 在回复是错误回复时，是不是应该用状态 500？我记不清在哪看到的了，也许记错了。200 似乎更合理，除非 HTTP 请求本身的机制出了问题。（也许原文就是这么说的，是我忘了，还把 500 散播到了所有错误响应）

英文原文

Can anyone confirm if JSON-RPC over HTTP is supposed to use status 500 if the reply is an error reply? I can't remember where I picked that up, maybe it's wrong. It seems like 200 would make more sense unless there's something wrong with the mechanics of the HTTP request itself. (and maybe that's what it said and I forgot and spread 500 to all error responses)

Re: Warning: don't use -server or bitcoind on a machine where you web browse

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Warning: don't use -server or bitcoind on a machine where you web browse

Date2010-07-24 02:29:09 UTC

ForumBitcointalk · 原文

0.3.3 的 JSON-RPC HTTP 认证功能解决了这个问题。

英文原文

The JSON-RPC HTTP authentication feature in 0.3.3 solves this problem.

Version 0.3.2.5 -- please test!

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleVersion 0.3.2.5 -- please test!

Date2010-07-24 03:32:52 UTC

ForumBitcointalk · 原文

请测试 0.3.2.5，为 0.3.3 发布做准备！这个构建版看起来不错，应该就是进 0.3.3 的那个。如果你是 Windows 或 Linux 用户，我鼓励你现在就升级。

新功能：
- Gavin Andresen 的 HTTP 认证，保护 JSON-RPC 安全
- 初始区块下载提速 5 倍，30 分钟以内

在这里下载：
http://www.bitcoin.org/download/bitcoin-0.3.2.5-win32.zip
http://www.bitcoin.org/download/bitcoin-0.3.2.5-linux.tar.gz

谢谢！

英文原文

Please test 0.3.2.5 in preparation for the 0.3.3 release! This build is looking good and should be the one that goes into 0.3.3. I encourage you to go ahead and upgrade now if you're on Windows or Linux.

New features:
- Gavin Andresen's HTTP authentication to secure JSON-RPC
- 5x faster initial block download, under 30 minutes

Download here:
http://www.bitcoin.org/download/bitcoin-0.3.2.5-win32.zip
http://www.bitcoin.org/download/bitcoin-0.3.2.5-linux.tar.gz

Thanks!

Re: Reading/Writing Blocks and FLATDATA

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Reading/Writing Blocks and FLATDATA

Date2010-07-24 04:04:20 UTC

ForumBitcointalk · 原文

FLATDATA 是个变通办法，用来序列化定长数组。本来有个更干净的办法让它直接理解怎么序列化数组，但 MSVC6 做不到，而当时我想保持和 MSVC6 的兼容。我们已经不支持 MSVC6 了，因为我们用了 Boost 里的某个东西。我们在 0.2.0 之后就失去了对它的支持。也许哪天我会换成那个干净的办法，直接知道怎么序列化定长数组，不用再包一层 FLATDATA。

英文原文

FLATDATA was a workaround to serialize a fixed field length array. There was a cleaner way to make it understand how to serialize arrays directly, but MSVC6 couldn't do it and I wanted to keep compatibility with MSVC6 at that time. We don't support MSVC6 anymore because we use something in Boost that doesn't. We lost support for it after 0.2.0. Maybe someday I'll swap in the clean way that just knows how to serialize fixed length arrays without wrapping them in FLATDATA.

Re: a simple traffic load test run

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: a simple traffic load test run

Date2010-07-25 14:46:33 UTC

ForumBitcointalk · 原文

那是在测试网络上吗？
http://bitcointalk.org/index.php?topic=363.0

英文原文

Was that on the test network?
http://bitcointalk.org/index.php?topic=363.0

Re: a simple traffic load test run

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: a simple traffic load test run

Date2010-07-25 15:29:52 UTC

ForumBitcointalk · 原文

请在测试网络上做这些测试。它就是干这个用的。谢谢。

英文原文

Please do these tests on the test network. That's what it's for. Thanks.

Bitcoin 0.3.3 released -- PLEASE UPGRADE

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleBitcoin 0.3.3 released -- PLEASE UPGRADE

Date2010-07-25 16:55:09 UTC

ForumBitcointalk · 原文

请升级到 0.3.3！0.3.2 和 0.3.3 做了重要的安全改进。

新功能：
- Gavin Andresen 的 HTTP 认证，保护 JSON-RPC 安全
- 初始区块下载提速 5 倍，30 分钟以内

英文原文

Please upgrade to 0.3.3! Important security improvements were made in 0.3.2 and 0.3.3.

New features:
- Gavin Andresen's HTTP authentication to secure JSON-RPC
- 5x faster initial block download, under 30 minutes

Re: Stealing Coins

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Stealing Coins

Date2010-07-25 17:45:22 UTC

ForumBitcointalk · 原文

最好私下告诉我，这样可以先修好。

我刚把我的邮箱地址用邮件发给你了。（或者你也可以在这里 PM 我）

英文原文

It's best if you tell it to me privately so it can be fixed first.

I just e-mailed you my e-mail address. (or you could PM me here)

Re: Stealing Coins

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Stealing Coins

Date2010-07-25 19:06:23 UTC

ForumBitcointalk · 原文

Red，谢谢你先私下告诉我！请直接发出来吧（也让大家别再提心吊胆了！）

他的意思是，付到比特币地址的交易只和哈希函数一样安全。为了让比特币地址短一些，它们是公钥的哈希，而不是公钥本身。攻击者只需要攻破哈希函数，不需要攻破 ECDSA。

英文原文

Red, thanks for telling me privately first! Please go ahead and post it (and relieve the suspense for everyone!)

His point is that transactions paid to a Bitcoin Address are only as secure as the hash function. To make Bitcoin Addresses short, they are a hash of the public key, not the public key itself. An attacker would only have to break the hash function, not ECDSA.

Re: Stealing Coins

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Stealing Coins

Date2010-07-25 20:01:40 UTC

ForumBitcointalk · 原文

引用自：knightmb 于 July 25, 2010, 07:44:02 PM（https://bitcointalk.org/index.php?topic=571.msg5736#msg5736）
如果我算出公钥 123456 生成哈希 ABCD
而且
公钥 654321 也生成哈希 ABCD
我手里还是没有私钥。

但按你说的，我只需要公钥 654321，就能冒充公钥 123456 花币了。

你还是得用公钥 654321 去签名。你得找一个碰撞，用的公钥还得是你知道私钥的那个。

当你认领一笔付到比特币地址的交易时，你给出和哈希匹配的公钥，然后必须用那把密钥签名。

Red 的意思是，快速生成不安全的公钥很容易，找到碰撞之后你能破解出私钥。

他指出，如果要求公钥必须是安全的——必须经过大量工作找到质数才算——那强度就超过了哈希函数本身。想暴力破解的人，每尝试一次都得花时间生成一把密钥。

英文原文

Quote from: knightmb on July 25, 2010, 07:44:02 PM（https://bitcointalk.org/index.php?topic=571.msg5736#msg5736）
If I figure out that Public Key 123456 generates Hash ABCD
and
Public Key 654321 also generates Hash ABCD
I'm still left without the Private Key.

But from what you are saying, all I need is Public Key 654321 and I can spend coin pretending to be Public Key 123456.

You would still have to sign it with public key 654321. You need to find a collision using a public key for which you know the private key.

When you claim a Bitcoin Address transaction, you give your public key that matches the hash, then you must sign it with that key.

Red's point is that it's easy to quickly generate insecure public keys which you could break and find the private key after you find a collision.

He points out that if the public key was required to be a secure one, one which must have required significant work to find the prime numbers, that would increase the strength above that of the hash function alone. Someone trying to brute force would have to take time generating a key for each attempt.

Re: Stealing Coins

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Stealing Coins

Date2010-07-25 20:48:01 UTC

ForumBitcointalk · 原文

引用
有一篇论文声称用 2^52 次密码学运算找到了 SHA-1 碰撞。而最优安全哈希需要 2^80 次运算。2^52 的时间还是很大，但已经进入集群和僵尸网络的范围了。

2^80 是你能用生日攻击的情况。这里不能用生日攻击，所以难度是完整的 2^160 位。不过，如果你要破解 100 万（2^20）笔交易中的任意一笔，可以做部分生日攻击 2^160/2^20 = 2^140。

比特币地址是唯一用 160 位哈希的地方。其他地方都是 SHA-256。它们的计算方式是：

bitcoinaddress = RIPEMD-160(SHA-256(publickey))

如果我说错了请纠正我（我很乐意认错），但我觉得在这种情况下很难对 RIPEMD-160 用解析攻击。解析攻击规定了某一范围或模式的输入去尝试，会大大增加你找到碰撞的几率。但在这里，你对 RIPEMD-160 的输入没有那种控制权，因为它的输入是 SHA-256 的输出。如果解析攻击帮你找到了一个能让 RIPEMD-160 产生碰撞的输入，你打算拿它怎么办？你还是得让 SHA-256 输出那个值，所以你还是得把 SHA-256 也攻破。

对暴力破解来说，RIPEMD-160(SHA-256(x)) 并不比单独的 RIPEMD-160 更强。但对解析攻击来说，似乎你必须同时解析攻击 RIPEMD-160 和 SHA-256。如果我错了，那强度就和 RIPEMD-160 一样，SHA-256 只起到一轮密钥强化的作用。

英文原文

Quote
Here is a paper that claims to find SHA-1 collisions in 2^52 crypto operations. And optimally secure hash would take 2^80 operations. 2^52 time is still large, but it is getting into cluster and botnet range.

2^80 is if you can use a birthday attack. You can't use a birthday attack for this, so the difficulty is the full 2^160 bits. Although, if you were trying to crack any one of 1 million (2^20) transactions, you could do a partial birthday attack 2^160/2^20 = 2^140.

Bitcoin Addresses are the only place where 160-bit hash is used. Everything else is SHA-256. They're calculated as:

bitcoinaddress = RIPEMD-160(SHA-256(publickey))

Correct me if I'm wrong (please, and I'll gladly eat crow) but I think it would be hard to use an analytical attack on RIPEMD-160 in this case. An analytical attack prescribes a certain range or pattern of inputs to try that will greatly increase your chance of finding a collision. Here, you don't have that kind of control over RIPEMD-160's input, because the input is the output of SHA-256. If an analytical attack helps you find an input to RIPEMD-160 that produces a collision, what are you going to do with it? You still have to get SHA-256 to output that value, so you would still have to break SHA-256 too.

For brute force, RIPEMD-160(SHA-256(x)) is no stronger than RIPEMD-160 alone. But for analytical attack, it seems like you must analytical attack both RIPEMD-160 and SHA-256. If I'm wrong, then the strength is the same as RIPEMD-160 and the SHA-256 only serves as one round of key strengthening.

Re: JSON-RPC password

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: JSON-RPC password

Date2010-07-25 21:34:29 UTC

ForumBitcointalk · 原文

引用自：lachesis 于 July 25, 2010, 07:52:35 PM（https://bitcointalk.org/index.php?topic=461.msg5738#msg5738）
我发现了一个像是 bug 的东西：用户名和密码组合足够长时，bitcoind 里的 base64 编码器生成的 authorization 头长这样：
Code:
...
Authorization: Basic YWJiYWJiYWFiYmE6aGVsbG93b3JsZGhlbGxvd29ybGRoZWxsb3dvcmxkaGVsbG93
b3JsZGhlbGxvd29ybGRoZWxsb3dvcmxk

它每 64 个字符就插一个换行，这显然会破坏 Authorization 头，所以 "bitcoin getinfo" 这样的命令会失败。行为正常的客户端连服务器还是没问题的。

可以在 Base64Encode 函数末尾去掉 result 里的换行（还有 '\n'）来解决：
Code:
result.erase(std::remove(result.begin(), result.end(), '\n'), result.end());
result.erase(std::remove(result.begin(), result.end(), '\n'), result.end());

密码设这么长还发现了这个 bug，给你 +1。

已上传到 SVN，rev 110。

英文原文

Quote from: lachesis on July 25, 2010, 07:52:35 PM（https://bitcointalk.org/index.php?topic=461.msg5738#msg5738）
I found what appears to be a bug: with a long enough username and password combination, the base64 encoder in bitcoind produces authorization headers that look like this:
Code:
...
Authorization: Basic YWJiYWJiYWFiYmE6aGVsbG93b3JsZGhlbGxvd29ybGRoZWxsb3dvcmxkaGVsbG93
b3JsZGhlbGxvd29ybGRoZWxsb3dvcmxk

It inserts a newline every 64 characters, which obviously breaks the Authorization header, so commands like "bitcoin getinfo" fail. The server still works fine with properly behaving clients.

This can be solved by removing the newlines (and maybe '
's) from result at the end of the Base64Encode function:
Code:
result.erase(std::remove(result.begin(), result.end(), '
'), result.end());
result.erase(std::remove(result.begin(), result.end(), '
'), result.end());

+1 to you for having such a long password that you found this bug.

Uploaded to SVN as rev 110.

Re: JSON-RPC password

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: JSON-RPC password

Date2010-07-25 21:44:16 UTC

ForumBitcointalk · 原文

【引用 BitLex 于 2010年7月25日 20:45:38（https://bitcointalk.org/index.php?topic=461.msg5753#msg5753）】

"我在 PHP 上运行这个时也遇到了一些问题。到目前为止都没有成功，无论是 wiki 上的示例（jsonRPCClient 尝试 fopen(http://username:password@localhost:8332/)），还是我的 curl 示例（使用 setopt CURLOPT_HTTPAUTH、CURLAUTH_BASIC），似乎都不行。"
真奇怪，不是刚有人说这样是可行的吗？（他用的是哪个库？）如果你找出问题所在，请发帖说明。

希望它不会给所有 PHP 用户都带来这么大的麻烦。

看来我们已经遇到 Fortran 那种情况了。

英文原文

【引用 BitLex on July 25, 2010, 08:45:38 PM（https://bitcointalk.org/index.php?topic=461.msg5753#msg5753）】

"i got some problems here too trying to get this run on PHP.
so far i had no luck, neither the wiki-sample (jsonRPCClient trying to fopen(http://username:password@localhost:8332/)), nor my curl-sample (using setopt CURLOPT_HTTPAUTH, CURLAUTH_BASIC) seem to work.
"
That's strange, didn't someone just say that was supposed to work? (what library was he using?) Post if you figure out what wrong.

I hope it's not going to put up this much of a fight for all PHP users.

Looks like we've got the Fortran scenario already.

Re: JSON-RPC password

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: JSON-RPC password

Date2010-07-25 21:51:31 UTC

ForumBitcointalk · 原文

【引用 gavinandresen 于 2010年7月25日 21:38:19（https://bitcointalk.org/index.php?topic=461.msg5768#msg5768）】

"发现得好！更简单的修复方法是在 rpc.cpp 的 EncodeBase64 函数中指定 BIO_FLAGS_BASE64_NO_NL。"
SVN rev 111

英文原文

【引用 gavinandresen on July 25, 2010, 09:38:19 PM（https://bitcointalk.org/index.php?topic=461.msg5768#msg5768）】

"Great catch! Simpler fix is to specify the BIO_FLAGS_BASE64_NO_NL in the rpc.cpp/EncodeBase64 function
"
SVN rev 111

Re: md5?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: md5?

Date2010-07-25 22:06:57 UTC

ForumBitcointalk · 原文

供日后参考，这是我的公钥。自 2008 年 bitcoin.org 网站上线以来一直是这个。趁现在下载一份，以备后用。

http://www.bitcoin.org/Satoshi_Nakamoto.asc

英文原文

For future reference, here's my public key. It's the same one that's been there since the bitcoin.org site first went up in 2008. Grab it now in case you need it later.

http://www.bitcoin.org/Satoshi_Nakamoto.asc

Re: Stealing Coins

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Stealing Coins

Date2010-07-25 22:27:36 UTC

ForumBitcointalk · 原文

抱歉，实际上是 ECDSA（椭圆曲线数字签名算法），不是 RSA。我不该说"素数"。ECDSA 生成密钥对花不了多少时间。

英文原文

Sorry, actually it's ECDSA (Elliptic Curve Digital Signature Algorithm) not RSA. I shouldn't have said "prime numbers". ECDSA doesn't take much time to generate a keypair.

bitcoind without wxWidgets

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

Titlebitcoind without wxWidgets

Date2010-07-26 17:23:33 UTC

ForumBitcointalk · 原文

我移除了 bitcoind 中最后几个 wxBase 依赖。

现在 bitcoind 在 SVN rev 112 中无需 wxWidgets 或 wxBase 即可编译。

main(int argc, char* argv[]) 已加入 init.cpp。CMyApp 和 Startup 文件夹相关的代码移到了 ui.cpp。bitcoind 不再链接 ui.cpp 和 uibase.cpp。

makefile 用 -DGUI 控制是否使用图形界面。

我已在 MinGW、VC 和 Ubuntu 上测试编译通过。不知道有没有把 Mac OSX 构建搞坏，需要有人检查一下。

英文原文

I replaced the last of the few wxBase dependencies in bitcoind.

bitcoind now compiles without wxWidgets or wxBase in SVN rev 112.

main(int argc, char* argv[]) is added to init.cpp. CMyApp and the Startup folder stuff are moved to ui.cpp. ui.cpp and uibase.cpp aren't linked by bitcoind.

The makefiles have -DGUI to control whether the GUI is used.

I test compiled MinGW, VC and Ubuntu. I don't know if I broke the Mac OSX build, someone will need to check that.

Re: Bitcoin x64 for Windows

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Bitcoin x64 for Windows

Date2010-07-26 18:41:31 UTC

ForumBitcointalk · 原文

【引用 Olipro 于 2010年7月26日 06:39:17（https://bitcointalk.org/index.php?topic=501.msg5815#msg5815）】

"SHA 上下文缓存部分的功劳归于 tcatm——这带来了极其出色的性能。此外，Intel 编译器在这里真正发挥了实力，其并行化能力带来了远超 Visual Studio 的巨大性能提升。

性能：4 核 4700khash/s，我想这已经说明了一切。

我同时提供了 VS 和 Intel 两个构建版本，但两者根本没有可比性，Intel 构建版把 VS 版甩得远远的。"
那还是基于 Crypto++ 的吗？让我们把它合并进主源码吧。

英文原文

【引用 Olipro on July 26, 2010, 06:39:17 AM（https://bitcointalk.org/index.php?topic=501.msg5815#msg5815）】

"Credit to tcatm for the caching part of the SHA context - this offers absolutely brilliant performance. Additionally, the Intel compiler really comes into its own here as its parallelisation abilities give a massive performance boost over Visual Studio.

Performance: 4700khash/s on 4 cores, I think that speaks for itself.

I've included both the VS and Intel build, but there's really no comparison, the Intel build craps all over VS.
"
Is that still starting from Crypto++? Lets get this into the main sourcecode.

Re: Bitcoin x86 for Windows

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Bitcoin x86 for Windows

Date2010-07-27 01:29:42 UTC

ForumBitcointalk · 原文

【引用 Olipro 于 2010年7月26日 13:04:41（https://bitcointalk.org/index.php?topic=572.msg5851#msg5851）】

"Crypto++ 5.6.0：http://www.cryptopp.com/
缓存版 SHA256：http://pastebin.com/rJAYZJ32（虽然我确信这份代码在别处也公开提交过，是在 IRC 上有人发给我的）"
我已把缓存 SHA256 状态的想法加入 SVN，rev 113。提速约 70%。根据你在 x64 帖子中的说法，我把功劳记给了 tcatm。

我可以用 MinGW 编译 Crypto++ 5.6.0 的 ASM SHA 代码，但一运行就崩溃。它说是给 MASM（微软汇编器）用的，他们给的示例命令行看起来像是 Visual C++ 的。它是不是只能在 MSVC 和 Intel 编译器下工作？

英文原文

【引用 Olipro on July 26, 2010, 01:04:41 PM（https://bitcointalk.org/index.php?topic=572.msg5851#msg5851）】

"Crypto++ 5.6.0: http://www.cryptopp.com/
Cached SHA256: http://pastebin.com/rJAYZJ32 (although I'm pretty sure this is publically submitted elsewhere, I was linked to it on IRC)
"
I added the cached SHA256 state idea to the SVN, rev 113. The speedup is about 70%. I credited it to tcatm based on your post in the x64 thread.

I can compile the Crypto++ 5.6.0 ASM SHA code with MinGW but as soon as it runs it crashes. It says its for MASM (Microsoft's assembler) and the sample command line they give looks like Visual C++. Does it only work with the MSVC and Intel compilers?

Re: Proof-of-work difficulty increasing

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Proof-of-work difficulty increasing

Date2010-07-27 03:04:58 UTC

ForumBitcointalk · 原文

新难度系数 244.213223092
+35%

我已更新首帖。

日期、难度系数、变化幅度
2009 1.00
30/12/2009 1.18 +18%
11/01/2010 1.31 +11%
25/01/2010 1.34 +2%
04/02/2010 1.82 +36%
14/02/2010 2.53 +39%
24/02/2010 3.78 +49%
08/03/2010 4.53 +20%
21/03/2010 4.57 +9%
01/04/2010 6.09 +33%
12/04/2010 7.82 +28%
21/04/2010 11.46 +47%
04/05/2010 12.85 +12%
19/05/2010 11.85 -8%
29/05/2010 16.62 +40%
11/06/2010 17.38 +5%
24/06/2010 19.41 +12%
06/07/2010 23.50 +21%
13/07/2010 45.38 +93%
16/07/2010 181.54 +300%
27/07/2010 244.21 +35%

英文原文

New difficulty factor 244.213223092
+35%

I updated the first post.

Re: Bitcoin x86 for Windows

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Bitcoin x86 for Windows

Date2010-07-27 18:27:30 UTC

ForumBitcointalk · 原文

【引用 BlackEye 于 2010年7月25日 22:12:23（https://bitcointalk.org/index.php?topic=453.msg5774#msg5774）】

"我已成功将 Crypto++ 5.6.0 的 SHA256 功能集成进比特币。这是目前最快的 SHA256，使用了 SSE2 汇编代码。由于比特币向区块哈希函数发送的是未对齐数据，我不得不把 MOVDQA 指令改成 MOVDQU。

我认为现在应该采用 Crypto++ 5.6.0 的 SHA256 功能。"
我已把 Crypto++ 5.6.0 库的一个子集加入 SVN。我把它精简到只剩 SHA 和 11 个通用依赖文件。里面除了 SHA 不应再有其他加密代码。

我对齐了数据字段，它就能工作了。ASM SHA-256 快约 48%。综合提速约为 0.3.3 版本的 2.5 倍。

我想它用的是 SSE2。它在编译时根据编译器环境自动设置构建配置。

它似乎在运行时做了一些 SSE2 检测，但很难判断它是否真的会在 SSE2 不可用时回退。我希望正式构建版都带上 SSE2。SSE2 从第一代 Pentium 4 就有了。Pentium 3 或更老的机器本来就慢得不值当，在上面挖矿纯粹是浪费电。

这是 SVN rev 114。

英文原文

【引用 BlackEye on July 25, 2010, 10:12:23 PM（https://bitcointalk.org/index.php?topic=453.msg5774#msg5774）】

"I was able to integrate the SHA256 functionality from Crypto++ 5.6.0 into Bitcoin. This is the fastest SHA256 yet using the SSE2 assembly code. Since Bitcoin was sending unaligned data to the block hash function, I had to change the MOVDQA instruction to MOVDQU.

I think using the SHA256 functionality from Crypto++ 5.6.0 is the way forward right now.
"
I added a subset of the Crypto++ 5.6.0 library to the SVN. I stripped it down to just SHA and 11 general dependency files. There shouldn't be any other crypto in there other than SHA.

I aligned the data fields and it worked. The ASM SHA-256 is about 48% faster. The combined speedup is about 2.5x faster than version 0.3.3.

I guess it's using SSE2. It automatically sets its build configuration at compile time based on the compiler environment.

It looks like it has some SSE2 detection at runtime, but it's hard to tell if it actually uses it to fall back if it's not available. I want the release builds to have SSE2. SSE2 has been around since the first Pentium 4. A Pentium 3 or older would be so slow, you'd be wasting your electricity trying to generate on it anyway.

This is SVN rev 114.

Re: Bitcoin x86 for Windows

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Bitcoin x86 for Windows

Date2010-07-27 19:47:42 UTC

ForumBitcointalk · 原文

好的，谢谢。我还想知道，只要不开启挖矿（Generate），它是否能正常运行。按理说，只要不实际执行 SSE2 指令，它应该还是能加载的。至少 Pentium 3 的机器可以在不开挖矿的情况下运行它。

英文原文

OK, thanks. I'd also like to know if it runs fine as long as you don't turn on Generate. You'd think as long as it doesn't actually execute any SSE2 instructions, it would still load. At least Pentium 3's could run it without generating.

Re: Having problems specifing -datadir

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Having problems specifing -datadir

Date2010-07-28 20:58:26 UTC

ForumBitcointalk · 原文

我复现了这个问题。数据库不喜欢相对路径。

"bitcoind -datadir=./subdir getinfo" 对运行中的守护进程有效，但以 "bitcoind -datadir=./subdir" 启动守护进程就会报那个异常。

我想我们应该在传给数据库之前先解析出完整路径。

看来你是第一个用相对路径使用 -datadir 的人。

英文原文

It was able to reproduce this. The database doesn't like the relative path.

"bitcoind -datadir=./subdir getinfo" works against a running daemon, but trying to start the daemon as "bitcoind -datadir=./subdir" gets that exception.

I guess we should resolve the full path before passing it to the database.

It looks like you were the first one to ever use -datadir with a relative path.

Re: Build error SVN r115 on my Mac: workaround

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Build error SVN r115 on my Mac: workaround

Date2010-07-28 21:23:23 UTC

ForumBitcointalk · 原文

我在 OSX 构建中就只搞坏了那一个地方吗？！只改那一处之后真的能用吗？

makefile.vc 我也得这么改。它能编译，但 SHA-256 工作不正常；每次都返回同一个错误的哈希。

我们先禁用它，如果有人搞清楚怎么修，到时候再重新启用。即便如此，仅中间状态（midstate）优化就带来了 1.7 倍的提速。

Crypto++ ASM SHA-256 在 Linux 和 Windows（MinGW）的 GCC 下都能工作。

我已把 makefile.osx 的修改上传到 SVN。（如果现在能编译了请告诉我）

英文原文

Was that the only thing I broke in the OSX build?! Does it actually work after just that one change?

I had to do that for makefile.vc also. It compiled, but SHA-256 didn't work correctly; it returned the same incorrect hash each time.

We'll disable it now, and if anyone figures out how to fix it, we can re-enable it then. It's still 1.7x faster from the midstate optimisation.

The Crypto++ ASM SHA-256 works with GCC on Linux and Windows (MinGW).

I uploaded this makefile.osx change to SVN. (let me know if that compiles now)

Re: Difficulty

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Difficulty

Date2010-07-29 01:16:23 UTC

ForumBitcointalk · 原文

你看错代码了。起作用的是这段代码：

Code:
bool CBlock::CheckBlock() const
{
...
// Check timestamp
if (nTime > GetAdjustedTime() + 2 * 60 * 60)
return error("CheckBlock() : block timestamp too far in the future");
...

bool CBlock::AcceptBlock()
{
...
// Check timestamp against prev
if (nTime <= pindexPrev->GetMedianTimePast())
return error("AcceptBlock() : block's timestamp is too early");

时间戳最多允许超前未来 2 小时。它可以比前一个区块更早，但必须大于最近 11 个区块时间的中位数。之所以这样设计，是为了在前一个区块的时间太超前（比如这次发生的情况）时，下一个区块能把时间纠正回来。

英文原文

You were looking at the wrong code. Here's the code that applies:

Code:
bool CBlock::CheckBlock() const
{
...
// Check timestamp
if (nTime > GetAdjustedTime() + 2 * 60 * 60)
return error("CheckBlock() : block timestamp too far in the future");
...

bool CBlock::AcceptBlock()
{
...
// Check timestamp against prev
if (nTime <= pindexPrev->GetMedianTimePast())
return error("AcceptBlock() : block's timestamp is too early");

The timestamp is limited to up to 2 hours in the future. It can be earlier than the previous block, but it must be greater than the median of the last 11 blocks. The reason for doing it that way is so the time can get corrected in the next block if the previous block had the time too far in the future, like what happened.

Re: Scalability and transaction rate

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Scalability and transaction rate

Date2010-07-29 02:00:38 UTC

ForumBitcointalk · 原文

当前每个用户都是网络节点，这并不是为大规模应用设计的配置。那就好比每个 Usenet 用户都运行自己的 NNTP 服务器。设计上支持让用户仅仅是用户。运行节点的负担越重，节点就越少。剩下的少数节点会是大型服务器集群。其余的都是只做交易、不挖矿的客户端节点。

【引用 bytemaster 于 2010年7月28日 20:59:42（https://bitcointalk.org/index.php?topic=532.msg6269#msg6269）】

"再说，10 分钟确认一笔支付是否有效太长了。它得像今天刷信用卡一样快。"
请看自动售货机那个帖子，我在里面概述了支付处理商如何能够很好地验证支付——实际上是非常好（欺诈率远低于信用卡），大约 10 秒甚至更短。如果你不信或没看懂，抱歉，我没时间说服你。
http://bitcointalk.org/index.php?topic=423.msg3819#msg3819

英文原文

The current system where every user is a network node is not the intended configuration for large scale. That would be like every Usenet user runs their own NNTP server. The design supports letting users just be users. The more burden it is to run a node, the fewer nodes there will be. Those few nodes will be big server farms. The rest will be client nodes that only do transactions and don't generate.

【引用 bytemaster on July 28, 2010, 08:59:42 PM（https://bitcointalk.org/index.php?topic=532.msg6269#msg6269）】

"Besides, 10 minutes is too long to verify that payment is good. It needs to be as fast as swiping a credit card is today.
"
See the snack machine thread, I outline how a payment processor could verify payments well enough, actually really well (much lower fraud rate than credit cards), in something like 10 seconds or less. If you don't believe me or don't get it, I don't have time to try to convince you, sorry.
http://bitcointalk.org/index.php?topic=423.msg3819#msg3819

Re: wiki registration email?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: wiki registration email?

Date2010-07-29 02:10:46 UTC

ForumBitcointalk · 原文

什么鬼？我们怎么会聊到这个？据我所知，唯一的邮件是你在论坛里开启通知时发的，还有大概就是 wiki 注册邮件。我会考虑关掉论坛通知邮件，我都不知道为什么要有这个。

英文原文

WTF? How did we get on that? AFAIK, the only e-mail is if you tell the forum to do notifications, and I guess the wiki registration. I'd consider turning off the forum notification e-mails, I don't know why we have that.

* ALERT * Upgrade to 0.3.6

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

Title*** ALERT *** Upgrade to 0.3.6

Date2010-07-29 19:13:06 UTC

ForumBitcointalk · 原文

请尽快升级到 0.3.6！我们修复了一个实现缺陷：虚假交易有可能被显示为已接受。在升级到 0.3.6 之前，请不要接受比特币交易作为付款！

如果你不能马上升级到 0.3.6，最好先关闭你的比特币节点，直到完成升级。

0.3.6 还带来了更快的哈希速度：
- 中间状态（midstate）缓存优化，感谢 tcatm
- Crypto++ ASM SHA-256，感谢 BlackEye
挖矿总提速 2.4 倍。

下载：
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.6/

Windows 和 Linux 用户：如果你用的是 0.3.5，仍需升级到 0.3.6。

英文原文

Please upgrade to 0.3.6 ASAP! We fixed an implementation bug where it was possible that bogus transactions could be displayed as accepted. Do not accept Bitcoin transactions as payment until you upgrade to version 0.3.6!

If you can't upgrade to 0.3.6 right away, it's best to shut down your Bitcoin node until you do.

Also in 0.3.6, faster hashing:
- midstate cache optimisation thanks to tcatm
- Crypto++ ASM SHA-256 thanks to BlackEye
Total generating speedup 2.4x faster.

Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.6/

Windows and Linux users: if you got 0.3.5 you still need to upgrade to 0.3.6.

Re: * ALERT * version 0.3.6

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: *** ALERT *** version 0.3.6

Date2010-07-29 19:55:51 UTC

ForumBitcointalk · 原文

还没来得及更新 SVN。等 0.3.6 吧，我正在构建。与此同时你可以先关闭节点。

英文原文

Haven't had time to update the SVN yet. Wait for 0.3.6, I'm building it now. You can shut down your node in the meantime.

Re: * ALERT * version 0.3.6

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: *** ALERT *** version 0.3.6

Date2010-07-29 20:30:15 UTC

ForumBitcointalk · 原文

SVN 已更新到 0.3.6。

正在上传 0.3.6 的 Windows 构建版到 SourceForge，随后会重新构建 Linux 版。

英文原文

SVN is updated with version 0.3.6.

Uploading Windows build of 0.3.6 to Sourceforge now, then will rebuild linux.

Re: * ALERT * Upgrade to 0.3.6 ASAP!

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: *** ALERT *** Upgrade to 0.3.6 ASAP!

Date2010-07-29 21:20:38 UTC

ForumBitcointalk · 原文

0.3.6 的 Linux 构建版改回了旧的 makefile.unix。它静态链接了 libjpeg，所以应该没问题。

现在好用点了吗？

如果你遇到 22DbRunRecoveryException，而且之前用过别人构建的版本，你可能需要删除 database/log.000000*（或把这些文件移到别处）。

Windows 和 Linux 用户：如果你用的是 0.3.5，仍需升级到 0.3.6。

英文原文

0.3.6 Linux build is back to the old makefile.unix. It static links libjpeg so that shouldn't be a problem.

Is that working better?

If you got 22DbRunRecoveryException and you've used someone else's build before, you may need to delete (or move the files somewhere else) database/log.000000*

Windows and Linux users: if you got 0.3.5 you still need to upgrade to 0.3.6.

Re: * ALERT * Upgrade to 0.3.6 ASAP!

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: *** ALERT *** Upgrade to 0.3.6 ASAP!

Date2010-07-29 21:43:15 UTC

ForumBitcointalk · 原文

"./bitcoin: /lib64/libc.so.6: version `GLIBC_2.11' not found (required by./bitcoin)" 这个问题应该不是从 0.3.6 才开始的吧？它和 0.3.0 是在同样的系统上构建的。

不幸的是，我在 0.3.0 之前就升级到了 Ubuntu 10.04。我不会再升级了。不知道什么时候才有时间重装降级，但至少只要不再升级，这个问题会随着时间慢慢自己解决。

英文原文

"./bitcoin: /lib64/libc.so.6: version `GLIBC_2.11' not found (required by ./bitcoin)" isn't a new problem that started with 0.3.6 is it? This was built on the same OS installations as 0.3.0.

Unfortunately I upgraded to Ubuntu 10.04 before 0.3.0. I will not upgrade anymore. I don't know when I might have time to reinstall to downgrade, but at least by not upgrading, it'll gradually fix itself.

Re: Implementation bug prior to 0.3.6

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Implementation bug prior to 0.3.6

Date2010-07-29 22:04:15 UTC

ForumBitcointalk · 原文

其实直接给我发私信就行。修的人就是我。如果你发现了安全漏洞，我非常希望你能私下告诉我，以便在公开之前修复。

英文原文

Actually, it works well to just PM me. I'm the one who's going to be fixing it. If you find a security flaw, I would definitely like to hear from you privately to fix it before it goes public.

Re: Transaction disappeared in the void...

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Transaction disappeared in the void...

Date2010-07-29 22:08:31 UTC

ForumBitcointalk · 原文

如果交易一开始没能立刻发出，比如当时你没联网，它可能需要最多 2 小时才会重发。从长远看，它会坚持不懈地一直发送。

我会在未来版本中缩短这个时间。

你确实需要下载完完整的区块链（目前是 71040 个区块）才能看到确认数。收款方也一样。

英文原文

If the transaction didn't go out immediately at first, like if you weren't connected at the time, it may take up to 2 hours to resend it. Long term, it does keep relentlessly sending it.

I'll shorten that length of time in a future version.

You do need to have downloaded the complete block chain (currently 71040 blocks) before you'll see any confirms. Same with the recipient.

Re: Linux distribution download

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Linux distribution download

Date2010-07-29 22:17:24 UTC

ForumBitcointalk · 原文

是的，我非常清楚自己应该留在 9.04 或 9.10。降级比升级费事得多，而我最近时间很紧。Ubuntu 是最流行的发行版，所以我还是用它。

英文原文

Yeah, acutely aware that I should have stayed on 9.04 or 9.10. It's a lot more work to downgrade than upgrade and I've been squeezed for time. Ubuntu is the most popular distro, so I'm staying with that.

Re: * ALERT * Upgrade to 0.3.6 ASAP!

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: *** ALERT *** Upgrade to 0.3.6 ASAP!

Date2010-07-29 23:12:12 UTC

ForumBitcointalk · 原文

【引用 lachesis 于 2010年7月29日 22:14:36（https://bitcointalk.org/index.php?topic=626.msg6515#msg6515）】

"在 32 位 Debian testing 上，我遇到几个构建错误，都类似这样：
Code:"
script.cpp:114: error: ‘OP_NOP1’ was not declared in this scope
我在没有先执行 "make clean" 或 "make" 的情况下尝试 "make bitcoind" 时也遇到过这些错误。看起来 bitcoind 的构建说明没有先编译头文件，但也没有删除 headers.h.gch，所以如果存在旧的头文件就会继续用旧的。

如果还有人遇到这个错误，最简单的办法是执行 "make clean" 后重新构建。

我们其实并不需要预编译头文件。它只让编译稍微快一点。我想干脆把它去掉。即便如此，你还是得记住再执行一次 "make -f makefile.unix clean" 或删除 headers.h.gch，才能把残留文件清掉。

该死的 GLIBC_2.11。我还以为自己已经小心地拒绝了所有更新。

英文原文

【引用 lachesis on July 29, 2010, 10:14:36 PM（https://bitcointalk.org/index.php?topic=626.msg6515#msg6515）】

"On Debian testing 32-bit, I get a few build errors, all resembling:
Code:"
script.cpp:114: error: OP_NOP1 was not declared in this scope
I got these when attempting to "make bitcoind" without "make clean" or "make" first. It looks like the bitcoind build instructions don't compile the headers first, but they also don't delete the headers.h.gch, so the old headers are used if present.

If anyone else gets this error, the simplest solution is to "make clean" and retry the build.

We don't really need pre-compiled header. It only makes it compile slightly faster. I think I'll just get rid of it. Even still, you'd still need to remember to "make -f makefile.unix clean" or delete headers.h.gch one more time to get rid of the leftover file.

Damn that GLIBC_2.11. I thought I'd been careful not to accept any of the updates.

Re: Bug: "Immature" coins lost in wallet.dat during transaction

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Bug: "Immature" coins lost in wallet.dat during transaction

Date2010-07-30 19:19:05 UTC

ForumBitcointalk · 原文

我不明白它怎么会在币还没成熟时就让你发出。你的余额应该低于发送金额才对。它应该会显示余额 0.01，对吧？我试的时候它会说 "you don't have enough money"，命令行下则是 "Insufficient funds"。

你发送时它说还有多少个区块才成熟？

还有可能它仍会被确认。

你有没有以任何方式复制或移动过 wallet.dat？

英文原文

I don't get how it let you send if it was not matured. Your balance would have been lower than the amount. It would have said balance 0.01, right? If I try that it says "you don't have enough money" or "Insufficient funds" from the command line.

How many blocks did it say it had left to mature when you sent?

There's a chance it might still go through.

Have you copied or moved your wallet.dat in any way?

Re: [PATCH] implement 'listtransactions'

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: [PATCH] implement 'listtransactions'

Date2010-07-30 19:40:54 UTC

ForumBitcointalk · 原文

你需要用 listtransactions 来做什么？

我不实现 listtransactions 的原因是，我要确保网页程序员不会用它。用它来监控收款太容易让人上瘾了。那样做没有可靠的办法保证万无一失。在我们有成熟的示例代码，用 getreceivedbyaddress 和 getreceivedbylabel 指着说"用这个！用这个！别用 listtransactions！"之前，我认为不该实现 listtransactions。

等我们实现 listtransactions 时，对付这个问题的办法之一是让它只输出纯文本。它不应把字段拆成 comment、confirmations、credit、debit 之类。可以是一整串格式化好的字符串，比如 "0/unconfirmed 0:0:0 date comment debit 4 credit 0" 之类的，这样程序员就很难拿它去做错误的处理。它只用来查看服务器状态。我猜这对想把它排成 HTML 表格的网页界面来说会有点烦，不过也没办法。

英文原文

What are you needing to use listtransactions for?

The reason I didn't implement listtransactions is I want to make sure web programmers don't use it. It would be very easy to latch onto that for watching for received payments. There is no reliable way to do it that way and make sure nothing can slip through the cracks. Until we have solid example code using getreceivedbyaddress and getreceivedbylabel to point to and say "use this! use this! don't use listtransactions!", I don't think we should implement listtransactions.

When we do implement listtransactions, maybe one way to fight that is to make it all text. It should not break down the fields into e.g. comment, confirmations, credit, debit. It could be one pretty formatted string like "0/unconfirmed 0:0:0 date comment debit 4 credit 0" or something so it's hard for programmers to do the wrong thing and process it. It's only for viewing the status of your server. I guess that would be kinda annoying for web interfaces that would rather format it into html columns though.

Re: * ALERT * Upgrade to 0.3.6 ASAP!

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: *** ALERT *** Upgrade to 0.3.6 ASAP!

Date2010-07-30 19:53:06 UTC

ForumBitcointalk · 原文

【引用 knightmb 于 2010年7月30日 19:24:07（https://bitcointalk.org/index.php?topic=626.msg6702#msg6702）】

"我能想象你做出这些构建版有多痛苦，因为我正在一台 Ubuntu 9.04 的机器上编译这个程序，到目前为止无论装多少包、编多少源码，总是凑不齐所有依赖，哈哈。"
我不明白你为什么这么痛苦。我只是照着 build-unix.txt 里的说明做的。我对 Boost 1.37 做了几处小修正，下次更新 SVN 时会放上去，记在下面：

Dependencies
------------
sudo apt-get install build-essential
sudo apt-get install libgtk2.0-dev
sudo apt-get install libssl-dev
sudo apt-get install libdb4.7-dev
sudo apt-get install libdb4.7++-dev
sudo apt-get install libboost-all-dev (or libboost1.37-dev)

wxWidgets
---------
cd /usr/local
tar -xzvf wxWidgets-2.9.0.tar.gz
cd /usr/local/wxWidgets-2.9.0
mkdir buildgtk
cd buildgtk
../configure --with-gtk --enable-debug --disable-shared --enable-monolithic
make
sudo su
make install
ldconfig

在 makefile.unix 里加了一段注释：

# for boost 1.37, add -mt to the boost libraries
LIBS= \
-Wl,-Bstatic \
-l boost_system \
-l boost_filesystem \
-l boost_program_options \
-l boost_thread \
-l db_cxx \
-l crypto \
-Wl,-Bdynamic \
-l gthread-2.0

英文原文

【引用 knightmb on July 30, 2010, 07:24:07 PM（https://bitcointalk.org/index.php?topic=626.msg6702#msg6702）】

"I can only imagine the pain you went through to get these builds because I'm trying to build the program on a Ubuntu 9.04 box and so far I can't seem to find all the dependencies to compile no matter how much I keep installing packages and compiling source, LOL.
"
I can't understand why you're having so much pain. I just followed the instructions in build-unix.txt. I made a couple little corrections for Boost 1.37, which I'll put on SVN the next time I update it, noted below:

added a comment in makefile.unix:

Re: * ALERT * Upgrade to 0.3.6 ASAP!

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: *** ALERT *** Upgrade to 0.3.6 ASAP!

Date2010-07-30 21:44:04 UTC

ForumBitcointalk · 原文

【引用 knightmb 于 2010年7月30日 20:04:19（https://bitcointalk.org/index.php?topic=626.msg6713#msg6713）】

"所以最后那条命令应该直接是 sudo apt-get install libboost1.37-dev"
但这在 Boost 1.40+（Ubuntu 10.04）上行不通，那里需要装 libboost-all-dev。

最近 Boost 把很多东西都改了，"-mt" 之类的，搞得很难办。

顺便说一下，我试过 Boost 1.34，但它没有 boost.interprocess 那些东西。

Mac OSX 版本现在有了。见 bitcoin.org 或 SourceForge 链接。

英文原文

【引用 knightmb on July 30, 2010, 08:04:19 PM（https://bitcointalk.org/index.php?topic=626.msg6713#msg6713）】

"So that last command should simply be
sudo apt-get install libboost1.37-dev
"
Except that wouldn't work for boost 1.40+ (on Ubuntu 10.04), where you need to get libboost-all-dev.

Seems they changed everything around in Boost recently, "-mt" and all that, makes it hard.

BTW, I tried Boost 1.34 but it didn't have the boost.interprocess stuff.

Mac OSX version is available now. See bitcoin.org or the SourceForge link.

Re: 4 hashes parallel on SSE2 CPUs for 0.3.6

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: 4 hashes parallel on SSE2 CPUs for 0.3.6

Date2010-07-31 00:29:20 UTC

ForumBitcointalk · 原文

太厉害了……

你是说用 128 位寄存器以 SIMD 方式一次处理四个 32 位数据？我想了很久，但觉得由于加法进位会串到相邻的值，这应该不可能实现。

英文原文

That's amazing...

So are you saying you use 128-bit registers to SIMD four 32-bit data at once? I've wondered about that for a long time, but I didn't think it would be possible due to addition carrying into the neighbour's value.

Webpage idea: Next predicted difficulty change

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleWebpage idea: Next predicted difficulty change

Date2010-07-31 01:32:08 UTC

ForumBitcointalk · 原文

如果有人做个页面（就像 http://www.alloscomp.com/bitcoin/calculator.php 上那个好用的计算器），预测下一次难度调整会是多少，那就太好了。

预测难度调整倍数 =

自上次调整以来产生的区块数 / 2016
------------------------------------
自上次调整以来经过的时间 / 14 天

比如，如果只用了 3.5 天（而不是 7 天）就走完了一半的调整周期，我们预计难度会翻倍：

(1008/2016) / (3.5/14) = 0.5/0.25 = 2.0

它还可以显示预计的下次调整时间，以及上次调整的时间和幅度。

英文原文

It would be neat if someone had a page (like that handy calculator at http://www.alloscomp.com/bitcoin/calculator.php) that projects what the next difficulty adjustment will be.

projected difficulty adjustment multiplier =

blocks_since_last_adjustment / 2016
------------------------------------
time_since_last_adjustment / 14_days

For instance, if it already got half way to the next adjustment in only 3.5 days instead of 7, we would expect difficulty to double:

(1008/2016) / (3.5/14) = 0.5/0.25 = 2.0

Also, it could show the predicted time when the next adjustment will occur, and tell when the last adjustment was and how much it changed.

Re: Linux distribution download

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Linux distribution download

Date2010-07-31 14:38:52 UTC

ForumBitcointalk · 原文

它可以用 Boost 1.37 或更新版本构建。

英文原文

It can be built with Boost 1.37 or later.

Re: Linux version => No GUI after upgrade. WTF?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Linux version => No GUI after upgrade. WTF?

Date2010-08-02 17:39:27 UTC

ForumBitcointalk · 原文

控制台有输出什么吗？你确定你运行的不是 "bitcoind"？

试试 0.3.7 版本。

英文原文

Did it print anything to the console? Are you sure you didn't run "bitcoind"?

Try version 0.3.7.

Re: Mac Client Problems Outlined...

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Mac Client Problems Outlined...

Date2010-08-02 18:02:20 UTC

ForumBitcointalk · 原文

"Minimize to the tray instead of the taskbar"（最小化到托盘而非任务栏）和 "Minimize to the tray on close"（关闭时最小化到托盘）在 Mac 上大概还没实现。下个版本我们应该把它们置灰。

英文原文

"Minimize to the tray instead of the taskbar" & "Minimize to the tray on close" must not be implemented yet on the Mac. We should grey them out in the next version.

Re: 4 hashes parallel on SSE2 CPUs for 0.3.6

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: 4 hashes parallel on SSE2 CPUs for 0.3.6

Date2010-08-02 19:02:46 UTC

ForumBitcointalk · 原文

在 AMD 上是快 2 倍，在 Intel 上是慢一半吗？

【引用 tcatm 于 2010年7月31日 10:12:38（https://bitcointalk.org/index.php?topic=648.msg6797#msg6797）】

"顺便问下，既然 __attribute__ ((aligned (16))) 就能告诉编译器在编译时对齐，你为什么还用 alignup<16> 这个函数？"
试过了，但对栈上的东西不起作用。我做过测试。

它甚至不会报错，就是不对齐。

英文原文

Is it 2x fast on AMD and 1/2 fast on Intel?

【引用 tcatm on July 31, 2010, 10:12:38 AM（https://bitcointalk.org/index.php?topic=648.msg6797#msg6797）】

"Btw. Why are you using this alignup<16> function when __attribute__ ((aligned (16))) will tell the compiler to align at compiletime?
"
Tried that, but it doesn't work for things on the stack. I ran some tests.

It doesn't even cause an error, it just doesn't align it.

Re: Protocol Buffers for Bitcoin

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Protocol Buffers for Bitcoin

Date2010-08-02 20:22:08 UTC

ForumBitcointalk · 原文

我没用 protocol buffers 或 boost serialization，是因为它们看起来太复杂，无法做到绝对严密和安全。它们的代码量太大，读完也无法确信不存在某种能引发意外行为的输入构造方式。

我讨厌重复造轮子，是很不情愿才自己写序列化例程的。我们的序列化格式尽可能地简单扁平。输入流的构造方式没有任何多余的自由度。在每一处，接收方期待的就是数据结构中的下一个字段。给出的选择只有接收方预期的那些。有版本机制，所以升级是可行的。

CAddress 是唯一有可观预留空间的对象。（标志位约 7 字节，未来 IPv6 扩展约 12 字节）

像区块和交易这样的大对象在体积上已经没多少优化空间。它们的大部分数据是哈希、密钥和签名，这些都不可压缩。序列化开销非常小，长度字段通常只有 1 字节。

关于 Gavin 提到的现有 P2P 广播基础设施的想法，我怀疑根本不存在。只需要广播的 P2P 系统很少。有些库比如 Chord 试图提供分布式哈希表基础设施，但那是个我们不需要也不想要的巨大难题。那些库的安装难度也比我们自己大得多。

英文原文

The reason I didn't use protocol buffers or boost serialization is because they looked too complex to make absolutely airtight and secure. Their code is too large to read and be sure that there's no way to form an input that would do something unexpected.

I hate reinventing the wheel and only resorted to writing my own serialization routines reluctantly. The serialization format we have is as dead simple and flat as possible. There is no extra freedom in the way the input stream is formed. At each point, the next field in the data structure is expected. The only choices given are those that the receiver is expecting. There is versioning so upgrades are possible.

CAddress is about the only object with significant reserved space in it. (about 7 bytes for flags and 12 bytes for possible future IPv6 expansion)

The larger things we have like blocks and transactions can't be optimized much more for size. The bulk of their data is hashes and keys and signatures, which are uncompressible. The serialization overhead is very small, usually 1 byte for size fields.

On Gavin's idea about an existing P2P broadcast infrastructure, I doubt one exists. There are few P2P systems that only need broadcast. There are some libraries like Chord that try to provide a distributed hash table infrastructure, but that's a huge difficult problem that we don't need or want. Those libraries are also much harder to install than ourselves.

Re: Builds for Ubuntu?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Builds for Ubuntu?

Date2010-08-03 20:56:11 UTC

ForumBitcointalk · 原文

【引用 nimnul 于 2010年8月3日 17:51:15（https://bitcointalk.org/index.php?topic=454.msg7282#msg7282）】

"satoshi 的 noWx 补丁已经进 0.3.7 了吗？在那之前 bitcoind 需要 wx，而且我从没见 Satoshi 宣布过它进了主干"
有，0.3.7 里有。它在 rev 112 里。

英文原文

【引用 nimnul on August 03, 2010, 05:51:15 PM（https://bitcointalk.org/index.php?topic=454.msg7282#msg7282）】

"Is satoshi noWx patch in 0.3.7 already? Before that bitcoind required wx, and I never seen Satoshi announcing that it's in trunk
"
Yes, 0.3.7 has it. It was in rev 112.

Re: Bitcoind x86 binary for CentOS

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Bitcoind x86 binary for CentOS

Date2010-08-03 21:05:08 UTC

ForumBitcointalk · 原文

【引用 sgtstein 于 2010年8月3日 17:30:37（https://bitcointalk.org/index.php?topic=685.msg7275#msg7275）】

"我用 4.8 成功构建了，4.7 从来不行，但用 4.8 时，每当 bitcoind 把初始区块下载转存到磁盘就会卡死。"
我强烈建议你不要用 BDB 4.8。如果有人用了你的构建版再换回官方构建版，database/log0000* 文件会不兼容。

英文原文

【引用 sgtstein on August 03, 2010, 05:30:37 PM（https://bitcointalk.org/index.php?topic=685.msg7275#msg7275）】

"I have successfully built it with 4.8, 4.7 never would but with 4.8 bitcoind locks up whenever it dumps the initial block download to disk.
"
I urge you not to use BDB 4.8. The database/log0000* files will be incompatible if anyone uses your build and then goes back to the official build.

Re: Content-Length header and 500 (was Re: Authentication, JSON RPC and Python)

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Content-Length header and 500 (was Re: Authentication, JSON RPC and Python)

Date2010-08-03 21:26:26 UTC

ForumBitcointalk · 原文

【引用 gavinandresen 于 2010年8月3日 18:56:44（https://bitcointalk.org/index.php?topic=689.msg7299#msg7299）】

"
【引用 jgarzik 于 2010年8月3日 18:09:08（https://bitcointalk.org/index.php?topic=689.msg7288#msg7288）】
bitcoin 要求 Content-Length 头，但有几个 JSON-RPC 库不提供它。当 Content-Length 头缺失时，bitcoin 返回 500 Internal Server Error。
"
你能具体说是哪些 JSON 库不提供 Content-Length 吗？能记录下来就好了。

我想我们应该尝试支持没有 Content-Length 参数的情况。不过我不想大改流处理，即使不得不一次读一个字符。

补充：前提是真有不支持 Content-Length 的库存在。

英文原文

【引用 gavinandresen on August 03, 2010, 06:56:44 PM（https://bitcointalk.org/index.php?topic=689.msg7299#msg7299）】

"
【引用 jgarzik on August 03, 2010, 06:09:08 PM（https://bitcointalk.org/index.php?topic=689.msg7288#msg7288）】
bitcoin requires the Content-Length header, but several JSON-RPC libraries do not provide it. When the Content-Length header is absent, bitcoin returns 500 Internal Server Error.
"
Can you be more specific about which JSON libraries don't provide Content-Length ? It'd be nice to document that.

I guess we should try to support the case where there's no Content-Length parameter. I don't want to rip and replace streams though, even if it has to read one character at a time.

Edit: That is, assuming there actually are any libraries that don't support Content-Length.

Re: What happens when network is split for prolonged time and reconnected?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: What happens when network is split for prolonged time and reconnected?

Date2010-08-03 22:45:07 UTC

ForumBitcointalk · 原文

creighto：我同意这个想法。几小时后，客户端应该能察觉区块流是否以超出偶然可能的幅度减少。它能听出自己是不是再也听不到世界的"嗡鸣"了。

【引用 knightmb 于 2010年8月3日 19:02:13（https://bitcointalk.org/index.php?topic=661.msg7303#msg7303）】

"
【引用 gavinandresen 于 2010年8月3日 18:38:44（https://bitcointalk.org/index.php?topic=661.msg7293#msg7293）】
或者，如果分叉持续得够久（超过 100 个区块），涉及较短链上生成币的交易在合并时就会失效。
"
有意思的信息，所以除了一些双重支付问题，只要区块链分离不超过 100 来个区块（或 16 个多小时），

实际上，分叉很可能极不对称。把世界对半分开很难。更可能是一个国家对世界其他地区，比如 1:10 的分叉。这种情况下，少数分叉生成 100 个区块要花 10 倍的时间，也就是大约 7 天。而且客户端会非常容易察觉自己听到的区块太少，肯定出问题了。

【引用 knightmb 于 2010年8月3日 19:02:13（https://bitcointalk.org/index.php?topic=661.msg7303#msg7303）】

"分叉延迟有硬编码的上限吗？意思是，如果我的小网络和公共网络分离了，在里面花了些币，几天后回来再和公共网络同步（除了可能发生的币生成），交易应该没问题吧？"
没有时间限制。只要你花的不是在少数分叉上生成的币，也不是花掉了收到的别人的双重支付，你的交易之后随时都能进入另一条链。

英文原文

creighto: I agree with that idea. After a few hours, it should be possible for the client to notice if the flow of blocks has dropped off by more than would be likely just by chance. It could tell if it's not hearing the hum of the world anymore.

【引用 knightmb on August 03, 2010, 07:02:13 PM（https://bitcointalk.org/index.php?topic=661.msg7303#msg7303）】

"
【引用 gavinandresen on August 03, 2010, 06:38:44 PM（https://bitcointalk.org/index.php?topic=661.msg7293#msg7293）】
Or if the split lasted long enough (more than 100 blocks), transactions that involve generated coins on the shorter chain would be invalid at the merge.
"
Interesting info, so other than some double-spending issues, as long as the block chain isn't separated for more than 100 or so blocks (or 16+ hours),

In practice, splits are likely to be very asymmetrical. It would be hard to split the world down the middle. More likely it would be a single country vs the rest of the world, lets say a 1:10 split. In that case, it would take the minority fork 10 times as long to generate 100 blocks, so about 7 days. Also it would be super easy for the client to realize it's hearing way too few blocks and something must be wrong.

【引用 knightmb on August 03, 2010, 07:02:13 PM（https://bitcointalk.org/index.php?topic=661.msg7303#msg7303）】

"If there a hard coded limit on split delay? Meaning if I had a small network split from the public network, spent some coin around, came back a few days later and got them sync up to the public network (other than coin generation if it happened) transactions should be fine?
"
There's no time limit. Assuming you weren't spending coins generated in the minority fork, or spending someone's double-spends you received, your transactions can get into the other chain at any time later.

Please upgrade to 0.3.8!

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitlePlease upgrade to 0.3.8!

Date2010-08-03 23:40:18 UTC

ForumBitcointalk · 原文

0.3.8 版本加入了一项重要的安全改进。每个人都应该升级以获得这项改动。

新的安全功能会在检测到可能需要升级的问题时，在状态栏显示警告信息并锁定 RPC。

如果它看到一条更长的链却无法处理，就知道出问题了。它会显示 "WARNING: Displayed transactions may not be correct! You may need to upgrade."（警告：显示的交易可能不正确！你可能需要升级。），并让大多数 RPC 命令返回错误。它仍会像往常一样继续挖矿，这对网络稳定是必要的。

之前的版本也有重要的安全更新，所以如果你最近没升级过，现在升级极其重要！

另外别忘了，我们最近加入了 2.4 倍的挖矿提速，感谢 tcatm 的中间状态缓存优化和 BlackEye 帮忙搞定 ASM SHA-256。

下载：
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.8/

英文原文

Version 0.3.8 adds an important security improvement. Everyone should upgrade to get this change.

The new safety feature displays a warning message in the status bar and locks down RPC if it detects a problem that may require an upgrade.

If it sees a longer chain, but it can't process it, then it knows something is wrong. It displays "WARNING: Displayed transactions may not be correct! You may need to upgrade." and makes most RPC commands return an error. It still keeps generating as normal, which is necessary for the stability of the network.

There were important security updates in the versions before this too, so if you haven't upgraded recently, it's extremely important that you upgrade now!

Also, don't forget, we recently added 2.4x faster generating thanks to tcatm's mid-state caching optimisation and BlackEye's help getting ASM SHA-256 working.

Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.8/

Re: Bitcoind x86 binary for CentOS

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Bitcoind x86 binary for CentOS

Date2010-08-04 00:09:32 UTC

ForumBitcointalk · 原文

【引用 knightmb 于 2010年8月3日 23:46:46（https://bitcointalk.org/index.php?topic=685.msg7365#msg7365）】

"有两个版本，一个用原生代码构建，另一个修改过，最多可接受 1000 个节点（所以叫超级节点）"
我希望你不要发布那个支持 1000 节点连接的构建版。用不了多少人运行它，我们就得再发一个版本专门限制入站连接了。

英文原文

【引用 knightmb on August 03, 2010, 11:46:46 PM（https://bitcointalk.org/index.php?topic=685.msg7365#msg7365）】

"There are two versions, one built from stock code, the other modified to accept up to 1,000 nodes (hence the super node name)
"
I'd rather you didn't make a build of the 1000 node connecting version available. It won't take very many people running that before we have to make another release just to limit the incoming connections.

Re: Please upgrade to 0.3.8!

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Please upgrade to 0.3.8!

Date2010-08-04 00:29:37 UTC

ForumBitcointalk · 原文

我猜 SourceForge 的镜像还没更新。文件在管理端有了，但用户端还没有。我不知道要多久。以前都是一更新就同步的。

补充：SourceForge 现在更新了。

英文原文

I guess SourceForge hasn't updated its mirrors yet. The files are there on the admin side, but not on the user side. I have no idea how long that will take. It's always been immediate in the past.

Edit: SourceForge is updated now.

Re: Building initial transaction trust through "coin ripping"

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Building initial transaction trust through "coin ripping"

Date2010-08-04 00:40:40 UTC

ForumBitcointalk · 原文

软件就是设计成支持这类事情的。我本来打算发布托管（Escrow）方案的细节，但自从被 Slashdot 报道后就一直没时间。

英文原文

The software is designed to support things like this. I was going to post details of the plans for Escrow, but since getting slashdotted I haven't had time.

Re: Flood attack 0.00000001 BC

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Flood attack 0.00000001 BC

Date2010-08-04 16:25:36 UTC

ForumBitcointalk · 原文

【引用 Insti 于 2010年8月4日 14:58:31（https://bitcointalk.org/index.php?topic=287.msg7498#msg7498）】

"它似乎弊大于利，因为它阻碍了微支付的实现，比如 bytemaster 提议的那种。"
比特币目前对非常小的微支付并不实用。比如按次搜索付费或按页面浏览付费，如果没有聚合机制就不行；需要支付少于 0.01 的也不行。粉尘垃圾交易限制是第一次有意尝试阻止这类过小的微支付。

比特币适用于比现有支付方式所能处理的更小的交易。小到可以覆盖你所说的微支付区间的高端。但它并不声称对任意小的微支付都实用。

英文原文

【引用 Insti on August 04, 2010, 02:58:31 PM（https://bitcointalk.org/index.php?topic=287.msg7498#msg7498）】

"It seems to do more harm than good because it prevents micropayment implementations such as the one bytemaster is suggesting."
Bitcoin isn't currently practical for very small micropayments. Not for things like pay per search or per page view without an aggregating mechanism, not things needing to pay less than 0.01. The dust spam limit is a first try at intentionally trying to prevent overly small micropayments like that.

Bitcoin is practical for smaller transactions than are practical with existing payment methods. Small enough to include what you might call the top of the micropayment range. But it doesn't claim to be practical for arbitrarily small micropayments.

Re: Flood attack 0.00000001 BC

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Flood attack 0.00000001 BC

Date2010-08-05 16:03:21 UTC

ForumBitcointalk · 原文

忘了补充微支付的好消息。虽然我认为比特币目前对较小的微支付还不实用，但随着存储和带宽成本持续下降，它最终会实用的。如果比特币大规模流行起来，到那时可能已经实现了。另一个让它们更实用的办法是，我实现纯客户端模式，让网络节点数量收敛到少数专业服务器集群。无论你需要多小的微支付，最终都会变得实用。我觉得 5 到 10 年后，带宽和存储都会显得微不足道。

我不是说这个网络能免疫 DoS 攻击。我认为大多数点对点网络都可以用多种方式被 DoS 攻击。（顺便说一句，我读到唱片公司很想 DoS 掉所有文件共享网络，但他们不想违反反黑客/反滥用法。）

如果我们开始遭到 DoS 攻击，大量垃圾交易来回发送，你就需要开始支付 0.01 的最低交易费。0.1.5 其实有设置这个的选项，但我为了减少困惑把它拿掉了。免费交易很好，只要大家不滥用，我们就可以一直保持免费。

这就引出一个问题：如果每笔交易有 0.01 的最低手续费，而只是最低的 0.01，我们应该自动加上吗？每次都问会很烦。如果你有 50.00，要转出 10.00，收款方会得到 10.00，你还剩 39.99。我觉得应该直接自动加上。跟很多其他服务自动加的费用比起来，这微不足道。

【引用 FreeMoney 于 2010年8月4日 19:30:32（https://bitcointalk.org/index.php?topic=287.msg7569#msg7569）】

"多打包交易会降低你的哈希速率吗？"
完全不会。

英文原文

Forgot to add the good part about micropayments. While I don't think Bitcoin is practical for smaller micropayments right now, it will eventually be as storage and bandwidth costs continue to fall. If Bitcoin catches on on a big scale, it may already be the case by that time. Another way they can become more practical is if I implement client-only mode and the number of network nodes consolidates into a smaller number of professional server farms. Whatever size micropayments you need will eventually be practical. I think in 5 or 10 years, the bandwidth and storage will seem trivial.

I am not claiming that the network is impervious to DoS attack. I think most P2P networks can be DoS attacked in numerous ways. (On a side note, I read that the record companies would like to DoS all the file sharing networks, but they don't want to break the anti-hacking/anti-abuse laws.)

If we started getting DoS attacked with loads of wasted transactions back and forth, you would need to start paying a 0.01 minimum transaction fee. 0.1.5 actually had an option to set that, but I took it out to reduce confusion. Free transactions are nice and we can keep it that way if people don't abuse them.

That brings up the question: if there was a minimum 0.01 fee for each transaction, should we automatically add the fee if it's just the minimum 0.01? It would be awfully annoying to ask each time. If you have 50.00 and send 10.00, the recipient would get 10.00 and you'd have 39.99 left. I think it should just add it automatically. It's trivial compared to the fees many other types of services add automatically.

【引用 FreeMoney on August 04, 2010, 07:30:32 PM（https://bitcointalk.org/index.php?topic=287.msg7569#msg7569）】

"Does including more slow down your hashing rate?
"
No, not at all.

Re: Flood attack 0.00000001 BC

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Flood attack 0.00000001 BC

Date2010-08-05 16:30:20 UTC

ForumBitcointalk · 原文

【引用 bytemaster】

"支付通常是预付的，比如一次 1 BTC，连接关闭时把"找零"退回。这条规则让为一次简单的"搜索查询"付费、而不再有后续交易变得不可能。"
一个替代方案是用凑整系统。你一次支付比如 1000 个页面、图片、下载或搜索的费用。用完这 1000 个，再付下一个 1000 个。即使你只用了 1 个，还剩 999 个可能永远用不上，也没关系，因为每 1000 个的成本仍然很小。

或者按天付费。某天第一次访问网站时，支付 24 小时的访问费。

按 1000 个或按天计费，消费者也更容易理解。他们担心按次计费，是因为难算清会不会越积越多。24 小时无限量他们知道费用是多少。或者如果 1000 个看起来绰绰有余，他们觉得 1000 个肯定够用，就不会担心每次点击都在多花钱。

英文原文

【引用 bytemaster】

"Payments would generally be advanced, say 1 BTC at a time and when the connection closes any "change" would be returned. This rule makes it impossible to pay for a simple "search query" with no further transactions.
"
One alternative is to use a round-up system. You pay for, say, 1000 pages or images or downloads or searches or whatever at a time. When you've used up your 1000 pages, you pay for another 1000 pages. If you only use 1 page, then you have 999 left that you may never use, but it's not a big deal because the cost per 1000 is still small.

Or you could pay per day. The first time you access the site on a given day, you pay for 24 hours of access.

Per 1000 or per day may be easier for consumers to get their heads around too. They worry about per item because it's harder to figure if it might add up too fast. Unlimited for 24 hours they know what the cost will be. Or if 1000 seems like plenty, they're not worrying that it's costing more with each click if they figure 1000 is more than they'll probably use.

Re: Flood attack 0.00000001 BC

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Flood attack 0.00000001 BC

Date2010-08-05 16:39:58 UTC

ForumBitcointalk · 原文

【引用 bytemaster 于 2010年8月5日 15:39:19（https://bitcointalk.org/index.php?topic=287.msg7684#msg7684）】

"解决这个问题的唯一办法是让交易广播"不免费"。也就是说，如果你想让我打包你的交易，你得付我钱。最终（无双关意）的结果是，每个客户端甚至在向其他客户端发送交易时就得付钱，而不只是付给把它打包进区块的那个人。这样经济规律就会起作用，没人能在交易广播系统里搭便车。"
我不知道怎么实现这个。给区块创建者的交易费用了个特殊技巧，可以在不增加任何体积的情况下包含交易费。如果每笔交易费都要对应一笔交易，那交易费的交易的交易费又怎么办？

英文原文

【引用 bytemaster on August 05, 2010, 03:39:19 PM（https://bitcointalk.org/index.php?topic=287.msg7684#msg7684）】

"The only solution to this problem is to make broadcasting of a transaction "non free". Namely, if you want me to include it you have to pay me. The net (no pun intended) result is that each client would need to pay other clients to whom they even send their transaction, not just the individual who gets it in a block. In this way the laws of economics take over and no one gets a free ride on the transaction broadcast system.
"
I don't know a way to implement that. The transaction fee to the block creator uses a special trick to include the transaction fee without any additional size. If there was a transaction for each transaction fee, then what about the transactions fees for the transaction fee's transaction?

Re: Who's the Spanish jerk draining the Faucet?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Who's the Spanish jerk draining the Faucet?

Date2010-08-05 17:06:03 UTC

ForumBitcointalk · 原文

静默失败会很难看。

【引用 gavinandresen 于 2010年8月4日 20:40:55（https://bitcointalk.org/index.php?topic=704.msg7575#msg7575）】

"1. 按 IP 地址的第一个字节限速（这次是 79. 或 81.）。"
确实需要。你打算定什么速率？归根结底，限速总比被全部掏空好。

【引用 gavinandresen 于 2010年8月4日 20:40:55（https://bitcointalk.org/index.php?topic=704.msg7575#msg7575）】

"3. 按 IP 地址反向 DNS 查询的最后两级域名限速（这次是 rima-tde.net）。"
这招可能会出奇地好用。如果有效，就能让他们碰不到速率上限，但速率上限仍是最后一道防线。

【引用 gavinandresen 于 2010年8月4日 20:40:55（https://bitcointalk.org/index.php?topic=704.msg7575#msg7575）】

"4. 把标准发放量降到 0.5 个比特币（自从我开水龙头以来，比特币涨了 10 倍）。"
确实该降了。

英文原文

Silently failing would look bad.

【引用 gavinandresen on August 04, 2010, 08:40:55 PM（https://bitcointalk.org/index.php?topic=704.msg7575#msg7575）】

"1. Rate limit based on the first byte of the IP address (79. or 81. in this case).
"
Definitely needed. What rate are you thinking of? Ultimately, it's better to rate limit it than to let it all drain out.

【引用 gavinandresen on August 04, 2010, 08:40:55 PM（https://bitcointalk.org/index.php?topic=704.msg7575#msg7575）】

"3. Rate limit based on last two domains of reverse DNS lookup of the IP address (rima-tde.net in this case).
"
That might work surprisingly well. If it works, it keeps them from hitting the rate limit, but the rate limit is there as the last line of defence.

【引用 gavinandresen on August 04, 2010, 08:40:55 PM（https://bitcointalk.org/index.php?topic=704.msg7575#msg7575）】

"4. Make the standard amount given away 0.5 Bitcoins (Bitcoins have gone up 10 times in value since I started the Faucet).
"
Definitely time to lower it.

Re: bitcoind transaction to ip address

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: bitcoind transaction to ip address

Date2010-08-05 17:28:40 UTC

ForumBitcointalk · 原文

没实现。

事实证明反正没人喜欢那种转账方式，所以它没得到多少开发关注。

英文原文

It's not implemented.

It turned out nobody liked that mode of transfer anyway, so it hasn't had much development attention.

Re: Transaction Overload Solution

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Transaction Overload Solution

Date2010-08-05 17:38:21 UTC

ForumBitcointalk · 原文

我想不出实现它的办法。所有的交易费都会变成额外的交易。那交易费的交易的交易费又怎么办？

英文原文

I can't think of a way to implement that. All the transaction fees would be additional transactions. What about the transaction fees for the transaction fee's transaction?

Re: Flood attack 0.00000001 BC

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Flood attack 0.00000001 BC

Date2010-08-05 17:49:43 UTC

ForumBitcointalk · 原文

【引用 bytemaster 于 2010年8月5日 16:46:52（https://bitcointalk.org/index.php?topic=287.msg7699#msg7699）】

"现在交易费地址是留"空"的，由区块生成者填写。现在你会把它填成你请来打包区块的人的地址。"
如果只让一个人来打包区块，那可能要花好几天。哦，你的意思是给每个节点发一个不同版本，把交易费写给他们？

现在的方式是，谁打包出来就归谁。

如果有需要，我们可以为交易广播搞一个类似 BitTorrent 的针锋相对机制：把付费交易中继给我，否则我就不中继给你。不过这大概不会成为真正的问题。只要有一个节点按规矩中继，就能抵消另外 7 个贪婪不中继的节点。

英文原文

【引用 bytemaster on August 05, 2010, 04:46:52 PM（https://bitcointalk.org/index.php?topic=287.msg7699#msg7699）】

"Right now the transaction fee address is left "blank" and the block generator fills it out.
Now you would fill it in with the address of the person you are asking to build the block.
"
If you're only going to have one person work on building the block, that could take days. Oh, do you mean send a different variation to each node with the tx fee written to them?

The way it is now, it's whoever builds this gets it.

If we needed to, we could have a BitTorrent-esque tit-for-tat for transaction broadcast. Relay paying transactions to me, or I won't relay them to you. It probably won't be an actual problem though. It only takes one node relaying like it should to cancel out 7 others greedily not relaying.

Re: A proposal for a semi-automated Escrow mechanism

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: A proposal for a semi-automated Escrow mechanism

Date2010-08-05 18:08:30 UTC

ForumBitcointalk · 原文

可以写一笔需要两个签名才能花掉的交易。你写一笔付款，要求收款方和付款方双方的签名才能花掉。要解除托管，你把自己那一半的签名给收款方；或者收款方也可以把他签好的一半给你，把钱退回。这种简单情形下没有中间人。最后的手段就是永远拒绝释放，实质上等于把钱烧掉。

英文原文

A transaction can be written that requires two signatures to spend it next. You write a payment that requires the signature of both the recipient and the sender to spend it. To release the escrow, you give the recipient the signature for your half, or the payee can return it by giving you his signed half. There's no mediator in this simple case. The recourse is to refuse to ever release it, essentially burning the money.

Re: latency and locality

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: latency and locality

Date2010-08-07 16:28:17 UTC

ForumBitcointalk · 原文

一旦脱离"每个节点的影响力与其 CPU 算力成正比"的体系，你还能用什么来判断谁（大致）是一个人？

英文原文

Once you get away from a system where each node's influence is proportional to their CPU power, then what else do you use to determine who is (approximately) one person?

Re: Bitcoin minting is thermodynamically perverse

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Bitcoin minting is thermodynamically perverse

Date2010-08-07 17:46:09 UTC

ForumBitcointalk · 原文

这和黄金与金矿开采的情况一样。黄金开采的边际成本往往贴近金价。金矿开采是一种浪费，但这种浪费远小于拥有黄金作为交换媒介所带来的效用。

我认为比特币也会一样。比特币促成的交易所带来的效用，将远远超过所耗电力的成本。所以，没有比特币才是净浪费。

【引用 gridecon 于 2010年8月6日 16:48:00（https://bitcointalk.org/index.php?topic=721.msg7889#msg7889）】

"总的来说，我也不同意"生成币的巨大计算负担是当前系统的必要条件"这一说法。据我理解，货币创造本质上是以时间为度量的——如果时间是根本的控制变量，那为什么每个人还要在给定的时间段内"尽可能多地掷骰子"？"币所有权和交易的"证明链"并不依赖于生成币的方法。"
每个节点对网络的影响力与其 CPU 算力成正比。向网络证明你有多少 CPU 算力的唯一办法，就是真正用起来。

如果还有别的每人拥有量有限、可以用来实现一人一票的东西，我想不出来。IP 地址……比 CPU 容易弄到大量得多。

我想也许可以在某些时刻测量 CPU 算力。比如，CPU 算力挑战平均每 10 分钟只运行 1 分钟。这样不用一直运行，也能在给定时刻证明你的总算力。不过我不确定这怎么实现。一个当时不在场的节点没法知道，过去的链到底是在带 9 分钟休息的工作周期里生成的，而不是连续生成的。

工作量证明有个很好的特性：它可以通过不可信的中间人传递。我们不用担心通信的保管链问题。不管是谁告诉你最长链，工作量证明自己会说话。

英文原文

It's the same situation as gold and gold mining. The marginal cost of gold mining tends to stay near the price of gold. Gold mining is a waste, but that waste is far less than the utility of having gold available as a medium of exchange.

I think the case will be the same for Bitcoin. The utility of the exchanges made possible by Bitcoin will far exceed the cost of electricity used. Therefore, not having Bitcoin would be the net waste.

【引用 gridecon on August 06, 2010, 04:48:00 PM（https://bitcointalk.org/index.php?topic=721.msg7889#msg7889）】

"As an overall point, I also do not agree with the idea that the very high computational burden of coin generation is in fact a necessity of the current system. As I understand it, currency creation is fundamentally metered by TIME - and if that is the fundamental controlling variable, what is the need for everyone to "roll as many dice as posible" within that given time period? The "chain of proof" for coin ownership and transactions doesn't depend on the method for spawning coins.
"
Each node's influence on the network is proportional to its CPU power. The only way to show the network how much CPU power you have is to actually use it.

If there's something else each person has a finite amount of that we could count for one-person-one-vote, I can't think of it. IP addresses... much easier to get lots of them than CPUs.

I suppose it might be possible to measure CPU power at certain times. For instance, if the CPU power challenge was only run for an average of 1 minute every 10 minutes. You could still prove your total power at given times without running it all the time. I'm not sure how that could be implemented though. There's no way for a node that wasn't present at the time to know that a past chain was actually generated in a duty cycle with 9 minute breaks, not back to back.

Proof-of-work has the nice property that it can be relayed through untrusted middlemen. We don't have to worry about a chain of custody of communication. It doesn't matter who tells you a longest chain, the proof-of-work speaks for itself.

Re: A proposal for a semi-automated Escrow mechanism

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: A proposal for a semi-automated Escrow mechanism

Date2010-08-07 20:04:59 UTC

ForumBitcointalk · 原文

【引用 jgarzik 于 2010年8月5日 19:00:30（https://bitcointalk.org/index.php?topic=645.msg7723#msg7723）】

"由于存在这种最后手段，它不太可能被用作托管机制"
真的吗？你觉得人们理解不了它的好处？（如果你回应的论点是它根本没有任何好处，那我想这正好印证了人们理解不了它。）

英文原文

【引用 jgarzik on August 05, 2010, 07:00:30 PM（https://bitcointalk.org/index.php?topic=645.msg7723#msg7723）】

"Due to that recourse, it is unlikely to be used as an escrow mechanism
"
Really? Do you think people won't be able to understand the benefit? (If your response is an argument that there's no benefit at all, I guess that will reinforce the case that people won't be able to understand it.)

Escrow

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleEscrow

Date2010-08-07 20:13:52 UTC

ForumBitcointalk · 原文

下面概述一种软件上可行的托管交易。这还没实现，我近期大概也没时间实现，只是让你知道什么是可能的。

基本托管：买家把一笔付款提交到托管中。卖家收到一笔钱在托管中的交易，但在买家解锁之前他花不掉。买家此后随时可以释放这笔付款，也可能永远不释放。这不允许买家把钱拿回去，但给了他一个选择：永远不释放，赌气把钱烧掉。卖家也有选择把钱退回给买家。

这个系统虽然不能保证双方不受损失，但它让作弊无利可图。

如果卖家不发货，他就拿不到钱。买家还是会损失这笔钱，但至少卖家没有骗他的金钱动机。

买家无法通过不付款获利。他拿不回托管的钱。他不可能因为资金不足而付不出。卖家能看到资金已锁定到他的密钥上，无法转给别人。

这时，经济学家会说，欺诈的卖家可能会开始谈判，比如"放款吧，我退你一半"，但到那时，信任已经所剩无几、怨恨却那么多，谈判不太可能发生。骗子既然已经在为行骗而食言，凭什么会守信用退你一半？我想对于不大的金额，几乎所有人光凭原则就会拒绝。

英文原文

Here's an outline of the kind of escrow transaction that's possible in software. This is not implemented and I probably won't have time to implement it soon, but just to let you know what's possible.

The basic escrow: The buyer commits a payment to escrow. The seller receives a transaction with the money in escrow, but he can't spend it until the buyer unlocks it. The buyer can release the payment at any time after that, which could be never. This does not allow the buyer to take the money back, but it does give him the option to burn the money out of spite by never releasing it. The seller has the option to release the money back to the buyer.

While this system does not guarantee the parties against loss, it takes the profit out of cheating.

If the seller doesn't send the goods, he doesn't get paid. The buyer would still be out the money, but at least the seller has no monetary motivation to stiff him.

The buyer can't benefit by failing to pay. He can't get the escrow money back. He can't fail to pay due to lack of funds. The seller can see that the funds are committed to his key and can't be sent to anyone else.

Now, an economist would say that a fraudulent seller could start negotiating, such as "release the money and I'll give you half of it back", but at that point, there would be so little trust and so much spite that negotiation is unlikely. Why on earth would the fraudster keep his word and send you half if he's already breaking his word to steal it? I think for modest amounts, almost everyone would refuse on principle alone.

Re: 4 hashes parallel on SSE2 CPUs for 0.3.6

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: 4 hashes parallel on SSE2 CPUs for 0.3.6

Date2010-08-07 21:16:01 UTC

ForumBitcointalk · 原文

【引用 impossible7 于 2010年8月6日 11:37:20（https://bitcointalk.org/index.php?topic=648.msg7838#msg7838）】

"CRITICAL_BLOCK 是一个包含 for 循环的宏。断言失败表明在循环体内调用了 break。这个块里唯一的 break 语句在第 2762 行。在原始源文件里，这个临界块里没有 break 语句。我认为你必须删除第 2759-2762 行。原始 main.cpp 里没有那样的东西。"
抱歉。CRITICAL_BLOCK 并不完美。必须小心不要从里面 break 或 continue 出来。有个断言能捕获并警告 break。用它确实可以被批评，但没有它的话语法会臃肿得多，也更容易出错。

有没有可能 SSE2 代码在 Intel 上慢是因为某个可以绕开的怪癖？比如，某个东西能用但不对齐就慢，或者缓存抖动，或者某种指令特别慢？我不确定好不好找，但我记得 Intel 以前有个可以按指令级分析的 profiler。我猜如果 tcatm 手头没有那款慢 CPU 的机器来测试，就没什么希望了。但如果它能在大多数 CPU 上正常工作就太好了。

英文原文

【引用 impossible7 on August 06, 2010, 11:37:20 AM（https://bitcointalk.org/index.php?topic=648.msg7838#msg7838）】

"CRITICAL_BLOCK is a macro that contains a for loop. The assertion failure indicates that break has been called inside the body of the loop. The only break statement in this block is in line 2762. In the original source file, there is no break statement in this critical block. I think you must remove lines 2759-2762. The is nothing like that in the original main.cpp.
"
Sorry about that. CRITICAL_BLOCK isn't perfect. You have to be careful not to break or continue out of it. There's an assert that catches and warns about break. I can be criticized for using it, but the syntax would be so much more bloated and error prone without it.

Is there a chance the SSE2 code is slow on Intel because of some quirk that could be worked around? For instance, if something works but is slow if it's not aligned, or thrashing the cache, or one type of instruction that's really slow? I'm not sure how available it is, but I think Intel used to have a profiler for profiling on a per instruction level. I guess if tcatm doesn't have a system with the slow processor to test with, there's not much hope. But it would be really nice if this was working on most CPUs.

Re: bitcoin generation broken in 0.3.8?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: bitcoin generation broken in 0.3.8?

Date2010-08-09 18:50:41 UTC

ForumBitcointalk · 原文

我发现 SSE2 只带来约 2% 的微小提速，似乎不值得为此牺牲兼容性。我想选更稳妥的方案。

在我看来，Crypto++ 不太可能在运行时决定是否用 SSE2。有一处它检测 SSE2 来决定某个区块数参数，但 SSE2 相关的全是编译时的 #ifdef，我看不出它怎么在运行时切换。也许我没找对地方。

我们要在所有 makefile 里启用 SSE2 吗？万一有人用 64 位编译，看来必须启用。

我会重新编译 Linux 0.3.8 发布版中的 64 位部分。

英文原文

I found that SSE2 only added a slight 2% speedup, which didn't seem worth the incompatibility. I was trying to take the safer option.

It doesn't look to me like Crypto++ could be deciding whether to use SSE2 at runtime. There's one place where it detects SSE2 for deciding some block count parameter, but the SSE2 stuff is all #ifdef at compile time and I can't see how that would switch at runtime. Maybe I'm not looking in the right place.

Should we enable SSE2 in all the makefiles? It seems like we must in case someone compiles with 64-bit.

I will recompile the 64-bit part of the Linux 0.3.8 release.

Version 0.3.8.1 update for Linux 64-bit

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleVersion 0.3.8.1 update for Linux 64-bit

Date2010-08-09 19:46:58 UTC

ForumBitcointalk · 原文

当我们在 0.3.6 版本切换到 Crypto++ 5.6.0 的 SHA-256 后，Linux 64 位构建版的挖矿坏了。0.3.8.1 版已在 SourceForge 上，64 位二进制已更新。

下载：
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.8/bitcoin-0.3.8.1-linux.tar.gz/download

0.3.8 之后的版本可能要求 SSE2。有人还在用 Pentium 3 或更老的机器、这会成为问题吗？

英文原文

When we switched to Crypto++ 5.6.0 SHA-256 in version 0.3.6, generation got broken on the Linux 64-bit build. Version 0.3.8.1 is on SourceForge with the 64-bit binary updated.

Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.8/bitcoin-0.3.8.1-linux.tar.gz/download

Future versions after 0.3.8 will probably require SSE2. Anyone have Pentium 3 or older where this would be a problem?

Re: What could be the transition plan to Y2038 compliant Bitcoin?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: What could be the transition plan to Y2038 compliant Bitcoin?

Date2010-08-09 20:13:26 UTC

ForumBitcointalk · 原文

unsigned int 能用到 2106 年。到那时网络肯定至少要彻底改造一次。

不应该有任何 signed int。如果你在哪儿发现了 signed int，请告诉我（请在 25 年内），我会把它改成 unsigned int。

英文原文

unsigned int is good until 2106. Surely the network will have to be totally revamped at least once by then.

There should not be any signed int. If you've found a signed int somewhere, please tell me (within the next 25 years please) and I'll change it to unsigned int.

Re: bitcoin generation broken in 0.3.8? (64-bit)

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: bitcoin generation broken in 0.3.8? (64-bit)

Date2010-08-09 20:34:06 UTC

ForumBitcointalk · 原文

我上传了 Linux 版 0.3.8.1，64 位已重新构建。我用它跑了难度 1 的测试，已经生成了区块。

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

下载：
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.8/bitcoin-0.3.8.1-linux.tar.gz/download

英文原文

I uploaded 0.3.8.1 for Linux with re-built 64-bit. I ran a difficulty 1 test with it and it has generated blocks.

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

Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.8/bitcoin-0.3.8.1-linux.tar.gz/download

Re: Version 0.3.8.1 update for Linux 64-bit

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Version 0.3.8.1 update for Linux 64-bit

Date2010-08-09 20:55:06 UTC

ForumBitcointalk · 原文

说得好，我觉得如果你没有 SSE2，可以关掉挖矿运行。

要不在 cryptopp/config.h 顶部加上：

#if!defined(_M_X64) &&!defined(__x86_64__)
#define CRYPTOPP_DISABLE_SSE2 1
#endif

这样 32 位构建就会禁用 SSE2。（至少在 GCC 或 MSVC 下）

英文原文

That's a good point, I believe you could run with generation off if you don't have SSE2.

How about add to the top of cryptopp/config.h:

#if !defined(_M_X64) && !defined(__x86_64__)
#define CRYPTOPP_DISABLE_SSE2 1
#endif

that would disable SSE2 for 32-bit builds. (at least with GCC or MSVC)

Connection limits

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleConnection limits

Date2010-08-09 20:58:45 UTC

ForumBitcointalk · 原文

SVN rev 125：
- 即使已有 8 个入站连接，也始终建立 8 个出站连接
- 出站连接限制为每个 a.b.?.? 网段一个
- 开关 -maxconnections=#

我加了个（目前未文档化的）开关 -maxconnections=#。除非你的路由器撑不住太多连接，否则不建议用；如果需要，试试 -maxconnections=30。

我还没怎么测试过 -maxconnections，有人能测一下吗？

英文原文

SVN rev 125:
- Always make 8 outbound connections even if have 8 inbound
- Limit outbound connections to one per a.b.?.? range
- Switch -maxconnections=#

I added the (currently undocumented) switch -maxconnections=#. You shouldn't use it unless you need to because your router can't maintain a lot of connections, then try -maxconnections=30.

I haven't really tested -maxconnections much, could someone test it?

Re: Bitcoin minting is thermodynamically perverse

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Bitcoin minting is thermodynamically perverse

Date2010-08-09 21:28:39 UTC

ForumBitcointalk · 原文

如果你需要给家里供暖，电脑产生的热量就不算浪费。如果你在的地方用电取暖，那电脑的热量就不是浪费。用电脑产热和用电取暖成本相当。

如果你有比电更便宜的取暖方式，那浪费的只是成本差价。

如果是夏天还开着空调，那就是双倍浪费。

比特币挖矿最终会流向成本最低的地方。也许是寒冷、用电取暖的地区，在那里它基本等于免费。

英文原文

The heat from your computer is not wasted if you need to heat your home. If you're using electric heat where you live, then your computer's heat isn't a waste. It's equal cost if you generate the heat with your computer.

If you have other cheaper heating than electric, then the waste is only the difference in cost.

If it's summer and you're using A/C, then it's twice.

Bitcoin generation should end up where it's cheapest. Maybe that will be in cold climates where there's electric heat, where it would be essentially free.

Re: Version 0.3.8.1 update for Linux 64-bit

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Version 0.3.8.1 update for Linux 64-bit

Date2010-08-10 23:46:00 UTC

ForumBitcointalk · 原文

SVN rev 128：在 32 位上禁用 SSE2。这可能只对 MSVC 和 GCC 有效。其他编译器可能有不同的 64 位宏定义。

英文原文

SVN rev 128: disable SSE2 on 32-bit. This may only disable it for MSVC and GCC. Other compilers might have different 64-bit defines.

Re: Not a suggestion

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Not a suggestion

Date2010-08-11 00:14:22 UTC

ForumBitcointalk · 原文

这是个非常有意思的话题。如果找到解法，比特币就可以有更好、更简单、更方便的实现。

最初，一个币可以只是一串签名。有了时间戳服务，旧的签名可以在回溯扇出太大之前逐渐丢弃，币也可以单独保存或按面额保存。正是检查"不存在双重支付"的需求，要求知道所有交易的全局信息。

挑战在于，你怎么证明不存在其他花费？一个节点似乎必须知道所有交易才能验证。如果它只知道输入/输出点的哈希，就无法检查签名来判断某个输出点之前是否被花过。你有什么想法吗？

很难想到零知识证明在这里怎么用。

我们要证明的是"某物不存在"，这似乎要求知道全部并检查其中不包含那个东西。

英文原文

This is a very interesting topic. If a solution was found, a much better, easier, more convenient implementation of Bitcoin would be possible.

Originally, a coin can be just a chain of signatures. With a timestamp service, the old ones could be dropped eventually before there's too much backtrace fan-out, or coins could be kept individually or in denominations. It's the need to check for the absence of double-spends that requires global knowledge of all transactions.

The challenge is, how do you prove that no other spends exist? It seems a node must know about all transactions to be able to verify that. If it only knows the hash of the in/outpoints, it can't check the signatures to see if an outpoint has been spent before. Do you have any ideas on this?

It's hard to think of how to apply zero-knowledge-proofs in this case.

We're trying to prove the absence of something, which seems to require knowing about all and checking that the something isn't included.

Re: Escrow

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Escrow

Date2010-08-11 01:30:02 UTC

ForumBitcointalk · 原文

【引用 jgarzik 于 2010年8月10日 18:53:57（https://bitcointalk.org/index.php?topic=750.msg8566#msg8566）】

"去问问现实中的商家老板，愿不愿意告诉他们的顾客：钱有可能永远丢失，双方都无法挽回。"
这么说好像钱会莫名其妙丢失，双方想合作也拿不回来。

预付款买东西，钱也拿不回来。消费者对此似乎挺能接受。这并不比那更糟。

任何一方随时都可以选择把钱释放给对方。

【引用 nelisky 于 2010年8月10日 20:20:36（https://bitcointalk.org/index.php?topic=750.msg8585#msg8585）】

"但烧钱方案虽然能很好地防止经济上划算的欺诈，却无法防止报复，一旦一方不诚实，大家都会输。我肯定不会支持这个。"
那你一定也反对常见的预付款制度，因为在那里面吃亏的是顾客。

预付款：顾客损失，骗子拿到钱。
简单托管：顾客损失，但骗子也拿不到钱。

你们是想说预付款更好吗？因为至少骗子拿到了钱，至少有人拿到了？

想象有人偷了你的东西。你拿不回来，但如果可以——如果它有个能远程触发的自毁开关，你会用吗？让小偷知道你所有的东西都有自毁开关，偷了就变废品（虽然你也损失了），这会是好事吗？如果他们归还，你可以重新激活。

想象黄金被偷就会变成铅。如果小偷归还，它又变回黄金。

我还是觉得问题可能在于表达方式。比如，在博弈论讨论中别那么直白地说"烧钱"。钱从来没有真正被烧掉。你永远随时都有释放它的选择。

英文原文

【引用 jgarzik on August 10, 2010, 06:53:57 PM（https://bitcointalk.org/index.php?topic=750.msg8566#msg8566）】

"Ask some real-world business owners if they want to tell their customers about the chance of the money being lost forever, unrecoverable by either party.
"
That makes it sound like it might somehow get lost and the parties can't get it even if they want to cooperate.

When you pay for something up front, you can't get it back either. Consumers seem comfortable with that. It's no worse than that.

Either party always has the option to release it to the other.

【引用 nelisky on August 10, 2010, 08:20:36 PM（https://bitcointalk.org/index.php?topic=750.msg8585#msg8585）】

"But the money burning solution, while great at preventing economically viable fraud, does nothing to prevent revenge and actually makes everyone loose if one side is dishonest. I would certainly not endorse that.
"
Then you must also be against the common system of payment up front, where the customer loses.

Payment up front: customer loses, and the thief gets the money.
Simple escrow: customer loses, but the thief doesn't get the money either.

Are you guys saying payment up front is better, because at least the thief gets the money, so at least someone gets it?

Imagine someone stole something from you. You can't get it back, but if you could, if it had a kill switch that could be remote triggered, would you do it? Would it be a good thing for thieves to know that everything you own has a kill switch and if they steal it, it'll be useless to them, although you still lose it too? If they give it back, you can re-activate it.

Imagine if gold turned to lead when stolen. If the thief gives it back, it turns to gold again.

It still seems to me the problem may be one of presenting it the right way. For one thing, not being so blunt about "money burning" for the purposes of game theory discussion. The money is never truly burned. You have the option to release it at any time forever.

Re: Compile error in SVN r127

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Compile error in SVN r127

Date2010-08-11 01:42:30 UTC

ForumBitcointalk · 原文

SVN 已更新。谢谢。

以后恐怕还会反复栽在这个坑里。它没把我的编译搞坏。

英文原文

Updated SVN. Thanks.

There's little hope of not repeatedly stumbling over that in the future. It doesn't break the compile for me.

Re: Not a suggestion

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Not a suggestion

Date2010-08-11 21:07:59 UTC

ForumBitcointalk · 原文

还在思考这个想法……

网络需要做的唯一工作，就是判断某次输出点的花费是否为第一次。

如果我们愿意让客户端自己保存其货币的历史记录，那么网络就不需要存储某些信息，例如：
- 价值
- 一笔交易中输入点与输出点的对应关系

网络将只跟踪一堆相互独立的输出点。它不知道这些输出点属于哪些交易、对应什么金额。客户端可以查询某个输出点是否已被花费，并可以提交一个满足条件的输入点来将其标记为已花费。网络保存该输出点以及第一个证明其已花费的有效输入点。输入点对其关联的下一个输出点的哈希与一个 salt 进行签名，这样，若知道 salt，就可以私下证明该签名签署了某个特定的下一个输出点，但公开来看，网络并不知道下一个输出点是什么。

我认为客户端将不得不保存一直追溯到最初生成币的完整历史记录。支付方需要向收款方发送数据，同时仍与网络通信以将输出点标记为已花费，并检查该花费是否为第一次花费。也许数据传输可以作为电子邮件附件来完成。

客户端必须保存完整历史记录这一事实，削弱了隐私上的好处。处理大额资金的人仍然能看到大量交易历史。考虑到历史会回溯发散，他们最终可能看到大部分历史。可以通过把面额做得更细来限制发散，但处理大额资金的商家仍然可能看到大量历史。

英文原文

Still thinking this idea through...

The only job the network needs to do is to tell whether a spend of an outpoint is the first or not.

If we're willing to have clients keep the history for their own money, then some of the information may not need to be stored by the network, such as:
- the value
- the association of inpoints and outpoints in one transaction

The network would track a bunch of independent outpoints. It doesn't know what transactions or amounts they belong to. A client can find out if an outpoint has been spent, and it can submit a satisfying inpoint to mark it spent. The network keeps the outpoint and the first valid inpoint that proves it spent. The inpoint signs a hash of its associated next outpoint and a salt, so it can privately be shown that the signature signs a particular next outpoint if you know the salt, but publicly the network doesn't know what the next outpoint is.

I believe the clients would have to keep the entire history back to the original generated coins. Someone sending a payment would have to send data to the recipient, as well as still communicating with the network to mark outpoints spent and check that the spend is the first spend. Maybe the data transfer could be done as an e-mail attachment.

The fact that clients have to keep the entire history reduces the privacy benefit. Someone handling a lot of money still gets to see a lot of transaction history. The way it retrospectively fans out, they might end up seeing a majority of the history. Denominations could be made granular to limit fan-out, but a business handling a lot of money might still end up seeing a lot of the history.

Re: Lost large number of bitcoins

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Lost large number of bitcoins

Date2010-08-11 21:46:51 UTC

ForumBitcointalk · 原文

引用自：sirius-m，2010 年 8 月 11 日 02:01:53 AM（https://bitcointalk.org/index.php?topic=782.msg8657#msg8657）

我在 FAQ 里加了每次交易后备份的提醒。顺便问下，备份前一定要停客户端吗？有点麻烦。自动备份确实有用。

备份前几秒内你什么都不做、也没收款的话（比如 5 秒），不停客户端备份也行。

引用自：gridecon，2010 年 8 月 11 日 08:46:08 PM（https://bitcointalk.org/index.php?topic=782.msg8795#msg8795）

等等，我又糊涂了。我还以为这次乌龙的核心是比特币被设定成每笔交易都"掏空你的钱包"。

不，平时不会每笔交易都掏空钱包。它会找面额最小的一组币凑出接近金额的数。只不过这次不巧，他钱包里是单张 9000 BTC 的大钞，要付 1 BTC，只能拆开，找回 8999 BTC。

英文原文

Quote from: sirius-m on August 11, 2010, 02:01:53 AM（https://bitcointalk.org/index.php?topic=782.msg8657#msg8657）I added to the FAQ the warning to back up after each transaction. Is it necessary btw to stop the client before making a backup? That's a bit inconvenient. Automatic backups would be useful indeed.
You can get away with backing up without stopping the client if you don't do anything or receive a payment within a few seconds before the backup. (like 5 seconds)

Quote from: gridecon on August 11, 2010, 08:46:08 PM（https://bitcointalk.org/index.php?topic=782.msg8795#msg8795）Wait, I'm confused again. I thought the essence of the surprise was that Bitcoin is programmed to "empty your wallet" for EACH transaction.
No, it doesn't usually empty your wallet with each transaction. It uses the smallest set of coins it can find to add up to near the amount. In this case, unfortunately, his wallet had a single 9000 BTC bill in it, and it had to break it to get 1 BTC and 8999 BTC change.

Re: Where is the separate discussion devoted to possible Bitcoin weaknesses.

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Where is the separate discussion devoted to possible Bitcoin weaknesses.

Date2010-08-11 22:40:25 UTC

ForumBitcointalk · 原文

不用搞成这么 breaking 的改动。新节点可以长期接受旧交易，等大多数节点都升级了再开始拒绝没有 PoW 的交易。或者，永远接受旧交易，但每个时间段只限量。

交易加 PoW 我想过很多次，但最后总觉得 0.01 手续费本质上差不多、而且更好。0.01 基本就是工作量证明，只是不浪费。但如果问题是验证海量交易太慢，那 PoW 倒是能验得更快。

更 general 的 umbrella 式局部解法是：实现一个检测"收到的块数异常下跌"的机制。这样攻击者要从 DoS 里获利，还是得占全网相当大一部分算力。

引用自：gavinandresen，2010 年 8 月 11 日 04:10:56 PM（https://bitcointalk.org/index.php?topic=788.msg8761#msg8761）

比特币的 p2p 网络会受到各种拒绝服务攻击。

行，我说出来了。

这时候搞演示测试，只能证明我们已经知道的事，还会把开发时间从加固系统挪去线上救火。

英文原文

It doesn't have to be such a breaking change. New nodes could accept old transactions for a long time until most nodes have already upgraded before starting to refuse transactions without PoW. Or, they could always accept old transactions, but only a limited number per time period.

I've thought about PoW on transactions many times, but usually I end up thinking a 0.01 transaction fee is essentially similar and better. 0.01 is basically a proof of work, but not wasted. But if the problem is validating loads of transactions, then PoW could be checked faster.

A more general umbrella partial solution would be to implement the idea where an unlikely dropoff in blocks received is detected. Then an attacker would still need a substantial portion of the network's power to benefit from a DoS attack.

Quote from: gavinandresen on August 11, 2010, 04:10:56 PM（https://bitcointalk.org/index.php?topic=788.msg8761#msg8761）Bitcoin's p2p network is subject to various kinds of denial of service attacks.

There, I said it.
+1

Any demonstration tests at this point would only show what we already know, and divert dev time from strengthening the system to operational fire fighting.

Re: Flood attack 0.00000001 BC

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Flood attack 0.00000001 BC

Date2010-08-11 23:28:50 UTC

ForumBitcointalk · 原文

在条件允许的情况下，让 blk*.dat 文件保持小巧是件好事。

最终的解决方案是：不管它变得多大都不在乎。

但就目前而言，趁它还小，保持小巧是好的，这样新用户能更快上手。当我最终实现纯客户端模式后，这就没那么重要了。

交易费方面还有更多工作要做。一旦发生洪水攻击，你仍然可以通过支付 0.01 的交易费插队，让你的交易进入下一个区块。不过，我还没来得及把这个选项加到界面里。

不管规模如何，测试网络都会以同样的方式反应，只是浪费的带宽和造成的烦扰要小得多。

英文原文

It would be nice to keep the blk*.dat files small as long as we can.

The eventual solution will be to not care how big it gets.

But for now, while it's still small, it's nice to keep it small so new users can get going faster. When I eventually implement client-only mode, that won't matter much anymore.

There's more work to do on transaction fees. In the event of a flood, you would still be able to jump the queue and get your transactions into the next block by paying a 0.01 transaction fee. However, I haven't had time yet to add that option to the UI.

Scale or not, the test network will react in the same ways, but with much less wasted bandwidth and annoyance.

Re: BSD detection

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: BSD detection

Date2010-08-12 00:02:06 UTC

ForumBitcointalk · 原文

引用自：dkaparis，2010 年 8 月 11 日 11:00:16 PM（https://bitcointalk.org/index.php?topic=790.msg8807#msg8807）

headers.h 里有这段代码：

（以下代码保留英文原文：）

#ifdef __WXMAC_OSX__
#define __WXMAC__ 1
#define __WXOSX__ 1
#define __BSD__ 1
#endif
#endif

那段代码本来就是馊主意，我删了。Mac 代码只该用 __WXMAC_OSX__，别用 __WXMAC__ 或 __WXOSX__，__BSD__ 也别再用了。

引用：

#if (defined(__unix__) || defined(unix)) && !defined(USG)
#include <sys/param.h>
#endif

这样一定能在 Mac 上 define 出 BSD 吗？

英文原文

Quote from: dkaparis on August 11, 2010, 11:00:16 PM（https://bitcointalk.org/index.php?topic=790.msg8807#msg8807）There is this piece of code in headers.h:

#ifdef __WXMAC_OSX__
#define __WXMAC__ 1
#define __WXOSX__ 1
#define __BSD__ 1
#endif
#endif

That code was a bad idea anyway, I'm deleting it. Any Mac code should only use __WXMAC_OSX__, not __WXMAC__ or __WXOSX__, and we should stop using __BSD__.

Quote
#if (defined(__unix__) || defined(unix)) && !defined(USG)
#include <sys/param.h>
#endif

Will that definitely cause BSD to be defined on Mac?

Re: Not a suggestion

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Not a suggestion

Date2010-08-12 02:46:56 UTC

ForumBitcointalk · 原文

引用自：Red，2010 年 8 月 12 日 01:10:19 AM（https://bitcointalk.org/index.php?topic=770.msg8824#msg8824）

引用自：satoshi，2010 年 8 月 11 日 09:07:59 PM（https://bitcointalk.org/index.php?topic=770.msg8798#msg8798）

> 我觉得客户端得把账本一直保留到最初生成的币。客户端要存全历史，隐私好处就打折了。

我一开始也这么想，后来把自己说服了。

你是又说回现在的比特币系统了吗？

我说的是我描述的那个假想系统：如果网络不知道交易的值和 lineage，那就没法验证、没法 vouch，客户端就只能把历史一路存回去。

如果一个客户端是最近才上线的，要让它相信一笔交易有合法的过去，有两种办法：

1）给它看一路回到最初生成的币的完整历史。
2）给它看到某个足够深的块的历史，然后相信——既然这么多节点都说到那为止的历史是对的，那一定是对的。

但如果网络根本不知道所有交易的值和 lineage，我觉得它连 2）都做不到。

英文原文

Quote from: Red on August 12, 2010, 01:10:19 AM（https://bitcointalk.org/index.php?topic=770.msg8824#msg8824）Quote from: satoshi on August 11, 2010, 09:07:59 PM（https://bitcointalk.org/index.php?topic=770.msg8798#msg8798）I believe the clients would have to keep the entire history back to the original generated coins. The fact that clients have to keep the entire history reduces the privacy benefit.

I thought this too at first. But then I convinced myself otherwise.
Are you back to talking about the existing Bitcoin system here?

I was talking about in the hypothetical system I was describing, if the network doesn't know the values and lineage of the transactions, then it can't verify them and vouch for them, so the clients would have to keep the history all the way back.

If a client wasn't present until recently, the two ways to convince it that a transaction has a valid past is:
1) Show it the entire history back to the original generated coin.
2) Show it a history back to a thoroughly deep block, then trust that if so many nodes all said the history up to then was correct then it must be true.

But if the network didn't know all the values and lineage of the transactions, it couldn't do 2), I don't think.

Re: BSD detection

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: BSD detection

Date2010-08-12 21:14:20 UTC

ForumBitcointalk · 原文

SVN rev 130 里有了。检查下编译对不对。

代码：（以下保留英文原文）

#if (defined(__unix__) || defined(unix)) && !defined(USG)
#include <sys/param.h> // to get BSD define
#endif
#ifdef __WXMAC_OSX__
#ifndef BSD
#define BSD 1
#endif
#endif

英文原文

This is in SVN rev 130. Check that it compiles right.

Code:#if (defined(__unix__) || defined(unix)) && !defined(USG)
#include <sys/param.h> // to get BSD define
#endif
#ifdef __WXMAC_OSX__
#ifndef BSD
#define BSD 1
#endif
#endif

Bugfixes in SVN rev 130

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleBugfixes in SVN rev 130

Date2010-08-12 21:20:31 UTC

ForumBitcointalk · 原文

rev 130 中的杂项 bug 修复：

修复使用相对路径的 -datadir
autostart 现在默认关闭，Windows 除外
修复用 msvc 编译时偶尔出现的 "vector iterator not dereferencable" 断言
修复 Linux 构建中的 readlink 编译警告
使用 sys/param.h 和 BSD 宏定义替代 __BSD__
-paytxfee 开关，例如 -paytxfee=0.01

英文原文

Misc bugfixes in rev 130:

fix -datadir with relative path
autostart is now off by default except on windows
fix occasional "vector iterator not dereferencable" assertion when compiled with msvc
fix readlink compile warning on linux build
use sys/param.h and BSD define instead of __BSD__
-paytxfee switch, e.g. -paytxfee=0.01

Re: Bitcoin Watchdog Service

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Bitcoin Watchdog Service

Date2010-08-12 21:34:44 UTC

ForumBitcointalk · 原文

没错，很可能有人用拨号调制解调器或卫星天线上网。既用那种方式、又恰好遇到有线互联网中断的人会更少见，但如果受影响的网段够大，在一百万人里肯定会有多宿主的极客。

ISP 网络中断只是你所在的区域。如果你仍能与所在区域的其他部分通信，那大概只占全世界的千分之一或更少。该网段的出块速度会降到几个小时才出一个块。

我倾向于监控收到的区块频率是否降得过慢的方案。这能覆盖大量可能性。

英文原文

True, there would probably be someone with a dial-up modem or satellite dish internet. Rarer would be someone who has both that and the wired internet that has the outage, but if it's a big enough segment to matter, out of a million people there's bound to be a multi-home geek.

ISP network cuts are just your local area. If you still have communication with the rest of your area, it would probably be something like 1/1000 of the world or less. Block generation in the segment would take several hours per block.

I favour the plan to monitor if the frequency of blocks received drops too slow. That covers a large range of possibilities.

Re: Having problems specifing -datadir

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Having problems specifing -datadir

Date2010-08-12 21:43:29 UTC

ForumBitcointalk · 原文

已在 SVN rev 130 中修复。

英文原文

Fixed in SVN rev 130.

Re: 4 hashes parallel on SSE2 CPUs for 0.3.6

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: 4 hashes parallel on SSE2 CPUs for 0.3.6

Date2010-08-12 22:07:23 UTC

ForumBitcointalk · 原文

速度差这么大，达到 4 倍或 6 倍，感觉很可能是老芯片对某个特定指令或弱项处理很慢。除非是 i5 的卖点：他们把 SSE2 做快了 6 倍。

快速总结：
Xeon Quad 慢 41%
Core 2 Duo 慢 55%
Core 2 Duo 持平（vess）
Core 2 Quad 慢 50%
Core i5 快 200%（nelisky）
Core i5 快 100%（vess）
AMD Opteron 快 105%

aceat64：
我的系统从 ~7100 降到了 ~4200。
这台机器是双 Intel Xeon 四核 CPU（E5335）@ 2.00GHz。

impossible7：
在 Intel Core 2 Duo T7300、x86_64 linux 上，比原版（r121）慢了 55%。

nelisky：
我的 Core2Quad（Q6600）慢了 50%，
我的 i5 快了约 200%。

impossible7：
在 AMD Opteron 2374 HE、x86_64 linux 上，我得到了 105% 的提升（！）

英文原文

That big of a difference in speed, by a factor of 4 or 6, feels like it's likely to be some quirky weak spot or instruction that the old chip is slow with. Unless it's a touted feature of the i5 that they made SSE2 six times faster.

A quick summary:
Xeon Quad 41% slower
Core 2 Duo 55% slower
Core 2 Duo same (vess)
Core 2 Quad 50% slower
Core i5 200% faster (nelisky)
Core i5 100% faster (vess)
AMD Opteron 105% faster

aceat64:
My system went from ~7100 to ~4200.
This particular system has dual Intel Xeon Quad-Core CPUs (E5335) @ 2.00GHz.

impossible7:
on an Intel Core 2 Duo T7300 running x86_64 linux it was 55% slower compared to the stock version (r121)

nelisky:
My Core2Quad (Q6600) slowed down 50%,
my i5 improved ~200%,

impossible7:
on an AMD Opteron 2374 HE running x86_64 linux I got a 105% improvement (!)

Re: Bugfixes in SVN rev 130

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Bugfixes in SVN rev 130

Date2010-08-13 03:15:23 UTC

ForumBitcointalk · 原文

不，不是那回事。

-paytxfee 允许你在交易中附带交易费。如果交易确认变慢，你可以用 "-paytxfee=0.01" 获得优先权。你发出的每笔交易会多花 0.01。没有任何理由用超过 0.01。

它只是在那里以备不时之需。很可能用不上，如果真用上了可以再详细解释。

英文原文

No, that's not what it is.

-paytxfee allows you to include a transaction fee with your transactions. If transaction confirmations become slow, you can get priority by using "-paytxfee=0.01". Any transactions you send would cost an extra 0.01. There's no reason to use more than 0.01.

It's just there in case we need it. It probably won't be needed, and it can be explained more if we do.

Re: Bitcoin Watchdog Service

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Bitcoin Watchdog Service

Date2010-08-13 17:09:27 UTC

ForumBitcointalk · 原文

引用：

可没有 irc 服务器来 bootstrap 了。

没关系，反正你也上不了 sourceforge 下软件。

只要以前连过，就不再需要 IRC 来 bootstrap。就算没连过，也可以从种子节点 bootstrap。0.3.0 起 IRC 已经完全多余了。

英文原文

QuoteBut there will be no irc server to bootstrap from.
Which doesn't matter because you can't access sourceforge to download the software either.

If you've ever been connected before, you don't need IRC to bootstrap anymore. Even if you haven't, you can bootstrap from seed nodes. IRC is completely redundant since 0.3.0.

Version 0.3.9 rc1, please test

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleVersion 0.3.9 rc1, please test

Date2010-08-13 17:40:00 UTC

ForumBitcointalk · 原文

这是一个测试版，如果你愿意在 0.3.9 正式发布前帮忙测试的话。
（或者，如果你想现在就升级、而不想等的话）

下载：（仅二进制）
http://www.bitcoin.org/download/bitcoin-0.3.9.rc1-win32.zip
（http://www.bitcoin.org/download/bitcoin-0.3.9.rc1-linux.tar.gz）

SHA1 a36ea00cce27b4b083755df73a3d1e5e5729884e bitcoin-0.3.9.rc1-win32.zip
SHA1 bbb333b0ea57302740ad1bb9948520d00f884f9d bitcoin-0.3.9.rc1-linux.tar.gz

补充：
Linux 请改测 rc2。这个版本加了 tcatm 4-way SSE2 的 -4way 开关。这只针对 Linux：
http://www.bitcoin.org/download/bitcoin-0.3.9.rc2-linux.tar.gz

SHA1 47d9998f7d15fe81234a5c89a542da9d0664df40 bitcoin-0.3.9.rc2-linux.tar.gz

请回来报告你的结果
http://bitcointalk.org/index.php?topic=820

英文原文

Here's a test build if you'd like to help test before 0.3.9 is released.
(or if you'd rather get upgrading out of the way now instead of waiting)

Downloads: (binaries only)
http://www.bitcoin.org/download/bitcoin-0.3.9.rc1-win32.zip
(http://www.bitcoin.org/download/bitcoin-0.3.9.rc1-linux.tar.gz)

SHA1 a36ea00cce27b4b083755df73a3d1e5e5729884e bitcoin-0.3.9.rc1-win32.zip
SHA1 bbb333b0ea57302740ad1bb9948520d00f884f9d bitcoin-0.3.9.rc1-linux.tar.gz

Edit:
Linux please test rc2 instead. This adds a -4way switch for tcatm's 4-way SSE2. This will only be for Linux:
http://www.bitcoin.org/download/bitcoin-0.3.9.rc2-linux.tar.gz

SHA1 47d9998f7d15fe81234a5c89a542da9d0664df40 bitcoin-0.3.9.rc2-linux.tar.gz

Please report back your results
http://bitcointalk.org/index.php?topic=820

Re: Not a suggestion

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Not a suggestion

Date2010-08-13 19:28:47 UTC

ForumBitcointalk · 原文

我还没理解你的想法。它对公开网络隐藏了什么信息吗？优势是什么？

如果至少 50% 的节点对交易的验证足够充分、以至于旧交易可以被丢弃，那么所有人都看到了一切，也可以保存一份记录。

公开节点能看到交易的金额吗？能看到金额来自哪笔之前的交易吗？如果能，那他们就知道了一切。如果不能，那他们就无法验证金额来自合法来源，你也就不能把他们生成的链当作对它的验证。

它隐藏比特币地址吗？是这样吗？好吧，如果是这样，那我可能明白了。

密码学可能提供一种做“密钥致盲”的方法。我做过一些研究，比较冷僻，但那里可能有东西。“群签名”可能相关。

这里大致方向上有一些内容：
http://www.users.zetnet.co.uk/hopwood/crypto/rh/

我们需要一种生成公钥的额外致盲变体的方法。致盲变体应具有与根公钥相同的性质，使得私钥可以为其中任何一个生成签名。其他人无法判断一个致盲密钥是否与根密钥相关，也无法判断来自同一根密钥的其他致盲密钥之间是否相关。这就是致盲的性质。简而言之，致盲就是 x = (x * large_random_int) mod m。

向比特币地址付款时，你每次都会生成一个新的致盲密钥。

然后你需要能这样签署签名：让人无法判断两个签名来自同一个私钥。我不确定始终签署不同的致盲公钥是否已经具备这个性质。如果没有，我认为群签名就派上用场了。有了群签名，可以做到某样东西被签署了，却不知道是谁签的。

举个例子，假设某个不得人心的军事攻击命令必须下达，但没人想在历史上留下是自己下令的记录。如果 10 位领导人都有私钥，其中一人可以签署命令，而你不知道是谁签的。

英文原文

I'm not grasping your idea yet. Does it hide any information from the public network? What is the advantage?

If at least 50% of nodes validated transactions enough that old transactions can be discarded, then everyone saw everything and could keep a record of it.

Can public nodes see the values of transactions? Can they see which previous transaction the value came from? If they can, then they know everything. If they can't, then they couldn't verify that the value came from a valid source, so you couldn't take their generated chain as verification of it.

Does it hide the bitcoin addresses? Is that it? OK, maybe now I see, if that's it.

Crypto may offer a way to do "key blinding". I did some research and it was obscure, but there may be something there. "group signatures" may be related.

There's something here in the general area:
http://www.users.zetnet.co.uk/hopwood/crypto/rh/

What we need is a way to generate additional blinded variations of a public key. The blinded variations would have the same properties as the root public key, such that the private key could generate a signature for any one of them. Others could not tell if a blinded key is related to the root key, or other blinded keys from the same root key. These are the properties of blinding. Blinding, in a nutshell, is x = (x * large_random_int) mod m.

When paying to a bitcoin address, you would generate a new blinded key for each use.

Then you need to be able to sign a signature such that you can't tell that two signatures came from the same private key. I'm not sure if always signing a different blinded public key would already give you this property. If not, I think that's where group signatures comes in. With group signatures, it is possible for something to be signed but not know who signed it.

As an example, say some unpopular military attack has to be ordered, but nobody wants to go down in history as the one who ordered it. If 10 leaders have private keys, one of them could sign the order and you wouldn't know who did it.

Re: Proposed change to sendtoaddress API call

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Proposed change to sendtoaddress API call

Date2010-08-13 23:39:14 UTC

ForumBitcointalk · 原文

现在就开始为了向后兼容而不惜一切代价地把 API 搞复杂，还为时过早。

直接返回 "<txid>"。

英文原文

It's too soon to start junking up the API for backward compatibility at all costs.

Just return "<txid>".

Re: 4 hashes parallel on SSE2 CPUs for 0.3.6

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: 4 hashes parallel on SSE2 CPUs for 0.3.6

Date2010-08-14 00:49:18 UTC

ForumBitcointalk · 原文

Windows 上的 MinGW 编译它有问题：

g++ -c -mthreads -O2 -w -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -DWIN32 -D__WXMSW__ -D_WINDOWS -DNOPCH -I"/boost" -I"/db/build_unix" -I"/openssl/include" -I"/wxwidgets/lib/gcc_lib/mswud" -I"/wxwidgets/include" -msse2 -O3 -o obj/sha256.o sha256.cpp

sha256.cpp: In function `long long int __vector__ Ch(long long int __vector__, long long int __vector__, long long int __vector__)':
sha256.cpp:31: internal compiler error: in perform_integral_promotions, at cp/typeck.c:1454
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.mingw.org/bugs.shtml> for instructions.
make: *** [obj/sha256.o] Error 1

英文原文

MinGW on Windows has trouble compiling it:

Re: 4 hashes parallel on SSE2 CPUs for 0.3.6

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: 4 hashes parallel on SSE2 CPUs for 0.3.6

Date2010-08-14 04:22:29 UTC

ForumBitcointalk · 原文

没试过的话，试试对齐 thash。可能有用。反正没坏处。

引用自：tcatm，2010 年 8 月 14 日 12:53:07 AM（https://bitcointalk.org/index.php?topic=648.msg9147#msg9147）

看起来像是触发了 tree optimizer 的编译器 bug。能试下 -O0 编译吗？

-O0 也没用，一样的错。

MinGW 是 GCC 3.4.5，多半是它的问题。

我看能不能搞个新点的 MinGW。

英文原文

If you haven't already, try aligning thash. It might matter. Couldn't hurt.

Quote from: tcatm on August 14, 2010, 12:53:07 AM（https://bitcointalk.org/index.php?topic=648.msg9147#msg9147）Looks like we're triggering a compiler bug in the tree optimizer. Can you try to compile it -O0?
No help from -O0, same error.

MinGW is GCC 3.4.5. Probably the problem.

I'll see if I can get a newer version of MinGW.

Re: 4 hashes parallel on SSE2 CPUs for 0.3.6

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: 4 hashes parallel on SSE2 CPUs for 0.3.6

Date2010-08-14 17:55:37 UTC

ForumBitcointalk · 原文

在 32 位上用 MinGW GCC 4.5 跑通测试了。在 Core 2 上正好比原版慢 50%。

英文原文

Got the test working on 32-bit with MinGW GCC 4.5. Exactly 50% slower than stock with Core 2.

Re: 4 hashes parallel on SSE2 CPUs for 0.3.6

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: 4 hashes parallel on SSE2 CPUs for 0.3.6

Date2010-08-14 22:06:13 UTC

ForumBitcointalk · 原文

MinGW GCC 4.5.0：
Crypto++ 不工作，X86_SHA256_HashBlocks() 永不返回
我只在 test.cpp 里跑通了 4-way，但被 BitcoinMiner 调用时不行

MinGW GCC 4.4.1：
Crypto++ 工作
4-way SIGSEGV

GCC 肯定没有对齐 __m128i。

即使我们把自己的 __m128i 变量对齐了，编译器也可能在幕后用 __m128i 做临时变量。

通过把我们自己的 __m128i 变量对齐、并把这些内联函数改成宏定义，我在 4.4.1 上仅用 -O0 跑通了：
#define Ch(b, c, d) ((b & c) ^ (~b & d))
#define Maj(b, c, d) ((b & c) ^ (b & d) ^ (c & d))
#define ROTR(x, n) (_mm_srli_epi32(x, n) | _mm_slli_epi32(x, 32 - n))
#define SHR(x, n) _mm_srli_epi32(x, n)

但那是用的 -O0。

英文原文

MinGW GCC 4.5.0:
Crypto++ doesn't work, X86_SHA256_HashBlocks() never returns
I only got 4-way working with test.cpp but not when called by BitcoinMiner

MinGW GCC 4.4.1:
Crypto++ works
4-way SIGSEGV

GCC is definitely not aligning __m128i.

Even if we align our own __m128i variables, the compiler may decide to use a __m128i behind the scenes as a temporary variable.

By making our __m128i variables aligned and changing these inlines to defines, I was able to get it to work on 4.4.1 with -O0 only:
#define Ch(b, c, d) ((b & c) ^ (~b & d))
#define Maj(b, c, d) ((b & c) ^ (b & d) ^ (c & d))
#define ROTR(x, n) (_mm_srli_epi32(x, n) | _mm_slli_epi32(x, 32 - n))
#define SHR(x, n) _mm_srli_epi32(x, n)

But that's with -O0.

Re: 4 hashes parallel on SSE2 CPUs for 0.3.6

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: 4 hashes parallel on SSE2 CPUs for 0.3.6

Date2010-08-15 03:40:29 UTC

ForumBitcointalk · 原文

MinGW GCC 4.4.1 和 4.5.0 上，test.cpp 能跑，但 BitcoinMiner 一调就 SIGSEGV。这么看不像 GCC 版本的问题，是别的原因，可能只是栈对齐的运气。

Ubuntu 32 位 GCC 4.3.3 上我这跑得好好的。

MinGW 4.5.0 上 Crypto++ 的问题我找到了。补丁如下：

代码：（以下保留英文原文）

--- \old\sha.cpp Mon Jul 26 13:31:11 2010
+++ \new\sha.cpp Sat Aug 14 20:21:08 2010
@@ -336,7 +336,7 @@
ROUND(14, 0, eax, ecx, edi, edx)
ROUND(15, 0, ecx, eax, edx, edi)

- ASL(1)
+ ASL(label1) // Bitcoin: fix for MinGW GCC 4.5
AS2(add WORD_REG(si), 4*16)
ROUND(0, 1, ecx, eax, edx, edi)
ROUND(1, 1, ecx, eax, edx, edi)
@@ -355,7 +355,7 @@
ROUND(14, 1, eax, ecx, edx, edi)
ROUND(15, 1, ecx, eax, edx, edi)
AS2( cmp WORD_REG(si), K_END)
- ASJ( jne, 1, b)
+ ASJ( jne, label1, ) // Bitcoin: fix for MinGW GCC 4.5

AS2( mov WORD_REG(dx), DATA_SAVE)
AS2( add WORD_REG(dx), 64)

英文原文

On both MinGW GCC 4.4.1 and 4.5.0 I have it working with test.cpp but SIGSEGV when called by BitcoinMiner. So now it doesn't look like it's the version of GCC, it's something else, maybe just the luck of how the stack is aligned.

I have it working fine on GCC 4.3.3 on Ubuntu 32-bit.

I found the problem with Crypto++ on MinGW 4.5.0. Here's the patch for that:
Code:--- \old\sha.cpp Mon Jul 26 13:31:11 2010
+++
ew\sha.cpp Sat Aug 14 20:21:08 2010
@@ -336,7 +336,7 @@
ROUND(14, 0, eax, ecx, edi, edx)
ROUND(15, 0, ecx, eax, edx, edi)

- ASL(1)
+ ASL(label1) // Bitcoin: fix for MinGW GCC 4.5
AS2(add WORD_REG(si), 4*16)
ROUND(0, 1, eax, ecx, edi, edx)
ROUND(1, 1, ecx, eax, edx, edi)
@@ -355,7 +355,7 @@
ROUND(14, 1, eax, ecx, edi, edx)
ROUND(15, 1, ecx, eax, edx, edi)
AS2( cmp WORD_REG(si), K_END)
- ASJ( jne, 1, b)
+ ASJ( jne, label1, ) // Bitcoin: fix for MinGW GCC 4.5

AS2( mov WORD_REG(dx), DATA_SAVE)
AS2( add WORD_REG(dx), 64)

tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

Titletcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10

Date2010-08-15 15:52:09 UTC

ForumBitcointalk · 原文

0.3.10 把 tcatm 的 4-way SSE2 作为可选开关加进来了。

用 "-4way" 开关打开。不用这个开关就是 Crypto++ ASM SHA-256。

我只在 Linux 上把它跑通了。

下载：
从 http://bitcointalk.org/index.php?topic=827.0 获取 0.3.10

请回来报告你的 CPU 和结果！我觉得很明显了：Core 2 及更低的更慢，i5 更快。我觉得我们还没听到 i7 的结果。我们需要知道不同型号的 AMD 或其他不太常见的 CPU 的情况。

英文原文

0.3.10 has tcatm's 4-way SSE2 as an option switch.

Use the switch "-4way" to turn it on. Without the switch you get Crypto++ ASM SHA-256.

I could only get this working with Linux.

Download:
Get 0.3.10 from http://bitcointalk.org/index.php?topic=827.0

Please report back your CPU and results! I think it's pretty clear that Core 2 and lower are slower, i5 faster. I don't think we've heard any i7 results yet. We need to know about the different models of AMD or other less common CPUs.

Re: Potential disaster scenario

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Potential disaster scenario

Date2010-08-15 16:37:16 UTC

ForumBitcointalk · 原文

生成会聚集到一些地方：
1）最便宜或免费的地方
2）出于理想主义想帮忙的人
3）想不通过交易买币、直接获得一些币的人

确实有合法的免费地方。生成在任何用电暖的地方基本都是免费的，因为电脑的热量抵消了电暖器的基础供暖。很多小公寓图方便都用电暖。

取暖油有多贵？油价这么高，如果实际上比电还贵，那生成的成本就是负的。

还有把电费算在父母账上的孩子、算在雇主账上的员工、僵尸网络，等等。

第 3 种情况适用于小额。做交易所的开销不划算，如果你只是需要一点零花钱做些小额支付。我觉得相比法定货币这是个不错的优势，铸币税不再流向一个大实体，而是以方便的金额流向需要凑点零钱的人。

英文原文

Some places where generation will gravitate to:
1) places where it's cheapest or free
2) people who want to help for idealogical reasons
3) people who want to get some coins without the inconvenience of doing a transaction to buy them

There are legitimate places where it's free. Generation is basically free anywhere that has electric heat, since your computer's heat is offsetting your baseboard electric heating. Many small flats have electric heat out of convenience.

How expensive is heating oil? With the price of oil so high, if it's actually more expensive than electric, then generating would have negative cost.

There's also kids putting it on their parent's power bill, employees their employer, botnets, etc.

Case 3 comes into play for small amounts. The overhead of doing an exchange doesn't make sense if you just need a small bit of pocket change for incidental micropayments. I think this is a nice advantage vs fiat currency, instead of all the seigniorage going to one big entity, let it go in convenience amounts to people who need to scrape up a small amount of change.

Re: Version 0.3.9 rc1, please test

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Version 0.3.9 rc1, please test

Date2010-08-15 18:11:41 UTC

ForumBitcointalk · 原文

引用自：jgarzik，2010 年 8 月 15 日 05:46:27 PM（https://bitcointalk.org/index.php?topic=806.msg9467#msg9467）

extended-help 的主意可能是我想的，但代码不太一样。

主意是主要部分。你贴出补丁时，我才意识到本该那样做，而不是 "-?"。我一直对 "-?" 有保留，因为它侵占了可能的参数取值，而且 help 的回显取决于调用方的版本、而不是服务器的版本。

英文原文

Quote from: jgarzik on August 15, 2010, 05:46:27 PM（https://bitcointalk.org/index.php?topic=806.msg9467#msg9467）the extended-help might have been based on my idea, but the code was somewhat different.
The idea was the main part. When you posted your patch, I realized it should have been done that way instead of "-?". I always had reservations about "-?" because it intrudes on the possible parameter values, and the help response is based on the version of the caller instead of the server.

Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2

Date2010-08-15 18:23:26 UTC

ForumBitcointalk · 原文

希望有人能测一下 i5 或 AMD，确认我构建得没问题。我手头没有这两种可以测。

我也好奇 32 位 linux 比 64 位慢多少。

英文原文

I hope someone can test an i5 or AMD to check that I built it right. I don't have either to test with.

I'm also curious if it performs much worse on 32-bit linux vs 64-bit.

Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2

Date2010-08-15 18:43:27 UTC

ForumBitcointalk · 原文

我刚上传了一个快速构建版，测试者可以检查我构建得对不对。（我没有 i5 或 AMD）如果没问题，我再打包完整版本、做完发布流程。

英文原文

I just uploaded a quick build so testers can check if I built it right. (I don't have an i5 or AMD) If it checks out, I'll put together the full package and do all the release stuff.

Re: overflow bug SERIOUS

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: overflow bug SERIOUS

Date2010-08-15 20:59:09 UTC

ForumBitcointalk · 原文

这是初步改动。看着对吗？还有更多要改，这不是全部。马上 SVN。

代码：（以下保留英文原文）

bool CheckTransaction() const
{
// Basic checks that don't depend on any context
if (vin.empty() || vout.empty())
return error("CTransaction::CheckTransaction() : vin or vout empty");

// Check for negative and overflow values
int64 nTotal = 0;
foreach(const CTxOut& txout, vout)
{
if (txout.nValue < 0)
return error("CTransaction::CheckTransaction() : txout.nValue negative");
if (txout.nValue > 21000000 * COIN)
return error("CTransaction::CheckTransaction() : txout.nValue too high");
nTotal += txout.nValue;
if (nTotal > 21000000 * COIN)
return error("CTransaction::CheckTransaction() : txout total too high");
}

if (IsCoinBase())
{
if (vin[0].scriptSig.size() < 2 || vin[0].scriptSig.size() > 100)
return error("CTransaction::CheckTransaction() : coinbase script size");
}
else
{
foreach(const CTxIn& txin, vin)
if (txin.prevout.IsNull())
return error("CTransaction::CheckTransaction() : prevout is null");
}

return true;
}

别置顶这个主题，没人往上看。帖子够多自然会 bump 上去。

英文原文

Here's the preliminary change. Look right? I have more changes to make, this isn't all of it. Will SVN shortly.

Code: bool CheckTransaction() const
{
// Basic checks that don't depend on any context
if (vin.empty() || vout.empty())
return error("CTransaction::CheckTransaction() : vin or vout empty");

return true;
}

Don't sticky the topic, nobody looks up there. There'll be enough posts to bump.

Re: overflow bug SERIOUS

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: overflow bug SERIOUS

Date2010-08-15 21:06:45 UTC

ForumBitcointalk · 原文

如果大家能停下生成，会有帮助。我们可能需要围绕当前这条链重做一条分支，你生成得越少，这个过程越快。

第一个补丁会在 SVN rev 132 里。还没上传。我先把其他一些杂项改动推上去，然后再上传这个补丁。

英文原文

It would help if people stop generating. We will probably need to re-do a branch around the current one, and the less you generate the faster that will be.

A first patch will be in SVN rev 132. It's not uploaded yet. I'm pushing some other misc changes out of the way first, then I'll upload the patch for this.

Re: overflow bug SERIOUS

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: overflow bug SERIOUS

Date2010-08-15 21:23:55 UTC

ForumBitcointalk · 原文

拿到更新后，你可以下载 knightmb 的区块链。要找一个足够旧的、在 74000 块之前结束的版本，这样最新的安全锁定检查才能验证它。有人能找到那个链接吗？

英文原文

Once you have an update, you could download knightmb's block chain. You'll want one that's old enough that it ends before block 74000 so the most recent security lockin will check it. Can someone find the link for that?

Re: overflow bug SERIOUS

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: overflow bug SERIOUS

Date2010-08-15 21:40:19 UTC

ForumBitcointalk · 原文

补丁已上传到 SVN rev 132！

目前建议的步骤：
1）关机。
2）下载 knightmb 的 blk 文件。（替换你的 blk0001.dat 和 blkindex.dat 文件）
3）升级。
4）启动时应该少于 74000 个块。让它重新下载其余部分。

如果你不想用 knightmb 的文件，也可以直接删除 blk*.dat 文件，但如果所有人同时下载整个块索引，会给网络带来很大负载。

我马上构建发布版。

英文原文

Patch is uploaded to SVN rev 132!

For now, recommended steps:
1) Shut down.
2) Download knightmb's blk files. (replace your blk0001.dat and blkindex.dat files)
3) Upgrade.
4) It should start out with less than 74000 blocks. Let it redownload the rest.

If you don't want to use knightmb's files, you could just delete your blk*.dat files, but it's going to be a lot of load on the network if everyone is downloading the whole block index at once.

I'll build releases shortly.

Re: overflow bug SERIOUS

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: overflow bug SERIOUS

Date2010-08-15 22:58:08 UTC

ForumBitcointalk · 原文

不要更新区块链下载。当你拿别人的区块链下载时，你不希望它一直到最新。一个稍微旧一点的更好，这样它可以下载并验证最新的区块。

tcatm 的 4-way SSE2 SHA-256 在 sha256.cpp 文件里，几个版本前就已经上传了。

我刚上传了 rev 134，是在 Linux 上启用它构建的 makefile.unix。如果你现在在 Linux 上构建 rev 134，就会得到 -4way 开关。

如果因为它构建出问题，就编辑 makefile.unix 并：
- 删除 -DFOURWAYSSE2
- 从这些行的末尾删除 obj/sha256.o：
bitcoin: $(OBJS) obj/ui.o obj/uibase.o obj/sha256.o
bitcoind: $(OBJS:obj/%=obj/nogui/%) obj/sha256.o

我构建 0.3.10 linux 版时会带上 -4way 选项。

以下是 Windows 的补丁下载：

http://www.bitcoin.org/download/bitcoin-0.3.10-win32-setup.exe
http://www.bitcoin.org/download/bitcoin-0.3.10-win32.zip

SHA1 16645ec5fcdb35bc54bc7195309a1a81105242bb bitcoin-0.3.10-win32-setup.exe
SHA1 4f35ad7711a38fe8c880c6c9beab430824c426d3 bitcoin-0.3.10-win32.zip

步骤：
1）关机。
2）下载 knightmb 的 blk 文件，替换你的 blk0001.dat 和 blkindex.dat 文件。
http://knightmb.dyndns.org/files/bitcoin/blocks/
http://rapidshare.com/files/413168038/BitcoinBlocks.torrent
3）升级到 0.3.10。
4）启动时应该少于 74000 个块，然后重新下载其余部分。

或者，如果你不想折腾下载 blk 文件，也可以这样：

1）关机。
2）删除（或移走）blk*.dat
3）升级到 0.3.10。
4）它会重新下载所有块，大概需要一个小时。

英文原文

Don't update the block chain download. When you take someone's block chain download, you don't want it right up to the end. A somewhat old one is better so it can download and verify the most recent blocks.

tcatm's 4-way SSE2 SHA-256 is in the file sha256.cpp and already uploaded a few revs ago.

I just now uploaded rev 134 which is the makefile.unix that enables building with it on Linux. If you build rev 134 on Linux now you'll get the -4way switch.

If you have problems building because of it, then edit makefile.unix and:
- remove -DFOURWAYSSE2
- remove obj/sha256.o from the end of these lines:
bitcoin: $(OBJS) obj/ui.o obj/uibase.o obj/sha256.o
bitcoind: $(OBJS:obj/%=obj/nogui/%) obj/sha256.o

The 0.3.10 linux build will have the -4way option when I build it.

Here are the patch downloads for Windows:

http://www.bitcoin.org/download/bitcoin-0.3.10-win32-setup.exe
http://www.bitcoin.org/download/bitcoin-0.3.10-win32.zip

SHA1 16645ec5fcdb35bc54bc7195309a1a81105242bb bitcoin-0.3.10-win32-setup.exe
SHA1 4f35ad7711a38fe8c880c6c9beab430824c426d3 bitcoin-0.3.10-win32.zip

Steps:
1) Shut down.
2) Download knightmb's blk files and replace your blk0001.dat and blkindex.dat files.
http://knightmb.dyndns.org/files/bitcoin/blocks/
http://rapidshare.com/files/413168038/BitcoinBlocks.torrent
3) Upgrade to 0.3.10.
4) It should start out with less than 74000 blocks and redownload the rest.

Or if you don't want to mess with downloading blk files, you can just do this:

1) Shut down.
2) Delete (or move) blk*.dat
3) Upgrade to 0.3.10.
4) It redownloads all blocks, probably take about an hour.

Re: overflow bug SERIOUS

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: overflow bug SERIOUS

Date2010-08-15 23:17:24 UTC

ForumBitcointalk · 原文

引用自：knightmb，2010 年 8 月 15 日 10:59:04 PM（https://bitcointalk.org/index.php?topic=823.msg9574#msg9574）

[edit] 刚看到你的帖子，那我编个不到 74,000 的，至少给你们技术人员省几分钟下新链的时间。

别动旧的！越老越好。块号多少？60000–74000 都行。你那个放了一阵子的、经过 vet 的就是最好的选择。

英文原文

Quote from: knightmb on August 15, 2010, 10:59:04 PM（https://bitcointalk.org/index.php?topic=823.msg9574#msg9574）[edit] Just saw your post, I'll build one to less than 74,000 then, should at least save you technical people a few minutes of downloading the new chain.
Just leave the old one alone! Older is better. What block number is it? Anywhere from 60000-74000 is good. The one that you've had available for a while has been vetted and is the best choice.

Re: overflow bug SERIOUS

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: overflow bug SERIOUS

Date2010-08-15 23:36:10 UTC

ForumBitcointalk · 原文

从 67000 开始正好。

是的，目前你会停在 74638。随着更多节点升级并生成，它应该会开始慢慢往上涨。

Linux 构建链接如下。

Linux 版包含了 tcatm 的 4-way SSE2 SHA-256，在 i5 和 AMD CPU 上生成更快。用 "-4way" 开关启用，看看对你是不是更快。

下载链接：
http://www.bitcoin.org/download/bitcoin-0.3.10-win32-setup.exe
http://www.bitcoin.org/download/bitcoin-0.3.10-win32.zip
http://www.bitcoin.org/download/bitcoin-0.3.10-linux.tar.gz

SHA1 16645ec5fcdb35bc54bc7195309a1a81105242bb bitcoin-0.3.10-win32-setup.exe
SHA1 4f35ad7711a38fe8c880c6c9beab430824c426d3 bitcoin-0.3.10-win32.zip
SHA1 e3fda1ddb31b0d5c35156cacd80dee6ea6ae6423 bitcoin-0.3.10-linux.tar.gz

英文原文

Starting at 67000 is perfect.

Yeah, at the moment you'll stop at 74638. It should start slowly creeping up as more nodes upgrade and generate.

Linux build links below.

The Linux version includes tcatm's 4-way SSE2 SHA-256 that makes generating faster on i5 and AMD CPU's. Use the "-4way" switch to enable it and check if it's faster for you.

Download links:
http://www.bitcoin.org/download/bitcoin-0.3.10-win32-setup.exe
http://www.bitcoin.org/download/bitcoin-0.3.10-win32.zip
http://www.bitcoin.org/download/bitcoin-0.3.10-linux.tar.gz

Re: overflow bug SERIOUS

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: overflow bug SERIOUS

Date2010-08-15 23:37:07 UTC

ForumBitcointalk · 原文

引用自：Joozero，2010 年 8 月 15 日 11:32:43 PM（https://bitcointalk.org/index.php?topic=823.msg9582#msg9582）

我觉得你该加上这个：http://bitcointalk.org/index.php?topic=259.0

客户端上得有个 label，有需要就弹警告消息。

现在大家总得去刷网站，我觉得不好。

同意，早就想做了，一直没时间。

眼下你也可以订阅 bitcoin-list 邮件列表。它平时很少用，除了这种公告和重大新版。

订阅/退订页面：

http://lists.sourceforge.net/mailman/listinfo/bitcoin-list

英文原文

Quote from: Joozero on August 15, 2010, 11:32:43 PM（https://bitcointalk.org/index.php?topic=823.msg9582#msg9582）I think that you should add something about this: http://bitcointalk.org/index.php?topic=259.0
There must be a label on the client that show a warning message if needed
Now everyone have always to check the website, and I think that this is bad.
Agree, wanted to do that for a long time, haven't had time to do it.

For now, you could also subscribe to the bitcoin-list mailing list. It rarely gets used except for announcements like this and major new versions.

Subscribe/unsubscribe page:
http://lists.sourceforge.net/mailman/listinfo/bitcoin-list

Version 0.3.10 - block 74638 overflow PATCH!

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleVersion 0.3.10 - block 74638 overflow PATCH!

Date2010-08-15 23:48:22 UTC

ForumBitcointalk · 原文

0.3.10 版修复了 74638 块的溢出 bug。http://bitcointalk.org/index.php?topic=823

Linux 版包含了 tcatm 的 4-way SSE2 SHA-256，在 i5、i7（带超线程）和 AMD CPU 上生成更快。试试 "-4way" 开关启用它，看看对你是不是更快。

从 sourceforge 下载：
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.10/

不再需要删除 blk*.dat。好的区块链已经超过了坏的区块链，所以你只需升级，它会自动重组掉坏的区块链。

英文原文

Version 0.3.10 patches the block 74638 overflow bug. http://bitcointalk.org/index.php?topic=823

The Linux version includes tcatm's 4-way SSE2 SHA-256 that makes generating faster on i5, i7 (with hyperthreading) and AMD CPU's. Try the "-4way" switch to enable it and check if it's faster for you.

Download from sourceforge:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.10/

It is no longer necessary to delete blk*.dat. The good block chain has overtaken the bad block chain, so you can just upgrade and it'll automatically reorg away the bad block chain.

Re: 0.3.10.1 Question on where block should be

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: 0.3.10.1 Question on where block should be

Date2010-08-16 00:28:28 UTC

ForumBitcointalk · 原文

我怀疑，如果你连接的所有节点都是 0.3.9 或更低版本，接收区块会有点困难。我们需要足够多的人升级，这样你连接的节点中至少有一个是 0.3.10。当我们占到网络的八分之一以上时，问题会开始消失。

做端口转发会有帮助，这样你能获得很多连接。

英文原文

I suspect there's some difficulty receiving blocks if all the nodes you're connected to are 0.3.9 or lower. We need enough of us so that at least one node you connect to will be 0.3.10. The problem will start to go away when we make up more than 1/8th of the network.

It'll help if you port forward so you can get lots of connections.

Re: 0.3.10.1 Question on where block should be

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: 0.3.10.1 Question on where block should be

Date2010-08-16 00:37:20 UTC

ForumBitcointalk · 原文

目前，能不能请一些运行 0.3.10、有静态 IP、能接收入站连接的人贴出自己的 IP？然后我们可以用 -addnode= 加上它们，确保至少连上一个 0.3.10 节点。

英文原文

For now, can some people running 0.3.10 with static IP who can receive incoming connections post their IP? Then we can -addnode= them and make sure to connect to at least one 0.3.10 node.

Re: overflow bug SERIOUS

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: overflow bug SERIOUS

Date2010-08-16 01:00:45 UTC

ForumBitcointalk · 原文

引用自：Ground Loop，2010 年 8 月 16 日 12:29:55 AM（https://bitcointalk.org/index.php?topic=823.msg9609#msg9609）

问下 fallout：我在坏块之后、用坏链提交了一笔交易。

那笔交易现在什么状态？

据我看，我（升级过的）付款方钱包显示扣款了。

它会被重新纳入修复后的链吗？接收方能花吗？

对，它会被重新纳入修复后的链。交易不会消失，两边都还看得见，只是确认数会跳回 0 重新数。

只有一种情况那 50 BTC 会消失：你在 74638 之后的那条坏链上生成过块。坏链上的块都还没 mature。

英文原文

Quote from: Ground Loop on August 16, 2010, 12:29:55 AM（https://bitcointalk.org/index.php?topic=823.msg9609#msg9609）Question about fallout: I had a transaction that I submitted after the bad block, using the bad block chain.

What is the status of that transaction?
From what I can tell, my (updated) sending client wallet shows the deducted amount.

Will it get reincorporated into the fixed chain, and will the recipient be able to spend it?
Right, it will get reincorporated into the fixed chain. The transaction won't disappear, it'll still be visible on both sides, but the confirmation count will jump back to 0 and start counting up again.

It's only if you generated a block in the bad chain after block 74638 that the 50 BTC from that will disappear. Any blocks in the bad chain wouldn't have matured yet.

Re: overflow bug SERIOUS

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: overflow bug SERIOUS

Date2010-08-16 01:02:24 UTC

ForumBitcointalk · 原文

引用自：kosovito，2010 年 8 月 16 日 12:39:17 AM（https://bitcointalk.org/index.php?topic=823.msg9615#msg9615）

都照做了，现在客户端是 0.3.10，停在 74638 块。一切正常吗？

如果你还显示 74638 个块，说明你没连上任何 0.3.10 节点。

今天先试试加这些参数：

-addnode=75.158.131.108 -addnode=99.27.237.13 -addnode=68.68.99.14

看：

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

英文原文

Quote from: kosovito on August 16, 2010, 12:39:17 AM（https://bitcointalk.org/index.php?topic=823.msg9615#msg9615）I did all steps, now my client is 0.3.10 and it stopped at block 74638. Is all fine?
If you still show 74638 blocks then you aren't connected to any 0.3.10 nodes.

For today, try adding these parameters:
-addnode=75.158.131.108 -addnode=99.27.237.13 -addnode=68.68.99.14

See
http://bitcointalk.org/index.php?topic=828

Re: overflow bug SERIOUS

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: overflow bug SERIOUS

Date2010-08-16 01:12:05 UTC

ForumBitcointalk · 原文

引用自：trebronics，2010 年 8 月 16 日 01:02:35 AM（https://bitcointalk.org/index.php?topic=823.msg9625#msg9625）

大多数跑客户端的人没在看这个帖。所以……问几个傻问题：

1）这对还跑在坏链上的 3.8.1 版（灾难前）客户端接下来有什么影响？
2）对升到 3.8.10 但没删区块链文件的客户端有什么影响？

1）一旦超过 50% 的节点算力升级、好链超过坏链，0.3.10 节点会让坏交易很难拿到确认。
2）如果你没删 blk*.dat 文件，你就没在给那 50% 出力，在好链超过坏链之前，你看到的还是坏交易。

英文原文

Quote from: trebronics on August 16, 2010, 01:02:35 AM（https://bitcointalk.org/index.php?topic=823.msg9625#msg9625）Most people running clients are not reading this message thread. So... Silly questions:

1) How will this continue to affect version 3.8.1 (pre-catastrophe) clients with bad block chain?
2) How will this affect clients that upgrade to 3.8.10 but don't remove their block chain files?
1) Once more than 50% of the node power is upgraded and the good chain overtakes the bad, the 0.3.10 nodes will make it hard for any bad transactions to get any confirmations.
2) If you didn't remove your blk*.dat files, you're not helping to contribute to that 50%, and you'll still show bad transactions until the good chain overtakes the bad chain.

Re: overflow bug SERIOUS

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: overflow bug SERIOUS

Date2010-08-16 02:16:10 UTC

ForumBitcointalk · 原文

随着更多节点升级，坏链的速度也慢下来了。

自 74638 以来，我们已经生成了 14 个块。0.3.10 的构建版大约在 2、3 小时前上传。在我连接的节点中，超过一半已经是 0.3.10。我觉得我们很可能已经拥有超过坏链的算力了。

英文原文

The bad chain is also slowed down as more nodes upgrade.

We've already generated 14 blocks since 74638. The builds of 0.3.10 were uploaded about 2 and 3 hours ago. Of the nodes I'm connected to, more than half are already 0.3.10. I would say we probably already have more power than the bad chain.

Re: overflow bug SERIOUS

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: overflow bug SERIOUS

Date2010-08-16 02:38:21 UTC

ForumBitcointalk · 原文

在 Windows 上，运行 findstr /c:"version message" debug.log

看起来坏链最近到了 74678 块。真想快点超过它。

在 http://nullvoid.org/bitcoin/statistix.php 的统计上，过去 3 小时是每小时 5 个块。我们大约一天前做过一次难度调整，本应把它调回每小时 6 个块。

英文原文

On Windows, findstr /c:"version message" debug.log

It looks like the bad chain was on block 74678 recently. Can't wait to overtake it.

On the stats at http://nullvoid.org/bitcoin/statistix.php there's been 5 blocks per hour in the last 3 hours. We had a difficulty adjustment about a day ago that should have put it back to 6 blocks per hour.

Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2

Date2010-08-16 02:57:57 UTC

ForumBitcointalk · 原文

引用自：tcatm，2010 年 8 月 16 日 12:43:39 AM（https://bitcointalk.org/index.php?topic=820.msg9617#msg9617）

我提议 sha256.cpp 用 -O3 -march=amdfamk10 编（32 位 64 位都行），只有支持这个指令集的 CPU（AMD Phenom、Intel i5 及更新）能从 -4way 受益，性能能提 ~9%。

GCC 4.3.3 不支持 -march=amdfamk10。我得到：

sha256.cpp:1: error: bad value (amdfamk10) for -march= switch

引用自：NewLibertyStandard，2010 年 8 月 16 日 01:49:01 AM（https://bitcointalk.org/index.php?topic=820.msg9630#msg9630）

开 4way 后，我开满虚拟核性能好不少。我觉得关超线程后开不开 4way 哈希数差不多。

嘿，你可能发现了点什么！

超线程以前没用，是因为活全在算术逻辑单元里，超线程是共享 ALU 的。

tcatm 的 SSE2 代码肯定是普通 x86 指令和 SSE2 指令混着，所以一个在跑 x86 代码时，另一个能跑 SSE2。

超线程下提升多少？

有数字吗？什么 CPU？

英文原文

Quote from: tcatm on August 16, 2010, 12:43:39 AM（https://bitcointalk.org/index.php?topic=820.msg9617#msg9617）I propose to compile sha256.cpp with -O3 -march=amdfamk10 (will work on 32bit and 64bit) as only CPUs supporting this instruction set (AMD Phenom, Intel i5 and newer) benefit from -4way and it'll improve performance by ~9%.
GCC 4.3.3 doesn't support -march=amdfamk10. I get:
sha256.cpp:1: error: bad value (amdfamk10) for -march= switch

Quote from: NewLibertyStandard on August 16, 2010, 01:49:01 AM（https://bitcointalk.org/index.php?topic=820.msg9630#msg9630）With 4way, I get significantly better performance when I have all my virtual cores enabled. I think I get about the same amount of hashes when hyper threading is turned off with or without 4way.
Hey, you may be onto something!

hyperthreading didn't help before because all the work was in the arithmetic and logic units, which the hyperthreads share.

tcatm's SSE2 code must be a mix of normal x86 instructions and SSE2 instructions, so while one is doing x86 code, the other can do SSE2.

How much of an improvement do you get with hyperthreading?

Some numbers? What CPU is that?

Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2

Date2010-08-16 03:23:04 UTC

ForumBitcointalk · 原文

引用自：Vasiliev，2010 年 8 月 16 日 03:17:07 AM（https://bitcointalk.org/index.php?topic=820.msg9660#msg9660）

试试 -march=amdfam10

行。

好奇怪……确定是一回事吗？tcatm，试下 amdfam10，确认测速一样。

英文原文

Quote from: Vasiliev on August 16, 2010, 03:17:07 AM（https://bitcointalk.org/index.php?topic=820.msg9660#msg9660）try -march=amdfam10
That works.

That's strange... are we sure that's the same thing? tcatm, try amdfam10 and make sure you get the same speed measurement.

Re: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10

Date2010-08-16 04:36:59 UTC

ForumBitcointalk · 原文

引用自：jgarzik，2010 年 8 月 16 日 03:35:28 AM（https://bitcointalk.org/index.php?topic=820.msg9665#msg9665）

代码：（以下保留英文原文）

cpu family : 6
model : 26
model name : Genuine Intel(R) CPU 000 @ 3.20GHz
stepping : 4

cpu family 6 model 26 stepping 4 是 Intel Core i7。

-4way 提速 23%，-4way + 超线程一共提速 63%。

开超线程比不开快 33%。

英文原文

Quote from: jgarzik on August 16, 2010, 03:35:28 AM（https://bitcointalk.org/index.php?topic=820.msg9665#msg9665）Code:cpu family : 6
model : 26
model name : Genuine Intel(R) CPU 000 @ 3.20GHz
stepping : 4cpu family 6 model 26 stepping 4 is an Intel Core i7.
That's a 23% speedup with -4way, 63% total speedup with -4way + hyperthreading.
33% faster with hyperthreading than without it.

Re: overflow bug SERIOUS

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: overflow bug SERIOUS

Date2010-08-16 12:59:38 UTC

ForumBitcointalk · 原文

看起来我们在 74689 附近超过了坏链。0.3.9 及更低版本的节点这几个小时一直在用当前块号回应。

这意味着升级前不再需要删除 blk*.dat。你只需升级，它就会重组掉坏的区块链。

感谢大家的快速响应！

英文原文

It looks like we overtook the bad chain somewhere around 74689. 0.3.9 and lower nodes have been responding with the current block number for some hours now.

That means it's no longer necessary to delete blk*.dat before upgrading. You can just upgrade and it'll reorg away the bad block chain.

Thanks to everyone for the quick response!

Re: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10

Date2010-08-16 13:38:01 UTC

ForumBitcointalk · 原文

我把 sha256.cpp 包在了
#ifdef FOURWAYSSE2
#endif // FOURWAYSSE2
里。

现在再试试。

英文原文

I wrapped sha256.cpp in
#ifdef FOURWAYSSE2
#endif // FOURWAYSSE2

try it now.

Re: [PATCH] Automatic block validation

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: [PATCH] Automatic block validation

Date2010-08-16 15:25:54 UTC

ForumBitcointalk · 原文

这条路不好走。

我们得制造一次 reorg，把那条非法链断开。

这种代码这辈子几乎测不到，又相当 intricate，越简单、越安全越好。

我的想法是这样的（还没测）。它检查主链上所有块。如果发现坏块，就把那条链所有块的 bnChainWork 置 0，让它再也赢不了 best chain，同时把 best chain work 降到分叉点，这样分叉之后任何新块都会触发 reorg。（不实际做一次 reorg 就改不了 pindexBest。）

还不完美。它还得再收到一个合法块才能触发 reorg。

也可能在检查完直接调 AddToBlockIndex 或 Reorganize，但那要小心得多。我大概会把 AddToBlockIndex 里设新 best block 的部分拆出来，用那个办法，而不是下面这段代码。

代码：（以下保留英文原文）

bool CTxDB::LoadBlockIndex()
{
...

// Verify blocks in the main chain
vector<CBlockIndex*> vChain;
for (CBlockIndex* pindex = pindexBest; pindex && pindex->pprev; pindex = pindex->pprev)
{
vChain.push_back(pindex);
CBlock block;
if (!block.ReadFromDisk(pindex))
return error("LoadBlockIndex() : block.ReadFromDisk failed");
if (!block.CheckBlock())
{
bnBestChainWork = pindex->pprev->bnChainWork;
foreach(CBlockIndex* pindex2, vChain)
pindex2->bnChainWork = 0;
}
}

return true;
}

英文原文

That's a difficult approach.

We need to cause a reorg, which will disconnect the invalid chain.

This is code that will rarely ever get tested, and is fairly intricate, so something simple and safe is best.

Here's what I was thinking of. (I haven't tested this yet) It checks all the blocks in the main chain. If it finds a bad one, it sets all that chain's bnChainWork to 0 so it can't win best chain again, and it reduces best chain work to the fork level so any new block after the fork will cause a reorg. (It can't change pindexBest without actually doing a reorg)

This isn't perfect yet. It still needs to receive one valid block to trigger the reorg.

It would probably be possible to initiate an AddToBlockIndex or Reorganize after the check, but it would require a lot more careful attention. I probably should break out part of AddToBlockIndex that sets the new best block. I'll probably end up doing that instead of the code below.

Code:bool CTxDB::LoadBlockIndex()
{
...

// Verify blocks in the main chain
   vector<CBlockIndex*> vChain;
   for (CBlockIndex* pindex = pindexBest; pindex && pindex->pprev; pindex = pindex->pprev)
   {
   vChain.push_back(pindex);
   CBlock block;
   if (!block.ReadFromDisk(pindex))
   return error("LoadBlockIndex() : block.ReadFromDisk failed");
   if (!block.CheckBlock())
   {
   bnBestChainWork = pindex->pprev->bnChainWork;
   foreach(CBlockIndex* pindex2, vChain)
   pindex2->bnChainWork = 0;
   }
   }

return true;
}

blocks minus 1

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

Titleblocks minus 1

Date2010-08-16 15:59:25 UTC

ForumBitcointalk · 原文

我想把状态栏显示的块数减 1。刚打开程序时，会显示 0 个块而不是 1 个：

"0 connections 0 blocks 0 transactions"

一直以来都是 "nBestHeight + 1"，因为把创世块也算进去了。严格说，创世块是个块。它是硬编码的块，你生来就有它。不可能没有创世块。可以把它想成一把 reference coin，其他币都拿它当尺子量。大家想看的块数是自己下到了多少个块。

主要好处是：块数会等于当前 best block 的块号。blocks 是 10，就说明你最高有 10 号块，没有 11 号。

也能减少这儿的 confusion：

引用自：kencausey，2010 年 8 月 15 日 11:45:26 PM（https://bitcointalk.org/index.php?topic=823.msg9588#msg9588）

引用自：davidonpda，2010 年 8 月 15 日 11:31:37 PM（https://bitcointalk.org/index.php?topic=823.msg9580#msg9580）

……它已经到 74638 块了。我猜这意思是 74638 现在是好块了？

我自己也晕过，在 #bitcoin-dev 问明白了：

坏块是 74638 号，最后一个好块是 74637。编号从 0 开始，所以客户端显示有 74638 个块，意思是你最高到 74637 号块，也就是最后一个好块。

英文原文

I'd like to reduce the number of blocks displayed in the status bar by 1. When you first load the program, it'll display 0 blocks instead of 1:
"0 connections 0 blocks 0 transactions"

It's always been "nBestHeight + 1" because it's counting the genesis block. Technically, yes, the genesis block is a block. It's a hardcoded block that you start out with. You can't not have the genesis block. Maybe think of it as a reference coin that you measure other coins against. The block count people are looking for is the number of blocks they've downloaded.

The main benefit is that blocks will be equal to the block number of the current best block. If blocks is 10, then the highest block number you have is 10. It means you have block 10 and you don't have block 11.

It would reduce the confusion we had here:

Quote from: kencausey on August 15, 2010, 11:45:26 PM（https://bitcointalk.org/index.php?topic=823.msg9588#msg9588）Quote from: davidonpda on August 15, 2010, 11:31:37 PM（https://bitcointalk.org/index.php?topic=823.msg9580#msg9580）... It already is on block 74638. I assume that means that block is now a good one?

I had some confusion on this myself and got clarification in #bitcoin-dev:

The bad block was number 74638, the last good one was 74637. The numbers start at 0, so when your client shows there are 74638 blocks then that means you have up to block number 74637, the last good one.

Re: blocks minus 1

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: blocks minus 1

Date2010-08-16 17:06:27 UTC

ForumBitcointalk · 原文

已在 SVN rev 137 中完成。

英文原文

Done in SVN rev 137

Re: [PATCH] Automatic block validation

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: [PATCH] Automatic block validation

Date2010-08-16 17:08:02 UTC

ForumBitcointalk · 原文

引用自：satoshi，2010 年 8 月 16 日 03:25:54 PM（https://bitcointalk.org/index.php?topic=832.msg9754#msg9754）

在检查完直接调 AddToBlockIndex 或 Reorganize 大概也行，但要小心得多。我大概会把 AddToBlockIndex 里设新 best block 的部分拆出来，用那个办法，而不是下面这段代码。

SVN rev 139 里我就是这么干的。

我没删坏链，而是在 ConnectBlock 里多加了一次 CheckBlock，坏块被踢出去后就再也回不到 best chain。

英文原文

Quote from: satoshi on August 16, 2010, 03:25:54 PM（https://bitcointalk.org/index.php?topic=832.msg9754#msg9754）It would probably be possible to initiate an AddToBlockIndex or Reorganize after the check, but it would require a lot more careful attention. I probably should break out part of AddToBlockIndex that sets the new best block. I'll probably end up doing that instead of the code below.
This is what I ended up doing in SVN rev 139.

Instead of deleting the bad chain, I added an extra CheckBlock to ConnectBlock so bad blocks can't get back into the best chain once they're kicked out.

Checking the block chain on load

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleChecking the block chain on load

Date2010-08-16 20:07:46 UTC

ForumBitcointalk · 原文

SVN rev 139 在加载后对区块链做一次基本检查。

有了这个，我们当时就不需要删除 blk*.dat 了，它会自动重组回分叉点。当时没时间仔细实现这个。

它可能比我们希望的慢，因为要加载所有块。如果太慢，我们可以让它只回溯到某个块号。

英文原文

SVN rev 139 does a basic check of the block chain after loading.

With this we wouldn't have needed to delete blk*.dat, it would have automatically done a reorg back to the fork. There wasn't time to do a careful implementation of this at the time.

It might take longer than we want, since it has to load all the blocks. If it's too slow, we could have it only go back to a certain block number.

Re: checkpointing the block chain

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: checkpointing the block chain

Date2010-08-16 20:20:53 UTC

ForumBitcointalk · 原文

除了最大工作量证明，软件没有办法自动判断一条链是否比另一条更好。设计上要求它无论要回溯多远，都必须切换到更长的链。

唯一的例外是我加的手动检查点。如果没有那些，它可以一路重组回第一个块。

英文原文

There is no way for the software to automatically know if one chain is better than another except by the greatest proof-of-work. In the design it was necessary for it to switch to a longer chain no matter how far back it has to go.

The only exception to that is the manual checkpoints I've added. If it weren't for those, it would be able to reorg all the way back to the first block.

Re: overflow bug SERIOUS

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: overflow bug SERIOUS

Date2010-08-16 22:54:55 UTC

ForumBitcointalk · 原文

未升级的节点大多数时间都在正确的链上，但它们仍试图在每个块里打包那笔溢出交易，所以一直在试图分叉、生成无效块。如果一个旧版本节点重启，它的内存池会被清空，所以在那笔交易再次被广播之前，它可能生成一段时间的有效块。0.3.9 及更低版本的节点仍然必须升级。

SVN 现在有了我们需要的代码，可以自动重组区块链，不用再手动删除 blk*.dat 文件。我知道昨天我没法又快又仔细地写出那段代码，所以当时选了快速的手动方案。

英文原文

Un-upgraded nodes have the correct chain most of the time, but they are still trying to include the overflow transaction in every block, so they're continually trying to fork and generate invalid blocks. If an old version node is restarted, its transaction pool is emptied, so it may generate valid blocks for a while until the transaction gets broadcast again. 0.3.9 and lower nodes still must upgrade.

The SVN now has the code we needed to automatically reorg the block chain without having to delete the blk*.dat files manually. I knew I couldn't write that code fast and carefully enough yesterday, so I went with the quick manual option.

Re: checkpointing the block chain

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: checkpointing the block chain

Date2010-08-16 23:01:48 UTC

ForumBitcointalk · 原文

引用自：NewLibertyStandard，2010 年 8 月 16 日 10:42:28 PM（https://bitcointalk.org/index.php?topic=834.msg9839#msg9839）

链的强度怎么算？

总工作量证明。

英文原文

Quote from: NewLibertyStandard on August 16, 2010, 10:42:28 PM（https://bitcointalk.org/index.php?topic=834.msg9839#msg9839）How is the strength of the chain calculated?
Total proof-of-work.

Re: New screenshots to the front page?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: New screenshots to the front page?

Date2010-08-18 16:58:44 UTC

ForumBitcointalk · 原文

当然。0.1 的旧截图已经非常过时了。

Windows Aero 是个不错的选择。Windows 仍然是最大的用户群。注意透明部分后面露出的内容。

交易列表里显示什么？不要塞得满满的，就几样东西就行。

英文原文

Definitely. The old screenshots of 0.1 are very outdated.

Windows Aero is a good choice. Windows is still the largest user group. Mind what's behind it for the transparent parts.

What to have displayed in the transaction list? Not completely filled up with stuff, just a few things.

Re: Difficulty: More nodes active, or faster nodes?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Difficulty: More nodes active, or faster nodes?

Date2010-08-18 18:01:40 UTC

ForumBitcointalk · 原文

VIA C7 硬件 SHA-256 公布的性能数字并不惊人。只有 1500 khash/s 左右。想想看，硬件实现并不意味着快得离谱。它仍然要走完所有步骤。只有把硬件简化到单一用途、小到能并行塞下很多个，才会快。这不一定容易，也不一定理所当然。

英文原文

The performance numbers posted from a VIA C7's hardware SHA-256 weren't astronomical. Only in the 1500 khash/s range. If you think about it, just because it's implemented in hardware doesn't mean it's crazy fast. It still has to do all the steps. It's only if simplifying it down to single-purpose hardware makes it small enough to fit many in parallel. That's not necessarily easy or a given.

Re: Checking the block chain on load

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Checking the block chain on load

Date2010-08-18 18:28:28 UTC

ForumBitcointalk · 原文

在下一个 SVN 版本里，我会让它只回溯到 74000 块处的最后一个检查点。如果将来需要纠正问题，我们总可以确保它至少回溯到问题所在的位置。另外，我在加验证块索引的代码，也就是说工作量证明链会被检查。

不过，系统对你的 blk*.dat 文件还不能完全放心。如果你用别人 blk 文件的副本，你就是在信任那个人。

英文原文

In the next SVN rev, I'll make it only go back to the last checkpoint at block 74000. If we need to correct a problem in the future, we can always make sure it goes back at least as far back as the problem. Also, I'm adding code to verify the block index, which means the proof-of-work chain is checked.

Still, the system won't be entirely secure against your blk*.dat files. You are trusting someone if you use a copy of their blk files.

Re: Convert Bitcoin to GTK: Yes? No? wx is better?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Convert Bitcoin to GTK: Yes? No? wx is better?

Date2010-08-19 18:44:36 UTC

ForumBitcointalk · 原文

引用自：BioMike，2010 年 8 月 19 日 08:05:18 AM（https://bitcointalk.org/index.php?topic=867.msg10226#msg10226）

WxWidgets 本身不是问题。问题是用的版本（2.9），很多发行版打包者认为它不稳定（虽然 WxWidgets 开发者说不是）。另一方面，据我所知 WxWidgets 在 Linux 下用 gtk 画界面，让比特币开发者跨平台很省事。

wxWidgets 2.9 是他们第一个 UTF-8 版。我们全平台都是 UTF-8，包括 Windows。

发行版里 2.8 的包是 UTF-16 的，只会把人绕晕。2.8 时代大家被它的 wxString UTF-16/ANSI 条件编译选项折腾出的构建问题无穷无尽，直到我们统一到 2.9 才消停。而且用 2.8 的话我们只能用 ANSI，那只是等 wxWidgets 支持 UTF-8 之前的临时措施。

这个问题会自己消失。假以时日，2.9 会成为更 mainstream 的版本。

英文原文

Quote from: BioMike on August 19, 2010, 08:05:18 AM（https://bitcointalk.org/index.php?topic=867.msg10226#msg10226）WxWidgets is not really a problem. My problem is the version that is used (2.9), which is considered unstable by many distro packagers (although the WxWidgets devs say it isn't). On the other side, as far as I know WxWidgets uses gtk under Linux for drawing the whole stuff and makes it for the bitcoins devs easy to make things cross platform.
wxWidgets 2.9 is their first UTF-8 version. We are UTF-8 on all platforms including Windows.

The distro packages of 2.8 are UTF-16, so they just trip people up. People had endless build problems with 2.8 and its wxString UTF-16/ANSI conditional build options until we standardized on 2.9. Also, to use 2.8, we were using ANSI, which was just a temporary stopgap until wxWidgets supported UTF-8.

This is a problem that will solve itself. With time, 2.9 will become a more mainline release.

Re: HOWTO: Compiling Bitcoin on Ubuntu 10.04 (Karmic)

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: HOWTO: Compiling Bitcoin on Ubuntu 10.04 (Karmic)

Date2010-08-19 18:55:48 UTC

ForumBitcointalk · 原文

这篇 walkthrough 写得非常好。有人如果照着做过、没遇到坑，应该确认一下。

英文原文

That's a really well written walkthough. Someone should confirm if they followed it and didn't run into any snags.

Re: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10

Date2010-08-19 19:07:43 UTC

ForumBitcointalk · 原文

引用自：Ground Loop，2010 年 8 月 18 日 11:14:26 PM（https://bitcointalk.org/index.php?topic=820.msg10167#msg10167）

非 Mac 的 i5 有爱吗？

Windows i5 64 位这儿变慢了。

第一次听说有人说 i5 变慢。其他人都说 i5 上 4way 更快，开超线程更快。

引用自：nelisky，2010 年 8 月 18 日 11:02:25 PM（https://bitcointalk.org/index.php?topic=820.msg10164#msg10164）

还有 i5，至少我的 macbookpro 上……

好，那 Mac 上也 work 了？

Laszlo 跟我说他在 Mac 上编进了 -4way，所以 Mac 上也可以试 -4way 开关。SVN 上的 makefile.osx 好像还没加，只有编好的版本有。

英文原文

Quote from: Ground Loop on August 18, 2010, 11:14:26 PM（https://bitcointalk.org/index.php?topic=820.msg10167#msg10167）Any non-Mac i5 love?
Windows i5 64-bit got slower here.
That's the first I've heard anyone say i5 was slower. Everyone else has said 4way was faster on i5. Moreso with hyperthreading enabled.

Quote from: nelisky on August 18, 2010, 11:02:25 PM（https://bitcointalk.org/index.php?topic=820.msg10164#msg10164）And i5, at least on my macbookpro
Good, so I take it that's a confirmation that it's working on Mac as well?

Laszlo told me he did compile in the -4way stuff on Mac, so the -4way switch is also available to try on Mac. I don't think makefile.osx on SVN has it yet, just the built version.

Re: 28 days without generation, i have 4200khash/s

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: 28 days without generation, i have 4200khash/s

Date2010-08-19 19:40:30 UTC

ForumBitcointalk · 原文

确保你电脑的日期和时间正确。

英文原文

Make sure your computer's date and time are correct.

Need a post writing up some things users should know

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleNeed a post writing up some things users should know

Date2010-08-19 20:14:01 UTC

ForumBitcointalk · 原文

我不确定该叫它什么，但我们确实需要一篇帖子，把用户应该知道的这些事列出来。如果有人有时间写，清单如下：

- 确保时钟设置正确。

- Microsoft Security Essentials。这个一直没好好写过。

- 警告：不要乱动你的 wallet.dat 文件。它是个数据库文件，没你想的那么简单。在这个 Beta 版本里，我们还没来得及把它做得防折腾。如果你开始换来换去，它可能不会按预期工作。

英文原文

I'm not sure what to call it, but we could use a post that lists these things users should know. If someone has time to write it, here's the list:

- Make sure your clock is set correctly.

- Microsoft Security Essentials. This never got written up proper.

- Warning not to mess around with your wallet.dat file. It's a database file, it's not as simple as you think. In this Beta version, we haven't had time to try and tinker-proof it yet. It may not work as expected if you start swapping it around.

Re: Hypothetical question on lost coins / transfers

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Hypothetical question on lost coins / transfers

Date2010-08-19 20:28:50 UTC

ForumBitcointalk · 原文

没错。不需要重新广播你的交易，它也能工作。

当任何节点断开一条分叉时，它会把分叉里的所有交易倒回交易池，加到新链上。整个网络都在确保把你的交易重新整合进去。你看到的应该只是确认数从 0 重新开始。

在某些类型的分叉里，你的交易可能两条分叉都进了，所以你本来就没问题。

英文原文

That's right. You don't need to be re-broadcasting your transactions for it to work.

When any node disconnects a fork, it dumps all the transactions from the fork back into the transaction pool to add to the new chain. The entire network is making sure to re-integrate your transactions again. All you should see is that your number of confirmations starts over from 0.

In some types of forks, your transaction would have gotten into both forks already, so you're already good either way.

Re: Need a post writing up some things users should know

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Need a post writing up some things users should know

Date2010-08-22 22:51:00 UTC

ForumBitcointalk · 原文

时钟那部分会在下一个版本（0.3.11 或更高）里解决。SVN rev 141 在你的时钟偏差太大时会弹出一个消息框。

英文原文

The clock part will be covered in the next release (0.3.11 or higher). SVN rev 141 pops up a message box if your clock is too far off.

Re: 28 days without generation, i have 4200khash/s

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: 28 days without generation, i have 4200khash/s

Date2010-08-22 23:01:02 UTC

ForumBitcointalk · 原文

在 debug.log 里搜 "proof-of-work found"。搜到了就看它后面有没有报错。

引用自：davidonpda，2010 年 8 月 19 日 07:43:01 PM（https://bitcointalk.org/index.php?topic=862.msg10291#msg10291）

时间允许多大误差才正常。

误差 2 小时。

SVN rev 141 和下个版本（0.3.11+）会修。如果你的时钟偏了超过 1 小时，会弹消息框提醒。

英文原文

Search debug.log for "proof-of-work found". If you find any, then check for any errors right after that.

Quote from: davidonpda on August 19, 2010, 07:43:01 PM（https://bitcointalk.org/index.php?topic=862.msg10291#msg10291）How big of a margin on the time is allowed for things to work right.
The margin is 2 hours.

This should be solved in SVN rev 141 and the next release (0.3.11+). It'll pop up a message box alerting you if your clock is off by more than an hour.

Re: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10

Date2010-08-22 23:21:50 UTC

ForumBitcointalk · 原文

谢谢澄清。我看过有人贴的链接，说 AMD 在 2007 年左右做了那个改动，但不知道 Intel 这边是什么情况。

那 Core/Core2 没指望了。它们只有一半的 SSE2 硬件。

奇怪的是 Intel 有 3 个 128 位单元，反而是只有 2 个 128 位单元的 AMD 更快。

英文原文

Thanks for clearing that up. I read the link someone posted about AMD making that change around 2007, but I didn't know what the story was for Intel.

There's no hope for Core/Core2 then. They only have half the SSE2 hardware.

Strange that Intel has 3 128bit units, but AMD with 2 128bit units is the faster one.

Development of alert system

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleDevelopment of alert system

Date2010-08-22 23:55:06 UTC

ForumBitcointalk · 原文

我一直在写警报系统。警报通过网络广播，适用于一段版本号范围。警报消息用只有我持有的私钥签名。

节点收到警报可以做两件事：
- 在状态栏放一条警告消息。
- 让 json-rpc 接口中涉及资金的方法返回错误。

在溢出 bug 或分叉这类用户可能无法信任收到的付款的情况下，警报可以在他们升级前让旧版本基本保持安全。手动用户在查看收款时会注意到状态栏警告，json-rpc 安全模式会让自动化网站在升级前不再做任何交易。

警报期间返回错误的方法有：
sendtoaddress
getbalance
getreceivedbyaddress
getreceivedbylabel
listreceivedbyaddress
listreceivedbylabel

英文原文

I've been working on writing the alert system. Alerts are broadcast through the network and apply to a range of version numbers. Alert messages are signed with a private key that only I have.

Nodes can do two things in response to an alert:
- Put a warning message on the status bar.
- Make the money handling methods of the json-rpc interface return an error.

In cases like the overflow bug or a fork where users may not be able to trust received payments, the alert should keep old versions mostly safe until they upgrade. Manual users should notice the status bar warning when looking for received payments, and the json-rpc safe mode stops automated websites from making any more trades until they're upgraded.

The json-rpc methods that return errors during an alert are:
sendtoaddress
getbalance
getreceivedbyaddress
getreceivedbylabel
listreceivedbyaddress
listreceivedbylabel

Re: integrating digital payments into p2p protocols

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: integrating digital payments into p2p protocols

Date2010-08-22 23:57:32 UTC

ForumBitcointalk · 原文

嗨，Zooko！

我想感谢你在一两年前——当时我刚在密码学邮件列表上宣布比特币——在你的博客上介绍比特币。

英文原文

Hey Zooko!

I wanted to thank you for posting about Bitcoin on your blog a year or two ago, back when I announced it on the Cryptography mailing list.

Re: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10

Date2010-08-24 22:43:56 UTC

ForumBitcointalk · 原文

引用自 ArtForz，发表于 August 21, 2010, 04:56:31 PM（https://bitcointalk.org/index.php?topic=820.msg10609#msg10609）

- AMD K10: 2 128bit units
- intel nehalem: 3 128bit units

这大概解释了为什么超线程能提升 -4way 的性能。如果三个 SSE2 单元过剩，那么超线程就能让它们全都保持忙碌。

英文原文

Quote from: ArtForz on August 21, 2010, 04:56:31 PM（https://bitcointalk.org/index.php?topic=820.msg10609#msg10609）

> - AMD K10: 2 128bit units
> - intel nehalem: 3 128bit units
This probably explains why hyperthreading increases performance with -4way. If three SSE2 units is excessive, then hyperthreading would help keep them all busy.

Re: Development of alert system

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Development of alert system

Date2010-08-24 23:51:12 UTC

ForumBitcointalk · 原文

如果你多疑到为此歇斯底里，那你肯定也多疑到——只要状态栏上出现警告信息——就会去网站和论坛上核实。

我认为，如果再出现类似溢出漏洞那样的 bug，重要的是自动化网站要停止交易，直到管理员弄清楚发生了什么并决定如何处理。如果你认定这是误报并愿意冒险，可以使用 "-disablesafemode" 开关。

英文原文

If you're so paranoid that you're getting hysterical over this, then surely you're paranoid enough that if a warning message displays on the status bar, you'll check the website and forum.

I think if another bug like the overflow bug occurs, it's important that automated websites stop trading until their admins can check out what's going on and decide what to do. If you decide it's a false alarm and want to take your chances, you can use the "-disablesafemode" switch.

Re: Development of alert system

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Development of alert system

Date2010-08-25 00:06:36 UTC

ForumBitcointalk · 原文

这已纳入 SVN rev 142，作为 0.3.11 版本。

英文原文

This is in SVN rev 142 as version 0.3.11.

Re: Development of alert system

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Development of alert system

Date2010-08-25 15:17:37 UTC

ForumBitcointalk · 原文

它无法远程执行任意操作。也许你们中的一些人是在回应其他发帖者——他们建议警报系统应该做得更多？

如果出现警报，以下 json-rpc 方法将返回错误：
sendtoaddress
getbalance
getreceivedbyaddress
getreceivedbylabel
listreceivedbyaddress
listreceivedbylabel

其余 14 个方法照常运行。

我认为更安全的选项应该默认启用。如果你想让你的服务器继续交易、无视警报——警报说它收到的钱可能像溢出漏洞产生的钱——那你可以使用这个开关；万一丢了钱，别怪别人。

最坏的情况是：你保持警报启用，你的网站会停止交易，直到你升级或加上 -disablesafemode 开关。

当你的节点本来就处于风险中时，遭遇一次意外的短暂停机，总比遭遇小偷掏空你所有库存要好。

将来某天，当我们很久都没有再发现新 bug，并且它已经过彻底的安全审查而一无所获时，可以再放宽。我并不是说这是永远不变的永久方案。这仍然是测试版软件。

英文原文

It can't do arbitrary actions remotely. Maybe some of you are responding to other posters who suggested the alert system should do more?

If there is an alert, the following json-rpc methods return an error:
sendtoaddress
getbalance
getreceivedbyaddress
getreceivedbylabel
listreceivedbyaddress
listreceivedbylabel

The remaining 14 methods function as normal.

I believe the safer option should be enabled by default. If you want your server to keep trading and ignore an alert saying the money its receiving might be like the money from the overflow bug, then you can use the switch and not blame anyone else if you lose your money.

Worst case if you leave alerts enabled, your site stops trading until you upgrade or add the -disablesafemode switch.

Getting surprised by some temporary down time when your node would otherwise be at risk is better than getting surprised by a thief draining all your inventory.

Someday when we haven't found any new bugs for a long time and it has been thoroughly security reviewed without finding anything, this can be scaled back. I'm not arguing that this is the permanent way of things forever. It's still beta software.

Re: Development of alert system

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Development of alert system

Date2010-08-25 16:40:20 UTC

ForumBitcointalk · 原文

我把开关名改成了 -disablesafemode。

英文原文

I changed the switch name to -disablesafemode.

Re: Development of alert system

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Development of alert system

Date2010-08-25 16:56:15 UTC

ForumBitcointalk · 原文

引用自 jimbobway，发表于 August 25, 2010, 04:45:22 PM（https://bitcointalk.org/index.php?topic=898.msg11153#msg11153）

引用自 BioMike，发表于 August 23, 2010, 05:15:43 AM（https://bitcointalk.org/index.php?topic=898.msg10742#msg10742）

@mizerydearia，我觉得引用按钮比回复按钮好找。

那么，理论上这是第一个这样的控制系统：<some goverment> 可以逮捕 satoshi，要求他交出密钥（或从他的电脑上拿到），然后关闭整个网络？

或者这不可能？<some goverment> 能做到哪一步？

给 satoshi 的几个反问：

你能扛住水刑吗？
你能忍受电击吗？
各种酷刑？
最后，你该不会是 Jack Bauer 吧？说真的。

关于警报系统，谁在乎呢？这个密钥最多只能暂时禁用六个 json-rpc 命令，直到网站所有者加上 -disablesafemode 开关或升级。所有节点继续运行和生成，网络保持在线。如果我不在，任何脚本小子都能琢磨出加两个字符、做出一个禁用警报系统的新版本。这只是暂时的不便。

引用自 BioMike，发表于 August 23, 2010, 05:15:43 AM（https://bitcointalk.org/index.php?topic=898.msg10742#msg10742）

那么，理论上这是第一个这样的控制系统：<some goverment> 可以逮捕 satoshi，要求他交出密钥（或从他的电脑上拿到），然后关闭整个网络？

这让我觉得反对的人根本不知道自己在说什么。它不可能"关闭整个网络"。

英文原文

Quote from: jimbobway on August 25, 2010, 04:45:22 PM（https://bitcointalk.org/index.php?topic=898.msg11153#msg11153）

Quote from: BioMike on August 23, 2010, 05:15:43 AM（https://bitcointalk.org/index.php?topic=898.msg10742#msg10742）

@mizerydearia, I think the quote button is easier to find then the reply one.

So, theoretical this is a first control system where <some goverment> can arrest satoshi and demand
that he hands over his key (or get it from his computer) and shut down the complete network?

Or is that not possible? How far would <some goverment> get?

A few rhetorical questions for satoshi:

Can you resist waterboarding?
Can you endure electric shock?
All forms of torture?
Lastly, are you Jack Bauer by any chance? Seriously.

WRT the alert system, who cares? The most the key can do is temporarily disable six json-rpc commands until the site owners either add the -disablesafemode switch or upgrade. All nodes keep running and generating, the network stays up. If I'm not available, any script kiddie can figure out how to add two characters and make a new version that disables the alert system. It would be a temporary inconvenience only.

Quote from: BioMike on August 23, 2010, 05:15:43 AM（https://bitcointalk.org/index.php?topic=898.msg10742#msg10742）

So, theoretical this is a first control system where <some goverment> can arrest satoshi and demand
that he hands over his key (or get it from his computer) and shut down the complete network?

This is what makes me think the people objecting don't know what they're talking about. It can't "shut down the complete network".

Re: Development of alert system

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Development of alert system

Date2010-08-25 17:59:30 UTC

ForumBitcointalk · 原文

引用自 nelisky，发表于 August 25, 2010, 01:28:32 AM（https://bitcointalk.org/index.php?topic=898.msg11092#msg11092）

那么管理员能从 bitcoind 得到什么样的警告？能从 debug.log 里 grep 到什么吗？或者 rpc 调用会抛出某种特定错误？有没有办法在本地强制触发，用来给服务做单元测试？

getinfo 新增了一个字段，会显示状态栏上显示的任何警报信息或其他错误。

rpc 方法会返回一个 json-rpc 错误，错误描述为 "Safe mode: "，后面跟警报指定的附加文本。

我为你加了 "-testsafemode" 开关。SVN rev 145。

这些都很新，还可能变动。

引用自 mizerydearia，发表于 August 25, 2010, 12:11:50 AM（https://bitcointalk.org/index.php?topic=898.msg11079#msg11079）

我刚发现 http://www.bitcoin.org/wiki/doku.php?id=man_page，上面没有 -disablesafemode 的说明。也许应该加上！还有 -4way 之类的也应该加上。

很多开关是故意不写文档的，比如功能还在开发中、名字还没定，或者只是测试代码，不打算发布。

-4way 最终应该会被自动检测取代。

英文原文

Quote from: nelisky on August 25, 2010, 01:28:32 AM（https://bitcointalk.org/index.php?topic=898.msg11092#msg11092）

So what kind of warning do admins get from bitcoind? Is there something we can grep from debug.log? Or will rpc calls raise some specific error? Is there a way to locally force this to happen, for unittesting services?

getinfo has a new field that shows any alert messages or other errors that would be displayed on the status bar.

The rpc methods return a json-rpc error with the error description "Safe mode: " followed by additional text specified by the alert.

I added the switch "-testsafemode" for you. SVN rev 145.

This stuff is very new and may still be subject to change.

Quote from: mizerydearia on August 25, 2010, 12:11:50 AM（https://bitcointalk.org/index.php?topic=898.msg11079#msg11079）

I just discovered http://www.bitcoin.org/wiki/doku.php?id=man_page and don't see any reference to -disablesafemode. Perhaps it should be added! Also others liek -4way should be added as well.

Many switches are intentionally undocumented, like if their functionality is still under construction or I haven't settled on their name yet, or just test code not intended for release.

-4way should eventually be replaced by an auto-detect.

Re: Development of alert system

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Development of alert system

Date2010-08-26 00:08:12 UTC

ForumBitcointalk · 原文

引用自 BioMike，发表于 August 25, 2010, 06:23:45 PM（https://bitcointalk.org/index.php?topic=898.msg11162#msg11162）

引用自 satoshi，发表于 August 25, 2010, 04:56:15 PM（https://bitcointalk.org/index.php?topic=898.msg11155#msg11155）

引用自 BioMike，发表于 August 23, 2010, 05:15:43 AM（https://bitcointalk.org/index.php?topic=898.msg10742#msg10742）

那么，理论上这是第一个这样的控制系统：<some goverment> 可以逮捕 satoshi，要求他交出密钥（或从他的电脑上拿到），然后关闭整个网络？

或者这不可能？<some goverment> 能做到哪一步？

这让我觉得反对的人根本不知道自己在说什么。它不可能"关闭整个网络"。

我从没反对过这个改动/想法，只是问这是否可能、到什么程度。
多了解一点有什么错？

抱歉，你的帖子确实是个问题，而不是论断。

英文原文

Quote from: BioMike on August 25, 2010, 06:23:45 PM（https://bitcointalk.org/index.php?topic=898.msg11162#msg11162）

Quote from: satoshi on August 25, 2010, 04:56:15 PM（https://bitcointalk.org/index.php?topic=898.msg11155#msg11155）

Quote from: BioMike on August 23, 2010, 05:15:43 AM（https://bitcointalk.org/index.php?topic=898.msg10742#msg10742）

So, theoretical this is a first control system where <some goverment> can arrest satoshi and demand
that he hands over his key (or get it from his computer) and shut down the complete network?

Or is that not possible? How far would <some goverment> get?

This is what makes me think the people objecting don't know what they're talking about. It can't "shut down the complete network".

I've never objected this change/idea, just asking if this was possible and to what extent.
What's wrong with getting informed?

My apologies, your post was indeed a question not a statement.

Re: RFC: remove DB_PRIVATE flag

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: RFC: remove DB_PRIVATE flag

Date2010-08-26 00:33:28 UTC

ForumBitcointalk · 原文

能详细说说去掉 DB_PRIVATE 会有什么影响吗？

我想不起来当初用 DB_PRIVATE 是不是有特定原因，还是只是从某个示例代码里照抄了这些标志。去掉 DB_PRIVATE 后，其他进程同时打开数据库是否就安全了？这可能是个改进，具体要看副作用。会不会因为必须立即写出每个改动或做其他协调而大幅降低性能？那之后还会有额外的锁定或协调文件吗？还有什么会变？你可以计时对比去掉 DB_PRIVATE 前后的初始区块下载，最好 -connect 到本地机器，这样网络就不是影响因素了。

显然，DB_PRIVATE 并没有达到人们期望的效果，也就是阻止其他进程打开数据库。它照样让它们打开，只是一旦它们打开就会搞砸。另一个办法——如果可行的话——是把数据库文件锁住，让其他进程无法访问。

英文原文

Can you provide more details about what removing DB_PRIVATE does?

I can't remember if I had a specific reason for DB_PRIVATE, or if I just copied the flags from some example code. Does removing DB_PRIVATE make it safe for other processes to open the database simultaneously? That may be an improvement, depending what the side effects are. Does it substantially reduce performance by making it have to write out every change immediately or do other coordination? Are there additional locking or coordination files then? What else changes? You could test by timing an initial block download with and without DB_PRIVATE, preferably -connect-ing to a local machine so network isn't a factor.

Apparently, DB_PRIVATE doesn't do what you would hope it would do, which is prevent other processes from being able to open the database. It still lets them, it just screws up if they do. Another option, if there's a way, would be to make it lock the database files so they can't be accessed by other processes.

Re: Need a post writing up some things users should know

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Need a post writing up some things users should know

Date2010-08-26 00:44:05 UTC

ForumBitcointalk · 原文

任何备份流程/步骤都只是权宜之计，等有时间再在软件里用代码好好解决。在代码到位之前，我们可以先用文字来缓解问题。

主要的备份改进将是预制的密钥池，以及加载时重新扫描、从区块历史中捞出遗漏的交易。这样一次备份就能长期有效。

英文原文

Any backup process/procedure would just be a stopgap until there's time to properly work on coding solutions in software. We can try to use words to help the situation until code gets there.

The main backup improvement will be pre-made pool of keys, and a rescan at load to scrape missed transactions from the block history. Then a backup will last forward for a long time.

Re: auto backing up of wallet.dat

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: auto backing up of wallet.dat

Date2010-08-26 00:57:40 UTC

ForumBitcointalk · 原文

我在另一个帖子里已经开始说了，这里再重复一遍，这个帖子似乎更切题。

主要的备份改进将是预生成的密钥池，以及加载时重新扫描、从区块历史中捞出遗漏的交易。这样一次备份就能长期有效。

我正准备发和你一样的想法，nelisky。

加一个 json-rpc 命令怎么样：锁定钱包、刷出数据、把 wallet.dat 复制到你指定的位置，然后解锁？这比密钥池方案小，也许可以先做。

复制文件最简单的可移植方法是什么？Boost 里有吗？

叫什么名字好？比如：
backupwallet <destination>

英文原文

I started posting in the other topic but I'll repeat here, this thread seems more specific to the topic.

The main backup improvement will be a pre-generated pool of keys and a rescan at load to scrape missed transactions from the block history. Then a backup will last forward for a long time.

I was starting to post the same idea you said nelisky.

How about a json-rpc command that locks the wallet, flushes it, copies wallet.dat to a location you specified, then unlocks it? That would be a smaller project than the pooled keys, so maybe it could be done first.

What's the simplest portable way to copy a file? Is there something in Boost?

What should it be named? maybe:
backupwallet <destination>

Re: Gentoo Linux Ebuild

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Gentoo Linux Ebuild

Date2010-08-27 00:49:43 UTC

ForumBitcointalk · 原文

试试 -datadir=

上次我试 $(shell /usr/bin/wx-config) 时，立刻就有人嚷嚷说用它构建有问题。当时没时间细查。

$(shell /usr/bin/wx-config) 的一个问题是，它会随便抓到当时存在的任意版本（wx 2.8）和任意配置（非 UTF-8）的 wxWidgets。-lwx_gtk2ud-2.9 只匹配正确的配置。如果 wxWidgets 用了错误的配置构建，它就会失败。

引用

Iirc，我在 freenode 的 #wxwidgets 频道跟开发者们聊过，他们对为什么用这个感到不解。

他们说了为什么觉得不可思议吗？

引用

这是因为在我的系统上路径是 /usr/include/wx-2.9/wx/wx.h

它为什么在那？是操作系统自带的，还是你自己构建的？如果你是自己构建的，我很好奇它为什么会把自己放到别处。

wxWidgets 2.9 终于有 debian 包了吗？

也许我们应该这样：

INCLUDEPATHS= \
-I"/usr/local/include/wx-2.9" \
-I"/usr/local/lib/wx/include/gtk2-unicode-debug-static-2.9" \
-I"/usr/include/wx-2.9" \
-I"/usr/lib/wx/include/gtk2-unicode-debug-static-2.9"

同样，这些路径能确保只用 2.9，遇到 2.8 会失败。

wxWidgets 2.8 有 ANSI 和 UTF-16 两种，都不合我们用。它诱人是因为很容易装到包；很多人被它折腾得够呛，直到我们开始在 makefile 里硬编码 2.9。

英文原文

Try -datadir=

Last time I tried $(shell /usr/bin/wx-config), there was immediate hollering about build problems with it. There wasn't time to investigate at the time.

One problem with $(shell /usr/bin/wx-config) is it will pick up any version (wx 2.8 ) and any configuration (non-UTF-8 ) of wxWidgets that happens to be there. -lwx_gtk2ud-2.9 only matches the right configuration. It fails if wxWidgets was built with the wrong configuration.

Quote

Iirc, chatting in #wxwidgets on freenode, the devs there were baffled why that was used.

Did they say why they were baffled?

Quote

This is because on my system the path is /usr/include/wx-2.9/wx/wx.h

Why is it there? Was it included by the OS, or did you have to build it? If you built it, I wonder why it would put itself in a different place.

Has wxWidgets 2.9 finally started to become available as a debian package?

Maybe we should do this:

INCLUDEPATHS= \
-I"/usr/local/include/wx-2.9" \
-I"/usr/local/lib/wx/include/gtk2-unicode-debug-static-2.9" \
-I"/usr/include/wx-2.9" \
-I"/usr/lib/wx/include/gtk2-unicode-debug-static-2.9"

Again, those paths help make sure it's only 2.9 and will fail with 2.8.

wxWidgets 2.8 comes in ANSI and UTF-16, both wrong for us. It's tempting because it's so easily available as a package; a lot of people were frustrated by it until we started hardcoding 2.9 into the makefile.

Re: auto backing up of wallet.dat

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: auto backing up of wallet.dat

Date2010-08-27 01:13:42 UTC

ForumBitcointalk · 原文

如果读进内存再写出来，在内存紧张时可能会失败。

我在找类似 copyfile(const char* from, const char* to) 或 copyfile(path from, path to) 的东西，最好是 Boost 里现成的。如果你能帮我找到，我更有可能去实现它。

引用自 nelisky，发表于 August 26, 2010, 01:21:57 AM（https://bitcointalk.org/index.php?topic=921.msg11232#msg11232）

至于文件复制，为什么要增加对 boost 的依赖？我个人希望核心库的依赖越少越好。

我们用 Boost 做 JSON 和十几样取代 wxWidgets 依赖的东西。Boost 是好用、可移植的东西，我们不该回避它。

英文原文

If you read it into memory and write it out, it could fail in tight memory situations.

I'm looking for something like copyfile(const char* from, const char* to) or copyfile(path from, path to), preferably something in Boost if it has it. If you find it for me, it's more likely I'll get to implementing it.

Quote from: nelisky on August 26, 2010, 01:21:57 AM（https://bitcointalk.org/index.php?topic=921.msg11232#msg11232）

As for the file copy, why add to the boost dependency? I for one would love to get a core lib with very little deps.

We require Boost for JSON and a dozen things replacing dependencies on wxWidgets. Boost is good, portable stuff, we should not shy away from it.

Re: auto backing up of wallet.dat

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: auto backing up of wallet.dat

Date2010-08-27 02:54:07 UTC

ForumBitcointalk · 原文

我怀疑 Windows 上没有 mmap(2)。我宁愿调用现成的文件复制函数，也不愿自己写一个再测试。

引用自 nelisky，发表于 August 27, 2010, 01:21:09 AM（https://bitcointalk.org/index.php?topic=921.msg11346#msg11346）

但如果你已经在用 boost::filesystem 的功能，就可以用它里面的 copy_file。我只是觉得，如果不是别处已经需要它，就有点小题大做了。

谢谢。我就想它应该在里面某个地方。

我们已经在十几处用了 boost::filesystem。这不是新增的依赖。它给了我们很多可移植的东西，否则我们得为每个操作系统写 #ifdef，还得到处测试。

英文原文

I doubt there's an mmap(2) on Windows. I'd rather call an existing file copy function than make and test my own.

Quote from: nelisky on August 27, 2010, 01:21:09 AM（https://bitcointalk.org/index.php?topic=921.msg11346#msg11346）

But if you are already using features from boost::filesystem you can use copy_file from that. I just think that, if not already required for something else, it's a tad overkill.

Thanks. I thought it would be in there somewhere.

We already use boost::filesystem in a dozen places. It's not a new added dependency. It gives us a lot of portable stuff that we would otherwise have to have a #ifdef for each OS and test everywhere.

Re: auto backing up of wallet.dat

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: auto backing up of wallet.dat

Date2010-08-27 15:47:57 UTC

ForumBitcointalk · 原文

抱歉，我最近太忙了，消息只能粗看，还是跟不上。

我们要尽量避免 Windows API 调用。它们通常要 6-8 个参数，还要大量测试才能写对，做件简单的事得写一页代码。

我通常也回避 iostreams。感觉经常碰到它的局限。90 年代他们把 C++ 流标准搞砸了，挺可惜的，流做好了可以非常强大好用。在 rpc.cpp 里用它，没准还是个错误。

归根结底，我宁愿调用现成的文件复制函数，也不愿自己写一个再测试。

英文原文

Sorry, I've been so busy lately I've been skimming messages and I still can't keep up.

We want to avoid Windows API calls whenever possible. They usually take about 6-8 parameters and a lot of testing to get right, it takes a page of code to do something simple.

I usually shy away from iostreams. Seems like I too often hit limitations. They kind of botched the C++ streams standard in the 90's, which is too bad, streams can be very powerful and useful when done right. Using it in rpc.cpp may still turn out to be a mistake.

Bottom line is I'd rather call an existing file copy function than make and test my own.

Re: New web service: obtain dump of bitcoin block NNNN

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: New web service: obtain dump of bitcoin block NNNN

Date2010-08-27 16:13:16 UTC

ForumBitcointalk · 原文

这有点意思，像一张倒置的柱状图，显示每天产生了多少个区块。目标是每天 144 个区块。

英文原文

That's kind of interesting as an upside-down bar chart of how many blocks were produced each day. The target is 144 blocks per day.

Re: Bitcoins are most like shares of common stock

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Bitcoins are most like shares of common stock

Date2010-08-27 16:39:26 UTC

ForumBitcointalk · 原文

比特币没有股息，也没有潜在的未来股息，所以不像股票。

更像收藏品或商品。

英文原文

Bitcoins have no dividend or potential future dividend, therefore not like a stock.

More like a collectible or commodity.

Re: Bitcoin does NOT violate Mises' Regression Theorem

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Bitcoin does NOT violate Mises' Regression Theorem

Date2010-08-27 17:32:07 UTC

ForumBitcointalk · 原文

做个思想实验，想象有一种贱金属，像黄金一样稀缺，但有以下特性：
- 颜色是无趣的灰色
- 不是电的良导体
- 强度一般，也不延展、不易锻造
- 没有任何实用或装饰用途

还有一个特殊的、神奇的特性：
- 可以通过通信信道传输

如果它不知怎的出于某种原因获得了一点价值，那么任何想远距离转移财富的人都可以买一些，传输过去，让接收方卖掉。

也许它能像你建议的那样循环获得初始价值：人们预见到它作为交换媒介的潜在用途。（我肯定会想要一些）也许收藏家、随便什么随机原因都可能点燃它。

我认为，货币的传统资格标准是在这样的假设下写成的：世上有太多稀缺的竞争物品，有内在价值自动加持的物品一定会胜过没有内在价值的。但如果世上根本没有能用作货币的有内在价值的东西，只有稀缺而无内在价值，我认为人们还是会用起某种东西。

（我这里用"稀缺"一词仅指潜在供应有限）

英文原文

As a thought experiment, imagine there was a base metal as scarce as gold but with the following properties:
- boring grey in colour
- not a good conductor of electricity
- not particularly strong, but not ductile or easily malleable either
- not useful for any practical or ornamental purpose

and one special, magical property:
- can be transported over a communications channel

If it somehow acquired any value at all for whatever reason, then anyone wanting to transfer wealth over a long distance could buy some, transmit it, and have the recipient sell it.

Maybe it could get an initial value circularly as you've suggested, by people foreseeing its potential usefulness for exchange. (I would definitely want some) Maybe collectors, any random reason could spark it.

I think the traditional qualifications for money were written with the assumption that there are so many competing objects in the world that are scarce, an object with the automatic bootstrap of intrinsic value will surely win out over those without intrinsic value. But if there were nothing in the world with intrinsic value that could be used as money, only scarce but no intrinsic value, I think people would still take up something.

(I'm using the word scarce here to only mean limited potential supply)

Version 0.3.11 with upgrade alerts

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleVersion 0.3.11 with upgrade alerts

Date2010-08-27 21:54:12 UTC

ForumBitcointalk · 原文

0.3.11 版本现已发布。

改动：
- 加载时对 blk*.dat 做一些检查
- -4way 代码用 -march=amdfam10 构建，稍快一点
- 时钟偏差太大时警告
- getinfo 命令也能看到警告/错误/警报
- 警报系统

警报系统可以在状态栏显示通知，提醒你正在运行的版本需要为重要的安全更新而升级。

收到警报后，你的节点还可能进入安全模式，禁用以下 json-rpc 命令（自动化网站在用），以保护它在你有机会升级之前不丢钱：
sendtoaddress
getbalance
getreceivedbyaddress
getreceivedbylabel
listreceivedbyaddress
listreceivedbylabel

如果你认定这是误报并愿意冒险，可以用 -disablesafemode 开关重新启用它们。

这是重要的安全改进。对于一大类可能的问题，一旦发现问题，它能立刻警告所有人，防止他们基于错误信息行动。

节点继续运行，收到警报也不会停止生成，所以旧版本仍可能试图制造分叉，但警报系统能确保用户被警告、不要对分叉里的任何东西采取行动。

下载：
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.11/

英文原文

Version 0.3.11 is now available.

Changes:
- Some blk*.dat checking on load
- Built the -4way code with -march=amdfam10, which makes it a little faster
- Warning if your clock is too far off
- Warnings/errors/alerts can also be seen in the getinfo command
- Alert system

The alert system can display notifications on the status bar to alert you if you're running a version that needs to be upgraded for an important security update.

In response to an alert, your node may also go into safe mode, which disables the following json-rpc commands (used by automated websites) to protect it from losing money until you get a chance to upgrade:
sendtoaddress
getbalance
getreceivedbyaddress
getreceivedbylabel
listreceivedbyaddress
listreceivedbylabel

If you decide it's a false alarm and want to take your chances, you can use the switch -disablesafemode to re-enable them.

This is an important safety improvement. For a large segment of possible problems, this can warn everyone immediately once a problem is discovered and prevent them from acting on bad information.

Nodes keep operating and do not stop generating in response to an alert, so old versions may still try to make a fork, but the alert system can make sure users are warned not to act on anything in the fork.

Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.11/

Re: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10

Date2010-08-28 14:27:15 UTC

ForumBitcointalk · 原文

简化是故意的。1.34 亿多次里只有一次会出现一个以上的 thash[7]=0。它只会慢 0.0000007%。

英文原文

The simplification is intentional. There will only be more than one thash[7]=0 in one out of 134,217,728 cases. It only makes it 0.0000007% slower.

Re: Version 0.3.11 with upgrade alerts

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Version 0.3.11 with upgrade alerts

Date2010-08-28 14:54:04 UTC

ForumBitcointalk · 原文

引用自 torservers，发表于 August 28, 2010, 01:00:37 PM（https://bitcointalk.org/index.php?topic=941.msg11499#msg11499）

"关于"对话框里还是显示 0.3.10.1 beta。

什么操作系统？我在 Windows 和 64 位 Linux 版本上运行过，也检查过关于对话框。

Mac 版本还是 0.3.10.1。

引用自 pavelo，发表于 August 28, 2010, 07:36:07 AM（https://bitcointalk.org/index.php?topic=941.msg11481#msg11481）

iirc，可以用某个 gcc __attribute__ 按函数指定 -march。这样只有相关的函数会被优化，如果用户没指定 -4way，其他都该没问题。

我把首帖更新得更明确了。只有 -4way 代码是这样编译的。

英文原文

Quote from: torservers on August 28, 2010, 01:00:37 PM（https://bitcointalk.org/index.php?topic=941.msg11499#msg11499）

The "About" dialog still shows 0.3.10.1 beta.

What OS? I ran the Windows and 64-bit Linux version and checked the about dialog.

The Mac version is still 0.3.10.1.

Quote from: pavelo on August 28, 2010, 07:36:07 AM（https://bitcointalk.org/index.php?topic=941.msg11481#msg11481）

iirc, it is possible to specify -march on a per-function basis using some gcc __attribute__. That way, only the function in question would be optimized, and if the user doesn't specify -4way, everything else should be ok.

I updated the first post to be more specific. Only the -4way code is compiled this way.

Re: Big endian code problems

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Big endian code problems

Date2010-08-29 22:14:36 UTC

ForumBitcointalk · 原文

代码通篇都假设小端字节序，写的时候就没打算移植到大端。每个通过网络发送的整数都得做字节交换，代码里还有几十处别的地方也要改。不值得为此增加代码臃肿。

反正大端字节序正在被淘汰。

英文原文

The code assumes little-endian throughout and was written with the intention of never being ported to big-endian. Every integer that is sent over the network would have to be byte swapped, in addition to many dozens of other places in code. It would not be worth the extra sourcecode bloat.

Big-endian is on its way out anyway.

Re: CryptoPP Assertion Error

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: CryptoPP Assertion Error

Date2010-09-05 23:25:32 UTC

ForumBitcointalk · 原文

你大概可以直接把这行注释掉
cryptopp/secblock.h:187
//assert(false);

告诉我行不行，注意看会不会内存泄漏。

这看起来像个模板类，用来确保派生类定义自己的 allocate 和 deallocate 版本。如果这真是问题所在还一路进了 release 版，那就奇怪了。大概是误报。

英文原文

You can probably just comment out the line
cryptopp/secblock.h:187
//assert(false);

Let me know if it works, and watch if it memory leaks.

It looks like a template class to make sure the derived class defines its own version of allocate and deallocate. It would be weird if that was the actual problem and it made it all the way to release. Probably a false alarm.

Re: Warning : Check your system ( Help me )

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Warning : Check your system ( Help me )

Date2010-09-05 23:36:20 UTC

ForumBitcointalk · 原文

这条错误信息换成什么文案更好，能让下一个人不那么困惑？有建议吗？

它是想告诉他们时钟错了，需要校正。

它依赖 3 个时间源：
1) 系统时钟
2) 其他节点（如果与系统时钟相差一小时以内）
如果这两者不一致，那就
3) 用户（请用户修正系统时钟）

我想过 NTP，但这个更安全。

英文原文

Any suggestions for better text to put for this error message so the next person will be less likely to be confused?

It's trying to tell them their clock is wrong and they need to correct it.

It's relying on 3 time sources:
1) the system clock
2) the other nodes, if within an hour of the system clock
if those disagree, then
3) the user (asking the user to fix the system clock)

I've thought about NTP, but this is more secure.

Re: HTTP status codes from the JSON-RPC api

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: HTTP status codes from the JSON-RPC api

Date2010-09-06 21:21:21 UTC

ForumBitcointalk · 原文

这已纳入 SVN rev 147。

这更标准，虽然 json-rpc 1.0 没规定错误对象的格式，但它规定了错误是对象而不是字符串或其他值，所以我们得改成正确的。code/message 成员在后来的 json-rpc 规范里成了标准。

如果你的代码检查错误并期望是个字符串，你得改。出错时，error 成员现在是个对象，不再是字符串。

SVN rev 147 里还有：
- 命令行 json-rpc 把错误码作为退出码返回。unix 上退出码只能是 0-255，所以是 abs(code)%256。
- 另一个帖子里讨论过的 "backupwallet <destination>" 命令。它锁定钱包并复制，你可以确信拿到的是正确的拷贝。

英文原文

This is in SVN rev 147.

This is more standard, and although json-rpc 1.0 didn't specify the format of error objects, it did specify that they would be objects not strings or other values, so we needed to change this to be correct. The code/message members have become standard in later json-rpc specs.

If you have code that checks the error and expects a string, you'll need to change it. When there is an error, the error member is now an object not a string.

Also in SVN rev 147:
- The command line json-rpc returns the error code as its exit code. Exit codes can only be 0-255 on unix, so it's abs(code)%256.
- The "backupwallet <destination>" command that was discussed in another thread. It locks the wallet and copies it, so you can be sure you get a correct copy.

Re: Warning : Check your system ( Help me )

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Warning : Check your system ( Help me )

Date2010-09-06 21:41:06 UTC

ForumBitcointalk · 原文

引用自 Insti，发表于 September 06, 2010, 12:51:37 PM（https://bitcointalk.org/index.php?topic=960.msg12101#msg12101）

引用自 satoshi，发表于 September 05, 2010, 11:36:20 PM（https://bitcointalk.org/index.php?topic=960.msg12063#msg12063）

这条错误信息换成什么文案更好，能让下一个人不那么困惑？有建议吗？

"请检查你电脑的日期和时间是否正确。如果时钟错了，比特币将无法正常工作。"

谢谢。

英文原文

Quote from: Insti on September 06, 2010, 12:51:37 PM（https://bitcointalk.org/index.php?topic=960.msg12101#msg12101）

Quote from: satoshi on September 05, 2010, 11:36:20 PM（https://bitcointalk.org/index.php?topic=960.msg12063#msg12063）

Any suggestions for better text to put for this error message so the next person will be less likely to be confused?

"Please check that your computer's date and time are correct. If your clock is wrong Bitcoin will not work properly."

Thanks.

Re: auto backing up of wallet.dat

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: auto backing up of wallet.dat

Date2010-09-06 21:45:10 UTC

ForumBitcointalk · 原文

rpc backupwallet <destination> 已纳入 SVN rev 147。

英文原文

rpc backupwallet <destination> is in SVN rev 147.

Re: bitcoind as daemon in OSX

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: bitcoind as daemon in OSX

Date2010-09-06 21:52:45 UTC

ForumBitcointalk · 原文

你能构建吗？

试试把 init.cpp 第 78 行从：
#ifdef __WXGTK__

改成：
#ifndef __WXMSW__

如果行，我就改源码。应该行。

英文原文

Can you build?

Try changing line 78 of init.cpp from:
#ifdef __WXGTK__

to:
#ifndef __WXMSW__

If that works, I'll change the source. It should work.

Re: Always pay transaction fee?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Always pay transaction fee?

Date2010-09-07 16:32:21 UTC

ForumBitcointalk · 原文

另一个办法是减少每个区块允许的免费交易数量，超过就要求交易费。每个区块节点只收这么多 KB 的免费交易，之后就至少要求 0.01 交易费。

阈值大概应该比现在低。

我认为阈值不该是 0。我们应该永远允许至少一些免费交易。

英文原文

Another option is to reduce the number of free transactions allowed per block before transaction fees are required. Nodes only take so many KB of free transactions per block before they start requiring at least 0.01 transaction fee.

The threshold should probably be lower than it currently is.

I don't think the threshold should ever be 0. We should always allow at least some free transactions.

Version 0.3.12

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleVersion 0.3.12

Date2010-09-07 19:17:55 UTC

ForumBitcointalk · 原文

0.3.12 版本现已发布。

特性：
- json-rpc 错误返回更标准的错误对象。（感谢 Gavin Andresen）
- json-rpc 命令行返回退出码。
- json-rpc "backupwallet" 命令。
- 如果收到的消息引发异常，能恢复并继续。其他节点本不该能引发异常，之前也没发生过，但如果有人找到引发异常的办法，这能防止它被用来让网络节点停机。

如果你有检查错误字符串内容的 json-rpc 代码，需要改成期望形如 {"code":<number>,"message":<string>} 的错误对象，这是标准。看这个帖子：
http://bitcointalk.org/index.php?topic=969.0

下载：
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.12/

英文原文

Version 0.3.12 is now available.

Features:
- json-rpc errors return a more standard error object. (thanks to Gavin Andresen)
- json-rpc command line returns exit codes.
- json-rpc "backupwallet" command.
- Recovers and continues if an exception is caused by a message you received. Other nodes shouldn't be able to cause an exception, and it hasn't happened before, but if a way is found to cause an exception, this would keep it from being used to stop network nodes.

If you have json-rpc code that checks the contents of the error string, you need to change it to expect error objects of the form {"code":<number>,"message":<string>}, which is the standard. See this thread:
http://bitcointalk.org/index.php?topic=969.0

Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.12/

Re: Always pay transaction fee?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Always pay transaction fee?

Date2010-09-08 17:30:14 UTC

ForumBitcointalk · 原文

目前，付不付手续费由 -paytxfee 开关手动控制。让软件自动检查最近区块的大小、看要不要付手续费，其实很容易。我们离阈值还远得很，暂时不需要。反正先手动控制、看看情况也是好主意。

就算达到阈值也不是大事。免费交易只是进块慢一点。

我粗略统计了 74000-78000 附近的 4000 个区块，不含区块奖励交易：

平均每个区块 2 笔交易，每小时 17 笔，每天 400 笔。

平均每个区块交易字节数 428 字节，即每笔交易 214 字节。

当前阈值是每区块 200KB，约每区块 1000 笔交易。我觉得应该降到每区块 50KB。那仍是平均每区块交易量的 100 多倍。

阈值以后很容易改。到时候我们可以决定提高。把它保持低一点当断路器、按需提高是好主意。如果现在就触及阈值，那几乎肯定是某种泛洪而不是真实使用。阈值低一点有助于在那种情况下限制浪费的磁盘空间。

英文原文

Currently, paying a fee is controlled manually with the -paytxfee switch. It would be very easy to make the software automatically check the size of recent blocks to see if it should pay a fee. We're so far from reaching the threshold, we don't need that yet. It's a good idea to see how things go with controlling it manually first anyway.

It's not a big deal if we reach the threshold. Free transactions would just take longer to get into a block.

I did a rough tally of 4000 blocks from around 74000-78000. This is excluding the block reward transactions:

There were average 2 transactions per block, 17 transactions per hour, 400 transactions per day.

Average transaction bytes per block was 428 bytes, or 214 bytes per transaction.

The current threshold is 200KB per block, or about 1000 transactions per block. I think it should be lowered to 50KB per block. That would still be more than 100 times the average transactions per block.

The threshold can easily be changed in the future. We can decide to increase it when the time comes. It's a good idea to keep it lower as a circuit breaker and increase it as needed. If we hit the threshold now, it would almost certainly be some kind of flood and not actual use. Keeping the threshold lower would help limit the amount of wasted disk space in that event.

Re: Version 0.3.12

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Version 0.3.12

Date2010-09-08 18:06:04 UTC

ForumBitcointalk · 原文

比特币客户端目前只创建和识别符合两种可能模板的交易。

那些是快速测试，粗略检查交易是否符合那些标准交易的一些通用指标。节点只会把这些交易打包进区块。

将来如果在现有的 2 种交易类型之外增加更多模板，我们可以把"不愿打包非标准交易"的测试改成接受它们。

英文原文

Bitcoin clients currently only create and recognize transactions that match two possible templates.

Those are some quick tests that loosely check if transactions fit some general metrics that those standard transactions fit. Nodes will only work on adding those transactions to their block.

In the future, if we add more templates to the existing 2 types of transactions, we can change the "rather not work on nonstandard transactions" test to accept them.

Re: Bitcoin Blogger: Is It Better To Buy Or Generate Bitcoins?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Bitcoin Blogger: Is It Better To Buy Or Generate Bitcoins?

Date2010-09-08 20:27:39 UTC

ForumBitcointalk · 原文

引用自 BitLex，发表于 September 07, 2010, 08:10:54 PM（https://bitcointalk.org/index.php?topic=955.msg12189#msg12189）

AMD X3 @2.8ghz
->stock client
~3800khs ~150Watt

你试过 -4way 吗？

引用

24 核机器能期望多少哈希？我有个四核每秒生成 4,300 哈希，我估计 24 核机器挖比特币能到每秒 25,000 哈希。

AMD Phenom（我记得是 4 核）CPU 用 -4way 大约 11,000khps，快约 100%。24 核该有 66,000khps。AMD 是最好的选择，因为它的 SSE2 实现最好。（或者是因为 tcatm 用的是 AMD，按它优化了代码）

还有太多别的事要做，我还没时间把 -4way 做成自动。目前还得手动。
http://bitcointalk.org/index.php?topic=820.0

英文原文

Quote from: BitLex on September 07, 2010, 08:10:54 PM（https://bitcointalk.org/index.php?topic=955.msg12189#msg12189）

AMD X3 @2.8ghz
->stock client
~3800khs ~150Watt

Did you try -4way?

Quote

How many hashes can I expect with a 24 core machine? I have a quad-core generating 4,300 hashes-per-second, so I am estimating a 24-core machine could mine bitcoins at 25,000 hashes-per-second.

AMD Phenom (I think 4-core) CPUs are doing about 11,000khps with -4way, about 100% speedup. 24 cores should get 66,000khps. AMD is the best choice because it has the best SSE2 implementation. (or maybe because tcatm had an AMD and optimised his code for that)

There's been so much else to do that I haven't had time to make -4way automatic. For now you still have to do it manually.
http://bitcointalk.org/index.php?topic=820.0

Auto-detect for 128-bit 4-way SSE2

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleAuto-detect for 128-bit 4-way SSE2

Date2010-09-09 01:04:05 UTC

ForumBitcointalk · 原文

SVN rev 150 有些代码，尝试自动检测是否用 4-way SSE2。我们需要这个，因为它只在某些有 128 位 SSE2 的较新 CPU 上更快，64 位 SSE2 的不行。

它用 CPUID 指令获取 CPU 品牌、家族、型号和步进。这是容易的部分。难的是知道拿型号怎么办。我找不到 CPU 家族、型号、步进编号表，只能依据看到的各种零散报告。

最后是这样的：
Code: // We need Intel Nehalem or AMD K10 or better for 128bit SSE2
// Nehalem = i3/i5/i7 and some Xeon
// K10 = Opterons with 4 or more cores, Phenom, Phenom II, Athlon II
// Intel Core i5 family 6, model 26 or 30
// Intel Core i7 family 6, model 26 or 30
// Intel Core i3 family 6, model 37
// AMD Phenom family 16, model 10
bool fUseSSE2 = ((fIntel && nFamily * 10000 + nModel >= 60026) ||
(fAMD && nFamily * 10000 + nModel >= 160010));

我在 AMD CPU 上看到一些零散的不一致的型号，所以不确定这能不能覆盖所有有能力的 AMD。

如果错了，你还可以用 -4way 或 -4way=0 覆盖。

它把发现的东西打印到 debug.log。搜 CPUID。

只在用 GCC 构建时启用。

英文原文

SVN rev 150 has some code to try to auto-detect whether to use 4-way SSE2. We need this because it's only faster on certain newer CPUs that have 128-bit SSE2 and not ones with 64-bit SSE2.

It uses the CPUID instruction to get the CPU brand, family, model number and stepping. That's the easy part. Knowing what to do with the model number is the hard part. I was not able to find any table of family, model and stepping numbers for CPUs. I had to go by various random reports I saw.

Here's what I ended up with:
Code: // We need Intel Nehalem or AMD K10 or better for 128bit SSE2
  // Nehalem = i3/i5/i7 and some Xeon
  // K10 = Opterons with 4 or more cores, Phenom, Phenom II, Athlon II
  // Intel Core i5 family 6, model 26 or 30
  // Intel Core i7 family 6, model 26 or 30
  // Intel Core i3 family 6, model 37
  // AMD Phenom family 16, model 10
  bool fUseSSE2 = ((fIntel && nFamily * 10000 + nModel >= 60026) ||
   (fAMD && nFamily * 10000 + nModel >= 160010));

I saw some sporadic inconsistent model numbers for AMD CPUs, so I'm not sure if this will catch all capable AMDs.

If it's wrong, you can still override it with -4way or -4way=0.

It prints what it finds in debug.log. Search on CPUID.

This is only enabled if built with GCC.

Re: Won't let me send coins because it requires a transaction fee?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Won't let me send coins because it requires a transaction fee?

Date2010-09-10 00:23:24 UTC

ForumBitcointalk · 原文

出问题的是哪个版本？release 构建，还是自己构建的？什么操作系统？

你是用 IP 还是用比特币地址发送的？

你发送 49.99 时，它提示你付 0.01 手续费了吗？

GetMinFee 有个改动，但我想不出它怎么会导致这个。它只在区块变得巨大时才开始起作用。

区块号差 1 的原因是 0.3.11 里显示的数字减了 1，这样更合理。

英文原文

What version is the one where this happened? Release build, or built it yourself? Which operating system?

Were you sending by IP or by Bitcoin Address?

When you sent 49.99, did it prompt you to pay a 0.01 fee?

There was a change in GetMinFee, but I can't see how it would cause this. It only starts to apply when a block gets huge.

The reason for the difference in block number is the number displayed was reduced by 1 in 0.3.11 because it made more sense that way.

Re: Won't let me send coins because it requires a transaction fee?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Won't let me send coins because it requires a transaction fee?

Date2010-09-10 00:46:37 UTC

ForumBitcointalk · 原文

我想我知道怎么回事了。双击那笔生成的交易。它里面大概有个小于 0.01 的交易费。

有人一直在付 0.00000010 的交易费。我觉得用 -paytxfee 都设不出这个，得改代码才行。你生成的区块值 50.00000010，所以你想全额发送时，找零剩 0.00000010，触发了防粉尘垃圾的 0.01 手续费。

平时这无害，只在这个边角情况下出问题。我应该在 CreateTransaction 里加个特例处理。

英文原文

I think I know what happened. Doubleclick on the generated transaction. It probably has a sub-0.01 transaction fee in it.

Someone has been paying a 0.00000010 transaction fee. I don't think you can even set that with -paytxfee, I think you'd have to modify the code to do it. Your generated block is worth 50.00000010, so when you try to send the whole thing you have 0.00000010 left over for the change, which triggers the dust spam 0.01 fee.

It would normally be harmless except in this corner case. I should add a special case to CreateTransaction to handle this.

Re: Won't let me send coins because it requires a transaction fee?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Won't let me send coins because it requires a transaction fee?

Date2010-09-10 17:12:33 UTC

ForumBitcointalk · 原文

修复已纳入 SVN rev 151。

下次升级后，你就能发出卡住的 0.01（实际是 0.01000010）了。

英文原文

The fix is in SVN rev 151.

You will be able to send your stuck 0.01 (actually 0.01000010) when you next upgrade.

Re: Auto-detect for 128-bit 4-way SSE2

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Auto-detect for 128-bit 4-way SSE2

Date2010-09-10 18:11:06 UTC

ForumBitcointalk · 原文

引用自 teknohog，发表于 September 09, 2010, 07:32:05 PM（https://bitcointalk.org/index.php?topic=1007.msg12336#msg12336）

因为 CallCPUID 函数包含 x86 汇编，它在其他架构上破坏构建。我把 main.cpp 第 2770 行改成了

#if defined(__GNUC__) && defined(CRYPTOPP_X86_ASM_AVAILABLE)

至少在 ARM 上又能编译了。

已加入 SVN rev 152。

英文原文

Quote from: teknohog on September 09, 2010, 07:32:05 PM（https://bitcointalk.org/index.php?topic=1007.msg12336#msg12336）

Since the function CallCPUID function contains x86 assembler, it breaks the build on other architectures. I've changed line 2770 in main.cpp to

#if defined(__GNUC__) && defined(CRYPTOPP_X86_ASM_AVAILABLE)

to make it compile again, at least on ARM.

Added in SVN rev 152

Re: Running on a port other than 8333

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Running on a port other than 8333

Date2010-09-12 17:40:20 UTC

ForumBitcointalk · 原文

引用自 lachesis，发表于 August 10, 2010, 03:24:55 PM（https://bitcointalk.org/index.php?topic=589.msg8544#msg8544）

另外，比特币打开 BerkeleyDB 是独占的吗，从而不需要文件锁？它不是——我自己测试过。

有办法独占打开 BerkeleyDB 吗？

DB_PRIVATE 是两头不讨好。DB_PRIVATE 不是独占的，但别的进程同时访问时它会被搞坏。

我在 rev 153 里去掉了 DB_PRIVATE 标志。

英文原文

Quote from: lachesis on August 10, 2010, 03:24:55 PM（https://bitcointalk.org/index.php?topic=589.msg8544#msg8544）

Also, does Bitcoin open the BerkeleyDB as exclusive, precluding the need for a file lock?It does not -- did my own tests.

Is there a way to open BerkeleyDB exclusive?

DB_PRIVATE is the worst of both worlds. DB_PRIVATE is not exclusive, but it does make it get screwed up if another process tries to access it at the same time.

I've dropped the DB_PRIVATE flag in rev 153.

Re: RFC: remove DB_PRIVATE flag

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: RFC: remove DB_PRIVATE flag

Date2010-09-12 18:00:39 UTC

ForumBitcointalk · 原文

rev 153 里在试去掉 DB_PRIVATE 标志。我们得盯着看有什么不同。

至少在 Windows 上，它会创建六个 __db.001 - __db.006 文件，大小从 24K 到 4MB。退出时不删除，就留在那。

文档说它用内存映射文件。我猜它们的权限和数据库文件一样，所以同样的用户访问限制适用。

Windows 私有局域网下载 78500 个区块的测试：
with DB_PRIVATE 20 minutes 51 seconds
without DB_PRIVATE 20 minutes 51 seconds

没想到会分毫不差。

英文原文

Trying it without the DB_PRIVATE flag in rev 153. We need to keep an eye on what's different.

On Windows at least, it creates six __db.001 - __db.006 files with sizes from 24K to 4MB. It doesn't delete them on exit, it just leaves them behind.

The docs say it uses memory mapped files. I assume they have the same file permissions as the database files, so the same user access restrictions apply.

Tests on Windows private LAN download of 78500 blocks:
with DB_PRIVATE 20 minutes 51 seconds
without DB_PRIVATE 20 minutes 51 seconds

I wasn't expecting them to come out exactly the same.

Re: Switch to GPL

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Switch to GPL

Date2010-09-12 19:24:53 UTC

ForumBitcointalk · 原文

如果唯一的库是闭源的，那就有人去做个开源的。

如果唯一的库是 GPL 的，那就有人去做个非 GPL 的。

如果最好的库是 MIT、Boost、new-BSD 或公有领域，那我们就不用反复重写了。

我不否认 GPL 对操作系统是个好许可证，尤其非 GPL 代码还允许与 OS 对接。对小项目，我觉得对闭源接管的恐惧被夸大了。

英文原文

If the only library is closed source, then there's a project to make an open source one.

If the only library is GPL, then there's a project to make a non-GPL one.

If the best library is MIT, Boost, new-BSD or public domain, then we can stop re-writing it.

I don't question that GPL is a good license for operating systems, especially since non-GPL code is allowed to interface with the OS. For smaller projects, I think the fear of a closed-source takeover is overdone.

Re: Memory leak

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Memory leak

Date2010-09-19 17:22:03 UTC

ForumBitcointalk · 原文

在 0 和 2 个连接之间跳，可能是它在连自己。你用了 "-connect" 开关吗？

你自己编译的还是 release 构建，什么版本？

200Kb/sec 我不太确定，因为连接尝试之间至少等半秒。它在 0 和 2 个连接之间闪得多快？比每秒两次还快？

linux 上的等待函数是：

inline void Sleep(int64 n)
{
boost::thread::sleep(boost::get_system_time() + boost::posix_time::milliseconds(n));
}

如果它工作不正常，循环就可能全速空转。

英文原文

Bouncing between 0 and 2 connections could be if it's connecting to itself. Are you using the "-connect" switch?

Did you compile it or is this a release build, and what version?

I'm not sure how the 200Kb/sec, since it waits at least a half second between connection attempts. How fast is it flickering between 0 and 2 connections? Faster than twice a second?

The wait function on linux is:

inline void Sleep(int64 n)
{
boost::thread::sleep(boost::get_system_time() + boost::posix_time::milliseconds(n));
}

If that doesn't work right, then it would be possible for it to spin through the loop as fast as it can.

Re: Issues building bitcoin on Windows 7

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Issues building bitcoin on Windows 7

Date2010-09-19 18:46:46 UTC

ForumBitcointalk · 原文

它卡住的行：
Code:ERROR extern map<string, string> mapAddressBook;
ERROR extern CCriticalSection cs_mapAddressBook;
ERROR extern vector<unsigned char> vchDefaultKey;
OK extern bool fClient;
OK extern int nBestHeight;

OK extern unsigned int nWalletDBUpdated;
ERROR extern DbEnv dbenv;

所以它表现得像什么都没定义，连 map 和 vector 都没有。

可 db.h 是被 headers.h 包含的（只在那，别处没有），headers.h 在 db.h 之前包含了 vector、map、util.h 和一切。

是不是 VC 在用预编译头搞砸了？你的目录里会不会有之前失败尝试留下的预编译头文件，被它找到用了？

现在有个安装包，装 MinGW 非常容易。别用最新的 4.5.0，用旧几个版本比如 4.4.1 (1.908.0) 或 1.812.0。安装程序一站式装好，不像以前那么难。我记得我唯一要做的就是把 make*.exe 改名成 make.exe。
http://tdm-gcc.tdragon.net/

题外话：要是有谁能把 tcatm 的 4-way 128-bit SSE2 代码在 Windows 上跑起来就好了。MinGW 的优化有点问题，我不确定，也许是栈上 16 字节对齐的问题，导致段错误。我摆弄了一下，在测试程序里能跑通他的代码，但不知为什么在比特币本身里不行。

英文原文

The lines it's tripping on:
Code:ERROR extern map<string, string> mapAddressBook;
ERROR extern CCriticalSection cs_mapAddressBook;
ERROR extern vector<unsigned char> vchDefaultKey;
OK extern bool fClient;
OK extern int nBestHeight;

OK extern unsigned int nWalletDBUpdated;
ERROR extern DbEnv dbenv;

So it's acting like nothing is defined, not even map and vector.

Yet, db.h is included by headers.h (and only there, nowhere else) which includes vector, map, util.h and everything before db.h.

Is VC trying to use precompiled headers and screwing it up? Could there be some leftover precompiled header files in your directory from previously failed attempts that it's finding and using?

There's an installer package now that makes it really easy to install MinGW. Don't use the latest version 4.5.0, use a few versions back like 4.4.1 (1.908.0) or 1.812.0. A setup program completely installs everything, it's not hard like it used to be. I think the only thing I had to do was rename make*.exe something to make.exe.
http://tdm-gcc.tdragon.net/

Off topic, but: It would be nice if someone would hack on getting tcatm's 4-way 128-bit SSE2 code working on Windows. There's something with MinGW's optimisation, I'm not sure but maybe a problem with 16-byte alignment on the stack, that makes it segfault. With some fiddling, I was able to get his code to work in a test program, but not in Bitcoin itself for some reason.

Re: Bug? /usr/bin/bitcoind ""

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Bug? /usr/bin/bitcoind ""

Date2010-09-19 19:58:11 UTC

ForumBitcointalk · 原文

我对那些 bug 跟踪器一无所知。真要搞一个，得好好调研再选。

只用论坛我们管得挺好。bug 发在论坛我更可能看到，我觉得其他用户也更可能在这里帮忙解决和追问，而不是在 bug 跟踪器里。关键一步是其他用户帮忙解决那些简单的、其实不是 bug、只是误解或困惑的东西。

我在论坛上看到的所有未解决 bug，我都记了个清单。有些我还在想修复的最佳设计。这类软件不能留那么多未解决的 bug，多到需要跟踪器来管。

英文原文

I don't know anything about any of the bug trackers. If we were to have one, we would have to make a thoroughly researched choice.

We're managing pretty well just using the forum. I'm more likely to see bugs posted in the forum, and I think other users are much more likely to help resolve and ask follow up questions here than if they were in a bug tracker. A key step is other users helping resolve the simple stuff that's not really a bug but some misunderstanding or confusion.

I keep a list of all unresolved bugs I've seen on the forum. In some cases, I'm still thinking about the best design for the fix. This isn't the kind of software where we can leave so many unresolved bugs that we need a tracker for them.

Re: The case for removing IP transactions

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: The case for removing IP transactions

Date2010-09-19 21:49:30 UTC

ForumBitcointalk · 原文

最好默认禁用按 IP 接收，除非你明确要用。这是一大片没人用的攻击面，默认不该开着。

店面场景下，你通常只想让客户通过你的自动化系统付款，系统只给出与特定订单和账户关联的比特币地址。主动发到服务器 IP 的随机匿名付款没什么用。

一般来说，按 IP 发送的用处有限。如果直连不用代理，中间人风险也许可以忍，但没有隐私。如果用隐私代理，中间人风险高到无法接受。就算我们费劲实现了 SSL，通常也只有大店面会去搞 CA 证书，但那些场景大多还是用比特币地址更好。

我把这个改动上传到了 SVN rev 156。启用的开关是 "-allowreceivebyip"。

这个版本的发送方会收到错误 "Recipient is not accepting transactions sent by IP address"。旧版本的发送方会收到 "Transfer was not accepted"。

我给开关起了个不同的名字，因为 "-allowiptransactions" 听起来像包括发送。如果有更好的开关名，我们可以再改。

英文原文

Probably best to disable receiving by IP unless you specifically intend to use it. This is a lot of surface area that nobody uses that doesn't need to be open by default.

In storefront cases, you would typically only want customers to send payments through your automated system that only hands out bitcoin addresses associated with particular orders and accounts. Random unidentified payments volunteered to the server's IP address would be unhelpful.

In general, sending by IP has limited useful cases. If connecting directly without a proxy, the man-in-the-middle risk may be tolerable, but no privacy. If you use a privacy proxy, man-in-the-middle risk is unacceptably high. If we went to all the work of implementing SSL, only large storefronts usually go to the trouble of getting a CA cert, but most of those cases would still be better off to use bitcoin addresses.

I uploaded this change to SVN rev 156. The switch to enable is "-allowreceivebyip".

Senders with this version will get the error "Recipient is not accepting transactions sent by IP address". Older version senders will get "Transfer was not accepted".

I used a different name for the switch because "-allowiptransactions" sounds like it includes sending. If there's a better name for the switch, we can change it again.

Re: Message Encryption as a built-in feature?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Message Encryption as a built-in feature?

Date2010-09-19 22:47:00 UTC

ForumBitcointalk · 原文

theymos 已经说过了……ECDSA 不支持加密消息。只支持数字签名。

英文原文

Theymos already said this... ECDSA does not support encrypting messages. Only digital signatures.

Re: Always pay transaction fee?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Always pay transaction fee?

Date2010-09-23 16:08:35 UTC

ForumBitcointalk · 原文

引用自 satoshi，发表于 September 08, 2010, 05:30:14 PM（https://bitcointalk.org/index.php?topic=994.msg12237#msg12237）

当前阈值是每区块 200KB，约每区块 1000 笔交易。我觉得应该降到每区块 50KB。那仍是平均每区块交易量的 100 多倍。

这个改动我已在 SVN rev 157 实现。

我之前设这么高，是为了让很大的交易不触发交易费。阈值大约是 26,000 BTC（由 50 BTC 生成的币组成）。虽然那时生成容易 100 倍，但只有几个人在那个量级碰到过手续费。新阈值下，发送生成的币大约 11,000 BTC 会触发。基本只有生成的比特币会触及。如果你买的比特币，它们会是面额更大的交易，离手续费线远得很，除非你分几百笔单独买的。就算真触到手续费线，你也只需付一次，把你的小交易打包到一起。

英文原文

Quote from: satoshi on September 08, 2010, 05:30:14 PM（https://bitcointalk.org/index.php?topic=994.msg12237#msg12237）

The current threshold is 200KB per block, or about 1000 transactions per block. I think it should be lowered to 50KB per block. That would still be more than 100 times the average transactions per block.

I implemented this change in SVN rev 157.

The reason I previously made it so high was to allow very large transactions without hitting the transaction fee. The threshold was around 26,000 BTC for transactions made of 50 BTC generated coins. Even though it was 100 times easier to generate back then, only a few people ever encountered the fee at that level. The new threshold puts it at around 11,000 BTC for sending generated coins. It would mostly only be reached with generated bitcoins. If you bought your bitcoins, they'll be denominated in larger transactions and won't be anywhere near the fee limit, unless you bought them in several hundred separate transactions. Even if you do reach the fee level, you only have to pay it once to bundle your little transactions together.

Internal version number

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleInternal version number

Date2010-09-23 16:19:08 UTC

ForumBitcointalk · 原文

下个版本（0.3.13），我要把内部版本号整数的格式从 313 改成 31300，比如 31305 = 0.3.13.5。最后一个数字代表版本之间 SVN 上的改动，应该在版本号里如实体现。不然，万一某个子版本出了岔子要绕过去，会很麻烦。

英文原文

In the next release (0.3.13), I'm going to change the format of the internal version number integer from 313 to 31300, for instance 31305 = 0.3.13.5. The last number represents changes on the SVN between releases and ought to be properly represented in the version number. Otherwise, it would be a pain if we had a mistake or something in one of the sub versions that needed to be worked around.

Re: Warning : Check your system ( Help me )

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Warning : Check your system ( Help me )

Date2010-09-23 16:28:25 UTC

ForumBitcointalk · 原文

我不明白，你是不是以为程序会设置系统时钟？它不会。

引用自 Cdecker，发表于 September 19, 2010, 08:14:08 PM（https://bitcointalk.org/index.php?topic=960.msg13212#msg13212）

我们已经有办法（大致）同步客户端，为什么不用呢？

我们用基于其他节点时间中位数的内部偏移，但出于安全原因，不让它们把我们偏移超过一小时。如果它们显示我们偏差超过一小时，我们就提醒用户修正时钟。

英文原文

I don't understand, are you under the impression that the program sets the system clock? It doesn't.

Quote from: Cdecker on September 19, 2010, 08:14:08 PM（https://bitcointalk.org/index.php?topic=960.msg13212#msg13212）

We already have ways to synchronize (approximately) the clients, so why not make use of that?

We use an internal offset based on the median of other nodes' times, but for security reasons we don't let them offset us by more than an hour. If they indicate we're off by more than an hour, then we resort to alerting the user to fix their clock.

Re: Porn

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Porn

Date2010-09-23 17:56:55 UTC

ForumBitcointalk · 原文

比特币对没有信用卡、或不想用手头卡的人会很方便：要么不想让配偶在账单上看到，要么不信任把卡号给"色情网站的人"，要么怕被循环扣费。

英文原文

Bitcoin would be convenient for people who don't have a credit card or don't want to use the cards they have, either don't want the spouse to see it on the bill or don't trust giving their number to "porn guys", or afraid of recurring billing.

Re: How divisible are bitcoins - the technical side

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: How divisible are bitcoins - the technical side

Date2010-09-23 18:39:56 UTC

ForumBitcointalk · 原文

我不鼓励用额外的小数位。它们只为将来预留。

你说得对，0.01 以上仍可以有更高精度，但接收方看不到。界面会显示向下取整。

英文原文

I would not encourage using the extra decimal places. They're only intended for future use.

You are correct that above 0.01 can still have additional precision, but the recipient won't be able to see it. The UI will show it rounded down.

Re: Internal version number

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Internal version number

Date2010-09-23 18:46:20 UTC

ForumBitcointalk · 原文

我觉得不会给版本比较带来问题。31300 > 312。

英文原文

I don't think it should cause any problems for version comparisons. 31300 > 312.

Re: How To Make a Distributed BitCoin Escrow Service

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: How To Make a Distributed BitCoin Escrow Service

Date2010-09-26 17:34:26 UTC

ForumBitcointalk · 原文

还没实现，但网络能支持需要两个签名的交易。说明在这：
http://bitcointalk.org/index.php?topic=750.0

它绝对比没有托管的直接付款安全，但不如人工仲裁的托管——假设你足够信任那个人。

这种托管里，骗子赢不了，但你仍可能输。它至少去掉了骗你的牟利动机。卖家确信钱已为他预留，买家则保留了杠杆：完成之前卖家还没拿到钱。

英文原文

It's not implemented yet, but the network can support a transaction that requires two signatures. It's described here:
http://bitcointalk.org/index.php?topic=750.0

It's absolutely safer than a straight payment without escrow, but not as good as a human arbitrated escrow, assuming you trust the human enough.

In this kind of escrow, a cheater can't win, but it's still possible for you to lose. It at least takes away the profit motive for cheating you. The seller is assured that the money is reserved for him, while the buyer retains the leverage that the seller hasn't been paid yet until completion.

Re: I broke my wallet, sends never confirm now.

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: I broke my wallet, sends never confirm now.

Date2010-09-30 16:38:53 UTC

ForumBitcointalk · 原文

正如你发现的，根本问题是：在交易至少有 1 个确认之前，我们不该计入或花掉它们。0/未确认交易是二等公民。它们顶多算个提示，说收到了点东西，但计入余额或花掉还为时过早。

我改了，让它们以较淡的字体显示，入账金额用方括号像 [+1.23]，金额不计入余额、也不能花。这不适用于你发出的交易——那是你自己写的，你当然信任。

我没用 (+1.23)，因为会计里括号表示负数。希望方括号足够不同，能表达清楚。

JSON-RPC 接口如果想看 0/未确认，指定 0 个确认就行。

改动已上传到 SVN rev 158。我很快会发 0.3.13 RC。

如果你的钱包里有这类交易，在升级到 0.3.13 之前不要发任何付款，0.3.13 很快就来。

如果你已经发了这类交易，或者你是它们的创建者，那就用 theymos 的补丁，或做如下修改，用它把干净的交易发到新钱包来清理。

改动：
if (pcoin->GetDepthInMainChain() < 1 && pcoin->GetDebit() <= 0)
continue;
改成：
if (pcoin->GetDepthInMainChain() < 1)
continue;

英文原文

As you figured out, the root problem is we shouldn't be counting or spending transactions until they have at least 1 confirmation. 0/unconfirmed transactions are very much second class citizens. At most, they are advice that something has been received, but counting them as balance or spending them is premature.

I made changes so they show up in lighter print, with the credit amount in square brackets like [+1.23], and the amount not counted towards your balance and not available for spending. This doesn't apply to transactions you sent, which you implicitly trust, since you wrote them.

I didn't make it (+1.23) because parenthesis in accounting means negative. I hope square brackets is different enough to be clear what is meant.

The JSON-RPC interface can still see 0/unconfirmed if it wants by specifying 0 confirmations.

I uploaded the changes to SVN rev 158. I will post a 0.3.13 RC shortly.

If you have any of these transactions in your wallet, do not send any payments until you've upgraded to 0.3.13, which will be coming soon.

If you've already sent any of these transactions, or you're the creator of them, then use theymos' patch or make the following change and use it to send your clean transactions to a new wallet to clean things up.

change:
if (pcoin->GetDepthInMainChain() < 1 && pcoin->GetDebit() <= 0)
continue;
to:
if (pcoin->GetDepthInMainChain() < 1)
continue;

Re: I broke my wallet, sends never confirm now.

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: I broke my wallet, sends never confirm now.

Date2010-09-30 16:59:00 UTC

ForumBitcointalk · 原文

0.3.13 候选发布版，请测试：
http://www.bitcoin.org/download/bitcoin-0.3.13-rc1-win32-setup.exe

英文原文

0.3.13 release candidate, please test:
http://www.bitcoin.org/download/bitcoin-0.3.13-rc1-win32-setup.exe

0.3.13 RC1 for Windows, please test

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

Title0.3.13 RC1 for Windows, please test

Date2010-09-30 17:04:15 UTC

ForumBitcointalk · 原文

0.3.13 候选发布版，很快发布，请测试：
http://www.bitcoin.org/download/bitcoin-0.3.13-rc1-win32-setup.exe

- 在有 1 个确认之前，不计入也不花费付款
http://bitcointalk.org/index.php?topic=1306.0
- 内部版本号从 312 到 31300
- 只有指定 -allowreceivebyip 才接受按 IP 地址发送的交易
- 去掉 DB_PRIVATE Berkeley DB 标志
- 修复带亚分找零时发不出最后一分的问题
- Linux 上自动检测是否用 128-bit 4-way SSE2
Gavin Andresen：
- 选项 -rpcallowip= 接受来自另一台机器的 json-rpc 连接
- Linux 上 SIGTERM 干净关机

英文原文

0.3.13 release candidate, to be released soon so please test:
http://www.bitcoin.org/download/bitcoin-0.3.13-rc1-win32-setup.exe

- don't count or spend payments until they have 1 confirmation
http://bitcointalk.org/index.php?topic=1306.0
- internal version number from 312 to 31300
- only accept transactions sent by IP address if -allowreceivebyip is specified
- dropped DB_PRIVATE Berkeley DB flag
- fix problem sending the last cent with sub-cent fractional change
- auto-detect whether to use 128-bit 4-way SSE2 on Linux
Gavin Andresen:
- option -rpcallowip= to accept json-rpc connections from another machine
- clean shutdown on SIGTERM on Linux

Re: BitCoin Wikipedia page DELETED!!!

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: BitCoin Wikipedia page DELETED!!!

Date2010-09-30 17:50:32 UTC

ForumBitcointalk · 原文

如果你写，我觉得应该是个非常短的单段条目，100 词以内，只说明比特币是什么。

我倒希望他们别删条目，而是限长度。不够出名的东西，至少可以有个说明它是什么的 stub 条目。我经常碰到烦人的红链，那些东西维基至少该听说过。

条目可以简单到这样：
"比特币是一种点对点去中心化电子货币。"

更标准的维基做法是：我们在所属的某个更通用的分类（比如 Electronic Currency 或 Electronic Cash）里占一段，说明我们是它的一个实例。我们大概能在那立住一段。还是那句话，保持短。只说明它是什么。

英文原文

If you do, I think it should be a very brief, single paragraph article like 100 words or less that simply identifies what Bitcoin is.

I wish rather than deleting the article, they put a length restriction. If something is not famous enough, there could at least be a stub article identifying what it is. I often come across annoying red links of things that Wiki ought to at least have heard of.

The article could be as simple as something like:
"Bitcoin is a peer-to-peer decentralised /link/electronic currency/link/."

The more standard Wiki thing to do is that we should have a paragraph in one of the more general categories that we are an instance of, like Electronic Currency or Electronic Cash. We can probably establish a paragraph there. Again, keep it short. Just identifying what it is.

Re: Prioritized transactions, and tx fees

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Prioritized transactions, and tx fees

Date2010-09-30 18:11:56 UTC

ForumBitcointalk · 原文

它随区块填满而提高手续费要求：

<50KB 免费
50KB 0.01
250KB 0.02
333KB 0.03
375KB 0.04
等等。

这是典型的定价机制。前 50KB 售罄后，价格涨到 0.01。250KB 售出后，涨到 0.02。在某个价格上，只要你愿意出价超过其他客户，基本总能挤进去。

光是附上最低的 0.01 就很有用。

英文原文

It ramps up the fee requirement as the block fills up:

<50KB free
50KB 0.01
250KB 0.02
333KB 0.03
375KB 0.04
etc.

It's a typical pricing mechanism. After the first 50KB sells out, the price is raised to 0.01. After 250KB is sold, it goes up to 0.02. At some price, you can pretty much always get in if you're willing to outbid the other customers.

Just including the minimum 0.01 goes a long way.

Re: Prioritized transactions, and tx fees

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Prioritized transactions, and tx fees

Date2010-09-30 18:22:22 UTC

ForumBitcointalk · 原文

没错，开关应该更动态，按 KB 付费。只是不好解释。

英文原文

True, the switch should be something more dynamic that pays per KB. It's harder to think of how to explain it.

Re: Remote RPC access

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Remote RPC access

Date2010-09-30 18:27:41 UTC

ForumBitcointalk · 原文

在自己的局域网里用是安全的，比如一个地方有多台服务器互相通信。

0.3.13 RC1 Windows 版已出：
http://www.bitcoin.org/download/bitcoin-0.3.13-rc1-win32-setup.exe

英文原文

It can be safe if you're using it over your own LAN, like if you have multiple servers at a location that talk to each other.

0.3.13 RC1 is available for Windows:
http://www.bitcoin.org/download/bitcoin-0.3.13-rc1-win32-setup.exe

Re: 0.3.13 RC1 for Windows, please test

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: 0.3.13 RC1 for Windows, please test

Date2010-10-01 00:32:46 UTC

ForumBitcointalk · 原文

0.3.13 来不及了，我尽量抽时间加到下个版本。

英文原文

Too late for 0.3.13, but I'll try to find time to add it to the next version.

Version 0.3.13, please upgrade

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleVersion 0.3.13, please upgrade

Date2010-10-01 00:34:35 UTC

ForumBitcointalk · 原文

0.3.13 版本现已发布。为避免 0/未确认交易可能带来的问题，请升级。注意：如果还没花掉 0/未确认交易，0.3.13 能防住问题；但如果已经花了，你需要 0.3.13.2。

改动：
- 在有 1 个确认之前，不计入也不花费付款。
- 内部版本号从 312 到 31300。
- 只有指定 -allowreceivebyip 才接受按 IP 地址发送的交易。
- 去掉 DB_PRIVATE Berkeley DB 标志。
- 修复带亚分找零时发不出最后一分的问题。
- Linux 上自动检测是否用 128-bit 4-way SSE2。
Gavin Andresen：
- 选项 -rpcallowip= 接受来自另一台机器的 json-rpc 连接。
- Linux 上 SIGTERM 干净关机。

下载：
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.13/

（感谢 Laszlo 的 Mac OSX 构建！）

注意：
Linux 64 位版的 SSE2 自动检测在 64 位模式下对 AMD 无效。请试试这个，告诉我它判断得对不对：
http://www.bitcoin.org/download/bitcoin-0.3.13.1-specialbuild-linux64.tar.gz

你仍可以用 -4way 和 -4way=0 手动控制 SSE2。

0.3.13.2 版（SVN rev 161）改进了已花掉 0/未确认交易的情况。这是它的 Windows 构建：
http://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe

英文原文

Version 0.3.13 is now available. You should upgrade to prevent potential problems with 0/unconfirmed transactions. Note: 0.3.13 prevents problems if you haven't already spent a 0/unconfirmed transaction, but if that already happened, you need 0.3.13.2.

Changes:
- Don't count or spend payments until they have 1 confirmation.
- Internal version number from 312 to 31300.
- Only accept transactions sent by IP address if -allowreceivebyip is specified.
- Dropped DB_PRIVATE Berkeley DB flag.
- Fix problem sending the last cent with sub-cent fractional change.
- Auto-detect whether to use 128-bit 4-way SSE2 on Linux.
Gavin Andresen:
- Option -rpcallowip= to accept json-rpc connections from another machine.
- Clean shutdown on SIGTERM on Linux.

Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.13/

(Thanks Laszlo for the Mac OSX build!)

Note:
The SSE2 auto-detect in the Linux 64-bit version doesn't work with AMD in 64-bit mode. Please try this instead and let me know if it gets it right:
http://www.bitcoin.org/download/bitcoin-0.3.13.1-specialbuild-linux64.tar.gz

You can still control the SSE2 use manually with -4way and -4way=0.

Version 0.3.13.2 (SVN rev 161) has improvements for the case where you already had 0/unconfirmed transactions that you might have already spent. Here's a Windows build of it:
http://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe

Re: Version 0.3.13

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Version 0.3.13

Date2010-10-03 18:17:06 UTC

ForumBitcointalk · 原文

引用自 ShadowOfHarbringer，发表于 October 02, 2010, 01:00:07 PM（https://bitcointalk.org/index.php?topic=1327.msg14997#msg14997）

不错，不过自动 4way 检测在我的 Gentoo AMD 64 版客户端上不工作。

我还是得加 "-4way" 开关。

忘了说，我怀疑检测在 64 位 AMD 上可能不工作。难以置信，但 AMD 在 64 位模式下报告的型号不一样。

你能 grep 一下 debug.log 里的 CPUID，告诉我它说什么吗？（其他用 64 位 AMD 的也一样）你的 AMD 是什么芯片？

所有支持 64 位的 AMD 都有更好的 SSE2 硬件吗？

英文原文

Quote from: ShadowOfHarbringer on October 02, 2010, 01:00:07 PM（https://bitcointalk.org/index.php?topic=1327.msg14997#msg14997）

That's nice, however the automatic 4way detection is not working on my Gentoo AMD 64 version client.

I still have to add the "-4way" switch.

Forgot to say, I suspected the detect might not work on 64-bit AMD. I found it hard to believe but AMD reports a different model number in 64-bit mode.

Could you grep CPUID your debug.log and tell me what it says? (and anyone else with 64-bit AMD) And what AMD chip do you have?

Do all AMDs that support 64-bit have the better SSE2 hardware also?

Re: Version 0.3.13, please upgrade

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Version 0.3.13, please upgrade

Date2010-10-03 19:39:06 UTC

ForumBitcointalk · 原文

请几个人跑一下这个特别构建？它会赦免粉尘垃圾交易，暂时解决 0/未确认问题。我们其实只需要一个让它们通过的块，就能清理之前的交易。谁用它生成了块请回帖。

只有二进制。linux 版只有 64 位。
http://www.bitcoin.org/download/bitcoin-0.3.13.1-specialbuild-win32.zip
http://www.bitcoin.org/download/bitcoin-0.3.13.1-specialbuild-linux64.tar.gz

SHA1 fb7c66270281ed058c570627cf7baff0bdc16e5d bitcoin-0.3.13.1-specialbuild-win32.zip
SHA1 9fc44ea5f2109618073e2cfd887e2cc266eb31a9 bitcoin-0.3.13.1-specialbuild-linux64.tar.gz

linux 64 位版还包含对 AMD 64 位模式下 cpuid 4-way 128-bit SSE2 自动检测的修改，欢迎测试看看是不是更好。

英文原文

Could a few people please run this special build? It'll amnesty the dust spam transactions, which will clear up the 0/unconfirmed problem for now. We really just need one block letting them through to clear up the previous transactions. Post if you generate a block with this.

These are binaries only. The linux version is 64-bit only.
http://www.bitcoin.org/download/bitcoin-0.3.13.1-specialbuild-win32.zip
http://www.bitcoin.org/download/bitcoin-0.3.13.1-specialbuild-linux64.tar.gz

SHA1 fb7c66270281ed058c570627cf7baff0bdc16e5d bitcoin-0.3.13.1-specialbuild-win32.zip
SHA1 9fc44ea5f2109618073e2cfd887e2cc266eb31a9 bitcoin-0.3.13.1-specialbuild-linux64.tar.gz

The linux 64-bit version includes a change to the cpuid 4-way 128-bit SSE2 autodetect for AMD in 64-bit mode, if you'd like to test that and see if that's better.

Re: Version 0.3.13, please upgrade

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Version 0.3.13, please upgrade

Date2010-10-03 19:49:32 UTC

ForumBitcointalk · 原文

引用自 tcatm，发表于 October 03, 2010, 07:45:45 PM（https://bitcointalk.org/index.php?topic=1327.msg15111#msg15111）

983 Mhash/s 的机器。

真的？什么硬件？

英文原文

Quote from: tcatm on October 03, 2010, 07:45:45 PM（https://bitcointalk.org/index.php?topic=1327.msg15111#msg15111）

983 Mhash/s box.

Seriously? What hardware is that?

Re: Version 0.3.13, please upgrade

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Version 0.3.13, please upgrade

Date2010-10-03 20:02:24 UTC

ForumBitcointalk · 原文

Code:diff -u old\main.cpp new\main.cpp
--- old\main.cpp Sun Oct 03 20:57:20 2010
+++ new\main.cpp Sun Oct 03 20:57:54 2010
@@ -2831,6 +2831,10 @@
bool fUseSSE2 = ((fIntel && nFamily * 10000 + nModel >= 60026) ||
(fAMD && nFamily * 10000 + nModel >= 160010));

+ // AMD reports a lower model number in 64-bit mode
+ if (fAMD && sizeof(void*) > 4 && nFamily * 10000 + nModel >= 160004)
+ fUseSSE2 = true;
+
static bool fPrinted;
if (!fPrinted)
{
@@ -2989,6 +2993,17 @@

// Transaction fee based on block size
int64 nMinFee = tx.GetMinFee(nBlockSize);
+ //////// temporary code
+ if (nBlockSize < MAX_BLOCK_SIZE_GEN / 10 && GetWarnings("statusbar") == "")
+ {
+ if (nBestHeight < 91000)
+ nMinFee = 0;
+ if (nBestHeight < 100000 && nTxSize < 2000)
+ nMinFee = 0;
+ if (nBestHeight < 110000 && nBestHeight % 10 == 0)
+ nMinFee = 0;
+ }
+ //////// temporary code

map<uint256, CTxIndex> mapTestPoolTmp(mapTestPool);
if (!tx.ConnectInputs(txdb, mapTestPoolTmp, CDiskTxPos(1,1,1), pindexPrev, nFees, false, true, nMinFee))
diff -u old\serialize.h new\serialize.h
--- old\serialize.h Sun Oct 03 20:57:45 2010
+++ new\serialize.h Sun Oct 03 20:57:54 2010
@@ -22,8 +22,8 @@
class CAutoFile;
static const unsigned int MAX_SIZE = 0x02000000;

-static const int VERSION = 31300;
-static const char* pszSubVer = "";
+static const int VERSION = 31301;
+static const char* pszSubVer = " test1";

英文原文

-static const int VERSION = 31300;
-static const char* pszSubVer = "";
+static const int VERSION = 31301;
+static const char* pszSubVer = " test1";

Re: Version 0.3.13, please upgrade

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Version 0.3.13, please upgrade

Date2010-10-03 20:54:07 UTC

ForumBitcointalk · 原文

引用自 theymos，发表于 October 03, 2010, 08:09:51 PM（https://bitcointalk.org/index.php?topic=1327.msg15118#msg15118）

ArtForz 已经在跑无手续费的了，他有全网 20-30% 的 CPU 算力。但最初发出损坏交易的那个人删了钱包，而且网络已经遗忘了这些历史交易，所以基于此的任何交易都不会确认。

在你的节点有一条交易路径回到区块链之前，交易不会被接受、也不会显示为 0/未确认。

你钱包里的交易都附带了回到区块链所需的所有未记录交易。如果你有一笔显示为 0/未确认的交易，那你就有它依赖的所有前置未记录交易，重播你的交易时也会重播那些。

如果已经生成了无手续费的块还没用，那我得看看哪错了。那是段不常用的代码。依赖它们的交易，应该记录在每个相关人的钱包里。

引用自 theymos，发表于 October 03, 2010, 08:09:51 PM（https://bitcointalk.org/index.php?topic=1327.msg15118#msg15118）

最初发出损坏交易的那个人删了钱包

唉……为什么删钱包，而不是挪到一边、留个旧拷贝以防万一？永远不要删钱包。

引用自 tcatm，发表于 October 03, 2010, 08:10:47 PM（https://bitcointalk.org/index.php?topic=1327.msg15119#msg15119）

跑着呢。3 小时内应该能找到块。

收集重播交易可能要花点时间。你能接受入站连接会有帮助，这样能监听更多节点。就算 3 小时内找到块，也请至少连续跑几天。

英文原文

Quote from: theymos on October 03, 2010, 08:09:51 PM（https://bitcointalk.org/index.php?topic=1327.msg15118#msg15118）

ArtForz is already running with no fees, and he has 20-30% of the network's CPU power. The person who originally sent the broken transactions deleted his wallet, though, and the network has forgotten these historical transactions, so any transactions based on this won't confirm.

Transactions aren't accepted or displayed as 0/unconfirmed until your node has a path of transactions back to the block chain.

Any transactions in your wallet also have bundled with them all unrecorded transactions required to reach the block chain. If you have a transaction that is displayed as 0/unconfirmed, then you have all the previous unrecorded transactions it depends on and you will also rebroadcast those transactions when you rebroadcast yours.

If a no-fee block has already been generated and hasn't helped, then I need to look at what's wrong. It's a part of code that doesn't get much use. They should be recorded in the wallets of everyone who has a transaction depending on them.

Quote from: theymos on October 03, 2010, 08:09:51 PM（https://bitcointalk.org/index.php?topic=1327.msg15118#msg15118）

The person who originally sent the broken transactions deleted his wallet

Sigh... why delete a wallet instead of moving it aside and keeping the old copy just in case? You should never delete a wallet.

Quote from: tcatm on October 03, 2010, 08:10:47 PM（https://bitcointalk.org/index.php?topic=1327.msg15119#msg15119）

It's running. Should find a block within 3 hours.

It may take a while to collect re-broadcast transactions. It'll help if you can accept inbound connections so you'll be listening to more nodes. Even if you find a block in 3 hours, keep it running continuously for a few days at least.

Re: [PATCH] increase block size limit

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: [PATCH] increase block size limit

Date2010-10-03 21:07:28 UTC

ForumBitcointalk · 原文

引用自 theymos（2010 年 10 月 3 日 08:28:39 PM）（https://bitcointalk.org/index.php?topic=1347.msg15126#msg15126）：打上这个补丁会让你与其他比特币客户端不兼容。

+1 theymos。别用这个补丁，它会让你与网络不兼容，对你自己不利。

如果我们接近需要的那一天，可以之后分阶段引入这一改动。

英文原文

Quote from: theymos on October 03, 2010, 08:28:39 PM（https://bitcointalk.org/index.php?topic=1347.msg15126#msg15126）Applying this patch will make you incompatible with other Bitcoin clients.
+1 theymos. Don't use this patch, it'll make you incompatible with the network, to your own detriment.

We can phase in a change later if we get closer to needing it.

Re: How to overthrow the GPU Oligarchs

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: How to overthrow the GPU Oligarchs

Date2010-10-03 21:30:04 UTC

ForumBitcointalk · 原文

引用自 theymos（2010 年 10 月 2 日 06:11:11 AM）（https://bitcointalk.org/index.php?topic=1332.msg14966#msg14966）：引用自 lzsaver（2010 年 10 月 2 日 05:49:47 AM）（https://bitcointalk.org/index.php?topic=1332.msg14960#msg14960）：能多讲讲这个吗：
「他们不得不用 extraNonce 做些奇怪的事情，这会增大区块头的大小」。
当你挖矿时，你计算的是区块头的哈希。哈希更多的数据比哈希更少的数据要慢，所以对所有人来说，区块头的大小至关重要且固定，只有一个例外。这正是困惑所在。extraNonce 不是区块头的一部分，它是第一笔交易的一部分。它不会拖慢你的哈希速度，也不会改变区块头的大小。

我们要保持警惕，把“区块内容会拖慢哈希速度”这类误解扼杀在萌芽里。不会。

extraNonce 永远不需要很大。如果我们愿意，可以每当时间变化（每秒）就重置它。最坏的情况下，如果你不想费心维护它的递增，extraNonce 可以是 4 个随机字节，因碰撞而浪费时间的概率可以忽略不计。

不同的机器自动不会发生碰撞，因为它们在第一笔交易里的生成公钥不同。每个线程也一样。

英文原文

Quote from: theymos on October 02, 2010, 06:11:11 AM（https://bitcointalk.org/index.php?topic=1332.msg14966#msg14966）Quote from: lzsaver on October 02, 2010, 05:49:47 AM（https://bitcointalk.org/index.php?topic=1332.msg14960#msg14960）Can you tell more about it:
"they have to do weird things with extraNonce, which increases the size of the block header".
When you generate, you calculate hashes of the block header. Hashing more data is slower than hashing less data, so the block header is critically of a fixed size for everyone, with one exception.This is the point of confusion. extraNonce is not part of the block header, it is part of the first transaction. It does not slow down your hashing. It does not change the size of the header.

We need to be vigilant and nip in the bud any misconception that the contents of your block slows down your hash speed. It doesn't.

extraNonce never needs to be very big. We could reset it every second whenever the time changes if we wanted. Worst case, if you didn't want to keep track of incrementing it, extraNonce could be 4 random bytes and the chance of wasting time from collision would be negligible.

Separate machines are automatically collision proof because they have different generated public keys in the first transaction. That also goes for each thread too.

Re: Version 0.3.13, please upgrade

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Version 0.3.13, please upgrade

Date2010-10-03 21:43:20 UTC

ForumBitcointalk · 原文

ShadowOfHarbringer，你的机器用 -4way 会更快吗？

如果是，那么我想：任何支持 64 位的 AMD 都有 128 位 SSE2。

我在这里发布的 specialbuild 版本会查找 model 4 或更高版本。如果你的机器用 -4way 更快，那我应该改成：只要是支持 64 位的 AMD，就一律使用 SSE2。

英文原文

ShadowOfHarbringer, is yours faster with -4way?

If it is, then I'm thinking that any AMD that supports 64-bit has 128-bit SSE2.

The specialbuild version I posted here looks for model 4 or higher. If yours is faster with -4way, then I should change it to always use SSE2 with any AMD with 64-bit.

Re: Memory leak

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Memory leak

Date2010-10-03 22:07:00 UTC

ForumBitcointalk · 原文

你在连接自己。全部 21 次连接尝试都连到了一个版本为 31300（0.3.13）的节点。并不是所有人都已经升级到 0.3.13 了。

IRC 看起来是正常的。它应该有其他节点可以尝试。

断开连接后、需要确保它不会马上又尝试连接自己，这方面可能还有些事要做。不过我看不出它是怎么发生的：它应该会重置 nLastTry，把自己放到队列尾部，但日志里没体现。

你可以试试把 addr.dat 移到一边。也许它里面有问题。

你用 -addnode 了吗？

英文原文

You're connecting to yourself. All 21 connection attempts were to a node with version 31300 (0.3.13). Not everyone has 0.3.13 yet.

IRC seems to be working. It ought to have other nodes to try.

There may be something I need to do to make sure it doesn't try to connect to itself again right away after disconnecting. I can't see how it's happening though, it should be resetting nLastTry which would put it to the back of the queue, but the log doesn't show it.

You can try moving addr.dat aside. Maybe there's something wrong in it.

Are you using -addnode?

Re: Version 0.3.13, please upgrade

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Version 0.3.13, please upgrade

Date2010-10-03 23:46:19 UTC

ForumBitcointalk · 原文

务必让你的节点保持在线，这样它会继续广播交易 b412a0。自 29/09/2010 16:41 以后，我就没再看到它的广播了。

英文原文

Make sure you keep your node online so it'll keep rebroadcasting transaction b412a0. It haven't seen it rebroadcast since 29/09/2010 16:41.

Re: Website and software translations

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Website and software translations

Date2010-10-04 01:44:41 UTC

ForumBitcointalk · 原文

谢谢 eurekafag，俄语翻译已加入 SVN rev 160。

英文原文

Thanks eurekafag, Russian translation added to SVN rev 160.

Re: Website and software translations

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Website and software translations

Date2010-10-04 19:21:01 UTC

ForumBitcointalk · 原文

引用自 eurekafag（2010 年 10 月 4 日 10:55:56 AM）（https://bitcointalk.org/index.php?topic=151.msg15248#msg15248）：哪里能找到最新的英文 .po 文件，好让翻译跟上？
poedit 可以办到。要么从某个发布版里拿 src 目录，要么用 SVN 下载。把你的 .po 文件放在 src 目录下三级深的位置。用 poedit 打开它，做 Catalog->Update from sources。

比如，你有：
src
src\base58.h
src\bignum.h
...
src\util.cpp
src\util.h
src\xpm
src\locale
u\LC_MESSAGES\bitcoin.po

用 poedit 打开 bitcoin.po，做 Catalog->Update from sources。它会从 bitcoin.po 所在位置往上 3 级目录（..\..\..）找源代码。

这会更新你已有的 .po 文件，并加入新增的字符串。它可能会尝试匹配相近的字符串，所以要检查一遍，确保它没有猜错。

一定要用我上传到 SVN 或发布版里的 .po 文件，因为我每次总会顺手修好几处。我把你的俄语文件附在这条消息里了。

英文原文

Quote from: eurekafag on October 04, 2010, 10:55:56 AM（https://bitcointalk.org/index.php?topic=151.msg15248#msg15248）Where can I find the latest English .po file to keep the translation up-to-date?
poedit does it. Either get the src directory from a release, or download it with SVN. Place your .po file 3 directories deep under the src directory. Open it with poedit and do Catalog->Update from sources.

So for example, you have:
src
src\base58.h
src\bignum.h
...
src\util.cpp
src\util.h
src\xpm
src\locale
u\LC_MESSAGES\bitcoin.po

Open bitcoin.po with poedit, do Catalog->Update from sources. It looks for the sourcecode up 3 directories (..\..\..) from where bitcoin.po is.

This updates your existing .po file you already worked on and adds any news strings. It may try to match close strings, so check things over and make sure it didn't make any bad guesses.

Make sure you use the .po file I uploaded to SVN or in a release, because I always fix up at least a few things. I'm attaching your Russian one to this message.

Re: [PATCH] increase block size limit

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: [PATCH] increase block size limit

Date2010-10-04 19:48:40 UTC

ForumBitcointalk · 原文

可以像这样分阶段引入：

if (blocknumber > 115000)
maxblocksize = largerlimit

可以提前很多版本就开始部署，这样等到区块号到达、改动生效时，没有它的旧版本早已淘汰。

当接近那个分界区块号时，我可以向旧版本发警报，确保它们知道必须升级。

英文原文

It can be phased in, like:

if (blocknumber > 115000)
maxblocksize = largerlimit

It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don't have it are already obsolete.

When we're near the cutoff block number, I can put an alert to old versions to make sure they know they have to upgrade.

Re: Website and software translations

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Website and software translations

Date2010-10-06 15:42:39 UTC

ForumBitcointalk · 原文

不知为什么 poedit 把文件重排了。我重新跑了一次 update from sources，它又恢复了原来的顺序，现在没问题了。你是不是在文件不按字母排序的驱动器上跑的，比如 FAT 驱动器或 U 盘？

字符串并不经常新增或改动。要等好几个月，改动才会攒够。

我上传了这些改动。

这个 Windows 构建里带有俄语翻译：
http://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe

英文原文

poedit reorganised the file for some reason. I re-ran update from sources and it put it back in the original order so it's fine now. Did you run it on a drive where files aren't sorted alphabetically, like a FAT drive or USB flash drive?

Strings aren't added or changed very often. It's months before enough changes build up.

I uploaded the changes.

This Windows build has the Russian translation in it:
http://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe

Re: I broke my wallet, sends never confirm now.

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: I broke my wallet, sends never confirm now.

Date2010-10-06 16:54:23 UTC

ForumBitcointalk · 原文

那更多是个 SelectCoins 的问题。

SVN rev 161 有个改进：递归判断自己未确认的交易是否可花。这很有必要，因为你应该能立刻花自己的找零。

新的递归判定是：0/unconfirmed（未确认）可以花，前提是它是你的，并且它的所有依赖要么已在区块里，要么也都是你的。

这里有个 Windows 构建：
http://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe

如果你已经有一笔 0/unconfirmed 的交易并且可能已经花过，这个版本是改进。如果你是那笔 0/unconfirmed 交易的最初创建者，那你还是得用 theymos 的补丁。

英文原文

That's going to be more of a SelectCoins thing.

SVN rev 161 has a refinement to recursively determine if your own unconfirmed transactions can be spent. This is needed because you should be able to spend your own change right away.

The new recursive determination is: 0/unconfirmed can be spent if it's yours and all its dependencies are either in a block or also yours.

Here's a Windows build:
http://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe

This version is an improvement if you already had a 0/unconfirmed transaction and might have already spent it. If you were the original creator of a 0/unconfirmed transaction, you still need theymos' patch instead.

Re: Tor connections not working reliably, many seednodes offline

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Tor connections not working reliably, many seednodes offline

Date2010-10-06 17:36:41 UTC

ForumBitcointalk · 原文

也许你只是运气不好，碰到了没有反向解析的出口节点。

IRC 服务器的回应看起来并不像是因此把你断开的。正常的话之后应该出现 IRC SENDING: NICK，但没有，所以它超时了。

我看到问题了。IRC 代码会查找各种短语来判断服务器何时准备好接收你的 NICK，但没有查找那个特定的短语。我会修好它。

我不确定是不是真的必须等服务器查完主机名之后再发 nick。

第一次用 TOR、靠种子节点连接，花了多长时间才连上？

英文原文

Maybe you were just unlucky to have an exit node without reverse lookup.

The IRC server's response doesn't look like it was disconnecting you for that. It's supposed to go IRC SENDING: NICK after that, and it doesn't so it gets timed out.

I see the problem. The IRC code is looking for various phrases to see when the server is ready to receive your NICK, but it's not looking for that particular phrase. I'll fix it.

I don't know if it's really required to wait for the server to finish looking up hostname before sending nick.

How long did it take to get connected with TOR the first time, having to use the seed nodes?

Re: The Niche List

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: The Niche List

Date2010-10-06 23:10:31 UTC

ForumBitcointalk · 原文

引用自 kiba（2010 年 9 月 23 日 04:00:16 PM）（https://bitcointalk.org/index.php?topic=1268.msg13828#msg13828）：1. 像 rapidshare 之类的下载站和其他糟糕的主机。验证码不方便，还得用 paypal。比特币可能同时扮演两种角色，把整个流程打通。
我再重复一次：这方面有开源软件，所以只需要接上比特币支付机制就行。我找到的一个不错的是 Mihalism Multi Host。它是按免费主机设计的，所以只需要做几处小调整，放宽一些与付费使用相称的限制。

英文原文

Quote from: kiba on September 23, 2010, 04:00:16 PM（https://bitcointalk.org/index.php?topic=1268.msg13828#msg13828）1. Download site like rapidshare and other crappy host. Inconvenient captcha and required paypal. Bitcoin can possibly take both roles and streamline the whole process.
Repeating myself here, but there is open source software for that, so it would just be a matter of bolting on a Bitcoin payment mechanism. One good one I found was Mihalism Multi Host. It's designed as a free host, so it would just need a few tweaks to loosen up restrictions consistent with paid use.

Key pool feature for safer wallet backup

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleKey pool feature for safer wallet backup

Date2010-10-09 20:19:33 UTC

ForumBitcointalk · 原文

SVN rev 163（0.3.13.3 版）有了密钥池功能。预生成的新密钥会在使用前先在队列里“陈化”，这样 wallet.dat 的备份里就包含了你将来会用到的密钥。

目前我把默认池大小设为 100。可以用 -keypool= 配置。注意，增大池大小需要一点时间，所以别调得太夸张。每个密钥约占 1K 磁盘空间。

恢复这方面的事我还没处理。如果你真的还原了一个旧的 wallet.dat，我想你可能得删掉 blk*.dat，让重新下载时重新发现自己的交易。

我只做过中等程度的测试。在经过更多测试之前，你可能不想把它用在网站服务器上。

英文原文

SVN rev 163 (ver 0.3.13.3) has the key pool feature. Pre-generated new keys are aged in a queue before use, so that backups of wallet.dat hold keys you'll use in the future.

For now I made the default pool size 100. It can be configured with -keypool=. Be aware, it takes a little time to increase the pool size, so don't go crazy with it. Disk space is about 1K per key.

I have not addressed the recovery side of this yet. If you actually did restore an old wallet.dat, I think you may have to delete blk*.dat to rediscover your own transactions during the redownload.

I've only tested this moderately. You might not want to use this for a website server until it's had some more testing.

Version 0.3.14

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleVersion 0.3.14

Date2010-10-21 16:39:27 UTC

ForumBitcointalk · 原文

0.3.14 版现已发布
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.14/

改动：
- 密钥池功能，钱包备份更安全
Gavin Andresen：
- 测试网络模式，开关 -testnet
- unix/osx 上 JSON-RPC 连接可使用 SSL 的选项
- validateaddress RPC 命令
eurekafag：
- 俄语翻译

英文原文

Version 0.3.14 is now available
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.14/

Changes:
- Key pool feature for safer wallet backup
Gavin Andresen:
- TEST network mode with switch -testnet
- Option to use SSL for JSON-RPC connections on unix/osx
- validateaddress RPC command
eurekafag:
- Russian translation

Re: Website and software translations

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Website and software translations

Date2010-10-21 22:50:47 UTC

ForumBitcointalk · 原文

顺序对程序无关紧要，但对我维护它很重要。如果它把 .po 文件的顺序打乱了，我就没法 diff 找改动。我在程序里改英文文本时，要更新全部 7 个翻译文件，顺序一致的话会轻松得多。

我还是可以让 poedit 重新扫描，把它恢复成正常顺序。

未翻译的字符串显示在最上面是正常的。

引用自 eurekafag（2010 年 10 月 6 日 07:39:36 PM）（https://bitcointalk.org/index.php?topic=151.msg15697#msg15697）：顺便说，有几行很像，或许可以合并成一行。它们意思很接近，只差一两个词。当然只是个建议。
我知道，但不改复杂源代码的话不容易做到。

英文原文

The order matters not to the program, but it matters to me maintaining it. If it jumbles the order of the .po file then I can't diff for changes. I have to update all 7 translation files when I change the English text in the program, and it's easier when they're all in the same order.

I can still put it back into normal order by making poedit rescan it.

It is normal that untranslated strings are shown on top.

Quote from: eurekafag on October 06, 2010, 07:39:36 PM（https://bitcointalk.org/index.php?topic=151.msg15697#msg15697）By the way, there are some similar lines that possibly may be replaced by one. They are very close by meaning and differs only by 1-2 words. Just a suggestion of course.
I know, but not easily without complicating the sourcecode.

Re: ERROR - PLEASE HELP ME!

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: ERROR - PLEASE HELP ME!

Date2010-10-23 18:22:49 UTC

ForumBitcointalk · 原文

引用自 theymos（2010 年 10 月 21 日 10:00:26 PM）（https://bitcointalk.org/index.php?topic=1530.msg17955#msg17955）：他的区块数一直卡在 1698。
他在难度 1.0 下生成了无效区块。他的 blk0001.dat 或 blkindex.dat 里肯定有一条损坏的记录。他只需要删掉 blk*.dat，让它重新下载就行。

安全锁定检测到了问题，显示了“WARNING: Displayed transactions may not be correct!（警告：显示的交易可能不正确！）”，因为它看到了一条更长的链但无法接受。安全锁定不能阻止挖矿，否则会制造出一种攻击可能。

引用自 gavinandresen（2010 年 10 月 22 日 02:25:14 PM）（https://bitcointalk.org/index.php?topic=1530.msg18074#msg18074）：比特币客户端真不应该在你还没同步到最后一个区块检查点之前就允许挖矿。
好主意，我改了一下，确保它在检查点区块 74000 之前不会挖矿。

英文原文

Quote from: theymos on October 21, 2010, 10:00:26 PM（https://bitcointalk.org/index.php?topic=1530.msg17955#msg17955）his block count remains "stuck" at 1698.
He was generating invalid blocks at difficulty 1.0. He must have a corrupted entry in his blk0001.dat or blkindex.dat file. He just needs to delete blk*.dat and let it redownload.

The safety lockdown detected the problem and was displaying "WARNING: Displayed transactions may not be correct!" because it saw a longer chain existed that it was unable to accept. The safety lockdown cannot stop generation or it would create an attack possibility.

Quote from: gavinandresen on October 22, 2010, 02:25:14 PM（https://bitcointalk.org/index.php?topic=1530.msg18074#msg18074）The Bitcoin client really shouldn't allow coin generation until you have all of the blocks up to the last block checkpoint.
Good idea, I made a change to make sure it won't generate before checkpoint block 74000.

Re: ERROR - PLEASE HELP ME!

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: ERROR - PLEASE HELP ME!

Date2010-10-23 18:38:04 UTC

ForumBitcointalk · 原文

好吧，如果重新下载也确实过不了区块 1698，那问题就更蹊跷了。

是的，有可能是他装了杀毒软件，或者路由器、防火墙在做字节序列的模式匹配，把它审查掉了。

能拿到 knightmb 的 blk*.dat 来试试会很有启发，看能不能让他越过这个点。

英文原文

OK, if it really won't get past block 1698 on redownload, then we're in stranger territory.

Yes, possibly he has antivirus software or even a router or filewall that is pattern matching a sequence of bytes and censoring it.

It would be instructive to get knightmb's blk*.dat and see if that gets him past that point.

Re: Win7 64bit since last patch Tues now crashes

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Win7 64bit since last patch Tues now crashes

Date2010-10-23 18:52:02 UTC

ForumBitcointalk · 原文

引用自 Odin（2010 年 10 月 22 日 09:24:38 PM）（https://bitcointalk.org/index.php?topic=1540.msg18105#msg18105）：故障模块名称：mingwm10.dll
这是重要的线索。我认为它是在说崩溃发生在那个模块里。也许可以试试其他版本的它。mingwm10.dll 只是个简单的占位东西，满足多线程应用的某个回调要求。

还有其他人在 64 位 Windows 上跑得正常吗？

英文原文

Quote from: Odin on October 22, 2010, 09:24:38 PM（https://bitcointalk.org/index.php?topic=1540.msg18105#msg18105） Fault Module Name: mingwm10.dll
This is the important clue. I believe it's saying it crashed in that. Maybe there are other versions of it to try. mingwm10.dll is just a simple placeholder thing that satisfies some callback requirement for multithreaded apps.

Is anyone else running OK on Windows 64-bit?

Re: Suggestion: Allow short messages to be sent together with bitcoins ?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Suggestion: Allow short messages to be sent together with bitcoins ?

Date2010-10-23 19:02:57 UTC

ForumBitcointalk · 原文

ECDSA 不能加密消息，只能做签名。

把明文消息永久记录下来、让所有人都能看到，是不明智的。那是等着出事。

如果要做消息系统，它应该是一个与比特币网络平行的独立系统。消息不应该记录在区块链里。消息可以用比特币地址的密钥对来签名，证明是谁发的。

英文原文

ECDSA can't encrypt messages, only sign signatures.

It would be unwise to have permanently recorded plaintext messages for everyone to see. It would be an accident waiting to happen.

If there's going to be a message system, it should be a separate system parallel to the bitcoin network. Messages should not be recorded in the block chain. The messages could be signed with the bitcoin address keypairs to prove who they're from.

Re: Multiple Wallets, one computer

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Multiple Wallets, one computer

Date2010-10-24 19:17:51 UTC

ForumBitcointalk · 原文

我已经有了一个类似东西的雏形。跟 Gavin 描述的差不多。

再多几个 rpc 接口：

move <fromaccount> <toaccount> <amount>
把资金从一个内部账户移到另一个。我觉得空账户名（""）就是你的默认账户。如果你卖东西给某个用户，可以做 move "theiraccount" "" 123.45。
"move”是最好的名字吗？我没用 "transfer”，因为它听起来太像发送交易了。

我在想新增一个 getaccountaddress 函数，而不是重载 getnewaddress：

getaccountaddress <account>
给你一个从 getnewaddress <account> 分配的地址。在该地址收到款之前，它会一直给同一个地址，之后再分配新地址。（它自动做了我前段时间贴的那段示例代码的事）

这些命令能不能让简单场景下，不需要自己搞数据库也能实现你的网站？

英文原文

I have the beginning of something like this. It's mostly like what Gavin described.

Some more rpc interface:

move <fromaccount> <toaccount> <amount>
Move from one internal account to another. I think blank account name ("") will be your default account. If you sell something to a user, you could do move "theiraccount" "" 123.45.
Is "move" the best name for this? I shied away from "transfer" because that sounds too close to sending a transaction.

I'm thinking a new function getaccountaddress instead of overloading getnewaddress:

getaccountaddress <account>
Gives you an address allocated from getnewaddress <account>. It'll keep giving the same address until something is received on the address, then it allocates a new address. (It automatically does what the sample code I posted some time ago did)

Would these commands make it possible in simple cases to implement your website without needing a database of your own?

Re: Multiple Wallets, one computer

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Multiple Wallets, one computer

Date2010-10-25 16:53:53 UTC

ForumBitcointalk · 原文

下面是基于账户的命令用法伪代码。网站集成确实容易多了。

print "send to " + getaccountaddress(username) + " to fund your account"
print "balance: " + getbalance(username, 0)
print "available balance: " + getbalance(username, 6)

// 如果你做了笔销售，把钱从他们的账户移出来
move(username, "", amount, 6)

// 提现
sendfrom(username, bitcoinaddress, amount, 6)

英文原文

Here's some pseudocode of how you would use the account based commands. It sure makes website integration a lot easier.

print "send to " + getaccountaddress(username) + " to fund your account"
print "balance: " + getbalance(username, 0)
print "available balance: " + getbalance(username, 6)

// if you make a sale, move the money out of their account
move(username, "", amount, 6)

// withdrawal
sendfrom(username, bitcoinaddress, amount, 6)

Re: Win7 64bit since last patch Tues now crashes

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Win7 64bit since last patch Tues now crashes

Date2010-10-25 17:27:47 UTC

ForumBitcointalk · 原文

我唯一能想到的办法是看能不能找到其他版本的 mingwm10.dll 来试。mingwm10.dll 是随 MinGW 编译器附带的一个小小 DLL，做多线程构建时需要它。我不确定它具体干什么，但大概就是说类似“好的 Windows，看，我如你要求的那样在 DLL 里了”这种话。

你 debug.log 文件的末尾可能会显示它崩溃前最后在做什么。

英文原文

The only thing I can think of is to see if there are other versions of mingwm10.dll you can get. mingwm10.dll is a tiny little DLL that came with the MinGW compiler that you need when you build for multi-thread. I don't know exactly what it does, but it probably just says something like "yes Windows, see I'm in a DLL like you insisted."

The end of your debug.log file might show the last thing it was doing before it crashed.

Re: New icon/logo

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: New icon/logo

Date2010-11-13 00:55:51 UTC

ForumBitcointalk · 原文

如果有艺术功底的人愿意贡献替代方案，我很欢迎。图标/logo 是按 16x16 和 20x20 像素尺寸作为图标来设计的。我觉得它是最好的程序图标，但在网站上用的大尺寸图形方面还有改进空间。

如果作者能把作品设为公有领域，会简单得多。

英文原文

I'm happy if someone with artistic skill wants to contribute alternatives. The icon/logo was meant to be good as an icon at the 16x16 and 20x20 pixel sizes. I think it's the best program icon, but there's room for improvement at larger sizes for a graphic for use on websites.

It'll be a lot simpler if authors could make their graphics public domain.

Re: Some testing that I did on the testnetwork, my findings.

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Some testing that I did on the testnetwork, my findings.

Date2010-11-13 23:25:26 UTC

ForumBitcointalk · 原文

感谢把泛洪测试限制在 testnet 上。

0.3.15 版结合了几项功能，帮助合法交易在泛洪攻击期间插队。关键是 Gavin 的想法：按交易依赖的币龄来给交易定优先级。每个币都有权在一定间隔内周转一次。等得越久，积累的优先级越高。优先级 = sum(valuein * age) / txsize。交易费仍然优先于优先级，优先级决定同一费率层内交易的处理顺序。

配合优先级功能，SelectCoins 只有在实在没别的可花时，才会动用你自己的 0 确认交易。这有助于防止你快速周转币，除非你真的把所有币快速周转、刻意为之。

英文原文

Thank you for limiting flood tests to the testnet.

Version 0.3.15 combines several features to help legitimate transactions jump the queue during a flood attack. The key was Gavin's idea for prioritising transactions based on the age of their dependencies. Every coin is entitled to turn over so often. The longer waited, the more priority accumulates. Priority is sum(valuein * age) / txsize. Transaction fee still takes precedence over priority, and priority determines the order of processing within a fee strata.

In support of the priority feature, SelectCoins only uses your own 0 conf transactions only as a last resort if that's all you have left. This helps keep you from turning your coins over rapidly unless you're forcing it by actually turning all your coins over rapidly.

Version 0.3.15

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleVersion 0.3.15

Date2010-11-13 23:26:40 UTC

ForumBitcointalk · 原文

0.3.15 版现已发布。

改动：
- paytxfee 开关改为按 KB 计费，大交易也能加上正确的手续费
- 发送时尽量避开确认数不足 6 的币
- BitcoinMiner 按依赖的币龄以优先级顺序处理交易
- 确保下载到区块 74000 之前不开始挖矿
- Dean Gores 的 bug 修复
- testnet、keypoololdest 和 paytxfee 加入 getinfo

英文原文

Version 0.3.15 is now available.

Changes:
- paytxfee switch is now per KB, so it adds the correct fee for large transactions
- sending avoids using coins with less than 6 confirmations if it can
- BitcoinMiner processes transactions in priority order based on age of dependencies
- make sure generation doesn't start before block 74000 downloaded
- bugfixes by Dean Gores
- testnet, keypoololdest and paytxfee added to getinfo

Re: Some testing that I did on the testnetwork, my findings.

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Some testing that I did on the testnetwork, my findings.

Date2010-11-14 16:53:19 UTC

ForumBitcointalk · 原文

引用自 ByteCoin（2010 年 11 月 13 日 11:55:11 PM）（https://bitcointalk.org/index.php?topic=1668.msg21899#msg21899）：当然，如果网络没有被泛洪，而且你也不太担心当前交易被卡住，那大概值得优先用你的 0 确认交易，这样可以把高优先级的币“省”下来，等网络被泛洪时再用。
以防下一个区块到来之前来一波泛洪，你至少该用一点优先级。

只要所有依赖至少有 1 个确认，如果交易一开始优先级不够，依赖会随时间陈化，直到够为止。

引用自 Gaming the system（……）：像我上面帖子里说的那样，塞进 1000 个左右刚周转过的 BTC 来刷优先级，当然还是管用！
或者控制一笔交易花掉多少优先级。软件得知道你未来的计划，才能决定现在花掉优先级还是留着以后用。不过我觉得不用搞到那么细。普通用户和泛洪者之间的差距足够大。

优先级不必包治百病。一旦知道有泛洪，你可以加上 -paytxfee=0.01。有了优先级，在那之前的交易顶多变慢，不会卡死。

英文原文

Quote from: ByteCoin on November 13, 2010, 11:55:11 PM（https://bitcointalk.org/index.php?topic=1668.msg21899#msg21899）Of course, if the network is not being flooded and you're not overly concerned about the current transaction getting held up then it's probably worth preferring to use your 0 conf transactions so that you can "save" the higher priority coins for when the network is being flooded.
You should use at least some priority in case a flood comes along before the next block.

As long as all dependencies have at least 1 conf, if the transaction doesn't have enough priority at first, the dependencies will age until it does.

QuoteGaming the system by including 1000 or so recently turned over BTC to bump the priority as described in my post above still works of course!
Or managing how much priority you spend on a transaction. The software would have to know your future plans to know whether to spend your priority now or save it for later. I don't think we'll need to get into that much detail though. There's a wide enough difference between normal users and flooders.

Priority doesn't have to do everything. Once you know there's a flood, you can add -paytxfee=0.01. Hopefully with priority, your transactions before that should be at worst slow, not stuck.

Re: Need OP_BLOCKNUMBER to allow "time" limited transactions

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Need OP_BLOCKNUMBER to allow "time" limited transactions

Date2010-11-15 18:37:44 UTC

ForumBitcointalk · 原文

我们不能安全地做 OP_BLOCKNUMBER。万一分叉后区块链重组，交易需要能进入后面的区块。OP_BLOCKNUMBER 交易及其所有后代都会失效。这对后来那些没参与限时交易的币主不公平。

nTimeLock 做的是反过来的事。它是一笔开放交易，在截止前可以用新版本替换。它要到锁定后才能被记录。截止时版本号最高的那个会被记录。比如可以用它来写一笔托管交易：除非在截止前撤销，否则它会自动永久锁定并生效。这个功能还没启用、也没被使用，但支持已经在了，以后可以实现。

英文原文

We can't safely do OP_BLOCKNUMBER. In the event of a block chain reorg after a segmentation, transactions need to be able to get into the chain in a later block. The OP_BLOCKNUMBER transaction and all its dependants would become invalid. This wouldn't be fair to later owners of the coins who weren't involved in the time limited transaction.

nTimeLock does the reverse. It's an open transaction that can be replaced with new versions until the deadline. It can't be recorded until it locks. The highest version when the deadline hits gets recorded. It could be used, for example, to write an escrow transaction that will automatically permanently lock and go through unless it is revoked before the deadline. The feature isn't enabled or used yet, but the support is there so it could be implemented later.

Re: Transaction / spam flood attack currently under way

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Transaction / spam flood attack currently under way

Date2010-11-19 23:50:24 UTC

ForumBitcointalk · 原文

引用自 creighto（2010 年 11 月 19 日 08:29:12 PM）（https://bitcointalk.org/index.php?topic=1850.msg22896#msg22896）：也许除了最近实现的币龄优先级规则，还应该有个免手续费的最低币龄规则。换句话说，也许可以定个生成规则：免费交易必须 3 个区块深之后才能再次免费转账。这样真实用户急用时还是可以立刻花新到手的钱，同时也允许真实用户按需重新整理资金而不产生额外成本。我觉得这会显著抑制正在发生的这类垃圾攻击。
我正在做类似的事。优先级就是你说的这个概念的更正式版本。

引用自 FreeMoney（2010 年 11 月 19 日 05:39:44 PM）（https://bitcointalk.org/index.php?topic=1842.msg22844#msg22844）：按现在 3.15 的情况，有不少免费交易空间，而且这些空间优先给 [age]*[value]/[size] 最高的交易，对吧？把免费空间的任意一部分要求 [age]*[value]/[size] > C，合理吗？

比如把 C 设成：标准的 1BTC 交易能在下一个区块进入主要的免费区；0.1 的大概等 10 个区块后能进；再把允许 [age]*[value]/[size] < C 的区域做成每区块进十几笔交易左右。
对，就是这样。而无优先级要求的区域是 3K，每区块约十几笔交易。

我刚上传了 SVN rev 185，免费交易有了最低优先级要求。交易泛洪都是由反复重花的币组成的，所以它们反复依赖自己 0 确认的交易。0 确认的交易优先级为 0，所以这类免费交易一次只能等一笔交易进区块。

0.3.15 版不会用 0 确认依赖来写交易，除非实在没别的可用，所以普通用户一般不会被这个卡住。

我觉得这是个不错的折中，还没到把默认手续费设成 0.01 那一步。要求免费交易只能隔一段时间周转一次币，并不过分。用免费交易就是在接受施舍，那同一批币能用多频繁，总得有个限度。

我们一直说免费交易处理得可能慢一些。你可以加上 -paytxfee=0.01 来确保交易快速通过。

英文原文

Quote from: creighto on November 19, 2010, 08:29:12 PM（https://bitcointalk.org/index.php?topic=1850.msg22896#msg22896）Perhaps in addition to the age priority rule recently implimented, there should be a minimum age rule without a transaction fee. Said another way, perhaps a generation rule that says that a free transaction must be 3 blocks deep before it can be transfered again for free. This will still allow real users to immediately spend new funds if they have to, while still permitting real users to reshuffle funds to suit their needs without an overhead cost. I think that this would significantly inhibit the type of spamming attack that is currently underway.
I'm doing something like that. Priority is a more formalised version of the concept you're describing.

Quote from: FreeMoney on November 19, 2010, 05:39:44 PM（https://bitcointalk.org/index.php?topic=1842.msg22844#msg22844）As it stands now 3.15 has a lot of free transaction space and that space is given first to transactions with the highest [age]*[value]/[size] correct? Would it be reasonable to make some arbitrary portion of the free space require [age]*[value]/[size] > C ?

Maybe set C so that a standard 1BTC transaction can get into the main free area on the next block. And a .1 can get in after waiting about 10 blocks. And make the area which allows [age]*[value]/[size] < C to let in about a dozen transactions or so.
Yes, like this. And the no-priority-requirement area is 3K, about a dozen transactions per block.

I just uploaded SVN rev 185 which has a minimal priority requirement for free transactions. Transaction floods are made up of coins that are re-spent over and over, so they depend on their own 0 conf transactions repeatedly. 0 conf transactions have 0 priority, so free transactions like that will have to wait for one transaction to get into a block at a time.

Version 0.3.15 doesn't write transactions using 0 conf dependencies unless that's all it has left, so normal users shouldn't usually have a problem with this.

I think this is a good compromise short of making the default fee 0.01. It's not so much to ask that free transactions can only be used to turn coins over so often. If you're using free transactions, you're taking charity and there has to be some limit on how often you can use it with the same coins.

We've always said free transactions may be processed more slowly. You can help ensure your transactions go through quickly by adding -paytxfee=0.01.

Re: OpenCL miner for the masses

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: OpenCL miner for the masses

Date2010-11-20 17:24:20 UTC

ForumBitcointalk · 原文

引用自 m0mchil（2010 年 11 月 20 日 10:16:19 AM）（https://bitcointalk.org/index.php?topic=1334.msg23018#msg23018）：已更新到 SVN 186
谢谢 m0mchil 一直跟进更新！

GPU 矿工们请尽快升级，关掉免费交易滥用！这个版本有了基于优先级的新限制来对付免费交易垃圾。

引用自 m0mchil（2010 年 11 月 16 日 10:30:41 AM）（https://bitcointalk.org/index.php?topic=1334.msg22251#msg22251）：刚更新到 SVN 181，修了 getwork 补丁，让它每 60 秒才用新交易重建一次区块。这其实是原客户端的行为，之前补丁里漏掉了。修好了每次 getwork 请求都占用大量 CPU 的问题（最近交易垃圾泛滥后这很明显）。请升级。
SVN 184 之前，把交易编译进区块用的是 n^2 算法。新的高效单遍算法快了几个数量级。（O(n) 对 O(n^2)/2 算法，n=200 时大概快 10 到 100 倍）

英文原文

Quote from: m0mchil on November 20, 2010, 10:16:19 AM（https://bitcointalk.org/index.php?topic=1334.msg23018#msg23018）updated to SVN 186
Thanks m0mchil for keeping up on the updates!

GPU miners, please upgrade as soon as possible to shut down the free transaction abuse! This version has the new priority-based limit on free transaction spam.

Quote from: m0mchil on November 16, 2010, 10:30:41 AM（https://bitcointalk.org/index.php?topic=1334.msg22251#msg22251）Just updated to SVN 181 and fixed getwork patch to wait 60 seconds between rebuilding the block with new transactions. This is actually the behavior of the original client, was forgotten in the patch by mistake. Fixes heavy CPU usage on every getwork request (this became obvious with recent heavy transaction spam). Please upgrade.
Before SVN 184, compiling transactions into a block used an n^2 algorithm. The new efficient single-pass algorithm is orders of magnitude quicker. (O(n) vs O(n^2)/2 algorithm, n=200 maybe 10 to 100 times quicker)

New getwork

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleNew getwork

Date2010-11-23 19:50:12 UTC

ForumBitcointalk · 原文

我把 m0mchil 的 getwork 重新设计了一版，上传到 SVN rev 189（31601 版）

m0mchil 的外部比特币矿机想法解决了很多问题。GPU 编程不成熟、编译困难，我也不想给构建再加依赖。getwork 让这些问题可以分开解决，不同的硬件和系统用不同的程序。矿场跑一个比特币节点、其余只跑 getwork 客户端也很方便。

接口有几处改动：

getwork [data]
如果不给 [data]，返回格式化好的待计算哈希数据：
"midstate"：对前半数据做哈希后预计算的哈希状态
"data"：区块数据
"hash1"：第二次哈希用的格式化哈希缓冲
"target"：小端序哈希目标
如果给了 [data]，尝试解这个区块，成功返回 true。[data] 就是 "data” 字段里返回的那 128 字节区块数据，只是 nonce 改了。

注意：
- 提交可能命中的结果时不返回工作，只有不带参数调用时才返回。
- block 字段已拆成 data 和 hash1。
- data 是 128 字节，包含 midstate 已哈希过的前半部分。
- hash1 恒定不变，为方便起见也包含在内。
- "ThreadRPCServer method=getwork” 的日志已关掉，否则日志里垃圾太多。

英文原文

I uploaded a redesign of m0mchil's getwork to SVN rev 189 (version 31601)

m0mchil's external bitcoin miner idea has solved a lot of problems. GPU programming is immature and hard to compile, and I didn't want to add additional dependencies to the build. getwork allows these problems to be solved separately, with different programs for different hardware and OSes. It's also convenient that server farms can run a single Bitcoin node and the rest only run getwork clients.

The interface has a few changes:

getwork [data]
If [data] is not specified, returns formatted hash data to work on:
  "midstate" : precomputed hash state after hashing the first half of the data
  "data" : block data
  "hash1" : formatted hash buffer for second hash
  "target" : little endian hash target
If [data] is specified, tries to solve the block and returns true if it was successful. [data] is the same 128 byte block data that was returned in the "data" field, but with the nonce changed.

Notes:
- It does not return work when you submit a possible hit, only when called without parameter.
- The block field has been separated into data and hash1.
- data is 128 bytes, which includes the first half that's already hashed by midstate.
- hash1 is always the same, but included for convenience.
- Logging of "ThreadRPCServer method=getwork" is disabled, it would be too much junk in the log.

Re: New getwork

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: New getwork

Date2010-11-23 20:55:27 UTC

ForumBitcointalk · 原文

它不是完全的直接替换。我想把接口清理一下。只需要改几处。

ScanHash_ 函数不会消失。顺便说，这个接口设计成和它的参数（midstate、data、hash1）镜像对应。

英文原文

It's not an exact drop-in replacement. I wanted to clean up the interface a little. It only requires a few changes.

ScanHash_ functions aren't going away. BTW, the interface of this is designed to mirror the parameters of that (midstate, data, hash1).

Re: New getwork

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: New getwork

Date2010-11-24 17:21:01 UTC

ForumBitcointalk · 原文

引用自 jgarzik（2010 年 11 月 24 日 04:47:42 AM）（https://bitcointalk.org/index.php?topic=1901.msg24008#msg24008）：我怀疑 ByteReverse（或缺了它）有点怪。'data' 和 'nonce' 到底要不要字节反转、怎么反转，很不清楚。
getwork 会做字节反转。midstate、data 和 hash1 已经是大端序，你传回 data 时还是大端序，所以你在大端序下工作，不用做任何字节反转。它们就是传给 ScanHash_ 函数的同一份数据。你可以拿 midstate、data、hash1，放进 16 字节对齐的缓冲，传给 ScanHash_ 函数，比如 ScanHash(pmidstate, pdata + 64, phash1, nHashesDone)。如果找到 nonce，把它打进 data 再调 getwork。

我大概应该把 ScanHash_ 函数改成用 pdata 而不是 pdata + 64，这样才一致。

target 是小端序，它应该和 m0mchil 那版的做法一样。（如果不一样，那就该修）那是唯一需要字节反转的情况。我觉得做法像这样：if ByteReverse((unsigned int*)hash[6]) < (unsigned int*)target[6]。

引用自 DiabloD3（2010 年 11 月 24 日 11:31:11 AM）（https://bitcointalk.org/index.php?topic=1901.msg24050#msg24050）：中本聪，请修一下你的 getwork 实现，让它符合 m0mchill 的规范。
这就是新规范。把你的矿机更新到用它应该不难。

改动是：
- 提交可能命中的结果时不返回工作，只有不带参数调用时才返回。
- block 字段拆成了 data 和 hash1。
- state 为保持一致改名为 midstate。
- 不需要 extranonce。

英文原文

Quote from: jgarzik on November 24, 2010, 04:47:42 AM（https://bitcointalk.org/index.php?topic=1901.msg24008#msg24008）I suspect something weird going on with ByteReverse (or lack thereof). It's quite unclear whether or not 'data' and 'nonce' must be byte-reversed, and in what way.
getwork does the byte-reversing. midstate, data and hash1 are already big-endian, and you pass data back still big-endian, so you work in big-endian and don't have to do any byte-reversing. They're the same data that is passed to the ScanHash_ functions. You can take midstate, data and hash1, put them in 16-byte aligned buffers and pass them to a ScanHash_ function, like ScanHash(pmidstate, pdata + 64, phash1, nHashesDone). If a nonce is found, patch it into data and call getwork.

I should probably change the ScanHash_ functions to use pdata instead of pdata + 64 so they're consistent.

target is little endian, it's supposed to be the same as how m0mchil's did it. (if it's not, then it should be fixed) That's the only case where you would use byte reverse. I think you do it like: if ByteReverse((unsigned int*)hash[6]) < (unsigned int*)target[6].

Quote from: DiabloD3 on November 24, 2010, 11:31:11 AM（https://bitcointalk.org/index.php?topic=1901.msg24050#msg24050）Satoshi, please fix your implementation of getwork so it complies with m0mchill's specification
This is the new spec. It shouldn't be hard to update your miner to use it.

The changes are:
- It does not return work when you submit a possible hit, only when called without parameter.
- The block field has been split into data and hash1.
- state renamed to midstate for consistency.
- extranonce not needed.

Re: OpenCL miner for the masses

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: OpenCL miner for the masses

Date2010-11-24 17:53:09 UTC

ForumBitcointalk · 原文

新版 getwork 已经在官方客户端里了，但矿机需要更新一下才能用。

英文原文

A revised version of getwork is now in the official client, but the miners need to be updated a little to use it.

Re: RFC: ship block chain 1-74000 with release tarballs?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: RFC: ship block chain 1-74000 with release tarballs?

Date2010-11-25 17:51:39 UTC

ForumBitcointalk · 原文

费时间的不是下载，是验证和建索引。

从带宽上看，它比你下载一个归档包更高效。比特币只下载 blk0001.dat 里的数据，目前是 55MB，自己构建 47MB 的 blkindex.dat。构建 blkindex.dat 才是所有磁盘活动的原因。

区块下载期间，每 500 个区块才把数据库刷到磁盘一次。你可能会看到区块数在 ??499 和 ??999 处停住。那就是在刷盘。

自己做验证和建索引，是确保索引数据可信的唯一办法。如果从不可信的来源拷贝 blk0001.dat 和 blkindex.dat，你没法知道里面的内容是否都可信。

也许 Berkeley DB 有些可调参数，能启用或增大缓存。

英文原文

It's not the downloading that takes the time, it's verifying and indexing it.

Bandwidthwise, it's more efficient than if you downloaded an archive. Bitcoin only downloads the data in blk0001.dat, which is currently 55MB, and builds blkindex.dat itself, which is 47MB. Building blkindex.dat is what causes all the disk activity.

During the block download, it only flushes the database to disk every 500 blocks. You may see the block count pause at ??499 and ??999. That's when it's flushing.

Doing your own verifying and indexing is the only way to be sure your index data is secure. If you copy blk0001.dat and blkindex.dat from an untrusted source, there's no way to know if you can trust all the contents in them.

Maybe Berkeley DB has some tweaks we can make to enable or increase cache memory.

Version 0.3.17

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleVersion 0.3.17

Date2010-11-25 20:07:36 UTC

ForumBitcointalk · 原文

0.3.17 版现已发布。

改动：
- 新的 getwork，感谢 m0mchil
- UI 选项菜单里加了交易费设置
- 免费交易限制
- sendtoaddress 返回交易 id 而不是 "sent"
- getaccountaddress <account>

UI 交易费设置很简单，因为 0.1.5 里还有残留，我只需要重新启用。

基于账户的命令 move、sendfrom 和 getbalance <account> 会在下个版本里。还有一些改动要先做完。

下载：
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.17/

英文原文

Version 0.3.17 is now available.

Changes:
- new getwork, thanks m0mchil
- added transaction fee setting in UI options menu
- free transaction limits
- sendtoaddress returns transaction id instead of "sent"
- getaccountaddress <account>

The UI transaction fee setting was easy since it was still there from 0.1.5 and all I had to do was re-enable it.

The accounts-based commands: move, sendfrom and getbalance <account> will be in the next release. We still have some more changes to make first.

Downloads:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.17/

Re: RFC: ship block chain 1-74000 with release tarballs?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: RFC: ship block chain 1-74000 with release tarballs?

Date2010-11-26 17:32:01 UTC

ForumBitcointalk · 原文

我在一块很慢的 7 年老硬盘上测过，带宽和 CPU 明显不是瓶颈。初始下载用了 1 小时 20 分钟。

如果花的时间比这长得多，肯定超过 24 小时，那一定是从很慢的节点下载，或者你的连接比约 15KB/秒（120kbps）还慢得多，或者有别的问题。真发生的话，很想知道瓶颈看起来是什么。

大约每 10 分钟，最新区块发过来时，它就有机会换到更快的节点。最新区块广播时，它会向其他节点请求接下来的 500 个区块，并从发得最快的那个继续下载。至少应该是这样工作的。

引用自 jgarzik（2010 年 11 月 26 日 02:07:43 AM）（https://bitcointalk.org/index.php?topic=1931.msg24522#msg24522）：引用自 satoshi（2010 年 11 月 25 日 05:51:39 PM）（https://bitcointalk.org/index.php?topic=1931.msg24438#msg24438）：也许 Berkeley DB 有些可调参数，能启用或增大缓存。
下载时你需要 ACID（http://en.wikipedia.org/wiki/ACID）里的哪几条性质？
可能只需要多点读缓存。建索引时它要在 blk0001.dat 和 blkindex.dat 上到处随机读。它不能假设文件比内存小，虽然目前确实还小。缓存会有效，因为大多数依赖都是近期的。

应该有人去试试不同的 Berkeley DB 设置，看有没有能让下载明显变快的。如果发现了明显有效的，我们再敲定细节。

引用自（……）：往 BDB 加记录其实就是往日志文件末尾追加，直到你发 checkpoint。checkpoint 再更新主数据库文件。我们每 500 个区块 checkpoint 一次。

英文原文

I tested it on a slow 7 year old drive, where bandwidth and CPU were clearly not the bottleneck. Initial download took 1 hour 20 minutes.

If it's taking a lot longer than that, certainly 24 hours, then it must be downloading from a very slow node, or your connection is much slower than around 15KB per sec (120kbps), or something else is wrong. It would be nice to know what appears to be the bottleneck when that happens.

Every 10 minutes or so when the latest block is sent, it should have the chance to change to a faster node. When the latest block is broadcast, it requests the next 500 blocks from other nodes, and continues the download from the one that sends it fastest. At least, that's how it should work.

Quote from: jgarzik on November 26, 2010, 02:07:43 AM（https://bitcointalk.org/index.php?topic=1931.msg24522#msg24522）Quote from: satoshi on November 25, 2010, 05:51:39 PM（https://bitcointalk.org/index.php?topic=1931.msg24438#msg24438）Maybe Berkeley DB has some tweaks we can make to enable or increase cache memory.
Which of the ACID（http://en.wikipedia.org/wiki/ACID） properties do you need, while downloading?
It may only need more read caching. It has to read randomly all over blk0001.dat and blkindex.dat to index. It can't assume the file is smaller than memory, although it currently still is. Caching would be effective, since most dependencies are recent.

Someone should experiment with different Berkeley DB settings and see if there's something that makes the download substantially faster. If something substantial is discovered, then we can work out the particulars.

QuoteAdding BDB records is simply appending to a log file, until you issue a checkpoint. The checkpoint then updates the main database file.We checkpoint every 500 blocks.

Re: Version 0.3.17

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Version 0.3.17

Date2010-11-26 18:23:30 UTC

ForumBitcointalk · 原文

Laszlo 做 Windows 构建，但好久没请他做了，因为没什么大改动。我会请他做这个版本。

英文原文

Laszlo does them, but I haven't asked him to do one for a while because there wasn't anything major. I'll ask him to do this version.

Re: New getwork

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: New getwork

Date2010-11-26 21:31:13 UTC

ForumBitcointalk · 原文

它就是这么做的，返回 true/false。

英文原文

That's what it does, it returns true/false.

Re: New demonstration CPU miner available

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: New demonstration CPU miner available

Date2010-11-26 22:02:41 UTC

ForumBitcointalk · 原文

你应该试试在 sha256.cpp 里用 tcatm 的 4 路 SSE2 SHA。它作为 C 文件编译没问题，只要把 sha256.cpp 改名为 sha256.c。我在 Windows 上简单测试能跑通，但和比特币链接在一起就不行。作为 C 程序的一部分而不是 C++，它可能更有机会跑起来。

目前只在 Linux 构建里启用了，所以如果你能把它搞定，可以让 Windows 用户也用上。在 AMD CPU 上大约快 100%。

英文原文

You should try it with tcatm's 4-way SSE2 SHA in sha256.cpp. It compiles fine as a C file, just rename sha256.cpp to sha256.c. I was able to get it to work in simple tests on Windows, but not when linked in with Bitcoin. It may have a better chance of working as part of a C program instead of C++.

Currently it's only enabled in the Linux build, so if you get it to work you could make it available to Windows users. It's about 100% speedup on AMD CPUs.

Re: Cooperative mining

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Cooperative mining

Date2010-11-28 16:03:30 UTC

ForumBitcointalk · 原文

ribuck 的描述很到位。

矿池运营者可以改自己的 getwork，多收一个参数：份额打到哪个地址。

对矿池运营者来说，简单的做法是等到下一个区块被找到，再按比例分配：
用户的近命中数/所有人的近命中总数

这样起步更简单、更安全。好处是同一个用户的多次命中可以合并成一笔交易。你命中的很多通常来自同一批人。

即时满足的做法是每个近命中立刻按固定金额支付，运营者承担随机性风险——找到区块前近命中可能多也可能少。

不管哪种，提交解出区块那次命中的用户应该额外拿一笔，比如 10 BTC。

新用户甚至根本不需要比特币软件。他们可以下载一个矿机，在 mtgox 或 mybitcoin 上开个账户，把充值地址填进矿机，指向任何人的矿池服务器。矿机说找到东西后，过一会儿账户里就会多出几个币。

矿机作者最好确保永远不误报近命中。用户会靠这个检查矿池运营者有没有作弊。如果矿机错误地说找到了，用户去账户里一看没有，就会迁怒矿池运营者。

英文原文

ribuck's description is spot on.

Pool operators can modify their getwork to take one additional parameter, the address to send your share to.

The easy way for the pool operator would be to wait until the next block is found and divy it up proportionally as:
user's near-hits/total near-hits from everyone

That would be easier and safer to start up. It also has the advantage that multiple hits from the same user can be combined into one transaction. A lot of your hits will usually be from the same people.

The instant gratification way would be to pay a fixed amount for each near-hit immediately, and the operator takes the risk from randomness of having more or less near-hits before a block is found.

Either way, the user who submits the hit that solves the block should get an extra amount off the top, like 10 BTC.

New users wouldn't really even need the Bitcoin software. They could download a miner, create an account on mtgox or mybitcoin, enter their deposit address into the miner and point it at anyone's pool server. When the miner says it found something, a while later a few coins show up in their account.

Miner writers better make sure they never false-positive near-hits. Users will depend on that to check if the pool operator is cheating them. If the miner wrongly says it found something, users will look in their account, not find anything, and get mad at the pool operator.

Re: RFC: ship block chain 1-74000 with release tarballs?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: RFC: ship block chain 1-74000 with release tarballs?

Date2010-11-28 17:13:01 UTC

ForumBitcointalk · 原文

抛开其他人说的，先说当前下一步是什么：
引用自（……）：应该有人去试试不同的 Berkeley DB 设置，看有没有能让下载明显变快的。如果发现了明显有效的，我们再敲定细节。
我尤其怀疑，多点读缓存会很有帮助。

引用自 jgarzik（2010 年 11 月 28 日 02:33:29 AM）（https://bitcointalk.org/index.php?topic=1931.msg25017#msg25017）：IRC 上又来个新用户，这次是 Linux，下载速度是 4 秒一个区块——估计总下载时间约 4 天。
那就是有更具体的问题了。这不是正常初始下载该有的速度。没有更多细节就没法诊断。如果是下载慢，10–20 分钟后下一次区块广播应该让它换到更快的源，那时有没有变快？debug.log 里可能有线索。他们的网速多快？是一直稳定地慢，还是某个点突然变慢？

引用自（……）：创世区块到区块 74000 的哈希都硬编码（编译）进了比特币，那我们完全可以从任何地方自动下载一个区块数据库的压缩包，解开、验证，然后开始跑。
74000 检查点保护不了你，下载超过 74000 后它就没用了。-checkblocks 做得更多，但也很容易被绕过。你还是得信任那个压缩包的提供者。

如果真有“验证它”这一步，那花的功夫和现在正常初始下载一样长，而瓶颈是建索引，不是数据下载。

引用自 jgarzik（2010 年 11 月 28 日 07:33:55 AM）（https://bitcointalk.org/index.php?topic=1931.msg25058#msg25058）：想必将来会有只下载区块头的轻客户端，但那也有几十万个头……
每个头 80 字节，没有建索引的工作量。可能 1 分钟就够。

引用自（……）：用一个不是为批量数据传输设计的协议（比特币 P2P）传未压缩数据。
数据主要是哈希、密钥和签名，压缩不动。

初始下载的速度反映的不是协议的批量传输速率。限速因素是下载同时在做的建索引。

英文原文

Despite everything else said, the current next step is:
QuoteSomeone should experiment with different Berkeley DB settings and see if there's something that makes the download substantially faster. If something substantial is discovered, then we can work out the particulars.
In particular, I suspect that more read caching might help a lot.

Quote from: jgarzik on November 28, 2010, 02:33:29 AM（https://bitcointalk.org/index.php?topic=1931.msg25017#msg25017）Another new user on IRC, Linux this time, was downloading at a rate of 1 block every 4 seconds -- estimated total download time around 4 days.
Then something more specific was wrong. That's not due to normal initial download time. Without more details, it can't be diagnosed. If it was due to slow download, did it speed up after 10-20 minutes when the next block broadcast should have made it switch to a faster source? debug.log might have clues. How fast is their Internet connection? Was it steadily slow, or just slow down at one point?

QuoteWe have the hashes for genesis block through block 74000 hardcoded (compiled) into bitcoin, so there's no reason why we shouldn't be able to automatically download a compressed zipfile of the block database from anywhere, unpack it, verify it, and start running.
The 74000 checkpoint is not enough to protect you, and does nothing if the download is already past 74000. -checkblocks does more, but is still easily defeated. You still must trust the supplier of the zipfile.

If there was a "verify it" step, that would take as long as the current normal initial download, in which it is the indexing, not the data download, that is the bottleneck.

Quote from: jgarzik on November 28, 2010, 07:33:55 AM（https://bitcointalk.org/index.php?topic=1931.msg25058#msg25058）Presumably at some point there will be a lightweight client that only downloads block headers, but there will still be hundreds of thousands of those...
80 bytes per header and no indexing work. Might take 1 minute.

Quoteuncompressed data using a protocol (bitcoin P2P) that wasn't designed for bulk data transfer.
The data is mostly hashes and keys and signatures that are uncompressible.

The speed of initial download is not a reflection of the bulk data transfer rate of the protocol. The gating factor is the indexing while it downloads.

Re: Is safe running bitcoins with the same wallet on more computers simultaneously?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Is safe running bitcoins with the same wallet on more computers simultaneously?

Date2010-11-28 18:06:39 UTC

ForumBitcointalk · 原文

引用自（……）：它会自动同步吗？
完全不会。在多台电脑上用 wallet.dat 的多个副本是不推荐、也不支持的，事实上整个比特币就是按“防这一手”设计的。两个副本都会搞坏。

如果你是想把挖到的币归集到一个钱包，现在更好的办法是在其他机器上跑 getwork 矿机。jgarzik 有个 CPU 矿机，支持 tcatm 的 4 路 SSE2，所以在 Windows 上，如果你是 AMD 或较新的 Intel（core 3、5 或 7），它比内置 SHA 最快快一倍。

新的演示版 CPU 矿机：
http://bitcointalk.org/index.php?topic=1925.0

英文原文

QuoteWill it be synchronized automatically?
Very much not. Using multiple copies of wallet.dat is not recommended or supported, in fact all of Bitcoin is designed to defeat that. Both copies will get screwed up.

If you're trying to consolidate your generated coins into one wallet, a better solution now is to run getwork miners on the additional systems. jgarzik has a CPU miner, and it supports tcatm's 4-way SSE2, so on Windows it's up to twice as fast as the built-in SHA if you have an AMD or recent Intel (core 3, 5 or 7).

New demonstration CPU miner available:
http://bitcointalk.org/index.php?topic=1925.0

Re: RFC: ship block chain 1-74000 with release tarballs?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: RFC: ship block chain 1-74000 with release tarballs?

Date2010-11-29 20:19:12 UTC

ForumBitcointalk · 原文

你好像总比实际情况更倾向于认定一切都坏了。

写区块索引是轻活。建交易索引才是每区块大量随机访问的工作。我怀疑读所有前序 txin 才是慢的原因。读缓存能帮上忙。最好让 DB 自己做。也许它有缓存用多少内存的设置。

引用自（……）：1）比特币应该在程序启动时打开数据库，而不只是打开环境，程序退出时关闭数据库。
已经是这样了。看 CDB。（比如）CTxDB 对象的生命周期只是为了支持数据库事务，以及在退出时知道还有没有东西在用数据库。

引用自（……）：而且，比特币会强制做数据库 checkpoint，把日志里的所有事务推进主数据库。
如果真是这样会慢得多。正常应该是一分钟或 500 个区块才一次：

if (strFile == "blkindex.dat" && IsInitialBlockDownload() && nBestHeight % 500 != 0)
nMinutes = 1;
dbenv.txn_checkpoint(0, nMinutes, 0);

大概应该加上这个：
if (!fReadOnly)
dbenv.txn_checkpoint(0, nMinutes, 0);

引用自（……）：2）初始区块下载时，txn commit 应该每 N 条记录一次，而不是每条记录一次。我建议 N=1000。
事务提交意味着刷盘？这让我很意外。我以为包在事务里的数据库操作会像其他数据库操作一样记日志。很多数据库应用几乎每对操作都要包事务，比如从一个账户转钱到另一个（借记 a，贷记 b）。我无法想象它们被要求自己把所有东西批量打包。

下面两种情况，情况 1 会刷一次、情况 2 会刷两次吗？

情况 1：
write
write
write
write
checkpoint

情况 2：
begin transaction
write
write
commit transaction
begin transaction
write
write
commit transaction
checkpoint

扭曲我们的数据库用法不是正确方向。关键是 BDB 的设置和缓存。

英文原文

It seems like you're inclined to assume everything is wrong more than is actually so.

Writing the block index is light work. Building the tx index is much more random access per block. I suspect reading all the prev txins is what's slow. Read caching would help that. It's best if the DB does that. Maybe it has a setting for how much cache memory to use.

Quote1) bitcoin should be opening databases, not just environment, at program startup, and closing database at program shutdown.
Already does that. See CDB. The lifetime of the (for instance) CTxDB object is only to support database transactions and to know if anything is still using the database at shutdown.

QuoteAnd, additionally, bitcoin forces a database checkpoint, pushing all transactions from log into main database.
If it was doing that it would be much slower. It's supposed to be only once a minute or 500 blocks:

if (strFile == "blkindex.dat" && IsInitialBlockDownload() && nBestHeight % 500 != 0)
nMinutes = 1;
dbenv.txn_checkpoint(0, nMinutes, 0);

Probably should add this:
if (!fReadOnly)
dbenv.txn_checkpoint(0, nMinutes, 0);

Quote2) For the initial block download, txn commit should occur once every N records, not every record. I suggest N=1000.
Does transaction commit imply flush? That seems surprising to me. I assume a database op wrapped in a transaction would be logged like any other database op. Many database applications need to wrap almost every pair of ops in a transaction, such as moving money from one account to another. (debit a, credit b) I can't imagine they're required to batch all their stuff up themselves.

In the following cases, would case 1 flush once and case 2 flush twice?

case 1:
write
write
write
write
checkpoint

case 2:
begin transaction
write
write
commit transaction
begin transaction
write
write
commit transaction
checkpoint

Contorting our database usage will not be the right approach. It's going to be BDB settings and caching.

Re: Incompatible wallet format with latest bitcoin-git ?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Incompatible wallet format with latest bitcoin-git ?

Date2010-11-30 19:02:31 UTC

ForumBitcointalk · 原文

这个钱包是跟什么一起用的？早期的 accounts 补丁还是 git 构建？

是在加载钱包的时候。我猜肯定在这段里：

else if (strType == "acentry")
{
string strAccount;
ssKey >> strAccount;
uint64 nNumber;
ssKey >> nNumber;
if (nNumber > nAccountingEntryNumber)
nAccountingEntryNumber = nNumber;
}

你可以用这段查一下：

else if (strType == "acentry")
{
string strAccount;
assert(!ssKey.empty());
ssKey >> strAccount;
uint64 nNumber;
if (ssKey.size() != 8 )
printf("***** %s %d\n", strAccount.c_str(), ssKey.size());
assert(ssKey.empty() == false);
ssKey >> nNumber;
if (nNumber > nAccountingEntryNumber)
nAccountingEntryNumber = nNumber;
}

git 上某个时期的 accounts 中间版本是不是有过键只是 ("acentry", "account") 的？

如果你有 gdb，可以在 gdb 里跑，做个 backtrace。

gdb --args bitcoin ...
run
(wait for exception)
bt

英文原文

What was this wallet used with? An early accounts patch or git build?

It's while loading the wallet. I assume it must be in this:

else if (strType == "acentry")
   {
   string strAccount;
   ssKey >> strAccount;
   uint64 nNumber;
   ssKey >> nNumber;
   if (nNumber > nAccountingEntryNumber)
   nAccountingEntryNumber = nNumber;
   }

You could check that with this:

else if (strType == "acentry")
   {
   string strAccount;
   assert(!ssKey.empty());
   ssKey >> strAccount;
   uint64 nNumber;
   if (ssKey.size() != 8 )
   printf("***** %s %d
", strAccount.c_str(), ssKey.size());
   assert(ssKey.empty() == false);
   ssKey >> nNumber;
   if (nNumber > nAccountingEntryNumber)
   nAccountingEntryNumber = nNumber;
   }

Was there an interim version of accounts on git at some point that had just ("acentry", "account") for the key?

If you have gdb, you could run it in gdb and do a backtrace.

gdb --args bitcoin ...
run
(wait for exception)
bt

Re: RFC: ship block chain 1-74000 with release tarballs?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: RFC: ship block chain 1-74000 with release tarballs?

Date2010-12-01 21:25:39 UTC

ForumBitcointalk · 原文

这是个不错的优化。我下次更新 SVN 时加上。

更一般地，我们也可以考虑这个：

dbenv.set_lk_max_objects(10000);
dbenv.set_errfile(fopen(strErrorFile.c_str(), "a")); /// debug
dbenv.set_flags(DB_AUTO_COMMIT, 1);
+ dbenv.set_flags(DB_TXN_NOSYNC, 1);
ret = dbenv.open(strDataDir.c_str(),
DB_CREATE |
DB_INIT_LOCK |
DB_INIT_LOG |

那之后写钱包的刷盘就靠 CDB::Close() 里的 dbenv.txn_checkpoint(0, 0, 0) 了。

英文原文

That's a good optimisation. I'll add that next time I update SVN.

More generally, we could also consider this:

We would then rely on dbenv.txn_checkpoint(0, 0, 0) in CDB::Close() to flush after wallet writes.

Re: Wikileaks contact info?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Wikileaks contact info?

Date2010-12-05 09:08:08 UTC

ForumBitcointalk · 原文

引用自 RHorning（2010 年 12 月 4 日 10:17:44 PM）（https://bitcointalk.org/index.php?topic=1735.msg26876#msg26876）：说白了，放马过来吧。鼓励维基解密用比特币，我愿意面对这一行为带来的任何风险或后果。
不，别“放马过来”。

这个项目需要逐步成长，软件才能在成长中不断加固。

我在此呼吁维基解密不要尝试使用比特币。比特币还是个处于婴儿期的小型 beta 社区。你拿不到多少，不过是零花钱，而你带来的热度在这个阶段很可能摧毁我们。

英文原文

Quote from: RHorning on December 04, 2010, 10:17:44 PM（https://bitcointalk.org/index.php?topic=1735.msg26876#msg26876）Basically, bring it on. Let's encourage Wikileaks to use Bitcoins and I'm willing to face any risk or fallout from that act.
No, don't "bring it on".

The project needs to grow gradually so the software can be strengthened along the way.

I make this appeal to WikiLeaks not to try to use Bitcoin. Bitcoin is a small beta community in its infancy. You would not stand to get more than pocket change, and the heat you would bring would likely destroy us at this stage.

Re: JSON-RPC method idea: list transactions newer than a given txid

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: JSON-RPC method idea: list transactions newer than a given txid

Date2010-12-08 20:21:49 UTC

ForumBitcointalk · 原文

用 listtransactions 这么干是不安全的。

我知道有人批评我不情愿加 listtransactions。让我解释一下我的顾虑。

交易是动态的。过去的交易可能变成未确认、消失又回来、变无效消失，或者被一笔不同的双重支付替换。它们的日期会变，顺序会变。

程序员天然倾向于这样用 listtransactions：把我上次问过之后的新交易喂给我，我自己记账或存静态记录。这在一切正常使用中都好像管用，但只要你拿金额做点什么，它就高度可利用：
1）过去的交易变无效消失了，你怎么知道？
2）区块链重组时，交易被重新确认，很容易重复计数。
3）一笔交易可以被一笔 txid 不同的双重支付替换。你会把两笔都数进去。

“因为以前的交易都见过了，所以只需要看新交易”这个模型是错的。旧交易随时可能变。

任何时候你根据收到的付款金额采取行动，都必须回头问比特币要一个当前余额总数（或用 move、sendfrom），并做好它可能变少的准备。

现在有了 Accounts 功能，做对的事更容易了，我们也更有条件提供 listtransactions。

英文原文

It's not safe to use listtransactions this way.

I know I've been criticized for being reluctant about listtransactions. Let me explain my reluctance.

Transactions are dynamic. Past transactions can become unconfirmed, go away and come back, become invalid and disappear, or be replaced by a different double-spend. Their date can change, their order can change.

Programmers are naturally inclined to want to use listtransactions like this: feed me the new transactions since I last asked, and I'll keep my own tally or static record of them. This will seem to work in all regular use, but if you use the amounts for anything, it is highly exploitable:
1) How do you know if a past transaction becomes invalid and disappears?
2) When there's a block-chain reorg, it would be easy to double-count transactions when they get confirmed again.
3) A transaction can be replaced by a double-spend with a different txid. You would count both spends.

The model where you assume you only need to see new transactions because you've already seen previous transactions is not true. Old transactions can change at any time.

Any time you take an action based on payment amounts received, you always need to go back to bitcoin and ask for a current balance total (or use move or sendfrom), and be ready for the possibility that it can go down.

Now that we have the Accounts feature making it easier to do it the right way, we're better prepared to have listtransactions.

Re: JSON-RPC method idea: list transactions newer than a given txid

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: JSON-RPC method idea: list transactions newer than a given txid

Date2010-12-08 22:36:45 UTC

ForumBitcointalk · 原文

那你怎么应付我在你引用的那条消息里列的问题？

英文原文

Then how do you cope with the issues I listed in the message you quoted?

Version 0.3.18

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleVersion 0.3.18

Date2010-12-08 23:19:24 UTC

ForumBitcointalk · 原文

改动：
- 修了从 0.3.17 降级再升级回来时的 wallet.dat 兼容问题
- IsStandard() 检查，区块里只收已知交易类型
- Jgarzik 的优化，初始区块下载快一点

这个版本的主要新增是 Gavin 一直在做的基于账户的 JSON-RPC 命令（更多细节见 http://bitcointalk.org/index.php?topic=1886.0）。
- getaccountaddress
- sendfrom
- move
- getbalance
- listtransactions

下载：
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.18/

英文原文

Changes:
- Fixed a wallet.dat compatibility problem if you downgraded from 0.3.17 and then upgraded again
- IsStandard() check to only include known transaction types in blocks
- Jgarzik's optimisation to speed up the initial block download a little

The main addition in this release is the Accounts-Based JSON-RPC commands that Gavin's been working on (more details at http://bitcointalk.org/index.php?topic=1886.0).
- getaccountaddress
- sendfrom
- move
- getbalance
- listtransactions

Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.18/

Re: JSON-RPC method idea: list transactions newer than a given txid

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: JSON-RPC method idea: list transactions newer than a given txid

Date2010-12-09 00:12:17 UTC

ForumBitcointalk · 原文

我说的不是给定 minconf 级别的正常风险，我说的是这样用 listtransactions 的额外坑。

引用自 satoshi（2010 年 12 月 8 日 10:36:45 PM）（https://bitcointalk.org/index.php?topic=2151.msg28292#msg28292）：2）区块链重组时，交易被重新确认，很容易重复计数交易。
楼主举的 listtransactions <account> [count=10] [txid] 的例子似乎暗示——程序员也很容易想当然——只要把上次调用 listtransactions 返回的最后一个 txid 传进去，就永远不会重复看到同一笔交易，但事实并非如此。如果你没有自己维护持久的 map 或字典来跟踪哪些 txid 已经接受过，很容易把付款重复计数。

一个函数天生就适合某种显而易见的用法，而那种用法是个不明显的陷阱，这不对。

引用自 jgarzik（2010 年 12 月 8 日 11:07:22 PM）（https://bitcointalk.org/index.php?topic=2151.msg28301#msg28301）：引用自 satoshi（2010 年 12 月 8 日 10:36:45 PM）（https://bitcointalk.org/index.php?topic=2151.msg28292#msg28292）：3）一笔交易可以被一笔 txid 不同的双重支付替换。你会把两笔都数进去。
listtransactions 并没有让这个问题比 listreceivedbyaddress 本来就有的漏洞更严重。
假设两笔支付都打到同一个地址。getreceivedbyaddress 在任何时刻都只会数其中一笔，永远不会两笔都数。

用 listtransactions，很容易两笔都数进去。你看到第一笔，数了；看到第二笔，又数了。总数就重复了。

英文原文

I'm not talking about the normal risk for a given minconf level, I'm talking about additional pitfalls from listtransactions when used this way.

Quote from: satoshi on December 08, 2010, 10:36:45 PM（https://bitcointalk.org/index.php?topic=2151.msg28292#msg28292）2) When there's a block-chain reorg, it would be easy to double-count transactions when they get confirmed again.
The OP's example of listtransactions <account> [count=10] [txid] seems to imply and it would be very easy for programmers to assume that if they pass in the last txid of the previous call to listtransactions, they will never see the same transaction more than once, which is not the case. It would be very easy to double-count payments if you don't maintain your own persistent map or dictionary to track which txid's you've already accepted.

It doesn't seem right to have a function that seems tailor made to be used a certain obvious way, and that way is a non-obvious trap.

Quote from: jgarzik on December 08, 2010, 11:07:22 PM（https://bitcointalk.org/index.php?topic=2151.msg28301#msg28301）Quote from: satoshi on December 08, 2010, 10:36:45 PM（https://bitcointalk.org/index.php?topic=2151.msg28292#msg28292）3) A transaction can be replaced by a double-spend with a different txid. You would count both spends.
listtransactions does not add anything to this problem, beyond that which is already vulnerable through listreceivedbyaddress.
Suppose both spends are to the same address. getreceivedbyaddress would always count only one or the other spend at any given time, never both.

Using listtransactions, it would be very easy to count both. You see the first spend, you count it. You see the second spend, you count it. Total is double counted.

Re: Version 0.3.18

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Version 0.3.18

Date2010-12-09 14:37:05 UTC

ForumBitcointalk · 原文

新的交易模板可以按需添加。用不了几天，就会有大量 GPU 算力接受并处理它。网络支持会早在有足够多客户端懂得接收和解读新交易之前就完善。

时间戳哈希现在其实已经能做：

txin: 0.01
txout: 0.00 <appid, hash> OP_CHECKSIG
fee: 0.01

如果真有像 BitDNS 这样的实际应用准备开始往链里插哈希，我们随时可以加一个专门的时间戳交易模板。

我喜欢 Hal Finney 的用户友好时间戳想法。把文件的哈希转成比特币地址，往它发 0.01：

引用自 Hal（2010 年 12 月 5 日 11:43:56 PM）（https://bitcointalk.org/index.php?topic=2077.msg27173#msg27173）：我想到了个简单办法实现上面说的时间戳概念。对你想加时间戳的文件跑 sha1sum。把结果转成比特币地址，比如用 http://blockexplorer.com/q/hashtoaddress 。然后往那个地址打一小笔款。

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

我知道这可以说不是比特币分布式数据库的好用法，但没人能阻止人们这么干，所以我们得知道它可能发生。

英文原文

New transaction templates can be added as needed. Within a few days, there will be plenty of GPU power that accepts and works on it. Network support will be thorough long before there'll be enough clients who understand how to receive and interpret the new transaction.

Timestamp hashes are still already possible:

txin: 0.01
txout: 0.00 <appid, hash> OP_CHECKSIG
fee: 0.01

If there's an actual application like BitDNS getting ready to actually start inserting hashes, we can always add a specific transaction template for timestamps.

I like Hal Finney's idea for user-friendly timestamping. Convert the hash of a file to a bitcoin address and send 0.01 to it:

Quote from: Hal on December 05, 2010, 11:43:56 PM（https://bitcointalk.org/index.php?topic=2077.msg27173#msg27173）I thought of a simple way to implement the timestamp concept I mentioned above. Run sha1sum on the file you want to timestamp. Convert the result to a Bitcoin address, such as via http://blockexplorer.com/q/hashtoaddress . Then send a small payment to that address.

The money will be lost forever, as there is no way to spend it further, but the timestamp Bitcoin address will remain in the block chain as a record of the file's existence.

I understand that this is arguably not a good use of the Bitcoin distributed database, but nothing stops people from doing this so we should be aware that it may be done.

Re: Version 0.3.18

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Version 0.3.18

Date2010-12-09 15:17:53 UTC

ForumBitcointalk · 原文

当我意识到新交易类型能加得多快之后，我开始认同 Gavin 的白名单观点。

引用自 nanotube（2010 年 12 月 9 日 06:19:05 AM）（https://bitcointalk.org/index.php?topic=2162.msg28434#msg28434）：为什么不让大家都省事点，直接允许交易里带比如 64 或 128 字节的随机数据？
这已经能做到了。<pubkey> OP_CHECKSIG。<pubkey> 可以是 33 到 120 字节。

我也支持第三种交易类型：时间戳哈希大小的任意数据。反正本来就能做，加一个又何妨。它还能告诉节点不用费心去索引它。

英文原文

I came to agree with Gavin about whitelisting when I realized how quickly new transaction types can be added.

Quote from: nanotube on December 09, 2010, 06:19:05 AM（https://bitcointalk.org/index.php?topic=2162.msg28434#msg28434）why not make it easier on everyone and just allow say, 64 or 128 bytes of random data in a transaction?
That's already possible. <pubkey> OP_CHECKSIG. <pubkey> can be 33 to 120 bytes.

I also support a third transaction type for timestamp hash sized arbitrary data. There's no point not having one since you can already do it anyway. It would tell nodes they don't need to bother to index it.

Re: JSON-RPC method idea: list transactions newer than a given txid

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: JSON-RPC method idea: list transactions newer than a given txid

Date2010-12-09 18:08:08 UTC

ForumBitcointalk · 原文

引用自 jgarzik（2010 年 12 月 9 日 12:58:05 AM）（https://bitcointalk.org/index.php?topic=2151.msg28330#msg28330）：关于“txs after <txid>”，我同意你和 satoshi 的看法。我的 listtransactions（现在是 xlisttransactions）补丁特意没有这个功能，一直都没有。
只要接口设计成展示用户最近 N 笔交易历史这种用途就行，现在有了 Accounts 功能，用正确的方式做付款检测更容易了。

Gavin，listtransactions 能不能加个选项，列出所有账户的交易？

我不确定接口能长什么样，也许：
listtransactions <JSON null type> [count]

不过从命令行做这个会很难。

我想不出接口的好方案，这就是问题所在。也许像 "" 一样搞个 "*” 特殊情况。所有人都得确保用户建不出叫 "*” 的账户名。

引用自 jgarzik（2010 年 12 月 9 日 04:13:50 PM）（https://bitcointalk.org/index.php?topic=2151.msg28572#msg28572）：当然，用交易跟踪这个很容易。
我不明白用交易跟踪这个怎么就“容易”了。

英文原文

Quote from: jgarzik on December 09, 2010, 12:58:05 AM（https://bitcointalk.org/index.php?topic=2151.msg28330#msg28330）I agree with you and satoshi about "txs after <txid>". My listtransactions (now xlisttransactions) patch pointedly does not have that feature, and never has.
As long as the interface is designed for things like showing the user the last N transactions history, it's fine, now that we have the Accounts feature making it easier to do payment detection the right way.

Gavin, could listtransactions have an option to list transactions for all accounts?

I'm not sure what the interface could be, maybe:
listtransactions <JSON null type> [count]

It would be hard to do that from the command line though.

I can't think of a good solution for the interface, that's the problem. Maybe "*" special case like "" is. Everyone would have to make sure no user can create account name "*".

Quote from: jgarzik on December 09, 2010, 04:13:50 PM（https://bitcointalk.org/index.php?topic=2151.msg28572#msg28572）Sure, and that's easy enough to track with transactions.
I don't get how that's "easy" to track with transactions.

Re: Automated nightly builds

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Automated nightly builds

Date2010-12-09 18:28:45 UTC

ForumBitcointalk · 原文

谢谢 Cdecker 把这个搭起来。

有没有可能也构建 GUI 版？如果是 Ubuntu，拿到 wxWidgets 2.9.0，应该就是照 build-unix.txt 的步骤走一遍的事。这个环境能一次构建好 wxWidgets、放那儿一直用吗？

英文原文

Thanks for setting this up Cdecker.

Is there any chance of getting it to build the GUI version also? If this is Ubuntu, if you get wxWidgets 2.9.0 it should just be a matter of following the steps in build-unix.txt exactly. Is this an environment where you can build wxWidgets once and leave it there and just keep using it?

Re: BitDNS and Generalizing Bitcoin

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: BitDNS and Generalizing Bitcoin

Date2010-12-09 21:02:42 UTC

ForumBitcointalk · 原文

我觉得 BitDNS 完全可以是独立的网络、独立的区块链，同时和比特币共享 CPU 算力。唯一的交集是让矿工能同时为两个网络找工作量证明。

网络之间不需要任何协调。矿工并行订阅两个网络。他们扫描 SHA 的方式是：一旦命中，就可能同时解出两个。如果一个网络难度更低，解可能只对其中一个网络有效。

我觉得外部矿机可以对两个程序都调 getwork，再把工作合并起来。也许先调比特币拿工作，交给 BitDNS 的 getwork 合成合并后的工作。

与其碎片化，不如让各网络共享、叠加彼此的总 CPU 算力。这就解决了“多个网络并存时，可用 CPU 算力集火某一个”的危险。反过来，世界上所有网络共享合并后的 CPU 算力，总强度增加。小网络也能接入现成的矿工基础，更容易起步。

英文原文

I think it would be possible for BitDNS to be a completely separate network and separate block chain, yet share CPU power with Bitcoin. The only overlap is to make it so miners can search for proof-of-work for both networks simultaneously.

The networks wouldn't need any coordination. Miners would subscribe to both networks in parallel. They would scan SHA such that if they get a hit, they potentially solve both at once. A solution may be for just one of the networks if one network has a lower difficulty.

I think an external miner could call getwork on both programs and combine the work. Maybe call Bitcoin, get work from it, hand it to BitDNS getwork to combine into a combined work.

Instead of fragmentation, networks share and augment each other's total CPU power. This would solve the problem that if there are multiple networks, they are a danger to each other if the available CPU power gangs up on one. Instead, all networks in the world would share combined CPU power, increasing the total strength. It would make it easier for small networks to get started by tapping into a ready base of miners.

Re: BitDNS and Generalizing Bitcoin

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: BitDNS and Generalizing Bitcoin

Date2010-12-09 22:46:50 UTC

ForumBitcointalk · 原文

引用自 nanotube（2010 年 12 月 9 日 09:20:40 PM）（https://bitcointalk.org/index.php?topic=1790.msg28700#msg28700）：矿工好像基本上得做“额外工作”。如果 bitdns 挖矿的额外工作没有奖励（当然它还会拖慢主链比特币的工作），矿工有什么动力去包含 bitdns（以及其他侧链）？
动力就是：同样的工作，还能拿到额外侧链的奖励。

挖比特币的同时，为什么不顺手拿免费域名呢？

如果你现在一周挖 50 BTC，那现在可以拿到 50 BTC 外加一些域名。

你只有一份工作。如果解出来，它同时解出比特币和 BitDNS 的一个区块。概念上，它们通过一棵默克尔树绑在一起。交到比特币这边，就掰掉 BitDNS 那根分支；交到 BitDNS 那边，就掰掉比特币这根分支。

实际要给比特币做改造的话，BitDNS 那边大概要多 ~200 字节，但这不是大事。你一直在说每区块 50 个域名，跟为了向后兼容的每区块 200 字节比，那是小巫见大巫。如果我们真在乎省几个字节，可以排一个很久以后的区块，让比特币升级到默克尔树在顶层的现代化结构。

注意，链在这棵新默克尔树的下面。也就是说，比特币和 BitDNS 各自在自己的区块里有自己的链式链接。这和常见的时间戳服务器结构是反的——那边是链在上面、默克尔树在下，因为那是要造一条共同的主链。这是两个不共享链的时间戳服务器。

英文原文

Quote from: nanotube on December 09, 2010, 09:20:40 PM（https://bitcointalk.org/index.php?topic=1790.msg28700#msg28700）seems that the miner would have to basically do "extra work". and if there's no reward from the bitdns mining from the extra work (which of course, slows down the main bitcoin work), what would be a miner's incentive to include bitdns (and whatever other side chains) ?
The incentive is to get the rewards from the extra side chains also for the same work.

While you are generating bitcoins, why not also get free domain names for the same work?

If you currently generate 50 BTC per week, now you could get 50 BTC and some domain names too.

You have one piece of work. If you solve it, it will solve a block from both Bitcoin and BitDNS. In concept, they're tied together by a Merkle Tree. To hand it in to Bitcoin, you break off the BitDNS branch, and to hand it in to BitDNS, you break off the Bitcoin branch.

In practice, to retrofit it for Bitcoin, the BitDNS side would have to have maybe ~200 extra bytes, but that's not a big deal. You've been talking about 50 domains per block, which would dwarf that little 200 bytes per block for backward compatibility. We could potentially schedule a far in future block when Bitcoin would upgrade to a modernised arrangement with the Merkle Tree on top, if we care enough about saving a few bytes.

Note that the chains are below this new Merkle Tree. That is, each of Bitcoin and BitDNS have their own chain links inside their blocks. This is inverted from the common timestamp server arrangement, where the chain is on top and then the Merkle Tree, because that creates one common master chain. This is two timestamp servers not sharing a chain.

Re: Fees in BitDNS confusion

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Fees in BitDNS confusion

Date2010-12-09 23:58:54 UTC

ForumBitcointalk · 原文

不是 locktime。

有个很久以后的可能设计：

你故意写一笔双重支付。输入输出都一样，这次带上手续费。当你的双重支付进了区块，第一笔支付就失效了。收款人其实察觉不到，因为新交易生效的那一刻旧交易失效，新交易直接顶替它的位置。

说起来容易做起来难。要做出能正确写双重支付的客户端，得做不少工作：在钱包里管理两个版本直到其中一个被选中、处理所有边界情况。现有代码里的每个假设都是“你不会写双重支付”。

比特币矿工那边也得改，交易池才有可能接受双重支付，但严格限定：输入输出必须一致且手续费更高。目前双重支付永远进不了交易池，所以每个节点都以“把先看到的那笔交易打进区块”为证。

英文原文

Not locktime.

There's a possible design for far in the future:

You intentionally write a double-spend. You write it with the same inputs and outputs, but this time with a fee. When your double-spend gets into a block, the first spend becomes invalid. The payee does not really notice, because at the moment the new transaction becomes valid, the old one becomes invalid, and the new transaction simply takes its place.

It's easier said than implemented. There would be a fair amount of work to make a client that correctly writes the double-spend, manages the two versions in the wallet until one is chosen, handles all the corner cases. Every assumption in the existing code is that you're not trying to write double-spends.

There would need to be some changes on the Bitcoin Miner side also, to make the possibility to accept a double-spend into the transaction pool, but only strictly if the inputs and outputs match and the transaction fee is higher. Currently, double-spends are never accepted into the transaction pool, so every node bears witness to which transaction it saw first by working to put it into a block.

Re: BitDNS and Generalizing Bitcoin

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: BitDNS and Generalizing Bitcoin

Date2010-12-10 17:29:28 UTC

ForumBitcointalk · 原文

把世界上所有工作量证明仲裁系统都塞进一个数据集，是扩展不起来的。

比特币和 BitDNS 可以分开用。用户不该为了用其中一个而被迫下载两个的全部。BitDNS 用户大概也不想下载接下来几个不相干的网络塞进来的所有东西。

各网络需要有各自的命运。BitDNS 用户可能完全自由地加各种大数据功能，因为域名注册商不需要很多；而比特币用户可能越来越严苛地限制链的大小，好让大量用户和小设备都能轻松用。

担心用比特币安全买域名的恐惧是假问题。用比特币换其他不可抵赖的商品很容易。

如果你还担心，密码学上可以做到无风险交易。双方在两边都摆好交易，当双方都签了交易，第二位签名者的签名会触发两边同时释放。第二位签名者没法只放一边不放另一边。

英文原文

Piling every proof-of-work quorum system in the world into one dataset doesn't scale.

Bitcoin and BitDNS can be used separately. Users shouldn't have to download all of both to use one or the other. BitDNS users may not want to download everything the next several unrelated networks decide to pile in either.

The networks need to have separate fates. BitDNS users might be completely liberal about adding any large data features since relatively few domain registrars are needed, while Bitcoin users might get increasingly tyrannical about limiting the size of the chain so it's easy for lots of users and small devices.

Fears about securely buying domains with Bitcoins are a red herring. It's easy to trade Bitcoins for other non-repudiable commodities.

If you're still worried about it, it's cryptographically possible to make a risk free trade. The two parties would set up transactions on both sides such that when they both sign the transactions, the second signer's signature triggers the release of both. The second signer can't release one without releasing the other.

Accounts example code

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleAccounts example code

Date2010-12-10 19:21:03 UTC

ForumBitcointalk · 原文

一些用 0.3.18 新的基于账户命令的示例伪代码。

print "send to " + getaccountaddress(username) + " to fund your account"
print "balance: " + getbalance(username, 0)
print "available balance: " + getbalance(username, 6)

// 如果你做了笔销售，把钱从他们的账户移到你的 "" 账户
if (move(username, "", amount, 6, "purchased item"))
SendTheGoods()

// 提现
sendfrom(username, bitcoinaddress, amount, 6, "withdrawal by user")

可以用 listtransactions(username) 给他们看最近交易列表。

英文原文

Some sample pseudocode using the new Accounts based commands in 0.3.18.

print "send to " + getaccountaddress(username) + " to fund your account"
print "balance: " + getbalance(username, 0)
print "available balance: " + getbalance(username, 6)

// if you make a sale, move the money from their account to your "" account
if (move(username, "", amount, 6, "purchased item"))
SendTheGoods()

// withdrawal
sendfrom(username, bitcoinaddress, amount, 6, "withdrawal by user")

You can use listtransactions(username) to show them a list of their recent transactions.

Re: BitDNS and Generalizing Bitcoin

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: BitDNS and Generalizing Bitcoin

Date2010-12-10 19:55:12 UTC

ForumBitcointalk · 原文

引用自 Hal（2010 年 12 月 10 日 07:14:04 PM）（https://bitcointalk.org/index.php?topic=1790.msg28938#msg28938）：额外的区块链会各自造出自己口味的币，在交易所和比特币交易？这些链专属币用来奖励那条链上的矿工，以及购买那条链管辖范围内的某种权利或特权？
对，域名和比特币之间的汇率会浮动。

BitDNS 用比 10 分钟更长的间隔比较合适。

到目前为止，这场讨论里已经需要不少管理数据了。如果你能自由用足需要的空间，不用担心为比特币链里昂贵的空间付手续费，会容易得多。一些交易：

改 IP 记录。

改名。域名对象可以赋予你拥有一个域名的权利，你可以随意改成任何没被占用的名字。这会鼓励用户释放掉不想要的名字。生成的域名初始是空白的，矿工把它卖给想改成自己要的名字的人。

续费。可以免费，或者要求消耗另一个域名对象来续费。这样的话，域名对象（domaincoins？）就代表拥有一年域名的权利。花掉的手续费归下个区块的矿工。

英文原文

Quote from: Hal on December 10, 2010, 07:14:04 PM（https://bitcointalk.org/index.php?topic=1790.msg28938#msg28938）additional block chains would each create their own flavor of coins, which would trade with bitcoins on exchanges? These chain-specific coins would be used to reward miners on those chains, and to purchase some kinds of rights or privileges within the domain of that chain?
Right, the exchange rate between domains and bitcoins would float.

A longer interval than 10 minutes would be appropriate for BitDNS.

So far in this discussion there's already a lot of housekeeping data required. It will be much easier if you can freely use all the space you need without worrying about paying fees for expensive space in Bitcoin's chain. Some transactions:

Changing the IP record.

Name change. A domain object could entitle you to one domain, and you could change it at will to any name that isn't taken. This would encourage users to free up names they don't want anymore. Generated domains start out blank and the miner sells it to someone who changes it to what they want.

Renewal. Could be free, or maybe require consuming another domain object to renew. In that case, domain objects (domaincoins?) could represent the right to own a domain for a year. The spent fee goes to the miners in the next block fee.

Re: BitDNS and Generalizing Bitcoin

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: BitDNS and Generalizing Bitcoin

Date2010-12-10 20:19:39 UTC

ForumBitcointalk · 原文

同意。所有交易、IP 变更、续费等都该有点手续费，归矿工。

可以考虑用一定量的工作来生成域名，而不是固定总发行量。每域名的工时可以按摩尔定律增长排期。这样域名数量会随需求和用户数增长。

英文原文

I agree. All transactions, IP changes, renewals, etc. should have some fee that goes to the miners.

You might consider a certain amount of work to generate a domain, instead of a fixed total circulation. The work per domain could be on a schedule that grows with Moore's Law. That way the number of domains would grow with demand and the number of people using it.

Re: BitDNS and Generalizing Bitcoin

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: BitDNS and Generalizing Bitcoin

Date2010-12-11 13:08:30 UTC

ForumBitcointalk · 原文

@dtvan：3 个点都很到位。
1）IP 记录不需要进链，只做注册商功能、不做 DNS。CA 问题也顺带解决了，漂亮。
2）选一个顶级域，.web +1。
3）过期和可观的续费成本，非常重要。

引用自 joe（2010 年 12 月 11 日 10:53:58 AM）（https://bitcointalk.org/index.php?topic=1790.msg29130#msg29130）：不过现在再想想，我支持在主网里纳入额外的 coinbase/跟踪系统。理由是不要把 CPU 算力稀释到多个网络。我们想要一个强大的网络，所以网络应该多才多艺。
避免 CPU 算力碎片化已经不再是理由。独立网络/链可以共享 CPU 算力，而几乎不共享其他东西。见：http://bitcointalk.org/index.php?topic=1790.msg28696#msg28696 和 http://bitcointalk.org/index.php?topic=1790.msg28715#msg28715

英文原文

@dtvan: all 3 excellent points.
1) IP records don't need to be in the chain, just do registrar function not DNS. And CA problem solved, neat.
2) Pick one TLD, .web +1.
3) Expiration and significant renewal costs, very important.

Quote from: joe on December 11, 2010, 10:53:58 AM（https://bitcointalk.org/index.php?topic=1790.msg29130#msg29130）However, thinking more about this now I support inclusion of additional coinbases / tracking systems in the main network. The reason for doing this is so as not to water down CPU power into multiple networks. We want one strong network, so the network should be versatile.
Avoiding CPU power fragmentation is no longer a reason. Independent networks/chains can share CPU power without sharing much else. See: http://bitcointalk.org/index.php?topic=1790.msg28696#msg28696 and http://bitcointalk.org/index.php?topic=1790.msg28715#msg28715

Re: Bitcoin and buffer overflow attacks

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: Bitcoin and buffer overflow attacks

Date2010-12-11 13:32:37 UTC

ForumBitcointalk · 原文

引用自 da2ce7（2010 年 12 月 11 日 05:49:22 AM）（https://bitcointalk.org/index.php?topic=2208.msg29095#msg29095）：直接往 IP 地址转账，看起来是个明显的攻击面。
你得先找到一个把它打开的人。它默认是关的。

引用自 witchspace（2010 年 12 月 11 日 09:59:40 AM）（https://bitcointalk.org/index.php?topic=2208.msg29124#msg29124）：没法绝对保证没有缓冲区溢出攻击。不过用一种没有缓冲区溢出、会检查数组下标的语言（Python、Java、C#……）实现客户端会有帮助。
全是 STL。几乎没有缓冲区。

英文原文

Quote from: da2ce7 on December 11, 2010, 05:49:22 AM（https://bitcointalk.org/index.php?topic=2208.msg29095#msg29095）direct to IP address transfers seems like a obvious surface area to attack.
If you ever find anyone who turned it on. It's disabled by default.

Quote from: witchspace on December 11, 2010, 09:59:40 AM（https://bitcointalk.org/index.php?topic=2208.msg29124#msg29124）There is no way to be absolutely sure that there are no buffer overflow attacks. Although it would help to implement the client in a language that doesn't have buffer overflows because it checks array indices (Python, Java, C#, ...).
It's all STL. There are almost no buffers.

Re: minimalistic bitcoin client on D language?

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: minimalistic bitcoin client on D language?

Date2010-12-11 22:07:04 UTC

ForumBitcointalk · 原文

引用自 Hal（2010 年 12 月 11 日 08:08:45 PM）（https://bitcointalk.org/index.php?topic=2188.msg29223#msg29223）：我想听听对代码的具体批评。在我看来这是个令人印象深刻的工作，虽然我希望注释多一点。现在我主要研究了 init、main、script 和一点 net 模块。这是套强大的机器。
这话从你嘴里说出来分量很重，Hal。谢谢。

英文原文

Quote from: Hal on December 11, 2010, 08:08:45 PM（https://bitcointalk.org/index.php?topic=2188.msg29223#msg29223）I'd like to hear some specific criticisms of the code. To me it looks like an impressive job, although I'd wish for more comments. Now I've mostly studied the init, main, script and a bit of net modules. This is some powerful machinery.
That means a lot coming from you, Hal. Thanks.

Re: PC World Article on Bitcoin

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleRe: PC World Article on Bitcoin

Date2010-12-11 23:39:16 UTC

ForumBitcointalk · 原文

但愿这种关注是在别的背景下到来的。维基解密捅了马蜂窝，蜂群正朝我们飞来。

英文原文

It would have been nice to get this attention in any other context. WikiLeaks has kicked the hornet's nest, and the swarm is headed towards us.

Added some DoS limits, removed safe mode (0.3.19)

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleAdded some DoS limits, removed safe mode (0.3.19)

Date2010-12-12 18:22:33 UTC

ForumBitcointalk · 原文

DoS 方面还有更多工作要做，但为防万一，我先把手头已有的快速构建一版，再去碰更复杂的想法。这个构建是 0.3.19 版。

- 加了一些 DoS 控制
正如 Gavin 和我之前明确说过的，软件对 DoS 攻击完全没有抵抗力。这是一处改进，但攻击方式还是多得数不过来。

-limitfreerelay 这部分我先留作开关，需要的话可以用。

- 去掉了“安全模式”警报
“安全模式”警报是 0.3.9 溢出 bug 之后的临时措施。我们可以说用户只管用 “-disablesafemode” 跑，但为了观感干脆不要它更好。它从来不是长期功能。看到更长（总工作量证明更大）的无效区块链时，安全模式仍可被触发。

构建：
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.19/

英文原文

There's more work to do on DoS, but I'm doing a quick build of what I have so far in case it's needed, before venturing into more complex ideas. The build for this is version 0.3.19.

- Added some DoS controls
As Gavin and I have said clearly before, the software is not at all resistant to DoS attack. This is one improvement, but there are still more ways to attack than I can count.

I'm leaving the -limitfreerelay part as a switch for now and it's there if you need it.

- Removed "safe mode" alerts
"safe mode" alerts was a temporary measure after the 0.3.9 overflow bug. We can say all we want that users can just run with "-disablesafemode", but it's better just not to have it for the sake of appearances. It was never intended as a long term feature. Safe mode can still be triggered by seeing a longer (greater total PoW) invalid block chain.

Builds:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.19/

Bitcoin open source implementation of P2P currency

Mon, 01 Jan 0001 00:00:00 +0000

AuthorSatoshi Nakamoto

TitleBitcoin open source implementation of P2P currency

Date2014-03-07 01:17:00 UTC

ForumP2P Foundation · 原文

我不是 Dorian Nakamoto。

英文原文

I am not Dorian Nakamoto.

-mempoolfullrbf 配置项默认值由 0 改为 1，Full RBF 成为默认 mempool 策略

Mon, 01 Jan 0001 00:00:00 +0000

项目	内容
日期	2024-08-05
首次发布	Bitcoin Core v28.0
合并 PR	#30493
合并提交	`902dd14`
影响范围	Mempool

事实摘要

PR #30493（标题 policy: enable full-rbf by default）把 -mempoolfullrbf 的默认值开启。该选项本身是 2022 年 7 月由 PR #25353 加入的，此前默认关闭。PR 说明给出的理由包括该选项已被常规使用、多数矿池已开启，以及开启后紧凑区块重构成功率明显更高。v28.0 release notes 的 Mempool Policy Changes 一节写明：该配置项默认值已从 0 改为 1，即 mempoolfullrbf=1，并标注 #30493。

关键链接

13F 里的比特币 ETF：季度申报能看到什么、看不到什么

Mon, 01 Jan 0001 00:00:00 +0000

2026-10-26 · 机构视角 · 配置与表述观察

2024 年 1 月美国现货比特币 ETF 上市之后，一个问题随之而来：到底哪些机构在买？媒体口径的"机构入场"大多无法核验，但有一个例外——Form 13F。这份按季度提交给 SEC 的持仓报告，是美国监管体系里唯一强制机构公开其证券持仓的文件。现货比特币 ETF 属于 13F 的申报范围，于是从 2024 年第一季度起，机构的比特币 ETF 持仓第一次有了官方记录。本文先交代这份文件的规则，再看首批披露，最后列清它结构性的盲区。

一、13F 机制：谁必须报、报什么、何时报

谁报。 依据《1934 年证券交易法》第 13(f) 条及 SEC 规则 13f-1，对"13(f) 证券"行使投资酌定权（investment discretion）且规模达到 1 亿美元的机构投资管理人，必须按季度提交 Form 13F。申报主体是管理人层面（一家资管公司合并申报其管理的账户），银行、保险公司、养老金、对冲基金与财务顾问公司都在其列。2024 年第一季度恰好是现货比特币 ETF 上市后的首个完整季度，截止日为 3 月 31 日。

报什么。 13F 报告的是季末持有 13(f) 证券的多头头寸：证券名称、股数与市值。13(f) 证券以 SEC 每季度公布的官方清单为准，主要是上市股票与 ETF，也包括部分上市期权（以看涨/看跌标注）和可转债。它不包括：空头头寸、场外衍生品、期货（CME 比特币期货不在此列）、现货比特币本身，以及未上市的信托份额等非清单证券。

何时报。 季末后 45 天内提交。也就是说，3 月 31 日的持仓最晚到 5 月 15 日才公开，期间发生的买卖完全不可见。申报还可以事后修订（13F-HR/A），个别头寸可申请保密处理、延迟公开。

这三点决定了 13F 的性质：它是一张季末时点的多头快照，不是资金流记录，更不是完整的方向账本。

二、首批披露：2024 年第一季度出现了谁

ETF 上市后的第一个申报季，截至 2024 年 5 月 15 日的截止日，共有数百家专业机构在 13F 中列示了现货比特币 ETF（Bitwise 当时统计的口径为 700 家以上）。其中金额最大、类型最具代表性的有以下三家。

2100 万：一个数字的协议含义

Mon, 01 Jan 0001 00:00:00 +0000

2026-10-22 · 第一性原理 · 原创

“2100 万"是比特币最广为人知的数字，也是被误解最多的数字。误解通常来自两个方向：要么把它当作刻在数学定理里的必然，要么把它当作随时可改的营销口号。本文先列出可核验的事实，再讨论这个数字到底意味着什么。

事实：白皮书里没有 2100 万

先说一个反直觉的事实：比特币白皮书正文从未出现"2100 万"这个数字。白皮书第六节"激励"只描述了发行机制——新币随每个区块产生、发行速率递减、最终过渡到手续费激励，但没有给出总量上限的具体数字。读者可自行核对白皮书公开版。

上限数字最早出现在中本聪的公开文字里，是 2009 年 2 月 13 日他在 P2P Foundation 论坛的回复：

"Circulation will be 21,000,000 coins. Transactions only transfer ownership."（流通量将是 2100 万枚；交易只转移所有权。）
——2009-02-13，P2P Foundation；归档

一年后他在 Bitcointalk 再次确认：“Eventually at most only 21 million coins for 6.8 billion people in the world if it really gets huge."（2010-02-06，归档）

至于这个数字怎么来的，中本聪在 2009 年给 Mike Hearn 的私人邮件里答得坦率：“Educated guess, and the maths work out to round numbers."（有依据的猜测，数学上凑得出整数。邮件 2024 年经 Hearn 公开，报道）

Bech32 地址全面支持合并（BIP-173）

Mon, 01 Jan 0001 00:00:00 +0000

项目	内容
日期	2017-09-29
首次发布	Bitcoin Core v0.16.0
合并 PR	#11167
合并提交	`8213838d`
影响范围	Wallet
相关 BIP	BIP-173

事实摘要

PR #11167 合入 Bech32 编解码与地址校验的完整支持，使节点与钱包能够识别、生成并向 bc1 开头的原生 SegWit 地址付款。Bech32 采用全小写字符集并带强校验和，口头传递与手工输入时更不易出错且能定位错误。该支持随 v0.16.0 发布，release notes 单列一节说明 BIP-173 地址支持。此后 Bech32 成为原生 SegWit 地址的标准编码。

关键链接

BIP-1

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-1
标题	BIP Purpose and Guidelines
作者	Amir Taaki <genjix@riseup.net>
指定日期	2011-09-19
类型	Process（协作流程）
状态	Closed（已关闭）
接替文档	Proposed-Replacement: BIP-2
阅读版	https://bips.dev/1
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki

二、放在哪一族

BIP-1 是流程族的起点，相当于比特币改进提案体系的“宪法初稿”：定义 BIP 是什么、分几类、怎么投稿、状态怎么流转、编辑做什么。

它已被 BIP-2（2016，Luke Dashjr）替换；现行流程是 BIP-3（Updated BIP Process，状态 Deployed）。分层分类规则见 BIP-123。

读 BIP-1 是为了理解整套提案制度从何而来，以及为什么：仓库收录 ≠ 社区背书 ≠ 已经激活。

三、它要解决什么

2011 年前后，比特币没有公司、没有产品负责人、也没有正式路线图。开发者越来越多，改动若只靠邮件列表和论坛口头传递，容易出现：

各家实现各写各的，互不兼容；
同一想法反复争论、没有统一留档；
后来的人不知道某项设计当初为什么被接受或被否决。

Amir Taaki 借鉴 Python 的 PEP（Python Enhancement Proposal），提出：把想法写成公开设计文档，编上固定编号，放进版本库。仓库里的修订历史，就是这份建议的完整历史记录。

BIP 被定位为三件事的主要机制：

提出新功能：用规范语言写清要改什么；
收集社区意见：公开讨论，作者负责争取共识，并记录反对意见；
记录设计决定：为什么选这条路、放弃了哪些替代方案。

作者（champion）负责推进共识；编辑只做行政与文字工作——编号、格式检查、入库——不当技术裁判，更不能强迫全网采用。

四、规则本身

4.1 三类 BIP

Standards Track（标准类 / 共识规则）

描述会影响大多数或全部比特币实现的改动，例如：网络协议变更、区块或交易有效性规则变更、影响应用互通性的任何新增或修改。SegWit、Taproot 等升级都属于这一脉络。标准类 BIP 由设计文档与参考实现两部分组成；在标为 Final 之前，必须提供实现（代码、补丁或指向实现的 URL）。

Informational（信息类 / 使用说明）

描述设计问题，或向社区提供一般性指南与信息，但不提出必须采用的新功能。信息不一定代表社区共识或推荐，用户与实现者可以忽略，也可以遵循。

BIP-10

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-10
标题	Multi-Sig Transaction Distribution
作者	Alan Reiner <etotheipi@gmail.com>
指定日期	2011-10-28
层级	Applications（应用）
类型	Informational（信息类）
状态	Closed（已关闭）
阅读版	https://bips.dev/10
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0010.mediawiki

二、放在哪一族

多签协作的“文件传递”这一族，与 BIP-11 分工不同：BIP-11 管的是哪种多签交易算标准交易、能被网络转发和打包；BIP-10 管的是链下协作——一笔需要多人签名的交易，怎么在参与方之间传递、补签、合并。

它也覆盖一个附带场景：普通 1-of-1 交易由离线电脑签名。签名设备不需要持有区块链，正是这份编码的设计目标之一。

三、它要解决什么

多签交易天生是多步协作：一笔被多个地址共同“锁定”的资金，花费时需要相关各方（或脚本要求的子集）逐一看到拟议交易并用各自私钥签名。必须有人提议如何分配这笔资金、收集齐签名、再广播完成的交易。

原文担心的是：多签一旦启用，功能与复杂度同时大增；若每个客户端各用一套传递与收集签名的流程，用户会被客户端选择割裂。提供一套高效、统一的编码，就是为了让实现它的程序彼此互操作，提高开发者采用兼容协议的机会。

另一个动机在离线签名：这套编码把验证与签名所需的全部信息都打包在内，签名方不需要访问区块链，因此可以做非常轻量的专用签名设备——只需极少的比特币工具加一个 ECDSA 模块。这一点让 BIP-10 的用处超出多签本身。

四、规则本身

4.1 流程：分发提案（TxDP）

原文为这套流程定了一组推荐术语，各实现应统一使用：

一方发起流程，创建 “Distribution Proposal”（分发提案，简称 DP 或 TxDP）。
创建者（preparer）按自己希望的花费方式构造交易，但把 TxIn 的脚本留空——那里将来放签名脚本。
提案同时附上所花费的未花费输出所在的完整交易（序列化后一并纳入）。原因是：被签名的数据包含前序交易哈希、却不包含金额；附上完整交易后，签名方可以核对该交易与 OutPoint 哈希相符、核对每个输入的金额，全程不需要区块链。
TxDP 有自己的 “DP ID”（也叫 Unsigned ID）：拟议交易在脚本留空状态下的哈希，用 Base58 表示。这个命名是特意定的，以免与广播后的真实交易 ID 混淆——真实 ID 要等所有签名集齐后才能确定，可称为 “Broadcast ID”。
TxDP 内含一份可无序排列的“签名—公钥”对列表，代表已收集到的签名。若你收到的 TxDP 只差你的签名，你签完即可广播。
内容相同、签名不同的多份 TxDP 可以轻易合并：发起方可以一次性把请求发给所有人，收回后逐一合并，而不必把文件在各方之间接力传递。
TxDP 若存成文件或用邮件发送，文件后缀应为 .txdp 或 .btcdp。

4.2 文本格式

编码借用了 PGP/GPG 的 ASCII 文本块风格：紧凑、在任何字符编码下解释一致，可以直接粘进邮件正文或存为文本文件；又比 PGP 多了一些人类可读的元素，不必借助程序也能大致人工查看。其骨架为：

BIP-100

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-100
标题	Dynamic maximum block size by miner vote
作者	Jeff Garzik <jgarzik@gmail.com>、Tom Harding <tomh@thinlink.com>、Dagur Valberg Johannsson <dagurval@pvv.ntnu.no>
指定日期	2015-06-11
层级	Consensus (hard fork)（共识（硬分叉））
类型	Specification（规范类）
状态	Closed（已关闭）
阅读版	https://bips.dev/100
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0100.mediawiki

二、放在哪一族

2015 年区块大小之争的硬分叉提案组，共五份，BIP-99 是它们的分类学序言，本篇居组首。同组分工：BIP-101（Gavin Andresen）主张按时间表自动增长——8MB 起步、每两年翻倍；BIP-102（同为 Jeff Garzik）退到最简的一次性 2MB；BIP-103（Pieter Wuille）按技术进步速率缓慢爬坡，年增 17.7%；BIP-104（Block75）按区块平均满载率自动调节。BIP-100 的独特性在于“谁决定”：它不预设任何增长曲线，把上限的决定权交给矿工逐期投票，其余四份则都把决定权交给事先写死的公式或一次性数字。BIP-101 原文也点名回应了本提案，指其实现更复杂、且“矿工直接控制上限”是优点还是缺点见仁见智。

三、它要解决什么

固定的 1,000,000 字节硬上限是静态的：链上生态长大，它不会跟着长；要改，只能再打一场硬分叉之争。原文 Motivation 的立论是：矿工直接承受上限变化的正负两面——块越大，链上生态越能生长；块越小，全网资源负担越轻——且矿工靠出块收入与整个生态相连，可充当其余参与者的高效代理（proxy）。因此与其由开发者定一个数，不如建一套确定性的投票系统，让上限随矿工的集体判断逐期演化，且在所有采用节点之间对上限的取值永不产生分歧。它与 emergent consensus（涌现共识）的区别也被点明：后者允许矿工接受任意大小的块，BIP-100 的矿工则受 75% 超多数规则与 5% 变动上限约束，并把涌现共识信号的数值也纳入计算。

四、规则本身

4.1 投票的编码

hardLimit（硬上限）初值为 1,000,000 字节。投票写在区块 coinbase 的 scriptSig 里，格式为 /BIP100/B[0-9]+/，数字单位为兆字节，例如 /BIP100/B8/ 表示主张上限 8,000,000 字节。细节照原文：coinbase 开头若按 BIP-34 编码了区块高度，忽略之；一串里只取第一个 BIP100 匹配；若无 BIP100 匹配，则取第一个涌现共识格式 /EB[0-9]+/ 作为票值。

BIP-101

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-101
标题	Increase maximum block size
作者	Gavin Andresen <gavinandresen@gmail.com>
指定日期	2015-06-22
层级	Consensus (hard fork)（共识（硬分叉））
类型	Specification（规范类）
状态	Closed（已关闭）
阅读版	https://bips.dev/101
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki

二、放在哪一族

2015 年区块大小之争的硬分叉提案组，背景分类见 BIP-99。同组对照：BIP-100 把上限交给矿工逐期投票；BIP-102 只做一次性 2MB；BIP-103 按年增 17.7% 的慢曲线爬到 2063 年；BIP-104 按满载率自动调节。BIP-101 是这组里步子最大、时间表最激进的一份：起点直接跳到 8MB，且以每两年翻倍的指数曲线增长——原文 Rationale 自述，部署方案借自 Jeff Garzik 的 BIP-100，但把上限决定方式从投票换成了可预知的日历。它后来成为 Bitcoin XT 推动的扩容路线核心，也是这场争论中知名度最高的一份文本。

三、它要解决什么

原文 Motivation 只有两句，要点是：网络交易量在持续增长，很快会撞上“每十分钟一兆字节”的 1MB 上限；提高上限，就是减轻这一上限对比特币采用与增长的压制。与 BIP-102 的“先解燃眉之急、免得反复争”不同，BIP-101 在“考虑过的其他方案”里明确批评一次性扩容：测试与部署的成本与长期方案一样高，而新上限一到顶，同样的争论还要再来一遍。因此它索性一步给出 20 年曲线。原文同时用整节篇幅正面回应反对意见——全节点减少、挖矿的带宽成本、大块攻击、UTXO 集年增约 100% 等——立场是：节点减少主因在轻钱包便利与设备形态迁移，扩容带来的采用增长反而能让网络分布到更多司法辖区；带宽在挖矿盈利方程中只是众多变量之一。

四、规则本身

4.1 增长曲线（按区块时间戳计算）

激活后，主网最大块大小由区块头的时间戳决定，照原文伪代码：

起点：2016-01-11 00:00:00 UTC（时间戳 1452470400）时为 8,000,000 字节；
此后每 63,072,000 秒（两年，不计闰年）翻倍一次；两次翻倍之间，按时间戳在段内线性插值增长；
到 2036-01-06 00:00:00 UTC（时间戳 2083190400）后封顶，最大值固定为 8,192,000,000 字节（即 8MB × 2^10）。

用时间戳而非高度的理由，原文写明：时间戳在每个区块头里，节点拿到区块头即可知该块的上限，不必等交易数据下载完。参数依据同样写在 Rationale 里：8MB 起点来自用参考实现实测大块、并听取带宽受限矿工（特别是防火墙后的中国矿工）的反馈；翻倍周期取自 CPU、存储与带宽的长期增长趋势；20 年封顶是因为指数增长不可能永远持续，若趋势中断，矿工共识可用软分叉把上限再收紧。

BIP-102

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-102
标题	Block size increase to 2MB
作者	Jeff Garzik <jgarzik@gmail.com>
指定日期	2015-06-23
层级	Consensus (hard fork)（共识（硬分叉））
类型	Specification（规范类）
状态	Closed（已关闭）
阅读版	https://bips.dev/102
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0102.mediawiki

二、放在哪一族

2015 年区块大小之争的硬分叉提案组，分类背景见 BIP-99。它是同组五份里刻意做到最简的一份，也与作者自己的另一份提案形成对照：Jeff Garzik 在 BIP-100 里主张上限由矿工投票逐期决定，到 BIP-102 则收成一个写死的数字、一次到位的改动。与 BIP-101 的 20 年指数曲线、BIP-103 跨 46 年的慢爬坡、BIP-104 的自动调节公式相比，它不回答“以后怎么办”：BIP-101 原文正是以此为由批评一次性方案——新上限一到，同样的争论就得重来。本篇的立场恰恰相反（见第三节）：先让网络完成一次硬分叉升级的演练，并维持当下的手续费与块空间经济政策。

三、它要解决什么

原文 Motivation 只列两条，照录其意：其一，延续当前的经济政策；其二，演练一次硬分叉网络升级（Exercise hard fork network upgrade）。Discussion 一节展开：短期看，需要一次扩容来维持手续费与块空间方面的现行经济政策、符合市场预期、防止市场紊乱；长期看，上限应当反映网络工程所能承受的最大值。换言之，它要解决的不只是“块不够大”，还包括“比特币从未认真做过一次有计划的硬分叉”——用最小幅度的改动，把升级流程本身走通一遍。这正是它在 BIP-99 框架里的位置：挑一个最可能达成无争议的变更，做无争议硬分叉的先例。

四、规则本身

全文规范只有三条，逐项照原文：

4.1 规范要点

在触发点把 MAX_BLOCK_SIZE 提高到 2,000,000 字节；
最大块 sigops 上限按相同倍数提高，保持 SIZE/50 的既有公式；
触发条件须同时满足：（1）区块时间到达旗日（flag day）当天的 00:00:00；（2）最近 1,000 块中 95% 已信号支持。

4.2 兼容性

原文 Backward compatibility 写明：全量校验的旧客户端与此变更不兼容；第一个超过 1,000,000 字节的块，会把旧客户端从新网络中分区出去。

BIP-103

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-103
标题	Block size following technological growth
作者	Pieter Wuille <pieter.wuille@gmail.com>
指定日期	2015-07-21
层级	Consensus (hard fork)（共识（硬分叉））
类型	Specification（规范类）
状态	Closed（已关闭）
阅读版	https://bips.dev/103
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0103.mediawiki

二、放在哪一族

2015 年区块大小之争的硬分叉提案组，分类背景见 BIP-99。五份提案里，它是增速最克制、论述最“立场化”的一份：BIP-100 交矿工投票、BIP-101 以每两年翻倍冲到 2036 年的约 8.192GB、BIP-102 一次性到 2MB、BIP-104 按满载率自动调节；BIP-103 则主张上限只能随技术进步的实测速率走，且在 Motivation 里直言扩容之争的前提需要检讨——手续费市场与适应块空间竞争的生态是健康的，不必用快速扩容去回避它。作者 Pieter Wuille 同时也是 BIP-101 所提的版本位机制的提出者，但在本篇里他给出的是全组最慢的一条曲线。

三、它要解决什么

原文 Motivation 的推理链条值得完整转述：人们希望比特币随时间扩容、承载更多链上交易，代价是中继节点的带宽、处理与存储，以及区块在网络中的传播速度；但技术本身也在进步——当所依赖的各项技术及其市场可得性都改善后，没有理由让比特币的基础交易速率不按比例改善。因此，扩容的正当尺度是“与技术增长同步”，而不是满足某种需求预期：任何放宽上限的硬分叉都无法保证满足全部、乃至某个特定需求（除非预期挖矿生态高度中心化），手续费市场的形成应视为健康。

更深一层，它反对以扩容换时间：比特币相对中心化系统的优势不在规模，而在透明与无需信任；用快速扩容买时间，等于回避这一现实。由此得出对硬分叉的总体态度——硬分叉力量极大，必须极负责任地使用，只应限于无争议变更，否则会侵蚀系统赖以成立的低信任预期；正因扩容之争已有争议，本篇刻意让改动渐进、且起点推到足够远的未来。

四、规则本身

4.1 上限函数

区块大小上限改为一个函数，输入是前 11 个块时间戳的中位数（median time past）：GetMaxBlockSize(pindexBlock->pprev->GetMedianTimePast())，sigops 上限按比例缩放。原文给出的代码要点，逐项核对如下：

第一步在 2017 年 1 月 1 日：在此之前（nMedianTimePast < 1483246800），上限仍为 1,000,000 字节；
此后每 2^23 秒（8,388,608 秒，约 97 天）上调一档：档位 step = (nMedianTimePast - 1483246800) >> 23，最多 175 档封顶；
每档乘以 2^(1/16) 倍（约 +4.4%）：代码用一张 16 项的基础表（从 1,044,274 到 2,000,000，即第一整年内逐档的上限值），取 bases[step & 15] << (step / 16)；
整体效果：2017 年 1 月至 2063 年 7 月之间，年增长 17.7%。

4.2 参数依据

Rationale 照原文：等 1.5 年再启动硬分叉，是为把风险降到最低（前提是它届时被证明无争议）；每档仅 4.4% 的小步，使市场或技术突变的风险最小化；17.7% 的年增速与近年带宽的平均增速一致，而带宽被视为瓶颈——若日后实际技术跟不上这一增速，意向是用软分叉再把上限收紧；用基于时间的检查，是因为实现简单、上下文需求少、高效且易于审查；用“前一块的中位过去时间”保证单调递增、且能提前知道每个块的上限，不依赖该块自身的时间戳。

BIP-104

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-104
标题	'Block75' - Max block size like difficulty
作者	t.khan <teekhan42@gmail.com>
指定日期	2017-01-13
层级	Consensus (hard fork)（共识（硬分叉））
类型	Specification（规范类）
状态	Closed（已关闭）
阅读版	https://bips.dev/104
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0104.mediawiki

二、放在哪一族

2015 年区块大小之争的硬分叉提案组，分类背景见 BIP-99；本篇定稿最晚（2017 年 1 月），是对这场争论的一个收尾式回答。它与同组的关系，正好构成“上限由谁决定”的完整光谱：BIP-100 交给矿工在 coinbase 里投票；BIP-101 交给预先写定的日历曲线；BIP-102 只给一个一次性数字；BIP-103 交给假定的技术增速。 BIP-104 的答案是：谁都不交——仿照难度调整，让上限成为对链上实际用量的自动响应。它在“考虑过的其他方案”里逐一点名否决了写死数字（2MB、8MB 等迟早重蹈覆辙）与矿工投票（复杂、政治化、人为介入使响应迟缓、权力集中于少数人），与 BIP-100 构成组内最直接的一组对照。

三、它要解决什么

原文 Motivation：区块已经太满，无法支撑交易量的进一步增长；SegWit 与 Lightning 等链下方案有帮助，但解决不了这个问题。比特币需要一种合理有效、可预知的上限管理办法：允许适度增长、让上限尽量小、并防止交易费的大起大落。论证的支点是难度调整——约每两周一次、全自动的难度重定目标已被证明合理有效且可预知，原因恰在于无人参与（除最初定下十分钟一个块的目标外），因而不政治、不惹争议，只是对网络资源变化的响应。原文由此推出结论：人同样不应参与最大块大小的决定；Block75 的目标，就是把上限管理做成与难度同构的永久性自动机制，目标值是让区块平均保持 75% 满。

四、规则本身

4.1 重算公式

上限每 2016 块（与难度同一节拍）重算一次，公式照原文：

new max block size = x + (x * (AVERAGE_CAPACITY - TARGET_CAPACITY))

其中：TARGET_CAPACITY = 0.75（目标满载率）；AVERAGE_CAPACITY 为前 2016 块的平均满载百分比（以小数表示）；x 为现行最大块大小。举例说，若上一周期平均满载 100%，新上限即放大 25%；平均只有 50%，则收缩 25%。所有生成、校验区块或引用现行硬编码上限的代码，都须改为支持 Block75 的动态值。

BIP-105

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-105
标题	Consensus based block size retargeting algorithm
作者	BtcDrak <btcdrak@gmail.com>
指定日期	2015-08-21
层级	Consensus (hard fork)（共识（硬分叉））
类型	Specification（规范类）
状态	Closed（已关闭）
阅读版	https://bips.dev/105
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0105.mediawiki

二、放在哪一族

2015 年区块大小之争中的“动态上限”一族。它和同期几份提案回答同一个问题——1MB 上限要不要动、由谁动：

BIP-100：由矿工投票决定动态区块上限——BIP-105 正是针对这类“免费投票”写出的修正方案

BIP-101：按预定时间表直接提高上限

BIP-106：按上一周期的实际块大小（与手续费）自动调控上限

BIP-107：先按时间表扩容、再转入按交易量动态上调

BIP-105 的特色是把投票做成“有代价的投票”：想把上限投大，先要多做工作量证明。它借用的记账位置来自 BIP-34（coinbase 中先压入区块高度）。

同族后来的 BIP-109 则放弃动态机制，回到一次性改数字。这一族最终都没有成为主网共识规则。

三、它要解决什么

3.1 固定时间表预测不了未来

原文担心：一旦比特币突然走红，交易量暴增，而协调一次硬分叉耗时很长，网络来不及响应会损害比特币的可信度。

反过来，预先排定的扩容表同样有问题——它在预测未来。若步子迈得太大，可能在区块补贴大幅下降的接下来九年里妨碍手续费市场形成、引入或放大矿工攻击向量，或以未知方式影响网络；而固定改动一旦部署又难以收回，损害可能很大。

3.2 免费投票可以被操纵

原文直接批评 BIP-100 式的自由投票：矿工可以在带外（off-band）出售选票而毫无风险，提案的发起方也能借此操纵区块大小；大矿池还能零成本地投票，用操纵上限的方式打压或攻击小矿池。

动态调整本身也有被算力大者操纵（gamed）的风险。BIP-105 要解决的核心，就是怎样让“调大”这件事变得有成本、难合谋乱投。

四、规则本身

4.1 投票方式

初始区块大小上限为 1MB。
矿工每出一块，可投票把区块大小上限提高或降低，最多为当前上限的 10%。
选票写在区块 coinbase 交易的 scriptSig 中：按 BIP-34，scriptSig 以压入区块高度开头，紧接着的下一次压入是一个小端序数字，表示该矿工偏好的区块大小（单位为字节）。原文给的例子是 2MB 与 10MB 的编码写法。
投当前大小，即表示投“不变”。

4.2 增票要付难度代价

若矿工投票提高上限，该区块的哈希必须达到一个按其所投增幅比例放大的难度目标——投得越大，难度要求越高。
若投票降低上限，则不需要达到更高的难度目标；反对增大的算力可以零成本投降票。
区块哈希若未达到其选票所要求的难度目标，该区块无效、将被拒绝。

设计理由是：给“增大”定价，矿工群体就只会在确有必要时才合谋增容；用难度作惩罚，比用固定比特币金额作成本更不可预测。

4.3 每 2016 块重定一次

每 2016 个区块，用过去 2016 个区块中全部选票的中位数重新计算区块大小上限，作为接下来 2016 个区块的上限。
超过计算出的基础上限的区块无效、将被拒绝。
基础上限不得低于 1MB，也不得高于 8MB。原文同时注明：上限的具体数字（8MB）还需要进一步讨论。

4.4 全节点保留最终控制

原文强调，协议层必须设硬顶，是为了让全节点保留对共识的控制——全节点正是约束矿工诚实运行的机制，不能让矿工对区块大小有完全控制权。

BIP-106

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-106
标题	Dynamically Controlled Bitcoin Block Size Max Cap
作者	Upal Chakraborty <bitcoin@upalc.com>
指定日期	2015-08-24
层级	Consensus (hard fork)（共识（硬分叉））
类型	Specification（规范类）
状态	Closed（已关闭）
阅读版	https://bips.dev/106
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0106.mediawiki

二、放在哪一族

2015 年区块大小之争中的“动态上限”一族，与 BIP-105、BIP-107 是近亲，但信号来源不同：

BIP-105：信号来自矿工付费投票，取中位数

BIP-106：不投票——信号直接来自链上已经发生的事实，即上一周期的实际块大小（第二方案再看手续费总额）

BIP-107：先按时间表扩容，之后按“块有多满”小步上调

原文在“考虑过的其他方案”中列出对照对象：Jeff Garzik 的 BIP-100、Meni Rosenfeld 的弹性区块上限（elastic block cap）、Gavin Andresen 的 BIP-101、Pieter Wuille 的 BIP-103，以及 Poon 与 Dryja 的闪电网络论文。它的立场是：上限应当像难度一样，能随需求自动升降。

三、它要解决什么

动机只有一条主线：采用率上升，交易量必然增长；若 1MB 上限不改成能随网络需求自我调整的弹性上限，采用就会受阻，比特币的增长会被“卡住”（choke up）。原文附了一张自创世以来的平均区块大小变化图作为背景。

与 BIP-105 担心“矿工投票可被操纵”不同，BIP-106 的出发点更简单：需求会自己体现在块的大小里，那就让上限跟着实际块大小走，不需要任何人表态。

四、规则本身

原文给出两个并列方案，二选一。

4.1 方案一：只看上一周期的块大小

考察上一个难度周期中前 2000 个区块的大小：

若其中超过 50% 的区块，其大小超过当时 MaxBlockSize 的 90%，则 MaxBlockSize 翻倍；
否则，若其中超过 90% 的区块，其大小低于当时 MaxBlockSize 的 50%，则 MaxBlockSize 减半；
其余情况，MaxBlockSize 不变。

设计类比难度调整：块持续接近上限说明需求真实存在，块普遍很空则上限下调，避免少数区块就扫空内存池。

BIP-107

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-107
标题	Dynamic limit on the block size
作者	Washington Y. Sanchez <washington.sanchez@gmail.com>
指定日期	2015-09-11
层级	Consensus (hard fork)（共识（硬分叉））
类型	Specification（规范类）
状态	Closed（已关闭）
阅读版	https://bips.dev/107
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0107.mediawiki

二、放在哪一族

2015 年区块大小之争中的“分阶段折中”方案。它与同族提案的差别在于不押注单一机制：

BIP-101：纯时间表扩容——BIP-107 的第一阶段借用了类似的时间表思路，部署方式也明言与 BIP-101 相同

BIP-105：矿工付费投票、中位数重定，上限可升可降

BIP-106：按上一周期实际块大小（与手续费）自动升降

BIP-107：先用几年时间表当“跑道”（runway），等网络与协议基础设施、第二层服务成熟后，再切换到只升不降的动态规则

原文称第一阶段类似 Adam Back 的提案：先给一段安全的保守扩容期，再进入动态阶段。

三、它要解决什么

3.1 两个相反的担忧要同时兼顾

原文列出未来几年预期中的大额基础设施投入：改善全球网络连接、改善区块传播、第二层链下服务与网络、交易与区块链的一般效率改进。在此背景下，它摆出两个必须精细平衡的担忧：

扩得太猛，可能加剧网络与挖矿中心化趋势（主要由 ASIC 等挖矿硬件驱动），进而威胁网络安全；
对链上交易量上升不作响应，则可能造成“消费级失败”：普通用户享受了六年多低成本链上交易后，会被 prohibitive 的“手续费市场”定价挤出区块链。

开发者、矿工、企业与用户之间对“需要扩容”已有共识，分歧在后果。BIP-107 的答案是分段处理：先小步、后自动，且自动阶段只进不退、步幅极小。

四、规则本身

4.1 第一阶段：时间表（2016–2020）

2016–2017 年：2MB
2018–2019 年：4MB
2020 年：6MB

这段“跑道”用来在切换到动态规则之前，缓解交易量压力，同时让网络与协议基础设施改进、第二层服务出现。

4.2 第二阶段：动态上调（2020 年起）

每 4032 个区块（约 4 周）做一次检查（CHECK），理论上一年最多触发 13 次上调。
若最近至少 3025 个区块达到或超过 60% 满，则最大区块大小提高 10%。
上限只能提高，永不下降。
默认的 limitfreerelay 也按最大区块大小提高的比例同步提高：无手续费交易可继续按常态提交与中继；这一参数也有助于抵消用“便士洪泛”（penny-flooding）触发扩容的尝试。

原文的算例：动态规则于 2020 年 1 月 1 日上线时，上限为 6MB；若至少 3025 个区块达到 3.6MB（即 60%），新上限变为 6.6MB；若 13 次上调在年内全部触发，2020 年底的理论最大上限约为 20.7MB。

BIP-109

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-109
标题	Two million byte size limit with sigop and sighash limits
作者	Gavin Andresen <gavinandresen@gmail.com>
指定日期	2016-01-28
层级	Consensus (hard fork)（共识（硬分叉））
类型	Specification（规范类）
状态	Closed（已关闭）
阅读版	https://bips.dev/109
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0109.mediawiki

二、放在哪一族

区块大小之争中“简单改数字”一派的收尾之作。同一作者 Gavin Andresen 此前写过 BIP-101（提高最大区块大小）；同期还有 BIP-102（扩容至 2MB）。BIP-105、BIP-106、BIP-107 都在设计动态机制，BIP-109 反其道而行：

不投票、不看链上指标、不分阶段——只做一次性的 1MB → 2MB；
真正花笔墨的地方不在数字，而在两个防攻击的配套上限：sigop 的准确计数与签名哈希总量上限；
部署上借用 BIP-9（version bits）的思路选信号位，但阈值从常见的 95% 降到 75%。

理解它，要把重点放在“扩容的同时怎样不让 2MB 区块变成 CPU 耗尽攻击的工具”。

三、它要解决什么

原文的动机只列三条，非常直白：

延续当前经济政策——短期内交易量在涨，先给链上容量留出余地；
演练一次硬分叉网络升级（Exercise hard fork network upgrade）——把硬分叉本身当作需要练习的治理动作；
缓解潜在的 CPU 耗尽攻击——区块变大后，若不限制签名运算与签名哈希的成本，恶意矿工可以构造验证代价极高的 2MB 区块拖慢全网。

第三条是它与 BIP-102 等单纯改数字提案的关键区别。

四、规则本身

4.1 区块大小：1,000,000 → 2,000,000 字节

规范序列化区块的最大字节数，从 1,000,000 提高到 2,000,000。一次改完，没有后续时间表或动态公式。

BIP-11

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-11
标题	M-of-N Standard Transactions
作者	Gavin Andresen <gavinandresen@gmail.com>
指定日期	2011-10-18
讨论日期	2011-10-02
层级	Applications（应用）
类型	Specification
状态	Deployed（已采用）
阅读版	https://bips.dev/11
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0011.mediawiki

二、放在哪一族

多签与标准交易族的早期关键文档。协议里早已有 OP_CHECKMULTISIG，但在 BIP-11 之前，这类交易属于“非标准”：多数节点不转发，矿工也未必打包，实际很难用。

BIP-11 把它推进为标准交易（在 n ≤ 3 的限制下）。后续演进包括：

BIP-13：P2SH 地址格式

BIP-16：Pay to Script Hash，把复杂脚本哈希进地址，多签更易用

再往后：SegWit、Taproot、描述符与现代多签钱包实践

理解 BIP-11，是理解“为什么比特币能做多人授权、托管、企业资金管控”的起点。

三、它要解决什么

3.1 受保护钱包（Wallet Protection Service）

采用 2-of-2：一把签名来自用户电脑上的钱包（可能已中毒），另一把来自钱包保护服务（WPS）。用户发起转账时，客户端把拟交易发给 WPS；WPS 再向用户确认“是否本人发起、金额与收款是否正确”，双方都签才生效。

文档特别提醒：用户应要求 WPS 提供所用私钥的备份，并离线安全保存，以免服务商倒闭后资金被锁死。客户端与 WPS 如何通信，不在本 BIP 范围内。

3.2 三方托管（买方、卖方、仲裁方）

采用 2-of-3：买方、卖方、可信仲裁人各提供一个公钥。买方把币打入 2-of-3 的 CHECKMULTISIG 输出，并把交易 ID 告知卖方与仲裁人。

履约顺利：卖方先签名，买方再联署，资金付给卖方；
发生争议：仲裁人与买方或卖方中的任一方合作，即可决定资金去向。

三方如何交换公钥与签名，同样不在本 BIP 范围内。

3.3 其他

凡是“赎回资金需要不止一个签名”的场景——公司资金需多人签字、共享账户、简单治理安排等——都可以落在 M-of-N 模型上。

核心障碍不在操作码（OP_CHECKMULTISIG 已存在），而在网络策略：非标准交易难以进内存池、难以被挖出。BIP-11 要做的，就是把限定条件下的多签交易升为标准类型。

BIP-110

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-110
标题	Reduced Data Temporary Softfork
作者	Dathon Ohm <dathonohm+bip@proton.me>
指定日期	2025-12-03
层级	Consensus (soft fork)（共识（软分叉））
类型	Specification（规范类）
状态	Closed（已关闭）
阅读版	https://bips.dev/110
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0110.mediawiki

二、放在哪一族

编号紧挨着 BIP-109，方向却正好相反。BIP-105 至 BIP-109 争论的是“区块能装多少交易”；BIP-110 问的是“区块里什么东西不该装”——它要临时收紧的是任意数据在交易各字段中的容身之处。

它是一份软分叉提案，规则大量援引后来的脚本体系：

BIP-16：P2SH，其 redeemScript 推送是规则 2 的唯一例外

BIP-141：隔离见证（共识层），定义了 witness v0 的合法形态

BIP-341：Taproot，定义 witness v1 与控制块（control block）

BIP-342：Taproot 脚本验证，定义 Tapleaf 版本 0xc0（Tapscript）

BIP-433：Pay to Anchor（P2A），是它承认的又一种已定义 witness 形态

与 BIP-114 对照看也很有意思：114 想把脚本树做大、做活，110 则在临时期内把 Taproot 控制块压到 128 个脚本叶子的规模——一个扩表达，一个收数据。

三、它要解决什么

3.1 任意数据嵌入被“标准化支持”后的激励扭曲

原文称，比特币社区历来对把任意数据嵌入交易的技术持对抗态度，因为一旦这种用法变得理所当然、开始“承重”（load-bearing），就会产生负外部性，尤其是压在节点运营者身上。

导火索是原文所称 2022 年开始被利用的 “inscription” 手法：把任意数据嵌入交易的趋势，给节点运营者带来显著的不必要负担，并把开发焦点与激励从“健全、无许可、无国界的货币”这一根本目的上引开。

3.2 它想达到的效果

在共识层临时使几种被认为危害最大的数据滥用方法失效，同时保留一切已知的货币用途；
具体说：使嵌入大于 256 字节的连续任意数据的一切方法失效；使主要被滥用于数据嵌入的大 scriptPubKey 与大 Tapleaf 形态失效；并在共识层恢复长期以来的 83 字节 OP_RETURN 策略上限；
以此传递信号：任意数据存储不会被当作受支持的用例，并改善节点网络的去中心化——原文的说法是让比特币“只做一件事，并把它做好”（do one thing, and do it well）。

原文也承认：垃圾信息（spam）主要仍应由策略（policy）层应对，策略无法保证 100% 有效、尤其防不住自己挖矿的作恶者，这份软分叉的作用是收住最坏情形。

BIP-111

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-111
标题	NODE_BLOOM service bit
作者	Matt Corallo <bip111@bluematt.me>；Peter Todd <pete@petertodd.org>
指定日期	2015-08-20
层级	Peer Services（对等服务）
类型	Specification（规范类）
状态	Deployed（已部署）
阅读版	https://bips.dev/111
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki

二、放在哪一族

P2P 网络服务宣告族，是 BIP-37 的补丁式扩展。BIP-37（Connection Bloom filtering，连接布隆过滤）让轻客户端把一个 BLOOM 过滤器交给全节点，节点只回传匹配的交易，从而省下轻客户端的带宽——但它当年没有定义任何服务位（service bit）。

BIP-111 补的正是这一位：节点先宣告“我提供过滤服务”，对等方再决定要不要向它发过滤器。它与同期的时间锁族（BIP-112、BIP-113）同在 2015 年 8 月前后定稿、编号相邻，但层面完全不同——那两份改共识，这一份只改节点之间如何自我介绍。

后来轻客户端过滤又演进出 BIP-157（客户端区块过滤）与 BIP-158（紧凑区块过滤器）：思路反过来，由节点提供紧凑过滤器、客户端在本地匹配。读 BIP-111，能看清 BLOOM 路线为什么需要先解决“谁愿意提供服务”这一步。

三、它要解决什么

3.1 BIP-37 默认“人人提供”，现实并非如此

BIP-37 没有规定服务位，等于隐含假设：所有向对等方提供数据的节点都支持连接过滤。

3.2 过滤的隐私与 DoS 问题

原文给出两个理由，说明这个假设站不住：

隐私：已发表的研究表明，BIP-37 的连接过滤算法提供的隐私很少、甚至没有；
拒绝服务风险：在某些节点上，连接过滤是一个很大的 DoS 风险点。原文脚注举了 2013 年 7 月 bitcoin-dev 邮件列表上的讨论为例，并链接了示例性的 DoS 利用代码。

结论是：允许节点运营者关掉连接 BLOOM 过滤，是一个非常需要的功能——而要让关闭成为可能，先得有一个办法把“提供/不提供”说清楚。这就是服务位的用途。

四、规则本身

4.1 新增服务位

NODE_BLOOM = (1 << 2)

支持 BLOOM 过滤的节点应当置起该位；不支持的，应当保持不置起。
NODE_BLOOM 与 NODE_NETWORK 相互独立、互不相同：宣告 NODE_BLOOM 而不宣告 NODE_NETWORK 是合法的（原文说目前这样做没什么道理，但未来的某些提案可能使之更有用）。
选用服务位，理由是“应用一个 BLOOM 过滤器”本身就是一项服务。

4.2 协议版本一并抬高

参考实现中，协议版本从 70002 提高到 70011。这样做是为了向后兼容：

BIP-112

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-112
标题	CHECKSEQUENCEVERIFY
作者	BtcDrak <btcdrak@gmail.com>；Mark Friedenbach <mark@friedenbach.org>；Eric Lombrozo <elombrozo@gmail.com>
指定日期	2015-08-10
层级	Consensus (soft fork)（共识（软分叉））
类型	Specification（规范类）
状态	Deployed（已激活）
阅读版	https://bips.dev/112
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki

二、放在哪一族

时间锁族的核心成员，与两份文档不可分开读：

BIP-68：用共识强制的序列号实现相对锁定时间——先给交易的 nSequence 字段赋予“相对锁定”的共识语义

BIP-112：再给脚本一个能检查这个字段的操作码

BIP-113：把锁定时间的判断端点改为过去时间中位数——三份文件在部署一节中互相写明，须用同一机制同时部署

它的前辈是 BIP-65（OP_CHECKLOCKTIMEVERIFY）：那是绝对时间锁，检查“现在是否已过某个时刻/高度”；BIP-112 是相对时间锁，检查“被花的输出是否已经够老”。原文的参考实现与文档大量建立在 Peter Todd 为 BIP-65 所做的工作之上；相对锁定的想法由 Mark Friedenbach 提出，他发明了用序列号实现相对锁定的方法并写了 CHECKSEQUENCEVERIFY 的参考实现。

在编号相邻的这一组里，BIP-110（数年后）与 BIP-114 反复引用本页的托管与 HTLC 例题——114 的例子正是把 112 的脚本拆成 MAST 分支。

三、它要解决什么

3.1 BIP-68 给了语义，脚本却够不着

BIP-68 把 nSequence 重新用作共识强制的相对锁定时间：未到龄的非最终（non-final）交易不能被选进区块。但脚本本身没有办法根据这个字段作决定——合约无法写出“这条路径要等输出确认满 N 个区块/一段时间之后才走得通”。

BIP-112 把 nSequence 交到脚本手里。由此可以构造这样的执行路径：时钟从证明已发布（proof-of-publication，即资金交易上链确认）那一刻才开始走，而不是在某个历法时刻预先定死。这为分阶段协议打开了空间：托管、支付通道、双向锚定（bidirectional pegs）等。

3.2 典型场景

带超时的托管：Alice、Bob 与托管方建 2-of-3 地址，赎回脚本一条支路是任意两人签名（随时可花），另一条支路是 “30d” CHECKSEQUENCEVERIFY 之后 Alice 单独签名——资金确认 30 天后，Alice 可独自取回。时钟从付款确认时才开始。
追溯撤销（功能等价）：区块链不可篡改，确认过的承诺无法真正撤回。但可以让一条路径被延迟、另一条路径在窗口期内凭“撤销条件”立即花费，从而在功能上模拟撤销：撤销条件迟迟不出现，延迟路径到期后按原合约执行。
哈希时间锁定合约（HTLC）：一条路径要求在撤销窗口内出示哈希原像，出示秘密即向对方保证该交易永不会被广播——因为对方可立即凭秘密 claim，而自己还要等窗口过去。
双向支付通道与闪电网络：相对锁定让一方在对方广播已撤销交易时，有一段可预期长度的响应时间；时钟从承诺交易确认那刻起算，通道不必像绝对锁定那样临近到期就关闭重开。具体构造见第四节末与原文例题。
双向锚定侧链：延时分支配合（不在本 BIP 范围内的）REORGPROOFVERIFY，让转回主链的提取在重组证明期过后才生效。

四、规则本身

4.1 重定义 NOP3

CHECKSEQUENCEVERIFY 重定义既有的 NOP3 操作码。执行时，只要下列任一条件为真，脚本解释器即终止并报错：

BIP-113

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-113
标题	Median time-past as endpoint for lock-time calculations
作者	Thomas Kerin <me@thomaskerin.io>；Mark Friedenbach <mark@friedenbach.org>
指定日期	2015-08-10
层级	Consensus (soft fork)（共识（软分叉））
类型	Specification（规范类）
状态	Deployed（已激活）
阅读版	https://bips.dev/113
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki

二、放在哪一族

时间锁族的“计时基准”文档。它自己不发明任何时间锁，只回答一个基础问题：判断“锁到期没有”时，应当拿什么时间来比？

BIP-65：OP_CHECKLOCKTIMEVERIFY，绝对锁定——原文说，本提案旨在保证锁定时间计算有可靠行为，正是 BIP-65 所需要的

BIP-68：相对锁定时间（序列号）

BIP-112：CHECKSEQUENCEVERIFY，脚本相对锁定

BIP-113：给上述按时间计的锁定统一换上中位过去时间（median time-past）这一端点，并与 BIP-68、BIP-112 用同一机制同时部署

想法来源上，原文致谢称：最初的想法由 Gregory Maxwell 于 2013 年 7 月 16 日在 #bitcoin-wizards 频道提出；Mark Friedenbach 设计并编写了参考实现，Thomas Kerin 撰写了本文档。

三、它要解决什么

3.1 区块时间戳并不可靠

当时的规则是：若当前时间或区块高度小于等于交易 locktime 所指定的值，该交易就被排除、不得进块。问题是共识规则并不强制区块时间戳严格有序排列。

3.2 由此产生的歪激励

原文点名这一后果：矿工有动机谎报自己区块的时间，以便把按墙上时钟（wall clock）判断其实尚未到期的时间锁定交易提前收进块里，多赚手续费（collect more fees）。

也就是说，拿单个区块自己的时间戳当裁判，这个裁判恰好由利益相关方填写。BIP-113 要换掉的正是这个裁判。

四、规则本身

4.1 新的端点：过去 11 个区块的中位数

交易 locktime 的数值本身不变，变的只是判断一笔交易能否进块时的计算方式。不再用不可靠的单个时间戳，而是用如下函数得出“当前区块时间”：

BIP-114

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-114
标题	Merkelized Abstract Syntax Tree
作者	Johnson Lau <jl2012@xbt.hk>
指定日期	2016-04-02
层级	Consensus (soft fork)（共识（软分叉））
类型	Specification（规范类）
状态	Closed（已关闭）
阅读版	https://bips.dev/114
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki

二、放在哪一族

脚本表达能力演进族，站在两步改革的延长线上：

BIP-16：P2SH——把赎回条件从 scriptPubKey 换成一个 20 字节哈希，花费时才由赎回者给出脚本，解决了“条件难指定、大脚本占 UTXO、发送方付费”三个问题

BIP-141：隔离见证（共识层）——P2WSH 把脚本移入 witness，恢复 10,000 字节脚本上限；本 BIP 明确依赖（depends on）BIP-141 部署

BIP-114：再进一步——P2SH 与 P2WSH 在花费时都必须公开脚本的全部分支，包括没有执行的那些；MAST 则只公开执行的一支

它的例题直接取自时间锁族：把 BIP-112 的带超时托管、HTLC 脚本“压平”为若干互斥分支，展示分支化之后的可读性与体积收益。思想来源上，原文致谢称 MAST 的想法来自 Russell O’Connor、Pieter Wuille 与 Peter Todd。

后来 Taproot 的脚本树（taptree，见 BIP-341）以不同机制实现了“只揭示所走的那一支”这一核心直觉；但那是另一套设计，不能与本提案混为一谈——本提案本身从未激活。

三、它要解决什么

3.1 原始脚本模型的五个问题

原文回顾了比特币脚本系统的演进，并列出原始设计对复杂脚本的不足：

接收方难以指定赎回条件；
大脚本占用更多 UTXO 空间；
追加的区块空间由发送方付费；
为防 DoS，脚本被限制在 10,000 字节、201 个操作码以内；
脚本中未执行的分支、以及非共识强制的数据，对全网公开，既占区块空间，又损害隐私。

BIP-16 修好了前三条，但受脚本中数据推送 520 字节上限约束，P2SH 脚本不能超过 520 字节，且花费时仍须公开全部未执行分支。BIP-141 的 P2WSH 把上限恢复回 10,000 字节，但同样要公开未执行分支。

BIP-115

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-115
标题	Generic anti-replay protection using Script
作者	Luke Dashjr <luke+bip@dashjr.org>
指定日期	2016-09-23
层级	Consensus (soft fork)（共识（软分叉））
类型	Specification（规范类）
状态	Closed（已关闭）
阅读版	https://bips.dev/115
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0115.mediawiki

二、放在哪一族

脚本防重放与链分裂应对族。它和时间锁族相邻但不同：BIP-65 的 OP_CHECKLOCKTIMEVERIFY、BIP-112 的 CHECKSEQUENCEVERIFY 约束的是“什么时候能花”，BIP-115 约束的是“在哪条链上能花”——把某个具体区块的哈希钉进花费条件。

它的做法沿用了软分叉的经典手法：重定义一个 OP_NOP 占位操作码（这里是 OP_NOP5），部署方式计划用 BIP-9 的 version bits，部署名写作 “cbah”，但原文中起始时间、超时时间与 bit 位均为 TBD（待定），从未定稿。

与它同属“让脚本能检查链上既有事实”思路的，还有后来的各类内省（introspection）与契约（covenant）提案；BIP-115 是其中较早、目标非常聚焦的一个：只查一个区块高度对应的哈希，不引入通用计算。

三、它要解决什么

3.1 从双花中安全恢复

用户有时会在收款交易尚未确认时就把币花出去（Tx B1）。如果那笔收款交易（Tx A1）被双花，钱包必须改发一笔新的支出交易（Tx B2）。

若双花的版本（Tx A2）仍然付给该钱包，问题不大：换掉输入指向、重新签名即可。但若 Tx A2 根本不付给该钱包，钱包只能在 Tx B2 里改花别的、不冲突的 UTXO——攻击者随后可以重组链、把 Tx A1 的双花再翻回来，使 Tx B1 与 Tx B2 两笔同时确认，钱包被坑两次。

有了 OP_CHECKBLOCKATHEIGHT，钱包发 Tx B2 时可以附加条件：确认 Tx A2 的那个区块必须在本链历史中。这样重组翻转后 Tx B2 自动失效，风险被消除。

BIP-116

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-116
标题	MERKLEBRANCHVERIFY
作者	Mark Friedenbach <mark@friedenbach.org>, Kalle Alm <kalle.alm@gmail.com>, BtcDrak <btcdrak@gmail.com>
指定日期	2017-08-25
层级	Consensus (soft fork)（共识（软分叉））
类型	Specification（规范类）
状态	Draft（草案）
阅读版	https://bips.dev/116
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0116.mediawiki

二、放在哪一族

MAST（默克尔化抽象语法树）与合约脚本族的前身一族。传统写法是把合约的全部花费条件枚举进一个脚本，花费时靠 witness 里的选择值穿过一串 if/else；BIP-16（P2SH）与 BIP-141（SegWit）能把脚本推迟到花费时才揭示，但仍要揭示全部条件。

BIP-116 给出另一半拼图：用默克尔树承诺一整组数据元素，花费时只出示用到的元素与分支证明。它自己只管“证明某个元素在集合里”，不管执行代码；与它同日提出、同作者的 BIP-117（尾调用语义）负责把选出的策略脚本真正执行起来，两者合起来构成一种广义 MAST。这一思路与显式 MAST 方案 BIP-114 目标相同、路径不同；BIP-119（OP_CHECKTEMPLATEVERIFY）则是同一时期另一条契约路线——用模板哈希直接约束下一笔交易的形态。

它依赖的快速默克尔树构造来自 BIP-98，刻意不用中本聪为区块头设计的那种默克尔树（见 4.3）。

三、它要解决什么

3.1 全部条件必须全揭示

既有合约写法的通病：所有执行路径都必须写进 scriptPubKey 或赎回脚本，哪怕花费时根本用不到。后果有三层：

浪费链上空间，脚本还受压入（push）大小上限限制，复杂合约根本写不下；
隐私受损：未用到的策略条件往往带有用户特征，花费一次就全曝光；
可互换性（fungibility）受损：外人能从完整条件集分辨这枚币的来历与用途。

3.2 只承诺、按需揭示

改用默克尔哈希树承诺全部策略选项，花费时只强制揭示实际用到的那一条，未用部分继续保持隐藏。泄露最少，链上负担也最少。

同时，脚本大小与运行限制从此只约束“单条被用到的策略”，而不是所有策略之和——可行的合约复杂度因此大幅上升。

四、规则本身

4.1 操作码与栈布局

MERKLEBRANCHVERIFY 重定义 OP_NOP4。执行时若出现以下任一情形，脚本报错终止：

栈少于 3 项；
栈顶第一项超过 2 字节；
第一项按整数解释（记为 N）为负数或非最小编码；
第二项不是恰好 32 字节（即所承诺的默克尔根）；
第三项不是按 BIP-98 序列化的默克尔树包含证明，且其所需 VERIFY 哈希个数不等于 floor(N/2)；
栈中剩余元素少于 floor(N/2) 个——这些就是待验证的输入元素。

4.2 验证方式

N 的最低位决定输入元素如何变成 VERIFY 哈希：最低位为 0 时，每个输入元素用双重 SHA256 哈希；最低位为 1 时，每个元素必须恰好 32 字节，直接当作已算好的哈希。

BIP-117

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-117
标题	Tail Call Execution Semantics
作者	Mark Friedenbach <mark@friedenbach.org>, Kalle Alm <kalle.alm@gmail.com>, BtcDrak <btcdrak@gmail.com>
指定日期	2017-08-25
层级	Consensus (soft fork)（共识（软分叉））
类型	Specification（规范类）
状态	Draft（草案）
阅读版	https://bips.dev/117
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0117.mediawiki

二、放在哪一族

脚本执行语义与广义 MAST 族。它是 BIP-116（MERKLEBRANCHVERIFY）的姊妹提案，同日、同作者：BIP-116 负责证明“被选出的策略脚本确实在承诺集合里”，BIP-117 负责在证明之后把这个脚本真正跑起来。

上游基础是 BIP-16（P2SH）与 BIP-141（SegWit）：两者都能在花费时才揭示脚本，但每个输出只能承诺一个脚本。对照方案是显式 MAST 的 BIP-114——它靠 BIP-141 的脚本版本机制激活专门的 MAST 构造；116+117 的路线则主张只用脚本本身完成成员验证与跳转，所需的共识改动少得多，也为日后纯脚本层面的创新留了口子。

三、它要解决什么

3.1 一个输出只能承诺一个脚本

P2SH 与 SegWit 解决了“脚本不必提前公开”，但没有解决“策略不止一种”：无论最终用哪条路径花费，全部策略都必须塞进同一个脚本里揭示。合约越复杂，脚本越大，未用路径的隐私泄露也越严重。

3.2 让赎回脚本自己算出要执行的策略

本提案的思路是推广既有做法：赎回脚本可以先做任意计算，把最终要执行的策略脚本放到栈顶，再由执行语义把它当作子脚本运行。配合 BIP-116，流程是：预先把合约的所有可能执行路径枚举、压平为互不分支的策略脚本，哈希进一棵默克尔树；花费时只出示用到的那条路径，用 MERKLEBRANCHVERIFY 证明它在树中，然后尾调用执行它。这就是原文所说的广义 MAST。

四、规则本身

4.1 尾调用的触发条件

脚本执行结束时，若同时满足：

执行状态不是“干净”的——主栈多于 1 项，或主栈恰有 1 项但 alt 栈非空；
主栈栈顶元素按布尔解释为真；
栈顶元素不是单字节、或不在 0x51 至 0x60 的闭区间内，

则把栈顶元素弹出、解释为序列化脚本并执行它；主栈与 alt 栈的其余元素原地保留，作为该子脚本的输入。子脚本终止，整个脚本随之终止——执行不返回调用方，这正是“尾调用”。

4.2 单字节的特殊情形：分片拼接

若栈顶恰是 0x51（OP_1）至 0x60（OP_16）范围内的单字节，则它表示 N＝2 至 17：从主栈（不够时续接 alt 栈）再弹出 N 个元素，按逆序拼接成一个序列化脚本再执行。此举是为了绕开单个压入 520 字节的上限，把大脚本分片带进来。原文据此算得：每个输入可用的最大脚本规模为 10000＋17×520＝18840 字节。

BIP-118

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-118
标题	SIGHASH_ANYPREVOUT for Taproot Scripts
作者	Christian Decker <decker.christian@gmail.com>, Anthony Towns <aj@erisian.com.au>
指定日期	2017-02-28
层级	Consensus (soft fork)（共识（软分叉））
类型	Specification（规范类）
状态	Draft（草案）
前置依赖	BIP-340, BIP-341, BIP-342
阅读版	https://bips.dev/118
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki

二、放在哪一族

签名哈希（sighash）与链下协议族。它源于闪电网络论文中提出的 SIGHASH_NOINPUT 想法（由 Joseph Poon 于 2016 年 2 月正式提出），后改名为 ANYPREVOUT，以表明“任意前一输出可用、但输入的其他方面仍有承诺”。

它建立在 Taproot 三件套之上：BIP-340（Schnorr 签名）、BIP-341（Taproot 输出规则）、BIP-342（Tapscript 验证）。原文明确它只支持脚本路径花费，不支持密钥路径花费。

与同族提案的关系：BIP-119（OP_CHECKTEMPLATEVERIFY）能用模板哈希达到部分相似效果，原文专门比较过——ANYPREVOUTANYSCRIPT 可与 SIGHASH_SINGLE、SIGHASH_ANYONECANPAY 组合、允许动态找零输出，但需要签名运算；CTV 只需哈希运算、脚本更短，且能承诺输入个数与序号。两者常被放在同一张“契约工具”清单里对照，但机制互不依赖。

三、它要解决什么

链下协议靠一批尚未广播的交易互相博弈：先约定好“链上出现某笔交易时，就用另一笔预定交易回应”。问题是，回应交易里的签名默认承诺了被花费的确切 UTXO（outpoint）。同一回应要能应对多种可能的链上交易，就得为每一种可能各签一份——组合一多，签名与存储负担爆炸。

原文的解法：让签名不承诺具体的前一输出。同一份签名可以动态重绑定到另一个由同一密钥授权、条件兼容的 UTXO 上，一份签名覆盖一族情形。典型应用是 eltoo 式的链下状态更新：后签的状态要能压过先签的状态，而结算交易又要精确对应某一份更新——原文脚注用这一例说明了“为何有时要承诺脚本、有时不要”。

这种重绑定是选择性加入的：只有使用专门的 BIP 118 公钥类型的脚本才有此能力；还可以用不同密钥、让签名承诺所花脚本、使用不同金额、不同 nSequence 或 OP_CODESEPARATOR 等手段，进一步收窄一份签名可被重绑定的范围。

四、规则本身

4.1 BIP 118 公钥

通过 BIP-342 为“未知公钥类型”预留的软分叉口子引入新公钥类型，无需新操作码：

公钥恰为单字节 0x01 时，指 Taproot 内部密钥本身；
公钥为 33 字节且首字节为 0x01 时，去掉前缀，余下 32 字节即实际公钥。

这类公钥称为 BIP 118 公钥。对它使用 CHECKSIG、CHECKSIGVERIFY、CHECKSIGADD 时，不再按未知类型（非空签名即算通过）处理，而是按下列修改后的摘要规则验证。

BIP-119

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-119
标题	CHECKTEMPLATEVERIFY
作者	Jeremy Rubin <j@rubin.io>
指定日期	2020-01-06
层级	Consensus (soft fork)（共识（软分叉））
类型	Specification（规范类）
状态	Draft（草案）
阅读版	https://bips.dev/119
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki

二、放在哪一族

契约（covenant）族的核心提案：脚本第一次能约束“这枚币下一步必须变成什么样”，而不只是“谁能花”。它的前身是只承诺输出哈希的 OP_CHECKOUTPUTSHASHVERIFY，因不承诺版本号与锁定时间而不安全，已被本提案取代；它也曾被叫作 OP_SECURETHEBAG。

谱系上，它与 BIP-116／BIP-117 的 MAST 路线都着眼于让脚本表达更强的花费条件，但手段不同：那一族是“承诺一组策略、按需揭示并执行”，BIP-119 是“承诺一笔未来交易的确切模板、花费时逐字段核对”。与 BIP-118（SIGHASH_ANYPREVOUT）的关系原文专门论述：ANYSCRIPT 模式能用预签签名模拟模板，但 CTV 限制更死（输入个数、找零方式都被钉住）、只需哈希运算、脚本更短，且为未来模板升级（如 OP_TXHASH 一类设想）留了路径。原文还指出，OP_VAULT、OP_CHECKCONTRACTVERIFY、OP_TXHASH 等后续提案在其当前设计中都把 CTV 作为组成部分。

部署手法沿用先例：重定义一个 OP_NOP（这里是 OP_NOP4），与 BIP-65、BIP-112 改写 OP_NOP 语义的方式相同。

三、它要解决什么

3.1 预签名的三大成本

在没有契约原语时，想预先定好一枚币的去向，只能预签交易。原文指出这带来三类成本：

信任：预签交易要交给某方保管，保管方可能丢失或滥用；
交互：多方场景里，每换一种情形就要多方再签一轮；
存储：所有可能情形都要事先签好存好，情形一多就不可收拾。

3.2 把“去向”写进输出本身

OP_CHECKTEMPLATEVERIFY 引入交易模板：一种简单的花费限制，把实际花费交易与一个哈希化的交易规格做模式匹配。去向直接由脚本强制，不再依赖任何人保管签名——想按别的样子花，验证直接失败。原文列举的应用方向包括金库（vault）、支付池、拥堵控制、批量创建通道以及离散对数合约（DLC）等，具体构造见原文参考文献。

四、规则本身

4.1 操作码语义

OP_CHECKTEMPLATEVERIFY 使用 OP_NOP4（0xb3）。执行规则：

栈为空，失败；
栈顶元素不是 32 字节时，按 NOP 处理（共识层面）；推荐的标准性规则对此类用法以 SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS 拒绝，为未来给其他长度赋义留路；
栈顶元素为 32 字节时，计算当前交易在当前输入序号下的 DefaultCheckTemplateVerifyHash，与栈顶不相等则失败；相等则按 NOP 继续。

最常见的裸形式是 34 字节脚本：0x20 <32 字节哈希> OP_CHECKTEMPLATEVERIFY。

BIP-12

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-12
标题	OP_EVAL
作者	Gavin Andresen <gavinandresen@gmail.com>
指定日期	2011-10-18
层级	Consensus (soft fork)（共识（软分叉））
类型	Specification（规范类）
状态	Closed（已关闭）
阅读版	https://bips.dev/12
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0012.mediawiki

二、放在哪一族

P2SH（pay-to-script-hash）设计竞赛的最初一案。BIP-13 在参见中把 BIP-12 标为 “the original P2SH design”；后来实际部署的是 BIP-16 的方案，另一竞争设计是 BIP-17 的 OP_CHECKHASHVERIFY。

它与 BIP-11 是同一时期的姊妹提案：BIP-11 先把多签定为标准交易，BIP-12 则试图更进一步，让任意复杂脚本都能藏进一个哈希里收款。读它是为了理解 P2SH 为什么最终没有选“执行数据”这条路。

三、它要解决什么

动机只有一句：启用“端到端”的安全钱包，以及向托管交易或其他复杂交易付款的方式，同时对旧客户端与旧矿工保持向后兼容。

问题在于旧有模式：付款方在付款时就必须知道这笔钱日后该如何赎回的全部细节。若收款条件是复杂的多签或托管脚本，付款方要构造冗长的脚本，体积与手续费成本也都压在付款一侧。

BIP-12 想把方向倒过来：由收款方指定日后花费这笔钱所需的交易类型，付款方只面对一个脚本哈希和一种新地址。

四、规则本身

4.1 OP_EVAL 的语义

OP_EVAL 重新定义既有的 OP_NOP1 操作码，执行时：

从栈顶弹出一个元素，将其反序列化为脚本并执行；
栈顶无元素、或该元素不是合法脚本，交易验证失败；
被反序列化的脚本中若含有 OP_CODESEPARATOR，验证失败；
被求值的脚本中若再出现 OP_EVAL，也会执行，但递归深度限制为 2；
若把 OP_EVAL 当作空操作（no-op）来解释会导致验证失败，则该交易验证必须失败——这是防止新旧客户端判断分叉的关键约束（见 4.4）。

4.2 新的标准交易类型

与操作码配套，定义一种会被客户端转发、会被矿工打包的标准锁定脚本：

DUP HASH160 {20-byte-hash-value} EQUALVERIFY OP_EVAL

其解锁脚本为：

...signatures... {serialized script}

即赎回时给出签名与被序列化的脚本本身，节点先核对脚本的哈希与锁定脚本中的哈希一致，再用 OP_EVAL 执行该脚本。只有当这个被序列化的脚本本身属于标准交易类型之一时，花费 OP_EVAL 输出的交易才算标准交易。

BIP-120

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-120
标题	Proof of Payment
作者	Kalle Rosenbaum <kalle@rosenbaum.se>
指定日期	2015-07-28
层级	Applications（应用）
类型	Specification（规范类）
状态	Closed（已关闭）
阅读版	https://bips.dev/120
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0120.mediawiki

二、放在哪一族

应用层的支付凭证族。它与 BIP-70（支付协议）相邻：支付协议解决“怎么付得明白”，BIP-120 解决“付完之后怎么向第三方证明我付过”。

它还有一个配套文档：请求如何送达钱包，由 BIP-121 的 btcpop: URI 方案单独规定，本 BIP 只管证明本身的数据结构、流程与验证。更早的替代思路——用付款私钥签服务器指定的消息——没有被标准化，也难以覆盖 P2SH 等脚本类型；本提案刻意把证明做成一笔“交易形状”的对象，好让各种脚本类型一视同仁。

三、它要解决什么

3.1 付款之后需要一张“收据”

原文列举的场景都指向同一件事：付款本身即凭证，不必再引入用户名、密码、邮箱等个人信息——

预付费酒店房间：付款证明就是房门钥匙；
在线视频租赁：在任何设备上凭证明观看已付费的视频；
广告牌：预付两周期限内，凭证明随时更新内容；
付费网站登录、按月付费的停车场（由汽车自动出示证明）、彩票（所有人付到同一地址，中奖者凭中奖交易的证明领奖）。

3.2 当时办法为什么不够

原文盘点了既有做法。BIP-70 的 PaymentRequest 加上履行它的交易勉强算证明，但只能用于经 BIP-70 付的款，且没有标准的请求／出示方式。用付款私钥签消息可以按需生成、防复用，但未标准化，且难以覆盖所有脚本类型。

原文为付款证明定下五条目标性质：按需生成；只能用一次（防被盗后复用）；对任何脚本类型的付款都能生成（P2SH、P2PKH 等）；能证明持有解锁原交易全部输入所需的凭证；钱包与服务器都容易实现。

对多签还有一条细则：P2SH 的 M-of-N 只要求任一组合法的 M 把密钥即可，不必是当初实际签名的那 M 把——否则多签的意义就被证明环节抵消了。

四、规则本身

4.1 PoP 的数据结构

交易 T 的付款证明 PoP(T) 与一笔比特币交易结构完全相同：输入与 T 相同、同序，但每个输入的 sequence 号一律置 0；输出恰好一个，金额为 0，格式为：

OP_RETURN <version> <txid> <nonce>

其中 version 为 2 字节小端（当前为 0x01 0x00），txid 为 32 字节的被证明交易，nonce 为 6 字节随机数据。

BIP-121

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-121
标题	Proof of Payment URI scheme
作者	Kalle Rosenbaum <kalle@rosenbaum.se>
指定日期	2015-07-27
层级	Applications（应用）
类型	Specification（规范类）
状态	Closed（已关闭）
阅读版	https://bips.dev/121
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0121.mediawiki

二、放在哪一族

应用层的 URI 方案族，是 BIP-120（Proof of Payment）的配套传输层。BIP-120 明确把“请求如何送达钱包”留给单独规范，BIP-121 就是那份规范。

它的骨架直接沿用比特币支付链接 BIP-21：同样的查询参数风格、同样的 UTF-8 与百分号编码规则、同样的扩展规则，只是换了 scheme 与必填参数。同族还有为区块链引用设计的 BIP-122（blockchain: 方案），两者都是“用一条链接把意图递给用户自己的钱包／工具”的思路。

三、它要解决什么

BIP-120 的流程第一步是：想验证付款的一方把 PoP 请求送到付款人的钱包。请求里有回送地址、一次性 nonce、以及定位交易的提示——这些信息怎么递过去，需要一个钱包能统一识别的载体。

本提案的答案是 URI：把请求编码成一条 btcpop: 链接，可以印成二维码让钱包扫，也可以经 NFC 传递。钱包一打开链接，就知道要为哪笔付款生成证明、把证明发到哪里、用哪个 nonce。

四、规则本身

4.1 与 BIP-21 的四点差异

规范主体与 BIP-21 相同，差异只有四处：

scheme 是 btcpop，不是 bitcoin；
路径部分（地址部分）恒为空；
必填参数 p：PoP 的回送目的地，例如一个 https: URL 或一个 mailto: URI；
必填参数 n：nonce，Base58 编码。

可选参数 txid 给出要证明的交易哈希，同样用 Base58 编码。除 p 与 n 外，所有参数都只是帮钱包定位交易的提示。BIP-21 的可扩展性同样适用（例如将来可加 date、toaddr 参数）；req- 前缀参数的规则不变：钱包不支持某个 req- 参数时，必须视该 URI 为无效。

BIP-122

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-122
标题	URI scheme for Blockchain references / exploration
作者	Marco Pontello <marcopon@gmail.com>
指定日期	2015-08-29
层级	Applications（应用）
类型	Specification（规范类）
状态	Draft（草案）
阅读版	https://bips.dev/122
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0122.mediawiki

二、放在哪一族

应用层的 URI 方案族，与支付用的 BIP-21（bitcoin:）、付款证明请求用的 BIP-121（btcpop:）并列，但用途正好错开：那两者是“发起动作”，BIP-122 是“引用与查看”——它不要求付款、不要求证明，只表达“我想看这条链上的这个对象”。

它指向的对象是区块链浏览器（explorer）与本地工具，而不是某个具体网站。这与 BIP-120、BIP-121 一样同出 2015 年那批应用层小规范，原文的讨论出处是 2015 年 8 月的 bitcoin-dev 邮件列表。

三、它要解决什么

原文指出的痛点很具体：用户想看一笔交易或一个区块的详情时，客户端通常随手指给一个区块链浏览器，或者给一列备选让用户挑；帖子与消息里引用某笔交易、某个区块时也常常根本不给链接。大量时候，用户只能复制哈希再粘贴到浏览器里——在移动设备上尤其别扭。

统一的 blockchain: 链接把选择权交回用户：引用方只管写标准链接，用户点开时由自己偏好的工具（网页服务或本地应用）接管。钱包等工具的开发者也不必再为“接哪家浏览器”操心，更不必给用户维护一列备选。

四、规则本身

4.1 URI 形式

blockchain:[//<chain>]/<tx|block|address>/<hash>

chain：可选。目标链的 chain ID（见 4.2），含前导零；省略时默认比特币主网；
type：必填，三选一——tx 表示交易，block 表示区块（哈希或高度均可），address 表示地址；
hash：必填，所引用对象的哈希（含前导零），区块也可以给高度。

原文给出的 ABNF 文法为：

blockchainuri = "blockchain:" ["//" chain] "/" object
object = ("tx" "/" hash) / ("block" "/" (hash / blockheight)) /
         ("address" "/" address)
chain = hash
hash = 64HEXDIG
blockheight = 1*15DIGIT
address = base58

4.2 chain ID 如何定义

一条链的 chain ID 是其创世区块的区块哈希；分叉链则用分叉后第一个区块的哈希。原文给出的例子：比特币主网为 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f，测试网为 000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943，regtest 为 0f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206。这样任何链（包括从其他链分叉出去的链）都有天然唯一、不用注册的标识。

BIP-123

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-123
标题	BIP Classification
作者	Eric Lombrozo <elombrozo@gmail.com>
指定日期	2015-08-26
类型	Process（流程类）
状态	Deployed（已部署）
阅读版	https://bips.dev/123
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0123.mediawiki

注：本 BIP 原文没有 Layer 字段——它定义的正是“层”本身；本站按其流程类属性归入流程层。

二、放在哪一族

BIP 流程与分类族，是给所有 BIP 贴“系统层”标签的元文档。BIP-1 定下了提案的类型（标准类／信息类／流程类）与流程，现行流程由 BIP-3 承接；BIP-123 补的是另一维：每份标准类 BIP 属于哪个系统层。

这一维至今写在每份新 BIP 的文件头里（Layer 字段）。本档案站每篇解读“档案卡”中的层级、以及 lede 开头的“共识层（软分叉）”“应用层”等字样，用的就是这套分类：例如 BIP-115 至 BIP-119 标为 Consensus (soft fork)，BIP-120 至 BIP-122 标为 Applications，都是按本 BIP 的定义归层的。

原文末尾还附了一张当时已有 BIP 的分类总表，把 1 号到 152 号之间的提案逐一归层（该表状态为当时的快照，如其中 BIP-1 仍标 Active、不少后来定稿的提案仍标 Draft；现行状态以仓库为准）。

三、它要解决什么

比特币不是单一标准，而是一叠标准：有些是互操作不可缺的绝对要求，有些是可选的，实现者可以自行取舍。若不加区分地走同一套提案流程，轻重缓急全被抹平——改一行应用约定的文档，和改共识规则的文档，看起来分量相同，实际风险与推广难度天差地别。

原文的出发点是：让 BIP 流程更贴合各自的互操作要求，就必须先按层分类。层号越低，互操作要求越精细、越苛刻，标准被接受与部署的挑战也越大。分类不是贴标签比赛，而是给每份提案标明“动的是系统的哪一层、出问题会出多大的问题”。

四、规则本身

标准类 BIP 必须归入四层之一；非标准类 BIP 可以归入这些层，也可以不归层。

4.1 第一层：共识层（Consensus）

定义密码学承诺结构。其职责是让任何人都能在本地判定某个状态与历史是否有效，提供结算保证，并确保最终收敛。共识层不关心消息如何在网络上传播。

这一层的分歧会造成网络分裂（分叉）：不同节点可能接受互不兼容的历史。共识层变更再细分为：

软分叉：旧规则下有效的某些结构在新规则下不再有效；旧规则下无效的结构在新规则下仍然无效（规则只收紧）；
硬分叉：旧规则下无效的某些结构在新规则下变为有效（规则放松）。

4.2 第二层：对等服务层（Peer Services）

规定节点如何彼此发现、如何传播消息。基本节点互操作只要求其中一个子集，其余服务是可选扩展。

BIP-124

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-124
标题	Hierarchical Deterministic Script Templates
作者	Eric Lombrozo <eric@ciphrex.com>, William Swanson <swansontec@gmail.com>
指定日期	2015-11-20
层级	Applications（应用）
类型	Informational（信息类）
状态	Closed（已关闭）
阅读版	https://bips.dev/124
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0124.mediawiki

二、放在哪一族

钱包脚本构造与互操作族。它站在 BIP-32（分层确定性钱包）的密钥派生之上，想再往上统一一层：脚本本身怎么由派生路径确定性地拼出来。

它直接引用的前置与配套包括：

BIP-16：Pay to Script Hash，当时最常见的多签承载方式

BIP-32：分层确定性派生，本 BIP 的密钥来源

BIP-65：OP_CHECKLOCKTIMEVERIFY，哈希锁与时间锁合约的构件之一

BIP-112：CHECKSEQUENCEVERIFY，另一构件

原文还把 Lightning Network 白皮书列为参考文献：多层协议把区块链当结算层，正是它想服务的复杂脚本场景。后来钱包间交换脚本构造方式的实际工作，更多沿输出脚本描述符一族展开（见 BIP-380 起的描述符系列，以及 BIP-129 的多签设置）——但那是后来的路线，本 BIP 本身停在 Closed，不能把后来的成果算作它的采用。

三、它要解决什么

3.1 各钱包各写各的脚本

原文指出，当时钱包发出的脚本只有极少数广泛使用的格式，最常见的是 pay-to-pubkey-hash 与 m-of-n 的 pay-to-script-hash（BIP-16）。问题是：不同钱包用互不兼容的派生方案生成签名密钥、再构造脚本。同一套授权策略，换一个钱包就拼不出同一份脚本，更谈不上多家钱包协作。

3.2 脚本正在变复杂

随着哈希锁、时间锁合约（BIP-65、BIP-112）出现，不同钱包需要能协作生成更精巧的脚本；同时，把区块链当结算层的多层协议（例如 Lightning Network）也在发展，需要足够通用的模板，才能跟上快速演进的脚本设计。

本 BIP 的目标因此很具体：给出一套通用格式，保证不同钱包对同一组 BIP32 派生路径，产出的脚本完全一致。

四、规则本身

4.1 密钥：派生路径加自由索引

单个密钥由一条 BIP32 派生路径和一个索引 k 确定，记法为 A_k =（A 的派生路径）/k。同一个模板换不同的 k，就得到同一策略下的一系列脚本——这正是“确定性”的含义：路径与索引定了，脚本就定了。

BIP-125

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-125
标题	Opt-in Full Replace-by-Fee Signaling
作者	David A. Harding <dave@dtrt.org>, Peter Todd <pete@petertodd.org>
指定日期	2015-12-04
层级	Applications（应用）
类型	Specification（规范类）
状态	Deployed（已部署）
阅读版	https://bips.dev/125
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki

二、放在哪一族

交易替换与内存池策略族，核心是 nSequence 的用法。它与相对锁定时间一族相邻又必须分清：

BIP-68：用共识强制的序列号表达相对锁定时间

BIP-112：CHECKSEQUENCEVERIFY

BIP-125 原文明确说：opt-in full-RBF 与其他 nSequence 用法没有已知的问题性冲突，与比特币 0.1 实现里的共识锁定时间、BIP-68、BIP-112 都兼容。

它处理的是节点策略（mempool 里一笔未确认交易能不能被另一笔顶掉），不是共识规则：交易一旦上链，就不存在“替换”一说。理解这一族的关键是分清三件事：付款人有没有发信号、节点愿不愿意按信号替换、收款人要不要把未确认交易当作已付款。

三、它要解决什么

3.1 发出去的交易改不动

原文的出发点：许多节点不会把内存池里的一笔交易，换成另一笔花费相同输入的交易。付款人因此很难调整已经发出的交易——例如确认迟迟不来想加手续费，或者有其他正当的替换需求，都做不到。

3.2 直接恢复全量替换，又会伤到“先见”预期

历史上，中本聪的原始实现本就用每个输入的 nSequence 支持内存池内替换，后来在 0.3.12 版被移除，理由包括替换交易不必多付手续费，矿工没有动力打包，也没有内建的速率限制防止中继带宽被滥用。

等到有人做出 RBF 补丁想重新启用替换时，一部分收款人已经形成了预期：先看到的那一版交易，很可能就是最终被确认的那一版。于是出现了折中方案 RBF First Seen Safe（RBF-FSS）：替换交易必须按不低于原金额支付原交易的全部输出，原始的 RBF 则被称为 full-RBF。但 FSS 每次替换都要多加一个输入：钱包没有闲置输入时用不了，不同来源的输入混在一起损隐私，还白白增大交易体积。

opt-in full-RBF 的解法是回到中本聪的原始语义（只微调一点，让用 locktime 的人能退出）：付款人自己先发信号声明“可替换”，依赖先见版本的收款人可以据此忽略这类未确认交易；同时付款人享有 full-RBF 的效率，不必背 FSS 的额外输入。

四、规则本身

4.1 两种发信号方式

显式信号（Explicit signaling）：一笔交易的任一输入的 nSequence 小于 (0xffffffff - 1)，即视为该交易选择加入、允许被替换。

BIP-126

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-126
标题	Best Practices for Heterogeneous Input Script Transactions
作者	Kristov Atlas <kristov@openbitcoinprivacyproject.org>
指定日期	2016-02-10
类型	Informational（信息类）
状态	Draft（草案）
阅读版	https://bips.dev/126
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0126.mediawiki

二、放在哪一族

钱包隐私与交易构造最佳实践族。它不改协议、不改共识，只给钱包“怎么拼交易”定一套自律规范，目标是链上隐私。

它只有一条明确的规范衔接：与 BIP-69（交易输入输出的字典序索引）的关系——同时遵循两者的应用，应先执行本 BIP 的流程，再执行 BIP-69。

它讨论的对象与 BIP-125 那类节点策略无关：这里没有节点要执行的新规则，约束的是钱包自己的选币与输出构造方式。

三、它要解决什么

3.1 拼凑付款会把身份信息写上链

当一笔交易的多个输入分别花费发往不同比特币地址的在先输出时，用户的个人可识别信息（PII）会以不受控制的方式泄漏进区块链——旁观者很容易据此推断这些不同地址同属一人。

这类交易又常常躲不掉：钱包余额随时间自然碎片化，想付一笔较大的金额，往往必须把多个 UTXO 拼在一起。

3.2 三个目标

原文说，这套建议要同时做到三件事：

最大化用户保护协议的效果：如果为保护隐私而构造的交易有独特“指纹”，保护反而失效、甚至适得其反；规范要让这类交易不显眼。
最小化不可避免的异构交易的坏处：如果不可避免的交易与有意构造的保护性交易长得无法区分，前者在图分析面前就多了一层含混性，能借光受益。
限制对 UTXO 集合增长的影响：此前非标准化的有意异构交易每笔都倾向于让全网 UTXO 集合变大；把不可避免与有意两种交易都标准化，是为了把这种增长压到最小。

为此，原文提出两种形态：标准形（Standard form）与备选形（Alternate form）。

四、规则本身

4.1 先分清几个定义

异构输入脚本交易（HIT）：包含多个输入，且各输入所花费的在先输出的脚本不完全相同（例如花费了发往不止一个地址的输出）。全文判断“输入脚本”时，指的都是输入所引用的在先输出的脚本。

不可避免的 HIT：用户想新造一个金额大于钱包中最大单个未花费输出的输出，被迫拼凑而成。

有意的 HIT：作为用户保护协议的一部分、为减少 PII 无控制披露而特意构造的 HIT。

4.2 标准形：四条规则

一笔 HIT 同时满足以下全部条件，才是标准形：

唯一输出脚本的数量，必须等于唯一输入脚本的数量（不论输入、输出的实际个数）；
所有输出脚本都必须互不相同（唯一）；
至少要有一对输出金额相等；
交易中最大的输出，必须属于一个至少含两个等额输出的集合。

为什么按“唯一脚本数”而不是输入/输出个数对齐？原文的理由是照顾保护性的选币行为：钱包里可能因有意或意外的地址复用、或粉尘攻击，存有脚本相同的可花费输出；为减轻地址复用的坏处，每当某个 UTXO 被用作输入，所有与其花费脚本相同的 UTXO 都应一并纳入。要求输出脚本全部唯一，是为了杜绝输出端再复用地址；把输出数限制在唯一输入脚本数以内，则保证标准形 HIT 的输入数不少于输出数、不净增 UTXO。

BIP-127

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-127
标题	Simple Proof-of-Reserves Transactions
作者	Steven Roose <steven@stevenroose.org>
指定日期	2019-01-28
层级	Applications（应用）
类型	Specification（规范类）
状态	Complete（已完成）
阅读版	https://bips.dev/127
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0127.mediawiki

二、放在哪一族

托管证明与钱包互操作族。它要标准化的不是一笔真实付款，而是一种“证明我控制着这些币”的凭证构造方式。

它的地基是两个现成标准：普通比特币交易的序列化与验证规则，以及 BIP-174 的 PSBT（部分签名比特币交易）格式。原文还专门为 PSBT 定义了一个扩展字段，好让签名设备能认出“这不是一笔要把钱转走的普通交易”。

它与储备证明的其他研究路线（如隐私更好的 Provisions 一类方案）是并列关系：原文明确说自己只把既成事实做法形式化，不追求那类改进的隐私性质（见第三节）。

三、它要解决什么

3.1 托管方丢币不说，用户无从核验

比特币历史上很早就出现了替用户保管比特币的公司：用户交出币的控制权，换取某种服务。这类公司丢掉用户比特币却不及时公开的案例屡见不鲜。

储备证明（Proof of Reserves）就是让管理大量比特币的公司证明自己控制着相应金额的资金；定期做这种控制权证明，有助于确保没有发生重大损失而无人知晓。

3.2 每家自造一套，用户就得每家重学一遍

“储备证明”这个词并不新，但愿意做的高额托管方并不多。原文给出的原因之一是：每家想做证明的公司都得自创一套构造方法；相应地，用户想核验，就得先弄懂这家的构造。托管方与用户的门槛都被抬高了。

本 BIP 因此只做一件事：把证明的构造定成标准格式，让现有钱包基础设施能直接参与构造，让任何人都能用通用软件按标准流程验证。

3.3 它明确不做什么

原文专门声明：这里的构造有已知短板，主要是隐私性质。学界已有隐私好得多的储备证明机制研究（原文引用了 Provisions 论文），但本 BIP 有意只形式化事实上已经在用的老办法，不引入那些改进。读它时不要期待它解决隐私问题。

四、规则本身

4.1 证明应有的性质

原文先列目标：构造灵活，能支持复杂的钱包基础设施；易于与现有钱包方案（硬件、软件）集成；验证走标准流程，不因发布者不同而不同；证明通过绑定一条信息，防止被他人冒用（把别家的证明抄来当自己的）；并且能验证签发者在某个特定区块时控制着资金，不论那之后发生了什么。

4.2 证明格式：一笔故意无效的交易

证明被格式化为一笔普通比特币交易，只做一处小改造，同时起到两个作用：让交易不可花费（资金不冒风险），并把证明与签发者绑定（防抄）。具体构造：

第一个输入（承诺输入，commitment input）：其在先输出点的 txid 部分，必须设为承诺信息的 SHA-256 哈希，信息前要加上固定前缀 “Proof-of-Reserves: ”（例如信息是 “Some Message”，txid 就是 SHA-256(“Proof-of-Reserves: Some Message”)，字符串按 UTF-8 编码）；输出索引为 0。
其余输入：签名必须承诺（commit）到承诺输入，例如使用 SIGHASH_ALL。也就是说，每一枚被证明的 UTXO 的签名，都把这条承诺信息签了进去。
输出：交易必须只有一个输出，金额恰好等于全部输入之和（计算时承诺输入按 0 计），即这笔交易不付矿工费。

由于第一个输入只是一个承诺哈希、并不对应真实 UTXO，这笔交易是无效的，永远不可能被确认上链——无效在这里是设计目的，不是缺陷。

BIP-128

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-128
标题	Timelock-Recovery Storage Format
作者	Oren Z <orenz0@protonmail.com>
指定日期	2026-02-05
层级	Applications（应用）
类型	Specification（规范类）
状态	Draft（草案）
阅读版	https://bips.dev/128
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0128.mediawiki

二、放在哪一族

钱包恢复、继承与预签交易族。它建立的时间锁构件都来自更早的文档：

BIP-65：OP_CHECKLOCKTIMEVERIFY，原文以“一笔 nLocktime 设为未来日期的预签交易”作为传统做法的例子

BIP-68：共识强制序列号的相对锁定时间，本 BIP 计算取消期 nSequence 时直接遵循它

BIP-112：CHECKSEQUENCEVERIFY，脚本型钱包做相对锁时用

BIP-119 与 BIP-443：原文在比较脚本型方案时提到，称这类新操作码设想仍在讨论阶段

它与脚本型恢复钱包是两条路线之争：本 BIP 不要求用户先搬家到脚本钱包，而是让今天普通的 P2WPKH 钱包也能预签出带取消期的恢复计划；它标准化的只是这份计划的存储与交换格式（JSON），不是新的脚本或共识规则。

三、它要解决什么

3.1 单笔预签恢复交易的取消难题

预签交易是做恢复计划的一种办法，用于种子丢失或继承场景。最常见的例子是预签一笔交易，把 nLocktime 设在未来日期（见 BIP-65）。

它的局限在“顺利情形”下暴露：种子没丢、一切正常，但 nLocktime 快到了——用户必须动用钱包、花掉其中一个 UTXO，才能让那笔预签交易作废，防止它到期后直接把资金转走、中间没有取消期。对于把种子分存在多处地理位置的用户，这种被迫操作很恼人。

3.2 时间锁恢复计划：两笔交易加一段取消期

本 BIP 所称的 Timelock-Recovery plan，是预签一对交易，最终把资金转到一个或多个次级钱包；第二笔交易带特殊的 nSequence 相对时间锁，使主人始终有一段取消期。执行与监控这种计划，比广播并盯住一笔交易复杂：还要能加速第一笔交易、判断相对时间锁是否已过、更细致地处理链重组。

前提有了，缺的是格式：生成计划的钱包与监控/执行的服务若各用各的格式，计划就无法导出、导入与托付。本 BIP 要定的就是这份计划的统一存储格式。

3.3 为什么不用脚本型钱包替代

原文专门比较了脚本型路线：脚本可以用 OP_CHECKLOCKTIMEVERIFY（BIP-65）与 OP_CHECKSEQUENCEVERIFY（BIP-112）限制次级密钥只能在绝对日期后、或资金到账一段相对时间后使用，且新收到的资金自动纳入恢复机制，这些都是优点。

但缺点同样被列明：脚本钱包对硬件钱包更难正确实现、备份更容易漏（连基本多签都有人忘备份描述符）；脚本目前只能限制次级密钥“何时”能用，不能限制“如何”用——时间一到，次级密钥就能把钱转到任何地方，哪怕一切正常，主人也必须定期把 UTXO 花到新地址来“续期”，对超冷存储很不方便；新操作码方案（BIP-119、BIP-443）还在讨论中；而且新人通常从 P2WPKH 钱包起步，预签交易不必搬家，改用脚本功能却要新建钱包并转移资金，对大额持仓者门槛很高。

四、规则本身

4.1 计划由两笔交易组成

警报交易（Alert Transaction）：大体是一笔归集交易——绝大部分资金仍留在原钱包，但落到一个全新的、从未用过的地址，原文称之为警报地址（alert-address）；另有一笔手续费，以及一小笔固定金额发往若干锚地址（anchor-addresses），这些地址可用于通过 CPFP 加速警报交易。之所以叫“警报”，是因为监控区块链、发现这笔交易，就应当提醒主人：恢复计划已被启动——无论是有意、无意还是恶意。

BIP-129

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-129
标题	Bitcoin Secure Multisig Setup (BSMS)
作者	Hugo Nguyen <hugo@nunchuk.io>, Peter Gray <peter@coinkite.com>, Marko Bencun <marko@shiftcrypto.ch>, Aaron Chen <aarondongchen@gmail.com>, Rodolfo Novak <rodolfo@coinkite.com>
指定日期	2020-11-10
层级	Applications（应用）
类型	Specification（规范类）
状态	Complete（已完成）
前置依赖	BIP-32, BIP-174, BIP-322, BIP-380, BIP-381, BIP-382, BIP-383
阅读版	https://bips.dev/129
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0129.mediawiki

二、放在哪一族

多签钱包建立与描述符族。BIP-174（PSBT）把多签的“签一笔交易”流程标准化了，本 BIP 补的是它前面缺的一环：多签钱包本身最初怎么在不同厂商的设备之间安全地建起来。

它的前置依赖（Requires）构成一条清晰的链：

BIP-32：分层确定性密钥，签名者提供的 KEY/XPUB 来自它

BIP-174：PSBT，多签交易协作的既有标准

BIP-322：通用签名消息格式，密钥记录里的 SIG 用它（也接受 legacy 格式）

BIP-380、BIP-381、BIP-382、BIP-383：输出脚本描述符，BSMS 的配置记录就用描述符（或描述符模板）表达

它在钱包协调族里的位置是“建钱包”而不是“花钱包”：产出物是一份所有签名者都核对过、并各自保存的描述符记录，此后生成与核验收款、找零地址才有共同依据。

三、它要解决什么

原文列出多签设置阶段的五类关切：

多签配置是否正确、未被篡改——包括签名者成员、脚本类型、派生路径与所需签名数（M-of-N）；
密钥或配置会不会在设置过程中泄漏；
签名者是否把配置存进各自存储、以什么格式存；
签名者的存储是否防篡改；
签名者之后是否真的用这份配置生成并核验收款与找零地址。

攻击者若能修改配置，可把用户骗去向错误地址打款，盗走资金或以此勒索；若不能改、但能学到密钥与配置，则可监控钱包全部交易，损失隐私。

本 BIP 只负责处理前三项：降低初始设置阶段被篡改的风险，并定义一个可互操作的多签配置格式。第 4、5 项由各签名者自行负责，不在本提案范围内——读它时不要期待它保证设备存储安全或后续地址核验。

四、规则本身

4.1 角色与前置约定

协调者（Coordinator）：发起设置。它决定多签类型与确切的策略脚本；启用加密时，由它向各方分发共享秘密；它收集各签名者的信息生成描述符记录，再把记录分发回各签名者。

签名者（Signer）：任何控制私钥、能用私钥签名的软件或硬件，是多签的参与成员。它要向协调者提供密钥记录（内含公钥或扩展公钥 XPUB），核查自己的 KEY 确实被包含进描述符记录，并把描述符记录存入自己的存储。

前置假设：参与方都支持 BIP-32、BIP-322、描述符系列（BIP-380 至 BIP-383）与 AES 加密（RFC 3686）。文件约定：描述符与密钥记录用 .bsms 扩展名，加密数据用 .dat；换行一律用 LF（\n）。本节所述版本号为 BSMS 1.0。

BIP-13

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-13
标题	Address Format for pay-to-script-hash
作者	Gavin Andresen <gavinandresen@gmail.com>
指定日期	2011-10-18
层级	Applications（应用）
类型	Specification（规范类）
状态	Deployed（已部署）
阅读版	https://bips.dev/13
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0013.mediawiki

二、放在哪一族

P2SH 族的地址一环。这一族要分三份文档看：

BIP-12：OP_EVAL，P2SH 的原始设计（后未采用）

BIP-13：本页，地址格式——脚本哈希怎么编码成可书写、可粘贴的地址

BIP-16：Pay to Script Hash，实际部署的赎回校验规则

另一竞争设计 BIP-17（OP_CHECKHASHVERIFY）也在 BIP-13 的参见之列。地址格式与校验规则是两件事：BIP-13 只定前者，无论赎回机制最终选哪一案，收款方都需要一种把脚本哈希告诉付款方的方式。

三、它要解决什么

原文要支持的是“任意复杂的交易”。这里的“复杂”有明确定义：指赎回已收到的币时需要什么信息——普通地址只需要一把 ECDSA 私钥，而复杂条件（多签、托管等）需要的信息要多得多。

设想端到端的安全钱包、向托管交易付款、第三方钱包安全服务这类场景，收款条件没法压进一个公钥哈希里。本质做法是：让地址编码的对象从“ECDSA 公钥的哈希”换成“脚本的哈希”。付款方照旧付给一个地址，脚本细节留到收款方日后花费时再揭示。

四、规则本身

4.1 编码方式

新地址的构造与既有比特币地址完全相同，采用 Base58Check 编码：

base58-encode: [one-byte version][20-byte hash][4-byte checksum]

版本字节：主网为 5，测试网为 196。
20 字节哈希：将用于赎回这笔币的脚本的哈希。
4 字节校验和：版本字节与哈希拼接后做双重 SHA256，取其前 4 字节（与既有地址相同的做法）。

版本字节的选择保证 Base58 编码后的首字符稳定：主网字节 5 编码后以 “3” 开头，测试网字节 196 编码后以 “2” 开头。这就是今天以 “3” 开头的地址的来源。

4.2 原文记录的批评与回应

这份 BIP 很短，但如实记下了三条批评：

BIP-130

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-130
标题	sendheaders message
作者	Suhas Daftuar <sdaftuar@chaincode.com>
指定日期	2015-05-08
层级	Peer Services（对等服务）
类型	Specification（规范类）
状态	Deployed（已部署）
阅读版	https://bips.dev/130
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki

二、放在哪一族

P2P 网络与区块中继族。它只动节点之间“怎么宣布新区块”这一件小事，属于对等服务层，不碰共识、不碰交易格式。

它的上下文是 0.10 版引入的 headers-first（先头后体）区块下载：区块只有能接上一条有效的区块头链时才会被处理。理解本 BIP，要先看清它与既有消息的分工：inv 宣布“我有这个区块哈希”，getheaders 索取区块头，headers 送回区块头，getdata / block 则取整块。本 BIP 没有新增这些消息，只新增了一条表达偏好的信号消息，让对方可以省掉其中一来一回。

同族可对照阅读的有 BIP-152（紧凑区块中继）等同样着眼于降低区块传播开销的文档，但两者机制不同，不要混为一谈。

三、它要解决什么

3.1 先见流程：宣布一个新区块要多绕一圈

原文复述了当时区块中继的一般流程：

节点 N 用一条 inv 消息宣布新链尖，里面只有区块哈希；
对等节点 P 收到后，回一条 getheaders（索取直到新链尖的区块头，外加定位用的 block locator），再回一条 getdata 取新链尖整块；
N 再回一条 headers（新区块的头，连同 P 还不知道的前置区块头），和一条 block（新区块整块）。

既然自 headers-first 以来，P 反正都要先拿到区块头才能处理区块，那么当新区块就建在当前链尖之上时，N 直接把新区块的区块头宣布出来更有效率：省下 P 生成与发送 getheaders 这一步，也省下构造 block locator 的功夫。

3.2 重组时：中间区块的头迟到，整块就只能等

发生重组、有一个或多个区块被断开时，当时节点只对新链尖发一条 inv。对等节点可以立刻请求新链尖整块，但要等中间区块的区块头送达后，才能请求那些中间区块。如果宣布时就把从最后分叉点到新链尖的一串区块头一并发出，对等节点便可立刻请求全部中间区块。

BIP-131

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-131
标题	"Coalescing Transaction" Specification (wildcard inputs)
作者	Chris Priest <cp368202@ohiou.edu>
指定日期	2015-11-30
层级	Consensus (hard fork)（共识（硬分叉））
类型	Specification（规范类）
状态	Closed（已关闭）
阅读版	https://bips.dev/131
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0131.mediawiki

二、放在哪一族

共识层硬分叉提案族，而且是其中改动验证模型的一类：它不新增操作码或脚本功能，而是要改“一个输入到底指什么”——从指向某一个具体的在先输出，改成指向一整类输出。

它补充（supplement）而非取代普通“非合并（non-coalescing）”交易：两种交易按设计并存，靠交易版本字段里的类型位区分。因此它与 BIP-11 那种只改节点策略、不动共识的标准交易文档完全不同：本 BIP 一旦实施，全节点验证普通交易的代码也必须跟着改（见 4.3），这正是它被标为 Consensus (hard fork) 的原因。

它针对的问题——小额 UTXO 太贵花不动、UTXO 集合膨胀——是长期议题；但解决路线是本 BIP 独有的，并未成为后来实际采用的方案，读时须以它 Closed 的状态为准。

三、它要解决什么

原文指出的低效是这样的：当你想花费多个 scriptPubKey 完全相同的输入时，普通交易必须把每个输入逐一列出，并把表达同一信息的签名重复多遍。这让交易体积膨胀，花小额输入变得很贵。

后果有两层：

小额输入因为不划算而花不出去，长期留在 UTXO 池里，而 UTXO 池是全节点必须保存维护的；
原文推演：如果最大区块体积的增速慢于用户实际发送的交易量，这问题会更严重——换言之，手续费上升时，一个 UTXO 值得被花费的最低经济金额也随之上升，更多小额输出会被卡住。

原文认为 UTXO 集合的长期增长会对网络产生负面的扩展性后果。合并交易就是为压低“同类小额输出”的花费成本而设计的。

四、规则本身

4.1 重新定义交易版本字段

本 BIP 首先重定义交易的 version 字段：前四个字节定义为版本号，后四个字节定义为交易类型。类型 “0000” 表示普通交易，类型 “0001” 表示合并交易。原文给的例子是：

version 1 的普通输入交易：        version: 10000000
version 2 的普通输入交易：        version: 20000000
version 2 的合并输入交易：        version: 20000001

实质是把 version 字段的最后一个比特置 1，为这笔交易的全部输入启用通配（wildcard）语义。

BIP-132

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-132
标题	Committee-based BIP Acceptance Process
作者	Andy Chase <theandychase@gmail.com>
指定日期	2015-08-31
类型	Process（流程类）
状态	Closed（已关闭）
阅读版	https://bips.dev/132
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0132.mediawiki

二、放在哪一族

流程族，即“关于 BIP 本身的 BIP”（meta-BIP）：它不写协议规则，写的是提案制度怎么运转。

这一族的谱系在原文里就点明了起点：

BIP-1：定义了怎么写、怎么提交一份 BIP，但原文认为它没有说清一份 BIP 究竟怎样才算被采纳（Accepted）或被否决——本 BIP 正是要补这一块

与它同类的后续文档包括 BIP-2（BIP 流程修订版）与现行流程 BIP-3。但要注意谱系与效力的区别：实际沿用下来的流程是 BIP-2、BIP-3 那条线，编辑负责编号与格式、作者负责争取共识，并没有“委员会投票裁定”这一环。本 BIP 的委员会方案从未成为 BIP 流程的一部分，它是流程族里一条没有走通的支线。

读它仍有价值：它把一个真问题摆上了台面——在一个没有公司、没有董事会、节点自愿升级的系统里，“被采纳”三个字到底由谁、按什么程序说出口。

三、它要解决什么

原文的判断很直接：一份 BIP 怎样算被采纳，现行流程没有明确定义。BIP-1 规定了撰写与提交的办法，却没有给出判定接受或拒绝的精确方法。

动机一节补了一句理由：BIP 代表着对比特币基础设施的重要改进，要让创新持续，BIP 流程就必须有清晰定义的阶段与采纳确认。

本 BIP 因此提出两样东西：

一套流程：一份 BIP 依次经过征求意见与表态，最后落到 Accepted 或 Deferred；
一套委员会：由代表各板块的授权团体审议意见，并在精确条件下表明是否采纳。

判定标准也一并给出（细节见第四节）：四个板块中至少三个板块，每个板块内至少 70% 的被代表份额赞成，这份 BIP 才算被采纳。

设计理由（Rationale）一节说，委员会制是用来组织生态各板块的核心关切：每个板块内部观点可以很多，但要得到一个决定性的“是/否”，就需要一个有代表性的权威结构；这个结构应当是流动的——人们可以离开不再反映自己观点的委员会，并且每次评估某份 BIP 时都要重新验证其代表性。

四、规则本身

4.1 流程：从提交评论到 Accepted 或 Deferred

BIP Draft：提案先是草稿，且必须已被 BIP 编辑分配编号（即已获编辑批准），才有资格进入下一步。
提交评论（Submit for Comments）：提案中列名的第一位 champion 可随时发起，方式是在 bitcoin-dev 邮件列表发帖，给出 BIP 编号，并声明打算立即提交评论。
评论期（Comments）：提交后开始两周期限，社区应从“提修改建议”转入“发表对提案的意见或担忧”。
意见汇总（Reported Opinions / Waiting on opinion）：评论期过后，各委员会必须汇总其所代表社区收到的评论并提交意见，截止时间为提交评论后四周（即再给两周）。委员会在截止后不得反悔，但可应其请求标注“若再次提交评论，决定可能改变”；若重新提交，委员会可以改主意。
Accepted：若四个板块中至少三个板块、每个板块至少 70% 的被代表份额接受提案，BIP 即被视为已采纳。委员会未提交意见的，按“Decline to accept（拒绝接受）”计。到了这一步，BIP 不得做实质修改，但可以被替换；小的修改或澄清允许，但必须记录在文档中。
Deferred：未达到上述门槛，BIP 被打回建议阶段；修改后可重新提交评论，但不得早于上一次提交评论之日起两个月。两次提交尝试失败后，BIP 被标记为 rejected（被拒）；被拒的 BIP 仍可修改并再次提交。

每份委员会意见必须包含：一句明确表态——“Intend to accept”“Intent to implement”“Decline to accept”或“Intend to accept, but decline to implement”四选一；若拒绝，必须给出清晰具体的理由，并附一份清单，列明要发生什么或改动什么，委员会才会转而接受；若接受，必须列出接受的理由，同时列出担忧，或列明哪些方面一旦变化、委员会在下次提交评论时可能反悔。

BIP-133

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-133
标题	feefilter message
作者	Alex Morcos <morcos@chaincode.com>
指定日期	2016-02-13
层级	Peer Services（对等服务）
类型	Specification（规范类）
状态	Deployed（已部署）
阅读版	https://bips.dev/133
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki

二、放在哪一族

对等网络消息与交易转发策略族。BIP-133 不改交易格式，也不改共识，只在节点之间多加一种“事先打招呼”的消息，让转发更省带宽、省内存池资源。

它与几条既有机制是配合关系，而不是替代关系：

有限内存池：Bitcoin Core 0.12 引入的思路，原文以此为背景——节点只保留自己愿意处理的交易，低费、不会被挖出的交易不无限堆积。

拒绝过滤器（reject filter）：帮助节点避免反复请求同一笔刚因费不足被拒的交易；但它每个区块后重置，管不了第一次请求。

Bloom 过滤器：SPV 客户端用来只接收与自己相关的交易；原文明确 feefilter 与它叠加生效，两个过滤器都要通过才转发。

理解这一族的关键是分清“公告”和“本体”：inv 只是“我有这笔交易”的公告，getdata 才是去索取本体。BIP-133 过滤的是公告环节。

三、它要解决什么

3.1 有限内存池挡不住无效公告

内存池有限之后，节点有了自我保护：低费垃圾交易不会无限占用资源，拒绝过滤器也能减少重复索取。

但原文指出两个漏洞：

拒绝过滤器每出一个区块就重置，时间跨度较长的 inv 会让同一笔交易被重新请求，且第一次请求根本拦不住；
每一笔被内存池接受的交易，其 inv 至少要在每个对等连接上发送或接收一次，发送方无从知道：这条 inv 发过去，对方会不会因为费太低而根本不会用 getdata 来取。

结果是带宽和处理都花在了注定被对方丢弃的交易上。

3.2 先声明门槛，再决定发不发

思路很直接：如果接收方先把自己的最低费率告诉发送方，发送方在发 inv 之前就能算出这笔交易的费率够不够门槛，不够就不发。

feefilter 要补的就是这个“事前声明”，而不是事后拒绝。

四、规则本身

4.1 消息格式

feefilter 是一条对等网络消息，pchCommand 为 “feefilter”，内容是一个 int64_t，数值按聪每千字节（satoshis per kilobyte）解释，表示费率门槛。

功能发现靠协议版本：protocol version >= 70013 才视为支持该特性。

BIP-134

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-134
标题	Flexible Transactions
作者	Tom Zander <tomz@freedommail.ch>
指定日期	2016-07-27
层级	Consensus (hard fork)（共识（硬分叉））
类型	Specification（规范类）
状态	Closed（已关闭）
阅读版	https://bips.dev/134
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0134.mediawiki

二、放在哪一族

交易格式重做与可塑性修复族，而且是其中走硬分叉路线的一支。BIP-134 不满足于给旧格式打补丁，而是要换一套新的交易序列化。

同族对照：

BIP-141：Segregated Witness，同样要解决签名可塑性对 txid 的影响，但走软分叉路线，把见证数据移出 txid 计算。

BIP-140：Normalized TXID，同样以“算 ID 时剔除签名脚本”为核心，走软分叉加新操作码的路线。

BIP-68：相对锁定时间。原文把这类“复用既有字段”的历次软分叉改动列为技术债的例子，认为新格式应把它们收进更好维护、更好解析的体系。

BIP-134 在这一族里的位置是：设想最彻底、改动面最大，因而也最难部署的一个方案。

三、它要解决什么

3.1 老格式用了约八年，字段只能硬塞

原文动机部分说，比特币交易在当时已用了约八年基本相同的版本与布局，教训之一是缺少灵活性。

典型例子是 sequence 字段：先引入、后来又被弃用，但所有交易仍被迫保留这些字段、让区块链跟着变大，哪怕它们全都取默认值。

3.2 可塑性卡住上层协议

交易数据字段重新排序，是为了干净地修复可塑性问题。原文明确说，未来技术如闪电网络将依赖这类修复落地。

同时，重排之后把签名从交易里拿掉变得很容易，且不破坏其 tx-id，这对未来的修剪（pruning）功能有利；原文称测试显示空间占用可降到约 75%。

3.3 想要的能力清单

原文列出的目标包括：

修复可塑性；
签名检查的线性扩展（linear scaling）；
面向未来的高度可扩展性；
让交易更小；
支持闪电网络。

此外 v4 格式还打算原生支持输入金额证明、scriptBase（输入与输出合并脚本，供硬件钱包确知自己在花什么），以及双花证明——节点发现双花时只发证明，不必发整笔交易。

四、规则本身

4.1 版本 4 与紧凑消息格式（CMF）

方案利用一个事实：交易最前面 4 字节决定版本号，而多数客户端用一条非共识的策略规则，不接受未明确定义的版本号。BIP-134 选用新版本 4，并规定版本之后的数据使用 Compact Message Format（CMF）。

BIP-135

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-135
标题	Generalized version bits voting
作者	Sancho Panza <sanch0panza@protonmail.com>
指定日期	2017-03-29
类型	Informational（信息类）
状态	Closed（已关闭）
取代文档	Replaces: BIP-9
阅读版	https://bips.dev/135
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0135.mediawiki

二、放在哪一族

升级部署与矿工信号族，源头是 BIP-9（version bits 状态机）。BIP-135 在档案关系上直接写明 Replaces: BIP-9，意图不是另起炉灶，而是把 BIP-9 的框架一般化。

它在这一族里的特殊之处有两点：

信号对象放宽：BIP-9 只管向后兼容的软分叉信号，BIP-135 把信号位的语义扩展到任意共识变更，统称 forks（分叉），软、硬都在内；
参数改为逐位可配：BIP-9 对一条链上所有部署共用固定阈值与不可配的锁定期，BIP-135 让每一位有自己的阈值、窗口与宽限期。

仍用同一段 version bits、仍保留 BIP-9 状态机的状态与原始参数（name、bit、starttime、timeout），只是在状态转移条件上追加参数。设计目标之一就是用合适的参数配置，能严格地向后兼容既有 BIP-9 部署。

三、它要解决什么

原文动机先肯定 BIP-9 服务过往部署有功，再列三条短板：

只适用于向后兼容的变更，硬分叉等变更不在其内；
固定的 95% 阈值不够灵活，无法表达一条“争议程度光谱”——不同变更本应可以用不同门槛；
小少数可以否决拟议变更，可能导致不希望看到的停滞。

协议需要一套灵活的、就协议变更达成共识的方案，才能适应市场需要。通用化修订的目标，就是在保持对既有 BIP-9 部署向后兼容的同时，给激活策略更多选择自由。

原文同时给出配套的使用建议，例如：阈值应尽可能高以确保平稳激活，且强烈建议 threshold 不低于 windowsize 的一半向上取整，以保证只有多数支持才激活；timeout 建议设为 starttime 之后一年；尝试失败后应留一段休耕期（fallow period，惯例建议三个月）以便发现有缺陷的客户端，并给成功分叉留出警告与升级时间。

四、规则本身

4.1 信号位

信号位是区块头 nVersion 字段的最低 29 位，编号 0 到 28。nVersion 最高 3 位必须置为 001，即取值落在 0x20000000 到 0x3FFFFFFF；若某区块 nVersion 最高 3 位不是 001，它的所有信号位一律按 0 处理。

BIP-136

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-136
标题	Bech32 Encoded Tx Position References
作者	Велеслав <veleslav.bips@protonmail.com>, Jonas Schnelli <dev@jonasschnelli.ch>, Daniel Pape <dpape@dpape.com>
指定日期	2017-07-09
层级	Applications（应用）
类型	Informational（信息类）
状态	Draft（草案）
阅读版	https://bips.dev/136
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0136.mediawiki

二、放在哪一族

交易引用与人类可用编码族。BIP-136 不定义新交易、不改节点如何验证，只定一套“怎么向人报一笔交易在哪”的标准说法。

它的两个直接依靠：

BIP-173：Bech32 编码。原文的 TxRef 编码以此为基础，后又按 BIP-350 的 Bech32m 加以细化。

BIP-350：Bech32m。现行规范正文要求 TxRef 使用 Bech32m 编码；同时因早期存在按原 Bech32 造出的 TxRef，解析器应能解码两者，并提示用户升级到 Bech32m 版本。

与 TxID 的关系是分工，不是替代：TxID 是共识里的密码学标识，TxRef 是给人用的位置坐标。一个报“内容指纹”，一个报“第几块、第几笔”。

三、它要解决什么

自比特币最初版本起，TxID 就是共识协议的核心部分，用户之间 routinely 用它标识交易。但原文列出它在不少用例里的实际局限：

对全节点而言，按 TxID 查一笔交易很贵，要么线性扫描区块链，要么维护昂贵的 TxID 索引；
SPV 钱包按 TxID 查询要依赖第三方服务；
TxID 是 64 个字符的十六进制串，不适合口头或手写转述。

原文的办法是换个引用维度：交易不仅可以按 TxID 引用，也可以按它在区块链中的位置引用。把位置坐标编码得短、且适合偶尔人工抄写，就是 TxRef 要做的事。

BIP-137

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-137
标题	Signatures of Messages using Private Keys
作者	Christopher Gilliard <christopher.gilliard@gmail.com>
指定日期	2019-02-16
层级	Applications（应用）
类型	Specification（规范类）
状态	Deployed（已部署）
阅读版	https://bips.dev/137
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0137.mediawiki

二、放在哪一族

消息签名与地址类型辨认族。BIP-137 管的不是链上交易签名，而是链下用同一把私钥给一段文本消息签名、让别人验“这话确实是持钥人签的”。

它在族里的位置需要和后继者一起看：

BIP-322：通用消息签名（generic signmessage）。原文开篇即说明：已有一个新签名格式被定义出来，相对本 BIP 有若干优势；保留 BIP-137 是为了与既有实现向后兼容。细节应以 BIP-322 为准去看新方案。

BIP-141：隔离见证。正是 SegWit 带来 P2SH 包裹与 Bech32 两类新地址后，“这把钥匙对应哪类地址”才成为验签时必须说清的问题，本 BIP 要补的正是这块标准空白。

所以这一族的读法是：BIP-137 记录并统一了当时各客户端已在用的做法，BIP-322 是面向之后的新格式。

三、它要解决什么

比特币私钥不只能签交易，也能签任意消息，这早已成为习惯用法。原文列出的用途包括：抵押用的资金证明、信用证明、活动入场、空投、审计等。

问题出在地址多样化之后：

用 P2PKH 地址的私钥签消息，做法早已为人熟知，当时并没有 BIP 把它写下来；
SegWit 出现后有了 P2SH 形式与 Bech32 形式的地址，若没有具体标准，验签方无从判断一个签名对应的是 P2PKH、P2SH 还是 Bech32 地址。

BIP-137 因此要做两件事：把既成做法写成明确标准，并用签名格式本身把地址类型编码进去，让不同客户端之间能签、能验、结果一致。

四、规则本身

4.1 签名的构成

一个比特币消息签名共 65 字节，序列化为：

[1 字节头][32 字节 r 值][32 字节 s 值]

其中 r 与 s 是 ECDSA 签名的两个分量，可用标准 ECDSA 库函数算出。头字节像一个位掩码，携带恢复公钥所需的信息。

BIP-138

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-138
标题	Compact Encryption Scheme for Non-seed Wallet Data
作者	Pyth <pythcoiner@wizardsardine.com>
指定日期	2026-05-11
层级	Applications（应用）
类型	Specification（规范类）
状态	Draft（草案）
依赖文档	Requires: BIP-32, BIP-340, BIP-380, BIP-388, BIP-389, BIP-390
阅读版	https://bips.dev/138
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0138.md

二、放在哪一族

钱包描述符与备份族。BIP-138 档案头明确写了它依赖的一串文档，读它要先认清这条链：

BIP-32：分层确定性钱包，xpub 与派生路径的来源。

BIP-340：Schnorr 签名。本 BIP 借用它的带标签哈希（tagged hash）构造来派生秘密，并使用 x-only 公钥形式。

BIP-380：输出脚本描述符。本 BIP 加密备份的首要对象。

BIP-388：钱包策略。另一首要对象；BIP-389、BIP-390 同列在依赖中，其中 BIP-390 的 musig() 表达式在本 BIP 的密钥规则中有专门处理。

范围上它还顺带覆盖：标签数据见 BIP-329 一类用途，以及 BIP-139 一类钱包备份元数据——原文说方案为描述符与策略而设计，但同样适用于标签与备份元数据。

这一族共同的焦虑是同一件事：种子之外，还有一份“说明你的币在哪”的数据，丢了或泄露了都出事。

三、它要解决什么

3.1 丢描述符，几乎和丢种子一样致命

原文开门见山：种子让你能签名，描述符把你映射到你的币。丢失钱包描述符或钱包策略，几乎和丢种子本身一样灾难性。

对多签或 Miniscript 钱包，光有钥匙不够：没有描述符，就重构不出脚本。原文还提醒一个不直观的风险：某些多签设计本可在丢一把种子时仍保住币，但若那把种子的公钥也随之丢失，币照样可能变得不可达。

3.2 离线存太长，在线存泄露

描述符离线保管有两个实际障碍：

描述符可能远比 12 或 24 个助记词长，纸质与钢板备份变得不实际、易出错；U 盘等离线数字介质会随时间退化，也难扛水火；
手机与云盘解决了长度问题，却暴露钱包结构：明文描述符会泄露公钥与脚本细节，云存储往往未加密，即便加密，其实现不透明、安全性又归结为能访问云的最弱设备，每多一份拷贝就多一份攻击面。

3.3 目标性质

BIP-138 要的是一份加密、紧凑的备份格式，并列明期望性质：

加密：可安全存放在不可信的云服务商或备份服务处；
访问受控：只有指定共同签名人能用其 xpub 解密，且不能用链上已 revealed 的公钥解密；
易实现：不需要复杂工具或库，也不要求访问私钥材料——安全的签名系统本就不会交出私钥；
厂商中立：可与任何硬件签名器配合。

范围红线先划清：载荷在加密前必须移除一切私钥材料。正因为解密靠的是公钥材料，这套方案不适合存私钥。

BIP-14

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-14
标题	Protocol Version and User Agent
作者	Amir Taaki <genjix@riseup.net>, Patrick Strateman <bitcoin-bips@covertinferno.org>
指定日期	2011-11-10
讨论日期	2011-11-02
层级	Peer Services（对等服务）
类型	Specification（规范类）
状态	Deployed（已部署）
阅读版	https://bips.dev/14
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0014.mediawiki

二、放在哪一族

对等服务层的身份与版本这一族，管的是节点在网络上如何报家门：我说的协议是哪个版本、我跑的是什么实现。

文中用词先作区分：bitcoin 指协议本身，Satoshi 指当时的客户端（后称 Bitcoin Core 一脉）。这份 BIP 处理的正是“协议”与“某一个实现”从最初混为一体、到必须分家的问题——今天在节点连接信息里看到的 user agent 字符串（如 /Satoshi:x.y.z/ 的形态），源头就在这里。

三、它要解决什么

比特币起步时只有一个 Satoshi 客户端，协议即客户端，版本号只有一个。但社区开始分化：用 Java、Python、Javascript、C++ 等不同语言写的替代客户端快速出现，各有自己的功能集。

当时协议里内嵌的版本号——主要出现在 “version” 与 “getblocks” 消息中，“block” 消息里也用它表示产出该块的软件版本——与客户端版本号是同一个数。这带来两个问题：

绑架其他实现：Satoshi 客户端每次发版都抬高这个数，其他所有客户端被迫追赶它的版本编号节奏，这与比特币的去中心化性质相悖——网络健康要求把“协议”这一共享协作过程从“协议的实现”中拆出来。
版本抬升可致不兼容与网络分裂：靠一个共享编号区分彼此，本就容易出问题。

拆法是：协议有自己的版本号，所有实现对齐到同一标准；客户端的身份与版本则降格为一条信息性的 user agent 字符串，像车牌一样只用于区分彼此。原文也承认，把协议开发改为多方协商有“难以达成一致时”的民主代价，需要强沟通渠道与快发布节奏来缓解，但这属于流程类 BIP 的范围，不是本文的事。

四、规则本身

4.1 字段分工

“version” 与 “getblocks” 数据包中的 version 字段，改为协议版本号；“block” 中的版本号表示该块创建时的协议版本。
“version” 数据包中原先未使用的 sub_version_num 字段，改为新的 user agent 字符串。

原文为两者的用途划了一条明确的界线：

BIP-140

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-140
标题	Normalized TXID
作者	Christian Decker <decker.christian@gmail.com>
指定日期	2015-10-14
层级	Consensus (soft fork)（共识（软分叉））
类型	Specification（规范类）
状态	Closed（已关闭）
阅读版	https://bips.dev/140
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0140.mediawiki

二、放在哪一族

交易可塑性修复族。BIP-140 要根除的是 txid 会随签名表示变化这一件事，思路是让引用输出用的 ID 从一开始就不包含签名。

同族文档：

BIP-62：处理可塑性。靠给签名定规范表示来缓解第三方修改，但原文指出其检查复杂、且未必能消除全部第三方可塑性来源。

BIP-66：严格 DER 签名。与 BIP-62 一同缓解第三方修改问题。

BIP-11：M-of-N 标准交易。BIP-140 的新标准脚本格式直接沿用 BIP-11 的 m-of-n 形态，再加版本参数与新操作码。

BIP-141：隔离见证。同为解决签名可塑性对 txid 的影响，走的却是把见证移出交易本体的路线。两份文档解决同一问题、给出不同结构，放在一起读最能看清取舍。

BIP-140 在族内的独特主张是覆盖面：不只防第三方改签名表示，也防签名者本人重签——因为 ECDSA 带随机参数，同一签名者能给出任意多份不同签名，规范表示管不住这一点，而把签名移出哈希可以。

三、它要解决什么

交易可塑性指的是：一笔交易可以被修改——或由签名者之一重签，或由第三方修改签名的表示形式。麻烦在于，序列化表示一变，交易的哈希就变，而花费交易正是用这个哈希来引用要花的资金的。

若一笔交易被改后最终上链确认，所有依赖原交易的后续交易都会失效、成为孤儿。链式交易、上层协议与多方共同签名的结构首当其冲。

原文还指出规范化带来的附带好处：交易模板。模板是一笔未签名的交易骨架，可以先在其上搭出整串后续交易，各方确认整串结构符合预期后再补签名生效。这样就不必由一方先收齐全部签名、握有完整已签交易才能算出 ID，也降低了一方单方面锁死资金的可能。多签输出上的高层协议（如支付通道类构造）正是原文点名的受益场景。

需要留意的例外原文也写明了：使用 SIGHASH_NONE、SIGHASH_SINGLE 或 SIGHASH_ANYONECANPAY 时，交易仍可被单方面修改，但那是创建者明确允许修改的情形，不算问题。

四、规则本身

规范分三部分：规范化 TXID 的计算、新操作码、UTXO 跟踪的改动。整体以软分叉方式引入，交易版本升至 2，以显式选择加入规范化 ID 的跟踪。

4.1 规范化 TXID 怎么算

对非 coinbase 交易，把每个输入的签名脚本剥除——把脚本长度置 0、移除其字节数组；再把每个输入引用的前交易哈希替换为其规范化版本（若有；版本 1 交易没有规范化 ID，就用普通 ID）。规范化 TXID 就是对这样规范化后的交易做双重 SHA256，与既有 txid 算法同构。

BIP-141

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-141
标题	Segregated Witness (Consensus layer)
作者	Eric Lombrozo <elombrozo@gmail.com>, Johnson Lau <jl2012@xbt.hk>, Pieter Wuille <pieter.wuille@gmail.com>
指定日期	2015-12-21
层级	Consensus (soft fork)（共识（软分叉））
类型	Specification（规范类）
状态	Deployed（已激活）
阅读版	https://bips.dev/141
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki

二、放在哪一族

SegWit 家族的总纲，共识层这一份。本 BIP 只定共识规则，同族的其他文档各管一段，读本篇时应把它们当作配套件：

BIP-143：版本 0 见证程序的签名验证新摘要算法。本 BIP 多处指明，P2WPKH 与 P2WSH 的签名校验细节以 BIP-143 为准，包括只接受压缩公钥等限制。

BIP-144：隔离见证（对等服务）。含见证数据的交易与区块如何序列化、如何在节点间传输，本 BIP 的总大小与交易权重定义都引用它的序列化。

BIP-173：原生 v0–16 见证输出的 Base32 地址格式。本 BIP 参考文献所列的地址出口；本族另有 BIP-142 曾提出 Base58 方案，现已关闭。

BIP-16：P2SH。见证程序可以原生出现，也可以嵌套进 P2SH 输出出现，两种触发方式都写在本 BIP 里。

再往前看问题来源：BIP-62 用规范签名处理可塑性。本 BIP 在动机里逐条比较后认为，把签名移出交易哈希是比规范签名路线更彻底的解法。理解本族，先分清三层：共识（本篇）、签名摘要（143）、网络传输（144），不要把三份的规则混在一起。

三、它要解决什么

出发点是一个区分：交易的全部效果由什么决定？原文的回答是：由输出的消耗（花费）与新输出的创建决定。其他交易数据、尤其是签名，只用于验证区块链状态是否合法，不用于决定状态本身。

既然签名不决定效果，把它从被交易默克尔树承诺的交易结构里移出去，可以同时修好几件事。原文列了三组：

3.1 非自愿可塑性变得不可能

签名数据不再是交易哈希的一部分，签名方式怎么变，都不再影响交易标识。原文逐条对照规范签名路线（BIP-62）的优势：

只要全部输入都至少带一次 CHECKSIG 或 CHECKMULTISIG 类签名，任何脚本类型都不会被非自愿延展；
m-of-n 多签情形下，一笔交易要被延展需要 m 个私钥持有人同意，而不是 BIP-62 下的 1 个；
未知 ECDSA 签名可塑性也不会再造成非自愿延展；
可以无对手方风险地构造未确认交易依赖链，这是闪电网络等链下协议的重要前提。

3.2 签名传输变为可选

见证数据只在对等节点要验证交易时才需要，只查交易是否存在时可以不传。这减小了 SPV 证明的体积，同样带宽下 SPV 客户端能下载更多交易，对其隐私也可能有改善。

BIP-142

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-142
标题	Address Format for Segregated Witness
作者	Johnson Lau <jl2012@xbt.hk>
指定日期	2015-12-24
层级	Applications（应用）
类型	Specification（规范类）
状态	Closed（已关闭）
阅读版	https://bips.dev/142
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0142.mediawiki

二、放在哪一族

SegWit 地址格式族，是 BIP-141 落地时必须配齐的一块：共识定了见证程序长什么样，钱包之间还得有一种统一的地址写法，用户才能把“付给这个见证程序”说出口、写下来。

它与同族文档的关系：

BIP-141：隔离见证（共识层）。本 BIP 的地址只服务于它定义的 P2WPKH 与 P2WSH 两种输出，其 scriptPubKey 都是 OP_0 后跟一个推送：20 字节哈希或 32 字节哈希。

BIP-13：P2SH 地址格式。本 BIP 在理据中以它为参照：P2SH 地址 2012 年已定义，用见证嵌套进 P2SH 的过渡办法，多数既有钱包无须升级即可付给 SegWit 兼容钱包。

BIP-16：Pay to Script Hash。嵌套路线所依靠的机制；P2WSH 地址被原文类比为见证版的 P2SH 地址——前者只管付给单个公钥，后者可承载任意复杂的 SegWit 交易。

BIP-173：原生见证输出的 Base32 地址格式，被 BIP-141 列入参考文献。BIP-142 状态已关闭，今天的原生 SegWit 地址不应再按本页的 Base58 写法去构造，本页是为存档与对照而读。

三、它要解决什么

动机只有一句：为原生隔离见证交易定义标准收款地址，以推动这种更高效交易方式的早期采用。

背景在理据部分说得更细。BIP-141 给了两种用见证程序的方式：原生的 scriptPubKey（版本字节推送加见证程序推送，除此之外无他），与见证嵌套进 P2SH 的方式（scriptPubKey 外观是普通 P2SH 输出）。后者靠 BIP-13 已在 2012 年定义的 P2SH 地址即可过渡，多数现有钱包不用升级就能付款；但它占用更多区块空间，原文定位它只是让过渡更平滑的短期方案，最终所有用户都应转用更高效的原生见证程序为主要付款方式。

BIP-143

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-143
标题	Transaction Signature Verification for Version 0 Witness Program
作者	Johnson Lau <jl2012@xbt.hk>, Pieter Wuille <pieter.wuille@gmail.com>
指定日期	2016-01-03
层级	Consensus (soft fork)（共识（软分叉））
类型	Specification（规范类）
状态	Deployed（已激活）
阅读版	https://bips.dev/143
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki

二、放在哪一族

隔离见证（SegWit）共识族的核心配套文档之一。BIP-141 定义见证的共识层结构，本篇紧随其后，专门规定 0 版见证程序里的签名到底对什么数据负责。

同族关系：

BIP-141：隔离见证（共识层），本篇随它一同部署

BIP-144：隔离见证（对等服务），管见证数据怎么在节点间传输

BIP-147：处理哑栈元素可锻性，与本篇同属 segwit 部署包

再往后，Taproot 的签名摘要另由 BIP-342 一系规定，不沿用本篇算法；本篇只管 0 版见证程序。

三、它要解决什么

原有脚本系统的签名摘要算法（SignatureHash）有两个原文明确指出的弱点。

3.1 哈希量随交易规模平方增长

每验一个签名，都要把交易的一个子集序列化后做双重 SHA256，哈希量与交易大小成正比；一笔交易里签名操作（sigops）越多，整体验签成本按 O(n²) 增长。原文举例：普通 1 MB 区块在 2015 年的一般电脑上约 2 秒可验完，而一笔含 5569 个 sigops 的 1 MB 交易可能要 25 秒。这类构造会拖慢全网验证。

3.2 签名不承诺输入金额

原算法不把“这个输入花了多少钱”算进摘要。在线节点可以自己去查被花输出的金额，但离线签名设备（冷钱包、硬件钱包）不知道金额，就算不出确切的花费与手续费；要补这个信息，又得把整笔被花交易搬进来，与轻量、气隙（air-gapped）设备的目标相冲突。

在原脚本系统里直接修这两点，要么是硬分叉，要么只能对新操作码做软分叉且限制很多。隔离见证软分叉恰好提供了一个干净的切口：可以为见证程序另定一套脚本语义，未升级节点仍把这类输出看作“任何人可花”，不破坏原系统。

四、规则本身

4.1 新摘要的十个字段

新算法只适用于 0 版见证程序中的签名操作。摘要是对下列序列化结果做双重 SHA256：

BIP-144

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-144
标题	Segregated Witness (Peer Services)
作者	Eric Lombrozo <elombrozo@gmail.com>, Pieter Wuille <pieter.wuille@gmail.com>
指定日期	2016-01-08
层级	Peer Services（对等服务）
类型	Specification（规范类）
状态	Deployed（已部署）
阅读版	https://bips.dev/144
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki

二、放在哪一族

隔离见证（SegWit）的网络传输分册。BIP-141 在共识层定义见证结构、并要求未来区块对它作出承诺；本篇补上对等服务层：节点如何对外宣告自己支持见证、如何索要和转发见证数据。

同族关系：

BIP-141：隔离见证（共识层），定义见证本身

BIP-143：v0 见证程序的签名验证规则

BIP-145：getblocktemplate 的隔离见证更新，面向挖矿接口

本篇只管“线上怎么传”，不改变任何一笔交易是否有效。

三、它要解决什么

见证数据被分离出去之后，老的 tx 与 block 消息格式装不下它。若直接改老格式，不支持见证的旧节点会解析失败甚至误判；若另起一套完全平行的消息，又会让交易、区块以及所有处理原始交易的 RPC 都要做双份。

因此需要一套新机制，同时满足三点：

节点能宣告自己可以提供见证数据；
对方能按需请求“带见证”的交易与区块；
旧节点完全不受影响，仍按老格式收发无见证的数据。

这正是本篇要定义的：新序列化格式、新服务位、新的库存（inv）请求类型。

四、规则本身

4.1 带见证的交易序列化

P2P 协议新增一种交易序列化，在原有字段之间插入两个字节：

version（4 字节）之后是 marker（1 字节，必须为 0）与 flag（1 字节，必须非零）；
随后依次是输入数量、输入列表、输出数量、输出列表；
再后是 script_witnesses：每个输入各有一份见证结构；
最后仍是 lock_time（4 字节）。

见证结构本身是一个栈：先写元素个数（var_int），再逐个写“长度（var_int）+ 字节串”。见证份数不单独编码，由输入个数推定，顺序与输入一一对应；某个输入的见证为空时，编码为一个零字节。

设计上有三个刻意的安排：

marker 取 0，使不支持本篇的旧解析器绝不会把新格式误读成一笔合法交易（按旧格式读，它会变成“零输入、一输出”，解析不成立）；
不能只用一个 0x00 作标记，否则“零输入零输出”的空交易（某些测试中用到）会被误判为新格式，所以中间再加 flag 字节；
flag 可看作位向量，将来若要给交易附加更多未承诺数据，可以继续扩展。

若交易见证为空，必须使用旧序列化格式，不得用新格式。

BIP-145

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-145
标题	getblocktemplate Updates for Segregated Witness
作者	Luke Dashjr <luke+bip22@dashjr.org>
指定日期	2016-01-30
层级	API/RPC（接口）
类型	Specification（规范类）
状态	Deployed（已部署）
阅读版	https://bips.dev/145
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0145.mediawiki

二、放在哪一族

挖矿接口族中专为隔离见证打的补丁。getblocktemplate（GBT）是矿工与矿池向节点索要“待挖区块模板”的 JSON-RPC 接口，基础规范在 BIP-22（基础）与 BIP-23（矿池挖矿）；版本位与规则协商牵涉 BIP-9。

同族关系：

BIP-141：隔离见证（共识层），本篇是它在挖矿接口上的对应更新

BIP-22 / BIP-23：getblocktemplate 的原规范，本篇只做增补

BIP-144：隔离见证（对等服务），管节点间传输；本篇管节点与矿工之间的模板接口

三、它要解决什么

隔离见证实质改变了区块的结构：交易多出一份见证数据，区块的资源计量也从单纯的字节数变成“权重”。原文的动机说得很直接：区块结构变了，原来的 getblocktemplate 规范就不够用了；新的计量方式也必须能通过 GBT 正确传达给挖矿一方。

具体缺口有三处：

模板里没有字段告诉矿工“这个区块最多能装多少权重”；
模板中的交易条目分不清 txid 与包含见证的完整哈希，矿工无法正确组装；
见证承诺（witness commitment）需要放进 coinbase 交易，这个动作由谁做、放在哪个位置，原规范没有规定。

不补这三处，矿池软件就算连着支持 SegWit 的节点，也挖不出合规的见证区块。

四、规则本身

4.1 模板新增 weightlimit

模板对象新增一个可选键：

weightlimit（Number，非必填）：区块允许的总权重。

同时，“segwit”规则的启用方式被收紧：只要模板包含带见证数据的交易，模板的 “rules” 列表中就必须给 “segwit” 加上 “!” 前缀（表示强制规则）。

原文还留了向下兼容的口子：即便客户端提交的 “rules” 里没有 “segwit”，服务端也可以为老矿工生成不含见证的模板，此时 “segwit” 不加 “!” 前缀；但如果服务端在激活后已不能生成无见证模板，则必须在激活之前的 “vbavailable” 列表里就对 “segwit” 使用 “!” 前缀，让客户端提前知晓。

BIP-146

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-146
标题	Dealing with signature encoding malleability
作者	Johnson Lau <jl2012@xbt.hk>, Pieter Wuille <pieter.wuille@gmail.com>
指定日期	2016-08-16
层级	Consensus (soft fork)（共识（软分叉））
类型	Specification（规范类）
状态	Closed（已关闭）
阅读版	https://bips.dev/146
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0146.mediawiki

二、放在哪一族

可锻性（malleability）修复族的一员，处理的是“签名编码”这一路。它的前身是 BIP-62（处理可锻性）——原文致谢部分写明，本篇正是从那份已放弃的大提案中拆分出来的；先行的 BIP-66（严格 DER 签名）已以软分叉方式强制了签名编码格式。

同族关系：

BIP-62：处理可锻性的总提案，本篇与 BIP-147 都是从中抽出的单项

BIP-66：严格 DER 签名，本篇的两条规则都以它已经生效为前提

BIP-147：处理哑栈元素可锻性，与本篇并列的另一路修复

BIP-141：隔离见证；它让非见证交易之外的问题以另一种方式收敛，本篇的适用范围则同时覆盖见证前与见证脚本

三、它要解决什么

签名可锻性，是指网络上的任意中继节点在没有私钥的情况下，也能改动一笔交易里的签名、且改完仍有效。对非隔离见证交易，这会改变 txid，使建立在其上的未确认子交易随之失效；对隔离见证交易，txid 虽然不再受第三方可锻性影响，但 wtxid 仍会被改变，并可能降低紧凑区块中继（BIP-152）的效率。

BIP-66 强制严格 DER 编码之后，原文指出 ECDSA 签名还剩两个已知的可锻性来源：

3.1 ECDSA 本身的高 S 对称性

一个 ECDSA 签名里的 S 值，取其对曲线阶的“负数”（即用曲线阶减去 S）仍然是有效签名。也就是说，同一笔花费天然存在两个等价签名，任何人都可以把高 S 换成低 S（或反过来），交易随之变样。

3.2 失败签名的任意性

当签名在 OP_CHECKSIG 或 OP_CHECKMULTISIG 中验证失败时，脚本只是往栈上返回 FALSE 并继续执行。这个注定失败的签名可以填任何值——只要符合 BIP-66 的编码规则——于是它又成了一个可以随意改动的字节串。

本篇要用两条新共识规则，分别封死这两条路。

BIP-147

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-147
标题	Dealing with dummy stack element malleability
作者	Johnson Lau <jl2012@xbt.hk>
指定日期	2016-09-02
层级	Consensus (soft fork)（共识（软分叉））
类型	Specification（规范类）
状态	Deployed（已激活）
阅读版	https://bips.dev/147
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0147.mediawiki

二、放在哪一族

可锻性修复族中专治“哑元素”的单项文档。它和 BIP-11 讲的是同一个操作码的同一个历史包袱：OP_CHECKMULTISIG 验证时会多弹出一个栈元素，BIP-11 当年用 OP_0 占位绕过它；本篇则把这个占位从“习惯”升为“规矩”。

同族关系：

BIP-62：处理可锻性的总提案；原文致谢写明，本篇的 NULLDUMMY 规则即由 Peter Todd 最初提出、从 BIP-62 中抽出成文

BIP-146：处理签名编码可锻性，与本篇同源并列，但最终状态为 Closed

BIP-141 / BIP-143：本篇与它们共用同一次 segwit 部署（见第四节）

三、它要解决什么

OP_CHECKMULTISIG 与 OP_CHECKMULTISIGVERIFY 有一个由来已久的设计缺陷：它们在签名验证之后，还会额外消费一个栈元素，原文称之为哑元素（dummy element）。

问题在于，这个元素不被以任何方式检查：

它可以是任意字节，换成别的值，脚本照样有效；
于是任何中继节点都能在不持有私钥的情况下改动多签交易的这部分内容。

后果与一般的可锻性相同：对非隔离见证交易，会改变 txid 并使未确认子交易失效；对隔离见证交易，会改变 wtxid，并可能降低紧凑区块中继（BIP-152）的效率。

修复的思路不需要动操作码本身：只要在共识层规定“哑元素只许为空”，任意填充的空间就被彻底关掉。

四、规则本身

4.1 NULLDUMMY 规则

新共识规则名为 NULLDUMMY：OP_CHECKMULTISIG 与 OP_CHECKMULTISIGVERIFY 所消费的哑元素，必须是空字节数组；只要它不是空值，整个脚本立即判定为失败。

适用范围包括：

见证前（pre-segregated witness）脚本中的两个多签操作码；
BIP-141 所定义的 P2WSH（pay-to-witness-script-hash）脚本。

规则就这一条，没有例外表，也不需要新的操作码或新的签名格式。

BIP-148

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-148
标题	Mandatory activation of segwit deployment
作者	Shaolin Fry <shaolinfry@protonmail.ch>
指定日期	2017-03-12
层级	Consensus (soft fork)（共识（软分叉））
类型	Specification（规范类）
状态	Deployed（已激活）
阅读版	https://bips.dev/148
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki

二、放在哪一族

软分叉激活机制族中很特殊的一篇：它自己不引入任何新的协议功能，只负责“催”另一个部署生效。被它催的，是 BIP-9 版本位框架下名为 “segwit” 的既有部署——即 BIP-141、BIP-143、BIP-147 这一包规则。

同族关系：

BIP-16：P2SH，当年以预定旗帜日（flag day）方式激活；原文明确说本篇效仿的正是这种做法

BIP-9：版本位部署框架，既有 segwit 部署跑在它上面

BIP-149：隔离见证（第二次部署），同一作者的后续备选方案，针对“第一次部署到期仍失败”的情形

理解本篇，关键在于分清三层：功能（141/143/147）、部署窗口（BIP9）、以及本篇的强制信号规则。

三、它要解决什么

原文的动机部分先列了隔离见证的好处：扩大区块容量、修复交易可锻性、让脚本更容易升级等。随后点明处境：既有 segwit 部署自 2016 年 11 月 15 日启动、到 2017 年 11 月 15 日到期，采用的是矿工信号达到阈值才锁定、激活的常规路径；若信号迟迟不足，这套规则就会在到期时无声失效。

作者的希望写得很明确：最好是矿工响应本篇、赶在本篇真正生效之前就主动让 segwit 提前激活；否则，本篇将强制既有部署在 2017 年 11 月 15 日午夜之前完成激活。

办法不是再开一次新部署，而是改变“什么样的区块算数”：在本篇生效窗口内，不为 segwit 信号的区块会被运行本篇的节点直接拒绝。矿工若想让自己的区块被这部分节点接受，就只能信号——信号率被这样推上去，既有部署便按它自己的 BIP9 规则锁定并激活。

四、规则本身

4.1 先说清术语

原文所称的“既有 segwit 部署”，指使用位 1（bit 1）、运行于 2016 年 11 月 15 日至 2017 年 11 月 15 日之间的 BIP9 “segwit” 部署，目标是激活 BIP-141、BIP-143 与 BIP-147。

BIP-149

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-149
标题	Segregated Witness (second deployment)
作者	Shaolin Fry <shaolinfry@protonmail.ch>
指定日期	2017-04-14
层级	Consensus (soft fork)（共识（软分叉））
类型	Specification（规范类）
状态	Closed（已关闭）
阅读版	https://bips.dev/149
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0149.mediawiki

二、放在哪一族

激活机制族里的“备选方案”：它与 BIP-148 出自同一作者、指向同一个目标（让隔离见证落地），但处理的是不同的失败情形。

分工是这样划的：

BIP-148：在既有 BIP9 部署到期之前发力，以强制信号促成它在原窗口内锁定

BIP-149（本篇）：假设既有部署最终到期失败，则在其结束之后，再开一次全新的部署

被部署的内容本身没有任何变化，仍是那一包规则：

BIP-141：隔离见证（共识层）

BIP-143：v0 见证程序的签名验证

BIP-147：哑栈元素可锻性（NULLDUMMY）

本篇的正式定性是 UASF——用户激活软分叉（user activated soft fork）。

三、它要解决什么

原文的动机写得很坦白：尽管生态中很大一部分人希望激活这项软分叉，矿工却迟迟不愿为 BIP9 的 segwit 部署信号。若矿工信号这条路走不通，按原框架，部署会在 2017 年 11 月 15 日到期作废，此前数年的工作要从头再来。

本篇的回答是把主动权换到用户一侧：设计一个用户激活的软分叉，用带“保证锁定”（guaranteed lock-in）的版本位机制再部署一次 segwit——即便矿工信号不足，到超时点也会锁定。

这样安排的两个目的，原文都写明了：

给用户留出充足的准备时间，不再要求矿工绝对多数（supermajority）配合；
同时仍保留矿工提前激活（MASF）的可能：矿工若在新部署期间主动信号达标，可以走更快的老路。

参考实现还自带一道保险：原文写明，它在 2017 年 11 月 7 日之前拒绝在主网运行，在此之前只能用于测试网与 regtest。

四、规则本身

4.1 触发条件：只在失败之后

这是一次有前提的部署，原文给了两条硬约束：

只有当 BIP9-segwit 未能在 2017 年 11 月 15 日超时之前锁定或激活时，才应部署本篇；
本篇不得在 2017 年 11 月 15 日之前部署。

换句话说，它从设计上就排在既有部署之后，不与它抢跑。原文的理由部分也说明，开始时间特意设在 BIP9-segwit 超时之后，就是为了避开与旧节点之间的兼容问题。

BIP-15

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-15
标题	Aliases
作者	Amir Taaki <genjix@riseup.net>
指定日期	2011-12-10
层级	Applications（应用）
类型	Specification（规范类）
状态	Closed（已关闭）
阅读版	https://bips.dev/15
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0015.mediawiki

二、放在哪一族

收款标识易用性这一族：管的是付款方在掏钱之前，怎么把“付给谁”表达出来。它与 BIP-13 那类地址格式文档分工不同——地址格式解决机器编码，别名解决人记不住的问题。

原文在文档开头就自注了后继方向：BIP-70（支付协议）可被视为 Aliases 的替代方案。本页的价值在于它对各候选方案的逐项利弊分析，而不是任何一套被定下来的格式。

三、它要解决什么

用原版比特币付款，必须有一串形如 1Hd44nkJfNAcPJeZyrGC5sKJS1TzgmCTjjZ 的地址。问题是地址不好记——原文的类比是：若没有域名，上网就得逐个输入网站的 IP 地址。

于是目标是设计一个比特币别名系统：用好记的名字解析出收款地址。原文开宗明义地提醒：这是一次不易回头、影响深远的协议级改动，必须稳健、安全，最好一次做对——因此文档用大篇幅“仔细论证”，比较多套方案的性质，而没有草率选定一套格式。

四、规则本身

本 BIP 的主体是对五套候选方案的逐项评估。以下按原文顺序提炼。

4.1 FirstBits：拿区块链当地址簿

原理：地址一旦收到过付款就记录在链上，即可证明它存在过。把地址转成小写，取其前几个唯一字符作为别名。原文示例：布拉格 brmlab 黑客空间的地址 1BRMLAB7nryYgFGrG8x9SYaokb8r2ZwAsX，别名即 1brmlab；配合 Vanitygen（靓号生成器）还能刻意生成有意义的地址。给钱时只需给出别名，省去手敲全址、扫码或上网复制。

原文结论是拒绝，理由有三：

能生成的别名受算力限制，想要的完整别名往往只能近似，且耗能；
扩展性极差：每个索引／查询节点要跟踪有史以来的每个地址并快速查询，地址数量随网络效应急剧增长，方案将不可行；
基于部分默克尔根的轻客户端存不起全部地址，只能依赖可信第三方查询——这一点比其他问题更致命。

4.2 DNS TXT 记录

把别名到地址的映射放进域名的 TXT 记录（具体格式不在本文范围）。问题：

可用性：需要用户会配置 DNS 记录与相应工具；
安全性：DNS 按设计就是不安全的，同网络者可伪造记录；DNSSEC 自 1990 年代起一直在修补与推广，但截至 2011 年 12 月仍非互联网事实标准，且不少注册商只提供网页界面，未必能配 DNSSEC；
更新慢：记录变更生效需要时间，这会促使人们不在每笔交易换新地址，带来安全问题。

4.3 服务器服务

用域名查主机、再连固定端口取地址：付款给 foo@bar.net 时，客户端先用 DNS 找到 bar.net 的 IP，再连其 4567 端口询问用户 foo 的地址，服务器返回地址或错误码后断开。映射的存储与修改由服务方自理，可配网页前端。

BIP-150

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-150
标题	Peer Authentication
作者	Jonas Schnelli <dev@jonasschnelli.ch>
指定日期	2016-03-23
层级	Peer Services（对等服务）
类型	Specification（规范类）
状态	Closed（已关闭）
阅读版	https://bips.dev/150
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0150.mediawiki

二、放在哪一族

P2P 网络身份与隐私族的一篇，与它的前置文档是一对：

BIP-151：对等通信加密。本篇的认证必须跑在它建立的加密通道之上——原文第一条规范就写明，加密会话未建立，不得开始认证。

两者之后，这条路线由 BIP-324（v2 P2P 加密传输协议）以另一套设计承接；本篇与 BIP-151 的状态均为 Closed。

在本篇内部，认证解决的问题不是“数据会不会被偷看”（那是加密的事），而是“对面到底是不是我以为的那个节点”。

三、它要解决什么

原文的设想从节点运营者的两个需求出发：

运营者想把某些节点服务只开放给选定的一部分节点，或给它们更高的数据流优先级；
节点要向特定对方广播交易、向对方请求过滤等可能泄露敏感信息的操作，运营者需要先确认对面确实是目标节点，而不是中间人（MITM）攻击者。

原文列出的认证收益包括：

连接已知节点时能识破中间人攻击；
把耗资源的交易过滤只开放给特定节点；
把可能导致节点指纹暴露的敏感信息（如手续费估算）只给认证过的节点看；
允许向已认证节点使用自定义消息类型（私有扩展）。

难点在于隐私：认证过程本身不能变成一种“探测”工具——随便连上来问一句，就能试出对方是不是某个身份。整篇规范的哈希问答设计，都是为了在证明身份的同时不给指纹识别留机会。原文同时明说：本篇不做“首次使用即信任”（TOFU），身份公钥必须事先通过其他渠道交换。

四、规则本身

4.1 前提与总则

方案基于椭圆曲线密码的 ECDSA，秘密（私钥）永不在线路上传输；
认证只能在 BIP-151 的加密通道建立之后开始，认证会用到加密通道的会话 ID（encryption-session-ID）；
身份公钥必须预先通过另一渠道共享（邮件/PGP、纸面交换等），本篇不覆盖公钥的首次分发；
认证状态保持到加密/连接终止为止；一条连接只允许一次认证，要重新认证必须重建连接。

4.2 两份本地名单与身份密钥

每个支持认证的节点要维护两份可由用户编辑的“数据库”：

known-peers：已知的身份公钥，连同网络标识（IP 与端口），作用类似 OpenSSH 的 known-hosts 文件；
authorized-peers：被授权的身份公钥名单，认证通过后能访问哪些受限服务，由它决定。

本地身份密钥为 ECC 密钥（私钥 32 字节），一个节点可以配置多把。原文特别提醒：每个网络接口（IPv4、IPv6、Tor）应使用各自独立的身份密钥，否则可能把某个 Tor 地址与某个 IP 地址关联起来。

4.3 双向认证的四步问答

认证要求双方互相认证，全程只交换哈希与签名，不直接亮出公钥：

请求方发送 AUTHCHALLENGE（哈希）；
应答方回 AUTHREPLY（签名）；
请求方发送 AUTHPROPOSE（哈希）；
应答方再发 AUTHCHALLENGE（哈希），请求方再回 AUTHREPLY（签名）。

三个消息的构造都有防探测设计：

BIP-151

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-151
标题	Peer-to-Peer Communication Encryption
作者	Jonas Schnelli <dev@jonasschnelli.ch>
指定日期	2016-03-23
层级	Peer Services（对等服务）
类型	Specification（规范类）
状态	Closed（已关闭）
接替文档	Proposed-Replacement: BIP-324
阅读版	https://bips.dev/151
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0151.mediawiki

二、放在哪一族

P2P 网络隐私族里管“加密”的那一篇。它有一篇直接的下游与一个正式的后继：

BIP-150：对等节点认证。认证必须建立在加密通道之上，用的正是本篇协商出的会话 ID；本篇只管把通道变密文，管不了“对面是谁”。

BIP-324：v2 P2P 加密传输协议。本篇档案序言明确记有 Proposed-Replacement: 324——本篇的接替文档。加密节点流量这件事，最终是沿着 324 那套设计落地的，不是沿着本篇。

读本篇的价值，在于看清 2016 年这套方案的设计取向：机会性、按连接选择、只加密选定的一部分对等连接，而不是把全网流量一刀切地改掉。

三、它要解决什么

原文的出发点：比特币节点之间的通信在当时完全不加密。由此带来两类问题：

安全上，链路上的第三方可以操纵流量（例如拦下某些命令），通信双方却无从察觉；
隐私上，大规模监控与分析变得很容易：网络服务商或任何中间人可以轻易识别出某个比特币用户、其掌控的地址与密钥，甚至与该用户的其他网络身份关联起来；一笔刚创建并广播的交易，其金额与收款方在链路上就是明文。对 SPV（轻）节点，这类影响尤为显著，也会削弱单个节点的抗审查能力。

原文也坦承边界：即便加密，报文的大小、发送间隔等特征仍在，按流量特征分析通信类型依然可能；比特币的信任模型也让这类风险在多数场景下不算致命——但“能显著抬高针对性分析的成本”本身就是目标。

已有的替代办法——VPN、Tor、stunnel、curveCP 等更低层级的加密机制——对 SPV 节点与常见的 DHCP/NAT 环境并不实用，搭建门槛也高。本篇要给出的，是一个节点软件内建、上手成本低的加密选项，且只加密选定的一部分远端节点连接。

四、规则本身

4.1 总则：双向各自协商

支持加密的节点必须接受来自所有节点的加密请求；
两个通信方向要各自独立做一次 ECDH 协商，因此一条双向连接使用两把对称密钥，一方向一把；
只有两个方向都协商成功之后，双方才可以发送加密消息；
协商必须在向对方发送任何其他消息之前启动；version 消息之后才到的 encinit 消息应被忽略。

4.2 密钥推导：ECDH + HKDF

双方各自生成临时（ephemeral）会话密钥对，交换公钥后用 ECDH 算出共享秘密，再用 HKDF（RFC 5869，哈希为 SHA256）推导：

提取：PRK = HKDF_EXTRACT(salt="bitcoinecdh", ikm=ecdh_secret || cipher-type)；把密码套件类型也算进输入，是为了防弱密码套件攻击；
派生两把 32 字节密钥：K_1 用 info=“BitcoinK1”，K_2 用 info=“BitcoinK2”；
同时派生 256 位的会话 ID：SID = HKDF_EXPAND(info="BitcoinSessionID", L=32)，供 BIP-150 把加密会话与身份认证关联起来。

分工上，K_1 只用来加密报文的长度字段，避免从明文长度泄露消息大小；K_2 与 Poly1305 配合构成 AEAD（带认证的加密）来保护正文。

BIP-152

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-152
标题	Compact Block Relay
作者	Matt Corallo <bip152@bluematt.me>
指定日期	2016-04-27
层级	Peer Services（对等服务）
类型	Specification（规范类）
状态	Deployed（已部署）
阅读版	https://bips.dev/152
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki

二、放在哪一族

区块中继与网络效率族的核心文档。比特币节点之间转发新区块时，传统做法是把整块连同每一笔交易全文发出去；BIP-152 改的只是“线上怎么传”，不改区块本身长什么样。

它与相邻文档的关系：

BIP-130：sendheaders 消息。低带宽模式下，新区块仍先按 BIP-130 的 inv/headers 方式公告，再由接收方主动索取紧凑区块

BIP-141 与 BIP-144：隔离见证的共识层与对等服务层定义。紧凑区块的第 2 版专门为见证交易而设，短 ID 改用 wtxid 计算

理解 BIP-152，是理解现代节点为何能在带宽尖峰小得多的情况下仍然快速同步新区块的起点。

三、它要解决什么

原文 Motivation 指出，历史上的 P2P 协议在中继区块时非常浪费带宽：区块里的每一笔交易都被完整包含，哪怕其中绝大多数在区块被中继之前就已经到达过接收节点（它们早已在各地节点的内存池里传播过一轮）。

后果有两层：

接收区块时，节点会出现中等程度的入站带宽尖峰；
若某节点比它的对等节点先收到区块，它要把整块再转发出去，出站尖峰会非常显著。

尖峰一旦引发缓冲膨胀（buffer bloat），家用网络会暂时近乎不可用，还会拖慢向远端对等节点的转发——对方可能宁可等，也不愿重复请求同一区块。因此，降低区块中继的带宽占用，对大量个人节点运行者直接有用。

原文特意说明：本工作的目标明确不是降低区块传输延迟，但作为副作用，它在若干重要情形下确实降低了延迟，并为后续专门面向低延迟中继的工作打下基础。

四、规则本身

4.1 两种模式：高带宽与低带宽

协议按对等关系与带宽条件分两种用法，由 sendcmpct 消息的第一个布尔值切换：

高带宽模式（置 1）：发送方直接用 cmpctblock 消息公告新区块，附带短交易 ID，甚至可以在完整验证区块之前就发出（只要求区块头已核验等条件，见 4.5）。接收方若本地已有全部交易，一次往返都不需要即可重建整块；缺交易时走一轮 getblocktxn/blocktxn 补齐，最好情形延迟与旧流程的 1.5×RTT 下限相同，但带宽省得多。此模式只能对少数对等节点开启（见 4.5）。
低带宽模式（置 0）：仍按 BIP-130 用 inv/headers 公告（且在完整验证之后），接收方再用 getdata 请求 MSG_CMPCT_BLOCK（类型值 4）索取紧凑形式；缺交易时再多一轮补齐，最坏到 2.5×RTT，但带宽仍远低于传整块。原文指出，由于 TCP 传大数据时延迟往往更差，即便走到 2.5×RTT，总延迟预期仍会下降。

4.2 线上传的是什么

新增四个数据结构：

BIP-154

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-154
标题	Rate Limiting via peer specified challenges
作者	Karl-Johan Alm <karljohan-alm@garage.co.jp>
指定日期	2017-04-12
层级	Peer Services（对等服务）
类型	Specification（规范类）
状态	Closed（已关闭）
阅读版	https://bips.dev/154
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0154.mediawiki

二、放在哪一族

对等网络的抗拒绝服务（anti-DoS）与连接管理一族。它不处理交易、区块或地址的传播格式，只处理一件事：当一个节点的入站连接名额成为稀缺资源时，凭什么决定谁能占用。

原文文件头没有 Replaces、Requires 等关系字段，也没有指定前后任文档；它的自洽性很强——挑战的用途标识符（Purpose Identifier）目前只定义了“建立对等连接”一种，原文预想未来可为布隆过滤等同样有 DoS 风险的操作再增加用途，但那属于设想，并未在本 BIP 中定义。

同族的参照是节点既有的连接上限与驱逐逻辑：BIP-154 是在那套逻辑之上加一道“付费插队”的门，而不是替换它。

三、它要解决什么

原文 Motivation 给出的前提是：比特币网络的连接数有上限（原文写作入站与出站合计最多 125）。用一批傀儡节点把连接打满既 trivial 又便宜，后果有二：

节点为了接纳新连接，不得不驱逐已有的其他节点；
节点之间彼此建立连接的能力被严重削弱。

网络处在这种受压状态时，就容易进一步遭受女巫攻击（Sybil attack）等后续攻击。

设想的对策是：受压时，节点仍可接纳新连接，但要求来访对等节点先完成某种工作量证明（proof of work），以证明自己不是在简单地刷连接。攻击者此时必须为“免费槽位之外”的每一个连接真实付出算力，女巫攻击的成本被大幅抬高。

但这里有一个关键约束：不能直接套用比特币区块所用的双 SHA256 工作量证明。因为攻击者可用专用硬件（ASIC 等 SPH）极大加速求解；若为了抵消这种加速而提高证明权重，普通节点在通用硬件（桌面电脑等 GPH）上又要付出不可接受的代价。因此原文另行引入对专用硬件不那么敏感的工作量证明算法，并说明：此事不涉及共识，将来可以再增加其他 POW 算法。

四、规则本身

4.1 两种槽位：免费与付费

支持本机制的节点设定两个上限：连接总数（入站上限由此减去出站与 feeler 连接数得出），以及 POW 连接槽位数——即入站连接中有多少个名额必须凭工作量证明换取。其余名额即“免费连接槽位”，照旧先来先得。

4.2 握手流程：先发挑战，再断开

节点须能处理两种新消息：challenge（挑战）与 solution（解答）。握手顺序被小幅改动：

连接方可以在 version 消息之前先发一个 solution；
若该解答满足本地节点的要求，就给予连接；若不满足（未知、错误等），本地节点发一个新的 challenge 并关闭连接；
若连接方没有先交解答、而该连接又被标记为需要 POW，本地节点同样发 challenge 并关闭连接。

注意这套流程是“发完挑战就断开”：解不解、解完是否重连，都由收到挑战的节点自行决定——它也可以丢弃挑战，去找别的对等节点，或者等对方空出免费槽位。

BIP-155

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-155
标题	addrv2 message
作者	Wladimir J. van der Laan <laanwj@gmail.com>
指定日期	2019-02-27
层级	Peer Services（对等服务）
类型	Specification（规范类）
状态	Deployed（已部署）
阅读版	https://bips.dev/155
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0155.mediawiki

二、放在哪一族

节点地址发现与 gossip（地址传播）一族。它接续的是既有的 addr 消息：节点靠互相转告“我知道这些节点在这些网络端点上”，新节点才能逐步找到可连接的对等节点，无需永远依赖少数种子。

BIP-155 不是推翻 addr，而是给它配一个 v2 继任者。旧 addr 把一切端点塞进固定的 16 字节地址字段（洋葱地址靠 OnionCat 方式嵌进 IPv6 形式），装不下新一代网络的长地址；addrv2 用“网络 ID + 变长地址”的结构把这个上限打开，同时保留与旧对等节点的兼容路径。

原文文件头没有 Requires、Replaces 等关系字段——它与旧 addr 的关系是并行兼容、按对端能力选用，而不是在文件头层面声明取代。

三、它要解决什么

原文 Motivation 聚焦一个具体的装不下问题：

Tor v3 隐藏服务自 Tor 0.3.2.9 起进入稳定版，相比旧版隐藏服务有更好的加密与隐私特性，但它的地址是 256 位的，塞不进现有 addr 消息——旧消息把洋葱地址封装在 OnionCat IPv6 地址里，地址字段只有 128 位。

不止 Tor：I2P 等其他传输层协议历来就使用更长的地址。地址 gossip 不过去，意味着这些网络上的节点无法经 P2P 网络被其他对等节点发现和连接，哪怕节点软件本身支持走这些网络出站。

BIP-156

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-156
标题	Dandelion - Privacy Enhancing Routing
作者	Brad Denby <bdenby@cmu.edu>, Andrew Miller <soc1024@illinois.edu>, Giulia Fanti <gfanti@andrew.cmu.edu>, Surya Bakshi <sbakshi3@illinois.edu>, Shaileshh Bojja Venkatakrishnan <shaileshh.bv@gmail.com>, Pramod Viswanath <pramodv@illinois.edu>
指定日期	2017-06-09
层级	Peer Services（对等服务）
类型	Specification（规范类）
状态	Closed（已关闭）
阅读版	https://bips.dev/156
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0156.mediawiki

二、放在哪一族

交易传播与网络层隐私一族。比特币的隐私短板不只在链上：一笔交易最初从哪个节点冒出来，本身就可能把交易与某个 IP 地址关联起来。BIP-156 处理的正是广播环节的去匿名化风险，与链上地址复用、金额关联等问题分属不同层面。

它的学术来源是 Dandelion 论文（原文 References 列有 Sigmetrics 2017 的 Dandelion 论文与 Sigmetrics 2018 的后续工作 Dandelion++ 论文，两者是研究文献，不是 BIP）。在本仓库内，原文文件头没有 Requires、Replaces 等关系字段；它与既有传播方式的关系是对照关系——既有的扩散（diffusion）是它要修补的对象，而不是它依赖的规范。

三、它要解决什么

3.1 扩散为什么会泄密

没有 Dandelion 时，一个节点生成交易后，会以相互独立的指数延迟把交易发给各个对等节点。学界称这种方式为扩散（diffusion）。原文 Abstract 与 Motivation 指出，这种传播在统计上是对称蔓延的：消息以源头为中心向四周散开，网络对手——尤其是布设了间谍节点、相互勾结的对手——可以据此把交易与源 IP 地址关联起来。

更糟的是指纹攻击（fingerprint attack）：若对手是掌握 P2P 网络拓扑的僵尸网络式对手（原文指出这种规模的僵尸网络常见且便宜，对手可用探测消息学到网络结构），它可以先离线模拟交易传播，为每个节点生成“指纹”，再把间谍节点实际观察到的传播轨迹与指纹比对。原文的模拟结论是：这类对手在每个节点平均观察不到十笔交易，就能对整个网络实现完全去匿名化。

BIP-157

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-157
标题	Client Side Block Filtering
作者	Olaoluwa Osuntokun <laolu32@gmail.com>, Alex Akselrod <alex@akselrod.org>, Jim Posen <jimpo@coinbase.com>
指定日期	2017-05-24
层级	Peer Services（对等服务）
类型	Specification（规范类）
状态	Deployed（已部署）
依赖文档	Requires: BIP-158
阅读版	https://bips.dev/157
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki

二、放在哪一族

轻客户端协议一族，是对 BIP-37 的反向重构。BIP-37 的模式是：轻客户端把自己的布隆过滤器发给全节点，全节点替它挑出匹配的交易。BIP-157 把方向倒过来：过滤器由全节点按块确定性生成、向所有人公开供应，筛选工作回到客户端自己手里做。

它与 BIP-158 是一对搭档，且依赖关系写进了文件头：BIP-157 定义协议流程（怎么索取、怎么验证过滤器），并 Requires BIP-158；BIP-158 定义过滤器本身的结构（装什么数据、怎么编码压缩）。只有 BIP-157 而没有具体的过滤器类型，协议是空的；原文因此把最初的过滤器类型放在 BIP-158 中单独定义。

原文在批评 BIP-37 的节点 DoS 问题时还引用了 BIP-111（NODE_BLOOM 服务位）所记录的背景，可一并参照。

三、它要解决什么

轻客户端的诉求是：不下载、不验证全部数据，也能读到与自己相关的链上交易，并尽量少信任对等节点、少耗带宽与存储。它的做法通常是先同步全部区块头、验工作量证明、跟随最长工作量证明链，再只取与自己有关的数据。

当时通行的轻客户端协议 BIP-37，原文列了三类已知的毛病：

隐私近乎为零：客户端要把盯着的地址、未花费输出等信息编成布隆过滤器交给全节点。原文引用的研究结论是，多数现成实现给钱包与应用的隐私保护实际上“virtually zero”——过滤器在隐私与误报率之间无论怎么调参，都要向对端交出大量信息；
安全可被蒙骗：恶意全节点可以干脆漏掉关键数据而极少被发现。对闪电网络客户端这类必须对某些链上事件及时作出反应的应用，这种遗漏不可接受；
全节点被反噬：用心构造的布隆过滤器能让诚实全节点付出可观的 I/O 与 CPU 代价，构成对全节点的拒绝服务向量，反过来让节点运营者不愿再支持该协议。

新协议的解法是把关系反过来（见第二节）：全节点生成确定性过滤器，客户端下载过滤器后在本地比对，命中才下载整块。确定性带来三个好处：过滤器只需构造一次并存盘，供应成本低，消除了 BIP-37 式的不对称消耗；客户端能自行校验过滤器的正确性，比检查“对方有没有漏发”容易得多；整块可以从任意来源下载，没有任何单个对端能掌握客户端到底关心什么，隐私更好。

四、规则本身

4.1 过滤器类型与服务位

为兼顾可扩展性与体积，协议允许多种过滤器类型：类型决定过滤器里装哪些区块数据、以及构造与查询的方法，每种类型以一个字节的代码标识。全节点为每个区块、为每种自己支持的类型各生成一个过滤器，并可用服务位宣告自己支持哪些类型。最初的类型由 BIP-158 定义，并分配了一个服务位来宣告对它的支持。

4.2 过滤器头：一条可以自查的承诺链

设计借用了区块头的“headers-first”思路。如同区块头以默克尔承诺绑定块内交易，原文定义过滤器头（filter header）来承诺区块过滤器，且每个过滤器头还承诺前一个过滤器头：

某个过滤器的规范哈希，是其序列化字节的双重 SHA256；
过滤器头是 32 字节，等于“过滤器哈希拼接前一个过滤器头”再作双重 SHA256；
创世块所用的“前一个过滤器头”定义为 32 字节全零。

客户端可以先把整条链的过滤器头下载并核对，再下载过滤器本体。若多个对等节点给出的过滤器头链不一致，客户端能定位到最初分叉的那一个块，下载该整块、自行算出正确过滤器，从而判定哪个对端在作恶或出错。原文结论是：只要至少有一个诚实对端，轻客户端就能识别出正确的区块过滤器。

BIP-158

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-158
标题	Compact Block Filters for Light Clients
作者	Olaoluwa Osuntokun <laolu32@gmail.com>, Alex Akselrod <alex@akselrod.org>
指定日期	2017-05-24
层级	Peer Services（对等服务）
类型	Specification（规范类）
状态	Deployed（已部署）
依赖文档	Requires: BIP-157
阅读版	https://bips.dev/158
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0158.mediawiki

二、放在哪一族

轻客户端紧凑过滤器一族，是 BIP-157 协议的另一半：BIP-157 规定轻客户端如何向全节点索取过滤器、如何用过滤器头互相校验；BIP-158 规定过滤器这个数据结构本身——每个区块要收进哪些条目、用什么数学结构装、参数取多少。文件头里两篇互相 Requires，缺一不可。

它也是对 BIP-37 布隆过滤器的替代构造：同样回答“某个条目在不在这个区块里”这类成员查询，但换了数据结构与使用方向。BIP-37 是客户端定制过滤器、由节点代查；本篇是节点为每个区块生成一份固定过滤器、供所有客户端下载自查。原文附录 A 专门记下了为何放弃布隆过滤等备选编码：同样的误报率下，布隆过滤器的体积比本篇的 Golomb 编码集更大，这是被否掉的主因。

三、它要解决什么

BIP-157 定的协议需要一种按块确定的过滤器：对同一个区块，任何人独立构造都得到同一份字节；且要尽量小，因为轻客户端为同步钱包，需要把大量区块的过滤器都下载回来——过滤器本身的大小加上因误报而多下载的整块，共同决定总带宽。

原文 Motivation 说得很收敛：本文件为 BIP-157 的轻客户端协议定义最初的一种过滤器类型 basic，其设计目标就是压低普通钱包场景下的过滤器体积。采用的结构是 Golomb 编码集（Golomb-coded set，GCS）：用 Golomb-Rice 编码压缩一组条目的哈希值，以概率结构换体积——集合内的条目必然命中，集合外的条目以 1/M 的概率误报命中，其中 M 是可调参数。

四、规则本身

4.1 Golomb 编码集怎么构造

每个区块的过滤器，是把与该块相关的一组数据条目压成一个 GCS。构造分四步（细节以原文伪代码为准）：

哈希映射：用 SipHash（参数固定为 c=2、d=4，密钥 k 为 128 位）把每个原始条目哈希为 64 位整数，再均匀映射到区间 [0, N×M) 内，其中 N 是条目数、M 是目标误报率的倒数。映射用“乘以区间长度后取 128 位乘积的高 64 位”的办法代替取模，避免昂贵的除法。查询时的误报率即为 1/M；N 与 M 都必须小于 2^32 以防溢出。
排序：把映射后的整数按升序排列。
作差：逐个计算相邻值之差（delta）。由于哈希值均匀分布，这些差值近似服从几何分布。
Golomb-Rice 编码：把每个差值拆成商与余数：商以一元编码写出（q 个 1 后跟一个 0），余数以 P 位大端写出，其中 P 是余数编码的位长参数。几何分布的数据用这种编码能得到最优压缩。

查询时按相反顺序逐个解码差值、累加还原出已排序的哈希集合，再把待查条目以同样方式哈希后比对；因为集合有序，解码值一旦超过目标即可提前终止，也不必把整个解压结果同时放进内存。若要一次查多个条目，还可把查询集同样哈希排序后与解压流并行比对，效率更高（原文附录 B 给了伪代码）。

BIP-158 紧凑区块过滤器基础代码合并进主分支

Mon, 01 Jan 0001 00:00:00 +0000

项目	内容
日期	2018-08-26
首次发布	Bitcoin Core v0.18.0
合并 PR	#12254
合并提交	`254c85b6`
影响范围	P2P
相关 BIP	BIP-158

事实摘要

PR #12254 合入了 BIP-158 的 Golomb 编码集合（GCS）过滤器构造代码，可为每个区块生成基本型紧凑过滤器，供轻客户端下载后本地匹配交易、无需向服务器交出所关注的地址。该 PR 只包含过滤器构造基础，过滤器索引与 RPC、网络服务在此阶段尚未提供。此代码未进入 v0.17.0，经核对标签源码，首次随 v0.18.0 发布。

关键链接

BIP-159

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-159
标题	NODE_NETWORK_LIMITED service bit
作者	Jonas Schnelli <dev@jonasschnelli.ch>
指定日期	2017-05-11
层级	Peer Services（对等服务）
类型	Specification（规范类）
状态	Deployed（已部署）
阅读版	https://bips.dev/159
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0159.mediawiki

二、放在哪一族

服务位（service bit）与节点能力宣告一族。比特币节点在握手与地址传播时用一组服务位说明自己能提供什么服务，其他节点据此决定连谁、向谁要什么数据。既有的 NODE_NETWORK 服务位只表达一种能力：“我能提供全部历史区块”。

BIP-159 在这套宣告体系里补上缺失的一档：能力有限但并非无用。它的直接同类是更早的 BIP-111（NODE_BLOOM 服务位）——同样是用一个新服务位把一类节点的真实能力如实说出来，让需要服务的对端自行取舍，而不是靠试错去发现。

原文篇幅很短，文件头也没有 Requires、Replaces 等关系字段：它只定义一个新服务位及其使用纪律，不改动任何既有消息的格式。

三、它要解决什么

原文 Motivation 的起点是裁剪节点（pruned peer）的尴尬处境。裁剪节点为了节省磁盘，只保留最近一段时间的区块数据，但除此之外——中继新区块、区块头、交易与地址——它与传统全节点能提供的服务并无不同。

问题出在宣告环节：当时只有 NODE_NETWORK 一个服务位表示“能提供全部历史区块”。于是出现两难：

裁剪节点如实不置 NODE_NETWORK，它在对端眼里就近乎“什么都提供不了”，难以被选中连接，它的中继能力被白白浪费；
它若置上 NODE_NETWORK，则是虚假宣告，向它索取深层历史区块的节点必然扑空。

原文列出的两点诉求因此是：第一，裁剪节点应有办法宣告自己“能提供有限但明确的服务”；第二，已完成初始区块下载的节点，应当可以把一部分出站连接名额留给裁剪节点，让其他对端把宝贵的连接留给能提供全链数据的未裁剪节点去完成自举同步。把有限能力如实标签化，整个网络的连接资源才能分工。

四、规则本身

4.1 新服务位：bit 10，最低保证 288 个区块

本 BIP 新增的服务位是：

NODE_NETWORK_LIMITED：bit 10（0x400）。置位即承诺：该节点必须有能力提供至少最近 288 个区块——原文括注约合 2 天的区块量。

与之配套的宣告纪律是：裁剪/受限节点不得置任何表示“能提供完整区块链”的服务位（例如 NODE_NETWORK）；而反过来，能提供完整区块链的节点也可以同时置 NODE_NETWORK_LIMITED——原文特意用一条 Rationale 说明，这个方向的叠加是允许的。

4.2 使用纪律：缓冲、地址中继与防指纹

原文 Specification 的其余部分都是围绕这个服务位的使用纪律：

重组缓冲：连接到置 NODE_NETWORK_LIMITED 的对端时，应计入 144 个区块的安全缓冲，以应对链重组——即不要把对方的可用深度恰好用到 288 的极限上；
地址中继：遵循本 BIP 的全节点，应当中继自己愿意连接的对端的地址与服务信息（addr 消息），包括置 NODE_NETWORK_LIMITED 的对端。否则有限节点宣告了能力，却在地址传播中被过滤掉，宣告便没有意义；
防指纹对策：不同裁剪节点的裁剪深度各不相同（取决于配置与磁盘空间），若如实按各自深度提供区块，对手可用 getdata 请求逐段试探出一个节点的确切裁剪深度，形成指纹识别弱点。因此裁剪节点不应泄漏自己的裁剪深度，并且不应提供比 288 这个宣告阈值更深的区块。

4.3 风险：谁需要检查服务位

原文 Risks 一节把代价与注意事项说清：

BIP-16

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-16
标题	Pay to Script Hash
作者	Gavin Andresen <gavinandresen@gmail.com>
指定日期	2012-01-03
层级	Consensus (soft fork)（共识（软分叉））
类型	Specification（规范类）
状态	Deployed（已激活）
阅读版	https://bips.dev/16
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki

二、放在哪一族

P2SH（Pay to Script Hash，付给脚本哈希）族的核心文档。它要解决的问题承接自多签一脉：

BIP-11：M-of-N 标准交易，让多签交易能被默认转发与打包；

BIP-13：P2SH 的地址格式，让脚本哈希能写成普通人可用的地址。

BIP-16 本身取代了 BIP-12（OP_EVAL）——后者想用一个新操作码实现同样的事、且能做的更多，最终被认为过于复杂、扩张脚本语言能力的风险太大。

同一目标当时还有两个竞争或平行的写法：BIP-17（OP_CHECKHASHVERIFY，CHV）主张换一个操作码实现 P2SH；BIP-18（hashScriptCheck）则在协议相同的前提下重写了表述方式。最后被采用的是 BIP-16 这一版定义，BIP-17 状态为 Closed。读这段历史，关键是分清“目标相同”与“机制不同”：三份文档都想让收款方定义花费条件，分歧在具体怎么改验证规则。

三、它要解决什么

原文给出的目的只有一句话，却决定了之后十几年钱包的形态：把“提供赎回条件”的责任，从付款人转移到赎回人（收款方自己）。

在 P2SH 之前，付款人要往一个复杂脚本（比如 2-of-3 多签）付款，就必须拿到完整的花费条件、构造对应的输出脚本。条件越复杂，付款一方的负担越重，地址也越长、越难处理。

P2SH 之后，付款人只需要一个固定长度的 20 字节哈希：短到可以扫 QR 码、可以轻松复制粘贴。无论背后的条件多复杂——多签、时间锁、组合条件——对付款人来说都只是同一个长度的哈希。复杂的脚本由收款方保管，等他真正花费时再出示。

作者也承认这一动机当时有争议：有人认为没有必要，直接把完整脚本给付款人即可。作者的回应是：哈希化能最大限度复用已经建好的“向 Base58 编码的 20 字节地址付款”的整套基础设施（商户、交易所、钱包软件），让多签等功能更快落地。

四、规则本身

4.1 新的标准交易类型

定义一种会被转发、会被矿工打包的新标准输出形式：

OP_HASH160 [20-byte-hash-value] OP_EQUAL

其中 [20-byte-hash-value] 必须是压入 20 字节的操作码（0x14）后跟恰好 20 字节。这个 20 字节值，就是赎回脚本（redeemScript）序列化后的哈希。

4.2 怎么花费

花费这种输出的 scriptSig 形如：

BIP-17

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-17
标题	OP_CHECKHASHVERIFY (CHV)
作者	Luke Dashjr <luke+bip17@dashjr.org>
指定日期	2012-01-18
层级	Consensus (soft fork)（共识（软分叉））
类型	Specification（规范类）
状态	Closed（已关闭）
阅读版	https://bips.dev/17
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0017.mediawiki

二、放在哪一族

P2SH（付给脚本哈希）之争中的一方，与 BIP-16 正面竞争。

三份文档目标完全相同：让收款方用一个 20 字节哈希指定“这笔钱将来要满足什么脚本才能花”，付款人只付给哈希。分歧只在实现机制：

BIP-12（OP_EVAL）：新增一个能“执行栈上脚本”的操作码，能力最强，也被认为最危险；
BIP-16：不加操作码，认出一种特殊形式的 scriptPubKey 后做额外两阶段验证；
BIP-17（本页）：重定义既有的 OP_NOP2 为新操作码 OP_CHECKHASHVERIFY，只核对哈希、不“执行”被哈希的那段脚本——原文 Rationale 明说它意在取代 BIP-12 与 BIP-16 这两种“验完哈希再求值脚本”的路线。

配套关系与另外两方相同：应用场景来自 BIP-11 的 M-of-N 多签，地址格式用 BIP-13。结局是 BIP-16 被采用、本页关闭；其后 BIP-18 又进一步把表述重写，但走的仍是 BIP-16 的协议。

三、它要解决什么

动机与 BIP-16 原文几乎逐字相同，因为要解决的是同一个问题：

把“提供赎回条件”的责任，从付款人转移到赎回人。 这样付款人无论面对多复杂的花费条件，都只需要处理一个固定长度的 20 字节哈希：短到可以扫 QR 码、可以轻松复制粘贴。

同样，原文也记录了争议：有人认为复杂与多签交易直接把完整脚本给付款人即可，不必多此一举；作者的立场是哈希化能最小改动既有“向 20 字节地址付款”的基础设施，让商户、交易所与软件更快支持多签。

所以 BIP-17 的独立价值不在“要不要 P2SH”，而在“用哪种机制实现 P2SH 更安全、更干净”——它试图避开“把栈上数据当脚本执行”这一步。

四、规则本身

4.1 新操作码 OP_CHECKHASHVERIFY

它重定义既有的 OP_NOP2，执行时：

取“先前脚本的末尾部分”——一般即 scriptSig，自最后一个被求值的 OP_CODESEPARATOR 起（没有 OP_CODESEPARATOR 则自脚本开头；没有先前脚本则哈希空字符串）——计算其哈希；
与栈顶元素比较：栈为空则脚本立即失败；
哈希相符则什么都不做、如同 OP_NOP 继续执行；不符则脚本立即失败；
关键细节：相符时栈顶的哈希不弹出——这是为向后兼容保留的动作。

该操作码重定义只适用于时间戳在 2012 年 2 月 23 日之后的区块中的交易验证。

BIP-171

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-171
标题	Currency/exchange rate information API
作者	Luke Dashjr <luke+bip@dashjr.org>
指定日期	2017-03-04
层级	Applications（应用）
类型	Specification（规范类）
状态	Closed（已关闭）
阅读版	https://bips.dev/171
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0171.mediawiki

二、放在哪一族

应用层的外部数据接口一族。它不属于 P2P 网络协议，也不属于链上规则，而是管“链外世界的数据怎么以统一格式喂给钱包软件”：钱包想给用户显示一个法币计价，就需要向某个行情服务器查询汇率，BIP-171 想把这类查询的请求与应答格式标准化。

原文文件头没有 Requires、Replaces 等关系字段。它在概念上与本 BIP 中定义的计价单位 XBT 相连——原文把 XBT 定义为 100,000,000 satoshis（即通常所说的 1 BTC），并要求一切比特币金额的查询都以 XBT 为单位提出，哪怕最终展示给用户的单位不同。

三、它要解决什么

原文 Motivation 写得很直白：终端用户经常希望在比特币钱包软件里看到法币计价的信息。但由于比特币的性质，汇率天然不存在任何权威来源：提供这类信息的独立服务方有很多，却各用各的格式。结果是钱包软件被迫为每一个行情提供方写一套专门的对接代码。

标准接口的意义在于一次实现、处处互通：钱包（及其他软件）与服务提供方只要各自实现一遍本规范，就立刻能与所有其他兼容实现互操作。换言之，它要消除的是“每个提供方一种方言”的重复劳动，而不是去指定汇率本身应该是多少、该信哪一家。

原文的 Rationale 还解释了两个格式细节的设计理由：多条结果之间用换行符分隔而不是 JSON 数组，是为了让客户端可以把历史数据简单地追加进缓存文件，也能逐行解析而不必把整批数据读进内存组成一个对象；长描述中需要换行时，则借 JSON 本身的转义（\n、\n\n）表达，不破坏逐行结构。

四、规则本身

4.1 通用约定

四种请求全部以 GET 方式发往一个共同 URI，参数用 application/x-www-form-urlencoded 编码。所有匹配参数都可以用逗号分隔的多个值表示，含义是“其中任意一个”。应答一律是 JSON 格式，多条结果之间用换行符（LF，绝不用回车）分隔。

其他通用规则：

订阅制服务的认证可以用标准 HTTP 认证；原文建议使用 TLS（HTTPS）和/或 Linked Data Signatures，以免中间人欺骗客户端；应答中的 signature 字段即为 Linked Data Signatures 预留；
一台声称兼容 BIP-171 的服务器，必须至少支持一个与 XBT 比价的货币对；
货币对的标记（token）是任意字符串，最长 255 字符，只能用 RFC 3986 的非保留字符（字母数字及连字符、下划线、句点、波浪号）；
货币代码以 ISO 4217 代码为准，XBT 特别定义为 100,000,000 satoshis；没有现成代码的货币可用超过 3 字符的字符串，无代码又想要短代码的，可以在左侧补空格补到 4 字符，软件可以剥掉这些空格；
汇率（rate）的定义是：兑换一个单位基础货币所需计价货币的数量，即 1 baseCurrency = rate quoteCurrency。

4.2 请求一：列举支持的货币对（mode=list）

参数可带 quote、base、locale 作过滤（服务器可以据此收窄结果）。每条结果是一个 JSON 对象，含货币对标记 cp、计价货币 quote、基础货币 base、可选的适用 locale、可选的简短描述 desc（建议短于 45 字符），以及可选签名。

BIP-172

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-172
标题	Define Bitcoin Subunits as Satoshis
作者	OceanSlim <oceanslim@gmx.com>
指定日期	2025-05-01
层级	Applications（应用）
类型	Informational（信息类）
状态	Draft（草案）
阅读版	https://bips.dev/172
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0172.mediawiki

二、放在哪一族

货币单位命名一族。它处理的是纯粹的人类语言问题：比特币最小单位早就存在于协议里（1 BTC 可分到小数点后八位），但这个单位叫什么、复数怎么写、缩写用哪个，长期靠社区习惯，没有一份正式定义。BIP-172 要补的正是这份定义。

同族的两个近邻，原文在 Rationale 中专门逐一作了对比：

BIP-176：Bits 计价单位——主张把 100 satoshis（0.000001 BTC）定为一个中间单位 bits

BIP-177：重定义比特币基本单位——主张更激进地把“bitcoin”一词改指今天所说的 1 satoshi

BIP-172 与两者的分界在于：它既不新设中间单位，也不改动 “bitcoin” 的既有含义，只把社区已经在用的最小单位名称正式登记下来。自称是三者中扰动最小的路线。

三、它要解决什么

原文 Motivation 指出，随着比特币采用面扩大，为子单位准备一套清晰、标准化的术语越来越重要。而眼下的现状是：指同一个最小单位（1/100,000,000 BTC），市面上同时流通着 “satoshi”、“satoshis”、“sat”、“sats” 等多种写法，有时干脆只写成 BTC 的小数值（0.00000001 BTC）。

术语不统一的代价，原文列了四条：

新进入比特币生态的人容易被搞糊涂；
不同应用与服务之间的用户体验不一致；
技术文档与讨论中产生歧义；
开发与实现比特币相关软件时可能出错。

把 “satoshi/satoshis” 定为标准词、把 “sats” 定为公认缩写，目标就是在沟通、界面、文档与开发各环节消除这层摩擦。

原文 Rationale 补了两层理由。其一，这个单位与名称都不是新发明：中本聪定下 1 bitcoin 可分到八位小数、即每 bitcoin 含 100,000,000 个单位；社区则已自发用 “satoshi” 称呼这个最小单位，本 BIP 是把既有惯例正式化，而不是引入新词。其二，随着比特币计价变高，用 BTC 小数表达小额越来越别扭、易错（原文举例：0.00000546 BTC 对照 546 sats，后者对人更直观）。其三，它类比了法币的两级面额体系——如美元与美分——并指出 “sat” 与 “cent” 发音相近，能给熟悉传统货币的人搭一座直觉的桥。

BIP-173

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-173
标题	Base32 address format for native v0-16 witness outputs
作者	Pieter Wuille <pieter.wuille@gmail.com>, Greg Maxwell <greg@xiph.org>
指定日期	2017-03-20
层级	Applications（应用）
类型	Informational（信息类）
状态	Deployed（已部署）
替代文档	Replaces: BIP-142
接替文档	Proposed-Replacement: BIP-350
阅读版	https://bips.dev/173
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki

二、放在哪一族

地址格式族，紧接隔离见证（SegWit）落地。它替代先前的 BIP-142（见证地址的早期方案），为 BIP-141 定义的见证程序（witness program）提供一套可直接使用的原生地址编码。

与它直接相关的文档包括：

BIP-141：隔离见证（共识层定义见证程序）

BIP-143：见证交易的签名校验，其中给出 P2WPKH 与 P2WSH

BIP-350：Bech32m，对本篇校验和的后续修正，被列为 Proposed-Replacement

BIP-13 与 BIP-16：Base58 时代 P2SH 地址的来路，本篇要改进的对象之一

今天以 bc1q… 开头的原生 SegWit 地址，编码规则就出自本篇；以 bc1p… 开头的 Taproot 地址则已改走 BIP-350 的 Bech32m。

三、它要解决什么

比特币长期使用 Base58 地址，校验和是截断的双重 SHA256。原文列出它的几处局限：

Base58 不能使用二维码的 alphanumeric 模式，在二维码里占空间；
大小写混合，不便手抄、在移动键盘上输入或口头念出；
双重 SHA256 校验慢，且没有明确的检错保证；
58 不是素数的幂（prime power），多数纠错码研究不直接适用；
Base58 解码本身也相对复杂、较慢。

SegWit 引入了一类新输出——见证程序。把见证程序嵌进 P2SH 也能用，但效率与安全性不是最优；直接使用原生见证输出，需要一套为它准备的新地址格式。BIP-173 提出带校验和的 Base32 格式 Bech32，并在此之上定义 v0–16 见证输出地址。

BIP-174

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-174
标题	Partially Signed Bitcoin Transaction Format
作者	Ava Chow <me@achow101.com>
指定日期	2017-07-12
层级	Applications（应用）
类型	Specification（规范类）
状态	Deployed（已部署）
阅读版	https://bips.dev/174
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki

二、放在哪一族

钱包协作与离线签名族的核心格式文档。在它之前，“造一笔未签名交易、交给多方依次签名”没有统一格式，各家钱包实现互不相通；BIP-174 把这件事标准化，此后多签、硬件钱包与气隙（air-gapped）签名才有了共同语言。

它建立在既有概念之上，并为后续扩展留了登记机制：

BIP-32：分层确定性钱包，PSBT 中的派生路径与主密钥指纹按它定义

BIP-143：SegWit 签名哈希，原文在签名者校验一节中讨论其与 UTXO 提供方式的关系

新字段与新版本须另写 BIP 并登记到本篇配套的类型注册表（type registry），本篇是 PSBT 版本 0 的定义文档。

三、它要解决什么

3.1 多方接力签名缺少共同格式

创建未签名或部分签名的交易、在多个签名者之间传递，原先是实现相关的：用不同钱包软件的人很难把同一笔交易传下去签名、再把签名合并。本篇目标是给出一个标准且可扩展的格式，让不同客户端能传递同一笔待签交易。

3.2 离线签名者拿不到 UTXO

签名需要知道所花费的 UTXO。若签名设备是离线的硬件钱包或气隙钱包，它无法自己查 UTXO 集。本格式把签名所需的全部信息装进交易文件本身，离线签名者不必直连 UTXO 集，也降低被欺骗的风险。

四、规则本身

4.1 总体结构：键值映射

PSBT 是二进制格式，由若干键值映射（map）组成：

<psbt> := <magic> <global-map> <input-map>* <output-map>*
<magic> := 0x70 0x73 0x62 0x74 0xFF

魔术字节是 ASCII 的 psbt 加分隔符 0xFF，刻意让普通交易解析器无法把它当普通交易解析，反之亦然。每张映射由若干键值对组成，以 0x00 字节结尾。键由键长度、键类型与键数据组成，同一映射内键必须唯一，出现重复键的 PSBT 无效。

BIP-175

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-175
标题	Pay to Contract Protocol
作者	Omar Shibli <omar@commerceblock.com>, Nicholas Gregory <nicholas@commerceblock.com>
指定日期	2017-07-17
层级	Applications（应用）
类型	Informational（信息类）
状态	Closed（已关闭）
阅读版	https://bips.dev/175
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0175.mediawiki

二、放在哪一族

分层确定性钱包的派生应用族。它不另造钱包体系，而是站在三份既有文档之上：

BIP-32：分层确定性钱包，提供扩展公钥与派生路径

BIP-43：Purpose 字段，本篇据此固定用途值为 175'

BIP-44：Coin type 字段，本篇的币种层与它一致

学理来源是 Ilja Gerhardt 与 Timo Hanke 提出的同态支付地址与多方 Pay-to-Contract 协议，本篇把该派生方案写成可实现的规范。

三、它要解决什么

一笔比特币交易在现实世界里往往对应一份合同：谁付给谁、为什么付。传统商业里靠发票与收据追踪付款；付款人签字确认发票，收款人交付货物。

问题是：光看链上地址，看不出这笔钱对应哪份合同。Gerhardt 与 Hanke 的思路是让地址本身可被证明地派生自“合同条款＋收款方公钥”——任何拿到合同与支付基公钥的人都能重算地址、核对这笔付款到底绑的是哪份合同。

原文强调两点性质：这种派生不膨胀 UTXO 集，且对网络其他参与者完全隐形——派生出的地址看起来与普通 P2(W)PKH 或 P2(W)SH 地址没有区别；要花这笔钱，需要同时知道合同内容与收款方私钥。

四、规则本身

4.1 角色与流程

需要两方：付款人（customer）与收款人（merchant）。

付款人向收款人提交购买请求，说明要买的商品或服务；
收款人据此构造发票（即合同），列明计费项与总金额；
收款人把合同连同“支付基”扩展公钥（payment base）交给付款人；
付款人按合同与支付基生成付款地址公钥，把资金发到该地址。

付款本身即构成付款人的收据：商家要动用这笔资金，就必须按同一合同与支付基重建私钥路径，等于默认接受了合同条款。

4.2 派生路径结构

m / purpose' / coin_type' / contract_hash

Purpose：常量 175'（即 0x800000AF），按 BIP-43 的建议固定， hardened 派生；
Coin type：与 BIP-44 同名字段相同，hardened 派生；
Payment base：m / purpose' / coin_type' 对应的扩展公钥；
Contract hash：由合同文档算出的一段多层路径（见 4.3），拼在支付基之后得到付款地址。

4.3 由合同生成地址

给定合同文档 c1…cn、支付基扩展公钥与哈希函数 h：

BIP-176

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-176
标题	Bits Denomination
作者	Jimmy Song <jaejoon@gmail.com>
指定日期	2017-12-12
类型	Informational（信息类）
状态	Complete（已完成）
阅读版	https://bips.dev/176
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0176.mediawiki

二、放在哪一族

计价单位与术语族，只管“怎么称呼金额”，不管协议。它与几个既有单位同处一把尺子上：

satoshi（聪）：最小单位，1 BTC 的一亿分之一；
bits（本篇）：100 聪，1 BTC 的一百万分之一，即 µBTC；
mBTC（毫比特币）：1 BTC 的千分之一；
BTC：基本计价单位。

同族的另一次尝试是 BIP-177（重定义比特币基本单位），它在原文中明确把本篇列为要反驳的替代方案——两篇放在一起读，正好看到“换小单位计价”与“直接把基本单位改成最小单位”两种思路的分歧。

三、它要解决什么

比特币价格涨高之后，小额用 BTC 表示会拖出一长串小数。原文举例：当 BTC 为 15,000 美元时，10.05 美元写成 0.00067 BTC 很容易看错一位、差出十倍；写成 670 bits 就清楚得多。反过来也一样：“1 美元约 59 bits”比“1 美元约 0.000059 BTC”更容易理解，与日元、韩元等货币做双向比较也更顺。

原文归纳的预期好处包括：

减少小额金额上的用户出错；
缓解“非要拥有整数个比特币”的单位偏见（unit bias）；
让多数人更容易比较价格；
与法币的双向换算更容易；
所有 UTXO 金额用 bits 表示时至多需要 2 位小数，处理起来更简单。

四、规则本身

4.1 定义

1 bit = 100 satoshis = 1/1,000,000 BTC

复数形式为 “bits”；
“bit” 与 “bits” 不是专有名词，除句首等情形外不应大写。

4.2 使用建议

所有以比特币计价的条目，都鼓励同时以 bits 标示金额——或设为默认单位，或至少提供为可选项。这是一条鼓励性建议（encouraged），不是强制要求。原文在向后兼容一节明确：像 Bitcoin Core 图形界面这类已用 µBTC 计价的软件可以继续用，没有义务切换到 bits；µBTC 一词也可与 bits 并存。

BIP-177

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-177
标题	Redefine Bitcoin's Base Unit
作者	John Carvalho <bitcoinerrorlog@gmail.com>
指定日期	2025-04-23
类型	Informational（信息类）
状态	Draft（草案）
阅读版	https://bips.dev/177
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0177.mediawiki

二、放在哪一族

计价单位与术语族，与 BIP-176（Bits 计价单位）正面对位。本篇用整整一节反驳 BIP-176：认为用 bits 只是把小数换了个层级，没有消除小数思维；本篇主张一步到位——直接把最小单位改名为 bitcoin 本身。

它针对的现行惯例是：1 bitcoin = 100,000,000 个基本单位（日常称这基本单位为 satoshi／sat）。本篇要改的只是称呼与显示，不是账本：原文反复强调账本与共识规则不变、链上数据不变、BTC 代码不变。

三、它要解决什么

现行惯例要求用户面对八位“人造小数”：账本里其实只有整数个基本单位，小数点纯粹是人为加的抽象。原文认为这带来几个问题：

容易让人误以为比特币天生是十进制的；
小额显示拖着一串零，认知负担大、容易算错；
新人从一开始就建立了与协议真实记账方式不一致的心智模型。

把基本单位直接定为 “1 bitcoin”，显示值就与链上值一一对应：协议怎么记，用户就怎么看。原文给出的理由还包括整数运算更简单、教育上更清楚，以及一步到位后不必随价格上涨再不断新增单位。

四、规则本身

4.1 单位重定义

内部基本单位本身不变；
历史上 1 bitcoin = 100,000,000 个基本单位；按本提案，1 bitcoin 就等于 1 个基本单位；
原来所说的 “1 bitcoin”，在新定义下对应 100,000,000 bitcoins；
总量观感随之变化：基本单位总数约 2.1 quadrillion（千万亿量级），原文指出这只是表示方式的变化、不改变供给，并类比日元、印尼盾等高单位数货币并不被视为通胀。

4.2 术语

非正式称呼 “satoshi” 与 “sat” 被废弃（deprecated）：所有引用、界面与文档应把基本单位简称为 “bitcoin”；
原文同时承认，本篇管不住任何人私下继续用任何口头称呼，它规定的只是如何“正确地”把比特币的唯一单位显示为 bitcoin；
货币代码 BTC 不受影响，继续指 100,000,000 个基本单位。

原文专节交代了 sat 的来历：为纪念创造者而生、后来成为文化符号（“stacking sats”）。作者认为它虽有文化价值，却引入了与本篇目标相悖的第二层计价。

BIP-178

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-178
标题	Version Extended WIF
作者	Karl-Johan Alm <karljohan-alm@garage.co.jp>
指定日期	2018-04-04
层级	Applications（应用）
类型	Specification（规范类）
状态	Draft（草案）
阅读版	https://bips.dev/178
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0178.mediawiki

二、放在哪一族

私钥导入导出与地址类型族。WIF（Wallet Import Format）是把单个私钥写成可复制字符串、在钱包之间搬运的传统格式；本篇不改 WIF 主体，只动它末尾的标志字节，目标是让私钥与“它该用哪种地址”一起旅行。

它与地址格式的演进直接挂钩：同一把私钥能对应 P2PKH、嵌套 SegWit 与原生 SegWit 等不同地址，其中原生 SegWit 的 Bech32 格式见 BIP-173，嵌套方式涉及 BIP-16 的 P2SH。地址类型越多，WIF 不标类型的代价就越大——这正是本篇的出发点。本篇基于 Thomas Voegtlin 在 bitcoin-dev 邮件列表的初始提议与 Electrum 3.0 的实现，原文致谢一节有明确交代。

三、它要解决什么

同一把私钥可以关联多种地址：传统的 P2PKH（1…）、把 SegWit 公钥嵌进 P2SH 的 P2SH-P2WPKH（3…）、原生 SegWit 的 P2WPKH（Bech32）等等。

现行 WIF 只有一个 1 字节尾缀，用来表示对应公钥是压缩（尾缀 0x01）还是未压缩（无尾缀），没有办法说明这把私钥当初关联的是哪一种地址。后果是：导入私钥时，钱包只能假设所有类型都有可能，并逐一追踪每种可能的地址，既费资源，也容易让用户困惑——钱明明在其中一种地址里，钱包却要把几种都查一遍。

把这个尾缀扩展一下，让它顺带说清地址类型，导入就能一步到位。

四、规则本身

4.1 尾缀编码表

私钥数据仍是 uint256，其后的可选 uint8 标志被扩展为下表（扩展类型一律为压缩公钥）：

尾缀值	类型	含义
无尾缀	P2PKH_UNCOMPRESSED	未压缩传统公钥，公钥格式未知
`0x01`	P2PKH_COMPRESSED	压缩传统公钥，公钥格式未知
`0x10`	P2PKH	压缩公钥，只对应传统 P2PKH（`1…`）
`0x11`	P2WPKH	压缩公钥，只对应 Bech32 原生 SegWit
`0x12`	P2WPKH_P2SH	压缩公钥，只对应嵌套在 BIP-16 P2SH 里的 SegWit（`3…`）

4.2 导入时的两种结果

私钥用的是旧类型（无尾缀或 0x01）：钱包仍须按老办法，把各种地址类型都纳入追踪；
私钥用的是扩展类型（0x10／0x11／0x12）：钱包只需追踪那一种对应地址。

原文特别区分 0x01 与 0x10：前者可以对应上表任何类型，后者只对应传统 P2PKH，二者不可混为一谈。

BIP-179

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-179
标题	Name for payment recipient identifiers
作者	Emil Engler <me@emilengler.com>, Luke Dashjr <luke+bip@dashjr.org>
指定日期	2019-10-17
类型	Informational（信息类）
状态	Complete（已完成）
阅读版	https://bips.dev/179
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0179.mediawiki

二、放在哪一族

术语与用户教育族，是全仓库最短的提案之一：它不提任何新格式、新字段或新规则，只给一个早已存在的字符串换个名字。同族的是 BIP-176（给 100 聪命名为 bits）这类“只动称呼”的文档——它们的共同点是：改的是人脑子里的模型，不是机器执行的协议。

本篇的词源在致谢里交代： “Bitcoin Invoice Address” 一词由 Chris Belcher 提出。地址格式本身的演进见 BIP-173 等文档，与本篇无关。

三、它要解决什么

比特币地址的设计意图是只用一次：每来一笔新付款，就应生成一个新地址。

但 “address（地址）” 这个词在日常生活里恰好暗示相反的性质：邮政地址、电子邮件地址、IP 地址（视服务商而定）——几乎所有叫“地址”的东西都很少变、甚至从不变。用户带着这种直觉使用比特币，就会自然地把一个地址存下来反复收款，与一次性使用的设计意图背道而驰。

本篇的动机就是把术语换成一个能暗示“只对应一笔交易”的词，让名字本身起教育作用。

四、规则本身

4.1 新术语

新词是：

Bitcoin Invoice Address

其中 “Bitcoin” 与 “Address” 两部分都是可选的；“Address” 后缀只应作为过渡步骤使用。由此得到四种合法说法：

Bitcoin Invoice Address
Bitcoin Invoice
Invoice Address
Invoice

定义：Bitcoin Invoice Address 是可用来表明一笔交易的预期接收方与用途的字符串——注意，这与今天所说的“地址”所指的东西完全相同，变的只有名字。

4.2 为什么保留两个可选部分

原文给出的理由分两边：

保留 “Bitcoin”：方便多币种钱包标明这属于比特币；也用来区分闪电网络发票（lightning invoice）与链上发票。

BIP-18

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-18
标题	hashScriptCheck
作者	Luke Dashjr <luke+bip17@dashjr.org>
指定日期	2012-01-27
层级	Consensus (soft fork)（共识（软分叉））
类型	Specification（规范类）
状态	Complete（已完成）
阅读版	https://bips.dev/18
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0018.mediawiki

二、放在哪一族

P2SH 族里最特殊的一份：它不提出新协议，而是给 BIP-16 的同一套协议换一副术语骨架。

原文 Rationale 写得很直白：本提案取代 BIP-12 与 BIP-17（两者都是给脚本系统做扩展、让 scriptPubKey 把验证外包出去）；同时也取代 BIP-16——因为 BIP-16“在协议上与本提案完全相同”，区别只是 BIP-16 给出了一种具体实现写法，且为了保持协议表述的一致性而没有宣布 scriptPubKey 过时；本提案则认为应当把旧名目正式废弃、新交易类型一律用新结构表达。

配套仍是同一组：应用场景来自 BIP-11 的 M-of-N 多签，地址格式用 BIP-13。读本页要抓住一句话：链上发生的事实与 BIP-16 是同一件，变的只是文档如何命名与组织这件事。

三、它要解决什么

动机部分与 BIP-16、BIP-17 相同：P2SH 的目的，是把提供赎回条件的责任从付款人转移到赎回人，让付款人用一个固定长度的 20 字节哈希（可扫 QR 码、可复制粘贴）为任意复杂的条件付款。

在此之上，本提案多解决一个“表述问题”：旧的交易结构里，输入端叫 scriptSig、输出端叫 scriptPubKey，两者都是“被执行的脚本”。而 P2SH 的实际结构已经不是这个形状了——输入端本质上是一包数据加上最后一段待检脚本，输出端本质上只是一个哈希承诺。继续套旧名字，会让规范读起来与实际验证流程对不上。因此本提案主张：旧名目宣布过时（客户端为兼容仍须支持，但新交易类型不再使用），改用三个新元素把结构说清楚。

四、规则本身

4.1 三个新元素

dataSig：放在交易输入中原 scriptSig 的位置，内容是多个序列化的数据元素，按“只压数据”的脚本方式编码；
scriptCheck：dataSig 的最后一个元素。它被执行时，dataSig 中在它之前的元素已预先压入栈（紧挨着它前面的元素位于栈顶）；
hashScriptCheck：放在交易输出中原 scriptPubKey 的位置，给出允许赎回该输出的 scriptCheck 的哈希。

相应地：兼容客户端必须继续支持 scriptSig 与 scriptPubKey（原文用大写 MUST），但新交易类型不应再使用它们；付款的服务与个人暂时仍应支持旧的基于公钥的地址，收款方也可以继续生成使用旧地址。

4.2 hashScriptCheck 的精确编码

必须恰好编码为：

0xa9 0x14 (20-byte-hash-value) 0x87

旧（BIP-18 之前）的客户端可以把这串字节解释成一条熟悉的旧脚本：

BIP-180

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-180
标题	Block size/weight fraud proof
作者	Luke Dashjr <luke+bip@dashjr.org>
指定日期	2017-03-17
层级	Peer Services（对等服务）
类型	Specification（规范类）
状态	Closed（已关闭）
阅读版	https://bips.dev/180
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0180.mediawiki

二、放在哪一族

轻客户端安全与对等网络协议族。轻客户端（SPV 客户端）只下载区块头、不验证全部交易，天然无法自己发现“这个区块其实无效”；欺诈证明（fraud proof）的思路是让全节点拿出可验证的证据，使轻客户端不必下载全块也能确信某块违规。

本篇只挑一种违规来证明：区块超出大小／重量上限。重量口径来自 BIP-141（SegWit 对区块重量的定义：剥离见证后的大小 × 3 ＋完整大小）。原文在答疑中说明为什么只做这一种：当时活跃的威胁正是矿工以超大区块强行推动硬分叉，而这一种违规恰好可被可靠证明、且证明无法在不破坏该次硬分叉尝试的前提下被攻破；对所有无效情形给出证明，当时被认为不可能。

三、它要解决什么

原文动机写得很直白：当时不断有人提出硬分叉扩大区块上限，在达不成共识的情况下，支持者常威胁并试图让矿工强行推行。

在当时的现状下，轻客户端根本无法检测无效区块：只要一条链工作量最大，它就可能被骗着接受这条由超大区块组成的无效链。有了区块大小欺诈证明，轻客户端就能保护自己的用户免受这种未经共识的“硬分叉”尝试——别人声称某块合法时，它可以要求对方拿出证明，或者接受诚实节点给出的超限证明并拒绝该链。

四、规则本身

4.1 核心思路：只证下界

证明不必给出区块的精确大小，只需给出一个可验证的下界：只要下界已经超过上限，区块必然无效。由此定义了几个概念：

完整交易大小证明（full tx size proof）：用 SHA2 的中间状态（midstate）加尾部数据，证明某笔交易完整数据的大小；
尺寸分量（size component）：或是一个默克尔链接及其在默克尔树中的高度，或是一个完整交易大小证明；
完整尺寸证明（full-size proof）：证明含见证数据时区块大小下界的一组分量；
剥离尺寸证明（stripped-size proof）：证明剥离 SegWit 见证数据后区块大小下界的一组分量。

其中 SHA2 能证明大小的原因，原文在答疑中解释：SHA2 最后一块必须在末尾写入输入数据的总长度，因此提交最后一块之前的 midstate、只重放最后一块，就能核对声称的交易大小与实际被哈希的数据是否一致，最终哈希即该交易的 txid 或见证哈希。

4.2 证明格式要点

证明依次包含：交易数量的 log2 量级、剥离尺寸证明的分量个数与各分量、各分量代表的交易数（同样以 log2 表达），完整交易大小证明还包括 256 位 midstate、交易总大小、最后一块大小（0–55）及其内容。剥离证明中普通交易按默认 60 字节计，完整证明则沿用剥离证明已确立的尺寸。

以 log2 表达交易数量，是为了防攻击：避免客户端被无法验证的虚报数量欺骗。证明中至少须含一个完整交易大小证明，以钉死交易总数不被虚增。

4.3 验证步骤（概要）

分别验证剥离尺寸证明与完整尺寸证明，得到各自的大小下界（lowStrippedSize、lowFullSize）；验证中要重建默克尔根并与区块头（剥离证明）或见证承诺（完整证明）比对，且不得有重复的默克尔链接；
在算得的交易数据下界上加上 80 字节区块头与交易计数变长整数的大小；
按重量公式算下界重量：完整大小下界＋剥离大小下界 × 3；
把下界重量与适用的区块重量上限比较，超过即证明该块超限。

原文说明：证明生成方应尽量用最少的数据凑出超限下界（通常是挑最大的几笔交易做完整大小证明，直到越过上限），但具体优化方式不作强制。

BIP-19

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-19
标题	M-of-N Standard Transactions (Low SigOp)
作者	Luke Dashjr <luke+bip17@dashjr.org>
指定日期	2012-01-30
层级	Applications（应用）
类型	Specification（规范类）
状态	Closed（已关闭）
阅读版	https://bips.dev/19
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0019.mediawiki

二、放在哪一族

M-of-N 多签标准交易族，是 BIP-11 的“同题竞争稿”。

BIP-11（2011，Gavin Andresen，状态 Deployed）已经把基于 OP_CHECKMULTISIG 的 M-of-N 交易定为标准。本页要解决的不是“能不能多签”，而是 BIP-11 路线的一个计量代价：每次 OP_CHECKMULTISIG 在区块签名操作（sigop）上限里按 20 次计，于是每区块最多只能装约 1,000 笔这类多签交易。

BIP-19 的办法是换一种拼法：不用 OP_CHECKMULTISIG，改用多个 OP_CHECKSIG——每个只计 1 次 sigop——把通过的签名数加总再与门槛比较，以同样的 M-of-N 语义换取更好的可扩展性（标题中的 “Low SigOp” 即指此）。

它与 P2SH 一族（BIP-16 等）是平行关系：P2SH 管“怎么把复杂条件藏进哈希”，本页管“多签脚本本身怎么写更省计量”。最终 BIP-11 的形式成为通行标准，本页状态为 Closed。

三、它要解决什么

动机场景与 BIP-11 相同，原文照录了两类用例：

3.1 受保护钱包（Wallet Protection Service）

采用 2-of-2：一把签名来自用户电脑上的钱包（可能已中毒），另一把来自钱包保护服务（WPS）。用户发起转账时，客户端把拟交易发给 WPS，由其再向用户确认是否本人发起、细节是否正确，双方都签才生效。原文同样提醒：用户应要求 WPS 提供所用私钥的备份并离线安全保存，以免服务商倒闭后资金被锁死。客户端与 WPS 的通信方式不在本 BIP 范围内。

3.2 三方托管（买方、卖方、仲裁方）

采用 2-of-3：买方、卖方、可信仲裁人各提供一个公钥，买方把币打入 2-of-3 输出并把交易 ID 告知另两方。履约顺利时卖方先签、买方联署，资金付给卖方；发生争议时，仲裁人与买卖任一方合作即可决定资金去向。三方如何交换公钥与签名，同样不在本 BIP 范围内。

BIP-197

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-197
标题	Hashed Time-Locked Collateral Contract
作者	Matthew Black <matthew@atomicloans.io>, Tony Cai <tony@atomicloans.io>
指定日期	2019-03-19
层级	Applications（应用）
类型	Specification（规范类）
状态	Draft（草案）
阅读版	https://bips.dev/197
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0197.mediawiki

二、放在哪一族

哈希时间锁合约（HTLC）应用族，定位是把 HTLC 从“跨链原子交换”推进到“跨链抵押借贷”。

原文在摘要里给出它的两条根：其一是 BIP-199（哈希时间锁合约 HTLC）的交易脚本思路；其二是 Atomic Loans 规范（一篇 arXiv 论文，本篇给出链接），本篇是该规范在比特币一侧的抵押合约部分。与之配套的还有另一条链上的哈希时间锁本金合约（HTLPC）：借款本金在那条被原文称为 principal blockchain 的链上发放，比特币这边只负责锁抵押品。

原文兼容性一节称，本篇与以太坊一侧的 ERC-1850（原子借贷）兼容，未来可扩展到其他支持 HTLC 与智能合约的链。

三、它要解决什么

设想一个债务安排：借款人有比特币，出借人有另一条链上的货币。借款人想以比特币作抵押，借出另一条链上的本金；出借人则需要保证：借款人不按期连本带息偿还时，自己能拿到约定比例的抵押品，而不是只能干等。

难点在于两条链互不感知：比特币脚本看不到另一条链上是否已还款。原文给出的办法，是用一组秘密（secret）与超时（timeout）把两条链上的合约状态推进绑在一起——在一条链上揭示某个秘密，既是推进那一侧状态的凭证，也解锁另一侧对应的路径。加上分阶段超时，合作时按约走完，不合作时各方也能按预先锁定的比例收回自己那份。

原文在动机一节概括：HTLCC 交易是一种用揭示秘密来结算债务协议状态的安全方式；面对不合作的对手方，能收回一定比例的抵押资金；面对合作的对手方，能确保本金＋利息＋清算费得到偿付。

四、规则本身

4.1 两组抵押脚本

抵押品不锁进一个脚本，而是拆进两个 P2SH，金额比例在锁定时预先约定，代表还款失败且不走清算时双方各自有权拿回的份额：

可退还抵押（Refundable Collateral）：偏向借款人的那一份；
可没收抵押（Seizable Collateral）：出借人在没收期可动用的那一份。

两组脚本结构相近，都是多层 OP_IF / OP_ELSE 分支：每条分支或要求揭示某个秘密（先用 OP_SIZE … OP_EQUALVERIFY 钉死秘密长度，再以 [HASHOP] 校验其哈希），或在某个超时之后允许单方签名花费，或要求借贷双方 2-of-2 多签（OP_2 <borrower pubkey> <lender pubkey> OP_2 OP_CHECKMULTISIG）配合秘密揭示。其中 [HASHOP] 可取 OP_SHA256 或 OP_HASH160，[TIMEOUTOP] 可取 OP_CHECKSEQUENCEVERIFY 或 OP_CHECKLOCKTIMEVERIFY。

BIP-199

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-199
标题	Hashed Time-Locked Contract transactions
作者	Sean Bowe <sean@z.cash>、Daira Hopwood <daira@z.cash>
指定日期	2017-03-27
层级	Applications（应用）
类型	Specification（规范类）
状态	Closed（已关闭）
阅读版	https://bips.dev/199
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0199.mediawiki

二、放在哪一族

脚本合约族，处在“用脚本条件换取原子性”的源头位置。BIP-199 把哈希时间锁定合约（Hashed Time-Locked Contract，HTLC）写成一份可复用的脚本模板：同一个哈希条件串起多笔支付，秘密一经公开，所有环节同时结算；秘密不公开，则各笔资金按超时各自退回。

它依赖的时间锁原语来自更早的提案：

BIP-65：OP_CHECKLOCKTIMEVERIFY，绝对时间锁

BIP-112：OP_CHECKSEQUENCEVERIFY，相对时间锁

原文明确点出的两大应用场景，是闪电网络的跨通道支付与零知识或有支付（Zero-knowledge contingent payments）。今天谈闪电网络的路由支付、原子交换时反复出现的 HTLC，脚本骨架正出自这一族。理解 BIP-199，是理解“为什么链下支付可以做到要么全成、要么全退”的起点。

三、它要解决什么

3.1 用秘密换钱，需要一条安全的结算通道

许多链下协议把“披露秘密”当作结算机制的一部分；在另一些协议里，秘密本身就是有价值的商品。问题在于：买方先付钱，卖方不交秘密怎么办？卖方先交秘密，买方不付钱又怎么办？

原文的回答是：HTLC 交易提供了一种安全而廉价的“以链换秘密”的方法——持有秘密的一方能在退款发生之前先拿到资金；对方不配合时，付款方也能把资金收回。交易不必做大、验证成本也不必做高。

3.2 闪电网络中的原子交换

原文以闪电网络为例：通道之间用 HTLC 脚本做原子交换。Alice 构造秘密 K 并哈希得到 L，她向 Bob 发起一笔“凭 L 的原像领取”的 HTLC 支付；Bob 再向 Carol 发起同一原像、同一金额的 HTLC 支付。

只有当 Alice 释放原像 K 时，价值交换才真正发生；秘密在每一跳被披露，各方随之得到补偿。任何一环不配合，流程都可以经由退款条件中止。

3.3 零知识或有支付

原文还举了零知识证明的用法：用零知识证明保证某个哈希原像确实能解出有价值的信息——例如，它是某个加密数独题解的解密密钥。HTLC 可以无风险地把这类解密密钥换成钱，且不需要体积大、验证昂贵的交易。

四、规则本身

4.1 脚本模板

HTLC 允许指定的一方（“卖方”）通过披露某个哈希的原像来花费资金；也允许第二方（“买方”）在超时到达后花费资金，即退款情形。脚本形式为：

OP_IF
    [HASHOP] <digest> OP_EQUALVERIFY OP_DUP OP_HASH160 <seller pubkey hash>
OP_ELSE
    <num> [TIMEOUTOP] OP_DROP OP_DUP OP_HASH160 <buyer pubkey hash>
OP_ENDIF
OP_EQUALVERIFY
OP_CHECKSIG

其中两个占位符可替换：

BIP-2

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-2
标题	BIP process, revised
作者	Luke Dashjr <luke+bip@dashjr.org>
指定日期	2016-02-03
类型	Process（流程类）
状态	Closed（已关闭）
替代	BIP-1
接替文档	Proposed-Replacement: BIP-3
阅读版	https://bips.dev/2
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki

二、放在哪一族

流程族的第二代文档。它替代 BIP-1，把初版里含糊的地方逐项收紧；文件头里又已标注 Proposed-Replacement 为 BIP-3，现行流程以 BIP-3 为准。

分层字段（Layer）来自 BIP-123 的分类——BIP-2 把 Layer 写进文件头模板，并注明启用本 BIP 即意味着启用 BIP-123。

读这一族要分清三件事：仓库收录、状态标注、网络实际采用。BIP-2 只管前两件的规矩，第三件由实现与用户自愿选择决定。

三、它要解决什么

BIP-1 定下了制度框架，但留了几个模糊点：

状态标准含糊：原文明确说，BIP-1 对 Status 的判定标准不明确、常引起困惑，结果是许多已有显著实际使用的 BIP 长期停在 Draft 或当时的 Accepted 状态，没有及时更新。
许可过时：BIP-1 只允许 Open Publication License 或公有领域。原文认为前者已过时、且允许作者阻止出版与衍生作品，不适合标准文档；后者在部分法域不被承认为有效的法律行为。
流程细节缺失：评论如何留、参考实现何时必须完成、编辑的检查清单等，都没有写细。

BIP-2 的目标不是另起炉灶，而是给同一套制度补上可核验的判定标准与更合适的许可清单。

四、规则本身

4.1 工作流（与 BIP-1 一脉相承的部分）

每份 BIP 须有 champion（牵头人／作者）：写文档、在合适论坛推进讨论、争取社区共识。
先查旧讨论，再到比特币开发邮件列表公开探路，避免重复已被否决的想法；小补丁不必写 BIP，直接走对应项目的开发流程。
草稿先在邮件列表讨论，再以 pull request 提交到 BIP 仓库；作者不得自行编号，入库前用别名（如 bip-johndoe-infinitebitcoins）作文件名。
一份 BIP 只讲一个核心想法；越聚焦越容易成功。
编辑不得无理拒绝；可拒绝的情形包括重复劳动、不守格式、过于发散、技术上站不住、缺动机说明或未处理向后兼容、违背比特币设计哲学。被接受的最低门槛是：描述清楚完整、构成净改进、实现（如适用）扎实且不过度复杂化协议。
所有权可以移交：原作者无暇、无兴趣或失联时可转给新 champion；仅仅不认同方向不是移交理由，不同意者应另写一份竞争性 BIP。

4.2 三类 BIP 与文件结构

类型仍为三类：Standards Track（标准类，影响多数或全部实现的改动，由设计文档与参考实现两部分组成）、Informational（信息类，提供指南或信息，不代表社区共识，用户可忽略）、Process（流程类，管协议之外的流程，通常需要社区共识，用户一般不能随意忽略；meta-BIP 属此类）。

BIP-20

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-20
标题	URI Scheme
作者	Luke Dashjr <luke+bip@dashjr.org>
指定日期	2011-01-10
层级	Applications（应用）
类型	Specification（规范类）
状态	Closed（已关闭）
接替文档	Proposed-Replacement: BIP-21
阅读版	https://bips.dev/20
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0020.mediawiki

二、放在哪一族

bitcoin: URI（支付链接）族的第一份正式文本。它基于 Nils Schneider 的一篇更早文档写成，原文开头即注明：本 BIP 已被 BIP-21 取代。

这条链条是：BIP-20（本页，语法最全也最重）→ BIP-21（砍掉备选金额写法、简化为十进制 BTC）→ 再后来由 BIP-321 接替 BIP-21。日常扫码付款、点链接付款用的都是这条线后代的形式；本页是这条线的源头档案，能看清最早的设计者想把多少功能塞进一条链接里——包括后来被一致认为不该留的东西。

与地址、多签等族不同，URI 族完全在应用层：它不碰共识、不碰脚本，只规定“一条付款请求链接应该长什么样、客户端拿到链接后必须怎么做”。

三、它要解决什么

目的很朴素：让用户点一下网页链接、或扫一下 QR 码，就能发起一笔付款，不用手抄地址、不用手输金额。

设计上有两条贯穿全文的立场，后来被 BIP-21 完整继承：

支付标识，不是个人标识：当时的最佳实践是每笔交易用一个新地址。所以 URI 表达的应是一次性付款，而不是某个人的长期身份信息。
名字本身要能自解释：方案名就叫 “bitcoin:”，路人看到也能猜出用途、搜得到资料；过于晦涩的名字会挡住新用户。

原文还专设 “Forward compatibility” 一节：希望 2011 年生成的 URI 到 2036 年还能用，所以要留足扩展余地；同时也写明这只是当下能做到的最好版本，不应被视为一成不变，后人应能在不打碎旧 URI 的前提下改进它。

四、规则本身

4.1 通用处理规则（原文标为“重要”）

客户端不得在未取得用户授权时对 URI 采取行动；
客户端应要求用户逐笔手动批准付款；在某些情形下，可以允许用户预先设定自动批准。

图形客户端应默认把自己注册为 “bitcoin:” 方案的处理程序（若尚无其他处理程序）；若已有，则首次运行时可以提示用户是否改选自己。

4.2 语法（BNF）

bitcoin:<address>[;version=1.0][?amount=<amount>][?label=<label>][?message=<message>][?send=<private key>]

正式文法中地址为 Base58 字符串，参数部分可包含：amount（金额）、label（收款方名称等标签）、message（扫码后展示给用户看的消息）、send（用于“发送”而非“请求”比特币），以及为将来扩展保留的其他参数。字符须正确做 URI 编码。

BIP-21

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-21
标题	URI Scheme
作者	Nils Schneider <nils.schneider@gmail.com>, Matt Corallo <bip21@bluematt.me>
指定日期	2012-01-29
层级	Applications（应用）
类型	Specification（规范类）
状态	Closed（已关闭）
替代	BIP-20
接替文档	Proposed-Replacement: BIP-321
阅读版	https://bips.dev/21
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki

二、放在哪一族

bitcoin: URI（支付链接）族的第二代，也是把这套写法真正定型的版本。

原文开头有两层交代，先看清位置：文件头注明“本 BIP 已被 BIP-321 取代，请改读 BIP-321”；正文则说明它是对 BIP-20 的修改——BIP-20 出自 Luke Dashjr、又基于 Nils Schneider 的更早文档，而本版把 BIP-20 的备选金额写法全部移除。

所以链条是：BIP-20（复杂全语法）→ BIP-21（本页，简化定型）→ BIP-321（现行接替文档）。与 BIP-20 同属应用层：不碰共识与脚本，只约定支付链接的写法与客户端的处理规则。今天扫码、点链接付款时见到的 bitcoin:<地址>?amount=…&label=… 基本形状，就定型于这一版。

三、它要解决什么

目的与 BIP-20 相同：让用户点一下网页链接、或扫一下 QR 码，就能轻松付款。

它要额外解决的是 BIP-20 留下的两个麻烦：

金额写法太多：十进制、十六进制、X 指数并存，同一金额有多种表达，解析与显示都容易出错、出歧义。简化为单一写法，才能让不同钱包对同一条链接算出同一个数。
扩展参数的进退没有规矩：将来必然要加新参数。老客户端遇到不认识的参数，是该整单拒绝还是忽略？若一律拒绝，新功能永远推不开；若一律忽略，关键参数被无声丢弃又会出事。需要一条事先约好的规则——这就是 4.4 的 req- 前缀机制。

同 BIP-20 一样，它坚持 URI 是“支付标识，不是个人标识”：每笔交易应使用唯一地址，链接表达一次付款，而不是某人的身份；方案名 “bitcoin:” 本身也要让路人看得懂、搜得到。

四、规则本身

4.1 通用处理规则（原文标为“重要”）

客户端不得在未取得用户授权时对 URI 采取行动；
客户端应要求用户逐笔手动批准付款；某些情形下，可允许用户预先设定自动批准。

图形客户端应默认把自己注册为 “bitcoin:” 方案的处理程序（若尚无其他处理程序）；若已有，首次运行时可以提示用户是否改选。

4.2 通用格式

URI 遵循 RFC 3986 的通用格式：路径部分是一个比特币地址，查询部分提供附加付款选项。

BIP-22

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-22
标题	getblocktemplate - Fundamentals
作者	Luke Dashjr <luke+bip22@dashjr.org>
指定日期	2012-02-28
层级	API/RPC（接口）
类型	Specification（规范类）
状态	Deployed（已部署）
阅读版	https://bips.dev/22
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0022.mediawiki

二、放在哪一族

挖矿接口（API/RPC）族的基础文档，与 BIP-23 是上下篇关系：

BIP-22（本页）：getblocktemplate 的基础——怎么请求模板、模板里有什么、怎么提交区块，外加可选的长轮询与模板微调；
BIP-23：在基础之上为矿池挖矿加的全部可选扩展（区块提议、可变项、提交缩略、逻辑服务等），并明确其所有章节都是对本页的可选增补。

规范内部还牵到两处其他 BIP：模板的 version 字段要求客户端理解所用版本的含义，如版本 2 须遵守 BIP-34（coinbase 中写入区块高度；coinbaseaux 一节也重申高度不经模板下发、由 BIP-34 要求写入）；Rationale 还专门说明，交易要下发 sigops 数据，是因为 BIP-16 改变了区块 sigop 的计数规则（要把 scriptCheck 里的也算进去），光看交易本身数不出来。

三、它要解决什么

原文 Motivation 给出两个背景：

其一，bitcoind 内置的 JSON-RPC 服务已经扛不住“生成可供有效挖矿的工作”所需的负载，专门生成工作的外部软件变得必要——挖矿软件与全节点开始分家。

其二，新的独立节点实现正在成熟，将来同样要能给矿工供活。

两边一分家，就必须有一套共同标准来传递“区块怎么构造”的全部细节，否则每种节点与每种工作生成软件之间都要单独适配。getblocktemplate 就是这个接口契约：全节点负责给出经它认可的区块材料，矿工与代理软件在此范围内组装、哈希、提交。

与更早的取活方式相比，关键变化写在摘要里：不再只发一个简单的区块头去哈希，而是把整个区块结构发过去，矿工可以（在允许范围内）自行定制与组装。

四、规则本身

4.1 请求模板：getblocktemplate

JSON-RPC 方法 getblocktemplate 只接受一个参数，且必须是请求参数对象。其中 mode 用于显式选择默认的 “template” 请求，或 BIP-23 定义的 “proposal”（区块提议）；请求还可带 capabilities 数组，声明客户端支持的能力，如 “longpoll”、“coinbasetxn”、“coinbasevalue”、“proposal”、“serverlist”、“workid” 以及 BIP-23 的各项可变项。

4.2 模板必含的字段

返回必须是一个 JSON 对象，关键字段包括：

BIP-23

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-23
标题	getblocktemplate - Pooled Mining
作者	Luke Dashjr <luke+bip22@dashjr.org>
指定日期	2012-02-28
层级	API/RPC（接口）
类型	Specification（规范类）
状态	Deployed（已部署）
阅读版	https://bips.dev/23
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0023.mediawiki

二、放在哪一族

挖矿接口族的扩展篇，是 BIP-22 的下篇：

BIP-22：getblocktemplate 基础（模板请求与字段、submitblock 提交、长轮询、模板微调）；
BIP-23（本页）：原文第一句规范说明就定调——本页所有章节都是 BIP-22 之上的可选扩展，专为矿池挖矿（pooled mining）增强。

它给矿池场景补了五组东西：基础矿池字段、区块提议（先验货再开工）、可变项清单（矿工到底能改模板的哪些地方）、提交缩略（少传字节的份额提交方式）、逻辑服务（把多台服务器当成一个服务来调度）。此外还划了支持等级：Level 1 要求实现 BIP-22 非可选部分与长轮询、本页基础扩展、以及 “coinbase/append”、“submit/coinbase”、“time/increment”（仅服务器）等条目；Level 2 再加 “transactions/add” 与区块提议。读实现声称的“支持 BIP-23”时，先对到这两档。

三、它要解决什么

动机直指矿池的权力结构：原文说，当时对挖矿过度集中于矿池、以及矿池握有的控制权，存在合理担忧。

老式的集中取活方式下，矿工拿到的只是待哈希的材料，区块里到底装了什么、coinbase 把钱付给谁，矿工无从过目。getblocktemplate 已经把整个区块结构暴露给矿工（见 BIP-22）；本页进一步要让矿工能在开哈希之前审查区块、并有可能动手修改它——审查与修改的权利，就是从矿池手里分回给矿工个体的部分。

同时，为鼓励普及，本页以“做既有集中式 getwork 协议的完整超集”为设计目标：矿池不必大动干戈就能采纳，矿工审计能力是增量加上去的，而不是另起炉灶逼全行业换接口。

四、规则本身

4.1 基础矿池扩展

请求可带 target（期望的目标值，服务器可忽略）；模板新增 expires（本工作自服务器发响应起最多有效的秒数）与 target（有效结果必须小于的数，大端十六进制）。目标值不可省略的原因写在 Rationale 里：有些矿池用更低的目标运转，不应浪费带宽去收注定不合格的份额；高算力下矿工也需要向矿池要更低目标来管理自己的带宽。

4.2 区块提议（Block Proposal）

服务器在模板的 capabilities 中带上 “proposal” 即表示支持。矿工可在工作过期前的任意时点，把自己组装的区块提议给服务器做一般校验：以 mode: "proposal" 调用 getblocktemplate，附十六进制区块数据 data，有 workid 时一并带上。

服务器须按平常的接受规则（除工作量证明那项检查外）验这块数据，结果三选一：合规则返回 null（并保持同一 workid，且不应因此使旧模板失效）；不合规则返回拒收理由字符串（词表见 BIP-22 附录）；或返回一个“增量模板”，指出要改什么——缺失的键按提议区块、再按原模板的取值理解，增量模板还可带 reject-reason。只为登记备案的服务器，原文推荐简单返回 {"workid":"new workid"} 这样的对象。客户端可假设：提议过的区块只要改动限于自己提供的那段 coinbase scriptSig 与时间头，就仍然有效，服务器无正当理由不应推翻这一假设。

BIP-3

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-3
标题	Updated BIP Process
作者	Murch <murch@murch.one>
指定日期	2025-01-09
讨论日期	2024-05-13
类型	Process（流程类）
状态	Deployed（已部署）
替代	BIP-2
依赖	BIP-123
阅读版	https://bips.dev/3
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0003.md

二、放在哪一族

流程族的现行版本，第三代。链条是：BIP-1（2011，初版）→ BIP-2（2016，修订版，已 Closed）→ BIP-3（替代 BIP-2，状态 Deployed）。它依赖 BIP-123 的分层分类：文件头里的 Layer 取值仍按 BIP-123 定义。

今天往仓库提交新提案、判断一份旧 BIP 的状态是什么意思，都以 BIP-3 的定义为准。文件头标注版本 1.4.0，且流程类 BIP 被定义为“活文档”，可按粗略共识持续修订。

三、它要解决什么

BIP-2 写于 2016 年。原文列出的修订动机是：

BIP-2 的若干环节没有获得广泛采用（最典型的是评论机制：实际很少有 BIP 收到评论，个别评论反而被文件头里的汇总放大了权重）；
分配给编辑的判断裁量太多，有些本应由作者或读者承担；
三类 BIP 的界定不够清楚——Standards Track 常被误解为“被推荐”，而一些影响互操作性的提案却被标成 Informational；
仓库的实际使用方式已经演变，流程需要与之对齐。

一句话：精简。把没人用的机制撤掉，把状态与类型减到读者真正能用的程度。

四、规则本身

4.1 先说清三件事

BIP 是什么：为比特币提出的改进提案，主题是支持与扩展比特币货币用途的信息与技术；多数 BIP 用一份自包含的技术说明讲一个新概念、新功能或新标准，少数是流程、实现指南、最佳实践或事故报告（如 BIP-50）。任何人都可以提交，但内容须有质量、不浪费社区时间；仓库范围限于不反对“比特币是点对点电子现金系统”这一根本原则的提案。
BIP 不代表什么：单个 BIP 不定义“什么是比特币”，不代表社区共识，也不是普遍性的实施推荐；它只是作者向社区提出的一份个人推荐。有的 BIP 永不会被采用，有的被一两个客户端采用，有的最终改动了全网共同执行的共识规则。
仓库是干什么的：出版媒介与档案馆。它以高可见度便于全社区审议，透明记录每份 BIP 的全部修改历史；它不追踪社区情绪，也不追踪生态采用情况（除状态字段给出的简要概览外）。没有任何正式或非正式的决策机构治理比特币开发或裁定 BIP 的采用。

所有权上，每份 BIP 主要归其作者，作者负责推进讨论、回应反馈与异议；随流程推进，它逐渐变为社区共有。作者可指定 Deputies（副手）：未参与写作的代管人，在作者缺席时可代行作者职责，除非被作者推翻。

BIP-30

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-30
标题	Duplicate transactions
作者	Pieter Wuille <pieter.wuille@gmail.com>
指定日期	2012-02-22
层级	Consensus (soft fork)（共识（软分叉））
类型	Specification（规范类）
状态	Deployed（已激活）
阅读版	https://bips.dev/30
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki

二、放在哪一族

共识层（软分叉）的“堵漏”族：不引入新功能，只给已有的交易标识符（txid）唯一性补上一条原本缺失的强制规则。

它的位置要和两个相邻话题分开看：

与 coinbase 的关系：重复交易最容易的来源正是 coinbase——币基交易结构简单、早期高度上完全可能逐字节相同，标识符随之相同；搭在重复 coinbase 之上，普通交易也能被复制出相同标识符。BIP-34（区块 v2、coinbase 中写入高度）是另一条线上让 coinbase 天然各不相同的办法，属于“让重复难以产生”；本页走的是另一头——直接规定链不许收。
与重组（reorg）的关系：本页真正的保护对象不是 txid 的美观，而是重组时的账本安全（见第三节）：规则要保证的“定律”，原文写在 Rationale 里，是任何方案都必须服从的前提。

同族可对照阅读的还有 BIP-16 等同年软分叉：都是“只收紧、不放宽”的规则变更。

三、它要解决什么

起因是参考实现里一个一直没被当真的假设：**它默认重复交易（标识符完全相同的交易）不存在。**原文指出这并不成立：

coinbase 特别容易被复制出相同的；
一旦有了重复的 coinbase，建立在其输出之上的普通交易也可以有重复版本。

更要紧的是，已经有人描述并演示了利用这一处理方式的攻击：

回滚已确认交易：攻击可把一笔已完全确认的交易打回只剩一次确认的状态，进而使它有被彻底变成不可花费的风险；
分叉子集网络：另一种攻击可以让一部分节点眼中的区块链发生分叉。

原文在 Rationale 里把危害抽象成一条定律：可用交易输出的集合，不得因为“把若干区块加进链、再把它们移除”而改变。这正是重组（reorg）时发生的事，而当时的参考实现在临时加入的区块含有重复交易时，会违反这条定律——重复交易会覆盖掉先前同标识符交易的未花费输出，区块被重组移除后，账也回不到原样。

四、规则本身

4.1 规则一句话

区块不得包含这样的交易：其标识符与同一条链上更早的一笔交易相同，而那笔更早的交易尚未被完全花费。

换个方向读：标识符相同的新交易，只在旧的那笔已经花得一干二净时，才允许再次出现。

4.2 适用范围与历史例外

规则最初适用于时间戳在 2012 年 3 月 15 日 00:00 UTC 之后的所有区块（测试网：2012 年 2 月 20 日 00:00 UTC）。

BIP-300

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-300
标题	Hashrate Escrows (Consensus layer)
作者	Paul Sztorc <truthcoin@gmail.com>、CryptAxe <cryptaxe@gmail.com>
指定日期	2017-08-14
层级	Consensus (soft fork)（共识（软分叉））
类型	Specification（规范类）
状态	Draft（草案）
阅读版	https://bips.dev/300
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0300.mediawiki

二、放在哪一族

侧链与 Drivechain（驱动链）族的核心文档。BIP-300 与 BIP-301 是一对：BIP-300 管“钱怎么进出”——主链为每条侧链托管一笔资金，进出都走主链共识；BIP-301 管“侧链的区块由谁出”——盲合并挖矿。两者合起来构成 Drivechain 方案。

在本 BIP 之前，侧链与主链之间的双向锚定通常要靠联盟或一组固定公钥多签放行。BIP-300 要把放行权换成算力本身：提现是否成立，由矿工在很长一段时间内逐块表态决定。

三、它要解决什么

3.1 一种由工作量证明治理提现的二层

原文开宗明义：BIP-300 启用一种新型 L2，其“提现”（L2 到 L1 的交易）由工作量证明治理，而不是由联盟或一组固定公钥治理。

设计强调提现要慢、透明、可审计：让诚实用户容易做对，让不诚实的矿工难以滥用。

3.2 两条设计目标

原文列出两条主要目标：

分区（partitioning）：用户可以完全忽略 BIP-300 交易；验证全部、一部分或完全不验证这些交易，对 L1 没有区别。
安全（security）：L2 的用户应有信心——若某个 L2 网络支付了大量手续费，矿工就会希望它存续下去，提现也因此会被准确处理。

3.3 在 L1 与 L2 之间架桥

一旦 BIP-300 在 L1 与这些 L2 之间建起“桥”，用户就可以即时地把币换入换出，只在最终结算时才动用 BIP-300。原文由此主张：比特币可以承载世界上任何形状、任何规模的交易，而完全不必改动 L1 本身。其动机部分还追溯到侧链的早期愿景：让开发者在不修改 Bitcoin Core 代码的前提下为比特币宇宙添加功能，创新可以更快、更灵活、更分布式地发生，又不失去共同平台与单一货币的协同。

BIP-301

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-301
标题	Blind Merged Mining (Consensus layer)
作者	Paul Sztorc <truthcoin@gmail.com>、CryptAxe <cryptaxe@gmail.com>
指定日期	2019-07-23
层级	Consensus (soft fork)（共识（软分叉））
类型	Specification（规范类）
状态	Draft（草案）
阅读版	https://bips.dev/301
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0301.mediawiki

二、放在哪一族

合并挖矿与 Drivechain 族，与 BIP-300 成对出现：BIP-300（算力托管）解决侧链资金进出主链的问题，BIP-301 解决侧链区块由谁生产的问题。原文记号上把主链一侧写作 main:、侧链一侧写作 side:，并以 Simon 指代侧链用户、Mary 指代主链矿工。

它的参照系是传统合并挖矿（Merged Mining）：矿工复用同一份哈希算力同时为多条链工作，原文举的例子是 Namecoin。BIP-301 要保留“复用算力”这一点，去掉传统合并挖矿强加给矿工的负担。

三、它要解决什么

3.1 传统合并挖矿的两条缺点

原文指出传统合并挖矿有两个缺点：

矿工必须为另一条链运行全节点，也就是必须运行“非比特币”软件，这类软件可能有缺陷；
矿工在另一条链上获得报酬，拿到的是那条链的代币（例如合并挖矿 Namecoin 挣的是 NMC）。

3.2 把组装区块的工作交出去

盲合并挖矿（Blind Merged Mining，BMM）的想法是分工：组装侧链区块的工作——选哪条侧链区块、放哪些交易、收多少费——由侧链用户完成；矿工不运行任何新软件、不“看”这些侧链（故称“盲”），只在主链上做一件事：为某个侧链区块背书。

侧链用户同时在 L1 上“出价”，竞买成为该侧链区块唯一创建者的权利。BIP-301 要保证 L1 矿工每 10 分钟、每个 L2 类别只接受一份出价，而不是像通常那样把所有出价都收下。

3.3 原文的算例

原文设想：一个侧链区块含 20,000 笔交易、每笔付 0.10 美元手续费，整个侧链区块值 2,000 美元手续费。侧链的 coinbase 把这 2,000 美元付给 Simon；Simon 自己不做任何哈希，而是发一笔 L1 交易付 1,999 美元给主链矿工 Mary。结果 Mary 什么侧链工作都没做，却拿走了几乎全部手续费收入；Simon 净得 1 美元。原文强调：BIP-301 在 L1 上让这种分工无需信任——Mary 若拿了 Simon 的钱，就必须让 Simon 控制那个侧链区块。

BIP-31

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-31
标题	Pong message
作者	Mike Hearn <hearn@google.com>
指定日期	2012-04-11
层级	Peer Services（对等服务）
类型	Specification（规范类）
状态	Deployed（已部署）
阅读版	https://bips.dev/31
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0031.mediawiki

二、放在哪一族

BIP-31 属于对等网络（P2P）基础消息族，处理的是节点之间最底层的连接健康检查：连接还在不在、对方还响不响应、延迟有多大。

它与 BIP-14（协议版本与用户代理）、BIP-35（mempool 消息）、BIP-37（连接布隆过滤）同属对等服务层，都是在不改共识规则的前提下，给节点间通信补上小而实用的机制。

这类改动的特点是：不触碰区块与交易的合法性，只改“节点怎么说话、怎么确认对方还活着”。

三、它要解决什么

原文列了三个当时常见的网络问题：

3.1 设备休眠后连接“假活”

一些客户端跑在会随时休眠的设备上，手机和笔记本（合上盖子）尤其常见。系统醒来后，原来的 TCP 连接表面上还在，实际上可能因为 IP 地址已变、对方已离开或连接已被中间系统超时而失效。现在往往要过很久才能发现。

3.2 对方过载，无从判断

参考客户端当时大体是单线程的，在重负载下（例如正在下载区块链时）响应网络消息会变得很慢。被动等待广播的一方很难判断对方是没消息，还是已经忙到回不过来。能探测到过载节点，就能避开它们、均衡负载。

3.3 不知道谁离自己“更近”

下载区块链这类大数据时，选网络上更近的节点效率更高，也能减轻拥挤的跨国链路负担。但当时没有简单的办法测量到某个对等节点的延迟，客户端只能随机选。

这三个问题，都可以用一个向后兼容的小改动一并解决：让 ping 带上可回显的标记，并规定对方必须回一个 pong。

四、规则本身

4.1 ping 加 nonce，新增 pong

当双方在 ver 消息中协商出的协议版本大于 60000 时：

ping 消息必须包含一个 uint64 字段，名为 nonce；
发送方应把 nonce 设为随机值；
接收方用一个新的 pong 消息回应该 nonce，pong 同样只包含一个 uint64 字段，原样回显。

客户端发出 ping 后计时，收到对应 pong 时就得到往返延迟。若在第一个 pong 回来之前又发了第二个 ping，可以靠 nonce 区分两次回应；若客户端从不让 ping 重叠发送，则把 nonce 设为零即可。

BIP-310

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-310
标题	Stratum protocol extensions
作者	Pavel Moravec <pavel.moravec@braiins.cz>、Jan Čapek <jan.capek@braiins.cz>
指定日期	2018-03-10
层级	Applications（应用）
类型	Informational（信息类）
状态	Draft（草案）
阅读版	https://bips.dev/310
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0310.mediawiki

二、放在哪一族

挖矿协议族。Stratum 是矿工（矿机）与矿池服务器之间通信的协议；比特币早期的挖矿协议文档还有 BIP-40、BIP-41（Stratum 线路协议与挖矿协议，仅分配编号）与 BIP-22、BIP-23（getblocktemplate，节点与矿池之间取区块模板的接口）。

BIP-310 不重写 Stratum，而是给它加一层“扩展协商”：以后再加新功能，不必再逐个发明新消息。它规范的第一个、也是最重要的扩展 version rolling，与区块头 nVersion 位的用途直接相关，因此常与下面两篇一起读：

BIP-320：把 nVersion 的 16 位预留为通用用途

BIP-323：把预留扩大到 24 位

三、它要解决什么

3.1 矿工想改 nVersion，却没法告诉矿池

最初的动机是 version rolling：矿工改写区块头第一个字段 nVersion 的值。区块头里可供矿工滚动的空间有限，多滚一些位能减少向矿机分发新任务的频率；其中 AsicBoost 等技术也要用到 nVersion 的位。

但在原始 Stratum 协议里，这件事做不成：矿工无法把不同的区块版本值传达给服务器，服务器也无法把“哪些位可以安全滚动”告诉矿工。这是一个与旧协议不兼容的改动，矿工与矿池两侧都必须实现某种协议扩展才能支持。

3.2 乱发未知消息不安全

原文指出一个现实约束：通常矿工若向服务器发送未知消息，服务器会直接关闭连接（并非所有实现都这样，但有些会）。因此试探性地发送未知消息并不安全。

3.3 借一次不兼容改动，做成通用机制

作者的取舍是：既然不得不做一次不兼容改动，就把它做成通用的——引入一条新消息 mining.configure，统一处理特性的初始配置与协商。此后添加新特性不必再增加新消息；矿工既能宣告自己的能力，也能向服务器请求所需特性。原文要求同一协商机制也能服务于尚未知晓的未来特性，且在挖矿软件中应当易于实现。每个扩展有一个唯一字符串名，称扩展代码（extension code）。

四、规则本身

4.1 mining.configure 消息

这是矿工在与服务器建立连接后应当发送的第一条消息（JSON-RPC 请求）。它带两个必填参数：

extensions：扩展代码列表，矿工应宣告其全部可用特性；
extension-parameters：各扩展的参数映射。参数名按约定由扩展代码加点号加参数名构成，例如 version-rolling.mask 是 version-rolling 扩展的 mask 参数。

返回值为一张映射：extensions 列表中的每个代码都必须有明确返回值——true 表示该特性被支持、配置被理解并应用；false 表示不支持或未知；字符串则表示出错信息。某些扩展还借返回映射把附加信息（如最终掩码）送回矿工。

BIP-32

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-32
标题	Hierarchical Deterministic Wallets
作者	Pieter Wuille <pieter.wuille@gmail.com>
指定日期	2012-02-11
层级	Applications（应用）
类型	Informational（信息类）
状态	Deployed（已部署）
阅读版	https://bips.dev/32
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki

二、放在哪一族

BIP-32 是确定性钱包族的地基。它定义了“种子 → 密钥树”这套派生机制本身，后来的一系列文档都建在它上面：

BIP-39：把种子写成助记词，让人能抄写与口述

BIP-43：给树的第一层加“用途”字段

BIP-44：多账户层级结构，规定币种、账户、内外部链的固定路径

再往后还有 BIP-49、BIP-84、BIP-86 等按地址类型分工的派生方案，用的都是 BIP-32 的树与扩展密钥。

文档分两部分：第一部分是密钥派生系统本身；第二部分是在这棵树上搭出的默认钱包结构。第二部分是建议性的，第一部分才是互通的关键。

三、它要解决什么

当时的参考客户端使用随机生成的密钥：为了避免每笔交易后都重新备份，默认预存 100 个备用密钥放进密钥池。即便如此，这类钱包仍有三个硬伤：

备份要反复做：随机密钥不断新增，旧备份随时过期；
不能安全地跨系统共用：钱包不打算被多台设备同时使用；用加密功能把私钥藏起来后，“阉割版”钱包连新公钥（新地址）都生成不了；
分享只能全有或全无：普通确定性钱包通常只有一条密钥链，想分享就得分享整条链，没法只交出其中一部分。

原文举的例子是网店：商家希望让网站服务器为每笔订单、每位顾客生成新收款地址，但绝不能把能花钱的私钥放在服务器上。用椭圆曲线数学，可以只给服务器算公钥的能力；再加上分层结构，服务器拿到的只是“对外收款”那一支，连找零地址那一支都看不到。

四、规则本身

4.1 扩展密钥：密钥加链码

每个密钥都附带额外的 256 位熵，称为链码（chain code，32 字节）。私钥加链码记作扩展私钥 (k, c)，公钥加链码记作扩展公钥 (K, c)，其中 K 是由 k 算出的公钥。对应的扩展公私钥共用同一条链码。

每个扩展密钥有 2 的 31 次方个普通子密钥和同样数量的硬化（hardened）子密钥：普通子密钥用索引 0 到 2 的 31 次方减 1，硬化子密钥用 2 的 31 次方到 2 的 32 次方减 1，写作 i 加下标 H。

BIP-320

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-320
标题	nVersion bits for general purpose use
作者	BtcDrak <btcdrak@gmail.com>
指定日期	2018-03-01
类型	Specification（规范类）
状态	Draft（草案）
接替文档	Proposed-Replacement: BIP-323
阅读版	https://bips.dev/320
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0320.mediawiki

二、放在哪一族

区块头与软分叉信号族。区块头的 nVersion 字段一身二任：一边是版本号本身，一边自 BIP-9 以来被 version bits 机制借用作矿工软分叉信号位。BIP-320 处理的正是这两任之间的冲突：把一部分位正式划出信号用途，留给矿工自由使用。

它的上下游关系清楚：

BIP-9：Version bits with timeout and delay，信号机制本身

BIP-8：Version bits with lock-in by height，另一套部署参数

BIP-310：Stratum 协议扩展；矿工与矿池协商滚动哪些位，走的就是本 BIP 划出的这片空间

BIP-323：本 BIP 的提议接替者，把预留从 16 位扩大到 24 位

三、它要解决什么

3.1 矿工想用这些位，节点却会误报

原文动机说得很直接：矿工出于各种目的想使用 nVersion 字段的一些位；但因为这些位被用来协调矿工激活的软分叉，全节点软件在这些位被用于软分叉信号以外的目的时，会发出“未知软分叉”的误报警。

解法不是禁止矿工用，而是先把一部分位预留给通用用途，再让节点软件更新为忽略这些位，从此不再误报。原文算过账：预留 16 位之后，还剩下足够 13 个软分叉用 version bits 并行信号的空间。

3.2 例一：nonce 空间不够用

原文举的第一个例子是挖矿硬件：现有硬件能在不到 200 毫秒内耗尽 32 位 nonce 字段，控制器不得不非常频繁地向每颗挖矿芯片分发新任务，消耗大量带宽与 CPU。多滚一些位可以大幅缓解这个问题；而过多地滚动 nTime 并不理想，因为它会在更长时间尺度上扭曲时间戳。

BIP-321

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-321
标题	URI Scheme
作者	Matt Corallo <bip21@bluematt.me>
指定日期	2024-11-15
层级	Applications（应用）
类型	Specification（规范类）
状态	Complete（已完成）
取代文档	Replaces: BIP-21
阅读版	https://bips.dev/321
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0321.mediawiki

二、放在哪一族

支付链接与发票族。这一族的源头是 BIP-20 与 BIP-21 定义的 bitcoin: URI 方案：把收款地址、金额等信息编码成一条链接或一个二维码，用户点击或扫码即可付款。BIP-321 是 BIP-21 的修改版与指定接替者，档案上以 Replaces 标记取代 BIP-21。

同一族中还有几份近亲：

BIP-72：支付协议的 bitcoin: URI 扩展

BIP-351：Private Payments；其地址经本 BIP 的 pay 参数承载

BIP-352：Silent Payments（静默支付）；其地址经本 BIP 的 sp 参数承载

理解 BIP-321 的关键，是看清它如何把“一条 URI 只能装一个链上地址”的老格式，升级为“一条 URI 可以同时装多种支付指令、付款方自选其一”的统一发票格式。

三、它要解决什么

3.1 让付款像点链接一样简单

原文动机的第一句就是 URI 方案的总目的：让用户只需点击网页上的链接或扫描二维码，就能轻松完成付款。bitcoin: URI 是操作系统、浏览器与钱包之间传递“付款指令”的通用语言。

3.2 老格式装不下现代支付方式

BIP-21 写于只有链上地址的年代。如今收款方常常同时希望提供闪电发票、静默支付地址等多种收款方式，新地址类型也不断出现。若每种方式都另造一套链接格式，钱包与商户系统就要反复适配；若把新地址硬塞进 URI 的地址位置，老钱包又会无法识别。

BIP-321 的修法是结构性的：地址部分保留给经典链上地址，新的支付指令一律放进查询参数。这样旧付款方至少还能走链上回退路径，新付款方则能挑更现代的方式。

3.3 付款发起方需要拿到付款凭证

原文还新增了一个老格式没有的环节：发起付款的应用（如在手机上唤起钱包的另一个应用）可能需要知道付款已完成的结果。链上付款尚可自行监控区块链，但闪电等支付没有全局账本可查。为此本 BIP 定义了可选的付款证明（Proof of Payment）回传机制。

BIP-322

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-322
标题	Generic Signed Message Format
作者	Karl-Johan Alm <karljohan-alm@garage.co.jp>、Oliver Gugger <gugger@gmail.com>
指定日期	2018-09-10
讨论日期	2018-03-14
层级	Applications（应用）
类型	Specification（规范类）
状态	Complete（已完成）
依赖文档	Requires: BIP-174、BIP-340、BIP-341、BIP-342
阅读版	https://bips.dev/322
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki

二、放在哪一族

消息签名族。旧的标准做法是“用地址对应的私钥签一段消息”，以证明签者与收款地址的关系；这一做法的正式文档是 BIP-137（用私钥签署消息）。但它只支持 P2PKH 一类地址，SegWit、多签、Taproot 等现代脚本无从下手。

BIP-322 把签名对象从“某个私钥”推广到“某个脚本”：只要能满足脚本，就能签。它的依赖关系写在档案里：Requires BIP-174（PSBT）、BIP-340、BIP-341、BIP-342（Schnorr 签名与 Taproot 一族）。其 full 签名形式在结构上又与 Signet 的挑战—求解模式相通，原文称它与 BIP-325（Signet）所用的挑战类似。

三、它要解决什么

3.1 旧格式只认 P2PKH

原文动机开门见山：现行消息签名标准只适用于 P2PKH（以 1 开头）的收款地址。本 BIP 提议用一种基于比特币脚本的方法把标准扩展、普遍化，使任何脚本控制的币原则上都能被签——同时为便于与既有签名硬件互操作，还定义一种形似比特币交易的消息签名格式（其中含有一个无效输入，因此不可能在任何真实网络上被花费）。

3.2 旧签名并不真正证明知道私钥

原文指出的第二个缺陷在密码学层面：现行消息签名格式使用 ECDSA 签名，而这类签名并不承诺公钥，因而并不真正证明签者知道任何秘密密钥——有效的签名可以被第三方微调，变成对某些相关密钥同样有效的签名。

3.3 它能证明什么、不能证明什么

原文罕见地用整段篇幅划界，读时不应跳过：

本 BIP 只处理一种用例：签名者表明自己将能够控制发往某个收款地址的资金；
任何消息签名协议都不可能真正“证明控制资金”：签名一经产生即告过时，且持有密钥的人可能愿意替他人签消息、却不愿替他人签真实交易。这两个局限，任何消息签名协议都修复不了；
证明“某笔先前交易是签名者发出的”，用本 BIP 同样做不到。

四、规则本身

4.1 四种签名形态

本 BIP 规定三种签名格式，另加一个资金证明变体。签名者必须在签名前加上所用变体的前缀；为兼容定稿之前的实现，验签者在无前缀时可以假定其为 simple 变体。

Legacy（旧格式）：紧凑型、可恢复公钥的 ECDSA 签名，经 base64 编码，无前缀；兼容 P2PKH 等。原文要求新证明对所有收款地址格式都应使用新格式，legacy 格式可以保留，但必须限制在 legacy P2PKH 地址上使用。
Simple（简单格式）：前缀 smp。签名是见证栈（witness stack），按共识编码后 base64；兼容 P2WPKH、P2WSH、P2TR（原文注明不含时间锁脚本）。
Full（完整格式）：前缀 ful。签名是完整的 to_sign 交易（见 4.2 节），按共识编码后 base64；兼容全部脚本类型。
Full (Proof of Funds)（资金证明变体）：前缀 pof。签名是已定稿的 PSBT 包；同样兼容全部脚本类型，并额外证明对一组 UTXO 的控制。

4.2 两笔虚拟交易：to_spend 与 to_sign

Full 形式的核心是构造两笔虚拟交易：

BIP-323

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-323
标题	24 nVersion bits for general purpose use
作者	Matt Corallo <bips@bluematt.me>
指定日期	2026-04-22
讨论日期	2026-02-26
类型	Specification（规范类）
状态	Draft（草案）
取代文档	Replaces: BIP-320
阅读版	https://bips.dev/323
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0323.mediawiki

二、放在哪一族

区块头与软分叉信号族，是 BIP-320 的直接续篇，档案上以 Replaces 标记取代 BIP-320。BIP-320 把 nVersion 的 16 位划作矿工通用空间；BIP-323 认为这片空间已经被硬件实践证明不够用，主张扩大到 24 位。

同族的相关文档：

BIP-9：Version bits 信号机制；预留位正是从它的含义范围中划出

BIP-8：Version bits 的另一种部署参数，同样被本 BIP 点名移除预留位

BIP-310：Stratum 协议扩展；矿工与矿池协商滚动哪些位，走的是这片预留空间

三、它要解决什么

3.1 16 位不够用，硬件已经在借 nTime 的位

原文动机说得具体：BIP-320 把 16 位 nVersion 定义为额外 nonce 空间，但事实证明这还不够——一些设备已经开始动用 nTime 中的 7 位作为额外 nonce 空间。原文据此判断：在 nVersion 里留 16 位给信号用途，实际效用有限；不如在 nVersion 里给出 24 位作为额外 nonce 空间。

BIP-324

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-324
标题	Version 2 P2P Encrypted Transport Protocol
作者	Dhruv Mehta <dhruv@bip324.com>、Tim Ruffing <crypto@timruffing.de>、Jonas Schnelli <dev@jonasschnelli.ch>、Pieter Wuille <bitcoin-dev@wuille.net>
指定日期	2019-03-08
层级	Peer Services（对等服务）
类型	Specification（规范类）
状态	Deployed（已部署）
取代文档	Replaces: BIP-151
阅读版	https://bips.dev/324
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0324.mediawiki

二、放在哪一族

P2P 网络传输族。比特币节点之间长久以来以明文 v1 协议通信；为这条链路加加密的尝试中，较早的一份是 BIP-151（对等通信加密，状态已关闭），BIP-324 在档案上以 Replaces 取代它，给出了最终成形的 v2 方案。与它同族的还有处理“节点如何找到彼此”的文档，如 BIP-155（addrv2 消息）——本 BIP 的信号机制正是经由 addr 中继传播服务标志，与之衔接。

这一族改的都不是“传什么”，而是“怎么传”：消息语义（version、inv、tx、block 等）保持不变，变的是它们在网线上的样子。

三、它要解决什么

3.1 明文传输的三个毛病

原文动机承认一个前提：比特币是无许可网络，中继的数据本身是公开的，协议也没有密码学身份概念，节点之间长期以未加密、未认证的连接通信。但明文在攻击者面前有严重缺陷，原文列了三条：

元数据泄露隐私：数据本身公开，但关联元数据可能暴露隐私。例如，全局被动窃听者监听所有比特币 P2P 连接，可以轻易识别某笔交易的来源与时间。
连接可被低成本篡改：连接未认证，攻击者可以低成本、且往往低被发现风险地篡改它，例如在传输途中改掉连接中的特定字节（如节点标志），还不必保持任何状态。
协议自我暴露：深度包检测可以轻易识别一条 P2P 连接，因为连接以一串固定魔术字节开头。能识别连接，就能审查连接，也能为窃听、篡改以及需要控制受害者连接的攻击（如针对矿工的日蚀攻击）提供便利。

3.2 解法：机会性加密＋伪随机字节流

新协议（v2）的对策是大幅抬高上述攻击的成本，核心手段是未经认证的、机会性的传输加密，并让线上的字节流对被动窃听者呈现为伪随机（与均匀随机字节不可区分）。

原文逐项说明收益：加密（哪怕未认证、且仅在双方都支持 v2 时使用）迫使窃听者转为主动攻击——要么做持续的中间人攻击，要么把连接降级回 v1，要么自建节点等诚实节点连上来；主动攻击在规模上更耗资源，而对人工建立的刻意连接，即便只是运营者手动比对协议版本与会话 ID 这类基本检查，原则上也能让攻击者露馅。篡改本就是主动攻击，加密后攻击者还被迫维持完整的中间人状态，成本更高。伪随机字节流则排除基于模式匹配的识别，审查防火墙要拦截就得做完整的中间人攻击，或改用更显眼的白名单策略。

3.3 为什么加密却不做认证

原文用整节篇幅回答这一设计取舍：未经认证的加密也严格优于不加密，因此所有连接都应加密，哪怕未认证。至于认证，由于比特币的无许可性质，认证永远只能限于特定场景（例如同一运营者的节点之间），是否需要、需要何种形式的认证取决于具体对端；因此认证应当另行处理。本 BIP 要做的是打好技术地基：导出一个唯一标识加密通道的会话 ID，通道建立后，双方可用任何认证协议确认彼此持有相同的会话 ID（即“通道绑定”）。至于为何不用 TLS、Noise 等通用传输加密协议，原文列出的技术理由包括：它们不提供伪随机字节流、不原生支持 secp256k1、字节流不可塑形、且其流式接口与比特币所需的包式接口不匹配，改造它们会抵消现成方案的复用收益。

BIP-324 v2 加密传输整合完成：节点间通信可协商加密传输，v26 中默认关闭

Mon, 01 Jan 0001 00:00:00 +0000

项目	内容
日期	2023-10-03
首次发布	Bitcoin Core v26.0
合并 PR	#28331
合并提交	`6f882e6f86`
影响范围	P2P
相关 BIP	BIP-324

事实摘要

该 PR 使 BIP-324 的 v2 传输协议功能完整：启用 -v2transport 后，节点对外连接时向支持 v2 的对等节点协商加密传输（基于 EllSwift 密钥交换与带认证的流加密），入站连接可自动识别 v1/v2 并兼容处理，v2 连接即时失败时回退 v1。v2 传输使节点间流量对被动旁观者不可见、更难被流量分析与主动篡改。26.0 发布说明将其列为实验性支持、默认关闭；默认启用要到之后的 v27.0（#29347）。

关键链接

BIP-325

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-325
标题	Signet
作者	Karl-Johan Alm <karljohan-alm@garage.co.jp>, Anthony Towns <aj@erisian.com.au>
指定日期	2019-03-20
层级	Applications（应用）
类型	Specification（规范类）
状态	Complete（已完成）
阅读版	https://bips.dev/325
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0325.mediawiki

二、放在哪一族

测试网络族。比特币已有的测试环境各有短板：主网不能拿真钱试错；testnet 虽不要真钱，却以不可控的不可靠著称；regtest 出块成本为零，任何一方都能完全控制链，不适合多方长期场景。

BIP-325 提出的 signet 是这中间的一档：保留工作量证明，又叠加一道由指定挑战脚本控制的签名关卡，让出块权回到可协调的范围内。它与主网规则的关系是“另起一条测试链”，不改主网共识。

三、它要解决什么

3.1 testnet 太不可靠

原文指出，testnet 上常见巨型重组（reorg）、长时间不出块、又突然连珠炮式出块。对单机短时试错尚可，但对“多家独立机构、各自跑软件、持续较长时间”的集成测试，现实中几乎不可行。

3.2 regtest 又太可控

regtest 里造块几乎零成本，任何参与方都能完全主宰测试链，因此撑不起需要多方互不完全信任、又要长期运行的场景。

3.3 目标：可预期的不可靠

signet 的目标不是完美可靠，而是“可靠地不可靠”（reliably unreliable）：整体行为像主网，不出现成千上万个区块级别的重组；同时又比主网更容易触发那些预期内但罕见的事件，例如 6 个区块深度的重组，以便提前演练软件的应对。

四、规则本身

4.1 挑战（challenge）

signet 网络多了一个共识参数，称为挑战，即一个 scriptPubKey。它可以是简单的单公钥（P2PKH 式）、k-of-n 多签，也可以是任何其他脚本。出块者必须给出能满足该挑战的解，区块才算完整有效。

4.2 签名放在哪里

每个 signet 区块都必须在 coinbase 交易中带有 BIP-141 承诺。见证承诺的可选数据里，要再放入一段对挑战的解，格式为：

1–5 字节：推送长度前缀；
4 字节：Signet 头 0xecc7daa2；
x 字节：scriptSig；
y 字节：scriptWitness。

不以 Signet 头开头的推送会被忽略；多个带 Signet 头的推送只认第一个。特例是：当空解本身就有效时（scriptSig 与 scriptWitness 皆空），这段额外承诺可以省略，以便用不感知 signet 的出块代码测试挑战平凡为真的自定义 signet 链。

BIP-326

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-326
标题	Anti-fee-sniping in taproot transactions
作者	Chris Belcher <belcher@riseup.net>
指定日期	2021-06-10
讨论日期	2021-06-10
层级	Applications（应用）
类型	Informational（信息类）
状态	Draft（草案）
阅读版	https://bips.dev/326
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0326.mediawiki

二、放在哪一族

钱包行为与隐私族，具体落在 Taproot 钱包的默认做法上。它不定义新地址、新脚本或新共识规则，而是建议钱包在构造 Taproot 花费时如何填写已有的时间锁字段。

它依赖的既有规则包括：

BIP-68：用序列号表达相对锁定时间，nSequence 的编码上限与语义出自这里

BIP-341：Taproot 的 SegWit v1 花费规则，本篇所说的 Taproot 交易即花费 BIP-341 输出的交易

与之形成对照的是现行主流做法：用 nLockTime 做防手续费狙击（anti-fee-sniping），原文提到该做法已在 Bitcoin Core 与 Electrum 中实现。链下协议一方则包括 CoinSwap、闪电网络与离散对数合约（DLC）等将采用 PTLC 的协议。

三、它要解决什么

3.1 PTLC 更私密，却会在关通道时露馅

Taproot 让点时间锁定合约（PTLC）成为哈希时间锁定合约（HTLC）更私密的替代：用 PTLC 关闭链下合约时，链上只看到一个普通的 Taproot 脚本，看不到哈希值与原像。

但若关闭时走的是时间锁路径，链上会出现 OP_CHECKSEQUENCEVERIFY 操作码或交易中的 nSequence 值。这类标记在当时并不常见，等于把“这是一笔链下结算”写在了脸上。

3.2 让普通钱包的日常交易来打掩护

本篇的思路是：让 Bitcoin Core 这类链上钱包在自己的 Taproot 交易里也日常地设置 nSequence（按 BIP-68 的方式），用它替代一部分原有的 nLockTime 防狙击保护。

BIP-327

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-327
标题	MuSig2 for BIP340-compatible Multi-Signatures
作者	Jonas Nick <jonasd.nick@gmail.com>, Tim Ruffing <crypto@timruffing.de>, Elliott Jin <elliott.jin@gmail.com>
指定日期	2022-03-22
讨论日期	2022-04-05
类型	Informational（信息类）
状态	Deployed（已部署）
阅读版	https://bips.dev/327
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0327.mediawiki

二、放在哪一族

Schnorr 多签族，坐落在 Taproot 生态的正中央。原文没有给它标注 Layer 字段；按内容看，它规范的是钱包与签名设备如何协作产出签名，属于应用层面的签名协议标准，而不是共识规则。

它直接建立在以下文档之上：

BIP-340：secp256k1 的 Schnorr 签名，聚合公钥与最终签名都必须与它兼容、能通过它的验证

BIP-341：Taproot 花费规则，MuSig2 的首要应用就是共同控制 Taproot 输出的密钥路径

BIP-32：分层确定性钱包，聚合公钥的普通微调（plain tweaking）用于按 BIP-32 派生子密钥

BIP-342：Taproot 脚本验证，其中的 OP_CHECKSIGADD 是脚本层 n-of-n 多签的对照方案

后续文档中，BIP-328 专门规定如何从本篇的聚合公钥构造 BIP-32 扩展公钥做派生；BIP-373 则定义 MuSig2 在 PSBT 中的字段。读本篇是读懂这一串 MuSig2 配套标准的前提。

三、它要解决什么

3.1 多人共同控制一个 Taproot 输出，需要统一标准

多位签名者想共同控制一个 Taproot 输出时，该输出里放的应是众人公钥聚合出的单个公钥，花费时再由众人合作产出对该公钥有效的普通 Schnorr 签名。不同软件项目若各行其是，就无法互操作。本篇要为 MuSig2 这一方案定出统一、互通的标准。

BIP-328

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-328
标题	Derivation Scheme for MuSig2 Aggregate Keys
作者	Ava Chow <me@achow101.com>
指定日期	2024-06-04
层级	Applications（应用）
类型	Informational（信息类）
状态	Complete（已完成）
阅读版	https://bips.dev/328
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0328.mediawiki

二、放在哪一族

MuSig2 配套族，紧贴 BIP-327 与 BIP-32 之间。

BIP-327：MuSig2 多签标准，产出与普通公钥无异的聚合公钥，本篇的派生对象正是这种聚合公钥

BIP-32：分层确定性钱包，定义扩展公钥（xpub）、链码与 CKDpub 子公钥派生，本篇借用整套派生机制

它解决的是多签实践中的一个具体环节：脚本多签时代，各方共享各自的 xpub、分别派生再拼脚本；换到 MuSig2 后，如何同样做到“一套密钥、不断派生新地址”。本篇给出的答案是只派生聚合公钥本身。

三、它要解决什么

多位共同签名者用 MuSig2 造出一个聚合公钥，它与随机公钥不可区分。遵循“每笔收款用新地址”的最佳实践，各方需要不断生成新的聚合公钥。

直白的做法是：每位签名者都生成多份公钥，每需要一个新聚合公钥就重新聚合一次。这类似脚本多签里各方共享 xpub、派生后拼出多签脚本的做法，可行，但要管理多份扩展公钥，存储与计算负担都更重。

既然 MuSig2 的聚合公钥本身看起来就是一个普通公钥，能不能只拿这一份公钥当 xpub 来派生？本篇就是把这一简化写成规范：从单个扩展公钥派生，而不是从许多扩展公钥派生再聚合，从而降低生成新聚合公钥所需的存储与计算。

四、规则本身

4.1 合成 xpub 的构造

从 BIP-327 的普通（plain）聚合公钥构造一个合成 xpub（synthetic xpub）：

深度（depth）设为 0；
子编号（child number）设为 0；
链码固定为字节串 868087ca02a6f974c4598924c36b57762d32cb45717167e300622c7167e38965，即文本 MuSig2MuSig2MuSig2 的 SHA256。

所有遵循本规范的合成 xpub 都必须使用这个固定链码。构造完成后，即可像对待任何普通 xpub 一样，从它派生非硬化（unhardened）子公钥。

4.2 只能非硬化派生

不存在“聚合私钥”这种东西——私钥始终分散在各位签名者手中。因此，从聚合公钥出发只能做非硬化派生，硬化派生不可能，这也是本方案的固有限制。

BIP-329

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-329
标题	Wallet Labels Export Format
作者	Craig Raw <craig@sparrowwallet.com>
指定日期	2022-08-23
层级	Applications（应用）
类型	Informational（信息类）
状态	Draft（草案）
阅读版	https://bips.dev/329
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0329.mediawiki

二、放在哪一族

钱包互操作族。资金本身的迁移早已有成熟标准——助记词、扩展密钥与派生路径一整套，本篇在档案卡的相关文档中对应的是：

BIP-39：助记码

BIP-32：分层确定性钱包

BIP-44：确定性钱包的多账户层级

BIP-380：输出脚本描述符通用操作，本篇的可选 origin 字段用它的缩略描述符语法

BIP-392：静默支付输出脚本描述符，本篇 spscan 类型的引用格式由它定义

这些标准让用户能自由换钱包，却都不管“标签”这类钱包元数据。BIP-329 补的正是这一块：它站在既有格式（SLIP-0015、Electrum 的标签 JSON）的经验之上，给出一个自描述、可独立使用的统一格式。

三、它要解决什么

用户会给钱包里的交易、地址、公钥、输入、输出、xpub 等记录打标签。在 UTXO 模型下，标签格外有价值：它标明资金来源——是外部收到的，还是上一笔交易的找零。花钱时若不小心把不同来源混在一起，会造成不必要的隐私泄露，因此标签对选币有实际指导作用；在一些钱包中，标签甚至已成为花费前必须参考的信息。

但此前没有定义好的标准来迁移标签：换钱包，标签就丢了，用户实际上被锁定在原来的钱包应用里。此外，许多钱包还允许把某个未花费输出冻结为不可花，这类与标签性质相近的钱包元数据同样无处安放，本格式一并收纳。

原文也交代了为何不直接沿用既有格式：SLIP-0015 定义了地址与输出标签的导出格式，但要求用与钱包种子关联的私钥加密，无法被接触不到私钥的协调类钱包独立使用；Electrum 的标签 JSON 格式可以扩展到其他记录类型，但格式本身不自描述，难以判定记录类型。

四、规则本身

4.1 载体：JSON Lines

格式选用 JSON，并采用 JSON Lines（换行分隔的 JSON）：导出文件是 UTF-8 编码的文本文件，每行一条记录、每条是一个合法 JSON 对象，行间以 \n 分隔，值不得跨多行。这样文件可以被切分、流式处理或增量追加，单行格式错误也不会让整份导入失效，也便于命令行按行处理。

4.2 每条记录的字段

每个 JSON 对象包含 3 到 4 个键值对：

type：记录类型，取值之一为 tx、addr、pubkey、input、output、xpub、spscan；
ref：对具体记录的引用，如交易 ID（十六进制）、地址（base58 或 bech32）、公钥（十六进制），输入与输出则写成“交易 ID:下标”，xpub 为 BIP-32 扩展公钥，spscan 为静默支付扫描密钥表达式；
label：用户打的标签；
origin（可选）：密钥来源信息；
spendable（可选）：true 或 false，表示该输出是否应可被钱包花费。

其中 type 与 ref 必填；label、origin、spendable 可选。若 label 或 spendable 被省略，导入方不得改动原有对应值。spendable 只应出现在 type 为 output 的记录上。

BIP-33

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-33
标题	Stratized Nodes
作者	Amir Taaki <genjix@riseup.net>
指定日期	2012-05-15
层级	Peer Services（对等服务）
类型	Specification（规范类）
状态	Closed（已关闭）
阅读版	https://bips.dev/33
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0033.mediawiki

二、放在哪一族

BIP-33 属于轻客户端与节点分工这一族：当完整区块链越来越大时，普通用户的设备怎样在不保存、不验证全部数据的前提下，仍然查到自己的交易历史？

它的历史脉络在原文中写得很清楚：2011 年 Jan Moller 的 BCCAPI 先开了“把区块链交互委托给远程服务器”的路子；ThomasV 的 Electrum 服务器随后跟进，要求全套自由软件栈；Marek Palatinus（slush）又起草 Stratum 来接替 Electrum 服务器的角色。BIP-33 提出的 stratized nodes，是“区块链服务”（blockchain service）这一更早概念的修改版，目标是规范地接替 Stratum 当时所扮演的、为用户客户端提供区块链查询的角色。

同族后来真正落地的路线不同：BIP-37 的布隆过滤让 SPV 客户端直接向普通全节点要过滤后的数据，再往后还有 BIP-157 与 BIP-158 的客户端区块过滤。读 BIP-33，是看清“专用服务节点”这条路线曾被认真设计过、最终又未被采用。

三、它要解决什么

原文开篇判断：网络规模扩大后，角色正在专业化。早期一个用户同时是矿工、商家和终端用户；随着系统成长，这些功能被抽象成专门服务，是自然结果。

问题随之而来：区块链对终端用户越来越笨重，在便携设备和低端机器上处理它越来越不现实。已有的应对办法——轻量（只存区块头）客户端、跳过最后一个检查点之前区块的验证——在作者看来至多是拖延问题的临时 workaround，解决不了根子上的负担。

因此方案的目标被限定得很明确：把区块链验证与查询的负担，从用户客户端身上卸给专业服务，并且要以安全的方式卸——原文强调，任何附带的好处都只是次要的。

作者对当时 Stratum 的评价也写进原文：Stratum 已无人维护，容易遭受资源饿死与拒绝服务攻击，且不安全。新协议正是要替代它的这一角色。

四、规则本身

4.1 两种新节点角色

节点在握手时的 version 消息里有一个 services 位域，用来宣告自己支持哪些服务（NODE_NETWORK 即值 1，表示可被索取完整区块）。BIP-33 新增两个值：

NODE_SERVICE（2）：区块链服务节点，支持新增的 getoutputs 与 getspends 消息；它本身不回应 getdata（除非同时标了 NODE_NETWORK）；若标了 NODE_NETWORK，用 getdata 取交易时不仅查内存池，必要时还查区块链；
NODE_STRATIZED（4）：采用本方案策略的节点；会中继已接受交易的 inventory；不支持 getblocks，因为它并不保存完整区块链。

除上述差别外，两类节点的行为与 NODE_NETWORK 节点相同。

BIP-330

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-330
标题	Transaction announcements reconciliation
作者	Gleb Naumenko <naumenko.gs@gmail.com>, Pieter Wuille <pieter.wuille@gmail.com>
指定日期	2019-09-25
层级	Peer Services（对等服务）
类型	Specification（规范类）
状态	Draft（草案）
阅读版	https://bips.dev/330
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0330.mediawiki

二、放在哪一族

P2P 交易中继族，定位是“积木块”，不是完整的中继协议本身。它要支撑的上层协议是 Erlay：Erlay 同时使用泛洪（向所有对等节点发 INV 公告）与对账两条路，泛洪只用在需要快速传播的少数连接上，其余连接靠高效集合对账来补齐与同步。

它与交易公告既有机制的关系包括：

BIP-339：基于 WTXID 的交易中继，本篇的草图建立在 WTXID 之上，协商与启用 Erlay 以双方都信号支持 BIP-339 为前提

此外，它借用 BIP-340 定义的 TaggedHash 来计算短 ID 的盐值哈希。理解本篇，关键在分清“对账协议本身”与“使用对账的高层中继协议”两层：本篇只定前者的消息与算法。

三、它要解决什么

现行做法中，每一对相连的节点之间，每个 32 字节的交易 ID 至少要单向公告一次（通过 INV 消息）。这使公告交易的成本呈“节点数 × 每节点连接数”的量级，带宽开销很高。

基于对账的协议可以有更好的扩展性。若交易中继的带宽扩展性能改善到接近 O(nodes) 且常数开销不高，就能以几乎不增加带宽的代价提高网络连接度（connectivity），让网络更能抵抗分区攻击（partitioning attacks）；同时降低运行比特币节点的带宽需求，潜在地让更多人能运行全节点。

Erlay 设想的工作方式是：每个节点为每个对等节点维护一个对账集，原本要用 INV 公告的交易先放进对账集；每隔一段时间选一个对等节点做一轮对账，双方互相学到对方已知的交易；每轮对账后清空对应集合。这样既省带宽，又基本保持交易传播延迟不变。

本篇就是为这类对账式中继提供 P2P 层的扩展规范。

四、规则本身

4.1 32 位短交易 ID

对账不用完整的 32 字节 WTXID，而用 32 位短 ID：双方各贡献一份盐（salt），排序后按 BIP-340 的 TaggedHash（标签 “Tx Relay Salting”）哈希，取出密钥对 WTXID 做 SipHash-2-4，再映射到 [1..0xFFFFFFFF] 区间。短 ID 近似均匀分布，这是把它们当作 32 位草图元素的前提。每条连接使用独立盐，可把非对抗模型下的碰撞率控制在低水平。

BIP-331

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-331
标题	Ancestor Package Relay
作者	Gloria Zhao <gloriajzhao@gmail.com>
指定日期	2022-08-08
讨论日期	2022-05-17
层级	Peer Services（对等服务）
类型	Specification（规范类）
状态	Draft（草案）
阅读版	https://bips.dev/331
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0331.mediawiki

二、放在哪一族

P2P 交易中继与内存池策略族，核心概念是“包”（package）：一组以花费关系相连的未确认交易。本篇只定义在网络上“怎么要、怎么给”一个包的消息层；包能否被内存池接受，还取决于另一套安全的包接受策略，原文将后者列为实现本协议的前提。

它的前提与邻居包括：

BIP-339：基于 WTXID 的交易中继，包中交易一律以 WTXID 引用，包中继要求双方都支持 wtxid 中继

BIP-133：feefilter 消息，手续费过滤会影响低费祖先能否被公告，本篇专门讨论了与它的配合

BIP-330：交易公告对账（Erlay），原文指出使用对账中继的客户端可以无冲突地叠加包中继：对账后发现某笔交易有未确认祖先，再用祖先包中继补齐

三、它要解决什么

3.1 高费率交易要能带着低费祖先一起传播

自 0.13 版起，Bitcoin Core 在内存池评估与选币打包时就以祖先包而非单笔交易为单位计算费率。但在传播与接受环节，若只逐笔考虑，一笔交易单独不达内存池最低费率时就会被拒绝或驱逐；用户想给它挂一笔高费子交易来“子付父费”（CPFP）也做不到——子交易会因为花费不存在的输入被拒；想用高费后代替换一笔冲突交易（RBF）同样受阻。

后果是用户加费的手段被削弱。更严重的是，依赖预签名、时效性交易的合约协议（如闪电网络的 HTLC-Timeout、Revault、DLC、Eltoo 等）有一条关键安全假设：各方能及时传播并确认交易。攻击者利用内存池策略限制阻止交易传播或上链的“钉住攻击”（pinning attacks），正是钻了逐笔接受的空子。若预报费率太低又无加费手段，对手方就可能窃取资金；一味高估手续费只能在流量低且可预测时凑效，还浪费用户的钱。

理论上，只要有安全且激励相容的包内存池接受策略就够了，但让节点靠自己试凑被拒交易的组合，既低效又可能打开新的拒绝服务攻击面。因此需要新的 P2P 消息，让节点之间高效、可靠地交换包验证所需的信息。

3.2 更好地处理孤儿交易

按 txid 中继有个毛病：交易的见证数据被篡改时 txid 不变，节点无法用 txid 对已下载或已验证的交易去重。两个都支持 BIP-339 的节点之间，理应不再需要 txid 中继；唯一残留场景是处理“孤儿”交易——花费了本节点尚不知道的未确认交易的输出。

孤儿交易很常见：新节点刚完成初始区块下载、内存池还没跟上，或者从多个对等节点并发下载时子交易先于父交易到达。旧处理办法是把孤儿存进缓存、按 txid（prevout 里写的只有 txid）逐代索取缺失的父交易，既要求节点为未验证数据分配内存，又迫使两个 wtxid 中继节点回退到 txid 中继。本篇让孤儿消解更高效，且不再需要 txid 中继。

3.3 基本术语

父/子：Tx1 花费 Tx0 的输出，则 Tx0 是父、Tx1 是子。祖先/后代：递归地包含父母的父母、子女的子女。包：一列可用有向无环图表示的未确认交易。祖先包：某笔未确认交易加上它的全部未确认祖先。拓扑排序：父交易在列表中排在子交易之前。

BIP-332

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-332
标题	Stale Tip Relay
作者	Anthony Towns <aj@erisian.com.au>, w0xlt <woxlt.dev@gmail.com>, Ram <pseudoramdom@proton.me>
指定日期	2026-08-21
讨论日期	2026-07-29
层级	Peer Services（对等服务）
类型	Specification（规范类）
状态	Draft（草案）
依赖文档	Requires: BIP-434
阅读版	https://bips.dev/332
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0332.md

二、放在哪一族

P2P 区块中继的旁支族，处理的是“没能成为主链的区块”这一平时被丢弃的信息。既有的 headers、inv、block 等中继消息都是围绕活跃链（active chain）设计的：它们不表达“这一支是落败的过时分支”、该以哪个已知区块为重建起点、发送方是否能提供该分支的区块数据。BIP-332 因此另设一条专用消息，而不复用现成消息去硬凑。

它的协商机制不另起炉灶，而是依赖：

BIP-434：对等节点功能协商，本篇用它来协商 staletip 功能支持，未协商成功不得发送

BIP-324：v2 P2P 加密传输协议，本篇明确不为 staletip 预留它的 1 字节消息类型 ID

BIP-325：Signet，测试网络部分专门讨论了默认 signet 上过时分支的特殊情况

它在定位上是一项可选的对等服务：节点完全验证活跃链、正常服务对等节点，都不需要知道任何过时分支。

三、它要解决什么

矿工偶尔会产出过时区块（stale blocks）：区块本身或其区块头有效，却没有成为节点活跃链的一部分。这类区块目前基本被网络沉默地丢弃，但它们其实是有用的信号。

首先，过时区块的出现率反映新区块传遍全网矿工的速度，出现率异常升高可能是多种网络问题的症状：传播退化或拥塞、网络分区，或自私挖矿等对抗性挖矿行为。

其次，若某个过时区块与当前活跃链尖累计工作量相同，活跃链尖可能被重组为该过时区块的子区块；节点若已提前下载（甚至已验证）该区块，重组会更快。过时区块的内容还能揭示不同矿池之间出块策略的差异。

原文同时强调：这些好处对网络运行并非必需，因此本篇把它设计为可选功能，性能要求低、资源上限严格。

基本术语：活跃链是节点当前选定的最佳链；过时分支是从某个已知区块派生、但其链尖不在活跃链上的一串有效区块头；过时链尖（stale tip）就是该分支的最后一个区块头。

四、规则本身

4.1 staletip 消息

新增一条可选的 P2P 消息 staletip，载荷由三部分组成：

fork_point（uint256）：分叉点区块哈希，即第一个压缩区块头的“前一区块哈希”所指的区块，必须是接收方已知的区块，通常是过时分支与接收方活跃链的最后一个共同区块，也可以是双方预计都已知的过时分支上的更靠后的区块，此时只发未知的后缀；
headers：CompressedHeader 向量，按链顺序构成 fork_point 之后的一条单一线性分支，最后一个就是过时链尖；每条竞争分支要单独发一条 staletip；
have_block（bool）：发送方是否愿意提供该过时分支的区块数据。置真表示发送方当前拥有过时链尖（最后一个头）的完整区块数据并愿意经正常区块下载机制提供，也应愿意提供其拥有的该分支更早区块；置假则对可用性不作任何声称。发送方不应在预期请求会失败时把该标志置真。

布尔值只允许单字节 \x00 或 \x01，其他编码为畸形。向量长度用 CompactSize 编码，只支持最小编码。

BIP-337

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-337
标题	Compressed Transactions
作者	Tom Briar <tombriar11@protonmail.com>
指定日期	2024-02-01
层级	API/RPC（接口）
类型	Specification（规范类）
状态	Draft（草案）
阅读版	https://bips.dev/337
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0337.mediawiki

二、放在哪一族

交易序列化与接口族。本篇被归在 API/RPC 层，参考实现落成的也是两个新的 RPC 端点，而不是新的共识规则或 P2P 消息：它定义的是一种在软件之间搬运交易时可用的紧凑编码，解压后必须还原出原来那笔逐字节的标准交易。

它与既有交易形态的关系是“编码层”的关系：被压缩的对象仍然是普通的比特币交易，涵盖 P2PK、P2PKH、P2SH、P2WPKH、P2WSH、P2TR 等脚本类型，原文的测试向量就分别给出了 Taproot、P2WPKH、P2SH-P2WPKH 与 P2PKH 交易压缩前后的对照。

原文提到的一个应用背景是：已有一个进行中的 app，用隐写术把数据编码进图片、经各类社交媒体群组传递；配合本压缩方案与 elligator squared 加密，可以构造一种非常安全、私密的交易广播方式。本篇本体只定压缩方案，不规范隐写或广播渠道本身。

三、它要解决什么

典型的比特币交易里有大量“空白与填充”：许多字段实际上只取少数几个可能值中的一个，却都按完整的 32 位或固定长度存放。原文主张，利用这一事实与若干类似手法，可以为约 90% 的比特币交易构造一种编码，使其大小约为原来的 25%–50%。

压缩后的交易序列化大小可降到原交易的一半以下。其中一种手法——压缩交易的输出点（outpoint）——在原文表述中，是一种“可能有损”（potentially lossy）的途径，因此被设为可选路径；但要让压缩交易降到原大小的 70% 以下，压缩输出点又是必要的。

四、规则本身

4.1 四种主要手法

原文列出的四种主要压缩方法是：

在交易数据之前、以及每个输入与输出之前打包元数据，用元数据决定后续数据结构如何解读；
把 32 位数值换成变长整数（VarInt）或紧凑整数（CompactSize）编码；
使用压缩后的签名，并在解压时做公钥恢复；
把 36 字节的输出点（txid/vout 对）替换为区块高度与索引。

4.2 基本原语

CompactSize（1–5 字节）：0–253 直接用一个字节；254–65535 用 254 加两个小端字节；65536 到 2^32−1 用 255 加四个小端字节。
CompactSize Flag（2 位）：取值 1、2、3 表示字面值；0 表示随后会跟一个 CompactSize 编码的数值。
VarInt（1 字节以上）：7 位小端编码，每字节装 7 位，最高位为 1 表示后面还有字节，为 0 表示最后一字节。
VLP-Bytestream（2 字节以上）：带 VarInt 长度前缀的字节流，先用 VarInt 给出长度，再跟相应长度的数据。

4.3 总体结构与交易元数据

一笔压缩交易依次由：1 字节交易元数据、按元数据决定是否出现的版本/输入计数/输出计数/LockTime（各为 CompactSize 编码）、可选的最低区块高度（VarInt）、全部输入与输出的元数据、输入数据、输出数据组成。

BIP-338

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-338
标题	Disable transaction relay message
作者	Suhas Daftuar <sdaftuar@chaincode.com>
指定日期	2020-09-03
层级	Peer Services（对等服务）
类型	Specification（规范类）
状态	Closed（已关闭）
阅读版	https://bips.dev/338
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0338.mediawiki

二、放在哪一族

对等网络（P2P）协议族，管的是节点之间一条连接用来传什么、不传什么。

它要正式化的，是网络上自 2019 年起已经在用的“只中继区块”连接（block-relay-only connections）：发起方把 version 消息里的交易中继字段设为 false——这个字段由 BIP-37 引入、BIP-60 也有定义——只让区块在这条连接上传播，不走交易，也不理会对方发来的 addr 地址消息。

三、它要解决什么

只中继区块的连接有两个好处，原文 Motivation 说得很清楚：

抗网络分区：多开一些低带宽连接专门传区块，节点在网络被分割、隔离时更有韧性；
不给攻击者画地图：这类连接不中继交易、忽略收到的地址，攻击者更难摸清完整的网络拓扑，而拓扑知识恰恰能降低发动网络分区攻击的成本。

问题在于：连接的“低资源”性质目前只有发起方自己知道。version 消息里的交易中继字段不是连接终身设置——按 BIP-37 的语义，对方日后仍可能开启交易中继。于是接收连接的一方分不清：对面是“永远不中继交易”的轻连接，还是“暂时关着、随时会开”的普通节点；也不知道对方会忽略自己公告的地址——若早知道，就会把地址公告优先给别的对等节点。

后果是节点没法放心地对这类连接放宽入站连接数限制。BIP-338 要补的，就是一个终身有效的声明机制。部署后，节点可以区别对待低资源连接与全中继连接，有望提高全网可接纳的只中继区块连接数量。

四、规则本身

4.1 新消息 disabletx

新增一条名为 disabletx 的消息，内容为空，仅以消息类型标识；
实现本 BIP 的节点，协议版本须为 70017 或更高。

4.2 什么时候发

若节点在给某对等节点的 version 消息中把交易中继字段设为 false，且对方协议版本 ≥ 70017，则可以（MAY）向对方发送 disabletx；
若要发，必须在发送 verack 之前发出；
交易中继字段未出现或为 true 时，绝不能（MUST NOT）发送 disabletx。

4.3 发出或收到之后，禁发的消息

一方只要发送过或收到过 disabletx，双方就都不得再在这条连接上发送以下消息：

BIP-339

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-339
标题	WTXID-based transaction relay
作者	Suhas Daftuar <sdaftuar@chaincode.com>
指定日期	2020-02-03
层级	Peer Services（对等服务）
类型	Specification（规范类）
状态	Deployed（已部署）
阅读版	https://bips.dev/339
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0339.mediawiki

二、放在哪一族

对等网络（P2P）协议族，处在交易中继（transaction relay）这条链路上：节点先用 inv 公告“我有这笔交易”，对方再用 getdata 索取。

它建立在隔离见证（SegWit）之上：wtxid 这个概念由 BIP-141 定义——对包含见证数据的完整交易再做一次哈希；带见证的序列化方式见 BIP-144。BIP-339 做的事，是把中继环节引用交易的标识从 txid 换成 wtxid。

同族邻居：BIP-338（同作者，disabletx 消息，管哪些连接不走交易中继）；更早的中继优化还有 BIP-152 紧凑区块中继。

三、它要解决什么

历史上，inv 公告交易时用的都是 txid——不包含见证数据的哈希。SegWit 被网络采用之后（BIP-141、BIP-143、BIP-144），这一惯例仍未改变，而问题恰恰出在见证上：

一笔交易的见证可以被改动（malleated）而不改变其 txid。于是节点收到一份见证被改过、因而拒绝接受的交易后，当其他对等节点再公告同一个 txid 时，它通常还是会再下载一遍——因为它没法仅凭 txid 区分“这次是完好版本还是又一份被改过的版本”。

反过来处理也不行：如果节点拒绝一次后就拉黑该 txid、再不下载，第三方就能抢先把一份见证被改坏的无效版本公告给各节点，让大家误以为这个 txid 已经“见过且无效”，从而把正版交易的中继堵死。

症结在于公告标识没有承诺见证内容。改用 wtxid——它把见证也算进哈希——两种版本天然是两个不同的标识，上述两难随之消除。这正是原文 Motivation 的完整逻辑。

四、规则本身

4.1 协商消息 wtxidrelay

新增一条名为 wtxidrelay 的空消息（pchCommand == “wtxidrelay”）；
实现本 BIP 的节点，协议版本须为 70016 或更高；
收到协议版本 ≥ 70016 的对等节点的 version 消息后，必须在发送 verack 之前回送 wtxidrelay；
verack 之后才收到的 wtxidrelay，必须忽略或视为无效。

只有双方都发过这条消息的连接，才启用基于 wtxid 的中继。

BIP-34

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-34
标题	Block v2, Height in Coinbase
作者	Gavin Andresen <gavinandresen@gmail.com>
指定日期	2012-07-06
层级	Consensus (soft fork)（共识（软分叉））
类型	Specification（规范类）
状态	Deployed（已激活）
阅读版	https://bips.dev/34
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki

二、放在哪一族

BIP-34 是共识层软分叉族的早期范本，也是区块与交易“版本号升级”这条线的起点。

往前看，它接续的是 BIP-30（重复交易）所暴露的问题：coinbase 交易可能完全重复，交易 ID 会撞车。往后看，它的两阶段阈值升级办法，成为后来软分叉部署的参照，后来的部署方式还包括 BIP-9（version bits）以及把成熟部署“埋入”代码的 BIP-90（Buried Deployments）。

理解 BIP-34，是理解“比特币怎样在不分裂网络的前提下集体同意改规则”的第一课。

三、它要解决什么

原文给的动机有两条：

3.1 演练并明确升级机制

区块与交易都是带版本号的二进制结构，当时都还是版本 1。BIP-34 要引入一条明确的升级路径：网络如何集体同意，把交易的二进制结构、规则与行为一起往前推一版。这次升级本身不大，重点是把机制走通、留档。

3.2 保证区块与交易的唯一性

如果两个 coinbase 交易内容完全相同，它们的交易 ID 也会相同，后一笔会覆盖前一笔的记录，验证与索引都会出问题。给每个新 coinbase 加一个全网独一无二的值——它所在区块的高度——就能从构造上杜绝重复，并帮助未与网络连接时的离线区块验证。

四、规则本身

4.1 规范四条

版本号大于 1 的交易视为非标准交易：官方 Satoshi 客户端不挖也不中继这类交易；
把区块高度作为第一项加入 coinbase 交易的 scriptSig，并把区块版本升到 2。高度的格式是“最小编码的序列化 CScript”：第一个字节是数字所占的字节数（原文注：在主网上，接下来约 150 年内都是 0x03，因为区块数小于 2 的 23 次方减 1），其后是该数字的小端表示（含符号位）。高度指该区块在区块链中的高度，创世区块高度为 0；
75% 规则：最近 1000 个区块中有 750 个版本不低于 2 时，开始拒绝无效的版本 2 区块（testnet3 为最近 100 个中 51 个）；
95% 规则（不归点）：最近 1000 个区块中有 950 个版本不低于 2 时，拒绝一切版本 1 区块（testnet3 为最近 100 个中 75 个）。

4.2 升级是怎样锁定的

阈值分两段：先有四分之三的算力产出 v2 区块，新规则开始对 v2 区块生效；再到 95%，旧版本区块被全体拒绝，升级不可逆。矿工先用脚投票，规则随后才强制——这是典型的矿工激活软分叉节奏。

BIP-340

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-340
标题	Schnorr Signatures for secp256k1
作者	Pieter Wuille <pieter.wuille@gmail.com>; Jonas Nick <jonasd.nick@gmail.com>; Tim Ruffing <crypto@timruffing.de>
指定日期	2020-01-19
讨论日期	2018-07-06
层级	未标注（签名规范）
类型	Specification（规范类）
状态	Deployed（已部署）
阅读版	https://bips.dev/340
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki

二、放在哪一族

签名方案族，是 Taproot 三件套的地基：BIP-340 定签名本身，BIP-341 定 SegWit v1 输出的花费规则，BIP-342 定脚本（Tapscript）里的签名验证语义。后两者的 Schnorr 验证都直接引用本文档的算法。

它接替的不是某一篇旧 BIP，而是比特币自创世以来使用的 ECDSA（配合 SHA256、同一条 secp256k1 曲线）。原文开宗明义：沿用同一条曲线与同一个哈希函数，既有的密钥生成机制（如 BIP-32 及其派生方案）全部保留，不引入对曲线与哈希函数的新安全假设。

下游应用包括：基于线性性质的多签与门限签名协议 MuSig2（BIP-327）、FROST，以及适配器签名（adaptor signatures）、盲签名等构造——这些在原文 Applications 一节都有专门论述。

三、它要解决什么

原文 Motivation 把 Schnorr 相对 ECDSA 的优势列为三条：

可证明安全：Schnorr 签名在随机预言机模型与通用群模型下有安全性证明（强不可伪造，SUF-CMA）；ECDSA 的最好证明结果依赖更强的假设；
不可锻性（non-malleability）：由 SUF-CMA 直接推出。ECDSA 则天生可锻：若 (r, s) 有效，(r, n−s) 对同一消息与公钥同样有效，第三方无需私钥就能把一份有效签名改成另一份——比特币只能靠网络策略规则压住其中一种形态，相关讨论见 BIP-62 与 BIP-146；
线性（linearity）：多方可以协作产生一个对“公钥之和”有效的签名，这是多签、门限签名等上层构造的基石，验证者看到的只是一份普通签名。

既然要新立标准，原文顺手把几个与 Schnorr 本身无关的问题一并解决：签名改用定长 64 字节编码（ECDSA 的 DER 编码变长、最长可达 72 字节）；公钥只编 x 坐标、32 字节（现行压缩公钥是 33 字节）；支持批量验证；最重要的是字节级完全定义——验证算法在每个字节上都没有歧义，保证没人能造出“对部分验证者有效、对另一部分无效”的签名。ECDSA 的 DER 解析当年定义不严，酿成过真实问题，最后要靠 BIP-66 打补丁，原文明确以此为戒。

BIP-341

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-341
标题	Taproot: SegWit version 1 spending rules
作者	Pieter Wuille <pieter.wuille@gmail.com>; Jonas Nick <jonasd.nick@gmail.com>; Anthony Towns <aj@erisian.com.au>
指定日期	2020-01-19
讨论日期	2019-05-06、2019-10-09
层级	Consensus (soft fork)（共识（软分叉））
类型	Specification（规范类）
状态	Deployed（已激活）
依赖	BIP-340
阅读版	https://bips.dev/341
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki

二、放在哪一族

Taproot 三件套的核心一篇。BIP-340 定 Schnorr 签名，BIP-341 定输出结构与花费规则，BIP-342 定脚本路径里脚本的执行语义（Tapscript）；三者同批部署，缺一不可。

往上接的是隔离见证族：Taproot 输出就是 BIP-141 框架下的 SegWit 版本 1 输出；其地址编码是 BIP-350 的 Bech32m。思想来源包括 MAST（默克尔化脚本树，前序提案 BIP-114、BIP-117）与 Greg Maxwell 最初的 Taproot 构想。原文 Design 一节特意划界：新的叹息哈希模式（如 BIP-118）、跨输入聚合等想法不在本批之列，留待独立升级。

激活方式另有专文：BIP-343 曾提出用 BIP8（LOT=true）强制激活本提案，最终未被采用（见第六节）。

三、它要解决什么

原文 Motivation 把目标定为三点，且明确不引入新的安全假设：提高比特币脚本能力的隐私、效率与灵活性。

旧格局下，付款给公钥与付款给脚本是两套互斥的构造，花费时必须把实际执行的条件、乃至脚本全文亮出来。观察者因此能知道：这笔钱原本可以怎么花、有哪些备选路径。而现实中的绝大多数应用，最终的花费往往是“所有参与方都同意”后的一次普通签名——为这一常态付出的，却是把全部条件上链公开的代价。

Taproot 的解法分两层：

默克尔分支：把全部备选脚本组织成一棵默克尔树，花费时只揭示真正执行的那一条，其余分支只以哈希形态出现在证明里，内容永不公开；
Taproot 微调：在此之上，把“公钥路径”与“脚本树”合并进同一个输出。输出只是一个公钥；用密钥路径花费时，外界根本看不出它还承诺了一棵脚本树。

再加上 Schnorr 的密钥聚合：多方公钥可聚合成一个公钥、合作签出一份与单签无异的签名，使“各方同意”的常态正好走最省、最隐蔽的密钥路径。原文还顺手修了签名哈希的几个老问题（见 4.3），并为未来预留了叶子版本与 annex 等升级位。

BIP-342

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-342
标题	Validation of Taproot Scripts
作者	Pieter Wuille <pieter.wuille@gmail.com>; Jonas Nick <jonasd.nick@gmail.com>; Anthony Towns <aj@erisian.com.au>
指定日期	2020-01-19
讨论日期	2019-05-06
层级	Consensus (soft fork)（共识（软分叉））
类型	Specification（规范类）
状态	Deployed（已激活）
依赖	BIP-340、BIP-341
阅读版	https://bips.dev/342
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki

二、放在哪一族

Taproot 三件套的收尾一篇：BIP-340 定 Schnorr 签名，BIP-341 定输出结构与两条花费路径，BIP-342 则回答“脚本路径被走时，叶子里的脚本按什么语义执行”——这套语义称为 Tapscript。

它的基线是 P2WSH 的脚本规则（BIP-141），连同 BIP-65 的 OP_CHECKLOCKTIMEVERIFY 与 BIP-112 的 OP_CHECKSEQUENCEVERIFY；BIP-342 在此之上作增删改。部署方式与 BIP-341 完全相同，两篇是同一次软分叉的两半：341 管“结构”，342 管“脚本内部的规则”。

三、它要解决什么

BIP-341 只改进了脚本的结构（默克尔树、密钥/脚本双路径）。但它要的一部分好处，与脚本语言内部某些操作码的旧语义直接冲突：若不与 341 同时处理，这些好处就无法保证落到脚本路径的花费上。

原文 Motivation 点名的三个目标，都必须在脚本内部兑现：

Schnorr 签名：脚本里的验签操作码仍在验 ECDSA，脚本路径就享受不到新签名；
批量验证：旧的 OP_CHECKMULTISIG 一次验多个签名、与批量验证不兼容，留着它就留着一个堵点；
签名哈希改进：BIP-341 的新签名消息要同样适用于脚本内的签名，且希望借新体系简化 OP_CODESEPARATOR 的处理。

所以 BIP-342 不是可选的后续优化，而是与 341 捆绑的同一批共识改动：目标是在 Tapscript 诞生的第一天，就把验签体系切换干净，而不是先沿用旧语义、日后再改。

BIP-343

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-343
标题	Mandatory activation of taproot deployment
作者	Shinobius <quantumedusa@gmail.com>; Michael Folkson <michaelfolkson@gmail.com>
指定日期	2021-04-25
层级	Consensus (soft fork)（共识（软分叉））
类型	Specification（规范类）
状态	Closed（已关闭）
阅读版	https://bips.dev/343
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0343.mediawiki

二、放在哪一族

它不属于 Taproot 的技术内容，而属于“软分叉怎么激活”的部署机制族。BIP-340、BIP-341、BIP-342 回答 Taproot 是什么；BIP-343 回答的是：万一矿工迟迟不发信号，靠什么保证它最终上线。

机制谱系：BIP-8（按高度锁定的版本位，含 LOT 参数）、BIP-9（版本位投票，BIP-341 实际部署用的是其修改版）、BIP-148（2017 年 SegWit 的强制激活，用户激活软分叉 UASF 的先例）、BIP-91（同年降低阈值的矿工侧协调）。原文致谢也点明：Shaolin Fry 与 Luke Dashjr 在 BIP-148 与 BIP-8 上的工作是本提案的前提。

三、它要解决什么

原文 Motivation 的前提判断是：Taproot 软分叉已被评估为拥有压倒性的社区共识，因此应当尝试激活。真正的风险不在技术，而在一个治理问题：

软分叉的常态部署要靠矿工在信号期发出支持信号、达到阈值才锁定。若矿工始终凑不齐阈值，一项已有压倒性共识的升级就会被无限期挂起——等于矿工对软分叉握有永久否决权。原文认为这不可接受：强制信号条款必须预先写进部署方案，只在矿工未能在常规信号期内达标时才派上用场。

2017 年的教训被明确引用：BIP-148 与 BIP-91 的部署表明，强制信号机制要提前许多个月预警；且 BIP-148 还证明，不同实现采用不同激活机制并行运行，可以互相激励、让各部署最终同步激活。本提案就是按这个剧本，为 Taproot 写的一份“保险丝”部署。

四、规则本身

4.1 部署参数（BIP8，LOT=true）

信号位：区块版本中的比特位 2（与 Taproot 的其他部署方案相同）；
信号开始高度：681408；
最小激活高度：709632；
激活阈值：90%；
信号超时高度：760032，最后激活高度 762048；
Lockinontimeout（LOT）设为 true：一旦 Taproot 在超时前仍未锁定，超时前最后一个信号期将强制执行矿工信号；
在这段强制期里，若 Taproot 此前尚未锁定，不带比特位 2 的区块有被拒绝的风险；
Taproot 一旦锁定，本 BIP 即停止生效——它的全部作用就是把部署推过锁定这道门。

4.2 与实际部署的兼容性（原文专节）

Bitcoin Core 实际发布的激活机制是 Russell O’Connor 提出、由 David Harding 在 bitcoin-dev 邮件列表中概述的“Speedy Trial”：实质上是 BIP8 的一个变体，唯一差别是开始与超时用中位过去时间（MTP）而非区块高度定义；同样使用比特位 2，部署期为 2021 年 4 月 24 日零点至 8 月 11 日零点，最小激活高度同为 709632，目标是激活 BIP-340、BIP-341、BIP-342。原文论证：由于既定开始时点上 MTP 与区块高度没有出现偏差，本 BIP 的 BIP8（LOT=true）部署与 Speedy Trial 相互兼容，可以并行运行而不冲突。

BIP-345

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-345
标题	OP_VAULT
作者	James O'Beirne <vaults@au92.org> Greg Sanders <gsanders87@gmail.com>
指定日期	2023-02-03
讨论日期	2023-01-09
层级	Consensus (soft fork)（共识（软分叉））
类型	Specification（规范类）
状态	Closed（已关闭）
接替文档	Proposed-Replacement: BIP-443
阅读版	https://bips.dev/345
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0345.mediawiki

二、放在哪一族

契约（covenant）与金库（vault）族。它不是孤立的操作码提案，而是和几件已有或在提的工具拼在一起用：

BIP-119：OP_CHECKTEMPLATEVERIFY，把最终提取锁定到一组确定的输出

BIP-112：OP_CHECKSEQUENCEVERIFY，提供相对时间锁，也就是金库的“等待期”

BIP-340、BIP-341、BIP-342：Schnorr 与 Taproot/Tapscript 基础，金库结构建在 Taproot 的 taptree 上，本 BIP 借 OP_SUCCESSx 占位操作码做软分叉升级

原文还提到，它是对更早想法的收敛：2016 年的 Bitcoin Vaults 讨论、2021 年的 TAPLEAF_UPDATE_VERIFY 提案都指向同一种“只替换一个叶子、其余花费条件原样保留”的机制。

档案上它已 Closed，并给出接替文档 BIP-443。读它主要是为了理解“专用契约”这条路线怎样设计金库，而不是把它当作现行规则。

三、它要解决什么

托管比特币的核心风险是私钥一旦被盗，币可以被立刻、不可逆地转走，持有人几乎没有干预窗口。金库的思路是反过来给花费加一道程序：

币先锁进金库结构；
正常提取必须先发起“触发”，然后等一段可配置的延迟（spend delay）；
延迟期内若发现异常——比如私钥已泄露、有人在偷币——持有人可以随时走预设的“恢复路径”（recovery path），把币扫到安全处；
延迟期满且无人干预，提取才按触发时定下的目标完成。

恢复路径因此可以做得极端安全：可以是纸上保存的私钥、不同厂商设备组成的 2-of-3 多签，甚至地理上分散保存——反正它平时根本用不上，只有最坏情况才启用。

在现行共识规则下模拟金库，只能靠预签名交易加一次性密钥，原文列了它的硬伤：金额与提取模式必须预先定死、最终目标要经过一个预先定好的中转地址、手续费方案在建库时就得定、地址复用会丢币、代表金库的交易数据必须永久保存、每存一笔新余额都要重做一遍建库仪式。BIP-345 想用链上契约去掉这些预计算负担。

它的设计目标还有：同一金库配置可反复接收存入、恢复与触发可批量处理、可部分提取而不必重建库、提取目标与手续费都在提取时动态决定。

四、规则本身

4.1 两个新操作码

以软分叉方式重定义两个 Tapscript 占位操作码：

OP_VAULT：重定义 OP_SUCCESS187（0xbb），负责“触发”提取；
OP_VAULT_RECOVER：重定义 OP_SUCCESS188（0xbc），负责走恢复路径。

4.2 金库的结构

币存入一个 Taproot 输出，其 taptree 至少含两个叶子：

BIP-346

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-346
标题	OP_TXHASH
作者	Steven Roose <steven@roose.io> Brandon Black <freedom@reardencode.com>
指定日期	2024-04-24
层级	Consensus (soft fork)（共识（软分叉））
类型	Specification（规范类）
状态	Draft（草案）
阅读版	https://bips.dev/346
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0346.md

二、放在哪一族

交易自省（transaction introspection）与契约族。比特币脚本今天几乎“看不见”正在花费自己的这笔交易：签名校验能间接约束交易，但脚本不能直接读版本号、输入输出等字段。BIP-346 给 Tapscript 加一个最基础的自省原语：按需算出交易选定字段的哈希。

它与几个邻居的关系很紧：

BIP-119：OP_CHECKTEMPLATEVERIFY。本 BIP 是它的严格推广——字段选择器取空值时的默认模板，语义上等同于 CTV 承诺的那组字段。

BIP-348：OP_CHECKSIGFROMSTACK。TXHASH 算出的哈希交给 CSFS 验签，就得到完全通用的签名哈希构造。

BIP-118：SIGHASH_ANYPREVOUT。其签名模式及 ANYPREVOUTANYSCRIPT 等变体，可以用 1 字节选择器 + CSFS 组合模拟出来，不必再单独改签名算法。

BIP-342：Tapscript 规则与 sigops 预算，本 BIP 的升级路径与资源计费都建在它之上。

原文致谢里也点明了血统：想法源自 Russell O’Connor 把 CTV 推广为 TXHASH 的思路，及 Jeremy Rubin 的 BIP-119 工作。

三、它要解决什么

脚本若想对花费交易施加条件——“这笔钱只能这样花”——现有手段只有两类：一是预签名交易（交互式、要保存数据、金额目标定死），二是签名哈希标志间接捎带的条件，粒度粗且不可组合。

OP_TXHASH 的定位是给一个通用的底层原语：脚本指定“把交易的哪些部分拿出来算哈希”，把哈希压回栈上，脚本随后可以：

与预设哈希比较，强制交易长成某个模板（等价于契约）；
把哈希当作待签消息交给 BIP-348 的 OP_CHECKSIGFROMSTACK 验签，等于让签名者对任意选定的交易字段组合签字，由此拼出包括现有全部 SIGHASH 标志、BIP-118 新标志在内的各种签名哈希模式；
在多方协议里只约束与自己有关的输入输出，其余部分放行——原文举的例子是：多方共同出资的交易里，各方只盯自己那份，手续费追加也不必推翻整个协议。

原文还指出，TxFieldSelector 这套字段选择编码将来可复用于一个假想的 OP_TX（直接把字段压栈而不哈希），算出的 TransactionHash 也可能被未来的 SegWit 版本用作原生签名哈希。但这些是铺垫，不是本 BIP 的内容。

BIP-347

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-347
标题	OP_CAT in Tapscript
作者	Ethan Heilman <ethan.r.heilman@gmail.com> Armin Sabouri <arminsdev@gmail.com>
指定日期	2023-12-11
讨论日期	2023-10-21
层级	Consensus (soft fork)（共识（软分叉））
类型	Specification（规范类）
状态	Complete（已完成）
依赖	BIP-340、BIP-341、BIP-342
阅读版	https://bips.dev/347
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0347.mediawiki

二、放在哪一族

Tapscript 能力扩展族，也是“恢复早期被禁用操作码”这一脉。本 BIP 只做一件事：把拼接操作带回 Tapscript，因此它依赖 Taproot 的整套基础：

BIP-340：Schnorr 签名

BIP-341：Taproot 输出结构

BIP-342：Tapscript 验证规则；本 BIP 正是走它留下的 OP_SUCCESSx 软分叉升级路径

它常与同批的小原语一起被讨论，如 BIP-348（OP_CHECKSIGFROMSTACK）：原文列举的若干用法——比如在脚本内拼出待验签的数据再验签、构造默克尔树——靠的是 CAT 的拼接加上哈希与验签类操作码配合。原文还专门比较了它与金库的关系：按 Andrew Poelstra 的构造，OP_CAT 本身即足以在比特币上搭出金库（vault），与 BIP-345 的专用金库操作码是两种不同路线。

三、它要解决什么

Tapscript 没有一种通用的办法把栈上的两个值拼起来。这看似小事，却卡住了整整一类构造：脚本无法自己拼装并计算默克尔树及其他哈希数据结构，表达能力因此受限。

原文列举了 OP_CAT 能解锁或大幅简化的用途（非穷尽）：

Bitstream：用比特币原子交换文件解密密钥的协议；没有 CAT 时要靠复杂昂贵的可验证计算，有了 CAT 可去掉这一要求；
树签名（tree signatures）：脚本体积只随公钥数量对数增长的多签，还能表达 n-of-m 之外的逻辑条件；原文举例，不到 1KB 的交易可支持多达 4,294,967,296 个公钥的树签名；
Lamport 后量子签名：这类签名只要求能对栈上值做哈希与拼接；原文同时提醒，Taproot 输出还有密钥路径，量子攻击者可能绕过脚本路径，这一条并非现成的抗量子方案；
非否认合约（non-equivocation contracts）：对支付通道中的双花/说谎行为施加罚没；
金库：借助 CAT 与 Schnorr 的技巧构造契约与金库，无需预签名交易；
复刻 CHECKSIGFROMSTACK 类构造：进而做简单的契约；
BitVM2 的改进：原文称 OP_CAT 可让 BitVM2 去掉其证明系统中的可信设置、并减小所用交易体积。

历史背景：OP_CAT 在早期比特币里本来就有，2010 年被一个提交连同另外 15 个操作码一并禁用。流传的说法是它可被用来构造求值时内存占用随脚本长度指数膨胀的脚本——例如把 1 字节值反复 OP_DUP、OP_CAT 四十次。本 BIP 的回应是：Tapscript 已强制栈元素最大 520 字节，这个口子在今天的规则下不存在了。

BIP-348

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-348
标题	CHECKSIGFROMSTACK
作者	Brandon Black <freedom@reardencode.com> Jeremy Rubin <j@rubin.io>
指定日期	2024-11-26
层级	Consensus (soft fork)（共识（软分叉））
类型	Specification（规范类）
状态	Draft（草案）
阅读版	https://bips.dev/348
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0348.md

二、放在哪一族

Tapscript 验签能力扩展族。比特币脚本原有的 OP_CHECKSIG 只能验证“对当前这笔花费交易的签名哈希”的签名；BIP-348 把验签的对象换成栈上任意给出的数据，是 Tapscript 走向更通用合约的一块拼图。

它和邻居是配套关系：

BIP-340：Schnorr 签名方案，本 BIP 的验签完全按它执行

BIP-342：Tapscript 规则；本 BIP 在其叶子版本 0xc0 语境下替换 OP_SUCCESS 占位操作码，验签计费也用它的 sigops 预算

BIP-119：OP_CHECKTEMPLATEVERIFY。与 CSFS 组合可实现闪电网络的 LN Symmetry 通道（见下节）

BIP-346：OP_TXHASH。TXHASH 算出交易哈希、CSFS 对它验签，两者相加即得到完全通用的签名哈希构造

BIP-349：OP_INTERNALKEY。同作者同批提案；CSFS 的设计讨论里明确说，APO 式的内部公钥用法不塞进本 BIP，而由 BIP-349 单独承担

历史上 CHECKSIGFROMSTACK 先在 Elements 侧链实现，本 BIP 的参考实现即参照它、并以 Bitcoin Core 的拉取请求形式给出（原文 Implementation 一节链接 PR #29270）。

三、它要解决什么

OP_CHECKSIG 的验签对象被共识写死：只能是当前交易的签名哈希。这意味着脚本无法要求“某人对某段任意数据签过名”——比如对一个模板哈希签名、对一条委托声明签名。想绕开只能靠各种技巧，复杂且受限。

BIP-349

Mon, 01 Jan 0001 00:00:00 +0000

一、档案卡

档案卡

编号	BIP-349
标题	OP_INTERNALKEY
作者	Brandon Black <freedom@reardencode.com> Jeremy Rubin <j@rubin.io>
指定日期	2024-11-14
层级	Consensus (soft fork)（共识（软分叉））
类型	Specification（规范类）
状态	Draft（草案）
阅读版	https://bips.dev/349
官方原文	https://github.com/bitcoin/bips/blob/master/bip-0349.md

二、放在哪一族

Tapscript 小原语族，而且是同批提案里最小的一个：整份规范的核心只有一句话。它与以下文档配套：

BIP-341：Taproot。它定义了“内部公钥”（internal key）——构造 Taproot 输出时先定的那把公钥，之后与脚本树一起做 tweak 得到最终输出公钥。本 BIP 压栈的正是这把内部公钥。

BIP-342：Tapscript 验证规则。本 BIP 在其叶子版本 0xc0 语境下替换 OP_SUCCESS 占位操作码。

BIP-348：OP_CHECKSIGFROMSTACK，同作者同批。两者常组合：INTERNALKEY 把内部公钥取出来，CSFS 拿它对某段消息验签。

BIP-118：SIGHASH_ANYPREVOUT。原文 Credits 说明，INTERNALKEY 的想法源自 2022 年 Russell O’Connor 与 Jeremy Rubin 在 Bitcoin Wizards IRC 的讨论，灵感来自 BIP-118 对内部公钥的“双关”用法（key punning）。

读它不需要先懂整套契约理论；它解决的是一个非常具体的别扭：脚本在执行时，明明身处某个 Taproot 输出之内，却读不到这个输出的内部公钥，想引用它只能把 32 字节公钥原文再抄一份进脚本，白花体积。

三、它要解决什么

原文列了三个动机场景：

给密钥路径再加脚本条件：构造 Taproot 输出时，尤其是内部公钥是多方聚合公钥的场合，各方可能希望仍用内部公钥协作签名（走密钥路径），但要叠加额外的脚本限制。脚本里引用内部公钥时，用 OP_INTERNALKEY 可省 8 vBytes——省的是重复写一遍 32 字节公钥的开销。
减轻哈希锁脚本的控制块负担：不打算用密钥路径花费时，内部公钥通常设为一个 NUMS 点（谁都没有对应私钥的点）。带哈希锁的脚本若本来就要在 Tapscript 里写下这个 NUMS 点的字节，改用 OP_INTERNALKEY 引用它又可省 8 vBytes。原文附带提醒：内部公钥必须是 SECP256K1 曲线上某点的 X 坐标，所以充当它的哈希值要反复调整直到恰好是一个合法 X 坐标，平均约需试 2 次。
换钥时保住默克尔根（re-keying）：考虑形如 CTV <X> CSFS <S+1> CLTV 的脚本片段（原文称这类片段对 LN-Symmetry 应用有用），嵌在 TR(X, {...}) 里。若内部公钥从 X 换成 Y，叶子里写死的 <X> 就与新内部公钥对不上了。把叶子改写成引用 OP_INTERNALKEY，叶子会自动跟着新内部公钥走：TR(Y, {CTV OP_INTERNALKEY CSFS <S+1> CLTV}) 等价于把片段里的 X 换成 Y。原文说，这个一般性技巧是一种有用的契约原语：当希望让旧状态的签名失效时（例如假想的操作码 OP_TAPLEAFUPDATEVERIFY 直接改内部公钥来增减参与方），各脚本路径都能统一改用调整后的公钥。