Re: Bitcoin P2P e-cash paper — Cryptography mailing list ("I'm better with code than with words")
Document text
Research, not advice. Part of the Bitcoin research archive (October 2026). Claims labelled unverified, contested or fringe are reported, not endorsed; statuses of bills and rules are as of the date checked. Government, court and patent records are public domain; the research notes are CC BY 4.0.
Bitcoin P2P e-cash paper | Satoshi Nakamoto Institute The Complete SatoshiLibraryMempoolNewsletter Donate Toggle languageEN Open main menu The Complete SatoshiLibraryMempoolNewsletter The Complete Satoshi /Emails /Cryptography Emails Cryptography Mailing List Bitcoin P2P e-cash paper 12 From: Satoshi Nakamoto Subject: Bitcoin P2P e-cash paper Date: November 14, 2008 at 18:55:35 UTC 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 View originalView in thread About Contact Podcasts Feed Newsletter Donate Get involved GitHub X Nostr Satoshi Nakamoto Institute Established block #272,311 Satoshi Nakamoto Institute is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. Some works may be subject to other licenses.