Create 15.md

2021-01-01 14:59:59 -06:00
parent 66dbcc0a0f
commit a6c3787151
1 changed files with 70 additions and 0 deletions
@@ -0,0 +1,70 @@
 ---
 layout: default
 title: Bitcoin P2P e-cash paper
 grand_parent: Emails
 parent: Cryptography Mailing List
 nav_order: 15
 ---
 # Bitcoin P2P e-cash paper
 The email on the Cryptography Mailing List that announced Bitcoin publicly to the world.
 {: .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
 ```