From 622110727b76ce1d137df9a3b5e550dea762c031 Mon Sep 17 00:00:00 2001
From: wakgill <76528604+wakgill@users.noreply.github.com>
Date: Sat, 9 Jan 2021 16:14:41 -0600
Subject: [PATCH] Create 226.md

---
 226.md | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 226.md

diff --git a/226.md b/226.md
new file mode 100644
index 0000000..95d8177
--- /dev/null
+++ b/226.md
@@ -0,0 +1,24 @@
+---
+layout: forum
+title: 'Re: Privacy versus Safety: handling change'
+grand_parent: Forum Posts
+parent: Bitcoin Forum
+nav_order: 226
+date: 2010-07-17 16:27:39 UTC 
+original: https://bitcointalk.org/index.php?topic=434.msg3770#msg3770
+---
+
+# Re: Privacy versus Safety: handling change
+
+---
+
+```
+Re: Privacy versus Safety: handling change
+July 17, 2010, 04:27:39 PM
+
+We should queue up a supply of pre-made addresses in the wallet to use when a new address is needed.  They aren't very big, so it wouldn't hurt to have a lot of them.  This would more generally cover the case also where someone backs up, then requests a new address and receives a big payment with it.  Maybe there should be separate queues so one type of demand on addresses doesn't deplete it for the others.
+
+The addresses would be created and stored in the normal place, but also listed on a separate list of created-but-never-used addresses.  When an address is requested, the address at the front of the never-used queue is handed out, and a new address is created and added to the back.
+
+There's some kind of rescan in the block loading code that was made to repair the case where someone copied their wallet.dat.  I would need to check that the rescan handles the case of rediscovering received payments in blocks that were already received, but are forgotten because the wallet was restored.
+```