[137608] in cryptography@c2.net mail archive
Re: Bitcoin P2P e-cash paper
daemon@ATHENA.MIT.EDU (Satoshi Nakamoto)
Fri Nov 14 17:29:13 2008
Date: Sat, 15 Nov 2008 02:55:35 +0800
From: "Satoshi Nakamoto" <satoshi@vistomail.com>
Reply-To: satoshi@vistomail.com
To: hal@finney.org
Cc: cryptography@metzdowd.com, jamesd@echeque.com
Hal Finney wrote:
> I think it is necessary that nodes keep a separate=20
> pending-transaction list associated with each candidate chain.=20
> ... One might also ask ... how many candidate chains must=20
> 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 m=
ain branch down to the fork, returning the block transactions to the pen=
ding-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. T=
hey just sit on the disk and don't require attention unless they ever be=
come the main chain.
> Or as James raised earlier, if the network broadcast=20
> is reliable but depends on a potentially slow flooding=20
> algorithm, how does that impact performance?
Broadcasts will probably be almost completely reliable. TCP transmissio=
ns 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 broa=
dcasts 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 gene=
rate them, otherwise nodes would spend too much time working on obsolete=
blocks.
I'm planning to run an automated test with computers randomly sending pa=
yments 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 contributio=
n
> to the world by their efforts (similar to the various "@Home" compute
> projects where people volunteer their compute resources for good cause=
s).
>=20
> In this case it seems to me that simple altruism can suffice to keep t=
he
> network running properly.
It's very attractive to the libertarian viewpoint if we can explain it p=
roperly. I'm better with code than with words though.
Satoshi Nakamoto
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
