[doc / test / mempool] unbroadcast follow-ups #18807

pull amitiuttarwar wants to merge 10 commits into bitcoin:master from amitiuttarwar:2020-01-unbroadcast-followup changing 9 files +68 −22
  1. amitiuttarwar commented at 9:36 pm on April 28, 2020: contributor

    This PR is a follow up to #18038 which introduced the idea of an unbroadcast set & focuses mostly on documentation updates and test fixes. One small functionality update to not throw an expected error in LoadMempool when you upgrade software versions.

    #18895 is another follow up to that addresses other functionality updates.

    Background context: The unbroadcast set is a mechanism for the mempool to track locally submitted transactions (via wallet or RPC). The node does a best-effort of delivering the transactions to the network via retries every 10-15 minutes until either a GETDATA is received or the transaction is removed from the mempool.

  2. DrahtBot added the label Docs on Apr 28, 2020
  3. DrahtBot added the label Mempool on Apr 28, 2020
  4. DrahtBot added the label P2P on Apr 28, 2020
  5. DrahtBot added the label Tests on Apr 28, 2020
  6. DrahtBot added the label Validation on Apr 28, 2020
  7. DrahtBot added the label Wallet on Apr 28, 2020
  8. amitiuttarwar force-pushed on Apr 29, 2020
  9. amitiuttarwar force-pushed on Apr 29, 2020
  10. DrahtBot commented at 2:42 am on April 29, 2020: member

    The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

    Conflicts

    No conflicts as of last run.

  11. fanquake referenced this in commit 0ef0d33f75 on Apr 29, 2020
  12. DrahtBot added the label Needs rebase on Apr 29, 2020
  13. in doc/release-notes.md:97 in 0dd03ca9b3 outdated 
    91@@ -87,6 +92,13 @@ New settings
92 Wallet
93 ------
94 
95+- To improve wallet privacy, the frequency of wallet rebroadcast attempts has
96+  been reduced from approximately once every 15 minutes to approximately once a
97+  day. To maintain a similar level of guarantee for initial broadcast of wallet
    jonatack commented at 11:02 am on April 29, 2020:
    suggest s/approximately once a day/once every 12-36 hours/
    amitiuttarwar commented at 0:54 am on May 15, 2020:
    sure. changed
  14. in test/functional/wallet_resendwallettransactions.py:67 in 0dd03ca9b3 outdated 
    65+        assert_equal(node.p2ps[1].tx_invs_received[txid], 0)
66+
67+        self.log.info("Bump time & check that transaction is rebroadcast")
68+        # Transaction should be rebroadcast approximately 24 hours in the future,
69+        # but can range from 12-36. So bump 36 hours to be sure.
70+        rebroadcast_time = int(time.time()) + 36 * 60 * 60
    jonatack commented at 11:08 am on April 29, 2020:

    Suggestion as per #18038 (review) with only one call to time.time() and two info logging statements.

     0        # Check transaction is rebroadcast in 12-36 hour time interval.
 1        time_now = int(time.time())
 2
 3        self.log.info("Bump time 12 hours from now, check transaction is not yet rebroadcast")
 4        rebroadcast_time = time_now  + (12 * 60 * 60)
 5        node.setmocktime(rebroadcast_time)
 6        assert_equal(node.p2ps[1].tx_invs_received[txid], 0)
 7
 8        self.log.info("Bump time 36 hours from now, check transaction is rebroadcast")
 9        rebroadcast_time = time_now + (36 * 60 * 60)
10        node.setmocktime(rebroadcast_time)
11        wait_until(lambda: node.p2ps[1].tx_invs_received[txid] >= 1, lock=mininode_lock)
    amitiuttarwar commented at 1:02 am on May 15, 2020:

    so, I took a closer look at this part of the test, and as @jnewbery pointed out in that thread, the test wasn’t actually checking anything (not just the additional check after 12 hour bump, but the existing one as well).

    I’ve updated so there’s just one “transaction should not be rebroadcast” check, and that it occurs after we’ve bumped almost 12 hours into the future.

  15. jonatack commented at 11:10 am on April 29, 2020: member
    Quick first pass, will review after rebase.
  16. in src/net_processing.cpp:822 in 0dd03ca9b3 outdated 
    817+    for (const uint256& txid : unbroadcast_txids) {
818+        RelayTransaction(txid, *connman);
819+    }
820+
821+    // schedule next run for 10-15 minutes in the future
822+    // add randomness on every cycle to avoid possibility of p2p fingerprinting
    jnewbery commented at 3:35 pm on April 29, 2020:
    Format in sentences please
    amitiuttarwar commented at 1:24 am on May 15, 2020:
    fixed
  17. jnewbery commented at 3:36 pm on April 29, 2020: member
    Concept ACK. Will review fully once this is rebased.
  18. sidhujag referenced this in commit 7fc0f22e3d on Apr 29, 2020
  19. fjahr commented at 4:34 pm on April 29, 2020: member
    Concept ACK
  20. brakmic commented at 4:47 pm on April 30, 2020: contributor

    Concept ACK.

    Built, run and tested the code on macOS Catalina 10.15.4. Both tests were successful. Commit 0dd03ca9b3531ac8c4ede030bb075b882b588f79

    0./test/functional/mempool_unbroadcast.py   (13s 854ms) │
12020-04-30T16:35:16.018000Z TestFramework (INFO): Initializing test directory /var/folders/7q/4ffytzk562dd2ky4bfg9_w7h0000gn/T/bitcoin_func_test_ngy9nfi0
22020-04-30T16:35:19.438000Z TestFramework (INFO): Test that mempool reattempts delivery of locally submitted transaction
32020-04-30T16:35:19.994000Z TestFramework (INFO): Generate transactions that only node 0 knows about
42020-04-30T16:35:21.479000Z TestFramework (INFO): Reconnect nodes & check if they are sent to node 1
52020-04-30T16:35:25.579000Z TestFramework (INFO): Add another connection & ensure transactions aren't broadcast again
62020-04-30T16:35:27.753000Z TestFramework (INFO): Test that transactions removed from mempool are removed from unbroadcast set
72020-04-30T16:35:28.071000Z TestFramework (INFO): Stopping nodes
82020-04-30T16:35:28.595000Z TestFramework (INFO): Cleaning up /var/folders/7q/4ffytzk562dd2ky4bfg9_w7h0000gn/T/bitcoin_func_test_ngy9nfi0 on exit
92020-04-30T16:35:28.596000Z TestFramework (INFO): Tests successful

    0./test/functional/wallet_resendwallettransactions.py  (13s 961ms)  
12020-04-30T16:36:05.847000Z TestFramework (INFO): Initializing test directory /var/folders/7q/4ffytzk562dd2ky4bfg9_w7h0000gn/T/bitcoin_func_test_k0jcybzc
22020-04-30T16:36:07.329000Z TestFramework (INFO): Create a new transaction and wait until it's broadcast
32020-04-30T16:36:17.090000Z TestFramework (INFO): Create a block
42020-04-30T16:36:17.213000Z TestFramework (INFO): Bump time & check that transaction is rebroadcast
52020-04-30T16:36:17.584000Z TestFramework (INFO): Stopping nodes
62020-04-30T16:36:18.055000Z TestFramework (INFO): Cleaning up /var/folders/7q/4ffytzk562dd2ky4bfg9_w7h0000gn/T/bitcoin_func_test_k0jcybzc on exit
72020-04-30T16:36:18.055000Z TestFramework (INFO): Tests successful

    Will do a full review after rebase.

  21. amitiuttarwar force-pushed on May 1, 2020
  22. DrahtBot removed the label Needs rebase on May 1, 2020
  23. Sjors commented at 6:53 pm on May 4, 2020: member

    the node will try to announce unbroadcast transactions until a peer requests it via a GETDATA

    If I was a bully node, I would send a GETDATA back to any node who announces a transaction I haven’t seen yet. Is that kind of behaviour punished at the p2p level? Would it make sense to require that the GETDATA comes from a node that we never told about the transaction? Or that it comes from at least two nodes?

  24. fanquake removed the label Docs on May 6, 2020
  25. amitiuttarwar commented at 3:28 am on May 6, 2020: contributor

    @gzhao408 has kindly taken over the follow-ups that change the codebase functionality in #18895 .

    I’ll use this PR to focus on updates to tests & docs. but currently still WIP.

    @Sjors

    If I was a bully node, I would send a GETDATA back to any node who announces a transaction I haven’t seen yet. Is that kind of behaviour punished at the p2p level?

    nodes requesting announced txns they haven’t seen is … desired :) but I think what you’re getting at is the attacker might request but then not propagate. I don’t see a way a peer could directly know if the other node propagated the transaction. So yes, we’d have to use another heuristic to try to evaluate that question.

    but something to keep in mind.. transactions on the unbroadcast set are queued for every peer (ReattemptInitialBroadcast calls RelayTransaction which iterates through each node). so the attacker sending back a GETDATA would also have to somehow interrupt me from sending out to the other peers, be my only connection, etc.

    Would it make sense to require that the GETDATA comes from a node that we never told about the transaction?

    we don’t usually get unsolicited GETDATA messages, but maybe what you’re considering here is getting an INV from a peer we didn’t announce it to. I considered this sort of approach in earlier iterations of the design (announce to some peers, wait for it to come back from others), but it seems unnecessary & a significant change to current txn propagation.

    Or that it comes from at least two nodes?

    also considered this approach, but over the course of review comments it didn’t seem necessary bc some of the reasons talked about above. all of this design discussion is scattered throughout #18038 if you’re interested in digging deeper :)

  26. amitiuttarwar force-pushed on May 15, 2020
  27. in test/functional/wallet_resendwallettransactions.py:53 in b9866b92ef outdated 
    48@@ -49,16 +49,21 @@ def run_test(self):
49         block.solve()
50         node.submitblock(ToHex(block))
51 
52-        # Transaction should not be rebroadcast
53         node.syncwithvalidationinterfacequeue()
54-        node.p2ps[1].sync_with_ping()
55+        now = int(time.time())
    amitiuttarwar commented at 1:23 am on May 15, 2020:

    @MarcoFalke I removed the sync_with_ping() call because I think its a no-op, but I’d like your review to make sure I’m not (re)introducing a race in weird conditions.

    my understanding: sync_with_ping() is a p2p interface method that ensures any messages it has sent to the node have been processed by the node.

    the syncwithvalidationinterfacequeue() makes sense to me bc that’s making sure the wallet gets notified about the block.

    since we’re trying to check if the wallet kicks off rebroadcasting the transaction, so this synchronization should not be relevant? it was definitely not sufficient. the test previously wasn’t checking anything bc it didn’t give enough time for a rebroadcast to kickoff, so I’ve added a time.sleep() call.

    tldr; I removed the sync_with_ping() bc I think it was a no-op & misleading. I’ve added a time.sleep(2) to actually test that a transaction isn’t rebroadcast. please lmk if I’m missing something.

    MarcoFalke commented at 10:29 am on May 15, 2020:

    sync_with_ping() is a p2p interface method that ensures any messages it has sent to the node have been processed by the node.

    Correct. Also, any messages that the node has put in the send buffer (before the pong is sent) will get “flushed out” to the mininode.

    amitiuttarwar commented at 4:46 pm on May 15, 2020:
    so, do you agree that seems irrelevant here?
  28. amitiuttarwar renamed this:
    [WIP] unbroadcast follow-ups
    [doc / test / mempool] unbroadcast follow-ups
    on May 15, 2020
  29. amitiuttarwar commented at 1:54 am on May 15, 2020: contributor
    review comments addressed, additional release notes added & WIP removed.
  30. in doc/release-notes.md:70 in b9866b92ef outdated 
    64@@ -65,6 +65,14 @@ Notable changes
65 P2P and network changes
66 -----------------------
67 
68+- The mempool now tracks transactions submitted via the wallet or rpcs as
69+  unbroadcast transactions. Every 10-15 minutes, the node will try to announce
70+  unbroadcast transactions until a peer requests it via a `GETDATA`, or the
    MarcoFalke commented at 12:22 pm on May 15, 2020: 
    0  unbroadcast transactions until a peer requests it via a `getdata` message, or the
    amitiuttarwar commented at 8:46 pm on May 17, 2020:
    updated
  31. in doc/release-notes.md:72 in b9866b92ef outdated 
    64@@ -65,6 +65,14 @@ Notable changes
65 P2P and network changes
66 -----------------------
67 
68+- The mempool now tracks transactions submitted via the wallet or rpcs as
69+  unbroadcast transactions. Every 10-15 minutes, the node will try to announce
70+  unbroadcast transactions until a peer requests it via a `GETDATA`, or the
71+  transaction is removed from the mempool for other reasons. If you have a
72+  custom setup to use P2P messages to submit a local transaction to your node
    MarcoFalke commented at 12:23 pm on May 15, 2020: 
    0  custom setup to use P2P messages to submit a transaction that belongs to a loaded wallet to your node

    local means wallet, right?

    amitiuttarwar commented at 4:56 pm on May 15, 2020:

    kind of.. I’ve been using the language “local” because it could be wallet, or submitted via sendrawtransaction. similarly, if we’re talking about these edge cases, someone could theoretically form a transaction & give it to me out of band, then I submit from one computer to my main node via my highly specific custom P2P setup that involves being disconnected from the greater internet. but I guess every valid transaction involves some loaded wallet?

    lol. it all seems like quite an edge case. maybe here I can just remove the word “local”.

    new:

    If you have a custom setup to use P2P messages to submit a transaction to your node while it is not connected to other nodes, these changes reduce your initial broadcast guarantees. (#18038)

    MarcoFalke commented at 5:55 pm on May 15, 2020:

    If you have a custom setup to use P2P messages to submit a transaction to your node while it is not connected to other nodes, these changes reduce your initial broadcast guarantees

    This has always been the case. Your pull didn’t change that.

    amitiuttarwar commented at 6:06 pm on May 15, 2020:
    oh. great point. lol ok I’ll update to wallet.
    amitiuttarwar commented at 7:41 pm on May 15, 2020:

    is there a reason you’ve suggested “that belongs to a loaded wallet” rather than just wallet transaction?

    would be relevant if your wallet address is receiving too, right?

    amitiuttarwar commented at 8:47 pm on May 17, 2020:
    updated to “wallet transaction”, lmk if you have further thoughts
    MarcoFalke commented at 11:37 am on May 18, 2020:
    how would bitcoin core know that this is a wallet transaction when the wallet is not loaded? Maybe this is clear to everyone reading the sentence, but I think the distinction should be made to avoid potential confusion.
    amitiuttarwar commented at 2:23 am on May 20, 2020:

    ah, this was my misunderstanding. I was interpreting “loaded wallet” to mean (wallet has spendable funds aka utxos) vs (node has wallet component loaded)

    also looked in the code and realized that watchonly is a wallet only thing.

    I get what you’re saying now. I’m thinking about how to clarify the language.

    amitiuttarwar commented at 8:13 pm on May 23, 2020:
    ok. recruited harding & revamped the description. @MarcoFalke what do you think now? @harding thanks so much for your help. I continued tinkering with the language, let me know if you have any further recommendations
  32. MarcoFalke commented at 12:23 pm on May 15, 2020: member
    some questions on the release notes
  33. amitiuttarwar force-pushed on May 17, 2020
  34. in test/functional/wallet_resendwallettransactions.py:61 in eed809422e outdated 
    58+        # Leave 2 mins for buffer
59+        twelve_hrs = 12 * 60 * 60
60+        two_min = 2 * 60
61+        node.setmocktime(now + twelve_hrs - two_min)
62+        time.sleep(2) # ensure enough time has passed for rebroadcast attempt to occur
63         assert_equal(node.p2ps[1].tx_invs_received[txid], 0)
    glozow commented at 10:01 pm on May 20, 2020:

    Would you want to grab the lock? And also since this function is pretty handy?

    0        assert_equal(txid in node.p2ps[1]get_invs(), False)
    amitiuttarwar commented at 8:07 pm on May 23, 2020:
    good call, updated.
  35. in doc/release-notes.md:78 in 16f56f5ff7 outdated 
    73+  while it is not connected to other nodes, these changes reduce your initial
74+  broadcast guarantees. (#18038)
75+
76 Updated RPCs
77 ------------
78
    glozow commented at 10:29 pm on May 20, 2020:

    Since it seems you’ll need to include the rpc info [from #18895](/bitcoin-bitcoin/18895/#issuecomment-630998986) I wanted to help draft a description:

    0- `getmempoolinfo` now returns an additional `unbroadcastcount` field which represents the number of transactions that the mempool considers unbroadcast.
1- Mempool RPCs such as `getmempoolentry` and `getrawmempool` with `verbose=true`now return an additional "unbroadcast" field which indicates whether the mempool considers this transaction unbroadcast.
    amitiuttarwar commented at 8:07 pm on May 23, 2020:
    thanks! added with some extra info
  36. glozow commented at 10:32 pm on May 20, 2020: member
    Been trying to keep an eye on this PR since it’s closely related to #18895 so I thought I’d leave a couple comments :)
  37. fanquake commented at 11:22 am on May 23, 2020: member
    There’s a comment from @harding here about a change you might want to include in this PR.
  38. amitiuttarwar force-pushed on May 23, 2020
  39. amitiuttarwar commented at 8:21 pm on May 23, 2020: contributor
    rebased the branch, addressed review comments, added release notes for RPC updates from #18895 (thanks for getting that started @gzhao408) and updated language as per #18895 (review)
  40. MarcoFalke removed the label Mempool on May 23, 2020
  41. MarcoFalke removed the label Tests on May 23, 2020
  42. MarcoFalke removed the label Validation on May 23, 2020
  43. MarcoFalke removed the label Wallet on May 23, 2020
  44. in doc/release-notes.md:85 in 866081579b outdated 
    80+  mempool tracks locally submitted transactions until their initial broadcast
81+  is acknowledged by a peer. This field returns the count of transactions
82+  waiting for acknowledgement.
83+
84+- Mempool RPCs such as `getmempoolentry` and `getrawmempool` with
85+  `verbose=true` now return an additional "unbroadcast" field. This indicates
    MarcoFalke commented at 8:25 pm on May 23, 2020: 
    0  `verbose=true` now return an additional `unbroadcast` field. This indicates
  45. MarcoFalke approved
  46. MarcoFalke commented at 8:26 pm on May 23, 2020: member
    Looks good now. Thx
  47. in doc/release-notes.md:68 in 866081579b outdated 
    64@@ -65,9 +65,28 @@ Notable changes
65 P2P and network changes
66 -----------------------
67 
68+- The mempool now tracks whether transactions submitted via the wallet or rpcs
    jonatack commented at 10:09 pm on May 23, 2020:
    suggestion: s/rpcs/RPCs/
  48. in doc/release-notes.md:87 in 866081579b outdated 
    82+  waiting for acknowledgement.
83+
84+- Mempool RPCs such as `getmempoolentry` and `getrawmempool` with
85+  `verbose=true` now return an additional "unbroadcast" field. This indicates
86+  whether initial broadcast of the transaction has been acknowledged by a
87+  peer. `getmempoolancestors` and `getmempooldescendants` are also impacted.
    jonatack commented at 10:14 pm on May 23, 2020:
    I think the word “impacted” is odd here as it is often used to denote a negative connotation. Perhaps “updated”, “also benefit from this change”, etc.
  49. in doc/release-notes.md:110 in 866081579b outdated 
    105@@ -87,6 +106,13 @@ New settings
106 Wallet
107 ------
108 
109+- To improve wallet privacy, the frequency of wallet rebroadcast attempts has
110+  been reduced from approximately once every 15 minutes to once every 12-36
    jonatack commented at 10:17 pm on May 23, 2020:
    Each of these three release note entries employs a different verb tense: future (“will try/will not track”) in the first entry, present (“now returns/tracks/returns”) in the second one, and a form of past (“has been reduced”) tense at the beginning of the third one. Perhaps use a consistent verb tense.
    amitiuttarwar commented at 6:33 pm on May 25, 2020:

    hm, I updated this one to be present (“has been reduced” -> “is reduced”).

    I read through the other ones and the difference between present & future makes sense to me… eg.

    The mempool now tracks whether transactions submitted via the wallet or RPCs have been successfully broadcast. Every 10-15 minutes, the node will try to announce unbroadcast transactions until…

    the present “now tracks” indicates how the code has changed, but the future “will try” is what happens when you run the code in the future.

    so I’ve left them for now. if you have any specific suggestions, I’m happy to consider them.

  50. in src/txmempool.h:722 in 866081579b outdated 
    719         LOCK(cs);
720         return m_unbroadcast_txids;
721     }
722 
723-    // Returns if a txid is in the unbroadcast set
724+    /** Returns if a txid is in the unbroadcast set */
    jonatack commented at 10:20 pm on May 23, 2020:

    s/if/whether/

    (it does not return only if true)

  51. jonatack commented at 10:25 pm on May 23, 2020: member
    Light review with a few minor suggestions below (feel free to ignore).
  52. [docs] add release notes dab298d9ab
  53. [test] updates to unbroadcast test 
    - add () to function to actually disconnect from p2pconn
- extract max interval into a constant
- disconnect at the end of a subtest rather than start of next
    bd093ca15d
  54. [test] P2P connection behavior should meet expectations 
    - P2PTxInvStore should supplement `on_inv` behavior of parent, not overwrite.
    00d44a534b
  55. [test] Test that wallet transactions aren't rebroadcast before 12 hours ba54983182
  56. [mempool] Don't throw expected error message when upgrading 9c8a55d9cb
  57. [doc] Provide rationale for randomization in scheduling. 1f94bb0c74
  58. [test] Manage node connections better in mempool persist test 
    there were two calls to disconnect_nodes that were no-ops. fixed one & removed
the other & added assertions to confirm node has no connections when creating
the unbroadcast transaction.
    fa32e676e5
  59. [trivial] Remove misleading 'const' 
    Returning by const value is only meaningful in a specific circumstance around
user defined types. In this case, the const is not enforcing any restrictions
on the call site, so is misleading.
    750456d6f2
  60. [doc] Update unbroadcast description in RPC results 8f30260a67
  61. [trivial/doc] Fix comment type 9e1cb1adf1
  62. amitiuttarwar force-pushed on May 25, 2020
  63. amitiuttarwar commented at 6:34 pm on May 25, 2020: contributor
    thanks for review @MarcoFalke & @jonatack, comments have been addressed !
  64. glozow commented at 11:04 pm on May 25, 2020: member
    ACK 9e1cb1a And thank you for touching things up for me :)
  65. MarcoFalke commented at 4:21 pm on May 30, 2020: member

    ACK 9e1cb1adf1 👁

    Signature:

     0-----BEGIN PGP SIGNED MESSAGE-----
 1Hash: SHA512
 2
 3ACK 9e1cb1adf1 👁
 4-----BEGIN PGP SIGNATURE-----
 5
 6iQGzBAEBCgAdFiEE+rVPoUahrI9sLGYTzit1aX5ppUgFAlwqrYAACgkQzit1aX5p
 7pUg2Dwv9EQ7oHPs8SFa494QyeEFubUt6HHSV8eJl98uS1jhK6ty7WCcKvHToqZMe
 8PiC8Jrwjk53dWMNcFMFvSbhU2x8I5qIQjLKj/4YNLOwZaUKasOiAwGwxoNnWkXNU
 9MT5odexk+BnkuOtYZN24qteCcZdCGD4dQqT//UC4CmG9aR0vi2Ff+y45Qn5FOfrB
10NKR8OrgWh/AjTxrXCJMK73lGEscLuf0nmgOAqBJxt+VsONPpO2642RdAHASSqgD6
11mXBIIbZ9dEOOCVQorwuKu9lyLvZ1LRcz3hcZfTQLiVA1bQBnqEyyVDNv/rSl7JVS
120O+dFSXu+YkgJMmVkFyhRq3/Le69bbK4y44am2w6Ab4W+hhzLnR1LGJGf5iL53Zc
13QVQpqAEp7Zri2Vm5zZfqFK4y9sxqdmE8DZ4HrtljPT30Li8Hc7Ygo7cP0kVHPBhK
14MU3sT5r8T/+V8p3VOj6L1XVgHPH3D97xyg4kPaDFeUoK0UysKfFfPVME50ZXQ27p
15SNm8OtZI
16=3KJW
17-----END PGP SIGNATURE-----

    Timestamp of file with hash de6ba48e94c3bcb5032ea5569ce708038f02ef67193d1448110f51b57e5d3132 -

  66. MarcoFalke merged this on May 30, 2020
  67. MarcoFalke closed this on May 30, 2020
  68. sidhujag referenced this in commit e89c4bd9d2 on May 31, 2020
  69. in test/functional/wallet_resendwallettransactions.py:58 in 9e1cb1adf1 
    56+        now = int(time.time())
57+
58+        # Transaction should not be rebroadcast within first 12 hours
59+        # Leave 2 mins for buffer
60+        twelve_hrs = 12 * 60 * 60
61+        two_min = 2 * 60
    glowang commented at 3:41 pm on June 5, 2020:
    I’m curious - any reason why we chose 2 minutes here?
    MarcoFalke commented at 4:37 pm on June 5, 2020:
    It can probably be reduced to one second, if now gets set to block_time (the mock time before this call)
  70. ComputerCraftr referenced this in commit 285bce192a on Jun 10, 2020
  71. ComputerCraftr referenced this in commit d2fddf6f43 on Jun 10, 2020
  72. ComputerCraftr referenced this in commit 69e7eee7a1 on Jun 10, 2020
  73. ComputerCraftr referenced this in commit 1cf6ab1d17 on Jun 10, 2020
  74. MarcoFalke referenced this in commit 0afbeb73cc on Jun 16, 2020
  75. sidhujag referenced this in commit 7dda7c0a8c on Jul 7, 2020
  76. deadalnix referenced this in commit 0462bb493d on Jan 21, 2021
  77. Fabcien referenced this in commit ad4cfa37da on Jan 21, 2021
  78. deadalnix referenced this in commit 2b1e2420f9 on Jan 22, 2021
  79. Fabcien referenced this in commit 1f752d8a30 on Jan 22, 2021
  80. Fabcien referenced this in commit 731ea9c056 on Jan 22, 2021
  81. Fabcien referenced this in commit 0b9b237d21 on Jan 22, 2021
  82. Fabcien referenced this in commit 0b18505550 on Jan 22, 2021
  83. deadalnix referenced this in commit a26312c624 on Jan 22, 2021
  84. deadalnix referenced this in commit dbfdb444f5 on Jan 22, 2021
  85. Fabcien referenced this in commit a47972a97f on Jan 22, 2021
  86. Fabcien referenced this in commit 9be10274eb on Jan 22, 2021
  87. DrahtBot locked this on Feb 15, 2022


amitiuttarwar DrahtBot jonatack jnewbery fjahr brakmic Sjors MarcoFalke glozow fanquake glowang

Labels
P2P

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-12-22 06:12 UTC
This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me