鸟在笼中恨关羽不能张飞，人处世上要八戒更须悟空。
佛在心中恨酒色不能杀盗，神处世上要三清更须元始。

---------------人缘慧链

FaceBlock(非比技术资本)简介

让天下没有难创的业。
—FaceBlock(非比技术资本)

致力于最新金融科技财富机遇把握，结合区块链和AI技术创新，打造以人为本的投资模式，构建每个人的信用社交资本（Social Dao），实现一个全新的分布式商业自组织！！让科技创新的成果最大回馈真正的奋斗者！ 抢金融机遇，分利润股权！！！

具体合作目标：
1，引领99名科技创新创业者实现财务自由

2，打造可以自盈利的金融套利交易工具

3，为每一位科技创新者和商业产品运营大咖，提供个人数据NFT IP发行网络财富变现机遇

加油，所有的FBer一起共识、共建、共生一个诚信、透明、真实的元宇宙数字世界！

信用价值互联网邀请链接:
http://www.faceblock.io/?ref=Frex
app下载地址:
https://m3w.cn/faceblock

faceBlock open source now: 　https://github.com/faceblockteam

In Yuan, We Trust !
人缘链

来吧，一起玩耍！

faceBlock创始人 华源慧
2021/10

http://www.chinavalue.net/pvisit/WSCOTTSTORNETTA.aspx


价值中国：在最初创业阶段，即使您经历了一些失败，您是否始终认为区块链技术是一种下一个如同“互联网”一样颠覆性的技术呢？为什么？您是如何考虑其影响或影响的呢？

斯科特：因为我始终认为区块链技术是充满希望的，我始终坚信，区块链技术将受到广泛的认可和应用，区块链肯定是互联网量级的核心、基础技术，只是需要花费一点时间让人们去接受它。

价值中国：您如何看待比特币和区块链之间的关系？从技术理论上看，是否有可能有人能发明了一种不利用区块链技术的分布式货币？

斯科特：在谈论区块链技术的应用和影响之前，我想先谈谈比特币。

关于我和比特币，是很奇妙的缘分。有一天我收到了一封邮件，里面写了比特币相关的事情，写信人表示他对这项新兴的科技非常感兴趣，他注意到了我和Stuart Haber的研究在其中有所涉及，然后，有一个叫中本聪的人在我和Stuart Haber的研究之上做了更进一步的发展。人们发现了我的研究成果在比特币中被多次引用，并且我还会说日语，所以他们在怀疑我是否是那篇作品的原创作者中本聪。事实上我不是，但是我去了解了中本聪的论文，以及他的研究，是非常厉害非常了不起的研究。

我和他取得了联系，他告诉我，有人写邮件问他，他所提出的比特币和我所提出的数字时间戳之间的联系是怎样的，中本聪回答，比特币是数字时间戳的更为分布式的应用，并且专门应用于金钱交易上。所以早期区块链和比特币的关系正如他所说的这样，比特币是区块链的一个应用。比特币创造了一个新的货币体系，这是一个了不起的成就。但区块链还有很多其他的应用，除了获得最多关注的比特币，区块链仍需要进一步发展。我坚信数字货币在未来也会有更大的发展空间，但它必然是在区块链技术基础之上的，而非脱离区块链，但它不一定要沿用今天被称为比特币的技术。

区块链的特征

价值中国： 众所周知，“数字时间戳”的发明对区块链来说极为重要，核心在于，它解决了安全问题。您能解释一下加密数字时间戳和区块链之间的关系吗？

斯科特：这个问题我之前已经回答了一部分，所以我再简单地再阐述一下。加密数字时间戳技术就是早期的区块链技术，他们就是同一件事情。不像比特币和区块链，它们有很大的差别。许多人对区块链和比特币的关系有所争议，但我认为更重要的事情是要推动未来区块链技术的发展。

价值中国：有人认为去中心化不是区块链的必然特征，分布式技术和去中心化也可能不是一回事。您是如何看待这种观点的呢？

斯科特：这个问题非常重要，我特别重视——区块链的主要特征是分布式记录，记录被分布是非常必要的，换句话说，目前区块链的算法也是分布式的，这也是比特币的核心技术。所以，我同意文件记录需要被分布储存这个想法。但算法是否一定要是去中心化的算法呢，也许并不是必要的，我们有许多其他的办法可以解决算法的问题，而并不是必须要采用比特币的发展模式。目前已经有一些新的办法被创造出来，我们非常期待看见更多的新方法出现去推动技术的进步。

我再清楚地总结一下我的观点，第一，记录是否需要被分布呢？答案是肯定的，只有确保分布式记录，才能保证记录不可篡改，这是区块链的核心技术。第二，算法是否需要是分布式的呢？我认为在一些情况下需要，而另一些情况下不需要，这主要取决于应用的主要目的。第三，整个社会的掌控者和领导者是否需要被分布呢？我认为这取决于具体情况，大部分人可能会不同意我的看法，但是我始终坚持我的看法，并且我认为我的看法最终会被证明是正确的。

如何分布统治者就像如何运行算法，我们个人、个体在市场上是处于弱势地位，而统治阶层是处于强势地位，这样的力量对比在一些情况下是有益的，而一些情况下并非如此。所以我觉得这些问题不能只用一个简单的“是或者不是”的答案来回答，这取决于具体的情况和具体的立场。我自己的公司名字是日文“幽玄”，意思是沉思，我的立意也就是希望自己在发展的大潮中保持清醒，从不同的角度思考问题，而并非“随波逐流”地赚取利益。

http://satoshinakamoto.me/whitepaper/
http://satoshinakamoto.me/bitcoin.pdf

Re: Bitcoin P2P e-cash paper
NOVEMBER 17, 2008 SATOSHI NAKAMOTO CRYPTOGRAPHY MAILING LIST
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

Re: Bitcoin P2P e-cash paper
NOVEMBER 17, 2008 SATOSHI NAKAMOTO CRYPTOGRAPHY MAILING LIST
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

Welcome to SatoshiNakamoto.me
OCTOBER 14, 2016 SCRIBER META
Welcome to SatoshiNakamoto.me. This website is dedicated to preserving the history and integrity of Bitcoin’s mysterious and elusive creator.

Every single public post that Satoshi Nakamoto wrote until he stopped posting publicly on December 13, 2010 is cataloged and categorized in chronological order for a searchable database to serve as future reference.

There are several ways to use this site, such as using the sidebar Sources to go through Satoshi’s writings by category (places he wrote), or using the Search to lookup his (or her) writings by keyword. You can also go through the Archives to review writings by date. There are also interesting statistics to review about when Satoshi wrote.

You can learn more about SatoshiNakamoto.me using the About page and can follow the site’s creator on Twitter @Satoshi_Says.

Satoshi Nakamoto

Bitcoin 0.2 released!
DECEMBER 16, 2009 SATOSHI NAKAMOTO BITCOIN TALK
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.