Make peer=%d log prints consistent #9486

pull TheBlueMatt wants to merge 11 commits into bitcoin:master from TheBlueMatt:2017-01-peer-log-consistency changing 8 files +205 −62
  1. TheBlueMatt commented at 4:49 pm on January 7, 2017: member
    Based on #9375, this changes all the “peer %d"s in net_processing to “peer=%d” which was far more common.
  2. Make CBlockIndex*es in net_processing const 80175472d1
  3. [qa] Make compact blocks test construction using fetch methods 9a0b2f4c5b
  4. [qa] Avoid race in preciousblock test.
    If node 0 is sufficiently fast to announce its block to node 1,
    node 1 might already have the block by the time the
    node_sync_via_rpc loop gets around to node 1, resulting in the
    submitblock result "duplicate-inconclusive" as node 1 has the block,
    but prefers an alternate chain.
    8baaba653e
  5. Call AcceptBlock with the block's shared_ptr instead of CBlock& 180586fd44
  6. Add a CValidationInterface::NewPoWValidBlock callback 6987219577
  7. Relay compact block messages prior to full block connection c802092142
  8. Cache most-recently-announced block's shared_ptr 9eaec08dd2
  9. Cache most-recently-connected compact block 5749a853b9
  10. Ensure we meet the BIP 152 old-relay-types response requirements
    In order to do this, we must call ActivateBestChain prior to
    responding getdata requests for blocks which we announced using
    compact blocks.
    
    For getheaders responses we dont need code changes, but do note
    that we must reset the bestHeaderSent so that the SendMessages call
    re-announces the header in question.
    
    While we could do something smarter for getblocks, calling
    ActivateBestChain is simple and more obviously correct, instead of
    doing something more similar to getheaders.
    
    See-also the BIP clarifications at
    https://github.com/bitcoin/bips/pull/486
    9eb67f5000
  11. Avoid holding cs_most_recent_block while calling ReadBlockFromDisk c1ae4fcf7d
  12. MarcoFalke added the label Docs and Output on Jan 7, 2017
  13. Make peer id logging consistent ("peer=%d" instead of "peer %d") e6111b2398
  14. morcos commented at 7:39 pm on January 9, 2017: member
    utACK. Thanks!
  15. morcos commented at 7:40 pm on January 9, 2017: member
    Please tag for 0.14
  16. fanquake added this to the milestone 0.14.0 on Jan 9, 2017
  17. whitemagpie commented at 9:42 am on January 10, 2017: none
    My first review as a noob - please let me know if I am making a mistake. Thanks! utAck 8017547 utAck e6111b2 utAck 180586f utAck 8baaba6 utAck c1ae4fc
  18. MarcoFalke commented at 10:33 am on January 10, 2017: member

    @whitemagpie This is based on #9375, so you might want to review that first.

    On Tue, Jan 10, 2017 at 10:42 AM, Tuhina notifications@github.com wrote:

    My first review as a noob - please let me know if I am making a mistake. Thanks! utAck 8017547 utAck e6111b2 utAck 180586f utAck 8baaba6 utAck c1ae4fc

    — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

  19. laanwj commented at 12:51 pm on January 10, 2017: member
    Concept ACK
  20. in src/validation.cpp: in 80175472d1 outdated
    3037         LOCK(cs_main);
    3038         for (const CBlockHeader& header : headers) {
    3039-            if (!AcceptBlockHeader(header, state, chainparams, ppindex)) {
    3040+            // cast away the ppindex-returns-const CBlockIndex - we're just assigning it to a CBlockIndex*
    3041+            // that we own and is updated non-const anyway
    3042+            if (!AcceptBlockHeader(header, state, chainparams, const_cast<CBlockIndex**>(ppindex))) {
    


    jtimon commented at 5:54 pm on January 10, 2017:
    I’m not sure I understand this. AcceptBlockHeader doesn’t take it as const since it modifies it. Why should ProcessNewBlockHeaders take it as const?
  21. jtimon commented at 6:03 pm on January 10, 2017: contributor
    utACK https://github.com/bitcoin/bitcoin/pull/9486/commits/e6111b2398ca21f0e38333236abb0be7fa48c95f as an indepdent commit, but I still haven’t reviewed #9375 (which contains the rest of the commits). At a fast glance I don’t see why that commit needs to depend on #9375 and couldn’t be trivially merged independently instead thought.
  22. TheBlueMatt commented at 6:40 pm on January 10, 2017: member

    re: the const_cast, see the original PR, there’s a discussion about it there.

    On January 10, 2017 9:54:44 AM PST, “Jorge Timón” notifications@github.com wrote:

    jtimon commented on this pull request.

    { { LOCK(cs_main); for (const CBlockHeader& header : headers) {

    •        if (!AcceptBlockHeader(header, state, chainparams,
      

    ppindex)) {

    •        // cast away the ppindex-returns-const CBlockIndex - we're
      

    just assigning it to a CBlockIndex*

    •        // that we own and is updated non-const anyway
      
    •        if (!AcceptBlockHeader(header, state, chainparams,
      

    const_cast<CBlockIndex**>(ppindex))) {

    I’m not sure I understand this. AcceptBlockHeader doesn’t take it as const since it modifies it. Why should ProcessNewBlockHeaders take it as const?

    – You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/bitcoin/bitcoin/pull/9486#pullrequestreview-15973887

  23. jtimon commented at 2:11 am on January 13, 2017: contributor
    Thoughts on making this independent from #9375 and trivial to review and merge?
  24. instagibbs commented at 3:22 pm on January 13, 2017: member
    grep utACK https://github.com/bitcoin/bitcoin/pull/9486/commits/e6111b2398ca21f0e38333236abb0be7fa48c95f @whitemagpie It’s easier to ACK the “latest” commitment only since commits are hash chained
  25. laanwj commented at 5:44 am on January 15, 2017: member
    utACK e6111b2
  26. laanwj merged this on Jan 15, 2017
  27. laanwj closed this on Jan 15, 2017

  28. laanwj referenced this in commit f62bc10a60 on Jan 15, 2017
  29. codablock referenced this in commit 5db2eaec96 on Feb 7, 2018
  30. codablock referenced this in commit 7daefe10f6 on Feb 7, 2018
  31. codablock referenced this in commit cef919f182 on Feb 7, 2018
  32. gladcow referenced this in commit b26525c841 on Mar 8, 2018
  33. gladcow referenced this in commit 43480ef30f on Mar 13, 2018
  34. gladcow referenced this in commit 3e76f2dc35 on Mar 14, 2018
  35. gladcow referenced this in commit 12d083e64d on Mar 15, 2018
  36. gladcow referenced this in commit 14ad1fecdc on Mar 15, 2018
  37. gladcow referenced this in commit 07a01daae7 on Mar 15, 2018
  38. gladcow referenced this in commit 7e230fec1a on Mar 15, 2018
  39. gladcow referenced this in commit e1b0ff93d7 on Mar 24, 2018
  40. gladcow referenced this in commit 22553a022c on Apr 4, 2018
  41. UdjinM6 referenced this in commit bc45a2f87a on Apr 11, 2018
  42. andvgal referenced this in commit da2d909670 on Jan 6, 2019
  43. andvgal referenced this in commit fd5c50bc2b on Jan 6, 2019
  44. CryptoCentric referenced this in commit dc2ef27d5e on Feb 28, 2019
  45. CryptoCentric referenced this in commit dd3fd51204 on Feb 28, 2019
  46. CryptoCentric referenced this in commit ad4400172c on Mar 2, 2019
  47. DrahtBot 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-10-04 19:12 UTC

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