Don't pick up every transaction in entire history #2183

issue pascalBokBok opened this issue on January 16, 2013
  1. pascalBokBok commented at 1:26 PM on January 16, 2013: none

    The space required to run the bitcoin-qt client is quickly running amok. Currently my .bitcoin directory is 8,3 GB on my disk - which is a lot on a SSD. Also it takes a very long of time to sync - which means it's hard for newcomers to start.

    The current implementation regarding storing every transaction has started to put a heavy burden on me as a user.

  2. Diapolo commented at 2:49 PM on January 16, 2013: none

    This is IMHO no issue to be posted on Github.

  3. pascalBokBok commented at 2:57 PM on January 16, 2013: none

    Where then?

  4. Diapolo commented at 3:00 PM on January 16, 2013: none

    Perhaps via IRC or the bitcointalk.org forums, but I consider issue directly related to specific issues with the client. Your complaint may be true, but in terms of development process or coding changes it's much more of a long-term goal. Great work is currently done, as @sipa did a great job with switching to another block/coin database and reduce file-sizes and a whole lot of other things.

  5. sipa commented at 3:03 PM on January 16, 2013: member

    @pascalBokBok Just to clarify: the purpose of the reference client is being an implementation of a full Bitcoin node. It can by definition not do anything but verify every transaction in history.

    There are a number of solutions, if this is a problem:

    • If you're unable to spend the resources required, you can run a lightweigh (SPV) client like MultiBit, which uses a lower security model, but is a lot faster (as it doesn't verify transactions, only block headers) and doesn't need to store transactions the user isn't interested in.
    • Even though a fully validation node is required to verify everything, it doesn't necessarily need to store everything indefinitely. Changing this poses risks to the network (as nodes still need to find archive nodes that do have history to bootstrap from), but it will probably be implemented some time.
    • We might move to a model where the client also incorporates a lighter security model, and upgrades itself when possible/chosen by the user. This is a big change, and will probably take a while before it is implemented.
  6. pascalBokBok commented at 3:25 PM on January 16, 2013: none

    @sipa cool. Didn't know about multibit. According to multibit installer: "MultiBit is experimental software. Do not use it with large amounts of bitcoin." Since I administer an associations bitcoins I'm somewhat hesitant to use it.

    Problem is people can't get started without waiting 24 hours with their computer online and their mobile broadband quota being killed.

  7. laanwj commented at 3:35 PM on January 16, 2013: member

    It's a compromise between security and bandwidth use/cpu time. Verifying everything is safest, and that's what the satoshi client does. You can't have both.

    This is a well-known discussion and with a little searching you find it a zillion times in other places. Let's close this issue.

  8. luke-jr commented at 3:54 PM on January 16, 2013: member

    @pascalBokBok All of Bitcoin is experimental...

  9. Diapolo commented at 5:43 PM on January 16, 2013: none

    @laanwj ACK to close this "issue".

  10. gavinandresen closed this on Jan 16, 2013

  11. MarcoFalke locked this on Sep 8, 2021

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2026-04-13 21:16 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me