You've already forked nakamoto-archive
wakgill
72 lines
2.3 KiB
Markdown
72 lines
2.3 KiB
Markdown
---
|
|
layout: default
|
|
title: Bitcoin P2P e-cash paper
|
|
grand_parent: Emails
|
|
parent: Cryptography Mailing List
|
|
nav_order: 15
|
|
date: 2008-11-17 17:24:43 UTC
|
|
---
|
|
|
|
# Bitcoin P2P e-cash paper
|
|
|
|
Satoshi describes how long he has worked on coding Bitcoin.
|
|
{: .fs-6 .fw-300 }
|
|
|
|
---
|
|
|
|
```
|
|
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
|
|
```
|