Block-header-only, faster startup client #7

issue gavinandresen openend this issue on December 20, 2010
  1. gavinandresen commented at 1:53 pm on December 20, 2010: contributor

    Bitcoin newbies have to endure an hour or two (or more) while bitcoin downloads and indexes all transactions and blocks.

    Satoshi has mostly implemented code that downloads just the block headers; as long as you’re not generating blocks, you don’t need all the old transactions.

  2. gavinandresen commented at 5:44 pm on December 20, 2010: contributor

    See the blockheaders feature branch here for initial work on this. Notes from Satoshi:

    CBlockIndex contains all the information of the block header, so to operate with headers only, I just maintain the CBlockIndex structure as usual. The nFile/nBlockPos are null, since the full block is not recorded on disk.

    The code to gracefully switch between client-mode on/off without deleting blk*.dat in between is not implemented yet. It would mostly be a matter of having non-client LoadBlockIndex ignore block index entries with null block pos. That would make it re-download those as full blocks. Switching back to client-mode is no problem, it doesn’t mind if the full blocks are there.

    If the initial block download becomes too long, we’ll want client mode as an option so new users can get running quickly. With graceful switch-off of client mode, they can later turn off client mode and have it download the full blocks if they want to start generating.

  3. laanwj referenced this in commit 50d08dc1e1 on Sep 18, 2011
  4. sipa referenced this in commit d73bad33e8 on Jun 2, 2013
  5. bardiharborow commented at 11:50 am on March 29, 2014: contributor
    @gavinandresen, we need to add another service category (NODE_SPV??) for SPV clients, so that they can operate without getting queried for blocks by other peers.
  6. laanwj commented at 11:54 am on March 29, 2014: member
    Why, how is this any different from what SPV clients do? See #3884 for another step towards this.
  7. bardiharborow commented at 0:24 am on March 30, 2014: contributor
    @laanwj, my understanding is that most SPV clients at the moment either get headers from a centralised source (Electrum) or use their own p2p network. I don’t know, some may use the main Bitcoin network, but wouldn’t they be queried for blocks by other clients and have to ignore those requests which could confuse the other peer (maybe?). I think it would be neater if other peers knew that you could be asked for headers, but not for blocks/txs. Anyway, sorry to bring up an old issue. Just thought someone should start working through the massive backlog, so I started from the back.
  8. christophebiocca commented at 0:29 am on March 30, 2014: none
    @bardiharborow SPV nodes talk to full nodes, not to each other (although that might be possible as well?). There’s a service bit specifically for offering full blocks instead of just headers: https://en.bitcoin.it/wiki/Protocol_specification#version
  9. sipa commented at 3:06 pm on March 30, 2014: member

    Electrum does SPV validation, but is in the strictly technical sense not an SPV node, as it does not participate in the P2P network.

    Actual SPV nodes (like Bitcoin Wallet for Android or Multibit) do connect to the P2P network (only to other full nodes, service flag NODE_NETWORK), and fetch blocks and headers from it. SPV nodes so far don’t connect to each other, both because they provide very little service (most don’t even keep all old headers around) and because they are only online sporadically.

  10. bardiharborow commented at 9:36 pm on March 30, 2014: contributor
    I’ve just realised that nodes can chose not to advertise their IP, which I assume is what they do. Does anyone know how hard this would be to implement? The only technical discussion seems to be 3 years old. Wouldn’t we also need a way of being alerted to transactions and downloading merkle branches? (This may already exist but the wiki maybe out of date and I’m not completely on top of the code.)
  11. sipa commented at 9:38 pm on March 30, 2014: member

    All this exists. SPV clients are used, and the protocol provides everything necessary. See BIP37 for example.

    The only thing we don’t have is the ability to run the reference code base in such an SPV client mode, where it doesn’t do full block validation. There are several steps towards that, but the first is certainly headers-first synchronization.

  12. laanwj commented at 2:18 am on March 31, 2014: member
    @bardiharborow This has all been done years ago. Please move questions like these to the stack exchange or forums, or #bitcoin on IRC. Github is not the place for basic discussion like this.
  13. justmoon referenced this in commit 3de48d4a52 on Apr 7, 2014
  14. kac- referenced this in commit 3eb6774e8a on Apr 22, 2014
  15. laanwj added the label P2P on May 9, 2014
  16. kac- referenced this in commit 35f0a4e2e9 on Oct 8, 2014
  17. gavinandresen commented at 6:28 pm on October 28, 2014: contributor
    Headers-first download merged. And there are plenty of SPV wallets. Closing this.
  18. gavinandresen closed this on Oct 28, 2014

  19. rdponticelli referenced this in commit 920c243932 on Nov 26, 2014
  20. rubensayshi referenced this in commit 2dd28153fd on Mar 16, 2015
  21. dexX7 referenced this in commit 23e8332381 on Apr 8, 2015
  22. TheBlueMatt referenced this in commit 704d415d05 on Oct 20, 2015
  23. brishtiteveja referenced this in commit 3ebf38ee00 on Jan 25, 2016
  24. braydonf referenced this in commit c8ee50d671 on May 12, 2016
  25. tempgit9 referenced this in commit 9562d65297 on Jan 16, 2017
  26. AkioNak referenced this in commit 4cc1ea7290 on Jul 24, 2017
  27. MarcoFalke referenced this in commit 351fadd68a on Dec 19, 2017
  28. MarcoFalke referenced this in commit 88411e98e5 on Dec 19, 2017
  29. classesjack referenced this in commit 3f731c8379 on Jan 2, 2018
  30. hkjn referenced this in commit 3aab98f8dc on Jan 13, 2018
  31. hkjn referenced this in commit 7e80175d2b on Feb 23, 2018
  32. KrzysiekJ referenced this in commit 2759850592 on Mar 28, 2018
  33. effectsToCause referenced this in commit 2fea219d9c on Jun 22, 2018
  34. dginovker referenced this in commit d2186b3db6 on Jul 29, 2018
  35. MarcoFalke referenced this in commit 4d550ffab6 on Jul 30, 2018
  36. hashtobewild referenced this in commit 8ef8754605 on Aug 26, 2018
  37. dooglus referenced this in commit 94bef303b0 on Oct 20, 2018
  38. DigiGreenCoin referenced this in commit 010b7f223f on Oct 29, 2019
  39. MarcoFalke referenced this in commit cf43f3f0a8 on Dec 5, 2019
  40. Warchant referenced this in commit 7958da26e8 on Dec 31, 2019
  41. Bushstar referenced this in commit 01915f3cc6 on May 5, 2020
  42. MarcoFalke referenced this in commit 4946400470 on Jun 26, 2020
  43. laanwj referenced this in commit 31bdd86631 on Jul 15, 2020
  44. KolbyML referenced this in commit 1a313221ad on Aug 1, 2020
  45. KolbyML referenced this in commit fb35e0e26f on Sep 4, 2020
  46. laanwj referenced this in commit 924a4ff7eb on Oct 29, 2020
  47. jonasschnelli referenced this in commit c33662a0ea on Dec 2, 2020
  48. KolbyML referenced this in commit 3d9f0283ff on Dec 5, 2020
  49. MarcoFalke referenced this in commit 590e49ccf2 on Apr 4, 2021
  50. MarcoFalke referenced this in commit bce09da122 on Apr 28, 2021
  51. fanquake referenced this in commit fa00bb2c5c on Apr 29, 2021
  52. MarcoFalke referenced this in commit eb9a1fe037 on May 7, 2021
  53. laanwj referenced this in commit ee9befe8b4 on May 12, 2021
  54. MarcoFalke referenced this in commit c857148636 on May 15, 2021
  55. satindergrewal referenced this in commit 46ce232dc0 on Jun 22, 2021
  56. 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: 2024-05-18 10:13 UTC

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