• Skip to primary navigation
  • Skip to content
  • Skip to footer

Nakamoto Studies Institute

  • Satoshi Writings
    • Satoshi’s White Paper
    • Satoshi Nakamoto Emails
    • Satoshi Nakamoto Forum Writings
  • Literature
    • Daniel Krawisz Archive
  • About NSI
  • Newsletter
  • Support
You are here: Home / Emails / Re: Bitcoin P2P e-cash paper

Re: Bitcoin P2P e-cash paper

November 14, 2008 by bitcoincash

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 [EMAIL PROTECTED]

Notable Selections:

It’s very attractive to the libertarian viewpoint if we can explain it properly. I’m better with code than with words though.

Filed Under: Emails Tagged With: altruism, hal finney, libertarian, tcp

Support NSI with Bitcoin Cash

Did you like this piece? Please consider dropping a tip to support our ongoing efforts to archive the work of Satoshi Nakamoto. Small tips are only made possible with Bitcoin Cash!

Footer

Categories

  • Code
  • Emails
  • Forums
  • Literature
  • Uncategorized

Keywords

adam back anonymous b-money bitcoin.org Bitcoin: A Peer-to-Peer Electronic Cash System bitcointalk bug commerce double spend dustin d. trammel gavin andresen generate coins gnutella gpu hal finney hashcash hash cash inflation james a. donald liberty standard linux micropayment mike hearn moore's law napster nicholas bohm node non-reversible transaction p2p foundation proof-of-work ray dillinger satoshi nakamoto scaling Simplified Payment Verification sirius-m the crypto anarchist manifesto" the cryptography mailing list timothy c. may tor transaction fee v0.1.6 visa wei dai white paper [bitcoin-list]

Support NSI with Bitcoin Cash

Copyright © 2020 · Genesis Sample on Genesis Framework ·